• jameslo

    @bocanegra Yeah, sorry, I edited my comment after I realized my mistake.

    posted in technical issues read more
  • jameslo

    @raynovich I thought this way by @jyg was clever

    edit: oh but you'd have to add in the imaginary input AND you'd have to know how to map the phase you want into the real and imaginary FFT coefficients. Yeah, I guess it would be clearer to just generate the sum by hand, even using counters and cos in control rate.

    posted in technical issues read more
  • jameslo

    But none of this speculation is relevant to @raynovich 's question. Regardless of the reason, [realtime] isn't going to show you the 1.45 ms time quantization that happens when you naively mix control rate and audio rate processing (as demonstrated by my 2nd test). And control-rate delays like [delay] and [pipe] are different from audio delays [delwrite~], [delread~] and [vd~], so I'm not sure what you (@raynovich) are referring to when you write "sound design delays".

    posted in technical issues read more
  • jameslo

    @ingox But I'm not assuming that [realtime] is inaccurate, I'm just wondering whether it is showing that the OS and Pd are precomputing future logical time events in chunks, i.e. lurching forward faster than logical time. If at real time 0 Pd finished it's first 6 ms of logical time work, then it could go on vacation for 6 ms without anyone in logical time noticing. But the real time folk notice.

    I dunno, I'm probably high. :)

    posted in technical issues read more
  • jameslo

    I wonder if [realtime] is just measuring something irrelevant to sound output, e.g. when the OS and Pd decide to schedule computations. That would explain why my and David's results for my previous test differ. Look at these tests:
    Screenshot 2021-06-12 082032.png delayInReality.pd
    Neither jitter in the 6 ms range, and they only transition on 64 sample boundaries, which is what I'd expect because that's when control-rate messages are processed (assuming [block~ 64]).

    edit: ugh, I just realized how bad my sends and receives are. Things still work, it's just terrible coding. Just run one side or the other.

    posted in technical issues read more
  • jameslo

    @Knallberto It works for me (Mid 2012 Macbook Pro, Mojave, Pd 0.51-4)

    Screen Shot 2021-06-11 at 5.52.58 PM.png

    posted in technical issues read more
  • jameslo

    @raynovich I ran this test and you can see that all the delays are rounded to the nearest 6 ms or so:
    Screenshot 2021-06-11 135704.png delayInRealtime.pd
    I was expecting it to round to the nearest 1.45 ms because I assumed that bangs would be processed between 64 sample audio blocks, so something else is going on.

    I found what I think is the delay object in x-time.c, but I don't understand the code structure well enough (yet!) to make heads or tails of it.

    posted in technical issues read more
  • jameslo

    @solipp Thank you for contributing this library, I'm learning tons. I have some questions about fft-split~.

    • It looks like you are simply passing the bins that are below the threshold frequency to the left inverse transform, and the rest to the right (with the omitted bins on each side muted), is that correct?
    • If so, then why does the transition band sound continuous? i.e. when I output lowpass to the left and highpass to the right, as I sweep up it moves continuously from left to right around the threshold frequency.
    • I struggled to make a test to see what phase distortions occur near the threshold frequency, and there don't appear to be any. Could that be true? (I'm not confident I tested properly)

    posted in news read more
  • jameslo

    @ddw_music good point. Then maybe that same trick could simplify your impulse generator?
    Screenshot 2021-06-09 061804.pngOr you could snapshot the output state to parameterize the obliteration :)
    Screenshot 2021-06-09 063147.png

    posted in technical issues read more
  • jameslo

    @ddw_music you could also just replace the impulse generator with [set 1(

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!