Post by nic on Dec 21, 2013 13:57:54 GMT
I'm getting feedback that there is some confusion with how the MidiBus library works and how it is related to the MidiBus app. In one line:
You do not need the MidiBus app in order for apps that use the MidiBus library to work.
I'm probably going to rename the app (if that is possible) on the next update.
Here is a post I made on discchord last week which might clarify things a bit:
You do not need the MidiBus app in order for apps that use the MidiBus library to work.
I'm probably going to rename the app (if that is possible) on the next update.
Here is a post I made on discchord last week which might clarify things a bit:
Right now the MidiBus *app* is a fairly simple utility for generating a very stable distributable clock source (as well as measuring accuracy of any clock sources) so maybe it should be called 'MidiChrono'. Over time I plan to add in other MidiBridge functionality like patching/routing, filtering and scenes, so that it could become more of a central MIDI tool which is why I left the name as is. This first v1.0 iteration is meant to be a handy utility for some musicians clocking multiple apps/devices and is not designed to be a panacea for fixing MIDI sync on iOS. It does appear to have helped a good few already though.
The MidiBus *library* on the other hand is architected to (hopefully) improve MIDI on iOS over time assuming reasonable adoption. An app that uses the library to add MIDI will be 'better behaved' in terms of virtual ports and channels due to the way it is setup. Right now there are a myriad of methods being used by iOS devs to implement CoreMIDI in their apps and due to the flexibility (and sometimes misunderstanding) of CoreMIDI these can often fail to inter-operate nicely or at all.
Some apps define loads of ports, others don't define any, some apps listen (fixed) to OMNI etc. All these variations result in the quagmire of interconnectivity we enjoy today. The library encourages (but does not force - a developer can override the default behavior if they want to) MIDI implementation consistency. Adding MIDI to an app with the library also only takes minutes (instead of weeks for someone just starting with CoreMIDI), so it *should* be attractive to developers to adopt it. It also adds features that are not currently in CoreMIDI, namely clock generation and better interface querying.
Again over time the feature set will be augmented (hopefully) so users of the library can add routing, filtering and possibly make use of MIDI transports that are not CoreMIDI. What gets added will depend upon take-up and demand!
The MidiBus *library* on the other hand is architected to (hopefully) improve MIDI on iOS over time assuming reasonable adoption. An app that uses the library to add MIDI will be 'better behaved' in terms of virtual ports and channels due to the way it is setup. Right now there are a myriad of methods being used by iOS devs to implement CoreMIDI in their apps and due to the flexibility (and sometimes misunderstanding) of CoreMIDI these can often fail to inter-operate nicely or at all.
Some apps define loads of ports, others don't define any, some apps listen (fixed) to OMNI etc. All these variations result in the quagmire of interconnectivity we enjoy today. The library encourages (but does not force - a developer can override the default behavior if they want to) MIDI implementation consistency. Adding MIDI to an app with the library also only takes minutes (instead of weeks for someone just starting with CoreMIDI), so it *should* be attractive to developers to adopt it. It also adds features that are not currently in CoreMIDI, namely clock generation and better interface querying.
Again over time the feature set will be augmented (hopefully) so users of the library can add routing, filtering and possibly make use of MIDI transports that are not CoreMIDI. What gets added will depend upon take-up and demand!