Audio Plugin Parameters Management in JUCE


#1

Since two weeks I've started to learn Juce, to implement an audio unit. I've done all the UI with complex parts in a couple of hours and got good result. All the dsp parts are already written. For me the motivation to experiment with Juce is the fact that you do not have to worry to much on where to deploy and that all compatibility are "well" handled bla bla bla...

My plugin does not require parameters but I wanted to implement them for test purpose to feel really how deep I can go with Juce. I've read a lot of posts and solutions regarding the communication between the processor and the editor and there are finally nothing "standardised" from Juce itself, on sample and demo... except the timer wich is used to frequently check if something has changed... Well I do not like this way, is like picking up the phone every time to check if there is a call or not.

AudioProcessorParameter has been brought recently and does not face the communication problem. Furthermore, scale, prefix... does not work and the recorded automation in Logic (yes I've used begin/end gesture) does not call setValue when you read back what you have recorded. So I'm a little scared to continue with Juce because the topic about parameted sync/com exists since few years. I have the feeling that there is something wrong with the parameters.

Do you plan to provide an elegant and efficient solution to face this problem?


#2

The AudioProcessorParameter class is just a simple abstraction around the underlying plugin APIs - it won't attempt to help you solve any thread sync issues, it's just a layer for talking to the hosts. Obviously whether hosts take any notice of things like begin/end gestures, prefixes, etc is totally up to them - the JUCE classes provide a way for you to publish these things, but we can't force hosts to all use them correctly.

People all have different needs, so most people have rolled their own ways of handling comms between their GUI and DSP code. Some people use Tiemrs or FIFOs or other tricks, and there's no one-size-fits-all solution. We will be releasing some extra utilities for this in our V4 release, including a ValueTree based implementation that we're using at ROLI and Tracktion for our plugins, and which takes care of all the messy stuff involved in managing the entire plugin state. But that'll be overkill for many people who will probably want to keep on using the base classes.


#3

I understand that all people have different needs, but if we talk strictly on plugin management (sync, state...) we are all facing the same issue.

So I'm glad to read that you plan to provide a solution, but I think you should provide some information (not precice for sure) about the date you will realease V4 ( maybe you already mentioned that). So as user of the lib we can then decide if we have too spend more time on a temporary solution until you release the standard one. We have all already lot of issues to worry about especially on DSP parts,  and a lot of us do those developments in extra after their working days :)


#4

Any chance to receive feedback about the release? 1 month, 3 month, 6 month? Thanks!


#5

Our policy for announcing release dates is not to do so in the reply to somebody's forum post, but it will be less than 3 months!


#6

I'm joyfully getting my head around mountains of new "modern" C++ (lamda's, threading, type deduction). 

But I have lost countless hours of sleep thinking about efficient message passing / notifications between the processor and GUI/Message thread. (C++ 17 seems the only hope for things like std::future to become useable in a plugin scenario, hoping JUCE is going to put us all straight

 

So that response has just made my week Jules!

3 month's of DSP focus and pretty GUI components rather than killing myself over this topic I think, then I can take a look are way you and the ROLI team have tackled this. Hope the summit is still going ahead !  

Cheers


#7

Thanks for the feedback Jules!