26 Jan
2008
26 Jan
'08
12:16 p.m.
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
26 Jan
26 Jan
2:16 p.m.
Hi Thorsten,
Hi Audun,
We propose a program that acts as a proxy between
sequencing software
and both software and hardware synthesizers. Among the goals are unified
patch selection and making projects more portable.
Just a litte question to better understand your idea. How would a
sequencer request a certain patch on a certain channel on a certain
port?
With plain MIDI the sequencer would just send the appropriate control
change / program change values on the given channel and midi port.
Without knowing which device would interpret the values in which way.
How would that be different with an abstraction layer? How could an
abstraction layer assure that a given PC/CC value pair would always
refer to a certain kind of patch? Regardless of the system and
synthesizer setup employed.
Obviously there would be some kind of translation. But who would define
the translation rules? Who would define what kind of patches JSM can
handle and which not. The JSM developers might come up with a "snappy
synth bass". All a user would have to do was to tell JSM how to select a
"snappy synth bass" patch on a given synthesizer.
But they might not come up with a "blurry sound from space which sounds
like a cat screaming when its tail gets clamped by the door". The user
wouldn't be able to reliably select such a patch. Simply because it
wouldn't be offered to him. On the other hand he could extend the
translation rules to offer such a patch. But than again it wouldn't work
on a foreign setup.
Thanks for your insight.
Yours sincerely,
Dennis Schulmeister
--
Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany
Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: dennis(a)windows3.de
Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net)
(mostly German)
http://www.windows3.de - http://www.denchris.de
http://www.audiominds.com - http://www.motagator.net/bands/65
3:35 p.m.
On Sat, 2008-01-26 at 19:16 +0100, Dennis Schulmeister wrote:
Just a litte question to better understand your idea.
How would a
sequencer request a certain patch on a certain channel on a certain
port?
I think the patch selection would be more part of the JSM than the
sequencer, but the details must be figured out in collaboration with
sequencer authors. So it wouldn't be the sequencer requesting a patch,
but rather patch selection throughy the JSM, the JSM providing all
necessary info to the sequencer and changing connections.
With plain MIDI the sequencer would just send the
appropriate control
change / program change values on the given channel and midi port.
Without knowing which device would interpret the values in which way.
How would that be different with an abstraction layer? How could an
abstraction layer assure that a given PC/CC value pair would always
refer to a certain kind of patch? Regardless of the system and
synthesizer setup employed.
Obviously there would be some kind of translation. But
who would define
the translation rules? Who would define what kind of patches JSM can
handle and which not. The JSM developers might come up with a "snappy
synth bass". All a user would have to do was to tell JSM how to select a
"snappy synth bass" patch on a given synthesizer.
But they might not come up with a "blurry sound
from space which sounds
like a cat screaming when its tail gets clamped by the door". The user
wouldn't be able to reliably select such a patch. Simply because it
wouldn't be offered to him. On the other hand he could extend the
translation rules to offer such a patch. But than again it wouldn't work
on a foreign setup.
The minimum the abstraction layer would do, is automatic switching
between profiles. One per environment. This way you would not have to
adapt everything on each iteration of working on a project in turns.
Patch selections could be stacked. One selection for each environment.
The next thing could be virtual ports to represent roles in the project.
Roles like drum-module or lead-synth.
Then replacing unavailable patches with patches that are similar as far
as that can be discerned from meta-data.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
4:43 p.m.
The minimum the abstraction layer would do, is
automatic switching
between profiles. One per environment. This way you would not have to
adapt everything on each iteration of working on a project in turns.
So the idea is to decouple patch selection from the sequencers. A
sequencer would just send MIDI data to a MIDI port offered to it by JSM.
JSM in turn would provide the necessary means to select a patch from any
synthesizer available.
So if Alice and Bob would work on a common project both would have their
own profile defined for the project. They would need to do so both on
their own. But at least it would be assured that each JSM MIDI port
would have similar patches assigned.
Then replacing unavailable patches with patches that
are similar as far
as that can be discerned from meta-data.
Of course for such a feature an arbitrary large library of meta-data of
all patches of all MIDI-capable synthesizers ever built and written
would be needed. :)
Yours sincerely,
Dennis Schulmeister
--
Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany
Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: dennis(a)windows3.de
Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net)
(mostly German)
http://www.windows3.de - http://www.denchris.de
http://www.audiominds.com - http://www.motagator.net/bands/65
7:37 p.m.
Dennis Schulmeister wrote:
So the idea is to decouple patch selection from the
sequencers. A
sequencer would just send MIDI data to a MIDI port offered to it by JSM.
JSM in turn would provide the necessary means to select a patch from any
synthesizer available.
The idea is to provide the JSM with a patch and synth (and other
metadata) database,
and a mechanism for sequencers to connect to and query the database. So
patch selection
will happen in the sequencer in the classical sense: I imagine that a
"patch" database entry
will contain the necessary information the sequencer needs in order to
get the right
sound from it's midi tracks: The port to connect to (A JSM jack midi
input port), the midi
channel and the required program and bank changes. The only thing that
changes inside
the sequencer is that it doesn't have to care about midi metadata, it
gets it for free from the
JSM. The sequencer is entirely free as to whether it wants to read the
JSM database or not.
The same old midi data is sent, and it can be set up by hand using low
level midi numbers
if one wants that instead.
Of course for such a feature an arbitrary large library of meta-data of
all patches of all MIDI-capable synthesizers ever built and written
would be needed. :)
Metadata for most synths are available via a simple google search. The
plan for JSM is to
be able to read and import the standard instrument definition formats
and put the instrument definitions in
it's database, ready for sequencers to read. Some of the patch
categorization has to be set up
by hand, but some of it could also be automated due to the nature of
naming patches what they
sound like: A patch that sounds like a piano will likely have "piano"
somewhere in its patch name,
and JSM will hopefully correctly deduce that it belongs in the "piano"
category.
-Audun Halland-
27 Jan
27 Jan
7:55 a.m.
Hi Audun,
Thank you for answering.
The idea is to provide the JSM with a patch and synth
(and other
metadata) database,
and a mechanism for sequencers to connect to and query the database. So
patch selection
will happen in the sequencer in the classical sense:
I think that contradicts to what Thorsten wrote:
I think the patch selection would be more part of the
JSM than the
sequencer, but the details must be figured out in collaboration with
sequencer authors. So it wouldn't be the sequencer requesting a patch,
but rather patch selection through the JSM, the JSM providing all
necessary info to the sequencer and changing connections.
Thorsten also writes about JSM providing info to the sequencer. But as I
understand it the trick is that the sequencer tells JSM what sound it
wants so that JSM can find and select an appropriate patch from one of
the available synthesizers.
I think such a scheme could be implemented without a change to the
sequencers. JSM being in between the sequencer and the synthesizers
would receive the patch changes (PC / CC) from the sequencer and perform
a translation to them before sending them to one of the synthesizers.
+-Sequencer-+ +-----JSM-----+ +---------+
| | | | --CC 32 / PC 56-->| Synth A |
| #TRACK 1# |-PC 32---|->Synth Bass-|-\ / +---------+
| | | | X
| #TRACK 2# |-PC 06---|->Rhodes EP--|-/ \ +---------+
| | | | --PC 98---------->| Synth B |
+-----------+ +-------------+ +---------+
That's how I understand it: JSM implements a standard patch list. Much
like the General MIDI patch list (only more comprehensive). When JSM
receives a patch change it makes use of the user provided synth profile
in order find a synthesizer and to select a fitting patch from it.
There's no need for JSM to talk back to the sequencer since it wouldn't
make any difference.
But it could be even easier:
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 program changes.
In such a scenario the sequencer (or master keyboard) wouldn't need to
bother about patch selection at all. Patch selection would be entirely
JSM's domain:
+-Sequencer-+ +-----JSM-----+ +---------+
| | | | --CC 32 / PC 56-->| Synth A |
| #TRACK 1# |---------|->Synth Bass-|-\ / +---------+
| | | | X
| #TRACK 2# |---------|->Rhodes EP--|-/ \ +---------+
| | | | --PC 98---------->| Synth B |
+-----------+ +-------------+ +---------+
Yours sincerely,
Dennis Schulmeister
--
Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany
Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: dennis(a)windows3.de
Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net)
(mostly German)
http://www.windows3.de - http://www.denchris.de
http://www.audiominds.com - http://www.motagator.net/bands/65
<GunPG KeyID: B8382C97>
On Sun, 2008-01-27 at 00:24 +0100, Audun Halland wrote:
Dennis Schulmeister wrote:
So the idea is to decouple patch selection from
the sequencers. A
sequencer would just send MIDI data to a MIDI port offered to it by JSM.
JSM in turn would provide the necessary means to select a patch from any
synthesizer available.
The idea is to provide the JSM with a patch and synth (and other
metadata) database,
and a mechanism for sequencers to connect to and query the database. So
patch selection
will happen in the sequencer in the classical sense: I imagine that a
"patch" database entry
will contain the necessary information the sequencer needs in order to
get the right
sound from it's midi tracks: The port to connect to (A JSM jack midi
input port), the midi
channel and the required program and bank changes. The only thing that
changes inside
the sequencer is that it doesn't have to care about midi metadata, it
gets it for free from the
JSM. The sequencer is entirely free as to whether it wants to read the
JSM database or not.
The same old midi data is sent, and it can be set up by hand using low
level midi numbers
if one wants that instead.
Of course for such a feature an arbitrary large library of meta-data of
all patches of all MIDI-capable synthesizers ever built and written
would be needed. :)
Metadata for most synths are available via a simple google search. The
plan for JSM is to
be able to read and import the standard instrument definition formats
and put the instrument definitions in
it's database, ready for sequencers to read. Some of the patch
categorization has to be set up
by hand, but some of it could also be automated due to the nature of
naming patches what they
sound like: A patch that sounds like a piano will likely have "piano"
somewhere in its patch name,
and JSM will hopefully correctly deduce that it belongs in the "piano"
category.
-Audun Halland-
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
8:53 a.m.
On Sun, 2008-01-27 at 12:55 +0100, Dennis Schulmeister wrote:
It can always be that we have somewhat different ideas, especially at
this early stage.
The idea is to
provide the JSM with a patch and synth (and other
metadata) database,
and a mechanism for sequencers to connect to and query the database. So
patch selection
will happen in the sequencer in the classical sense:
I think that contradicts to what Thorsten wrote: > I think the patch selection would be more part of
the JSM than the
> sequencer, but the details must be figured out in collaboration with
> sequencer authors. So it wouldn't be the sequencer requesting a patch,
> but rather patch selection through the JSM, the JSM providing all
> necessary info to the sequencer and changing connections.
Thorsten also writes about JSM providing info to the
sequencer. But as I
understand it the trick is that the sequencer tells JSM what sound it
wants so that JSM can find and select an appropriate patch from one of
the available synthesizers.
I wanted to emphasise that all the "knowledge" should be in the JSM and
that a sequencer as client only offers an interface to use the JSM.
As such, a sequencer would never request a patch from the JSM that needs
to be resolved, because patch selection already happened through the JSM
so the selected patch is clearly defined.
That's how I understand it: JSM implements a
standard patch list. Much
like the General MIDI patch list (only more comprehensive). When JSM
receives a patch change it makes use of the user provided synth profile
in order find a synthesizer and to select a fitting patch from it.
The General MIDI standard patch list will be useful thanks to all the
hardware supporting it and it could make sense to allow specifying GM
equivalents for Patches to have a fallback.
But the general idea is not a standard patch list, but listing
everything that is available in the specific environment plus having
meta-data for filtering/searching.
Unifying patch selection is at the core, improving the portability of
projects comes second.
Instead of having to select a device (implicitly via a port/channel), a
bank and a program number, the user should be able to pick a patch from
a flat list, aided by searching/filtering. Comparable to what Ardour
does for plugin selection (as pioneered in Om/Ingen).
It is not desired that only a description of the patch is stored and
resolved each time; the patch selection ends with a specific patch.
However, it might be possible to store search terms with the selection
and use them once the project is opened in another environment.
Thanks for your thoughts!
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
6141
days inactive
6142
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
Audun Halland -
Dennis Schulmeister -
Thorsten Wilms