<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Lots of thoughts here, but little time. Here are the salient points to me:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Matt</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 29, 2017 at 11:43 PM, Alexandre Torres Porres <span dir="ltr"><<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I had some concerns with pthreads and Windows compat but it looks like<br>
those aren't issues (? I don't have much experience with Windows dev) so<br>
I think I would be fine either way.<br></blockquote><div><br></div></span><div>it's working in windows!</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_1099883264905117983gmail-"><br>
> And is this threaded stuff only for multi threaded processors? How does<br>
> this work on a single core rasbperry pi or something like that?<br>
><br>
<br>
</span>It looks like threading works fine on single core</blockquote><div><br></div></span><div>cool</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
One issue that might be of concern is backwards compat with old versions<br>
of Cyclone. Otherwise I'm fine with threaded as the default.</blockquote><div><br></div></span><div>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...</div><div><br></div><div>You see, it just affects one operation: reading a file, and not all files, just <u>Large</u> files... and it affects it in a good way: Preventing Audio drop outs! As it happens in Max by the way...<br></div><div><br></div><div>Nothing that a decent documentation explaining one should always rely on the 3rd outlet doesn't solve it. </div><div><br></div><div><div>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...</div></div><div><br></div><div>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.</div><div><br></div><div>cheers</div></div></div></div>
<br>______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/pd-list</a><br>
<br></blockquote></div><br></div>