problem with variable brightness (2011 edition)

  • I have a 2011 256 and was hoping to mod a few apps so that all the LEDs are always dimly lit instead of off (for dark situations) The problem is that there's a slight flicker when using variable brightness, and with that many LEDs dimmed it becomes really distracting. I've noticed the same "flicker" in the monome test patch when i set all the LEDs to the dimmest setting.

    So my question (for tehn and other 2011 256 owners) is it just me or is the flicker normal?

  • I haven't had a chance to play with this model in person, but it sounds pretty normal. Is the flicker more pronounced at lower brightness levels?

  • i pretty carefully tuned the firmware to eliminate flicker, so something might be up.

    are you using per-led brightness or overall brightness (intensity)?

  • @tehn

    it happens with per-led brightness and overall brightness. when i turn the overall intensity to the lowest or medium setting in the serialosc-test patch, the LEDs flicker constantly, one row at a time (but only the first or last 8 of a row flicker)

    btw i've been seeing the flickering since the day i got it in feb 2011, so its always been like that.

    edit- i did notice once that one of the ribbon cables inside is pretty bent up, not sure if that would make any difference though.

  • hadn't noticed it before but i've just had the similar results with a 2011 256 using the serialosc-test.maxpat.

    machine used - '08 macbook, osx leopard, mains powered.

    when lighting the whole device i found that using a low intensity and a low led/level/all message makes the flickering obvious due to the rate they occur

    whereas

    using a high intensity and a low led/level/all message reduces the rate so less flickering occurs but when it does it appears as a more obvious 'blink'.

    i also tried switching between a powered usb hub and straight into the laptop to see if it made a difference but it didn't.

    again these flickers are in rows of 8.

    it might be worth noting i couldn't replicate this on a 2011 128 (no flickering noticed) and i haven't looked inside the 256 yet as everything else about it seems perfectly fine but i can give it a go if required.

    hope this helps, happy new year all.

  • thanks for the tips. i'll check mine for similar issues.

  • @2D10
    you explained it way better than i did. weird that its only 256's

    @tehn
    did u ever get a chance to do any testing? is there any hope for a fix?

  • i'm going to need a few days. in the middle of a huge list. yes, there is always a fix!

  • @elquinto

    "weird that its only 256's"

    unfortunately its not...i've just noticed it on the 128 as well.

    i have no idea how i missed it yesterday, eyes must be failing me :)

    @tehn

    thanks for looking into this when you get the chance.

  • i tested this and it's working very well. however, on the bottom intensity setting, i do see a *very* subtle flicker-- every several seconds there is a very faint dropout of a few random leds. for me it's difficult to see at a glance, i have to really stare deeply into it.

    that said, the flicker isn't visible at all at the next higher intensity setting.

    i can put together some firmwares that will remove this bottom intensity level.

  • It sounds like we're getting different results. On my 256 its really noticeable on both low and medium brightness that random rows of LEDs(rows of 8) are blinking constantly.

  • btw i just noticed in the serialosc-test.maxpat when i use grid/led/intensity i don't notice any blinking until i get *very* low, and like u said, u really have to stare into it to notice. but when i use grid/led/level/all it blinks much worse like i described, on low and medium levels.

  • @tehn
    i probably wasn't being specific enough. when i was saying low and medium brightness/levels i was referring to the 4 led states, off, low medium and high. and earlier when u asked me if i was using per-led brightness or overall brightness i got overall brightness confused with grid/led/level/all. i've always had overall brightness(intensity) set to maximum.

    So just to clarify, in the serialosc-test patch, when i set the overall intensity to the same level as the different led states, i see no blinking at either levels. however when i use grid/led/level/all the blinking is readily apparent at low or medium and the blinking is always in rows of 8.

    hopefully i described it better this time.

  • i'll test that.

  • @tehn

    regarding the firmware.
    thank you but personally i think i'll be fine with them how they are for now.
    i just thought i'd post my findings to give more results to compare.

    some additional testing notes that might help -

    if i'm using the maximum values (12 to 15) in the /led/level messages or just the regular grid/led/set messages i get no noticeable flickering when adjusting the intensity, even at the lowest setting.

    its only when using the 2 lower lit states (4 to 7 & 8 to 11) in the /led/level/all messages that the flickering occurs at varying rates (dependent on the intensity setting (see 10 posts above)).

    as a hopeful long shot i quickly did some more testing on a windows machine as well to see if the flickering was computer related but no difference noticed.

    this has all been with a static/non animated grid though.
    in some minimal tests done with the leds regularly changing states using the /led/level messages i couldn't notice a flicker.

  • Gonna stick a varibrightness question in here since it seems like a reasonable thread for it.

    I wasn't around when these first came around or were being planned, but does anyone know if there are plans to make the grid have 16 steps of brightness like the Arc? Would definitely make animation/swells smoother on the grid. At the moment I'm only doing a little bit of that (in my Monolase app), but when an LFO goes slow, you can really see the stepping.

  • @2d10 thanks for the feedback. let me know how it fares in actual application use.

    @rodrigo it's not possible with the hardware on the 2011 units, but i've considered this as the way forward with new units. at the same time i'm considering scrapping variable brightness on the grids altogether and going back to binary. i know there are advocates for every feature set (including rgb, where i'm definitely not going.)

    the issue at hand-- does variable brightness or RGB really add a *substantial* improvement to usability? at this point most of what i've seen is at times very beautiful, but by no means intrinsically required.

    ie. in mlr, if the inner-loop function was very dimly indicated, that'd be very pretty, but also somewhat helpful. however, many of us have gotten along wonderfully without it.

    where is the threshold to make "improvement" on an idea? when does improvement actually just lead to unneeded complexity?

    these are hard questions. i've spent years on them.

  • @tehn

    one use case where variable brightness can come in handy is in a clip launcher... enabled clips are dimmed... playing clips are full brightness

  • @tehn
    regarding actual application use, there's an app called Clipmapper that uses variable brightness (idle clips are dimmed, while playing clips are full) and the LED blinking is there too and very obvious.

    also i made a mod to mlr so that instead of any off (inactive) LEDs , they are dimmed. this makes it a lot easier to play in darker rooms, but the LED blinking is obvious there too.

  • i have a 2011 walnut 64 coming in the post so i'm looking forward to playing with the brightness levels and seeing if i can come up with something that makes full use of them.

    but really, i don't think it'll offer any drastic usability gains.

    having played for a good few months with the arc though, the brightness levels on that do seem to offer a range of tantalizing possibilities.

  • I think having more ranges would definitely amplify the usability.

    A couple of obvious uses are:
    Button states. This is more apparent with rgb as you can cycle through colors, but I'm using a row in one of my apps where dimmed means one function, and full brightness another.

    Then there are layers, similar to what I've seen in some arc apps, where say with something like mlr you have a bright layer as our main layer, then there could be another dimmer layer underneath doing something else, etc...

    Another use would be as a cycle indicator, with 15 steps. 4 isn't enough to give any meaningful info there, so I've not messed with it, but I think with 16 you could get a reasonable idea of what's going on, with one button/led.


    "substantial" is a dangerous word here because does a 128 add a substantial improvement over a 64 in terms of usability? If so, wouldn't the same apply to varibrightness?

    Hardware restrictions and design choices are by no means easy, but I don't think that minimalism and addition(via improvement) are at odds with each other. (I imagine the rgb reservation is a design/esthetic one).

  • "Another use would be as a cycle indicator, with 15 steps. 4 isn't enough to give any meaningful info there, so I've not messed with it, but I think with 16 you could get a reasonable idea of what's going on, with one button/led."

    i agree, smooth transitions would look amazing. on the other hand, i found 3 levels to be what you could distinguish between at a glance. even with 8 levels of brightness you'd have a difficult time distinguishing level 4 from level 5. so pretty transitions or pulsing are what benefit.

    "does a 128 add a substantial improvement over a 64 in terms of usability? If so, wouldn't the same apply to varibrightness?"

    sortof. 16 vs 8 steps is a major improvement in terms of granularity. anything where you don't have to physically "page" a set of data so that you can use your hands immediately vs. accessing shortcuts to find more data. this has an upper limit of course, and i have trouble thinking of how to effectively use my 512.


    but your points are well taken. i don't think variable brightness adversely complicates the protocol-- it's already there and feels ok. much of this conversation to me is about choosing appropriate uses for devices. there's often a desire to stretch uses "because you can." for example-- virtual sliders on a 8x8 grid are simply a bad idea in most cases (where you want resolution.)

    more use cases for varbright are welcome, please post your ideas.

  • 16 v 8, in a stepped app is obviously a big difference, but my example was in terms of general usage, non-stepped applications.

    It's also difficult to imagine the kind of things you can do with something that doesn't exist. I've only used the varibrightness stuff a little bit on mine as I've not had massive ideas in terms of how to apply it. That and my coding isn't good enough to do layers of data yet....

    I do agree that the "because you can" monster can gobble many a usefulness, but at the same time, pushing the other way isn't good either (ie the direction that Apple may be going if they keep closing off things).

  • Rodrigo had mentioned using variable brightness in mlr
    This struck my fancy bone

    How about a version of mlr where each row could have multiple sub loops

    The first would act as normal
    The second would modulate the amplitude of the first loop
    The third would modulated the pitch of the first loop

    Or more simply being able to select start and end point via the monome with one level and the currently playing sub loop with another level

    These would all be different brightnesses.

    Just a quick thought

  • Yeah layers would definitely open up possibilities. Also when combined with an arc, or arc-like programming.

    Take the tremolo/rotating thing from a couple of the arc patches. Say you pull focus on an mlr row, and then setup the tremolo rate on the arc (which displays on the arc), but that is also mirrored on the mlr row (as a lower layer thing), so you can be elsewhere with the arc in terms of focus, but still have the position displayed on the row.

  • That is an interesting point.

    In MonomeSerial days, we had 16 levels, and the tremolo thing Rodrigo describes wouldn't have been a problem. It worked great on all the old hardware, too ('cause we weren't using per-LED brightness levels). I haven't checked since switching to SerialOSC, but I sort of assumed that the global brightness controls would still work as they did. Are those cut down to four too?

  • I plan on adding an mlr 'window' display with variable brightness to my mlr type applications. The downside with that is that I need to remove that code (or close it off) as for non varibrightness it would all be full brightness.

  • all of the brightness controls (global and per-LED) are 16 levels. on devices that support it, the 16 per-LED levels are quantized to 4 (i.e. the firmware does something like "brightness = brightness >> 2").

  • Sweet. Thanks for clarifying!

  • @tehn
    have u had any luck replicating the "row blinking" issue with per-led brightness? any word on whether this problem can be fixed with new firmware?

    no rush or anything, but i'd really like to see a fix.

  • I have to say that I'm experiencing it too. It's really noticeable and bad when using the dimmest setting.

    I set up a sort of loudness to LED intensity thing for my mixer/fader page, and I had to limit the range from 8-15 as below that the flickering is bad, across all leds (not just the ones you're working with).

  • @tehn

    any updates?

  • @elquinto:

    update forthcoming, but it will simply remove the lower intensity settings. you're just as well off at the moment using the upper ranges.

  • hmm.... i meant, do you have any update on whether you've tested the per led brightness issue we've been giving followup bug reports about? i'm really curious if it can be fixed with new firmware. i'm not sure how removing the lower intensity level would help since the blinking happens only when using the 2 lower lit states (4 to 7 & 8 to 11) in the /led/level messages. easiest way too notice is use /led/level/all

    here's the test patch-

  • ah, apologies. i was confusing another issue.

    what i mean is the scale would be adjusted. the brightness scale would be shifted overall.

  • i'm really confused about what adjusting the brightness scale (removing the lower intensity) is going to fix. the grid blinks just as much on "/led/level/all 11" as it does on "/led/level/all 4". grid intensity is working fine, its led/level thats busted.

  • 0-15 are arbitrary numbers dividing the span between a low brightness and a high brightness. It sounds like that lower brightness is moving up, and you'll be using tighter divisions of the remaining span.

  • @GTZ
    thats what i figured, but i don't think that would do anything to fix the blinking problem with led/level. (which is why im so confused)

  • If the lowest available brightness is above the threshold at which things begin blinking, you shouldn't encounter blinking. So, level 1 will soon be brighter than level 11 is now. I guess.

  • i don't know, it would help if u could see it in person. the blinking doesn't get any better when going from low to medium threshold with led/level/all. if u use the same brightness levels with led/intensity i don't see any blinking at all. intensities 1-2 flicker a bit, but not like the blinking in led/level. i'm assuming tehn is talking about removing those 2 lower intensities that flicker by rescaling the brightness. Still though, that wouldn't fix the blinking problem with variable brightness units and led/level, which is the main problem here. i mean, is the blinking a limitation of the hardware, or is it a bug? to me it seems like a bug, but i don't know as much as tehn of course.

  • this is going to be a mixed issue with firmware and hardware. the hardware imposes limitations of timing, but i was under the impression that the firmware i'd arrived at was working very well. i'll keep working on it.

    do you have a specific app that you're using that brings out the issue? beyond testing i mean.

  • yes, theres Clipmapper which brings out the issue, but you need Max4Live.
    http://post.monome.org/comments.php?DiscussionID=11731&page=1#Item_0

    also something i really want to do is mod some of the apps i use to have a backround layer of dimmed LEDs, to make it easier to play in darker rooms. but if the blinking is that distracting in Clipmapper, it would be just as distracting in anything i do as well.

  • @tehn
    friendly reminder, still hoping u have time to check this out.