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,yep, it is threaded, so the idea it shouldn't be the default to be in sync with max is wrong, if the idea is to be in sinc with max, than threaded needs to be the default.it seems when using [coll] in Max, determinacy is lost, which was the main point people argued about.I think there's an issue here regarding a difference between Max and Pd. In Max, determinacy is actually usually lost, and people coming from the Max perspective is used to dealing with that.Another point is that the 3rd outlet of coll, which sends a bang, only exists because of this loss of determinacy, since you can only rely on its output to warn you that the file read is done. If Max were a determinant environment, then there wouldn't be the need of this outlet at all.Now, we're cloning this object, with its 3rd outlet and everything, and the library is supposed to be fully compliant with max, that all adds up to the case of making it default.See, I'm working on its documentation right now, and if threaded is not the default, this is kinda of what I'd have to say:- careful when using coll in the default settings, as it can cause drop outs for large files, unlike in max- coll in the default setting is determinant, which makes its 3rd outlet basically useless, going totally against its logic and purpose of existence, as its only function is to signal the end os the action in an indeterminant environment, as it is the case with max- the default setting of coll is here just for the case where one is using [trigger] to first send a read message into coll and send a bang or whatever next only after the file read is complete, instead of relying on the 3rd outlet of coll, which is how coll was built... so basically if one is going against it design.You see how confusing that is? Now, if threaded is the default and I'm to document it, all I have to do is say:- As in Max, this doesn't choke the audio and is indeterminant, so you need to rely on its 3rd outlet.Done...Even though it adds a lot of noise, my compromise would be to have a backwards compatibility flag (-unthreaded / "@threaded 0" or whatever), where I can make a separate subpatch to explain all the issues involved. I can then warn that it can cause audio chokes, and how it makes the 3rd outlet pointless, and how it is not compliant with max, and I guess it only serves, in the end, to warn and educate people to use this object correctly. I see much more advantage in fixing a patch that was incorrect than consciously choosing to set the object to behave in an unthreaded way, with many inconsistencies and an issue like potential drop outs.If this is being argued just because of the issue of backwards compatibility breakage, I'd like to point out that it is really far from being any major issue in that respect, there is only a tiny change, in respect to just one among dozens of features.It is much more related to a bug fix than anything else, and usually fixing bugs do change the behaviour, of course. Looks like more of a discussion related to "is it a bug or a feature"? Well, for me it is a bug, because this so called "feature" is relying on bad practice (not using the 3rd outlet, as you should), and if you rely on it in order for your patch work, well, maybe you should just fix your patch, instead of relying on a mistake.cheers