[PD] Coll object Was: cartopol~ and poltocar~
Fred Jan Kraan
fjkraan at xs4all.nl
Sat Oct 17 16:58:32 CEST 2015
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> 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>> 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>>
>> 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 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>>
>> 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 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>> 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
>>
>
> _______________________________________________
> 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