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
Does anyone know anything about this change in alsa:
warning: snd_pcm_sw_params_set_xfer_align is deprecated (declared
at /usr/include/alsa/pcm.h:1115)
I just wanted to check background before fixing the code.
Regards
Victor
The first milestone is reached and result is a tarball that brave souls
may want to download and try. It contains implementation of JACK
multiconfig functionality. JACK server settings can be saved as part of a
studio. Then, loading studio will cause JACK settings stored as part of
the studio to be restored.
Build will produce three operational components:
* ladishd - The daemon, a D-Bus service
* gladish - GTK GUI interface
* ladish_control - Command-line interface
In the tarball you will also find bundled suitable (latest and gratest)
flowcanvas and LADI Tools.
Download:
http://ladish.org/download/ladish-0.1.tar.bz2http://ladish.org/download/ladish-0.1.tar.bz2.sig
Homepage: http://ladish.org/
Roadmap: http://ladish.org/roadmap
---------------------------------------------------------------------
LADI Session Handler or simply ladish is a session management system
for JACK applications on GNU/Linux. Its aim is to allow you to have
many different audio programs running at once, to save their setup,
close them down and then easily reload the setup at some other
time. ladish doesn't deal with any kind of audio or MIDI data itself;
it just runs programs, deals with saving/loading (arbitrary) data and
connects JACK ports together. It can also be used to move entire
sessions between computers, or post sessions on the Internet for
download.
ladish has GUI frontend, gladish, based on lpatchage (LADI Patchage)
and the ladish_control command line app for headless operation. LADI
Tools is set of apps that interface with ladish, JACK server and
a2jmidid
ladish requires D-Bus and JACK compiled with D-Bus support.
LADI Session Handler is rewrite of LASH.
Project goals:
* Save and restore sets of JACK (audio and MIDI) enabled
applications.
* Provide JACK clients with virtual hardware ports, so projects can
be transfered (or backups restored) between computers running
different hardware and backups.
* Don't require session handling library to be used. There is no need
of such library for restoring connections between JACK clients.
* Flow canvas based GUI. Positions of elements on the canvas are
saved/restored.
* Allow clients to use external storage to save its state. This
includes storing internal state to non-filesystem place like memory
of a hardware synth. This also includes storing client internal
state (client project data) in a way that is not directly bound to
ladish project.
* Import/export operations, as opposed to save/load. Save/load
operate in current system and may cause saving data outside of
project itself (external storage). Import/export uses/produces
"tarball" suitable for transferring session data over network to
other computer or storing it in a backup archive.
* Hierarchical or tag-based organization of projects.
* List of JACK applications. Applications are always started through
ladish to have restored runtime environment closer to one existed
before project save.
* Distributed studio - network connected computers. Netjack
configuration is part of the studio and thus is saved/restored.
* Collaborate with the X11 window manager so window properties like
window position, virtual desktop and screen (multimonitor) are
saved/restored.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Greetings,
Thank you for all your great feedback on the last two betas!
phasex-0.12.0-beta4 addresses all of the concerns brought up so far:
Velocity: Many of you have noticed that velocity and aftertouch
were completely unsupported. Now, velocity (with aftertouch) can be
mapped to directly to oscillators and LFOs (by setting the source),
used as a modulation source (adjust volume w/ AM or pitch w/ FM), or
mapped to the filter in the filter-lfo section.
GUI: Some of you mentioned that the colors were too dark with too
little contrast, so now there are four GTK theme options: Dark
(original purple background), Light (orange background), System (use
the system GTK theme), and Custom (choose any gtkrc file for your
theme). There have also been issues with getting phasex to fit on
small screens (usually netbooks). The knob images have been trimmed
down vertically (just blank pixels), and the padding between widgets
has been almost completely cut out. The font can be selected in the
preferences. Additionally, a true fullscreen mode has been added.
It is now possible to fit phasex into an 800x600 desktop.
Atom processors: Compiler optimization flags for the Intel Atom
processors have been added to the build system. Run './configure
--enable-arch=atom' to build for the Atom. To force 32- or 64-bit
builds, use 'atom32' or 'atom64'.
The rest is just small tweaks and bugfixes, such as fixing the
segfault on quit issue, fixing all the compiler warnings, minor
updates to the build system, new menu items, etc.
As I don't have access to a netbook right now, please let me know
how it works out with the Atom or other low-power CPU, or on any
machine with a screen smaller than 1024x768. Of course, feedback
from the rest of you is highly welcome, too ;-}
Visit http://sysex.net/phasex/beta for source tarball, Fedora 11
RPMS, or Fedora 8 RPMS.
Cheers,
--ww