Gregory Taylor

 of this tutorial, I spent some time walking through the process of setting up your system to make use of the Oopsy software for compiling and downloading 

 patches to a Daisy-enabled device. I'm working with a Daisypatch in this tutorial, but those of you with a Daisypetal (the stompbox version of the Electrosmith offerings) will find very little in the way of difference - the few differences that exist have mostly to do with the knobs and encoder and what they address - things you can find described in the 

In the time since you read Part one, I hope you've had a chance to try your hand at compiling and downloading the example patches that come with the Oopsy software. I've personally really enjoyed having that lovely reverb sitting in my Eurorack.

For this second part of our tutorial, I thought I'd create a few 

 patches and go over some tips and tricks that I hope can be the start of you being able to create your own Daisypatch modules. I'm also going to be starting with something very simple, and the looking at the process of building that out to create something interesting and unique (those of you who are familiar with my book 

 will be familiar with this approach). I also want to concentrate on something that I know a number of you are probably going to be doing — porting 

 patchers [your own or someone else's] to use with a Daisypatch. When we're done, you should have a couple of interesting things to run on your Daisypatch that may not be rocket surgery, but are really compelling. Let's get started!

Daisypatch_Walkthrough_2.zip

I'd say that the very best place for us to start is by spending a few minutes with the video on the Oopsy software that my friend and colleague Graham Wakefield posted a few weeks back. It's a great visual overview of what Oopsy is all about, and I'll be reinforcing some of these ideas as we go along. (It’s funny, but taking in that same information feels quite different to me while staring at a Daisypatch and a folder full of example patches.) I did this very thing myself, to acquaint/reacquaint myself with "the lay of the land."

I've really been looking forward to announcing this! *Oopsy* is a way to embed the precise flexibility of Max/MSP's gen~, from microtemporal scheduling to single-sample feedback loops, into the hands-on flexibility and performative happy accidents of modular analog and digital hardware, using Daisy-enabled devices. 

Where:
- Get Oopsy from https://github.com/electro-smith/oopsy
- Get Max/MSP + gen~ from https://cycling74.com
- Get Daisy from https://www.electro-smith.com/daisy
- Oopsy on Cycling '74 forum: https://cycling74.com/forums/oopsy/
- Oopsy on the Electrosmith forum: https://forum.electro-smith.com/c/integrations/oopsy-max-msp-gen
- Oopsy on MW: https://www.muffwiggler.com/forum/viewtopic.php?f=16&t=242322

Background: I got excited about Daisy hardware when I heard about the kickstarter, and backed it immediately, as I'm really fascinated by the possibility of putting the capacities of digital signal processing and control in gen~ (from microtemporal scheduling to single-sample feedback loops), into the midst of modular analog and digital hardware, with its hands-on flexibility and performative happy accidents. The folks at Electrosmith kindly sent me some other Daisy hardware, and in spare moments over the past months I put together this Oopsy package to streamline the mapping of gen~ to the Daisy hardware. It's now open sourced on the ElectoSmith Github, and I'll be continuing to add more features, hardware support (e.g. Noise Engineering's Versio), examples, and posting videos here. 

- What is gen~? An open-ended domain of audio-processing inside of Max/MSP, which regenerates its optimized machine code with every edit you make, allowing a variety of things that are difficult or impossible to patch normally, like sample accurate granular scheduling and single sample feedback for complex filters. Also the code can be exported as C++ for use outside of Max for embedded devices etc. Also gen~ was kind of my PhD thesis :-)

- What is Daisy? A fantastic kickstarted DSP platform that runs in Eurorack, guitarpedals, synths, etc.-- with a few commercial users already like Noise Engineering Desmodus Versio, the QuBit Surface & Data Bender, etc.  

- What does Oopsy do? It snoops your Max patch, exports and snoops and the C++ code of each gen~ it finds, and wraps that up in a bundle of code to make it work with the Daisy with some nifty mappings. So, every time you hit Ctrl-S to save, it can rebuild & upload to your Daisy hardware.

Like, subscribe, etc. etc. to hear more about it  :-) 

https://www.patreon.com/grrrwaaa

Oopsy: Daisy from gen~ in Max/MSP

After I compiled and downloaded the example files and played with them (that reverb and the FM are pretty wonderful, by the way), I thought I’d try some stuff of my own. I’ve written some 

-based tutorials of my own along the way, so I had a nice collection of things I figured I could repurpose as Eurorack modules. In a way, this installment is about the practice of porting patches to run on the Daisypatch.

Once again, I’d like to start by sharing some tips to smooth your way — tips that 

 suggest to you that I made some silly mistakes getting started, let’s just say. Let’s get the “gotchas” out of the way first:

Here are some patching tips for setting up your interface quickly and efficiently. Once coming up with a consistent naming convention becomes a matter or habit, you’ll be amazed at how rapidly you can work!

 operators are associated with the audio in/audio out jacks on the Daisypatch front panel. But in addition, it’s good to get into the habit of remembering that you can use arguments to the 

 operators to associate them with other input/output knobs and jacks on the front panel of your Eurorack module. Here are some examples:

My final bit of “advice to the beginner” isn’t about gotchas or naming conventions at all — I found that a little pre-planning goes a long way toward guaranteeing a patch creates a module that’s a joy to use. Taking a few minutes to sit down and plan out what parameters I wanted to assign to knobs and roughing out my interface meant that actually doing the patching/porting was not only quicker, but produced results that were compelling with my first download to the Daisypatch. I don’t know about you, but I always find it really satisfying when my initial UI design is such that I “live with” my patch/device for a while rather than redoing it right away - UIs that grow from the experience of using something and “getting it under your fingers” is always my goal.

For my first attempt at converting a patch to run on the Daisypatch, I thought I’d start simple: a single LFO based on what I created in 

In that tutorial, I took my standard go-to MSP LFO patch and ported it to 

. Here's what the original LFO ported to 

image.png

For my first attempt, I decided to slim things down a bit to keep it simple — I thought I’d try to set my Daisypatch device up so that I only really had to have four parameters on knobs to start with. That meant that that I needed to trim things down a little bit.

 version of the LFO patch, I noticed that the patcher relied on an external 

. I'll need to replace that with an internal phasor operator controlled by a frequency parameter set using one of the knobs.

Next, I decided what other parameters I’d actually want to access from the front panel, which meant that I figured I might trim off some functionality from the original patch. Here's what I did:

I removed some interesting features, but I figured I could always go back and add them in later.

 operators. Since I wanted the controls to make conceptual sense on my Daisypatch module (and since I knew about the naming and alphabetical parameter-to-knob assignments), I figured I ought to do some judicious 

 operator renaming. I decided to go with the cv

way of doing things, and to make sure that I didn't have any parameter names that came before lower-case "c" in the alphabet.

My parameters also needed minimum, maximum, and default values for each parameter using attributes. I decided to take Graham’s advice about smoothing input voltages, and so I added 

I wanted an output in the 0. - 5.0 volt CV range, so some output scaling was in order. Since the 

 signals to 0.v - 5.0v in Eurorack for me, the 

 operator to add scales from 0- 1 (i.e. it's a 

 LFO patch included a nice trigger sent at the start of the waveform, which seemed like a useful feature to keep - I'd send that bit of the original patching out the GATE1 output on the Daisypatch. Since I’d spent some time with Graham’s intro video, I knew that it’d be good hygiene to use an 

 abstraction to make sure that all of my gates were output properly.

Here’s the result of that activity. Although I've tried to describe things in some detail, the work itself was almost entirely a matter of 

I saved my patch, put my Daisy Seed into “receive mode” with a little button pushing on the Daisy Seed, and punched the big round button on my Oopsy 

When the download was complete, I pushed in the rotary encoder on the Daisy front panel and turned it until I was my parameters displayed:

Looked good. Of course, the proof is in the hearing I patched the CV OUT1 jack to the cutoff of my trusty Filtare SEII, fed some yummy noise into it, and spent some happy moments enjoying some celebratory knobtwisty filtering.

This got me thinking a little about what kinds of LFO I 

 currently have in my Eurorack. I realized that I’d been spending time recently using sync’d LFOs whose summed outputs were used for various control tasks. (I was doing this using MSP and my Expert Sleepers modules for this.) Staring at those displays, I realized that I could just grab that original MSP patch I was using, port it to 

). That would make a great addition to my module set, and doing it with Oopsy was really just a minor variation on what I’d just done.

 patch I was working on), some decisions on the parameters I wanted, and I was on my way. First, I sat down and planned out what parameters I wanted as knobs, and what features my triple-summed LFO module would have.

The plan would be to have single main frequency that drove all three of my LFOs, with each individual LFO having

And — as long as I was at it, I thought it'd be cool to collect each retrigger gate for the three oscillators and output them as a single string of gates, too.

Apart from adding the phase offset back into my basic LFO patch, there was hardly any work to do at all.

 patch itself takes three copies of this patch, copies and modifies the 

 operators and reorders them to set which controls I want to be under the knobs. (I experimented with this a little bit. Being able to patch, save, and load again and again is really a joy.) Here’s what I wound up with:

The result of this patching gave me the following tweakable parameters for the patch:

In addition, I had the following parameters available using the Daisypatch’s rotary encoder:

That’s a pretty full-featured set. It looked shipshape, so I saved, enabled the Daisy Seed, punched the button, and you guessed it. Wow!

I decided to try leveraging a few more old 

 patches I had laying around that I’d love to see as Eurorack tools. One of the features of 

 I particularly love is - of course - its ability to use single-sample processing to create ringing delay lines. Do I have a patch for that? I do - created as part of this 

Note: Synchronicity is wonderful. While I was writing this, I got a note from a friend out on the left coast of this country mentioning that he was interested in implementing this as a guitar pedal on the Daisypetal. (You know who you are, man. Shouting out to you!) That email just made me sure that I was on the right track, although what I was making might be a little different than a pedal incarnation of the 

 patch. So I opened up my tutorial, and grabbed this patch:

This time, I'd be working with audio inputs, although some of the patch would have to be relocated for use on the Daisy.

There were a few small modifications and tweaks to make this one sing.

The major revision involved handling the keyboard input on the original patch, which was handled externally to the 

 patch itself. I realized that I could replace the keyboard with a knob that selected a MIDI note number and used that to calculate the amount of delay from there. It was not only not very difficult, but the result looked quite a lot like my external patch minus some 

 constant, with a little smoothing courtesy of

 operators here would mean that they'd show up as 

, which I don't want. Time to un-name those 

Oh — remember my comment about reminding yourself that the Daisypatch doesn't run at the usual 441 kHz. I usually use in Max? I can use the 

 operator, and I'll never have to worry about setting the size of my 

Finally, I thought I'd like to add a little clipping to the patch output. I usually use the ordinary 

 operator, but our mutual friend Graham Wakefield (to whom we really owe a pint) suggested something new: output saturation rather than clipping by using a 

 operator sequence. It's pretty nice and this tutorial's official "Graham pro-tip."

The rest of the patch was very similar to my tutorial patch.

Once again — patch saved, Daisy Seed enabled, button pressed, and I have a positively awesome ringing stereo delay that sounds amazing and is nothing like anything else in my rack.

I was actually starting to feel a little guilty about pawing through my old 

 patch pile and spending just a couple of minutes creating things that ran on my Daisypatch, but hey - I had some pretty nice stuff that I didn’t have on my Eurorack. The guilt passed and I turned my attention to the ever-popular N-second recirculating delay line (the “Fripp in the Box," as it is sometimes fondly called). Boy, that sure would be great to have in my rack, wouldn’t it? So I hunted around and found an example I’d created as a part of the 

 for Beginners tutorial series - it was right there in Tutorial 4.

Well nothing too fancy here. In fact, I’ll hardly need to do anything at all. But wait. Given how much memory the Daisypatch has, how about a 

Remember how I mentioned at the start of this tutorial that it was important to keep in mind that my Daisypatch modules would be running at 48 kHz. in stead of 44.1 kHz.? Yep, that's right - here's where I made my first big mistake of my porting frenzy. 32 seconds of delay at 44.100 kHz.

I took at run at the thing and thought, "That's weird. I've only got about 29 seconds of delay. What's the deal?"

It turns out that 32 seconds at 48000 samples per second will require a stereo buffer with 1,536,000 samples rather than 1,411,200 samples! 

How might I rescue myself from a lifetime of stupidity of this nature going forward? Our mutual friend Graham chimed in again with a brilliant solution that I will use hereafter: make the calculation for the length of the buffer a part of the 

 — Instead of trying to figure the number of samples forever, I could go with a 

There was one other issue that I suppose I never had to think much about in MSP. I was getting some real glitching that it took a while (and the kind advice of my friend Graham Wakefield) to solve. Simply put, I needed to do some 

 smoothing of the delay time parameter. Remember how those nice oopsy.ctrl.smooth operators are intended to deal with noisy hardware input? It turns out that even a small amount of noice amplified over the entire 32 seconds of the delay buffer builds up and causes a little trouble (even 1% noise will be a 1/3 second glitch). Certainly not something I ever run into working on a laptop.

Since I had a pretty long delay time, I added a pair of the more aggressive 

 operator, it worked like a charm once I’d set up the 

 operators for my user interface knobs (see

This patch is kind of interesting, if for no other reason that I now have lots of memory space for my delay. I think that I’m going to return to this patch at some point. My pal Darwin Grosse has this amazing recirculating delay matrix as part of the MODE plug-in collection that I have dearly missed. And there’s also that recent Forum exchange about changing the delay lengths on the fly without pitch change. Oooooh….

I’m going to close this walkthrough and tutorial with one of the things that I Daisy-fied that I really love. Back in the day when 

 was young and Great Sages scoured the interwebs in search of filter code that could be codeboxed, My Forum spelunking turned up a posting whose title plumbs the deep well of understatement: 

The State Variable Filter shared therein has been a favorite of mine ever since (with a minor addition I’ll show you in a minute), and has resided happily in my live performance laptop rig nearly ever since. Flushed with the success of my recent endeavors, I thought I might create a Daisypatch version of it (

). Once again, it was really a case of grabbing the 

 version and duplicating it (since I wanted a stereo filter), working out my 

 operator labels, and… well, as long as I was at it I thought I’d add a lagniappe (“a little somethin’ extra,” as they say in New Orleans): the ability to crossfade between filter types. Here’s the basic patch I roughed out, with my addition there at the center right:

 output modes. At first, I thought that all I needed was a crossfade between lowpass, bandpass, and highpass outputs. But I suddenly realized that my Daisypatch had 

 outputs, so I could have a second stereo output that crossfaded lowpass, 

h, and highpass output by just doing a little operator duplication.

And, as long as I was at it, I figured I'd replace my 

 operators with sequences of math operators (It's a personal thing I'm doing at the moment). The other bit is my non-use of the 

constant that dates from my childhood days of learning that π = 3.14159 and the delight I always felt when typing those 5 decimal places as a way of feeling as though I 

, somehow.... You might have simply transformed the 

 operator in the version above to use the 

 as you ported without giving it a thought.

 operators Graham's little saturation hack. Here's the result:

So I've installed my toolchain, got it working, and ported/modified a couple of patches to do some cool stuff in my rack. There's just one more little trick to perform: the 

. This one's as wonderful as it is stupid simple: All I do is to take the four 

 objects from the patches I've created, add a name to each of them by typing an argument into the

 object's message box, and then drop all four of those now-named 

 objects into a new patch with an Oopsy bpatcher in it, and renamed it as 

And — that's right, you guessed it — I set my Daisy Seed to receive, punch the button, and 

are loaded to the Daisypatch, where I can use the rotary encoder to choose between them. Pretty sweet!

Well, I think it's time to pour a celebratory libation, take a rest, and enjoy my new Eurorack stuff! I hope that this manages to communicate a little of my enthusiasm for the Daisypatch, that it gives you a little help getting set up, and that these humble patches whet your enthusiasm.

In Part one of this tutorial, I spent some time walking through the process of setting up your system to make use of the Oopsy software for compiling and downloading gen~ patches to a Daisy-enabled device. I'm working with a Daisypatch in this tutorial, but those of you with a Daisypetal (the stompbox version of the Electrosmith offerings) will find very little in the way of difference - the few differences that exist have mostly to do with the knobs and encoder and what they address - things you can find described in the oopsy_petal.maxpat and oopsy_field.maxpat patches in the oopsy distribution.

For this second part of our tutorial, I thought I'd create a few gen~ patches and go over some tips and tricks that I hope can be the start of you being able to create your own Daisypatch modules. I'm also going to be starting with something very simple, and the looking at the process of building that out to create something interesting and unique (those of you who are familiar with my book Step by Step will be familiar with this approach). I also want to concentrate on something that I know a number of you are probably going to be doing — porting gen~ patchers [your own or someone else's] to use with a Daisypatch. When we're done, you should have a couple of interesting things to run on your Daisypatch that may not be rocket surgery, but are really compelling. Let's get started!

After I compiled and downloaded the example files and played with them (that reverb and the FM are pretty wonderful, by the way), I thought I’d try some stuff of my own. I’ve written some gen~-based tutorials of my own along the way, so I had a nice collection of things I figured I could repurpose as Eurorack modules. In a way, this installment is about the practice of porting patches to run on the Daisypatch.

Once again, I’d like to start by sharing some tips to smooth your way — tips that might suggest to you that I made some silly mistakes getting started, let’s just say. Let’s get the “gotchas” out of the way first:

If you’re porting a gen~ patch to your Daisypatch module, it might not occur to you right away to be mindful of parts of your original gen~ patch that are associated with the sample rate MSP is using.  Remember that the Oopsy software lets you change the rate at which your patching runs to 32kHz, 48 kHz. (the default), or even 96 kHz. If you’re like me and have grown used to MSP running at 44.1 kHz., you might be surprised when you finally work out why your 16-second delay line is actually only giving you 14.7 seconds of delay. (PSST! You forgot to change the argument that sets the size of your data or buffer operator!) That's definitely an error I made. Happily the basic gen~ operators (such as the mstosamps operator and the samplerate constant) automatically adjust for you. Keep an eye on those buffers, though….

When you’re creating, modifying, or porting your gen~ patch, make sure that every inlet and outlet is identified by a number that you only use once.

This one won’t confuse everyone, but it was an assumption that caught me by surprise, anyway: The audio output jacks on the Daisypatch are not DC-coupled. If, like me, you were accustomed to using an audio interface such as a MOTU FastLane to send control voltages to your Eurorack, it might not occur to you that the Daisypatch audio outputs work differently. The place I noticed it involved trying to send a fixed control voltage out one of the audio outputs and discovering that things weren’t working out as I expected (it’s not a problem at all with the CV out jacks, of course).

The CV and knob inputs update at a default block-rate of 1ms for your Daisy. The Oopsy help files suggest that you might want to add some filtering or smoothing for control voltages (the oopsy_field patch comments says to do so "...depending on how they are used in the patch.") There are a pair of very nice smoothing abstractions available to handle control voltages and knob inputs — a 10 Hz. two-pole lowpass filter (oopsy.ctrl.smooth2) and a three pole 30 Hz. lowpass filter (oopsy.ctrl.smooth3) for when you want to do a little more aggressive filtering from hardware input analog-to-digital convertors. With one exception I'll mention later on, I found that just adding an oopsy.ctrl.smooth2 abstraction on any CV or knob input was a good practice, generally speaking. You'll find that to be a general approach in the patches I'm going to be porting.

Don't give your parameters names that begin with a number. Oopsy will think it's dealing with a constant.

In my opinion, it's a really good idea to work with a consistent way of naming parameters. Although it's true that param ctrl1, param cv1, param knob1, kn1_<parameter name> or param cv1_<parameter name> will all associate a parameter with Knob 1, your life will be a good deal easier if you always use one way of specifying things (I'm a cv1_<parameter> person, myself).

Here are some patching tips for setting up your interface quickly and efficiently. Once coming up with a consistent naming convention becomes a matter or habit, you’ll be amazed at how rapidly you can work! 

The first four in and out operators are associated with the audio in/audio out jacks on the Daisypatch front panel. But in addition, it’s good to get into the habit of remembering that you can use arguments to the param operator and to in and out operators to associate them with other input/output knobs and jacks on the front panel of your Eurorack module. Here are some examples:

param ctrl1, param cv1, param knob1, kn1_<parameter name> or param cv1_<parameter name> will all associate a parameter with Knob 1 on the Daisypatch module. The same works for all four knobs.  If you don't use one of these naming conventions, Oopsy will grab the first four parameter names in alphabetical order and assign them to the four knobs.

You can identify the Daisypatch's GATE 1 and GATE 2 jacks as param gate1 and param gate2.

You can associate an out operator with another of the Daisypatch’s outputs using an argument to the out operator — out 5 cv1 associates the fifth out operator’s output with the CV 1 jack, out 7 gate1 associates the seventh out operator’s output with the GATE 1 jack, and so on.

MIDI input/output on the Daisypatch is converted to/from normalized byte streams that are identified using arguments such as in 5 midi or out 6 midi.

What happens if you have more parameters you want to control in your patch than what's afforded you by the Daisypatch hardware? Easy - you just add a param operator for them, too. There's one thing to keep in mind, though: those parameters will be listed in alphabetical order (upper case/lower case). While all the aliasing for the four knobs winds up appearing on the OLED display of your Daisypatch as kn1-kn4, using capital letters to specify the name of a parameter will list those parameters before the knobs, which may not be what you want. I tend to set up my parameter naming so that the knobs are all listed first and in order, followed by my other parameters. Your mileage may vary, of course.

For my first attempt at converting a patch to run on the Daisypatch, I thought I’d start simple: a single LFO based on what I created in this tutorial. 

In that tutorial, I took my standard go-to MSP LFO patch and ported it to gen~. Here's what the original LFO ported to gen~ looked like:

For my first attempt, I decided to slim things down a bit to keep it simple — I thought I’d try to set my Daisypatch device up so that I only really had to have four parameters on knobs to start with. That meant that that I needed to trim things down a little bit. 

Looking at my gen~ version of the LFO patch, I noticed that the patcher relied on an external phasor~. I'll need to replace that with an internal phasor operator controlled by a frequency parameter set using one of the knobs.  

The low/high output scaling ranges were jettisoned, too

Since I was creating something that produced a single LFO waveform, I figured that I could get rid of the inverted ramp as a waveform choice (since inverting the output of the whole LFO would do the same thing). 

Then, I turned my attention to my param operators. Since I wanted the controls to make conceptual sense on my Daisypatch module (and since I knew about the naming and alphabetical parameter-to-knob assignments), I figured I ought to do some judicious param operator renaming. I decided to go with the cvN_<parameter_name> way of doing things, and to make sure that I didn't have any parameter names that came before lower-case "c" in the alphabet.

My parameters also needed minimum, maximum, and default values for each parameter using attributes.  I decided to take Graham’s advice about smoothing input voltages, and so I added oopsy.ctrl.smooth2 abstractions to all of the param operators’ outlets. 

I wanted an output in the 0. - 5.0 volt CV range, so some output scaling was in order. Since the out 1 cv1 operator will always map 0. - 1.0 gen~ signals to 0.v - 5.0v in Eurorack for me, the scale operator to add scales from 0- 1 (i.e. it's a scale -1 1 0 1 1 operator).

My original gen~ LFO patch included a nice trigger sent at the start of the waveform, which seemed like a useful feature to keep - I'd send that bit of the original patching out the GATE1 output on the Daisypatch. Since I’d spent some time with Graham’s intro video, I knew that it’d be good hygiene to use an oopsy.gate.min abstraction to make sure that all of my gates were output properly.

Here’s the result of that activity. Although I've tried to describe things in some detail, the work itself was almost entirely a matter of param object renaming and attribute addition:

I saved my patch, put my Daisy Seed into “receive mode” with a little button pushing on the Daisy Seed, and punched the big round button on my Oopsy bpatcher.

Looked good. Of course, the proof is in the hearing I patched the CV OUT1 jack to the cutoff of my trusty Filtare SEII, fed some yummy noise into it, and spent some happy moments enjoying some celebratory knobtwisty filtering. 

This got me thinking a little about what kinds of LFO I didn’t currently have in my Eurorack. I realized that I’d been spending time recently using sync’d LFOs whose summed outputs were used for various control tasks. (I was doing this using MSP and my Expert Sleepers modules for this.) Staring at those displays, I realized that I could just grab that original MSP patch I was using, port it to gen~ (which is easy, as I described in the gen~ LFO tutorial). That would make a great addition to my module set, and doing it with Oopsy was really just a minor variation on what I’d just done.

One cup of coffee, a little gen~ patch copying (I took the basic gen~ patcher above and dropped it into a gen operator inside the gen~ patch I was working on), some decisions on the parameters I wanted, and I was on my way. First, I sat down and planned out what parameters I wanted as knobs, and what features my triple-summed LFO module would have. 

The plan would be to have single main frequency that drove all three of my LFOs, with each individual LFO having 

a multiplier-based variation on the main LFO frequency

an adjustable duty cycle for the square wave choice

the ability to invert the waveform output prior to summing

The tripLFO.maxpat gen~ patch itself takes three copies of this patch, copies and modifies the param operators and reorders them to set which controls I want to be under the knobs. (I experimented with this a little bit. Being able to patch, save, and load again and again is really a joy.) Here’s what I wound up with:


kn2_mult1 (main frequency multiplier for LFO 1 - knob 2)

kn3_mult2 (main frequency multiplier for LFO 2 - knob 3)

kn2_mult3 (main frequency multiplier for LFO 3 - knob 4)

sq_duty1 (duty cycle for for LFO 1 when using square wave output)

sq_duty2 (duty cycle for for LFO 2 when using square wave output)

wq_duty3 (duty cycle for for LFO 3 when using square wave output)

wave1 (waveform select for LFO 1 - sine, ramp, triangle, square, random)

wave2 (waveform select for LFO 2 - sine, ramp, triangle, square, random)

wave3 (waveform select for LFO 3 - sine, ramp, triangle, square, random)

I decided to try leveraging a few more old gen~ patches I had laying around that I’d love to see as Eurorack tools. One of the features of gen~ I particularly love is - of course - its ability to use single-sample processing to create ringing delay lines. Do I have a patch for that? I do - created as part of this gen~ tutorial on delay lines, in fact.

Note: Synchronicity is wonderful. While I was writing this, I got a note from a friend out on the left coast of this country mentioning that he was interested in implementing this as a guitar pedal on the Daisypetal. (You know who you are, man. Shouting out to you!) That email just made me sure that I was on the right track, although what I was making might be a little different than a pedal incarnation of the gen~ patch. So I opened up my tutorial, and grabbed this patch:

The major revision involved handling the keyboard input on the original patch, which was handled externally to the gen~ patch itself. I realized that I could replace the keyboard with a knob that selected a MIDI note number and used that to calculate the amount of delay from there. It was not only not very difficult, but the result looked quite a lot like my external patch minus some message boxing and dspstate~ stuff I could do with the samplerate constant, with a little smoothing courtesy of oopsy.ctrl.smooth3 thrown in:

My original patch named the history operators. That's fine in an ordinary gen~ patch, but naming the history operators here would mean that they'd show up as parameters, which I don't want. Time to un-name those history operators....

Oh — remember my comment about reminding yourself that the Daisypatch doesn't run at the usual 441 kHz. I usually use in Max? I can use the samplerate constant as an argument to the delay operator, and I'll never have to worry about setting the size of my delay operator ever again!

Finally, I thought I'd like to add a little clipping to the patch output. I usually use the ordinary clip -1 1 operator, but our mutual friend Graham Wakefield (to whom we really owe a pint) suggested something new: output saturation rather than clipping by using a * 0.5 > tanh > * 2 operator sequence. It's pretty nice and this tutorial's official "Graham pro-tip."

The rest of the patch was very similar to my tutorial patch.

Once again — patch saved, Daisy Seed enabled, button pressed, and I have a positively awesome ringing stereo delay that sounds amazing and is nothing like anything else in my rack. 

I was actually starting to feel a little guilty about pawing through my old gen~ patch pile and spending just a couple of minutes creating things that ran on my Daisypatch, but hey - I had some pretty nice stuff that I didn’t have on my Eurorack. The guilt passed and I turned my attention to the ever-popular N-second recirculating delay line (the “Fripp in the Box," as it is sometimes fondly called). Boy, that sure would be great to have in my rack, wouldn’t it?  So I hunted around and found an example I’d created as a part of the gen~ for Beginners tutorial series - it was right there in Tutorial 4.

Well nothing too fancy here. In fact, I’ll hardly need to do anything at all. But wait. Given how much memory the Daisypatch has, how about a 32-second delay line? Sure - let’s see if it works....

Remember how I mentioned at the start of this tutorial that it was important to keep in mind that my Daisypatch modules would be running at 48 kHz. in stead of 44.1 kHz.? Yep, that's right - here's where I made my first big mistake of my porting frenzy. 32 seconds of delay at 44.100 kHz. 

It turns out that 32 seconds at 48000 samples per second will require a stereo buffer with 1,536,000 samples rather than 1,411,200 samples! D'oh! 

How might I rescue myself from a lifetime of stupidity of this nature going forward? Our mutual friend Graham chimed in again with a brilliant solution that I will use hereafter: make the calculation for the length of the buffer a part of the data operator itself — Instead of trying to figure the number of samples forever, I could go with a data samplerate*32 2 operator. Cool, huh?

There was one other issue that I suppose I never had to think much about in MSP. I was getting some real glitching that it took a while (and the kind advice of my friend Graham Wakefield) to solve. Simply put, I needed to do some serious smoothing of the delay time parameter. Remember how those nice oopsy.ctrl.smooth operators are intended to deal with noisy hardware input? It turns out that even a small amount of noice amplified over the entire 32 seconds of the delay buffer builds up and causes a little trouble (even 1% noise will be a 1/3 second glitch). Certainly not something I ever run into working on a laptop. 

Since I had a pretty long delay time, I added a pair of the more aggressive oopsy.ctrl.smooth3 operators in series. 

Daisy_tutorial.png

In the second part of this tutorial, I’m going to create a few gen~ patches and go over some tips and tricks that I hope can be the start of you being able to create your own Daisypatch modules. I also want to concentrate on something that I know a number of you are probably going to be doing — porting gen~ patchers [your own or someone else's] to use with a Daisypatch.

oopsy-daisy-—-an-introduction-part-2

These articles are really great! I think I need to order one soon... thanks again Gregory!

Gosh, thanks. I got a nice note from Graham Wakefield about the piece this morning that included a really lovely little hack that I just had to include (Let's just say that he was sympathetic to my idiocy when it came to remembering that I was always going to be working in 24/48/96 kHz. on the Daisypatch). I've updated the page and the downloadable content as well. If you've already grabbed the example files, grab 'em again. :-)

a dope tutorial! (do people still say 'dope'?... i may have dated myself there a bit 😊)

i looked up saturation to learn more but i'm not finding math explanations(and when i run a sine-wave at 1Hz through '* 0.5' -> 'tanh~' -> '* 2.' ...it doesn't look like much of a change... i doubt i'm able to see the detail i'm looking for with scope~, though... and probably more likely to see changes with a more complex mix of signals)... i wonder if there might be an explanation somewhere on the net describing the mathematical difference? 

(something a bit like this, except for audio instead of neural networks:

https://stackoverflow.com/questions/13632976/neural-network-with-tanh-wrong-saturation-with-normalized-data

they write, "will force the gradients into the most non-linear value range and speed up the learning"... which explains why the math provides the result it does for the neural-network... it also helps me understand that saturation is most present near the asymptotes(i guess that's obvious but it's good to learn the word 'asymptote' to know the top and bottom portion of the 'S'-like curvature by name 👨‍🎓)... so then i wonder how they come up with values like multiplying by '0.5' or '2/3' before tanh, etc. to create the result which pushes everything into the area of the asymptotes 

 to the amount they describe...?)... probably beyond the scope of this tutorial, but just got me curious...

thanks again for an amazing tutorial! (i just got my Daisy Petal, excited to try things out now)

a dope tutorial! (do people still say 'dope'?... i may have dated myself there a bit 😊)

 i looked up saturation to learn more but i'm not finding math explanations(and when i run a sine-wave at 1Hz through '* 0.5' -> 'tanh~' -> '* 2.' ...it doesn't look like much of a change... i doubt i'm able to see the detail i'm looking for with scope~, though... and probably more likely to see changes with a more complex mix of signals)... i wonder if there might be an explanation somewhere on the net describing the mathematical difference? 
(something a bit like this, except for audio instead of neural networks:
https://stackoverflow.com/questions/13632976/neural-network-with-tanh-wrong-saturation-with-normalized-data
they write, "will force the gradients into the most non-linear value range and speed up the learning"... which explains why the math provides the result it does for the neural-network... it also helps me understand that saturation is most present near the asymptotes(i guess that's obvious but it's good to learn the word 'asymptote' to know the top and bottom portion of the 'S'-like curvature by name 👨‍🎓)... so then i wonder how they come up with values like multiplying by '0.5' or '2/3' before tanh, etc. to create the result which pushes everything into the area of the asymptotes exactly to the amount they describe...?)... probably beyond the scope of this tutorial, but just got me curious...

thanks again for an amazing tutorial! (i just got my Daisy Petal, excited to try things out now)


The [/ 2] > [tanh] > [*2] will have almost no effect on signals in a reasonable -1 to 1 range, but will start to saturate more when they go outside that range, and will never be louder than -2 .. 2. The reason I recommended that is because the DaisyPatch audio outputs are mapping -1..1 gen~ signals to -5v to 5v in the rack, which is a typical voltage range for audio signals in Eurorack. But Euro voltages can also handle up to about -10v to 10v (which would be -2..2 in gen~ land). So rather than just hard clipping with [clip -1 1], which can be a bit harsh, I figured the extra available headroom could be used to soft limit.

You can replace the "2"s with a smaller parameter to make the saturation/limiting kick in earlier if you like :-) or replace it with a fancier saturation algorithm ;-)

And yeah, the relation to NNs is fun. A neuron in a neural network is bascially a matrix mixer with a DC offset channel fed into a waveshaper. Training a network is basically making lots of tiny nudges to the mixer knobs so that the final output gets closer to what you want, which usually means making better category/pattern discriminations of the inputs and reflecting those with more distinct outputs. Which, to my mind, sounds like getting more dynamic/interesting outputs from a variety of likely inputs. Which is a bit like painstaking knob-twiddling to find the most interesting metastable points in a big sonic feedback installation. There's perhaps also some mechanism-independent isometry with dub selector knowhow.

The [/ 2] > [tanh] > [*2] will have almost no effect on signals in a reasonable -1 to 1 range, but will start to saturate more when they go outside that range, and will never be louder than -2 .. 2.  The reason I recommended that is because the DaisyPatch audio outputs are mapping -1..1 gen~ signals to -5v to 5v in the rack, which is a typical voltage range for audio signals in Eurorack. But Euro voltages can also  handle up to about -10v to 10v (which would be -2..2 in gen~ land). So rather than just hard clipping with [clip -1 1], which can be a bit harsh, I figured the extra available headroom could be used to soft limit. 

ah, thank you, Graham, that helps. i realize now, for audio: we are taking (..what normally, without tanh/etc., would be..) clipped audio and scaling 

towards the asymptote area where the reshaping is most effective for harmonic distortions(whereas the NN description is working with non-clipped data(or maybe not) to scale 

 or maybe just 'normalize' differently.. into the asymptote area yet again, where i guess that speeds up learning somehow...)

... 😂and i definitely don't have this knowhow because i have no idea what any of these words mean:

although i think 'GrandMaster Dub Selector Knowhow' is the title by which we should all refer to Graham Wakefield from now on 😃🙌 

(but wait... with a PhD that would be "Dr. GrandMaster Dub Selecta Knowhow")

ah, thank you, Graham, that helps. i realize now, for audio: we are taking (..what normally, without tanh/etc., would be..) clipped audio and scaling down towards the asymptote area where the reshaping is most effective for harmonic distortions(whereas the NN description is working with non-clipped data(or maybe not) to scale up or maybe just 'normalize' differently.. into the asymptote area yet again, where i guess that speeds up learning somehow...)

mechanism-independent isometry with dub selector knowhow

although i think 'GrandMaster Dub Selector Knowhow' is the title by which we should all refer to Graham Wakefield from now on 😃🙌 
(but wait... with a PhD that would be "Dr. GrandMaster Dub Selecta Knowhow")

Thanks again!


I think the asymptote means the bit where it goes flat (the max and min); maybe that's helpful for speeding up learning because there are diminishing returns there. Probably that's why they like using ReLU shapes these days (for you & I, that means a clipped ramp) rather than tanh: once a neuron is in the asymptote, there's no further tuning required -- it has tuned itself out of relevance. But we're not interested in speeding up learning, almost the opposite -- creativity isn't an optimization problem -- it's more interesting to spend more time on the journey than the destination (e.g. in most time-based work the climax is quite short compared to the buildup). And for audio is makes more sense to focus energy on the bendiest parts of the curve :-)

...and, uh, and I guess I may have been reading too much Manuel Delanda again...

Oopsy Daisy — An Introduction, Part 2