7 Mar
2003
7 Mar
'03
8:06 p.m.
http://plugin.org.uk/releases/0.3.7/
I've done a major code audit (with the help of valgrind :), and things are
a lot less crufty now.
There are still some outstanding known sound quality/noise/aliasing bugs,
I'l tackle them in the next release, but I'd appreciate more reports.
ChangeLog:
2003-02-23 Steve Harris <steve(a)plugin.org.uk>
* Fixed memory leak in gate
* Fixed filter implementation in gate
* Fixed key defaults in gate
* Made passes=0 work in GSM
* Added bandlimiting filter to GSM (less cruchy sounds)
2003-02-24 Steve Harris <steve(a)plugin.org.uk>
* Removed stale code from surround encoder
* Fixed memory leak in surround encoder
2003-02-24 Steve Harris <steve(a)plugin.org.uk>
* Fixed maths error in multiplexer
* Fixed buffer overrun in sifter
* Efficiency improvements to FAD delay
* Fixed infinite loop in FAD delay.
* Fixed (another) buffer overrun in FM oscillator
* Performance improvement for FM oscillator
* Fixed buffer overrun in multiband EQ
* Fixed aliasing in Hermes
* Fixed memory leaks in:
AM pitchshift
Analogue osc
Bode sifters
Comb
Comb splitter
Delayorama
Dyson compressor
FM oscilator
Giant flange
Gong
GVerb
Hermes filter
L/C/R delay
Multiband EQ
Plate reverb
Rate shifter
Retro flanger
Satan maximiser
SC*
Sifter
Single band parametric
Multiplexer
Tape delay
There are still known leaks in imp and the multiband EQ
8 Mar
8 Mar
6:33 a.m.
Thanks for another fine set of effects!
There are still some outstanding known sound
quality/noise/aliasing bugs,
I'l tackle them in the next release, but I'd appreciate more reports.
Multiband EQ
If I set faders to zero I still get gain, which causes distortion on stuff
that's already at 0dB.
SC*
I can't seem to get the compression on drums right using the SC compressors.
The quiet bits are reduced, just as the peaks are - maybe I just don't
understand the variables. Looks like you decided against calling them the
Steve's Compressor series, eh?
I can get the effect I want with Dyson Compressor by setting all the faders to
the right though. The SC series are better for multitrack situations where
you can choose not to have any makeup gain on each track - otherwise the
additive gain would be too great. I find Dyson easier to use for final stereo
mixes where you want them to be as loud as possible without introducing
clipping.
Cheers
Daniel
7:11 a.m.
On Sat, Mar 08, 2003 at 10:25:31 +0000, Daniel James wrote:
I think there is a problem with the envelope tracker that makes it too
sluggish for transients, also you probably want a peak folling compressor for
this task, SC4 was meant to be switchable RMS/peak, but I forgot to add
the code before releasing the first time.
I'l probably add it and give it a new uid. The envelope follower problem
still needs pinning down for all the SCs though.
Who said the're not Steve's Compressor ;)
- Steve
Thanks for another fine set of effects!
Yes, there is an incorrect scaling factor. Should be an easy fix, but I
haven't got round to it.
There are still some outstanding known sound
quality/noise/aliasing bugs,
I'l tackle them in the next release, but I'd appreciate more reports.
Multiband EQ
If I set faders to zero I still get gain, which causes distortion on stuff
that's already at 0dB. SC*
I can't seem to get the compression on drums right using the SC compressors.
The quiet bits are reduced, just as the peaks are - maybe I just don't
understand the variables. Looks like you decided against calling them the
Steve's Compressor series, eh?
7:41 a.m.
SC4 was meant to be switchable RMS/peak, but I forgot
to add
the code before releasing the first time.
ah - that would do it for drums, where the bass and snare peak levels are
always going to be relatively high. When mixing down our stuff, these are the
main cause of clipping - other than vocalists getting too close to the mic as
they reach the lung-bursting bit...
Who said the're not Steve's Compressor ;)
I think it would be a fine name for the series, in the tradition of Barry's
Satan Maximiser. That one gave our drummer a good laugh! If people don't know
what SC sounds for, they'll probably never try one.
Is your plugin metadata thing able to categorise plugins by group in
application menus? That way you could have all the compressors together, all
the flangers, all the reverbs etc. Could be easier to find what you're
looking for than strict alphabetical order.
Cheers
Daniel
8:03 a.m.
On Sat, Mar 08, 2003 at 11:33:16 +0000, Daniel James wrote:
Yes, thats the main point: http://www.ecs.soton.ac.uk/~swh/jrss.png
- Steve
Who said
the're not Steve's Compressor ;)
I think it would be a fine name for the series, in the tradition of Barry's
Satan Maximiser. That one gave our drummer a good laugh! If people don't know
what SC sounds for, they'll probably never try one.
Is your plugin metadata thing able to categorise plugins by group in
application menus? That way you could have all the compressors together, all
the flangers, all the reverbs etc. Could be easier to find what you're
looking for than strict alphabetical order. 
4:03 p.m.
Steve,
I'm having a problem compiling 0.3.7. I had no problem with 0.3.6.
Here's what I get during configure -
loading cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for fftw_one in -lsfftw... no
checking for fftw_one in -lfftw... no
configure: error: Could not find working fftw library. Package now
requires it
I have installed fftw-2.1.3. I have tried it installed in /usr and
/usr/local with the same results. Running gcc 2.96 on RH 7.3.
Jan
On Sat, 2003-03-08 at 05:55, Steve Harris wrote:
On Sat, Mar 08, 2003 at 11:33:16 +0000, Daniel James
wrote:
Yes, thats the main point: http://www.ecs.soton.ac.uk/~swh/jrss.png
- Steve
Who said
the're not Steve's Compressor ;)
I think it would be a fine name for the series, in the tradition of Barry's
Satan Maximiser. That one gave our drummer a good laugh! If people don't know
what SC sounds for, they'll probably never try one.
Is your plugin metadata thing able to categorise plugins by group in
application menus? That way you could have all the compressors together, all
the flangers, all the reverbs etc. Could be easier to find what you're
looking for than strict alphabetical order. 
4:54 p.m.
On Saturday 08 March 2003 21:29, Jan \"Evil Twin\" Depner wrote:
checking for fftw_one in -lsfftw... no
checking for fftw_one in -lfftw... no
configure: error: Could not find working fftw library. Package now
requires it
I have installed fftw-2.1.3. I have tried it installed in /usr and
/usr/local with the same results. Running gcc 2.96 on RH 7.3.
I've sometimes had some problems with the two header
naming conventions in fftw. There's an option for fftw's
configure-script to specify whether you want the header files
with or without type prefix. IIRC Red Hat 7.3 comes _with_
type prefix, so it might be that you have files drfftw.h and dfftw.h
for double-precision and/or srfftw.h & sfftw.h (was it?) for single precision.
FFTW's configure-script defaults to no prefix.
Maybe the swh-plugins configure-script is looking for files without
the 'd' or the 's': rfftw.h and fftw.h. When I was using 7.3 I just made
symlinks.
--
Jaakko Prättälä
Jaakko.Prattala(a)Helsinki.FI
7:22 p.m.
Jaakko,
It creates fftw.h and rfftw.h, no prefix. Of course, the big question
is why did it work in 0.3.6 and not in 0.3.7.
Jan
On Sat, 2003-03-08 at 14:45, Jaakko Prättälä wrote:
On Saturday 08 March 2003 21:29, Jan \"Evil
Twin\" Depner wrote:
checking for fftw_one in -lsfftw... no
checking for fftw_one in -lfftw... no
configure: error: Could not find working fftw library. Package now
requires it
I have installed fftw-2.1.3. I have tried it installed in /usr and
/usr/local with the same results. Running gcc 2.96 on RH 7.3.
I've sometimes had some problems with the two header
naming conventions in fftw. There's an option for fftw's
configure-script to specify whether you want the header files
with or without type prefix. IIRC Red Hat 7.3 comes _with_
type prefix, so it might be that you have files drfftw.h and dfftw.h
for double-precision and/or srfftw.h & sfftw.h (was it?) for single precision.
FFTW's configure-script defaults to no prefix.
Maybe the swh-plugins configure-script is looking for files without
the 'd' or the 's': rfftw.h and fftw.h. When I was using 7.3 I just made
symlinks.
--
Jaakko Prättälä
Jaakko.Prattala(a)Helsinki.FI
7:59 p.m.
On Sunday 09 March 2003 00:48, Jan \"Evil Twin\" Depner wrote:
Jaakko,
It creates fftw.h and rfftw.h, no prefix. Of course, the big question
is why did it work in 0.3.6 and not in 0.3.7.
Jan
Whoa, I got your message just seconds after I wrote the
"now I think I got it"-email. How typical.
Anyway I _did_ get the same error as you before
symlinking in the way I described earlier and now it
compiles.
--
Jaakko Prättälä
Jaakko.Prattala(a)Helsinki.FI
7:34 p.m.
On Saturday 08 March 2003 22:45, Jaakko Prättälä wrote:
On Saturday 08 March 2003 21:29, Jan \"Evil
Twin\" Depner wrote:
Or (now I think I've got it :-) maybe you have only the double precision
fftw with the 'd'-prefix, like I do? The swh configure script looks for
libsfftw and libfftw but not libdfftw.
I successfully compiled swh-plugins 0.3.7
after I made the following symlinks:
/usr/local/lib/libfftw.so -> /usr/local/lib/libdfftw.so
/usr/local/lib/librfftw.so -> /usr/local/lib/libdrfftw.so
/usr/local/include/fftw.h -> /usr/local/include/dfftw.h
/usr/local/include/rfftw.h -> /usr/local/include/drfftw.h
and ran ldconfig.
I think there'll be no problems with the precision since
(to my knowledge) double precision is fftw's default.
Maybe swh's configure-script should look for 'd'-prefixed files too?
--
Jaakko Prättälä
Jaakko.Prattala(a)Helsinki.FI
checking for fftw_one in -lsfftw... no
checking for fftw_one in -lfftw... no
Maybe the swh-plugins configure-script is
looking for files without
the 'd' or the 's': rfftw.h and fftw.h. When I was using 7.3 I just made
symlinks.
7:50 p.m.
I've got /usr/lib/libfftw.a, /usr/lib/libfftw.la, /usr/lib/librfftw.a,
and /usr/lib/librfftw.la.
Jan
On Sat, 2003-03-08 at 17:26, Jaakko Prättälä wrote:
On Saturday 08 March 2003 22:45, Jaakko Prättälä
wrote:
On Saturday 08 March 2003 21:29, Jan \"Evil
Twin\" Depner wrote:
Or (now I think I've got it :-) maybe you have only the double precision
fftw with the 'd'-prefix, like I do? The swh configure script looks for
libsfftw and libfftw but not libdfftw.
I successfully compiled swh-plugins 0.3.7
after I made the following symlinks:
/usr/local/lib/libfftw.so -> /usr/local/lib/libdfftw.so
/usr/local/lib/librfftw.so -> /usr/local/lib/libdrfftw.so
/usr/local/include/fftw.h -> /usr/local/include/dfftw.h
/usr/local/include/rfftw.h -> /usr/local/include/drfftw.h
and ran ldconfig.
I think there'll be no problems with the precision since
(to my knowledge) double precision is fftw's default.
Maybe swh's configure-script should look for 'd'-prefixed files too?
--
Jaakko Prättälä
Jaakko.Prattala(a)Helsinki.FI
checking for fftw_one in -lsfftw... no
checking for fftw_one in -lfftw... no
Maybe the swh-plugins configure-script is
looking for files without
the 'd' or the 's': rfftw.h and fftw.h. When I was using 7.3 I just made
symlinks.
10:05 p.m.
On Sun, Mar 09, 2003 at 01:26:38 +0200, Jaakko Prättälä wrote:
On Saturday 08 March 2003 22:45, Jaakko Prättälä
wrote:
I think single used to be the default. Double, /may/ work but it will be
slow if it does.
The FFTW people should really sort this out.
- Steve
On Saturday 08 March 2003 21:29, Jan \"Evil
Twin\" Depner wrote:
I think there'll be no problems with the precision since
(to my knowledge) double precision is fftw's default.
Maybe swh's configure-script should look for 'd'-prefixed files too? checking for fftw_one in -lsfftw... no
checking for fftw_one in -lfftw... no
Maybe the swh-plugins configure-script is
looking for files without
the 'd' or the 's': rfftw.h and fftw.h. When I was using 7.3 I just made
symlinks.
10 Mar
10 Mar
5:13 a.m.
On Sunday 09 March 2003 03:57, Steve Harris wrote:
On Sun, Mar 09, 2003 at 01:26:38 +0200, Jaakko
Prättälä wrote:
I totally agree, but the latest fftw
(2.1.3) release is
from 1999 :-)
I'm quite sure that
the default for fftw is _double_,
unless you specify --enable-float for the build.
Here are some findings
to support this presumption:
These babblings are not so relevant, but I included
them for completeness' sake...
<cryptic_cyberbabble>
- from the default fftw.h
(no configure-script options, fftw version 2.1.3):
/* Define for using single precision */
/*
* If you can, use configure --enable-float instead of changing this
* flag directly
*/
/* #undef FFTW_ENABLE_FLOAT */
/* our real numbers */
#ifdef FFTW_ENABLE_FLOAT
typedef float fftw_real;
#else
typedef double fftw_real;
#endif
- make |grep "FFTW_ENABLE_FLOAT" produces no output
other than compiler warnings.
</cryptic_cyberbabble>
...but the next says a lot:
- from the faq (fftw-2.1.3/FAQ/fftw-faq.ascii):
Question 2.9. How do I compile FFTW to run in single precision?
On a Unix system: configure --enable-float. On a non-Unix system: edit
fftw/fftw.h to #define the symbol FFTW_ENABLE_FLOAT. In both cases, you
must then recompile FFTW.
The logical solution would be to
build one's fftw with
./configure --enable-shared --enable-float --enable-type-prefix
and make non-prefixed symlinks to the double version.
In this case (I have symlinks to the shared lib),
Steve, your configure-script says
checking for fftw_one in -lsfftw... (cached) no
checking for fftw_one in -lfftw... (cached) yes
(strange)
so I guess it will link against the double-precision
version of the lib. I haven't gotten into testing
imp or pitch_scale yet, so I can't say if there are
any problems with this. Last night I tried out
delay-o-rama + flanger. Tapping a mic never
sounded so good :-)
--
Jaakko Prättälä
Jaakko.Prattala(a)Helsinki.FI
I think there'll be no problems with the precision since
(to my knowledge) double precision is fftw's default.
Maybe swh's configure-script should look for 'd'-prefixed files too?
I think single used to be the default. Double, /may/ work but it will be
slow if it does.
The FFTW people should really sort this out.
11 Mar
11 Mar
7:33 a.m.
On Mon, Mar 10, 2003 at 11:05:26 +0200, Jaakko Prättälä wrote:
OK, well in that case it almost certainly does work, 'cos I've not had
reports of segfaults. My code must be more generic than I think :)
- Steve
The FFTW
people should really sort this out.
I totally agree, but the latest fftw (2.1.3)
release is
from 1999 :-)
I'm quite sure that
the default for fftw is _double_,
unless you specify --enable-float for the build.
8 Mar
8 Mar
7:20 p.m.
Steve,
Here it is.
Jan
On Sat, 2003-03-08 at 13:29, Jan "Evil Twin" Depner wrote:
Steve,
I'm having a problem compiling 0.3.7. I had no problem with 0.3.6.
Here's what I get during configure -
loading cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for fftw_one in -lsfftw... no
checking for fftw_one in -lfftw... no
configure: error: Could not find working fftw library. Package now
requires it
I have installed fftw-2.1.3. I have tried it installed in /usr and
/usr/local with the same results. Running gcc 2.96 on RH 7.3.
Jan
On Sat, 2003-03-08 at 05:55, Steve Harris wrote:
On Sat, Mar 08, 2003 at 11:33:16 +0000, Daniel
James wrote:
Yes, thats the main point: http://www.ecs.soton.ac.uk/~swh/jrss.png
- Steve
Who said
the're not Steve's Compressor ;)
I think it would be a fine name for the series, in the tradition of Barry's
Satan Maximiser. That one gave our drummer a good laugh! If people don't know
what SC sounds for, they'll probably never try one.
Is your plugin metadata thing able to categorise plugins by group in
application menus? That way you could have all the compressors together, all
the flangers, all the reverbs etc. Could be easier to find what you're
looking for than strict alphabetical order. 
11 Mar
11 Mar
5:55 a.m.
On Sat, 8 Mar 2003 11:55:00 +0000
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
On Sat, Mar 08, 2003 at 11:33:16 +0000, Daniel James
wrote:
Yes, thats the main point:
http://www.ecs.soton.ac.uk/~swh/jrss.png
This link is broken :-(
--
Alexandre Prokoudine
ALT Linux Documentation Team
JID: avp(a)altlinux.org
Who said
the're not Steve's Compressor ;)
I think it would be a fine name for the series, in the tradition
of Barry's Satan Maximiser. That one gave our drummer a good
laugh! If people don't know what SC sounds for, they'll probably
never try one.
Is your plugin metadata thing able to categorise plugins by
group in application menus? That way you could have all the
compressors together, all the flangers, all the reverbs etc.
Could be easier to find what you're looking for than strict
alphabetical order.
7:23 a.m.
On Tue, Mar 11, 2003 at 12:46:42 +0300, Alexandre Prokoudine wrote:
This link is broken :-(
Works for me.
- Steve
Is your plugin metadata thing able to categorise
plugins by
group in application menus? That way you could have all the
compressors together, all the flangers, all the reverbs etc.
Could be easier to find what you're looking for than strict
alphabetical order.
Yes, thats the main point:
http://www.ecs.soton.ac.uk/~swh/jrss.png
8 Mar
8 Mar
7:53 a.m.
On Sat, Mar 08, 2003 at 11:03:28 +0000, Steve Harris wrote:
Fixed it current snapshot. It was easy.
I've made the follower have a variable response related to the attack
time, which I think give a more natural response and seems to work better
on drums. New code in snapshot:
http://plugin.org.uk/snapshots/swh-plugins-2003-03-08.tar.gz
However I dont trust my own ears on compressors, so if people could try
this new version (SC1 only) and report back wether its better for
percussion and still OK on non percussive material that would be great.
Its still not ideal for percussion (as its RMS), but it should be more
useful now.
- Steve
If I set
faders to zero I still get gain, which causes distortion on stuff
that's already at 0dB.
Yes, there is an incorrect scaling factor. Should be an easy fix, but I
haven't got round to it. I can't
seem to get the compression on drums right using the SC compressors.
The quiet bits are reduced, just as the peaks are - maybe I just don't
understand the variables. Looks like you decided against calling them the
Steve's Compressor series, eh?
I think there is a problem with the envelope tracker that makes it too
sluggish for transients, also you probably want a peak folling compressor for
this task, SC4 was meant to be switchable RMS/peak, but I forgot to add
the code before releasing the first time.
8:20 a.m.
Fixed it current snapshot. It was easy.
says the dsp expert...
I've made the follower have a variable response
related to the attack
time, which I think give a more natural response and seems to work better
on drums.
However I dont trust my own ears on compressors, so if
people could try
this new version (SC1 only) and report back wether its better for
percussion and still OK on non percussive material that would be great.
I'll try and give it a go. I am supposed to be working today, but trying all
this LADSPA stuff is far more appealing.
The nested menus look excellent - Audacity doesn't appear to support those as
yet.
Cheers
Daniel
4:08 p.m.
On Sat, Mar 08, 2003 at 12:12:35 +0000, Daniel James wrote:
I'll try and give it a go. I am supposed to be
working today, but trying all
this LADSPA stuff is far more appealing.
Heh, I know that feeling :)
The nested menus look excellent - Audacity doesn't
appear to support those as
yet.
It probably wont unless peopel request it.
- Steve
11 Mar
11 Mar
5:56 a.m.
On Sat, 8 Mar 2003 19:59:29 +0000
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
On Sat, Mar 08, 2003 at 12:12:35 +0000, Daniel James
wrote:
2 votes so far :-)
--
Alexandre Prokoudine
ALT Linux Documentation Team
JID: avp(a)altlinux.org
I'll try and give it a go. I am supposed to
be working today,
but trying all this LADSPA stuff is far more appealing.
Heh, I know that feeling :)
The nested menus look excellent - Audacity
doesn't appear to
support those as yet.
It probably wont unless peopel request it.
7930
days inactive
7934
days old
linux-audio-user@lists.linuxaudio.org
20 comments
5 participants
participants (5)
-
Alexandre Prokoudine -
Daniel James -
Jaakko Prättälä -
Jan "Evil Twin" Depner -
Steve Harris