From: Rib R. <ri...@gm...> - 2004-08-13 07:30:45
|
On Mon, 03 May 2004 16:54:30 -0700 (PDT) Hiroo Hayashi <hiroo@co...> wrote: > Here is my idea. > > 1. interface IDriver (I don"t have good name for this now.) > > This is an interface for Device.driverList. All of drivers (single > driver, bank driver, converter) implement this. > > public String getPatchType(); > public String getAuthors(); > public boolean supportsPatch(StringBuffer patchString, Patch p); > > 2. class Converter implements IDriver > abstract public IPatch[] extractPatch(IPatch p); > > I don"t think we need to define interface for converter. > > 3. interface IPatchDriver extends IDriver > This includes methods shared by ISingleDriver and IBankDriver which are > used by LibraryFrame, etc. > > 4. interface ISingleDriver extends IPatchDriver > > This includes methods only for Single Driver. > > 5. interface IBankDriver extends IPatchDriver > > This includes methods only for Bank Driver. > > Note 1: This requires no change in synth drivers. > > Note 2: These interface includes only methods which core class uses. In > other words they do not include methods which are used only by extending > drivers. For example the followings are not included in ISingleDriver. > > public void send(byte[] sysex); > public void send(int status, int d1, int d2); > public void send(int status, int d1); I like this. > Note 3: IBankDriver does not extend ISingleDriver. > > It is simply because a bank driver does not extend a single driver, > but (sometimes) uses single driver methods. IBankDriver does not need > all methods ISingleDriver. And a BankDriver uses same name methods > with its Single Driver. It each method on BankDriver does not extend > one of SingleDriver, but uses it. This is the reason I propose to > pass a SingleDriver object to BankDriver constructor. > > Here is Rib"s reply which I"ve not answered yet. > > On Tue, 04 May 2004 00:57:09 -0700 (PDT) > Rib Rdb <ribrdb@ya...> wrote: > > Rib> --- Hiroo Hayashi <hiroo.hayashi@co...> wrote: > Rib> > I used interfaces for drivers so that a synth can have a bank > Rib> > driver > Rib> > that is a subclass of any Driver (or IDriver for that matter). > Rib> > > Rib> > (For example, I wanted YamahaMotifBankDriver to extend > Rib> > YamahaMotifSingleDriver). > me> I think what you want to do can be done by passing the Single > me> driver object to the constructor of the bank driver as I do in > me> RolandTD6 driver. > me> Here is the part of constructor RolandTD6Device. > me> > me> // add drivers > me> TD6SingleDriver singleDriver = new TD6SingleDriver(); > me> addDriver(singleDriver); > me> addDriver(new TD6BankDriver(singleDriver)); > > Rib> Hmm. I suppose this would work, although it"s not as elegant as > Rib> simply being able to say "MyBankDriver extends MySingleDriver > Rib> implements BankDriver". > > My proposal is just saying "MyBankDriver implements IBankDriver". > > First I tried to use "super" in my TD6 BankDriver but it did not work > well. It"s not extending the Single Driver but only uses it. Having > single driver object in the bank driver made the code straight forward > and simple. I think the difference here is that YamahaMotifSingleDriver isn't really a single driver. It was an abstract class with common initialization code and a few other functions overriding methods in driver. The BankDriver would use the NormalVoiceDriver or the BankVoiceDriver as you describe. Does anyone have any problems with these interface ideas? I'd like to commit this and the package reorganization before I work more on the XML drivers, and I'd like to try to get the XML drivers mostly working before school starts in about a month. |