Thanks for the thorough explanation. Unfortunately, you verify my fear that the MIDI 2.0 requirement for a Manufacturer SexEx ID will effectively block most Indie developers from using MIDI 2.0. (I wonder if MIDI 1.0 had been such a success if everyone creating products for it had to pay an annual fee...)

The "good" thing now is that I don't need to spend time learning about MIDI 2.0 since I don't have the finances to use it.

Gunnar - I would say, don't panic yet. Midi 2 is barely even off the ground, if even that.

The whole thing about the Mfg ID is protective rather than restrictive. The purpose is to allow manufacturers to do whatever they need to with SysEx, but protect their devices, and the devices of others, from damage from everyone else's SysEx. Any device can use the need for this ID to ensure that ONLY SysEx that is correct for this device reaches it.

As far as I know, there is no verification for this code in any of the software in any of the devices that might receive it, and as this software is in ROM and new codes might be added at any time maybe there could NOT be. So the chances are that any device receiving any ID would accept it.

A problem WOULD arise if the system included a device that DID have the ID that might have been borrowed. I have seen a fairly old list of these IDs, and even that list contained a number of Mfg names (and their IDs) that I've never heard of. They might be no longer in business, even if someone somewhere might still be using a piece of their 'kit'.

Anyway, we should see what happens when the Midi-2 plane does actually start yo fly?

Geoff

Gunnar,

The MIDI CI uses Universal System Exclusive commands as I explained in my post above Bavi's.

JohnG.

JohnG,

Yes, the MIDI-CI uses Universal System Exclusive commands that include Manufacturer SysEx ID, something that the "Details" page clearly states that I must have to implement MIDI-CI and MIDI 2.0.

JohnG: You are correct that the beginning of the messages all use a Manufacturer ID of hex 7E (Universal System Exclusive - Non-Real Time), but within the data of the "Discovery" and "Reply to Discovery" messages, there are fields for Manufacturer ID that represent the device that is initiating or replying to the discovery request:

Ideally it'd be best to pay for a Manufacturer ID assignment to ensure there won't be any conflicts if you ever need to define device-specific messages. But if you are a developer that only wants to query MIDI 2.0 devices, I wonder if there is any harm in putting a Manufacturer ID like hex 7D (Non-Commercial) or hex 7E (Universal System Exclusive - Non-Real Time) in the Discovery message? I don't understand all the details and potential use cases of MIDI 2.0 to know if this could cause a problem.

Bavi,
Thanks for your direct response.

[quotePost id=12355]JohnG: You are correct that the beginning of the messages all use a Manufacturer ID of hex 7E (Universal System Exclusive - Non-Real Time), but within the data of the "Discovery" and "Reply to Discovery" messages, there are fields for Manufacturer ID that represent the device that is initiating or replying to the discovery request:

Ideally it'd be best to pay for a Manufacturer ID assignment to ensure there won't be any conflicts if you ever need to define device-specific messages. But if you are a developer that only wants to query MIDI 2.0 devices, I wonder if there is any harm in putting a Manufacturer ID like hex 7D (Non-Commercial) or hex 7E (Universal System Exclusive - Non-Real Time) in the Discovery message? I don't understand all the details and potential use cases of MIDI 2.0 to know if this could cause a problem.[/quotePost]

A Universal System Exclusive of 7Eh message is not a Manufacturer ID,
In my opinion a "universal" message shouldn't "require" a manufacturer's ID.
If it does, it isn't universal, by definition.
In my opinion.

A GM system on is a universla message.
It can be issued within any stream of MIDI messages.
Likewise a CI message should be possible but seems to include a Manufacturer ID within it.
What isn't made clear in the specification (that I've been able to interpret) is how, for instance a VSTi (or the DAW controlling it) exchanges messages with e.g. a hardware synth.
Does the VSTi (somehow) also embed data within an outgoing CI exchange.
Perhaps an new version of the VSTi specification (from Steinberg) is needed to clarify the situation.

I do wish that someone from the MMA protocol group would clarify this section.

Yes, I think it would be good if someone from MMA could clarify this. If you think about it, the situation is rather absurd.

In MIDI 1.0, you only needed a Manufacturer ID to define your own SysEx message.

In MIDI 2.0, MMA claims: "To implement MIDI-CI and MIDI 2.0, you need a manufacturers SysEx ID".

There is a maximum of 16.383 unique SysEx IDs. If the MMA claim is correct, everyone on the planet that wants to implement MIDI 2.0 (however simple) needs a SysEx ID. That will (IMO) lead to a situation where all IDs will be occupied, and no additional companies (large or small) can implement MIDI 2.0. And MMA will have annual revenue of $4.259.580, pretty good for a non-profit organization.

This simply can't be the case...

Totally agreed Gunnar!

But then, when the specifications were published with only USB connection, and no MIDI 2 SMF defined, I decided to ignore the whole thing until considerably more clarity was present, ... and I for one, will not be holding my breath.

How do you write any sort of DAW software without the MIDI 2 SMF spec?
Surely there needs to be a new VST/VSTi spec. to accomodate MIDI CI between a MIDI controller and the s/w instrument?

Maybe we'll see some clarity by 2025?

I'll be sticking to making music with MIDI 1.0 for the forseeable future.