transform pixels to physical layout

[dbu]

for our installation, we will probably not have one BBB with straight led strips but drive LEDs arranged in panels. is there a way to define the mapping between the logical bitmap and the physical strip arrangement?

i guess that would belong into the ledscape driver itself to work for all processes that feed data to the pixels. if there is none, did you think about how to implement that? i can have a go at that, but ideally it would be reusable.

[RGB-123]

The BBB and ledscape should be considered to be more like a graphics driver card. I recommend all visualizations be generated by another linux or windows machine. Processing or other software for visualizations is also handy. Pinmapping should be handled by these "3rd party" applications. Right now the current Processing Examples - https://github.com/Yona-Appletree/LEDscape/tree/master/processing are very similar to the Fadecandy examples - https://github.com/scanlime/fadecandy/tree/master/examples/processing

[Yona-Appletree]

I'm closing this as per RGB-123's comment: The role of LEDscape is to push pixel buffers out to the hardware, and provide features that fit best at this layer (e.g. interpolation, dithering and luminance-correction). LED arrangement & mapping is diverse (and changes frequently) enough that any attempt we made to support the various options would often fall short of what people want to do.

Managing the layout (and potentially the visualization generation) on the BBB is a perfectly viable project architecture, but one that, in our opinion, should handled by separate software.

[dbu]

ok, the OPC.pde code looks like what i would expect. we are thinking about a distributed architecture with different programs that could be sending over OPC. in that case, defining the setup at the graphic producing side instead of the display will not be convenient. i guess we will do a proxy at some level that can split the image to several BBB and also handle the physical layout arrangements.