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 <[email protected]> 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 > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
