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 <i...@vt.edu
<mailto:i...@vt.edu>>:
On 1/29/2017 3:18 PM, Alexandre Torres Porres wrote:
2017-01-29 17:53 GMT-02:00 Ivica Ico Bukvic <i...@vt.edu
<mailto:i...@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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
