monome home - a serialosc device manager

  • monome home collects information about all of the serialosc devices currently connected to your computer and displays it in a simple device list.

    you can click on one of the displayed devices to select it and allow editing of its serialosc settings i.e host, port, prefix, rotation, tilt.

    also provided is a simple testing section to check key presses and encoder deltas, and to test grid and ring leds.

    requires serialosc 1.2 or above and max 6 or above. (zeroconf/bonjour is not used, so you do not need the externals installed in max)

    --- update ---
    r2 - noticed a few simple errors
    r3 - forgot to resize patch window

  • great! will take a look.

  • just fixed a few quick errors and attached version 2 to the first post.

    the code still needs a bit of tidying up but i think all the main functionality is there so wanted to get it out for testing.

    my next plan was to further develop and finish a routing, spanning, setup preset app. however, building this got me thinking.

    the way the current serialosc.maxpat patches work they effectively totally take over control of the selected device, stopping it from talking to any other apps by randomly changing the port and setting the prefix.

    when zeroconf looked like an option for all systems this was workable as routing/spanning apps could announce themselves and be picked up by other apps in the serialosc.maxpat drop down menu.

    with the serialosc device api over osc only physical devices show up (which is awesome!) so we need a new way of allowing intermediary applications to be selected and focused on.

    i think there needs to be a discussion on how these intermediary applications should talk and how they can be picked up in a serialosc.maxpat and used as if they were physical devices.

    i don't think it would be good to have lots of different serialosc.maxpat versions, some which just connect to devices, some which connect to someone's personal router software, some that work with spanning etc, and having to keep track of which one was in which version of the application. could end up like a bit of a headache, which was how some m4l app development was getting when there was the "auto-config", "auto-focus" and "standard connection" to incorporate into every app.

    good idea?

  • i like this patch a lot. i think it is great. have no problems at all with v3 so far.

  • glad you're liking it! it's proving pretty useful for me, lets you quickly test programming ideas without using a serialosc.maxpat.

    also allows you to use old monomeserial applications easily. just change the send and receive ports of the monomeserial application to the send and receive ports listed in the monome home device list.

  • added an app page to the docs:

    any updated versions will likely be posted up there from now on.

  • Very well done, Sir.
    Just gave it a quick test, and everything seems to run fine so far.
    Couldn´t stop to stare at the vari-bright map-test. pure vari-bright beautyness.

  • solid bump on this, this is a good discussion and relevant to the monome emu thread going on (also looks like a sweet app!)

    i would totally like to see a way to add virtual devices to the new discovery mechanism. i have a few possibilities to throw out here in the interest of sparking discussion:

    * serialosc itself could have a mechanism to register virtual devices -- this could be messy if apps crash and/or don't clean up!

    * serialosc.maxpat could listen for discovery messages on an assigned port -- seems reasonable as long as you only need one "process" listening on the port (max can share the port across patches so you could still have multiple instances of serialosc.maxpat..right? pretty sure that's right). this could be an issue if max proper and m4l are running at the same time (does that happen much?)

    * a range of ports could be 'reserved' for other apps that can respond w/ discovery messages. 12002 is serialosc's assigned port for this, what if the patch simply iterated over a range of ports, say 12002 - 12006, and collected all responses in a global list? that seems like a really simple modification and is kind of an intriguing idea.

    * screw it, zeroconf isn't that bad! i don't think we're going here though :) it is nice that it still works though.

    * other crazy shit

  • lol! that one was thrown in for fun :) but i hear you dude, there has to be a good middle ground here, if that means no zeroconf i'm fine with that. so far i kind of lean towards the 3rd option, seems easy enough to try it out at least. i'll have to find some time to experiment.

  • having a think, first time in a while on this topic.

    ideally serialosc itself would have a mechanism built in for virtual devices. but then how far should it go, if it's letting you create virtual devices shouldn't it do some of the routing and spanning, then maybe it should do presets, by then it would really need a graphical user interface. if it's gone that far then maybe it should just be a one stop shop for grids and have built in launchpad, livid, push and apc emulation.

    one day i think i'd like to see that kind of app. sounds like pages is nearly getting there though :)

    but yeah, really like that third idea. so...

    - there's the serialosc server that listens on port 12002.

    - there's the real devices that serialosc creates, one static receive port for each device, which we assume lasts for the life of the device, but could be different next time.

    - then we create router/spanner/preset apps, like pages, which would generate a free port number from 12003 - 12010 on open, and then listen for requests for devices like serialosc server. when receiving a request they would send out lists of device info on all the virtual devices that they have created for routing/spanning.

    - the virtual devices created by any routing/spanning apps would each generate their own port number to receive messages on, which would stay static for the life of the device, much like serialosc creates devices with a static receive port. the virtual device would respond to send port and prefix changes, allowing it to work with serialosc.maxpat (if serialosc.maxpat let the virtual devices appear in its list of course).

    - any monome app would need to have a kind of serialosc.maxpat. it would get the real devices from serialosc server on 12002, it would then iterate through ports 12003 - 12010 getting info from any routing/spanning/preset apps. it would let the user of the app select between any of the real and virtual devices, and set the send port of the virtual device to match its app receive port on connection.

    is that the gist of what you guys were thinking? or have i got it totally warped? heh

  • so some thoughts that pop up.

    is reserving ports 12003 - 12010 for virtual device servers ok? i really have no idea about how ports get allocated or if another program might use them at some point. would 8 be enough? i think it would when each port can be its own virtual device server. hard to think of needing more than 8 sets of virtual devices.

    should virtual device servers, such as a routing/spanning/preset app, or pages, respond exactly the same as the serialosc server? should any monome app be able to tell they are different? should they have any extra standard methods or functions that it might be useful to define early so we can all implement?

    if virtual device servers are going to respond just like the real serialosc device server then they need to provide sensible device type, device id, and device port info when requested to. especially if monome apps using serialosc.maxpat are going to use the device id as a way to autoconnect to the device when the monome app is opened.

    should virtual devices behave exactly like real devices? if so, how should they generate a useful device id which can be used to autoconnect to. they'd also need to have a device type, which i guess could depend on the type of virtual device created, wether it's a virtual grid or arc, if it's vari-bright or not. they'd also need to send out size information like a real device, and also respond to rotation and tilt.

  • no you've totally got it!

    "is reserving ports 12003 - 12010 for virtual device servers ok?"

    there are definitely some standard ports out there that should be avoided but i think that range is safe enough. my /etc/services file says port 12002 is "reserved" for:

    entexthigh 12002/udp # IBM Enterprise Extender SNA COS High Priority

    although it also says:

    # 12110-12171 Unassigned

    that might be a better range? i think in practice though the 12002-12010 range should be fine and having them continuous makes life a little bit easier.

    "would 8 be enough?"

    seems like a pretty good start at least! and really it's more like each routing app takes up a port, the app could create multiple devices and you'd still only be using one port in that 12002-12010 range.

    "should virtual device servers, such as a routing/spanning/preset app, or pages, respond exactly the same as the serialosc server? should any monome app be able to tell they are different? should they have any extra standard methods or functions that it might be useful to define early so we can all implement?"

    i think it's reasonable to expect them to behave like serialosc at a minumum, yes. a sort of standard way to communicate extra features could be workable, if no response comes then it's assumed the feature isn't there. say for example if setting up spanning over osc was a feature, it might respond back with a /feature/spanning message and have corresponding api calls. app developers could get together and try to come up with standard osc protocols for these features. i think these things can develop organically.

    "should virtual devices behave exactly like real devices?"

    this is all true, many apps will rely on these messages and features (although not all). it's not an easy task to reimplement the serialosc server protocol but that's essentially what's needed (this is how pages works as well). i think there's probably a bare minimum that can be implemented that will work with most applications, but to me this is more up to individual developer discretion.

  • reimplementing /sys/* stuff is not that hard. and while i don't want to raise the old issues, i still support zeroconf which is a well-designed, lean tech that does its work (not to mention network transparency, blah blah).

    while it works for me, from what i heard the problem with zeroconf is buggy implementations in max and pd (and no implementation in sc3, iirc). but c'mon, pages, griddle and all the emulators are well-behaved citizens of the monome world and killing zeroconf will bring a lot of problems with less than optimal solutions for those apps.

    one solution that i can think of is implementing the osc discovery mechanism on top of zeroconf - something like a plugin inside serialosc itself that simply exposes whatever is found by the bonjour service browser under the _monome_osc._udp category.

    that makes serialosc:

    1) a bonjour client, that looks out for emulators/pages/spanners out there;
    2) a bonjour server that advertises all the hardware on the zeroconf bus (just like now);
    3) a middleware layer that exposes things from points 1 and 2 for the osc-expecting software on port 12002 plus the notify/add/remove messages.

    looks elegant enough to me. your thoughts, guys?

  • if someone could rebuild the max zeroconf externals for 64bit i'd gladly go for zeroconf.

    the more i think about it having virtual devices be able to broadcast their own existence over zeroconf seems more elegant.

    building a router/spanner app with no zeroconf but using phortran's 3rd suggestion would allow you to broadcast your own virtual devices but you wouldn't be able to see any applications. you'd have to rely on each monome app to select a virtual device in its dropdown menu. thinking about building the app it'd be much better to be able to see monome apps via zeroconf. also to be able to broadcast virtual devices over zeroconf.

    what were the zeroconf conventions for monome?

    was it "_monome_osc._udp" for devices? and something else for applications?

    also the serialosc.maxpat would have to be modified to check the extra ports 12003 through 12010. if you wanted to properly implement the virtual device servers then you'd want them sending device/remove and device/add messages as well. to do this the new serialosc.maxpat would need 8 extra udpreceive objects.

  • raja, phortran's 3rd suggestion requires yet another upgrade in the lower house - max, pd, supercollider, chuck, etc. all will have to be updated for multi-port polling.

    plus we lose another awesome use-case here - when a monome is connected to another computer, it still shows up in zeroconf. this is a huge benefit for apps like android emulators on phones, that are not even connected physically to the pc.

    myr, "_monome_osc._udp" is the service type for devices. applications don't normally need to register themselves on the bus.

  • thinking it through i realised it'd be better to have the monome apps broadcasting their presence for the router/spanner to pick up. you'd then need to modify serialosc.maxpat and maybe reserve some more ports for apps to broadcast on, and you'd need some kind of server keeping track of what monome apps are open which a virtual device could query...

    and then i remembered zeroconf did all of that already, it just doesn't work in 64bit max. might have to switch back to 32 :(

  • i guess i saw examples or got a virtual monome showing itself in zeroconf.

    what is a service type?

  • i like zeroconf and i don't think zeroconf support is necessarily going away, it works well in its current form for a lot of people. i think it would be nice to allow virtual devices in a non-zeroconf setup though, where the port range option (which is admittedly not the most elegant solution) could be an alternative.

  • @Myr, a service type is just a zeroconf term for the offered types on network services. serialosc subprocesses broadcast themselves as services of type "_monome_osc._udp".

  • kk, here's my proposal again in the form of a flowchart. like i said, the osc discovery server could be done on top of an internal DNS-SD service browser. it only requires a bit of rewiring inside serialosc and very little extra code.

    random pros:

    * no need to rewrite or replace apps or externals;
    * compatible with everything;
    * better than the current mechanism - exposes virtual devices to new-style apps.

    i'd even take the challenge of implementing this myself, if the idea makes sense to anyone else. maybe i'm missing something here and it's a badly wrong way of solving the discussed problems? looks good to me so far.

    1193 x 543 - 99K
  • nope, there will be a zeroconf client *inside* serialosc that will serve one and only one purpose: to expose whatever it finds on the zeroconf bus using the current osc discovery protocol.

    thus, as the diagram depicts, real devices are advertised only by means of the classic zeroconf mechanism. the osc discovery server (green) takes its data from the zeroconf bus - it's just a proxy for zeroconf here. see?

    say, you wrote a SuperCollider app using the new discovery system and you'd like to use it with pages. right, pages can't make themselves discoverable using the new osc system, yet they're present in the zeroconf world (blue).

    my scheme assumes that serialosc knows about pages (or any other virtual devices) and lists them just like all the other hardware, when you send /serialosc/list on port 12002. a reasonable way to achieve this is to implement the discovery server on top of zeroconf *internally*.

    your app will never touch zeroconf if you don't want that. still, your app will be able to work with griddle, pages, wireless emulators - all of these in the most crazy configurations. does this sound good, heh?

    Edit: yeah, you guessed it right :)

  • that's a very interesting idea artfwo, i like that it literally means no changes to existing apps. great diagrams too! my only concern would be that existing issues people have with zeroconf would persist. most of the zeroconf issues i've seen seem to be related to dns lookups. i've noticed whenever i get on my work VPN lookups to localhost.localdomain. start to fail (it takes over my dns). so for people with that issue we might just be moving the problem out of max/msp and into serialosc? what do you think?

  • right, @visinin spoke about some of that today as well. check the IRC logs - looks like a registration mechanism can be done and maybe we can try that approach.

  • idea looks great artfwo, thanks for the diagrams!

    am i correct in thinking that the serialosc server would then rely on zeroconf? so if zeroconf wasn't working serialosc server wouldn't display anything on 12002?

    i think it's important that the serialosc server is still available if zeroconf isn't installed or working... at least with the current versions of serialosc.maxpat which rely on generating random ports each time, making it hard to connect to an app to a device if the dropdown menu isn't working.

    maybe serialosc should be a mix between the 2nd and 3rd diagrams from artfwo. so the green serialosc server is run parallel to the blue zeroconf, but when zeroconf is working/available it also adds its collected devices to the green serialosc server.

    also with the serialosc server it gives you a device id, device type and device port.
    zeroconf gives you only a device id and device port. people are already using device type as a way of setting up correct led brightnesses for varibright and OG devices. is there a way to get zeroconf to also give you a device type?

  • looking through the serialosc.maxpat with zeroconf it does set up a zeroconf service for the app itself, with the service type "_osc._udp". sweet!

    think this is one of the best parts of zeroconf, routing and spanning apps can discover which apps are open. seems it would help with storing different presets of virtual devices and paging.

  • zeroconf is wonderful and i love it but unfortunately it just breaks so much. supporting third-party monome OSC endpoints is the only thing it's got going for it now and i think if we can fix that then we can get rid of zeroconf for good.

    i wish we didn't have to, but between the hassles with max/msp externals and ISPs and windows and ugh it's just awful.

  • i like the idea of having two servers available to send discovery messages to.

    - serialosc server. listens on 12002, sends available real devices, and zeroconf virtual devices if zeroconf is working.

    - app server. broadcasts available apps. so far only available over zeroconf with service type _osc._udp".

    if zeroconf could be made to send device type, as well as device id and port, as serialosc server does, then the device type of virtual devices could be used to specify wether they are routing or spanning apps etc. we could also think of a way for virtual devices to generate device ids so monome apps like serialosc.maxpat can autoconnect to them by storing the device id.

  • ok, so with no zeroconf, i think we still need a way to make virtual devices available on serialosc server, or a port next to it like phortran's idea. i think it'd also be good to reintroduce an app server, like the serialosc zeroconf maxpat does.

    i think one of the problems with the current setup is monome apps, serialosc.maxpat, generating a random port number and basically being invisible. it makes it hard for users when the device dropdown menu doesn't populate, it hides that it's just port numbers being connected which i think frustrates new users. it also makes it hard for intermediary apps like routers/spanners/preseters, i think they'd be much helped by being able to discover apps.

    if monome apps are going to generate a random port number to receive on when opened, which i think is a good idea, then they should broadcast their existence with their port number and name.

  • without zeroconf i guess another app would have to act as an app server to respond to discover requests.

    we'd also be using an app to act as a virtual device server.

    would it make sense to have one app that tried to do all of it, as pages could. so it would get real devices from serialosc server on 12002, create its own virtual devices which would be discoverable on port 12003, and also listen out for applications somehow.

  • yeah phortran suggested that. i'm thinking of just extending serialosc to support registering virtual monomes through the OSC discovery mechanism.

  • +1 on that idea visinin

  • @Visinin - that would be great, I'm pondering the same conundrum myself... I've started working on an implemention of what @Myr is suggesting, but ideally, extending serialosc would be the ideal situation....

  • @sigabort
    yeah, agreed.

    so, i don't have the resources right now to work on this by myself, but we're forming a small team of people from the board (artfwo, phortran, thealphanerd, and me so far) to pitch in and work on this. if you're interested in helping out, either drop by #monome on freenode or send me an email (it's all over the serialosc copyright notices).

    we're be organizing this in a public trello:

  • More than happy to help out on this

  • i'd like to help out however i can, with little experience in traditional programming languages i don't know how useful that will be, maybe i can work on any max msp work needed.

    would it be possible, or sensible, to allow serialosc to register monome apps? they could register as virtual devices with their device type as "monomeApp" or something.

    does anyone else think monome apps announcing their presence would be useful? is this something i should work on a max app for? could start with zeroconf as the zc serialosc.maxpat creates a service of type "_osc._udp" for each monome app. if virtual device registration is now going to be handled by serialosc maybe port 12003 could be reserved for a monome app server, which would respond and act like the serialosc device server.

  • @myr
    i guess i don't understand the use-case. what would letting applications register with serialosc accomplish?

  • i'll try to think of some good examples, but basically so page/route/span applications can tell a monome application what device id to connect to, without having to select it in the user interface of each monome app, then when virtual devices are created the monome applications will automatically connect. it already fits in with the way serialosc.maxpat is working, would require one little change, and would require no changes to existing apps using serialosc.maxpat.

    i think it would simplify the work of route/span/page applications if monome applications could register themselves, at least when using maxmsp and serialosc.maxpat.

    currently there's only one way to get serialosc.maxpat to connect to a device/virtual device, using the drop-down in the serialosc.maxpat user interface. once you set the device in the drop-down menu serialosc.maxpat stores the device-id and will try to autoconnect to the device again next time, if it receives a /device/add message with the right id. serialosc.maxat will disconnect if it receives a /device/remove message with the right id, or if it receives a /sys/port message that is different to its receive port.

    so if you have one monome device and want to page between several different apps, you need your paging software to create a virtual device for each app, and you need to go to each different monome app and select a virtual device in the drop-down menu.

    i imagine the paging would work something like this:

    when you select a page in the paging software it would add that pages virtual devices to serialosc server, any monome applications set to connect to one of the pages virtual devices device id would then connect. when you switch to another page the paging software would remove the last pages virtual devices, disconnecting any monome apps focused on that device id with the /device/remove message, and then create the new virtual devices, connecting any monome apps focused on the new device ids with the /device/add message.

    if applications could register with serialosc then it would allow the paging software to see what apps are available and what port they are receiving on. the paging software could send a message to the application telling it what virtual device to connect to, removing the need to go to every app and select the virtual device in the user interface.

    it would be a simple change to serialosc.maxpat to make receiving a /sys/id message set the device id it stores to autoconnect to. it is effectively already what it does as the stored device id is set by the dropdown menu when u connect to a device.

  • hey myr, it's an interesting thought! the only point i want to clarify re: paging

    "when you switch to another page the paging software would remove the last pages virtual devices, disconnecting any monome apps focused on that device id with the /device/remove message, and then create the new virtual devices, connecting any monome apps focused on the new device ids with the /device/add message."

    the issue with this approach is that you lose any led changes the app makes while not in focus. in pages all apps are constantly connected and internal led states always updated so when you switch you instantly see exactly what the state is -- no redraw from the app needed.

    otherwise i think it's an interesting idea! excuse my ignorance, but is the device id saved with serialosc after you close/open the app / max/msp?

  • @Myr 's post actualy sparkles a thought about a p2p-style decentralized network of monomes and applications. imagine all them talking to each other at once!

  • @phortran hmm... i'm torn between the two approaches. some apps, a few of mine anyway, might want to be turned off/disconnected when not in focus on the current page.

    i assumed you'd also want to stop the not in focus apps sending lots of osc messages for leds when the monome device doesn't want to display them at the moment.

    i've built a "focus" or led redraw messages into all of my apps, so when they are connected they output the current leds. serialosc.maxpat provides an output to tell you when the device is connected and disconnected. i think it should be required for every monome app to take this into account, providing an led redraw function, and at least stopping sending leds when the device is disconnected.

    it seems more elegant to me that monome apps should deal with their led redrawing, it seems lazy on the side of app developers to require the paging app to keep track of all led states. and it stops monome app developers being able to use the device focus on or off messages.

  • just had a check through galapagoose's serialosc.maxpat's. looks like he hasn't fully implemented device id saving between opening/closing the app or maxmsp. i have in my version of serialosc.maxpat though.

    device id can be saved using galapagoose's serialosc.maxpat but it requires a relatively small change to the max app outside of the serialosc.maxpat. however, with how many apps there are now and how much work it took galapagoose to update them to have the serialosc.maxpat i wouldn't want to go through them all and add device id saving.

    it would be better to add device id saving between opening/closing to serialosc.maxpat itself, or to allow monome apps to broadcast their existence so paging apps can set the device id of the monome app in serialosc.maxpat.

  • i agree that would be ideal :) practically speaking i've never found the extra network overhead to be an issue though

  • @myr
    indeed serialosc.maxpat doesn't save the deveic-id internally — i couldn't imagine a system that would successfully save the id for multiple apps with multiple monomes (where do those preferences get saved?), in addition to issues with Max Runtime not allowing saving inside of the patch itself. conceptually i think it fits the same description as led-redraw, ie. it should be handled by the app itself.


    regarding this discussion, i think the quickest way we'd be able to implement this directly is via a p2p network approach on port 12003. ie. serialosc.maxpat is updated to broadcast its port number attached to /prefix name (finally it has a use again!). this can be polled. the p2p app gathers open-applications and creates a drop-down menu similar to serialosc but instead with app names. this routing/panning app itself is the only one that attaches to serialosc and then broadcasts directly to/from the relevant app via udp.

    this way it modularizes the routing/panning aspect, and handles device auto-connect internally (ie. on reload, it looks for the appropriate /prefix). it also requires zero changes to existing applications, and only the addition of an app-browser in serialosc.maxpat — obviously other platforms will need to be changed, but only a small bit of broadcasting code is required.