• manuels

    @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.

    posted in technical issues read more
  • manuels

    @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.

    posted in technical issues read more
  • manuels

    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

    posted in technical issues read more
  • manuels

    @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.

    posted in technical issues read more
  • manuels

    @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.

    posted in technical issues read more
  • manuels

    @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.

    posted in technical issues read more
  • manuels

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

    posted in technical issues read more
  • manuels

    @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]?

    posted in technical issues read more
  • manuels

    @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?

    posted in technical issues read more
  • manuels

    Here's an updated version of the pole-zero diagram I posted two years ago:

    pole-zero-diagram-2.0.pd

    Unfortunately, I didn't know about ELSE back then. As you probably know, it has frequency response and pole-zero plots as well, and there's also a section about the Z-plane in the wonderful live-electronics tutorial. In fact, these are the main reasons, why I decided to update my patch.

    So the new version of my pole-zero diagram has two additional features: First, you can now switch between linear and logarithmic scaling of both amplitude and frequency, and second, I added some examples of standard filter types, so that you can also see the effect of changing a filter's parameters on the positions of its poles and zeros.

    I hope this may be helpful for some of you. If something's wrong with the patch or the filter examples, please tell me!

    posted in patch~ read more

Internal error.

Oops! Looks like something went wrong!