• jameslo

    @mrsean I wasn't really suggesting you use it. I was thinking of posting my own solution to your problem (which uses both expr and expr~) but when I looked more closely I realized that it's almost the same as yours except all in audio domain.

    posted in patch~ read more
  • jameslo

    @mrsean Is [expr] and [expr~] available in the heavy compiler?

    posted in patch~ read more
  • jameslo

    @raynovich Did you try increasing the delay in your audio interface settings? On one of my patches that fixes the drop out after I create and destroy the gem window once.

    posted in technical issues read more
  • jameslo

    I just got a fast new computer and I get a very short dropout on [create( but not [destroy(, so I guess that means "yes, that's just the way it is"?

    I wonder if you put the GEM stuff in another process (using [pd~]) and you didn't return any audio from that process whether that would address this issue? EDIT: nope, it doesn't. And launching the subprocess is even more disruptive.

    posted in technical issues read more
  • jameslo

    @rewindForward In addition to sharing your patch (it could even be one using [expr~]), please let us know what your trigger signal is (i.e. I'm unclear why the signal is ~1 ms long)

    posted in technical issues read more
  • jameslo

    @whale-av I thought I had figured out the relationship between Q and BW but my patch failed miserably. So I just went with BW but got the same "close but no cigar" results:
    Screenshot 2026-01-20 110847.png
    Edit: looking back at that cookbook formula for notch coefficients (https://webaudio.github.io/Audio-EQ-Cookbook/audio-eq-cookbook.html), ff1 and ff3 are defined as 1/1+alpha, so the only way that could equal 1 is if alpha equals 0. But alpha is defined as sin(2 * pi * f / sr) / 2 * Q, so f would have to be 0 or Nyquist, or else Q is so large that it underflows the precision of the floats used to calculate the coefficients? And if it's the latter, then that seems like a weird thing to present as an illustrative example. (Note that in the example, f = 5512.5 = Nyquist/4--prob not a coincidence)

    I'm still mystified.

    posted in technical issues read more
  • jameslo

    In the help patch for [biquad~] there are coefficients for a very narrow bandstop filter centered at 5512.5 hz @ 44.1k or 6000 hz @ 48k. The filter's Q isn't stated so I thought I could reverse engineer it using those coefficients as my key but I can't seem to generate them exactly by using either my own coefficient calculator or the one from ELSE (bicoef2). I get close with a Q of about 3500, but I can't match all coefficients with a single Q value (I can't remember if the 1s are even posssible). Why would that be?
    help coefficients search.pd

    posted in technical issues read more
  • jameslo

    @april Check the order of coefficients to [biquad~]. I think the feedback coefficients come before the feedforward coefficients. Also check the sign of the feedback coefficients. According to this reference https://webaudio.github.io/Audio-EQ-Cookbook/audio-eq-cookbook.html (formula 4) they should be negative.

    Edit: additionally, try adding triggers to the outputs of the [expr] objects to ensure each of the sub branches are being evaluated in the order you think they should be. Here's my version based on that reference: biquad notch coefficients.pd

    posted in technical issues read more
  • jameslo

    @solipp said:

    use [set 64 1 $1(
    no need to switch dsp off

    OMG, I was staring at my own code and didn't see that!

    posted in technical issues read more
  • jameslo

    @hansr If you can tolerate the latency and inflexible cutoff frequencies, I've used FFT resynthesis for this kind of thing. At 44.1 and a window size of 2048, zeroing out the first two bins would get you very close I think. And if I'm not mistaken, doing it this way introduces less phase distortion.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!