From alsa-devel-owner@alsa.jcu.cz  Wed Feb 10 18:15:22 1999
Received: from thudson1.cygnus.com (thudson1.cygnus.com [205.226.144.45])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id SAA19445
	for <alsa-devel@alsa.jcu.cz>; Wed, 10 Feb 1999 18:14:22 +0100
Received: from cygnus.com (thudson@localhost [127.0.0.1])
	by thudson1.cygnus.com (8.8.7/8.8.7) with ESMTP id MAA02053
	for <alsa-devel@alsa.jcu.cz>; Wed, 10 Feb 1999 12:14:07 -0500
Message-ID: <36C1BE5E.E47EEDBE@cygnus.com>
Date: Wed, 10 Feb 1999 12:14:07 -0500
From: Thomas Hudson <thudson@cygnus.com>
MIME-Version: 1.0
To: alsa-devel@alsa.jcu.cz
Subject: Re: MIDI / Sequencer stuff (was:Re: Writing Article Re: Linux audio)
References: <199902090014.BAA05265@obelix.vande-pol.demon.nl> <36BF903B.1CADC0D3@cygnus.com> <36C18C1C.2781@bath.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

"P.J.Leonard" wrote:
>  is there a string parameter missing ? What is the returned int.
> 
Oops. Let's try again:

class Patchable
{
    // This returns the number of actively available patches. Loaded
    // patches for a sound card. For multibank outboard gear 127 x
num_banks
    int GetPatchCount() = 0; 

    // Set current patch to index. For multibank this would typically
    // generate two messages bank_change = index / 127; program_change =
index % 127
    // Return is previous patch number
    int SetCurrentPatch(int index) = 0;

    int GetCurrentPatch() = 0;

    vector<string> GetPatchNames() = 0;
    string GetPatchName(int index);
};

> This could be very large. I have several directories full of sounfonts
>each of which has tens /hundreds of presets.
> 
My idea is that this would only be loaded patches for sound cards. A 
separate app would handle downloading additional patches. Which means
we might want to register "listeners" for when this occurs:

class PatchChangeListener
{
  void PatchChanged(Patchable& changed_object) = 0;
}
class PatchNamesListener
{
  void PatchNamesChanged(Patchable& change_object) = 0;
};
class Patchable
{
   ...
   void AddPatchChangedListener(PatchChangeListener& listener) = 0;
   void AddPatchNamesListener(PatchNamesListener& listener) = 0;
   void Remove ...
};


Any object that had retrieved info from a Patchable could also
implement the appropriate listener abstract interface and register
itself to be notified of changes.

> 
>  We also need to absract the effects that can be applied to a patch. An
> interface that returns a list of modulation effects avialable on a
> channel with
> the valid ranges would be nice. These could then be controlled via some
> kind
> of extended midi event message.
> 
I haven't got this far yet. Though this points out a problem with my
original
thinking of treating each channel of a synth separately. I know the
Ultraproteus only has effects at the output of the mixer. All channels
share the effects.

I'm currently just trying to classify "flavors" of MIDI devices:

MIDI controlled effects device (TSR-24, SE-50, JMP-1, etc.) - An audio
  effects device that can respond to program changes, CCs, and sysex.
Synth - One or more channels that can receive channel messages as well
   as SysEx.
Patchbay - thorny devices... 
Mixer - Only experience I have here is with the MOTU Mixer 7s. It is an 
  eigth channel audio mixer that is automated by CC messages.
Recorder - Something that responds to MMC commands.
Lights - Midi show control devices. I haven't really looked at these.

Controllers - Keyboards, Drum pads, Guitar Synths, Footpedals, etc.

I'm sure I'm missing some.

Thomas

