thank you @dhj that’s valuable insight!
When people suggest other approaches and you point out why you don’t like them, that in itself helps to see what we could do better.
I understand, but if responses do not reply to the actual question but over and over state to use some alternative (yes, this happened every single time) it feels like there is no interest in discussing anything and there’s no fun in sharing thoughts if it’s being ignored.
So why do you need 100s of widgets
Let’s skip the “why” for the moment, lots of thought has gone into the setup over past months and I’ll soon showcase the project in another thread. Limited to the “what” here is the calculation:
scripts are currently managing 12 plugins x 4 params (bypass, preset, dry gain, wet gain) = 64
(plus some special case extras, I’ll skip these here)
For conventional mapping via widgets, each param needs one “receiving” and one “sending” widget, so that’s 128 then.
Scripts will abstract all these parameters into a simpler-to-use UI which can be controlled either by hand or, on stage, by preprogrammed MIDI automation. So, many if not all of these parameters will be actively used.
reason there is a Widget “type” is because the compiler can map the variable declaration directly to the underlying widget address
I both love and hate that logic, haha… smart solution, but also tacks view/UI and model so close together that it feels kinda dirty.
So widgets are a performant way to control state and they can act as an intermediate communication layer between scriptlets and plugins. (Technically it feels weird to have script and plugins communicate through an UI layer. Controller wants to change Model but has to ask View to do so. 
)
Then again a script referencing plugins directly is the most performant option, as it skips the “Widget” layer entirely, right?
So, about the performance concerns, how does OSC work performantly then?
After all it communicates by string-based addresses, so GP has to map/look up plugin addresses too.
The concept of “SetParameterByHandle” etc seems to be - in my thoughts - much more comparable to OSC. Just without requiring free port and using external UDP.
Thinking about it abstractly, it is a bit like a centralised task execution scheduler that can be accessed by scripts.
As an example, the script-callable SetParameterByHandle would just need to push a new task instruction to the scheduler, pseudo-coded as { taskType, targetName, value } and GP can then handle and execute the requested action on next tick.
Of course at least the lookup of plugin/widget referenced by targetName is a necessity, but still I’d imagine it to be much more performant than OSC - building, sending, recieve, parse, interprete should take considerably more time?
Who knows, just browsed the extension API and it doesn’t look impossible to implement the basic concept as an extension. May give it a try if I feel bored.
