I have a patch from years ago that supposedly converts the input from my Motormix faders into MSB/LSB so I can access all 512 values from the faders. But the jumps in numbers happen in 128 add steps. So 0-16192 will come in from a fader, but in 128 piece jumps. I'm guessing there's something I'm doing wrong.

midiparse

midiin

number

comment

split

unpack

I have a patch from years ago that supposedly converts the input from my Motormix faders into MSB/LSB so I can access all 512 values from th

0-511-resolution-msblsb-midi-faders

Don't know about motormix, but generally 

14 bit controlers are sent in order LSB MSB, 32 CC numbers apart

that would mean that fader 1 which uses MSB CC# 0 and LSB CC# 32

should send this raw midi sequence : 176 32 (value LSB) 176 0 (value MSB)

Here with added another example using thresh and route to extract 14bit value

Screen shot 2021-02-18 at 10.14.21 AM.png

The result you get - stepping 128 values would mean that

Don't know about motormix, but generally 
14 bit controlers are sent in order LSB MSB,  32 CC numbers apart
that would mean that fader 1 which uses MSB CC# 0 and LSB CC# 32
should send this raw midi sequence : 176  32 (value LSB) 176 0 (value MSB)
your patch gets the value ok

The result you get - stepping 128 values would mean that
order of sent CC messages is reversed



When I monitor the output from your thresh example, the numbers are flipped:

I tried using zl.rot 2 to flip the order, but I'm guessing the expo math would need to be modified.

Above is from the CC of midiparse. If I output the raw midi with thresh, I get:

push fader 1:
0   0-128  32 64 (64 flickers 64 or 0)
stop pushing fader 1
15 0 47 0

I tried using zl.rot 2 to flip the order, but I'm guessing the expo math would need to be modified. 

Above is from the CC of midiparse. If I output the raw midi with thresh, I get:
push:
176 15 0 176 47 64 176 0 77 176 32 32
release fader:
176 15 0 176 47 0

All you need to do is to capture output and discover

which controlers are send as MSB which as LSB and order

then it is easy to route and calculate the values.

Just slide fader really slow to see when MSB value changes

I guess that first 2 CCs are fader touch On

 = 2 CCs to report that fader 1 has been touched,

176 0 77 176 32 32 = 2 CCs sending fader value, if you start moving slider slowly

from the bottom then LSB value should slide first from 0 - 127, MSB staying at 0

All you need to do is to capture output and discover
which controlers are send as MSB which as LSB and order
in which they arrive.
then it is easy to route and calculate the values.
Just slide fader really slow to see when MSB value changes
I guess that first 2 CCs are fader touch On
so the sequence for the fader 1 would be
176 15 0 176 47 64 = 2 CCs to report that fader 1 has been touched,
176 0 77 176 32 32 =  2 CCs sending fader value, if you start moving slider slowly
from the bottom then LSB value should slide first from 0 - 127, MSB staying at 0
176 15 0 176 47 0   =   at the end fader release CCs.
----





Wow, you really know your midi! I looked through the manual and it has a little info on it and you're pretty close I think.

176 32 0 — MSB? — alternates between 32 0 and 32 64

The position is sent out with 9 bits of accuracy. The 2 least significant bits can be ignored for 7-bit accuracy. When the user stops moving the fader, a ‘touch off’ message is sent out.

Guessing the order:

176 15 0 — fader 1
176 47 64 — touch ON 
176 0 111 — LSB? — 0-127
176 32 0 — MSB? — alternates between 32 0 and 32 64
176 15 0 — fader 1
176 47 0 - touch OFF

Manual:
B0-(00thru07)-MSB-(20thru27)-LSB
MSB=0 M M M M M M M
LSB=0 L L 0 0 0 0 0
The position is sent out with 9 bits of accuracy. The 2 least significant bits can be ignored for 7-bit accuracy. When the user stops moving the fader, a ‘touch off’ message is sent out.

only 0 32 and 64 for MSB is weird, that would means that real resolution

is not 14 bit, but 3 x 127, now I understand why you mention 0-511 in title.

Anyway, your calculation would then first need to scale 0 32 64

And if you don't need touch fader infos just leave them out.

only 0 32 and 64 for MSB is weird, that would means that real resolution
is not 14 bit, but 3 x 127, now I understand why you mention 0-511 in title.

Anyway, your calculation would then first need to scale 0 32 64
to 0 1 2 to form the expression.
And if you don't need touch fader infos just leave them out.



Could it be that I've got the MSB and LSB reversed? According to the manual, it should be first, not second.

To find out the order is pretty easy: Do something like this, and check the Max window (this one should work with your first fader):

Then, if you real resolution is 512, you should see 4 steps on the LSB.

Using the appropriate bit shifting operators (<< 7) in your original patch, you will be able to divide by the appropriate power of 2 to shift your value to the 0-511 range. Here is the idea, for you to adapt to your case:

Then, if you real resolution is 512, you should see 4 steps on the LSB.
Using the appropriate bit shifting operators (<< 7) in your original patch, you will be able to divide by the appropriate power of 2 to shift your value to the 0-511 range. Here is the idea, for you to adapt to your case:

yes, you have to capture one fader moving it slow from the bottom to the top.

From user manual description it should send LSB 0-127 first,

"176 32 0 — MSB? — alternates between 32 0 and 32 64 "

0-127 when MSB is 0 and 256- 383 when MSB is 64

To send 0 - 511 one needs 4 x 127 - means 4 MSB Values

each of them multiplied by 128 and added to LSB value.

Is that motormix using 0 32 64 96 as MSB values ?

Till you capture it and post info here, one can't say.

on the left exactly what would be sent and received

At right the whole fader string to midiout

yes, you have to capture one fader moving it slow from the bottom to the top.

From user manual description it should send LSB 0-127 first,
followed by MSB in 32 step jumps
---
But you write:
"176 32 0 — MSB? — alternates between 32 0 and 32 64 "
that is simply not possible.
it would mean that output could be only
0-127 when MSB is 0 and 256- 383 when MSB is 64

Midi CC handles only 0-127
To send 0 - 511 one needs 4 x 127 - means 4 MSB Values
In normal case that wold be MSB 0 1 2 3 
each of them multiplied by 128 and added to LSB value.
-----
Is that motormix using 0 32 64 96 as MSB values ?
Till you capture it and post info here, one can't say.

I guess that it sends MSB 0 32 64 96
here is patch simulating  that
on the left exactly what would be sent and received
through midi
At right the whole fader string to midiout


CC 32 has 4 steps that it switches between: 0 32 64 96. If I move the fader slowly, it seems to stay at 0. If I speed up, it goes to 64 mostly (some 0s) and occasionally see 96 and sometimes 32, but I can't figure out what the conditions are that trigger them. I thought it might be speed related, but I'm not sure.

Using your patches "complete emulation of motormix" area, I can move fader 1 (motorized) in four sequences from top to bottom.

@JEAN-FRANCOIS CHARLES:
CC 32 has 4 steps that it switches between:  0 32 64 96. If I move the fader slowly, it seems to stay at 0. If I speed up, it goes to 64 mostly (some 0s) and occasionally see 96 and sometimes 32, but I can't figure out what the conditions are that trigger them. I thought it might be speed related, but I'm not sure.

@SOURCE AUDIO:
Using your patches "complete emulation of motormix" area, I can move fader 1 (motorized) in four sequences from top to bottom.
1— 176 0 (0-127) 176 32 0
2— 176 0 (0-127) 176 32 32
3— 176 0 (0-127) 176 32 64
4— 176 0 (0-127) 176 32 96

BTW, CC 0 comes in first, CC32 comes second when moving the fader

@JEAN-FRANCOIS CHARLES:
BTW, CC 0 comes in first, CC32 comes second when moving the fader

that patch I posted is just a guess, it does not really mean it should work

but to maybe help analyse the midi output of that faders.

when you state that you can move fader 1 on motormix sending this to it

Screen shot 2021-02-22 at 9.08.33 AM.png

why do you write about 4 sequences and also why from top to bottom ?

when yellow number is at 0 - then motormix fader is at the top ?

you say that MSB value seems to differ depending on fader movement speed,

I have another guess - there are more messages involved which then

partly get displayed using thresh, but some get dropped when fader moves fast.

One should record real time fader moved slowly from the

bottom to the top into midi file and so capture all that gets sent.

trying to understand that part you posted from user manual.

if one interprets that 2 lists as binary 

MSB= 0 1 1 1 1 1 1 1 1 and LSB= 0 1 1 0 0 0 0 0 0

The position is sent out with 9 bits of accuracy.

The 2 least significant bits can be ignored for 7-bit accuracy.

does that mean that it sends 7bit fader 0 -127 as first

To conclude, the guess I made in previous post seems wrong,

or is maybe CC#32 being sent twice, first as MSB value and then LSB Value ?

the whole string would then be (without touch CC#s)

one would have to use match to get that 3 values and do the math.

Only unknown is relation of MSB and LSB values to calculate.

I mean 4 LSB steps are 0 32 64 96, what are MSB steps to make 0 - 511

Screen shot 2021-02-22 at 9.56.23 AM.png

match above should actually work to detect the string.

that patch I posted is just a guess, it does not really mean it should work
but to maybe help analyse the midi output of that faders.
when you state that you can move fader 1 on motormix sending this to it


why do you write about 4 sequences and also why from top to bottom ?
You mean it is reversed ?
when yellow number is at 0 - then motormix fader is at the top ?
--------------
receiving midi from motormix:
you say that MSB value seems to differ depending on fader movement speed,
I have another guess - there are more messages involved which then
partly get displayed using thresh, but some get dropped when fader moves fast.
One should record real time fader moved slowly from the
bottom to the top into midi file and so capture all that gets sent.
And later analyse the flow.


trying to understand that part you posted from user manual.
"Manual: B0-(00thru07)-MSB-(20thru27)-LSB 
MSB=0 M M M M M M M  
LSB=0 L L 0 0 0 0 0 0 
if one interprets that 2 lists as binary 
MSB= 0 1 1 1 1 1 1 1 1  and LSB= 0 1 1 0 0 0 0 0 0
than that translates into plain text :
MSB range is 0 -127, LSB range is 0 - 96

The position is sent out with 9 bits of accuracy. 

The 2 least  significant bits can be ignored for 7-bit accuracy.

does that mean that it sends 7bit fader  0 -127 as first
followed by MSB and then LSB ?
Why on earth that complication ?

----
To conclude, the guess I made in previous post seems wrong,
order should be 

CC#0 (0-127) CC#32 (0-127) and then UNKNOWN  LSB CC number sending 0 - 96 range...
or is maybe CC#32 being sent twice, first as MSB value and then LSB Value ?
the whole string would then be (without touch CC#s)
176 0 nn 176 32 nn 176 32 nn
one would have to use match to get that 3 values and do the math.
Only unknown is relation of MSB and LSB values to calculate.
I mean 4 LSB steps are 0 32 64 96, what are MSB steps to make 0 - 511
using 0-127 and LSB ?


No, I mean that the fader moves from bottom to top for each of the four (0,32,64,96) 0-127 changes. I hooked up a line 0, 511 10000 to the yellow box so I can see the changes.

The yellow number at the top goes from 0-127 ($1) 4 times for each of the $2 jumps. So $2 changes from 0, then 32, 64, 96. For each one, the fader goes up from 0-127 then repeats with the next $2 change. So over the time it takes the yellow box to go from 0-511, the fader has gone from bottom to top 4 times.

Screen Shot 2021-02-23 at 9.59.53 AM.png

To clarify further, there is no second 0-127. There's only one.

So to be super clear, there's only 2 relevant CCs:

32 (0/32/64/96) — LSB - this is always 2nd

Mapping to 0-511 (if it's possible), can only be done with these. But the issue is the fader only generally outputs 0 or 64, making it more like 255. But there are occasional 32/96 output.

Any other ideas? :) Thanks for all your help, by the way!

@SOURCE AUDIO:
To clarify further, there is no second 0-127. There's only one.

So to be super clear, there's only 2 relevant CCs:
0 (0-127) — MSB - this is always 1st
32 (0/32/64/96) — LSB - this is always 2nd

Mapping to 0-511 (if it's possible), can only be done with these. But the issue is the fader only generally outputs 0 or 64, making it more like 255. But there are occasional 32/96 output.

record that fader moved slowly form zero to the top.

To also be super clear :
record that fader moved slowly form zero to the top.
and post midi file here.


Okay, here's a text file of the midi output sliding fader 1 from bottom to top.

midi_output_from_bottom_to_top.txt

I ask because it does not look as if it was really recorded directly from midiin into seq or similar.

that because there were 7 missing LSB values - that is what I first expected.

A search in forum for motormix shows - you have been posting about it since

many years, so I guess you should in the meantime know few things about it.

Extract from readme file from mmformat and mmparse max objects from JHNO :

"with my motormix, fader values sent with 8-bit precision seem accurate and reliable. however, the values sent in response to fader movement are much less predictable. a smooth and slow movement will usually step through the integer range 2 at a time. sometimes the least significant bit flips, and it skips 3, or rarely, 1. i would be interested to know if your machine fares any better or worse.

if you are curious, watch the raw midi values coming from the motormix. fader data is sent in 3-byte midi messages. the match object is useful for filtering the midi stream.

176 0 nn - most significant bits of fader 0

176 32 nn - 2 least significant bits (i only get one, though - nn is either 0 or 64) 

ignore 176 47 nn and 176 15 nn messages - these are fader "touch" events.

So finally - motormix sends CC0 value twice, followed by CC32 0 and CC32 64 to double the resolution

Can you manage to use 8-bit resolution based on this info ?

How did you record that file ?
I ask because it does not look as if it was really recorded directly from midiin into seq or similar.
that because there were 7 missing LSB values - that is what I first expected.
------
A search in forum for motormix shows - you have been posting about it since
many years, so I guess you should in the meantime know few things about it.

"with my motormix, fader values sent with 8-bit precision seem accurate and reliable. however, the values sent in response to fader movement are much less predictable. a smooth and slow movement will usually step through the integer range 2 at a time. sometimes the least significant bit flips, and it skips 3, or rarely, 1. i would be interested to know if your machine fares any better or worse. 

if you are curious, watch the raw midi values coming from the motormix. fader data is sent in 3-byte midi messages. the match object is useful for filtering the midi stream. 

176 0 nn  -  most significant bits of fader 0
176 32 nn - 2 least significant bits (i only get one, though - nn is either 0 or 64) 
176 1 nn  -  MSb's of fader 1
176 33 nn - LSb's of fader 1

ignore 176 47 nn and 176 15  nn messages - these are fader "touch" events.

jhno"
I still have old PPC max version, tried mmformat and this came out:
176 0 0 176 32 0    = 0
176 0 0 176 32 64  = 1
176 0 1 176 32 0    = 2
176 0 1 176 32 64  = 3
176 0 2 176 32 0    = 4
176 0 2 176 32 64  = 5
... cont.
... cont.
176 0 126 176 32 0    = 252
176 0 126 176 32 64  = 253
176 0 127 176 32 0    = 254
176 0 127 176 32 64  = 255
-----------
So finally - motormix sends CC0 value twice, followed by CC32 0 and CC32 64 to double the resolution
Fader Value 160 = 176 0 80 176 32 0
Fader Value 161 = 176 0 80 176 32 64

Yes, I have been posting about the Motormix for years. :D Been working on it on/off for a long time.

I recorded the midi stream I sent with midiin>midiparse far right midievent outlet.

I wonder if the Motormix isn't sending all the output values, or Max isn't capturing them all. Stefan Tiedje mentioned that possibility in a previous thread from years ago.

My issue is the manual says 9bits are sent out. So I want all 512. I have 8 bits (255) kind of working already, but CC 32 0/64 doesn't alternate consistently, so it's not perfect. It appears to change depending on fader speed.

"To find out what your motormix is actually sending, you can use my Comiditor, which can print the incoming Midi to the Max window. Especially with high resolution controller values this is required, as other tools show only the last received event..."

Yes, I have been posting about the Motormix for years. :D Been working on it on/off for a long time.
I recorded the midi stream I sent with midiin>midiparse far right midievent outlet.

Stefan Tiedje:
"To find out what your motormix is actually sending, you can use my  Comiditor, which can print the incoming Midi to the Max window.  Especially with high resolution controller values this is required, as  other tools show only the last received event..."

You would have to record midi directly from midiin into seq

for 9 bit control range one must receive 512 messages,

using alternating 0 64 for MSB can go only up to 8 bit.

I tried that externals from JHNO, because one of them emulates

output of motormix faders, the way I described it in the last post.

It is also possible that they simply made wrong statement about resolution, would not surprise me.

The position is sent out with 9 bits of accuracy. The 2 least significant bits can be ignored for 7-bit accuracy."

"4.) Fader test. Move the faders, and you should see their position reading on the LCD go from 

 Press the “SHIFT” and “UNDO” switches to end the test."

You would have to record midi directly from midiin into seq
or something else.
for 9 bit control range one must receive 512 messages,
one for each step of resolution.
using alternating 0 64 for MSB can go only up to 8 bit.
------

I tried that externals from JHNO, because one of them emulates
output of motormix faders, the way I described it in the last post.

It is also possible that they simply made wrong statement about resolution, would not surprise me.
In developer Pdf file they state :

"The position is sent out with 9 bits of accuracy. The 2 least significant bits can be ignored for 7-bit accuracy."
under troubleshooting :
"4.) Fader test. Move the faders, and you should see their position reading on the LCD go from 000 to 255. Press the “SHIFT” and “UNDO” switches to end the test."

that does not match


It's true. You may be right. :) Didn't see that in the manual until now. I was really hoping I could get more resolution out of these faders. I've reached out to the creator of the Motormix. Maybe he'll eventually reply and clarify it all...

Anyway, thanks SO MUCH for all your help and patience!

0-511 resolution MSB/LSB midi faders