Re: [PD] [bob~] denormals issue?

[David Medine]

From a few posts ago it looks like -O3 is what causes denormals to 
stick around, but I don't really know what I'm talking about. RK4 (which 
is what bob~ uses to solve the system) will never 'naturally' bring the 
filter state exactly back to 0 unless forced to in some way so if the 
denormals aren't handled elegantly, they will abound with 0 input to the 
filter no matter what (once some input has gone into the filter that 
is). My guess is that a slow decay doesn't push the filter states down 
into that region.


It is stupid and certainly sub-optimal, but maybe:

x = (xwhere DENORMAL_THRESH is some very, very small normal number? This would 
have to be done on the negative side of 0, too. 2x compares is probably 
not as bad as the potential 100x slowdown (according to Wikipedia) that 
denormal arithmetic might cause.


It should be the case that the same compiler flags (for plain C anyway) 
produce, within limits, the same behavior across different compilers but 
that probably isn't true. This would be an interesting check. I'd like 
to know if leaving off -03 has the same effect with gcc.


On 9/21/2016 3:26 PM, katja wrote:

On Linux i386 bob~ produces subnormals as well and very high cpu load.
It is not the slowly decaying signal that other filters tend to give,
but a quick decay to a fixed small number.

It's weird indeed when subnormals cause different CPU load depending
on how they are compiled. Since MinGW is a gcc port I would think it
uses the same math implementation which produces such high CPU load
for bob~ subnormals on my system.

On Thu, Sep 22, 2016 at 12:01 AM, Christof Ressi  wrote:

I tried your patch with the [bob~] object shipped with the Windows binaries. I 
clearly get subnormals! It's actually no wonder because there isn't any 
protection against subnormals in the code (at least I couldn't spot it).
But the weird thing is: the [bob~] I compiled myself would also show subnormals 
in your patch but the CPU load is not affected...


Gesendet: Mittwoch, 21. September 2016 um 23:47 Uhr
Von: katja 
An: "Christof Ressi" 
Cc: "pd-list@lists.iem.at" 
Betreff: Re: Re: Re: [PD] [bob~] denormals issue?

Without -O flags you get debug-level and all function inlining is
disabled, depending on the code it can make a huge difference indeed.
But Pd is probably compiled with at least -O2. So the flags don't make
much difference. The compiler? Doesn't Miller compile with MinGW
nowadays, I don't know. MinGW brings its own standard C libs, which
may implement math functions differently than MS. But regarding
denormals I guess they both respect the IEEE 754 standard.

You can check if you really have subnormals using attached patch
denorm-test.pd you. The patch tests lop~, change it to bob~.

On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi  wrote:

the SSE optimizations don't seem to matter at all. skipping -ffast-math gives a 
slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ 
filters are already to much for one core). Even when skipping all of those 
flags, the denormals issue is still not present.

Maybe it has something to do with the compiler?


Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr
Von: katja 
An: "Christof Ressi" , "pd-list@lists.iem.at" 

Betreff: Re: Re: [PD] [bob~] denormals issue?

I'm curious to know if the flags do flush denormals on your processor.
Forgot to mention that '-O3 -ffast-math' are also set,
platform-independent. So if you have a chance to try which flag does
something... It's just curiosity.

On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi  wrote:

Hi Katja,


Even if your test reveals a beneficial effect from compiler flags,
it is better when denormals are detected and flushed in the C code.

definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end 
of the DSP routine does the trick, just like in all the other recursive filters 
in Pd.




Von: katja 
An: "Christof Ressi" 
Cc: pd-list , "Miller Puckette" 
Betreff: Re: [PD] [bob~] denormals issue?

Hi Christof,

Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
-mfpmath=sse' for optimization to the compiler on Windows. You could
try compiling without (some of) these flags to see if they are
responsible for the different behavior. Makefile-defined optimization
flags can be overriden with argument CFLAGS given on command line.

The effect of optimization flags on denormals varies per processor
type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
wouldn't go away no matter what flags, is what I remember. Even if
your test reveals a beneficial effect from compiler flags, it is
better when denormals are detected and flushed in the C code. Anyway,
it is 

Re: [PD] [bob~] denormals issue?

[katja]

On Linux i386 bob~ produces subnormals as well and very high cpu load.
It is not the slowly decaying signal that other filters tend to give,
but a quick decay to a fixed small number.

It's weird indeed when subnormals cause different CPU load depending
on how they are compiled. Since MinGW is a gcc port I would think it
uses the same math implementation which produces such high CPU load
for bob~ subnormals on my system.

On Thu, Sep 22, 2016 at 12:01 AM, Christof Ressi  wrote:
> I tried your patch with the [bob~] object shipped with the Windows binaries. 
> I clearly get subnormals! It's actually no wonder because there isn't any 
> protection against subnormals in the code (at least I couldn't spot it).
> But the weird thing is: the [bob~] I compiled myself would also show 
> subnormals in your patch but the CPU load is not affected...
>
>> Gesendet: Mittwoch, 21. September 2016 um 23:47 Uhr
>> Von: katja 
>> An: "Christof Ressi" 
>> Cc: "pd-list@lists.iem.at" 
>> Betreff: Re: Re: Re: [PD] [bob~] denormals issue?
>>
>> Without -O flags you get debug-level and all function inlining is
>> disabled, depending on the code it can make a huge difference indeed.
>> But Pd is probably compiled with at least -O2. So the flags don't make
>> much difference. The compiler? Doesn't Miller compile with MinGW
>> nowadays, I don't know. MinGW brings its own standard C libs, which
>> may implement math functions differently than MS. But regarding
>> denormals I guess they both respect the IEEE 754 standard.
>>
>> You can check if you really have subnormals using attached patch
>> denorm-test.pd you. The patch tests lop~, change it to bob~.
>>
>> On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi  
>> wrote:
>> > the SSE optimizations don't seem to matter at all. skipping -ffast-math 
>> > gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise 
>> > (20 bob~ filters are already to much for one core). Even when skipping all 
>> > of those flags, the denormals issue is still not present.
>> >
>> > Maybe it has something to do with the compiler?
>> >
>> >> Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr
>> >> Von: katja 
>> >> An: "Christof Ressi" , "pd-list@lists.iem.at" 
>> >> 
>> >> Betreff: Re: Re: [PD] [bob~] denormals issue?
>> >>
>> >> I'm curious to know if the flags do flush denormals on your processor.
>> >> Forgot to mention that '-O3 -ffast-math' are also set,
>> >> platform-independent. So if you have a chance to try which flag does
>> >> something... It's just curiosity.
>> >>
>> >> On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi  
>> >> wrote:
>> >> > Hi Katja,
>> >> >
>> >> >> Even if your test reveals a beneficial effect from compiler flags,
>> >> >> it is better when denormals are detected and flushed in the C code.
>> >> >
>> >> > definitely! Maybe using the PD_BIGORSMALL macro on each filter state at 
>> >> > the end of the DSP routine does the trick, just like in all the other 
>> >> > recursive filters in Pd.
>> >> >
>> >> >
>> >> >
>> >> >> Von: katja 
>> >> >> An: "Christof Ressi" 
>> >> >> Cc: pd-list , "Miller Puckette" 
>> >> >> Betreff: Re: [PD] [bob~] denormals issue?
>> >> >>
>> >> >> Hi Christof,
>> >> >>
>> >> >> Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
>> >> >> -mfpmath=sse' for optimization to the compiler on Windows. You could
>> >> >> try compiling without (some of) these flags to see if they are
>> >> >> responsible for the different behavior. Makefile-defined optimization
>> >> >> flags can be overriden with argument CFLAGS given on command line.
>> >> >>
>> >> >> The effect of optimization flags on denormals varies per processor
>> >> >> type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
>> >> >> wouldn't go away no matter what flags, is what I remember. Even if
>> >> >> your test reveals a beneficial effect from compiler flags, it is
>> >> >> better when denormals are detected and flushed in the C code. Anyway,
>> >> >> it is still interesting to know what makes the difference.
>> >> >>
>> >> >> Katja
>> >> >>
>> >> >> On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi 
>> >> >>  wrote:
>> >> >> > Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I 
>> >> >> > noticed two things:
>> >> >> > 1) the CPU rise is gone
>> >> >> > 2) it needs only half the CPU. I put 20 [bob~] objects in a switched 
>> >> >> > subpatch and measured the CPU load. The DLL which comes with the 
>> >> >> > Windows binaries needs 15%, while my own DLL needs only 7%! That's 
>> >> >> > quite a deal...
>> >> >> >
>> >> >> > Christof
>> >> >> >
>> >> >> > PS: I attached the DLL in case you wanna try it yourself.
>> >> >> >
>> >> >> >
>> 

Re: [PD] Tcl error for [knob] and [mknob]

[Dan Wilcox]

> On Sep 21, 2016, at 3:40 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Antoine Rousseau >
> 
> Thanks ! 
> and thanks to Dan too, pointing me directly to the right direction !
> But I realize that if I fix mknob for latest Pd it will become incompatible 
> with older ones…

I believe the changes handle saving and loading based on the compatibility 
mode, so you should be able to simply check the version and call that iem color 
function in versions of pd less than 0.48.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [bob~] denormals issue?

[Miller Puckette]

Yeah, I want to find out more about that :)

M

On Thu, Sep 22, 2016 at 12:01:31AM +0200, Christof Ressi wrote:
> I tried your patch with the [bob~] object shipped with the Windows binaries. 
> I clearly get subnormals! It's actually no wonder because there isn't any 
> protection against subnormals in the code (at least I couldn't spot it). 
> But the weird thing is: the [bob~] I compiled myself would also show 
> subnormals in your patch but the CPU load is not affected...
> 
> > Gesendet: Mittwoch, 21. September 2016 um 23:47 Uhr
> > Von: katja 
> > An: "Christof Ressi" 
> > Cc: "pd-list@lists.iem.at" 
> > Betreff: Re: Re: Re: [PD] [bob~] denormals issue?
> >
> > Without -O flags you get debug-level and all function inlining is
> > disabled, depending on the code it can make a huge difference indeed.
> > But Pd is probably compiled with at least -O2. So the flags don't make
> > much difference. The compiler? Doesn't Miller compile with MinGW
> > nowadays, I don't know. MinGW brings its own standard C libs, which
> > may implement math functions differently than MS. But regarding
> > denormals I guess they both respect the IEEE 754 standard.
> > 
> > You can check if you really have subnormals using attached patch
> > denorm-test.pd you. The patch tests lop~, change it to bob~.
> > 
> > On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi  
> > wrote:
> > > the SSE optimizations don't seem to matter at all. skipping -ffast-math 
> > > gives a slight overall CPU rise, while skipping -O3 gives me huge CPU 
> > > rise (20 bob~ filters are already to much for one core). Even when 
> > > skipping all of those flags, the denormals issue is still not present.
> > >
> > > Maybe it has something to do with the compiler?
> > >
> > >> Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr
> > >> Von: katja 
> > >> An: "Christof Ressi" , "pd-list@lists.iem.at" 
> > >> 
> > >> Betreff: Re: Re: [PD] [bob~] denormals issue?
> > >>
> > >> I'm curious to know if the flags do flush denormals on your processor.
> > >> Forgot to mention that '-O3 -ffast-math' are also set,
> > >> platform-independent. So if you have a chance to try which flag does
> > >> something... It's just curiosity.
> > >>
> > >> On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi  
> > >> wrote:
> > >> > Hi Katja,
> > >> >
> > >> >> Even if your test reveals a beneficial effect from compiler flags,
> > >> >> it is better when denormals are detected and flushed in the C code.
> > >> >
> > >> > definitely! Maybe using the PD_BIGORSMALL macro on each filter state 
> > >> > at the end of the DSP routine does the trick, just like in all the 
> > >> > other recursive filters in Pd.
> > >> >
> > >> >
> > >> >
> > >> >> Von: katja 
> > >> >> An: "Christof Ressi" 
> > >> >> Cc: pd-list , "Miller Puckette" 
> > >> >> Betreff: Re: [PD] [bob~] denormals issue?
> > >> >>
> > >> >> Hi Christof,
> > >> >>
> > >> >> Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
> > >> >> -mfpmath=sse' for optimization to the compiler on Windows. You could
> > >> >> try compiling without (some of) these flags to see if they are
> > >> >> responsible for the different behavior. Makefile-defined optimization
> > >> >> flags can be overriden with argument CFLAGS given on command line.
> > >> >>
> > >> >> The effect of optimization flags on denormals varies per processor
> > >> >> type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
> > >> >> wouldn't go away no matter what flags, is what I remember. Even if
> > >> >> your test reveals a beneficial effect from compiler flags, it is
> > >> >> better when denormals are detected and flushed in the C code. Anyway,
> > >> >> it is still interesting to know what makes the difference.
> > >> >>
> > >> >> Katja
> > >> >>
> > >> >> On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi 
> > >> >>  wrote:
> > >> >> > Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and 
> > >> >> > I noticed two things:
> > >> >> > 1) the CPU rise is gone
> > >> >> > 2) it needs only half the CPU. I put 20 [bob~] objects in a 
> > >> >> > switched subpatch and measured the CPU load. The DLL which comes 
> > >> >> > with the Windows binaries needs 15%, while my own DLL needs only 
> > >> >> > 7%! That's quite a deal...
> > >> >> >
> > >> >> > Christof
> > >> >> >
> > >> >> > PS: I attached the DLL in case you wanna try it yourself.
> > >> >> >
> > >> >> >
> > >> >> >> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr
> > >> >> >> Von: "Christof Ressi" 
> > >> >> >> An: pd-l...@iem.at, "Miller Puckette" 
> > >> >> >> Betreff: [PD] [bob~] denormals issue?
> > >> >> >>
> > >> >> >> Hi Miller,
> > >> >> >>
> > >> >> >> 

Re: [PD] configure fails for portaudio (Windows 7)

[Christof Ressi]

Hi Dan,

Miller just wrote:

> At the moment I'm compiling Pd using mingw but having to rely on
> Microsoft Visual C for "pd.lib" (apparently linker information) and
> all the eterns in "extra" - I never could get that part to work in
> mingw.

Apparently I'm not the only one who can't manage to get beyond the extra folder 
with MinGW ;-)
 
 

Gesendet: Mittwoch, 21. September 2016 um 20:32 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list@lists.iem.at
Betreff: Re: [PD] configure fails for portaudio (Windows 7)

Thanks for your patience. I added the missing flag to the configure.ac, so 
you’ll need to do the following again:
 
* make clean
* ./autogen
* ./configure
* make
 
:)
 


Dan Wilcox
@danomatika[https://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com] 

On Sep 21, 2016, at 9:49 AM, Christof Ressi 
 wrote: 

We're almost there ;-). Build fails in 'extra' (see attachment).


Gesendet: Mittwoch, 21. September 2016 um 16:23 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list@lists.iem.at[pd-list@lists.iem.at]
Betreff: Re: [PD] configure fails for portaudio (Windows 7)

Ok, try now.
 


Dan Wilcox
@danomatika[https://twitter.com/danomatika[https://twitter.com/danomatika]]
danomatika.com[http://danomatika.com][http://danomatika.com[http://danomatika.com]]
robotcowboy.com[http://robotcowboy.com][http://robotcowboy.com[http://robotcowboy.com]]
 

On Sep 21, 2016, at 3:10 AM, Christof Ressi 

 wrote: 

Hi Dan, tried building again, now it fails with a different error but still 
related to portaudio (see attachment).

Best, Christof

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [bob~] denormals issue?

[Christof Ressi]

I tried your patch with the [bob~] object shipped with the Windows binaries. I 
clearly get subnormals! It's actually no wonder because there isn't any 
protection against subnormals in the code (at least I couldn't spot it). 
But the weird thing is: the [bob~] I compiled myself would also show subnormals 
in your patch but the CPU load is not affected...

> Gesendet: Mittwoch, 21. September 2016 um 23:47 Uhr
> Von: katja 
> An: "Christof Ressi" 
> Cc: "pd-list@lists.iem.at" 
> Betreff: Re: Re: Re: [PD] [bob~] denormals issue?
>
> Without -O flags you get debug-level and all function inlining is
> disabled, depending on the code it can make a huge difference indeed.
> But Pd is probably compiled with at least -O2. So the flags don't make
> much difference. The compiler? Doesn't Miller compile with MinGW
> nowadays, I don't know. MinGW brings its own standard C libs, which
> may implement math functions differently than MS. But regarding
> denormals I guess they both respect the IEEE 754 standard.
> 
> You can check if you really have subnormals using attached patch
> denorm-test.pd you. The patch tests lop~, change it to bob~.
> 
> On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi  
> wrote:
> > the SSE optimizations don't seem to matter at all. skipping -ffast-math 
> > gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise 
> > (20 bob~ filters are already to much for one core). Even when skipping all 
> > of those flags, the denormals issue is still not present.
> >
> > Maybe it has something to do with the compiler?
> >
> >> Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr
> >> Von: katja 
> >> An: "Christof Ressi" , "pd-list@lists.iem.at" 
> >> 
> >> Betreff: Re: Re: [PD] [bob~] denormals issue?
> >>
> >> I'm curious to know if the flags do flush denormals on your processor.
> >> Forgot to mention that '-O3 -ffast-math' are also set,
> >> platform-independent. So if you have a chance to try which flag does
> >> something... It's just curiosity.
> >>
> >> On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi  
> >> wrote:
> >> > Hi Katja,
> >> >
> >> >> Even if your test reveals a beneficial effect from compiler flags,
> >> >> it is better when denormals are detected and flushed in the C code.
> >> >
> >> > definitely! Maybe using the PD_BIGORSMALL macro on each filter state at 
> >> > the end of the DSP routine does the trick, just like in all the other 
> >> > recursive filters in Pd.
> >> >
> >> >
> >> >
> >> >> Von: katja 
> >> >> An: "Christof Ressi" 
> >> >> Cc: pd-list , "Miller Puckette" 
> >> >> Betreff: Re: [PD] [bob~] denormals issue?
> >> >>
> >> >> Hi Christof,
> >> >>
> >> >> Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
> >> >> -mfpmath=sse' for optimization to the compiler on Windows. You could
> >> >> try compiling without (some of) these flags to see if they are
> >> >> responsible for the different behavior. Makefile-defined optimization
> >> >> flags can be overriden with argument CFLAGS given on command line.
> >> >>
> >> >> The effect of optimization flags on denormals varies per processor
> >> >> type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
> >> >> wouldn't go away no matter what flags, is what I remember. Even if
> >> >> your test reveals a beneficial effect from compiler flags, it is
> >> >> better when denormals are detected and flushed in the C code. Anyway,
> >> >> it is still interesting to know what makes the difference.
> >> >>
> >> >> Katja
> >> >>
> >> >> On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi 
> >> >>  wrote:
> >> >> > Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I 
> >> >> > noticed two things:
> >> >> > 1) the CPU rise is gone
> >> >> > 2) it needs only half the CPU. I put 20 [bob~] objects in a switched 
> >> >> > subpatch and measured the CPU load. The DLL which comes with the 
> >> >> > Windows binaries needs 15%, while my own DLL needs only 7%! That's 
> >> >> > quite a deal...
> >> >> >
> >> >> > Christof
> >> >> >
> >> >> > PS: I attached the DLL in case you wanna try it yourself.
> >> >> >
> >> >> >
> >> >> >> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr
> >> >> >> Von: "Christof Ressi" 
> >> >> >> An: pd-l...@iem.at, "Miller Puckette" 
> >> >> >> Betreff: [PD] [bob~] denormals issue?
> >> >> >>
> >> >> >> Hi Miller,
> >> >> >>
> >> >> >> feeding audio into [bob~] and then going to zero will increase the 
> >> >> >> CPU load by ca. 6%. Clearing the filter or adding a tiny amount of 
> >> >> >> noise brings the CPU load back to its usual level immediately, so I 
> >> >> >> guess it's a problem with denormals.
> >> >> >> My Pd load meter won't really 

Re: [PD] [bob~] denormals issue?

[Miller Puckette]

At the moment I'm compiling Pd using mingw but having to rely on
Microsoft Visual C for "pd.lib" (apparently linker information) and
all the eterns in "extra" - I never could get that part to work in
mingw.  I think it's time I tried again to get everything moved over to
mingw, especially since it's apparently generating much faster code.

Probably wont be able to do and test this till I get back to a windows
machine, perhaps January...

M

On Wed, Sep 21, 2016 at 11:47:14PM +0200, katja wrote:
> Without -O flags you get debug-level and all function inlining is
> disabled, depending on the code it can make a huge difference indeed.
> But Pd is probably compiled with at least -O2. So the flags don't make
> much difference. The compiler? Doesn't Miller compile with MinGW
> nowadays, I don't know. MinGW brings its own standard C libs, which
> may implement math functions differently than MS. But regarding
> denormals I guess they both respect the IEEE 754 standard.
> 
> You can check if you really have subnormals using attached patch
> denorm-test.pd you. The patch tests lop~, change it to bob~.
> 
> On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi  
> wrote:
> > the SSE optimizations don't seem to matter at all. skipping -ffast-math 
> > gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise 
> > (20 bob~ filters are already to much for one core). Even when skipping all 
> > of those flags, the denormals issue is still not present.
> >
> > Maybe it has something to do with the compiler?
> >
> >> Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr
> >> Von: katja 
> >> An: "Christof Ressi" , "pd-list@lists.iem.at" 
> >> 
> >> Betreff: Re: Re: [PD] [bob~] denormals issue?
> >>
> >> I'm curious to know if the flags do flush denormals on your processor.
> >> Forgot to mention that '-O3 -ffast-math' are also set,
> >> platform-independent. So if you have a chance to try which flag does
> >> something... It's just curiosity.
> >>
> >> On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi  
> >> wrote:
> >> > Hi Katja,
> >> >
> >> >> Even if your test reveals a beneficial effect from compiler flags,
> >> >> it is better when denormals are detected and flushed in the C code.
> >> >
> >> > definitely! Maybe using the PD_BIGORSMALL macro on each filter state at 
> >> > the end of the DSP routine does the trick, just like in all the other 
> >> > recursive filters in Pd.
> >> >
> >> >
> >> >
> >> >> Von: katja 
> >> >> An: "Christof Ressi" 
> >> >> Cc: pd-list , "Miller Puckette" 
> >> >> Betreff: Re: [PD] [bob~] denormals issue?
> >> >>
> >> >> Hi Christof,
> >> >>
> >> >> Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
> >> >> -mfpmath=sse' for optimization to the compiler on Windows. You could
> >> >> try compiling without (some of) these flags to see if they are
> >> >> responsible for the different behavior. Makefile-defined optimization
> >> >> flags can be overriden with argument CFLAGS given on command line.
> >> >>
> >> >> The effect of optimization flags on denormals varies per processor
> >> >> type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
> >> >> wouldn't go away no matter what flags, is what I remember. Even if
> >> >> your test reveals a beneficial effect from compiler flags, it is
> >> >> better when denormals are detected and flushed in the C code. Anyway,
> >> >> it is still interesting to know what makes the difference.
> >> >>
> >> >> Katja
> >> >>
> >> >> On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi 
> >> >>  wrote:
> >> >> > Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I 
> >> >> > noticed two things:
> >> >> > 1) the CPU rise is gone
> >> >> > 2) it needs only half the CPU. I put 20 [bob~] objects in a switched 
> >> >> > subpatch and measured the CPU load. The DLL which comes with the 
> >> >> > Windows binaries needs 15%, while my own DLL needs only 7%! That's 
> >> >> > quite a deal...
> >> >> >
> >> >> > Christof
> >> >> >
> >> >> > PS: I attached the DLL in case you wanna try it yourself.
> >> >> >
> >> >> >
> >> >> >> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr
> >> >> >> Von: "Christof Ressi" 
> >> >> >> An: pd-l...@iem.at, "Miller Puckette" 
> >> >> >> Betreff: [PD] [bob~] denormals issue?
> >> >> >>
> >> >> >> Hi Miller,
> >> >> >>
> >> >> >> feeding audio into [bob~] and then going to zero will increase the 
> >> >> >> CPU load by ca. 6%. Clearing the filter or adding a tiny amount of 
> >> >> >> noise brings the CPU load back to its usual level immediately, so I 
> >> >> >> guess it's a problem with denormals.
> >> >> >> My Pd load meter won't really show the increase, but it's clearly 
> >> >> >> visibly on Process Explorer.
> >> >> >>
> >> >> >> See 

Re: [PD] Tcl error for [knob] and [mknob]

[Christof Ressi]

> Of course I would be honored to include mknob (say Add/Knob shift+ctrl+K...) 
> to Pd,
> if authors agree, which would avoid such issue in the future !
 
that would be too good to be true!
 
 

Gesendet: Mittwoch, 21. September 2016 um 23:39 Uhr
Von: "Antoine Rousseau" 
An: "Christof Ressi" 
Cc: "Antoine Rousseau" , Pd-list 
Betreff: Re: Re: [PD] Tcl error for [knob] and [mknob]

Thanks !and thanks to Dan too, pointing me directly to the right direction !But 
I realize that if I fix mknob for latest Pd it will become incompatible with 
older ones... Not sure what to do then. Maybe I'll have to upload a new version 
to Deken specifying (in its name) which Pd version to use. Not very 
comfortable... but all of this is only transitional.
 
Of course I would be honored to include mknob (say Add/Knob shift+ctrl+K...) to 
Pd, if authors agree, which would avoid such issue in the future ! I could 
propose a push request to github, or a diff as preferred.
 
 
2016-09-21 22:22 GMT+02:00 Christof Ressi :Thanks a lot! 
By the way, mknob is just awesome! :-)
 
 

Gesendet: Mittwoch, 21. September 2016 um 21:51 Uhr
Von: "Antoine Rousseau" 
An: "Christof Ressi" 
Cc: Pd-list 
Betreff: Re: [PD] Tcl error for [knob] and [mknob]

Thanks Christof, i'll try to fix mknob soon.
 
2016-09-21 12:16 GMT+02:00 Christof Ressi 
:Thanks Dan! I filed an issue on 
MetaluNet/moonlib.
 
 

Gesendet: Mittwoch, 21. September 2016 um 05:20 Uhr
Von: "Dan Wilcox" 

An: "Lucas Cordiviola" 

Cc: 
pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]
Betreff: Re: [PD] Tcl error for [knob] and [mknob]

(reposting as I forgot to update subject line) 
 The color format saving & loading was updated recently: 
https://github.com/pure-data/pure-data/commit/6af3739b2284cfd53ad0ca8eeb2d3c450767e77b[https://github.com/pure-data/pure-data/commit/6af3739b2284cfd53ad0ca8eeb2d3c450767e77b][https://github.com/pure-data/pure-data/commit/6af3739b2284cfd53ad0ca8eeb2d3c450767e77b[https://github.com/pure-data/pure-data/commit/6af3739b2284cfd53ad0ca8eeb2d3c450767e77b]]
 
I’m sure the externs need to be updated to handle this.
 


Dan Wilcox
@danomatika[https://twitter.com/danomatika[https://twitter.com/danomatika][https://twitter.com/danomatika[https://twitter.com/danomatika]]]
danomatika.com[http://danomatika.com][http://danomatika.com[http://danomatika.com]][http://danomatika.com[http://danomatika.com][http://danomatika.com[http://danomatika.com]]]
robotcowboy.com[http://robotcowboy.com][http://robotcowboy.com[http://robotcowboy.com]][http://robotcowboy.com[http://robotcowboy.com][http://robotcowboy.com[http://robotcowboy.com]]]
 

On Sep 20, 2016, at 9:15 PM, 
pd-list-requ...@lists.iem.at[pd-list-requ...@lists.iem.at][pd-list-requ...@lists.iem.at[pd-list-requ...@lists.iem.at]][pd-list-requ...@lists.iem.at[pd-list-requ...@lists.iem.at][pd-list-requ...@lists.iem.at[pd-list-requ...@lists.iem.at]]]
 wrote: 

From: Lucas Cordiviola 

Subject: Re: [PD] Tcl error for [knob] and [mknob]
Date: September 20, 2016 at 8:17:06 PM MDT
To: Christof Ressi 
,
 
"pd-l...@iem.at[pd-l...@iem.at][pd-l...@iem.at[pd-l...@iem.at]][pd-l...@iem.at[pd-l...@iem.at][pd-l...@iem.at[pd-l...@iem.at]]]"
 

 
 

Win 8.1
 
[knob] and [mknob]
 
warning:external GUI object uses obsolete Pd function iemgui_all_colfromload()
 
Seems that they work but we cant set the colors. If you connect [numberboxes] 
they work.___ 
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]
 mailing list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list][https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]][https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list][https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]]]

___

Re: [PD] [bob~] denormals issue?

[katja]

Without -O flags you get debug-level and all function inlining is
disabled, depending on the code it can make a huge difference indeed.
But Pd is probably compiled with at least -O2. So the flags don't make
much difference. The compiler? Doesn't Miller compile with MinGW
nowadays, I don't know. MinGW brings its own standard C libs, which
may implement math functions differently than MS. But regarding
denormals I guess they both respect the IEEE 754 standard.

You can check if you really have subnormals using attached patch
denorm-test.pd you. The patch tests lop~, change it to bob~.

On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi  wrote:
> the SSE optimizations don't seem to matter at all. skipping -ffast-math gives 
> a slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ 
> filters are already to much for one core). Even when skipping all of those 
> flags, the denormals issue is still not present.
>
> Maybe it has something to do with the compiler?
>
>> Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr
>> Von: katja 
>> An: "Christof Ressi" , "pd-list@lists.iem.at" 
>> 
>> Betreff: Re: Re: [PD] [bob~] denormals issue?
>>
>> I'm curious to know if the flags do flush denormals on your processor.
>> Forgot to mention that '-O3 -ffast-math' are also set,
>> platform-independent. So if you have a chance to try which flag does
>> something... It's just curiosity.
>>
>> On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi  
>> wrote:
>> > Hi Katja,
>> >
>> >> Even if your test reveals a beneficial effect from compiler flags,
>> >> it is better when denormals are detected and flushed in the C code.
>> >
>> > definitely! Maybe using the PD_BIGORSMALL macro on each filter state at 
>> > the end of the DSP routine does the trick, just like in all the other 
>> > recursive filters in Pd.
>> >
>> >
>> >
>> >> Von: katja 
>> >> An: "Christof Ressi" 
>> >> Cc: pd-list , "Miller Puckette" 
>> >> Betreff: Re: [PD] [bob~] denormals issue?
>> >>
>> >> Hi Christof,
>> >>
>> >> Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
>> >> -mfpmath=sse' for optimization to the compiler on Windows. You could
>> >> try compiling without (some of) these flags to see if they are
>> >> responsible for the different behavior. Makefile-defined optimization
>> >> flags can be overriden with argument CFLAGS given on command line.
>> >>
>> >> The effect of optimization flags on denormals varies per processor
>> >> type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
>> >> wouldn't go away no matter what flags, is what I remember. Even if
>> >> your test reveals a beneficial effect from compiler flags, it is
>> >> better when denormals are detected and flushed in the C code. Anyway,
>> >> it is still interesting to know what makes the difference.
>> >>
>> >> Katja
>> >>
>> >> On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi  
>> >> wrote:
>> >> > Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I 
>> >> > noticed two things:
>> >> > 1) the CPU rise is gone
>> >> > 2) it needs only half the CPU. I put 20 [bob~] objects in a switched 
>> >> > subpatch and measured the CPU load. The DLL which comes with the 
>> >> > Windows binaries needs 15%, while my own DLL needs only 7%! That's 
>> >> > quite a deal...
>> >> >
>> >> > Christof
>> >> >
>> >> > PS: I attached the DLL in case you wanna try it yourself.
>> >> >
>> >> >
>> >> >> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr
>> >> >> Von: "Christof Ressi" 
>> >> >> An: pd-l...@iem.at, "Miller Puckette" 
>> >> >> Betreff: [PD] [bob~] denormals issue?
>> >> >>
>> >> >> Hi Miller,
>> >> >>
>> >> >> feeding audio into [bob~] and then going to zero will increase the CPU 
>> >> >> load by ca. 6%. Clearing the filter or adding a tiny amount of noise 
>> >> >> brings the CPU load back to its usual level immediately, so I guess 
>> >> >> it's a problem with denormals.
>> >> >> My Pd load meter won't really show the increase, but it's clearly 
>> >> >> visibly on Process Explorer.
>> >> >>
>> >> >> See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, 
>> >> >> Windows 7.
>> >> >>
>> >> >> Christof___
>> >> >> Pd-list@lists.iem.at mailing list
>> >> >> UNSUBSCRIBE and account-management -> 
>> >> >> https://lists.puredata.info/listinfo/pd-list
>> >> >>
>> >> > ___
>> >> > Pd-list@lists.iem.at mailing list
>> >> > UNSUBSCRIBE and account-management -> 
>> >> > https://lists.puredata.info/listinfo/pd-list
>> >> >
>> >>
>>
#N canvas 129 301 620 382 10;
#X symbolatom 18 351 72 0 0 0 - - -;
#X obj 18 323 makefilename %.70f;
#N canvas 0 50 190 245 nan 0;
#X obj 45 17 inlet;
#X obj 46 173 

Re: [PD] Tcl error for [knob] and [mknob]

[Antoine Rousseau]

Thanks !
and thanks to Dan too, pointing me directly to the right direction !
But I realize that if I fix mknob for latest Pd it will become incompatible
with older ones... Not sure what to do then. Maybe I'll have to upload a
new version to Deken specifying (in its name) which Pd version to use. Not
very comfortable... but all of this is only transitional.

Of course I would be honored to include mknob (say Add/Knob
shift+ctrl+K...) to Pd, if authors agree, which would avoid such issue in
the future ! I could propose a push request to github, or a diff as
preferred.


2016-09-21 22:22 GMT+02:00 Christof Ressi :

> Thanks a lot! By the way, mknob is just awesome! :-)
>
>
>
> Gesendet: Mittwoch, 21. September 2016 um 21:51 Uhr
> Von: "Antoine Rousseau" 
> An: "Christof Ressi" 
> Cc: Pd-list 
> Betreff: Re: [PD] Tcl error for [knob] and [mknob]
>
> Thanks Christof, i'll try to fix mknob soon.
>
> 2016-09-21 12:16 GMT+02:00 Christof Ressi :Thanks
> Dan! I filed an issue on MetaluNet/moonlib.
>
>
>
> Gesendet: Mittwoch, 21. September 2016 um 05:20 Uhr
> Von: "Dan Wilcox" 
> An: "Lucas Cordiviola" 
> Cc: pd-list@lists.iem.at[pd-list@lists.iem.at]
> Betreff: Re: [PD] Tcl error for [knob] and [mknob]
>
> (reposting as I forgot to update subject line)
>  The color format saving & loading was updated recently:
> https://github.com/pure-data/pure-data/commit/
> 6af3739b2284cfd53ad0ca8eeb2d3c450767e77b[https://github.com/
> pure-data/pure-data/commit/6af3739b2284cfd53ad0ca8eeb2d3c450767e77b]
>
> I’m sure the externs need to be updated to handle this.
>
>
> 
> Dan Wilcox
> @danomatika[https://twitter.com/danomatika[https://twitter.com/danomatika]
> ]
> danomatika.com[http://danomatika.com][http://danomatika.com[http://
> danomatika.com]]
> robotcowboy.com[http://robotcowboy.com][http://robotcowboy.com[http://
> robotcowboy.com]]
>
> On Sep 20, 2016, at 9:15 PM, pd-list-requ...@lists.iem.at[p
> d-list-requ...@lists.iem.at][pd-list-requ...@lists.iem.at[pd
> -list-requ...@lists.iem.at]] wrote:
>
> From: Lucas Cordiviola  lucard...@hotmail.com[lucard...@hotmail.com]]>
> Subject: Re: [PD] Tcl error for [knob] and [mknob]
> Date: September 20, 2016 at 8:17:06 PM MDT
> To: Christof Ressi  re...@gmx.at[christof.re...@gmx.at]]>, "pd-l...@iem.at[pd-l...@iem.at][
> pd-l...@iem.at[pd-l...@iem.at]]"  pd-l...@iem.at[pd-l...@iem.at]]>
>
>
> Win 8.1
>
> [knob] and [mknob]
>
> warning:external GUI object uses obsolete Pd function
> iemgui_all_colfromload()
>
> Seems that they work but we cant set the colors. If you connect
> [numberboxes] they work.___
> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and
> account-management -> https://lists.puredata.info/
> listinfo/pd-list[https://lists.puredata.info/listinfo/
> pd-list][https://lists.puredata.info/listinfo/pd-
> list[https://lists.puredata.info/listinfo/pd-list]]
>
> ___
> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>
>
> --
>
> Antoine Rousseau
>   http://www.metalu.net[http://metalu.net] __ http://www.
> metaluachahuter.com/[http://www.metaluachahuter.com/compagnies/al1-ant1/]
>
>
>


-- 
Antoine Rousseau
  http://www.metalu.net  __
http://www.metaluachahuter.com/

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [bob~] denormals issue?

[Christof Ressi]

the SSE optimizations don't seem to matter at all. skipping -ffast-math gives a 
slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ 
filters are already to much for one core). Even when skipping all of those 
flags, the denormals issue is still not present. 

Maybe it has something to do with the compiler?

> Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr
> Von: katja 
> An: "Christof Ressi" , "pd-list@lists.iem.at" 
> 
> Betreff: Re: Re: [PD] [bob~] denormals issue?
>
> I'm curious to know if the flags do flush denormals on your processor.
> Forgot to mention that '-O3 -ffast-math' are also set,
> platform-independent. So if you have a chance to try which flag does
> something... It's just curiosity.
> 
> On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi  
> wrote:
> > Hi Katja,
> >
> >> Even if your test reveals a beneficial effect from compiler flags,
> >> it is better when denormals are detected and flushed in the C code.
> >
> > definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the 
> > end of the DSP routine does the trick, just like in all the other recursive 
> > filters in Pd.
> >
> >
> >
> >> Von: katja 
> >> An: "Christof Ressi" 
> >> Cc: pd-list , "Miller Puckette" 
> >> Betreff: Re: [PD] [bob~] denormals issue?
> >>
> >> Hi Christof,
> >>
> >> Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
> >> -mfpmath=sse' for optimization to the compiler on Windows. You could
> >> try compiling without (some of) these flags to see if they are
> >> responsible for the different behavior. Makefile-defined optimization
> >> flags can be overriden with argument CFLAGS given on command line.
> >>
> >> The effect of optimization flags on denormals varies per processor
> >> type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
> >> wouldn't go away no matter what flags, is what I remember. Even if
> >> your test reveals a beneficial effect from compiler flags, it is
> >> better when denormals are detected and flushed in the C code. Anyway,
> >> it is still interesting to know what makes the difference.
> >>
> >> Katja
> >>
> >> On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi  
> >> wrote:
> >> > Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I 
> >> > noticed two things:
> >> > 1) the CPU rise is gone
> >> > 2) it needs only half the CPU. I put 20 [bob~] objects in a switched 
> >> > subpatch and measured the CPU load. The DLL which comes with the Windows 
> >> > binaries needs 15%, while my own DLL needs only 7%! That's quite a 
> >> > deal...
> >> >
> >> > Christof
> >> >
> >> > PS: I attached the DLL in case you wanna try it yourself.
> >> >
> >> >
> >> >> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr
> >> >> Von: "Christof Ressi" 
> >> >> An: pd-l...@iem.at, "Miller Puckette" 
> >> >> Betreff: [PD] [bob~] denormals issue?
> >> >>
> >> >> Hi Miller,
> >> >>
> >> >> feeding audio into [bob~] and then going to zero will increase the CPU 
> >> >> load by ca. 6%. Clearing the filter or adding a tiny amount of noise 
> >> >> brings the CPU load back to its usual level immediately, so I guess 
> >> >> it's a problem with denormals.
> >> >> My Pd load meter won't really show the increase, but it's clearly 
> >> >> visibly on Process Explorer.
> >> >>
> >> >> See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, 
> >> >> Windows 7.
> >> >>
> >> >> Christof___
> >> >> Pd-list@lists.iem.at mailing list
> >> >> UNSUBSCRIBE and account-management -> 
> >> >> https://lists.puredata.info/listinfo/pd-list
> >> >>
> >> > ___
> >> > Pd-list@lists.iem.at mailing list
> >> > UNSUBSCRIBE and account-management -> 
> >> > https://lists.puredata.info/listinfo/pd-list
> >> >
> >>
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [bob~] denormals issue?

[Christof Ressi]

Hi Katja, 

> Even if your test reveals a beneficial effect from compiler flags, 
> it is better when denormals are detected and flushed in the C code.

definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end 
of the DSP routine does the trick, just like in all the other recursive filters 
in Pd.



> Von: katja 
> An: "Christof Ressi" 
> Cc: pd-list , "Miller Puckette" 
> Betreff: Re: [PD] [bob~] denormals issue?
>
> Hi Christof,
> 
> Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
> -mfpmath=sse' for optimization to the compiler on Windows. You could
> try compiling without (some of) these flags to see if they are
> responsible for the different behavior. Makefile-defined optimization
> flags can be overriden with argument CFLAGS given on command line.
> 
> The effect of optimization flags on denormals varies per processor
> type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
> wouldn't go away no matter what flags, is what I remember. Even if
> your test reveals a beneficial effect from compiler flags, it is
> better when denormals are detected and flushed in the C code. Anyway,
> it is still interesting to know what makes the difference.
> 
> Katja
> 
> On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi  
> wrote:
> > Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I 
> > noticed two things:
> > 1) the CPU rise is gone
> > 2) it needs only half the CPU. I put 20 [bob~] objects in a switched 
> > subpatch and measured the CPU load. The DLL which comes with the Windows 
> > binaries needs 15%, while my own DLL needs only 7%! That's quite a deal...
> >
> > Christof
> >
> > PS: I attached the DLL in case you wanna try it yourself.
> >
> >
> >> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr
> >> Von: "Christof Ressi" 
> >> An: pd-l...@iem.at, "Miller Puckette" 
> >> Betreff: [PD] [bob~] denormals issue?
> >>
> >> Hi Miller,
> >>
> >> feeding audio into [bob~] and then going to zero will increase the CPU 
> >> load by ca. 6%. Clearing the filter or adding a tiny amount of noise 
> >> brings the CPU load back to its usual level immediately, so I guess it's a 
> >> problem with denormals.
> >> My Pd load meter won't really show the increase, but it's clearly visibly 
> >> on Process Explorer.
> >>
> >> See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 
> >> 7.
> >>
> >> Christof___
> >> Pd-list@lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> https://lists.puredata.info/listinfo/pd-list
> >>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list
> >
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [bob~] denormals issue?

[katja]

Hi Christof,

Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
-mfpmath=sse' for optimization to the compiler on Windows. You could
try compiling without (some of) these flags to see if they are
responsible for the different behavior. Makefile-defined optimization
flags can be overriden with argument CFLAGS given on command line.

The effect of optimization flags on denormals varies per processor
type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
wouldn't go away no matter what flags, is what I remember. Even if
your test reveals a beneficial effect from compiler flags, it is
better when denormals are detected and flushed in the C code. Anyway,
it is still interesting to know what makes the difference.

Katja

On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi  wrote:
> Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed 
> two things:
> 1) the CPU rise is gone
> 2) it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch 
> and measured the CPU load. The DLL which comes with the Windows binaries 
> needs 15%, while my own DLL needs only 7%! That's quite a deal...
>
> Christof
>
> PS: I attached the DLL in case you wanna try it yourself.
>
>
>> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr
>> Von: "Christof Ressi" 
>> An: pd-l...@iem.at, "Miller Puckette" 
>> Betreff: [PD] [bob~] denormals issue?
>>
>> Hi Miller,
>>
>> feeding audio into [bob~] and then going to zero will increase the CPU load 
>> by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the 
>> CPU load back to its usual level immediately, so I guess it's a problem with 
>> denormals.
>> My Pd load meter won't really show the increase, but it's clearly visibly on 
>> Process Explorer.
>>
>> See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7.
>>
>> Christof___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Tcl error for [knob] and [mknob]

[Antoine Rousseau]

Thanks Christof, i'll try to fix mknob soon.

2016-09-21 12:16 GMT+02:00 Christof Ressi :

> Thanks Dan! I filed an issue on MetaluNet/moonlib.
>
>
>
> Gesendet: Mittwoch, 21. September 2016 um 05:20 Uhr
> Von: "Dan Wilcox" 
> An: "Lucas Cordiviola" 
> Cc: pd-list@lists.iem.at
> Betreff: Re: [PD] Tcl error for [knob] and [mknob]
>
> (reposting as I forgot to update subject line)
>  The color format saving & loading was updated recently:
> https://github.com/pure-data/pure-data/commit/
> 6af3739b2284cfd53ad0ca8eeb2d3c450767e77b
>
> I’m sure the externs need to be updated to handle this.
>
>
> 
> Dan Wilcox
> @danomatika[https://twitter.com/danomatika]
> danomatika.com[http://danomatika.com]
> robotcowboy.com[http://robotcowboy.com]
>
> On Sep 20, 2016, at 9:15 PM, pd-list-requ...@lists.iem.at[p
> d-list-requ...@lists.iem.at] wrote:
>
> From: Lucas Cordiviola 
> Subject: Re: [PD] Tcl error for [knob] and [mknob]
> Date: September 20, 2016 at 8:17:06 PM MDT
> To: Christof Ressi , "
> pd-l...@iem.at[pd-l...@iem.at]" 
>
>
> Win 8.1
>
> [knob] and [mknob]
>
> warning:external GUI object uses obsolete Pd function
> iemgui_all_colfromload()
>
> Seems that they work but we cant set the colors. If you connect
> [numberboxes] they work.___
> Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list[https://
> lists.puredata.info/listinfo/pd-list]
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>



-- 
Antoine Rousseau
  http://www.metalu.net  __
http://www.metaluachahuter.com/

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] configure fails for portaudio (Windows 7)

[Christof Ressi]

I think it's the same error again...
 
 

Gesendet: Mittwoch, 21. September 2016 um 20:32 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list@lists.iem.at
Betreff: Re: [PD] configure fails for portaudio (Windows 7)

Thanks for your patience. I added the missing flag to the configure.ac, so 
you’ll need to do the following again:
 
* make clean
* ./autogen
* ./configure
* make
 
:)
 


Dan Wilcox
@danomatika[https://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com] 

On Sep 21, 2016, at 9:49 AM, Christof Ressi 
 wrote: 

We're almost there ;-). Build fails in 'extra' (see attachment).


Gesendet: Mittwoch, 21. September 2016 um 16:23 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list@lists.iem.at[pd-list@lists.iem.at]
Betreff: Re: [PD] configure fails for portaudio (Windows 7)

Ok, try now.
 


Dan Wilcox
@danomatika[https://twitter.com/danomatika[https://twitter.com/danomatika]]
danomatika.com[http://danomatika.com][http://danomatika.com[http://danomatika.com]]
robotcowboy.com[http://robotcowboy.com][http://robotcowboy.com[http://robotcowboy.com]]
 

On Sep 21, 2016, at 3:10 AM, Christof Ressi 

 wrote: 

Hi Dan, tried building again, now it fails with a different error but still 
related to portaudio (see attachment).

Best, Christofmake[3]: Verzeichnis „/c/pd_externals/pure-data/extra/bob~“ wird betreten
depbase=`echo bob~.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"pd\" 
-DPACKAGE_TARNAME=\"pd\" -DPACKAGE  
   
_VERSION=\"0.47.1\" -DPACKAGE_STRING=\"pd\ 0.47.1\" -DPACKAGE_BUGREPORT=\"\" 
-DPACKAGE_URL=\"\" -DPACKAGE=\"p
 
d\" -DVERSION=\"0.47.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_S  
   
TRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DLT_O  
   
BJDIR=\".libs/\" -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 
-DHAVE_MALLOC_H=1 -DHAVE_STDDEF_H=1 -DHA
 
VE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TIME_H=1 
-DHAVE_SYS_TIMEB_H=1 -DHAVE_UNISTD_H
 
=1 -DHAVE_ALLOCA=1 -Dvfork=fork -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 
-DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DRETSIG 

TYPE=void -DHAVE_DUP2=1 -DHAVE_FLOOR=1 -DHAVE_GETCWD=1 -DHAVE_GETTIMEOFDAY=1 
-DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1
  
-DHAVE_POW=1 -DHAVE_SQRT=1 -DHAVE_STRCHR=1 -DHAVE_STRERROR=1 -DHAVE_STRRCHR=1 
-DHAVE_STRSTR=1 -DHAVE_STRTOL=  
   
1 -I.  -I../../src -DPD   -O3 -ffast-math -funroll-loops -fomit-frame-pointer  
-MT bob~.lo -MD -MP -MF $depba  
   
se.Tpo -c -o bob~.lo bob~.c &&\
mv -f $depbase.Tpo $depbase.Plo
Xbob~.lo
libtool: warning: libobj name 'bob~.lo' may not contain shell special 
characters.
libtool: compile:  gcc -DPACKAGE_NAME=\"pd\" -DPACKAGE_TARNAME=\"pd\" 
-DPACKAGE_VERSION=\"0.47.1\" "-DPACKAGE 

_STRING=\"pd 0.47.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" 
-DPACKAGE=\"pd\" -DVERSION=\"0.47.1\" -DST  
   
DC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -   
  
DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
-DLT_OBJDIR=\".libs/\" -DSTDC_HEADE 

RS=1 -DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MALLOC_H=1 -DHAVE_STDDEF_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H   
  
=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMEB_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_ALLOCA=1 -Dvfork=fo
 
rk -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 
-DRETSIGTYPE=void -DHAVE_DUP2=1 -DHAV   
  
E_FLOOR=1 -DHAVE_GETCWD=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_MEMMOVE=1 
-DHAVE_MEMSET=1 -DHAVE_POW=1 -DHAVE_SQRT=1 -
 
DHAVE_STRCHR=1 -DHAVE_STRERROR=1 -DHAVE_STRRCHR=1 -DHAVE_STRSTR=1 
-DHAVE_STRTOL=1 -I. -I../../src -DPD -O3 -f  

Re: [PD] configure fails for portaudio (Windows 7)

[Dan Wilcox]

Thanks for your patience. I added the missing flag to the configure.ac, so 
you’ll need to do the following again:

* make clean
* ./autogen
* ./configure
* make

:)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Sep 21, 2016, at 9:49 AM, Christof Ressi  wrote:
> 
> We're almost there ;-). Build fails in 'extra' (see attachment).
> 
> 
> Gesendet: Mittwoch, 21. September 2016 um 16:23 Uhr
> Von: "Dan Wilcox" 
> An: "Christof Ressi" 
> Cc: pd-list@lists.iem.at
> Betreff: Re: [PD] configure fails for portaudio (Windows 7)
> 
> Ok, try now.
>  
> 
> 
> Dan Wilcox
> @danomatika[https://twitter.com/danomatika]
> danomatika.com[http://danomatika.com]
> robotcowboy.com[http://robotcowboy.com] 
> 
> On Sep 21, 2016, at 3:10 AM, Christof Ressi 
>  wrote: 
> 
> Hi Dan, tried building again, now it fails with a different error but still 
> related to portaudio (see attachment).
> 
> Best, Christof

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

Ok,
I`ve already said what I could say.



Mensaje telepatico asistido por maquinas.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2016-09-21 12:55 GMT-03:00 Fred Jan Kraan :

> I only try to keep a stable, backward compatible version
> available.
>

yeah, and it makes perfect sense then to just take it out if it is unstable.

as I said in this thread, me, derek and matt have been checking and working
on existing issues with cyclone - nothing made available yet. Fred Jan's
repo actually refers to our repo as the "active development" one, which is
https://github.com/porres/pd-cyclone/

We can try and see about this error, so whoever is willing to collaborate
sending examples and test reports, we could use this channel
https://github.com/porres/pd-cyclone/issues

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Fred Jan Kraan]

Hi Lucas,


> Can you test?
> 
> This worked ok with beta2, probably it will work on your new beta4.
>  
Don't confuse my attempt to produce a stable cyclone with maintenance in
the sense of adding features to its objects, others have appropriated
that role. I only try to keep a stable, backward compatible version
available.
> 
> Salutti,
> Lucarda.

Greetings,

Fred Jan
> 
> 
> Mensaje telepatico asistido por maquinas.
> 
> 
> 
> *From:* Pd-list  on behalf of Lucas
> Cordiviola 
> *Sent:* Tuesday, September 20, 2016 7:12 PM
> *To:* Fred Jan Kraan; Christof Ressi; por...@gmail.com
> *Cc:* pd-list@lists.iem.at
> *Subject:* Re: [PD] [coll] bug
>  
> 
> Ops,
> 
> I'm getting the error but only when opening the help patch. Not if using
> with or without the threaded option.
> 
> Testing with beta 2.
> 
> We should check the help patch.
> 
> 
> 
> 
> Mensaje telepatico asistido por maquinas.
> 
> 
> 
> *From:* Fred Jan Kraan 
> *Sent:* Tuesday, September 20, 2016 5:53 PM
> *To:* Lucas Cordiviola; Christof Ressi
> *Cc:* pd-list@lists.iem.at
> *Subject:* Re: [PD] [coll] bug
>  
> 
> 
> On 2016-09-20 07:28 PM, Lucas Cordiviola wrote:
>> @Christof
>> 
>> 
>> Thanx for the feedback.
>> 
>> 
>> @Fred
>> 
>> 
>> Thanx for the fix.
>> 
>> 
>> I was unable to get the error on beta 2, tested with win7-32, win8.1-64
>> and win10-64 (virtual machine). Seems to be only on win7-64 (I didn`t
>> test it).
> And Windows 10 32-bit, that is where I tested it and getting the same
> error. If I can't get it working properly on my build machine, I
> shouldn't distribute it.
>>  
>> Dan has mentioned something cool that could be used for threading:
>> 
>> https://lists.puredata.info/pipermail/pd-list/2016-09/116233.html
>> 
> What I expect is that it isn't the threading per se that causes the
> error, just the weird situation with the varying DLLs that have to be
> provided. I didn't like that at all.
>> 
>> may be in the future.
>> 
>> 
>> Salutti,
>> 
>> Lucarda.
> 
> Greetings,
> 
> Fred Jan
>> 
>> 
>> 
>> 
>> 
>> Mensaje telepatico asistido por maquinas.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] configure fails for portaudio (Windows 7)

[Christof Ressi]

We're almost there ;-). Build fails in 'extra' (see attachment).


Gesendet: Mittwoch, 21. September 2016 um 16:23 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list@lists.iem.at
Betreff: Re: [PD] configure fails for portaudio (Windows 7)

Ok, try now.
 


Dan Wilcox
@danomatika[https://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com] 

On Sep 21, 2016, at 3:10 AM, Christof Ressi 
 wrote: 

Hi Dan, tried building again, now it fails with a different error but still 
related to portaudio (see attachment).

Best, Christofmake[3]: Verzeichnis „/c/pd_externals/pure-data/extra/bob~“ wird betreten
depbase=`echo bob~.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"pd\" 
-DPACKAGE_TARNAME=\"pd\" -DPACKAGE_VERSION=\"0.47.1\" -DPACKAGE_STRING=\"pd\ 
0.47.1\"  
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"pd\" -DVERSION=\"0.47.1 
\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -
 DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE   
  _STDINT_H=1 -DHAVE_UNISTD_H=1 -DLT_OBJDIR=\".libs/\" 
-DSTDC_HEADERS=1 -DHAVE_FCN 
TL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MALLOC_H=1 -DHAVE_STDDEF_H=1 
-DHAVE_STDLIB_H=1 - 
DHAVE_STRING_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMEB_H=1 
- DHAVE_UNISTD_H=1 
-DHAVE_ALLOCA=1 -Dvfork=fork -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1  
-DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 
-DRETSIGTYPE=void -DHAVE_DUP2=1 -DHAVE_FLOOR=   
  1 -DHAVE_GETCWD=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_MEMMOVE=1 
-DHAVE_MEMSET=1 -DHAVE_ 
POW=1 -DHAVE_SQRT=1 -DHAVE_STRCHR=1 -DHAVE_STRERROR=1 -DHAVE_STRRCHR=1 
-DHAVE_ST RSTR=1 
-DHAVE_STRTOL=1 -I.  -I../../src -DPD   -O3 -ffast-math -funroll-loops -f   
  omit-frame-pointer  -MT 
bob~.lo -MD -MP -MF $depbase.Tpo -c -o bob~.lo bob~.c &&
 \
mv -f $depbase.Tpo $depbase.Plo
Xbob~.lo
libtool: warning: libobj name 'bob~.lo' may not contain shell special 
characters.
libtool: compile:  gcc -DPACKAGE_NAME=\"pd\" -DPACKAGE_TARNAME=\"pd\" 
-DPACKAGE_VERSION=\"0.47.1\" "-DPACKAGE_STRING=\"pd 0.47.1\"" 
-DPACKAGE_BUGREPORT=\"\" -DP
 ACKAGE_URL=\"\" -DPACKAGE=\"pd\" -DVERSION=\"0.47.1\" -DSTDC_HEADERS=1 
-DHAVE_SY S_TYPES_H=1 
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMOR
 Y_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
 -DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=1 
-DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHA 
VE_MALLOC_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_SYS_P  
   ARAM_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMEB_H=1 -DHAVE_UNISTD_H=1 
-DHAVE_ALLOC A=1 
-Dvfork=fork -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_REAL
 LOC=1 -DRETSIGTYPE=void 
-DHAVE_DUP2=1 -DHAVE_FLOOR=1 -DHAVE_GETCWD=1 -DHAVE_GETT
 IMEOFDAY=1 -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1 
-DHAVE_POW=1 -DHAVE_SQRT=1 -DHAVE_ST
 RCHR=1 -DHAVE_STRERROR=1 -DHAVE_STRRCHR=1 -DHAVE_STRSTR=1 
-DHAVE_STRTOL=1 -I. -I 
../../src -DPD -O3 -ffast-math -funroll-loops -fomit-frame-pointer -MT 
"bob~.lo"  -MD -MP -MF 
".deps/bob~.Tpo" -c "bob~.c"  -DDLL_EXPORT -DPIC -o .libs/bob~.o
libtool: compile:  gcc -DPACKAGE_NAME=\"pd\" -DPACKAGE_TARNAME=\"pd\" 
-DPACKAGE_VERSION=\"0.47.1\" "-DPACKAGE_STRING=\"pd 0.47.1\"" 
-DPACKAGE_BUGREPORT=\"\" -DP
 ACKAGE_URL=\"\" -DPACKAGE=\"pd\" -DVERSION=\"0.47.1\" -DSTDC_HEADERS=1 
-DHAVE_SY

Re: [PD] configure fails for portaudio (Windows 7)

[Dan Wilcox]

Ok, try now.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Sep 21, 2016, at 3:10 AM, Christof Ressi  wrote:
> 
> Hi Dan, tried building again, now it fails with a different error but still 
> related to portaudio (see attachment).
> 
> Best, Christof

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Tcl error for [knob] and [mknob]

[Christof Ressi]

Thanks Dan! I filed an issue on MetaluNet/moonlib.
 
 

Gesendet: Mittwoch, 21. September 2016 um 05:20 Uhr
Von: "Dan Wilcox" 
An: "Lucas Cordiviola" 
Cc: pd-list@lists.iem.at
Betreff: Re: [PD] Tcl error for [knob] and [mknob]

(reposting as I forgot to update subject line) 
 The color format saving & loading was updated recently: 
https://github.com/pure-data/pure-data/commit/6af3739b2284cfd53ad0ca8eeb2d3c450767e77b
 
I’m sure the externs need to be updated to handle this.
 


Dan Wilcox
@danomatika[https://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com] 

On Sep 20, 2016, at 9:15 PM, 
pd-list-requ...@lists.iem.at[pd-list-requ...@lists.iem.at] wrote: 

From: Lucas Cordiviola 
Subject: Re: [PD] Tcl error for [knob] and [mknob]
Date: September 20, 2016 at 8:17:06 PM MDT
To: Christof Ressi , 
"pd-l...@iem.at[pd-l...@iem.at]"  
 

Win 8.1
 
[knob] and [mknob]
 
warning:external GUI object uses obsolete Pd function iemgui_all_colfromload()
 
Seems that they work but we cant set the colors. If you connect [numberboxes] 
they work.___ Pd-list@lists.iem.at 
mailing list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] configure fails for portaudio (Windows 7)

[Christof Ressi]

Hi Dan, tried building again, now it fails with a different error but still 
related to portaudio (see attachment).

Best, Christof



 
 

Gesendet: Mittwoch, 21. September 2016 um 05:15 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list@lists.iem.at
Betreff: Re: [PD] configure fails for portaudio (Windows 7)

Can you pull, clean, run configure, and try building again? I just added the 
missing portaudio api.
 


Dan Wilcox
@danomatika[https://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com] 

On Sep 20, 2016, at 5:45 PM, Christof Ressi 
 wrote: 

Hi Dan! I tried your branch and 'configure' work now, however, I get an error 
with 'make':

portaudio/src/os/win/pa_win_wdmks_utils.c:53:51: fatal error: 
../../hostapi/wasapi/mingw-include/ks.h: No such file or directory
compilation terminated.
Makefile:719: die Regel für Ziel „portaudio/src/os/win/pa_win_wdmks_utils.lo“ 
scheiterte
make[2]: *** [portaudio/src/os/win/pa_win_wdmks_utils.lo] Fehler 1
make[2]: Verzeichnis „/c/pd_externals/pd/portaudio“ wird verlassen
Makefile:489: die Regel für Ziel „all-recursive“ scheiterte
make[1]: *** [all-recursive] Fehler 1
make[1]: Verzeichnis „/c/pd_externals/pd“ wird verlassen
Makefile:413: die Regel für Ziel „all“ scheiterte
make: *** [all] Fehler 2

Christof

 
 

Gesendet: Mittwoch, 21. September 2016 um 01:05 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list@lists.iem.at[pd-list@lists.iem.at]
Betreff: Re: [PD] configure fails for portaudio (Windows 7)

Can you try the “autotools_updates” branch from 
https://github.com/pure-data/pure-data/tree/autotools_updates?[https://github.com/pure-data/pure-data/tree/autotools_updates?]
 
I removed the separate step of calling configure on portaudio directly as we 
now handle it in a makefile instead.
 


Dan Wilcox
@danomatika[https://twitter.com/danomatika[https://twitter.com/danomatika]]
danomatika.com[http://danomatika.com][http://danomatika.com[http://danomatika.com]]
robotcowboy.com[http://robotcowboy.com][http://robotcowboy.com[http://robotcowboy.com]]
 

On Sep 20, 2016, at 3:40 PM, 
pd-list-requ...@lists.iem.at[pd-list-requ...@lists.iem.at][pd-list-requ...@lists.iem.at[pd-list-requ...@lists.iem.at]]
 wrote: 

From: "Christof Ressi" 

Subject: [PD] configure fails for portaudio (Windows 7)
Date: September 20, 2016 at 3:40:34 PM MDT
To: pd-l...@iem.at[pd-l...@iem.at][pd-l...@iem.at[pd-l...@iem.at]]

Hi list,

I've already build several Pd externals with MinGW on Windows 7 using the 
pd-lib-builder, but never build Pd itself from source for this platform. 
'configure' always fails for portaudio. The error message I get is this:

=== configuring in portaudio (/c/pd_externals/pd/portaudio)
configure: running /bin/sh m4/config/configure --disable-option-checking 
'--prefix=/usr/local'  --cache-file=/dev/null --srcdir=.
/bin/sh: m4/config/configure: No such file or directory
configure: error: m4/config/configure failed for portaudio

There is indeed no 'configure' in m4/config. Any idea what could be the 
problem? I attached the config.log, in case that helps...

Christofportaudio/src/os/win/pa_x86_plain_converters.c: In function 'Float32_To_Int32':
portaudio/src/os/win/pa_x86_plain_converters.c:171:10: error: expected '(' 
before '{' token
 __asm{
  ^
portaudio/src/os/win/pa_x86_plain_converters.c:179:9: error: unknown type name 
'mov'
 mov esi, sourceBuffer
 ^
portaudio/src/os/win/pa_x86_plain_converters.c:181:9: error: expected '=', ',', 
';', 'asm' or '__attribute__' before 'mov'
 mov edx, 4  // sizeof float32 and int32
 ^
portaudio/src/os/win/pa_x86_plain_converters.c:232:13: error: invalid storage 
class for function 'Float32_To_Int32_Clip'
 static void Float32_To_Int32_Clip(
 ^
portaudio/src/os/win/pa_x86_plain_converters.c: In function 
'Float32_To_Int32_Clip':
portaudio/src/os/win/pa_x86_plain_converters.c:258:10: error: expected '(' 
before '{' token
 __asm{
  ^
portaudio/src/os/win/pa_x86_plain_converters.c:266:9: error: unknown type name 
'mov'
 mov esi, sourceBuffer
 ^
portaudio/src/os/win/pa_x86_plain_converters.c:268:9: error: expected '=', ',', 
';', 'asm' or '__attribute__' before 'mov'
 mov edx, 4  // sizeof float32 and int32
 ^
portaudio/src/os/win/pa_x86_plain_converters.c:331:13: error: invalid storage 
class for function 'Float32_To_Int32_DitherClip'
 static void Float32_To_Int32_DitherClip(
 ^
portaudio/src/os/win/pa_x86_plain_converters.c: In function 
'Float32_To_Int32_DitherClip':
portaudio/src/os/win/pa_x86_plain_converters.c:366:10: error: