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.
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.
