Looking at the example, I was wondering, how far can you go with polling the effect for all it’s parameters each something is changed?
What scheme are you using in real world scenarios where you potentially have lots of parameters?
It’s seems like the effect should maintain a list of dirty flags in order to tell the UI what it should look for.
another related question. how to communicate data beyond just normalized floats between effect and UI without coupling both too tightly.
I was thinking about using something like that in the effect
bool SetProperty(const long id, void *data, const long size);
bool GetProperty(const long id, void **data, long *size);
I was also thinking about calling setParameterNotifyingHost() from the effect (which knows how to convert data to a normalized range) in response to a property change. And ensure that the UI widgets only have to deal with meaningfull parameter ranges.
Any comments, good or bad experience with something similar?
True, at the moment it’s up to the plugin writer to manage their parameters. There’s a thread somewhere where a couple of people have suggested helper classes for this, which would make it more efficient than polling.
Not sure if you understand what the parameters are for - they let the host automate values in your plugin. If they were blocks of raw data or non-numeric values, then how would the host know what to do with it? For any non-automatable data that you want to pass between your effect and UI, you can just use variables like you would in any other multi-threaded app.
Sure, I already have some parameter helper classes which holds information about ranges, mapping to [0;1], serialisation…
I was just looking for an unified mechanism for both parameters and other properties to be set from the UI.
The plugin which knows how to to convert parameters to a normalized range, is then reponsible of notifying the host about parameter changes or just be silent if it’s not a parameter.
BTW I’ve tried to use Juce Messaging mechanism to post single parameter update to the interface. But as handleMessageEvent() is private it’s not possible for a Component to override this.
To solve this, I could have the GUI own a MessageListener which is not a Component, but it would have been simpler to be able to override it in the main Component. Is there any reason why handleMessageEvent is kept private?
[quote=“mdsp”]BTW I’ve tried to use Juce Messaging mechanism to post single parameter update to the interface. But as handleMessageEvent() is private it’s not possible for a Component to override this.
To solve this, I could have the GUI own a MessageListener which is not a Component, but it would have been simpler to be able to override it in the main Component. Is there any reason why handleMessageEvent is kept private?[/quote]
I can’t find handleMessageEvent() in the docs, but I think the intent is for you to subclass MessageListener and override handleMessage(). In a component subclass you might do this by multiple inheritance, but Component already inherits from MessageListener, so it must be using it for something.
I use a ChangeBroadcaster / ChangeListener hookup in my plugin, that works for me.
Yes, it’s private to stop people breaking it! Components use messages and if you overrode it without passing messages back to the superclass everything would stop working.
It’s probably the wrong thing to use for a parameter update anyway - AsyncUpdater or ChangeBroadcaster both coalesce multiple callbacks, so would be more efficient. Or even simpler, use postCommandMessage().
Sorry Chap - this coalescing. I’d like to take advantage of it. What do I need to do to let the broadcaster know that it can ditch some messages?
I have items being dragged and need to send/process commands out on TCP/IP - but only at around 30Hz. If I have a lot of them, each a drag command, what tells the broadcaster that they’re similar enough to ditch or combine some?
