Gen – sample rate problem

Home Forums OWL Gen – sample rate problem

This topic contains 18 replies, has 4 voices, and was last updated by  jayrope 7 months ago.

Viewing 15 posts - 1 through 15 (of 18 total)
  • Author
    Posts
  • #2812

    jayrope
    Participant

    I made a pitch delay patch in gen (bit like the factory pitch shifter but including feedback).

    It runs fine in maxmsp gen as well as “ok” compiled in browser (pitch slightly off there), but as soon as it arrives on my OWL pedal transposing really sounds like running on samplerate 44.1 KHz instead of 48KHz.
    I checked against all kinds of possible other errors, in standalone mode as well as connected to USB/OwlControl

    Can someone else check if that error persists on another OWL?

    My pedal is v12.

    Try the browser patch with transpose turned all the was up, result in an octave, and about center position results in 0 transpose.

    The same on my OWL is off, the center is missing (either too high or too low).
    Both extremes are off as well, -12/far left is a little too low, +12/far right is much too low, though comparing to a 44.1/48 mismatch it isn’t quite there, only similar.

    To me it looks like a compiler error, as the browser version runs fine.

    Here’s the patch.

    Thank you and aswell to your suggestions.

    P.S.:Gen patch
    Gen patch

    #2815

    jayrope
    Participant

    Goodness. I think i found the error… was so out of maxmsp, that i didn’t realize one has to deliberately denote processing floats by putting dots behind values. Will try that and update here afterwards.

    #2819

    jayrope
    Participant

    To continue this report: I found that i can fix at least the patch preview by stepping up the pitch in the patch by 0.5 semitones. This messes up my patch in maxmsp/gen, but leads to a correct audio preview on the website.

    #2820

    jayrope
    Participant

    Actually i had to step up 0.69 semitones to get exact, and then chose 0.7, as the resulting fifths and octaves sound nicer, when a little wider than tempered.

    The patch is here.

    The weirdness stays unresolved, i just used my ears and worked around.

    In above image you see under the param B receiver this

    [* 24]
    |
    [int]
    |
    [-12]

    THIS WORKS AS EXPECTED ONLY IN MAX BUT NOT ON THIS SITE OR WITHIN A COMPILED PATCH ON THE OWL PEDAL.

    To make it work here and on the pedal i had to change this to

    [* 25.]
    |
    [int]
    |
    [-12.]
    |
    [+ 0.7]

    I really don’t get it, but sometimes a half working programming environment is the key to something special.

    Salute.

    #2824

    jeremybernstein
    Participant

    Hi!

    What happens if you use gen’s ‘samplerate’ operator instead of hardcoding 48000 throughout your patcher? Does it fix the problem?

    Another thing to check:
    – if you replace ‘exp’ with ‘fastexp’ in Max, does the problem occur there as well?
    – ‘cos’ with ‘fastcos’?
    – ‘pow’ with ‘fastpow’?

    Thanks

    #2826

    jayrope
    Participant

    Hi Jeremy, no it doesn’t. I actually used the samplerate object first, then switched to hardcoding and finally went back to using the samplerate object.
    The result is the same.
    It actually doesn’t resemble a typical sample rate problem, but rather a value shift (downwards), which only occurs upon compiling the patch here.

    Therefore I think it is a compiler issue.

    #2827

    jeremybernstein
    Participant

    What about this stuff:
    – if you replace ‘exp’ with ‘fastexp’ in Max, does the problem occur there as well?
    – ‘cos’ with ‘fastcos’?
    – ‘pow’ with ‘fastpow’?

    Thanks

    #2829

    jayrope
    Participant

    Oops interesting. The patch works as it is already (if crude), so i’ll probably get into testing that, when implementing the missing reverse mode of the original CT5 unit. Could take some days. Thanx for the suggestion!

    #2832

    Martin Klang
    Keymaster

    I’ve had a look through some code and the only references I’ve found to hard-coded sample rates is as default parameters to mstosamps and sampstoms operators, but these aren’t even used in your patch.

    The correct sample rate seems to be passed down, so I don’t know what might be causing this. Is it possible to isolate where the error happens?

    #2833

    cherifhashizume
    Participant

    How about trying “scale” instead of processing input from param B with “* 24” “int” and “- 12”? Also on the hardware, the value of input never actually reaches 0 or 1 so if you are just looking to get integer values, you can use “trunc” so everything nicely falls into the closest integer.

    #2834

    jayrope
    Participant

    Easy calculation results, feeding a range of -12 to +12 times 0.05776 into exp and fast exp

    for -12, 0 and +12
    exp: 0.5, 1 and 2
    fastexp: 0.486, 0.971 and 1.943

    Feeding the same range +0.69 into [* 0.05776], then to fastexp results in values
    0.5, 1 and 2 for -12, 0 and +12,
    but it is still different.

    Testing further inputing -6, -3, +3 and +6 results
    exp: 0.707, 0.841, 1.189 and 1.414 as expected
    fastexp: 0.750, 0.875, 1.250 and 1.500

    Aha! fastexp uses a kind of LINEAR SCALE???? That wouldn’t make sense…

    Asking: Is the compiler using the fastexp code to compile exp aswell? And besides exponential versus linear scale, why is there an offset? Oops, it’s already there in MaxMSP/Gen!

    I put up a thread on the gen forum. However, can the compiler be fixed?

    Thank you!

    • This reply was modified 7 months, 1 week ago by  jayrope.
    #2840

    jayrope
    Participant

    I wish i could change the title of this thread. However, i started a discussion on exp vs. fastexp over at the Gen forum.

    In that regard it gets more obvious, that we have an issue with the gen compiler here. Can that be fixed soon?

    #2841

    jayrope
    Participant

    Here’s a workaround by gen forum user STKR approximating exp more accurately than fastexp.

    expA(x0)	// approx exp(x) (more accurate than 'fastexp()')
    {
    	x = 0.999996 + (0.031261316 + (0.00048274797 + 0.000006 * x0) * x0) * x0;
    	x *= x; x *= x; x *= x; x *= x; x *= x;
    	return x;
    }
    
    out	= expA(in);

    Do we have a code repository, where i can make this snipped directly available as gen code to other users of gen for OWL related purposes?

    #2843

    Martin Klang
    Keymaster

    Is there a way to call this code from Gen if it is included in the compilation?

    #2846

    jayrope
    Participant

    Yes, actually i copypasted this code straight from a codebox within gen. It works, although in direct comparison to exp there is very slight differences. I set up a test patch tuning a phasor to semitones, and when one overlays the two, then there is phasing/very slight out of tunings. Musically it sounds like it could be bareable, maybe even interesting, a microtonal effect.

    Oh and, just for correctness the last line should read:

    out1 = expA(in1);

Viewing 15 posts - 1 through 15 (of 18 total)

You must be logged in to reply to this topic.


Latest News

Links

Follow us on Twitter