[PD] [coll] bug

IOhannes m zmoelnig zmoelnig at iem.at
Thu Feb 2 11:06:54 CET 2017


On 2017-02-02 01:14, Derek Kwan wrote:
> After a few days away from it and coming back to discuss the issue, I
> think threaded as the default makes sense GRANTED that it is well
> documented and there's an included explanation of why this differs from
> normal Pd usage. I wouldn't want users new to Pd expect all of Pd to
> work the way [coll] does as a default then getting confused as to why it
> isn't (also it looks like I accidentally left a post() in there from
> debugging but that's a different matter).

i don't think a threaded version of [coll] is so out-of-the ordinary
that it will confuse people out of their minds.
there are a number of objects that do not strictly adhere to the
depth-first paradigm, and thus break [t b b b] scheduling.
the most prominent is probably [delay]¹.

even though [delay] behaves as it does, i don't think that most will
expect Pd to behave like [delay].
(actually, a lot of new users need to get onto terms with the
depth-first principle; but once they have figured it out, they can
distinguish between the ordinary behaviour and an exception).

also, most new users probably will not start with [coll], and model
their understanding of Pd on that object.

oh, and of course the term "deterministic" can be stretched quite far.
even a non-threaded [coll] is not very deterministic: it can cause
variable length audio glitches when loading files (even with the same
file)...


fgaserd
IOhannes


¹ that's just a built-in example; other objects that do not promise to
have all their work done once their left-most inlet ist "done" include
e.g. most (all?) objects from the iemtab library, which use a
"done"-bang to signal when they have finished - even though they are not
threaded.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170202/81ca6ebc/attachment.sig>


More information about the Pd-list mailing list