how would i go about sending OSC messages from a monome app to a vj program (VDMX for instance) from a MAX patch? i just want a 1 or 0 from each button on the grid… this means i can send triggers to use in audiovisual work. at the mo i’m converting MIDI notes from polygome back into OSC but i’d prefer to do it from the source. i’d use the cnmat osc externals i’m guessing and send them to the right port on localhost.
The serialosc protocol is documented here: https://monome.org/docs/osc/
You might also find this helpful: https://monome.org/docs/grid-studies/max/
1 Like
i wanted a quick solution - like where i would conenct a simple osc out to get what i want. but you knew that, right?
Yeah, OSC is extremely flexible (and therefore not all that simple).
1 Like
tell your program to listen for /grid/key messages. these msgs have three arguments which are x, y, state.
if you want other messages from serialosc look at the first link above.
you have to also make sure serialosc and your program are using the same network port. if you can’t set the port in your program then find out what it needs and set the port on serialosc.
I don’t know how to tell your program to listen to arbitrary OSC messages. if there’s no way to do this then it’s not really a general OSC client.
thanks for that info. more practically if were to be formatting osc messages to hit a control surface in vdmx like this
say i’m using polygome, where in the patch would i send osc out on localhost for instance…
i’m sorry but I don’t know anything about how vdmx works. I doubt anyone else here does either. I would look on vmdx forum for more detail about mapping OSC.
oh I guess you did say “from a monome app.” then i guess what you want to know is how to send OSC from max
but you also said
i just want a 1 or 0 from each button on the grid
which means, to me, just get the messages from serialosc
there’s no such thing as “serialOSC” vs “normal OSC”. OSC messages are arbitrary strings with arbitrary data payloads attached to them, and serialosc uses a certain defined set of strings and payloads.
so i guess what i’m asking is, how do i format the messages from a monome patch to use in other stuff? just the lights output.
i can sort the accepting end no problem. i can send osc from max to a thing no problem. but how do i specifically route messages that would go to the monome grid, elsewhere?
ah ok, so if you want grab the set-LED messages then listen to /grid/led/set which also has three arguments, and is, of course, also on the serialosc reference page.
if you want to know all the commands used by serialosc, look at the reference page, Jason’s first link. there is nothing else to know about serialosc message formats and the reference page is clearly written.
if you have more general questions about OSC, then go to Jason’s second link.
1 Like
great. which port is serialosc going out on if i want to echo it out of my own osc sender? or which part of the patcher do i connect to?
port numbers are discussed in literally the first paragraph of the damn reference page which i am linking here again
so if i’m being lazy for not reading it, then you are (both) being lazy for not reading it out to me. 
i prefer human interaction…
and your advice is much appreciated
Thing is, this is a forum. So you’re reading either way. Good luck!
by default serialoscd listens on port 12002 and sends to port 8000. but of course the idea is that the user should be able to specify the application port. so there is a whole series of OSC commands to set and query the port. these too are in the reference page, so please for the love of god please look at it.
/sys/port i <port> - change serialosc rx port
/sys/host s <host> - change serialosc tx port
and in fairness, serialosc could probably do with a general FAQ in addition to the environment-specific setup guides and studies.
1 Like
agreed. a serialosc howto has been on my list for a couple years now, continues to get pushed down and most people sufficiently get started just by checking out the existing serialosc libraries, ie, via the grid studies.
but a concise demonstration of device negotiation would be good. i’ll bump it up on my list…
1 Like