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

EDIT: Question was not accurately asked… See last post please.

If you use a VST DSP device that introduces a (for testing purposes huge) delay into the PDC, if you disable this plugin, the PDC won’t be resetted to 0, but remembered! So if the device with the huge PDC delay is disabled, Renoise still behaves like the device was enabled and requires a huge PDC. The PDC should be set to 0 on disabling and reinitialized on enabling the dsp.

Tested on OSX 10.9.4.

BTW: What about adding a “bug reports redux” section to the forum?

EDIT: Please close the VST GUI before disabling and try several times enabling/disabling, since the problem doesn’t appear every time and somehow seems to be dependent if the plugin gui is opened or not. And enable “can run in multiprocessor environments” in the plugins comp ability options.

Disabled DSP devices still introduce latency because you may automate that device on and off during different parts of your song.

It would be a pain in the ass to recalculate PDC for the entire song, and then shift the timings of all other tracks, simply because you temporarily disabled (or re-enabled) a plugin on one track.

Oh that’s sounds completely logical… But sometimes (or very often here) is quite nice to have some “optional” version of a plugin inside the bus or something, then this will always introduce latency…

Hm, maybe introduce 2 disabling states, like clicking one time == disabled but automatable and two times == disabled and disappeared from dsp chain ( and greyed out )?

Maybe starting a poll here…

You could write a tool that would save the active_preset_data of a plugin/effect that uses a lot of delay and remove the device, afterwards when you need the plugin again - add the device and change itsactive_preset_data to what you had before.

Or you could ‘freeze’ the pattern/track, disable pdc, move the track your editing to index 1 and set it’s routing to your audio out, not the master.

gova good idea, where to save the preset data then? I mean if in memory it would be lost on reloading, or not? edit: lol ok in the song comments haha

Better keep it in the instrument comments so that you wouldn’t have to think about working with the actual song comments.

Hey dblue (and taktik),

an idea:

if the plugin is automated in anywhere in the patterns, then keep pdc. If there is no automation, set pdc to 0.

Wouldn’t that be very logical and quick to implement? A check on disabling over the whole song if there is some on/off automation.

Damn already checked off by dblue…

Damn already checked off by dblue…


if the plugin is automated in anywhere in the patterns, then keep pdc. If there is no automation, set pdc to 0. Wouldn’t that be very logical and quick to implement?

It’s certainly an idea, although we do generally try to avoid such “spooky” behaviour, where something different happens behind the scenes based on some magic property being vaguely set somewhere. Such things usually end up being far more confusing than useful.

Hm, why spooky? Isn’t that the most expected behaviour…? If I automate on/off a device it’s quite logical that the PDC is always alive (from feeling not brain), but if you put the device in the slot only for backup purposes, you would expect that it doesn’t affect the processing at all… IMO.


Sometimes I got the feeling you don’t want to listen (to everyflatulence in forum), but sometimes there are also very good ideas that also do to seem to EDIT: NOT produce too much effort - minor changes with lot of result (less effort since I understand you are quite a small team and obviously are very talented but no super mans/womans). Of course I cannot imagine how it is if I would have 9800 customers and a beloved software like you and everybody is screaming something. But your advantage towards your competition is that your team actually is listening to your customers and you have a working community. I only want to say, imhho if I were you, I would read the posts in the forum with more openness.

Some examples:

  • Movable post fader

  • m/s mode for eq

  • m/s mode for exciter (reducing the sliders)

…Yeah ok I am drunk this evening.

EDIT: Can I buy a statue of you guys for my shrine? Just for daily prayers…

Edit: sarcasm suxx and is stupid. Good n8 everyone.


Although this was my first idea as well (so simple right),

I think guessing pdc (from automation) is not a good thing…

… what about editing during playback and live performance.

Could this lead to some unknown sound bugs?

P.S. Making Tool for Your workflow is certainly doable. - i think

(via automated saving and loading dsp chains and some logic)

Ok, then i guess i can Encode the whole preset data into ASCII and afterwards successfully reconvert into preset data type? How many bytes are allowed in there instruments comments?

although I`m just starting to explore lua and renoise api (and assume that anything that can be done from ui it can be scripted) my initial tool idea was this:

some kind of operator: for example in dsp view right click… …lets call it ‘optimize dsp’ that will do:

  • save in temp directory (or comment?) current dsp chain ( *.xrnt )

  • remove all disabled effects and indicate that this dsp chain is frozen (somehow)

  • add listener to dsp device selection (or something) and restore from temp chain in that case (*.xrnt)

  • add pre-save song action to restore all optimized dsp tracks (or not if its stored in comment)

this is somewhat stupid approach but gets rid of problem of getting track of changes in dsp

im not interested in this kind of functionality so i will stop my idea here :slight_smile:

oprint(renoise.song().selected_device.active_preset_data) is your friend :wink:

I’m sure you’ll have enough space in the comments, I don’t think it’s a tangible limit practically. The plugins and some effects, like the convolver (though in 3.1 it’s 0-delay anyway) save their ‘state’ in chunks so it is already encoded, you just need to save the active_preset_data, then load it.

Also, don’t forget a dummy 0-delay device tomaintain a simple hierarchy, with enough parameters to reassign the automation if needed.

There are plenty of other ways to save this data, but that’s one option.

Ah no, that sounds again like a nasty workaround, especially if using some “placeholder” dsp (since the original device needs to be removed).

I wish there was a third power state for dsp devices, only available thru clicking or right clicking like “park device” or something.

Come on now, why does that make it worse? It’s minimized and if it stays minimised it’s transparent to the user, just rename the device to P:

where P stand for parked. done and done.

There’s only one way you’ll get what you personally want, by personally making the change. :stuck_out_tongue:

Hell, as the dummy device use the formula device, then you don’t even have to keep any instruments for comments just ‘inject’ the active preset data, then extract it, a comment instrument is just how I keep things organised. Can even keep the non-meta automation data in it with relative ease.

You already did half the work (concept is ready)… :stuck_out_tongue: No ok, I will try this if I’mclearheaded for this.

BTW. can I add custom nodes to the active song xml?

No you can’t make custom nodes. But the formula device variant really seems like the most comfortable to use and simplest to implement.

sng = renoise.song()
sel_track = sng.selected_track
sel_dev = sng.selected_device
sel_dev_index = sng.selected_device_index

I had an instrument freezing tool in the works a long time ago (to get rid of the delays, no other reason)

maybe i’ll write it myself I dunno, free time is non existant