[PD] [coll] bug

Ivica Ico Bukvic ico at vt.edu
Mon Jan 30 05:25:21 CET 2017


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 at vt.edu 
> <mailto:ico at 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 at vt.edu
>>     <mailto:ico at 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170129/96b09c97/attachment.html>


More information about the Pd-list mailing list