Amazing new way to conserve CPU usage of your effects plugins

[nyrvsystems]

Hi all,

Just posted a video demonstrating the CPU conversation power of NYRV AGENT (nyrv is pronounced nerve)

Check out this video showing how to save a ton of CPU resources https://youtu.be/j12KdIiK8q8

[bungle]

Nyrv is pronounced nerve. I presume conversation is pronounced conservation

[JerGoertz]

That's interesting, but it would be good to see how it fares under "actual project conditions" (i.e., with audio running on some tracks some of the time).

In any case, looks promising!

[bungle]

That's interesting, but it would be good to see how it fares under "actual project conditions" (i.e., with audio running on some tracks some of the time).

In any case, looks promising!

Yes it is a nonsense hype test, if a plugin uses a certain minimum amount of cycles, then no magic wrapper will make it use less.

[nyrvsystems]

That's interesting, but it would be good to see how it fares under "actual project conditions" (i.e., with audio running on some tracks some of the time).

In any case, looks promising!

Yes it is a nonsense hype test, if a plugin uses a certain minimum amount of cycles, then no magic wrapper will make it use less.

I encourage you to download the demo and run your own test. It works regardless of the plugin as we bypass the entire plugin if there is no signal in the buffer of AGENT. We actually do this at every slot. so it even works if you put a gate in the first slot. whenver the gate is engaged AGENT will bypass the cpu usage of any plugin that follows as it will now not have any audio in the buffer. No nonsense no hype.

[AC222]

WOW...this looks amazing. Huge cpu savings as well as the able to create custom channel strips.

Questions:

1) Is it possible to switch between channels in your DAW within the plugin? For example, if you created custom channel strips for each track can you switch to a new track within the rack or do you have to manually go to the track in the DAW and then reopen the plugin for the new track you are going to?

2) Can you use this as a virtual mixer with mute/solo, fader functions?

If you could just switch between tracks within the rack and mute/solo like a real mixer, I would say I am 100% sold.

[bungle]

That's interesting, but it would be good to see how it fares under "actual project conditions" (i.e., with audio running on some tracks some of the time).

In any case, looks promising!

Yes it is a nonsense hype test, if a plugin uses a certain minimum amount of cycles, then no magic wrapper will make it use less.

I encourage you to download the demo and run your own test. It works regardless of the plugin as we bypass the entire plugin if there is no signal in the buffer of AGENT. We actually do this at every slot. so it even works if you put a gate in the first slot. whenver the gate is engaged AGENT will bypass the cpu usage of any plugin that follows as it will now not have any audio in the buffer. No nonsense no hype.

Of course it is nonsense, in essence you are saying the plugin is off when unused, just like saying "we cured hunger, remove stomaches"
Some hosts do this already or offer options, and there are some reasons why you may not want this...
Also, consider not spamming KVR, multiple posts in multiple areas saying the same thing is bad form.

[LGK_Dude]

CRUD - I just purchased bluecat patchwork. Not the exact same thing I know, but if this actually reduces CPU load in my project (which always spike) then I would have rather had my money go here. Looking forward to seeing someone with real world examples, particularly for a DAW like Cubase which offers both AISO guard and the ability to save CPU when VST3 plugins are not in use. I plan on downloading and sharing in a week or two when there is less on my plate.

[murnau]

Of course it is nonsense, in essence you are saying the plugin is off when unused, just like saying "we cured hunger, remove stomaches"
Some hosts do this already or offer options, and there are some reasons why you may not want this...
Also, consider not spamming KVR, multiple posts in multiple areas saying the same thing is bad form.

It can't be the poorest idea to set plugins off which are unused partially instead that they take CPU all the time. VST3 spec cover this as well so saying that is nonsense is a bit unrealistic.

Also if you have reasons not to want this don't do it but it is always great to have a choice or?

Your comparison is somehow flawed anyway and not working here: I have no idea what you trying to say with that bizzare remove stomach advice? When i think about it's rather exactly the contrary because you don't need to remove (or freeze) a plugin when your CPU reach the limit. You can achieve the few percent you finally need.

[ObsoleteAcc99]

hi firstly, please don't post multiple identical topics in various sub forums. Pick one otherwise it just looks like hogging and trying to be at top of each forum.

I watched the video, and what I gather is that NyRV basically only uses the plugin CPU *when* there is audio passing through. Most plugins do NOT have this feature on their own, but some (blue cat come to mind) do have intelligent programming to do this automatically. Vst3 plugins that use the sdk flag that is present for this exact purpose also switch off the cpu when not needed (note, not al vst3 plugins follow this protocol for some strange reason).
Also, some daw's do this themselves. For example Nyrv would offer no cpu advantage in Logic cause Logic automatically shuts off cpu of ANY plugin when it is not processing audio - no matter whether it's a vst in a wrapper, an AU, whatever.. Logic also releases all cpu on transport stop but still keep the engine live for instrument playing - it's a rather unique feature that keeps cpu temps and fans low It will only use cpu for the instrument one is actively playing if transport is stopped (or someone say monitoring a guitar through an amp channel). I would think if anything nyrv would have to ADD a bit of cpu, however insignificant, to use these plugins in a daw like logic as it's adding another layer.

That said, Cubase and Ableton have been plagued by this issue since forever. Only plugins that are specifically programmed to release cpu when not processing audio, will free cpu in most daw's when playback is stopped or the transport passes a section of track the effect isn't processing.

So in this case, YES, that's a great feature, and there is certainly nothing wrong with pimping that at all... it's actually very clever and will help conserve cpu and only use it when truly necessary, if plugins are hosted through nyrv.

Now if I am misunderstanding the way the conservation works, please let me know.

[pottering]

Since the basic plugin functionality overlaps a lot with Effects Rack in Live, adding a little functionality that is more useful for Live users was actually pretty smart IMO.

Even so, multiple copies of Nyrv Agent in multiple tracks doesn't look that hot.
But multiple copies in chains inside Racks (like pads in Drum Racks) hosting those pesky CPU eating effects on the other hand...

Hope this feature makes it to the CM version.

[D-Fusion]

Does this work the same way as the new function in Sonar Platinum and smart function in FL Studio?

[aciddose]

Unfortunately even when you report the plug-in audio "tail size" many hosts don't implement this for you. Doing silence detection is reasonably easy as it is a bitwise compare. The problem is that there is no way to tell for certain what the tail size may be if the plug-in doesn't accurately report it. There is also no way to know whether calling suspend/resume will flush buffers correctly.

In a plug-in like a reverb or delay (or any filter) the tail-size may be extremely variable. It may be between zero to several seconds long! Unfortunately there is no way to reliably report to the host that the time has changed. The host can poll the time between each process call to work around this. None-the-less, in order to cope with hosts without a proper implementation some plug-ins may report the longest tail size even though typical tail sizes will be much shorter than the maximum.

In some cases you may want to stop processing audio, but continue running the LFOs or whatever else. For example in an envelope follower or compressor/limiter plug-in the release may require a significant amount of time to reset correctly.

If the plug-in reports this time correctly as tail, there is no real advantage. If VST implemented some method to inform the plug-in whether silence detection is active and plug-in authors expected to correctly handle "idle processing", such situations could be made far more efficient. Internally my plug-ins use an idle(samples) function to provide this information, although VST doesn't have such an interface to my knowledge.

For example if the envelope follower decays at an exponential slope (or otherwise) this can likely be handled with a single computation. Rather than processing all those additional samples of silence to meet the required tail size, the plug-in could be informed "silence for the next x samples". The current envelope position could then be computed in a single equation once the period of silence ends on the next full process call.

In any case it will be good if people become more aware of this sort of thing. Odds are you can massively reduce the cost of processing a project where you have ridiculous numbers of plug-ins used.

[nyrvsystems]

Great discussion Guys, I want to respond to all the points in here but that will take a bit of time to compile. I did want to mention that the "Smart CPU Saver" Feature can be optionally disengaged in the preferences panel. This would be done if for instance you have plugins where you want to sum the "analog" noise being generated even on an otherwise silent track.

[erikgyle]

So here's the trick:

I don't know about the Waves API, series, but other Waves' emulation plugins produce very slight noise, perhaps too slight to appear on peak meters. But, even that slight amount can be enough to switch the plugins down the chain from resting to processing (because most plugins are smart enough not to act on silent input).

And then, the question must be asked: what happens when the intended behavior of a plugin is, in fact, to produce noise? If Agent mutes all the plugins when the input is silent, it actually overrides the intended and desired behavior of the hosted plugins.