I have a problem, that is partly of my own making and need to air
this on the list for advice. This isn't a rant, just a frustrating situation.
As some of you know I have been working on a textbook for Pd for some time.
In the final stages and adding the practical exercises and the problem is thi
I'd say, you can't go wrong with fexpr~. Works for any kind of
discrete time difference equations & has many amazing /creative uses.
Chuck
On Thu, Mar 20, 2008 at 6:40 PM, Andy Farnell
<[EMAIL PROTECTED]> wrote:
>
> I have a problem, that is partly of my own making and need to air
> this on th
Thanks guys,
Marius and Charles, you've both suggested using [fexpr~] and
I think I might reconsider introducing this object.
So far the aim has been to keep the object set very small
and show how things are built from primitives, but all said
this makes a good example of where it can be a Swi
On Thu, 20 Mar 2008 19:18:21 -0500
"Mike McGonagle" <[EMAIL PROTECTED]> wrote:
> By the way, if you are looking for a Proof Reader, I would be more than
> happy to offer my services...
Mike, I'd certainly appreciate another set of eyes. Breaking up
the text into sections for those with particula
Hi Andy
If I'm doing it for myself, I run sig~ into rzero~ 1. But for visitors
I'd make a table, loadbang a 1 into the first element (send the
message 0 1) and use tabplay~ to get it as an audio signal.
cheers
M
On Fri, Mar 21, 2008 at 01:32:27AM +, Andy Farnell wrote:
>
>
> Thanks guys,
hello,
i think it's quite simple to emulate z~ with a simple delread~ / delwrite~.
cyrille
Andy Farnell a écrit :
> I have a problem, that is partly of my own making and need to air
> this on the list for advice. This isn't a rant, just a frustrating situation.
>
> As some of you know I have be
Andy Farnell a écrit :
Doesn't quite work. If you try it with 1/sr in place of [z~] in a patch that's
sensitive to it the results are wrong . Not sure why.
this is strange.
look at my exemple, it show that it should work. (1 signal is delayed with z~
and with delread/write; diference of both
On Thu, 2008-03-20 at 23:40 +, Andy Farnell wrote:
> You cannot obtain a single sample delay
> using [delwrite~] as far as I know, if you can it certainly means
> [samplerate~] must
> be added to all patches to make sure they run at different sr, which is mucho
> annoying.
yo.. it _is_ poss
Hallo,
Miller Puckette hat gesagt: // Miller Puckette wrote:
> If I'm doing it for myself, I run sig~ into rzero~ 1.
For all I know, [rzero~ 1] is the same as [delta~]: Both compute the
difference between the current and the previous sample. Or am I
missing something? Some time ago I added this t
> Andy Farnell a écrit :
>> Doesn't quite work. If you try it with 1/sr in place of [z~] in a
>> patch that's
>> sensitive to it the results are wrong . Not sure why.
oh, I did not even try to think about delwrite~/delread~, but of course
it is working (thanks cyrille...). I think your mistake w
I've put an example here so you can hear that they are not the same
These differences are important.
[rzero~] and [delwrite~] methods come out louder
and with apparently less dynamics. Using [z~] and [fexpr~]
I get much closer results to [delta~], more detail in
the poured water sound.
As I s
Hi,
Using the source:
pd/src/d_filter.c/sigrzero_perform()
t_sample next = *in1++;
t_sample coef = *in2++;
*out++ = next - coef * last;
last = next;
pure-data/externals/cxc/delta~.c/delta_perform()
float f = *(in++);
// *out++ = (f > 0 ? f : -
hmm,
first, i think you need [swap 1000] instead of [swap 1], because you
want to delay by 1000/44100 milliseconds and not 1/44100 milliseconds.
and then, there is this problem that delwrite~/delread~ is sensitive to
the order of creation. I attached a small patch, you can see that a
delwrite/r
Hallo,
Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
> Hi,
>
> Using the source:
>
> pd/src/d_filter.c/sigrzero_perform()
>
> t_sample next = *in1++;
> t_sample coef = *in2++;
> *out++ = next - coef * last;
> last = next;
>
>
> pure-data/exter
On Fri, 21 Mar 2008 18:38:19 -0400
marius schebella <[EMAIL PROTECTED]> wrote:
> want to delay by 1000/44100 milliseconds and not 1/44100 milliseconds.
Ah yes, sorry that's a typo as I rushed those examples together.
> and then, there is this problem that delwrite~/delread~ is sensitive to
> th
On Fri, 2008-03-21 at 18:38 -0400, marius schebella wrote:
> hmm,
> first, i think you need [swap 1000] instead of [swap 1], because you
> want to delay by 1000/44100 milliseconds and not 1/44100 milliseconds.
> and then, there is this problem that delwrite~/delread~ is sensitive to
> the order o
On Sat, 2008-03-22 at 13:34 +0100, Roman Haefeli wrote:
> On Fri, 2008-03-21 at 18:38 -0400, marius schebella wrote:
> > hmm,
> > first, i think you need [swap 1000] instead of [swap 1], because you
> > want to delay by 1000/44100 milliseconds and not 1/44100 milliseconds.
> > and then, there is
I have to say that the problem is not that the delread~ was created
after the delwrite~, but that the delwrite~ was created after the
line~... as soon as delwrite~ is created after line~ it already *writes*
(!) with a delay of one sampleblock. it might be true that delread is
working correctly
Hallo,
marius schebella hat gesagt: // marius schebella wrote:
> what happens if you create a feedback with subpatches, are we then
> back to "order of creation"??)
delwrite~/delread~ loops with feedback *always* have at least one block
delay. That's a general issue with block-based, realtime syn
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
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
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~
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
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 differenc
PROTECTED]>
> Subject: Re: [PD] I'm stuck in a corner, please help! RE: [delta~]
>object was: Re: Cyclone in vanilla?
> To: Enrique Erne <[EMAIL PROTECTED]>
> Cc: pd-list@iem.at
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1
* x[n] + x[n-1]
>
> setting the coefficient to 0 gets rid of the current input and leaves
> the one-sample delay.
>
> Thanks,
>
> Matt
>
>
>
> > Date: Fri, 25 Apr 2008 12:21:54 +0200
> > From: IOhannes m zm?lnig <[EMAIL PROTECTED]>
>
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~ c
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~]
> | |
>
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 performan
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
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
31 matches
Mail list logo
