Do I understand correctly that I must pay $280/year in order to use Midi 2.0?
If so - what is the purpose of such a fee?
As an Indie developer without any real income from developed solutions, that is not an option.
If so - what is the purpose of such a fee?
As an Indie developer without any real income from developed solutions, that is not an option.
Please explain what you mean by this.
I suspect that the $280 pa fee is to be a member of the MMA, which I assume may give you access to a Manufacturers SysEx ID (if you are in fact a 'manufacturer'). I very much doubt that there is any fee merely to 'use' MIDI 2.0. At the very least, the logistics of collecting suct a fee, even when MIDI 2.0 is actually available and can be 'used', will be complicated.
Geoff
I suspect that the $280 pa fee is to be a member of the MMA, which I assume may give you access to a Manufacturers SysEx ID (if you are in fact a 'manufacturer'). I very much doubt that there is any fee merely to 'use' MIDI 2.0. At the very least, the logistics of collecting suct a fee, even when MIDI 2.0 is actually available and can be 'used', will be complicated.
Geoff
Right, this makes a lot more sense than your your original question.
If you're making some sort of device that needs a unique ID, then you may need to get that ID recognised so that no-one else might use it. The fee referred to ($260 or $280) may be quite reasonable. Are you planning to make a midi device that will use such a SysEx ID? Will this device NEED a unique ID?
This is all quite different to merely 'using' MIDI 2.
Geoff
If you're making some sort of device that needs a unique ID, then you may need to get that ID recognised so that no-one else might use it. The fee referred to ($260 or $280) may be quite reasonable. Are you planning to make a midi device that will use such a SysEx ID? Will this device NEED a unique ID?
This is all quite different to merely 'using' MIDI 2.
Geoff
I'm developing software, not devices. From what I can see, the SysEx ID is not "optional" if I want to use Midi 2.0. I hope I misunderstand this, but judging by the information on the "Details about Midi 2.0" page, I cannot come to any other conclusion than that a SysEx ID is mandatory.
I cannot interpret these statements in any other way than if I don't have a SysEx ID, I cannot use Midi 2.0. ANd to have a SysEx ID, I have to pay $260/year. Please tell me I'm wrong.
- "The additional capabilities that MIDI 2.0 brings to devices are enabled by MIDI-CI."
- "To implement MIDI-CI and MIDI 2.0, you need a manufacturers SysEx ID."
- "If a device does not support any new features, it uses the MIDI 1.0 as usual. "
I cannot interpret these statements in any other way than if I don't have a SysEx ID, I cannot use Midi 2.0. ANd to have a SysEx ID, I have to pay $260/year. Please tell me I'm wrong.
0
Undo
Votes
You need the manufacturer's SysEx ID to talk to a MIDI device via SysEx. This is not a change from MIDI 1.0 which works the same way.
You only need to purchase a manufacturer's SysEx ID if you are creating a MIDI device (hardware or software) of your own.
You only need to purchase a manufacturer's SysEx ID if you are creating a MIDI device (hardware or software) of your own.
In MIDI 1.0, I didn't have to talk via SysEx unless I had some special requirement. I can, e.g. (which I have done), create software that remote control a DAW using MIDI 1.0 without ever touching SysEx. Since MIDI-CI is required to negotiate MIDI 2.0 features, I have to talk SysEx to enable MIDI 2.0.
As an example: My software can remote control Cubase 11 today using MIDI 1.0 (without having a SysEx ID). When Cubase 12 is released next year, I presume it will enable remote control using MIDI 2.0. Can I adjust my software to remote control Cubase 12 using MIDI 2.0 without having a SysEx ID?
As an example: My software can remote control Cubase 11 today using MIDI 1.0 (without having a SysEx ID). When Cubase 12 is released next year, I presume it will enable remote control using MIDI 2.0. Can I adjust my software to remote control Cubase 12 using MIDI 2.0 without having a SysEx ID?
So, your software is intending to control Cubase. Cubase may well constitute a 'device'. Cubase will probably need to 'implement' MIDI-CI. I would expect that in this situation, Cubase would need to have a Mfg ID. When your software communicates with Cubase to take control using SysEx, then your message to do that would need to include the Mfg ID of Cubase. BUT - will Cubase then need to communicate back with your device (software), I don't know. If it does need to communicate back, then the items you quote suggest that you WOULD need an ID, as would any other individual using MIDI 2 to communicate with Cubase.
Geoff
Geoff
I don't want to spend the time and energy to learn MIDI 2.0 and implement a solution just to find out that I must pay $260/year to be able to use it. That is why I put the question in the first place.
I think this statement on the main page is pretty clear: "To implement MIDI-CI and MIDI 2.0, you need a manufacturers SysEx ID. A SysEx ID by itself is $260 a year, but it is included with your MMA membership."
I think it's a serious restriction that will stop many hobbyists and small businesses from adapting MIDI 2.0. I, for one, will immediately stop investing time and interest in MIDI 2.0 if such a price tag is attached to the mere use.
I think this statement on the main page is pretty clear: "To implement MIDI-CI and MIDI 2.0, you need a manufacturers SysEx ID. A SysEx ID by itself is $260 a year, but it is included with your MMA membership."
I think it's a serious restriction that will stop many hobbyists and small businesses from adapting MIDI 2.0. I, for one, will immediately stop investing time and interest in MIDI 2.0 if such a price tag is attached to the mere use.
Yes, I totally agree with your concerns. I have written my own software to play midi files, and I would like to continue that part of my interest. If MIDI-2 SMF files become available, I would hope to be able to do the same with them. But at $260 per year, hmm?
But I still don't see how the collection of such a 'tax' would be practical, or enforceable.
As I understand it, the various MIDI-2 messages would comprise components that are in effect SysEx, other parts that are in effect MIDI-1 data, and other parts that are JSON (i.e. plain text). Some of these components could be encapsulated in other components, or just in the MIDI-2 type 'chunks'. I assume that ONLY the SysEx components would be affected by the 'problem' of needing the SysEx ID.
It would be interesting to see an example of an exchange to establish MIDI-CI and start a process. My interest would be for enabling a piece of software to communicate with a MIDI-2 enabled Tone Module to play a MIDI-2 SMF. Gunnar's interest would be different, but his example would still interest me.
Are there any such examples published yet?
Geoff
But I still don't see how the collection of such a 'tax' would be practical, or enforceable.
As I understand it, the various MIDI-2 messages would comprise components that are in effect SysEx, other parts that are in effect MIDI-1 data, and other parts that are JSON (i.e. plain text). Some of these components could be encapsulated in other components, or just in the MIDI-2 type 'chunks'. I assume that ONLY the SysEx components would be affected by the 'problem' of needing the SysEx ID.
It would be interesting to see an example of an exchange to establish MIDI-CI and start a process. My interest would be for enabling a piece of software to communicate with a MIDI-2 enabled Tone Module to play a MIDI-2 SMF. Gunnar's interest would be different, but his example would still interest me.
Are there any such examples published yet?
Geoff
I assume that ONLY the SysEx components would be affected by the 'problem' of needing the SysEx ID.
Yes, that is probably true. But since MIDI-CI is SysEx, you need a SysEX ID to perform MIDI-CI. And if you can't perform MIDI-CI, the other party will assume that you can't talk MIDI 2.0 and will fall back to MIDI 1.0.
So whatever we do, we come back to the statement on the Details page: "To implement MIDI-CI and MIDI 2.0, you need a manufacturers SysEx ID. A SysEx ID by itself is $260 a year, but it is included with your MMA membership."
Looking at the PDF of the "M2-101-UM MIDI Capabilities Inquiry (MIDI-CI)" manual, I can't find a place where it says that a manufacturer's SysEx ID is required.
Starting on page 16 and looking at the detail, what I see is that CI exchange is implemeted as an Universal System Exclusive.
(Thinking about it how could it be otherwise?)
The interchange is not done at a manufacturers level, but at a system level.
Page 18 and 20, et seq., continue this, confirming that the CI interchange is all done at the Universal level not at a manufacturers level.
So it's implemented in much the same way as the GM/GM2 system on messages.
You don't need to be a "manufacturer" to issue SysEx messages, you can generate Universal SysEx messages and messages to other manufacturers' devices from any piece of software just by including their ID. So Steinberg Cubase can issue sysex commands to e.g. a Roland device, by simply including the Roland code in the message.
JohnG.
Starting on page 16 and looking at the detail, what I see is that CI exchange is implemeted as an Universal System Exclusive.
(Thinking about it how could it be otherwise?)
The interchange is not done at a manufacturers level, but at a system level.
Page 18 and 20, et seq., continue this, confirming that the CI interchange is all done at the Universal level not at a manufacturers level.
So it's implemented in much the same way as the GM/GM2 system on messages.
You don't need to be a "manufacturer" to issue SysEx messages, you can generate Universal SysEx messages and messages to other manufacturers' devices from any piece of software just by including their ID. So Steinberg Cubase can issue sysex commands to e.g. a Roland device, by simply including the Roland code in the message.
JohnG.
MIDI 1.0
In MIDI 1.0, you only need to purchase a Manufacturer ID assignment if you want to specify a new kind of System Exclusive message (or a new kind of Sequencer-Specific Meta Event).
If you only need to send an existing format of System Exclusive message (or store an existing format of Sequencer-Specific Meta Event), then you would just use the Manufacturer ID of the existing format. As long as you do not extend the format of the message in a new way, you are allowed to use other manufacturers' messages.
If you are only developing messages for your own private use, you can use the non-commercial Manufacturer ID (hex 7D) which is "reserved for non-commercial use (e.g. schools, research, etc.) and is not to be used on any product released to the public." But if you want to publicly describe your new message, I think you would need to purchase a Manufacturer ID assignment to prevent conflicts.
(In the MIDI 1.0 Detailed Specification, see "System Exclusive Messages" starting on PDF page 39 / printed page 34.)
(In the Standard MIDI Files Specification, see "Sequencer-Specific Meta-Event" on PDF page 12 / printed page 10.)
(To see a list of Manufacturer IDs, on this website's footer, go to the "About the MIDI Association" page, scroll down to "Manufacturer System Exclusive IDs", the click the link "The MIDI Association publishes a list of every assigned System Exclusive ID number.")
MIDI 2.0
After a quick look over the MIDI 2.0 specs, it looks like to start a MIDI 2.0 connection, an Initiator has to send a Discovery message and the Responder has to send a Reply to Discovery Message. Both of these messages have fields for Manufacturer ID (as well as Device Family, Device Family Model Number, and Software Revision Level). (In the MIDI-CI Specification, see "5.5 Discovery Message" starting on PDF page 22 / printed page 17 and "5.6 Reply to Discovery Message" starting on PDF page 25 / printed page 20.)
However, each device generates a random MUID on startup (or regenerates a new random MUID in the rare case it detects a conflict). The Discovery and Reply to Discovery messages include these MUIDs, then it appears the rest of MIDI 2.0 messages use these MUIDs to identify the Source MUID and Destination MUID of each message.
So if you are developing software that just wants to query MIDI 2.0 devices, I think you would only need a Manufacturer ID for the initial Discovery message. I can imagine developers that want to query MIDI 2.0 devices but don't have resources to purchase a Manufacturer ID might decide to violate the spec slightly by using some dummy Manufacturer ID in the Discovery message. (Say, perhaps, a Manufacturer ID of hex 7D [Non-Commercial] and zero values for the Device Family, Device Family Model Number, and Software Revision Level.)
This could become messy however. If you ever have a need to define some response or value or profile that is specific to your software, you could be tempted to start defining your own values, but if other developers used the same dummy Manufacturer ID and developed conflicting definitions it would be an incompatible mess. To prevent that, the MIDI Manufacturers Association would probably want you to purchase a Manufacturer ID assignment, and would probably not endorse using a dummy Manufacturer ID.
But perhaps the MIDI Manufacturers Association might consider defining a special Manufacturer ID in the Discovery message for developers that only want to query and control other MIDI 2.0 devices and not define any values or profiles for their own software. (Say, perhaps, allow use of the Manufacturer ID of hex 7E [Universal Non Real-Time] in the Discovery message to represent this "query and control only" usage.) However, I don't yet understand all the details of MIDI 2.0 to know if this is a workable idea though.
Purpose of fees
On this website's footer, go to About the MIDI Association to read about the MIDI Manufacturers Association's purpose and the cost and benefits of corporate memberships ($600 to $20,000 per year, based on company sales revenue) or non-membership Manufacturer ID assignment fees ($240 per year).
Because the MIDI Manufacturers Association is a nonprofit organization, you can see their IRS returns to get an idea of how they use their money. (Note recent data is missing -- the IRS says "Expect delays in data updates for the Tax-Exempt Organization Search tool. We are still processing 990 series received April 2020 and later.")
In MIDI 1.0, you only need to purchase a Manufacturer ID assignment if you want to specify a new kind of System Exclusive message (or a new kind of Sequencer-Specific Meta Event).
If you only need to send an existing format of System Exclusive message (or store an existing format of Sequencer-Specific Meta Event), then you would just use the Manufacturer ID of the existing format. As long as you do not extend the format of the message in a new way, you are allowed to use other manufacturers' messages.
If you are only developing messages for your own private use, you can use the non-commercial Manufacturer ID (hex 7D) which is "reserved for non-commercial use (e.g. schools, research, etc.) and is not to be used on any product released to the public." But if you want to publicly describe your new message, I think you would need to purchase a Manufacturer ID assignment to prevent conflicts.
(In the MIDI 1.0 Detailed Specification, see "System Exclusive Messages" starting on PDF page 39 / printed page 34.)
(In the Standard MIDI Files Specification, see "Sequencer-Specific Meta-Event" on PDF page 12 / printed page 10.)
(To see a list of Manufacturer IDs, on this website's footer, go to the "About the MIDI Association" page, scroll down to "Manufacturer System Exclusive IDs", the click the link "The MIDI Association publishes a list of every assigned System Exclusive ID number.")
MIDI 2.0
After a quick look over the MIDI 2.0 specs, it looks like to start a MIDI 2.0 connection, an Initiator has to send a Discovery message and the Responder has to send a Reply to Discovery Message. Both of these messages have fields for Manufacturer ID (as well as Device Family, Device Family Model Number, and Software Revision Level). (In the MIDI-CI Specification, see "5.5 Discovery Message" starting on PDF page 22 / printed page 17 and "5.6 Reply to Discovery Message" starting on PDF page 25 / printed page 20.)
However, each device generates a random MUID on startup (or regenerates a new random MUID in the rare case it detects a conflict). The Discovery and Reply to Discovery messages include these MUIDs, then it appears the rest of MIDI 2.0 messages use these MUIDs to identify the Source MUID and Destination MUID of each message.
So if you are developing software that just wants to query MIDI 2.0 devices, I think you would only need a Manufacturer ID for the initial Discovery message. I can imagine developers that want to query MIDI 2.0 devices but don't have resources to purchase a Manufacturer ID might decide to violate the spec slightly by using some dummy Manufacturer ID in the Discovery message. (Say, perhaps, a Manufacturer ID of hex 7D [Non-Commercial] and zero values for the Device Family, Device Family Model Number, and Software Revision Level.)
This could become messy however. If you ever have a need to define some response or value or profile that is specific to your software, you could be tempted to start defining your own values, but if other developers used the same dummy Manufacturer ID and developed conflicting definitions it would be an incompatible mess. To prevent that, the MIDI Manufacturers Association would probably want you to purchase a Manufacturer ID assignment, and would probably not endorse using a dummy Manufacturer ID.
But perhaps the MIDI Manufacturers Association might consider defining a special Manufacturer ID in the Discovery message for developers that only want to query and control other MIDI 2.0 devices and not define any values or profiles for their own software. (Say, perhaps, allow use of the Manufacturer ID of hex 7E [Universal Non Real-Time] in the Discovery message to represent this "query and control only" usage.) However, I don't yet understand all the details of MIDI 2.0 to know if this is a workable idea though.
Purpose of fees
On this website's footer, go to About the MIDI Association to read about the MIDI Manufacturers Association's purpose and the cost and benefits of corporate memberships ($600 to $20,000 per year, based on company sales revenue) or non-membership Manufacturer ID assignment fees ($240 per year).
Because the MIDI Manufacturers Association is a nonprofit organization, you can see their IRS returns to get an idea of how they use their money. (Note recent data is missing -- the IRS says "Expect delays in data updates for the Tax-Exempt Organization Search tool. We are still processing 990 series received April 2020 and later.")
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.
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
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
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.
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.
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.
Thanks for your direct response.
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.
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.
- Page :
- 1
- 2
There are no replies made for this post yet.
