27 Jan
2008
27 Jan
'08
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/