Daniel, I would like to come back on an earlier post of you concerning

Daniel, I would like to come back on an earlier post of you concerning patterns.
(https://plus.google.com/102282558639672545743/posts/VvRZmrvw6tJ)

I didn’t had the time at that moment to try it out but I would like to pick it up again.
Is this still the way forward to make a “pattern library” or did did it evolve already in the meantime ?

Ah, I’d missed this the first time around. After playing with it myself for a while there seem to me be two general approaches: “frame first”, which is Daniel’s approach, and “effect first” which is what I ended up with here: https://bitbucket.org/ratkins/ledeffects

I’m not sure if either is inherently “better” (in general, or for different types of patterns) or if it’s just that there are tradeoffs between the ease of expressing different ideas.

Being frame oriented makes it much easier to interleave other activity in between (reading sensor input, communication, etc…), which is why I tend towards that way.

I tried to put to code of the old post in a working example, but frustration is building up… whatever I try is giving me compilation errors. Painfull clear that my advanced c++ skills are very rusty after not being used for 20 years…
Strugling with what and how it should be in the .h, .cpp, .ino . Could somebody help me out by just making a runnable version of the codesnipets mentioned in the old post.

I can see if I can get something put together. Unfortunately - I’m behind on a large led installation for july 4th weekend, so my free time is starting to get very constrained. (The good thing is, I use this type of pattern interface in my own personal programming, so I should be putting things together that could be juggled/played with - unfortunately, the current state of my pattern/task control library is completely convoluted/thrown around).

Daniel yes, I tried this and I see why it’s more appropriate for the kind of “additive synthesis” stuff you’re doing. More of my patterns tend toward the "tread the LEDs array as an x/y matrix and do things like Snake or Conway’s Game of Life and it was easier to wrap my head around.

I’ll take a look at what you’ve got and see if it provides further enlightenment.

Robert, do I interpret you reply correctly that you successfully tried the example of Daniel. Do you mind sharing the source files ? As mentioned above, I didn’t do (advanced) c++ programming the last 20 years and then learn by example is the best approach to bring things back :wink:

I’m akin to Robert’s method for my projects as well, helps not make my brain melt. But I am currently just using separate .pdes for each effect which just concatonates into one main pde when its compiled. Is there a speed/memory benefit to moving those to .cpp format instead?

Peter no, I haven’t currently got any working code derived from Daniel’s example. I’ll give it a go at some point and definitely share it when I do.

There’s no speed or memory benefit to writing your patterns as separate .pdes vs .cpp files, it’s just a way of organising your code.