ki
MidiFire Beta
Posts: 25
|
Post by ki on Jul 10, 2018 15:19:37 GMT
As AUv3 instument or effect, StreamByter receives the hosts AU transport and timing events in addition to the midi input stream.
There are several use-cases where one could do things ‚on host rewind‘ or ‚on host start‘ or ‚at the start or end of each bar‘. For instance send a program or pattern change on Rewind, or a kick note on ever beat and a crash note ever 4 beats.
These new use-cases would be possible if the AU messages were converted into standard midi messages and then forwarded to the script running. There are midi system messages for rewind, start and the clock...
I did not manage to catch midi timer or clock using AUM as host - even when i proxxy the AUM midi clock to a virtual midiflow input port that echos them back to a virtual midiflow output port which then is read by the StreamByter AU in AUM. The clock is shown and monitored in midiflow, but does not arrive in the StreamByter AU as if this additional tempo info is filtered by AUM so that they only get the AU transport/tempo events.
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 10, 2018 18:07:46 GMT
Hi ki , Yes, you're right - StreamByter does not implement the callbacks to handle AUv3 transport/timing events at all. It would be easy enough to convert the transport commands to their MIDI equivalents (where this makes sense - I would have to investigate) and inject into the ruleset. However, timing events, I'm not sure sure; maybe they could be converted into clock ticks or presented in some other way. I think that would be much more difficult. In any case, I have noted your suggestion - I cannot make any promises other then that I will look into it in further detail when I start on the next feature release cycle Regards, Nic.
|
|
ki
MidiFire Beta
Posts: 25
|
Post by ki on Jul 10, 2018 18:28:35 GMT
Thanks a lot for investigating - the transport events alone would open up some more use cases.
-ki
|
|