[PD] Fwd: [coll] bug

[Ivica Bukvic]

I am perfectly fine with that because I don't mind updating all my patches
to adapt them to this change. You will, however, find other users who won't
like this because they will need to update their patches, even though it
may be a matter of running a simple shell script.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Feb 1, 2017 11:37, "Alexandre Torres Porres" <porres at gmail.com> 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,


2017-01-30 17:42 GMT-02:00 Roman Haefeli <reduzent at gmail.com>:

> Sounds like Max' [coll] is threaded


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170201/574bd85f/attachment.html>