OOPSY DAISY PATCH SM sampler playback issue
HI all,
I am attempting create a sampler with the Daisy patches of module, using Oopsyand Gen/Max MSP.
I’ve edited a patcher orignally made by Graham Wakefield in Gen~, so that it works as a sound on sound looper. I put it together in gen and it sounds great, no issues.
I’m attempting to make it into a eurorack module, and after getting the patch submodule on the breadboard, I’m having an issue where once I move knobs/ controls related to the phasor reading from the buffer, the sample play back becomes noisy and distored in a way it is not when in the gen patch- I know sometimes analog hardware noise can cause this, so I put the oopsy.ctl.smooth3 object infront of all the parameters and still get the same result.
Could someone with the patch/patch submodule assist in perhaps testing my max patcher on their unite to see if the issue persists? Any help as to why they would fundamentall;y work different in the atch vs embedded hardware would help. Attached is a link to the max patcher ready to be flashed to daisy patch. Thanks!
I doubt that this is the cause, but you have a typo in your Param cv2 object: "@min1" should be "@min 1".
In general, if you are writing a live audio signal into a buffer/data, you should be incrementing the pointer by 1 sample at a time. Anything other than that can lead to corrupted data, as you either leave gaps or overwrite too many samples. In your patch you have a [phasor 0.1] driving the two [poke] objects. I know the [data] is defined as 10 seconds so in theory [phasor 0.1] should produce increments of one sample at a time, but in practice there's a chance that you might get some floating point error in there. The Daisy runs with 32-bit floats that are more susceptible to this, compared to the 64-bit floats in Max. I'm not sure if that's the issue but it could be. You could fix this by replacing the [phasor] and [poke @index phase]s with a [counter dim(mydata)] driving [poke] (without @index phase).
Oh another thing you might want to watch out for: for feedback (sound on sound) you might want to insert [dcblock] ops to make sure your signal isn't running out of headroom due to any DC accumulation. You can put them right after the [wave], or right before the [poke]s.
You have clippers at the end, which can distort nastily. Try replacing with [tanh] for a softer clip? It will make the output a bit quieter initially, but if any signals are too hot they will distort in a much more pleasant way than [clip].
The calculation of [s clock] is a little odd. You have an accum that then goes into a fract, which will give you something like phasor from 0 to 1. But then this goes through an oopsy.ctrl.smooth3, which will turn the ramp into a smoothed ramp. That means at the end of each ramp loop, instead of jumping from 1 to 0 you'll get a smoothed curve from 1 to 0, which will sound like a fast rewind. I'm not sure that's what you want. I'm also not sure what the sample & hold is doing, but that's also going to be curved in a similar way.
Generally, you want to apply the smoothing to the param inputs directly and then use the smoothed values, i.e. don't use things like [* cv2], but route the [param cv2] to [oopsy.ctrl.smooth3] and then use that to feed into a [* ].
And for the ramp itself, to try to maintain a continuous ramp, you might want to place the accum+fract near the end (or just use a phasor). Again, things that work in Max (where math is 64-bit and signals have no noise) might not work on Daisy (where math is 32-bit and inputs always have noise).
Other tips:
The gate1 circuit to turn writing off should have the else-case as -1, so that it doesn't keep rewriting the 0th index of the data. Just hook up a [-1] object to the 3rd inlet of the [?].
Btw you can instead say [data samplerate*10 2] which will mean it still works even if you change the samplerate.
Hi Graham
Thanks so much for the time to look through my patch and give me those notes, that was extremely helpful and I think you were able to get to the root of the problem! Seems to be related to the fact that I couldn't get the Oopsy control objects in between those [/cv2] [*cv2] without separating the math operators from the param like you mentioned ---I made the other changes you mentioned as well and it works properly on the daisy now :) the only thing is that the tape flutter sounds from moving the knobs with oopsy.ctrl.smooth2 or oopsy.ctrl.smooth3 in front of the params are still pretty intense, and without those objects I suffer from the same noise issue I originally had. Any other suggestions for a less intense effect while still mitigating noise? Thanks again! Here is the patch cleaned up and labeled so you can see the changes made:
Glad that helped!
Yeah it's tricky -- modulating delay time is one of the things that reveals microfluctuations the most. If you think about it, modulating a delay is like doing a pitch shift, and our ears are incredibly sensitive to pitch changes. The shift is based on the rate-of-change of the control parameter, so even a very tiny bit of deviation can cause an audible result. On top of that, your parameter is modulating a multiplier against the entire range of the delay line -- 10 seconds on one knob -- which is a huge range!
You can look into a few different things to keep this under more control. You could consider having fine & coarse tuning options, with different filtering on each. You could consider quantizing the coarse tuning. You could look into different kinds of smoothing filters, such as a cascaded moving average, that might result in steadier output.