Hi everyone, I couldn’t find a forum specific to feature requests, so I’ll leave it here
Over the last days I did some intense gpscripting journeys. First of all, great job for having a scripting engine at all, and a sophisticated one. Not being limited to pre-implemented functionality is a huge plus!
AFAIK, scriptlets are pretty new. I love how they modularize logic and keep the rack scripts free of clutter. I think they are missing one feature however: Outputs.
Let’s start with an example.
I have a knob controlling gain. If gain is at 0, I want to bypass a plugin.
Right now the solution for this is:
map knob to scriptlet
write scriptlet to generate local midi cc
ensure those midi cc IDs are not in use already
create hidden widgets and map those to defined midi ccs
map these widgets to gain and plugin bypass
Midi and hidden widgets seem like a not very beautiful workaround.
The whole thing could become much faster and efficient if scriptlets had support for defining OUTPUT values which can be mapped to plugins directly. Essentially the “Mapping” section of widgets.
Thinking a step further (consider this a “COOL IDEA” not a “request”):
Allowing a “Plugin Binding” + having a scripting API to pass configuration to the assigned plugin directly would add powerful new capabilities. However even a basic “VST Interaction API” might be a pretty complicated thing to implement.
Then I don’t need a scriptlet at all. But this will only work if the widgets have a direct relation.
As soon as logic is involved (which I omitted in my example for simplicity), script logic is needed, and the script can only generate midi which then again widgets need to listen to.
Here are some other examples where this simplified approach is impossible:
One global (variations ignored) volume knob plus a local one, which shall be added as an offset. So pluginVolume = globalVolume + volumeOffset.
A knob with an associated toggle to switch between 0 and the set value.
Radio buttons, which cannot be part of a link group, so if a radio button should do anything besides a directly mappable action, a script is needed.
For all of the examples above, the MIDI send-n-receive workaround is needed.
(Or using GPScript Handles plus polluting the rack script with many small code snippets which I find messy).
Adding a parameter output section to scriptlets (which would technically not violate the idea of scriptlets not knowing their environment, as I imagine parameter mapping is implemented separated of its source, be it widget or scriptlet anyways) allows to streamline and makes it faster to add or modify such logic. IMO, allowing scriptlets to contain/generate their own mapping data next to generating midi is pretty senseful as this is the main communication technique used within GP.
You are clearly not understanding how parameters work in scriptlets. A scriptlet does not have to generate MIDI to be able to produce “output” and you generally only need to produce MIDI output if you want a scriptlet to modify or produce MIDI in response to MIDI input, for example, to transpose notes, or to turn the incoming notes into chords, or to change an aftertouch value into a CC value, etc.
Please read up on parameter variables in scriptlets
if I understand correctly, the solution that you describe is to create TWO extra knobs per parameter, link them by widget group, map one to the source parameter of the scriptlet and one to the target parameter of the plugin?
Am I still missing something significant? This doesn’t sound simpler than the MIDI workaround.
I’d had to create 2 extra knobs and use 1 widget group per scriptlet parameter.
Resulting in double amount of hidden extra controls and a limit of 26 cause of the groups.
Browsing the manual
… explained no other solutions than those already shown above and
… states “these parameters can be learned and controlled by widgets”.
Summing up, adding 2 extra knobs + using up a widget group just to get a scriptlet param mapped to a plugin param is similarly complicated and a feature allowing to map scriptlet params directly to plugin params without any extra widgets in between would be much cleaner.
Sorry you don’t like that approach — please understand that a scriptlet is a plugin just like any other plugin you can instantiate — plugins generally do not know anything about other plugins that may be available and we would like to keep scriptlets plugin neutral as well, otherwise they become unportable.
I’m not sure why you need to control a large number of host parameters for a live show but there are two other approaches that are usable right now.
Inject MIDI Messages into the GP Internal port. Then you can associate a widget with that message, just like you would associate a physical knob with a widget and then you can map that single widget to a plugin parameter just as you would do normally.
For example, this system function sends CC value 25 to CC number 42 to the local port
You could also send OSC messages directly to plugins using the SendOSCMessage statement
In the example below, I have a synth to which I’ve given an OSC handle called Legend. Parameter 34 of that plugin is the filter cutoff frequency. I can therefore send an OSC message directly to that plugin to set the value of that parameter and in the example here, I’m just responding to a Scriptlet Parameter but obviously it could be an incoming MIDI event as well, just scale the value to something between 0.0 and 1.0, etc
(FYI - open the image below into a new tab or window to see it at a large size to make it readable)
Both of these approaches are portable as the GP Local port is always available and in the OSC version, if you don’t have a plugin associated with that OSC handle, the message will just be ignored.
I understand and support the idea of keeping scriptlets independent and portable!
This is the only solution for easy to handle + reusable scripts.
I want to be sure there’s been no misunderstanding reading my words.
The idea is NOT to allow scriptlets to hard-bind to plugins in code.
The idea is to use the existing, already independent i/o parameters of scriptlets.
If the environment that executes scripts supported mapping those params directly, without UI layer in between, it would result in a setup with following features:
fast/easy to set up mapping as no workaround via any UI widgets is needed
clean and less error prone - no intermediate UI widgets, no possibility for misconfigurations
in case of target plugin removal, the mapping is removed, but script functionality stays intact
in case of scriptlet copying, just like copying a widget, unsets bindings
From a technical POV, it just doesn’t feel right to require “internal wiring parameters” to be forced to use UI too. Hope I was able to explain it a bit better with these words. Anyways, I do not know about the internals and technical or conceptual restrictions that would speak against this, so of course there may be other limitations making this a bad idea. In any case, thanks for your time and the OSC idea!
Okay, the OSC approach is pretty awesome!
I’d say my concept is kinda similar to this, just with the targeted plugin/param not controlled by OSC, but by a separated parameter mapping dialogue.
Think I’ll go, update all my scripts and remove a bunch of now-obsolete widgets
sorry you got me wrong. I referred to the data structure used inside SendOSCMessage, e.g. { /SetBPM, 120.0 } - and if it is available for scripting in general, or can only be used inside SendOSCMessage.
Supporting tuples as a general concept is on the list but right now this is special syntax for the SendOSCMessage statement and those things are not standalone tuples conceptually
/oscHandle/SetParam seems to only support the params handled by the plugin itself.
I tried to send negative int params (-2 bypass, -1 show plugin editor), but nothing happens.
The manual doesn’t list a dedicated OSC path for these, so I guess they cannot be controlled by OSC as of now. Do you think these can be added?
For now I’ll go with the traditional way of controlling a widget by OSC which then toggles the plugin bypass.
There is no current way to open a plugin editor from OSC ---- really the point of OSC is to control a plugin or such things as switching rackspaces, adjusting widgets, etc. for performance purposes, not so much for managing GP in an “editing” manner
