added juce::Label midiSignLabel; to PluginEditor.cpp
in processBlock() I’d like to refresh the UI (midiSignLabel) on every midi note
for (const auto metadata : midiMessages)
{
auto message = metadata.getMessage();
const auto time = metadata.samplePosition;
if (message.isNoteOn())
{
refreshUI() ???
}
}
how can I do this? there’s a reference for the audioprocessor in the editor class but I’d need it in the opposite way (or only the C++ sytax confused me). what kind of listeners shall I use and in which class?
That is a surprisingly complicated problem and Juce doesn’t have particularly good ready to use tools to solve it.
But a basic simple solution would be that you have an atomic member variable in your audio processor class and a timer in your GUI editor class. In your processBlock code you would set that atomic variable based on your MIDI message. The timer callback in the GUI editor would poll the value from the processor and do repaints of the GUI. Obviously that solution works only for very simple use cases. Anything more complicated could require using things like lock free ring buffers. Juce doesn’t provide an easy to use one, unfortunately. It does have the AbstractFIFO class but that is quite painful to use.
It looks like you only grab the midi note value in the editor when you construct it. You need to call setText, with the current value, in the timer callback. I minor optimization would be to only call repaint if the value has changed. ‘midiNote’ should also be an atomic. Depending on your intention, this seems like a weak implementation. But it will get you something, ie. The last midi note played, at 1 second intervals.
Time to debug. Use juce::Logger::outputDebugString in the timeCallback to help narrow diwn the issue. Ie, verify you are getting updated values for the backend. I’m in the hospital recovering from surgery, so I can’t run any code to verify things myself
Yes, bad design. But do you get a crash or an assert? Ie. Juce will assert for most UI related calls if not done on the MessageManager thread. Regardless, don’t do this.
Interesting. I use ValueTrees a ton, but I haven’t used ‘referTo’, so I can’t give an educated theory. I am interested in what the actual line of code is that is crashing. A read access crash sounds more like using memory that has been freed, or gone out of scope.
The speed at which the label is updated I have never seen before, even so this time I needed to wait more than a minute to replicate the error. I wonder if a usual timer of 50 or 100 ms is just as dangerous but with the difference that a collision occurs is minimal.
It seems that it is possible if there is synchronization.
Important note! The Value class is not thread-safe! If you’re accessing one from multiple threads, then you’ll need to use your own synchronization around any code that accesses it.
