Question about offsets (for rows and varibrightness)

  • So if I want to set a level for a row, how do I do it?

    This is what it says on the protocol page:

    /grid/led/level/row x_off y l[..]
    http://docs.monome.org/doku.php?id=tech:protocol:osc

    So if I want to turn off all of row3, what do I put?
    I've tried a bunch of variations, but I don't understand the bitmask stuff at all.

    Can someone throw me a bone here?

  • Or even better, can I set the level for every row except the first one, with one message?

    I'm using my top row as pages, and want to control the levels of other rows.

  • hi rodrigo

    "So if I want to turn off all of row3, what do I put?"

    if you're using level messages where it says l[..] you need to put a list of 8 or 16 numbers between 0 and 15 to set the row.

    you would put either

    /prefix/grid/led/level/row 0 3 0 0 0 0 0 0 0 0

    or

    /prefix/grid/led/level/row 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

    the row x_off is the x axis offset, i'm pretty sure this only works in multiples of 8

    y is the number of the row you want to use.

    am unsure about your other question but hope this helps a bit.

  • That does it. Thanks.

    I can do it using 7 messages, so that isn't so bad.

  • @Rodrigo

    a little late... but if you still need help with bitmasking let me know.

  • I ended up doing it a different way (I don't even remember what part of my patch this was for now). Thanks though.

  • /grid/led/level/map x_off y_off l[64]

    /grid/led/level/row x_off y l[..]

    /grid/led/level/col x y_off l[..]

    are not working for me.

    for example..

    i use /prefix/grid/led/level/row 0 0 10 ... doesn't work??
    my expectations are that row 0 gets set to 10 intensity.

  • Scroll up to 2D10's message from January 25th.

    (if I had to guess, I'd interpret l[..] as meaning a list of one or more numbers)

  • seems it's bitmasked? can you provide a working example of the code for use? i am a bit lost.

  • @raja
    > /prefix/grid/led/map x_off y_off row1 row2 row3...
    offsets and then 8 integers (bitmaps), one per row.

    > /prefix/grid/led/level/map x_off y_off row1_led1 row1_led2...
    offsets and then 64 integers (0-15) representing the brightness of each individual LED.

  • thanks for the clarity. it makes sense as far as i can tell without being able to physically test this at the moment. i did not understand that l[64] represented a list of integers for the brightness of each individual LED. thanks all!!

  • i understand the use of /prefix/grid/led/map x_off y_off row1 row2 row3...


    i don't understand /prefix/grid/led/level/map x_off y_off row1_led1 row1_led2...
    why wouldn't i use (the below):

    /grid/led/level/row x_off y l[..]
    /grid/led/level/col x y_off l[..]


    does /level/map allow the coding of the varibrightness setting for an entire grid of 64 buttons with only 8 numbers like /led/map?



    -----
    edit:

    for example, how could i use the map message, not the row or column message, to have varied brightness within row 1 and 2 and full brightness for row 3?

  • Apologies in advance for the ultimate wordiness:

    The "level/map" and the regular "map" would never be used at the same time. For the regular "map", you assume everything is at one global brightness setting... the reason why you can't code varibrightness setting for an entire grid with only 8 numbers using "level/map" is because each led out of 64 needs a specific brightness setting: you can't achieve that much specificity in a bitmask message. (personally, i would never use a message like "level/map", requiring 64 parameter settings in a list all at once, unless i'm controlling it entirely with an 8x8 Jitter matrix, or similar, all at once...)

    //"why wouldn't i use (the below):

    /grid/led/level/row x_off y l[..]
    /grid/led/level/col x y_off l[..] "//

    you could use that. but then in order to get coverage over an entire grid, you'd still have to send 8 versions of that message(one for each of 8 rows or columns, thus, 8messages x 8varibrightnessarguments-per-message = 64 varibrightness arguments so it would end up requiring the same amount of arguments as the "level/map" list. if you don't need varibrightness over the entire grid of 64, then you would want to mix and match "level/row"(or "level/column") with the regular "row" and "led" messages.


    [Edit: in answer to: "for example, how could i use the map message, not the row or column message, to have varied brightness within row 1 and 2 and full brightness for row 3?"
    quick answer, something like:
    level/map 0 0
    2 6 9 4 2 6 9 4
    2 6 9 4 2 6 9 4
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    long answer:
    you would still set the first 2 rows with individual brightness arguments and set all the other buttons with full brightness, still specified in 64 individual arguments... a pain in the ass for just 2 rows. you wouldn't want to do this. if you have entire rows and columns that will always be left at full brightness or off, then don't use "level" based messages for those rows and columns, only use "level" messages for the rows and columns you need.

    the "level" messages are more verbose, so for efficiency, you would never want to use them except for the rows/columns/specific-leds that you need them for.]

    Basically, only use level for what you need. Keep things simple for the rest. (only use "level/map" if you really want every button out of 64 to have individual brightness settings).

  • ah raja.. i appreciate the insight. never too many words from you... in fact, i tend to re-read your entire posts quite a few times.... [:

    will experiment and report back. i get neurotic over this and worry that i'm developing patch ideas with 'bad practice' and by bad i mean not the most max-centric computationally efficient structure. the less messages i can send... the better....

    i suppose i need to make it work before i can strive for efficiency. i enjoy the process and that's what matters !

    sorry to derail this thread all.

  • You guys should also peek at gtz's initial arc led experiments. I guess this also applies here now. He has some really nice map stuff going on.

  • gimme a sec.

  • http://post.monome.org/comments.php?DiscussionID=11690&page=1#Item_21

    i'm sure you'll find some food for thought in the arc layers patch in here. really awesome arc animations with that patch!

  • i try

    level/map 0 0
    2 6 9 4 2 6 9 4
    2 6 9 4 2 6 9 4
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15

    but no LED's .. trying to figure out a test message that works for level/map.

  • sorry, i must've missed an entire row when writing that message, it's this(with prefix set to 'example'):
    /example/grid/led/level/map 0 0
    2 6 9 4 2 6 9 4
    2 6 9 4 2 6 9 4
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15
    15 15 15 15 15 15 15 15

    basically, make sure you have 64 arguments, you'll notice i screwed up and there's only 7 lines of 8 arguments(56 total) in my original post. my bad, didn't actually test it out.

  • ah... so the list needs to be full. thanks.

  • funnelling in different lists with [zl join] into a map message makes for some seriously mesmerizing led displays...

  • RESSURECT!

    just to get my head around this...

    the

    /grid/led/map x_offset y_offset s[8]

    can only have 8 bitmasks - so to map a 128 for example you'd have to send one message with 0 0 as the offsets, then another message with offsets to map the second half of the grid?

    btw raja - you're tutorial patch, particularly the bitmask bit is excellent and helping me a lot ;-)

  • "to map a 128 for example you'd have to send one message with 0 0 as the offsets, then another message with offsets to map the second half of the grid?"

    yeah, then the offsets 8 0 or 0 8 (depending on orientation) followed by the bitmask.

  • Gotcha. I'll have a play around tonight.

  • nevermind