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