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


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

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.

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

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

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

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

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

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

I'm at the edge of what I am to plan out at this point. It's mostly just a process of reducing as much code as possible while still compiling, and trying to convert and C++ code into C code.

When things start looking like pure C again, I'll turn on the "-Wall -pedantic -std=c89" flags, and keep hacking away at stuff until it builds quietly.

Sign in to participate in the conversation

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