Gen - sample rate problem

OWL
#1

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
Gen patch716×563 101 KB

#2

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.

#3

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.

#4

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.

#5

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

#6

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.

#7

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

#8

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!

#9

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?

#10

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.

#11

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!

#12

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?

#13

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?

#14

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

#15

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);

#16

We have this github repo: GitHub - pingdynasty/OwlGenPatches
Happy to receive a pull request.

1 Like
#17

Okay, github newbie here. What is a pull request (!) ?
I tried copying code out of this now but cannot paste it back into Max, as it wants the max code compression upon pasting.

#18

Github is a universe unto itself! Once you get the hang of it it can be really useful, but the learning curve is steep. On github first you would fork the repository, then clone your fork, then add your files to the clone, then commit, and push. Then you create the pull request!

Can you make a very basic OWL Gen patch that uses the function? You could put that in the patch library, along with your .gendsp file (and .maxpat too if that is useful?).

PS we’re working on a way of displaying Gen patches visually in the patch library.

1 Like