17 Oct
2015
17 Oct
'15
5:06 p.m.
Threaded coll does the same because IIRC it enqueues events it cannot execute until the file is loaded, except, this makes it fall out of sync with the rest of the system in that case, but then again that is why coll has "done loading bang" outlet.
Also, I think what will test Max's threaded nature (or not) is loading a huge coll file with small signal vector size and seeing if it drops samples. If it doesn't, unless there are fundamental differences in the audio engine between Pd and Max , this would suggest it is threaded. Another (easier?) way is to ask someone at Cycling74 :-)
--
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
ico@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
Ico.bukvic.net
On Oct 17, 2015 10:59 AM, "Fred Jan Kraan" fjkraan@xs4all.nl wrote:
> 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 > > fjkraan@xs4all.nl 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 <ico@vt.edu > > mailto:ico@vt.edu> 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 > >> ico@vt.edu mailto:ico@vt.edu <mailto:ico@vt.edu mailto:ico@vt.edu> > >> 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" <ico@vt.edu mailto:ico@vt.edu > > >> <mailto:ico@vt.edu mailto:ico@vt.edu>> 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 > >> ico@vt.edu mailto:ico@vt.edu <mailto:ico@vt.edu mailto:ico@vt.edu >> > >> 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 > >> <pd-list@lists.iem.at mailto:pd-list@lists.iem.at > > <mailto:pd-list@lists.iem.at mailto:pd-list@lists.iem.at>>: > >> > >> 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 > >> > >> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at > > <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > >> > >> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at > > <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > >> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at > > <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list > > > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > >> > >> > >> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list > >> UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > >> > > > > _______________________________________________ > > Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
> | [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 > > fjkraan@xs4all.nl 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 <ico@vt.edu > > mailto:ico@vt.edu> 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 > >> ico@vt.edu mailto:ico@vt.edu <mailto:ico@vt.edu mailto:ico@vt.edu> > >> 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" <ico@vt.edu mailto:ico@vt.edu > > >> <mailto:ico@vt.edu mailto:ico@vt.edu>> 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 > >> ico@vt.edu mailto:ico@vt.edu <mailto:ico@vt.edu mailto:ico@vt.edu >> > >> 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 > >> <pd-list@lists.iem.at mailto:pd-list@lists.iem.at > > <mailto:pd-list@lists.iem.at mailto:pd-list@lists.iem.at>>: > >> > >> 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 > >> > >> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at > > <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > >> > >> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at > > <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > >> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at > > <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list > > > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > >> > >> > >> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list > >> UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > >> > > > > _______________________________________________ > > Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >