There are a few opcodes in Csound that introduce latency (e.g. pconvolve). As far as I know, all major plug-in formats support reporting any internal delay to the DAW so it can compensate for the delay.
Would be great if there was a way to indicate the amount of latency in a .csd so that a Cabbage plug-in can in turn report it to the DAW.
The amount of latency is set by ksmps. This makes sense because output only begins after a k-cycle, which is ksmps samples. This is something that Cabbage does automatically. But if you would like to have control over this I can look into it, but using ksmps seems to be the best option.
That’s true, but that is only one source of potential latency. Even after playback starts, various opcodes and instruments might introduce additional latency, e.g. through internal buffering and processing before they can start playback.
For example, the manual entry for pconvolve notes:
The overall latency of the opcode can be calculated as such [assuming ipartitionsize is a power of 2]
ilatency = (ksmps < ipartitionsize ? ipartitionsize + ksmps : ipartitionsize)/sr
This is obviously dependent on the specific orchestra code, so there is no way for Cabbage to determine the total latency on its own. That’s why it would be great if this additional latency could be specified.
Ok. I’ve added a new identifier called latency(), which takes a number of samples. This will add a user defined amount of latency, or plugin delay compensation, as some hosts call it. I haven’t had a chance to test it yet, but you can find the new build here once it’s cooked.
Note, the default is still ksmps.
Thanks Rory, will check it out.
@rorywalsh First I welcome myself to the community.
How to implement this new identifier the correct way?
I also get wrong latency when using ftconv.
Thank you very much
//rootenote
Thank you, this is really useful!
I’m really only nitpicking here, but when you say “add”, do you mean it adds that on top of the default ksmps (so total latency reported to the host will be ksmps plus the value specified in latency()), or does the value given to latency() replace the default (ksmps) as stated in the documentation? (I assume the latter, just wanted to double-check.)
Furthermore (with apologies, as I’m new to Cabbage and csound): is there way to have this value come from a single definition somewhere (think C++ constant expressions) that can be used both by latency() as well as actual csound code? And maybe math be done on it? In my plugin I’m doing a convolution, and during development I’m trying to optimize the length of the impulse response, and it would be less mistake-prone if I could just set the value at one place in the script and have it effect both latency() and the ftgen table size, than having to not forget writing the same value to both places. Not essential at all, totally a lazyness thing on my part.
However this also then raises the idea of putting the setting of the length of the impulse response into the hands of the user of the plugin later down the road as a speed/quality tradeoff. In which case the latency() value would need to change (as well as csound function tables to get resized) while the plugin GUI is open – not necessarily during performance though. Just food for thought.
Actually i notice that I have this changed in my local docs to:
latency(val)
Sets the plugin delay compensation in samples. Defaults to ksmps. Setting latency to -1 forces Csound to run at ksmps=1, but does not result in a one sample delay. In this mode, Cabbage performs ‘in-place’ processing. Note this -1 latency is only useful for realtime processing and in almost all cases, it is more efficient to use the host’s PDC.
If you use ksmps as the latency then your covered right? You don’t need to use the latency() identifier unless you want to set it to something other than the current ksmps.
This might be possible, I’ll have to look. But I’m not sure it is possible to get the plugin to trigger the host to update this value.
I know at least AAX plugins support this. But for parameters that might often trigger this change I still wouldn’t recommend it – it will cause noticeable clicks if changed during playback since the Delay Compensation Engine of the DAW will have to reset its buffers.
A better choice might be to declare the maximum amount of latency your plugin will ever have and use additional delays internally to get to that number if your current processing settings generate less delay than the maximum.
