Show more

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.

Show thread

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.

Show thread

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.

Show thread

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.

Show thread

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.

Show thread

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.

Show thread

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.

github.com/PaulBatchelor/daisy

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.

Show thread

@hecanjog

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.

Show thread

@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.

Baby steps.

@zensaiyuki Do you have any good books on color that you'd recommend?

patchlore boosted

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

Show thread

Here's the comparison image from the krita page: docs.krita.org/en/general_conc

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.

Show thread

For reference, these are my "fuzzy dots" as they exist right now. You can see the dark halos around the fuzzy points.

Show thread

@mathr how do you handle color spaces in your work? Do you do any kind of color transformation before writing RGB files to PPM files?

Show thread

What started out as an innocent algorithm for drawing fun and fuzzy dots has now turned evil. I greatly underestimated the amount of work that goes into virtually mixing colors.

patchlore boosted

"i know we're a little over time, but very quickly, third quarter projections---"

Show thread
patchlore boosted

If you're a developer and not an english native speaker, which language do you use for your development tools?

Please don't answer if you're a native english speaker, not to bias the results. Boosts appreciated :)

#translation #internationalization #i18n

Show more
post.lurk.org

Welcome to post.lurk.org, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.