On Wed, 26 Aug 2009 23:42:12 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
> On Wed, Aug 26, 2009 at 11:09:27PM +0200, Renato wrote:
>
> > Hello, I've packaged this plugin for Archlinux, it's now in the AUR
>
> Thanks ! It's a bit unfortunate you acted so quickly - the plugin
> is still in a 'beta' stage and following releases could well be
> incompatible. This is no big deal for people who install from
> source, but could generate some trouble for the others.
>
> > btw it would be good if in 'make install' the necessary files are
> > copied to $(DESTDIR)/pathtowherecopyfiles rather than
> > simply /pathtowherecopyfiles ; this surely makes packaging much
> > easier on Arch
>
> How should this be split up ? AFAIK there's only one place to
> install LADPSA plugins, and the usual /usr or /usr/local
> separation is not used. But I could be wrong about this.
>
Well, I don't know about LADSPA plugins, but the fact is that in Arch
for building from source in a pacman-aware (pacman is Arch's package
manager) manner, you need the DESTDIR option... infact you first
install all the files with the exact same direcotry tree as would
do 'make install' but, instead of in root, in a working directory...
i.e. you do
'make DESTDIR=/pathtotmpdir install'
Then you point pacman to /pathtotmpdir, so he knows what to install and
where on the system and keeps neatly track of it (you can then easily
remove the package).
So for Archers the DESTDIR is important, but on the other hand it's
easy to patch a Makefile if it doesn't have the DESTDIR option, so no
real big problem for now... just a heads up for the future.
> > and also btw, good plugin - I've used it with good results with the
> > settings suggested by Gabriel :)
>
> Fine !
>
> Ciao,
>
ciao,
Renato
Hello all,
i have written a channel class, which collects data from (file) sources and
copies it to a buffer. Jack will get this buffer and put it into his streams.
So far, I think, this is a normal design with the following code
for (unsigned int n = 0; n < nframes; ++n)
{
pBuffer[n] += pFrames[n];
pBuffer[n] *= volume;
}
i know, it's not really optimized. But it works as an example. as you can
think, pBuffer and pFrames are float* and volume is also a float.
now it happens, when the volume is 0, after 3-5 seconds, the CPU will run into
100%.
a workaround is the following before the loop
if(volume < 0.0000001)
volume = 0.0000001;
But i try to understand, what happens here. Is the compiler overoptimizing
zeros.
compiler is: $g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-
c++,treelang --prefix=/usr --enable-shared --with-system-zlib --
libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --
enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --
enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-
checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
what puzzles me is, that this doesn't happen on my double core system.
Any ideas. Thanks c~
Hi everyone,
what would your suggestions be for VST/VSTi hosts for testing plugins
during development?
Ideally I would like:
1. No frills
2. Simple interface (GUI not even needed)
3. Possibly a soundfile player
4. A simple MIDI GUI interface if possible
3 & 4 are really optional as I can use external programs to do it (although
it would be nice). The main thing is to be simple, load plugins on request,
no sequencing or that kind of stuff (otherwise I would just use Ardour or
LMMS). Just sound in and out, plus some MIDI.
Thanks!
Victor
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
Here's the first version of an lirc/Ardour's OSC wrapper I wrote a while
ago. Since it's working for me, it's time for you to enjoy it!
* Allows controlling Ardour from any lirc remote
* Uses a perl script to map lirc commands to Ardour's OSC interface
This is also the time to introduce my company's free software forge.
Comments and contributions welcomed!
Source code :
http://dev.ematech.fr/project/alo/download/file/alo-0.1.tar.gz
Development forge :
http://dev.ematech.fr/project/alo/
PS: Please note that other projects hosted there are under active
development and not ready for use yet but I'm working on it ;)
- --
Raphaël Doursenaud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqJytYACgkQaZKmNAdXaVXs8gCcCdtWCB886ewn53Nfj+wKO3ZD
pvcAoM6bUWkTFtHHRXYgnFeoT+AIvc7I
=YiF/
-----END PGP SIGNATURE-----
hi all,
In between smashing flies that came sitting on my hands while
typing, and taking cold showers (we have some heath wave here)
I wrote an auto-wah LADSPA plugin. It's available from the
usual place:
<http://www.kokkinizita.net/linuxaudio/downloads/WAH-plugins-0.0.1.tar.bz2>
Since I'm not a guitarist I'll need user feedback to improve it.
Enjoy !
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
Hi,
something for the guitarists around. This is the patch, that Miller Puckette
explained during the workshop at LAC2008.
Ciao
--
Frank
----- Forwarded message from Miller Puckette <mpuckett(a)imusic1.ucsd.edu> -----
Date: Mon, 24 Aug 2009 20:52:33 -0700
From: Miller Puckette <mpuckett(a)imusic1.ucsd.edu>
To: pd-announce(a)iem.at
Subject: [PD] [PD-announce] smeck (6ch guitar processing patch) released
Hi all,
I've finally done a good enough job of cleaning up the 'smeck' patch (seen
at Pd conventions 2007 and 2009) to consider it releasable. This patch takes
a 6-channel signal from a separated guitar pickup (such as the Roland GK series)
and does a variety of cool things to it. Smeck is available from:
http://crca.ucsd.edu/~msp/
cheers
Miller
_______________________________________________
Pd-announce mailing list
Pd-announce(a)iem.at
http://lists.puredata.info/listinfo/pd-announce
_______________________________________________
Pd-list(a)iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- End forwarded message -----
Hi programmers of virtual synthesizers :)
more than an hour ago I wiped of the dust of my old Oberheim to make
soundfonts of some basses, but some pad sounds captivated me. The
Oberheim is limited by 6-voice polyphony, resp. this isn't a limitation
for those sounds. Virtual synth often tend to make the mix muddy, when
playing pad sounds, because the polyphony isn't limited, every released
note is able to end the complete release decay. For the Oberheim some
notes are cut, while the wanted notes still can play the release decay.
A selectable limit for polyphony might be a feature, that should become
more common again, not only for virtual analog synthesizers.
I know that e.g. fluidsynth-dssi has a global setting for polyphony, but
the problem with this is, that it has impact to all used fluidsynth-dssi
plugins.
Cheers,
Ralf
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Everyone,
There is an updated version of the Invada LV2 plugins available.
This release contains a new plugin, 'Meters', which features Peak, VU, Phase &
Spectrograph meters.
Screenshot is here:
http://www.invadarecords.com/images/downloads/Screenshot-Invada_Meters.png
The amount of headroom between 0dB on the VU to digital 0dB is selectable from
- -15dB to -3 dB. There is no right value for this, it really depends on the
music, so just pick whatever value that causes the VU to spend most of it's time
between +/- 3dB.
(this stems from the fact that 0dB in the analogue world is the optimal level
whereas 0dB in the digital world is the maximum level)
Other Notable Changes:
* Envelope attack & decay for meters now consistent across sample rates.
* Improved font selection and sizing for widgets.
* Initialised uninitialised variables in the delay plugin (thx Damon).
* Added LV2 'Portgroups' extension to RDF's (thx Dave).
* 'DESTDIR' make option to help packagers (thx Philipp).
* Various GUI tweaks.
Download from here: http://www.invadarecords.com/Downloads.php?ID=00000264
Ubuntu packages from here: https://launchpad.net/~invada/+archive/ppa
Post bugs here: https://bugs.launchpad.net/invada-studio
Send comments here :)
Also packagers for distros may be interested on the 'nopkg' version of the
tarball that contains no debian folder: https://launchpad.net/invada-studio/lv2/1.2
Final note: Please be aware that the 'External UI' extension the plugins use is
due for a revision to make in fully compliant with LV2 spec V3 and above. When
this occurs there shouldn't be any issues as I'll provide version of the GUI's
compatible with both revisions.
regards,
Fraser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKkQSLNZroiEh4erwRAqM/AKDZ3+UWGtZuncD7URuAbuS/s1jpdgCfZQRW
p7Pf1XIBpdgBIzhcIveu5ZM=
=GHHe
-----END PGP SIGNATURE-----