Mopho, NRPN, MSB and LSB problem

Mopho, NRPN, MSB and LSB problem
« on: November 22, 2016, 12:05:59 AM »
So I finally started programming my midi controllers to control Mophoīs parameters.
CC works as expected but I would like to use NRPN to get access to more parameters.

I have a M-audio Trigger Finger Pro. When I map an NRPN to a knob/fader, it works like this. When the value is 0 on the controller, itīs 0 in the Mopho. As soon as the value is more than 0 on the controller, the value in Mopho jumps straight to 127 and stays there until the controller outputs "0".

First I thought this might be specific to trigger finger, as it has itīs problems and was generally a flop product, I bought it when the price had fallen from 400 to 130.

I then tried my Novation Xiosynth. Exactly the same thing happens there - controller values 1...127 give value 127 in Mopho.

I monitored the MIDI and I think I have a clue as to what is going on:

Both Both controllers ONLY send an MSB data entry CC, but no LSB data entry CC..  so the value MUST be in the MSB.
But I think Mopho is expecting the value as LSB. So as soon as the controller sends MSB value "1", Mopho interprets this as 1x128=128, so it tries to apply this value, which only goes to 127 so I end up with 127..

IMO in this case Mopho is not doing anything wrong, it is using MSB/LSB, like they are meant to be used. It is correct to multiply the MSB with 128. It is completely arbitrary to use MSB to send 7-bit values. The problem is with the controllers, they should be sending the value as LSB! (and sending MSB value 0, or on the case of filter cutoff, sometimes 1, because it goes to 164)

Am I correct?

And what could I do now...
Why the fuck are 2 controllers using only MSB to send 7-bit values (this is blatantly WRONG as far as I can understand)
And if this is such a widespread wrongness in controllers, I canīt use many controllers to control the Mopho with NRPNs and still have to resort to using a PC...
Like I said this seems to not be Mophoīs fault, but WTF am I supposed to do now. The controllers donīt seem to offer a way to configure if they send MSB or LSB, which is strange IMO..

Hereīs the MIDI output from the Xiosynth. The Trigger Finger did exactly the same thing so I wonīt post that separately.
As you can see they are not sending the LSB data entry AT ALL... (itīs a fader going up from 0, after the note event)


« Last Edit: November 22, 2016, 12:11:48 AM by eksotik »

Re: Mopho, NRPN, MSB and LSB problem
« Reply #1 on: November 22, 2016, 12:17:46 AM »
BTW I also experimented with the data increment and decrement CCīs.
They work but itīs fucked up, I can use one fader as increment and another as decrement, so when you move the increment fader in any direction (!) the value increments, same with the decrement.. and the value being changed has to be selected separately from the inc/dec... But that is messed up and useless and not how faders/knobs are supposed to work.

What this confirms though, is that the CC and NRPN values are getting to the Mopho and itīs reacting to them fine.
Problem is the controllers. I really would like to control it without using a computer..

Can anybody at least recommend a controller where MSB/LSB implementation is not fucked up and arbitrary?
« Last Edit: November 22, 2016, 12:20:54 AM by eksotik »

chysn

  • *****
  • 1812
Re: Mopho, NRPN, MSB and LSB problem
« Reply #2 on: November 22, 2016, 04:19:56 AM »
Was there a Mopho preset for the Trigger Finger Pro, or did you make it yourself?

The interesting thing here is that the Data Entry LSB isn't sent at all. If you could switch that

Bn 06 vv

to

Bn 26 vv

then the problem would be mostly solved (except for cutoff frequency). Is that a programming change that you're able to make in the setup?
Prophet 5 Rev 4 #2711

MPC One+ ∙ MuseScore 4

www.wav2pro3.comwww.soundcloud.com/beige-mazewww.github.com/chysnwww.beigemaze.com

he/him/his

Re: Mopho, NRPN, MSB and LSB problem
« Reply #3 on: November 22, 2016, 04:42:33 AM »
No preset, I started programming myself.
When selecting NRPN as the message type, it only allows the user to enter MSB and LSB for the parameter number, and then a min. and max. value, but the value only goes to 127. So the value itself can only be a regular 7 bit number it seems. So I wouldnīt be able to control the full cutoff range from it anyway.. but cutoff has a dedicated knob on the Mopho so thatīs not a big problem.

The problem is that is sends the LSB value as MSB and there is no setting for this on either machine.
But like I said, Novation Xiosynth does the exact same thing...

I remembered about kenton making a programmable midi utility that I could put in the middle of them. I guess it could change the MSB to LSB... but that can open up another can of worms. The parameter number itself still uses MSB. I guess it would be doable but I would rather not mess so much with such a simple task :D getting a number from 1 machine to another.
I would rather get a controller that can handle NRPNs properly.
Itīs astonishing though that 2 machines from 2 separate companies both piss on the MIDI spec for "convenience" reasons...

Glad itīs not the Mopho though :D
« Last Edit: November 22, 2016, 04:45:13 AM by eksotik »

chysn

  • *****
  • 1812
Re: Mopho, NRPN, MSB and LSB problem
« Reply #4 on: November 22, 2016, 06:20:42 AM »
Quote
Itīs astonishing though that 2 machines from 2 separate companies both piss on the MIDI spec for "convenience" reasons...

Well, technically they're not pissing on the spec. The MSB was actually designed to be the "main" value, while the LSB was designed to be an optional fine-tuning parameter. So a device that's capable of only 7-bit resolution should default to using the MSB.

However, now that devices with >7-bit resolution are commonplace, using LSB should definitely be a configurable option.
Prophet 5 Rev 4 #2711

MPC One+ ∙ MuseScore 4

www.wav2pro3.comwww.soundcloud.com/beige-mazewww.github.com/chysnwww.beigemaze.com

he/him/his

Re: Mopho, NRPN, MSB and LSB problem
« Reply #5 on: November 23, 2016, 04:08:45 AM »
Quote
Itīs astonishing though that 2 machines from 2 separate companies both piss on the MIDI spec for "convenience" reasons...

Well, technically they're not pissing on the spec. The MSB was actually designed to be the "main" value, while the LSB was designed to be an optional fine-tuning parameter. So a device that's capable of only 7-bit resolution should default to using the MSB.

However, now that devices with >7-bit resolution are commonplace, using LSB should definitely be a configurable option.

OK, I am quite new to this kind of MIDI sorcery, maybe I was  a bit too harsh.

Only reason I can think of for doing that is to lessen the MIDI traffic going on. Was it really a worthy optimization, sending 3 messages instead of 4... I doubt it, as we still use the same old MIDI, and as you say - now when more bits are commonplace and it still works, it seems to have been a pointless "shorcut" or convention to make, with no real gain, only confusion and problems down the road, like I am experiencing... not to mention itīs "mathematically" thinking straight out wrong. Like somebody in the military writing "120" as the time for something, and half of the units turn up at 12:00 and the other half at 1:20.. but at least the commander saved the trouble of writing a "0" :D


Anyway...
Before I got into that, Iīve noticed people asking about and stressing the importance of midi implementation of hardware, elsewhere and in this forum.
So I am still looking for suggestions on a controller that can handle this properly.
« Last Edit: November 23, 2016, 04:10:33 AM by eksotik »

Re: Mopho, NRPN, MSB and LSB problem
« Reply #6 on: November 25, 2016, 02:04:28 AM »
Itīs curious though, I looked into it a bit more, and the general consensus seems to be that indeed "LSB" is an optional fine tuning parameter. Which is still a bad idea IMHO.
I find it interesting because Dave himself was one of the inventors of MIDI... so it seems nobody is right and wrong in this situation. The controllers are a bit weak for not allowing full control of NRPN, and Dave should have opposed this principle in the midi spec :D especially as his synthesizer (I havenīt tried other DSI synth but Iīm guessing they are the same) now uses NRPN in a logical way.

page 12 talks about this:
http://oktopus.hu/uploaded/Tudastar/MIDI%201.0%20Detailed%20Specification.pdf

Re: Mopho, NRPN, MSB and LSB problem
« Reply #7 on: November 25, 2016, 11:11:58 AM »
There is a standard CC6 is the high bits and CC 38 is the low bits.

If your parameter is equal or less than 7 bits then you only need to use CC6.

CC38 is NOT fine tuning.

And it's not a bad idea!
« Last Edit: November 25, 2016, 11:13:57 AM by BobTheDog »

Re: Mopho, NRPN, MSB and LSB problem
« Reply #8 on: November 28, 2016, 07:45:41 AM »
There is a standard CC6 is the high bits and CC 38 is the low bits.
Yes, that is correct.

If your parameter is equal or less than 7 bits then you only need to use CC6.
Yes, that is correct according to MIDI spec. Unfortunately it doesnīt work like that on the Mopho.

CC38 is NOT fine tuning.
IMHO it shouldnīt be, itīs confusing to call it that. But thatīs what the general consensus sais, backed up by the MIDI spec, which I posted a link to.

And it's not a bad idea!
It is in the sense that now we have a situation where MIDI controllers canīt control a MIDI synth properly, which was the problem that MIDI was meant to solve in the first place - a common language. Now we have a situation where some send 7 bit values as MSB, others as LSB.
If a parameter is equal or less than 7 bits, then it would make sense to send "MSB=0" and put the 7 bit value in the LSB. This is how the Mopho operates. It makes perfect sense too. Itīs similar to when we want to write a time of day and less than 10 minutes have passed from the latest hour, we will write the minutes as ":05" not ":5" just because 10 minutes havenīt passed yet and we can save writing a "0". In this example the "0" is MSB and the "5" is the LSB. It makes sense to always put the LSB in the same place, not put it here in one case and there in another case.
I still think itīs a bad idea (because it leads to MIDI "breaking down" in some cases, as I have witnessed).
Could you explain why itīs not? I really canīt understand it. Only advantage I see to only sending MSB is that it saves 25% of MIDI traffic (3 messages instead of 4) - but is it really worth it? Are there any other gains from this?

Re: Mopho, NRPN, MSB and LSB problem
« Reply #9 on: November 28, 2016, 11:27:35 AM »
When they came up with midi digital communication was slow, the midi standard uses a bit rate of 31250 bits per sec.

If you have a slow bitrate for your comms you need to come up with a design that minimises the amount of data you send, otherwise you are going to get timing problems.

A note on or note off message takes aprox 1ms at this bitrate, so if you were to play a 8 note chord from a sequencer even though they are scheduled at the same time the notes would be spread over 8ms, if you then also start sending crap loads of data at the same time then this spread of 8ms is going to get even bigger.

So with NRPNs you can have the data as either 1 byte or 2 bytes, this saves bandwidth. Also you don't need to send the 98/99 CCs again as these should be remembered and you only need to send the parameter bytes to keep updating the same parameter, this also saves bandwidth.

The only time that CC39 could be considered a fine tune is when the parameter range is 2^14 (16384), so the MSB and LSB have a range 0-128 then MSG is course and LSB is fine if the range is anything different to this then it isn't a fine tune.

For example lets say you param range is 0-512

In midi binary (S = status bit): 512 = S0000100 S0000000

So the MSB can only have the values 0, 1, 2, 3, and 4. It doesn't have the range 0-127.






Re: Mopho, NRPN, MSB and LSB problem
« Reply #10 on: November 29, 2016, 02:40:43 AM »
When they came up with midi digital communication was slow, the midi standard uses a bit rate of 31250 bits per sec.

If you have a slow bitrate for your comms you need to come up with a design that minimises the amount of data you send, otherwise you are going to get timing problems.

A note on or note off message takes aprox 1ms at this bitrate, so if you were to play a 8 note chord from a sequencer even though they are scheduled at the same time the notes would be spread over 8ms, if you then also start sending crap loads of data at the same time then this spread of 8ms is going to get even bigger.

So with NRPNs you can have the data as either 1 byte or 2 bytes, this saves bandwidth. Also you don't need to send the 98/99 CCs again as these should be remembered and you only need to send the parameter bytes to keep updating the same parameter, this also saves bandwidth.

The only time that CC39 could be considered a fine tune is when the parameter range is 2^14 (16384), so the MSB and LSB have a range 0-128 then MSG is course and LSB is fine if the range is anything different to this then it isn't a fine tune.

For example lets say you param range is 0-512

In midi binary (S = status bit): 512 = S0000100 S0000000

So the MSB can only have the values 0, 1, 2, 3, and 4. It doesn't have the range 0-127.

Yeah, but I understand all this... did you actually read through my posts? :D
(English is my second language and itīs a bit harder to write about a technical subject, so maybe I wasnīt clear enough)

I am only wondering if this bandwidth saving was/is actually worth it in practice, and arenīt we using the same old MIDI protocol and physical cables etc today?
... considering this, it would appear that Dave Smith doesnīt care much about this bandwidth saving and is using MIDI somewhat "improperly", because EVERY parameter expects the LSB value, when only some of them exceed 127. It is this aspect that puzzles me - the seeming inconsistency between MIDI and itīs "father" :D

Furthermore, the midi controllers I have make no use of data increment/decrement when sending NRPN, so considering all of the above, arenīt they wasting bandwidth by sending 3 messages instead of ... 1? I am away from my music gear ATM, canīt test properly, can only mess in MIDI-OX... but arenīt data increment and decrement just 1 message after the controller number has been set? So if they save bandwidth by sending 3 messages instead of 4, why not save more and send 1?

Should I try to use SysEx or smth instead? One of the software editors provides a choie between NRPN and SysEx, but I canīt monitor itīs output, at least ATM.

Re: Mopho, NRPN, MSB and LSB problem
« Reply #11 on: November 29, 2016, 10:34:58 PM »
Ok sorry I didn't realise you new it, I misunderstood your posts.

I looked at the Trigger Finger on the net, it only supports 7 bit values for nrpn and it does it correctly using the MSB.

If your Morpho is expecting 7 bit values in the LSB then it is wrong as far as my understanding of midi goes as the LSB is the optional byte.

Looks like a DSI problem to me.

Re: Mopho, NRPN, MSB and LSB problem
« Reply #12 on: November 30, 2016, 06:23:36 AM »
Now we`re on the same page :D
I figured all that out, it can also be seen on the picture I posted (Trigger Finger / XIOsynth sending MSB only).

If we forget the "fine tuning" thing, then to me (as a newbie in MIDI anatomy, but moderately technically minded) it makes perfect sense how the Mopho handles MSB and LSB - like orders of magnitude in a natural number somewhere in the range of 2^14 (16384). Itīs just positional notation:

"use of the same symbol for the different orders of magnitude (for example, the "ones place", "tens place", "hundreds place")"  https://en.wikipedia.org/wiki/Positional_notation

MSB and LSB are just like the "thousands place" and "hundreds place", just not in base-10.

IMHO saying that the "hundreds place" are optional, and when we have a number under a thousand, we should write it where the "thousands" usually are is a perversion of positional notation, as we are not respecting the positions, but treating them arbitrarily.

Itīs just as silly to say that the "hundreds" are fine tuning for the "thousands" - we seem to agree on that. I can understand what is meant by that, and it can be true in some circumstances, but a general rule itīs not. Itīs just a/the special case, like the square is to all possible rectangles, or the circle to ellipses... 

I know that the MIDI spec is only a suggestion, that manufacturers are allowed to use it differently...
Still, the Mopho way is the logical way which respects positional notation, and in that sense I wouldnīt say that DSI have messed up. I would say the general consensus with their "fine tuning" logic is messed up :D
It also makes sense to use it like that in Mopho, because there are some parameters that go over 127: filter cutoff, LFO frequency, BPM...

Iīm wondering how other DSI synth handle this. As the Mopho is one of the simplest synths they have, I would guess the bigger synths use parameter values over 127 also (and not necessarily all the way to 2^14)

chysn

  • *****
  • 1812
Re: Mopho, NRPN, MSB and LSB problem
« Reply #13 on: November 30, 2016, 08:01:08 AM »
Quote
Still, the Mopho way is the logical way which respects positional notation, and in that sense I wouldnīt say that DSI have messed up. I would say the general consensus with their "fine tuning" logic is messed up

The root of the problem here is that MIDI scaled up its range by using LSB. If you have to scale up your range, you should (almost) always build from the big end, not the little end. If devices a few years down the road started using 21-bit values, are they going to add an NRPN controller for ELSB ("even less significant byte")? I would hope not. That part of the specification was just flat-out done poorly.
Prophet 5 Rev 4 #2711

MPC One+ ∙ MuseScore 4

www.wav2pro3.comwww.soundcloud.com/beige-mazewww.github.com/chysnwww.beigemaze.com

he/him/his

megamarkd

  • ***
  • 286
  • One day I will fund a vuvuzela marching band.
Re: Mopho, NRPN, MSB and LSB problem
« Reply #14 on: January 31, 2017, 05:49:37 PM »
With regards to programming NRPN's for a DSI machine with a 7bit only controller, I've spread 14bit parameters across two knobs/faders by putting a 01 in the msb.  I'm using a Bitstream 3x which allows me to see and edit the actual hex being sent, so for the cutoff (on a Tetra) the code for the first slider/knob would be [B0 63 00 B0 62 07 B0 06 00 B0 26 00] with the control data inserted at value 12 (lsb) with the max and min's being 127 and 0.  The code for the second slider/knob is the same but with [01] being set for value 9 (msb), so it will look like this: [B0 63 00 B0 62 07 B0 06 01 B0 26 00], again with the control data being transmitted as value 12.  The max and min values for this should be set to 36 and 0.  This method does mean with parameters that don't stretch the entire 256 increments will be a bit lopsided, but for stuff like filter envelope amount which span from -127 to +127 it is very usable and gets rid of the large steps that can occur using CC's to map the parameter.  For the LFO, you can even separate the clocked rates from the free-run frequencies.

cbx

  • **
  • 145
Re: Mopho, NRPN, MSB and LSB problem
« Reply #15 on: May 20, 2017, 09:08:05 PM »
Two things to check:

Is your mopho set to receive/transmit NRPN?
Are you using the correct NRPN number, the manual is a little confusing as it lists the parameter value then the NRPN

Re: Mopho, NRPN, MSB and LSB problem
« Reply #16 on: July 09, 2018, 12:03:49 AM »
Hi all,

I’d also like to update my mopho desktop using with M-audio Code49 keyboard. Especially with arpeggiator I’d like to get as much hand-on feel as possible.
I’m trying to control arpeggio from Code49: Arpeggio on/off, arpeggio type, resolution, etc by using Code49 pads.
The problem is that mopho does not recognise any NRPN messages sent from Code49.

For example I’m trying to set up Arpeggio on/off -function from Code49 pad.

First I check Mopho is set to receive NRPN messages from global settings. Then I choose mopho to receive midi channel 2 (because that is the channel I usually use with Mopho).
Then I set code49 to send midi channel 2. Code49 keyboard works with no problem so the midi notes are transmited.
 
Then I open Code49 editor to set up one of the pads to send NRPN message to Mopho. I check from Mopho manual that 100 is the NRPN value for setting arpeggio on/off.

In Code49 editor menu you can choose from these options.

1. NRP/NRPN type

A) NRP fine
B) NRP coarse
C) NRPN fine
D) NRPN coarse

2. MSB value from 0 to 127

3. LSB value from 0 to 127

4. Value (NRPN/NRP) from 0 to 127

5. MIDI Channel 1-16, Global, Omni


What should I set for NRPN type and for MSB and LSB values? Value (4.) should be obviously 100 (for setting arpeggio on/off).
Any other ideas how to get this work? Im not an expert with MIDI/NRPN so every advice is welcome.

Thanks!
« Last Edit: July 09, 2018, 12:48:55 AM by RoundNoise »

chysn

  • *****
  • 1812
Re: Mopho, NRPN, MSB and LSB problem
« Reply #17 on: July 09, 2018, 02:50:58 AM »
Hey, RoundNoise, welcome to the forum!

These parameter names from the Code 49 are not very clear. There should be MSB/LSB settings for both parameter number and value. The arpeggiator's parameter number is 100, and its range of values is 0-1, with 1 being on. These are my best guesses as to the correct settings:

(1) NRPN Type: I think this should be NRPN Fine. Why? My guess is that "Fine" indicates that both MSB and LSB are sent (or at least that the single value is sent as an LSB). The Mopho requires that your value of 1 be sent as an LSB, and some devices send their parameters as MSBs (see prior posts). If the Code 49 can't do this, you're out of luck.

(2) MSB Value: I think this should be 0. This seems to be mis-phrased, and should be "MSB Parameter Number," because there's another "value" in (4). If this is right, then the parameter number we're interested in is 100, so the MSB would be 0.

(3) LSB Value: I think this should be 100. If (2) and (3) are actually the NPRN parameter number, then 100 would be the LSB of that parameter number.

(4) NRPN Value: I think this should be 1 to turn on the arpeggiator and 0 to turn it off. This is pretty clearly the value parameter.

Note that you can do everything right here and it still might not work, if the Code 49 isn't formatting its values in the correct MSB/LSB positions. That problem is what this whole thread is about. Good luck!
« Last Edit: July 09, 2018, 02:57:21 AM by chysn »
Prophet 5 Rev 4 #2711

MPC One+ ∙ MuseScore 4

www.wav2pro3.comwww.soundcloud.com/beige-mazewww.github.com/chysnwww.beigemaze.com

he/him/his