1 Is there a specific ladspa forum somewhere that this would better be posted to or should I just email Richard Furse?
2 Where is the ladspa ‘latency’ port documented? In particular, what units is it in? Units of one sample presumably. This feature is not mentioned in the sdk I downloaded. (The sdk v1.15 just has the word ‘latency’ briefly in two comments and the Jan 2019 cmt_1.17 download does not include the word latency anywhere.)
3 How do I get my own ladspa developer’s number - having one is presumably a good idea if I want to share my work?
Regarding (1,3) LADSPA v1 is dead. Long Live LADSPA v2. If you just need basics, http://lv2plug.in/book/ may be a good start. Exposing LV1 plugins as LV2 is trivial. The DSP code can remain as-is and you basically just have to add proper meta-data.
Thanks very much for the replies. I’ve now implemented two LV2 plugins successfully but without the GUI part so far.
I have made the latency correction work for a simple 40 sample delay and the plugin analyser that is built in to Ardour then reports flat phase response instead of a fixed group delay plotted as a sawtooth. That is all correct.
But I have a slight problem with the plugin analyser. One of my plugins contains a hilbert transform with 40 sample latency. To narrow down the problem I made a temporary plug in which is just the hilbert transform on its own.
This has a zero at DC and corresponding low-frequency roll off. It seems to be having its frequency response plotted incorrectly by the plugin analyser white line plot, which shows gain at low frequencies and no roll off. But the roll off plotted on the ‘live signal’ spectogram is correct and the sound is correct.
Cutting this example down to just a 40 sample delay followed by two taps of opposite polarity and equal magnitude, a function that is a just a high pass filter after latency correction, still has the wrong plot.
I assume that the plugin analyser cannot cope with units that have significant latency, even if this is reported?
Which version of Ardour are you testing with? I recall there have been issues with latent plugins at some point.
Would you mind opening an issue at tracker.ardour.org? Is the plugin already available for testing, or can you describe another way to reproduce this issue?
OK I will see if I can make a minimal version of a troublesome plugin, quote a download url and raise a tracker.ardour issue and report version numbers.
I was testing under Mixbus 5.2.191 Intel 64 bit linux and Ardour 5.something.
The issue is that the plugin analyser gives a horizontal white line for the gain on 0dB when in fact the plug in is a low cut filter. This can be plainly heard and seen on the green live plot when wideband music is playing.
The issue with the hilbert transform was more complex, showing gain when there was none.
Now I will need to find out how to raise an issue tracker issue.
Ardour’s analyzer works by plotting the impulse-response using a 1 sample impulse. That obviously fails for non-linear plugins. In your case a 1 sample impulse just passes unmodified, only delayed.
I’m torn, it would not be too hard to use noise to measure the response of in/out (like for a live signal) or perhaps even offer different methods. Then again just documenting this limitation is also reasonable for a DAW.
High pass filters and Hilbert transforms should both be linear functions, it is not like a distortion or even a dynamic range compression plugin. An impulse response measurement of a high pass filter should be able to show the frequency and phase response.
Since the plugins reports its [worst case] latency it’s not LTI. If the plugin is changed to report its latency as zero, the analyzed IR matches exactly.
What if the plugin (the 40 sample delay and two tap FIR filter) just reports a constant 40 rather than 0, is that also plotted correctly? A fixed delay and a high pass filter should still be LTI, no?
I will try with the latency report modified to be one lower, then both taps might appear in the part of the impulse response that is considered.
But this will not help with something like a Hilbert transform where there is substantial ‘pre-ringing’ as you put it.
I would have thought the correct way to deal with the latency report is not to ignore part of the impulse response but to instead alter the phase response of the plot with the subtracting of a linear function in the way that classic network analysers always have done (eg Hewlett Packard 3577A) ? It should not make any difference to the magnitude plot.
Moreover, the reported latency should better be the average instead of the peak I would have thought?
I say the average would be better because this is presumably what makes the most sense in a DAW where we generally want all channels to have the same latency regardless of number of processing steps and for cue mixes to the artists if monitoring through the DAW. Is that right?
They will be the same anyway for most nearly all common examples except for delays and flangers etc. …
That should plot the correct frequency response, but the signal phase plot will show a 180deg shift
Ardour is a DAW is not a HP analog spectrum analyzer, but yes it should probably perform measurement in the same way.
Keep in mind that this FFT pane is only visible in generic edit mode. It is not shown for custom plugin UIs. As far as I know it was intended mainly for showing EQ curves in the early days. It is not a substitute for a proper measurement tool.
I suggest to not change your plugin only to make Ardour’s odd measurement tool happy.
In general it should be the max time from input to output. If a shorter value is reported some onset or lead-in may be cut off.
Common latent plugins include look-ahead limiters as well as convolution kernels that do need to buffer data. However in those cases there is no ambiguity: min = max = avg latency.
In your case, the peak (here 40 samples) would be needed to correctly plot the phase response with a proper analyzer.
@x42 Can you elaborate a bit? I have a few old LADSPA v1 plugins (from the TAP, or CAPS plugins packs, etc.) that I would like to migrate as LV2 plugins so that Ardour (6.9+) can still use them. -Any thoughts/ideas/links?..
Just to clear up any potential misunderstandings; Ardour can still use old LADSPA plugins, it’s just that new ones should be made as LV2.
I just compiled and installed CAPS from your link and it works in Ubuntu 22.04 and Ardour 8
The only slight bug I noticed was that I didn’t get graphical meter indication for the C* Compress X2 plugin.
I see the numerical values change as the compression sets in but the meter doesn’t move
Man, thanks so much! That is awesome. (A lot of people seem to be so much better at finding things online than me…)
Well, that’s great if true(!), which I believe you. -But then why might my old Mac (OS X 10.6.8) now running Ardour v6.9.0 not recognize the TAP, CAPS, and all other LADSPA v1 plugins that were working just fine on the ancient Ardour v2.8.16 I had running before on this machine? -Ardour 6.9 simply cannot find them during plugin scanning (-only the LV2s, AUs, and VSTs):
What am I missing here? I feel the explanation is probably simple…
(-Different folder used to store older LADSPA plugins?)
(A lot of people seem to be so much better at finding things online than me…)