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 )?
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.
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.
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
oprint(renoise.song().selected_device.active_preset_data) is your friend
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.
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.
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.
