[PD] [coll] bug

[Alexandre Torres Porres]

But anyway, I also wonder if the threaded version shouldn't be the default
behaviour of cyclone's coll, because we always have the bang output to rely
on and tell us when it is done anyway. The whole purpose of its existence
and design choice seems to be that anyway... it only makes sense if it is
undetermined...

so I'm thinking that if one wants the pd related behaviour that you should
add it as a flag, say "threaded 0"

2017-01-28 16:16 GMT-02:00 Alexandre Torres Porres <porres at gmail.com>:

> 3k.txt should be 300k.txt, I increased the entries but didn't change the
> name :)
>
> 2017-01-28 16:15 GMT-02:00 Alexandre Torres Porres <porres at gmail.com>:
>
>> Tests in Max that stand out:
>>>
>>> Reading and writing coll files while sound is running does not cause
>>> xruns in Max, whereas in Pd it can depending on the size of the coll file
>>> and CPU utilization.
>>>
>>
>> yes, I've checked that too... Max never chokes on the audio processing.
>>
>>
>>> You are right in that determinacy is preserved in Max no matter what
>>> (e.g. read outlet bang outputs immediately after issuing the read message
>>> in logical time).
>>>
>> I'm not sure if I get what you mean by determinacy, but I have the test
>> patch attached, which I used in Purr Data.
>>
>> in the unthreaded version, I dont get a bang, but I get a warning, so
>> things are printed in this order (1, warning, 3). Warning should be the
>> same as 2, I assume, so it's the correct order... for threaded, I get (1,
>> 3, warning, 2).
>>
>> So, the order changes... and I think that is what you mean by breaking
>> determinancy, right?
>>
>> In max, if I do something similar, I always get the order of 1, 2, 3 with
>> trigger, and the audio doesn't choke.
>>
>> If I get things correctly, this would be impossible to happen in Pd,
>> right? So if you get the right order, you can also get audio chokes.
>>
>>
>>> Doing Uzi with 100k generated entries into coll object in Max and I get
>>> guaranteed crashes from these on both 6 and 7.
>>>
>>
>> well, I tested opening a file with 400k entries in Max 7 and got no audio
>> crash/choke... it loaded the file fine, taking a bit under 500ms and the
>> audio wasn't interrupted. I also had a block size of 1 and audio I/O of 32
>> samples, highest CPU consuming setting possible, it was around 13%
>>
>> see image attachment
>>
>>
>>> Best,
>>>
>>> Ico
>>>
>>>
>> Cheers
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170128/a35b9035/attachment-0001.html>