Monome Emulation
I'm starting to pick away at ideas for Monome emulation in Usine. It seems in theory that it should be quite easy but I'm sure I will need some help so I will keep it all in one thread.
To start I am looking to get proper communication between Usine and Molar VSTI http://xferrecords.com/molar/MolarPC.zip
From the 'Monome' or Usine is this case is really quite simple. All Usine has to do is send momentary (while the pad is held down) messages as /256/press x x x on port 8000. This translates as data 1=column (left to right) position, data 2=row (top to bottom) position and data 3=pad state on/off. Pressed=on, released=off.
All other 'visual feedback' is handled by the software that the Monome is controlling. In the case of Molar, the only messages that I am aware of that are sent (port 8080) are /256/led x x x and 256/clear x - -
The first problem I need to resolve before anything can happen is that Molar (and many apps) sends multiple /led messages at the same time on various columns, rows and 'cells' and the OSC Receive module does not seem to accomodate 'unpacking' multiple simultanious messages so how can I receive multiple simultanious messages?
I am using this OSC monitor as reference and it registered simultanious messages just fine: http://www.frieder-weiss.de/OSC/OSCMonitor.zip
In case interested, the MonomeSeial OSC protocol is here: http://docs.monome.org/doku.php?id=tech:protocol:osc
To start I am looking to get proper communication between Usine and Molar VSTI http://xferrecords.com/molar/MolarPC.zip
From the 'Monome' or Usine is this case is really quite simple. All Usine has to do is send momentary (while the pad is held down) messages as /256/press x x x on port 8000. This translates as data 1=column (left to right) position, data 2=row (top to bottom) position and data 3=pad state on/off. Pressed=on, released=off.
All other 'visual feedback' is handled by the software that the Monome is controlling. In the case of Molar, the only messages that I am aware of that are sent (port 8080) are /256/led x x x and 256/clear x - -
The first problem I need to resolve before anything can happen is that Molar (and many apps) sends multiple /led messages at the same time on various columns, rows and 'cells' and the OSC Receive module does not seem to accomodate 'unpacking' multiple simultanious messages so how can I receive multiple simultanious messages?
I am using this OSC monitor as reference and it registered simultanious messages just fine: http://www.frieder-weiss.de/OSC/OSCMonitor.zip
In case interested, the MonomeSeial OSC protocol is here: http://docs.monome.org/doku.php?id=tech:protocol:osc
from my tries on liveOsc, when dealing with multiples data, i get better results receiving a 'block' of datas using ie a osc receiveX64 where each field is filled with the datas one after the other like XYZXYZXYZ one shot. don't know how it works on monome stuff but on liveosc script there are often booth ways, a single adress, wich is better for a single refresh/update and block, wich seems more adapted to update lot one shot. ie i on a monome pressing one cell is better dealt with single, asking a 'page' of cellz to update is better as a block. when message is single but lot at same time on same adress it unpacks, but seems can get dropouts like midi but im pretty sure can send receive more than 16 datas at the same time, wich is more than our hands can trig, it can be a pb however if sending 256 status to update , can't /don't the app send block of datas on a different adress on requests instead?
it semms it use as well whole column block update:
in my case often got as exemple a 'single' 4x send/receive module
1)track X 2)Clip Y 3)status 4) length
and if i request a colum i will get , for a 8xcol, 32 datas in osc32receive (T,C,S,L,T,C,S,L...ect).
are there adresses dealing with such 'block'? when you look at the console do you se only single(several lines) or blocks?
[iiiiiiiiii]
it semms it use as well whole column block update:
Code: Select all
/40h/led_col [col] [data0] [data1] [data2] ...
sets more than one byte of a column, referenced from the beginning of the column. variable byte count allowed, for spanning multiple units.1)track X 2)Clip Y 3)status 4) length
and if i request a colum i will get , for a 8xcol, 32 datas in osc32receive (T,C,S,L,T,C,S,L...ect).
are there adresses dealing with such 'block'? when you look at the console do you se only single(several lines) or blocks?
[iiiiiiiiii]
I don't think Molar is using 'block'. If I set two pads to blink on and off in Molar, here is what the console shows for one time 'off' then 'on'
[116144] OSC from 127.0.0.1 : /256/led (iii)
[116145] OSC from 127.0.0.1 : /256/led (iii)
[116146] OSC from 127.0.0.1 : /256/led (iii)
[116147] OSC from 127.0.0.1 : /256/led (iii)
[116144] OSC from 127.0.0.1 : /256/led (iii)
[116145] OSC from 127.0.0.1 : /256/led (iii)
[116146] OSC from 127.0.0.1 : /256/led (iii)
[116147] OSC from 127.0.0.1 : /256/led (iii)
ok and when do you get dropouts?
if you keep on tracing osc in and check the console you don't catch all datas?
if you keep on tracing osc in and check the console you don't catch all datas?
I am not noticing any dropouts in the console yet. The problem is is how do I receive multiple datas all at once from the same address if it is not sent as a block? Perhaps a script could convert the messages to block format?
Or am I doing something terribly wrong... is there a way to further specify which chunk of data the OSC receive module gets other than as set by the basic address? My receive address is currently /256/led
Or am I doing something terribly wrong... is there a way to further specify which chunk of data the OSC receive module gets other than as set by the basic address? My receive address is currently /256/led
no i think you're doing ok, the data will be received one after the other, the next step is to store it in array or dispatch.
depends on what's your target next, i suppose an array to feed matrix?
you can by patch use ie a dispatcher and spread the received data or use setArrayelement but be aware
dealing such XY matrix will soon become a pain at patch level,if want ie set a row on shot, where scripting suit nicely.
( if you want dive into that's a perfect introduction to deal with, the same that lead me in with live mx).
but if you wanna test first by patch, that stills allow many possibilities, need then to use setArray.
so in order 1)create an array, set is size, then set it's elements values = received onoff, XY will define indexes.
if it's targeted at Matrix, the best is to use same index system as matrix. from top left to bottom right.
so if you use the setArray, setting at the index = (Xcol+(Yine*NB_cols) the onoff values and feed matrix, it will be correctly mapped.
it look like this, assuming data1 is Xcol, data2 Yline,data3 Zonoff:

depends on what's your target next, i suppose an array to feed matrix?
you can by patch use ie a dispatcher and spread the received data or use setArrayelement but be aware
dealing such XY matrix will soon become a pain at patch level,if want ie set a row on shot, where scripting suit nicely.
( if you want dive into that's a perfect introduction to deal with, the same that lead me in with live mx).
but if you wanna test first by patch, that stills allow many possibilities, need then to use setArray.
so in order 1)create an array, set is size, then set it's elements values = received onoff, XY will define indexes.
if it's targeted at Matrix, the best is to use same index system as matrix. from top left to bottom right.
so if you use the setArray, setting at the index = (Xcol+(Yine*NB_cols) the onoff values and feed matrix, it will be correctly mapped.
it look like this, assuming data1 is Xcol, data2 Yline,data3 Zonoff:

Well that's a step in the right direction. I have no idea why that works but it does sort of. 1 and 0 are swapped except on the last column and it only works with three rows at a time and then gets really eratic.
So much for quite easy... eta next spring!
So much for quite easy... eta next spring!
cool. yup that one advantage of osc over midi, XY stuff is quite easy to deal with and stings also,
that 's what i felt unpacking to much data has some limits, but strange that it is inverte...d, a not to invert can do the job
normally but here i receive correctly maybe set the setvalue always active via a swich.
that 's what i felt unpacking to much data has some limits, but strange that it is inverte...d, a not to invert can do the job
normally but here i receive correctly maybe set the setvalue always active via a swich.
Hmmm... maybe I should instead focus on making some Monome controlled applications in Usine.
Probably more usefull at the moment as a Monome emulator is less than usefull without at least a dual touch screen.
I don't even have a dual touch to test with...
flip-flop!
Probably more usefull at the moment as a Monome emulator is less than usefull without at least a dual touch screen.
I don't even have a dual touch to test with...
flip-flop!
You've got a monome gurulogic?maybe I should instead focus on making some Monome controlled applications in Usine.
Seb.Dub
yes, I have two 128's which I usually use as a 256.
Not to take all of the fun out of countless hours of patching but if the matrix had the built in ability to send and receive OSC it would instantly be the perfect Monome emulator. The stucture is already more or less identical.
Funny, because i've started an emulation of mlrV to use with a launchpad. Will be a big patch, so there is yet lot of work...yes, I have two 128's which I usually use as a 256.
What kind of Osc message send a pad on a monome?
Osc=>Matrix and Matrix=>Osc might be doable, no?
Seb.Dub
All that is sent from the Monome via Monomeserial or similar is
/40h/press [x] [y] [state]
state: 1 (down) or 0 (up
(or /128/press /256/ press depending on which size Monome)
The full Monome OSC protocal is here. http://docs.monome.org/doku.php?id=tech:protocol:osc
Pretty basic really. Seems like it should be easy to adapt in Usine, but a bit more complex to unpack multiple messages received at the same time in the OSC receive module. Osc=>Matrix and Matrix=>Osc is fully possible with some clever patching,
I'm sure you've seen this? http://post.monome.org/comments.php?DiscussionID=6245
/40h/press [x] [y] [state]
state: 1 (down) or 0 (up
(or /128/press /256/ press depending on which size Monome)
The full Monome OSC protocal is here. http://docs.monome.org/doku.php?id=tech:protocol:osc
Pretty basic really. Seems like it should be easy to adapt in Usine, but a bit more complex to unpack multiple messages received at the same time in the OSC receive module. Osc=>Matrix and Matrix=>Osc is fully possible with some clever patching,
I'm sure you've seen this? http://post.monome.org/comments.php?DiscussionID=6245
what about making a patch with 8x8 matrix (extendabe to 16x8 or more) Usine MLR beeing able to run stand alone with matrix
and then the patch can also be bidirectional remotely contollled by either Monome or launchpad via osc /midi?
that would make 3shots in one go, also each one has his own wanted features, a common core can be found maybe...
and then the patch can also be bidirectional remotely contollled by either Monome or launchpad via osc /midi?
that would make 3shots in one go, also each one has his own wanted features, a common core can be found maybe...
I had a look to the monome forum before starting to make an mlrV patch. So yes, i've tested nonome...
How do you receive multiple message at the same time?
Do you mean with this kind of message:
/40h/led_col 2 255
How do you receive multiple message at the same time?
Do you mean with this kind of message:
/40h/led_col 2 255
Seb.Dub
Good idea 23fx23, but would need a collaborative work, because i haven't got a monome.....
I've nearly found a good way (light on cpu and stable
) to control the matrix within the launchpad like in mlrV...but it would need some modification to run the matrix in standalone...
I will think about it, because the patch won't be ready before, let say one or two months...
I've nearly found a good way (light on cpu and stable
I will think about it, because the patch won't be ready before, let say one or two months...
Seb.Dub
You don't necessarily need a Monome to develope a Monome compatable app. One example would be to use Serial-Pyio ( https://sourceforge.net/projects/serial-pyio/files/ ) which includes a virtual Monome.
If you open Serial-Pyio, select Device> Add virtual device you can create a 'test Monome' Ctrl click or Ctrl drag simulates multiple pad presses and fully controls the Monome app, which in the example below is Molar running in Usine.
That being said, I would be happy to help wherever I can...

If you open Serial-Pyio, select Device> Add virtual device you can create a 'test Monome' Ctrl click or Ctrl drag simulates multiple pad presses and fully controls the Monome app, which in the example below is Molar running in Usine.
That being said, I would be happy to help wherever I can...
I'm building myself an arduinome at the moment for controlling Usine with so it would be great to see some monome patches being released. It would help give me a headstart on learning Usine and OSC in more detail 
Who is online
Users browsing this forum: No registered users and 28 guests
