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-----
Dan Mills wrote:
> On Sun, 2009-08-23 at 19:24 +0200, Ralf Mardorf wrote:
>
>> The only useful thing is to
>> have a pre-adjusted meter, that can't be readjusted by the audio
>> engineer.
>>
>
> How do you deal with the annoying detail that there are at least 3
> standard alignments between 0Vu and 0dbFs (EBU, SMPTE and US Radio)? You
> need a calibration tweak to allow you to set the meters to whatever
> standard the rest of your system is aligned to.
>
> Regards, Dan.
I'm very sceptic that meters for studios in the box are in sync with
external equipment. I'm also very sceptic about the quality of measure
accurately for external equipment in any home recording studio, any
semi-pro studio and even some pro studios, were the equipment isn't
checked on a daily basis. Absolute accuracy becomes important especially
if tapes are sent from one studio to the other. The effective value is
sine wave +3dB = 0 and nothing else. Am I wrong?
