This is a specific VST problem but it may affect other multi channel VST's.
I was trying out Yellow Tools Independence Free. The Sample Player is a large (67MB) VST that also has some very nice samples. The Free version has a fixed number of samples but they are all superb. Internally you can assign midi channel input to specific instruments/layers. With a single sequence feeding the sampler I ran into no problems and was able to save the session easily.
After adding another sequence, and routing it to the same rack, the sequence works fine but when I went to save the session it immediately shows OVERLOAD and reports excessive CPU usage which appears to take over the machine. By waiting long it is possible to Quit the session. The session can be loaded and works normally, but again when it is saved it gets into a loop.
CPU usage when the sampler is processing is very low, but takes a lot of memory.
This may be just a compatibility issue, but it does prevent me from using Independence with MU.LAB
MU.LAB loops when saving the session
-
- KVRist
- 357 posts since 5 Aug, 2006 from St. Louis
-
- KVRAF
- 1645 posts since 24 May, 2002
I wanted to quickly check the plug out, but it's a HUGE download...
I assume it's a plug specific problem.
Maybe there is a virtual memory issue because it's so huge.
Did you try it in other hosts too? (on the same machine!)
Anyone else having experiences with this plug?
I assume it's a plug specific problem.
Maybe there is a virtual memory issue because it's so huge.
Did you try it in other hosts too? (on the same machine!)
Anyone else having experiences with this plug?
-
- KVRist
- 50 posts since 22 Mar, 2006 from NY Fingerlakes
Computer Music has the Independence Free on this issue's DVD. It has a couple extra instruments added to earn the CM moniker but seems to work fine with Mu.Lab.
I tried to lock it as described; up by using one sequence with a patch loaded then routing a second different sequence over to the same instance of Independence and then saving. Worked fine. Exit MuLab, restart and still fine.
Ran somewhere 25 -30% with other tracks running Raspier Bass, CM Fuzz, three instances of SpinEq CM, SFZ, Addictive Drums and Kjaerhus Classic Compressor (in other words a bunch of stuff) on a bottom of the line amd dual core 2 ghz, 2 gb ram, Vista, native onboard sound with asio for all.
I tried to lock it as described; up by using one sequence with a patch loaded then routing a second different sequence over to the same instance of Independence and then saving. Worked fine. Exit MuLab, restart and still fine.
Ran somewhere 25 -30% with other tracks running Raspier Bass, CM Fuzz, three instances of SpinEq CM, SFZ, Addictive Drums and Kjaerhus Classic Compressor (in other words a bunch of stuff) on a bottom of the line amd dual core 2 ghz, 2 gb ram, Vista, native onboard sound with asio for all.
-
- KVRist
- Topic Starter
- 357 posts since 5 Aug, 2006 from St. Louis
More on the lockup ....
I am running MU.LAB on a Toshiba Laptop, 2.4Ghz Athlon and 1GB of memory. Independence Free recommends a 3GHz processor and 1GB of memory, but states that the minimum is 1.6 GHZ.
MU.LAB only locks up when a change is made within the VSTi. It loads and saves fine until a change is made. When saving, the Task Manager shows 99% CPU for MU.LAB but no increase in memory usage during the loop.
I used the same files with the same Independence Free presets - two tracks routed to the VSTi and set this up on Sony Acid and also on Samplitude SE. I found no problems with either of these programs. I also tried to set this up in Orion but Orion does not support multi-channel VSTi. It handles one instance with no problem.
This is a very large VSTi especially the instruments. I will try MU.LAB on a different computer to see if it can be repeated elsewhere. The installation of Independence Free is somewhat time intensive.
I am running MU.LAB on a Toshiba Laptop, 2.4Ghz Athlon and 1GB of memory. Independence Free recommends a 3GHz processor and 1GB of memory, but states that the minimum is 1.6 GHZ.
MU.LAB only locks up when a change is made within the VSTi. It loads and saves fine until a change is made. When saving, the Task Manager shows 99% CPU for MU.LAB but no increase in memory usage during the loop.
I used the same files with the same Independence Free presets - two tracks routed to the VSTi and set this up on Sony Acid and also on Samplitude SE. I found no problems with either of these programs. I also tried to set this up in Orion but Orion does not support multi-channel VSTi. It handles one instance with no problem.
This is a very large VSTi especially the instruments. I will try MU.LAB on a different computer to see if it can be repeated elsewhere. The installation of Independence Free is somewhat time intensive.
-
- KVRist
- 50 posts since 22 Mar, 2006 from NY Fingerlakes
I see, that's a little different, I'll try to follow that and get back.
btw I stick the big content files (as well as most other hard drive hogs like banks, samples, sf2's etc) out on a USB hard drive just for that reason. As long as the Independence's Basic Path gets put together right you can copy the .dll file over to your usual plug folder and browse later for the content.
Also btw there's an item under preferences that allows block size for the samples moved into ram according to the HDD access speed (fast = small blocks of data, slow = larger) it makes a big diffence in how much the hdd lights up so it likely affects ram usage.
btw I stick the big content files (as well as most other hard drive hogs like banks, samples, sf2's etc) out on a USB hard drive just for that reason. As long as the Independence's Basic Path gets put together right you can copy the .dll file over to your usual plug folder and browse later for the content.
Also btw there's an item under preferences that allows block size for the samples moved into ram according to the HDD access speed (fast = small blocks of data, slow = larger) it makes a big diffence in how much the hdd lights up so it likely affects ram usage.
-
- KVRist
- 50 posts since 22 Mar, 2006 from NY Fingerlakes
OK hopefully reproduced what you had a problem with.
First aimed not two but three sequences at the offending Vsti using a single patch, preferences set to slow hard drive so ram was up. System use came out:36% with 1 sequence and upwards of 45 -55 % with three sequences going.(all the other stuff I mentioned earlier, together, added up to less than 20% and no one process exceeded 5-10%)
Messed with the settings (pitch bend, LFO, filter etc. Save still ok. Changed patch and left the Vsti editor then saved session and got an overload but this was easily escaped from by Jo's button on the resource meter. No lockup.
I'd say from this end it's a ram-system-Vsti thing not MuLab. Good luck at your end.
First aimed not two but three sequences at the offending Vsti using a single patch, preferences set to slow hard drive so ram was up. System use came out:36% with 1 sequence and upwards of 45 -55 % with three sequences going.(all the other stuff I mentioned earlier, together, added up to less than 20% and no one process exceeded 5-10%)
Messed with the settings (pitch bend, LFO, filter etc. Save still ok. Changed patch and left the Vsti editor then saved session and got an overload but this was easily escaped from by Jo's button on the resource meter. No lockup.
I'd say from this end it's a ram-system-Vsti thing not MuLab. Good luck at your end.
-
- KVRist
- Topic Starter
- 357 posts since 5 Aug, 2006 from St. Louis
Thanks for the tips on the performance parameters, I will give it a try. There is also an automatic RAM cleaner that can be turned on, I am also trying that.guitarfrodo wrote:btw I stick the big content files (as well as most other hard drive hogs like banks, samples, sf2's etc) out on a USB hard drive just for that reason. As long as the Independence's Basic Path gets put together right you can copy the .dll file over to your usual plug folder and browse later for the content.
Also btw there's an item under preferences that allows block size for the samples moved into ram according to the HDD access speed (fast = small blocks of data, slow = larger) it makes a big diffence in how much the hdd lights up so it likely affects ram usage.
I installed the Yellow Tools business on my desktop computer - Athlon 2800, with 1.5GB of RAM. Yellow Tools is installed here on a separate 7200 SATA drive (my Audio files drive). It runs at only about 5-8% CPU in MU.LAB, so I don't think the block size has anything to do with it. Now when I save, after making changes, the OVERLOAD light comes on, but eventually (3 secs.) gets back to normal. This means that MU.LAB is doing a lot of work to save the MuSession - maybe too much work.