Re: [PD] Fwd: what fdn~ does?
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
Re: [PD] TCP weirdness ? ...
hi, check this out: https://github.com/pure-data/pure-data/issues/378 TL;DR: [connect( tries to establish a connection until it times out. currently, the default timeout is system dependend, but it would be nice if we could also set it manually. and yes, the default timeout should be a bit shorter ;-). it's easy to implement, I wanted to make a PR but forgot... Christof > Gesendet: Dienstag, 29. Januar 2019 um 01:24 Uhr > Von: "oliver" > An: "pd-l...@mail.iem.at" > Betreff: [PD] TCP weirdness ? ... > > hi, i recently stumbled upon some weird behaviour when i tried to > connect 2 computers via netsend using the TCP protocol. > > this is on Windows 7 / 64bit, PD 0.49.0: > > so i hooked up 2 PCs with a network cable and fixed IP addresses. > everything works fine. i can ping, i can send udp data to and from. > > but now comes the weird situation: > > when i try to connect with a TCP protocol to a valid IP address, but the > port on the other machine is not yet opened (i.e. no [netreceive] has > been created on the other computer), then my local PD freezes for about > 20 (!) seconds before printing an error to the console. > > if i try to connect to a "localhost" non-existing port, there's still a > small PD freeze but only for about 1 second. > > also irritating is the fact, that an invalid connection doesn't output a > 0 on the left output, but instead does nothing. only the [disconnect( > message outputs a 0. > > i would expect a non existing connection (whether it's because of an > invalid IP-address or a wrong port number) to just immediately output an > error on the console AND output a 0 on the left output of [netsend], right ? > > i am no expert in this field, so it might be that this behaviour is > normal, though it doesn't seem right to me to stall a program for 20 > seconds because of a worng network connection. i also experienced this > behaviour with iemnet's [tcpsend] and [tcpclient]. > > i attached a patch with the described scenarios. > > thanks for any help or wisdom ! > > best > > oliver > > -- > > /// http://pendler.klingt.org // > \\\ http://oliver.klingt.org \\ > > ___ > 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] Fwd: what fdn~ does?
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] TCP weirdness ? ...
hi, i recently stumbled upon some weird behaviour when i tried to connect 2 computers via netsend using the TCP protocol. this is on Windows 7 / 64bit, PD 0.49.0: so i hooked up 2 PCs with a network cable and fixed IP addresses. everything works fine. i can ping, i can send udp data to and from. but now comes the weird situation: when i try to connect with a TCP protocol to a valid IP address, but the port on the other machine is not yet opened (i.e. no [netreceive] has been created on the other computer), then my local PD freezes for about 20 (!) seconds before printing an error to the console. if i try to connect to a "localhost" non-existing port, there's still a small PD freeze but only for about 1 second. also irritating is the fact, that an invalid connection doesn't output a 0 on the left output, but instead does nothing. only the [disconnect( message outputs a 0. i would expect a non existing connection (whether it's because of an invalid IP-address or a wrong port number) to just immediately output an error on the console AND output a 0 on the left output of [netsend], right ? i am no expert in this field, so it might be that this behaviour is normal, though it doesn't seem right to me to stall a program for 20 seconds because of a worng network connection. i also experienced this behaviour with iemnet's [tcpsend] and [tcpclient]. i attached a patch with the described scenarios. thanks for any help or wisdom ! best oliver -- /// http://pendler.klingt.org // \\\ http://oliver.klingt.org \\ #N canvas 441 357 685 385 10; #X obj 37 311 netsend; #X msg 37 41 connect localhost 3000; #X msg 46 289 send foo \$1; #X floatatom 46 262 0 0 0 0 - - -; #X msg 37 234 disconnect; #X floatatom 37 338 0 0 0 0 - - -; #X text 80 12 TCP \, ascii; #X obj 76 337 print backward; #X msg 37 176 connect 169.254.34.130 ; #X msg 37 124 connect 10.0.0.9 ; #X obj 194 311 netreceive 3000; #X obj 194 335 print REC; #X msg 37 68 connect localhost 4000; #X text 187 40 if present: immediate connection \, left outlet = 1 ; #X text 114 232 left outlet = 0; #X text 186 67 if not present: 1 second freeze \, left outlet = no change; #X msg 37 103 connect 192.254.34.130 ; #X text 221 101 if IP address not present: no freeze \, left outlet = no change, f 28; #X text 220 163 if IP address present \, but no [netreceive] on other machine: 20 seconds freeze on local PD before error in console \, left outlet = no change; #X connect 0 0 5 0; #X connect 0 1 7 0; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 2 0; #X connect 4 0 0 0; #X connect 8 0 0 0; #X connect 9 0 0 0; #X connect 10 0 11 0; #X connect 12 0 0 0; #X connect 16 0 0 0; ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: what fdn~ does?
* 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: what fdn~ does?
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"? Em sex, 25 de jan de 2019 às 18:03, Alexandre Torres Porres < por...@gmail.com> escreveu: > > > Em sex, 25 de jan de 2019 às 15:24, José de Abreu > escreveu: > >> >> > if i remember well one of revN~ objects from miller uses this approach to >> make reverb >> > > ok, now I'm curious, which one? Can we confirm it is an actual "FDN" > approach? It seems Miller has an important paper describing FDN for reverb > :) > > And, yeah, I've checking those sources already and I could get the gist of > it... but it'd be quite better if the author or someone who's been using > this object a lot could better clarify how to deal with it. > > cheers > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] Purr Data 2.8.0 released
Hi list, Purr Data 2.8.0 has been released and is now available: https://github.com/jonwwilkes/purr-data/releases/tag/2.8.0 Changes: * Constrained dragging. Version 2.8.0 adds the ability to drag iemguis, subpatches, graphs, grid, and Scope~, with a constraint either vertically or horizontally. There are new cursors that show up when the user moves the pointer along the bottom right-hand corners of these objects. Clicking when the "east-west" cursor is displayed will resize the widget in the horizontal direction. Clicking when the "north-south" cursor is displayed will resize in the vertical direction. Iemgui labels and the [cnv] object also allow constrained dragging. Just move the pointer in the corners of the little "drag rectangle" that appears when the relevant iemgui is selected. (The [cnv] object and the red gop rectangle have two such "drag rectangles.") * Fixed bug with scalar events. In some cases opening a subpatch could unbind the event for the scalar. * Improved help patch for [line] object. The new help file does a better job explaining the function of the 3rd inlet and specifies what happens when the grain size doesn't divide evenly into the total ramp duration. * Added a "footgun" GUI preset. A user stated that Max/MSP lets the user selectively hide cords. Well, in Purr Data we let the user hide _all_ cords and xlets with the "footgun" preset. The name is self-documenting but may come in handy for patches with so much spaghetti that the text in the object boxes is unreadable. Please report all bugs on the issue tracker: https://git.purrdata.net/jwilkes/purr-data/issues Best, Jonathan___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
