It only took like a week to get the new libpippi microsound module fixed up enough to drive pippi’s grain clouds. They’re much faster! Shaved about 20% off the runtime for the test suite, too. :)

The new “formation” engine is lacking support for grain masking and burst tables. I’ll probably just port that pretty directly over from the pulsar osc implementation. On the shortlist as well is to support basic morphing between stacks of grains, like the 2D pulsar osc. I’m not sure if it’s better to support that in the “tape” oscs which drive the grains, or at the level of the formation. I like the idea of tapeoscs being general purpose grain/cutup/microsound engines with a bring-your-own-orchestrator type of philosophy. The formation engine is the first orchestrator, but I’d like to explore others which are oriented more around grain introspection & support some kind of callback-based orchestration.

In the meantime, while I planned to move onto (finally!) refactoring the Wishart waveset segmentation stuff in libpippi next, I decided instead to take a detour and work on astrid quantization grids and sync first.

In previous versions of astrid instruments could register themselves to be quantized against a set of subdivisions (and multiples) of one global shared grid. That grid had one tempo and all quantized events followed it, basically.

This time around I’m still orienting everything around a global grid, however this time I’m using a monotonic system clock and crudely smashing that into ticks. Eventually I suppose I could replace this with a true monotonic tick stream – it exists already in the scheduler, but each instrument has its own scheduler so they would need to be locked together somehow in order to use it for this purpose. Having a single (optional, probably) external clock source for instruments to latch onto seems easier to implement and potentially more flexible.

Meantime good old CLOCK_MONOTONIC (actually CLOCK_MONOTONIC_RAW on linux) seems to be working well enough to syncronize events within musical time. This approach is not sample-accurate (though it could potentially be if I eliminate the variability in the processing that happens between calculating the delay and shuffling the buffer stacks around on playback) but it also won’t drift, since every process will share the same monotonic clock.

Otherwise the basic idea is that the quantization grid interval can be passed along with the render from the instrument itself along with an optional offset value. The interval will set the grid quantization and the offset can be used to introduce a phase rotation.

Later on it would be cool to support mutators of some kind (ideally in some way so that they could be shared between instruments) which could act the way that the ones built into pippi’s rhythm module do.

Here’s two (python) astrid instruments synced to a 1 second grid. They’re audibly misaligned sometimes. I’m curious if it’s possible to make the alignment worse than this in some scenarios (we’ll see!) but otherwise I’m totally down with a little alignment slop on quantization. Freebie humanization. ;-)