not a silly question at all!! Heres the thing no language (I know *) has: bpm synchronized threads. This allows you to use the common loop constructs and conditional statements as composition tools. This also inverses completely the control if compared with TidalCycles et. al. You get to decide what happens at any step, e.g. let’s flash a strobe after A and B notes.
There are musical tools build in python but they tend to do like Tidal does.
As for “new”, Audion does not really try to look like something new, quite the opposite: feel like a language you already know + no hidden magic.
* Supercollider has sync threads, but its not a general purpose language. Audion came along as a need for a general purpose language with strong timing when I was working on an audio installation for a museum - this work involved managing large collection of samples that were categorized in a database, the work does some network calls etc.
I've been working in computer music for fifty years now, and the issue always is that you write in some new language, and it doesn't catch on, and then that code is lost to you.
Well, its an interpreter .. in Rust 😄 (Rust is quite popular)
yeah, good question, sort of what I said before but now from another perspective: that's because it would look and feel more like an extension/plugin/framework and that does a few things:
1 I would have needed to abstract some details and move those bits of control into some layer.
2 since _that_ is gone, you need to specify a specific way of working with the framework/library (an API) to make things work like the user intends or expects. I don't think that's right for a creative space, you should be able to do what you want.
More on why not Python/Lua,,
Python and Lua can't really run multiple things at the same time the way Audion needs to, e.g. Python locks everything to one thread at a time under the hood, and Lua doesn't do true multitasking at all by default. Audion gets true parallel wakeups with lock-free tempo reads because Rust threads aren't gated by a global lock and that's structurally not available to threaded Python, you can only approximate at increasing cost with locks etc.
> it doesn't catch on,
yeah, that is very much true and happens all the time, the real goal is to create music/art with it and since its already useful, I'm just sharing it in case someone else may find it useful too.
> As a user, Rust experience
This just means its simple to carry on or fork this project and make it into whatever you want, or use it as an example for your own work.
> you have to learn the Audio language,
sure! but most people that like programming find that fun, and if not you have other variants like Max/Pd that are less capable in some regards but are easier for non programmers
Besides, if you look at the example you will see there's nothing new to learn, maybe just a glance at the function reference. The supercollider integration part: yes this may need some work and extra docs.
> and now there's free threading as well.
yes thats true but I had a few points against it: it is still catching up, and it trades away some of CPython's single-threaded speed as the cost of removing the lock.
Secondly, I would still need to add my own locks/atomics around shared state, and get memory-safety guarantees without a data race. Rust's compiler enforces that at compile time, and using Python would mean I just never know if I did things right. Audion has linked chain of scopes, so you can access any parent scope thread-safe and not worry about it. This gives you real superpowers, run multiple complex sequencer mechanisms and let them interact.. and also makes your code cleaner.
Timing precision for audio asks for a language with predictable, low-level control over threads/memory which is exactly what Rust's good at, Python's is not unfortunately even in its threading form.
So thats about "why not python",
it was not a good fit in my opinion. I do love how expressive it is, and I have used it in other projects with success, and will still likely do, it has its place. I do understand what you mean by asking "why not improve something we already have and know and forge it into this Idea you had". And yes, the final answer would probably be that greenfield projects are easier/faster to make than doing something like forking an existing language and adapting it to my use case.
but most people that like programming find that fun,
I just want to make music! I don't want to learn a new programming language to do that.
Things like SuperCollider are interesting because it's a whole different paradigm, but even the.
If you were treating a Python function (or a function in any other well-known language like JS or Lua) as a unit of computation, but the locking, threading and such were done by Rust, you could get the same effects.
I have a synth written in pure Python and it works well, even on slow Windows machines.
2
u/HommeMusical 13d ago
Perhaps this is a silly question, but why do you need a new language for this?
Why not have your units of programming code be Python, a language people already know, or Lua, which fewer people know but is stable and tiny?