i thought perhaps that our resident ambisonics gurus/interested
parties should take a look at this.
--p
---------- Forwarded message ----------
From: e deleflie <edeleflie(a)gmail.com>
Date: Thu, Sep 17, 2009 at 8:21 PM
Subject: [Flac-dev] (Universal) Ambisonic implementation
To: flac-dev(a)xiph.org
Hi Flac Developers,
My name is Etienne Deleflie, I'm the founder of
http://www.ambisonia.com and, more recently, Â http://soundofspace.com.
Myself and the community I serve are looking for a lossless file
format that can encapsulate ambisonic encoding. To this end a
specification has been drafted, and is nearing stability, that
describes practical features designed to get the most out of
ambisonics.
That spec is accessible here:
http://ambisonics.googlegroups.com/web/Universal_Ambisonic_0.96.pdf
I'm wondering if the FLAC community might be interested in
implementing a lossless implementation of that spec. I know there are
some current incompatibilities. I'm also aware that there are certain
open source processes involved around implementing new features. I'd
be happy to get involved with those processes if someone expressed
interest at implementing these features.
regards,
Etienne
_______________________________________________
Flac-dev mailing list
Flac-dev(a)xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
I was not a member of LAD when the "LV2 port groups" discussion was running
in August.
(First few lines from messages of Jörn Nettingsmeier and David Robillard,
below.)
Now I am 'on list' can I jsut check I have answered everyone's queries?
Regards,
Michael
(Basically using ambisonics.ch URLs as PSIs is no problem ..., MC.)
---------- Forwarded Message ----------
Subject: Re: [LAD] LV2 port groups
Date: Tue, 18 Aug 2009 07:53:54 -0000 (GMT)
From: "Michael Chapman" <chapman(a)mchapman.com>
To: Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>, dave(a)drobilla.net
Cc: "Linux Audio Developers" <linux-audio-dev(a)lists.linuxaudio.org>
On Sunday 16 August 2009 7:17 pm, Jörn Nettingsmeier wrote:
>Â michael, there are plans to implement the ACN/SN3D scheme in the LV2
>Â plugin standard.
>Â David Robillard wrote:
> > On Sun, 2009-08-16 at 19:22 +0200, Jörn Nettingsmeier wrote:
>Â >> David Robillard wrote:
> >>> On Sun, 2009-08-16 at 18:27 +0200, Jörn Nettingsmeier wrote:
>Â >>>> David Robillard wrote:
>Â >>>>> On Mon, 2009-08-10 at 11:02 -0400, David Robillard wrote:
>Â >>>>>> http://lv2plug.in/ns/dev/port-groups.lv2/port-groups.html
>Â >>>>>
>Â >>>>> P.S. Comments on this from anyone with experience in multi-channel
>Â >>>>> stuff would be appreciated if there's any problems.
>Â >>>>>
-------------------------------------------------------
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
