Thanks Cyrille and Pierre for replying to me.

@Pierre: I am definitely just a novice in pd, and so some of the explanation you sent me seemed quite hard to follow for me :( I did read the Motormix manual myself and found out, like you said, that it outputs 9 bits of information that only 7 need to actually be used to get the fader information, but I've still no idea how to do that. I came across this MIDIvice external for pd with specific support for Motormix but I'm not able to use the makefile in that set of files to create the external correctly. 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)

@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. 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.

I hope you guys (or anyone else) can help me out some more with this.

Thanks! Rishabh

On Wed, Apr 18, 2012 at 4:38 AM, Cyrille Henry ch@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

Le 18/04/2012 06:05, Rishabh Natarajan a écrit :

...

Hi folks,

I'm building a virtual mixer in PD and need to be able to switch between sets of 8 channels. I have a Motormix midi controller and it's connected to pd via Mbox2 (MIDI cables going between Motormix and Mbox2, USB going from Mbox2 to Macbook Pro). Using the ctlin object and 3 number boxes, I can see that pd is able to detect the button presses or fader movements, but I am not able to make head or tail of the values that are showing up. Whether I move a fader up or down seems to just jolt the left most output and once the motion is stopped it comes back to the same value. I guess that only detects the motion of the fader. When I connect it to a Vslider object, the slider moves sometimes and sometimes it doesn't. The middle outlet seems to have the number 47 on and when you move a slider, it shows the value for that particular slider, but comes back to 47 when you stop. When I press any button, nothing lights up on the console (though these are all supposed to light up and I'

ve

...

seen them lit) and now the left most channel shows the value for that button while the 47 just remains.

I need to map this motormix soon, and any help with this will be a godsend.

HELP!!

Thanks, Rishabh

______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list

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@chnry.net
<mailto:ch@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