Gregory Taylor

The new Daisypatch module from the folks at Electrosmith is here. It joins the Rebel Technologies OWL module - now reborn as the Befaco Lich, and provides another way to embed the precise flexibility of Max/MSP's gen~ into modular Eurorack hardware. 

I've watched the project carefully since its Kickstarter days. Well, the wait is over — while the hardware and the Oopsy software environments are still a work in progress, I was keen to check it out. Thanks to the folks at  Electrosmith (who kindly sent me some hardware to work with) and my friend and colleague Graham Wakefield (who put together the Oopsy package to streamline the mapping of gen~ to the Daisy hardware), I thought I'd walk you through setting up your working environment and showing you how Oopsy works. 

The first part of this tutorial will include some information about how to get the software tools you’ll need to get started in place on your machine. At the end of this first part of the tutorial, you'll have everything installed and be able to upload the example files provided as part of the Oopsy software release.

In part 2, we're going to be taking a run at creating some different kinds of gen~ patches to download and run in the Daisypatch module.

Please note that even though I’m trying to keep this simple in the hopes of attracting and interesting those of you who might want to get started running gen~ patches in your Eurorack, I am making a few assumptions about what kind of system you’re working on. The reason for that is a practical one: I’m describing my current system — the one I loaded the Oopsy software on to create these patches. I hope they’re sufficiently basic that you can easily imagine how your own system may vary, and I hope that those of you on slightly different systems who do find changes or helpful tips will chime in in the replies.

It’s also the case that the Daisy software environment is a work in progress as of the time I am writing. There will definitely be bugs fixed as we go along. There will also be tweaks/new features added and in the works (you can find a list of those projects described here. Finally, it may well be that some of the basic installation and operation details for the Daisy software and the gen~ support for it may change over time, as well. It’s my plan to update and expand the contents of this tutorial when that happens so that the content remains as up-to-date as I can make it.

So let’s get stuff set up. First, I need to mention what the machine I’m starting the install on looks like: 

I’m using a 2020 MacBook Pro running Catalina (10.15.7) with a beta version of Max (8.2.0) installed. I’ve checked around, and am informed that running the beta version of Max will exhibit no differences from running the most up-to-date version of Max currently available.

I’ve got a copy of Xcode installed on this machine (it’s version 12.4)

I use the SourceTree program to deal with GitHub repositories and various codebases.

I hope that none that is too exotic; I honestly don’t think so.

My Daisy installation voyage started with the Installing the Toolchain on Mac page on the Daisy Wiki. According to the instructions, the first step is to install the command line utility software (gcc-arm-embedded dfu-util) used to flash the programs we’ll want to send to the Daisypatch module. 

To do that, we use the open-source Homebrew package manager. The installation is remarkably straight-forward — navigate to the Homebrew package manager website and click on the clipboard icon to the right of the command line you’d be laboriously typing in to copy it to your clipboard. 

Open a terminal window using the Macintosh Terminal program, paste the contents of the clipboard into the command line and hit return (you’ll be asked to enter your su password).

Here’s a shortened version of what you’ll see. The installer helpfully tells you what it’s going to do, what it’s downloading to install, and it’ll helpfully prompt you to make sure it’s what you want to do. When you’re all done, The installer exits and points you to more helpful information.

% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Password: <enter your password>
==> This script will install:
/usr/local/bin/brew
/usr/local/share/doc/homebrew
/usr/local/share/man/man1/brew.1
/usr/local/share/zsh/site-functions/_brew
/usr/local/etc/bash_completion.d/brew/usr/local/Homebrew
==> The following existing directories will be made writable by user only:
.
.
.
==> Installation successful!
==> Homebrew has enabled anonymous aggregate formulae and cask analytics.
Read the analytics documentation (and how to opt-out) here:
https://docs.brew.sh/Analytics
No analytics data has been sent yet (or will be during this `install` run).
==> Homebrew is run entirely by unpaid volunteers. Please consider donating:
 https://github.com/Homebrew/brew#donations
==> Next steps:
- Run `brew help` to get started
- Further documentation: 
https://docs.brew.sh
% 

If you’re following along on one of the more security conscious Macs (i.e. if you’re running Catalina or Big Sur), you’re going to need to add an exception for security checks for gcc-arm-embedded stuff you’ve installed, just as you often have to do with third-party Max externals you’ve downloaded from someone else (If you’re following along on a Mojave machine, you don’t need to do this at all). Type these two lines into your Terminal and hit return

% find /usr/local/Caskroom/gcc-arm-embedded -type f -perm +111 -print | xargs spctl --add --label
% find /usr/local/Caskroom/gcc-arm-embedded | xargs xattr -d com.apple.quarantine

The second line listed in the toolchain page is intended to recursively remove the quarantine attribute in a directory. However, when I ran it, I got a huge collection of error messages of the basic form

% find /usr/local/Caskroom/gcc-arm-embedded | xargs xattr -d com.apple.quarantine
xattr: /usr/local/Caskroom/gcc-arm-embedded: No such xattr: com.apple.quarantine
xattr: /usr/local/Caskroom/gcc-arm-embedded/.metadata: No such xattr: com.apple.quarantine
xattr: /usr/local/Caskroom/gcc-arm-embedded/.metadata/config.json: No such xattr: com.apple.quarantine
xattr: /usr/local/Caskroom/gcc-arm-embedded/.metadata/10-2020-q4-major: No such xattr: com.apple.quarantine
.
.
.
xattr: /usr/local/Caskroom/gcc-arm-embedded/10-2020-q4-major/gcc-arm-none-eabi-10-2020-q4-major/share/gcc-arm-none-eabi/samples/src/fpin/fpin.c: No such xattr: com.apple.quarantine
xattr: /usr/local/Caskroom/gcc-arm-embedded/10-2020-q4-major/gcc-arm-none-eabi-10-2020-qmajor/share/gcc-arm-none-eabi/samples/src/makefile.conf: No such xattr: com.apple.quarantine
%

(and I do mean a huge collection of error messages).

As nearly as I can tell, there’s nothing that requires running this command on the contents of that file at all. However, I also realize that perhaps Big Sur operates with a slightly different set of rules and requirements, so perhaps this is necessarily there but not on Catalina installations. I think that that second instruction in the toolchain document is either not needed on Catalina installations, or its inclusion is generally not required.

So I’ve successfully installed the software to handle flashing the code to the Daisy Seed module, and it’s time to move on to creating a repository of Graham Wakefield’s Oopsy development software and compiling the Daisy library locally. I know that there are a lot of folks out there who love running GitHub from the command line, but I am personally more partial to the SourceTree application for this kind of thing.

To set up your local repository using SourceTree, you’ll need three things:

The URL of the github repository you want to clone

A destination on your local machine where you want to stash the files — I decided to put my stuff in with my installed Max Packages folder. Your mileage may vary.

A simple and short name that SourceTree will use to label your repository (How about… well… Oopsy?)

So I launched SourceTree and set up my local repository by click on the “+ New Repository” menu and choosing Clone from URL to bring up the “Clone a repository” dialog box.

After that, I just input my source URL, the pathname for my install, and oopsy for the repository name and let SourceTree do the rest. 

SourceTree went off and grabbed the entire repository and stashed it on my system.

After that, there was just one more step for setup: Compiling the Daisy Library itself on my machine.

To do that, I fired up my Terminal application one more time, opening the directory my Oopsy files lived

% cd /Users/gtaylor/Documents/Max\ 8/Packages/oopsy

(Remember that pesky space in the “Max 8” directory? You’ll need to use a backslash to preface the blank space when you type it in. You’re welcome.)

After that, the command ./install.sh will run the shell command that builds everything for you

% ./install.sh
/Users/gtaylor/Documents/Max 8/Packages/oopsy
get submodules
rebuilding everything. . . 
only errors, and warnings will output. . . 
-------------------
rebuilding libdaisy
In function 'gen_numname',
   inlined from 'dir_register' at Middlewares/Third_Party/FatFs/src/ff.c:2339::
Middlewares/Third_Party/FatFs/src/ff.c:1825:8: warning: writing 1 byte into a region of size 0 [-Wstringop
overflow=]
1825 |  ns[i] = '~';
     |  ~~~~~~^~~~~
Middlewares/Third_Party/FatFs/src/ff.c: In function 'dir_register':
Middlewares/Third_Party/FatFs/src/ff.c:1796:7: note: at offset -1 to object 'ns' with size 8 declared herec
1796 |  BYTE ns[8], c;
     |       ^~
arm-none-eabi-ar: creating build/libdaisy.a
done building libdaisy
% 
If you’re like me, you used the ls -la command to check on the contents of the top level of the Oopsy file system. If you do, you’ll probably notice that it looks as though nothing’s changed as a result of doing the install. Don’t worry - the results of your compiling labor have been safely stashed in the source directory. You can cd to that directory to make sure that everything worked (I use the ls -lt command because it lists the most recently changed files first).

% cd source
% ls -lt
total 208
drwxr-xr-x  31 gtaylor  staff    992 Feb 13 23:20 libdaisy
drwxr-xr-x   5 gtaylor  staff    160 Feb 11 12:40 build_frippery_patch
drwxr-xr-x   5 gtaylor  staff    160 Feb 11 11:15 build_LFO_1_patch
drwxr-xr-x   5 gtaylor  staff    160 Feb 11 08:21 build_LFO_4_frippery_patch
drwxr-xr-x   5 gtaylor  staff    160 Feb 11 08:07 build_LFO_4_patch
drwxr-xr-x   5 gtaylor  staff    160 Feb 11 08:05 build_simple_patch
drwxr-xr-x   5 gtaylor  staff    160 Feb 10 22:33 build_LFO_1_LFO_4_patch
drwxr-xr-x   5 gtaylor  staff    160 Feb 10 11:59 build_modfm_patch
drwxr-xr-x   5 gtaylor  staff    160 Feb 10 10:14 build_midside_patch
-rwxr-xr-x   1 gtaylor  staff    355 Feb  9 17:32 test.sh
-rw-r--r--   1 gtaylor  staff   2493 Feb  9 17:32 readme.md
-rwxr-xr-x   1 gtaylor  staff  24775 Feb  9 17:32 oopsy.js
-rw-r--r--   1 gtaylor  staff  27326 Feb  9 17:32 genlib_daisy.h
-rw-r--r--   1 gtaylor  staff   9111 Feb  9 17:32 genlib_daisy.cpp
drwxr-xr-x   5 gtaylor  staff    160 Feb  9 17:32 gen_dsp
-rw-r--r--   1 gtaylor  staff   1938 Feb  9 17:32 daisy.versio.json
-rw-r--r--   1 gtaylor  staff   1431 Feb  9 17:32 daisy.pod.json
-rw-r--r--   1 gtaylor  staff   2679 Feb  9 17:32 daisy.petal.json
-rw-r--r--   1 gtaylor  staff   2284 Feb  9 17:32 daisy.patch.json
-rw-r--r--   1 gtaylor  staff   4506 Feb  9 17:32 daisy.field.json
-rw-r--r--   1 gtaylor  staff    907 Feb  9 17:32 changelog.md
% 

That’s it. In fact, that’s really all of the hard stuff. Now - onward to fun!

Now that I had my software set up and configured, I thought I’d start by trying something simple — trying to compile and load the simple.maxpat file from the examples folder in my repository.

To do that, I needed to grab the handy cable that came with the Daisypatch and hook it up — one end into the little connector on the bottom of the Daisy Seed, and the other to my USB connection on the laptop (through a dongle, because Apple).

Opening the simple.maxpat patch showed me the appealingly minimal beginnings of my Daisy life… a single gen~ object, and a bpatcher with some controls and a display.

I figured I’d start by double-clicking the gen~ object to see what was inside:gen~ object to see what was inside:

Nothing too threatening here: some noisemaking stuff (noise and cycle operators), two pairs of param operators whose names seemed suspiciously as though they might relate to the controls and inputs/outputs of my Daisypatch, and a little patching to modify amplitude.

A little investigation into the controls on the bpatcher that handles the compilation and downloading looked equally straight-ahead. 

To my surprise, the display in the bpatcher starting outputting messages when I opened the patch:

So it looks like the Oopsy stuff compiles whatever’s in the gen~ object automatically, although nothing had really changed about the behavior of my Daisypatch. So - despite what I was seeing in the little window - the flashing to the Daisy Seed wasn’t working.

Okay. What else is there besides the big button and the display? There are a couple of umenu objects that let me set what kind of Daisy device I wanted to flash programs to, and one that lets me set the sample rate for what I’m flashing (Wait - I can run stuff at 96 kHz? Wow. I’ll have to look into that later on….). Finally, there’s a helpful button that lets me toggle between “discreet” and “verbose” modes.

I figured that I could set the bpatcher to verbose mode to see if there was more information about what was working (or not working, in my case). So I set it to verbose and punched the button.

The results were helpful in terms of telling me what was going on. At the bottom, it looked like I had two problems: errors from the dfu-util stuff I’d just installed, and a message that said that the flash failed.

Note: I have since learned that I can ignore the DFU error messages, and so should you.

Since I’m excited about the Daisypatch and want you to have a good experience working with it and creating and flashing your own gen~ patches, dear readers, I am willing to appear as ignorant as I truly am: There was something really simple I hadn’t read far enough ahead to figure out. In order to be able to flash stuff to the Daisy Seed, I needed to put the Daisy into flashable mode first so that the module was ready to expect what I was sending to it.

I should have had a good idea of the problem. It’s described right here in the Oopsy help file. See that bit about “If the device is plugged in via USB and ready to flash….” 

I know. “Duh.” But it wasn’t immediately obvious to me (perhaps this will change at some future point, but it’s how things are at the time of this writing). So I can save you some time here: Take a close look at your Daisy seed. 

See those two little microswitches labeled BOOT and RESET? Good. To set your Daisy up to receive your compiled gen~ patch, hold down the BOOT button and then press the RESET button. Once you release the RESET button, you can let go of the BOOT button (you can tell you did it right if the USER LED on your Daisy Seed stops flashing.

Having pushed those two buttons and set my Daisy to receive stuff flashed to it, I punched the “go” button in the bpatcher again. This time, my verbose output had good news for me.While I still saw the error messages for the DFU utility, that bottom line said done…

...and - more to the point - my Daisypatch looked just a little different. Something happened!

Plugging patch cables into the first two audio outputs and listening to my mixer confirmed that I’d successfully downloaded the simple patch. Woohoo!

Now you should be all set to investigate some of the features of the Oopsy gen~ patching world in more detail. We'll be digging into that in the next part of this tutorial, but you'll find a couple of example patches in the examples folder of your Oopsy repository. Try 'em out, and I'll see you next time!

Learn More: See all the articles in this series 

image1.png

The new Daisypatch module from the folks at Electrosmith provides a great way to embed the precise flexibility of Max/MSP's gen~ into modular Eurorack hardware. In this tutorial, I will walk you through setting up the Daisypatch tool chain and the Oopsy software.

oopsydaisy-patch-an-introduction

Oopsy Daisy — An Introduction, Part 1

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.

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 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!

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."

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.

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 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.  

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:

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). 

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

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.

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 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

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.

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:


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

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)

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

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)

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 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:

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 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. 

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! 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. 

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

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.

Search Results