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
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.
Dear linux-audio developers,
I have created New Project https://sourceforge.net/projects/impro-
visor/ for Impro-Visor, which is its correct name. I will populate the
source later today, as I need time to get acquainted with their
system, but I have to be off right now to another important meeting
for the afternoon and can't do it instantly. The source I will post
will be our version 4.0.
Regarding the assertion made earlier by another that I did not contact
sourceforge about the fork 'improvisor', see the forwarded message.
The fact that SF did not remove the other project immediately does not
mean they won't. Not everything happens at lightspeed. It would be a
true indication of courtesy and cooperation if the creator of that
project were simply to remove 'improvisor' as a possible source of
confusion. If not, I will consider the options regarding this action.
Forking at 3.39 would not really be a problem for me, but it seems
that there would be less stress and duplication of effort overall if
we were to proceed as I am suggesting. A year of development has been
put in between 3.39 and 4.0. (Why so long, you ask? For one thing
because of changes started by students, but not integrated, sometimes
take a long time to integrate.)
And yes, I do wish to be in control of my own project, which has been
in existence for four years. It seems reasonable to me. I DO intend to
accept contributions, however.
Thanks for your patience and understanding.
Regards,
Bob Keller
Begin forwarded message:
> From: "SourceForge.net Support" <sfnet_ops(a)corp.sourceforge.com>
> Date: July 27, 2009 9:20:36 AM PDT
> To: Bob.Keller(a)hmc.edu
> Subject: Re: Project: Improvisor has been reported as inappropriate
>
> Hello,
>
> Based on your complaint, it appears that you may wish to report a case
> of copyright infringement. SourceForge.net deals expediently with
> reports of copyright infringement.
>
> To report copyright infringement, please use our DMCA Notification
> Procedure as per
> http://sourceforge.net/apps/trac/sitelegal/wiki/DMCA%20Notification%20Proce…
>
> Regards,
> Chris Tsai
> SourceForge Support
> sfnet_ops(a)corp.sourceforge.com
>
> PS. When you submitted this report, you did not leave us any contact
> info to reply to. As such, I've taken the liberty of looking up your
> e-mail the Harvey Mudd College directory search. I trust this was not
> a problem.
>
Robert Keller
Csilla & Walt Foley Professor
Computer Science
Harvey Mudd College
Hi,
After numerous back and forth emails with the Impro-Visor guy I realized
there was no way to get through to him. This was even after a number of
people on the Yahoo group for the program sided with him and I set them
straight on the facts. Each one of them changed their position, but this
guy would not despite any statement of facts, evidence, etc. So no point
in trying to reason with unreasonable people.
Thus, I have started a SourceForge project to host Impro-Visor stuff (yes,
with the source code) and possibly a new line of development on a fork.
Right now it is just important to make the binaries/code easily available
for everyone (as guaranteed by the GPL). Only the last stable version is
up at the moment (version 3.39).
If anybody wants to join the project feel free, even people from the original
project are welcome because this is about opening it up, not taking it over
(which is sort of a slam I received from that guy when I let him know that
the application binaries/source would be hosted on another project).
I wanted to cooperate with people, but it was just too difficult for them to
admit being wrong. So instead of just posting the source code for their
latest preview, it was pulled. In spite of all their protests that they were
completely in the right, the application was removed. Basically, an
admittance that the GPL was being violated. Anyway, I still have that
preview and the source code (via disassembler) and can possibly still put
that up a little bit later.
Raymond
Improvisor: http://sourceforge.net/projects/improvisor
Hi all,
If anybody is interested, I have decompiled the latest Impro-visor version,
which has only been provide as a binary (in contradiction to the terms of the
GPL). So if you want the source code just let me know and I will send it.
I'm sure it won't compile immediately, since there are a number of incorrect
constructs returned by the decompilation. I will work on this in the next
while to have it compile.
I think someone else mentioned they posted the older binary/source somewhere.
Perhaps this can be hosted at the same location (have to look back to see
where that is/who posted).
Apart from that, I will be looking into forking Impro-visor in the next few
days. After making contact with the responsible parties about the GPL
violations, I have received no reply and the source code has not been
posted along with the binaries as is legally required. I also contacted
the department head at the institution responsible for this work to see
if they would look into the matter. Perhaps they can sort this out in the
next little while. Failing that, I will probably start a new project on
SourceForge and be looking to put together a development team.
Contributions to the software by users will also be welcome. There will
be a need for new leadsheets, transcriptions, documentation, and even
translations of the user interface.
Cheer,
Raymond
Hi,
I've been having problems with a few LADSPA plugins recently, so I've
written a little test app that loads all LADSPA plugins, connects the
ports and runs them for one cycle. (I've attached it here.)
I've run it on the plugin packages I have installed, using valgrind, and
the results are:
amb crashes
blop memory errors (patches sent for some of the errors)
calf memory errors in Flanger & MultiChorus plugins
caps memory errors in 3 plugins
cmt memory errors (patches sent)
fil OK
ladspa memory errors in Sine plugin (mismatched free/deletes)
mcp OK
rev OK
swh crashes
tap memory errors in 5 plugins
vco OK
Note that not all memory errors are bugs, but most are. (There's also a
chance that my test app is buggy, rather than the plugins.)
I've sent a few patches for cmt and blop, and will probably try to track
down the bugs in a few other packages. If others want to help
(especially the owners of the above packages!) that would be good.
Damon
It feels like my several year old PC will crap out soon for one reason
or another, so I need a replacement, better sooner than later.
This time it should be a laptop and I heard that formerly IBM and now
Lenovo thinkpads are of good build quality, even if they only come
with intel CPUs and cost an arm and a leg.
So, do you have any experience with those for audio work?
I'd be most interested in the T and R series and more recent models.
Also helpful would be some data that's impossible to find on websites:
- What chipsets are built in?
- do the usb buses and the like share interrupts with something nasty
like graphics?
Helpful commands to gather that data:
cat /proc/interrupts
lspci
lsusb
Thanks in advance for any help.
Regards,
Philipp
Just on a more serious note, amidst all this mayhem and frivolity, we
forked a project recently to more specifically add and modify a set of
tools for a defined purpose.
Unlike this trainwreck, we not only tried our best to do so in a
decent way, but the original author was thoroughly civilised about it,
and showed a lot of class in his positive and encouraging responses.
I certainly learned a lot from the process, and have even more respect
for Chris (Cannam) as a result.
It goes without saying that if Chris can use anything we write, then
he's most welcome to do so, and has our encouragement as well.
There's a way to do this that doesn't involve throwing digital
hatchets or burning anyone at the stake.
Alex.
> www.openoctave.org
>
> midi-subscribe(a)openoctave.org
> development-subscribe(a)openoctave.org
>
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
