christripledot

Long-time lurker, occasional poster... anyway...

Has anybody used [jit.matrix] to store their entire song/performance data?

My performance rig incorporates a variety of sequencers, arpeggiators, quantisers, automation/modulation matrices, synth editors, etc. Over the last few months I've been adapting these modules to use Jitter matrices for data storage (for performance reasons). In doing so I discovered the joys of shuffling data between different modules (e.g. copying and pasting step sequencer patterns, bit-operating one sequence against another, building transposition tables from melody sequences etc. etc.)

As it stands I use a variety of [pattrstorage] and [preset] objects to manage data that 'belongs together', but it feels awkward. Would it be feasible (or just foolhardy?) to stick everything to do with my entire patch into one huge supermatrix?

I'm thinking this supermatrix would hold pattern data, sequence ordering, pattern names, preferred BPM, launch quantisation, groove settings, all the instrument data for that pattern (replacing [pattrstorage]), and everything else I can think of. So after writing a whole heap of tunes and synth patches and whatnot, I can save the whole set's worth of data to a single binary file.

song-management

I'm an msp guy, but for a long time before that I was simply a math guy. A little off topic here, but you might be interested in learning about Donald Coxeter (pioneering n-dimensional geometer). I say this because his algorithms for finding symmetry (search Coxeter groups) are used in search engines, cosmology, etc.

If you can store all your data in one format, you could likely program another module to find symmetries, perform rotations, permutations, and so on to the data for something generative.

I'm still in the process of building my main patch, but I've been doing so for the purpose of someday building such a storage system, for the purpose of analyzing the data, for the purpose of building a comprehensive generative composition synth.

For the moment my patching ability is far outpaced by my imagination, but I'm slowly getting there. I'll keep you in mind when I figure it out.

I'm an msp guy, but for a long time before that I was simply a math guy.  A little off topic here, but you might be interested in learning about Donald Coxeter (pioneering n-dimensional geometer).  I say this because his algorithms for finding symmetry (search Coxeter groups) are used in search engines, cosmology, etc.

If you can store all your data in one format, you could likely program another module to find symmetries, perform rotations, permutations, and so on to the data for something generative.  

For the moment my patching ability is far outpaced by my imagination, but I'm slowly getting there.  I'll keep you in mind when I figure it out.


Not that people haven't already built generative synths, but I think it would be exciting/useful to have one that learned your composition style and used your patches to produce your style of music.

Although I'd like to be a math guy, I gave it up too soon, to my regret. Thanks for the tip though, Coxeter looks very interesting. I think I might need to do a few months of reading before I can really get my head around any of his papers though.

Your thoughts about an analysis system sound very interesting. I hadn't looked at it that way before. I was working in the opposite direction, but you've given me some new ideas.

My main patch is based around 'traditional' step sequencers (with a few generative niceties thrown-in) but I am working on a 'macro sequencer' patch to govern them. Basically, you set the length of phrasing (beats per bar, bars per musical phrase, phrases per 'movement'), choose a selection from a bank of allowed key signatures, and let it go. It chooses patterns based on the current playback position, and where necessary, transposes each pattern to fit the desired key. It also allows you to jam different patterns on the fly, 'smart muting' parts where necessary, and overruling you if you try to trigger something totally inappropriate.

So far, so good, but this sort of thing depends on laying out your patterns in memory in a very specific manner (i.e. ptns 0-63 = intro stuff, 1-127 = buildy stuff, 128-191 = drop stuff, 192-255 = elaborate stuff, etc...)

But I tend to make music in a much more haphazard way. Patterns get stored all over the shop and I can never be bothered to organise it properly. It would be awesome to have a patch that would scan a pattern, and determine its intensity, drummyness, choice of instruments, etc., and automatically group it with sympathetic patterns. On the most basic level, something like this could be used to provide the master sequencer with alternative choices, depending on pattern playback counts, preferred BPM range, or whatever.

Intelligent self-generating synth patches... Ooooooh that's a bit slicker than pattrstorage interpolation, now isn't it? Back to the drawing board....

if you do store all your pattern data in jitter matrices then you could visualize that data, either raw or via very simple mapping - then you might be able to see such things as "intensity, drummyness, choice of instruments, etc." and act accordingly...

Mmm, you're right. But I'm trying to free myself from the responsibility of choosing which pattern plays next. Plus I really don't have any CPU to spare on [jit.pwindow]s and the like!

I'm a ways off from it myself, but I've been writing my patches in a similar way. I'm applying overtone/undertone series math to my sampler so that it flexibly loops microrhythms/subdivisions/beats/bars/phrases/etc, and trying to think ahead. When I get to using some sort of storage/data analysis it hopefully won't be a complete overhaul.

Coxeter is my favourite, and a fellow Torontonian for some time before his passing. Sadly under-recognized.

Coxeter is my favourite, and a fellow Torontonian for some time before his passing.  Sadly under-recognized.


Song management