[PD] cartopol~ and poltocar~

[Jonathan Wilkes]

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.netOn 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.netthis 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/ba7ae708/attachment-0001.html>