[PD] MotorMix to PD

[pvallet]

Le 19/04/2012 02:52, Rishabh Natarajan a écrit :
> I've realized that with any fader on the motormix, the values being
> transmitted via ctlin to pd vary between 0, 64 and 96 and they mainly
> keep jumping between 0 and 64, even if you are only moving upwards. It
> only touches 96 once you get the fader to the very top.
>

This means you only catch the 2 Last bits of the slider value
(ctl number hex20 to hex27 or, as you say, 32 onwards in decimal.)
cf. https://en.wikipedia.org/wiki/Least_significant_bit

Quoting the book, the message is transmitted as: (in hexadecimal)
FADER (1 thru 8)
     B0-(00thru07)-MSB-(20thru27)-LSB
     MSB=0 M M M M M M M LSB=0 L L 0 0 0 0 0

So you can use (or can you?) Ctlin 0 to 7 to get a coarse (7 bits) info 
for the slider position.

or add ctl(0) value with ( ctl(32) value >>5 ) to get the full 9-bit data.
">>5" means: shift the bits  five places to the right, then you get 4 
possible values  (Some binary calculus awareness definitely helps here)

  Also, there is an
>     object written for Max to again deal specifically with the Motormix.
>     Is there any way to get this object to work with pd? (Perhaps along
>     the line of the cyclone library which holds most of Max's objects)

herm, not really as this seems a compiled external for max so you'd have 
to reimplement it

>
>     @Cyrille:I will try the print object to see all the other values
>     coming out from moving the Motormix fader. I found that the faders
>     started from number 32 onwards, but I'm not sure which of the
>     ctlin's outlets to connect to the vslider in the patch. I created an
>     object ctlin with argument 32 and then connected the leftmost outlet
>     to the first vslider. With every movement of the Motormix fader, the
>     vslider kept jumping positions but either went back to it's lowest
>     value or just stuck to some other value. It never moved along with
>     the motormix fader.

cf. supra for the explanation

As for getting the motor to move the faders
>     using ctlout, I've not got to that stage yet but hopefully with your
>     advice, I will be able to achieve the movement.
>
Yes, on the paper it should work.

47 is 2F in hexadecimal, you could use the tech. manual to find where it 
happens. (in many places really).

I'm afraid that you won't escape the task of interpreting and 
reconstructing composite midi messages in some places, like Cyrille 
showed for midiout messages. Could someone point to useful objects that 
can be used for accumulating / packing / parsing variable-length MIDI 
messages? as my pd knowledge of objects out there is a bit limited i 
have to say.

Warm regards,
Pierre.
>
>     On Wed, Apr 18, 2012 at 4:38 AM, Cyrille Henry <ch at chnry.net
>     <mailto:ch at chnry.net>> wrote:
>
>         hello,
>
>         message 47 i probably a fader release information.
>         using print better than number you'll see that it's not the only
>         message you are receiving.
>
>         fitering all information to have only fader movement is easy :
>         a "ctlin 0" object should output value of the 1st linear fader.
>         "ctlin 1" the 2nd etc
>
>         "ctlin 64" ... "ctlin 71" output rotation speed of the rotative
>         fader (they did not output an absolute value)
>
>         for the toggle, it's a bit more tricky: you have to use 2 ctlin
>         objects :
>         i used :
>         ctlin 47        ctlin 15
>         pack f f
>         route 66
>         sel 0 1 2 3 4 5 6 7
>
>         in order to select press information from 1 raw of toggle.
>         the other raw should be almost similar.
>
>         To move the fader thanks to the motor, you have to send 2 ctlout
>         information.
>         using midiout, you can send a message like : "176 0 $1 176 32 0"
>         i.e. sending value to ctlout 0, then sending 0 to ctlout 32.
>
>
>         toggle did not light on, because they can light in different
>         colour, you have to light them up manually.
>         to light up a specific toggle i used
>         "176 12 0 176 44 $1" where $1 value is 2 or 66, for 1st column
>         fader,
>         using 176 12 1 for 2nd column etc.
>         i think 44 can be changed to address other raw, ans the $1 value
>         for the color.
>
>         i don't have any motor mix since many many years, so can't help
>         more, but all can be made using simple ctlout. exapt display
>         text on the screen that need sysex messages.
>
>         cheers
>         cyrille
>
>
>

>  --------------------------------------( re-quoting my previous answer: )

Hi,
>
> Not sure if i understand you fully (don't own a motormix) and if you're an expert with PD (which i'm definitely not) but
>
> From a quick glance at the MIDI implementation from the MotorMix v 1.2 Developer pkg3.pdf on CMLabs web site I see this:
>
> FADER (1 thru 8)
>     B0-(00thru07)-MSB-(20thru27)-LSB
>     MSB=0 M M M M M M M LSB=0 L L 0 0 0 0 0
>
> meaning that the faders values are transmitted in two parts to get 9-bit precision.(512 values).
 >To reconstruct the nine bits you'll need to write a specific catcher 
with midiin or possibly sysexin.
> MSBs (most significant bits) are attached to controller numbers 0 to 7 and LSB (lower significant bits)
> are attached to numbers 20 to 27. but these are not transmitted as an independant Controller Change (B0)
> message. You might get away with just catching the first 7 bits(128 values) with ctlin though.
> If you can catch the LSB you'll need to >> (shift right) 5 places then add this value to the MSBs.
>
> as for other controllers:

> ROTARY 1-8
>     B0-(40thru47)-VALUE
>     VALUE = 0 s r r r r r r
>     s=1=clockwise    r r r r r r = rotation size
> ENCODER (rotate)    B0-48-VALUE
>     VALUE = 0 s r r r r r r
>     s=1=clockwise    r r r r r r = rotation size

You'll likewise have to perform some operations to get the final value, 
here for example substracting 64 (or 0 1 0 0 0 0 0 0 in binary) whould 
give you a range of signed values from -63 to 64


>
> Best regards,
>
> ----
> Pierre