Some questions to consider regarding scripting

Some suggestions have been made for which more discussion and feedback might be helpful so would appreciate thoughts

  1. Would it be useful if the Rig Manager was able to remember the last value received for each physical control that has been learned (i.e, for which there is an alias defined)? If we had this, then the scripting language could ask for the current value of a physical knob when you switch to another rackspace

  2. Those of you who have dabbled with scripting are no doubt aware that if you define a MIDI event callback, then it is up to you to send out the MIDI event received if you want to anything to happen. Otherwise the MIDI event will be completely ignored. I’m thinking that we should do the same thing for widgets. In other words, even if a widget is attached to some plugin parameter, if you define a callback for a widget, then you’ll get the callback and it’s up to you to send the widget value to the plugin parameter.

Thoughts please?

About (1) SURELY I’m a great supporter for such a implementation… have the possibility to remember (al rig manager level) last value trasmitted by a controller could better model the link between actual phisical controller (modwheel, pedals, knobs…) and parameters for VST

About callback implementation I’m aware that, in order to prevent some nasty loop, it’s a good pattern to follow the one you suggestet for the widget the same way we do for events at midi level… but I think taht MAYBE we will need some more scripting function to deal with parameters link (or maybe only some example to better understand how to send widget value to plugin…)

There’s no loop issue any more. That has been solved. The problem is that if we don’t to the same things for widgets as we do for MIDI, then if a widget is connected to a parameter, you have no way to prevent the parameter from being changed from scripting.


About callback implementation I’m aware that, in order to prevent some nasty loop

  1. I guess it would be useful for some people. I personally rather won’t need it.
  2. Makes totally sense to have the same for widgets. Maybe you want some widgets to work only depending of some conditions (switches, plugins being bypassed). But that would mean that the widget values and the plugin parameters wouldn’t be in sync right? What about the other direction (parameter change -> widget value)?
  3. I loved to have the same MIDI callbacks for some kind of MIDI scripting block that does nothing than having a MIDI input and output. Whatever goes into this MIDI block could be captured by a callback and then (if I want to) be sended to the output. So we could implement our own MIDI filter/processor. This would also allow us to directly inject MIDI messages to instruments … I think there’ve been some FRs for that already.

David, the idea of reacting on callback functions with widget is straight forward.
I think it is a good idea to send values in scripting to the assigned plugin parameter.
Would it be possible to have a function wich sens the value to the assigned parameter, but you do not have to know the parameter?
So when you change the assigned parameter, it is not necessary to change the script.

@Lukas You can do this now — for each synth that you want to control, create a MidiIn block for which there’s no physical device connected (the MidiIn OSC is a good choice) and connect it to the synth. Give each of those MidiIn blocks a GPScript name.

So suppose you have a main MidiIn Block called MAIN and you have three synth plugins connected to MidiInBlocks called Foo1, Foo2 and Foo3, you could write a script as followed (not tested, I’m not at a computer where I have Gig Performer installed)

var
MAIN : MidiInBlock // Attached to my main keyboard
Foo1 : MidiInBlock // Connected to some synth plugin
Foo2 : MidiInBlock // Connected to another synth plugin
Foo3 : MidiInBlock // Connected to a third synth plugin

On NoteEvent(m : NoteMessage) from MAIN // Note came in from keyboard
SendNow(Foo1, m) // Send the note message to Foo1
SendNow(Foo2, Transpose(m, 4)) // Send the note out to Foo2 transposed up 4 semitones

// Only send the note to the third synth if the Midi note number is greater than 60 (middle C)
if GetNoteNumber(m) > C3 // Yes, you can use MIDI Note names instead of integers :slight_smile:
then SendNow(Foo3, m)
end
End


we could implement our own MIDI filter/processor

You can of course already send a value to an arbitrary plugin. E.g, if you have a plugin called FM8 (script name) and a widget called Foo you can write

On WidgetValueChange(newValue : double) from Foo
SetParameter(FM8, 116, newValue) // Set parameter 116 of FM8 to newValue
End

The idea of being able to query the widget for the “current parameter number” is a great idea - please submit to bug tracking system so we don’t forget about it - I’m not at a computer where I have easy access to that stuff


I think it is a good idea to send values in scripting to the assigned plugin parameter.
Would it be possible to have a function wich sens the value to the assigned parameter, but you do not have to know the parameter?

@Lukas You can do this now — for each synth that you want to control, create a MidiIn block for which there’s no physical device connected (the MidiIn OSC is a good choice) and connect it to the synth.
Yes, but if I use MidiIn blocks I can only do it with MIDI data that directly comes from the keyboard. But I can't use data that comes out of a chain of MIDI plugins (pizMIDI midiSplitter, chordTrigger etc).
  1. yes, sounds really useful

  2. yes, I think this should be consistent with how MIDI messages work

Thanks for the feedback. We will at some point add the ability to remember the last received value for all incoming CC messages (and probably pitchbend messages)

Not sure however that we’re going to change the behavior of widgets right now though. If you want a widget that’s not tied to a particular plugin, then you can just drop in a widget and use it any way you want from scripting.

To the end, we’ve changed the callback (again) to
WidgetValueChanged
i.e, past tense, to make it clear that by the time you receive the callback, the widget WILL have the new value.