Here’s some random thinking about types of sound synthesis that interest me after work today… synthesis is a huge field. Digital synthesis especially has the promise of exploring the full spectrum of possible sounds. It’s the appeal and maybe the fallacy of digital synthesis that all sounds, if you just find the right way to modulate the speaker are possible. (Jliat’s All Possible CDs thought experiment is kind of the logical extreme of that line of thinking.)

There are some areas of sound synthesis that I’m drawn to, the scribbly venn diagram shows them circled in green and grey. Mimetic synthesis probably has some other official name in the literature, I don’t remember how Luc Döbereiner refers to it, but it’s the other side of the coin in terms of compositionally motivated sound synthesis – a term of his I like a lot. Mimetic synthesis is just synthesis that tries to recreate sounds we know in the world. Particle synthesis with a physics engine to make glass breaking sounds, a complex FM patch to simulate the sound of a trumpet, interpolated multi-sampled recordings of a violin to simulate naturalistic violin playing, etc. Compositionally motivated sound synthesis is basically like it sounds: an attempt to build waveforms up from compositional processes and generational approaches to create unheard sounds that aren’t found in the world, or permuations of that sort of reaching for the unheard.

There’s lots of overlap in things like synthesizing impossible pianos with strings 7 miles long, or using something like modified waveguide synthesis to break and mutate a physical model of a natural instrument, like a guitar. I called those hyper-instruments in the diagram for lack of a better word, but I think that term might actually be more commonly used to refer to traditional instruments with digital or electronic augmentations, like a disklavier? Anyway here I’m thinking of compositionally motivated permutations of mimetic synthesis to put it in a really obtuse way.

That kind of hyper-instrument work is compelling to me compositionally, but the math is tough haha and I get a similar satisfaction from doing digital transformations to acoustic instruments that I’m handling in the world, so, I’m not honestly sure how far down that rabbit hole I care to go? Maybe if I get more comfortable with the math at some point, I’ll feel different. It’s a really cool area of work and I’m certainly interested to check things out as a listener.

Re-creating expressive versions of existing instruments doesn’t interest me all that much in instrument-building. It’s wonderful to be able to make sketches or sort of work with instruments that I can’t play or cannoodle someone else into playing haha – there are some amazing piano and guitar software instruments out there that are really fun to play with – but I usually prefer to work with my own shitty instrumentalism and the talents of my instrumentalist friends I guess.

The stuff that really interests me is in the realm of lets call transformational synthesis – compositionally motivated sound synthesis which takes inputs from the world and does things, then sends those things back out into the world again. All kinds of concatinative synthesis, waveset segmentation synthesis, granular synthesis and microsound fall under that umbrella as well as things like Paul Lansky’s synthesis of timbral families by warped linear prediction (which I’m studying again at the moment) and etc.

Somewhere in there is also simple tone generation and combination which makes a lovely counterpart to the typically wilder timbres of transformational synthesis.

I think it’s helping me consider what sort of things I should be spending time on with the ugen / stream interfaces in astrid. Like basic tone generation and probably a small collection of microsound-ish oscs seems like the territory I’d like to cover for rain.

These are the Daves I know, I know. These are the Daves I know.

The astrid / instrument-building update is that I’ve been stuck on a memory alignment issue while refactoring the shared memory buffer system to use normal libpippi lpbuffer_t structs instead of the lpipc_buffer_t variants. The difference is kinda dumb: lpbuffer_t has a pointer to the variable-sized data portion with the samples, and the lpipc_buffer_t structs have a flexible array member at the end instead. Using the flexible array member (FAM) means only having to create and manage one shared memory segment instead of two, which is why my lazy ass decided to go that way at first and just make a slightly modified duplicate data structure for shared memory buffer, but my implementation with the two memory segments is breaking with memory alignment errors when trying to initialize the second segment… I’m doing something goofy and I’m not sure what.

At the moment I’m just trying to understand the problem with the two-segment implementation, but I’m starting to get interested in exploring the trade-offs of just using the FAMs on normal lpbuffer_t structs, too. Maybe that’s a nicer way to go anyway, I haven’t thought the trade-offs through yet.