Meet Oopsy: Daisy Object for Max/MSP Gen~

[mikenkeys]

Hey Everyone!

We are proud to share that Max/MSP gen~ integration is here!

Dropping into open beta today, Oopsy will manage the code-generation, compilation, and programming of your Daisy board from within Max/MSP. Create a new gen~ patch from one of the platform-specific templates, or add an oopsy object to an existing patcher using gen~ and drop your patch onto the Daisy.

The interface allows for control over your patch from any of the breakout board’s controls, as well as MIDI, LEDs, CV generation and more. Many of the breakout boards have sophisticated UIs for switching between multiple gen~ patchers within the same project, and for those using the Daisy Patch or Daisy Field you’ll have access to multiple scope modes including the enchanting Lissajous mode.

This is an open beta. Which means we’re looking to you, our amazing users, for feedback, which you can voice on the forum or on slack. For any developers out there, contributions are welcome, and we have a long list of upcoming plans to make this even more user-friendly, flexible, and enjoyable to work with.

The following breakout boards are supported right now, with custom boards and more third-party boards (like the Noise Engineering Versio) coming in the near future!

• Daisy Pod
• Daisy Patch
• Daisy Petal
• Daisy Field

Visit our new wiki page, for installation instructions and get patching today! Detailed usage can be found on the project’s Github README.

Download Oopsy!

[LottiKarotti16]

Amazing!!! Thanks!
early christmas present

will test it out the coming days and weeks!

[koshimazaki]

Awesome news @mikenkeys will be checking this tonight! Exciting times!

[koshimazaki]

Just to say this is working great. No issues in the installation or compiling. Love the fact that compiling and flashing of Daisy actually happens within Max. Super easy with those provided patches.
I had one funny gotcha as thought the firmware upload got stuck on 12% but that was CPU usage of reverb that flashed super fast and fine lol
Great to have visualisation there too.

[Manysounds]

This is amazing. Looking forward to this getting wild!

[asher]

Hi! I don’t own a Daisy (yet), but I have checked out the oopsy max and gen patchers and have a couple of questions before I consider buying one of the platforms

1. The Midi implementation is very impressive - I haven’t seen anyone convert the bytestream into audio rate in gen~ until this. Does this method affect midi output latency in any way? How processor intensive is this routine to run?

2. What is the practical CPU limit of the device? can I feasibly have some sort of effect AND midi effect running at once?

3. Is there a possibility that any of platforms will be able to have more params enabled? EG on the Daisy Patch there is a screen and a scroll wheel but only 4 parameters available - I think it would be beneficial for the user to be able to add knob parameters as necessary in gen~ and then be able to scroll through ‘banks’ of params using the screen.

4. Is the SD slot available for accessing files to read into gen~ buffers?

5. What happens if you try to use mc.gen~ patches?

Thanks heaps!

Asher

[grrrwaaa]

Hey Asher,

Thanks, that’s kind and great to hear!

1. It kind of came out of an earlier experiment that span off from a course I teach; in this case I was demonstrating to a student that you can write an interpreter in almost anything (by writing an interpreter in gen~, which is now the calculator example in Max). I realized this would work for parsing MIDI so I added it to oopsy. It does add a fair amount of overhead but only if you use it – and you can delete any parts you don’t need to make it cheaper.

Also on the roadmap I’d like to add some specific MIDI handlers (see https://github.com/electro-smith/oopsy/issues/15) – e.g. something like a [param midiclock] that oopsy could manage & bind outside of gen~.

2. Yes, you can have both audio & midi in the same patch. I tried some of the bigger gen~ examples to push CPU and it handles pretty well. Gigaverb was about 30-40% IIRC. One thing to watch out for is CPU spiking: the default block size on Daisy is just 48 samples/1ms so any single-block operation that is expensive might cause noise due to underrun. It’s only for and while structures are likely to cause this though – e.g. the overlap-add granulators I tried can cause droputs with very long grains. It’s just the way they were written; I plan on restructuring one to have more even continuous CPU performance for comparision.

3. Yes that’s planned, see https://github.com/electro-smith/oopsy/issues/6.

4. Not yet, but also planned

5. mc.gen~ is not currently supported. I’m not sure exactly how that would work – the same patch running in stereo (or quad on Patch) but all sharing params?

Would love to hear feedback on how this is being used! Also welcome ideas on how to approach features.

Graham

[Manysounds]

Yep! Just wanted to chime in with a little experiment I did using the Patch hardware.
I combined the following into a single gen~ object:
The MIDI I/O example with the mono sine oscillator
An old gen~ Moog Ladder filter (converted into a stereo offset filter)
An OWL gen~ delay patch I altered
And finally, the Reverb from the Oopsy reverb example patch
All together the CPU “meter” that Oopsy includes showed a whopping total of ONLY ~25% CPU usage with all subpatches running together simultaneously in a chain. (OSC and audio in LR->filter->delay->verb)
Just for the hell of it to see what I could do with my limited understanding of gen~
SO, TONS of available CPU cycles to go moving forward.
Someone could easily circumvent the four knob limit using external MIDI CC input or code converting audio in 3-4 into additional CV inputs but reallllly hoping to be able to use the encoder and a screen UI of some kind in the future.
ALSO, I added these subpatches as their own gen~ objects separately at the top level and Oopsy hooks you up with the ability to swap patches on the fly.
I am giddy like a child over here.

[grrrwaaa]

Nice!

Yeah I’m finding that some patchers really don’t eat much CPU at all – expect to do some polyphonic MIDI controlled stuff soon.

The ones that do seem to eat up more CPU are those with long delays (I have a port of the gen~ gigaverb that is ~42%) or with complex looping (for/while loops) that can trigger spikes (the gen~ OLA examples).

The extra audio ins might not be so useful as CV inputs as they are AC coupled like many eurorack audio inputs – like a high-pass filter it will cut out any stable nonzero offset. Faster LFOs will get through but very slow curves or v/oct type stuff is likely to get filtered out at the hardware level. But yes, MIDI input would be a good way to get more controls in. Maybe a befaco midi thing or those 16n fader clones might work well. I’ve been thinking about that too. And an on-screen interface for addressing all params via encoder is a priority for me too.

Graham

[asher]

awesome, will be following closely

could you link to the calculator example?

I didn’t exactly think about it very hard but I was thinking something like mcs.gens and then using something like mc.mixdown to sum the channels to mono/stereo… but that’s outside the gen domain I guess

[grrrwaaa]

For a fixed polyphony you can do what mcs.gen does with subpatchers inside gen~ and addition for the mixdown, which is totally viable for oopsy of course!

Here’s the calculator: https://cycling74.com/forums/-sharing-gen~-absurd-friday-interpeter-calculator-in-gen~

[koshimazaki]

This is heaps of fun. I am testing ~gen /Daisy with LFSR patch a Wiard Noisering emulator found here.
.
It’s working great. I posted the patch on Max forum in the post above, as not sure how to add text files or Max patches here.

One question. How can we access encoder switch? Is it accessible? I think oopsy mapped param switch_enable to gate in.

[Manysounds]

I DO have one request for Oopsy though:
It would be fantastic to have the ability to compile down to ONLY the required code to run a single ~gen instance. As awesome as the UI and extras are I would love to be able to easily grab an Oopsy .cpp code block and staple it into another .cpp project (like a ~gen poly Osc into the shared CloudSeed project Daisy code or something) without all the extra Oopsy bells and whistles. A toggle in the Oopsy object to allow such a thing is possible, I assume. I’m not certain if this would save us enough CPU cycles to warrant doing but mayyyyyyyybe.
Of course I could cannibalize this myself I guess but I’m not any kind of expert. Maybe this will be a winter project of mine…

[koshimazaki]

Cool idea. I think it might be possible in some point.

When it comes to the features I would love to be able to CV the patches like presets on it or sequence them using gates, I think that would be really powerful. I can’t think of any other module that allows that or is capable of that.

[antisvin]

First of all, you won’t be able to put a lot of patches on Daisy as long as it stores them on small flash partition. It’s just 128kb and sometimes it won’t be enough even for a single patch that needs large amount of data as lookup tables.

Patch switching is possible with Owl firmware running on Daisy Patch by using encoder or MIDI. It stores patches on 8MB QSPI flash and each patch can be up to 512kb in size each.

I don’t think that using gates for patch switching on Daisy Patch is particularly interesting - there’s no buttons to do it manually and you’ll loose gate inputs. It’s probably better to use some utility module to convert CV to MIDI and use gate inputs in patches.

[grrrwaaa]

I’m finding that the extra bells and whistles are only using about 1% of CPU time, so I’m not sure it’s really worth the effort for efficiency purposes. Also if you only have one gen~ in the patch, none of the multi-app menu stuff exists in the code. If you don’t use MIDI, the MIDI stuff doesn’t get generated, etc. If you don’t have OLED, none of that stuff goes in the binary, etc. I guess there could be additional flags to make it even leaner but I’m not sure what the benefit would be… I guess a poly template is interesting though – if you have a specific idea of how that might work I’m happy to add a feature request ticket for that.

[grrrwaaa]

“I would love to be able to CV the patches like presets on it” – if you mean presets in the sense of ‘param settings’ it’s an interesting thought, though I’m not sure how that would be interfaced (whether in gen or in hardware) to author them.

If you mean the sense of patches, then definitely likely. Once I got the multi-patch stuff working I was really surprised how fast it is to load, and I realized it could be interesting to trigger loading different patches from gate/cv or midi input. I just wasn’t sure people would want to eat up a gate/cv input for that – as @antisvin also points out. I also thought that MIDI (e.g. program change) would make more sense for that.

Regarding memory use, yes the flash memory is very tight, but I’ve been able to get 8 gen~ patches loaded on the Daisy without running out. It looks like about 56k for the base level with an empty patch, and on average +8k per additional gen~ patcher of a typical complexity. Big data tables like audio buffers etc. should be loaded from SDcard memory (support for which is on the roadmap for oopsy), so that should be independent.

Also a note about runtime memory footprint of multi-apps: each app re-uses the same memory space, so you don’t have all 8 side-by-side, and any large objects like long delays etc. will use the SDRAM memory which has 64mb available IIRC – I’ve actually not had a patch use more than a few mb of that yet.

[koshimazaki]

Yes MIDI program change would be a cool option indeed, Buchla 200e style. I was referring to a variety of patches not necessarily gen/oopsy ones. I guess clever programming could sort it faster/more efficient on the patch level if working with ~gen only.
Also, for changing patches with gates if it were effects I wouldn’t mind sacrificing gate then, so depends on the purpose. It probably would be too slow for triggering drums and loading different synth engine/~gen patch with each gate / trig.

[koshimazaki]

As for presets I meant patches loaded separately.
Tho actual param/presets crossed my mind regardless. Wonder how to go about them in gen actually as there is no preset object. Ideally, I would use CV to switch/morph between them. What
I can think of now is using selector within gen to switch between patches and I am using scale a lot. Controlling multiple gen patches at the same time is an interesting challenge already.

As for the implementation of ~mc.gen would it be possible to use different gen patches as individual voices? So each voice/ instance is a different gen patch? I haven’t used gen much hance the basic questions. Hope you don’t mind me asking.

[Manysounds]

You can nest ~gen patches (without the tilde~) inside of ~gen patches so running side-by-side patches is completely possible, making it 100% possible to have separate voice patches. It demands some re-naming and wiring of ins and outs but I did this on day one of Oopsy release, running the demo midi_io patch alongside the demo Reverb_Tank inside a “top level” ~gen