hello,
for those who know, I'm finishing the max for live patch interface for my protodeck controller.
all works fine except the last thing I'm working on : the RGB leds clip matrix used for clip feedback.

I try to explain precisely what I want to do.

8 tracks
6 scenes per "song"
this 8x6 matrix fits with the hardware clip matrix
I have button for going to next or previous song
I need to observe each clip contained in this 8x6 for the current song (current song= offset position of my little 8x6 hardware window=song "observed" in the real world on the hardware)

[p collectClipslots collect all clips in a coll.
I use a coll called: allClips
this coll is filled at the load time (with a loadbang that works fine) with index and object ID of all the clips of the liveset:
- index = x*100 + y (where x & y are the clips coordinates in the matrix)
- ID = object ID of each clip
The purpose is: no more clip collect at the performance time, only one time at the beginning.
This part works fine. I have the possibility to put 0 if there is no clip, or to drop this and only fill the coll with clipslot filled.


I have [p clipMatrixHandler] that uses a dump of the [coll allClips]
it contains [p theMatrix] that takes the big dump (all the data from [coll allClips], parses data one time at the beginning in order to fill each smallest element called [p ledUnit]. it is an abstraction.
I put 8x6 [p ledUnit].
thus, each one of these [p ledUnit] is feeded with ID of the clip to observe + the x,y coordinates (depending on current song)

the only thing that provokes events from live to the hardware is:
- one clip of the current song changes (transition from stopped to triggered, from triggered to stop, from triggered to playing)
- current song changes by triggering "previous song" or "next song" buttons


Now, the pictures:


[p collectClipslots] : the patch that collects all the clips ID and store them in the coll allClips





[p clipMatrixHandler] : the patch that dump a 8x6 clips ID information among the whole clips ID stored, depending on the current song





[p theMatrix] : the patch that observes the 8x6 current song clips





[p ledUnit] : the abstraction that observes a particular slots and send midi notes to the protodeck





I have no problem with the communication between live and the hardware.
The color triggering protocol works fine too. no problem with that. (it works with midi notes sent to the controller... pitch means led number and velocity means color... works fine!)

I tested each unit separately.
Each one seems to work... fine.
The whole system doesn't work: only the first line of leds works... a bit... some mismatch between the real world and the liveset
I'm sure I'm not far ... but...

It isn't not only not optimized, not improved, but it doesn't work fine...
all ideas, improvements, fix would be very appreciate.

a little up, with hope

ok, now, it works!
there were several things badly done in the patch' architecture ... grrrrr

I'll make a precise description of what I did on my website asap!

Cool! Please let us know when its posted!

okay!
no problemo!

there are many purpose with this open-source way: share words/ideas, hope people could help me to improve it etc

but I did a thing very close to my need... so I just hope it could hekp people, but not sure

so here is the update.

the process is all the same as described in the first post of this thread.



this one collects all my liveset clips ID and works fine for sure ; it only stores a position ID + the clip ID
the position ID = x*100 + y where x = track number & y = scene number





this other one is feeded with the current song number (a song is 6 scenes, it fits with my hardware where I observe/control one song at a time)
when the song number changes, it makes an extract from all the collection with all clips in order to feed the matrix with the 8x6 clip IDs of the current song
this part works fine too. good feeding, good extraction etc.





the big hardcoded and ugly matrix.
feeded with the collection extract.
I have doubt about the big data flow that enters when it is feeded, but it works too.
probably, a JS version could be done, but if it would increase performance, it wouldn't fix my problem





the most little unit: the ledUnit
for a song, it observes and sends midi note corresponding to colors and off states.
this is the problematic part.





so I'd need help.
if I'm staying on the same song :
- and fire clip or complete scene etc NO problem. right collor, fast handling etc. perfect.
- fire clip (manually with mouse) in other song, perfect too, the current song shows from green (playing) to blue (present but not playing) etc perfect

the problem appears when I change the song.
some stays green but shouldn't be like that (should be off or blue)
etc etc

max windows complains with : incorrect IDs for the objects involved in the ledUnit patch.
I checked it, there is the correct ID ... but indeed, I guess at a time, cause there is a big data flow, inconsistency state appears, even very quickly, so max complains.


I just hope someone could help me
the problem seems to be my ledUnit patch, where I modelized the behaviour of states feedback and where I may have made a mistake...
Maybe, the whole concept (big collection with *only position/ID of clips + extracting things when song changes) isn't the good one)

I just hope someone gives me a feedback on this, help me as I'm trying to help with all the docs on my protodeck's page.
I worked on it in an open-source way, I hope people would help me to thank me about that


all the best,

Sorry Julien, I can't help you, you're a bit over my head. But I really appreciate the way your working. Posting the screenshots on the forum is a great way to build a collective knowledgebase- they will stay up over time I hope?

all will be on my website, for eternity

btw, I'm testing, I cannot understand where I made a crap
it seems to be tricky as noone helps here... and I know there are experts.

I found a way:
in the clip matrix handler patch, when the new song integer feeds the patch, I delay a bang 100ms after the number feed... it works.
so I guess it is a bit a workaround, I override something, I don't know what..




It works, but it has to be improved, cause I have around 0.6s delay when I change the song... very ok for perf but, not optimal!

I think your difficulty in getting advice might be that you are solving your own problems too quickly.

You might also change your thread titles so they read like something from Le Canard Enchainé instead of geeky Max talk.

:

not optimized means I still need help
but indeed, working harder often means finding the solution

btw, now comes the optimization time !