hello, I posted and share informations yesterday about list processing etc.

Here is the real thing.

I'm using my own hardware named protodeck. On the hardware, there is a 8x6 grid that fits with the 8 tracks X 6 scenes that make each songs. In the liveset, there are sequence of 8x6 clips blocks i.e sequence of songs.

For the current song observed on the hardware, I need to have feedback for: - playing clip, - triggered clip, - empty slots.

So I need to observe 6 rows of 8 clips for a considered songs. OK.

There are many ways to do it. I did a thing with static data put in a coll. It is explained here: http://www.julienbayle.net/diy/protodeck/#m4L

But when I click on previous or next song (i.e when I move my grid up or down in the liveset), I have a little latency. When I write little, I mean, my 48 rgb leds are updated in ... 700ms. It works for me. It is really enough cause the main important thing is to have feedback when a clip is triggered etc and all of these real-critical-time functions are VERY fast.

So with Christian Blomert, who have the same need for a nice project he works on, we had other ideas.

no coll. but a constant polling of the live set (6 observers-structure made by us, for each row of the current grid) this constant polling seems ok. it sends for each raw 8 couple of bytes. it works fine. To light up or down a led, I'm using midi notes: - pitch = led index (which led to update) - velocity = color (16= red, 32=yellow=red+green, 48=green, 64=blue) - channel = 1 (everytime)

the "problem" is: the system sends everytime the whole value (even if nothing has changed!) so, in order to save bandwidth (wlan for Christian, MIDI for me), I implemented a list filter. and we have some sync issues.

without the filter, NO PROBLEM !

The fresh patch is:

we're sure the scanning thing is ok. without the filter, it works fine (already said before, sorry)

the filter is named savingBandwith

if someone could help, it would be VERY great for us :)