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@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@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