issue with OWL patch

Home Forums OWL issue with OWL patch

This topic contains 9 replies, has 4 voices, and was last updated by  manwithfeathers 5 months, 3 weeks ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #2875

    pepper
    Participant

    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.

    • This topic was modified 6 months, 1 week ago by  pepper.
    #2878

    Martin Klang
    Keymaster

    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.

    #2880

    jayrope
    Participant

    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.

    #2881

    pepper
    Participant

    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

    #2882

    pepper
    Participant

    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?

    #2883

    pepper
    Participant

    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.

    #2917

    pepper
    Participant

    Just checking in on this. Thoughts?

    #2918

    jayrope
    Participant

    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!

    #2919

    jayrope
    Participant

    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.

    #2953

    manwithfeathers
    Participant

    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

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.


Latest News

Links

Follow us on Twitter