Standardizing (backward) compatibility

  • So for the next party van I'm going to release it as just a single version, with a tick box to select wether you have a vari or nonvaribrightness monome, and want to include a choice for 2011/2012+ Arc as well. I'm not going to go as far as reworking the app to replace key presses, and that would be too much work to reimagine the interfacing solutions I came up with, but those two things are pretty easy to get going.

    It would be good to talk shop about how to do this with other devs so that most apps can have the same kind of choices.

    The default will soon be varibrightness grids and 1024 arcs (though we're in a transition at the moment), so that should perhaps be the default setting. So if you open up an app, you just press connect and you're good to go. But if you have an older monome or arc, you have to select that each time you connect.

    There's been some talk in some of the threads about autodetecting this based on /sys messages and serial numbers, which is probably a lot easier for arcs as I would imagine the serial number format hasn't changed much whereas the grids have all different kinds of serial numbers/formats not to mention launchpads and arduinomes etc....

    Lastly in terms of arc sensitivity, would it be better to have a two choice option (256 or 1024) and then have all the individual application/interface/mapping decisions the dev made take hold, or to have a numerical sensitivity control (1x, 2x, 3x, etc..) so people can fine-tune their control.
    I would lean towards the first thing, as for the most part I vary the arc mapping sensitivity per situation (ie pitch controls having a 'fast' control so I can go all the way up/down with one turn, and volume having a finer grain, so I can tweak it just right).

    I obviously have something in mind, but it would be good to get devs talking about this as standardization would be valuable.

  • In terms of actual implementation of the compatibility, a few versions ago I integrated this code (though I didn't think to make it user engage-able).


    I chose 4 as my cutoff point so that I can use a brightness of 5 when I want it to be backwards compatible and 4 when I want it to be only a varibrightness display.

    For the arc it would be easy enough to just put a * or / right at the serialosc output though one would need to make sure that all accums down the line are float versions (thank god I abstracted most of my arc handling already). My patch, having been built around a 2011 arc would just use a [/ 0.] to bring the new delta values down into line with what I have going, and new apps would have a [* 0.] to scale up the old values.

    (unless I'm picturing something wrong for arc stuff)

  • Once again Rodrigo, you are showing great thoughtfulness towards the needs of the end-user. My admiration and respect for you continues to grow. Thank you and more power to you! (& thank you too, Raja, your input and help in this forum also shows great thoughtfulness & a generous nature like Rodrigo's )- of course there are many, many people here, devs and users both whi are helpful, that's what I love about this place. I guess because the Party Van is one of my favourite apps I have particulary noticed & appreciated Rodrigo's efforts in evolving his baby to be as user friendly to every one as possible.

  • Cool, I'll build my bits and post the chunks.

    @art. Thanks. My main reason is that I'm that end user too, I only know what I know because other people (including Raja) has shared, so to not do the same would be shitty. Not to mention that if everyone was opened and shared the world would be a much better place (that sounds significantly more sappy than I mean it to though).

  • Oh another thing is nomenclature/labelling.

    I like "nonvaribrightness" (default set to OFF) for the varibrightness setting as it's exclusive of the anomaly (nonvaribrightness), whereas being inclusive to the standard would be 2011+ or something (which is confusing).

    Kind of stuck on the Arc though. It could be called hi-res and low-res, but that's not especially clear (especially once the 2012+ ones are standard), so should it be labelled "old" and "new"? Not sure. It would need to be clear for people who don't know there was an older version, while at the same time letting people know who need it.
    At the moment I have it labeled as "2011" and "2012+", but that's kind of cryptic. "256" and "1024" would be the most logical/descriptive but not intuitive.

  • It's not descriptive of resolution, but "key" and "non-key" represent an easy line to know which side your arc's on.

  • Regarding arduinomes and launchpads (former is my concern), will they be left behind as Raja proposed: "we'd still exclude launchpads and arduinomes"

    Where would this leave us who have arduinomes? Will we need to do something else as our devices currently read as 40h's?

  • @shimoda - I won't speak for Raja, but I'm pretty sure he was not proposing, but highlighting & raising a concern regarding aspects of development when he said //"even if an extra /sys/ message were added to serialosc to describe which device and its capabilities, we'd still exclude launchpads and arduinomes"// - ie he was not proposing they** be** left behind, simply that devs need to be aware of the danger of them being excluded when planning compatability backwards...
    (sorry in advance if I had mis-interpreted your post)

  • @gtz That would make sense except that the language of it is exclusive of the standard (the "norm" will be non-key, but the language would indicate that key is normal, but then again, I'm proposing using "nonvaribrightness" which has the same implication).

    With that maybe having the label being "varibrightness" and that it's turned on by default, though that may confused new/unexperienced users.

    @art is right. Basically launchpad/arduinomes wouldn't have monome(branded) serial number formats so it would be impossible to tell just from the serial number what's what, so rather than it being automatically detected (ideal) it has to happen in software (with user interaction).

    Since v03 of the party van (or so) I tried to make the patch 'generically useful', so the monome/arc mapping is all there, but you can still use it using generic midi controllers, or touchosc, or softstep, etc...
    Having it (party van) and all apps in general, work with all flavors of devices would be the way to go. The idea with this thread is to try to, collectively, decide on the best way to have that be the case.

    Oh I just thought of a nice generic term that could be used for both grid/arc, a "legacy" option. So if you have an older device, you put that serialosc into legacy mode (for nonvaribrightness and key-ed devices). That could even be an overlay on the seriralosc bpatcher itself.

  • I know very little about the internals of serialosc or the device firmware, so I'm not certain how feasible this is, but let me throw it out there in the spirit of brainstorming:

    Various graphics APIs have capabilities mechanisms (like OpenGL extensions, etc.) where an app can query whether the video driver supports a particular feature it cares about.

    What if the newer devices get a new /sys message that will return a response to confirm that it has a feature. For example, an app sends /sys/capabilities/arcresolution1024 and gets back an affirmative message from a 2012 arc. 2011 arcs ignore the message and send nothing back.

    Apps can then assume each special feature is unavailable by default until it sends a query and gets a yes response. If you have a device with a certain feature but it's not auto-detected, then that's a sign you need to update your firmware. For everyone else (including 40h, arduinome, etc.) things continue to work on the original specs.

  • Something like that would be great (it would basically be a robust /sys query) but that would require firmware updates in order to work. Most people would update their firmware if given the choice, but penetration for that would likely not be 100%. The newer generation of compatible apps could include a stipulation about requiring updated firmware though, and old devices/apps can live on none the wiser.

    For me, that would be ideal as then all compatibility could happen 'behind the scenes', similarly to how /size can have an app adapt to the size of the grid being used without user interaction.

    The implementation of something like that lies not with the software devs though, but on the hardware dev (Brian?).

  • If a device firmware/protocol change is on the table that would be a good thing to discuss about (what messages/commands would make the firmware as 'future proof' as possible while at the same time giving devs the tools to best build the software/features).

    A /sys query could produce lots of info on the varibrightness (4 levels or 16) or nonvaribrightness. I don't know that would be a desirable thing from the monome side of things, but it could even return wether the devices is RGB or not (with no specific inclusion of messages/protocol beyond that). Hell maybe even wether the LEDs are white/orange/yellow. I can't see where that would be useful, but why not.

  • If apps could use a shared widget to let users manually specify the device features, then a firmware update wouldn't be necessary to make an app work. You'd only need an update to get autodetection.

  • Yeah that's essentially what I'm trying to get at here. Autodetection would be easiest/best from a user/dev perspective but it may not be possible.

  • Okay, I finally got around to reading the serial protocol spec and the firmware code on github, something I should have done before opening my mouth.

    The current serial protocol includes a message to query the firmware version. If that were exposed to OSC, I wonder how much of the feature landscape could be inferred just from the version number?

  • @art & @ raja,

    sorry to quote too little there. I think (if I remember that time way back when, at least 7200 seconds ago) that I understood that you weren't suggesting that ards be left behind (images of the monome rapture appear in my head with naked walnut casings left lying around on the ground). What I think I am getting at was wondering whether what was suggested (a UI selection) made the most sense. I like where this conversation is going.

    What I don't like is that I haven't figured out how to wrap my head around the party van features and put them to some use as I see much of this as a completely awesome project and give grandios kudos to Rodrigo for his effort (and Raja et al for support/knowledge/random rants that keep the riff get the idea).

    Time to lock myself in a room. As soon as I finish soldering some more Shruthi and other Mutable goodness.

  • I saw that thread a bit ago but didn't give it a deep look (it was started before I was around and was long). I'll give it a thorough look at and see whats up.

    Yeah having a 'standard' "custom" serialosc would be a good solution. It can wrap all of what we're talking about right into it. I would be wary of overcomplicating the basic serialoscness of it. I'm all into autodetection/connectivity (I have my own personal one setup that way, due to umenu serial number retention).

  • Re: Launchpad and Arduinome,

    At this moment, it's enough to detect that we don't recognize the device. We can then assume that per-led variable brightness is not supported, and proceed accordingly.

    That will probably change over time. And of course, the proliferation of RGB devices will keep things in flux. (some of those can be programmed to emulate varibright functionality, some can not...)

  • I haven't seen the arduinome firmwares, but couldn't it just be any old serial number in place (including varibrightness ones).

  • it could, but the serial number tells serialosc which protocol version to use when communicating with the device. if you used a serial number of a certain form, the firmware would need to speak that protocol.

  • Right, so this is there already. There's no userspace way to query that?


  • 40h is obviously the 40h, but which is which for series/mext (ie varibrightness).

    And where would arduinomes/launchpads fall into this? (I guess if it's an unknown it could bang that and we can assume it's nonvaribrightness).

    This is mine, though I don't know if they new ones will change format or continue with a higher number:
    "monome arc 2 (m0000229)"

    This is looking pretty good! With this and that conversion code I posted before (along with a * and / on the delta value, we can build those bits right into serialosc for a completely transparent backend) (only difference is using old apps will mean switching all accum's to be float versions for compatibility with new arcs.

  • Actually for really transparent compatability a more robust conversion will be needed as my code only converts /set messages. /column /row and /map would have to be converted too. Not a big deal though.

  • hi guys

    this post got me to have a go at converting the led messages from level to the older format and i came up with this.

    basically it converts level messages in set, all, row and col format using a user defined threshold for when an led is to be considered on or off.
    i haven't braved the map messages yet though and there is probably a way more elegant way of doing what the objects do but i figured its a starting point.

    i've tried it out on a couple of apps and it seems to be working ok so far.

    i'm not sure if it'll be of use to you but thought i'd share it as this post got me to attempt it so... thanks :)

  • Man that is robust as shit! Way better than what I did.

    Should we decide on a standard threshold and just use that? (I can't imagine most users will want to 'tweak' that control). Then again that can be dev dependant.

    (Is there any reason why you used an [if] instead of just plain [> 4] and feed the thresh into all the right inlets?)

  • thanks rodrigo

    personally i'd side with keeping it dev dependant for flexibilities sake but i think that once set by a dev that hiding it from general use would be a good idea.
    it might save a few posts of the "this app doesn't work" nature through accidental tweaking.

    as for the [if] object vs [>] - nope...just patching at the wrong time in the day :)

  • Out and about at the moment, but I'll tweak it down to be abstraction free and repost it later.

    Unfortunately the compatibility wont be so cut and dry as it will produce float delta values. Actually, if I just adapt my current code to use values that would make sense for a new arc, and I can then just multiply UP my delta values and nothing would be different. Actually that should be the way to go for backward compatibility for Arc stuff. Adapting the code for 1024 with a [* 4] tagged on for older arcs.

    Delta is delta so there's no loss in resolution since were actually just talking about physical resolution (and not software resolution).

  • Ok, so we can combine those two bits to have a user selectable decision (on the off chance a varibrightness guy wants binary performance, or a varibrightness arduinome or some other potential variable) but it would auto select depending on the type of machine plugged in.

    So the setup area will have choices for varibrightness/legacy and keyed/keyless (still not happy about that terminology) for the arc, but when you plug your stuff it, it auto selects what's appropriate based on raja's patch.

    Do we know what serial number the new arcs start at and if they were purely sequential before that? (to add/modify rajas detection code to spit out arc resolution).

    Here's 2D10's code abstraction free (with [>] instead of [if]). Will be a bummer if legacyrowcol needs adjusting as I de-abstracted it.

  • So there's the /map message to account for but honestly, I don't know what it does as the description is pretty spartan.

  • i would really like to discourage you guys from doing the serial number to protocol mapping in max. the whole point of what serialosc does is abstract those details away so that you can deal with all of the devices through the same API.

    > Do we know what serial number the new arcs start at and if they were purely sequential before that?

    i think this is a really bad idea and would highly discourage it.

    basically, the gist i'm getting here is that you guys want some varibrightness fallback for old devices that don't support it (like the 40h and first-edition+gs 64/128/256es), yes? also, you want to be able to differentiate old arcs from new arcs.

    my plan is still to put the varibrightness -> binary translation layer in serialosc, is this something people still want? or would you rather have it all in a subpatch ala 2D10?

  • Yeah I'd sooner not do any of this stuff, and have it all happen in serialosc, but that hasn't been the case up to this point.

    I started this thread based on the assumption that those changes aren't happening (probably incorrect) but I just want to not have to maintain separate versions of my app(s) so people with older monomes can still use it. And with the (big) Arc change coming, that adds another layer of complication, so rather than figuring out a personal solution, I wanted to open it up here so (application) devs can bang our heads together to figure out something that worked for us.

    If serialosc could do the translation, for both older grids and older arcs, awesome. This is a working towards a solution until that happens.

  • > ya that would be great. we're actually waiting on you to do that, and since we have no idea when you'll be able to get around to it(let alone any additional arc resolution translation), we do have to come up with something.

    yep, gotcha. there's other serialosc-related work that's had to come first, (un)fortunately. a teaser: we're implementing an OSC-based discovery service, so that, in addition to zeroconf/bonjour, you can query a dedicated OSC port to get lists of devices and notifications when devices show up or go away. this, understandably, is slightly higher priority, and is also quite a bit harder (because of the modifications to the serialosc architecture).

    this is both for our friends on windows who have trouble with bonjour and our friends using languages (supercollider, chuck, csound, etc) where bonjour bindings/externals are not available. it is a gigantic architectural change and has taken me an absurd amount of time.

    > also, if you say it's a "bad idea" can you please explain why? if your reasoning is that you made serialosc to do this for us: explain to us how to use serialosc exactly as it is now to get what we want. it doesn't seem like you've actually exposed alot of what we need yet.

    this is the question that i asked following that statement: what specifically do you want? the impression i'm getting from this thread is that you want two things: varibrightness fallbacks on older devices and arc resolution independence, or at least some measure of translation.

    the first, yep, it's on the list. again, other things have pre-empted it.

    the second...i'm not sure what to do about yet. i don't know what kind of impact the increased resolution is going to bring, so i'm not sure what a "translation" layer would look like. do we upsample messages from the old arcs? downsample from the new, and add a new OSC message for high-res? furthermore, there's nothing inherent in the protocol that lets serialosc differentiate between the two right now. this is the big problem from my perspective, and it worries me.

    defining a range of serial numbers is a fragile method: suddenly you've got another compatibility table to maintain. the "m0000000" namespace is used by //all// new monome devices.

    i've asked tehn for his weigh-in on this, i'll report back.

    > explain to us how to use serialosc exactly as it is now to get what we want

    as it is now? oh, you can't, certainly. that's the point of the thread.

    > perhaps you could build in an extra returned /info message such as /sys/proto

    let me clarify this further: any circumstance in which an application needs to know the underlying protocol details is a failure in the serialosc abstraction of them, and needs to be fixed. this, beyond anything else i'm saying, is my point.

  • I understand where you're coming from (in terms of time and priorities).

    So with that first paragraph, does that mean that a device will (can?) show up automatically and 'connect' (ie plug and play)? That'd be amazing.

    For the rest of it, it's just a matter to reduce the load on the support I need to give for the apps. I'm kind of new around here so all I've ever known is serialosc, and serialosc as it's always been hasn't adapted varibrightness messages to older devices. That wasn't implemented when varibrightness devices came out, so it immediately required a work around. A hi-res arc is now coming out and the same (lack of) (automatic) compatibility is also going to require a work around. Also, other than some recent discussions, as far as I know, it's never been made clear that those changes were going to happen. The actual 'back-end' of monome/serialosc is kind of unclear. There's two versions of the serialosc protocol page (there's actually two whole wiki's if I'm not mistaken). There's no centralized (clear) guide on how to get things going, and there isn't a lot of transparency in terms of developments and plans. The new webpage has been "coming soon" for as long as I've had a monome. So as a user/developer, it's not clear "where things stand", not even starting on "where things are going".

    From the discussions in this thread it seems like it may be possible to create compatibility behind the userspace (but on top of serialosc) using what we have now. Hearing that there's no way to tell Arcs apart is a bummer, much more that there's no thoughts on how that is to be handled (what was the plan going forward for devs? Why was the 1024 only told at the last minute (where are the pictures?!))?

    I guess all of this is to paint a picture that I don't know what's going on. I can only go with what I have and know, and try to provide an app that works for everyone, while requiring the least amount of additional maintenance from me. I'm not alone in that boat.

    As I said, I understand time and priorities, but it would awesome if, since monome sells hardware that requires software from the community to work (I wonder what % of monome users are devs), it would be more open and communicative about things like this, and functionality/protocol changes.

    Also, here's everything combined together. Automatic protocol detection with all varibrightness to binary conversion (set/all/col/row/map).

  • Unless I misread it, (wait, I did misread it). I thought he was saying that there's nothing in the protocol to tell arcs from grids (to serialosc) but he's saying there's nothing in there to tell old arcs from new arcs.

    In terms of the max-based protocol detection, are we looking at matching from a list/coll of "known" 2011 arcs and everything else being a new hi-res one?

    Anyone have any ideas on what the start/end points are for those serial numbers? There's just 100 total old arcs correct? (50 arc2 and 50 arc4)

  • That's assuming that there wasn't a batch of varibrightness arcs released between them. (I think the arc2s came out in a different batch as the arc4s).

    Just checked and it's as follows:

    march 2011 (100)

    march 2011 (50), september 2011 (50)

    There were some other things released in tandem:

    Grayscale 64:
    september 2011 (100)

    Grayscale 128:
    september 2011 (100)

  • The grids are a non-issue as the code you wrote before can tell varibrightness ones apart. That's all we need to know there (no serialnumbers needed) as if it's not a 'mext', we can just send binary data.

    There's not a way to tell the arcs apart (yet) and these are shipping soon.

    If they add varibright2binary they'd add arc resolution compatibility. It's just a matter of when. I'd like to have a good solution in place until that point so that userspace is clean from this stuff. (So far it's all there but the arc auto detection). Knowing serial number start/ends, or clumps therein would solve that.