I've been working with VI a lot the last couple of days and I still notice the clicks, but they seem to be contained to the first few minutes of loading VI. Once I've been running VI (even with multiple instances) for a while, like 2 hours or more, I don't hear any clicks anymore. I've been RAM optimizing, adding CC expression data, velocity fades, everything I need and just having a ball and the clicking is gone. Still, when I reboot my computer and restart VI for the first time after reboot then I hear clicks and pops, but once used....its fine. Strange, like I said I can work with it, and the clicks still do not appear in bounced tracks...bounced audio sounds great! Has anyone else experience this?

BTW, VSL SE is incredible! Hats off to you guys!

Sorry to bump my thread, but I noticed something I think is important about my pops and clicks issue.

Hardware: Macbook Pro (Intel Core Duo) / 2 GB RAM

Software Setting: IN "LOGIC"
I/O Buffer Size - SET TO 1024
Large Disk Buffer - CHECKED OFF
Process Buffer - SET TO LARGE


1) The "Activity Monitor" shows processing equally distributed across both cores (as an overall average) most of the time.

2) However, using the "System Performance" window in Logic reveals that one core is being used almost entirely for audio processing. Therefore I'm going to experience clicks and pops when one core overloads, but why is it not distributing the work load across both cores? Is this a Logic issue, a OSX 10.4.9 issue, a VI plugin issue?

Has anyone else seen this? Also, the above software settings in Logic seem to help a lost especially with audio core overload settings, and I might add that I get less overload messages when I use my Digidesign MBox Mini than with the internal sound card.

Thanks, Brian

i also see that the load is not always distributed equally in logic.
however, as you wrote in your first post - and as i experienced myself - these problems arise already when only playing a single matrix (and even in the standalone player). in this case the cpu-meter is all the time below 3% - except when such a dropout occurs, where it jumps instantly to ridiculously large values like 150%. this can´t be a "real" overload caused by an unbalanced distribution.

Same here, I wrote a post about the problem immediately after I bought my first Vienna Instrument. It isn't a 10.4.9 issue - was in 10.4.8 as well. 10.4.9 didn't break anything for me.

I hope they are working on some fix [H]

I have LOTS of the mentioned "first play-clicks".
Both on a MacBookPro 10.4.9 and a G5 2GHz 10.4.6.
The MacBookPro takes its samples from a Firewire 400.
The G5 from a E-Sata Raid (very fast)

If noticed that the clicks go away if the matrix has been played, AND its individual notes have to be played.

Example: Existing arrangement from yesterday -> played today -> LOTS and Lots of clicks, pops an cracks -> on 3rd playthrough it is usually ok -> play a note new to the arrangement -> it clicks -> 2nd or 3rd time its ok.

Somehow the VI does not load all sample starts??

All the best,

Jochen

@Josch said:

I have LOTS of the mentioned "first play-clicks".
Both on a MacBookPro 10.4.9 and a G5 2GHz 10.4.6.
The MacBookPro takes its samples from a Firewire 400.
The G5 from a E-Sata Raid (very fast)

If noticed that the clicks go away if the matrix has been played, AND its individual notes have to be played.

Example: Existing arrangement from yesterday -> played today -> LOTS and Lots of clicks, pops an cracks -> on 3rd playthrough it is usually ok -> play a note new to the arrangement -> it clicks -> 2nd or 3rd time its ok.

Somehow the VI does not load all sample starts??

All the best,

Jochen

Jochen,

I remember a few posts back that Dietz had said something about Macs possibly paging samples starts in memory to virtual memory and that Macs are not suppose to do this, but it might be happening. Indeed that would probably cause significant processor spikes because of the time sensitive nature of needing particular sample starts during playback.

Brian

Hmmm..... do you mean, even if virtual memory is switched off?

But that would make no sense. Why store sample starts in Virt. memory (=on a disk) when they already are on a disk?

Hmmm, well certainly if virtual memory is off it can't be that. BTW, how do you turn off virtual memory on a mac?

Sorry my mistake, it was cm that talked about Macs and virtual memory, here's the quote below (http://community.vsl.co.at/viewtopic.php?t=11099&iframe=true">http://community.vsl.co.at/viewtopic.php?t=11099&iframe=true).

QUOTE from cm:

@Another User said:

as a long-time user of both (and more) platforms i'd like to just pick one point about one could discuss weeks:
- windows still has this division in kernel and user memory, so if you want to access 3 GB RAM on a 4 GB machine you have to configure it
- OS X still does not allow to configure the pagefile and i'm under the strong impression sometimes it swaps samples to virtual memory
- an ideal operating system would avoid both

[/url]

thanks simon, that´s very helpful to know that 10.4.9 is not causing this! wouldn´t have been much fun anyhow to go back to the old system.

the idea that the virtual memory management may cause these problems sounds reasonable. unfortunately, afaik one cannot turn off virtual memory in osx.

Well, if it was a general OS issue, shouldn't it happen in all other sample-players as well? Haven't had the problem with EXS24 or Kontakt [H]

hi,

unfortunately it is true that OS X uses to "page out" data which doesn´t seem to be relevant at this very moment for the OS. And because you cannot switch off or limit the so called "Swap File" in OS X it can happen that some of our samples get swapped into the virtual memory (= located on the internal HD) on first load.

After you have played with the samples a little it gets obvious for the OS that the regarding data is needed for playing back the samples in the required timeframe (meaning in realtime) and that it is important data.
Therefore the samples get a higher priority and will be kept in" Real Memory", which means they do not get swapped to "Virtual Memory" anymore.

This is exactly what happens when you notice that the more you play with the samples the less clicks you get.

This also happens to samples loaded in an Instance of an EXS player very frequently.

I just did a Workshop in Berlin a couple of weeks ago and played back a Piano track from an EXS instance on a MacBook Pro (from the internal Drive) and on first playback I think every sample header was swapped to virtual memory.

I didn´t only get clicks but after playing with crackles and clicks for some bars the machine stopped with an error message saying "Samplerate 44073 detected. Error while syncronizing Audio and Midi"

Obviously the HD drive was too slow to stream all sample headers with the right samplerate.

Apple knows about this behaviour and that this is a problem for RAM-intense realtime applications. As far as we know the problem is being investigated by Apple but we don´t know at the moment what can/will be done about it.

I got the information from an Apple engineer that the more RAM you have installed the better, because when physical RAM is still free, the Swap File Technology starts to use this free ram for its page file. So the samples are just moved from the Real memory of the thread "VSL-Server" to another area in the physical RAM.

Therefore having more RAM installed will reduce the clicks significantly since for the samples it doesn´t matter at which spot of the physical RAM they are stored.

best
chrisK

I can corrobate this statement.

Maya

simon,
if the memory/hd access of the exs and the vi is identical, then you are surely right. i just thought that a difference here might make the vi more vulnerable to changes in apple's virtual memory management system.

chris,
thanks for your reply!
i think it is not surprising that you can get such issues also with the exs when you stream from the internal hd - but i never experienced this with the exs when streaming from a decent external disk. what people report here, is that they have these dropouts even when using a fast sata disk and when basically none of the ram is used.
i for one have these dropouts when i load a single matrix - which uses e.g. 20 mb so that there are still more than 1.5 gb free memory available (after a fresh startup) - and play a simple (basically monophonic) melody line - streaming from a dedicated firewire 400 disk from which i can stream whole arrangements without any problems when using the exs.

best

kai

kai, besides i have to confirm chris' observations - the reason for not noticing the behaviour when streaming from an external disk ist not so much the speed of the disk itself, but the fact that OS X pages to the system volume which is on the same disk on a notebook, so simultaneous access to different regions of a disk can easily cause such a behaviour.
christian

edit: this is one reason why we recommend for all products to have the data on a fast, seperate hardrive

A merry thanks to all the knowledgeable people who answered this thread! This all makes a lot of sense now. Overall I am extremely pleased with my Vienna Instruments. I made the decision to backup, erase, and reinstall my entire computer to clear out the HD and memory of all the junk I no longer use. I must say, after a fresh reinstall VI is working better than before. Thanks again!

-Brian

@Another User said:

I just did a Workshop in Berlin a couple of weeks ago and played back a Piano track from an EXS instance on a MacBook Pro (from the internal Drive) and on first playback I think every sample header was swapped to virtual memory.

I didn´t only get clicks but after playing with crackles and clicks for some bars the machine stopped with an error message saying "Samplerate 44073 detected. Error while syncronizing Audio and Midi"

This is very unusual, and usually it goes away after the first play. It is pretty customary for me to have a substantial number of EXS24 instances in my sessions without any issues.

However a single instance of VSL VI is enough to create clicks and pops. While I don't dispute that OS X has odd ways of handling data, this is obviously an issue that others have resolved. EXS24 and Kontakt simply don't exhibit the same behavior as VSL VI, and I sincerely hope that VSL doesn't hide behind the excuse of "It's not us...it's them" without making a good effort at imrpoving the code of the VSL VI engine.

@cm said:

kai, besides i have to confirm chris' observations - the reason for not noticing the behaviour when streaming from an external disk ist not so much the speed of the disk itself, but the fact that OS X pages to the system volume which is on the same disk on a notebook, so simultaneous access to different regions of a disk can easily cause such a behaviour.
christian

edit: this is one reason why we recommend for all products to have the data on a fast, seperate hardrive

I have all samples on a RAID 0 set of fast WD harddrives, I still get clicks and pops for the first few minutes. I don't get that with Ivory, Akoustik, Kontakt 2 or other disk streaming based players.

@Simon Ravn said:

I have all samples on a RAID 0 set of fast WD harddrives, I still get clicks and pops for the first few minutes. I don't get that with Ivory, Akoustik, Kontakt 2 or other disk streaming based players.

Does VI appear to perform better with increasing time of usage or not? If not, its maybe not a problem caused by the OSX RAM Management...Could you please give us some more details?

Best
Maya

Same problem here. When played for the first time, most patches create pop / click. When playing the same notes a second time, everything's fine.

As other people here, this never happens with any other sampler / plug-in (EXS24, Kontakt, Ivory, Trilogy, etc.).

Jerome

In my experience this does not stop happening after repeated playback of the sequence. Clicks and Pops appear at first play, and the appear after playing it 20 times. All of my VSL SE sounds are housed on an internal SATA drive which is dedicated to samples only and nothing else.

I suspect that as more users buy VSL VI products, more people will chime in with these issues. Once again, I really hope that you guys are taking a closer look at the code trying to determine what might be happening and hopefully releasing an update asap.