[PD] Coll object Was: cartopol~ and poltocar~

Jonathan Wilkes jancsika at yahoo.com
Sat Oct 17 22:26:00 CEST 2015


Fred Jan,Let's say you've got a [cycle~] at frequency A.  What happens if you send it a message to change to 
frequency B, read a big file with [coll], then change the frequency back to A, all in zero logical time?  (I.e., 
each event is a child of the same [trigger].  Do you hear the change to frequency B?
-Jonathan
 


     On Saturday, October 17, 2015 3:16 PM, Fred Jan Kraan <fjkraan at xs4all.nl> wrote:
   

 

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
> 
> 
> 


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151017/925b8eaa/attachment-0001.html>


More information about the Pd-list mailing list