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"

I don't think it should be threaded by default either. I think it came up earlier on the list that Windows machines were having issues with coll's threading? I remember reading somewhere that pthreads was unix only and there's a separate Windows way of doing threading, which isn't in coll quite yet.

I did add back the bang out the 3rd inlet on instantiation when a file argt is loaded. There was a clock x->x_clock that was only instantiated in the threaded version that I needed to use because the methods that load the file arg coll_bind -> collcommon_doread return before coll_new returns so the object exist yet so there's no outlet to bang to (at least that's what I think was going on...). I did this by adding a check in coll_bind, where msg is the thing returned by collcommon_doread:

if(msg->m_line > 0) clock_delay(x->x_clock);

but that may have been the thing that screwed up the correct order of things. In any case, I'll have to look at it more...

Derek

yeah, derek was talking about our current development, where we screwed up with the order of bangs in the unthreaded - but fixed now.

Derek, would you care to elaborate why you think unthreaded should be the default?

And is this threaded stuff only for multi threaded processors? How does this work on a single core rasbperry pi or something like that?

cheers

2017-01-29 6:32 GMT-02:00 Derek Kwan derek.x.kwan@gmail.com:

...

coll_bind, where msg is the thing returned by collcommon_doread:

if(msg->m_line > 0) clock_delay(x->x_clock);

but that may have been the thing that screwed up the correct order of things. In any case, I'll have to look at it more...

(apologies in advance for polluting the list with cyclone-dev stuff but for those following along)

Oh, nm, it was something collcommon_doread and I fixed the unthreaded order =)

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

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

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.

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.

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@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@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

On Jan 29, Alexandre Torres Porres wrote:

yeah, derek was talking about our current development, where we screwed up with the order of bangs in the unthreaded - but fixed now.

Derek, would you care to elaborate why you think unthreaded should be the default?

I had some concerns with pthreads and Windows compat but it looks like those aren't issues (? I don't have much experience with Windows dev) so I think I would be fine either way.

And is this threaded stuff only for multi threaded processors? How does this work on a single core rasbperry pi or something like that?

It looks like threading works fine on single core, at least according to my perusing Stack Overflow, it's just that running threads will be paused for other threads. (source: http://stackoverflow.com/questions/12997628/creating-threads-on-a-single-cor... ). So maybe something similar to unthreaded? And even then, only the Model As, first model Bs, 1st compute, and zero are single-core, all the rest are quad core.

One issue that might be of concern is backwards compat with old versions of Cyclone. Otherwise I'm fine with threaded as the default.

Derek

Lots of thoughts here, but little time. Here are the salient points to me:

1. The best analogy to this in Pd is [soundfiler]. [soundfiler] stops the

world in order to load the file, which routinely causes dropouts. This is a constant source of disappointment and frustration to students especially if they're coming from Max. But the point here is that [soundfiler] is a control object, and Pd guarantees deterministic behavior for control objects.

2. Max users are used to there being no dropouts with [coll], which tells

me that it must not be deterministic in the fanout kind of way Ico mentioned (unless Max has a very different message passing structure that can process a message cascade over several dsp ticks in a deterministic way).

3. So the question, as with all things cyclone, is whether it should be

more Pd-like or more Max-like. So far we've defaulted to more Max-like with documentation, in order to support Max users who come over to Pd. In this case I think more Max-like makes plenty of sense since there is the load termination bang outlet, but I would want the deviation from Pd-like control object behavior prominently documented (probably with a compare/contrast with [soundfiler]). Then, for other Pd users, we need an easy way to make it run in one DSP tick; all things considered I'd rather have a custom attribute for that than a special argument. Might be a pain for backwards compatibility, but I think less so than switching the inlets of [pow~] was when it became clear it was necessary.

Matt

On Sun, Jan 29, 2017 at 11:43 PM, Alexandre Torres Porres porres@gmail.com wrote:

I had some concerns with pthreads and Windows compat but it looks like

...

those aren't issues (? I don't have much experience with Windows dev) so I think I would be fine either way.

it's working in windows!

...

...

And is this threaded stuff only for multi threaded processors? How does this work on a single core rasbperry pi or something like that?

It looks like threading works fine on single core

cool

...

One issue that might be of concern is backwards compat with old versions of Cyclone. Otherwise I'm fine with threaded as the default.

I don't see an actual issue with that. It's more like "well, if you were using trigger, and then you were reading a large file (which would cause audio drop out anyway), you may have been using trigger instead of a bang from coll's 3rd outlet... and now things might change"... We can offer a flag for the old behaviour anyway, as it is common on Pd when such a revision takes place...

You see, it just affects one operation: reading a file, and not all files, just *Large* files... and it affects it in a good way: Preventing Audio drop outs! As it happens in Max by the way...

Nothing that a decent documentation explaining one should always rely on the 3rd outlet doesn't solve it.

we must encourage the best practice for coll, which is relying on its 3rd outlet for bangs after reading a file... I don't see why offering the old behaviour by default is of any advantage, we'd be encouraging a bad practice, and sticking with a flawed design instead that causes audio drop outs...

And let me point out that recent changes in the coll object, with the inclusion of the threaded version, did change the bahaviour of coll and compromised backwards compatibility, as the 3rd outlet bang was removed from the default (unthreaded) version. If backwards compatibility was such of a concern, that shouldn't have happened then.

cheers

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list

3. So the question, as with all things cyclone, is whether it should be more Pd-like or more Max-like.

Do we know if Ivica's implementation actually matches up with what Max is doing? -Jonathan

Lots of thoughts here, but little time. Here are the salient points to me:

1. The best analogy to this in Pd is [soundfiler]. [soundfiler] stops the

world in order to load the file, which routinely causes dropouts. This is a constant source of disappointment and frustration to students especially if they're coming from Max. But the point here is that [soundfiler] is a control object, and Pd guarantees deterministic behavior for control objects.

Hello,

After a few days away from it and coming back to discuss the issue, I think threaded as the default makes sense GRANTED that it is well documented and there's an included explanation of why this differs from normal Pd usage. I wouldn't want users new to Pd expect all of Pd to work the way [coll] does as a default then getting confused as to why it isn't (also it looks like I accidentally left a post() in there from debugging but that's a different matter).

I would even post something to the Pd window if the object is threaded or not. I could seriously imagine if I had more patches depending on [coll] and determinism and if I were in a crunch, going absolutely crazy and frustrated as to why my patch broke. If the patch broke becaue of order, that can be quite subtle and if i'm familiar with an object, my instincts wouldn't say "hey let's go to the help file", esp if it's a wall of text. I know Max doesn't tell you in the Max window if it's threaded but this is Pd land here. So I would strongly side with well, first getting rid of my stupid debugging post that shouldn't be there, and putting in a post that says we're using threaded.

More on this, I think should be clear documentation outside of running Pd, maybe even in the main README, even if it's a short blurb expanded upon somewhere else, how this library in general differs from normal Pd land.

Anyways, the decision is a bit easier with large text files that would cause dropouts. Unthreaded would be unlikely to be used when you have live audio going on because of the dropouts unless you're making the dropouts part of your piece which I suppose could be pretty interesting but not a likely use case.

The issue is with the rest of the cases and I'm a little more torn there. The fix is pretty clear although a pain in the butt. If your read is in the middle of a trigger, then anything to the left of it depending on the read happening first would get all kablunked. Then the fix would be to have that read bang coming out from [coll] be in charge of triggering that kablunked stuff in the proper order and this could be a lot of rewiring... I suppose since we're going wtih a most Max-like experience as possible, it would be confusing if one object wasn't as Max-like as the others. Anyways, that's my two cents for now.

Derek

There's also the best-case scenario where you have already loaded multiple [coll]s or where you do some offset, so you don't need to access the disk any more.

Or if part of the RAM is used as a virtual HD.

Mensaje telepatico asistido por maquinas.

From: Pd-list pd-list-bounces@lists.iem.at on behalf of Matt Barber brbrofsvl@gmail.com Sent: Thursday, February 2, 2017 1:52 AM To: Derek Kwan Cc: pd-list@lists.iem.at Subject: Re: [PD] [coll] bug

There's always a worst-case scenario for a system call blocking on loading even a small file that would involve dropouts. Nothing is guaranteed when you read from disk.

On Wed, Feb 1, 2017 at 7:14 PM, Derek Kwan <derek.x.kwan@gmail.commailto:derek.x.kwan@gmail.com> wrote:

Lots of thoughts here, but little time. Here are the salient points to me:

1. The best analogy to this in Pd is [soundfiler]. [soundfiler] stops the

world in order to load the file, which routinely causes dropouts. This is a constant source of disappointment and frustration to students especially if.....................

On 2017-02-02 01:14, Derek Kwan wrote:

After a few days away from it and coming back to discuss the issue, I think threaded as the default makes sense GRANTED that it is well documented and there's an included explanation of why this differs from normal Pd usage. I wouldn't want users new to Pd expect all of Pd to work the way [coll] does as a default then getting confused as to why it isn't (also it looks like I accidentally left a post() in there from debugging but that's a different matter).

i don't think a threaded version of [coll] is so out-of-the ordinary that it will confuse people out of their minds. there are a number of objects that do not strictly adhere to the depth-first paradigm, and thus break [t b b b] scheduling. the most prominent is probably [delay]¹.

even though [delay] behaves as it does, i don't think that most will expect Pd to behave like [delay]. (actually, a lot of new users need to get onto terms with the depth-first principle; but once they have figured it out, they can distinguish between the ordinary behaviour and an exception).

also, most new users probably will not start with [coll], and model their understanding of Pd on that object.

oh, and of course the term "deterministic" can be stretched quite far. even a non-threaded [coll] is not very deterministic: it can cause variable length audio glitches when loading files (even with the same file)...

fgaserd IOhannes

¹ that's just a built-in example; other objects that do not promise to have all their work done once their left-most inlet ist "done" include e.g. most (all?) objects from the iemtab library, which use a "done"-bang to signal when they have finished - even though they are not threaded.

It's not quite like [delay] in that the delay time for this is unpredictable. It's not just that it affects depth-first processing, but that if you patch it wrong you may get bugs you can't always replicate; that's not the case with [delay], whose behavior is predictable in principle.

On Thu, Feb 2, 2017 at 11:01 AM, Alexandre Torres Porres porres@gmail.com wrote:

2017-02-02 8:06 GMT-02:00 IOhannes m zmoelnig zmoelnig@iem.at:

...

i don't think a threaded version of [coll] is so out-of-the ordinary that it will confuse people out of their minds.

thanks, me too, but you've put it really well and better than I could...

I've been using Pd for a while now, and don't think I'd ever be confused with seeing that at all

...

oh, and of course the term "deterministic" can be stretched quite far.

and that's also a term that confused me, I'm more used with "depth first"

Anyway, I just worked on a new help file and everything. I'm keeping the an option for unthreaded and all, but I'm also saying one should not use it and just adapt to the best patching practice instead if needed.

cheers

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list