<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-26 17:30 GMT-02:00 Ivica Ico Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Joining late to the party...</p>
<p>Being the culprit (I wrote the threaded addition to the coll
object) I am curious--Alexandre, do you mind elaborating how did
the threaded thing break max-msp compatibility? If you create a
coll object without the optional arg, you get Max behavior. If you
add the optional arg you get threaded which theoretically breaks
determinacy in favor of avoiding dropping samples due to file I/O
in the middle of a performance.</p></div></blockquote><div><br></div><div>sure, here's the deal, Max already has an optional 2nd argument, which is for telling it to not look for a file with that name. This is so because the 1st argument can be either for naming a coll object or telling it to look for a file to load. Moreover, if you give it a file name to look for and read, that also works as the name of the coll object, meaning that you can have multiple coll objects with that name. But since different coll objects with the same name already sahre the data, you don't need all of them to read files.</div><div><br></div><div>Some examples:</div><div><br></div><div>[coll name 1] <= this is a named coll, there's no file, don't bother looking for it</div><div><br></div><div>[coll x.txt] & [coll x.txt 1] <= the one to the left loads the file, the one to the right shares the data & doesn't look for the file because it doesn't need to.</div><div><br></div><div>This 2nd argument for coll was introduced in Max 4.0.8</div><div><br></div><div>Most of the objects in cyclone are outdated to Max 4.0 and not to some later version of Max 4 as was assumed sometimes - you can find descriptions of the cyclone library as "clones from max 4.5" but that is not true, probably that description was made by the time Max 4.5 was around and people were just assuming it to be true, but it's not.</div><div><br></div><div>It's funny how when cyclone 0.1 alpha 1 comes out, it's already outdated, cause it was released when Max 4.1 had just been made available (like a week or 2 before).</div><div><br></div><div>Therefore, cyclone's [coll] was outdated since version 0.1 alpha01, and it just kept outdated until the original author abandoned it (in version 0.1 alpha 55)</div><div><br></div><div>Well, enough anecdotes... back to cyclone's current development</div><div><br></div><div>The optional 2nd argument was introduced in Pd-l2ork (I don't know when), and ported to cyclone in the version "cyclone 0.2 beta1". Nonetheless, it is now removed from the latest state: "cyclone 0.2 beta3" - which is in deken for windows, and cyclone 0.2 beta1 is still available for mac and linux in deken. One way or another, if you build it from the repository, you'll get cyclone 0.2 beta3, without the 2nd argument/threaded functionality.</div><div><br></div><div>I can see other details in this version of coll. For some reason, the bang output on the third outlet (when finishing reading a file) was removed, and it is only present in the threaded version.</div><div><br></div><div>I can also check that this optional argument can come in any order, before or after the coll name. In the documentation of cyclone 0.2 it is mentioned that it's supposed to be only as the 2nd argument (btw, even though this is removed from cyclone 0.2 beta3, it is still mentioned in the documentation). Anyway, also having it as the 1st argument goes against the original max's syntax. So I consider that these changes added some relevant noise to coll's structure.</div><div><br></div><div>So, in my opinion, if new things were to be introduced to coll as they were, it'd would have been good to check its state. I'm sure that if it was realized it had a missing 2nd argument that the right thing to do would be to include it and have another way of dealing with the extra functionality, in a less intrusive way to its original syntax and all.</div><div><br></div><div>I think that an additional "flag" is less intrusive for an extra functionality. Something like "-threaded".</div><div><br></div><div>Well, we've been working on updating cyclone, and the major concern is to update and include missing functionalities, from Max 4.0 up to the latest version (Max 7.3.1 currently). There are about 60 objects that needed work in that direction (and now we have only 5 more to go). None of the other updates raise any issue like coll does, because coll was the only one that suffered such kind of intervention. So, what are doing with coll?</div><div><br></div><div>We've already updated it to include missing functionalities, which is the 2nd argument, a couple of attributes and a couple of extra methods (renumber2 and insert2). We are also fixing a couple of bugs. One of the bugs is the bang output on the 3rd inlet, that we put back...</div><div><br></div><div>About the threaded version, we're including it kind of as a flag, but in the max's attribute style way, so "@threaded 1" loads the threaded version, and this can also be edited with a "threaded" message method.</div><div><br></div><div>I still have a couple of other things to reply to regarding the rest of your message</div><div><br></div><div>cheers</div></div></div></div>