Re: [LAD] JACK Synthesizer Manager Proposal

On Sun, 2008-01-27 at 12:55 +0100, Dennis Schulmeister wrote:

> > 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:

It can always be that we have somewhat different ideas, especially at
this early stage.

> > 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/
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev