It's at this point that I'll want to look at some of the core C++ code and see how much of that I can devolve back into C.
I should mention that I have a Pod, and being the selfish person I am, am really only interested in building something that works for the Pod (for now). libdaisy has plenty of code that I'm probably not using (and will maybe never use), so that code can go. If there's code I'm not using in libdaisy that is also C++ code, that is double win for me.
A good way to figure this stuff out is to compile libdaisy with the example project, rather than link to it. That way, I can start ripping out code and looking for complaints from the compiler.
Header file inclusion was a mess in libdaisy when I first jumped in, and this has not seemed to change. The header dependencies still look like a mess, so I'll probably want to straighten that out.
Whenever I cannibalize software, I tend to work top-down. Grab and rework the highest-level abstractions and work through their dependencies until you reach the core stuff.
At this point, this is just a matter of converting the application C++ code into as close to C code as possible.
Next, I will port any DaisySP code into the example code and remove any deps needed here. So bye DaisySP at this point.
I may at this point also merge libdaisy code in with the main project code instead of linking them separately, as this makes the refactoring process easier. If I don't, I'll just make make sure the libdaisy Makefile is sane as well. We'll see.
Code consolidation. Grab all the working code as it stands and drop it into one repo. This includes the example, libdaisy, and daisyp. Preserve things as much as possible like they originally were.
The first step in the process is developing an ideal test patch to work from. I myself am quite fond of the reverb patch (it's the algorithm that started Soundpipe and my audio programming madness).
From there, a more sane makefile structure. This was done in a reductive manner last time, and I got most of the gunk of it that way. I'll try my best to keep this compatible with Daisy upstream, as it could be a useful thing for the community.
It's at this point that I blow up git and start over again. This fork will be one way. No turning back and merging changes. Period. Choo choo.
My final product will end up looking something like this, which was what I did when I first refactored libdaisy when it was still all in C.
Glancing back the codebase again after being months away from it, many things have changed, but not all things. I'll probably just do everything from scratch again.
Next steps for me:
Build a simpler Makefile. Their current system is way too over-engineered, and written by someone who hasn't actually written a Makefile from scratch before. (The makefile they currently was actually generated and lightly edited, which is a big "hell nah" for me).
The more ambitious project of mine is making a fork of libdaisy and converting it to (hopefully) clean C89 with cleaner Makefiles, and maybe some architecture simplifications along the way.
@hecanjog Got the SimpleOscillator example to successfully build and run today for the Pod! My DaisyVerb example sadly does not work out-of-the box.
@zensaiyuki Do you have any good books on color that you'd recommend?
@paul i got the year wrong. 1931. more info about how XYZ works here: https://en.m.wikipedia.org/wiki/CIE_1931_color_space
Trying to make my fuzzy dot color blending look better.
Would this work?
get foreground + background colors. these are stored as a 32-bit sRGB color (8 bit for each channel, though the alpha color channel here is ignored).
normalize foreground + background rgb backgrounds to be between 0-1.
linearly interpolate normalized colors based on distance to center point. Closer is more foreground, farther is more background.
convert this new color back to 32-bit sRGB space... somehow "baking in" the linear color space. (this is the magic operation I'd like to exist).
update pixel in framebuffer
Here's the comparison image from the krita page: https://docs.krita.org/en/general_concepts/colors/linear_and_gamma.html
In the left is a similar blurry circle image in sRGB color space with similar dark rings. The right image has the same coloring done in a linear color space with those issues gone.
I want to be more like the right image.
For reference, these are my "fuzzy dots" as they exist right now. You can see the dark halos around the fuzzy points.
More on linear color spaces:
Krita seems to take color mixing very seriously:
"i know we're a little over time, but very quickly, third quarter projections---"
Sound, music, computers, etc.
Human being, being human.
Welcome to post.lurk.org, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.