MUTOOLS

pljones · Post by **pljones** » Sun Jun 16, 2013 5:14 pm

I've just hit another problem.

I'm trying to mix down a MIDI file that drives a drum track in sforzando. I noticed on listening to the file that it stuttered as if sforzando hadn't been able to keep up. After another mixdown, I checked it's "Disk Loss" report and, indeed, it was reporting a large number of samples/buffers (I'm not quite sure which) being dropped.

I loaded up the MIDI file, sforzando and SFZ file into Reaper to check whether this was a problem with sforzando itself. In Reaper, the render took about the same amount of time but suffered no disk loss (according to sforzando). The file also sounds okay.

Is there something a VSTi needs to tell MuLab that sforzando isn't doing? Or is sforzando telling MuLab something that it's not hearing? So to speak...

(-edited to remove comments on RAM usage as it appears inconsistent, so likely unrelated-)

mutools · Post by **mutools** » Sun Jun 16, 2013 7:55 pm

To be honnest i don't know why Sforzando suffers from buffer losses in this case. I'll forward your question to Plogue.

pljones · Post by **pljones** » Mon Jun 17, 2013 6:15 am

Real-time vs off-line? Does MuLab tell the VST that it's rendering in off-line mode? sforzando, when in real-time mode, will prioritise "keeping up" over playing every sample (or buffer), which is what appears to be happening.

mutools · Post by **mutools** » Mon Jun 17, 2013 7:03 am

No, but it also doesn't support the "canDoOffline" selector so the plug shouldn't rely on it i think.

EvilDragon · Post by **EvilDragon** » Mon Jun 17, 2013 8:12 am

A good question is WHY MuLAB doesn't report plugins about offline rendering state? This could introduce issues with quite a few plugins (most notably EW PLAY, but there are others).

mutools · Post by **mutools** » Mon Jun 17, 2013 8:24 am

It is not obliged by the VST specs
So you could also reverse the question towards the plug devs
It's the first VST plug in hundreds/thousands that may suffer from it
You could ask the same question about any other FR in any other app. At least in MuLab/MUX's case the answer is always: http://www.kvraudio.com/forum/viewtopic.php?t=357048

davidv@plogue · Post by **davidv@plogue** » Mon Jun 17, 2013 1:19 pm

Hello

Plugins need to know which processing level you are running.

If your host starts a bounce/rendering session, plugins typically call the host's
audioMasterGetCurrentProcessLevel in the ::resume method

We are looking for kVstProcessLevelOffline, this is our cue to switch rendering mode, from a parallel (real time) streaming thread to an offline mode where we will read samples from disk direclty in process.

This has been the consensus IIRC for a long time on vst-mailing list, and theres plenty of threads everywhere about the topic:
http://forum.cockos.com/showthread.php?t=46599
Even Juce does it:
https://github.com/julianstorer/JUCE/bl ... rapper.cpp

[EDIT] We had to look for ProcessLevel changes in process as well, and we do support that too.

canDoOffline is for something else (effOfflineNotify, effOfflinePrepare, effOfflineRun) thanks to VST's lack of clear documentation, it is quite confusing

Regards

mutools · Post by **mutools** » Mon Jun 17, 2013 1:56 pm

Hey David, thanks for your prompt reply here and your email. I'm replying via email so we can go technical on this. When we have concluded, i'll post conclusion here.

mutools · Post by **mutools** » Mon Jun 17, 2013 2:57 pm

davidv@plogue wrote:Plugins need to know which processing level you are running.If your host starts a bounce/rendering session, plugins typically call the host's audioMasterGetCurrentProcessLevel in the ::resume method

Cfr our emails: To be honnest i would be very amazed if all plugins must be suspended+resumed before mixdown as that would most probably cause heavy delays when a user starts a mixdown because all plugins are first resetting themselves.

We are looking for kVstProcessLevelOffline, this is our cue to switch rendering mode, from a parallel (real time) streaming thread to an offline mode where we will read samples from disk direclty in process.

Ah ok, MuLab is currently returning kVstProcessLevelUser during mixdown, which is theoretically correct. But i checked your suggestion to return kVstProcessLevelOffline and it indeed seems to be the consensus. Didn't know about that as the VST SDK doesn't make this clear... (Oh that ambiguous VST SDK!!! So many probs it already caused

)

Thanks for the suggestion, i'll update MuLab.

davidv@plogue · Post by **davidv@plogue** » Mon Jun 17, 2013 3:19 pm

mutools wrote: Cfr our emails: To be honnest i would be very amazed if all plugins must be suspended+resumed before mixdown as that would most probably cause heavy delays when a user starts a mixdown because all plugins are first resetting themselves.

I guess it depends on the plugin, but reallocating a bunch of buffers and calculating tables for us doesn't take that much time in resume(). Many have called ::resume() the "second constructor" of the VST plugin.

Of course don't want to do any memory management duties in processXXX(), unless of course that process calls knows its in offline mode, or the first time its been in offline mode.

Ah ok, MuLab is currently returning kVstProcessLevelUser during mixdown, which is theoretically correct. But i checked your suggestion to return kVstProcessLevelOffline and it indeed seems to be the consensus. Didn't know about that as the VST SDK doesn't make this clear... (Oh that ambiguous VST SDK!!! So many probs it already caused )
Thanks for the suggestion, i'll update MuLab.

Yes the current state of plugin<->host VST spec interpretation is often way off track with regards to the official (TM) documentation. Luckily its quite stable now (since 2.4 is deprecated lol).

Thanks for your support.

mutools · Post by **mutools** » Mon Jun 17, 2013 3:27 pm

davidv@plogue wrote:Yes the current state of plugin<->host VST spec interpretation is often way off track with regards to the official (TM) documentation. Luckily its quite stable now

Hey it sounds like you talk about an official unofficial VST SDK. Where is that?

(since 2.4 is deprecated lol).

That's the first i hear about that. VST 3 is an almost complete new SDK and VST 2.4 is still alive in parralel to that, afaik. No?

davidv@plogue · Post by **davidv@plogue** » Mon Jun 17, 2013 3:34 pm

mutools wrote: Hey it sounds like you talk about an official unofficial VST SDK. Where is that?

Sadly in no shape or form that i know of, its scattered through posts on [vst-plugins], various forums and arguments over in #musicdsp (wow that was a long time ago for me).

That's the first i hear about that. VST 3 is an almost complete new SDK and VST 2.4 is still alive in parralel to that, afaik. No?

I don't think its alive in the sense that Steinberg is ever going to change/update the 2.X branch. I kind of like it the way it is. It wont change, wont break

mutools · Post by **mutools** » Mon Jun 17, 2013 3:51 pm

davidv@plogue wrote:I don't think its alive in the sense that Steinberg is ever going to change/update the 2.X branch. I kind of like it the way it is. It wont change, wont break

Ah i now understand how you meant it. Yeah i agree. Sometime ago i posted a suggestion to Steinberg (via the VST mailing list) about updating the docs of the VST 2.4 SDK here and there just to eliminate ambiguities, but even a dead room gives more feedback.

MUTOOLS

KVR Audio

[Bug Report MuLab 5.1.5] Mixdown Audio with sforzando is lossy