one of my messages didnt go to the list, it was too big...
let me adaot and resend it
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).
See, always confusing to me when determinacy is mentioned... that's not how it happens in Max if I understand it... In Max it takes a while (until the file read is ready) for the outlet to send a bang, it doesn;t go out "immediately" as in the unthreaded version in cyclone, where it causes audio drop outs
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 300k 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
I was also sending the file attached, but that's why my message got rejected...
Best,
Ico
Cheers
On Mon, 2017-01-30 at 15:20 -0200, Alexandre Torres Porres wrote:
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 300k 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%
Sounds like Max' [coll] is threaded, otherwise taking 500ms for a task without interrupting audio at this low latency setting would be a contradiction.
Roman
On 01/30/2017 08:42 PM, Roman Haefeli wrote:
On Mon, 2017-01-30 at 15:20 -0200, Alexandre Torres Porres wrote:
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 300k 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%
Sounds like Max' [coll] is threaded, otherwise taking 500ms for a task without interrupting audio at this low latency setting would be a contradiction.
well, it could do piecewise processing: just read a few lines per DSP tick. if systemcalls are involved, it's hard to predict the behaviour though. (e.g. rather than giving a single dropout, it could as well create multiple dropouts).
gmsadr IOhannes
On Mon, 2017-01-30 at 21:10 +0100, IOhannes m zmölnig wrote:
On 01/30/2017 08:42 PM, Roman Haefeli wrote:
On Mon, 2017-01-30 at 15:20 -0200, Alexandre Torres Porres wrote:
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 300k 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%
Sounds like Max' [coll] is threaded, otherwise taking 500ms for a task without interrupting audio at this low latency setting would be a contradiction.
well, it could do piecewise processing: just read a few lines per DSP tick. if systemcalls are involved, it's hard to predict the behaviour though. (e.g. rather than giving a single dropout, it could as well create multiple dropouts).
Right. Either way - and probably more important - it seems when using [coll] in Max, determinacy is lost, which was the main point people argued about.
Roman
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,
2017-01-30 17:42 GMT-02:00 Roman Haefeli reduzent@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
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,
-
Alexandre Torres Porres -
IOhannes m zmölnig -
Ivica Bukvic -
Roman Haefeli