tjw

I had thoughts of essentially reinventing the wheel but better with my audio dsl, having my own editor for audio graph, but thinking it through more, obviously the better thing to do is accept pd or msp patches as input, which would make it a drop-in replacement for Heavy once I get it producing native output using Reflaxe.

Just thinking out loud here. You don’t swing above your weight by trying to do everything. There’s a whole ecosystem there and it’s awesome!

#haxe #AudioDev #purdata

"Instead of making a prompt to write an overly verbose email, just email the prompt" is a great principle and, as much as possible, the same should be true of software development.

Indeed, if it didn't cost money/token, didn't consume too much CPU/GPU or bandwidth, etc. it would logically make sense that, if people are going to vibecode and not even check the result (and really, they shouldn't), that only the prompt, model version, configuration and any random seeds would need to be checked in.

But I think it's more likely in so many of these cases that if a prompt was good enough to produce good enough code that didn't even need to be edited, it probably should have been a one-line library call instead. I saw a dev talk about he he liked that AI could make boilerplate for him for cmake. But tools exist to make that boilerplate for you and in that case you need only check in the tool's config (e.g., camunda).

Boilerplate can be made cheaply and deterministically. Boilerplate should, as much as possible, not even be a thing.

So again, wherever possible, see if the prompt can be what is sent (or checked in) instead of having a neural network make fluff for you. Unless you're more concerned with impressing people with how verbose you can be (as an overly-verbose person, I assure you it doesn't impress people).

I’m seeing “AI music” startups making fundamentally the same mistake the company I quit a decade ago made - thinking that non-musicians would like to be musicians, if only there was an automated process to do the music-making for them. The problem is being a musician is more of a mindset than a skill. Such things can be cool tools for musicians if they’re designed right, but there isn’t a huge untapped market of non-musicians who would like to become musicians. You can already download a DAW and follow a youtube tutorial on how to make the type of music you like in that DAW. There are templates. There are stems ready to be remixed.

And it’s especially many technologists who are musicians (such as I) who fail to understand how non-musicians think. They don’t want to be like us! And why would they?

Step 1: programmers who are way smarter than me make our own replacement by inventing LLM-based agents

Step 2: in revenge, I make the LLMs create their own replacement by making simple DSLs and visual programming languages that normies with free or local models can easily use

Step 3: everyone has a self-programmable computer in their pocket and doesn't have to give the tech industry money anymore. Everyone's free!

One positive thing I can say about AI-assisted coding is that it’s weirdly inspired me to put more work into improving my OSS projects again. Mostly without the help of any such tools so far. My thought process has been that any effort I put into making it easier for people to volunteer to work on it isn’t a complete waste if no one volunteers because at the very least the documentation I provide will make it easier to have opencode use free models (I feel like providers should have free plans for OSS but whatever) to hack away at adding tests and other bullshit that I hate dicking around with. I definitely have a strong preference for deterministic code generation but these nondeterministic tools can assist in speeding up the process of making the DSLs (copilot helped me a little bit with making Haxe macros the other day but ho boy did it hallucinate a lot at first).

My principles for avoiding the ways in which LLMs can exacerbate already unsound development, which I should codify into a document somewhere (and perhaps make visible to agents!) -

• Prefer deterministic code generation to reduce code bloat. Concretely, as an example in the #haxe context, pre-build Macros to generate externs from e.g., python, js or ts code is preferred over code that must be manually run to create .hx files that are checked in, which in turn is preferred over using LLMs to manually create the externs. But even that last one is preferable to making externs by hand.

• Write documentation and instruction for persons. Do not optimize things to get the desired result from LLMs. Models change, but the principles for explaining things to persons remain the same. E.g., efforts to translate docs into multiple languages help persons, but make no difference for LLMs. If you really need agent-specific instructions, throw it into AGENTS.md but ideally that file should just say “see README.md and CONTRIBUTING.md“

• Do not measure success by lines of code! We’re not a big stupid company where higher-ups have no idea what’s going on and use crude metrics for determining head count. The less code needed to complete a task without making the code unclear, the better. LLMs can give a false sense of accomplishment by making a lot of complicated wrapper code that, if you put more thought into it, wasn’t needed. Providers may have a perverse incentive to create more tech debt, which in turn you’ll need to pay for more tokens to maintain.

• Prepare for the rugpull. You should always be prepared to keep going if the agents disappear. Never let your code turn into a black box that you don’t understand anymore. Never forget how to code. Be prepared for when that model stops being free or that other model jumps in price. Be prepared to maintain your code if civilization collapses or the global internet infrastructure breaks. You shouldn’t ever need the cloud to develop a non-cloud application, period. You should always be prepared to hire humans to help you or roll up your own sleeves. OSS succeeds when we do a better job than big tech at keeping our costs down and keeping things simple. Let them saddle themselves with tech debt and don’t repeat their mistakes!

I figured this was worth a new release since it was the primary remaining outstanding bug (that's actually noticeable anyway). Latest version of the Akai APC Key 25 script (for old and new/mkii versions) for #Bitwig. Now the track buttons don't get stuck in blinking state as though stop was queued even though the track is in fact stopped.

(for the devs)
I even added stubs for enough of the Bitwig API to make automated tests that don't require linking to Bitwig. It can even target any other language #Haxe targets. Doesn't have to be java/jvm.

https://codeberg.org/grig/apc-key-25-bitwig/releases/tag/1.6

Today I livestreamed about updating my #bitwig controllers, in my #haxe -based framework for targeting multiple DAWs. I’m fixing issues with the original APC Key 25 created by my changes meant to facilitate getting the mkII version working. My goal is to have both working again this week. I was working on this last June then foolishly put it down until now. Bitwig has its own script for mkII but I wanted to bring the features I added - and support for other DAWs - to this newer version of the device.

I have bigger plans for this script, as I discuss in the video. Ultimately, this framework will unlock a lot of potential even for simple hardware such as this and not just for Bitwig, but trackers like #Renoise.

If you want to support me working on this stuff, check out my ko-fi.

https://www.twitch.tv/videos/2662329462

My tech goals over this week and next:

• Move more projects over to Codeberg and switch where automated tests are done
• Increase test coverage and documentation for my projects so that devs new to the repos (and agents) can easily contribute
• Livestream dev every weekday
• Update contribution guidelines on my projects to include rules for AI (in short: no vibe coding, you’re responsible for the code you write or have an LLM write for you, no bots, etc.)
• Get my Tripoli project ready for dogfooding
• Have my open source libs, particularly grig.controller and grig.audio to better, more usable states

Let’s see if I can do it! I’ll consider it a success if I’m even halfway to these things in that time.

Some brief #haxe dev to assist in me making #WordPress plugins I did today on twitch:

https://www.twitch.tv/videos/2657957626

I have a modest but achievable (I think) goal of going from 0 to 10 paid subscribers on my kofi by end of next month.

LLM coding assistance are a lot more impressive to people who write shitty code, but more actually useful to people who write quality code.