|
From: Hiroo H. <hir...@co...> - 2004-08-01 19:34:37
|
Torsten and Rib came back. And Joachim joined us. During Torsten's and
Rib's absent I've done many of issues on my TODO list. Shall we restart
discussion of interface structure?
On Mon, 03 May 2004 16:54:30 -0700 (PDT)
Rib Rdb <ri...@ya...> wrote:
Rib> Attached is a jar file containing possible interfaces for Driver,
Rib> BankDriver and Patch. Also included is an abstract parent class of
Rib> device containing methods that should be common to all devices. I
Rib> used interfaces for drivers so that a synth can have a bank driver
Rib> that is a subclass of any Driver (or IDriver for that matter). (For
Rib> example, I wanted YamahaMotifBankDriver to extend
Rib> YamahaMotifSingleDriver). I will also upload the jar to yahoo groups
Rib> since i don't think message attachments are archived.
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);
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 <ri...@ya...> wrote:
Rib> --- Hiroo Hayashi <hir...@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've been having a question. Who calls Driver.calculateCheckSum(IPatch),
code in core or synth driver? It seems that now both call it, because
it is not clear.
If it is core's responsibility, each synth driver does not have to call
it. If it is a synth-driver's responsibility, we can drop it from
Interface.
--
Hiroo Hayashi
|