Fuzz and Val,
Thats an interesting direction that never occurred to me…sysex F9, F4, F5, and F253; as a way to map and trigger something in the environment and vice versa.
Thanks for the visuals, super helpful! And killer response!
So for playback events, scriptor sits after playback and before any Instruments. If record is set, the VSTi treats the received events just like playback. The environment however can intercept before it hits the Logic sequencer engine. Right?
I gather that when using the external midi instrument plug-in you can then get midifx scriptor to “sit in-front” of the environment when used on an external midi track?! Which is really cool, and I am going to try that to use midifx strummer to play some outboard gear. Then try the iac to play a standalone like kontact player or pipe back into logic.
Back to topic….So in my case that would still require two tracks, essentially making my no output midi track no longer needed. But you have to still select the external midi track and record enable the VSTi track you mean to record on. Not really hard to do, and I suppose that’s a much cleaner work flow without every instrument requiring two tracks. I would however still prefer a couple objects set in the environment, never to be looked at again…like your suggestion. And then just throwing a scriptor on the instrument track where you would want that functionality.
An environment cc trigger could allow midi to pass to the virtual instrument only when a conditional state is met. So the environment sets a special CC flag that isn’t recorded on the midi track. Sysex is a cool approach as that is not normally recorded. Having it as a track pluggin eliminates the no-output track. And you can just turn midifx off when your done recording with that track. Could even map the plug-in bypass function to some midi event or key press.
In the environment set up a global transformer to send F4 for all note on events and F5 for all note off events without filtering the source data.
In Scriptor when it sees F4/F5 events it filters all midi from reaching the VSTi. When it sees no F4/F5 events it just lets them play.
So the scriptor logic might be something like if F4 or F5 exists and Note on or Note off exists then run block output. If F4 or F5 do not exist and Note on or Note off exists then run stop block output. I think some type of window average and timer to smooth out a change of blocking state would be a good measure for sanity…but maybe not even needed.
Seems pretty simple. I see a potential for hung notes. So some type of dimensional array to track which note-ons have not been sent note-offs…for when going to the blocking state. But v1 could just send all note offs and value resets for the pedals, pitch and wheel with each blocking function state change. Maybe use a dictionary lookup for what things and values comprise a reset. A midi panic lite of sorts, I guess.
V2 could track live vs playback by comparison, you would have to duplicate one channel to a dedicated midi channel in the environment and maybe have all those velocities reset to zero. The idea being only the live events are the ones that get dropped. That would allow for overdub loop style of midi recording…even with external gear. But I still primarily punch in-out with both audio and midi.
Thanks for your detailed responses. Great stuff! You both rule!