Next FScape version 3.14 / Mellite 3.13 will contain new feedback UGens. Here is a test with the feedback loop consisting of a Hilbert transform based frequency shifter and a delay, the shift moving the signal down 30 Hz in each iteration. There is an anti-aliasing high pass filter as well. The input signal is just 10 seconds of microphone signal initially picked up, my voice making some screeching sounds. As the process evolves, some interesting changes in timbre occur, notably some extreme energies are coming down from Nyquist, perhaps due to some ringing or other artefacts. The video has a gap in the middle because the computer would freeze (I suspect it was some problem of the screen recorder). The code is quite experimental, as one has to take care to enable sufficient buffering so that the DSP graph is flowing uninterruptedly.

I quickly hacked together a 2D graphics layer for my functional-reactive / dataflow model 'Lucre', with a Processing inspired front API, which allowed me to translate the 'Tree' L-System sketch by Daniel Shiffman. While running smoothly on a laptop, the test on a Pi 4B immediately reveals that my library has hardly usable performance at this stage. First part of the video shows the few-frames-per-second of Lucre2D, followed by the totally smooth animation coming from Processing 3.

After giving up on the Pi 4, another attempt with the capsense library of CircuitPython on a Pi Pico. The resistor has a few mega ohms; with the correct threshold (which changes according to environment ...) one gets quite a good reading.

I'm starting to explore the visuality of small 2" round screens covered with a half-dome plano-convex glass lens. Despite low FPS (Pi 4B, code not performance optimised), the animation of moons along a Steiner Chain of size 3 is interesting.

Second attempt - success! This is now with stronger servos (Jamara Q7 Standard - c. 6 kg force), and minimising sideways force by adding a small wood strip to the trigger. It's a bit messy, so I'll add some plastic sheets to the floor, especially when adding Spirulina to the lichen formula and automatically running the irrigation twice a day 😃

Following a video I saw on YT about activating a spray bottle with servo motors, I tried to recreate a similar setup. It "kind of" works, but the servos do not perform the full required angle. My guess is, they are simply to weak and thus stop at the point where their force is exhausted. They are super cheap SG90.

Any ideas how to make it work? Should I find another bottle with a less strong spring? Should I get better servos? I'm using a PCA9685 board to create the PWM signals, so I'm a bit worried that I have to stick to the 50 Hz / 1-2ms analog servos, whereas the strong servos are usually digital with other frequency range. Hints welcome!

After building the SuperCollider server (scsynth) as a WebAssembly binary for the browser, the other piece that is missing is a full-fledged client to talk to it. ScalaCollider is a client written in Scala that normally runs on the JVM, but it can also be compiled for the browser, outputting JavaScript code. The demo shows how scsynth(.wasm) is controlled by ScalaCollider(.js) inside the browser.

Source code: https://github.com/Sciss/SoundProcessesJSTest

SuperCollider server (scsynth) can now be compiled to WebAssembly (wasm) via Emscripten. Video shows booting of server, loading a synth def, starting a synth, and adjusting one of its frequency parameters. Current development: https://github.com/Sciss/supercollider/tree/wasm

Current README: https://github.com/Sciss/supercollider/blob/0adb2b70484b460872fc830f7a3deffaf1313ab8/README_WASM.md

Sound synthesis programs found through genetic programming have gone through an 'optimisation' stage that removes redundant elements, then through a 'parametrise' stage that identifies up to five constants that, when modulated, yield clearly different sonic characteristics. Ranges are estimated for these parameters, and input is normalised to the interval [0, 1]; a simple UI can be used to explore these parameters. The next task is to understand how the parameters can be coupled and automatically modulated by other processes, while still remaining within interesting sonic spaces.

(another go, this time showing the right source code)

Sound synthesis programs found through genetic programming have gone through an 'optimisation' stage that removes redundant elements, then through a 'parametrise' stage that identifies up to five constants that, when modulated, yield clearly different sonic characteristics. Ranges are estimated for these parameters, and input is normalised to the interval [0, 1]; a simple UI can be used to explore these parameters. The next task is to understand how the parameters can be coupled and automatically modulated by other processes, while still remaining within interesting sonic spaces.