serialosc 1.2 does it support 40h ADCs?

  • Does the new serialosc support the ADCs in the 40h?

    The tilt appears to do something (kinda random) in response to my ADC outputs, so I figure it's worth trying to bring the ADC signals out to the Max test patch.

    If I modify _monome_test.maxpat, what messages do I have to pick up?

    example/tilt does not seem to be enough


    Regards, C.

  • So I wrote the tilt stuffs for 40h, you can see it hurrr

    https://github.com/monome/libmonome/blob/master/src/proto/40h.c#L145-164

    https://github.com/monome/libmonome/blob/master/src/proto/40h.c#L186-208

    So to answer your question more specifically... tilt is enabled, but it is only really listening to 2 out of the 3 adc's... and it is doing some scaling internally in the driver. This is because the tilt on the 40h has an extra bit of information than any of the other devices... as such it needed to be scaled in order to output similar values.

    So if you look at the pcb http://monome.org/here/thrulogic_pcb.jpg you can see that there is actually support physically for 4 adc's... but currently it is not supported. In theory if you were to build libmonome / serialosc from source you could modify how those adc's work... remove the scaling, and add support for all four.

    In theory this could have been done from the begining... but to keep things simple we kept the 40h behavior identical to that of all other devices... being that the /tilt/ messages are identical.

    Any other questions (I think I probably went to far and raised all this technical mumbo jumbo without actually answering anything)

  • @Raja & @thealpha
    Thanks to both of you for your comments and guidance.

    @RajaTheResidentPoseur
    That looks like the sort of thing I should be putting in Max/OSC messages, although I think section 7 analog out is more like what I need (and it looks like one of the ones that is not fully added in). However, when I scrolled up, I found that 40h has its own link to a simple table defining the data structure. Which should I be looking at?

    @thealphanerd
    Yes, you are correct, those are the ADC connections I'm trying to pick up. I soldered them to a DIN connector and brought them out to four Sharp IR sensors. This worked well in monomeserial, although monomeserial itself was unreliable. Since the firmware in my 40h kit is unchanged, it should still be making the ADC values available.
    Thanks for highlighting the code areas you're talking about. My C skills are vanishingly small, however, I give it a go:
    The first link looks like it's saying an 'enable' message to 'tilt' exposes all four sensor outputs, and the 'disable' message turns them off.
    The second link looks like it's highlighting the code which mashes up the four ADCs into X-Y tilt information.

    It looks like one could specify the analog out functionality somewhere, though maybe not in 'mext' and put in some sort of switch between x-y and 4-way ADC function in the proto 40h code (although, from my POV the x-y functionality is of no value) - just speculating.

    @interested parties
    Personally, I'd like the ADC outputs restored, but I suspect I may be in a minority of one.

  • @chrisbob

    So basically what I was highlighting is that of the four adc's only the first two are working. Further the two that are working are being scaled. The messages to turn tilt on and off are handled by serialosc...

    The reason for doing this was to keep things running smoothly between all models... so that developers would not need to write separate messages for the 40h as opposed to all other types of monome devices.

    If you wanted to restore adc functionality as it was in monome serial you would need to edit libmonome to actually handle the serial communication... and then edit serial osc to wrap the communication between the osc world and the serial world.

    Thankfully because the code is already there it shouldn't be super duper difficult.

    The only real problem is that as it stands at the moment, the only two people who would really be able to do this would be you (as you want it done), and me (as I know exactly what needs to be done). Unfortunately we are near finals, and I am shit slammed with work until mid december.

    Why not try hacking at it? I'll be around in #monome on freenode (always am), you can hop in there by clicking on the live chat button on the left. I'd be more than happy to help you try and figure it out.

    You can go on github, make a fork of both libmonome / serialosc, and see what you can get working.

  • @thealphanerd
    Many thanks for clarifying this. It's a relief to have the situation spelt out. I'm not sore about it: I imagine I may have been the only person to latch onto the ADCs for exotic functionality.

    "Unfortunately we are near finals, and I am shit slammed with work until mid december." Best wishes; get that result!

    I'm not in a super-hurry, but having put a toolchain together, earlier this year, I may be tempted to frig around with some of the code. Although, my project list grows ever longer ;-)

    As a lateral thought: I've also done a project off midibox.org website - I wonder if there's mileage in developing an OSC core module (based on an Atmel) in the way midibox have developed a midibox core module. The new monome kit looks to be part of the way there.

  • chrisbob... it would be a bit tougher to do so... you can send midi directly over serial without requiring a driver... whereas you cannot do so with OSC (as it is a networking protocol)

  • @thealphanerd

    Thanks for the insight. Hmm. I had a google about. What I'm probably angling for is an arduino with firmware to translate the inputs to OSC messages, with maybe an ethernet shield. There seems to be some stuff like that, but no critical mass.

    I wonder what would be the case for/against building a monome with an ethernet connection?

  • @chrisbob

    while I think that what you are considering a noble effort... you might want to really examine all the steps required for what you are trying to do... and whether or not the time commitment would be worthwhile (or if people would use it).

    You can easily use an arduino with a couple sensors, send the data over serial... and use something like max / pd to convert those values to OSC... really not too tough at all.

    Now if you wanted to send the messages directly from the arduino you are going to need another shield... another cable... and you are going to need to work out the protocol stuff to send OSC... which is technically a type of UDP message (although these days it can also be tcp). The arduino is also not super efficient at doing things... and you will still need to plug in a power adapter or a usb cable if you are not going to run off of batteries...

    So now you've turned your networking step into something MUCH more complex, and not nearly as flexible, and also introduced another cable... kinda sucks. :(

    The question becomes what is your ultimate goal in this project. If what you really want is a custom controller with some sliders and knobs and what not... well you might be best off just using an arduino and firmata (assuming you have not done much work with serial communication before) and just make a solution that works for yourself.

    While it is noble to try and make a standard rather than a one off... it can be a fools errand to try and sink your time into something people will not use.

  • This is in no way meant to discourage you... if you have the time and ability to pull something like this off, that would be amazing! Things like the monome wouldn't exist without dreamers pushing boundaries.

    More so that if this is one of your first projects (which I was under the impression it is), you might find it easier to make something a bit simpler to start.

    Iterations are a great design workflow as well. Come up with a "blue sky" model of what your perfect controller would be. Then implement a simple iteration that is a first step. This allows you to test your interaction models and make changes to the larger structure of the idea without starting from scratch. Nothing worse than sinking a bunch of time into an instrument to find out it sucks to play.

    You want to make a all in one sensor box that can run off batteries and wirelessly transfer scaled sensor data over a network (as an axample).

    So a nice first iteration might be... lets get that sensor data over serial to the computer. Then figure out how to scale it to make it useful in something like max or pd where you can rapidly make changes without having to recompile.

    Now once you have that working in its own silo... you can work on an OSC api and implement that in max.

    At that point you should have a system that has the input / output that you desire... and you can work on modifying the middle bits to get closer to your vision.

  • @thealphanerd
    Thank you so much for your thoughtful replies; I am encouraged, and it really put a smile on my face!

    The best place to start with is 'ultimate goal' - unfortunately mine tend to be rather high level (dreamer = rumbled) however, in this area, I have tried to narrow things down somewhat. In the course of this thread, I was thinking 'wouldn't it be nice' if there was a standard building block to hang stuff off like that nice Midi box. Clearly, if it had been simple and/or highly desirable, it would have been done by now.

    Your comment "You want to make a all in one sensor box that can run off batteries and wirelessly transfer scaled sensor data over a network (as an axample)" pretty much nails it. My direction of travel with this is towards interactive installation modules. Having had a go at hard-wired installations, and wanting to offer more instrumentation options, I'm definitely interested in overcoming some of the limitations and grief imposed by setting up and tearing down miles of cable. Something I'd want to test out on my own account and offer to people who are more in the business of installations.

    My software skills are pretty restricted; I have a crude idea of what I'm looking at with C source code, and very little experience with networking protocols, apart from knowing they exist and roughly how they fit into a software, hardware, firmware ecology. This is by no means my first project, although I've been refurbishing my skill set over the last couple of years. Mostly my skills overlap what we're talking about here, but don't fully encompass them.

    Anyway, I shall print out your comments to read on the journey to work and reflect.

    Best wishes, Chris.

    PS, you may find these entertaining:
    http://www.boutiquerobots.com
    http://vimeo.com/34744317

  • @chrisbob

    I have some ideas I have been playing with that you might be interested in exploring... hop on the irc channel some time and lets talk about it in a more direct forum.

    Took a look at your work and it is quite interesting... you might find this book interesting based on your profile

    http://www.amazon.com/Counterculture-Cyberculture-Stewart-Network-Utopianism/dp/0226817423

    I just got it on the recommendation of a genius :P

  • @thealphanerd
    Interesting recommendation! I'm somewhat familiar with Stuart Brand and Whole Earth, so it will be interesting to read the larger context.

    Currently getting my head round IRC. Chatzilla installed and connected so far.