It looks like the trigger() feature was broken along with some factorings / new features.
There are two reasons:
1.) Today we have to independent and highly ControlProxy objects for MidiOutput and Scripting.
A trigger() on the script on only triggers the connected script function. It knows nothing about a probably existing Output Midi mapping
2.) The value holding ControlDoublePrivate has a IgnoreNops feature, which is enabled by default. This prevents the setValue(getValue())
I think we cannot choose a solution that re-enables setValue(getValue()) bypassing IgnoreNops, because the Mixxx code relies in some places to the fact that the same value is never received twice.
To repair the trigger() feature for hardware ouputs only, we need a signal path, that connects the MidiOutput and scripting objects.
It looks like the trigger() feature was broken along with some factorings / new features.
There are two reasons: ivate has a IgnoreNops feature, which is enabled by default. This prevents the setValue( getValue( ))
1.) Today we have to independent and highly ControlProxy objects for MidiOutput and Scripting.
A trigger() on the script on only triggers the connected script function. It knows nothing about a probably existing Output Midi mapping
2.) The value holding ControlDoublePr
I think we cannot choose a solution that re-enables setValue( getValue( )) bypassing IgnoreNops, because the Mixxx code relies in some places to the fact that the same value is never received twice.
To repair the trigger() feature for hardware ouputs only, we need a signal path, that connects the MidiOutput and scripting objects.
What do you think?