Is there a way to use Max’s [midiin] connected to [gen~] to test [oopsy~] midi things?
[midiin] to [sig~] to an inside-of-[gen~] to a [midi in 5] doesn’t work automagically.
Is this even possible or do I have to flash up the firmware to my Daisy device to make test?
You should be able to run the midi in a max gen patch just like any max patch that uses midi. You may have to have another block or a few to run the max midi.
If it’s just CC, all that you’re doing is sending 1-127 values to a device. If you want to know if it works in that case, just mapping any parameter will test the control. That probably obvious and I’m guessing you’re after something a bit deeper.
I know the daisy dev branch has updated midi mapping that is highly simplified, especially for CCs. If you format it within oopsys proper midi format, I think it’s safe to assume the midi is functioning itself. Testing that would just be an effort to see if your device is broken or not IMO.
Some of Max’s jit/jitter objects and the one that starts with b… idk they’ve both heavily involved with video, but they have very continent midi tools as well if you want to test your controller with it.
I have mapped like 10 parameters before in a single project and many other variations and I’ve never had an issue mapping cc’s in oopsy once I used the dev branch. It’s just like param midi_cc14 or midi_cc14_ch3
Can you send up an example patch?
I want to send the output of a Max [midiin] into a [gen~] using the Oopsy midi objects so I can prototype the patch without having to compile to a Daisy.
I assumed that only the Oopsy.midi.parse would work.
It does not.
I mean what kind of midi data is it?
Either way, you’re likely going to have to write the gen patch with parameters that work with your incoming test midi and then later replace that with oopsy specific paramters.
But, again, Daisy/oopsy is working with the proper midi data so you can safely assume that any incoming midi that daisy is capable of working with is going to be identical to just placing in whatever thing that gets your patch functioning. Idk about notes, but if you want cc control, just type in exactly what I did above.
Just replace the max only stuff with oopsy equivalent parameters when you’re done. As far as I know, oopsy parameters are written for oopsy anyways. No matter what you do you’re going to either have to do a bunch of work on the Max side making it work into oopsy or a bunch of work on the oopsy side replacing to make the gen patch export right.
If it’s just cc control, placing in any max control 1-127 is equivalent to the control oopsy will put into your patch anyways. Just scale it or whatever you need to do to make it function right.
For more info email the devs or join the slack group. Unless you have a really complicated sequencer or instrument here, it’s much easier to just make the controls in the patch function in whatever way you need to and then just replace that with oopsy stuff.
If it doesn’t work when you did that, then you didn’t type in the proper connections. If that’s what you want to test, then check the example on midi for oopsy and just make sure that lines up.
Thanks, I understand all of that
I was hoping there was a work-through that would present normal Max MIDI data to [gen~] the way that the [oopsy.midi.parse] specifically would operate as it would in a compiled binary.
Oopsy generates code that sits between the gen~ core and the Daisy hardware, including for the helper MIDI inputs and outputs. When developing the patcher in Max, you will have to create these helper mappings yourself by Max patching, as gen~ itself knows nothing about MIDI etc. The Max interface to gen~ only knows about param, in, out etc.
E.g., if you have param midi_cc3 @min 0 @max 10 in your gen~ patcher, then you’ll want to create a ctlin 3 object in the Max patcher to receive MIDI CC 3, route it through a scale 0 127 0 10 to map to the param’s expected range, then through to a midi_cc3 $1 or attrui selected to midi_cc3 and routed to the gen~ object to connect it to the param.
1 Like
I think I understand. Thank you. This is really because I was on an airplane traveling while working on a MIDI syncable AD loop synth thing and couldn’t alpha test it “as is”. I ended up sending in a raw 24ppm bang-triggered 50 ms gate clock thing and futzing far too much in Gen~ to be utilizing the efficiently.
I’ve found for quick testing controls, it’s useful to have a bunch of wav files of dc recordings. I’ve either made these in Bitwig or dc sampled my modular. It’s always annoying to set a clock or gates or envelopes or whatever when you know it’s not even part of your patch.
So I have a bunch of recordings that are super easy to drop in as modulators. And cause they’re just audio, you always know you didn’t miss a link or set a tempo in ms when is supposed to be samples etc.
Also can let you know how a control will perform more closely to hardware modulations than the perfect max environment.
Yeah I got use to that with Assimil8or, since it operates on that level entirely. And it’s the basis for my automatic tempo scaling sidechain OOPSY patch. The only way to get that right is with a digital envelope and still most can’t do the right 50% exponential curve with the ability to click smooth.
I tried and failed (on a technicality I would say, lol) to do the math in max and so did the next logical thing. I sampled XFER’s LFO tool into several audio samples.
Part of what I love about eurorack is how you can brute force sound design cause there’s no routing limits and if an LFO doesn’t work you can do it by hand. And the daisy patch with max just takes that to the next level.