communicating directly through serial via max

  • Has anyone done anything with the monome direct via serial, im not getting any information coming in from the monome for some reason.

    This is the max comm. patch if you are interested.
    Ive never used the serial protocol before, it maybe lack of knowledge on my part.


  • pretty sure still has serial howto patches

  • oh! thank you sir!

  • im getting nothing coming through the serial object at all when trying this... I just dont understand. Will this be because serialOSC is using the port?

  • raja is correct! serialosc off!

  • cheers for the help lads. Dissapointed that serialOSC needs to be off, but i have ideas.

    What exactly is the serialosc.maxpat looking for?

    I would like to 'fake' a device. e.g create a patch which is converting serial into a something that will populate the serialosc.maxpat umenu.

    This way I wouldnt have to modify patches to work with the 40h protocol alone.

  • the 40h will work with serialosc, but the way. are you trying to use the auxiliary adc/enc?

  • sorry, i havent made myself clear. the 40h works great with serialOSC, but yes trying to use the ADC's.

    @tehn - do you have some advice relating to that?


    though i think alphanerd added 40h tilt to serialosc-- try sending a tilt enable message via osc.

  • thanks brian, I've been using the serial protocol on that page. Im sure the values are scaled (although to what I am unsure). Ill get on my searches.

  • are you getting values out then?

  • I'm yet to build add ins for the 40h although I assumed I'd get some sort of noise, nothing. I'll build something once my de9 ports come through, I'll know then.

  • so what about encoders? Is there room for a simple virtual bridge fix to get my 40h encoders midi controllable, as in does this seem doable? or some way to go through ableton to get it to pick up the midi data?

  • Ah! I didnt even think to ask you to test this.

    Can you go into the newest monome test and move your encoders? On loading this patch, it activates the first two ADC's of the 40h (or both tilt sensors for gs/series). This way we can figure the values coming through. Post here or PM me when you find out!

  • you guys both need to dig up some old version of serialosc, when the ADC and encoder checkboxes were at the bottom.

  • That is maybe the problem, where to dig up an old version?

  • I had Nice-Icles test it via an osc patch sending the /tilt message, this should give the same result as the old serial osc right?


    scroll down to monomeserial, there are tons of versions

  • So I put in support for adc's into serialosc for the 40h... but if I recall correctly I only did so for two of the inputs to keep the protocol identical to that of other devices. It really shouldn't be that hard to hack in support for the others.

  • ahh monomeserial, we are trying to avoid using that. I'll go the route of hacking in support for serialOSC, Im sure i seen a thread where myles pointed out what needed to be changed.

  • I came to a thought - I believe both of our 40h are using a modified firmware to deal with encoders? Will this still be recognised by the /tilt message?

  • OK! Updates -

    I built some add ons today, I stopped serialOSC and tried monomeserial (oldschool :D)
    . Not a peep outta adc's BUT plenty information although inaccurate coming from the enc readers when i moved the pot (mostly noise as it isnt pulses). So i believe this is to do with the firmware on the 40h and why we aint getting anything via the tilt message? Any ideas?

  • when i tried to stop serialosc it would just automatically shut off.... however i could run monomeserial intermediately and I got encoder readings from stretta's monome test patch

  • hmmm... I was just thinking... I wonder if you can even use encoders out of the box with the 40h. The built in adc code is designed to simply give the analog input in voltage... something like the input from from a potentiometer or a light sensor. Interpreting data from an encoder is a bit more complex...

    take a look here

    You may need to implement a circuit like the one shown in order to stabilize the noise, but even then you are going to need to write some code to interpret the data. You might find it easier to do some experimenting with simpler analog components like a pot or light sensor first in order to test the hardware

  • I believe our firmware is modified for encoders.

    Edit: modified for encoders only.