So… if you want a set of buttons that behave like regular ordinary MVC or VPA and properly trigger callback with events rather than being bound directly to single actions. JavaScript seems like a poor choice of languages. Anyway, keep reading for a possible way to accomplish this.
It’s true that Logic uses JavaScript. but even they us an Event based architecture, and you can script all of the MIDI, not just Host (DAW) control focused events. And their way of making Host changes is “setParameter”. Simple and Clean! It’s baffling to me how you could read what Logic has, for even 10 minutes and then not think that you needed to at least be at least parity.
Here is an example from Logic:
function HandleMIDI(event) {
event.send(); /* send original event */
if (event instanceof Note) { /* if it is a note */
event.pitch += 12; /* transpose up one octave */
event.sendAfterMilliseconds(100); /* send after delay */
}
}
function Reset() {
SetParameter('slider', 0);}
What you need is a trigger for the callback. It is beyond me why they didn’t just provide callbacks and a host class with methods or even the raw functions that Logic has. It’s a tried and true architecture after all, used by applications for decades.
But it seems that it is might be possible to construct this behavior with a little work around.
To get the same in Cubase without the MIDI scripting, I came up with the following cockamamie scheme.
Just brainstorming here but…
What you need is something to base the callback on, like a “dummy control track” (DCT). I’m thinking of a PLE that will set a value on the DCT, make a change, select the tracks with the return tag. You would need one Before PLE and one After PLE, and one for every callback you wanted to trigger, named appropriately of course. They wont do that callback, they will set some value on the DCT that will trigger the callback… eventually.
In the callback for the change from the PLE it calls a function that is concerned about triggering. um call it, “checkCalbackTrigger()”. This sets the trigger to the one you want to do.
Then in the callback when the track changes. (mOnTitleChange)… I think…, and the trigger is set, but the title is not the DCT, you do the specified callback via a lookup.
If you just did the triggered callback in checkCalbackTrigger it would trigger on the DCT, so you have to wait until it comes back from the PLE and the track changes back to the one you wanted.
Of course this is on a callback by callback basis.
This convoluted mess is because I can’t figure out how to watch for the event on the specific track without changing tracks.
Now for the functions in the callback.
You can make a set of CustomValueVariable s that are bound to the actions you want to trigger in the callback, and you make functions that match the name of the behavior. These then set the CVV, but the rest of the code will read like it is a function call to the host. Maybe even make it HostWrapper.doAction.
You could write the HostWrapper one time, You could even number the DCT actions and the callbacks so you wouldn’t even need to worry about what those are after it was written just once.
Save an array of whether it is immediate, or on track return, and build that functionality in.
It’s convoluted, and I haven’t tried it yet. But if you can display the name of the focused track on a display on a device, then I can’t see any reason this wouldn’t work. Which begs the question again.
Why didn’t they just provide events and callbacks? Just this thought experiment suggests that there isn’t a technical reason. It would have been a far superior architecture, and would have provided a simple path to something even more powerful.
Why does the surface representation on screen in the lower zone, or popped out to a separate window, not accept input? I can’t think of creating that code, and not thinking that it should be included. Someone would have to come along and tell the developer to leave out out specifically.
Are these related somehow?
I don’t get it.