{hhr, 200117}
On Motion
The original algorithm was conditioned with several parameter "motions" based on a few forms such as pseudo-random walk, linear and exponential distributions, and so forth. In the first reconfiguration, I took the motion types along from the original code. When moving to SoundProcesses, the question arises how these types are formally defined.
Also, what I never liked about the past versions is that they were "forgetful". When you rebooted the machine, it would restart these motions from an initial state, not remembering their last positions. When I translated a part of SuperCollider's Patterns abstraction, I always thought it would be interesting to use the statefulness of streams or expanded patterns as way to implement persistent motions. There are some notes from 2018 which state this idea. The stream implementation in the Patterns library had always been done so that I could hopefully pursue this idea, and this week I actually went through the code to make this workable.
For instance, let's take a stateful pattern, the brownian walk:
Brown(0.1, 0.5, 0.1)
For each step—the next operation—it moves up or down by a random step with a magnitude no higher than 0.1, and it will clip to the interval [0.1, 0.5].
This is a Pat pattern definition, and it is used as a pattern in SoundProcesses, each time it will issue a new motion with a random initial state. If you put this now into a Stream object, the pattern is expanded once, and the resulting stream—which carries the internal state of the walk—is always the same. When you come back to it, it will continue were it was left.
Of course it can also be used where no state is involved in a pattern. Here the fade-out duration of the phrase-player is defined by a random number between 0.1 and 0.5 seconds, using a White pattern which is advanced from a Control program (the value 0.25 in next(0.25) is just a default if the stream not found):
{hhr, 200918}
A multiple – three identically structured but independent tables of 27 Petri dishes each, in groups of nine “nodes”, and three Raspberry Pi 3B implementing three nodes each. Mechanical relays are used to move along the clockwise direction from node to node, producing an additional audible signal and rhythmic element.
Each table is fed by one radio receiver, possibly set to different frequencies. Each table has a different granulation of graphite powder. The computational and electronic components are situated below the table, which has an open metal frame (60 x 60 x 60 cm) and a circular glass plate through which one can see downwards on the electronics, or upwards the bottom sides of the Petri dishes.
The new title highlights a new interest in the coming-together of otherwise independently operating processes. The tables produce sound independently from each other. In later versions of workspace, a “dust” process is added, where from time to time a table makes a “silent” round, playing a low volume dust crackling sound instead of the sound phrases, making it possible to focus the ear on the other tables, but also highlighting the acoustic properties of the Petri dishes themselves, which you can hear shift from node to node as the wires that transmit the sounds have slightly differening positions. Each table has different dust frequencies, making a correspondence with the granulation of the graphite powder.
{hhr, 200622}
Original packing was based on these numbers, as far as I remember: http://hydra.nat.uni-magdeburg.de/packing/cci/
The 72 dishes (30 + 24 + 18) used a hole in the middle, it was probably based on five rings and around ninty dishes? Likely 91.
{hhr, 200623}
The 27 arrangement (right image) looks a lot more natural to me. The symmetry axis is softer, and we have nicer factorisation 3*3*3 (times 3 tables). It even plays nicer with the four channel structure of the amp. A question is how many Pi 3Bs we need to have uninterrupted overwriting of phrases.
Performance test: Pi 3B (not-plus), runs last version of Mellite workspace at around 66 seconds per iteration. With 3 Pis responsible for the entire circle, each Pi has to render 3 buffers, so a rotation cannot be faster than 66*3 = 198 seconds, and thus the minimum phrase length would be 22 seconds if we want to avoid gaps. Ideally, we could come to down to around 15 seconds, so we would need to try to speed up the iteration to no more than 45 seconds :-/
With three Pis, we could have a fixed channel / relay wiring, so that's a lot simpler. If we add a forth Pi, we need a coordinator Pi, essentially a fifth Pi, and then weirdly the memories / buffers would no longer correspond to static angles.
Another idea would be to measure the performance of a Pi 3B+; perhaps we have 4 Pis for each table, the Pi 3Bs responsible for two channels each, the Pi 3B+ for three channels, then we'd use the four amplifier channels, and slightly asymmetric relays.
Another idea would be to try to render two buffers in parallel, making use of the multi-core feature. But this could run into memory problems...
Possible performance improvements: Trying to run headless? Certainly without meters etc. Using a RAM disk for rendering target and/or temp files. Disable VNC etc. I also suspect Akka start/stop taking a bit of time, so ideally there would be the 'reset' feature in FScape, but that is unlikely to materialise in such short time.
link to software repository
{hhr, 200916}
I tried and implemented now "silent" rounds which can be initiated by any node based on a given probability. If a silent round is initiated, a token is passed around that is counted down until one round has been completed. It should allow for the possibility to hear only one or two tables in certain intervals, something that I thought was lost when all tables are audible all the time.
Instead of just being silent, one still hears the clicking of the relays, and I am using a low volume "dust" sound that for me corresponds with the dust accumulated on the Petri dishes over time, the graphite power (the sonic dust texture also differs between tables), and the pops on the radio signals.