[PD] [coll] bug

[Alexandre Torres Porres]

So, basically, the way [coll] was designed in cyclone caused signal drop
outs when reading large files, while in max that never happens. I don't see
the advantage or why you'd want [coll] to behave like that in Pd... and it
seems to go against the max design, which prevents that from happening.


> So, if you issued a bang to load a coll file that fans out into a trigger
> with two bangs (...) the second bang could potentially come out before the
> done reading bang.
>

So don't use a trigger to fan it out, use the bang that comes out of [coll].

[coll] has a 3rd outlet that sends a bang to say when it finished reading a
file. Its whole design purpose is just so you can do something after the
file read is done, so one should never really use a [trigger] in that way
because it offers another way (and a "safer" way) to deal with it.

Again, I don't see any advantage in having [coll] behaving as it was first
designed in cyclone. If you want that just so you can ensure a bang from a
trigger is sent out after [coll] read a file, that kind of assurance comes
at a cost of audio drop outs, and if it doesn't really cause drop outs in
the first place (since it is only a "potential" issue), it is not really
doing anything... as the same would occur n the threaded version! the
threaded version only really acts in the case of audio drop outs - and only
when reading large files (and not any other kind of operation).

On the other hand, the threaded version offers the advantage of no audio
drop outs, as it is in Max...  this happens with no compromise as you can
(and should) rely on the 3rd outlet bang if you want to schedule an action
for when it is done reading a file.

Looking at coll up to cyclone 0.1alpha57, it always had a 3rd outlet to
bang when file read is done, and it would always cause drop outs for large
files. I don't know how to consider how things are in cyclone 0.2, but one
could consider that the threaded option is gone...

For an update of cyclone, I'm really considering the so called threaded
version by default, as it offers a very relevant advantage of avoiding drop
outs. This change does have a compromise, but it is not a big compromise
and we can just document how it affects the object, and how one should
always rely on the 3rd outlet bang instead of a trigger... we can also
provide an option to go back to the old behavior, but I don't really think
anyone would really opt and care for that as it does have a serious drop
out issue.

cheers


2017-01-29 18:54 GMT-02:00 Ivica Ico Bukvic <ico at vt.edu>:

>
>
> On 1/29/2017 3:18 PM, Alexandre Torres Porres wrote:
>
> 2017-01-29 17:53 GMT-02:00 Ivica Ico Bukvic <ico at vt.edu>:
>
>> I also think unthreaded should be default to maintain determinacy in sync
>> with Max
>>
>
> hi, sorry, i dont think i get what you mean, can you elaborate on what
> "determinancy" is? I was asking about it in my earlier messages, I wasn't
> sure before and now I really don't I get what it's supposed to mean.
>
> cheers
>
>
>


> which breaks the order of execution but also ensures there are no dropped
> samples.
>

> HTH
>
> Best,
>
> Ico
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170130/11af3557/attachment-0001.html>