#1

Hi, my name is mikaël and I’m working on a software project I call the Algebraic Audio Station, or just Stacy for short:

http://www.corbac.com/page44.html

It’s my attempt at creating a tool that will allow me to manipulate audio signals at will. My only user interface is a 9x19 grid (with holes…) and I use it to manipulate audio circuits in real time. It’s just a dataflow programming environment like Pure Data or Max/MSP, but without a mouse or a screen.

The project is on hold for the time being, but I thought I’d share it with you. Please let me know what you think.

1 Like
#2

Hey man, really nice work. It’s funny you post this, I’ve been working on a similar linux environment for live performance. You have some really interesting methods for routing each of your audio ‘components’ ins/outs and your demo sounds rad, I’d like to see a video (EDIT: I saw your videos!). A goal of my environment is to emulate the flexibility of a modular synth’s control signals like you’ve done with ‘ui signals’. But providing exposing the ability to dynamically assign dsp modules’ parameters to a matrix router on a grid gets confusing very quickly… Thanks for posting!

#3

Thank you for the kind words. I had a quick look at Candor and can’t wait to properly dig into it.

The nice thing about a matrix router implemented on a grid is that it provides you with a “static” view of the connections: you could print out the grid and deduce all the connections from it.

On the other hand, my approach only provides a “dynamic” view of the connections. All you can deduce from a print-out of the grid is where components (or “modules”, in the modular synth model) are located, but you have no way whatsoever of knowing where the connections are. You can get that information out, but only one component at a time, interactively.

I haven’t given much thought about the matrix router model, but I believe it would only make sense if you have “fixed” inputs and output. My project is more flexible in that you can instantiate components at will, each with its own inputs and output (only one output per component though, that’s a deliberate design choice).

But even then, things can and do get confusing sometimes, if only from the fact that you can’t have object labels on a grid. But that’s part of the game: how far can you push the abstraction using only “grid language”?

And note that I’m already cheating with respect to the Monome in that I’m using a few colors :blush:

#4

When my environment becomes more mature, I’ll be sure to post it here. It allows one to chain together an arbitrary number of dsp functions and add/remove/reorder/edit them in real-time. From the monome’s limited perspective, certain functions have been grouped into modules and the number of available parameters have been normalized to four–there are sixteen possible module chains, each with a maximum of sixteen modules.

You bring up some good, fundamental limitations of the matrix router. I was thinking some of them might be solved by dynamically assigning targeted modules’ parameters from specific chains to each axis of the router on a dedicated grid ‘page’… but there would be no way I would be able to remember those designations during a performance. Back to the drawing board!

It took me a second to realize you were using colors, I’m a little more color-blind than average haha

#5

Hello, thanks for the heads up. I have been working on a similar idea in order to use the Grid to control The Elementary Signal Engine (ESE). Its quite hard going as, in actually fact you are designing an operating system, so consequently, because of other commitments it has been slow. I’d be happy to bounce ideas back and forward.

I love the name of you project “Algebraic Audio Workstation”, great idea!!!

#6

BTW the ESE can be downloaded here:

https://perevillez.wordpress.com

#7

In order to achieve a high level of abstraction and generality while sticking with the grid as the only user interface, it seems obvious to me that a great deal of creativity will be required. My current model of fixed component instances works pretty well, but I’m sure I will need other models to mitigate its limitations. And by “other models”, I mean different ways of doing the same thing: route signals between modules in real-time.

For example, my components are pleasant to work with as long as they stay “elementary” (i.e. they have very few inputs). My first synths were elementary: they were simple UI -> Audio functions, so only one input. But as soon as I added a simple “tuning” parameter, they became substantially harder to work with. Thus, working with existing DSP modules, with their many different parameters, would be too cumbersome in my current model.

I have explored a few leads from computer science, like default parameters and higher-order functions, but haven’t had the time to prototype anything yet.

By the way, I was wondering: has anyone worked on the general problem of user interface on the grid? Most modern GUIs are based on the work done on UIs at Xerox PARC, but has anyone studied grid UIs in a general context? Right now, my UI code is a big ad-hoc mess…

#8

The name comes from my desire to manipulate audio signals in the same way mathematicians manipulate numbers and other objects: by transforming them with operators and proving certain properties of these transformations.

As a very basic example, page 7 of my demo circuits is a “proof” that an IIR echo can be reversed. I do this by chaining two circuits, one echo and one “anti-echo”, and proving that the signal that comes out of the chain is the same as the signal that goes in.

But that will need a lot of hard work before it starts being remotely useful: right now, it’s just a very convoluted way of creating a null signal :slight_smile:

#9

If I get you right what you are talking about is “One Line Code of Music”?

See attached screenshot. It a Matrix Code Music synthesiser which instead of writing the code you patch bitwise operators in order to create the synthesis patterns

matrix Code Music.png1002×709 82.3 KB

Basically you patch a signal source (there are T1,2,3) and then you process them through the operators. Just with t*(t>>x) you can create a riot! There are two types of oscillators, aliased and anti-aliased.

The problem controlling it with the grid is that it limits how many operators you can use. As you can see my matrix has 53 X 41 you would need a huge grid. Mine is a 256 which is a 16 x 16. I have tried to source a pin matrix system but the hardware to do this is mind boggling!

#10

The pictured system above is called “ALIAS” and will be released at the beginning of next year. AS I said though, how you control this with the grid is a tad difficult to envisage. It woulds though what you are trying to do is to process signals in this way using convolution, so I am not too sure what you mean yet, but it certainly sounds very interesting.

#11

Yes, but the name Bytebeat is catchier! :slight_smile: I implemented three Bytebeat tunes on Stacy as example circuits. That’s a good example where “free-form” operator instantiation is much more compact than a fixed routing matrix.

#12

Here is an audio example of the system I have just put together. I use also analogue modelled filters at the back end and some reverb. Just tried to upload an mp3 example but the system said I couldn’t :frowning:

Here a link to it on my sound cloud:

https://soundcloud.com/perevillez/matrix-code-music-01