Post by nic on May 1, 2014 9:31:06 GMT
I have received a number of requests about the possibility of making MidiBus an Audiobus compliant app so that the transport can be controlled from the Audiobus panel.
All my apps including MidiBus and MidiBridge are MIDI only apps in that they do not process or generate audio (ie. they have no audio engine). In Audiobus' current incarnation an app requires an audio engine in order to participate on the 'bus.
I did talk/email with the Audiobus guys when they were developing version 1 and asked them to consider catering for MIDI only apps like (at the time) MidiBridge, Genome, Little MIDI Machine, Phaedra et al so that these apps could join the party and benefit from Audiobus' app-switching mechanism and panel. Unfortunately I was unable to convince them of the merits of this and to this day the audio engine requirement remains.
Ultimately there are three options:
1. I modify my apps to include some sort of dummy audio engine that could sit in the input slot generating silence. This approach would concern me in terms of efficiency as my apps would (unnecessarily) need to process audio, adding to CPU load. I'm not keen on this approach.
2. Audiobus adjust their architecture to permit non-audio apps (new slot type - Control?) to be Audiobus aware just in terms of the app-switching/transport panel. To date, all indications form the Audiobus team are that this is not a path they wish to follow.
3. No-one does anything and the status quo remains.
All is not lost however, as there is a bit of a workaround that can be used at the moment:
The MidiBus app responds to incoming clock, in particular the start/continue and stop MIDI messages (ticks are ignored), so it is possible to control the MidiBus transport remotely, either from an external hardware controller, or indeed another app.
The concept of the external controller is pretty straight forward. You set up all your apps that can slave to receive clock from the MidiBus app and send a MIDI start (FA) and Stop (FC) from the controller. In some cases where the controller does not send FA/FC, MidiBridge can be used to translate the controller message to start/stop. An example of this is (in this case DM1, but MidiBus app works the same way) is here.
If you have an Audiobus aware app that can both send and slave to an external clock (I believe BeatMaker 2 can do this), then you can set that up so that the app *sends* its clock signal to the MidiBus app and then it (and all other apps) slave to the MidiBus clock signal. You start/stop everything via the BeatMaker transport; from BeatMaker itself or the Audiobus panel.
Please feel free to comment.
Nic.
All my apps including MidiBus and MidiBridge are MIDI only apps in that they do not process or generate audio (ie. they have no audio engine). In Audiobus' current incarnation an app requires an audio engine in order to participate on the 'bus.
I did talk/email with the Audiobus guys when they were developing version 1 and asked them to consider catering for MIDI only apps like (at the time) MidiBridge, Genome, Little MIDI Machine, Phaedra et al so that these apps could join the party and benefit from Audiobus' app-switching mechanism and panel. Unfortunately I was unable to convince them of the merits of this and to this day the audio engine requirement remains.
Ultimately there are three options:
1. I modify my apps to include some sort of dummy audio engine that could sit in the input slot generating silence. This approach would concern me in terms of efficiency as my apps would (unnecessarily) need to process audio, adding to CPU load. I'm not keen on this approach.
2. Audiobus adjust their architecture to permit non-audio apps (new slot type - Control?) to be Audiobus aware just in terms of the app-switching/transport panel. To date, all indications form the Audiobus team are that this is not a path they wish to follow.
3. No-one does anything and the status quo remains.
All is not lost however, as there is a bit of a workaround that can be used at the moment:
The MidiBus app responds to incoming clock, in particular the start/continue and stop MIDI messages (ticks are ignored), so it is possible to control the MidiBus transport remotely, either from an external hardware controller, or indeed another app.
The concept of the external controller is pretty straight forward. You set up all your apps that can slave to receive clock from the MidiBus app and send a MIDI start (FA) and Stop (FC) from the controller. In some cases where the controller does not send FA/FC, MidiBridge can be used to translate the controller message to start/stop. An example of this is (in this case DM1, but MidiBus app works the same way) is here.
If you have an Audiobus aware app that can both send and slave to an external clock (I believe BeatMaker 2 can do this), then you can set that up so that the app *sends* its clock signal to the MidiBus app and then it (and all other apps) slave to the MidiBus clock signal. You start/stop everything via the BeatMaker transport; from BeatMaker itself or the Audiobus panel.
Please feel free to comment.
Nic.
