Re: [PD] cartopol~ and poltocar~

2015-10-16 Thread Jonathan Wilkes via Pd-list
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

Re: [PD] cartopol~ and poltocar~

2015-10-16 Thread Alexandre Torres Porres
Hi Ivica, you can get the new cyclone with deken and also here https://puredata.info/downloads/cyclone/releases/0.1-alpha57 I'm sure you can contribute to it and update it. I'm notr maintaining it myself, but I've been extensively reporting bugs to it. Fred is working on it, but this is a library

Re: [PD] cartopol~ and poltocar~

2015-10-16 Thread Ivica Bukvic
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 i...@vt.edu www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu Ico.bukvic.net On Oct

Re: [PD] cartopol~ and poltocar~

2015-10-16 Thread Ivica Bukvic
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,

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Jonathan Wilkes via Pd-list
I like how we're recording for posterity what are probably the most esoteric puns about twins. I can see the future eye-rolls now... :) -Jonathan On Friday, October 16, 2015 10:06 PM, Dan Wilcox wrote: “Execution order” indeed. Dan Wilcox @danomatika danomatika.com robotco

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Matt Barber
​Believe me, they don't need to be triggered, and order doesn't really matter. [baby~] | | [baby~] || [+~ ] | [output~] (not normalized, obvs.) On Fri, Oct 16, 2015 at 10:06 PM, Dan Wilcox wrote: > “Execution order” indeed. > > > Dan Wilcox > @danomatika

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Matt Barber
Looking closer, it appears the OOURA fft has special routines for n<64... but it uses those routines regularly as subroutines in larger ffts. In any case it looks like the smaller block sizes are intended to be usable in the code itself, but Miller must've had a reason not to trust them. Here's the

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Dan Wilcox
“Execution order” indeed. Dan Wilcox @danomatika danomatika.com robotcowboy.com > On Oct 16, 2015, at 4:54 PM, pd-list-requ...@lists.iem.at wrote: > > From: Jonathan Wilkes mailto:jancs...@yahoo.com>> > D

Re: [PD] cartopol~ and poltocar~

2015-10-16 Thread Alexandre Torres Porres
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 obj

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Robert Esler
Sorry I checked your patch again. I get the same behavior. I had an older version of Pd I was using. Yes, I just noticed this too. It appears OOURA limits the calculation to a block size of 32 or higher. Why? The code is so horribly documented I’d rather not even try to figure it out. P

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Matt Barber
OK, looking at the OOURA code, the init routine has this: static int ooura_init( int n) { n = (1 << ilog2(n)); if (n < 64) return (0); then later in the fft/ifft routine: if (!ooura_init(2*n))

Re: [PD] How does vline~ work under the hood?

2015-10-16 Thread Jonathan Wilkes via Pd-list
Hi Alexandre, The [vline~] object can compute ramps with subsample accuracy, regardless of the block size. Though I might not understand the question. -Jonathan On Friday, October 16, 2015 4:42 PM, Alexandre Torres Porres wrote: > Does vline also have to wait for a blo

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Jonathan Wilkes via Pd-list
Is there something like a real-life [trigger] you use to keep track of their ordering? -Jonathan On Friday, October 16, 2015 5:39 PM, Matt Barber wrote: It's actually twins. It's a complex situation; I don't yet know which is real and which imaginary. On Fri, Oct 16, 2015 at 5:29

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Matt Barber
It's actually twins. It's a complex situation; I don't yet know which is real and which imaginary. On Fri, Oct 16, 2015 at 5:29 PM, Jaime E Oliver wrote: > laptop baby > > On Oct 16, 2015, at 5:12 PM, Matt Barber wrote: > > I meant 32 points, sorry. You can usually assume I'm typing with a cryi

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread katja
If I understand the fft files correctly OOURA is now the default, but 'disguised' as mayer fft so the old API should remain valid. (http://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/d_fft_fftsg.c). Indeed I get the same result for Matt's test patch with Pd 0.46-5 which is on my syste

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Jaime E Oliver
laptop baby On Oct 16, 2015, at 5:12 PM, Matt Barber wrote: > I meant 32 points, sorry. You can usually assume I'm typing with a crying > baby in my lap. :) > > On Fri, Oct 16, 2015 at 4:14 PM, IOhannes m zmölnig wrote: > On 10/16/2015 03:50 AM, Matt Barber wrote: > > Basically, for [block~]

Re: [PD] cartopol~ and poltocar~

2015-10-16 Thread Gilberto Agostinho via Pd-list
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

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Matt Barber
I meant 32 points, sorry. You can usually assume I'm typing with a crying baby in my lap. :) On Fri, Oct 16, 2015 at 4:14 PM, IOhannes m zmölnig wrote: > On 10/16/2015 03:50 AM, Matt Barber wrote: > > Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform > -- > > it just passes

[PD] cartopol~ and poltocar~

2015-10-16 Thread Gilberto Agostinho via Pd-list
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~] i

Re: [PD] How does vline~ work under the hood?

2015-10-16 Thread Alexandre Torres Porres
> Does vline also have to wait for a block boundary when first triggered? this is probably cleared out and not sure if this is the question, but vline~ will respect the schedule timing of events with a delay of one block, meaning that it'll convert the events to audio rate but only for the next bl

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread IOhannes m zmölnig
On 10/16/2015 03:50 AM, Matt Barber wrote: > Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform -- > it just passes the signal through unchanged. isn't that what is expected of a 1 point FFT? (32bits == 4 bytes == sizeof(float)). > See the attached patch, which only shows [ff

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

2015-10-16 Thread Robert Esler
As far as I know Pd stopped using the mayer fft library in .46, which is probably why this is new behavior. I only get what you’re experiencing with a block size of 8. Otherwise, it seems to perform as expected. To really understand if this is a bug or not is to know which fft library is

[PD] nice loop~ example

2015-10-16 Thread Alexandre Torres Porres
howdy, anybody got a cool patch that depends on loop~ or illustrates a nice usage of it? I find this object not very interesting and easily replaceable by just phasor~ + *~ so I just never used it cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE

Re: [PD] playing .mid files in puredata

2015-10-16 Thread Dan Wilcox
Howdy all, xeq looks like a good candidate for resurrection via pd-lib-builder, so I got it building and put it on Github: https://github.com/pure-data/xeq It’s not quite working yet, but I bet a few of you could help me on that. Once it does, then we can upl