[PD] Coll object Was: cartopol~ and poltocar~
Jonathan Wilkes
jancsika at yahoo.com
Sat Oct 17 15:48:26 CEST 2015
Hi Fred Jan,I suppose what I am asking is if the read/write bang outlet happens depth-first
in Max, or not.
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
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 (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> 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>
> 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>> 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>
> 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>>:
>
> 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> 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
>
>
>
>
> _______________________________________________
> 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 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/3e31315e/attachment-0001.html>
More information about the Pd-list
mailing list