Issue with OWL patch

OWL
#1

This post is mainly for Martin, but maybe if others have come across the issue they can also chime in here.

This patch seems to work fine in gen~ and then I have significant issues with it on the OWL itself.
Am I doing something wrong?

Basically the symptom is that I get a ton of glitches, which I take to be a processing issue with vector sizes.
Let me know if I need to be more specific - you can hear glitches similar to what I experience by running the patch in the OWL runtime via the browser.

#2

When I compile the patch offline it runs in 17% of CPU, so there won’t be any audio drop outs because of that.
I can hear some glitches which go away when I select Remote Control in OwlControl. This usually means that the parameters need smoothing to avoid noise from the ADCs being picked up.
I can still hear some glitching with Remote on, but then I don’t know what the patch is meant to sound like. If you upload the .gendsp file (Edit Patch/Upload File) then we can have a little look for you.

#3

I checked out your patch and to me it seems, that if you had a [slide 16 16] (or bigger values) behind the constant value change of your glitch, you could probably avoid the clicks completely.

#4

OK, thanks guys!
Martin, I uploaded the file for you to peruse. It seems like you’re both in agreement that a [slide] will help to alleviate those issues. I guess I’m still curious why the glitches don’t occur in the Max/MSP domain, but maybe it’s because the processing can happen quicker. I’ll try out the slide trick for sure.

Let me know if you have any more thoughts!
best,
pepper

#5

I should also mention that I’ve seen some other example code whereby the [mix] object was used instead of [+], but not sure that this would matter. Maybe it’s an idiosyncrasy with [history] that I need to take account for?

#6

Just tried out [slide 16 16] - doesn’t resolve the issue actually. In fact, what I’m hearing is that the glitches are more pronounced in gen~ itself, which is what I was trying to avoid. I’d like to do this without any glissando if possible.

#7

Just checking in on this. Thoughts?

#8

Might help to wrap an envelope around this then.
Make a 2ms fade out upon trigger, then fade back in quickly. I’d take a closer look at this sometime later, but can’t right now. However, to me it seems again (i had proposed that before), that we should open up a library for gen code snippets somewhere here, so we all won’t run into the ever same problems. The maxmsp gen forums must have thousands of threads about click in glitchy loopers!

#9

Erm, addendum. Looked at your gendsp quickly, yes, an envelope would be good. Check out the gen~.7_segment_envelope from the Max gen examples. That’s a very bloated version, but you may minimize it down to your needs.

#10

Also worth trying is quantising / stepping the [param] inputs - ie,

[param A]
|
[* 16]
|
[int]
|
[/ 16]

this will take out any jitter in the ADCs.

gen code snippets would be great!

A

1 Like