Due to inactivity, the KMI Forums are now READ ONLY.
Here are some helpful links you can visit to get more up to date information about your KMI products:

KMI Downloads
KMI Support
KMI Facebook User Group

LED messages leaking to other LED

a place to share your patches and get help with the Max/MSP Dev. Kit.
Peter Ostry
Posts: 23
Joined: Fri Jul 22, 2011 1:56 pm

LED messages leaking to other LED

Postby Peter Ostry » Tue Feb 21, 2012 5:43 pm

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?
Peter Ostry
Posts: 23
Joined: Fri Jul 22, 2011 1:56 pm

Re: LED messages leaking to other LED

Postby Peter Ostry » Tue Feb 21, 2012 6:36 pm

--- 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.
TomSwirly
Posts: 79
Joined: Sun Aug 07, 2011 9:04 am

Re: LED messages leaking to other LED

Postby TomSwirly » Wed Feb 22, 2012 1:05 pm

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.
User avatar
Rodrigo
Posts: 25
Joined: Wed Feb 22, 2012 11:49 am
Location: Manchester, England
Contact:

Re: LED messages leaking to other LED

Postby Rodrigo » Wed Feb 22, 2012 3:48 pm

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.
TomSwirly
Posts: 79
Joined: Sun Aug 07, 2011 9:04 am

Re: LED messages leaking to other LED

Postby TomSwirly » Wed Feb 22, 2012 4:57 pm

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
Peter Ostry
Posts: 23
Joined: Fri Jul 22, 2011 1:56 pm

Re: LED messages leaking to other LED

Postby Peter Ostry » Wed Feb 22, 2012 5:07 pm

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.
User avatar
Rodrigo
Posts: 25
Joined: Wed Feb 22, 2012 11:49 am
Location: Manchester, England
Contact:

Re: LED messages leaking to other LED

Postby Rodrigo » Wed Feb 22, 2012 5:28 pm

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).
TomSwirly
Posts: 79
Joined: Sun Aug 07, 2011 9:04 am

Re: LED messages leaking to other LED

Postby TomSwirly » Wed Feb 22, 2012 6:54 pm

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...)
User avatar
Rodrigo
Posts: 25
Joined: Wed Feb 22, 2012 11:49 am
Location: Manchester, England
Contact:

Re: LED messages leaking to other LED

Postby Rodrigo » Thu Feb 23, 2012 4:54 am

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.
Peter Ostry
Posts: 23
Joined: Fri Jul 22, 2011 1:56 pm

Re: LED messages leaking to other LED

Postby Peter Ostry » Thu Feb 23, 2012 9:06 am

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.

Return to “SoftStep Max/MSP Dev Kit forum”

Who is online

Users browsing this forum: No registered users and 6 guests