Date: Tue, 22 Apr 2008 16:02:37 +0100 From: Andy Farnell padawan12@obiwannabe.co.uk Subject: Re: [PD] Cyclone in vanilla? To: pd-list@iem.at
=================
Right now my 'missing' list includes [z~], [abs~], [ln~], [log~], [pow~], [tanh~], [cosh~]
One might put [atan~] and [atan2~] on this list as well.
[ln~] and [log~] probably ought instead to be [log~] and [log10~], respectively.
Actually, for those of us who insist on vanilla and do everything with expr/expr~/fexpr~ or abstractions, is it possible to implement [z~] in fexpr~ for a delay larger than its vector size? You could do it with an abstraction using [delwrite~] and [delread~], setting the [block~] to 1, and then set the delay as a ratio to the [samplerate~] -- the difficulty in making it work correctly here is setting the size of the [delwrite~] efficiently (this could maybe be done with a loadbang routine that would send a message to a subpatch in the abstraction instance to add and connect a delwrite~ with the proper delay allocation...). In pedagogical situations such an example might also be useful for gently introducing the block/vector structure of PD that you would need anyway for proper delay/feedback examples as well as FFT (and possibly for sending messages to subpatches), but I'm pretty sure it's not the most efficient model available.
On a similar note, is it possible to recreate things like [zexy/noish~] or [zexy/noisi~] in vanilla PD as an abstraction? It would be great to have these for building pinkish noise or random control of other audio parameters, and these seem fairly primitive to any serious synthesis engine.
Thanks,
Matt
Hallo, Matt Barber hat gesagt: // Matt Barber wrote:
Actually, for those of us who insist on vanilla and do everything with expr/expr~/fexpr~ or abstractions, is it possible to implement [z~] in fexpr~ for a delay larger than its vector size? You could do it with an abstraction using [delwrite~] and [delread~], setting the [block~] to 1, and then set the delay as a ratio to the [samplerate~] -- the difficulty in making it work correctly here is setting the size of the [delwrite~] efficiently (this could maybe be done with a loadbang routine that would send a message to a subpatch in the abstraction instance to add and connect a delwrite~ with the proper delay allocation...).
You don't need to set the block~-size to 1, and personally I would just make the delwrite~ "big enough". It's cheap to store things in a delay. But anyway, attached is a z~-clone with delwrite~/delread~ that uses a helper abstraction created dynamically.
Ciao
Frank Barknecht _ ______footils.org__
I believe z~ is just rzero~ 0.
cheers Miller
On Wed, Apr 23, 2008 at 11:24:34AM +0200, Frank Barknecht wrote:
Hallo, Matt Barber hat gesagt: // Matt Barber wrote:
Actually, for those of us who insist on vanilla and do everything with expr/expr~/fexpr~ or abstractions, is it possible to implement [z~] in fexpr~ for a delay larger than its vector size? You could do it with an abstraction using [delwrite~] and [delread~], setting the [block~] to 1, and then set the delay as a ratio to the [samplerate~] -- the difficulty in making it work correctly here is setting the size of the [delwrite~] efficiently (this could maybe be done with a loadbang routine that would send a message to a subpatch in the abstraction instance to add and connect a delwrite~ with the proper delay allocation...).
You don't need to set the block~-size to 1, and personally I would just make the delwrite~ "big enough". It's cheap to store things in a delay. But anyway, attached is a z~-clone with delwrite~/delread~ that uses a helper abstraction created dynamically.
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
or [biquad~ 0 0 0 1]
eni
Miller Puckette wrote:
I believe z~ is just rzero~ 0.
cheers Miller
On Wed, Apr 23, 2008 at 11:24:34AM +0200, Frank Barknecht wrote:
Hallo, Matt Barber hat gesagt: // Matt Barber wrote:
Actually, for those of us who insist on vanilla and do everything with expr/expr~/fexpr~ or abstractions, is it possible to implement [z~] in fexpr~ for a delay larger than its vector size? You could do it with an abstraction using [delwrite~] and [delread~], setting the [block~] to 1, and then set the delay as a ratio to the [samplerate~] -- the difficulty in making it work correctly here is setting the size of the [delwrite~] efficiently (this could maybe be done with a loadbang routine that would send a message to a subpatch in the abstraction instance to add and connect a delwrite~ with the proper delay allocation...).
You don't need to set the block~-size to 1, and personally I would just make the delwrite~ "big enough". It's cheap to store things in a delay. But anyway, attached is a z~-clone with delwrite~/delread~ that uses a helper abstraction created dynamically.
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
IOhannes m zmölnig wrote:
Enrique Erne wrote:
or [biquad~ 0 0 0 1]
Miller Puckette wrote:
I believe z~ is just rzero~ 0.
no. both of them are equivalent to [z~ 1]
you could also argue that [f] is just the same as [0( :-)
oups, yes ofcorse z~ 1.
the output of 1 sample with rzero~ 0, z~ 1 and biquad~ 0 0 0 1 seems to be slightly different. if one wants to be fuzzy about that :) maybe ome rounding problem?
this is off the subject. it would have been more suitable in "I'm stuck in a corner, please help! RE: [delta~] object" ... therefore i'll change the subject.
and now i even couldn't do the delwrite/read with the subpatch :( :(
eni
#N canvas 366 22 837 595 10; #X obj -139 267 vline~; #N canvas 0 22 450 300 (subpatch) 0; #X array display-biquad 10 float 2; #X coords 0 1 10 -1 100 100 1; #X restore 7 434 graph; #X msg -75 354 bang; #X floatatom -131 100 12 0 0 0 - - -; #X obj -1 342 biquad~ 0 0 0 1; #X obj 175 349 z~ 1; #N canvas 0 22 450 300 (subpatch) 0; #X array display-z 10 float 2; #X coords 0 1 10 -1 100 100 1; #X restore 173 430 graph; #X obj 9 396 tabwrite~ display-biquad; #X obj 174 393 tabwrite~ display-z; #X text 161 111 click here; #X obj 315 393 tabwrite~ display-rzero; #N canvas 0 22 450 300 (subpatch) 0; #X array display-rzero 10 float 2; #X coords 0 1 10 -1 100 100 1; #X restore 317 432 graph; #X msg -10 218 0 , 0.5 0 0.022 , 0 0 0.044; #X msg 165 136 ; pd dsp 1; #X msg -143 29 1000; #X obj -97 148 * 2; #X floatatom -82 169 12 0 0 0 - - -; #X obj -140 171 pack f f; #X obj -142 124 t a a; #X msg -140 217 0 , 0.5 0 $1 , 0 0 $2; #X obj -85 51 samplerate~; #X floatatom -49 78 7 0 0 0 - - -; #X obj -142 52 t a b; #X obj -143 76 / 44100; #X msg 124 112 bang; #X obj -140 195 t a b; #X text -108 29 or here; #N canvas 0 22 450 300 (subpatch) 0; #X array display-org 10 float 2; #X coords 0 1 10 -1 100 100 1; #X restore -142 430 graph; #X obj -144 391 tabwrite~ display-org; #X obj 310 350 rzero~ 0; #X obj -126 312 dirac~; #N canvas 504 22 450 300 write~ 0; #X obj 39 234 outlet~; #X obj 20 32 inlet~; #X obj 37 97 delwrite~ asdf; #X connect 1 0 2 0; #X restore 472 341 pd write~; #N canvas 206 409 450 300 read~ 1; #X obj 17 33 inlet~; #X obj 26 156 outlet~; #X obj 36 125 delread~ asdf; #X floatatom 150 119 12 0 0 0 - - -; #X obj 175 84 samplerate~; #X floatatom 227 115 7 0 0 0 - - -; #X obj 127 63 t a b; #X obj 142 23 loadbang; #X obj 138 95 /; #X msg 134 43 1000; #X connect 2 0 1 0; #X connect 4 0 5 0; #X connect 4 0 8 1; #X connect 6 0 8 0; #X connect 6 1 4 0; #X connect 7 0 9 0; #X connect 8 0 3 0; #X connect 8 0 2 0; #X connect 9 0 6 0; #X restore 472 367 pd read~; #X obj 466 393 tabwrite~ display-del; #N canvas 0 22 450 300 (subpatch) 0; #X array display-del 10 float 2; #X coords 0 1 10 -1 100 100 1; #X restore 454 433 graph; #X text 467 327 i don't know whats wrong here; #X connect 0 0 4 0; #X connect 0 0 5 0; #X connect 0 0 28 0; #X connect 0 0 29 0; #X connect 0 0 31 0; #X connect 2 0 7 0; #X connect 2 0 8 0; #X connect 2 0 10 0; #X connect 2 0 28 0; #X connect 2 0 33 0; #X connect 4 0 7 0; #X connect 5 0 8 0; #X connect 12 0 0 0; #X connect 14 0 22 0; #X connect 15 0 16 0; #X connect 15 0 17 1; #X connect 17 0 25 0; #X connect 18 0 17 0; #X connect 18 1 15 0; #X connect 19 0 0 0; #X connect 20 0 21 0; #X connect 20 0 23 1; #X connect 22 0 23 0; #X connect 22 1 20 0; #X connect 23 0 3 0; #X connect 23 0 18 0; #X connect 24 0 2 0; #X connect 24 0 12 0; #X connect 25 0 19 0; #X connect 25 1 2 0; #X connect 29 0 10 0; #X connect 31 0 32 0; #X connect 32 0 33 0;
Enrique Erne wrote:
IOhannes m zmölnig wrote:
Enrique Erne wrote:
or [biquad~ 0 0 0 1]
Miller Puckette wrote:
I believe z~ is just rzero~ 0.
no. both of them are equivalent to [z~ 1]
you could also argue that [f] is just the same as [0( :-)
oups, yes ofcorse z~ 1.
the output of 1 sample with rzero~ 0, z~ 1 and biquad~ 0 0 0 1 seems to be slightly different. if one wants to be fuzzy about that :) maybe ome rounding problem?
no, i don't see any rounding errors...
and now i even couldn't do the delwrite/read with the subpatch :( :(
it's generally a good idea to tell [delwrite~] how much space it should allocate for the delayline. e.g. [delwrite~ abcd 1000] helped a lot...
and [rzero~ 0] is not the same as [z~ 1].
the output of [z~ 1] is y[n]=x[n-1] according to [rzero~]s help-patch it does the following:
y[n]=x[n]-a[n]*x[n-1] since you set a[n] to "0", you just get y[n]=x[n] :-(
to get [z~ 1], do something like
| +--+ | | | [rzero~ 1] | | [-~] |
fmgads.r IOhannes
IOhannes m zmölnig wrote:
Enrique Erne wrote:
IOhannes m zmölnig wrote:
Enrique Erne wrote:
or [biquad~ 0 0 0 1]
Miller Puckette wrote:
I believe z~ is just rzero~ 0.
no. both of them are equivalent to [z~ 1]
you could also argue that [f] is just the same as [0( :-)
oups, yes ofcorse z~ 1.
the output of 1 sample with rzero~ 0, z~ 1 and biquad~ 0 0 0 1 seems to be slightly different. if one wants to be fuzzy about that :) maybe ome rounding problem?
no, i don't see any rounding errors...
and now i even couldn't do the delwrite/read with the subpatch :( :(
it's generally a good idea to tell [delwrite~] how much space it should allocate for the delayline. e.g. [delwrite~ abcd 1000] helped a lot...
and [rzero~ 0] is not the same as [z~ 1].
the output of [z~ 1] is y[n]=x[n-1] according to [rzero~]s help-patch it does the following:
y[n]=x[n]-a[n]*x[n-1] since you set a[n] to "0", you just get y[n]=x[n] :-(
to get [z~ 1], do something like
| +--+ | | | [rzero~ 1] | | [-~] |
thanks iohannes. it looks good now.
#N canvas 366 22 837 595 10; #X obj -139 267 vline~; #N canvas 0 22 450 300 (subpatch) 0; #X array display-biquad 10 float 2; #X coords 0 1 10 -1 100 100 1; #X restore 7 434 graph; #X msg -75 354 bang; #X floatatom -131 100 12 0 0 0 - - -; #X obj -1 342 biquad~ 0 0 0 1; #X obj 175 349 z~ 1; #N canvas 0 22 450 300 (subpatch) 0; #X array display-z 10 float 2; #X coords 0 1 10 -1 100 100 1; #X restore 173 430 graph; #X obj 9 396 tabwrite~ display-biquad; #X obj 174 393 tabwrite~ display-z; #X text 161 111 click here; #X obj 315 393 tabwrite~ display-rzero; #N canvas 0 22 450 300 (subpatch) 0; #X array display-rzero 10 float 2; #X coords 0 1 10 -1 100 100 1; #X restore 317 432 graph; #X msg -10 218 0 , 0.5 0 0.022 , 0 0 0.044; #X msg 165 136 ; pd dsp 1; #X msg -143 29 1000; #X obj -97 148 * 2; #X floatatom -82 169 12 0 0 0 - - -; #X obj -140 171 pack f f; #X obj -142 124 t a a; #X msg -140 217 0 , 0.5 0 $1 , 0 0 $2; #X obj -85 51 samplerate~; #X floatatom -49 78 7 0 0 0 - - -; #X obj -142 52 t a b; #X obj -143 76 / 44100; #X msg 124 112 bang; #X obj -140 195 t a b; #X text -108 29 or here; #N canvas 0 22 450 300 (subpatch) 0; #X array display-org 10 float 2; #X coords 0 1 10 -1 100 100 1; #X restore -142 430 graph; #X obj -144 391 tabwrite~ display-org; #X obj -126 312 dirac~; #N canvas 504 22 450 300 write~ 0; #X obj 39 234 outlet~; #X obj 20 32 inlet~; #X obj 37 97 delwrite~ asdf 10; #X connect 1 0 2 0; #X restore 472 341 pd write~; #N canvas 206 409 450 300 read~ 0; #X obj 17 33 inlet~; #X obj 26 156 outlet~; #X obj 36 125 delread~ asdf; #X floatatom 150 119 12 0 0 0 - - -; #X obj 175 84 samplerate~; #X floatatom 227 115 7 0 0 0 - - -; #X obj 127 63 t a b; #X obj 142 23 loadbang; #X obj 138 95 /; #X msg 134 43 1000; #X connect 2 0 1 0; #X connect 4 0 5 0; #X connect 4 0 8 1; #X connect 6 0 8 0; #X connect 6 1 4 0; #X connect 7 0 9 0; #X connect 8 0 3 0; #X connect 8 0 2 0; #X connect 9 0 6 0; #X restore 472 367 pd read~; #X obj 466 393 tabwrite~ display-del; #N canvas 0 22 450 300 (subpatch) 0; #X array display-del 10 float 2; #X coords 0 1 10 -1 100 100 1; #X restore 454 433 graph; #X text 467 327 i don't know whats wrong here; #X obj 329 339 rzero~ 1; #X obj 315 360 -~; #X connect 0 0 4 0; #X connect 0 0 5 0; #X connect 0 0 28 0; #X connect 0 0 30 0; #X connect 0 0 35 0; #X connect 0 0 36 0; #X connect 2 0 7 0; #X connect 2 0 8 0; #X connect 2 0 10 0; #X connect 2 0 28 0; #X connect 2 0 32 0; #X connect 4 0 7 0; #X connect 5 0 8 0; #X connect 12 0 0 0; #X connect 14 0 22 0; #X connect 15 0 16 0; #X connect 15 0 17 1; #X connect 17 0 25 0; #X connect 18 0 17 0; #X connect 18 1 15 0; #X connect 19 0 0 0; #X connect 20 0 21 0; #X connect 20 0 23 1; #X connect 22 0 23 0; #X connect 22 1 20 0; #X connect 23 0 3 0; #X connect 23 0 18 0; #X connect 24 0 2 0; #X connect 24 0 12 0; #X connect 25 0 19 0; #X connect 25 1 2 0; #X connect 30 0 31 0; #X connect 31 0 32 0; #X connect 35 0 36 1; #X connect 36 0 10 0;
I've attached again an example of a patch that demonstrates the practical difference between different one sample differentiators.
Try replacing [fexpr~ $x1 - $x1[-1]] in the water flow generator with
/
| [z~]
| |
[-~]
|
which is fine.
Then try implementing the same with [rzero~ 1]
It sounds very different and I have not found a way to correct the accumulating DC error. Try the obvious [rzero~ 0.99999999] etc to hear that the behaviour is still not right.
Fundamentally, [z~] is a *very* useful primitive to have
On Fri, 25 Apr 2008 07:04:10 -0400 Enrique Erne enrique@netpd.org wrote:
IOhannes m zmölnig wrote:
Enrique Erne wrote:
IOhannes m zmölnig wrote:
Enrique Erne wrote:
or [biquad~ 0 0 0 1]
Miller Puckette wrote:
I believe z~ is just rzero~ 0.
no. both of them are equivalent to [z~ 1]
you could also argue that [f] is just the same as [0( :-)
oups, yes ofcorse z~ 1.
the output of 1 sample with rzero~ 0, z~ 1 and biquad~ 0 0 0 1 seems to be slightly different. if one wants to be fuzzy about that :) maybe ome rounding problem?
no, i don't see any rounding errors...
and now i even couldn't do the delwrite/read with the subpatch :( :(
it's generally a good idea to tell [delwrite~] how much space it should allocate for the delayline. e.g. [delwrite~ abcd 1000] helped a lot...
and [rzero~ 0] is not the same as [z~ 1].
the output of [z~ 1] is y[n]=x[n-1] according to [rzero~]s help-patch it does the following:
y[n]=x[n]-a[n]*x[n-1] since you set a[n] to "0", you just get y[n]=x[n] :-(
to get [z~ 1], do something like
| +--+ | | | [rzero~ 1] | | [-~] |
thanks iohannes. it looks good now.
I think this is my mistake -- as someone else pointed out, it should have been "rzero_rev~", not "rzero 1" -- sorry for the confusion.
Miller
On Fri, Apr 25, 2008 at 04:08:38PM +0100, Andy Farnell wrote:
I've attached again an example of a patch that demonstrates the practical difference between different one sample differentiators.
Try replacing [fexpr~ $x1 - $x1[-1]] in the water flow generator with
/
| [z~] | | [-~] |which is fine.
Then try implementing the same with [rzero~ 1]
It sounds very different and I have not found a way to correct the accumulating DC error. Try the obvious [rzero~ 0.99999999] etc to hear that the behaviour is still not right.
Fundamentally, [z~] is a *very* useful primitive to have
On Fri, 25 Apr 2008 07:04:10 -0400 Enrique Erne enrique@netpd.org wrote:
IOhannes m zm?lnig wrote:
Enrique Erne wrote:
IOhannes m zm?lnig wrote:
Enrique Erne wrote:
or [biquad~ 0 0 0 1]
Miller Puckette wrote: > I believe z~ is just rzero~ 0.
no. both of them are equivalent to [z~ 1]
you could also argue that [f] is just the same as [0( :-)
oups, yes ofcorse z~ 1.
the output of 1 sample with rzero~ 0, z~ 1 and biquad~ 0 0 0 1 seems to be slightly different. if one wants to be fuzzy about that :) maybe ome rounding problem?
no, i don't see any rounding errors...
and now i even couldn't do the delwrite/read with the subpatch :( :(
it's generally a good idea to tell [delwrite~] how much space it should allocate for the delayline. e.g. [delwrite~ abcd 1000] helped a lot...
and [rzero~ 0] is not the same as [z~ 1].
the output of [z~ 1] is y[n]=x[n-1] according to [rzero~]s help-patch it does the following:
y[n]=x[n]-a[n]*x[n-1] since you set a[n] to "0", you just get y[n]=x[n] :-(
to get [z~ 1], do something like
| +--+ | | | [rzero~ 1] | | [-~] |
thanks iohannes. it looks good now.
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Fundamentally, [z~] is a *very* useful primitive to have
I think, fundamentally z~ is just delread~/delwrite~ with a different way to specify delay times, slightly better performance because it doesn't allow many things delread~/delwrite~ can do, and no need to employ two objects. Or am I missing something?
Ciao
Frank Barknecht _ ______footils.org__
On 25/04/2008, at 18.34, Frank Barknecht wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Fundamentally, [z~] is a *very* useful primitive to have
I think, fundamentally z~ is just delread~/delwrite~ with a different way to specify delay times, slightly better performance because it doesn't allow many things delread~/delwrite~ can do, and no need to employ two objects. Or am I missing something?
Maybe that your implementation uses an unsupported feature?
On 25/04/2008, at 19.25, Steffen Juul wrote:
On 25/04/2008, at 18.34, Frank Barknecht wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Fundamentally, [z~] is a *very* useful primitive to have
I think, fundamentally z~ is just delread~/delwrite~ with a different way to specify delay times, slightly better performance because it doesn't allow many things delread~/delwrite~ can do, and no need to employ two objects. Or am I missing something?
Maybe that your implementation uses an unsupported feature?
I gotta point out that my intention was not to be rude, but rather to
point out that if, and i may very well be wrong, z~ implementations
need dynamic patching which is an unsupported feature then its not a
robust solution hence not the best to add to a printed book.
I'm sorry if i seamed rude, i just tried to be brief.
Hallo, Steffen Juul hat gesagt: // Steffen Juul wrote:
I gotta point out that my intention was not to be rude, but rather to
point out that if, and i may very well be wrong, z~ implementations
need dynamic patching which is an unsupported feature then its not a
robust solution hence not the best to add to a printed book.I'm sorry if i seamed rude, i just tried to be brief.
I didn't think you were rude at all. Note that I only used dynamic patching in my zel~ example to implement minimized buffer sizes as was requested.
But I also noted that I consider this a not very useful effort (premature optimization?): Just make a delwrite that is big enough to hold several samples and read from that. A delwrite with, say, 10 msec should cover most uses of a z~ clone. z~ with delays of more than a handful of samples normally aren't used as these tend to become more like "real" delays, not like the filter-equation delays z~ was written for.
Ciao
Frank Barknecht
On Fri, 2008-04-25 at 16:08 +0100, Andy Farnell wrote:
I've attached again an example of a patch that demonstrates the practical difference between different one sample differentiators.
Try replacing [fexpr~ $x1 - $x1[-1]] in the water flow generator with
/
| [z~] | | [-~] |which is fine.
Then try implementing the same with [rzero~ 1]
It sounds very different
because [rzero~] is _not_ the same as [z~ 1] (see previous posts, 'previouser' posts claiming both to be the same, are wrong). there are several ways to achieve one-sample-delays. however, they need to be implemented correctly, of course. if they are, they also lead to identical results.
i hope, i am not doing a mistake as well, but considering IOhannes' last post, it seems to me that:
/
| [z~]
| |
[-~]
|
which is:
y[n] = x[n] - x[n-1]
is the same as:
[rzero~ 1] (according to the formula in the help-file)
so.. replace the whole thing by [rzero~ 1] and you don't need an external here.
regarding the book: why not making a set of abstractions with meaningful names for the missing standard operators and classes like [z~]? (yo, some people suggested that already) it would be educational and it also wouldn't suggest, that puredata is clean, consistent and complete, but it would show, that some effort is required in order to make it consistent and complete for one-self. i think, that would be just frank. it's a project in progress.
i believe, that starting with abstractions based on vanilla would be a good idea, even if they are not optimized or require a lot of objects. once they can be replaced by built-in classes, you still could change the abstractions so that they can be used as wrappers, in case the new classes don't have the same name as your initial abstractions. i think, going that way, you can make sure, that the examples from the book will work also in the future, when everything what we miss right now, will be there. i think, this would be the better way instead of adding some dependencies to the book examples, that will be obsolete in the future (or even worse, get replaced by built-in classes with same names, but different behaviour).
probably, your book is going to be the killer reason, why those object classes need to be part of vanilla (yeah, i am dreaming ;-) ).
frank already started a set. if still stuff is missing, i'd be glad to help as far as i am able to.
roman
and I have not found a way to correct the accumulating DC error. Try the obvious [rzero~ 0.99999999] etc to hear that the behaviour is still not right.
Fundamentally, [z~] is a *very* useful primitive to have
On Fri, 25 Apr 2008 07:04:10 -0400 Enrique Erne enrique@netpd.org wrote:
IOhannes m zmölnig wrote:
Enrique Erne wrote:
IOhannes m zmölnig wrote:
Enrique Erne wrote:
or [biquad~ 0 0 0 1]
Miller Puckette wrote: > I believe z~ is just rzero~ 0.
no. both of them are equivalent to [z~ 1]
you could also argue that [f] is just the same as [0( :-)
oups, yes ofcorse z~ 1.
the output of 1 sample with rzero~ 0, z~ 1 and biquad~ 0 0 0 1 seems to be slightly different. if one wants to be fuzzy about that :) maybe ome rounding problem?
no, i don't see any rounding errors...
and now i even couldn't do the delwrite/read with the subpatch :( :(
it's generally a good idea to tell [delwrite~] how much space it should allocate for the delayline. e.g. [delwrite~ abcd 1000] helped a lot...
and [rzero~ 0] is not the same as [z~ 1].
the output of [z~ 1] is y[n]=x[n-1] according to [rzero~]s help-patch it does the following:
y[n]=x[n]-a[n]*x[n-1] since you set a[n] to "0", you just get y[n]=x[n] :-(
to get [z~ 1], do something like
| +--+ | | | [rzero~ 1] | | [-~] |
thanks iohannes. it looks good now.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Andy Farnell -
Enrique Erne -
Frank Barknecht -
IOhannes m zmölnig -
Matt Barber -
Miller Puckette -
Roman Haefeli -
Steffen Juul