Using DP I find load times will still vary from very slow to extremely fast on the same project that I start up many times in a day. Is there no way to keep the speed up?
-
Load times '08 Mac Octo-8 core 3ghx 14gb ram
-
I've noticed projects load quicker if they've been loaded before. However I was comparing load times with the new Play plug-in (East West) if you look at Activity Monitor on my system it maxes out at about 60MB/ second sample load - whereas Vienna Instruments have yet to go over 20MB/second. Both plug-ins stream samples with a bit from RAM so I wonder what the difference is? or is it just my system? Julian
-
I'm using DP and I find the load varies for VSL. After you open a session a few times it is much quicker but when you change buffers for any reason your back to slow loads like it has to learn all over. At least that's better than BFD2 where the samples and files can't even be found most of the time and if you reload the VI you loose your authorization and have to come crawling back to FXpansion for a few more installs. This is an the ultimate nightmare. Still, with multiple instances of VSL and that fresh boot to a project the VSL library seems lagging most other software on the 08 macs. My post tried to ask this question more from DP's perspective rather than VSL but I wondered if there was any way to help this issue out from the VSL end of things.
-
some background on that topic ....
if you load presets/matrices/patches a certain portion is loaded into compter's RAM - more precisely a certain amount of RAM is reserved by the VI and filled with data, initially with the preload data, later with buffer data.
if you now *unload* this patch/matrix/preset the reserved space is kept as long no other data needs it, so loading the same thing again later does not need a new memory allocation, only raw data loading - the complete process appears faster.
the above said goes for the stand-alone so far, now if you are using VI as plugin many parts of the process are handled by the host (alongside with VST or AU) and it appears that changing a buffer size for the host is forcing a re-allocation of RAM in the plugin.
this sounds somehow logical to me, because changing a buffer size means different size of data-portions to be streamed which finally should affect the way of adressing of the reserved RAM.
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
Thanks for this Christian. It helps. In DP and most other DAW apps using MACS we are constantly changing the buffers as needed to deal with our ever increasing use of VI's and tracks during the climb to finish of that project. DP will not tell you what buffer setting you need from the control panel like Nuendo does which is unfortunate so we're forced to experiment a bit and change buffers often. Also forcing the "buffer shuffle" as I like to call it is the fact that midway through projects, overdubs are required and we find ourselves trying to reduce latency as we lower buffer settings again to get back safe no crash playbacks as we seek out temporary lower throughput delays for midi, vocalists and musicians. This on a mac is due to the fact that there are no DAW makers willing to address DM (direct monitoring) issues in the MAIN MIXERS on MAC machines. Instead we rely on RME's or MOTU's side mixers to accommodate this. Unfortunately switching from playback to input is left un-tackled. Our entire working system is inherently tied to buffer settings and thus require constant reloads slowing down the workflow. Is there an eventual answer to all of this? Back to analog? :)
-
Thanks, Know that but my investment is pretty set. I do want Christian to know that although VSL claims faster loads on reopening of the same project, with a cold boot start on this machine. most of the ram allocation has to be redone and your back to waiting on long VSL loads. If you close the projects in DP and immediately reopen it, yes, it's very fast. This was what my original point was on this post although poorly explained by me. Other VI's do not have this issue like Kontakt 3, BFD2 and East-West. They all remember data locations and load quickly on reboot of the machine. There must be something about the way VSL is written which does not hold these load waypoints. So... this question is still unanswered. Will you guys improve this in the future?
-
My understanding is that if you reload samples without re-booting it is quick because those samples are still in RAM if there is enough spare RAM in the machine. Whereas on a re-boot all the samples have to be loaded directly from disc so I would have thought that the other virtual instruments would equally just have to start from scratch again as the data locations would be the default hard disc locations. However for whatever reason per MegaByte of raw sample header VI and Ensemble seem to load at a fairly slow rate compared with other virtual instruments. Now this could be due to sheer number of samples rather than data size but a speed increase would certainly help diminish the up to 15 minute load times I'm currently experiencing for very large projects. I wonder how long Herb's 32GB session takes to load from cold boot?! Julian
-
Yes, julian. It could be the shear size of the load by comparison. I wonder if instead of loading every articulation for a group VSL might rewrite the software to make an analysis of ONLY the used samples and just load them. This load template of course could change and we would expect a longer load but at least we would have much smaller load times overall or is that the way it currently is?
