On 1/29/2017 10:24 PM, Alexandre Torres Porres wrote:
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.
In essence, yes. However, not everyone uses low power computers and it is possible that even on midsize machines, such dropouts will be unlikely.

 
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.

Yes, but this could break traditional patches that rely on operations that need  to take place in a sequence within the same interrupt. I say this being fully aware how ironic this statement may be coming from me given pd-l2ork's mantra is if something is broken, we'll fix it and then you need to fix your patches, even though this has yet to cause any irreversible breakage when compared to vanilla in part because pd-l2ork now has the -legacy flag that enables prevalent legacy (mis)behavior used in historic patches. Back on topic, since you have no way of predicting when the bang will come back (which is the time it takes to load the time + clock_delay(0)), you have no way of initiating other operations that rely on coll's output because you don't know the file has loaded. This is not an issue with Max.

So, in essence, I agree with you but am also trying to make sure that this does not cause major backwards compatibility breakage. Hence my optional argument that can be named whatever you wish to name it thereby reserving a keyword (e.g. @threaded 1, akin to Max's Jitter attributes, to minimize clashes with file names and other Max idiosyncrasies).

Best,

Ico


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