Hi!
Audun Halland and I have been thinking about a set of related problems.
The first result is the following proposal, meant to gather feedback
from the community.
I'm posting about this to both LAD and LAU, but separately. Hopefully we
can keep it technical here and have the user POV on LAU :)
Please feel encouraged to come up with additional use cases and
implementation ideas.
You can read the following with a little bit of markup on
http://thorwil.wordpress.com/2008/01/26/jack-synthesizer-manager-proposal/
or the same text right here:
JSM, the JACK Synthesizer Manager
We propose a programm that acts as a proxy between sequencing software
and both software and hardware sythesizers. Among the goals are unified
patch selection and making projects more portable.
If we get the impression that the JSM is something that both
developers and users will find handy and use, then development might
start real soon.
In this text, we avoid going into technical details to foster free
thought and discussion.
Use Cases
1. Patch selection
Goal: Choose patches from all available hardware and software
synthesizers.
Giorgio uses a single means to select a patch among all patches of
all of his software and hardware synthesizers. He uses meta-data to find
the right patch. The right connections are made automatically.
2. Computer as syntheszier
Goal: Use the computer as a compound synthesizer in a live performance.
Hiromi has her keyboard connected to her laptop live on stage. She
uses several soft-synths via keyboard-split and layering. A few selected
parameters are bound to the wheels of the keyboard. After each song, she
switches from one setup to the next with least effort.
3. Collaboration
Goal: Exchange projects without having to change settings back and
forth.
Alice and Bob take turns on working on a project. They use different
hardware but don't have to manually change connections and choose
patches on each turn because of an abstraction layer.
MIDI Interface Ports
The problem with MIDI interface ports is that the hardware on the other
side and its setup might change. Or be entirely different if people
exchange projects. An abstraction layer can make this more comfortable
to handle.
The JSM takes care of the mapping between software ports and MIDI
interface ports. It can work on a per MIDI channel level.
Patches and Instrument Definitions
Patches and controllers are chosen by name; the user doesn't have to
deal with cryptic numbers. For kit-programms, name mappings are given
(e.g. bass drum on C1).
Patch selection happens by a single means, offering all available
patches (JACK apps, plugins, hardware). Making the required MIDI and
audio connections is automated as far as possible.
Categorization
Categories help to find the right patch among many. When exchanging
projects, they help to replace unavailable patches with similar ones.
Virtual/Compound Synthesizers
>From the outside, the computer can be dealt with like a single compound
synthesizer. Different synthesizers can be triggered from ranges on a
single keyboard (key splits). Synthesizers can be layered. The whole
setup can be switched with programm changes.
JACK to ALSA Bridge
JSM could be the de facto JACK MIDI to ALSA MIDI bridge. No Jack
"SYSTEM" midi ports, the jack world only sees the devices offered by
JSM.
--
Audun Halland and Thorsten Wilms
Now that the list traffic seems to have calmed down a bit I'd like to draw
attention to another, less controversial (hah!) subject... LASH. Please bear
with me the mandatory introduction:
The Finnish Centre for Open Source Solutions [0] along with a number of
Finnish companies (yes, Nokia's in) is hosting an annual event called
Summercode [1] this year for the third time. As you probably guessed it's a
lot like Google's Summer of Code, but I've understood that it's meant solely
for university students.
The students file applications detailing the project they wish to work on and
the goals they aim to reach. The winning applicants are granted three months
of paid (about 1800 euros/month) development time beginning from June.
For me, this represents an opportunity to get the mostest perfectest summer
job I can possibly imagine. I'm planning on submitting an application for
re-implementing LASH as a D-Bus service (it's Hip, Cool and Popular), and I'm
hoping I'll get lots and lots of feedback from the lot of you for carving out
my application.
Below are the goals in descending order which I believe matter the most. (I'm
in debt to Dave Robillard for sorting out the priorities to me.)
- Turn LASH into a D-Bus service daemon.
- Unify the client and server APIs
- New features, API changes, etc.
The last one is bound to be flammable, and I'm hoping that the feedback I get
will help me concentrate my efforts on what the developers and users think is
most important. Can't do everything in 3 months' time anyway.
The deadline for applications is February 20th, and I want mine to capture the
essence of creative cross-functional combinations of community synergies and
foresight for stimulating innovation.
Thanks,
Juuso
[0] http://www.coss.fi/web/coss/about
[1] http://www.coss.fi/web/coss/developers/summercode/faq
Fons Adriaensen:
> I've been searching for real-time audio processing tool that would
> permit rapid prototyping, for at least two years now, and I haven't
> found anything that up to the requirements.
>
That is interesting. Which requirements do you miss
from snd-rt? (I have a list myself, but it may not
contain the same as the one you have...)
Grame - Centre National de Creation Musicale - is pleased to announce
the release of Faust 0.9.9.3.
Faust AUdio STreams is a powerful and expressive functional programming
language for realtime audio signal processing. The Faust compiler
translates DSP specifications into efficient C++ code.
A variety of platforms and plugin formats are supported. A single Faust
specification can be used to easily generate JACK and ALSA applications,
as well as LADSPA, MAX/MSP, PD, Q, SC and VST plugins.
In addition to C++ code, the Faust compiler can also generate SVG
block-diagram representations as well as XML descriptions. To easily
test the compiler before installing it, please refer to
http://faust.grame.fr.
The Faust distribution can be downloaded at
http://sourceforge.net/projects/faudiostream
------------
What's new :
------------
- New architecture files :
. vst2p4.cpp (VST-2.4 architecture file),
. vsti-mono.cpp (mono VSTi synth architecture file),
. matlabplot.cpp (architecture file to plot data in Matlab or Octave
format).
- New scripts for a very easy generation of executable applications :
. faust2alsa (call the faust compiler and g++ to produce an Alsa
application),
. faust2jack (call the faust compiler and g++ to produce a Jack
application),
. faust2plot (call the faust compiler and g++ to produce an plot
application),
. faust2svg (call the faust compiler to produce SVG block-diagrams),
. faust2firefox,(faust2svg + display with firefox)
. faust2octave (faust2plot + display with octave)
- New libraries :
. filter.lib (Faust filters library)
. effect.lib (Faust effects library)
- faust2pd updated to Q 7.8,
- Improved metadata management : tags are no more limited to a
predifined set, metadata are now reported as comments in the generated
C++ code
- Support for new --simple-names option when drawing block-diagrams
.
------------
Bugs fixed :
------------
- out-of-order generation of complex mutual recursions corrected
- Lexer modified to support multiplateform end of line
- Erroneous code sharing corrected
---------------
Acknowledgments
---------------
We are grateful to all the contributors of this new release, with
special mentions to Albert Graef and Julius O. Smith. Keep sending us
remarks, suggestions, bug reports and contributions.
Hi all!
I just wanted to share some of the new developments and demo made with
Clam. It's mostly about a 3D audio (it seems a hot topic in linux-audio
nowadays)
http://parumi.wordpress.com/2008/01/25/3d-audio-and-clam/
Cheers!
Pau
PS: As Albert Graef said, a new release is near. It's just a matter of
finishing the multi-platform packages and documentation.
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Thank you for the help.
-- Darren
Hi everyone,
and interesting thread has been going on the olpc devel list.
It would be interesting to get your comments on one
of the statements that were posted there (I'll
leave you to check the thread on the list archives
http://lists.laptop.org/pipermail/devel/).
This particular e-mail goes (in response to me asking why they
were complaining about alsa and asking for OSS:
"OSS in general, or OSS on Linux? He did say "OSS 4", which is
the current version of the API. Solaris and all *BSD use it,
along with random SysV-like things. As far as sound on the
UNIX-like platforms goes, OSS is the standard. Probably it
ought to be proposed for the next POSIX/UNIX standard.
You can read Hannu's take on the matter in his blog. This
entry is particularly informative, but note that the code
has since been released under the GPL.
http://4front-tech.com/hannublog/?p=5
More on the ALSA defects:
http://lkml.org/lkml/2007/7/6/397
Basically we got swindled. ALSA has not been the utopia that
it was claimed to be. ALSA sucks. It's not even documented."
Hannu's text sometimes reads as propaganda. But it would be
nice to hear the opinion of other developers. As far as I am concerned,
for about five years now I have not even looked at OSS anymore.
But should I reconsider?
Thanks
Victor
Hi,
There is a Free Software event in south of France this summer.
We would like to make a place for libre audio and libre culture, which
includes conferences and workshop around the tools (softwares), the
diffusion (medias, communities, ...), the licences, the users (examples of
audio studio using free technologies, examples of libre artits, ... )
So don't hesitate to send your propositions
Here is the official call for conference :
>From 1st to 5th July 2008, the Ninth Libre Software Meeting(9th LSM) will
take place in Mont-de-Marsan, in south of France. Hundreds of conferences,
workshops and showings will be programmed.
To maintain the interest of the public, it is important for LSM to renew the
content of different themes. So, if you participate in a new or unknown
project, if you wish to share your passion and your libre software
experience, we will gladly welcome you during LSM 2008.
We start a large call for communications on the following axes :
- thematic conferences - all subjects are interesting, particularly
those we have not thought about ...
- projects or libre softwares presentations
- workshop animations (development, initiation, ... )
To propose to the public a rich and various content, please send your
propositons, suggestions and ideas before February 8th to appel2008 at
rmll.info
*Contacts :* (program directors)
Nicolas Ducoulombier : nicolas at ldd.fr <nicolas%20at%20ldd.fr>
Christophe Merlet : redfox at redfoxcenter.org<redfox%20at%20redfoxcenter.org>
The definite programme, theme list, conferences and contributors will be
highly influenced by the feedback we will get from this call for
contributions.
Do not hesitate to participate and give worthy projects wide visibility.
--
Benjamin Coudrin
benjamin.coudrin(a)gmail.com
(+33)6.09.11.00.83
miniloop is a simple live looping program. It can load a number of
stereo audio loops of equal length from the disk and loop them in sync
with each other, sending each loop to a different pair of JACK audio
outputs. These outputs are intended to be subsequently fed into an
external software mixer, such as Ardour. For live performance, you
will want to control the mixer using a MIDI control surface.
miniloop is similar in intent to Stephen Sinclair's LoopDub. I
actually created miniloop to explore some design ideas that I had
while working on LoopDub. Given that, it is appropriate to provide a
comparison between the two programs. The most important difference is
that LoopDub uses a built-in mixer, while miniloop uses an external
mixer. This means that miniloop is more flexible, but requires a more
complex software setup. Another important difference is the user
interface, which is radically different, and, I hope, somewhat easier
to use. Finally, LoopDub has many features that miniloop lacks;
miniloop is currently quite small (~500 SLOC) and quite feature-poor,
and I intend to keep it that way.
Project homepage here:
http://code.google.com/p/miniloop/
Download here:
http://code.google.com/p/miniloop/downloads/detail?name=miniloop-0.0.zip
Not sure whether this is any good with respect to real-time audio.
"LatencyTOP is a Linux tool for software developers (both kernel and
userspace), aimed at identifying where system latency occurs, and what
kind of operation/action is causing the latency to happen. By identifying
this, developers can then change the code to avoid the worst latency
hiccups."
<http://www.latencytop.org/>
It's part of Intel's OSS initiative:
<http://oss.intel.com/>
