[PD] Looking for some advice

[Mike McGonagle]

I've recently learned that Pd extended is pretty much no longer being
"extended", and as such, I'd like to learn how to compile Pd Vanilla along
with the few externals I need. I'm currently using Mac OS X 10.6.8 and have
tried using the standard "autogen/configure/make", but it seems to stop
when trying to link things up. I noticed that the makefile is set up to
target 10.8 by the autogen, what can I do to change it for my system?

Any suggestions for learning this would be greatly appreciated.

Mike
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] mailing list digest question

[Philip Stone]

Well, if a feature exists, it ought to be implemented logically. If digest mode 
is such a problem, maybe it shouldn’t be an option. But if it does, it should 
probably work better.



> On Sep 11, 2015, at 9:19 PM, Max  wrote:
> 
> IMHO the digest mode creates more issues then it solves. Because digest
> subscribers have it harder to actually reply to the right thread. That
> messes up the discussions.
> 
> A better solution to fix the cluttered inbox problem it to a) use a
> dedicated email account for lists, or/and b) use message filters in your
> mail client to move list mails to their own folder, so they don't bother
> you in your general inbox at all.
> 
> Or you could unsubscribe altogether and just look in the forums.
> 
> m
> 
> On 2015년 09월 12일 05:09, Philip Stone wrote:
>> Having recently switched to digest version of this list to help manage my 
>> daily email barrage, I’m noticing, quite often, that digests consist of only 
>> one or two messages, and come frequently throughout the day. It’s really not 
>> much less distraction than receiving un-digested list traffic. Is there any 
>> way to adjust this behavior?
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> http://lists.puredata.info/listinfo/pd-list
>> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] unexpected [array max] and [array min] behavior

[Matt Barber]

Thanks again. Can you confirm that a range with onset greater than n-1
should be empty, and not a range with just the (n-1) item? I'm building
some abstractions with these, and I want range behavior to be consistent
with those in the [array] objects.

Thanks!

M

On Fri, Sep 11, 2015 at 7:50 PM, Miller Puckette  wrote:

> I think it's correct to output negative infinity as the maximum value of
> the
> empty set, since if A is a subset of B, max(A) <= max(B), so the max of the
> empty set should be less than any number.  Hovever, using "1e30" for
> infinity
> is stupid and arbitrary - I do that sort of thing only because it's so
> poisonous in a real-time context when actual "inf" values start getting
> around
> the objects...
>
> The second thing you brought up is a mistake.  OTOH on revisiting this, I
> think the empty set should result in an output of (the impossible) -1 so
> that it can be easily checked for using select.  Also using "firstitem"
> would give a bad result if used on an array of structs with more than one
> member - so a but more surgery is needed here...
>
> more soon, off to a party to welcome the excellent Natacha Diels to our
> department :)
>
> M
>
> On Fri, Sep 11, 2015 at 04:14:47PM -0400, Matt Barber wrote:
> > Thanks for the fix in 0.46.7. There are a couple more subtle problems
> > having to do with bounds checking (one of which may be there by design).
> > Bounds checking occurs in the function array_rangeop_getrange() starting
> > line 536:
> >
> > firstitem = x->x_onset;
> > if (firstitem < 0)
> > firstitem = 0;
> > else if (firstitem > a->a_n)
> > firstitem = a->a_n;
> > if (x->x_n < 0)
> > nitem = a->a_n - firstitem;
> > else
> > {
> > nitem = x->x_n;
> > if (nitem + firstitem > a->a_n)
> > nitem = a->a_n - firstitem;
> > }
> >
> >
> > So unlike tabread which clips indices from 0 to n-1, this clips the onset
> > from 0 to n, which means an onset greater than (n-1) gets a range with 0
> > items. I think this might be by design, but I wanted to check because a
> > range with 0 items does something funny in the min/max array objects.
> >
> > So first off, in these lines (starting line 746):
> >
> > for (i = 0, besti = 0, bestf= -1e30, itemp = firstitem;
> > i < nitem; i++, itemp += stride)
> > if (*(t_float *)itemp > bestf)
> > bestf = *(t_float *)itemp, besti = i;
> >
> > If the input range has 0 items (i.e. if nitems is set to zero manually,
> or
> > if the onset is greater than n-1), the for-loop condition i < nitem is
> > never true, so the value output is going to be the bestf init value -1e30
> > (likewise with +1e30 in the min function). Since this a value that
> doesn't
> > point to anything in the array, I wonder if it would be better not to
> > output anything (or maybe a bang) in those cases.
> >
> >
> > Second, the value x->x_rangeop.x_onset is not bounds checked, so when you
> > do this (line 750):
> >
> > outlet_float(x->x_out2, besti + x->x_rangeop.x_onset);
> >
> >
> > if x_rangeop.x_onset iss out of range, you're going to output an
> erroneous
> > index value, which could be negative or greater than n. firstitem is
> > bounds-checked from the onset by array_rangeop_getrange() -- would it be
> > possible to use that instead?
> >
> >
> > This suite is really a wonderful addition to Pd, and adds so much new
> > functionality to vanilla.
> > Many cheers!
> >
> > Matt
> >
> >
> > On Fri, Sep 4, 2015 at 8:11 PM, Miller Puckette  wrote:
> >
> > > Yep :)
> > >
> > > M
> > >
> > > On Fri, Sep 04, 2015 at 07:46:30PM -0400, Matt Barber wrote:
> > > > Thanks.
> > > >
> > > > I meant to say that there was the same problem in [array min], but
> you
> > > > probably caught it in your fix.
> > > >
> > > > Best,
> > > >
> > > > Matt
> > > >
> > > > On Fri, Sep 4, 2015 at 7:19 PM, Miller Puckette 
> wrote:
> > > >
> > > > > Yep... thanks.  Fixed in git - may take some time for me to get
> out a
> > > new
> > > > > compiled version (other stuff to fix too :)
> > > > >
> > > > > M
> > > > >
> > > > >
> > > > > On Fri, Sep 04, 2015 at 05:51:15PM -0400, Matt Barber wrote:
> > > > > > Hi list,
> > > > > >
> > > > > > I've been playing around with the new(ish) [array] object suite
> in
> > > > > vanilla
> > > > > > 0.46.6. Forgive me if this is already a known issue, but it looks
> > > like
> > > > > the
> > > > > > min and max arguments aren't working properly.
> > > > > >
> > > > > > The second inlet (setting the number of points to search) works
> as
> > > > > > expected. The first inlet doesn't update: it seems to be set to
> 0 no
> > > > > matter
> > > > > > what (although the index outlet is updated, but not as expected).
> > > > > >
> > > > > > I think I see the problem in x_array.c
> > > > > >
> > > > > > The max object is defined line 723:
> > > > > >
> > > > > > typedef struct _array_max
> > > > > > {
> > > 

Re: [PD] weird behavior of [vd~] in phave vocoder (overlapping subpatches)

[Alexandre Torres Porres]

> But [vd~] itself does nothing regarding to overlap and that's
> very important to understand. It just behaves like [tabread4~].

I still like considering vd~ special, but I totally see and understand what
you mean ;)

> I think this is just an issue of proper documentation!

Agreed, we should ask miller to document this somewhere ;)

Have you tried listening to the difference by listening to the delay lines?

I was testing something about these delays and I'm actually getting some
parallel issues, I might and should open a new thread to discuss them.

One last thing from the original post,. We've sorted the delay times and
everything, but I was also asking why we have to multiply for the interval
ratio to get the hop difference between the two windows in the phase
vocoder.

In fact, I actually know why, and the question needs to be rephrased. The
proper question would have been why it DOESN'T have to multiply by the
ratio in the other patch that wasn't a phase vocoder (if you go back to my
very first attachment you'll see I had two patches and I was comparing
them, this was one of the issues).

And you "didn't have to" multiply it because it was working fine... But the
truth is that it works better if you multiply it by the ratio, and it just
can go unnoticed because it's not a phase vocoder, so it doesn't ruin
things as is the case with the phase vocoder.

Isn't it great to have it all sorted?

Thanks for your great help

ps. I noticed your last reply was off the list, so I got us back to settle
and close the thread.



2015-09-12 6:23 GMT-03:00 Christof Ressi :

> > But the point is, [tabread4~] won't automatically do anything, unlike
> [vd~]. At least that is how I see it.
>
> Hmmm... maybe you might have to go back to my explanation of point 1) and
> see how the overlapping only works fine all the time because the state of
> the delay line outside the subpatches happens to change synchroniously with
> the time the input buffer is taken for one of the overlapping windows.
> Window2 will get the input buffer one hope size time later than window1,
> and in that same time the delay line itself has moved for the same amount
> of samples. So after overlapping again at the output, everything is fine
> again. But [vd~] itself does nothing regarding to overlap and that's very
> important to understand. It just behaves like [tabread4~].
>
> You're last patch shows that you fully understand how oscillators and
> ramps work in overlapping subpatches. I've attached a patch where you can
> have a look how a delay line actually looks like inside such a subpatch.
> You can also see that a samplewise delay like [z~] (or [delay~]) is
> equivalent to a sorted pair of [delwrite~] and [delread~] and acts the same
> way. I've exchanged [vd~] for [delread~] to get rid of the problem with
> index 0.
>
>
> > or, in the meantime, can you explain why using a delay~ line is
> different as you understand it? I mean, what problems does it generate and
> all?
>
> So you from checking my patch you can see that they actually behave the
> same way! In the case of my [cpitchshift~] patch, the difference arises
> from the fact, that the [vd~] acts on a delay line outside the subpatch
> where [z~] is a delay line which is fully located inside the subpatch. Note
> that the delay time in samples is 1/4 window size, so it's 1 hop size and
> doesn't create discontiuities. It is just a lazy way to guarantee that the
> back window is 1 hop size behind :-). The problem only is: When you change
> the pitch at a certain point of time, the buffer of [z~] has been filled at
> a time where that pitch change has not occured yet. But after one window
> calculation it's fine again (unless you've again changed the pitch and so
> on...).
>
>
> > But then, I kinda think this is a bug! Not only a [vd~] bug, but also
> [vline~] and [phasor~] / [osc~] (regarding frequency).
>
> Well, the oversampling is happening, if you want it or not :-). And I
> think 1 second always should have as many samples as the sampling rate. I
> guess most of the misunderstandings come from the fact that the
> oversampling itself is not documented properly... and that [samplerate~]
> behaves unlogically!
> The phase correction for oscillators and ramps could be done internally in
> the objects, but then this might lead to other weird behaviour instead so
> it's kind of a trade off. Again, I think this is just an issue of proper
> documentation!
>
> Cheers
>
>
> *Gesendet:* Freitag, 11. September 2015 um 20:55 Uhr
> *Von:* "Alexandre Torres Porres" 
> *An:* "Christof Ressi" 
> *Cc:* Pd-List 
> *Betreff:* Re: Re: Re: Re: Re: [PD] weird behavior of [vd~] in phave
> vocoder (overlapping subpatches)
> "*So when you send 1000 ms to a [vd~] in a subpatch with overlap 4, the
> delay line will be read at sample 176400 (supposing the [delwrite~] is in a
> subpatch with sample rate 44100). This is not an 

Re: [PD] A patch to create a patch to create a patch to create a patch to close puredata...

[Matt Barber]

I don't think so, unless someone else presented them. I've never been able
to afford the time or money to get to a PdConv. Also I didn't think many
people would find them that interesting until now. :)

Nice work yourself.

M

On Sat, Sep 12, 2015 at 8:04 PM, Olivier Baudu <01iv...@labomedia.net>
wrote:

> Masterpieces !! :-D
>
> Are those patchs the ones Benjamin was talking about few answers before ?
> (He saw them at the PdConv in Montreal)
>
> I take this opportunity to post my last work :
>
> https://vimeo.com/139090261
>
> Cheers
>
> °1
>
>
> Le 12/09/2015 07:13, Matt Barber a écrit :
> > Jonathan Wilkes and I made these a few years ago. Run "orthodox" first
> > to get a feel for it.
> >
> > On Mon, Sep 7, 2015 at 9:57 AM, Olivier Baudu <01iv...@labomedia.net
> > > wrote:
> >
> > Youplala...
> >
> > https://vimeo.com/138517416
> >
> > Cheers
> >
> > °1
> >
> > Le 20/08/2015 01:20, Olivier Baudu a écrit :
> > > One more useless stuff for you, list :
> > >
> > > https://vimeo.com/136762246
> > >
> > > Cheers
> > >
> > > °1
> > >
> > > Le 11/08/2015 23:48, Olivier Baudu a écrit :
> > >> Hi list,
> > >>
> > >> Did you think I'd forgotten you ? :-p
> > >>
> > >> It follows :
> > >>
> > >> https://vimeo.com/136014798
> > >>
> > >> Cheers...
> > >>
> > >> °1
> > >>
> > >> Le 17/07/2015 13:41, i go bananas a écrit :
> > >>> these are awesome.
> > >>>
> > >>> On Fri, Jul 17, 2015 at 8:23 PM, Benjamin ~ b01  
> > >>> >> wrote:
> > >>>
> > >>> nice piece of digital art ;)
> > >>>
> > >>> btw, does someone on the list have an old patch that was
> producing a
> > >>> nice gui animation inside Pd ?
> > >>> I saw it a long ago @ Pd Conv Montreal ...
> > >>>
> > >>> thanks
> > >>> ++
> > >>> benjamin
> > >>>
> > >>> Le 15/07/2015 01:30, Olivier Baudu a écrit :
> > >>> > Sorry list...
> > >>> >
> > >>> > I can't refrain myself... :-p
> > >>> >
> > >>> > The Bangarland :
> > >>> > https://vimeo.com/133499700
> > >>> >
> > >>> > Cheers...
> > >>> >
> > >>> > 01
> > >>> >
> > >>> > Le 06/07/2015 22:04, Jaime E Oliver a écrit :
> > >>> >> nice indeed!
> > >>> >> J
> > >>> >> On Jul 6, 2015, at 2:10 PM, Jack   > >> wrote:
> > >>> >>
> > >>> >> Hello Olivier,
> > >>> >>
> > >>> >> Very nice ;)
> > >>> >> ++
> > >>> >>
> > >>> >> Jack
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >> Le 06/07/2015 20:46, Olivier Baudu a écrit :
> > >>> > Thank you Julian...
> > >>> >
> > >>> > Well, I don't know if this one is funny but, for sure,
> it's still
> > >>> > useless... :-)
> > >>> >
> > >>> > The Carouslide: https://vimeo.com/132739686
> > >>> >
> > >>> > :-p
> > >>> >
> > >>> > 01
> > >>> >
> > >>> > Le 01/07/2015 15:02, Julian Brooks a écrit :
> > >>> >> definitely raised a smile :)
> > >>> >>
> > >>> >> 2015-06-30 17:15 GMT+01:00 Olivier Baudu <
> 01iv...@labomedia.net 
> > >
> > >>> >> 
> >  > >>> >>
> > >>> >> Hi list...
> > >>> >>
> > >>> >> I got bored again... so...
> > >>> >>
> > >>> >> https://vimeo.com/132195870
> > >>> >>
> > >>> >> :-p
> > >>> >>
> > >>> >> Cheers...
> > >>> >>
> > >>> >> °1
> > >>> >>
> > >>> >> Le 24/06/2015 17:34, Olivier Baudu a écrit :
> > >>> >>> Hi list...
> > >>> >>>
> > >>> >>> I had time to waste so here you are :
> > >>> >>>
> > >>> >>> https://vimeo.com/131648084
> > >>> >>>
> > >>> >>> :-p
> > >>> >>>
> > >>> >>> Cheers...
> > >>> >>>
> > >>> >>> °1ivier
> > >>> >>>
> > >>> >>>
> > >>> >>>
> > >>> >>> ___
> > >>> >>> Pd-list@lists.iem.at 
> > >
> > >>> 

Re: [PD] [PD-dev] Looking for some advice

[Miller Puckette]

How I do it:

unarchive any recent version of Pd
overwrite the source with whatever version you want (for instance, you
can clone the git repo) into Pd-xxx/Contents/Resources
cd to Pd-xxx/Contents/Resources/src and hit "JACK=true make -f makefile.mac"

(or if you want 64-bit-ness:)  
  JACK=true make -f makefile.mac "ARCH=-arch x86_64" "EXTRAARCH=-arch x86_64"

cheers
Miller

On Sat, Sep 12, 2015 at 07:19:40PM -0500, Mike McGonagle wrote:
> I've recently learned that Pd extended is pretty much no longer being
> "extended", and as such, I'd like to learn how to compile Pd Vanilla along
> with the few externals I need. I'm currently using Mac OS X 10.6.8 and have
> tried using the standard "autogen/configure/make", but it seems to stop
> when trying to link things up. I noticed that the makefile is set up to
> target 10.8 by the autogen, what can I do to change it for my system?
> 
> Any suggestions for learning this would be greatly appreciated.
> 
> Mike

> ___
> Pd-dev mailing list
> pd-...@lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] unexpected [array max] and [array min] behavior

[Miller Puckette]

Yep, that sounds like the correct way to interpret it.

I've attempted a fix, now up on git repo.

Thanks again for flagging this

M

On Sat, Sep 12, 2015 at 08:18:31PM -0400, Matt Barber wrote:
> Thanks again. Can you confirm that a range with onset greater than n-1
> should be empty, and not a range with just the (n-1) item? I'm building
> some abstractions with these, and I want range behavior to be consistent
> with those in the [array] objects.
> 
> Thanks!
> 
> M
> 
> On Fri, Sep 11, 2015 at 7:50 PM, Miller Puckette  wrote:
> 
> > I think it's correct to output negative infinity as the maximum value of
> > the
> > empty set, since if A is a subset of B, max(A) <= max(B), so the max of the
> > empty set should be less than any number.  Hovever, using "1e30" for
> > infinity
> > is stupid and arbitrary - I do that sort of thing only because it's so
> > poisonous in a real-time context when actual "inf" values start getting
> > around
> > the objects...
> >
> > The second thing you brought up is a mistake.  OTOH on revisiting this, I
> > think the empty set should result in an output of (the impossible) -1 so
> > that it can be easily checked for using select.  Also using "firstitem"
> > would give a bad result if used on an array of structs with more than one
> > member - so a but more surgery is needed here...
> >
> > more soon, off to a party to welcome the excellent Natacha Diels to our
> > department :)
> >
> > M
> >
> > On Fri, Sep 11, 2015 at 04:14:47PM -0400, Matt Barber wrote:
> > > Thanks for the fix in 0.46.7. There are a couple more subtle problems
> > > having to do with bounds checking (one of which may be there by design).
> > > Bounds checking occurs in the function array_rangeop_getrange() starting
> > > line 536:
> > >
> > > firstitem = x->x_onset;
> > > if (firstitem < 0)
> > > firstitem = 0;
> > > else if (firstitem > a->a_n)
> > > firstitem = a->a_n;
> > > if (x->x_n < 0)
> > > nitem = a->a_n - firstitem;
> > > else
> > > {
> > > nitem = x->x_n;
> > > if (nitem + firstitem > a->a_n)
> > > nitem = a->a_n - firstitem;
> > > }
> > >
> > >
> > > So unlike tabread which clips indices from 0 to n-1, this clips the onset
> > > from 0 to n, which means an onset greater than (n-1) gets a range with 0
> > > items. I think this might be by design, but I wanted to check because a
> > > range with 0 items does something funny in the min/max array objects.
> > >
> > > So first off, in these lines (starting line 746):
> > >
> > > for (i = 0, besti = 0, bestf= -1e30, itemp = firstitem;
> > > i < nitem; i++, itemp += stride)
> > > if (*(t_float *)itemp > bestf)
> > > bestf = *(t_float *)itemp, besti = i;
> > >
> > > If the input range has 0 items (i.e. if nitems is set to zero manually,
> > or
> > > if the onset is greater than n-1), the for-loop condition i < nitem is
> > > never true, so the value output is going to be the bestf init value -1e30
> > > (likewise with +1e30 in the min function). Since this a value that
> > doesn't
> > > point to anything in the array, I wonder if it would be better not to
> > > output anything (or maybe a bang) in those cases.
> > >
> > >
> > > Second, the value x->x_rangeop.x_onset is not bounds checked, so when you
> > > do this (line 750):
> > >
> > > outlet_float(x->x_out2, besti + x->x_rangeop.x_onset);
> > >
> > >
> > > if x_rangeop.x_onset iss out of range, you're going to output an
> > erroneous
> > > index value, which could be negative or greater than n. firstitem is
> > > bounds-checked from the onset by array_rangeop_getrange() -- would it be
> > > possible to use that instead?
> > >
> > >
> > > This suite is really a wonderful addition to Pd, and adds so much new
> > > functionality to vanilla.
> > > Many cheers!
> > >
> > > Matt
> > >
> > >
> > > On Fri, Sep 4, 2015 at 8:11 PM, Miller Puckette  wrote:
> > >
> > > > Yep :)
> > > >
> > > > M
> > > >
> > > > On Fri, Sep 04, 2015 at 07:46:30PM -0400, Matt Barber wrote:
> > > > > Thanks.
> > > > >
> > > > > I meant to say that there was the same problem in [array min], but
> > you
> > > > > probably caught it in your fix.
> > > > >
> > > > > Best,
> > > > >
> > > > > Matt
> > > > >
> > > > > On Fri, Sep 4, 2015 at 7:19 PM, Miller Puckette 
> > wrote:
> > > > >
> > > > > > Yep... thanks.  Fixed in git - may take some time for me to get
> > out a
> > > > new
> > > > > > compiled version (other stuff to fix too :)
> > > > > >
> > > > > > M
> > > > > >
> > > > > >
> > > > > > On Fri, Sep 04, 2015 at 05:51:15PM -0400, Matt Barber wrote:
> > > > > > > Hi list,
> > > > > > >
> > > > > > > I've been playing around with the new(ish) [array] object suite
> > in
> > > > > > vanilla
> > > > > > > 0.46.6. Forgive me if this is already a known issue, but it looks
> > > > like
> > > > > > the
> > > > > > > min and max arguments aren't working properly.
> 

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

[Jonathan Wilkes via Pd-list]

Actually even for one's own patches, Pd is supposed to go into read-only mode 
when you depend on creation order for deterministic behavior.  That is-- it 
shouldn't let you save the patch after that.  But there's a long-standing 
unfixable bug that lets you do it anyway.
I make this joke with some sadness because data structure drawing commands 
depend on creation order for the drawings' z-order.  And I can't think of a 
better way to do it.  (One could use wires to chain them in order but that 
brings its own problems.)

-Jonathan 


 On Saturday, September 12, 2015 1:03 AM, Matt Barber  
wrote:
   

 Alexandre,
Looking at your original question, G05.execution.order says the following:
"If you're writing to and reading from a delay line, you have to get the write 
sorted before the read or else you'll never get less than a block's delay."
As the others have pointed out, there are basically two ways of "getting the 
write sorted before the read [in the DSP chain]":1) by accident, or in a way 
that can't be gleaned from looking at the patch in Pd (you'd have to take it 
into a text editor to see that the write was created before the read).2) on 
purpose, using subpatches, which is guaranteed both to work and to be inferred 
from the structure of the patch.
So it's not that the idiom on the left will ALWAYS be off by a block in every 
instance, but that it may or may not be depending on the unreadable 
contingencies of how the patch was created. You can rely on this for your own 
stuff, but if you wanted to send it to someone, they wouldn't be able to tell 
those contingencies by looking at the patch, so to that user, the behavior is 
"undefined" in the same way that failing to use a trigger makes message 
execution order "undefined." The behavior is deterministic under the hood, but 
your user can't be expected to look under the hood. The G05.execution.order is 
specifically tailored to show that it can be off by a block, but there's no way 
to know it just by looking; it's possible a better approach would have been to 
have shown another one that looked exactly the same but had the other behavior, 
and then finally the way to make it explicit using subpatches.

If you look at the first test patch you attached, you can tell a few things 
about execution precedence based on patch cords.1) [noise~] runs before 
[delwrite~], [pd delay-writer], [pd delay-reader], both [+~] objects, and the 
[output~] abstractions, because for each of those the [noise~] feeds into it or 
feeds into something that feeds into it.
2) [noise~] may or may not run before [vd~], and likewise [delwrite~] may run 
before or after [vd~]. If [delwrite~] runs after [vd~] (because it happened to 
have been created after), then setting [vd~]'s delay to 0 has it reading what 
[delwrite~] wrote on the previous block.
3) [pd delay-writer] is guaranteed to run before [pd delay-reader] because of 
the patch connection between them. If you severed that connection, and then cut 
and pasted [pd delay-reader], it would now run before [pd delay-writer], until 
you reconnected the cord. You can try this and hear it change when you 
reconnect and disconnect the connection.

There are some cases when you actually need a block delay, and you can specify 
that behavior in the same way.
Yes, send~/receive~ and throw~/catch~ can be off by a block as well, but you 
can force them to run in sync, again using subpatches (unless it creates a DSP 
loop).
Matt



On Tue, Aug 25, 2015 at 7:17 PM, Alexandre Torres Porres  
wrote:

Howdy, the "G05.execution.order" example in Pd shows us how delay lines will 
always delay at least a block of samples, unless you tweak it by using some 
subpatches and stuff.
Well, even though the example works as described, I was doing some tests and 
didn't get the same results. 
So it is weird that behaves like that in the example, but when I change the 
patch or make a new patch it just doesn't behave the same way. Meaning that it 
will not delay to at least a block in size, but less than that without doing 
the subpatches thing.
See my patch attached.
So what now, huh?
cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list