Why would it load twice? it would certainly load more VE instances, but the samples themselves would only be loaded once. If you're not sure it will work, then just try it with a small template first.
DG
190,665 users have contributed to 42,760 threads and 257,214 posts.
In the past 24 hours, we have 4 new thread(s), 12 new post(s) and 46 new user(s).
@PaulThomson said:
Ahh - I see. I get it now! Unfortunately it fails on my 64bit XP due to the graphic bug of going over however many instruments it is.. I'll have to check the threads out on that and see if I can get around that. Its still not a great solution long term as the extra instances will use a lot of memory and system resources so I hope that the VSL team are working on a proper solution. Thanks anyway! Cheers Paul
VSL has already said that they are working on a solution, but it will not be ready for a while. In the meantime, there are a couple of things that you can do to improve things:
DG
i have to admit i can't comment on the chunk technique (most of the time using win and trying to avoid DP support) - but i think i get the priciple ...
basically sample data which is not already in memory needs to be loaded.
say if a chunk contains only solo strings and you are loading now a chunk for chamber you need to wait.
other scenario: you have a larger preset loaded across several instruments and are now opening a chunk which contains patches (or matrices) which are not already referred referenced, so you need to wait until the missing patches are loaded
hope you can see it highly depends on the situation and what type of chunks should be loaded ...
christian
switching might behave different from (additional) loading - as long as patches are referenced they don't get unloaded.
to stay with the figurative explanation: closing a *chamber chunk* having chamber not referenced from other tracks will unload chamber data, now opening another *chamber chunk* will reload chamber data, just opening an additional *chamber chunk* will only load the missing patches, since a certain amount of chamber data is already referenced.
hth, christian
Does this re-loading of sounds occur each time you open a new chunk (sub-sequence) or just each time you open a new project?
You can share any virtual instrument between different chunks by using V-Racks. Normally I have a chunk for every cue, and all my virtual instruments reside in the V-Rack. I can switch between chunks within a fraction of seconds.
Cheers, Pitt
Thanks for that, Pitt. Great idea. Ideally, that's what I'd like to do as well.
So you're running DP on a Mac, & the V-Rack on your Mac can address VSL instruments that are loaded into slave PCs in multiple VE3 instances, as well as some VE3 instances loaded on your host Mac?
With that setup, what is your experience as far as reliability, latency and CPU load on the host?
And you don't have to reload samples when you change chunks?
If so, that's the ticket!
Best,
--Stu
I don't use slaves (yet), but the V-Rack will hold ANY virtual instrument audio unit and keeps it loaded whenever you switch chunks, so I am pretty sure it works with VE3 as well.
I'm working with V-Racks for over a year now, and it's very reliable. I've lots of sequences for every film (at least one for each cue, and these in lots of different versions), and I can instantly switch between the sequences. I haven't noticed any negative effect on CPU or latency. The only downside is that instruments in a V-Rack are not automatable. If you want to automate, say, the volume, then you have to route the output of the V-Rack VI into an aux track in the sequence. (But you can automate the MIDI volume, of course.)
For me, V-Racks are the killer feature of DP ... read the manual (p. 659) and try it out!
Cheers, Pitt
Hi again Pitt,
Yes, I've been using V-Racks also, since they were first introduced in DP. I have a huge Mach Five template as well as several Altiverb instances, which are always loaded into a V-Rack, thus always available from any chunk - I just didn't know if VE3 worked from a V-Rack.
The obvious advantage would be to avoid the mandatory reloading of VSL samples - until we get the promised VE3 update.
Has anyone tried this? (DP on the Mac, adressing multiple VE3 instances (loaded on slaves & the master computer) from within a V-Rack in DP).
Please report how it's working, thanks.
Best,
--Stu
Hi VSL,
Any news on that update to allow VE3 to keep samples in memory when switching projects?
Is it still 'late summer / early fall'?
Thanks,
David
Hi David,
we are working on it. It won´t be "late summer", sorry to say, but we ´re doing our best to be ready in fall (could be "late fall"). Software with that many OS´s to take care of is pretty hard to develop, especially with all the possible combinations and all the tests involved....
Best,
Paul