--- On Thu, 5/28/09, Sergei Steshenko wrote:
> From: Sergei Steshenko
> Subject: Re: [PD-dev] ffmpeg with gcc 3.4
> To: "pd-dev List" , "Hans-Christoph Steiner"
> Date: Thursday, May 28, 2009, 1:44 AM
>
>
> --- On Tue, 5/19/09, Hans-Christoph Stei
--- On Tue, 5/19/09, Hans-Christoph Steiner wrote:
> From: Hans-Christoph Steiner
> Subject: [PD-dev] ffmpeg with gcc 3.4
> To: "pd-dev List"
> Date: Tuesday, May 19, 2009, 4:04 PM
>
> There is hope, we can still use MSYS's default gcc 3.4.5
> for building ffmpeg, making the MinGW build set
--- On Thu, 5/21/09, Hans-Christoph Steiner wrote:
> From: Hans-Christoph Steiner
> Subject: [PD-dev] liboil - lib of CPU optimizations
> To: "pddev List"
> Date: Thursday, May 21, 2009, 11:55 AM
>
> Anyone ever looked at liboil? "Liboil is a library of
> simple functions that are optimized
--- On Tue, 5/26/09, Hans-Christoph Steiner wrote:
> From: Hans-Christoph Steiner
> Subject: [PD-dev] dlopen() for windows
> To: "pddev List"
> Date: Tuesday, May 26, 2009, 12:37 PM
>
> August just brought this potentially handy piece of
> software to my attention:
>
> http://code.google.c
--- Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
> On Thu, 27 Sep 2007, Sergei Steshenko wrote:
>
> > 1) if no formatting is enforced on a project, nobody is repelled, since
> > everybody has the possibility/freedom to write code the way he/she likes;
>
> N
--- Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
> On Thu, 27 Sep 2007, Sergei Steshenko wrote:
>
> > I think automatic reformatting is the only way - unless a project wants
> > too repell developers.
>
> The main branch of Pd must be repelling people in another
--- Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:
> Having common code formats is standard practice in any well organized
> projects (check the Linux and GNU standards for examples). Many have
> it done autmoatically when you check your code in to the repository.
>
> .hc
I think auto
--- marius schebella <[EMAIL PROTECTED]> wrote:
> maybe you also want to look at the vasp library. with vasp you can do
> fft on whatever buffersize you want.
> marius.
>
> Sergei Steshenko wrote:
> > --- Miller Puckette <[EMAIL PROTECTED]> wrote:
> >
&
--- Miller Puckette <[EMAIL PROTECTED]> wrote:
> Depending on the OS, you can get at least 100 milliseconds of buffering and
> perhaps much more... so it should be fine.
>
> cheers
> Miller
>
Well, the OS is Linux (SUSE 10.2 to be precise) and I'm interested in FFT
transforms taking, say, 3 se
Hello All,
I have a very basic question regarding pd - does it use dual buffer approach ?
That is, suppose I'm going to use a FIR (FFT, for example) with long (several
seconds) processing time (latency), and there is enough CPU performance to do
processing in real time.
Still, if I want to hear
--- Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
[snip]
>
> The FFTW3 patch is independent: you don't do --enable-fftw for it. I think
> it's a separate option. I don't have the time to look at what the actual
> diff looks like, but I've seen some parts of the diff a while ago.
>
Thanks - if
--- Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
> On Sat, 18 Aug 2007, Miller Puckette wrote:
>
> > Sorry, FFTW support isn't working at all in the current version of Pd
> > (they changed the API and I haven't had the patience to try to deal
> > with it yet.)
>
> Sorry, FFTW 3 was released seve
--- Miller Puckette <[EMAIL PROTECTED]> wrote:
> Sorry, FFTW support isn't working at all in the current version of Pd
> (they changed the API and I haven't had the patience to try to deal
> with it yet.)
>
> Miller
>
> On Sat, Aug 18, 2007 at 10:
Hello All,
I'm trying to build pd-0.40-2 in the framework of my AppsFromScratch.
For starters, 'gcc' complains about 'logn' on line #44 and 'inverse' on on
line #47 of 'pd-0.40-2/src/d_fft_fftw.c' file:
42 static fftw_plan fftw_getplan(int n, int dir)
43 {
44 logn = ilog2(n);
14 matches
Mail list logo
