A quick question on beginParameterChangeGesture and endparameterChangeGestures. So apparently one should call these methods, to support touch mode automation. This however works only for sliders, since one could implement “beginParameterChangeGesture” in sliderDragStarted and “endparameterChangeGestures” in sliderDragEnded.
Is there some way to implement the same thing for comboboxes/toggles/buttons/etc.? I have been testing cockos based plugins in Repaer and they actually work with touch, where all other plugins seem to break. i.e. the value jumps back to the original upon change from GUI where touch automation is enabled
Nope already tried it, this does not reflect the same behavior as other cockos plugins in reaper, neither aax plugins in Protools, the toggle(button) jumps quickly back to the original value, making touch automations for toggle useless
PS: the button was defined as a toggle to begin with, so I dont think this is the problem. Have you checked other JUCE plugins? They all exhibit the same behavior
Ahh sorry for the confusion, I thought of touch in the concept of UI interaction.
Well I’m afraid your best bet is to contact COCKOS…
The behavior you’re experiencing should be fixed on their end I guess.
I’ve tested 3 plug-ins which ALL of them I know aren’t using JUCE framework.
The first is Blue Cat
The second is Sound Toys
The last one is Cockos own.
All were VST.
yeah seems to be a reaper issue, but at the same time, I am experiencing the same issue with aax version in protools. Actually the only version that works as expected is VST3 in cubase. I am pretty sure this has to be regulated on JUCE side, reaper aside of course.
For AAX , I wasn’t able to reproduce this also.
Our plug-ins uses JUCE of-course. and I’m seeing the exact behavior that Sound Toys provides in our product…
Here is the snippet from Muteomatic:
if (buttonThatWasClicked == stopButton_){ getProcessor().paramStoppedState_->beginChangeGesture(); if (buttonThatWasClicked->getToggleState()){ getProcessor().paramStoppedState_->setValueNotifyingHost(STATE_ON); } else{ getProcessor().paramStoppedState_->setValueNotifyingHost(STATE_OFF); } getProcessor().paramStoppedState_->endChangeGesture(); return; }
To be honest Muteomatic is build based on JUCE 4.2 / pre multi-I/O even.
And currently our products based on JUCE 4.3 so you can look on latest dev branch to see if there are regressions but I don’t think so.
ok it seems like you are using the new parameter system in JUCE, I wonder if this might be causing the issue for us, since we are still on the old system
void AudioProcessorParameter::beginChangeGesture()
{
// This method can't be used until the parameter has been attached to a processor!
jassert (processor != nullptr && parameterIndex >= 0);
processor->beginParameterChangeGesture (parameterIndex);
}
void AudioProcessorParameter::endChangeGesture()
{
// This method can't be used until the parameter has been attached to a processor!
jassert (processor != nullptr && parameterIndex >= 0);
processor->endParameterChangeGesture (parameterIndex);
}
it seems like they follow the same code, so I dont think that is the issue
I just can’t re-produce this. Your code works absolutely fine for me. Just tested the latest develop branch in ProTools, Logic, Cubase, Reaper, Ableton. No issues at all.
I was using buttonclicked, but just checked your implementation with buttonStateChanged and getting the same behavior, just to be sure we are talking about the same issue, here is a screenshot