Talk about BORING!

What faith have I in MIDI 2 after seeing this?
Well, if they can't even get a projector working (in a lecture theatre), not a lot.

Question:
How long does a MIDI 2 device wait for a MIDI 1 device not to respond to its capability request?
A second, 5, 10, a minute?

No mention at all of how the standards are advancing, if at all, with MIDI 2 over USB (2?, 3?) firewire, Ethernet, etc.

As Shakespeare once said, or maybe paraphrased, "full of sound and fury and signifying nothing!"
I shan't hold my breath.
Yawn.

Hi --

1. OUCH! I can tell you that having the AV crew struggle with getting the slides to show properly was zero fun as one of the presenters. We discussed the problem with the ADC organizers afterwards. To be honest, I'm not 100% sure what the deal with the projector hardware losing sync was, but the AV crew folks that I interacted with were pros.

2. A good question about the negotiation process. The real answer is going to be "it depends" -- each individual timeout and delay in the process are specified on the scale of 100-300 ms, so it's a good bet that doing the entire protocol negotiation is going to happen faster than a modern instrument takes to complete its boot up cycle.

3. I'll be sure to include more jokes in my part next time, I guess?

4. We'll all see what happens, I guess.

1. OUCH! I can tell you that having the AV crew struggle with getting the slides to show properly was zero fun as one of the presenters.

Blaming a presenter for technical problems of the venue they're presenting at is asinine, but to then assert it's a bad sign for a completely unrelated protocol is insane.

3. I'll be sure to include more jokes in my part next time, I guess?

Please don't. You presented a technical topic to a technical audience and I, for one, was riveted.

4. We'll all see what happens, I guess.

There are already two MIDI 2.0 devices (that I'm aware of) on the market and the spec has not yet been published. I see that as a very good omen of more good things to come.

Blaming a presenter for technical problems of the venue they're presenting at is asinine, but to then assert it's a bad sign for a completely unrelated protocol is insane.

Well, I suspect that makes me both asinine and insane.
Having been a technical presenter for many, many years, I very soon discovered that not having one's material presentable (content and technology) has a severe impact upon one's credibilty.
(Subjects: early on-line transaction processing programming, ISDN D channel protocol, DSL rollout in the UK to some of the ISP's, CSMA/CD, structured cabling, TCP/IP, X.25 courses, data comms via satellite to Telco's worlwide, etc.)
Sadly, the more one struggles with the equipment, the more incompetent one looks.
It gets in the way of the message.
A quick test the evening before goes a long way to iron out any issues.

Just as my wife, when singing with an orchestra, does at least one rehearsal beforehand. Not to do so is asinine.

But, agreed, filling the presentation with jokes isn't the solution.
Maybe a few specific examples of usage would help.
E.g. "so if one is trying to send a 16 bit note on message, on channel 4 of the second group, the content might look as follows:-"
Slide with appropriate content.
Use a pointer (or have the area highlight) and explain the content.
Etc.

There are already devices on the market that claim to be MIDI 2 compliant.
If the spec hasn't been approved yet, how can they make that claim?
And just how much of the MIDI 2 spec do they claim to be conformant with?
What transport mechanism do they use? USB? What flavour?
Ethernet? Firewire? ???
How is the MIDI 2 protocol packetised into the packet structure of the mechanism being used for interconnect?
Data comms isn't only about protocols. But protocols within protocols and packets within packets.
e.g. HTML within HTTP within TCP/IP etc.
And, perhaps most importantly, electrical interconnects. Nothing of that to be seen in the whole presentation.
Where is the standard, e.g. issued by the USB standards committee, describing the packetisation of MIDI 2 into USB packet structure?

What happened to all of the polyphonic aftertouch MIDI 1 devices?
Why do none of the manufacturers I've tested use more than 10 bits of the 14 bit pitch bend message.
Maybe ten bits is enough? So why more?

A lovely, challenging academic excercise no doubt.

Thanks for this less...inflammatory (?) reply.

At the time we presented that (last November) the standard had *not* been voted on, and the MMA requested that we not show too much detail yet. I ripped things out of my slides, and to be honest, probably left in a few things that they would have preferred I not.

At NAMM in January, the entire set of MIDI 2 standards were voted on and approved. As of this moment, not all of those docs are publication ready, the working groups are going through all of the text looking for ambiguities and contradictions. The expectation is that everything will be published soon, perhaps in 1Q.

Not sure it makes sense in the absence of the full spec doc, but a new Note On message on Gr2:Ch4 (middle C, velocity = 50000 (~97 in MIDI 1 velocity)) looks like this in hex:



The other questions about transport -- MIDI 2 is transport-agnostic. the USB transport spec is working its way through the USB-IF and seems pretty far along.

As for it being an academic exercise -- we'll see, I guess? I'd like to think that the companies who've spent a boatload of money sending folks to working group meetings for the last bunch for years have done so for reasons other than purely academic.

You're right, this is going to take time for widespread adoption. Adopting the spec is the beginning of the process, not the end.

Thanks for this less...inflammatory (?) reply.

Infammatory? Perhaps.
Depends upon one's point of view, doesn't it, and how one responds to criticism?

Critical? Certainly.
Still, in my view at least, infinitely prefarable to boring.

As for it being an academic exercise -- we'll see, I guess? I'd like to think that the companies who've spent a boatload of money sending folks to working group meetings for the last bunch for years have done so for reasons other than purely academic.

I suspect for the same reasons I went to CCITT and BSI meetings as a company representative of a major mainframe computer manufacturer, with data communications protocols, etc.
To find out how much these things made sense and whether they might affect future products.
If decisions made there had no commercial sense to criticise and attempt to find agreement for appropriate implementable standards.
If the specifications make no sense or are far too costly to adopt, then to implement, maybe, a limited set of them.

Consider, if you will, why most manufacturers only implement 10 of the 14 potential bits of the most sensitive of MIDI 1 controls, pitch bend.
We have a potentiometer which is centered by spring pressure.
Beacause of its position within a typical MIDI controller keyboard, it has a relatively narrow range of movement.
Maybe 60 degrees in each direction?
The electronics which sense this movement is required to generate more than 16,000 values from this small physical displacement (+/- 8192).
Most companies, in my experience, find this level of accuracy far too expensive to manufacture, hence the restriction to around 1,000 values (probably 0 to 1023),
i.e. +/- 512.
As far as I see the manufacturing costs, implementing note on messages with values in the thousands makes no commercial sense at all.
And, 99.9% of customers have no need for this kind of accuracy. Nor will they be prepared to pay the excessive extra costs of manufacturing.

Look a the cost of the ROLI keyboards, they aren't MIDI 2 and they have no sound generator on board.

All the good old polyphonic aftertouch keyboards have disappeared. Why?
I suspect, too expensive to manufacture and sell at a price and in sufficient volume to make some profit from the development costs.

Hence my comment "a lovely, challenging academic excercise"! I stand by it.
(Actually, extremely simple compared to ISDN 'D' channel signalling at he 'S/T' interface.)

Time may prove me wrong, and It won't be the first time. I'll live with it.
But overall in the last 50 years I've been right more times than wrong with these issues.
And you're allowed to say "Nyah! I told you so!" ii I am proved wrong.
I've not survived into my seventies without taking some criticism, some pretty harsh, along the way.

Pitch bend wheel resolution of 10 or 14 bits has nothing to do with the limited physical movement of a potentiometer or the mechanical tension of the spring. It is because of either lower-res Analog to Digital Converters (ADC) circuits or limited software processing.

Good potentiometers are built from sturdiy materials which will last through decades of heavy use, BUT even cheaper ones can offer much better resolution - all it takes is an upgrade to a better ADC curcuit with 24/32 bit conversion. And there are a lot of industry-standard 16-channel 24 bit 31.25 kSPS ADCs, like Analog Devices AD4111/AD4112/AD7173 which go for $10 in large quantities. The reason why manufactures did not upgrade their synths is exacly because such better resolution wasn't required by the MIDI spec.

And if you want better controllers that allow finer movements comparing to spring-loaded joysticks or wheel controls, there is a lot of new technologies that could be used to replace the potentiometer - like touch-sensitive ribbons and glass, optical/infrared sensors, motion detection cameras, etc.

I did not miss anything. The MIDI 2.0 protocol supports 32 bit precision and it's up to instrument manufacturers to decide how to implement it - but 24-bit ADCs are cheaper than ever and US$10 gets you a 16-channel 24-bit ADC, i.e. 16 separate analog inputs for 16 different knobs/wheels/joysticks. So it would make little sense to introduce a premium MIDI 2.0 product and then cut corners by using ancient 10-bit ADCs from 1989.
(And if I discovered that someone does such ridiculous thing in a $1000 product, I would make sure to disclose this on every forum which I frequent, not to mention that I would never ever buy anything from them thereafter).

Dmitry,

"Such a ridiculous thing" yes, I didn't post the name here because it will probably be deleted, given that the manufacture concerned plays a prominent role on the MMA.

So I suggest you take a look at another forum and specifically the thread about pitch bend calibration here:
thread about pitch bend on a keyboard
See what you make of it.

My point is that if manufacturers are reducing costs to such an extent that they can't afford (?) to put at least 10 bit pitch bend controllers in their products, what chance is there of 16 bit let alone 24 bit controllers seeing the light of day.
We may see a few top end keyboards (with top end prices) for a short while then, like keyboards with polyphonic aftertouch, they'll disappear because 99.9% of the market doesn't need, and isn't prepared to pay the premium for such features.

Time will tell.

It's not a secret that Yamaha synthesizers only implement 7-bit pitch bend resolution in the tone generator part.

There is a disclaimer in the Data List / MIDI Data Format supplements (or the MIDI Implementation Chart sections of the user manual) for all Yamaha synthesizers and stage pianos released since late 1990s, that pitch bend is 'Transmitted with a resolution of 7 bits.'

Earlier variations of the same remark included Pitch Bend is transmitted with a resolution of 7 bits, receives only Pitch Bend Change MSB, Pitch Bender value LS byte (ignored), Operates with only the MSB data, Pitch bend is received only on the MSB side, Resolution 7 bit, Pitch Bender 0-12 semi 7-bit resolution, etc.


This is how it's been handled since Yamaha DX7 - in fact I came across this same issue with my own Motif ES, so my memory obviously failed me here! Huh.

Montage/MODX synth engine is no different - even though Montage uses two microcontrollers on the PNL board (Fujitsu MB9AF141NA and Toshiba TMP89FW24AFG) which include 12-bit and 10-bit multi-channel ADCs respectively.


I'd guess Yamaha truncated pitch bend to 7 bits so it could be assigned as a realtime control source for any synth parameter and not just oscillator pitch, thus it was natural to send it through the usual 7-bit data path for other controllers. But today it makes no sense and sure looks like an artifact from the old days when digital synths came with 8-bit 4 MHz Z80 processors and 1 Kbyte of DRAM memory, and required weird hacks like MIDI Running Status to save processing bandwidth.

I look forward to Yamaha's implementation of MIDI 2.0 but I really expect them to use dedicated 24-bit ADCs and 32-bit data paths in their new products - otherwise I will have to act on my promise to never buy their synths again, and I would hate to do this...

Again, 7-bit resolution is simply what was specified by MIDI 1.0 standard - better ADCs aren't really that much expensive, in fact Montage/MODX comes with 10/12-bit ADCs for physical wheels and sliders.


As for extended 32-bit resolution in MIDI 2.0 Channel Voice Messages, even these do not requre 'a lot of money'. You would need to replace the standard ARM Cortex-M microcontroller with a part that uses precision 20/24-bit multi-channel ADCs (like Analog Devices ADuCM362), and that shall cost you exactly the same (and maybe a bit lower); maybe you'd need add a standalone multi-channel 20/24-bit ADC (like Analog Devices AD4111/4112).

I expect that to be a part of a regular product update cycle, since the original Fujitsu part has already been discontinued (following a string of acquisitions/bankruptcies of Fujistu Semiconductors, Spansion, and Cypress Semiconductors). Maybe they would need to take special attention to power supply noise and wire isolation/grounding (but most likely this has already been taken care of when they designed DAC/ADC circuits in the Montage). And 32-bit software implementation will likewise be a part of a regular product development and update cycle.

Again, 7-bit resolution is simply what was specified by MIDI 1.0 standard - better ADCs aren't really that much expensive, in fact Montage/MODX comes with 10/12-bit ADCs for physical wheels and sliders.

7 bit for controllers in the MSB and a further 7 bits in the LSB.

Except for Pitch Bend, with its own separate message, was specified as 14 bit. Which Yamaha now ignore in the modx and montage.
Pitch Bend needs to be 14 bit due to the ears sensitivity to pitch as opposed to volume.
If one extends the pitch bend range e.g. to an octave (+/-12), for guitar 'slides', then 7 bit resolution is absolutely hopeless.

Sending LSBs in a separate message poses significant implementation issues.

Suppose you've received one of the MSB controllers (CC #0-31) - you will need to effect the MSB immediately, and wait for (optional) matching LSB messages (CC #31-63) to arrive and alter the data value.
But if subseqent LSB is big enough, it may cause a jump of the recorded value that results in an audible step - especially when response curve is non-linear (i.e. a small change of contoller value results in a significant change of the controlled parameter). This would eliminate any benefit of increased controller resolution, which is supposed to allow much smoother transitions.
If you wait for both MSB and LSB messages to effect the full 14-bit value, the latency could increase significantly, since the two halves are not guaranteed to arrive within reasonable time.
Additional message traffic will strain the already struggling 31.25 Kbit/s serial interface.


Pitch Bend does not suffer from these problems, since MSB and LSB arrive in the same message, and I do think that truncating the 14-bit Pitch Bend value to 7-bit permanently and irreversibly - not just for the specific purpose of sending it through the controller assignment matrix - is clearly an implementation error that should have been avoided on modern 32-bit microcontroller platforms.

Those 24 bits ADC specify their sps at much lower bit rates. At 24 bit ADC, the sample speed becomes so very low hat the sps becomes much slower than notice-able latency of 4msec (2 sps = 500msec). The practical limit of no noticeable ADC latency is probably some around 16-18 bits but then that is for a 1 or 2 channels, what if you have 88 keys, it may need quite some hardware (and thus pockets). 24 bit ADC requires some pretty good analog circuitry as well to avoid the noise. if some company claims the instrument support 24 bit MIDI shouldn't that be taken with some grains of salt (bits 15-24 random or zero) ?