[PD] cartopol~ and poltocar~

[Ivica Bukvic]

The pd-l2ork implementation makes sure that by default coll is non-threaded
and therefore fully backwards compatible. Only if you give it an optional
argument 1 does it actually instantiate as a threaded object. FWIW, in
L2Ork we cannot function without it being threaded as in some of the pieces
you have gestural trackers that capture up to 50 events/entries per second
and when reloaded from HD they consist of hundreds if not several thousand
entries.

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
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
Ico.bukvic.net
On Oct 17, 2015 12:42 AM, "Jonathan Wilkes" <jancsika at yahoo.com> wrote:

>
> Hi Ivica,
>
> When we discussed the threading feature before, I advocated against it
> since
> it breaks determinism.
>
> 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?
>
> 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.
>
> -Jonathan
>
>
>
>
> 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
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> Ico.bukvic.net <http://ico.bukvic.net/>
> On Oct 16, 2015 11:48 PM, "Ivica Bukvic" <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
> www.performingarts.vt.edu
> disis.icat.vt.edu
> 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>:
>
> 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 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/688ebaf2/attachment.html>