MIDI Devices & Presets

[joebear]

1) BH-iPad 'New MIDI Preset' screen (or editing existing MIDI Preset). For existing projects (each of which have a MIDI Device defined), there seems no ability to define Program Changes to be sent on other channels. Other than the Raw MIDI area, that is. Other projects -- that have no MIDI Devices defined -- have a row per channel in the Program Changes section. Is this by design? Just trying to understand. I guess I can understand the philosophy of 'if one MIDI Device is defined, all midi devices must be defined as MIDI Devices'. I now see your statement to this effect in http://www.bandhelper.com/tutorials/sending_MIDI.html

2) Depending on stage or studio, one client or another, I may be using different hardware. I may have the same (e.g.) guitar processor, but connected through different interfaces (sometimes in rather complex setups).
Currently, the Port binding seems suboptimal for my application. While it makes sense that the MIDI Channel is an attribute of the MIDI Device, it seems odd to define the Port as an attribute of each MIDI Preset. This results in the necessity of editing each and every MIDI Preset if one changes the Port upon which a given device exists (as happens when I go from studio to stage). If the Port were an attribute only of the MIDI Device, the Port could be changed just once in the MIDI Device screen, and all presets would inherit that attribute at runtime - as they do for channel.
There is a Port attribute in the MIDI Devices definition. However, I can't seem to get it to work. If I set that attribute in MIDI Devices to anything other than 'All', it still needs to be set to match in each and every MIDI Preset. If it is set differently in the MIDI Preset -- even to 'All' -- I no longer get anything sent out over any Port.

Edit: Hmm - I just noticed. After assigning a Port other than 'All' to a MIDI Device, then in each MIDI Preset, within the 'Program Changes' area, that device's row disappears. This is the case even if the MIDI Preset Port is set to 'Any'. If one changes the MIDI Preset Port to match that of the MIDI Device, the device is again displayed under Program Changes. The tradeoff is that any other device (even if its Port in MIDI Devices is set to 'Any') is eliminated from the MIDI Preset under 'Program Changes'.

The surface problem might seem to be too literal a string match, with no context of 'Any'. It seems to me, however, the most rational resolution would be to eliminate the Port from the MIDI Presets attributes/screen, deferring to the associated MIDI Device's Port.

3) In BH-iPad, on many screens (most? all?) there is a set of icons. The rightmost seems to be a sync icon, the next looks like it might be dedicated to device linking, the third (working leftward) looks like a DIN connector, which makes me think 'MIDI'. If I tap it, it greys out. Tap it again, it is back to white on black. Whatever the sate of it, however, MIDI seems to be sent on any event that would send MIDI -- which also flips the greyed out icon back to white. What is this icon indicating?

[arlo]

2) Depending on stage or studio, one client or another, I may be using different hardware. I may have the same (e.g.) guitar processor, but connected through different interfaces (sometimes in rather complex setups).
Currently, the Port binding seems suboptimal for my application. While it makes sense that the MIDI Channel is an attribute of the MIDI Device, it seems odd to define the Port as an attribute of each MIDI Preset. This results in the necessity of editing each and every MIDI Preset if one changes the Port upon which a given device exists (as happens when I go from studio to stage). If the Port were an attribute only of the MIDI Device, the Port could be changed just once in the MIDI Device screen, and all presets would inherit that attribute at runtime - as they do for channel.

When I added multiple port support, I added it at the MIDI preset level instead of the MIDI device level for backwards compatibility; the current structure takes longer to set up for those who need it, but it avoided the need to rework all the MIDI data that everyone had entered before that point. Since relatively few people have a need for this functionality, that was a better tradeoff, but it could change in the future if more people need to use the port assignments.

However, the main thing to know about ports is that you should only set them if you need to. Usually they are only needed if you have more than 16 MIDI devices, and addressing them by channel is not enough; in that case, you would address each device by its port and channel. If you do not need to do this, and you don't set any ports anywhere, then it's no problem to move from one set of devices to another, as long as they are configured to use the same channels.

There is a Port attribute in the MIDI Devices definition. However, I can't seem to get it to work. If I set that attribute in MIDI Devices to anything other than 'All', it still needs to be set to match in each and every MIDI Preset. If it is set differently in the MIDI Preset -- even to 'All' -- I no longer get anything sent out over any Port.

If you want to use ports (which are optional) and MIDI devices (which are optional), they do need to match exactly. "Port 1" matches "Port 1" and "All" matches "All," but "Port 1" does not match "All." Again, I recommend making your life easy and not using ports (leave all the port settings as "All").

3) In BH-iPad, on many screens (most? all?) there is a set of icons. The rightmost seems to be a sync icon, the next looks like it might be dedicated to device linking, the third (working leftward) looks like a DIN connector, which makes me think 'MIDI'. If I tap it, it greys out. Tap it again, it is back to white on black. Whatever the sate of it, however, MIDI seems to be sent on any event that would send MIDI -- which also flips the greyed out icon back to white. What is this icon indicating?

The icon indicates whether the MIDI engine is running (normal or faded) and whether the app is sending or receiving MIDI data (blinking). Tapping the app turns the MIDI engine on or off, but sending any MIDI data also turns the MIDI engine on, so there's no way to force it to stay off.

[joebear]

When I added multiple port support, I added it at the MIDI preset level instead of the MIDI device level for backwards compatibility; the current structure takes longer to set up for those who need it, but it avoided the need to rework all the MIDI data that everyone had entered before that point. Since relatively few people have a need for this functionality, that was a better tradeoff, but it could change in the future if more people need to use the port assignments.

I'm not getting what sort of compatibility consideration would lead to a need to implement Ports at the Preset level, where it seems to me they can only conflict with the Device level. I guess I need to ponder that.

However, the main thing to know about ports is that you should only set them if you need to. Usually they are only needed if you have more than 16 MIDI devices,

In the interest of precision, they are needed only if one consumes more than 16 *channels*. Note that many devices consume many channels. 7 per guitar synth (1 per string + master control) and 9 per multitimbral synth (8 pitched, and percussion on ch10) are de riguer. That's 16 right there. Where do I route the control over the FX processors in the mixer? Lighting controller? If I have all the above, over another port is the only option. This would be fine, except it is the MIDI router that defines port names, and the router changes between stage and studio, client to client, whcih causes the port name to change.

C'est la guerre.

As I stated, it can be worked around. I just don't understand the logic that makes the Channel an attribute of a Device only (when more than zero Devices are defined), while a Port is an attribute of both Device and Preset.

and addressing them by channel is not enough; in that case, you would address each device by its port and channel. If you do not need to do this, and you don't set any ports anywhere, then it's no problem to move from one set of devices to another, as long as they are configured to use the same channels.

It is not the devices that change so much, as the routing infrastructure. I'm OK with today's projects on a single Port. I have done other projects in the past which required many ports. I likely will again.

The icon indicates whether the MIDI engine is running (normal or faded) and whether the app is sending or receiving MIDI data (blinking). Tapping the app turns the MIDI engine on or off, but sending any MIDI data also turns the MIDI engine on, so there's no way to force it to stay off.

Got it - thanks for the explanation.

[arlo]

I'm not getting what sort of compatibility consideration would lead to a need to implement Ports at the Preset level, where it seems to me they can only conflict with the Device level. I guess I need to ponder that.

If ports were not set at the MIDI preset level, then the data saved for every program change entered into a MIDI preset would have to include the port info. Otherwise the app wouldn't know where to route each program change when the preset is triggered. This wouldn't be a problem to include for program changes added in the future, but all the program changes that all users have entered in the past would have to be updated. Now let's say some obscure problem appears in the conversion process after the app is released, affecting 1 in 1000 of the existing presets. That would still create a lot of angry users.

Additionally, MIDI devices are currently optional and used only to organize the display. In this new setup they would be used for actual routing, so it would work best to move a program change's channel info from the program change level to the device level. That means MIDI devices would become required even for users who have no need for port filtering.

Rearranging the data structure would undoubtedly be better for the small number of users who need to do port filtering, but I have to balance that against all MIDI users in general, who would receive no benefit but could see some trouble from this change.

In the interest of precision, they are needed only if one consumes more than 16 *channels*. Note that many devices consume many channels. 7 per guitar synth (1 per string + master control) and 9 per multitimbral synth (8 pitched, and percussion on ch10) are de riguer. That's 16 right there.

Okay, yes. But Set List Maker generally only needs to communicate with one channel per device, so the device/channel distinction is less important here.

Where do I route the control over the FX processors in the mixer? Lighting controller? If I have all the above, over another port is the only option. This would be fine, except it is the MIDI router that defines port names, and the router changes between stage and studio, client to client, whcih causes the port name to change.

The only physical ports an app can see are the ports provided by a MIDI interface attached to the USB port. It can't see whatever ports are further along in your network. When you say your MIDI router changes, are you referring to a multi-port USB interface?

[arlo]

For the new BandHelper and Set List Maker versions coming this month, I reworked this to set the port only at the MIDI device level and not at the MIDI preset level. To avoid a risky conversion process, I implemented this in a way that allows the old format of MIDI preset and the new format to both work together. Basically, any existing MIDI presets will continue working as they do now, but if you edit or add a MIDI preset, it will be saved in the new format, which links back to the MIDI device associated with each program change to get the port for the program change. (If you have not defined any MIDI devices, the app will continue to use the old format.) More info is in the release notes...

http://www.bandhelper.com/support/release_notes.html#ios_2_4

...and I will post updated documentation when the apps are released.

Let me know if you have any trouble adapting to the new format. I did include a way to mass-update all your presets to the new format, but I would recommend testing with some individual presets first.

[joebear]

Hi Arlo -
From the description, this looks like it will improve my workflow significantly.
I have a gig Thursday, with not enough intervening time to probe new features. I'll update to newest rev shortly after the gig, and let you know how I get on with it.
Thanks!

[arlo]

Okay, but my fear about triggering a bug in this functionality came true even though I avoided globally converting your data:

http://forum.arlomedia.com/index.php/topic,1090.0.html

So I don't recommend updating until version 4.2.1 is available.

[joebear]

Thanks for the notice. Classic 'index off by one' error? That's bit me enough times.

[arlo]

Yes, it's the difference between how MIDI is numerically represented (channels 0-15) and visually displayed (channels 1-16).