<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">There's always a worst-case scenario for a system call blocking on loading even a small file that would involve dropouts. Nothing is guaranteed when you read from disk.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 7:14 PM, Derek Kwan <span dir="ltr"><<a href="mailto:derek.x.kwan@gmail.com" target="_blank">derek.x.kwan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Lots of thoughts here, but little time. Here are the salient points to me:<br>
><br>
> 1. The best analogy to this in Pd is [soundfiler]. [soundfiler] stops the<br>
> world in order to load the file, which routinely causes dropouts. This is a<br>
> constant source of disappointment and frustration to students especially if<br>
> they're coming from Max. But the point here is that [soundfiler] is a<br>
> control object, and Pd guarantees deterministic behavior for control<br>
> objects.<br>
<br>
</span>Hello,<br>
<br>
After a few days away from it and coming back to discuss the issue, I<br>
think threaded as the default makes sense GRANTED that it is well<br>
documented and there's an included explanation of why this differs from<br>
normal Pd usage. I wouldn't want users new to Pd expect all of Pd to<br>
work the way [coll] does as a default then getting confused as to why it<br>
isn't (also it looks like I accidentally left a post() in there from<br>
debugging but that's a different matter).<br>
<br>
I would even post something to the Pd window if the object is threaded<br>
or not. I could seriously imagine if I had more patches depending on<br>
[coll] and determinism and if I were in a crunch, going absolutely crazy<br>
and frustrated as to why my patch broke. If the patch broke becaue of<br>
order, that can be quite subtle and if i'm familiar with an object, my<br>
instincts wouldn't say "hey let's go to the help file", esp if it's a<br>
wall of text. I know Max doesn't tell you in the Max window if it's<br>
threaded but this is Pd land here. So I would strongly side with well,<br>
first getting rid of my stupid debugging post that shouldn't be there,<br>
and putting in a post that says we're using threaded.<br>
<br>
More on this, I think should be clear documentation outside of running<br>
Pd, maybe even in the main README, even if it's a short blurb expanded<br>
upon somewhere else, how this library in general differs from normal Pd<br>
land.<br>
<br>
Anyways, the decision is a bit easier with large text files that would<br>
cause dropouts. Unthreaded would be unlikely to be used when you have live<br>
audio going on because of the dropouts unless you're making the dropouts<br>
part of your piece which I suppose could be pretty interesting but not a<br>
likely use case.<br>
<br>
The issue is with the rest of the cases and I'm a little more torn<br>
there. The fix is pretty clear although a pain in the butt. If your read<br>
is in the middle of a trigger, then anything to the left of it depending<br>
on the read happening first would get all kablunked. Then the fix would<br>
be to have that read bang coming out from [coll] be in charge of<br>
triggering that kablunked stuff in the proper order and this could be a<br>
lot of rewiring... I suppose since we're going wtih a most Max-like<br>
experience as possible, it would be confusing if one object wasn't as<br>
Max-like as the others. Anyways, that's my two cents for now.<br>
<span class="HOEnZb"><font color="#888888"><br>
Derek<br>
</font></span></blockquote></div><br></div>