Re: [PD] Fwd: what fdn~ does?
Nice sleuthing Holmes
On Tue, 29 Jan 2019 at 01:43, Alexandre Torres Porres
wrote:
> I guess "bingo"?
> https://ccrma.stanford.edu/~jos/pasp/First_Order_Delay_Filter_Design.html
>
> Em seg, 28 de jan de 2019 às 22:54, Alexandre Torres Porres <
> por...@gmail.com> escreveu:
>
>>
>> Em seg, 28 de jan de 2019 às 18:45, Peter P.
>> escreveu:
>>
>>> * Alexandre Torres Porres [2019-01-28 20:10]:
>>> > I guess I'm figuring something out, but the secondary inlets are still
>>> not
>>> > clear to me, they set the decay time, but why is there a "low" and
>>> "high"?
>>> Could it be that decay times are different for high and low frequencies
>>> and that these two are divided by a cutoff frequency? Just guessing
>>>
>>
>> Sort of... I finally made some sense of the code. it seems there's a
>> 1pole filter whose parameters depend on these low/high values and the delay
>> length! In the comment of the code we find a filter equation, something
>> like:* "yn = (2*gl*gh ) / (gl+gh) x + (gl-gh) / (gl+gh) y[n-1]" *-
>> where *gl* & *gh* are derived from these low and high values. Here's a
>> code simplification of it
>>
>>
>>
>> *for*(i = 0; i < x->x_ctl.c_order; i++){
>>
>> gl = pow(10, -0.003 * x->x_ctl.c_length[i] / low);
>>
>> gh = pow(10, -0.003 * x->x_ctl.c_length[i] / high);
>>
>> x->x_ctl.c_gain_in[i] = 2*gl*gh / (gl+gh);
>>
>> x->x_ctl.c_gain_state[i] = (gl-gh) / (gl+gh);
>>
>>
>>
>> I don't really get how this filter fully works yet, but I can sort of get
>> the gist of it. I'm now in the quest to find what is the source of this
>> filter, and maybe try it out independently to see how it behaves. But
>> perhaps a more sophisticated method, with a settable crossover frequency
>> could be used instead.
>>
>>
>> And yeah, it seems vanilla's [rev2~] and [rev3~] are implementations of
>> feedback delay networks like it's been said here on this thread.
>>
>>
>> cheers
>>
>>
>>
>>
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Re: [PD] Replacement for tot
Em qui, 31 de jan de 2019 às 11:32, oliver escreveu: > > [MouseState] from CYCLONE just [mousestate] is fine now in the newer versions, no need for capital letters ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Advantages of using [timer] over [realtime]
On Thu, 2019-01-31 at 15:13 +, Mario Buoninfante wrote: > What would be the pros and cons in using [timer] instead of > [realtime]. Do you expect some salesman's answer? I'm not good in that. Asking for pros and cons sounds like they have similar features where one is "shining" in one area, while the other is more "brilliant" in this regard. I'd say they are different by nature. > I know the latter asks the OS for time, while [timer] deals with > logical time. > If I got it right, logical time is tied to the sample rate No. > (and block size) No. > , so it's basically the 'Pd time'. Yes. I think you figured out the most significant differences already. [timer] is always consistent with objects that are able to schedule something for later, like [metro], [delay], [pipe], [delread~], etc. However, from what I understand it is not tied to sample rate or blocksize, since it measures logical time in milliseconds. Its accuracy is only limited by the 32bit floating point number format. [timer] will give you the same results, regardless of sample rate. > Another question would also be, which one is the most accurate? Only [timer] is accurate regarding logical time. Assuming, Pd is running without drop-outs, [realtime] and [timer] will give you similar numbers, but only [timer] reflects the accurate times as they have been generated by [delay], [metro] and such. [realtime] will suffer jitter in the range of your delay in your audio settings. Depending on CPU load, [realtime] will lag behind. However, if you overload your CPU, because your patch is too demanding to be running in realtime, [realtime] will reflect the effective (phyiscal) time that has passed since it was last triggered. Under such circumstance, the measurements taken by [timer] and [realtime] will drift apart more and more and [realtime] will give you larger values than [timer], because [timer] will be consistent with the amount of audio computed and thus will lag behind realtime. > If this question is applicable. Try this: [O] | [t b b b] \ | / \ [pd heavy_task] \ / \/ /\ / \ /\ [timer ] | [0. \ [timer] will give you always 0. [realtime] will show you the exact amount of time it took to calculate [pd heavy_task] Heavy task could be something like: [10( | [until | [2.34354( | [pow 3842.39] Hope this helps. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Advantages of using [timer] over [realtime]
> What would be the pros and cons in using [timer] instead of [realtime]. there's really no pro or con, they fullful entirely different tasks. this might not be so obvious when running Pd in realtime mode, but it becomes very apparent when running in batch mode (where the patch might take 1 minute of Pd time but only 1 second of OS time) personally, I only use [realtime] for profiling tasks. I *never* use it in my patch logic because it isn't deterministic. > Another question would also be, which one is the most accurate? If this > question is applicable. [realtime] is accurate for OS time and [timer] is accurate for Pd time ;-) Christof Gesendet: Donnerstag, 31. Januar 2019 um 16:13 Uhr Von: "Mario Buoninfante" An: pd-list Betreff: [PD] Advantages of using [timer] over [realtime] Hi, What would be the pros and cons in using [timer] instead of [realtime]. I know the latter asks the OS for time, while [timer] deals with logical time. If I got it right, logical time is tied to the sample rate (and block size), so it's basically the 'Pd time'. Another question would also be, which one is the most accurate? If this question is applicable. Cheers, Mario___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] Advantages of using [timer] over [realtime]
Hi, What would be the pros and cons in using [timer] instead of [realtime]. I know the latter asks the OS for time, while [timer] deals with logical time. If I got it right, logical time is tied to the sample rate (and block size), so it's basically the 'Pd time'. Another question would also be, which one is the most accurate? If this question is applicable. Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Replacement for tot
Ed Kelly via Pd-list wrote: Hi all, Does anyone have, or know of a replacement for tot. I specifically want to access the arrow keys, and the mouse position. I need it for my tracker seqauencers... for the arrow keys you can also use vanilla's [keyname] for mouse motion: either [MouseState] from CYCLONE or [receivecanvas] from the IEMGUTS library (available via deken) as for [receivecanvas]: check the helpfile, it already outputs keys and motion info. the tricky part is to use it inside a GOP, though write back to me if you want to go that route best oliver ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] Replacement for tot
Hi all, Does anyone have, or know of a replacement for tot. I specifically want to access the arrow keys, and the mouse position. I need it for my tracker seqauencers...Ed _-_-_-_-_-_-_-^-_-_-_-_-_-_-_ For Lone Shark releases, Pure Data software and published Research, go to http://sharktracks.co.uk ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
