@jameslo said:

Edit: aw crap, doesn't work for negative numbers. Can it be salvaged with an extra quadrant signal?

You could take the log of the absolute values of each signal instead and fix the sign at the end: output 1 for each [clone] instance if the signal is negative (otherwise 0) and take the sum, mutiply the output of [exp~] by 1 if that sum is pair and by -1 if it's impair. More complaints from the efficiency police expected ... But I love the idea!

@atux The circular thing is a bit tricky .... Maybe you could just give [list store] a list of twice the length (the source list appended to itself)? That's not elegant at all but for the moment I don't have other ideas.

@atux You can use [list store] for that. It takes messages like [get 1 3( to output a sublist of three items starting with the first item of the list. Take a look at the help file to find out how it works in detail.

I found this old thread as I was just about to open a new topic about the numerical error of [hip~] at low frequencies ... Well, to me at least the issue seems to be more of a "biggie" than you might have thought, because this kind of noise is added to the signal whenever [hip~] is used as a DC blocker (which is, after all, one of its main use cases). With good headphones this can become quite audible: Just try feeding [osc~ 0.1] into [hip~ 5] and listen to it at high gain!

Trying to understand what's going on here, I found this hint in Julius Smith's introduction to digital filters. So it really seems to be a result of the specific implementation structure of [hip~], where the zero is placed after instead of before the pole. I tried both implementations and can confirm that there is no (or much less) noise added if the zero precedes the pole.

As a simpler workaround I suggest to use [lop~] and subtract its output from the input signal.

Edit: So here's a little patch to demonstrate this ... hip-noise.pd

@jameslo I agree with both of your points. Except that I thought a hardsync oscillator would do exactly what you describe: reset the phase of the output phasor regardless of its current phase. So unless I'm mistaken here (which is very possible), my approach should be usable for that.

Wheter it can be used for a synchronized system with a central phasor I'm not so sure ... Maybe the mode (sync or non-sync) should depend on wheter the scaling factor is an integer or not? On the other hand: If it is an integer, the multiply-wrap method suggested by @PD-Pi is of course much simpler and probably more precise.

@jameslo said:

Can you show me a patch that, say, generates all 12 equally tempered tones starting with middle C from 1 phasor?

You could do something like this ... phasor-sync.pd

Note sure if that's anywhere close to what's going on inside Max's [rate~], though.

@lacuna Just because anyone else has replied yet ...

I don't really understand the code of IEMlib's [filter~] but I'm pretty sure that it is indeed a biquad filter, that is: if the filter (defined by the first argument) is second order. First order filters use a similar but cheaper algorithm. Higher order filters are implemented as a cascade of first and second order sections depending on whether the filter order is even or uneven.

To get the biquad coefficients right, it's important to notice the differences in implementation. (There has been confusion in the past because Max and Pd use different implementations.) Both Pd's [biquad~] and IEMlib's [filter~] seem to use Direct-Form II, but I'm not sure about that.

@ddw_music Maybe [player~] from the ELSE library could be an option?

@beep.beep Instead of using a send symbol for the routing to the two outlets, couldn't you just use the plain old [route] object with a preceding [list prepend]?

@ddw_music said:

Wouldn't surprise me at all if lop2~'s behavior is identical to RLPF's.

But ELSE's [lop2~] isn't even a resonant filter, just a first order low-pass filter! I think it's just named "lop2~" because "lop~" is already used in Pd Vanilla, kinda misleading though.

The resonant low-pass filter in ELSE is called [lowpass~]. Checking its help file, I noticed a somewhat strange preset range for the resonance/Q parameter. (Maybe that's also an issue in SC's RLPF?) Values smaller than 0.5 don't seem all too reasonable to me because the filter is then "overdamped" and the actual cutoff frequency drops far below the specified frequency. In some filters Q = 0.5 is therefore simply defined as zero resonance, which probably adds to the confusion ...

Edit: It's even worse than that, because there are also two different definitions of the Q factor. (Here, I was refering to the "physical" rather than the bandwidth definition.)

Another edit: In the ELSE tutorial only the bandwidth definition of Q is given (or maybe I just overlooked something?). But in Robert Bristow-Johnson's Audio EQ Cookbook, which is the source for some of ELSE's filters, the physical / electrical engineering definition is used. So there might really be a bit of confusion. Or is it just me confusing things here?