DISTRHO
Communicating generic notifications DSP → UI
Hi, I think that DPF lacks a kind of notification mechanism, to let UI know about some current status of the DSP. A typical case I encounter is for reporting volume level of an internal signal.
For this case, I confess to have used the instance-access mechanism. :smiling_imp:
To avoid it, I imagine that events-out can transmit notification messages, in an identical fashion to what state does.
Parameter outputs are a simple way to get messages there. I did not add this on purpose when first started DPF, as to make the API as simple as possible. I understand it makes sense to have something like this, but there are quite some implications behind the scenes... I would rather focus on the file handling first, since that seems more essential.
tbh, some new things I would prefer to do in a new lv2-specific class. something that allows usual DPF methods but then exposes stuff that is only pertinent for LV2. idea being that base DPF keeps being quite simple, and then the advanced stuff is LV2 only. it makes sense for files and dsp->ui messages, since lv2 spec covers this. I would not want to implement my own ringbuffer in DPF just to get dsp->ui messages for a few formats, when LV2 already does it in the host-side for us and LV2 is kinda what we should focus on going forward. what do you think?
what do you think?
Fine enough, in truth the solution of output parameters has totally escaped my mind, so I will use that. I forgot to check the meters example which does such a thing.
I think of contributing to the documentation effort in order to clarify a number of things.
Is it reasonable to offer a way of hiding these ports? (eg. notOnGui attribute?)
hiding the port is also something that only lv2 does :) I am fine with a parameter hint for this. If we end up going for a lv2-specific class we will move it in there perhaps. so feel free to add a new "hint" after the trigger one
I had to deal with this recently for the OneKnob plugins, while at some point I think we will need to add something specific for this, I do not think it is the time right now. I kinda consider the new DPF with updated pugl a "2.0" DPF, with a few things to add later that will make it be like "3.0". For now mostly just focusing on getting what is there on the API working as best as possible.
Anyway my point for writing this is that, while I didn't add a DSP->UI message passing mechanism, I still added a way to pass audio-based data to the UI via shared memory + ring buffer. Code for this sits at https://github.com/DISTRHO/OneKnob-Series/tree/main/plugins/common
Is this an approach that you find suitable? By experience I know that passing fast messages from DSP to UI is not the best, specially on higher audio buffer sizes. We get to keep the non-instance-access UI while still keeping good performance and data through-put. The only main thing we lose is lack of remote UI support, but that is not possible with instance-access anyway.
There is a WIP API for dealing with this, see https://github.com/DISTRHO/DPF/blob/main/distrho/DistrhoPlugin.hpp#L1010 and https://github.com/DISTRHO/DPF/blob/main/distrho/DistrhoPlugin.hpp#L677
I changed the way states are handled so we can have DSP or UI only states. Also makes it possible to expose LV2 paths to the host as a DPF state string.