So yeah all that shit I said in the previous post? Forget it. It worked really well, don’t get me wrong; I just really hate the idea of adding more equipment to my solution. While Reaper doesn’t allow me to send MIDI clock messages from the VST, the ultimate destination for them is Mutant Brain (Eurorack). It doesn’t matter that they be actual MIDI clock messages in my synth, I just need any trigger to fire at 24 PPQN. So instead of setting up a totally separate MIDI device and merging the MIDI streams before Mutant Brain receives any data, we can just send pulses as notes from the DAW and configure Mutant Brain to fire triggers based on that. Another problem solved!

I’m enjoying my little hiatus - experiencing some minor FOMO but there’s way too much change for me to considering playing sets right now. The synth is still a work in progress; I’ve recently added Clouds and a looper (I can take the Boss RC-5 out of the signal chain!) and that will be it for a while, but it will take a couple more weeks for me to get familiar with everything. Here’s what I’m working with in the rack at the moment:

The 1u row gives me some room to move utilities around and expand a bit, but 104hp/4u is about as far as I want to take Eurorack. Eurorack is a tool I’m using, generative MIDI from code will always be my focus.

Speaking of which…anyone who’s seen me perform has probably seen or heard me get trapped in loops with few or no snares. That might work for specific scenarios when I’m recording, but it tends to suck the air out of the room in a live (non ambient) setting. I think a look at how I’m approaching a fix for this will reveal a lot about my process, so let’s talk about it.

Like a lot of data generated by the Aleator, snare totals are calculated using probability theory. Specifically, I use two distributions (probability density functions, not cumulative) - continuous uniform and normal:

For this example we’ll focus on my use of continuous uniform distribution (first diagram) when calculating snare totals for one drop, steppers and rockers variations. The idea with this function is that an arbitrary value between the bounds will be returned. In my code, the parameters are being set as

                m_continuous.Alpha = 0.0;
                m_continuous.Beta = (double)dp.Progression.TotalMeasures * 3;

This means that in a musical phrase with four bars, there will be a minimum of 0 snares and a maximum of 12. For these kinds of rhythms I distribute snares evenly but even still…any number less than 4 will leave at least one measure with no snares, and there’s a ~33% chance that will happen.

This code is pretty old and I’m hard pressed to think of an instance where I’d be playing a rhythm like this and would want several measures without snares. My fix was to leverage the “Flood” functionality I introduced in the last dev cycle to force more snares into the phrase upon regeneration if the Flood checkbox is checked in the Aleator UI. Right now that basically amounts to increasing alpha from 0 to 3 and multiplying the the total number of measures by 4 instead of 3 to get beta. In this scenario that would give us a range of 3 - 16; much better odds that the majority of measures will have at least one snare than 0 - 12.

This is a really simple and straightforward example of how probability is used in my plugin; there are far more complex applications, especially when it comes to managing pitch and locating notes on the staff. But this is a devlog not a textbook, so there you have it.

I had to defer on snare scattering, maybe that will be Snares II. I need to let all of my current changes marinate for a bit and let any bugs shake out so it will probably be another week or so before I can report on that. ‘Til then…

SERIES

SERIES

Devlog

SERIES

Snares.