/frame not working on 256

  • I'm trying to use the /frame message with my 256 but it doesn't seem to work properly. The OSC specs are wrong on this, like bean pointed out to me earlier, it should be:

    /frame x y A B C D E F G H

    where x and y are offsets, multiples of 8.

    First of all /frame seems to be mirrored compared to /led_row

    /led_row 0 255 0 lights up the leds in the upper left corner
    /frame 0 0 255 0 0 0 0 0 0 0 lights up the leds in the upper right corner

    Then when you start using other values than all on/off for rows, things get crazy. Please see the little max patch below.

    I'm using OSX by the way, but it probably goes for Windows as well.


    #P window setfont "Sans Serif" 9.;
    #P window linecount 1;
    #P comment 655 430 100 196617 ehm....;
    #P message 539 327 39 196617 /clear;
    #P window linecount 3;
    #P comment 765 348 100 196617 only one section \, see the glitch when you press?;
    #P window linecount 2;
    #P comment 654 350 100 196617 and here's when it goes completely nuts;
    #P window linecount 3;
    #P comment 652 277 100 196617 this one appears on the wrong half of the monome;
    #P window linecount 2;
    #P comment 869 169 100 196617 these seem to make sense;
    #P window linecount 1;
    #P message 628 317 383 196617 /frame 0 0 34 80 144 4 80 197 160 81 \, /frame 0 8 34 80 144 4 80 197 160 81;
    #P message 634 83 145 196617 /frame 0 0 255 0 0 0 0 0 0 0;
    #P message 634 64 92 196617 /led_row 0 255 0;
    #P newex 573 498 63 196617 s toMonome;
    #P window linecount 2;
    #P message 623 395 214 196617 /clear \, /frame 0 0 34 80 144 4 80 197 160 81 \, /frame 0 8 210 32 1 186 64 1 134 128;
    #P message 621 452 408 196617 /clear \, /frame 0 0 34 80 144 4 80 197 160 81 \, /frame 0 8 210 32 1 186 64 1 134 128 \, /frame 8 0 34 80 144 4 80 197 160 81 \, /frame 8 8 210 32 1 186 64 1 134 128;
    #P window linecount 1;
    #P newex 578 258 63 196617 s toMonome;
    #P message 634 203 229 196617 /frame 8 0 255 255 255 255 255 255 255 255;
    #P message 634 167 229 196617 /frame 0 0 255 255 255 255 255 255 255 255;
    #P message 634 185 229 196617 /frame 0 8 255 255 255 255 255 255 255 255;
    #P message 634 221 229 196617 /frame 8 8 255 255 255 255 255 255 255 255;
    #P window linecount 3;
    #P comment 797 58 100 196617 these are mirrored. 0 0 is up right instead of up left like;
    #P connect 16 0 8 0;
    #P connect 11 0 8 0;
    #P connect 10 0 5 0;
    #P connect 9 0 5 0;
    #P connect 7 0 8 0;
    #P connect 6 0 8 0;
    #P connect 1 0 5 0;
    #P connect 4 0 5 0;
    #P connect 2 0 5 0;
    #P connect 3 0 5 0;
    #P window clipboard copycount 18;

  • i noticed similar behavior when building binary values for row messages on my 128.

    this was in direct communication with the device using C, so there was no OSC interpretation, max/msp, or monomeserial involved.

    i noticed that although the x,y offsets for row and column were logical, the binary values supplied to the device were displayed in reverse.

    i tested this on both a ppc and an intel mac to see if it was due to the machines endianness, and the behavior was identical on both machines.

    so, i concluded that i must build each byte in reverse order:

    0x12, 0x34 = 00010010 00110100

    must become:

    0x48, 0x2C = 01001000 00101100

    before being sent to the device.

  • Where are those "s toMonome"s being received? When I split these up, added a prefix and sent them to MonomeSerial they seemed to work as expected. Are you bypassing MonomeSerial and using a serial external in Max?

    Bytes seem to get reversed because the monome "reads" left to right (the 0 value column's on the left) which is the opposite of how we'd normally write a binary number. Like anthroid pointed out, depending on where in the chain your control messages pop up, you may or may not have to take that into account.

    Although it does seem awfully weird that /frame and /led-row would have different behaviour.

  • Thanks guys, I'm still puzzled though. The "toMonome" is just a bit of max patching to automatically prepend a (dynamic) prefix to any messages, and pass them on to MonomeSerial. It does not change the messages in any way. I don't understand, bean, why that works for you. I tried the same just to be sure but nothing changes for me. I attached the patch, this time with static prefixes. Please have another look.

    That byte order thing would be something I can live with, but that doesn't explain the glitches and offsets turning up at the wrong places. offset "0 8 some values" appears somewhere else as "0 8 some other values". Please see the patch.

    I'd love to have some definite specs on the 256 messages. I didn't buy a Monome to waste time trying to figure out the specs by trail and error :-\


    #P window setfont "Sans Serif" 9.;
    #P window linecount 2;
    #P message 378 527 257 196617 /256/frame 0 0 255 255 255 255 255 255 255 255 \, /256/frame 0 8 255 255 255 255 255 255 255 255;
    #P window linecount 1;
    #P newex 315 637 115 196617 udpsend localhost 8080;
    #P window linecount 2;
    #P message 711 523 257 196617 /256/clear \, /256/frame 0 0 34 80 144 4 80 197 160 81 \, /256/frame 0 8 210 32 1 186 64 1 134 128;
    #P message 381 565 221 196617 /256/frame 0 0 34 80 144 4 80 197 160 81 \, /256/frame 0 8 34 80 144 4 80 197 160 81;
    #P window linecount 1;
    #P message 315 486 63 196617 /256/clear;
    #P window linecount 7;
    #P comment 771 432 100 196617 same offsets \, but now only one section. See the glitch when you press? Both show up in the same quadrant!;
    #P window linecount 5;
    #P comment 430 459 100 196617 these ones appears on different halfs of the monome \, even thought the offset is the same;
    #P window linecount 1;
    #P message 714 640 169 196617 /256/frame 0 0 255 0 0 0 0 0 0 0;
    #P message 714 621 116 196617 /256/led_row 0 255 0;
    #P window linecount 3;
    #P comment 719 577 100 196617 these are mirrored. 0 0 is up right instead of up left like;
    #P connect 2 0 8 0;
    #P connect 1 0 8 0;
    #P connect 9 0 8 0;
    #P connect 5 0 8 0;
    #P connect 6 0 8 0;
    #P connect 7 0 8 0;
    #P window clipboard copycount 10;

  • I'll look at it when my 256 returns. Sounds like a monomeserial bug, any more information is appreciated.

    If you want to look at the source its MonomeXXhDevice.c::oscLedFrameEvent.

  • Ah ha! Seems to be a calble orientation issue. With orientation set to the default "left" it works as expected. With other orientations, things get mighty wonky.

    I'm not using the very latest MonomeSerial (mine dates, from November 7th, build D? F?), but got the same results with both it and the new H build.

  • Yay! I was just about to dig into the code. Turned my Monome around and now everything's fine. Ha! :-P

  • can confirm the same behavior here.. what good timing, i thought something was wrong with my own code, and then i checked the forums :)

    steeeeeve we need a fix! my usb bus would catch fire if i tried to update huge chunks of my 256 with /led

  • http://www.xferrecords.com/monochrome/MonomeSerial018I.zip

    fixed the 256 aforementioned bug with non-Left cable orientation: 256 "which destination quadrant" was incorrect on /frame messages

  • Thanks Steve! Works perfect.

  • This newest build 018I doesn't seem recognise the 40h. Although I don't often use the 256 in orientations other than left, so for the time being I can keep on with 018H.

    Other, continuing bugs include:

    No persistence of 256 settings (prefix, offsets, &c).

    Won't open if something else is bound to port 8080, even if MonomeSerial was bound to a different port on quit.

  • http://www.xferrecords.com/monochrome/MonomeSerial018J.zip

    > This newest build 018I doesn't seem recognise the 40h.

    Fixed, had my _IGNORE_40H_ buildflag set, oops

    > No persistence of 256 settings (prefix, offsets, &c).

    fixed I think, the first time I restarted MS the prefix displayed "/box", but seems ok on subsequent launches

    > Won't open if something else is bound to port 8080

    It's always been like that, I'm not sure how difficult it would be to fix. I'm not touching that bug as I don't want to create additonal (larger) issues.

    I'm really hoping someone comes along that wants to take on the project, as I've done my bit (adaptations) and I'm really too busy with my own bugs (in other software) to chase other peoples bugs / perform a re-write of MonomeSerial (most notably the coreMIDI input needs a rewrite).

  • Thanks!

    That "/box" on first restart happened to me too, but worked after that.

    I completely understand not wanting to delve into the port issues. It probably doesn't affect a whole lot of people. (Although I think at one point I said that same thing about /frame and the 256.)

    And I super appreciate all the work that you've put into MonomeSerial.

  • awesome, thanks steve

  • Hi guys. I have a question about /frame as well. I don't own a monome but I just completed a new Monome emulator for the Lemur called MonemurV2. It basically is MonomeSerial for the Lemur and allows for multiple monome configurations to run at once and dynamically shift on the fly.

    I have not implemented Frame because I didn't understand the syntax and I haven't found a Monome App that uses it to debug with. Do you know of an app that uses /frame?

    Looking at the above thread. Is the following correct?

    To light up an entire 40h monome
    /40h/frame 0 0 255 255 255 255 255 255 255 255

    To light up an entire 128 monome
    /128/frame 0 0 255 255 255 255 255 255 255 255
    /128/frame 8 0 255 255 255 255 255 255 255 255

    To light up an entire 256 monome
    /256/frame 0 0 255 255 255 255 255 255 255 255
    /256/frame 8 0 255 255 255 255 255 255 255 255
    /256/frame 8 8 255 255 255 255 255 255 255 255
    /256/frame 0 8 255 255 255 255 255 255 255 255

    So now Lemur users can have fun with Monome apps too.
    http://www.jazzmutant.com

    Steve, congrats on MonoChrome and Molar. They are excellent.

    Chris Lloyd

  • Yes, that is essentially the syntax for /frame. If supplied with only 8 arguments, the offsets default to 0,0.

    Also, maybe obvious, but worth noting that a 128 can also be oriented vertically, so that its two frames would be 0,0 and 0,8.

  • Thanks. That clears up /frame for me.

    I never thought of a 128 being oriented vertically. The other 3 messages that remain unimplemented for me are /cable and /offset and /intensity.

    I didn't really know how cable would make sense on a Lemur that is always oriented one direction, but I could see how apps could make clever use of it, especially on the 128.

    /offset I am not sure how to apply. Could I use it to run 4 separate 40h apps on one 256?

    /intensity is quite easy to implement so I will definitely do that one.

    Thanks for the help and if you know of any apps for me to check out that make use of these specific messages. It would be helpful for me so I can make sure they are supported.

  • Yep, /cable, aside from the 128, is mainly a matter of the literal convenience of which side the monome device's cable sticks out of. Pretty much non-applicable to an emulated device.

    /offset is most useful in using two (or more) separate devices in one continuous grid. Seen most often when using 2x 40h (or kits) side-by-side (occasionally even built into the same enclosure) as a 16x8. There are other uses for /offset. Implementing it into a virtual monome should be relatively simple, as it's just a matter of addition and subtraction.

    One thing that /offset won't do is allow you to run multiple apps. It's applied on the device level (like /cable, /intensity, /prefix, &c), and so would be in effect for any running apps. I wrote a Max patch called quadrants that splits the 256 into 8x8 or 8x16 units in order to run multiple apps, but it's kind of a messy hack. That's actually another thing that should be simpler from a virtualisation/emulation standpoint, because you could treat a 16x16 grid as if it actually were multiple devices.

    I believe that the monome_base patches have some examples of /frame and /intensity. I'm not sure anyone has ever used /cable in an app. It's the sort of thing that you're probably not going to need to change on the fly, you set it in MoneomeSerial and forget about it.

  • Thanks bean.

    That answers all my questions.

    The beauty of having a protocol such as this is once you nail the protocol, the magic just happens on the other end. I'll definitely implement the rest, probably sans /cable

    Cheers,
    Chris

  • I don't know what my problem is but I can't seem to find a link to MonomeTest.mxb. I want to verify my emulation.

    Does anyone know where to find it?

  • It's included in the monome_base patches:

    http://docs.monome.org/doku.php?id=app:monomebase