Re: AW: [Jsynthlib-devel] Some questions about BankDriver

[Rib R. <ri...@gm...>]

One of the reasons I was thinking about filters is so that drivers
could accept messages that aren't part of a patch. For example, when
sending a patch to the synth a driver could register that it's
expecting a patch dump succeeded or patch dump failed message. In this
case it might also be useful to specify how long a filter would last -
ie "I'm only expecting one message like this, and I want to give up
after 30 seconds"

On 5/14/05, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
>=20
> >On 5/14/05, Joe Emenaker <jo...@em...> wrote:
> >
> >
> >>Also, what does everyone else think about JSL being able to receive a
> >>patch even when the SysexGetDialog isn't open? For example, if JSL is
> >>just sitting there, and you dump a patch from a synth, it could pop up =
a
> >>message saying "JSL just received a patch dump which looks like a Alesi=
s
> >>DM5 Bank. Would you like to save it in your current library or discard
> >>it?". Then, all the SysexGetDialog class would need to do is arrange to
> >>send out dump requests (and notify the receiving mechanism that a
> >>certain type of patch is expected).
> >>
> >>
> >
> >Would it even need to do the notification? We'd just need to make sure
> >the incoming messages were routed correctly, wouldn't we.

> Well, I think that, from a user-experience point of view, you wouldn't
> want various sysex dumps just accumulating in your libraries. If the
> SysexGetDialog were open, then it could automatically insert them... but
> I think that, if you didn't have the dialog open, then you're not really
> "expecting" anything coming in, so it's probably nice to have JSL ask
> the user.

Good point. I didn't think about that


> I've thought about it some more... and here's another idea of how the
> sysex input queues could work:
> 1 - A message comes into a given MIDI interface.
> 2 - The queue manager would get a list of all of the synthdrivers using
> that interface as the input (unless the user has selected to not use
> mutliple MIDI interfaces, in which case it gets a list of all of the
> synthdrivers).
> 3 - It checks to see if any of those synthdrivers recognize the patch
> *taking into account* the input interface and channel/deviceID of the
> patch versus that of the synthdriver.
> 4 - If it finds a perfect match, then it adds it to the current library.
> If it doesn't then it checks all of the synthdrivers to see if they
> recognize the patch *without* taking into account the input interface
> and channel/deviceID. If it *does* find a match this time, then there
> are a few possible reasons, which the user might want to choose between:
>   A - This is a one-time patch dump from some device. Accept it and do
> nothing else.
>   B - This is a dump from one of the hardware devices in the synthdriver
> list, but it has changed interfaces and/or channel/deviceID without that
> data being updated in JSL. Accept the patch *and* change the
> interface/channel/deviceID of the matching synthdriver to match that of
> the incoming patch.
>   C - This is a dump from a new device. Accept the patch, and add a new
> device to the list of synthdrivers.
>   D - Discard the patch entirely.
>=20
> The nice thing is that "B" would be handy for handling problems where a
> misconfiguration is preventing any communication between JSL and the
> hardware device.
>=20
> "C" would make it *super* easy to add new instruments to the list of
> synthdrivers *provided* that JSL could somehow go through all of the
> available drivers... not just the ones in the users list of configured
> ones. If it did this, imagine how easy this would be for new users.
> Basically, they could run JSL, plug their MIDI interface into something,
> do a patch dump from it, and JSL would magically configure the driver
> for it. It would make it pretty difficult to *not* have success with JSL.