Lots of thoughts here, but little time. Here are the salient points to me:
- 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