Hi Jonathan, > Hi Fred Jan, > I suppose what I am asking is if the read/write bang outlet happens > depth-first > in Max, or not.
The test patch in Max 5 looked more or less like this: [bang( | [t b b] | \ | [read test.coll( | | [dump( | \ / [coll] | | [print] [coll] and [print] have only one inlet. The right line is connected to the third outlet. A collection (100 pairs) is present in the test.coll. The bang is printed first, the list after that. If I interpret this correctly, the [read test.coll( is executed depth first. Just like in cyclone. > > If it does not, then it means Max _is_ sacrificing predictability for > performance > in that case. As long as we can predict that it will not crash, I think > at least having that option would be important for compatibility. > > -Jonathan > > Fred Jan > > > > On Saturday, October 17, 2015 7:21 AM, Fred Jan Kraan > <[email protected]> wrote: > > > > > On 2015-10-17 06:38 AM, Jonathan Wilkes via Pd-list wrote: >> >> Hi Ivica, >> >> When we discussed the threading feature before, I advocated against it >> since >> it breaks determinism. > > There is an other reason for not adding threading to the coll object. In > the past I did some testing and found it a quite convoluted object. It > allows several types of indices (float, symbol) and has messages > operating on only these subsets. I tried to document this in the help > patch. > Large collections and threading may be useful, but better suited for an > object with a more consistent set of operations, and just one key type > at a time to make results more predictable. >> >> However, the Max/MSP documentation (as well as the outlet interface > itself) >> suggests that Max's implementation is threaded, too. Why else would you >> need a bang to signal when it has finished reading the file, for example? >> >> Can someone test how it works in practice in Max? > > The testing I did was for functionality, and I found cyclone/coll was > very much like Max/coll. Large collection loading was not in scope. >> >> I'm in favor of the default behavior for the sake of >> backwards-compatibility within >> Pd. But if Max is actually threading the reads/writes, that would make >> this an >> important general feature for Max compatibility. > > Compatibility is important, but not at any price. There are several > objects in Max and cyclone which are troubled by > 'Swiss-army-knife-syndrome'. Coll is certainly one of them. This makes > improving it low priority for me (with the exception for crashing issues). > Large collection support can be better implemented with a clear, > ortogonal operation set in a new object. >> >> -Jonathan >> > The latest source is in the SVN repository and at > http://puredata.info/downloads/cyclone/releases > <http://puredata.info/downloads/cyclone/releases>(you can ignore the > '(unreleased)' postfix. It refuses to go away for now). It contains > several bug-fixes and help-patches based on the Pd-l2ork versions. > Current planning is to leave the SVN repository as it is now and start > a Git repository based on the good work of IOhannes. But for now this is > just planning. > > Greetings, > > Fred Jan > > >> >> >> >> On Friday, October 16, 2015 11:50 PM, Ivica Bukvic <[email protected] > <mailto:[email protected]>> wrote: >> >> >> cool = coll >> -- >> Ivica Ico Bukvic, D.M.A. >> Associate Professor >> Computer Music >> ICAT Senior Fellow >> Director -- DISIS, L2Ork >> Virginia Tech >> School of Performing Arts – 0141 >> Blacksburg, VA 24061 >> (540) 231-6139 >> [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> >> www.performingarts.vt.edu <http://www.performingarts.vt.edu/> >> disis.icat.vt.edu <http://disis.icat.vt.edu/> >> l2ork.icat.vt.edu <http://l2ork.icat.vt.edu/> >> Ico.bukvic.net <http://ico.bukvic.net/> >> On Oct 16, 2015 11:48 PM, "Ivica Bukvic" <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> I am sure this has been covered on this list before--if it is not >> too much of a trouble where can one get the new version of cyclone? >> Also, there are some improvements on pd-l2ork side of things that >> I've implemented that may detract from Max behavior but also offers >> other benefits. For instance, coll object can be threaded and as >> such allows loading of large files without dropping samples, albeit >> at the expense of determinacy, so one in these cases must rely on >> outputting done loading bang signal before working with the cool >> object. This option is fully backwards compatible and the default >> behavior is non-threaded. It would be great if we could have those >> merged so that we don't have to maintain two separate versions of >> the cyclone library. >> Best, >> -- >> Ivica Ico Bukvic, D.M.A. >> Associate Professor >> Computer Music >> ICAT Senior Fellow >> Director -- DISIS, L2Ork >> Virginia Tech >> School of Performing Arts – 0141 >> Blacksburg, VA 24061 >> (540) 231-6139 >> [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> >> www.performingarts.vt.edu <http://www.performingarts.vt.edu/> >> disis.icat.vt.edu <http://disis.icat.vt.edu/> >> l2ork.icat.vt.edu <http://l2ork.icat.vt.edu/> >> Ico.bukvic.net <http://ico.bukvic.net/> >> this has been corrected in the new cyclone library >> >> actually, both cartopol~ and poltocar~ were "wrong" in the same way, >> but for extended 0.42 only poltocar~ was corrected, this incomplete >> fix ended up ruining spectral processing that was actually working >> before that. >> >> get the new cyclone, many objects are being corrected >> >> cheers >> >> 2015-10-16 18:14 GMT-03:00 Gilberto Agostinho via Pd-list >> <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>: >> >> Just a little update: the problem is with [cartopol~], its >> rightmost outlet is outputting the correct value multiplied by -1. >> >> >> On 16/10/15 22:55, Gilberto Agostinho wrote: >> >> Hello, >> >> I believe I found a bug with the objects [cartopol~] and >> [poltocar~]. Basically, if I would connect both outlets of >> [cartopol~] to the inlets of [poltocar~], I would expect to >> receive the same values as I would input. The problem is >> that the output of the second outlet of [poltocar~] is >> multiplied by -1! I tested this with both Pd 0.46.5 and >> pd-extended 0.43.4 (and this bug isn't present in Pd-l2Ork). >> >> Here is an image of the problem: >> > http://s1.postimg.org/bs79w4d5b/Screenshot_from_2015_10_16_22_50_23.png >> >> Is this a known bug? >> >> Cheers, >> Gilberto >> >> >> >> _______________________________________________ >> [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> _______________________________________________ >> [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> _______________________________________________ >> [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> mailing list > >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> >> _______________________________________________ >> [email protected] <mailto:[email protected]> mailing list >> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >> > > _______________________________________________ > [email protected] <mailto:[email protected]> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
