Yes, but I guess these are “dummy” enums mapped to “dummy” integer values distributed over the range of normalized floating point parameters. Like 0.f - 0.5f = int=1 = “off” and are likely only display values reported to the host. Same with scaled float parameters (like 20Hz to 20.000 Hz with 500 Hz in the middle mapped to normalized float).
I must confess I’m more into Iplug than JUCE, but am pretty sure different plugin formats internally only accept normalized values.
If JUCE team want to support embedded devices that use audio plugins, they should add support for the LV2 special features that allow separation between DSP and GUI. Supporting text parameters is a “must” for this. If the other plugin formats don’t support this, it’s because these plugin formats are not designed to be used in embedded devices (headless). Currently, the only audio-plugin format that fully works for embedded devices is LV2.
I don’t think it’s something really difficult to implement, they simply need good reasons to do it 
Regards,
Long ago I was into this that much, but Iplug2 supported something like distributed plugins for web audio modules (like plugins in your browser) and possibly vst3.
If this were true, then VST3 may support text parameters. If not, how can you tell the DSP what samples, neural models or IR to load?
AFAIK, VST3 doesn’t support text parameters, so this supposedly “GUI separation” only works partially. Same than some JUCE plugins work in zynthian while they don’t need to load samples, IRs, neural models, etc. If you want to do so, then you need the native GUI.
Regards,
According to Google AI,
To pass literal text or binary data blocks from the editor (controller) to the DSP (processor), VST3 relies on asynchronous messaging via connection points. [1, 2]
It might be that here separation doesn’t mean that one part can work without the other. I’m pretty sure vst3 parameters do not support text.
Anyway, I really want to make clear that I fully support the idea, I was just thinking about what the assumption that LV2 is the only plugin format supporting parameters of any other type than float/double means for a cross platform cross format framework.
According to JeffMcClintock, his GMPI Plugin SDK supports it. (Why we need another format I do not know.)
Touché! Then, we could say that VST3 has partial support for GUI / DSP separation. And of course, this is better than not supporting it at all.
In the other hand LV2 has full support for GUI / DSP separation because it supports text parameters, among other features like banks/presets, etc.
Cheers!
While I understand why the ability for text parameters supports headless plugin usage, I didn’t fully understand why the DSP/UI separation is necessary for it. But I get the basic point. But I guess it would be at least necessary that whenever you give the ability to load a file in juce (juce::file; juce::filechoser or the lot) that it is handled by the UI in other plugin formats, but can somehow auto-create a textual parameter in LV2 on compile time.
As I said above, VST3 allows separation using async messaging.
However, JUCE doesn’t provide access to this.
I don’t think this applies to the problem to be solved, because it seems to me that these IMessages allow communication between editor and processor, also for state serialization, but do not have anything to do with string parameters. The links you provided seem like being about controlling a vst3 plugin with midi data. While not having much expertise about the matter it seems more like an internal messaging system between processor and editor and the question of when an information is transferred in a realtime audio situation.
See IAttributeList::setString()
AU3 also supports distributed UI/DSP, but CLAP doesn’t.
Sadly, this plugin (the stereo->stereo one) gets overruns on my Pi5 with 2 128-byte buffers.
Maybe fewer than the original PianoRes, but … they happen. They happen even with Dry signal level at -60dB (the default, where the code is a bit quicker) and regardless of the setting for “Buffered/Latent Convolution” (which I don’t pretend to understand or know which should be more efficient.
I think the issue is that sfizz uses a lot of CPU. Plugging this on a leaner source might not have the issue.
Anyway, I’m getting a copy of the X42 convolver to work (respond to sustain pedal) but I’m seeing overruns. Later I’ll compare it with the JUCE plugin, probably using a MIDI sequence to make all things equal.
Sigh.
BTW, I’m seeing that the LV2 connect_port routine is being called continuously, for each of the 4 audio channels (2 in , 2 out.) I noticed it when I put debug prints in the code and ran zynthian from terminal.
[PS]
OOPS: the overruns were from a version that I compiled as root on Zynthian, which sets CXXFLAGS and due to how the makefile is written, overrides the optimizations. No idea whether this happens with the built-in version, but I know how to check and will do so later.
More efficient version, called zPianoRes:
A little fiddlier to set up, until I can figure out how to have a default IR loaded.