Non param data from AudioProcessorEditor to AudioProcessor


#1

Hi,

I am new to Juce and this forum, but the first impression is really good, i will use use Juce to plugin development mainly.

How do you send data non parameter data structures from the ui to the audio thread?

Is it possible to make the AudoProcessor both an ChangeListener and ChangeBroadcaster?

I could not figure out how to do this because editors can be created/destroyed at anytime so I didn’t know where to put addChangeListener and removeChangeListener?

Instead I am using a ReadWriteLock to allow both the audio and ui threads to read shared data simultaneously (enterRead/exitRead). The ui only have to block the audio thread when when something is changed (enterWrite/exitWrite).

Is it possible to do this without blocking the audio thread at all?


#2

Perhaps you may just want to use AudioProcessorEditor::getAudioProcessor() and communicate directly with the audio processor?


#3

Hi, this is exactly what I am doing, I am just using the ReadWriteLock to block the audiothread (processBlock) to access the data while the gui is setting it.

I am looking for a better ways to do this, so I don’t have to block the audiothread at all.


#4

Do you absolutely have to use a ReadWriteLock ? Why do you need to block the audio thread?


#5

I guess that if the audio thread is reading the data at exactly the same time the gui is writing, then the audio thread will get corrupted data.

The example audio plugin in the juce source dosn’t block the audio thread when the gui or host is calling setParameter.
I might be wrong, but the setParameter in the example is just setting/getting floats, while I am using structs.

But you actually gave me another idea now, maby I can get around this problem by having two copys of the data, one in the gui and one in the audio thread. Then I can try to block the gui thread from the audiothread and update the local data if nessecary. I the block fails i just use the old data instead.

This might work, i will test it right away :slight_smile:


#6

yes, for structs you can just use one pointer and 2 structs.
let’s the say the pointer points to the first struct and the audio thread is playing. now you fill up the second struct while the audio thread is playing, and when you’re finished, you just point the pointer to the second struct that you’ve just filled. because the pointer manipulation is atomic (executed in one processor cycle), this will work without blocking the thread.


#7

Thanks for the tip, is this true on all dual/multiple processor architectures?


#8

I think so, someone beat me if it isn’t :slight_smile:


#9

Well… Run !

This is not true.
That s why InterlockExchange and function like that exists.

Take a look at memory barrier for more information

HTH


#10

Well ok. Anyway I really appreciate the help, and using pointer switches with tryEnter in the audio thread and enter/exit in the gui thread seems like a good solution to my problems.


#11

[quote=“otristan”]Well… Run !

This is not true.
That s why InterlockExchange and function like that exists.

Take a look at memory barrier for more information

HTH[/quote]

Thanks, I read it. So it’s always a must to use some OS-based thread synchronisation mechanism (which always incorporates memory barriers) like a Critical Section if one wants to share resources between threads, even something as little as an Int or char?

What I don’t understand is, how does legacy software run bug-free on multiprocessor systems if it has never been written with consideration of memory barriers? I bet, there are many programmers who’d have done things like pointer modification (like in my example) without using some sort of OS-based synchronisation.