Yamaha MOX/Motif pitch wheel stepping?! Help!

[bloodyMary]

So I finally received my MOX6, which is supposed to replace my old Korg as the main board.

 

Well, aside from being built like crap (wobbling plastic everywhere, gaps between plastic parts, and slightly unleveled keys) it plays fine and I like the sound.

 

Until I tried to program my usual synth lead, which is an aggressive saw lead with pitch wheel set to -24/+2 range.

 

I love using the negative bend to make a 'dive', it sounds cool and adds expression to my solos.

 

So I started playing...and whenever I bend down, there's stepping, almost like I'm playing a chromatic scale while using the pitch bend.

 

Seems like the Pitch Bend has inadequate resolution.

 

 

What's up with THAT????

 

 

 

Any of you Motif guys experienced this stuff?

 

Is there a workaround or I'd just have to return this board? Damn, I waited for like 2 months to get it, and really looked forward to using it..

 

 

 

I might upgrade to Motif XS for better build, but if the engine and controllers behave the same, I'd pass.

 

 

Help me, I only have so much time before I can't return it anymore..

[MIDI2XS]

I own an XS and an XF. They both exhibit "stepping" or "zipper effect", the degree depending on controller settings. It can easily be demonstrated with a Voice such as PRE 5 C14 Lucky if the PB Range is set wide enough -- 24 semitones will definitely reveal the issue.

 

It does appear to be a controller resolution issue, since doing a 2-octave portamento with "Lucky" doesn't seem to sound as bad.

 

The Motifs do a lot of things well, just not everything.

 

[Reezekeys]

My very quick and possibly wrong math is that a true 14-bit pitchbend message would give you ~8190 separate messages bending down, which over a 24-semitone range would be around .003 semitones, or .3 cents per step. Obviously that's not happening with your MOX. I'm guessing that Yamaha wants to save some processing power and is quantizing the pitchbend resolution into grainier steps, but I would be curious to see if the pitchbend is indeed transmitting true 14-bit values. I can't imagine that it isn't, but I've seen a few instances of more recent products "dumbing down" features so I wouldn't be shocked if that were the case.

[MIDI2XS]

Unfortunately, to quote the XF's Data List, "PITCH BEND CHANGE ... Transmitted with a resolution of 7 bits". I verified, using MIDI-OX to capture the data, that there are about 127 values transmitted over the entire PB up/down range. At 24 semitones, that means each step is about 3/8 of a semitone, which is rather coarse.

 

[AnotherScott]

Unfortunately, to quote the XF's Data List, "PITCH BEND CHANGE ... Transmitted with a resolution of 7 bits". I verified, using MIDI-OX to capture the data, that there are about 127 values transmitted over the entire PB up/down range. At 24 semitones, that means each step is about 3/8 of a semitone, which is rather coarse.

Interesting. I wonder whether the Yamahas at least respond to higher resolution pitch bend. That is, even if the internal pitch wheel is limited in that respect, maybe you could still get the kind of bend you want if you were triggering your Yamaha sound from a second keyboard whose pitch bend sent higher resolution?

[Reezekeys]

7-bit PB in 2013? Gotta wonder who made that decision and why. My 1984 DX7 has 14-bit PB.

[HammondDave]

That's strange. I own an XS and never encountered this issue...

[MIDI2XS]

Interesting. I wonder whether the Yamahas at least respond to higher resolution pitch bend. That is, even if the internal pitch wheel is limited in that respect, maybe you could still get the kind of bend you want if you were triggering your Yamaha sound from a second keyboard whose pitch bend sent higher resolution?

The Data List indicates the PB change message is comprised of LSB and MSB, each of 7 bits (14 bits total). It's possible that Yamaha is using bit-limited analog-to-digital conversion for reading the PB control position, and therefore only has 7 bits of data to transmit. Based on the Data List information, and looking at the range of values (not the number of them) seen in the data I captured, it would seem that the Motif might indeed respond to a higher resolution PB message. Considering that portamento over a wide note span apparently doesn't have the problem, it's not a limitation imposed by the tone generator.

 

Since I don't usually need to bend more than a few semitones, I don't tend to have a problem with the Motif's PB. However, I can certainly understand how more demanding usage could be frustrating.

 

[AnotherScott]

Considering that portamento over a wide note span apparently doesn't have the problem, it's not a limitation imposed by the tone generator.

Right, and portamento is a whole different thing electronically, despite having a similar sonic effect. Portamento is sending a single MIDI Note On event, and the tone generator takes it from there. Pitch Bend is sending a separate MIDI event for every position of the wheel. So the first automatically generates "in between" pitches, the second never does, each pitch is essentially user-specified.

[Reezekeys]

The Data List indicates the PB change message is comprised of LSB and MSB, each of 7 bits (14 bits total).

AFIK the message is always 14 bits (two midi bytes), but on a 7-bit resolution message the LSB message will always be zero.

[MIDI2XS]

Considering that portamento over a wide note span apparently doesn't have the problem, it's not a limitation imposed by the tone generator.

Right, and portamento is a whole different thing electronically, despite having a similar sonic effect. Portamento is sending a single MIDI Note On event, and the tone generator takes it from there. Pitch Bend is sending a separate MIDI event for every position of the wheel. So the first automatically generates "in between" pitches, the second never does, each pitch is essentially user-specified.

Ultimately, portamento and PB aren't all that different. It's not as if there's an un-stepped ramped control voltage being applied to a VCO in the Motif. Obviously, with digital there are always steps. With portamento, some routine determines how many steps there will be during the glide. With PB, the number of steps is determined by the amount of control movement and (as we've been discussing) the resolution. My point was that since portamento on the Motif doesn't exhibit the same highly audible "stepping" as when the PB control is used, it would not be the tone generator that was preventing a smoother transition.

 

[AnotherScott]

This whole conversation also reminds me about how some people complain that the Nord Stage 2 has a limited pitch bend function. Implementing "obvious" features isn't always as simple as it may appear.

[MIDI2XS]

The Data List indicates the PB change message is comprised of LSB and MSB, each of 7 bits (14 bits total).

AFIK the message is always 14 bits (two midi bytes), but on a 7-bit resolution message the LSB message will always be zero.

Well, yes and no. The message indeed has two 7-bit bytes devoted to value. However, the LSB, even when only 7-bit resolution is transmitted, isn't necessarily always zero.

 

The first PB data byte is the LSB, the second the MSB. The LSB contains the "fine" control data, the MSB the "coarse". Each byte can have values ranging from 00h to 7Fh.

 

Maximum downward PB is (LSB/MSB) 00h/00h, while max upward is 7Fh/7Fh. PB center position is 00h/40h (64 decimal). Of course, 40h (64d) isn't really the center of a range of 128 values (0 through 127) - the MSB at 40h has 64 values below that but only 63 above.

 

The following is based on what I've observed with my XF and 7-bit PB data transmission:

So that the maximum upward bend will be the same as the max downward when the range settings are identical for each direction, an interesting approach is taken. For downward bending, the LSB does remain at 00h, and the MSB decreases from 40h to as low as 00h. For upward bending, the LSB/MSB needs to to be able to reach 7Fh/7Fh for max, so keeping the LSB at 00h won't do the trick. Starting at center (00h/40h) the first step of the 7-bit upward bend that's transmitted is not 00h/41h, but 02h/41h, the next step is 04h/42h, etc., until the two top steps are 7Ch/7Eh and finally 7Fh/7Fh. That is, with the upward bend the LSB gets incremented in steps of 02h. Since that byte is the "fine" data, each upward step is slightly wider than downward ones are, but it ensures that when the PB control is at max upward position, the bend will be to the full range that was set.

 

[bloodyMary]

Holy cow, that's just cheating on Yamaha part. Well, guess I'll try external control tomorrow..

 

Intended to use this as my only board.. Maybe I'll come up with a mod, seems like a fun project - get a 14 bit AD converter + microcontroller on a small board, hook the pitch wheel to that, and connect to midi input. Then hide that monstrosity inside the synth. I could do it, and have fun while doing it, but it would sure void the warranty.

 

 

 

Now, the question is whether I prefer Yamaha's cheating bend, or Korg's horrible aliasing oscillators (on the Krome).

 

Why can't they make the basic stuff work right!? They have like 40 years of experience and yet f@ck up such basic stuff!!

[MIDI2XS]

There's something else to consider. There are a lot more MIDI messages generated when using PB that's 14-bit than when it's 7-bit - 128 times as many. If enough is already happening - high polyphony, aftertouch, etc. - adding numerous more PB messages can increase the risk of MIDI data overload. Manufacturers might just be considering that many of us don't often need 2-octave bends, and that thinning the MIDI data can be advantageous over higher controller resolution.

 

[bloodyMary]

I think when a manufacturer implements a feature that allows for a 24 or even 36 semitones bend in their keyboard, they at least have to see if it sounds any good and make sure it does!

 

They could've thinned it to 10 bit, and it'd sound fine I'm sure (7 bit vs. 10 bit is 8 times more resolution!)

 

Besides, it works great on my Korgs and even on my older Yamahas..

 

 

 

This whole deal actually got me thinking of fitting a Roland joystick above the wheels, using the blank panel space. That'd be pretty cool - both joystick and wheel, right?

[MIDI2XS]

I think when a manufacturer implements a feature that allows for a 24 or even 36 semitones bend in their keyboard, they at least have to see if it sounds any good and make sure it does!

I agree that a feature should work well, or not be included. The Motifs can bend downward even more - try setting the Lower Range to -48 if you "like" what it does at -24.

 

 

This whole deal actually got me thinking of fitting a Roland joystick above the wheels, using the blank panel space. That'd be pretty cool - both joystick and wheel, right?

Before you go that far, please get back to us on whether an external controller with 14-bit PB MIDI output smoothes things on the Motif.

 

By the way, the knobs and sliders also are 7-bit (128 values over their entire ranges). If you intend to do anything real-time (sweeps?) with any of them, you might want to check whether that's going to be an issue for you as well.

[AnotherScott]

They could've thinned it to 10 bit, and it'd sound fine I'm sure (7 bit vs. 10 bit is 8 times more resolution!)

I don't think that's possible. If one data byte yields 7 bit resolution, and two data bytes yield 14 bit resolution, then you can't get 10 bit resolution, you can't send one and a half bytes or whatever. It's either processing the second byte (and its additional 128 possible values) or it isn't.

[MIDI2XS]

They could've thinned it to 10 bit, and it'd sound fine I'm sure (7 bit vs. 10 bit is 8 times more resolution!)

I don't think that's possible. If one data byte yields 7 bit resolution, and two data bytes yield 14 bit resolution, then you can't get 10 bit resolution, you can't send one and a half bytes or whatever. It's either processing the second byte (and its additional 128 possible values) or it isn't.

PB data in the LSB can be thinned by only passing values that are incremented by some predetermined amount. For example, assuming the generated PB data had LSB values 0,1,2,3,4,5,6,7,8,etc., a simple algorithm could thin that to 0,4,8,etc., just by making the lowest two bits of the LSB zero. That would result in 12-bit resolution. Make the lowest four bits of the LSB zero, and you'd have 10-bit resolution. The LSB is still 7 bits, it's just that not all of those bits would be used.

 

 

[AnotherScott]

PB data in the LSB can be thinned by only passing values that are incremented by some predetermined amount. For example, assuming the generated PB data had LSB values 0,1,2,3,4,5,6,7,8,etc., a simple algorithm could thin that to 0,4,8,etc., just by making the lowest two bits of the LSB zero. That would result in 12-bit resolution. Make the lowest four bits of the LSB zero, and you'd have 10-bit resolution. The LSB is still 7 bits, it's just that not all of those bits would be used.

I didn't think that would save any processing power, you're still reading the value in order to "round" it. But now I see, it is saving the tone generator from having to create a pitch for all those "extra" values you're sweeping through. And if that is done before sending the MIDI value to the tone generator, you are conserving MIDI bandwidth. So... point taken!

[MIDI2XS]

[...]if that is done before sending the MIDI value to the tone generator, you are conserving MIDI bandwidth. So... point taken!

Yes, and I should have mentioned that the thinning algorithm could just examine the lowest bits of the LSB (whatever number of them were considered expendable) and throw away any PB messages where any of those bits are non-zero. That approach would minimize what MIDI had to deal with, as you suggested.

 

 

 

[Reezekeys]

I'm thinking there would always be some thinning going on with true 14-bit PB, based on the rate of change in values. Suppose you quickly goose the PB wheel all the way up or down, in a very short time. Are 16,384 bytes gonna get sent in that quick interval? That would most definitely clog the midi data stream - at least the old 5-pin DIN, 32 kbaud midi stream. (Which leads me to wonder if keyboards produce different midi data streams over USB midi, since USB is a much faster protocol than old 5-pin DIN midi). Might be time for a "science experiment."

[Reezekeys]

The Data List indicates the PB change message is comprised of LSB and MSB, each of 7 bits (14 bits total).

AFIK the message is always 14 bits (two midi bytes), but on a 7-bit resolution message the LSB message will always be zero.

Well, yes and no. The message indeed has two 7-bit bytes devoted to value. However, the LSB, even when only 7-bit resolution is transmitted, isn't necessarily always zero.

Thanks for the explanation! You've illustrated why I usually preface "AFAIK" to these kinds of posts!

[MIDI2XS]

[...] Suppose you quickly goose the PB wheel all the way up or down, in a very short time. Are 16,384 bytes gonna get sent in that quick interval? That would most definitely clog the midi data stream - at least the old 5-pin DIN, 32 kbaud midi stream. [...]

Yes, a protocol designed to operate at 31,250 bits per second just might choke if asked to handle data at numerous times that rate.

 

 

Which gets us back to:

[...] Implementing "obvious" features isn't always as simple as it may appear.

True, and "Be careful what you ask for, you might get it" also comes to mind.

 

[Reezekeys]

Yea, thinking about it more I suppose the PB pot is sampled at a certain fixed frequency one that is designed to be compatible with the baud rate of midi.

 

To return - somewhat - to the original topic: I would really like to know why Yamaha couldn't or wouldn't implement 14-bit PB in one of their pro musical instruments. Is it really that hard to do?

[MIDI2XS]

Yea, thinking about it more I suppose the PB pot is sampled at a certain fixed frequency one that is designed to be compatible with the baud rate of midi.

MIDI is an asynchronous serial protocol - every byte of data is preceded by a start bit and followed by a stop bit. (That makes MIDI fairly unfussy, but those two extra bits added to each byte don't exactly help the transfer rate.) As long as you don't try to feed data so fast that there's buffer overflow, it should work.

 

 

To return - somewhat - to the original topic: I would really like to know why Yamaha couldn't or wouldn't implement 14-bit PB in one of their pro musical instruments. Is it really that hard to do?

In the XS, and probably in many of the recent Motifs, Yamaha used several 8-bit single-chip microcontrollers (NEC µPD780031AYGK). That chip has onboard ROM, RAM, and A/D. It's used to read buttons and controls, and can drive LEDs. The A/D section has 10-bit resolution, and there are eight channels of it on each chip. The one that's reading the PB control is also looking at the Modulation Wheel, the Ribbon Controller, and the pedal inputs. Others are looking at various buttons, knobs, sliders, and the Data Dial, as well as turning on/off related LEDs.

 

So, in response to your question "Is it really that hard to do?"...

Not that hard, and getting easier and less expensive to do as time goes by, due to advancements in chip technology. Yamaha might have looked at what chips were available at the time the XS was designed (about 10 years ago) and decided that the particular NEC micro incorporated what they needed, was likely of reasonable cost, and performed adequately. You also still have to ask if keeping compatible with MIDI (and by that I mean 31.25 kbps) is partially the issue.

 

[bloodyMary]

I'm thinking there would always be some thinning going on with true 14-bit PB, based on the rate of change in values. Suppose you quickly goose the PB wheel all the way up or down, in a very short time. Are 16,384 bytes gonna get sent in that quick interval? That would most definitely clog the midi data stream - at least the old 5-pin DIN, 32 kbaud midi stream. (Which leads me to wonder if keyboards produce different midi data streams over USB midi, since USB is a much faster protocol than old 5-pin DIN midi). Might be time for a "science experiment."

 

 

a rate limiter is real easy to implement - just add a line of code to the processor that says - only send out new pitch bend data if previous data was sent at least 20mSec before - so the data stream would get thinned on fast PB movements and not thinned on slow ones.

 

 

I actually think they saved some money on the A2D here, since 14 bit PB requires 14 bit A2D converter. using an 8 bit converter would probably save them a couple of cents..

[Reezekeys]

Yea, thinking about it more I suppose the PB pot is sampled at a certain fixed frequency one that is designed to be compatible with the baud rate of midi.

MIDI is an asynchronous serial protocol - every byte of data is preceded by a start bit and followed by a stop bit. (That makes MIDI fairly unfussy, but those two extra bits added to each byte don't exactly help the transfer rate.) As long as you don't try to feed data so fast that there's buffer overflow, it should work.

Yes, but what if you're triggering new notes in the middle of your wild pitch bending excursions? I would imagine the note events would have to be prioritized. Wouldn't a simple FIFO buffer cause late note triggers if there were a lot of PB events going on? Thanks for the explanations, this is all very interesting!

 

So, in response to your question "Is it really that hard to do?"...

Not that hard, and getting easier and less expensive to do as time goes by, due to advancements in chip technology. Yamaha might have looked at what chips were available at the time the XS was designed (about 10 years ago) and decided that the particular NEC micro incorporated what they needed, was likely of reasonable cost, and performed adequately. You also still have to ask if keeping compatible with MIDI (and by that I mean 31.25 kbps) is partially the issue.

Well, seeing that my original DX7, and many other keyboards, do full 14-bit PB, it's still puzzling to me. Hasn't 14-bit PB been part of the official midi spec since v1.0, back in the early 80s? Hard to believe they are doing this to save a few pennies per unit. Knobs & sliders I can see being sampled 8-bit as the regular control change messages are 0 to 127 anyway.

[MIDI2XS]

Yes, but what if you're triggering new notes in the middle of your wild pitch bending excursions? I would imagine the note events would have to be prioritized. Wouldn't a simple FIFO buffer cause late note triggers if there were a lot of PB events going on? Thanks for the explanations, this is all very interesting!

I think you've helped make my point why data thinning isn't necessarily completely evil. Even so, there's more to it than just sheer volume of data when it comes to timing.

 

As the PB control is moved, a three-byte message is generated for each position of the bend, with the increment determined by resolution. (Some of the messages might be two bytes long, rather than three, if "running status" is in use.) If you happen to hit a key during the bend, the note event is inserted in the data stream, and then the rest of the messages generated by the bend can be sent. But yes, if you do a bend and it generates "a ton" of data that precedes a note event, transmission of that event could potentially be delayed. That's why data thinning isn't necessarily bad.

 

As to data priority, some messages do get it. System Real Time messages can be inserted anywhere in the data stream. Those messages (such as Clock) can be critical to keeping things timed correctly, and since they're only one byte long they don't have much impact otherwise.

 

Here's something that might help put some of this in perspective. PB and Note-on/off messages are comprised of three bytes. At 31,250 bps, three bytes (30 bits, including start/stop for each byte) uses about 1.04 milliseconds (31250/30). MIDI latency can certainly introduce timing errors, but fortunately most of us are tolerant of events occurring several milliseconds off.

 

 

Well, seeing that my original DX7, and many other keyboards, do full 14-bit PB, it's still puzzling to me. Hasn't 14-bit PB been part of the official midi spec since v1.0, back in the early 80s? Hard to believe they are doing this to save a few pennies per unit. Knobs & sliders I can see being sampled 8-bit as the regular control change messages are 0 to 127 anyway.

Manufacturing cost is a fact of life. As I mentioned previously, Yamaha used several (four) of those NEC single-chip micros in each unit. I'm sure they got a substantial discount for purchasing them in quantity, and sometimes (often?) the accounting department has influence over engineering decisions.

 

The DX7 came out in 1983, and list price was about $2,000US. Inflation since then (30 years) would price the DX7 in today's dollars at about $4,680US - a Motif XF6 lists for about two-thirds of that. I'm not trying to defend Yamaha - there are certainly things to fault them on, and letting them know of any disappointment seems reasonable to me - but like all manufacturers, they have to design and price a product so that they can sell enough of them to clear a decent profit. That usually leads to some compromises. Anyone who can't live with the limitations should probably buy a different product.

 

[bloodyMary]

I see why low-res PB is easier and cheaper to implement - full 14 bit would require an extra chip (a 14 bit A2D), which would set them back a few bucks. Like 2 or 3 bucks, I mean.

 

 

It just pisses me of that they save 2 dollars on a $3000 product, which is supposed to be hi-end.

 

I always admired Yamaha for constant quality even in low end products, but this puts a hole in their reputation I think.

 

 

 

Anyway, MIDI2XS, thanks for sharing this cool info, about the NEC MCU's and stuff. really cool.

 

 

I think if I'm keeping the board (haven't made up my mind just yet), I'm building an external pitch bend thingie, maybe with a ribbon controller. I looked up and the popular (and cheap) Arduino developer boards have built-in 10 bits sampling, should improve the Yamaha PB about 8-fold.