@speed12 yes includes are an interesting concept. However, as pianopauls question hints, includes are a basic mechanism that “throws together” all code. It must be free of conflicting vars, doubled functions or event listeners etc. The option to save code separate from the project itself is kinda powerful in some situations though! In my case, I worked that way for a bit but found that for now my personal preference is to manage the code inside the project data.
@pianopaul Ah yes an interesting question.
To ensure I got you right, callback refers to Event bindings like WidgetValueChanged?
I’d imagine these scripts to be isolated / unaware of co-existing scripts.
So all scripts should be allowed to define whatever listeners/callbacks that they need.
I think its the same behavior as is implemented at extensions API?
I’m having a hard time right now to find a use case where one would want to listen to changes of the same widget in multiple scripts. Several scripts that make us of WidgetValueChanged seems like a common usecase though. Is there a good reason to allow only a single listener to be notified?
This is kinda the key point, scripting is a fantastic feature of GP as it allows anyone to extend GPs functionality and overcome specific scenarios that wouldn’t make sense for the devs to build features for, as they are so specific.
But it’s a balance: Above all GP has to be stable - for the intended audience of people performing live, that is the feature they value the most. And I suspect most users who are not programmers find the scripting component adequate for their needs, so adding additional technical features unlikely to be used by many is probably not a high priority. (Particularly if it introduces ways for non technical users to misunderstand their use and make their rig unstable or slow to reactt)
Fortunately, it’s possible to create extensions - which neatly silos building complex rig functionality into a domain where programming experience is required.
Having said that, it’s always good to hear suggestions on features - without feedback the Devs are never going to know what users consider important.
One feature discussed does seem like it would be useful more generally:
A ‘State’ widget that can hold multiple widget values, without any GUI parts. Having to add multiple hidden GUI components to do this does seem a bit clunky.
BTW I use VS Code + this excellent extension, and make use of Include statements to manage and re-use code. It is a bit basic, as the final code is “thrown together” in one block, but using naming conventions helps.
I have a slightly different opinion on adding features in this case, but all in all its a profound POV.
(in short I argue that a stable, official script API for such situations can be more reliable and way more intuitive, compared to working around the limitations via OSC or Widget Chaining. For regular users, this is way more difficult to understand than a simple SetValue(“MyPlugId”, 3, 0.5). And I claim that this is the reason for many scripting novices come up with unusual workarounds, searching for help around here, cause the current official solution is far from perfect.)
Anyways, I respect the dev teams answer stating official support for such is off limits for them.
Jup, using vscode with the gp script highlighting too if I write larger scripts, tho I do copy+paste them into bundled scripts.
Yes, we have that - it’s called the Gig Performer SDK and it’s officially supported
Obviously we can’t control what people do with GP Script but GP Script is not an “official” solution for what you are trying to do – that’s like complaining that it’s too hard to get from one end of the country to the other on a bicycle. It “can” be done but much better to get a car, train or airplane.
In our case, the “car train or airplane” is called the GP SDK
this really depends on your definition of “event” and “event listener”.
Is the listener expected to respond, actively handle something?
Is the listener allowed to modify state in general and/or the callee?
In my company’s tech stack we decided to classify events into multiple types - “notification” events with multiple listeners allowed that do not actively interact with callee (roughly equivalent to not allowing widget change listeners to modify widget state), and “request” events with exactly one handler, which may execute actions and even return data to the callee.
Tho I can understand this conflicts with the simplicitly of GPscript that you want to keep.
@dhj I disagree on that. I’m fine with doing it myself, but the feeling I got searching forums for answer is that there’re quite a few users beside me who are searching mechanisms that don’t exist, so there’s potential for improvement of built-in features without 3rd party extensions.
Anyways…
everyone has made their points clear
the suggested solution is to write a custom extension
productive discussion has come to an end, we’re repeating ourselves
Time to call it a day. Thanks for the detailed feedback.
