#1

Hi all,

I have a 256 vari-bright and I’m using it with SuperCollider. When I’m sending osc data in higher densities (I can’t specify the number exactly but probably around 100-150 level sets per second) often a quarter of the leds droppes out. I can only bring them back to life by unplugging and repluggin the monome.
I assume that the monome is divided in 4 sections of 64 LEDs and that each of these quarters is controlled by a seperate microprocessor. Apparently, at high densities the microprocessors are prone to crashing (every time this happens, it affects a different quarter, so it doesn’t seem to be the sensitivity of a particular region).

Is this a known issue and are there any workarounds?
Have there ever been firmware updates that might be advisable? I bought my 256 second hand, therefore I don’t know what software version is running on it.

Thanks!
Marko

1 Like
#2

You might find this thread relevant:

I experienced similar issues with my arc. It’s very easy to overwhelm the encoders (and serialosc before them). A (time-worn) work-around is to buffer changes and only send them to the monome at a controlled rate. I don’t know super collider but have been playing a bit with some JS (for Max) abstractions and would be happy to share them if it would help clarify.

(need more :coffee:)

#3

If you’re sending too many messages you should probably batch your led states up and just send a map message to set an entire quadrant at once. It would take 4 maps to update the entire grid.

1 Like
#4

Yeah, it all depends on your implementation.
I like the ‘buffer and batch’ solution a lot less than smart state management; only sending LED state changes when a condition has changed requiring the state of that LED or LEDs to change.

1 Like
#5

Any reason this has to be so high? I’m not a graphics person (and I still need coffee) but I wonder if you couldn’t get away with fewer updates (isn’t 60 a magic number?)

Also: are you using map? Are you always updating or only on state changes?

EDIT: @kisielk and @murray type faster than me! :slight_smile:

1 Like
#6

Why not both? Or do you find that overkill? Curious why you dislike ‘buffer and batch’?

#7

Me too. It’s been the standard way to update any kind of display for decades…

#8

Thank you all! I’m realizing I still have a lot of catching up to do (only started working with my monome a few weeks ago). :blush:

I’m using the MonoM extension in order to control my 256. I didn’t find any documentation of this extension therefore I just tried to figure my way out by reading the source code. So far I was using a number of independent Event streams that sent individual levset messages (event based but uncontained).
I don’t know how to use the levmap and ledmap functions but it seems like this might be a solution. Is my assumption right that you can send data for an entire 64 button grid at once?

If this is correct, could somebody please send me a few lines of example code just so that I see what the syntax has to be like?

Oh and if there is a SC/Monome tutorial or documentation, I’d be grateful for a hint. I found a link to one which only returned a 404 :slight_smile:

Thank you all!

1 Like
#9

@ppqq It’s not that I dislike it, but I simply like to keep messaging as minimal as possible. Like I said, it depends on your implementation. If you’re visualizing moving pictures on your monome, clearly not a option.

@kisielk You know, I am entitled to my own preferences. Let’s define display. :slight_smile:

#10

The functions in MonoM are just sending OSC messages of the same name. You can find the docs on the protocol here:

http://monome.org/docs/osc/

There’s also a grid study for getting started with the Monome in SC:

http://monome.org/docs/grid-studies/sc/

Unfortunately it doesn’t illustrate the use of map.

#11

Of course, I’m just curious as to the reasoning :slight_smile:
Display being anything that’s an array of pixels. The Monome is basically a very low resolution touch screen.

#12

For what it is worth the firmware for all the monome eurorack modules and aleph use the use the buffer and batch approach.

One buffer is divided into quadrants of 64 leds. On an arc each quadrant maps to an encoder, on a grid you have 1, 2, or 4 depending on the grid size. The buffer is entirely managed by the end application, basically:

  • the client makes changes to the buffer and explicitly marks it dirty
  • a periodic timer marks which quadrants need to be sent; if the buffer is dirty those quadrants are sent
  • the application chooses how often the refresh timer is run

In practice I’ve found this setup to be easy to use and good for ensuring consistent response (i.e. not overloading things with too many updates). The nice thing about it is that the course grained control over updates allows for a reduction in i/o without implementing a complex refresh logic.

1 Like
#13

For example, if you’ve several distinct animated columns spanning two or four quadrants. Is it better to send a column refresh message on every update tick or simply turn on/off the next LED? My intuition tells me it takes more resources for the system to evaluate an entire column(s) rather than a single coordinate.
Or if you’ve got multiple independent quadrants where each LED in the quadrant represents some arbitrary, discrete data that can be toggled. Update the entire quadrant? Or if you know which LED you want, update the single coordinate?

EDIT:
It’s basically the same as @ngwese described, but with higher granularity and without the assumption the client is the only one making changes.

#14

i do like buffer and batch - it’s definitely more resource intensive but not having to maintain the state makes things easier from dev point of view, one example: say you want to show some temporary state and then switch back.

you basically end up maintaining the buffer yourself. you could write something that would use a buffer but compare the 2 states and only send messages for the leds that changed, but it’d need to be smart enough to figure out what’s the cheapest way to update (say all 256 changed, in this case you do want to use batched quadrant updates instead of 256 individual messages).

if the technology is tolerant of updating often (not sure if it makes difference for led lifteime, for example), why not take advantage of it?

1 Like
#15

That answer comes down to requirements, potential future requirements, plus preferences and abilities of the implementer. :slight_smile:

#16

yeah, definitely, was just explaining my reasons for using it. i do think buffer and batch is more maintainable in a long run as more features get added, but again comes down to implementation, say if you abstract visualization.

1 Like
#17

one thing i’ve found on the 2012 series 64 is i can’t address all 64 leds at once using grid/led/level/set. this results in a lot of dropped messages by the monome firmware and sometimes this also causes the whole 8x8 quadrant to crash. same thing happens on my 2012 256. apparently this is not an issue on the 2015 grids.

#18

Sorry for the off-topic post, but I skimmed this title and clicked through hoping for audio of 256 (somethings) of quarters and buttons being dropped at high rates. :slight_smile:

#19

Great idea for a granular piece

1 Like