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.