Page 1 of 4

LED messages leaking to other LED

Posted: Tue Feb 21, 2012 5:43 pm
by Peter Ostry
I assume I'm not the only one:

When I operate the LEDs from Max directly by a stream of CCs it happens quite often that the LED of the pad with the next number receives a message. This happens in the SoftStep itself for some reason. I tried several methods to avoid this: delaying different messages, sending pairs, sending message boxes with commas etc. The speed of transmission plays a role but it also happens at lower speed.

I think the only thing I haven't tried is to send the three CCs, pause, send the next three CCs, pause, and so on. This would be quite complicated in my application.

Do you have a trick or a strategy to avoid consecutive LED messages leaking to the next pad?

Re: LED messages leaking to other LED

Posted: Tue Feb 21, 2012 6:36 pm
by Peter Ostry
--- and 15 minutes after I wrote the above I found a solution ---

A dummy message after each LED message does the trick.

For example to let a yellow LED blink at a custom frequency ...
40 0, 41 2, 42 4
40 0, 41 2, 42 4
40 0, 41 2, 42 4
40 0, 41 2, 42 4
... add a dummy 3-pair-message to each line:
40 0, 41 2, 42 4, 0 0, 0 0, 0 0
40 0, 41 2, 42 4, 0 0, 0 0, 0 0
40 0, 41 2, 42 4, 0 0, 0 0, 0 0

I haven't tried with another message because it worked instantly as it is. Maybe the 3 pairs of zeros confuse the Softstep or it tries to set a nonexisting LED or the zeros just act as a breakup between LED messages, who knows. I've switched as fast as possible at different pads and there was no leakage at all. Problem solved.

Re: LED messages leaking to other LED

Posted: Wed Feb 22, 2012 1:05 pm
by TomSwirly
Hello, Peter!

Clever trick to get it to work, very informative.

My feeling on this is that the softstep simply can't accept information faster than a certain rate. There have been hints of this on this forum, and we've been warned that really hitting it with a lot of information might even brick the unit(!) though no one has yet reported this in the field.

I haven't really tried to hammer this but I have code to rate-limit the messages that I send to the unit, and so far it's been working well. More to tell in a couple of weeks when I have my latest version put together.

Re: LED messages leaking to other LED

Posted: Wed Feb 22, 2012 3:48 pm
by Rodrigo
What are you using to limit the speed going in? (in Max?)

The objects I know (del, pipe, speedlim) wouldn't work to pass the same information just slower.

Re: LED messages leaking to other LED

Posted: Wed Feb 22, 2012 4:57 pm
by TomSwirly
Yes, that's an ongoing issue in pure Max - you something a lot like "speedlim" but that never throws anything away.

I'm doing it in Javascript, where I keep a queue of messages. You can see sample code here: https://github.com/rec/swirly/blob/mast ... ler.js#L17 but I don't know if what I just uploaded has even been run yet! :-D

Re: LED messages leaking to other LED

Posted: Wed Feb 22, 2012 5:07 pm
by Peter Ostry
Rodrigo wrote:What are you using to limit the speed going in? (in Max?)

I don't need to limit the speed when I use the dummy message. With the "blink once" LED status triggered by a [metro] I went just fast enough to see a dark LED because it could not blink that fast. This is the natural point to stop because an invisible light doesn't make sense.

However, during the tests I found out that sending value pairs directly doesn't work very well at higher speed. Message boxes with commas seem to work best. If your LED concept is simple you can of course prepare your message boxes including the dummies and bang them quickly out. Or store and recall them somewhere (coll, preset, pattrstorage etc.) For full flexibility you may consider a serial method that cannot easily break the messages up because of timing problems:

  1. A coll sends number/value pairs according to the data it receives (first pair=LED#, second pair=color, third pair=state).

  2. A [zl group 6] breaks the stream into lists of 6 numbers (= the 3 pairs).

  3. A [sprintf] puts the commas in and adds the dummy message:
    [sprintf %d %d\, %d %d\, %d %d\, 0 0\, 0 0\, 0 0]

  4. The [sprintf] connects to the right inlet of a message box to fill the string in and to the left inlet to bounce it immediately out.

  5. The result (because of the commas again number/value pairs) goes to a [midiformat] and to the Softstep.

    Image

Below is the content of the [coll]. First the pad numbers, then the colors and finally the states.

Code: Select all

1, 40 0;
2, 40 1;
3, 40 2;
4, 40 3;
5, 40 4;
6, 40 5;
7, 40 6;
8, 40 7;
9, 40 8;
10, 40 9;
green, 41 0;
red, 41 1;
yellow, 41 2;
off, 42 0;
on, 42 1;
slow, 42 2;
fast, 42 3;
blink, 42 4;
beat, 42 4;


Rodrigo wrote:The objects I know (del, pipe, speedlim) wouldn't work to pass the same information just slower.

Correct. [del] and [pipe] just delay the beginning of a stream while [speedlim] swallows what it cannot transfer. If we would be forced to effectively control the speed we would need to store our values and send them out at a certain clock speed. I want to avoid it because this way things can get very complicated compared to the effect: switching silly LEDs ...

But the 00,00,00 dummy after each LED message seems to work very well. Maybe it is just good to waste some processing time in the SoftStep device, enough to keep it under control.

Re: LED messages leaking to other LED

Posted: Wed Feb 22, 2012 5:28 pm
by Rodrigo
That's a great idea using coll to manage the 'mapping'.

Are you also sending it 'absolute' colors or just color stage changes? (ie going from Red to Yellow would turn off red and send red/green together afterwards).

If you wouldn't mind sharing, I'd love to see the rest of the LED/control section of your patch.

In thinking about it more I don't know if I'd even use yellow much, green/red is plenty, as long as it works reliably (and this is looking good so far).

Re: LED messages leaking to other LED

Posted: Wed Feb 22, 2012 6:54 pm
by TomSwirly
By the way, I just put up a packaged version of the speedlimit Max patch, and it's here:

https://github.com/rec/swirly/blob/mast ... it.maxhelp

(Boy, I wish this forum had formatting on...)

Re: LED messages leaking to other LED

Posted: Thu Feb 23, 2012 4:54 am
by Rodrigo
What dependencies does that have? I tried saving the speedlimit.jso file from the webpage into the same folder and it spits out error messages "no function call" or something like that.

Re: LED messages leaking to other LED

Posted: Thu Feb 23, 2012 9:06 am
by Peter Ostry
Rodrigo wrote:Are you also sending it 'absolute' colors or just color stage changes?

Always the correct color. Imagine an application that has "scenes" switched by program changes. Recalling a program must set new LEDs regardless of their curent state. My first message to a LED is always "yellow off" followed by the new colour and state.

Rodrigo wrote:If you wouldn't mind sharing, I'd love to see the rest of the LED/control section of your patch.

It is not ready yet, needs to get streamlined and would not tell you much because of the different LED options for each pad function. Most objects are triggers, gates, some counters and colls and of course [del] and [pipe] to avoid timing problems. Here is one of several LED menus:

    Image

"Unchanged"
The LED remains at the current state regardless what the specific pad functions does.

"Automatic"
Special multi-colour setting for continuous messages and "Autofade".

"Red beat, Green beat, ..."
The LED flashes in the musical tempo that gets extracted from a MIDI clock.