Julien Bayle

I posted and share informations yesterday about list processing etc.

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:

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

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.

but a constant polling of the live set (6 observers-structure made by us, for each row of the current grid)

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)

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.

without the filter, it works fine (already said before, sorry)

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

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

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.

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.

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

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


working on a liveset scanner ... but we have issues :-(