[LAU] JACK Synthesizer Manager Proposal

From: Thorsten Wilms <t_w_@email-addr-hidden>
Date: Sat Jan 26 2008 - 18:15:22 EET

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 the more technical side on LAD :)

Please feel encouraged to come up with additional use cases, ideas and
tell us about your relevant experience.

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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Sat Jan 26 20:15:03 2008

This archive was generated by hypermail 2.1.8 : Sat Jan 26 2008 - 20:15:03 EET