Uh, I forgot to set seeds on the sequencers. They now have seeds corresponding to their loop order on the interface, and the count of seeds needed. I’d seen a pattern lock in on two loops, and that just HAD to be fixed.
All these patches I’ve wanted to look at, but for some reason I don’t have the magic words to save patches on my iPad Pro into a format openable by Audulus.
Am I missing something?
Have you tried the workflow app?
I’ll try that. Thanks.
@dcLargo you’re doing some truly astounding work! Keep it up and thanks so much for sharing your journey with us all!
Thanks for that! Will do!
Discovered a few problems while I was working on my attempt at a 2+octave quantizer. One was a problem with my tap sequencer, which assumed positive values (before I switched to 1v/oct format, zero was special—that I planned for—and negatives frequencies did not exis so inn octave a zero is just another value—that I’d overlooked.) which made it uncertain where the output happened to be the integer zero.
The other problem was with the quantizer,which turning out to have non-matching subunits. The topmost msb) unit in the quantizer was miswirred, further confusing things when the sequence arrived at key. Fixed that.
I did get my 2-octave+1 sequencer working. Will upload tomorrow probably. Two outaves + one allows you to get any chord with any extensiions. Two 12-tone scale input devices allow all standard extensions on a chord. The 25 th tone creates the second inversion.
Alas, a 25-bit integer of a single extendescale gets truncated at the one-bit level, so it appears to bear one power of two beyond the limit of numbers .in Audulus. Musically, the 2^25th interval in the chromatic scale is the root of the chord. At the second inversion, techncally, the bit is judt one bit too many.
As it stands, I can’t produce a 25-bit number and not truncate the lower bits, so I opted for a “binary coded 12-tone-scale approace, with a separate scale input the first and second octave, plus a R” input, which if true, qives a value of 2 (root at +2 octaves)
0 being 440 is kind of problematic in general. The way it works in modular land is C1 is typically zero, so sequences may be added together with the expectation of higher notes. In Audulus, as the 1/oct signal probably is negative (better than 50% chance) you end up making super deep bass lines. It makes sense to shift octaves after the quantizing.
If you convert to the 1/oct format prior to quantization, it’s not necessary to have a quantizer more than an octave wide. You can derive the octave using a
floor() expression and the note with a
fract() expression. This is a piece of the uQuant quantizer unit. I multiplied the note portion by 12 to get a value from 0 to 12 for the quantization logic.
After the note has been quantized, I divide the note value by 12 and add it and the octave value before outputting the result. This allows the quantizer to handle any potential input value and output a properly quantized result.
BTW I have found that the current version of Audulus will preserve up to 19 bit integer values without rounding. Internally all values are stored as 32 bit floats.
For the scale of the piece (or random melody, etc) I used that method since, as you mentioned, you only need 12 tones and can handle the octave separately. For the chord piece, I wanted 25 tones, with the triad and the 7th in the first octave and the additional chord extensions and some root alternatives (I’m not doing any inversions at this point, but hoppin’ roots can sound kind of neat!)
The project now has a 2-octave (+ high root) quantizer, fed by two push button scale-code makers and a single button to add a high root. I’m calling this the chord quantizer.
Each tone loop’s final output is quantized by 12-tone quantizer, set to the scale of the melody. I’m calling these the song quantizers.
All the quantizers have the “frequency interval for the nth tone (aka degree) of scale” lookup feature, which has the by-product of giving you the number of tones in the scale. In the song quantizers, this lookup sets the current pitch of the progression, based on the scale being used. In the chord quantizer, which operates from a subset of the major scale, the lookup allows the generation fo various chord tones. (Of course, as this is a fixed scale, an actual quantizer is maybe overkill—a simple lookup via mux would work just as well. Hmmm…)
I removed one drum loop but left both tone loops.
Key is set as before, and handled separately as before, all subsequent processing done then with key normalized to A440 (zero in the audulus 440-based octave convention).
The 16-bar progression machine outputs octave and Interval (degree) for the progression. These are octaves and degree of scale above or below the key. The degree of the progression is sent to a song quantizer’s lookup function which returns the frequency (in octave format) to be added to the octave to give the starting tone of the progression The progressions are sent to the random frequency generator for loop two and to the random chord arpeggiator for loop 1.
For tone loop one, the span of tones to generate is found by looking up the highest interval from the chord quantizer and scaling the random values over that pitch range.
Tone loop 2’s random frequency gen works as before—you set how many 12ths of an octave to spray into the loop.
These random numbers from these generators are added to the progression octave and interval and saved in the loop steps.
On the output side of the sequencer loops, the random pitches (or random chord intervals) are quantized into the song scale, set to the key, and output to the synths.
Here it is:
Last addition today:
Arpeggio button and start@ knob. Knob to the right—arpeggiate upward. To the left—reverse. Start at step 1 (lowest tone) to highest tone.
I need a little light to indicate reverse, but you can hear it anyway!
As I walked out the door tonight to work, it occurred to me that I hadn’t tested the arpeggiator (or the random part) over a progression. I’m not sure it arpeggiates chords on up the scale. I think it’s working at the tonic of the scale (Aeolian running in A gives no sharps or flats, for instance) but I’m not convninced i put the progression in there. Will check tomorrow.
It seems to be doing the right thing now. You choose which chord tones you want on the tone selector buttons—upper buttons for the root through 7th—lower buttons for the next octave tones, 9ths through 15ths. The reference lights show which tones are in-scale, so you can set the tones properly.
Loops 1 can be arpeggiated or random, with the sign of the start@ indicates whether to run the notes upward or downward,
If thinge are sounding or looking cagey, please chime in.
Really nice work.
- I made a clean UI for the 25-tone chord tone selector, with a stereo signal type used to carry the 12- and 13- bit codes from this 2 octave+1 control over to the main sequencer’s #25 input in a somewhat more aesthetically pleasing way than by using two wires. A number label on a button indicates which major scale interval that button represents (for inversions you might reverse the roles of the rows.) The lights between the rows are meant to show which intervals are in-scale for the currently selected scale, so you can set up the proper intervals for an application.
- Added the ability to self-steer progressions by replacing the 16-bar progression machine, which was a hog, with a midi frequency-only patch and a button to pull the current key out of the midi output, so you can enter your progression off the actual key note. (If you want to do progressions by applying octave and degree of scale, as was done for the progression machine, you still can—you just deselect the “-key” button.
Fixed lots of things. Adding arpeggiation revealed many flaws! Almost too many to list. I’ll hit the biggies:
- My original sequencer units were originally designed to run a drum machine, then later, tone frequencies in Hz. Notice that in both these applications all values are positive, and zero has a special meaning—either a drum hit has zero velocity or no tone is needed. Moving all to octave format, while the best route for this project, did cause problems, as they did not respond at all to negative values, and zero represents just another note—the tonic of whatever key you’re in.
- Adding the ability to create progressions based on some key meant sometimes you’d want to dip into octaves below the original key octave. This means the sequencers needed to store and play negative values as well as zero or positive values. As soon as I tried running the arpeggiator I could see this flaw, as all values below zero were clamped to the original key and octave. I think the reason the progression machine worked was that it held that lower octave steady and it got added in later, bypassing the sequencers.
- After lots of hand-wringing and false starts, I decided the simplest fix was to modify my tone sequencers by converting all tones to Hz for storage in the upper tap sequencer, then output back in octave format. Problem solved, and less ugly than some of the workarounds I was considering. The lower sequencer unit stores the velocity info, so it wasn’t a problem.
- My matrix note display was designed assuming only positive numbers. Fixed that.
- One my scale selector, the mixolydian code was wrong. Fixed.
- I’d broken the ability to manually tap tones in via keyboard for a loop out of auto fill mode. Fixed that. Note — if the number of reps per fill set by the conductor is one, then the arpeggio you’re hearing is still being recorded. To reliably grab an arpeggio to play over, set the control to at least two reps and switch off of auto after the first pass.
This little patch frees up your midi keyboard by hanging onto the current interval of a progression. To use it, replace that little external midi patch on my last upload with this one. When you’re at a spot in your progression you’d like to hang on, hit the HOLD button. The MDI trigger updates the S/H each time you press a midi key. The hold button disables the trigger.
Latching MIDI freq source.audulus (4.5 KB)
The latest patch is fantastic with the new midi node. Some time it would be nice to have an iPad friendly light version. This runs beautifully on my laptop but kegs at 120% on my ipad mini 4.
Thx! It’s definitely a hog—runs in the high 70s on my iPad Pro. Taking off the 2nd drums loop will help. I spaced out everything inside the UI to allow ripping out loops that aren’t needed. All that connects to the drums are sync and reset, so it’s easy to put back.
I could only fit the 2nd drum loop back in because I’d dropped the progression sequencer. I do like the extra bit of polyrhythm I got adding the second drum loop back, but then again, the 2nd tone loop does that, too. The res drum-derived synths I made mainly because the ResDrum doesn’t add a big processor hit.
By the way, I’m looking at automating the chord output as you crawl up the scale. To that end, I made a little rotate bits patch this evening (DEMO attached).