> Lots of thoughts here, but little time. Here are the salient points to me:
>
> 1. The best analogy to this in Pd is [soundfiler]. [soundfiler] stops the
> world in order to load the file, which routinely causes dropouts. This is a
> constant source of disappointment and frustration to students especially if
> they're coming from Max. But the point here is that [soundfiler] is a
> control object, and Pd guarantees deterministic behavior for control
> objects.

Hello,

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 would even post something to the Pd window if the object is threaded
or not. I could seriously imagine if I had more patches depending on
[coll] and determinism and if I were in a crunch, going absolutely crazy
and frustrated as to why my patch broke. If the patch broke becaue of
order, that can be quite subtle and if i'm familiar with an object, my
instincts wouldn't say "hey let's go to the help file", esp if it's a
wall of text. I know Max doesn't tell you in the Max window if it's
threaded but this is Pd land here. So I would strongly side with well,
first getting rid of my stupid debugging post that shouldn't be there,
and putting in a post that says we're using threaded.

More on this, I think should be clear documentation outside of running
Pd, maybe even in the main README, even if it's a short blurb expanded
upon somewhere else, how this library in general differs from normal Pd
land.

Anyways, the decision is a bit easier with large text files that would
cause dropouts. Unthreaded would be unlikely to be used when you have live
audio going on because of the dropouts unless you're making the dropouts
part of your piece which I suppose could be pretty interesting but not a
likely use case.

The issue is with the rest of the cases and I'm a little more torn
there. The fix is pretty clear although a pain in the butt. If your read
is in the middle of a trigger, then anything to the left of it depending
on the read happening first would get all kablunked. Then the fix would
be to have that read bang coming out from [coll] be in charge of
triggering that kablunked stuff in the proper order and this could be a
lot of rewiring... I suppose since we're going wtih a most Max-like
experience as possible, it would be confusing if one object wasn't as
Max-like as the others. Anyways, that's my two cents for now.

Derek