[PD] Coll object Was: cartopol~ and poltocar~
Fred Jan Kraan
fjkraan at xs4all.nl
Sat Oct 17 21:16:31 CEST 2015
On 2015-10-17 05:57 PM, Jonathan Wilkes wrote:
> Fred Jan,
> Now that's interesting. Thanks for testing it.
>
> What happens with larger data sets? One thousand, ten thousand, etc.
Same result for 10.000 items; first the bang, then the result from the
dump. No interruption of the sound.
>
> And a question for Ivica,
> When you were using Max, did you mess with any global settings? I
> remember reading docs about
> a setting that could affect this (but I can't remember what it is atm).
>
> -Jonathan
Fred Jan
>
>
>
> On Saturday, October 17, 2015 11:06 AM, Ivica Bukvic <ico at vt.edu> wrote:
>
>
> 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 at vt.edu <mailto:ico at 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 17, 2015 10:59 AM, "Fred Jan Kraan" <fjkraan at xs4all.nl
> <mailto:fjkraan at 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 at xs4all.nl <mailto:fjkraan at 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 at vt.edu
> <mailto:ico at vt.edu>
> > <mailto:ico at vt.edu <mailto:ico at 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 at vt.edu <mailto:ico at vt.edu> <mailto:ico at vt.edu
> <mailto:ico at vt.edu>> <mailto:ico at vt.edu <mailto:ico at vt.edu>
> <mailto:ico at vt.edu <mailto:ico at vt.edu>>>
> >> www.performingarts.vt.edu <http://www.performingarts.vt.edu/>
> <http://www.performingarts.vt.edu/>
> >> disis.icat.vt.edu <http://disis.icat.vt.edu/>
> <http://disis.icat.vt.edu/>
> >> l2ork.icat.vt.edu <http://l2ork.icat.vt.edu/>
> <http://l2ork.icat.vt.edu/>
> >> Ico.bukvic.net <http://ico.bukvic.net/> <http://ico.bukvic.net/>
> >> On Oct 16, 2015 11:48 PM, "Ivica Bukvic" <ico at vt.edu
> <mailto:ico at vt.edu> <mailto:ico at vt.edu <mailto:ico at vt.edu>>
> >> <mailto:ico at vt.edu <mailto:ico at vt.edu> <mailto:ico at vt.edu
> <mailto:ico at 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 at vt.edu <mailto:ico at vt.edu> <mailto:ico at vt.edu
> <mailto:ico at vt.edu>> <mailto:ico at vt.edu <mailto:ico at vt.edu>
> <mailto:ico at vt.edu <mailto:ico at vt.edu>>>
> >> www.performingarts.vt.edu <http://www.performingarts.vt.edu/>
> <http://www.performingarts.vt.edu/>
> >> disis.icat.vt.edu <http://disis.icat.vt.edu/>
> <http://disis.icat.vt.edu/>
> >> l2ork.icat.vt.edu <http://l2ork.icat.vt.edu/>
> <http://l2ork.icat.vt.edu/>
> >> Ico.bukvic.net <http://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 at lists.iem.at <mailto:pd-list at lists.iem.at>
> <mailto:pd-list at lists.iem.at <mailto:pd-list at lists.iem.at>>
> > <mailto:pd-list at lists.iem.at <mailto:pd-list at lists.iem.at>
> <mailto:pd-list at lists.iem.at <mailto:pd-list at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>
> > <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>> mailing
> list
> >> UNSUBSCRIBE and account-management ->
> >> http://lists.puredata.info/listinfo/pd-list
>
> >>
> >>
> >>
> >> _______________________________________________
> >> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>
> > <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>> mailing
> list
> >> UNSUBSCRIBE and account-management ->
> >> http://lists.puredata.info/listinfo/pd-list
> >>
> >>
> >> _______________________________________________
> >> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>
> > <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>> mailing
> list
> >
> >> UNSUBSCRIBE and account-management ->
> >> http://lists.puredata.info/listinfo/pd-list
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>> mailing list
> >> UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >>
> >
> > _______________________________________________
> > Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>> mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> >
>
> _______________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
More information about the Pd-list
mailing list