This is usually the case in other hosts. They rather differ about if they introduce an entire buffer (or more) per plugin or if they stuff the added latencies of all plugins in a chain inside a needed number of buffers.
1 Like
I should have said 2 buffers with 256 samples, which is unfortunate but not too bad for the player, at 10.7 msec. I fixed the README, so thanks for pointing it out. The only fix would be for me to look at more efficient convolution code than JUCE, and at least one has been suggested and I plan to look into it.
It’s not a latency issue. Convolutions absolutely have to introduce latency if they have kernels that “precede zero.” That is, the kernel for a lowpass filter that preserves phase reaches as far into the past as into the future. One way of looking at it is the filter affects the signal before it receives the signal. Of course, this isn’t theoretically possible without a delay.
But when using convolutions with impulse response (IR) kernels, everything happens after the signal reaches the filter. So, it doesn’t cause latency in that case, and that’s the case for reverbs, and PianoRes is just a reverb that watches the sustain pedal.
In any case, latency per se doesn’t cause overruns. What causes overruns is too much CPU processing to complete for one buffer before the next buffer arrives. Since it’s not constant overruns, the cause is due to some other processing getting in the way (which is unavoidable – the main culprit is usually handling an interrupt.) So, increasing buffering just allows the system to “catch up” when one buffer takes a bit too long.
BTW, several of the Zynth samplesets have really bad (and worse, variable) latency baked into the samples. I hope to fix that!
2 Likes
There are a few convolution plugins in the zynthian collection, and they are quite CPU friendly. Perhaps you could fork some of them (x42 plugins are probably my favorites and they use zita-convolver implementation)
Regards
1 Like
Thanks! I can also try reducing the IR length a bit. From fiddling and comparing the 4s to 10s IRs, it’s clear that the first couple of seconds make a huge difference, and the rest is too subtle for me to hear, even when playing a chord and letting it fade to nothing.
This one was suggested in the JUCE forum, and it’s built using JUCE which might make things easier (same buffer operations, etc.) GitHub - HiFi-LoFi/KlangFalter: Convolution audio plugin (e.g. for usage as convolution reverb) · GitHub
1 Like
It’s in the zynthian collection too 
3 Likes
I don’t see it under Reverb, and I can’t find it in webconf Software → Engines → Audio plugins – where can I find it? (KlangFalter)
Also, I’d appreciate any tips on how best to measure plugin CPU usage. Of course, I know top but it reads about the same for my plugin as x42 convolution reverb. (Plus I’m not sure which process it’s running in. Is it jalv?)
For my own code I could always measure and print stats to file periodically, of course.
You are right, @jlearman !
it was removed for Oram. In the setup script is commented like this:
# Removed => Not working
#klangfalter-lv2
I can’t remember, but i suppose it didn’t work after the migration to bookworm64 
We was using the version from the kxstudio repo.
If you find it interesting, we could try to build from source.. Tell me if you do so.
Regards,
1 Like
Thanks! Actually, I think just knowing that it once worked might be good enough. I can build it and load it and if I need to fix something to make it work (like update JUCE) then I can use that as a model for my own plugin. Plus, if I can fix it, I’ll issue a PR and maybe we can get it back in.
BTW the Zita convolver looks great and runs well in my Pi5, but the x42 stuff is only LV2 and I want my plugin to work for multiple platforms. If I have trouble getting Klangfalter to work, I can use it as a fallback.
Also, I learned something about stereo convolutions from reading Zita. I hadn’t considered the 4-channel aspect of stereo → stereo convolutions, but clearly left channel input would indeed feed into right channel output. Learn something every day!
2 Likes
I loaded the pre-built KlangFalter from kxstudio. I can load it, but it doesn’t have a param to load the file. Any idea how I could add that, or how it was handled previously? I’m hoping I can just add to the ttl file, but the code would need to be consistent.
I compared the ttl file at zynthian-plugins/lv2/KlangFalter.lv2/KlangFalter.ttl at master · zynthian/zynthian-plugins · GitHub to the one I installed and the former just looks like a slightly earlier version (they added latency reporting and an auto-gain parameter.)
This relates to what I need to do for my plugin too. I need to recode how it gets the file; currently on a UI button click it launches a file chooser, which won’t work on Zynthian due to no UI, no button. I wonder how it worked at all!
Reuk, a JUCE maintainer, says it’s not possible.
It’s not because JUCE doesn’t support LV2 files, it’s because JUCE doesn’t support passing text (or files) via the AudioProcessorParameter interface, which is for conveying parameters, and he says:
parameters with textual values aren’t supported in any other plugin format as far as I know
(Note: I’ve since learned the difference between manifest.ttl and plugin-name.ttl, and it doesn’t matter which TTL file it’s in.)
It should be done …
It’s a serious limitation in the JUCE framework that limits a lot the plugin types we can integrate in zynthian.
Off course, integrating other plugin formats won’t help. It’s clear that native LV2 is the only plugin format that really works for embeded devices
The only workable path is not using JUCE for plugins that needs to load files as parameters: samplers, IR loaders, neural modelers, etc.
Or should we lobby to twist JUCE decision?
Regards
We could try. Please consider replying on my post there, explaining why it’s needed for LV2 but perhaps not other formats? I’m really new to plugins and I don’t really know the lay of the land.
1 Like
Done!
Perhaps other zynthianers would like to add their POVs too.
Regards
2 Likes
Thanks for piping up.
Meanwhile, I’m looking into simply modifying the x42 convolver into my purpose, which in theory shouldn’t be hard, but there’s a lot I don’t know so probably won’t be quick.
I was impressed with its performance; I used a 10s impulse file with two 64-byte buffers and no glitches that I noticed. It’d be nice if overruns were logged to zynthian debug log, but they’re not, so if anyone knows how to see the jalv log (where they might appear) please LMK. AI says to run zynthian startup script from terminal, which I’ll try if there’s not a better way.
I feel like by stating this they don’t want to say “lv2 shouldn’t support textual parameters because other formats don’t” but rather “JUCE’s purpose as a plugin framework is to unify shared properties of different formats under one code base”. So I kind of understand their POV, because the consequential question would be: if you add a textual parameter in JUCE, how it would translate in VST/AU? Other formats limit parameters to normalized float parameters for good reasons. I.e., what would happen, if you would automate/modulate a parameter with a filepath (as modulation source or target)?
I don’t want to lobby against JUCE integrating it, I just don’t know how this would be done technically or how accessible the alternatives would be.
Maybe the question there would be if string/path parameters would be possible to implement also in VST/AU/CLAP, which would then mean how DAWs do implement it as well.
2 Likes
Agreed: they have a valid point of view. But they could offer a means to manage it in the formats that do support it. It’s not a trivial issue.
According to Google AI, VST AU and CLAP do not support text parameters. I’ve caught Google AI in mistakes, but I suspect this isn’t one of them.
Surely not. They would either have to make sure that the textual parameter only gets added when compiling a LV2 plugin, which leads to confusion and will likely not happen, or they’ll have to “automatically” add a textual parameter in an LV2 plugin exclusively where other plugins formats would only use some serialized state internal variables for storing e.g. a file path. Might be possible.
1 Like
I believe that JUCE supports mapping text value to float values, similar to LV2 enumeration of text values. So there is a way to represent text values in VST/CLAP in JUCE. For accessibility it is desirable to allow text in plugins. LV2 presents all controls as floats but also has other data types available.