Newbie orientation

[bitsybabe]

As a newbie to MIDI altogether I have a few questions both in and around MIDIKit, and I‘m sorry in advance for any dumb ones!

1. Does the user on macOS or iOS need to fiddle with anything in the system to get their device into the world in which MIDIKit can see and connect to it? —Or if I put a Bluetooth MIDI adapter on my synth, will MIDIKit just be able to see it automagically?
2. Users tend to think of devices, not ports, so despite ports being the standard currency, I want my user to just select a device and from that, can I just connect the I/O ports?
3. How long does MIDIManager remember the connections? Is it like forever, across app restarts and phone upgrades and synth firmware updates?
4. I’m writing a librarian for one particular synth; are there classes or techniques to help with building all the SysEx byte streams I’ll need to create?
5. Does one standard MIDI file contain the entire library dump from the synth? Or is each patch stored in a file? Or is that up to me? And do the commands go in the file too, or just the data?
6. I want to offer a way for users to audition changes in their patches; if they save a musical phrase in a SMF would I use the real-time classes to transmit it?
7. There seems to be a lot of boilerplate code to include on my end at this time. Are there plans to provide some more streamlined ways to use the framework, so I can just say MIDIManager().firstDevice('410030').connect().getAllSettings() (not sure how to ID a device, but that is the mfr and model)? And then, device.send(currentPatch) (where device should know that send means transmitting on the out-to-in port)? I just think there’s a lot of opportunity to simplify - but I am new and not yet fully immersed into the code.

Thanks so much for any direction you can give me!

[orchetect]

It's on the to-do list to add a basic overview of MIDI, how it works on Apple platforms, and how MIDIKit helps when working with it.

Does the user on macOS or iOS need to fiddle with anything in the system to get their device into the world in which MIDIKit can see and connect to it? —Or if I put a Bluetooth MIDI adapter on my synth, will MIDIKit just be able to see it automagically?

Generally MIDI software and hardware is plug-and-play. On rare occasion, a piece of hardware will require a driver from the manufacturer to be installed (like if MIDI ports are part of a USB/Thunderbolt audio interface for example). But that is entirely the end-user's responsibility. From a coding standpoint, nothing special needs to be done. Bluetooth MIDI is a unique case and there are example projects in the repo to demonstrate how to get that working.

Users tend to think of devices, not ports, so despite ports being the standard currency, I want my user to just select a device and from that, can I just connect the I/O ports?

From my experience on Window and Mac, it's actually the opposite - users don't care about devices. They only care about endpoints. Both are discoverable through MIDIKit but usually endpoints are all you need. Even pro audio apps work this way, and only present the user with a single flat list of endpoints. The reason is that a device can have multiple endpoints, and it's ambiguous whether selecting a 'device' should merge all of its endpoints in that case. But if you would like to approach it the way you've described, you're welcome to.

How long does MIDIManager remember the connections? Is it like forever, across app restarts and phone upgrades and synth firmware updates?

The documentation should be fairly clear on this. All virtual endpoints and connections are preserved and auto-reconnected during the lifespan of MIDIManager, unless you change them. To restore them after an app restart, you would need to persistently store information regarding endpoint unique IDs and re-create the endpoints or connections. The one exception are persistent MIDI thru connections which are stored in the system and always active, even when MIDIManager is gone or the app has terminated. The use of these is discouraged, as Core MIDI exhibits certain bugs around this type of connection and it's easy to lose track of them and accidentally have orphan connections exist forever unless you are careful about managing them. Firmware or OS updates of any sort will never affect anything to do with MIDI.

I’m writing a librarian for one particular synth; are there classes or techniques to help with building all the SysEx byte streams I’ll need to create?

That piece is up to you. MIDKit focuses on core I/O and events so you don't have to deal with Core MIDI (which, trust me, you don't - it's been a nightmare over the years and easy to get wrong). There are various ways to create and parse SysEx messages in the library but nothing over and above that.

Does one standard MIDI file contain the entire library dump from the synth? Or is each patch stored in a file? Or is that up to me? And do the commands go in the file too, or just the data?

It entirely depends on the synth. Consult their user manual or documentation. The MIDI Spec itself only loosely defines some approaches to transmitting and storing raw data. And sad to say a lot of manufacturers don't always play by the same rules.

I want to offer a way for users to audition changes in their patches; if they save a musical phrase in a SMF would I use the real-time classes to transmit it?

There isn't a ton of interoperability between MIDI I/O and MIDI files as of yet, but they do share the same basic event types. There are no playback or sequencing classes. It's an item on the to-do list. AudioKit V6 adopts MIDIKit as a replacement for its old MIDI code and it has (or will have) more sequencing objects but I'm not sure what state it's in currently.

There seems to be a lot of boilerplate code to include on my end at this time. Are there plans to provide some more streamlined ways to use the framework, so I can just say MIDIManager().firstDevice('410030').connect().getAllSettings() (not sure how to ID a device, but that is the mfr and model)? And then, device.send(currentPatch) (where device should know that send means transmitting on the out-to-in port)? I just think there’s a lot of opportunity to simplify - but I am new and not yet fully immersed into the code.

A lot of effort was made in the design the library to have as little boilerplate as possible while maintaining the highest level of performance and feature set, so it's unfortunate to hear that. There's opportunities for API to evolve but, as most open source, it's a labor of love and takes volunteer hours to build out.

[bitsybabe]

Thank you so much for taking the time to respond. Your answers really help me to focus and I apologize if in any way I seem ungrateful for what I know has been a huge effort and obviously a labor of love. If there’s anything I can do to contribute in the future I shall, by way of heartfelt thanks!