Touch automation toggles beginParameterChangeGesture


#1

Hello,

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

Thanks for any pointers,
Armin


#2

Still scratching my head on this, anyone caring to shed some light on it?


#3

something like that should work :

void buttonClicked (Button* b) override
{
    param.beginChangeGesture();
    param.setValueNotifyingHost (b->getToggleState() ? 1.f : 0.f);
    param.endChangeGesture();
}

#4

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


#5

did you set up the button to behave as a toggle?
setClickingTogglesState (true);


#6

just tried, still getting the same thing

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


#7

might be worth providing code snippets.


#8

Its simple really a toggle button (toggle_PolCoords) setup, in my update UI I do the following:

    if (ourProcessor->polCart != toggle_PolCoords->getToggleState())
    {
        toggle_PolCoords->setToggleState(ourProcessor->polCart, dontSendNotification);
    }

in button clicked call back the following:

if (buttonThatWasClicked == toggle_PolCoords)
{
    //[UserButtonCode_toggle_PolCoords] 
    bool isPolar = toggle_PolCoords->getToggleState();
    float valueToSend = isPolar ? 1.0f : 0.0f;
    getProcessor().beginParameterChangeGesture(polCartParam);
    getProcessor().setParameterNotifyingHost (polCartParam, valueToSend);
    getProcessor().endParameterChangeGesture(polCartParam);

    //[/UserButtonCode_toggle_PolCoords]
}

#9

Does it toggle without the parameter changes?
(comment out the 3 lines starting with getProcessor()…)


#10

yes it toggles, not writing any automation of course, seriously guys, try out a couple of juce based plugins, they all exhibit the same behavior


#11

Btw using the three lines mentioned earlier works as expected in cubase with VST3


#12

Ahh sorry for the confusion, I thought of touch in the concept of UI interaction. :frowning:

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.


#13

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.


#14

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…

image

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.


#15

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


#16

looking at the AudioProcessorParameter

  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


#17

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.

void MyFirstPluginProjectAudioProcessorEditor::buttonStateChanged (Button*)
{
    bool newState = onOffButton.getToggleState();
    if (newState != oldState)
    {
        oldState = newState;
        MyFirstPluginProjectAudioProcessor& ap = dynamic_cast<MyFirstPluginProjectAudioProcessor&> (*getAudioProcessor());

        ap.cutoffParameter->beginChangeGesture();
        ap.cutoffParameter->setValueNotifyingHost (newState ? 1.0f : 0.0f);
        ap.cutoffParameter->endChangeGesture();
    }
}

#18

… are you maybe by mistake using the buttonClicked callback instead of the buttonStateChanged callback?


#19

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


#20

notice that the toggle back is happening automatically, I would expect the automation line to stay at 1 until I toggle back through UI