@ddw_music 10 (all the way right) and 1 (all the way left).

@kyro presented it as input => asin => ×amount => sin~ and showed it inside a larger patch:

You could also adapt my [expr~] version
trig wrap wavefolder kyro version.pd

@ddw_music Yeah, I should know better. That said, you can often click through to the sites that Google scraped and there it is!

But wait! I just checked the harmonics of a full wave rectified {cos~] and all the even FFT terms have positive magnitude, so this post appears to be correct. And now I just reran my first test and set my "top only" slider to exactly 2 and am getting the fundamental + all even harmonics. Why am I getting so tripped up by this?!!!

@oid said:

Even are not emphasized in single ended, even are canceled in balanced.

This is definitely closer to what my experiment implies, thanks.

Edit: I think it's things like this that misled me in the first place--what I now believe to be false statements are highlighted in yellow:

Look at this experiment:
symmetric vs asymmetric clipping.pd

The osc~ frequency is set so that it perfectly fits a 64 sample block, which make the FFT’s terms match the harmonics of the input.

When I increase the top and bottom clipping amount, the wave shape approaches a square wave and the harmonic content matches theory—all odd numbered harmonics, meaning harmonics that are odd multiples of the fundamental. Now I’ve read that even harmonics are emphasized in asymmetric signals, harmonics that are supposedly warmer and richer and are of the kind produced by single-ended tube stages, all of which have asymmetric current gain curves. That’s what my “top only” slider is crudely simulating. But the FFT contains both even and odd harmonics and there doesn’t seem to be any bias towards even harmonics, unless their mere presence is the magic sauce. What am I misunderstanding?

Edit: I was curious whether my heavy-handed asymmetric clipping was at fault, but this gentler version has similar (if not worse) characteristics.
symmetric vs asymmetric clipping 2.pd

@kyro Oh cool, I missed the fact that you could take the arcsine first, but of course now it seems completely obvious

TBH, wavefolding interests me more for the math and programming than the sound. My first approach was to make a reflector and to put several in series:
reflector wavefolder.pd

I’ve seen this kind of approach from others (e.g. using [expr~]) but it’s unsatisfying because you have to add more reflectors when you want more folds, so I came up with this next version after what felt like an eternity of head-scratching:
wrapping reflector wavefolder.pd

Another solution is to exploit how sine wraps around:
trig wrap wavefolder.pd

With all three versions, the sharp reversals make things very bright and can cause aliasing, which you may not be into, so I wanted to look for an alternative. Returning to how sines and cosines wrap around, I just arranged to overdrive [cos~] with my input signal:
cosine overdrive wavefolder.pd

This is the version I’ve used on the few occasions I’ve thought wavefolding might sound good. The only unsatisfying thing is that it’s never possible to pass the input signal undistorted, even with folding completely off. So I thought maybe I could make a function that’s like [cos~] but linear near the x-axis. The idea comes from hi-fi tube amp design, where the designers try to scale and bias the input signal so that the tube has as linear a current response as possible. Here’s one way:
transferFunction table wavefolding.pd

Note that you can change the non-linear part of the transferFunction table to anything you want. I made both sine and circular reversals; they sound slightly different to me. If you filled the table with a triangle wave then you’d get similar sharp reversals as in the first 2 implementations. I think that even with sine and circular reversals there are more upper partials than with the [cos~] version, so maybe another solution is just to crossfade between the [cos~] version and the clean input when you want undistorted signal.

Know of other ways? Other things to consider? Have a recording that will make me love the sound of wavefolding? Please share!

Hmm, there's something wrong with the [fexpr~] in my first post because if I trigger it on every sample (i.e. send [sig~ 1] to the [pd srNoise]), the result sounds and looks like it has a short period.
01-260606_0606.wav
Oddly, if I modify it to use the 13th and 14th taps, it sounds more like what I would expect from using the 14th and 15th taps. What am I misunderstanding/doing wrong?

Edit: oh wow, check this out. When I rewrite this patch to record the value of the feedback and shift register at each step, I see that the fb is getting shifted into the register one sample late, shown here on line 14 of each array's List View.

srNoiseFexpr~.pd
But when I step through the patch manually and snapshot~ those same values, the fb value is shifted into the register exactly when I expect, the equivalent of line 13. What the....?

Edit 2: Oh interesting: even though $y2's output expression is evaluated before $y1's, the value of $y2[-1] is not updated until all the expressions are evaluated. Which means that Edit 2 of my first post was right but for the wrong reason. Or I could still be completely wrong.

Last edit I promise because I'm just digging myself deeper and deeper into a false statement hole: my [fexpr~] can be fixed by substituting the 2nd expression into the first, i.e.

fexpr~ if($x1 == 1, ($y1 >> 1) | (((($y1 >> 1) & 1) ^ ($y1 & 1)) << 14), $y1);
(($y1 >> 1) & 1) ^ ($y1 & 1);
(($y1 & 1) * 2) - 1;

You can then delete the 2nd expression because it's only used for debugging. Unless someone corrects me, I still believe that output variable values like $y2 are not updated until all expressions are evaluated. I'm really not sure if it makes sense to talk about the order of expression evaluation, except for when values are referenced. So now I'll stop obsessing and will eagerly wait to be properly skooled.

Or this
control rate version.pd

@ice-ice I have to correct a false statement I made.
@jameslo said:

Edit 2: Hmm, there might be something wrong with the expression for the first outlet of fexpr~. See how it references the last value of the 2nd outlet? I don't think that value is calculated yet, and so it's using 1 sample old data. Maybe I should've xor'd the 2 bits that are 1 bit to the left?

Nope. When [fexpr~] has multiple expressions, they're evaluated bottom to top, i.e. the outlets are evaluated right to left. Therefore, $y2 is calculated before it is potentially used to calculate $y1.

@Ice-Ice Ha! I went down this same rabbit hole but I was thinking about the TR-909
https://electricdruid.net/tr-909-noise-generator/
and I didn't use fexpr~ or expr~. The algorithm definitely requires feedback.
TR909 LFSR.zip
It might not be the most efficient way, but I like how the patch looks like the circuit.

Edit: Thanks for the fun problem. I tried to make the example in the last link you posted using [fexpr~], see what you think.
srNoiseFexpr~.pd (use [metro~] from the zipfile I uploaded earlier)

Edit 2: Hmm, there might be something wrong with the expression for the first outlet of fexpr~. See how it references the last value of the 2nd outlet? I don't think that value is calculated yet, and so it's using 1 sample old data. Maybe I should've xor'd the 2 bits that are 1 bit to the left?

@xaverius Because Pd evaluates the control graph depth first, and you happened to connect the left inlet of [_pan] to the right spigot before you connected it to the left spigot. That means Pd will go as deep as it can down the right side (including the feedback on the outside of the abstraction) before it evaluates the left side. That depth-first plunge stops at [delay 1] because the whole point of [delay 1] is to schedule the evaluation of the rest of the graph for 1 ms later. With this understanding, print out what you're sending to the right inlet of [_pan] (both with the delay and without) and I think you'll see what's happening.

Personally, I wouldn't do this with feedback, just with a toggle and select, e.g.

@jorbecke I am not qualified to opine on your mental health, but if you are referring to the hurleur links going nowhere, then it might be a Google Chrome thing. Is that what you're using? If so, try another browser. Otherwise I'd have more modest expectations of a 13 year old thread

@y0g1 My friend who uses Max/MSP just explained to me that phasor~ resets when the right input signal changes to a non-zero value, which means that in my fexpr~ version the test should be "$x != 0 && $x != $x[-1]"

Edit: argh, I even misunderstood my friend. @lacuna is correct below--it's when the signal changes to a non-zero value from zero

@y0g1 said:

"phasor~"'s phase is reset when receiving a non zero signal.

If this was a test in college I'd be there during office hours arguing that the question was misleading

@y0g1 Assuming the sample frequency is 44.1khz, the phasor frequency is fixed at 1, and you don't need to support any other feature than what you mentioned above, try [fexpr~ if($x != 0, 0, ($y + 1) % 44100)] to replace both the phasor and following multiplication.

@playinmyblues The object named a12 should be an array, not a canvas. Replace it and things should start working.

@y0g1 said:

How would you adapt metronome timer for getting the difference between 4 consecutive "onsets", then reset the sample counter to be ready for the next 4 onsets ?

Ugh, in audio domain? I dunno but off the top of my head I think it would be nasty/not worth it. Can't you just take a stream of timing intervals in control domain and process them in groups of 4? How you would align each group of 4 isn't obvious to me either, which is what I think @ben.wes was alluding to earlier RE "cooldown period". Edit: maybe [fexpr~] could help.

@y0g1 I'm unable to test, but your patch looks like [fluid.ampfeature~] and [fexpr~] is supposed to be outputting 1 when the signal is above some threshold and 0 otherwise, is that correct? Is it working as you expect?

If so, the only thing you need from my patch is the part that extracts the leading edge as a pulse, inverts it, and then counts the samples between pulses, but if the signal out of [fexpr~] isn't clean (i.e. outputs one and only one contiguous block of 1s for every drum note) then my counter will output junk. That's why I was asking about [lop~] and threshold in my patch, which is what I assumed you were using for signal conditioning, e.g. for novelty metronome sounds I had to adjust them to get clean square pulses.

@y0g1 What value are you using for the threshold? What frequency are you using for [lop~]? Can you please post a recording of several snare hits?