It would be nice if someone could add the linuxaudio.org archives to
http://lad.linuxaudio.org/archive/lad.html. The Stanford archive might
be less good ;), but search engines prefer to link to lad.linuxaudio.org.
I gave someone on the 64 Studio list links to the Stanford archive and
was corrected, that there are some more actual LAD archives ;).
Cheers,
Ralf
Greetings,
I've been experimenting with MIDI control from one machine to another. I
checked the timing of a single note played simultanesouly by instances
of QSynth on both machines and was surprised to hear a very noticeable
flamming. I then replaced the MidiSport 2x2 with my Edirol UA25 and the
flamming disappeared. Both are USB interfaces, btw. MIDI routing between
the machines is handled by a Yamaha MJC8 and has never been problematic
with that box.
So, my question(s): Is the MidiSport just poorly designed and is there a
further condition or module option that can correct the timing delay
from that unit ?
Best,
dp
Hi,
On the LAU list we were discussing the possibilities of audio synthesis
environments as plugins.
" [LAU] From audio synthesis environment to plugin"
Pd, SC and Csound give so much possibilities when it comes to
instruments and effects. Wouldn't it be cool if Linux audio users could
easily use some code/patches as plugins? I imagine, someone makes a cool
synth 'patch' which you can easily use within a 'plugin interface'. So
without knowing how to code in SuperCollider for example, you can
benefit from patches of others, which you can easily use as plugin
(or 'jack application').
If there is such a 'plugin interface' and people start sharing
'plugins', this could make Linux more useful for Music Production. It
also could fill the gap of not having a lot commercial VST plugins for
Linux imho.
Of course I'm not the first with this idea and there are some solutions
or suggestions already. I'll try to give a list.... (of course I could
miss some options)
-------------
*Csound:*
CSoundLADSPA:
http://www.csounds.com/journal/issue6/csLADSPA.html
CSoundVST:
http://www.csounds.com/manual/html/CommandCsoundVST.html (Windows, but
also possible to build as native Linux plugin, recently).
-------------------
*Pd:*
http://www-crca.ucsd.edu/~jsarlo/pdvst/ (only Windows afaik)
-------------------
*
SuperCollider:*
SC comes with a SuperColliderAU.component (Mac only)
Here are some possibilities listed (Faust for example):
http://supercollider.sourceforge.net/wiki/index.php/Systems_interfacing_wit…
Java bindings -> http://www.erase.net/projects/p5_sc/ and jvst ->
http://jvstwrapper.sourceforge.net/
----------------------
So it seems that CSound already has an solution for GNU/Linux. But Pd
and SC only seems to have solutions for either Windows or Mac.
It would be great and good for Linux audio imho if we could use Pd and
SC patches as plugins on GNU/Linux. And to make them popular and have as
much sharing of plugins between users as possible, a crossplatform
solution might be the best bet.
I'm not a developer, so I can't tell how good my ideas and suggestions
are. I also don't know if I see clear when I see these opportunities.
That's why I mail it to this list, so experts can tell.
Maybe one or more developers likes the idea and also sees these
opportunities and are capable of setting plans and ideas into something
practical...
Thanks in advance,
\rooz
Rubber Band is an audio time-stretching and pitch-shifting library and
utility designed for musical applications. It allows you to change the
tempo and pitch of an audio recording independently of one another.
http://breakfastquay.com/rubberband/
This maintenance release contains a fix for a hang when faced with
some very peculiar stretch factors, and a fix for some incorrect
threading condition usage.
Chris
Sonic Annotator is a utility program for batch feature extraction from
audio files. It runs Vamp audio analysis plugins with specified
parameters on audio files, and writes the result features in a
selection of formats, in particular as RDF using the Audio Features
and Event ontologies, or as simple CSV files.
Version 0.4 is now available.
For more details and for downloads, please see
http://www.omras2.org/SonicAnnotator
Sonic Annotator was developed at the Centre for Digital Music, Queen
Mary, University of London. It was funded by the EPSRC through the
OMRAS2 project and is Free Software published under the GNU General
Public License.
Chris
Albin Stigo wrote:
> Hi,
>
> Yeah Fatar make the best keybeds thats why I'm designing an open
> source controller for them...
>
> The open source controller could be put in any studiologic of fatar
> keyboard you already have as a way of adding more features or
> correcting something you don't like...
>
Put in my Fatar keyboard? How does the open source controller looks
like? I can't imagine well how this works..
\r
Version 2.1 of the Vamp plugin SDK is now available.
http://www.vamp-plugins.org/
Vamp is a plugin API for audio analysis and feature extraction plugins written
in C or C++. Its SDK features an easy-to-use set of C++ classes for plugin
and host developers, a reference host implementation, example plugins, and
documentation. It is supported across Linux, OS/X, Windows, and Solaris.
A documentation guide to writing plugins using the Vamp SDK can be found at
http://www.vamp-plugins.org/guide.pdf.
Version 2.1 is a maintenance release which contains a number of bug fixes
and a new set of skeleton source code files for use by plugin developers.
All of the fixes are relevant to host code only: there is no need to recompile
or re-link any plugins that have been linked with 2.0 against the new release.
Chris
Hi,
I have a program which, at 2-periods per buffer with 128 samples per
period size and 48khz sampling rate, takes 9ms to pass input through
to its outputs. However, with the same hardware and settings, I
notice that JACK+Ardour2 take only 6ms (this is through the program,
not through a direct monitoring mode-- effects can be applied to the
input). The amount of extra latency I see in my program increases
with the buffer size: it is one buffer extra in our program. I have
a few questions about this on which I haven't been able to find
sufficient material with Google.
One difference between JACK and our software I notice is that JACK
is using ALSA's mmap mode. I am unclear on the advantages of mmap's
begin/commit access vs. using the plain vanilla readi/writei. If mmap
does offer a latency advantage and not just a CPU advantage, how does
the timing of that work as compared to read/write? Where's my extra
buffer worth of latency coming from?
Cheers,
Louis
Hi,
I'm trying to build AMS, but ./configure can't find clalsadrv and I
can't find where to download the source for it. I've already built
from source:
alsa-driver-1.0.20
alsa-tools-1.0.20
alsa-plugins-1.0.20
alsa-lib-1.0.20
can anyone tell me where clalsadrv is?
Cheers,
James.
Heya!
Not sure if anyone of you already read this announcement about my
mutex profiler "mutrace" I wrote a couple of days back:
http://0pointer.de/blog/projects/mutrace.html
Since I wrote that blog story I have added a couple of features to
mutrace that are particularly relevant when developing real-time
applications. I'd like to draw your attention to these, since this
might be of some interest for the audio community.
"mutrace -r" can be used to track down any mutex usage in real-time
threads. As everyone probably knows it's a good idea to abstain from
mutex usage entirely in RT threads. However, actually doing that is
not always realistic, and sometimes the more complex your project gets
the harder it becomes actually making sure that no hidden mutex usage
creeps into your program. Too verify lock-freeness or track down the
culprits you may use "mutrace -r". It will tell you not only if am RT
thread used a mutex, it will also tell you how often it was contended
and how often it changed ownership (i.e. how big the risk of
contention is even if it didn't contend in the specific run.) In
addition it will show you the mutex protocol, so if you are using a
mutex from an RT thread and really cannot do without it, you can at
least make sure it is a PRIO_INHERIT mutex,
And there's also now a second tool called "matrace" in the tarball
that tracks down malloc() usage from RT threads. It's a very simple
tool, which just catches the memory allocations/frees, checks the
scheduling and complains if necessary.
With these two tools two of the biggest donts in RT programming may be
tracked down: use of mutexes and use of malloc.
How does the output look like? As an example I simply ran jackd through
mutrace -r and matrace, for 10s without doing anything else. The
result for mutrace you may find here:
http://0pointer.de/public/mutrace-jackd.txt
(The interesting table is at the end, so scroll down)
Not sure what to make of this, as I don't know the Jack internals too
well. However mutrace reveals that at least one mutex was used from
an RT thread and even contended. Moreover that mutex was not
PRIO_INHERIT.
And here's matrace:
http://0pointer.de/public/matrace-jackd.txt
Seems free() is called a couple of times from an RT thread.
These might, or might not be problems. The tools can just inform you
what is done. If there's something to fix is up to the eye of the
beholder.
Get the tool here:
http://git.0pointer.de/?p=mutrace.git
Have fun,
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
