[PD] [coll] bug

[Matt Barber]

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.

2. Max users are used to there being no dropouts with [coll], which tells
me that it must not be deterministic in the fanout kind of way Ico
mentioned (unless Max has a very different message passing structure that
can process a message cascade over several dsp ticks in a deterministic
way).

3. So the question, as with all things cyclone, is whether it should be
more Pd-like or more Max-like. So far we've defaulted to more Max-like with
documentation, in order to support Max users who come over to Pd. In this
case I think more Max-like makes plenty of sense since there is the load
termination bang outlet, but I would want the deviation from Pd-like
control object behavior prominently documented (probably with a
compare/contrast with [soundfiler]). Then, for other Pd users, we need an
easy way to make it run in one DSP tick; all things considered I'd rather
have a custom attribute for that than a special argument. Might be a pain
for backwards compatibility, but I think less so than switching the inlets
of [pow~] was when it became clear it was necessary.

Matt


On Sun, Jan 29, 2017 at 11:43 PM, Alexandre Torres Porres <porres at gmail.com>
wrote:

> I had some concerns with pthreads and Windows compat but it looks like
>> those aren't issues (? I don't have much experience with Windows dev) so
>> I think I would be fine either way.
>>
>
> it's working in windows!
>
>
>
>>
>> > And is this threaded stuff only for multi threaded processors? How does
>> > this work on a single core rasbperry pi or something like that?
>> >
>>
>> It looks like threading works fine on single core
>
>
> cool
>
>
>> One issue that might be of concern is backwards compat with old versions
>> of Cyclone. Otherwise I'm fine with threaded as the default.
>
>
> I don't see an actual issue with that. It's more like "well, if you were
> using trigger, and then you were reading a large file (which would cause
> audio drop out anyway), you may have been using trigger instead of a bang
> from coll's 3rd outlet... and now things might change"... We can offer a
> flag for the old behaviour anyway, as it is common on Pd when such a
> revision takes place...
>
> You see, it just affects one operation: reading a file, and not all files,
> just *Large* files... and it affects it in a good way: Preventing Audio
> drop outs! As it happens in Max by the way...
>
> Nothing that a decent documentation explaining one should always rely on
> the 3rd outlet doesn't solve it.
>
> we must encourage the best practice for coll, which is relying on its 3rd
> outlet for bangs after reading a file... I don't see why offering the old
> behaviour by default is of any advantage, we'd be encouraging a bad
> practice, and sticking with a flawed design instead that causes audio drop
> outs...
>
> And let me point out that recent changes in the coll object, with the
> inclusion of the threaded version, did change the bahaviour of coll and
> compromised backwards compatibility, as the 3rd outlet bang was removed
> from the default (unthreaded) version. If backwards compatibility was such
> of a concern, that shouldn't have happened then.
>
> cheers
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170201/bf39bd29/attachment-0001.html>