[PD] [coll] bug

[Matt Barber]

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.

On Wed, Feb 1, 2017 at 7:14 PM, Derek Kwan <derek.x.kwan at gmail.com> wrote:

> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170201/6695c4cf/attachment.html>