The Oscimillator patch I made started out as a BIA clone, but I couldn’t fine enough documentation regarding the math in the different modes.
Also, as is typical of digital modules, it has three modes. This means that you would probably need to massively complicate the inner workings of the Audulus module and drain CPU. I found that the multiple instances of the oscimillator was enough for me, but I suppose it might be a challenge for someone to take on.
It’s not a full take on Clouds, but Michael Hetrick ported the Oliverb algorithm to Reaktor Blocks, which (it I’m not mistaken) is the same reverb used in Clouds.
Maybe someone defter than I can port it from Reaktor to Audulus. Or maybe I will some day (after I learn DSP a little better)
I’ve been playing around with Marbles since it came out on VCV Rack and it has a very interesting take on random melodies. You play it a bunch of notes from your sequence, like 50 notes. And it remembers the notes and their frequency of occurrence and constructs a scale. Then out of the quantized stepped output plays back notes from the scale randomly along a bell curve. You can bias the probability to one end or the other of the curve as to which notes will be played. Layered on top of this, the quantized step output has a length, like the Turing machine, and can be locked into a loop or have a probability of being changed.
Do you think such an approach would be viable with reset-able S&H nodes? I think this would be awesome to have in Audulus, even if you lose your scale when you close the patch.
Impressive module. At first glance it looks do-able in Audulus, although I suspect it would be rather CPU intensive. As a first step, I would probably build a stepped array of S&H nodes to capture a sequence. You would need at least one array for the random gates and three for the voltages. It might have to wait until we have some more efficient data storage.
decimal frequency capture of uTuring.audulus (306.0 KB)
The whole Marbles unit would definitely be overkill for Audulus, I think. But what makes me think the melodic learning might be possible is the Top Frequency of occurrence module @dcLargo made a while back. It could be stretched to 12 buckets as opposed to 10, but from there I’m unsure how to make a bell curve out of the data or biasing of said curve.
if you used 12 buckets (one for each note) you could certainly capture the number of samples for each. Not sure how you determine if a given scale is a major or the relative minor since they both contain then same notes. I’ll have to read the manual for Marbles. At this point I’m a bit unclear as to what the bell curve is supposed to apply to.
It seems like that’d sort itself out if you forced a key onto it. An algorhythm might assume the first note played is the tonic and then the others could fall into place around that. Does that make sense?
Which notes and how many notes in the scale? Based on frequency of occurrence, winners are those above some ranking, or more likely you choose from the top ranked on down until you reach some agreed-upon number of notes. If you hit 12, though, you’ve gone too far. Seven or eight seems a place to stop, although I prefer seven. Maybe using the log of the freq of occurrence* could help visualize the winners.
Still, calling the first note played the key, regardless the occurrence frequency, would be a reasonable start. It’s hard to say by frequency of occurrence alone what the key would be—apart from cowboy songs, of course!
*(skipping the log of zero, of course—mapping zero occurrences to the log of 1–zero, which is a proper ranking if the note occurs only once, and appropriately as one occurance statistically “next to nothing.”)
Using the first note would certainly work in many cases. You might also be able to determine the key by examining the frequency of notes. In most cases I would think the tonic, third and fifth would probably occur the most often. Since these would be different for the major and relative minor, you might be able to separate them that way.
So I think the way it works with Marbles is that there isn’t the traditional notion of a key in the musical theory sense. It receives notes, analyzes the frequency of occurrence of the notes, and quantized it’s pattern accordingly.
For example, if Marbles receives a sequence like A, G#, A, C the scale will be constrained to A, C, and G# with A being twice as likely to occur than G# and C.
I tried building one today (a day off), and hooked it up to my sequencer.
I built out my freq distribution thing to 12 bins, then set it to sampling midi keystrokes (each Keystroke on midi clocks another sample in.
The result of the sampling is brought out as potential inputs to a custom scale, success in getting on the scale depends on the setting of the “prob threshold” knob. As you increase the knob toward 1 (100%), the scale shrinks down until only bins at that very top value will play.
The randomization comes in by clocking a random 0-1 to set that threshold. Which has the effect of creating a unique scale with each clock pulse.
My quantizer’s “number of degrees” output is used to set the end point for my tone loops, so they only arpeggiate or randomly play over active tones in the present scale for that clock cycle, just as it does for fixed scales. It seems to work fine. The only surprise—and I’m leaving it for now—is that with zero sampled captured, my 12-bin sampler sees all those zero bins as equals in a chromatic scale, so the sequence continues to poop along chromatically, until you give the scale building part some input to build a histogram.
2 2 loop polyrhythm tone seq chord apregg v 11.28.18-3 marble scale.audulus (2.8 MB)
What d’yall think? Is this close to the marble thing?
That’s more than I could have hoped for. I think this is pretty much exactly it! I’ll definitely be adapting this one for my personal library, many thanks!
That’s odd. I’ll take a look.
Could you clarify the octave of results you mentioned? I have been getting 12 distinct bars, starting at A and ending at G#. I have been getting an occasional hit on another bucket when I hit the initial A. That may be the problem! I’m shot for the brain work tonight, but I’ll take a look tomorrow.
Looks like I fixed it. In the MIDI to histogram/scale maker thing I’d used a S/H to latch in the input. When I reset the patch, I wasn’t clearing the S/H. I swapped it with my resettable S/H and now it seems to be solid.
2 2 loop polyrhythm tone seq chord apregg v 11.30.18-1 marble scale.audulus (2.9 MB)
Looks perfecto!
This version adds a REC button on the histogram thing that defaults to on, but toggles off if you want the thing to stop recording what you play on the keyboard. I’m planning tomorrow to make the thing build a no-key scale (hopefully) by accounting for the current key the sequencer is in. In “no-key” I mean if you latch in an F# as the key, then the first bar of the histogram will always represent the tonic of the key. That way, you can keep track of what intervals on the scale are active.
2 2 loop polyrhythm tone seq chord apregg v 11.30.18-2 marble scale.audulus (2.7 MB)
Aw hell! I went ahead and did it! Now—unless I screwed it up—If you change key (using the key button on the sequencer), if you keep playing in-key, the first bin will always be the root or tonic.
2 2 loop polyrhythm tone seq chord apregg v 11.30.18-2 marble scale.audulus (2.7 MB)
Looks great! I will have to give it a thorough testing in the morning.
