On Fri, Aug 28, 2009 at 03:31:53AM +0200, hollunder(a)gmx.at wrote:
> It will never be run from there, the user is the packager in the sense
> that the user runs the script and thus creates the package that he can
> install afterwards. We, as packagers, just write a part of the script,
> the user can modify this script to her liking or just run it, which in
> turn builds the binaries and creates the package on the users system.
>
> Sorry if we were unclear about that, but we were talking about AUR,
> the arch user repository where only scripts are supplied that help the
> user to build a package. AUR doesn't provide binaries as such (except
> for rare cases). The same scripts are used for the official
> repositories but there they provide binaries and the scripts are
> optional.
>
> I hope it's somewhat clearer now, sorry for the confusion.
Yes, thanks.
I'm perfectly willing to prefix $(DESTDIR) to any install directories
if that is all that's required.
But while I can clearly see the use and even necessity for $DESTIR
for someone who is creating a binary package from a source package
(without having to really install that package locally), what on
earth is the purpose of forcing someone who installs from source
to go via such an intermediate step ? If the Makefile provides a
working 'make install' why complicate it ? And more pertinently,
how am I supposed to provide support for users who do such things ?
If I release a source package, and someone has a problem compiling
or installing it, I'd be happy to help. But not if the installation
procedure has been modified for no good reason - I could probably
go along with some changes, but where does that end ?
The web page about $DESTDIR you pointed says that one of the uses
would be to allow a user without root privileges to install in
some local dir (s)he has access to. But it contradicts that same
use by declaring that 'embedded file names will not be modified'.
Which in some cases will mean that the application will not run.
To install into a e.g. a home directory a user would have to modify
$PREFIX, not $DESTDIR.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
After reading extensively on digital filters used as crossovers,
I just finished implementing a digital LR-4 crossover filter using 2
chained butterworths 2 pole q=1/sqrt(2).
I used the bilinear transform method to calculate the coefficients of
the butterworth filter and chained 2 of them together to make the
Linkwitz-Riley.
I wrote a simple calf plugin using this dsp. The frequency response
curve of the output shows accurate 24dB/octave rolloff with white
noise fed into the filter, however the highpass filter curve shows
considerable noise at low frequencies (under 40Hz).
Should I be using a different algorithm? I read somewhere that
"biquad" is a good method, but I have no idea how to do it.
Regards,
Damien
Hi,
I've received a complaint about VMPK not seeing other application's MIDI ports
in the internal connections dialog. Among others, it doesn't list
LinuxSampler ports. This isn't usually a big problem, because it is still
possible to make the subscription using a connection manager like aconnect or
qjackctl.
Anyway, the problem is that VMPK (using RtMIDI functions) enumerates and
filters the existing ALSA sequencer ports in the system having the port type
flag SND_SEQ_PORT_TYPE_MIDI_GENERIC, that means "This port understands MIDI
messages." according to the alsa library documentation:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_port.html#g43e52c…
This is the same policy used for instance by aplaymidi, from alsa-utils. If
you execute "aplaymidi --list", it doesn't show linuxsampler either.
Please: can you add SND_SEQ_PORT_TYPE_MIDI_GENERIC to the sequencer ports of
your synths, if the ports understand MIDI messages and are supposed to be
subscribed by players or other applications?
In addition, there are other interesting flags defined in the ALSA library
that could be applied also to LinuxSampler, for instance:
SND_SEQ_PORT_TYPE_SYNTHESIZER.
http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_port.html#ge67062…
Regards,
Pedro
Patrick Shirkey:
>
> Hi,
>
> For those of you who are not subscribed to LAU, yesterday I had time to
> run a test to see how easy and stable it was to run pulseaudio with jack
> on Fedora 11.
>
> I had a few problems at first but after upgrading to pulseaudio-0.9.16
> (latest dev version) I was able to successfully connect Pulseaudio to
> Jack and play tracks with Totem. It was still a little unstable as I was
> able to bring pulse down a few times while using the
> gnome-volume-control applet. However jack was not affected by pulse dying.
>
> I did this on a standard Fedora kernel with a 2 core intel and 4 GB RAM.
> My system load without any audio playing it was around 10%. While
> playing a track with Totem through PA into Jack was around 20%. This
> could be due to the visuals that were running at the same time. I was
> able to listen to a complete 30 minute dj mix without any dropouts while
> still using my system as usual. I am going to run a full day test of
> audio playback today.
>
Which kernel are you running, and are you using a 32 or 64 bit
distribution?
I'm using the 32 bit distribution of fedora 11 with the latest
fedora PAE kernel. The cpu is a 4 core intel i7, 6 GB ram.
I haven't had any problems at all with pulseaudio/jack (only using
the packages provided by fedora), and I'm a bit surprised about
your post. But I haven't tried totem, I'll do when I get home.
Hi everyone,
perhaps one of you might have already seen this issue and will
know what is the best solution.
My problem is that one of the headers in the VST SDK2.4, aeffect.h,
has a macro, VSTCALLBACK, which in gcc will be defined
as __cdecl . This is not recognised by the compiler, thus preventing
me from using that header (to build a plugin).
My solution was to forcibly undefine __GNUC__ so that the macro
gets a blank definition.
However, I am not sure this is the best way out; I am wondering whether
the calling convention will break the plugin, since the host might be
expecting __cdecl and it will not be getting it.
Perhaps someone else would have a different solution.
Regards
Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth
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-----
