Why is PDC/latency of a device not ignored when DSP is bypassed?

Resurrecting this old thread, I really want to emphasize again, why I need a “device parking” a.k.a. dsp disabling + no pdc option:

Imagine you added a fancy spectral / fft whatever plugin to one of your tracks. It sounds so good, but also introduces huuuge latency. Now later you come back to composition process again, you want to add some more details… You are now stuck with unplayable latency, no way to enter midi data… Only solution currently is to remove the device. Or use two Renoise instances, copy over the dsp to the backup Renoise…

It really is annoying. Please add a second disabling mode, available thru context menu of the dsp “park device”, or “unmount device” or something.

It is also not really possible to write a tool for that. Since you would need a replacement device, and that will destroy related automation.

So there really is no excuse not to implement this ( @ all DAW developers out there ).

And honestly, how much work is it: 15 minutes? Duplicate the disable functionality and add a PDC disable. Connect to context menu. Done.

EDIT: Or add an option “disable PDC”, per DSP. Also accessible thru API. Make PDC value readable and deactivatable.

Well, it is logical that any device, even if disabled, should add to pdc. Else every enabling/disabling will lead to severe resynchronisation glitches. A native option to put a plugin into “stasis mode” for keeping it and its setup/routings would be cool, but well, we don’t have it.

I have an idea concerning the device parking tool. The formula device! You could store all relevant data inside the device, in the user section as string for example. Plus an identifier code for the tool so it finds the device and knows what to do with it. Then name the device in a certain way so you know: ok, here was a plugin. Also the whole preset data. Plus you can store any automation routings in there, and let the tool reconnect them once it transform the formula device to the real plugin. Storing any data as string can be done with base64 encoding, for example. I guess active preset data already does this, as it returns a string.

Does the formula device add latency? being a meta device I guess it won’t. You can read/write to the user code by using active_preset_data.

OopslFly sounds like a nice idea, also like the name “stasis mode” :slight_smile:

But you would also have to save along all automation data, and later restore it. Sounds like lot of work, for just a little of feature. It is much more simple to add this from core side… At least a PDC on/off switch from API side and context menu.