Re: [Jsynthlib-devel] Re: [jsynthlib-dev] Interfaces

[<tt_...@gm...>]

Hi Hiroo,

Hiroo Hayashi wrote:
> 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.

Sorry, but I can't give you a skillfull answer to your questions.
My experience with OOP is limited to this project.

But I want give you my opinion to some points:
The most important point from my point of view is the item 3 "IPatchDriver".
I like the idea to put all information about a patch itself into an own structure very much.
All parameters which are currently hold in the constructors of single resp. bank driver and methods like setPatchname/getPatchName, 
putPatch/getPatch should be collect in own classes, which can be loaded by each driver.
So maybe we should create ISinglePatchDriver and IBankPatchDriver.
BTW, I like to put some additional parameter to the bank patch information. I defined these parameters in my DX7 family drivers to use 
variables in the algorithms for some methods.

This would give us at least 2 benefits:
- Drivers doesn't need to know anything about patches. They have only to know how to request, send and store patches from/to a singular 
synth resp. how to call an editor. We could also implement the possibility to give the user the ability to choose a specific editor if 
several editors are available for one specific patch type (which was also discussed in the past).
- The library itself could use the information of IPatchDriver to handle patches without loading synth drivers. Maybe we can implement 
a feature that the library itself is looking automatically for a needed IPatchDriver if a patchlib file (or sysex file) is loaded with 
patches which driver isn't already loaded.

One additional remarks to the ISingleDriver and IBankDriver:
If we put all information of a patch into an own structure, single and bank drivers uses the same methods like createNewPatch, 
editPatch, requestPatchDump, sendPatch and storePatch.
If I don't miss something we don't need to distinct between single and bank drivers, but between single and bank patches.

Am I missing something or am I misunderstanding your intention?
But maybe my proposals are breaking the current device/driver structure, so we have to change all synthdrivers too, which would be a 
lot of work.

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

Since also the library operations (like creating and editing single resp. bank patches) need to calculate checksums I would say it's 
core's responsibility.
But on the other side there are many kinds of checksum algorithms depending the singular patch types so maybe it's easier to put the 
responsibility to synth drivers.
Generally I preferr to put the calculateCheckSum(IPatch) code into the core.

Bye
Torsten