I wrote a scripting engine for a pro audio plugin by embedding a
CPython interpreter. Since audio sequencing hosts use separate threads
for each audio track, loading more than one instance of my plugin
while running scripting code causes contention on Python's GIl and
results in CPU spikes at low latencies.
While CPython is more than capable of running fast enough in the audio
thread for control-rate (MIDI) work, the GIL is killing us. Using
process migration to move calls to CPython to daemon processes would
take less code than forking python itself, but the scripting engine
includes a python extension module that exposes pointers to the C++
classes in the audio engine. This complicates things quite a bit. The
calls look like this:
size = engine.getAudioBufferSize()
engine.loadPatchFile(SOME_PATH)
instrument.loadAudioFile(SOME_PATH_2)
instrument.setVolume(.5)
...where 'engine' and 'instrument' are C++ classes in the audio engine
that I wrapped in a python extension.
I think that the biggest problem for me is tackling the complexity of
managing new real time daemon processes for each audio track, finding
an IPC method, and also implementing a middle-ware layer that would
allow those synchronous calls to the engine be made back to the host.
This is the sort of overhead that one can expect when trying to use
process migration to work around the GIL. I consider myself an
experienced coder, but just thinking about finding a clean, rock-solid
daemon management and IPC mechanism that works on Mac and Windows
freaks me out.
Does anyone have any comments on this topic?
cheers,
-P
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'm just curious what your long-time experiences with these
gui-libraries are.
Considering to use one of these two but can't really decide.
But I do not want to switch in a year or two...
Thanks for your advices!
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkp/wE0ACgkQVC26eJ+o0+2UQACePLcVXkXSwPygZrC1sQnDUWC0
hk0AmgNmgru7KzOfYCkGppoqldsam5GH
=BzmB
-----END PGP SIGNATURE-----
Hi,
i would like to know if somebody has already thought about a (unified)
way to save or export the settings of ladspa plugins (or vst,lv2..)
I'm familiar with the idea of LASH, but i want to share plugin settings
between different sessions. A typical use case:
After recording songs with my drumset, the gate-plugin applied to
basedrum and snare has most times (nearly) the same setting.
At the moment this is a quite painful task: Ardour is able to save the
settings, but you can't export these or exchange them between other
applications.
In addition, ardour's ladspa plugin dialog can just save the settings,
changing an already saved settings is not possible. This results in a
heap of saved settings and old revisions..
It would be great to export these settings, it could be implemented as a
feature in applications like ardour2 ,jackrack or hydrogen.
After exporting the setting to a plain text file (or xml), sharing the
file with other people or between your computer would be no problem.
What are your thoughts on this? What are the disadvantages?
Thanks,
Sebastian
Hi,
I have tried the contact form on the FFADO website and through the email
address provided in the contact pages at the SourceForge.net project page to
no avail. I'm not sure where else to ask except here. Are any of the FFADO
developers on this email group that can provide a contact email that will
garner a response?
Thanks,
Alex
--
When you gotta have it, you gotta have it. Lesson learned from days of
record shopping.
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
