Audio driver settings/RAM constantly filling without unloading

[tatanka]

Hi,

two problems where I am looking for some advice, second problem maybe something buggy in the actual version.

I have an old PC with only i-3 and 8 GB RAM, WIN 7, 64 bit, Mulab 8.0.66.

First problem is sounddriver(s), I have tried evrything I have but did not find a good solution so far, Problem is too much CPU use or crackles. Alternatives I have:

- just the onboard windows drivers/sound. As I do not plan to do some audio recording (only midi tracks with VSTi to play them and the effects right on the track or on the master track, then render whole projekt to file at the end) this might be an option but CPU gets high very soon

For the ASIO world:
- I have an old Creative Asio Soundblaster card which still works good on other DAW (Wavefrom, Studion One) and has done fine on Mulab 6 but on Mulab 8 same Problems
- Asio4All this is my actual "least bad" with latency set to highest possible (2048)

What makes me wonder: on my Notebook (not that much younger and better) with win 10 I only have the win 10 onboard drivers and that works as aspected for that class of Notebook, no problems.

And I have not changed the PC and remember no problems on Mulab 6 while I was using it some years ago, it works with the same Audio drivers/settings then my other DAW.

So any advice really appreciated.

Second problem:

- it seems that Mulab in the actual version (could not say if any of the betas has it already cause I dont have tested it intensively) fills the RAM up continously while using it even if you dont add anything that might use RAM. I realized that while it crashes when trying to add Jamstix (that is normally my last VST to add when the core of the song is done) several times. Then I loaded the project again. When evrything is loaded it has around 5 GB from my 8 GB in use, thats realistic for the libs I use in that project. But when I worked on it for a while and I looked on the RAM use in the Taskmanager I realized that it was near to 7 GB so it could be that there was just not enough left for Jamstix to load properly. This happened a few times and the filling of the RAM goes on continously without loading anything that would need some RAM so I really thing there is something wrong with unloading the RAM in Mulab/from Mulab to windows.

[mutools]

About issue 1:

I can only give the standard tips:

* Try increasing the audio buffer size
* Optimize the multi-core settings

Both can be controlled via MuLab's Audio Setup.
See http://www.mutools.com/info/docs/mulab/audio-setup.html

About issue 2:

Note that when you delete eg. a VST it is not yet deleted from RAM as it still is in the undo queue.
To clear the undo, you can use a shortcut to "Clear Undo History".

If you still think there is something wrong and it is repeatable when not using any VSTs then please give me a step by step how to repeat it.

[Saffran]

This makes me think of the copy command in other daws.
There's two sorts of copy. One that makes an independant copy and need use of ram and the second is a link to the original sample and don't use more ram.

[dakkra]

This makes me think of the copy command in other daws.
There's two sorts of copy. One that makes an independant copy and need use of ram and the second is a link to the original sample and don't use more ram.

Mulab has both of these options for samples and sequences. However, VST's are a bit of an odd spot. If you were to "link" (reference would be a more appropriate term given the underlying concept of a pointer) a vst you would hear the same sound/effect everywhere it got linked. That makes it near fundamentally worthless as unlike samples and sequences, users generally want unique settings in their VST.

Mulab could try to do an FXB copy into ram so that the VST can be disposed, but this would also have some serious drawbacks. Namely, the undo event would have to reinitialize the VST and then import the FXB, thus eating up a lot of time/buffer. Secondly, not all VST's report all of their parameters to the host/DAW (MUX, Falcon, MSF, basically anything modular...) so the host cannot store the VSTs state, making the undo non-functional.

It's a weird spot. Undoing within the host and it's own native functions can be done with perfection while mostly preserving RAM, but an undo on external plugins simply will not be 100% effective without storing it in RAM.

That is simply a trade off in using plugins. They will always be more resource heavy than the host because the host doesn't have native/direct access to them.

Hope this helps to bring light to the subject.

Dakkra

[tatanka]

Thanks for the info, did not know that there was a specifice audio setup info in the Mulab Doc, that was helpful for understanding some grounds and that I really dont need Asio if I dont do Audio recording if the MME brings better performance in the end.

I will do some testing with the blocks/blocks size have not done that so far. And maybe try not to use all cores for better over all performance (multi core settings).

What stil wonders me is that I never had any audio setup/driver problems with Mulab 6 but maybe thats just because at that time PC and Mulab where kind of "up-to-date" and now difference between old PC and conditions of Mulab 8 have just gone into different directions

Joe:

To clear the undo, you can use a shortcut to "Clear Undo History".

which shortcut ? I will have an eye of this, that might be a cause that I have just replaced some VST and if the old ones still where in the RAM....

Thanks to you all again !

[pljones]

You can set up any key to be a shortcut to any of the available shortcuts. If there isn't one assigned, you can pick one.