in light of chinese musicians starting to do gigs via video streaming, it's not futuristic at all to imagine earning all your money via live streaming, ordering all your food and anything else you need to your door and essentially live without much human contact for years.
microsound, unit generators
Anxiously awaiting the next Hiroki Nishino paper... not to mention the release of LC!
audio dev rant
The "freedom" bits aren't really as important to me in this context. It's more about the conservation and preservation of musical software. Complex behemoths like JUCE can quickly solve problems now, but they are also brittle and will fall over eventually over time. APIs will deprecate and break things in the name of profit. C++s compilers + standards are a moving target. What happens when ROLI falls over? Legacy is my concern, not theirs. I'm talking NASA-levels of legacy here. Creative software needs that kind of long-term thinking.
audio dev rant
Seeing the widespread adoption of JUCE makes me a bit uncomfortable, especially when used in FOSS projects. I've definitely seen this trend advice telling people to "just port it JUCE", which I find to be lazy and short-sighted.
A reminder that:
JUCE has their own strange license agreement you have to comply with.
Was built/bought by a for-profit corporation in the music tech industry. It does NOT have FOSS interests at heart, only pushing their own products.
There's only one implementation of JUCE, and that's JUCE. Actually JUCE is an implementation of implementations, so that makes things worse.
Most of the implementations that Juce is implementing are non-FOSS and proprietary.
Has a massive amount of overhead, including a GUI for making projects from scratch.
Is built in C++, written by a C++ guru. So you can imagine that there's an massive tower of abstractions + C++ complexities that mere mortals (or ya know, people with common sense) aren't going to be able to comprehend.
It's that time of the day to go read & listen to & favorite everything posted in @paul's feed.
Made some more progress on the first pippi tutorial to cover sequencing and rhythm so far -- look ma, a drum beat!
This looks like an interesting color palette:
It was mentioned the comments section of r/pixelart. Might attempt to use it at some point.
After I don't know how many years of squatting on the domain, I've finally soft-launched a web site at https://arcanebanjo.com/ It's pretty utilitarian at the moment, but it's a solid start.
(Can I just say how great it feels to launch a website by just uploading some files, 1995 style?)
Finally finished my trigger delay algorithm for #monolith
You can think of it as like a MIDI delay/echo, only for trigger events in a modular environment. It is very well suited for making #generative music.
I've uploaded a small audio demo of it in action. The trigger for the lowest note gets put into the trigger delay, and is used to trigger the higher note events you hear.
The delay is synced to a master clock source to prevent clock drift that can happen often over time with audio delay effects. As a result, delay time is not expressed in units of seconds, but in "ticks". This patch randomly flips between tick times of 1 and 3, which make it sound like a sixteenth-note delay and a dotted eighth-note delay.
I have yet to really play around with this, but I have a feeling this could end up being really fun to use, especially trigger-delays feeding into other trigger delays.
s9 scheme (my fork at least) and tinyscheme both work with PCC, so at least there's a working LISP-y thing available. S9 scheme is the main scripting language used in #monolith, so I feel relieved about this.
Lua works as well (at least in ANSI mode it does, haven't tested anything else).
Computers and Sound.
Welcome to post.lurk.org, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.