mikaelhansson

As an update, this was reproduced and confirmed by Line6 so it was added to their look-into-it-list. I offered some ideas about solutions but just got a response to add it to Ideascale which seems odd after looking into what's normally posted there. I'll just put it here in case someone is interested: Hi, thanks for the reply! Yes, I realise it's quite complex. If I'm not getting this completely wrong, I guess an approximation could be done by having each module report its decay time and then just add them together left-to-right, applying a max function where there are parallel paths. If the problem is deemed too complex, I would suggest that you make a (user)setting per program where you can make the plug-in report an infinite tail. This way you can let the plug-in stay active only when it's needed without having to disable Cubase's resource saving feature.

I just want to add that, I get it, it's their job to be a filter so the developers can work on real bugs.

No difference if Trails is on or off. I have dived in to the VST3 specs to get some insight into this. All audio processing plug-ins have to implement an interface called IAudioProcessor. In there is a method called getTailSamples that are supposed to return the number of samples that are needed to let the tail decay. The VST3-host can then use this information for whatever it wants. Cubase use it to reduce cpu load by asking the plug-in how long the tail is and then disables the plug-in if there's no audio input and the tail has decayed. This resource saving function can be disabled by unchecking a checkbox in preferences, hence why it works when I uncheck the setting...but at the cost of all plugins staying active, regardless if they are only used for a single bar in the beginning of the song. Reaper don't have this feature what I can see, all plug-ins stay active, that's why it works there. I also downloaded Steinbergs TestVST-host. It contains some conformance tests and, surprise, it failed in the "Check tail processing" test. :-) As this only applies to VST3, it fails in Cubase but works in Logic (AU plug-in version). All this makes me fairly sure this is a genuine bug, it would be really odd with a problem in my setup that only affects Native and not other plug-ins. I submitted a ticket but I'm having a hard time getting past 1st line support, I've had to answer twice that unchecking the checkbox is not an acceptable solution.

Yeah, you're right...submitted. Thanks for pushing me in the right direction!

If anyone from Line 6 is snooping in there's some info in the VST3 SDK that might regard this: IAudioProcessor Class virtual uint32 getTailSamples( ) Gets tail size in samples. For example, if the Plug-in is a Reverb Plug-in and it knows that the maximum length of the Reverb is 2sec, then it has to return in getTailSamples() (in VST2 it was getGetTailSize ()): 2*sampleRate. This information could be used by host for offline processing, process optimization and downmix (avoiding signal cut (clicks)). It should return: kNoTail when no tail x * sampleRate when x Sec tail. kInfiniteTail when infinite tail.

Ok, I've found the reason. In Preferences->VST->Plug-ins there's a checkbox for Suspend VST 3 plug-in processing when no audio signals are received. Still, other plugins seems to handle this even if the checkbox is ticked, I guess they are checking if the plugin is still outputting sound and somehow "tricks" the VST3 protocol. I would say that this (like the other plugins handle it) is the preferred solution as having it unchecked drains unnecessary resources from plugins only used in other sections of a track.

Another thing to add is that the output meters in Native freezes for 1-2 sec when the sound is cut off.

No, it's definitely time based as the time until it cuts off is unaffected by the current level of the reverb tail or, if I'm using a delay with endless feedback, the signal is actually hotter when it's cut off. No other plugins have this problem. I've tried both built in and 3rd party plugins. Mysterious indeed...

Ok, so not a universal problem. Downloaded Reaper to try it in another host and both the AU and VST3 versions works there so it's either a problem with Native in Cubase for Mac or something in my setup. EDIT: I should add that other plugins don't have this problem in my setup. Anyone else with Cubase 9+ on a Mac that can try it out?

I wouldn't say resources are a problem since I've been running 16 simultaneous instances of Native as a test before, I'm on a Late 2016 MBP with 16GB. Just using an empty project in Cubase, playing a piano through one instance of Native, CPU-meter hardly reacting. Also tried with the Legacy Digital Delay, same problem. I'd guess they just cut processing off after the input has been inactive for something like 10 sec. Mostly not a problem but not so good for esoteric, ambient use of the reverbs and delays.

Seems like they cut off after about 10 sec. Does anyone else experience this? To reproduce, just take one of the longer reverbs, like the new Ganymede, set decay to max, send a short sound through it and wait. Same problem with delays, just bump up the feedback with something like the Transistor Tape. Btw, this problem was also present in the previous version.

It seems as there's a glitch in the Cosmos Echo in Native, at least in my setup. It seems to just cut the output after about 10 seconds. I have attached a short audio snippet. Tried the same on the Helix Rack and there it works without problem...endless regeneration :-) Anyone else with the same problem? /Mikael Cubase 9, Mac OS Sierra echo_error.mp3

Everything worked like a charm, no problem installing and setting up the trial version. The presets were not loaded automatically though as someone else mentioned but it was solved by a quick look in the manual to find the restore function. Performance wise it seems quite ok as well for being v1.0. When using "normal" presets I have no problem running 16 separate instances (about 70% average load) on my late 2016 15" MBP i7 running Cubase 9. There are exceptions though, Factory 2 - 01B - Cavernous Clean peaks the cpu, even when it's the only instance running, causing pops and clicks. Looking at the amount of slots filled in the patch it's not a surprise though... :-) /Micke