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 <c...@chnry.net
<mailto:c...@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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
