serialosc 1.2 OSC discovery API

  • hey everyone.
    this is the main new feature of the recently released [[http://post.monome.org/comments.php?DiscussionID=15225|serialosc 1.2a]].

    in addition to the bonjour/zeroconf method for getting information about connected Monomes, there is now a way to get this information over OSC. again, this is a new feature from 1.2 onwards and is not supported in earlier versions, and the zeroconf interface is still available.

    serialosc listens on port 12002 for these requests. they take two arguments, (string) and (integer), to which the response will be sent.

    --------------------------------------------------

    request:
    > /serialosc/list si
    response:
    > /serialosc/device ssi

    the response consists of several OSC messages, each describing one connected Monome. for example:
    > /serialosc/device ssi "m256-019" "monome 256" 19094

    I could then establish a connection by sending the necessary /sys/port and /sys/host commands to port 19094.

    --------------------------------------------------

    request:
    > /serialosc/notify si
    response:
    > /serialosc/add ssi
    > (or)
    > /serialosc/remove ssi

    the response to this command will likely not be immediate. instead, your application will receive either a /serialosc/add or a /serialosc/remove the next time a Monome is connected or disconnected (respectively). the arguments to /add and /remove are the same as the ones for /device (the /list response).

    note:
    /notify will only subscribe your application to the //next// event. after you receive the /add or /remove message, you must re-subscribe with /notify to receive another event. one response per message.

    --------------------------------------------------

    let me know if anything needs clarifying. i'll be writing this up in the wiki as well.
    -w

  • YEAH

    can you tell us the possible responses for "device type"?

  • i'll be making some example max patches for this. supercollider examples on the way as well.

    the major issue this should solve is the fact that windows doesn't do zeroconf very well. and many software environments don't handle zeroconf.

    zeroconf is still supported, however!

  • so just to be sure... zeroconf will not be needededed, assuming patches are written properly using 1.2a

  • yep!
    zeroconf is no longer a prerequisite on windows. on OSX it's bundled with the OS and we get it for free.

    @95:
    yes and no. for pre-varibright and pre-arc devices, you can see a list here:
    https://github.com/monome/libmonome/blob/master/src/private/devices.h (it's the column that goes "monome 64", "monome 128", etc).

    for varibright and arc devices, we get the device name from the device itself, and there's no list of those unfortunately.

  • Rad! I feel kinda liberated that I don't have to write bonjour port resolution code into my monome apps anymore.

  • Does this mean it might be possible to 'fool' serialosc into seeing an arduinome or even mk w/encoders as an arc if it can send the right OSC messages for delta? It would be nice, even if it's not going to get the led feedback to be able to roughly emulate or use some of these arc apps.

  • @shimoda:
    i don't follow.

    > 'fool' serialosc into seeing an arduinome or even mk w/encoders as an arc if it can send the right OSC messages

    if //what//, specifically, can send the right OSC messages? i also don't see how this applies to the discovery API.

  • Sorry, perhaps I'm phrasing this wrong. The mk kit had an encoder expansion that could send the same data as an arc, but would be sending it from the /mk device identifier. 'If what' refers to the mk device/arduinome. I'm probably asking this in the wrong place and it may be an issue of whether I can write a max patch that reads those encoder messages and sends them as arc messages to some modified serialosc.maxpat. Sorry, not trying to confuse.

  • @visinin - ah, gotcha. i'm wondering if it's possible to reliably detect the size (and non-arcyness) of a grid when we find it. it seems like libmonome might already do this.. but i can't tell, and I don't know where to look.

    not to be ungrateful though! auto-discovery is huge. i've been holding off on releasing chuck stuff because manually finding ports is super lame. like most stuff with coding though, as soon as one thing can be done, you wonder if you can do something else.

  • this is great!

    will post up my max abstraction/example if anyone is interested.

  • here's the abstraction i'm using and an example patch.

    i'm using it in m4l so there's a pattrstorage in the abstraction that would normally store your device id and settings with the live set. so you might have to go in and edit the initial value of the deviceid ui textedit object if you want it to automatically connect to your device when opened in normal max.

    !--- edit ---!
    first version had a problem with the prefix so it wouldn't work with any prefix other than monome. should be fixed in v2 download although i'm not at my monome to test things out at the minute.
    !------------!

  • edited version of the patch above to fix a bug with changing the prefix.

  • was having some weird issues with v2.

    the patch worked fine when opened in plain max. but when loaded in m4l it couldn't connect, it was a timing issue where the patch wasn't receiving the connected device info from the discovery api quick enough. i had used a deferlow object, which worked in max, but had to change it to a "delay 100" object which seems to have done the job.

    included in my post above is a download for v3.

    however, it got me thinking a done or finish message for the list request might be useful.

    so after the last device had been sent it could send: /serialosc/device done

    what do you think?

  • @myr:
    hm, or what about sending the reply as a bundle? how would that work for you?

    i.e. instead of a bunch of discrete messages, they would all be sent as one big bundle.

  • eh, more i think about it, less a bundle makes sense.

    is anybody else running into the issue myr is? would a "termination" message after a /serialosc/list be beneficial?

  • hey visinin,

    doing a bit more work finalising my serialosc patches for arc and monome.

    have you heard of anyone else wanting a "termination" message once the response from /serialosc/list is done?

    i still think it'd be a very useful addition and hope it wouldn't be too much work to implement.

  • well, this is the process i'm using in my serialosc abstraction:

    -on click of connect button (or load) generate random port number for app to receive on
    -check if free with ping and confirm message, if free send port on to relevant max objects
    -send serialosc/list message to get current devices
    (current problem area)
    -then check if stored device id (value stored with patch, updated whenever a device is selected in drop down menu of current devices) is one of the currently connected devices, if so send prefix, port and host messages to establish connection.

    so at the moment it seems max4live isn't receiving the currently connected device list from serialosc before it moves on and tries to check the stored device id against the currently connnected device list.

    hence why i've had to try deferlow and delay objects, which do work so far but, as you've said raja, isn't solid or good programming practice.

    if there was a "termination" message, for example /serialosc/device done, then i could wait till i've received that message before continuing on with the program. thus solving the problem :).

  • i use two monomes and an arc. for each i have an instance of my serialosc abstraction, each inside a different m4l app.

    if i set the serialosc abstraction up to automatically connect to whatever monome device is available when it's opened then the wrong device could get connected to the wrong app.

    with my abstraction it remembers the device id of the device you last connected to so that when i load up my apps each one connects to the right monome device.

    it also means that i can check if an added or removed device matches the stored device id, so it automatically reconnects an app if the usb cable accidently gets knocked out and put back in again.

    also, i haven't checked yet, but i don't think the problem is really to do with checking the device id per se. for instance what if after sending the list message instead of checking against a pre stored device id you wanted to get the port and connect to the first monome grid device available, checking it wasn't an arc by checking it's name. in m4l you'd still have to be using a delay object because you can't be sure the list of monome devices will have arrived before the program moves to the next step of trying to connect to one of them.

  • " you can't be sure the list of monome devices will have arrived before the program moves to the next step of trying to connect to one of them. "

    I have this on my list of possible issues for the 1.2a serialosc...
    but there's no way to tell (that I know of), no logging mode.

    not saying that this is the issue, just flying blind.

  • here's the latest version i've got of my serialosc patch. this one's a plain max version, and requires max 6.

    only had a quick check through it as i can't remember if i broke anything last time i worked on it, and it's pretty late here and i really should be asleep not patching, heh.

    hopefully you'll get the gist though raja, it's a bit messier than i'd like still a bit of work to be done.

  • woahhh!!

    just checked out your patch Myr and it's a pretty mammoth effort - congrats! i've been working on something similar (yet far simpler) for mlrv which simply stores and recalls the device that was attached when the preset file was saved by the user.

    just wanted to say thanks for this patch though as it's helped me better understand the way zeroconf-less serialosc patch works, and also clued me into a couple great new max6 objects (eg. dict and routepass). thanks!

  • thanks galapagoose! glad you found it of some use. haven't had much time to work on it since but i'll be posting up a new max and m4l version soon.

    i've stopped having the port randomly generated so there's no delay or deferlow objects needed at all. super quick. although it does seem to be causing some issues with the device list receiving many copies of the same device.

    i've exposed the port the device sends to in the ui, and you can see what port the selected device receives on, so you should be able to use an instance of this to connect to old monome serial style apps.

  • Well damn, I really should try and browse the forum more often...

    I just put together a zeroconf client in Clojure, using jmDNS:

    https://github.com/cassiel/clojure-zeroconf

    It does seem a little flakey (at least under OS X and Linux). I'm not sure it's the fault of serialosc: my network browser on the iPad generally sees all the monomes while the jmDNS code often doesn't, without relaunching the query thread a few times.

    Certainly, discovery takes a while: jmDNS uses a callback for initial discovery and for getting additional information (host and port) for entries which have been discovered.

    Anyway, I'll add a shim for the 12002 port feature. Obviously, it doesn't help with discovery of devices on different hosts, but I guess if any host reports at least one device, then I can attach to port 12002 on that host to get a definitive list of any others.