Is there a "generic" location in the code base for color question #603

fanno · 2024-01-31T23:48:37Z

fanno
Jan 31, 2024

Is there a location where i can "intercept" how colors are added/modifyed?

As i am new i have limited knowledge to the code base:

GFXBase.leds is where they are "stored" if i am correct, before they are drawn?

I "need" a location before they are stored or just before they are drawn.

GFXBase.leds is a pointer so i assume its hard if not impossible to add intercept when a index in the pointer is being set ? (i have limited c++ knowledge)

I assume i would only be able to add code inside say
GFXBase:
virtual void setPixel(int x, CRGB color)

Before actual draw would work too. "i think".

If you can point me in the right direction if its possible that would be awesome.

-Thanks

fanno · 2024-01-31T23:52:34Z

fanno
Jan 31, 2024
Author

I forgot to say that only "issue" is that currently i see in the various patterns sometimes setPixel (or equivelint) or a direct pointer to GFXBase.leds is used.

I would think that really only "setPixel's" should be used everywhere but I could be wrong.

0 replies

robertlipe · 2024-02-01T05:09:18Z

robertlipe
Feb 1, 2024

GFXBase.leds is where they are "stored" if i am correct, before they are drawn?

True.

I "need" a location before they are stored or just before they are drawn.

That's where they're drawn to, period. If the effect is drawing the wrong color, fix the effect. GFXBase.leds is a pointer

It's an array,. I'm pretty sure. I think, once again,that you're asking about details based upon your assumed guess of a solution instead of asking the real question. What are you REALLY trying to do?

0 replies

fanno · 2024-02-01T13:33:32Z

fanno
Feb 1, 2024
Author

I am testing the CRGBW "hack" but i would like to find a way to implememt it so it would work "all" the exsisting patterns and such.

(I got my strip working /lighting up but of cause, colors are wrong due to the w "data slot".)

It looks like patter's code is a "mess" of different styles, some using points some using setpixel...

My main issue is why maybe i did not ask directly is i am new and most defiantly do not understand the code base yet and don't really know "what to ask"

I am not intentionally trying to waste your time tho i can see how it could look like it i am sorry.

i am having trupple locating where the the code base GFXBase.leds is "used/read" via/in fastled i only see few fastlet.show(...) and it don't look like something "global"
it is in: CountEffect.Draw

its my understanding that fastlet.show() is the one that do the actual "draw" of cause i can easily be wrong.

my initial ida was sometthing like:
GFXBase
virtual void setPixel(int x, CRGB color)
{
if (isValidPixel(x))
#ifdef ....RGBW....
leds[x] = color //preform "hack" to convert CRGB -> CRGBW at least untill fastled get correct support for it.
#else
leds[x] = color;
#endif
else
debugE("Invalid setPixel request: x=%d, NUM_LEDS=%d", x, NUM_LEDS);
}

But issue some stuff don't always use the set buttons so perhaps just before "render" the same could be done.

I Tested creating a clone of "LEDStripGFX" and naming it eg LEDStripRGBWGFX

But having to create clone of each class seems like wrong approach.

0 replies

robertlipe · 2024-02-02T00:02:37Z

robertlipe
Feb 2, 2024

It's going to be an awful fit. I don't see a universal solution that would let you easily mix both strip types within a. Project. The lowest risk/cost that I can think of is to fundamentally make the rgb struct. A. RGBW. Struct and either provide a. Default fill for W When it's created and/or change the code so that a W "pixel" if filled if needed. This assumes that fastled. Now wants to eat 32.bit pixels RGBW instead. If 24.bits.foenjust.tje three primaries. That should at least help the effects code from knowing that each pixel is 24 bits. It's hopefully obvious that that breaks Mesmerizer, but you're going to have a custom. Build for this anyway.

…

On Thu, Feb 1, 2024, 7:33 AM Morten Hundevad ***@***.***> wrote: I am testing the CRGBW "hack" but i would like to find a way to implememt it so it would work "all" the exsisting patterns and such. (I got my strip working /lighting up but of cause, colors are wrong due to the w "data slot".) It looks like patter's code is a "mess" of different styles, some using points some using setpixel... My main issue is why maybe i did not ask directly is i am new and most defiantly do not understand the code base yet and don't really know "what to ask" I am not intentionally trying to waste your time tho i can see how it could look like it i am sorry. i am having trupple locating where the the code base GFXBase.leds is "used/read" via/in fastled i only see few fastlet.show(...) and it don't look like something "global" it is in: CountEffect.Draw its my understanding that fastlet.show() is the one that do the actual "draw" of cause i can easily be wrong. my initial ida was sometthing like: GFXBase virtual void setPixel(int x, CRGB color) { if (isValidPixel(x)) #ifdef ....RGBW.... leds[x] = color //preform "hack" to convert CRGB -> CRGBW at least untill fastled get correct support for it. #else leds[x] = color; #endif else debugE("Invalid setPixel request: x=%d, NUM_LEDS=%d", x, NUM_LEDS); } But issue some stuff don't always use the set buttons so perhaps just before "render" the same could be done. I Tested creating a clone of "LEDStripGFX" and naming it eg LEDStripRGBWGFX But having to create clone of each class seems like wrong approach. — Reply to this email directly, view it on GitHub <#603 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD3YGWDQQV7BBUSGZGTLYROKTRAVCNFSM6AAAAABCT52CMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGMZVGAYTM> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/603/comments/8335016 @github.com>

1 reply

fanno Feb 2, 2024
Author

Interesting thought.

can i ask how you invision i would do about doing that ?

change CRGB inside fastled it self ?

robertlipe · 2024-02-02T23:58:56Z

robertlipe
Feb 2, 2024

It's worth considering that there may be a FastLED crgb and a NightdriverLED crgb. (The byteorder depends on some definitions and we have to have something like a crgb for the HUB75 path that goes down to SmartMatrix instead of FastLED. Stick it in a debugger. Study the code. Break it into two halves. Make it work with FastLED. Make it work with NightdriverLED. It's likely to take actual work beyond minor tweaks. We've not had anyone else rush into the conversation reporting success with RGBW so it's up to you to blaze this path.

…

On Fri, Feb 2, 2024, 12:53 PM Morten Hundevad ***@***.***> wrote: Interesting thought. can i ask how you invision i would do about doing that ? change CRGB inside fastled it self ? — Reply to this email directly, view it on GitHub <#603 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD343IZJWMLJWIYVCWHLYRUY3BAVCNFSM6AAAAABCT52CMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGNBZHA3TE> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/603/comments/8349872 @github.com>

0 replies

fanno · 2024-02-24T15:28:31Z

fanno
Feb 24, 2024
Author

hello again

I managed to make it work hacking

    virtual void setPixel(int x, CRGB color)
    {
        if (isValidPixel(x)) {
            #ifdef USE_RGBW
                setRGBW(leds, x, color);
            #else
                leds[x] = color;
            #endif
        } else {
            debugE("Invalid setPixel request: x=%d, NUM_LEDS=%d", x, NUM_LEDS);
        }
    }

Then i have this as well as a CRGBW class similar to the hack
This will "offset" the data inside the original led data. inserting the white as value 0 in this case tho it could be made to be "automaticly" assigned a value and still only sending RGB to night driver.

its possible this could be done using some fancy pointer magic, that is currently outside my knowledge

inline void setRGBW(CRGB* led, int index, const CRGBW& color) {

	float start = index * (sizeof(CRGBW) / sizeof(CRGB) );

	int _pos = start;

	switch (index % 4)
	{
		case 1:
			led[_pos].g = color.r;
			led[_pos].b = color.g;
			led[_pos+1].r = color.b;
			led[_pos+1].g = color.w;
			break;
		case 2:
			led[_pos].b = color.r;
			led[_pos+1].r = color.g;
			led[_pos+1].g = color.b;
			led[_pos+1].b = color.w;
			break;
		default:
			led[_pos].r = color.r;
			led[_pos].g = color.g;
			led[_pos].b = color.b;
			led[_pos+1].r = color.w;
			break;
	}
}

inline void setRGBW(CRGB *led, int x, CRGB color) {
	CRGBW rgbw;
//	rgbw = color;

	rgbw.r = color.r;
	rgbw.g = color.g;
	rgbw.b = color.b;
	rgbw.w = 0;

	setRGBW(led, x, rgbw);
}

This works with all the effect i have tested that use setPixel or use functions that use setPixel

for samble setPixelsF wont work (without further edit) because it do stuff like like this:
leds[(int)p] = bMerge ? leds[(int)p] + c : c;

so when its setting a value in "red of second led" it is setting white in the first led.

I realize i am "hacking" something for its none intended usage.

If "core" allowed for "interrupt" of some kind to allow modification of the values could allow for some "dynamic" features on "all" effects. without changing all effects.

color corrections for colorblindness comes to mind, this would mean without changing the code of all the plugins logic ect.

but depending on such a implementation it would allow for the RGBW hack depending on the implementation.

if it was implemented so one would have a "getPixel" and never access the leds pointer directly and the getPixel would have a ability for similar "interupt" as setPixel it would in the RGBW hack case return color data from a different offset location in the pointer array.

Again i am not trying come in here as a "new/noob", and suggest changing everything. i realize this is kinda fundemental

0 replies

Thermotronica · 2024-02-24T17:22:39Z

Thermotronica
Feb 24, 2024

Sorry

1 reply

rbergen Feb 25, 2024
Maintainer

Thank you.

fanno · 2024-02-25T10:53:08Z

fanno
Feb 25, 2024
Author

Hello again

a bit more Testing, i changed:
setPixelsF to use getPixel and then added code reverse of the setPixel mod i made works.

        float p = fPos;
        if (p >= 0 && isValidPixel(p)) {
            setPixel((int)p, bMerge ? getPixel((int)p) + c1 : c1);  <<<<<<<<<<<<<<<<<
        }

curently i dont know whats "wrong" with the fire color it is "just" pure white flickering a littel i tracked it down to ColorFromPalette via GetBlackBodyHeatColor in the fireeffect (for testing i hacked ColorFromPalette (for testing)) to lower green and blue componenet by /10

to get a flickering "red ish"

So as of "prof" of concept it is possible. if one were to modify the base and only use get/set pixel rather than direct access to the led memory (can use functions that "result") in get/set

while doing this i also noticed that:
getPixel(int16_t x, int16_t y)
also do "direct" access "should" it not be like this ?

    virtual CRGB getPixel(int16_t x, int16_t y) const
    {
        if (isValidPixel(x, y))
            return getPixel(XY(x, y)); <<<<<<--------------------
        else
            throw std::runtime_error(str_sprintf("Invalid index in getPixel: x=%d, y=%d, NUM_LEDS=%d", x, y, NUM_LEDS).c_str());
    }

I sopouse there would be some preformance over head? tho i would think the code is more "clean" (not sure if thats the right word i would use) ?

I realize there is A LOT of locations in gfxbase that "would" need to be changed.

eg:
why would this not "already" be done ? preformance?
leds[XY(x, y)] = leds[XY(x, y + 1)];
to
setPixel(XY(x, y), getPixel(XY(x, y + 1)));

why would this not "already" be done ? preformance?
leds[XY(x, y)] += leds[XY(x, y - 1)];
to
addColor(XY(x, y), getPixel(XY(x, y - 1)));

(don't really like this but don't see another way, propearly lag of knowledge)
leds[XY(x, y)].nscale8(scale);
to
temp = getPixel(XY(x, y));
temp.nscale8(scale);
setPixel(XY(x, y), temp);

my "main" idea behind a single "entry/exit" point is that if changes are required for "what ever reason" only one location need to be changed? and ofcause also allow a "hook/interupt".

Again sorry if i am over stepping my bondery's for idears.

0 replies

fanno · 2024-02-25T12:11:31Z

fanno
Feb 25, 2024
Author

eg:
https://github.com/fanno/NightDriverStrip/blob/gfxbase-set/get/include/gfxbase.h

0 replies

robertlipe · 2024-02-25T13:03:26Z

robertlipe
Feb 25, 2024

Hi, Fanno.

Since we last "spoke", I've had a reason to dig into RGBW strips more deeply. I currently have "BTF-LIGHTING WS2814 IC RGBW RGB+Cool White" running on my ESP fixture, albeit with WLED. I have the "BTF-LIGHTING WS2805 IC RGBCCT Addressable Dual Data LED" on the way. It has RGB + one ugly white + one white in the color God intended. Each "pixel" (handwaving that each slot on the bus controls multiple packages) therefore can contain either 32 (RGBW) or 40 (RGBWW) pixels.

As a sidebar, I have a couple of OTHER new packages in flight from BTF that each represent something that I haven't actually seen before. It's a pretty exciting time.

I've spent some time staring at the oscilloscope and the internals of NeoPixel (to be reductive for the USE_281X case, Makuna NeoPixelBus:WLED :: FastLED:NightDriverLED) as well as reading the data sheets and think I have my head around it.

The actual controller (SK6812 or WS2805 or whatever) is a pretty dumb part (citation https://datasheet.lcsc.com/lcsc/2306301035_Worldsemi-WS2805_C5446697.pdf - Google Translate is tedious, but workable) as shown in the diagram on the second page, it outputs separate pins for RG and B as well as W1 and W2, but it's up to the strip designer to decide whether W1 goes to C3K or C6K for white color. It's also up to software to decide how to gamma mix the whole shebang on whether you use one or more of the white strips to just ratchet up brightness, color be damned (and holy cow, your powe supply better be prepared for every pixel to be 'on' in a virtual 0xff.ffff.ffff (SWRGB - soft, warm, reg, green, blue - and totally disregarding color mapping to bits for now) so you might want to correct for color purity or maximum brightness or power conservation (why use 3bulbs when one and a boop from another will do?) and so on. So figuring out both which "W" output is connected to which bulb and the order of the bulbs in the packetized frame is a challenge and expressing that withing NightDriverLED whee we have COLOR_ORDER to consider and probably should think about allowing different strips on different channels, though I think that's beyond a casual configuration in NDS today.

Most of all, you can be potentially almost doubling (3->5) the workload on the host controller. It's totally worth the time to have the host (that's the ESP32 in our case) stack the deck of pixels "correctly". If I drive the strip I have now (only one "W") as a plain ole 2812, the optimal ordering seems to be GRB, which is pretty common. If I bring in the W, it seems best to use BRG, and swap W and G. This allowing mixing RGBW in the way we expect. Once my RGBWW arrives, I'll know more about it.

For performance reaons, you really want the code to plop down the RGBWW value in memory such that the DMAs can slurp them up right from memory, leaf-blow them out the appropriate pin, then let each LED controller play "99 bottles of beer", strip off 24/32/40 bits off for their own use then pass all the bits downstream.

So really, you want structs CHSV and CRGB to get new members for w1 and w2 so that when they're template expanded out, they'll be the right size for whatever strip is being exploded so that the DMA controllers will know the right number of pixels. (I'm not confident that your "if offset = 2 blue = green" style of code can never work, but I'm pretty sure it's going to be tough to bullet proof that to walk exactlyto the end of the array and no further.)

Looking in .pio/libdeps/*/FastLED/src/pixeltypes.h in my project, I don't see evidence of RGBW support. This feature has been long requested in FastLED but FastLED has just lost their rhythm trying to support new hardware (ESP32-S3), spending development time on low-end combinations (serial + wifi + a thousand blinkies on a single-core, 8-bit system at 10's of Mhz is just overextended) and the loss of a key developer. (RIP Dan Garcia.) This opening is why newer packages like Makuna's have been able to get a toehold.

There are a variety of FastLED branches with some traction - some as old as 4 years - with some amount of RGBW support. Without endorsing any of them, you may find inspiration in, e.g.:
https://github.com/Charles-Goodwin/Lamp/blob/main/FastLED_RGBW.h
https://github.com/coryking/FastLED
https://www.partsnotincluded.com/fastled-rgbw-neopixels-sk6812/
https://www.partsnotincluded.com/fastled-vs-adafruit-neopixel-library/#comment-125
...and more. Be sure notice the comments about them being on hold and that you should wait for updates on Google Plus to get some idea how contemporary and active that work is, but the basic ideas should get you going. Bumgardner's approach has merit.

You can see Dan's (focalintent's) statement of progress in FastLED/FastLED#579, but that works stalled out for the obvious unfortunate reason.

Zack's work was pulled into the official tree, but, bafflingly, in 'experimental'. (I think they're just deadlocked on build/resource/test/expertise resources.) That PR was (the poorly nameed) https://github.com/FastLED/FastLED/pull/1544/files Notice that it follows the same basic ideas that we've talked about here repeatedly. Really, you'll want to read up on

https://github.com/search?q=repo%3AFastLED%2FFastLED%20crgbw&type=code

before attempting to add officially this into fastLED. Issue 1540 (Hey, Team Commodore!) seems to be the zero ground for discussion, with Zach kind of leading it. (IMO, it's fallen into the trap of trying to add substantial new code FIRST to the most prolematic 8-bit CPUs in asm instead of doing it on a modern CPU there the C++ IS tihe implementation...but I'm not doing the work and I'm generally repectful to not tell someone else how easy their job is.)

In short (too late, but "loads of information" is kinda my thing) I'd strongly resist the urge to try to ingegrate a "fix" for this in NightDriverStrip directly. This belongs in FastLED with jst a smattering of code here to expose the 'w' memberS to effects.

For one-off use, try to find one of the existing branches (or evern the stuff in FastLED's trunk or dev branches now now) and integrate that.

For doing this well, buzz Zach and the team at FastLED and coordinate allocate resources (hardware, programmer time, automated testing, etc.) to try to move the state of the art forward.

Finally, there is the "hold my beer" option of replacing FastLED in NDL with Makuna's NeoPixel. It's not all roses there, either (see dated info at https://blog.ja-ke.tech/2019/06/02/neopixel-performance.html - and many of the conclusions have changed) but using the same core as WLED has a lot going for it.

To the question you actually asked, the performance overhead of [gs]etPixel() over just tweaking array members directlybefore calling .show() is pretty large. These are operations done many tens to hundreds of thousands of times per second on a system with lots of pixels and heavy animations at high frame rates. Even those calls to isValidPixel should, IMO, be moveed out of the production builds, IMO, and left only in the debug builds. ISTR that it's a minority of effects that een call setPixel()-like methods, preferring to scribble in the "frame buffer" directly.

As you're presumably about to discover, if you haven't done so yet, the distance between "works for my device for my needs" and "solid enough to support other people on arbitrary configurations of ridiculously large builds" can be a large one. Still, hopefully I've given you lots of options to "draw" from in your quest. (Computer Graphics Dad Joke..)

1 reply

fanno Feb 25, 2024
Author

Indeed it i realise it could cause a ton of calls.

I am not thinking to call it every time before "show" it would be called become a pixel, tho everytime a effect would make changs that would result in calls.

But yes it would be manny manny calls. i am "new" to c++ ect. in terms of preformance is it something that could be quantifyed? without actuarly running some sord of benchmark, (maybe from theoretical data/knowledge).

i mean is it something that would end up having an "effect"

fanno · 2024-02-25T19:01:51Z

fanno
Feb 25, 2024
Author

could an approach be to make a "new" RGBWW class that everything is stored in.

and then in one location in the code depending on settings ect it would translate the RGBWW to RGB og RGBW or keep RGBWW

I also realize this would have a huge impact of memory it would propearly more than dubble the memory usage because you need a location for the "raw" RGBWW and a location for the "translated RGBXX

(you problerly thought of thinks like this already, i don't expect i bring much new things. if any)

0 replies

fanno · 2024-02-25T22:57:36Z

fanno
Feb 25, 2024
Author

i am thinking something like this:

NDRGBWW *leds = nullptr;
CRGB *fastleds = nullptr; << renamed så not much code would have to be changed other than where its mapped to fastled from leds > fastleds

FastLED.addLeds<.......>(devices[channel]->leds, ........);
would be changed to
FastLED.addLeds<.......>(devices[channel]->fastleds, ........);

this would mean "exsisting" code would modify the "raw" with RGBWW

NDRGBWW is a 5 byte struct that has RGB + the 2 whites.

new function in gfsbase.h

    virtual void updateLEDS()
    {
        for (.........) {
            fastleds[x] = leds[x].rgb(); <<<< extract the RGB data
            hackToMakerRGBW(fastleds, x, leds); <<<<< hack code like ai curently have to make RGBW work
            colorblindness stuff ?....

            
            fastleds[x] = leds[x].rgbw(); <<<< when fasthas/get direct RGBW support?
            fastleds[x] = leds[x].rgbwW(); <<<< when fasthas/get direct RGBWW support?
        }
    }

this would be called once. in effectmanager.h right after Draw() name og updateLEDS propearly not the best

what i meant with using more data i know memory can be issue.
but NDRGBWW could be has different versions depending on what you wanna build.

P.S.

I made a dirty quick test and it works, just something to maybe contemplate.

I don't know about c++ yet but pehaps its posible to instead of having memory for NDRGBWW and CRGB that you could populate
CRGB (fastleds) with referances to NDRGBWW or parts of NDRGBWW
tho i suspect this would not work.

I think another benefit of creating a custom data object (NDRGBWW) that one would not be "tied" to a specific framework, one could then from that object output formats for different "frameworks"

NDRGBWW should pehaps be named NDLEDDATA instead as its then not "locked" to RGB ... or RGBW or RGBWW RGBWW_THE_NEXT_THING

My main idea behind NDRGBWW is "flexibility" and and ND could be "ready" for RGBW even before fastled is.

-Thanks

Once again as usually, i am still learning so please bare with me. just throwing some thoughts out there. there are properly good reasons for the choices made and i just don't know them or have the knowledge needed to see it.

0 replies

fanno · 2024-02-25T23:02:39Z

fanno
Feb 25, 2024
Author

Think i forgot some context/comments inside updateLEDS function examble.

the content of this function would be dependent on build parameters and it would not do the "All" at same time its just to show what "could" be inside this

other than moving data from the "raw" to the output data.

0 replies

robertlipe · 2024-02-26T06:40:07Z

robertlipe
Feb 26, 2024

You have one bit right:

could an approach be to make a "new" RGBWW class that everything is

stored in. I agree that the fundamental data structure needs to be changed. (This is the basis of one of the works I cited, https://www.partsnotincluded.com/fastled-rgbw-neopixels-sk6812/) The FastLED implementers do, too. I do not think that trying to paper over this way up (in the software stack ladder) in ND instead of fixing it fundamentally in FastLED is going to be satisfying for anything other than a few special cases. Things like blend() needs to know the W1/W2 values of adjacent pixels in order to get the luminance and saturation calculations correct. The color correction (setTemperature, setCorrection) calls are all going to have to actually know about the color and presence of the white values and not just have them sidecar'ed outside the fundamental data structure. The various brightness functions need to know how to mix the existing bulbs and the (lower power, higher brightness, never actually really "white") bulbs to make something that doesn't jump around on the color wheel. If you don't include it in struct [C]RGB, anything involving offsets and sizes is going to break, often in non-obvious ways, and trying to paper over it in a single spot in the calling code is just going to be increasingly painful as you keep adding special cases. HSV->RGB roundtrips are just going to be (even more) mathematically bizarre. Approaches like https://github.com/sythatic/FastLED-RGBW/blob/devop/CRGBW.h simply aren't going to get you past anything but the simplest cases. (You might not NEED anything but the simplest cases, but this project does...) You might come up with something that works for your specific hardware and effects, but do do this right is going to take fundamental changes in FastLED - changes that have been near the top of the TODO list for them for some time, haven gotten some attention, but keep turning out to need larger and deeper attention than anyone has been able to give it for the couple of years that people have been working on it. (If it was something simple that worked to satisfaction, one of the several existing branches/patches would have been accepted.) You may be able to produce something that "works", but doing this right is going to need deep fixes in code that we don't control. I don't mean to sound discouraging, but if you're not already pretty close to your happy place with your project, your efforts will likely be better placed in working with the FastLED team to address some of these (and the many other) issues inside FastLED itself and/or using code that already supports RGBW/RGBWW. I just helped a friend with a WS2814 RGBW project and even though I'm waist-deep in the NightDriver project, it was simply a better fit for WLED. Setup was weird (I had to change the LED type, change the color order, and then activate "swap white with green") but it worked "brilliantly". I hate to sound like that car mechanic that's telling you that you need a new engine because you can't just turning up the stereo to cover the crazy sounds it's making, but here we are.

…

On Sun, Feb 25, 2024 at 5:02 PM Morten Hundevad ***@***.***> wrote: Think i forgot some context/comments inside updateLEDS function examble. the content of this function would be dependent on build parameters and it would not do the "All" at same time its just to show what "could" be inside this other than moving data from the "raw" to the output data. — Reply to this email directly, view it on GitHub <#603 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD32OFIVLLGV6IZFGC4DYVO7JVAVCNFSM6AAAAABCT52CMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKOBVHE2DK> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/603/comments/8585945 @github.com>

0 replies

fanno · 2024-02-26T08:31:03Z

fanno
Feb 26, 2024
Author

Hello again

I don't mean to sound discouraging, but if you're not already pretty close
to your happy place with your project, your efforts will likely be better
placed in working with the FastLED team to address some of these (and the
many other) issues inside FastLED itself and/or using code that already
supports RGBW/RGBWW.

oh i am happy with what i have working, i am just playing around trying to learn things.
as i have same any times i am not trying to come in here and expect changing everything. =)

I am with what i working on, just working on the "base".

In my case i am properly just going to "ignore" the W value and leave it 0/OFF, unless its on for permanent just white lighting

as to "NDRGBWW" i am properly going to do that as a "clone" and play with that some more.
I will properly ask questions about it here and there. Tho i am going to Italy for a week of work, so unless i can find work time in the hotel room doing nothing else it will be a while =)

0 replies

robertlipe · 2024-02-26T10:19:50Z

robertlipe
Feb 26, 2024

Cool. Sometimes we (I) can give authoritative help or a gentle nudge to get devs on track and make them happy. Sometimes, tough love is the most honest thing we can offer. My own WS2814A IC RGBW strip arrived today and my WS2805 (RGB + WW + CW) will arrive next month. These will surely increase the amount of exposure of ND to these types of strips. Certainly bridging the gap from 24 to 40 bits (in a world where we're already RAM and DMA-challenged) will be interesting. I may do some wacky USE_W281X effect that does something corny like modulating a two different easing effects of white glitter "chasers" atop a rainbow or something just to show we can. This would fall very carefully into that category of "stupid LED tricks" like configuring a 70 LED strand to be a 70*5/3 LED strand just so the pixel buffers are large enough and then "spread out" the rainbow effect (possibly generating it myself) to skip over those rascially WW/CW pixels) and maybe introducing a concept of layers to put glitter/sparkles/lightning (summoning my inner 7 y/o), perhaps from another timer thread, atop the primary "framebuffer". Maybe there's something we can do that's visually interesting that doesn't totally terrorize the code, that'll serve as a guide for the next one to stumble into this combination. It's probably more of a documentation exercise than a coding one. It's just bits... However, my inner grouch will probably stomp into the room at some point. These strips are still pricey. The things they're good at (posible face-melting brighess, as borne out by the ammeter on the display of my bench power supply, color purity, bouncing between relativelye low-power white modes and RGB modes, etc.) aren't particularly the things that NightDiver is good at. Perhaps I lack imagination. Perhaps I'll embrace that providing even a few hacky examples will inspire that person that's lighting a museum display that wants super-boring white 99% of the time but wants to bust a move with a rave the other 1%. Perhaps I'll roll up my own sleeves and tackle the opportunity in FastLED. (Magic 8-ball says: "Unlikely".) Oh. And keeping with the conversation in another thread tonight, some number of our WS281X users are using them for cases of remote display use, orchestrated by our ColorServer. To really support and additional one or two color channels, ColorDataTaskEntry() needs to handle things like the server sending RGB, but our frame buffer being RGBWW. Now memcpy() off the network packets into the dma send packets doesn't work; you need to actually handle a color-by-color request, adding or stripping one or two members for every packet. No matter what you do, it's going to be slower than memcpy(). So do you need a way to syncronize yoru actual strip configuration with the server, so it can send you optimally configurted packets on the premise that your colordata server is more powerful than your ESP32 and you should make that ITS problem instead of yours, inside a per-pixel/per-frame loop? I dunno. It's still relatively early days for these. That FastLED hasn't seen enough demand to support them is telling. That Makuta HAS is also telling. I think that we, a pretty small project that MOSTLY targets devs over end users, are really doing to need to listen for a while to see how these are actually going to be used in the real world before we figure out our permanent strategy. Do we drive FastLED changes? Do we replace FastLED? Do we just offer a few sample users for that aforementioned museum art display to build their own effects? (IMO, it's pretty rare for anyone to ask us for elp developing a custom effect. Either we're really good at allowing FastLED code to Just Work or people don't really do thaat...) Given that memory use and DMA bandwidth are two of our largest enemies, do we focus on custom confiurations specicfically to W vs. WW or do we just rally around two whites and hope that at at least one of those pins is connected to a bulb? I dunno. I'm not totally sure where we go from here. My plan is to listen to folks like you trying to do something outside the lines, to try to learn more about what people are actually using these for, and try to understnad our place in the larger blink-o-sphere of code and projects.

…

On Mon, Feb 26, 2024 at 2:31 AM Morten Hundevad ***@***.***> wrote: Hello again I don't mean to sound discouraging, but if you're not already pretty close to your happy place with your project, your efforts will likely be better placed in working with the FastLED team to address some of these (and the many other) issues inside FastLED itself and/or using code that already supports RGBW/RGBWW. oh i am happy with what i have working, i am just playing around trying to learn things. as i have same any times i am not trying to come in here and expect changing everything. =) I am with what i working on, just working on the "base". In my case i am properly just going to "ignore" the W value and leave it 0/OFF, unless its on for permanent just white lighting as to "NDRGBWW" i am properly going to do that as a "clone" and play with that some more. I will properly ask questions about it here and there. Tho i am going to Italy for a week of work, so unless i can find work time in the hotel room doing nothing else it will be a while =) — Reply to this email directly, view it on GitHub <#603 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD36PE6OTTOEN63K5AXDYVRB5HAVCNFSM6AAAAABCT52CMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKOBZGM3DQ> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/603/comments/8589368 @github.com>

0 replies

fanno · 2024-02-26T19:31:06Z

fanno
Feb 26, 2024
Author

I just have a thought about bandth wirth and memory usages

instead of 8 8 8 8 8 one could co something like

RGBW
8 8 8 7 +1

where W part has slightly less resolution but the spare bit tells if its W1 or W2

Yes w1 and W2 could be on at the same time. i guess but i think most normal use case you would use one of them

8 8 8 6 +2
even lower resolution but you can sue the 2 spares to tell if both W1 and W2 should be on (same brightness)

of just
8 8 8 4 4

0 replies

fanno · 2024-02-26T19:33:23Z

fanno
Feb 26, 2024
Author

forgot to say that ofcause the memory usages going out to the led's would in most likelihood need be 8 8 8 8 8 if it was w1 and w2

0 replies

robertlipe · 2024-02-26T21:14:06Z

robertlipe
Feb 26, 2024

The dma controller need so see a block of contiguous memory that it can pick up and. Leaf-blow out of the data pin, either via SPI or rmt or whatever. FastLED and others spend their lives stacking the deck exactly so the hardware can do this. If you're. Willing to bit bang it there are all kinds of compression tricks you can do but it's probably a 100x or more performance penalty.

…

On Mon, Feb 26, 2024, 1:33 PM Morten Hundevad ***@***.***> wrote: forgot to say that ofcause the memory usages going out to the led's would in most likelihood need be 8 8 8 8 8 if it was w1 and w2 — Reply to this email directly, view it on GitHub <#603 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD3YVVF2QKTP2ZPWMLQTYVTPQ5AVCNFSM6AAAAABCT52CMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKOJWHA2TE> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/603/comments/8596852 @github.com>

1 reply

fanno Feb 28, 2024
Author

I don't know the tearm "bit bang" is it this https://en.wikipedia.org/wiki/Bit_banging?

robertlipe · 2024-02-28T12:16:40Z

robertlipe
Feb 28, 2024

Yes. Sorry. It's a common term in embedded development, but it is admittedly pretty rare outside that world. It's when the stream of bits implementing some kind of communication is explicitly created under control of a computer in software instead of being delegated to hardware that's responsible for this. In the name of readability, the Wikipedia article doesn't adequately describe how terrible this actually is in the real world. There's the added reality that even if you knew how exhausting it actually is, the WS281X protocol (the precise stream of bits placed on the Data Output line that is then examined and decoded by chip like the World Semi WS2811 that is used to drive a couple of chips (Leading to the "COB" or "Chip on board" term you've probably seen in lighting products) or the WS2812 that embeds that cip directly into the LED's own package, typically the 5050 that's 5.0mm square because it's moderately fast and while a 50% allowed variation sounds generous to achieve, it's actually quiet brutal and missing that cadence (rhythm) just once can result in losing the framing (your position int he stream or packet or in our case, video frame) losing synchronization which can glitch the make the chips lose their place and everything physically further downstream (away from the computer) being unable to recover. This results in a visually disorienting blink or flash of that entire remaining piece of the strand losing color synchronization. The example fragment uses an example sending one byte on an SPI bus. This bus uses one pin for data (well, one each direction), one pin to tell the receiving chip when to pay attention, and another that encodes a clock signal that tells the receiver exactly when to sample that data line to read. If you have the luxury having an additional clock signal, that's lovely but you know in a common serial port or in our own WS281x chips, we don't have a pin for clock, we either have to encode the position inside the data (RS232 serial does this via start and stop bits which are 1.5 times longer than the normal data bits which allow the receiver a chance to find its position in the stream of bits or, like the WS281x, just hold your breath, observe the leading edge of the change of the first bit, and rely on the clock timing of the sender and the receiver to stay locked to each other. This is why 281x is called a "clockless" design and it's one eason we're slow - and inexpensive - compared to newer designs that can spare more pins, such as the APA102 lighting. Since there is no clock, the sender and receiver just have to externally agree upon how quickly the bits will flow. You may remember configuring a serial termainl or modem to use 9600bits per second - so every 104 milliseconds there was a new characgter started. Our clock rate is actually 800,000 bits per second. This is too fast to rely on interrupts or even timers, so it's often done by countin gthe number of clock cycles use in the respective senders and receivers. You can see this beign micromanaged (literally!) in fastled by the code at https://github.com/FastLED/FastLED/blob/master/src/fastspi_bitbang.h and a chip-specific interface like https://github.com/FastLED/FastLED/blob/master/src/platforms/avr/clockless_trinket.h (this is why FastLED relies on templates to try to optimize as mch of the handling s it does.) You can imagine that this is all terribly messy to get right in isolation. It's even worse when you're not the only code running and the networking or a timer interrupts you, breaking your rhythm or if you're managing a lot of pixels. 30 frames per second times 1500 pixels times 256 values for each of red,g reen, blue (and now, two whites) time ten pins at 800,000 bits per second is just plain hard to manage. You can start to get some sense of discomfort by reading the chip data sheets or articles like the small series at https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/ OR We can forget all of that, program dedicated hardware in a chip somewhere to handle this, and just pass a stream of bytes to a controller somewhere, let it manage the details of carrying the pixels, and let it tell us when it's (about to be) done. In the ESP32 devices, there are two peripherals onthe chip that can be (mis)used to delegate this to: the i2s controller (like i2c, but optimized for audio data), the remote control transceiver (optimized for IR transfer, but somewhat practical for arbitrary bit manipulations with little overhead), or in the post-2019 parts the fast GPIO controller. Chapters about each could be - and have been - written, but the idea is that you just build up frames of RGB{WW}, point the controller to the start, do some setup, then get an interrupt upon completion to either get more or to end. Why have I just explained all this to death? You proposed reducing the memory footprint by changing the layout in memory to reallocate the bits provisioned to each bulb type or to implement a run length encoding. If you're managing a few dozen bulbs and you're already having to touch every bit on their way to the device _anyway_ that might not seem totally terrible because you're already suffering decoding and moving those bits and their demanding timing anyway. For a real-world number of pixels, though, we want to build frames in memory exactly like the WS281x's want to consume them, hand them to hardware, and NOT touch the individual bits, repacking them, swapping green and white, deciding that whiteness only needs five bits, decoding RGB565->RGB24, handling palletization, etc. We want to build frames in memory looking like the top graphics at https://blog.ja-ke.tech/2019/06/02/neopixel-performance.html so that we can just hand them over. THIS is why we want struct RGB{WW} in the C++ to look exactly like what the pixels want to eat. We want to be able to allocate, fill move RGB values around, point the DMA controllers to the base/size (it's a little more complicated that, but nowhere near the timing horrors I've tried to convey above) and never touch those values again. Additionally, given that so much of our memory in ESP32 is PSRAM and handled via a bus arbiter that can slow to turn around (writing blocks is fast. reading blocks is fast. interleaving writes and reads that need address and clock to be renegotiated on each transfer is about the cruelest thing you can do to performance on these.) you very much strive for the frame buffers to be "write-mostly" if not strictly "write-only" and definitely not be twiddling bits or even bytes inside the frames as you go. I know that I've just typed a small textbook, but hopefully this explains WHY you really want to build RGBWW as contiguous streams of bytes inside a large frame instead of building parallel arrays or pointers-to-pointers or "sidecars" of extra white values or such. It may seem quaint to drag up memories of our old serial terminals and modems, but some amount of architecture and context really is necessary to understand to hit our performance goald for thousands of pixels at many refreshes per second over just a few wires and with low-cost parts. Enjoy the journey.

…

On Wed, Feb 28, 2024 at 4:08 AM Morten Hundevad ***@***.***> wrote: I don't know the tearm "bit bang" is it this https://en.wikipedia.org/wiki/Bit_banging? — Reply to this email directly, view it on GitHub <#603 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD36THCQBFBHNRMCKM23YV362FAVCNFSM6AAAAABCT52CMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DMMJWGM3TS> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/603/comments/8616379 @github.com>

0 replies

fanno · 2024-02-28T20:47:26Z

fanno
Feb 28, 2024
Author

Hello

First of all, thanks or the comprehensive explanation.

I admit i just google and clicked the first thing because i did not know what it was , but i asked for clarification because i was not sure.

I will read it again in more depth when i get from from Italy (including linked resources).

Thanks again so much for your time. i know this response cant justify your lengthy post, but its late and i am off to bed.

Just wanted to thank you.

0 replies

fanno · 2024-04-08T18:55:33Z

fanno
Apr 8, 2024
Author

I know if is a huge change: (and don't expect it to be added)
main...fanno:NightDriverStrip:RGBW

Limited testing. but this is somewhat what i was tinking:

I realize, that size for "hack" to work is needed to allocate the correct data size (getRGBWsize)
FastLED.addLeds<SK6812, LED_PIN ## channel, COLOR_ORDER>(devices[channel]->fastleds, getRGBWsize(devices[channel]->GetLEDCount())); \

In virtual void UpdateFastLEDS() the datasize calculation is curently fixed but would need to be dynamic some how. from

But the main idea for testing is using a NDRGBWW that could store the full data. for RGB W1 W2

I finally had some free time to test it out. Just wondered if you had any further "feedback"

0 replies

davepl · 2024-04-08T18:59:58Z

davepl
Apr 8, 2024
Maintainer

I’m on vacation and have read 10% of this whole thread, but here’s an idea for you (or anyone) that I did once for an episode. In PostProcessFrame, create a buffer with the RGBW values you want to send to the strip. Then copy your CRGB values over to the CRGBW array with a transformation that does this: - Extracts the “common” part of the RGB and shifts it to the W (this is not linear between R, G, and B necessarily) Sounds really simple, but it worked pretty well for me. Things like FF,FF,FF become solid W==FF as you’d expect. So for 99% of effects, that should work. - Dave

…

On Feb 1, 2024, at 3:33 AM, Morten Hundevad ***@***.***> wrote: I am testing the CRGBW "hack" but i would like to find a way to implememt it so it would work "all" the exsisting patterns and such. (I got my strip working /lighting up but of cause, colors are wrong due to the w "data slot".) It looks like patter's code is a "mess" of different styles, some using points some using setpixel... My main issue is why maybe i did not ask directly is i am new and most defiantly do not understand the code base yet and don't really know "what to ask" I am not intentionally trying to waste your time tho i can see how it could look like it i am sorry. i am having trupple locating where the the code base GFXBase.leds is "used/read" via/in fastled i only see few fastlet.show(...) and it don't look like something "global" it is in: CountEffect.Draw its my understanding that fastlet.show() is the one that do the actual "draw" of cause i can easily be wrong. my initial ida was sometthing like: GFXBase virtual void setPixel(int x, CRGB color) { if (isValidPixel(x)) #ifdef ....RGBW.... leds[x] = color //preform "hack" to convert CRGB -> CRGBW at least untill fastled get correct support for it. #else leds[x] = color; #endif else debugE("Invalid setPixel request: x=%d, NUM_LEDS=%d", x, NUM_LEDS); } But issue some stuff don't always use the set buttons so perhaps just before "render" the same could be done. I Tested creating a clone of "LEDStripGFX" and naming it eg LEDStripRGBWGFX But having to create clone of each class seems like wrong approach. — Reply to this email directly, view it on GitHub <#603 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF6GWDHV53Q6Q5VNUPDYROKTVAVCNFSM6AAAAABCT52CMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGMZVGAYTM>. You are receiving this because you are subscribed to this thread.

1 reply

fanno Apr 8, 2024
Author

You should be enjoying your vacation =)

Don't reply further until your done with vacation.

but here’s an idea for you (or anyone) that I did once for an episode
May have missed it that episode, i will have to go digging =)

The "thought" behind the NDRGBWW is that it "could" potentially be. a "generic" object to hole the raw data. so that NightDriver would have internal RGBWW and it would be available for usage. if a component "need" if and the output data could be "any" format

As i have stated Manny times before i am not a prof software coder, (well i do robots and PLC's), so i do not know the correct/good preciseness.

I think i tried PostProcessFrame a while back, but i properly did things wrong. I could try again. Its properly a better place to try and implement it.

Another way that i could perhaps explain it is if its in "base" is stored as RGBW1W2 support for thoes could be added "anytime" down the line.

robertlipe · 2024-04-10T03:08:51Z

robertlipe
Apr 10, 2024

My vacation just ended... I'd recently received some strips and just did, more or less, this: white = std::min({red, green, blue}); red -= white; green -= white; blue -= white; to let the white carry the common component of the RGB. Now if you have a strip that's a warm temp and makes orange from the white strip, you need some different math to pull that orange back out and make cold temp "real" white out of it for purity, but that worked reasonably well for a tiny hack. (Doing this well seems to require understanding something like https://en.wikipedia.org/wiki/Rec._709 to extract the correct amount of white for that specific light source.) Extracting it from HSV was hard, but hte effects I cared about didn't do that. I stick by my earlier answer that it's better to just make an struct RGBW[W] and DMA right from that than it is to try to synthesize it like this, though. Perhaps unioning them together makes them safer in most allocated contexts and doesn't result in "holes" in the frame to hop over. I also took the lazy way and just never mixed RGB and RGBW/RGBWW strips in a build. On Mon, Apr 8, 2024 at 2:00 PM David W Plummer ***@***.***> wrote:

…

I’m on vacation and have read 10% of this whole thread, but here’s an idea for you (or anyone) that I did once for an episode. In PostProcessFrame, create a buffer with the RGBW values you want to send to the strip. Then copy your CRGB values over to the CRGBW array with a transformation that does this: - Extracts the “common” part of the RGB and shifts it to the W (this is not linear between R, G, and B necessarily) Sounds really simple, but it worked pretty well for me. Things like FF,FF,FF become solid W==FF as you’d expect. So for 99% of effects, that should work. - Dave > On Feb 1, 2024, at 3:33 AM, Morten Hundevad ***@***.***> wrote: > > > I am testing the CRGBW "hack" but i would like to find a way to implememt it so it would work "all" the exsisting patterns and such. > > (I got my strip working /lighting up but of cause, colors are wrong due to the w "data slot".) > > It looks like patter's code is a "mess" of different styles, some using points some using setpixel... > > My main issue is why maybe i did not ask directly is i am new and most defiantly do not understand the code base yet and don't really know "what to ask" > > I am not intentionally trying to waste your time tho i can see how it could look like it i am sorry. > > i am having trupple locating where the the code base GFXBase.leds is "used/read" via/in fastled i only see few fastlet.show(...) and it don't look like something "global" > it is in: CountEffect.Draw > > its my understanding that fastlet.show() is the one that do the actual "draw" of cause i can easily be wrong. > > my initial ida was sometthing like: > GFXBase > virtual void setPixel(int x, CRGB color) > { > if (isValidPixel(x)) > #ifdef ....RGBW.... > leds[x] = color //preform "hack" to convert CRGB -> CRGBW at least untill fastled get correct support for it. > #else > leds[x] = color; > #endif > else > debugE("Invalid setPixel request: x=%d, NUM_LEDS=%d", x, NUM_LEDS); > } > > But issue some stuff don't always use the set buttons so perhaps just before "render" the same could be done. > > I Tested creating a clone of "LEDStripGFX" and naming it eg LEDStripRGBWGFX > > But having to create clone of each class seems like wrong approach. > > — > Reply to this email directly, view it on GitHub < #603 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AA4HCF6GWDHV53Q6Q5VNUPDYROKTVAVCNFSM6AAAAABCT52CMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGMZVGAYTM>. > You are receiving this because you are subscribed to this thread. > — Reply to this email directly, view it on GitHub <#603 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD32F3AG62IZFCQWGWMDY4LSMHAVCNFSM6AAAAABCT52CMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANJQGMYTG> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/603/comments/9050313 @github.com>

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Is there a "generic" location in the code base for color question #603

{{title}}

Replies: 24 comments 5 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Is there a "generic" location in the code base for color question #603

Replies: 24 comments · 5 replies

fanno Jan 31, 2024 Author

fanno Feb 1, 2024 Author

fanno Feb 2, 2024 Author

fanno Feb 24, 2024 Author

rbergen Feb 25, 2024 Maintainer

fanno Feb 25, 2024 Author

fanno Feb 25, 2024 Author

fanno Feb 25, 2024 Author

fanno Feb 25, 2024 Author

fanno Feb 25, 2024 Author

fanno Feb 25, 2024 Author

fanno Feb 26, 2024 Author

fanno Feb 26, 2024 Author

fanno Feb 26, 2024 Author

fanno Feb 28, 2024 Author

fanno Feb 28, 2024 Author

fanno Apr 8, 2024 Author

davepl Apr 8, 2024 Maintainer

fanno Apr 8, 2024 Author

Replies: 24 comments 5 replies

fanno
Jan 31, 2024
Author

fanno
Feb 1, 2024
Author

fanno Feb 2, 2024
Author

fanno
Feb 24, 2024
Author

rbergen Feb 25, 2024
Maintainer

fanno
Feb 25, 2024
Author

fanno
Feb 25, 2024
Author

fanno Feb 25, 2024
Author

fanno
Feb 25, 2024
Author

fanno
Feb 25, 2024
Author

fanno
Feb 25, 2024
Author

fanno
Feb 26, 2024
Author

fanno
Feb 26, 2024
Author

fanno
Feb 26, 2024
Author

fanno Feb 28, 2024
Author

fanno
Feb 28, 2024
Author

fanno
Apr 8, 2024
Author

davepl
Apr 8, 2024
Maintainer

fanno Apr 8, 2024
Author