jsynthlib-devel — Mailing list for developers and users interested in improving the JSynthLib.

Re: [Jsynthlib-devel] Deprecated methods questions

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

Hi Joachim,

Joachim Backhaus wrote:
> *************************
> 
> /** Play note. 
>      * @param p a <code>IPatch</code> value, which isn't used! !!!FIXIT!!!
>      * @deprecated Use playPatch().
>      */
>     public void playPatch(IPatch p) { // called by core and some Editors
> 	playPatch();
>     }
> 
> Why is that deprecated?
> There are many drivers that override this method and
> change the sysex array values of the Patch.
> And this leads to many deprecation warnings.
> 
> Shouldn't the Driver be modified so that the IPatch is used inside the
> playPatch(IPatch p) method?
> Or shouldn't just the deprecation tag be removed?

I've put this to deprecated, because the core.driver.playPatch doesn't use the parameter Patch.
The current patch to play is send by the menu-, popupmenu-, icon-actions.
These actions send the current patch to the synth and then call the driver.playPatch method.
So the driver.playPatch doesn't need to send the patch.
The playPatch method does only play the patch.

I took a look at the concerning drivers and many drivers doing the same things as in the "sendPatch(IPatch)" method, which isn't
necessary. Only the AlesisA6 and SCIProphet600 drivers seem to make some important things, which are not done by sendPatch().
I like to change these drivers, but without the hardware it's hard to test if I break something. So I let it be.

Maybe I was too aggressiv. So I can remove the deprecated flag again.
But I interpreted the comment at the playPatch method in this kind.

Bye
Torsten

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

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

Hi Hiroo,

Hiroo Hayashi wrote:
> Torsten,
> 
> Thank you for your reply.  I'm trying to understand what you wrote,
> but I could not yet.  I'm guessing you are thinking similar thing with
> me, and I could not express my intention well.  Let me try again.

Sorry for my bad english.

> First I'm not extending functionality at all.  I'm just trying to
> define a minimum set of methods which a synthdriver have to provide
> (in other words set of methods which core uses).

OK, my proposals are definitly extensions. Maybe we come back to these in  future.

> Now synth driver implements 3 classes
> 	Driver
> 	BankdDriver extends Driver (optional)
> 	Converter extends Driver (optional)
> 
> Many methods in Driver class does not required for BankDriver and
> Converter.  Extending Driver class is overkill for BankDriver and
> Converter.  Even Driver class itself has many methods which does not
> required by core.  For example Driver.calculateChecksum(IPatch, int,
> int, int) is a method only to implement
> Driver.calculateChecksum(IPatch).  We don't have to implement
> Driver.calculateChecksum(IPatch, int, int, int).
> 
> We need to make clear what a developer of synth driver has to
> implement.

I agree and start to understand your intention.
You mean what a developer has to implement therewith JSynthLib.core is working properly.
Which other methods the drivers need is the question of synthdrivers developer.

Bye
Torsten

[Jsynthlib-devel] Deprecated methods questions

[Joachim B. <jba...@pi...>]

Hi,

if you compile JSynthLib with deprecation on
(default with ANT using the current build.xml)
you get many depcreation warnings.

There are the following two problems:

    [javac] D:\JSynthLib\JSynthLib CVS\com\dreamfabric\DKnob.java:173:
warning: isManagingFocus() in javax.swing.JCompon
ent has been deprecated
    [javac]     public boolean isManagingFocus() {
    [javac]                    ^

Here is the Javadoc of "javax.swing.JComponent.isManagingFocus()":

"public boolean isManagingFocus()

    Deprecated. As of 1.4, replaced by Component.setFocusTraversalKeys(int,
Set) and Container.setFocusCycleRoot(boolean).

Changes this JComponent's focus traversal keys to CTRL+TAB and
CTRL+SHIFT+TAB. Also prevents SortingFocusTraversalPolicy from considering
descendants of this JComponent when computing a focus traversal cycle."

As "isManagingFocus()" in "DKnob" just returns true everytime I don't really
know what we should do here.

*************************

/** Play note. 
     * @param p a <code>IPatch</code> value, which isn't used! !!!FIXIT!!!
     * @deprecated Use playPatch().
     */
    public void playPatch(IPatch p) { // called by core and some Editors
	playPatch();
    }

Why is that deprecated?
There are many drivers that override this method and
change the sysex array values of the Patch.
And this leads to many deprecation warnings.

Shouldn't the Driver be modified so that the IPatch is used inside the
playPatch(IPatch p) method?
Or shouldn't just the deprecation tag be removed?

Regards,
Joachim

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

[Hiroo H. <hir...@co...>]

Torsten,

Thank you for your reply.  I'm trying to understand what you wrote,
but I could not yet.  I'm guessing you are thinking similar thing with
me, and I could not express my intention well.  Let me try again.


First I'm not extending functionality at all.  I'm just trying to
define a minimum set of methods which a synthdriver have to provide
(in other words set of methods which core uses).

Now synth driver implements 3 classes
	Driver
	BankdDriver extends Driver (optional)
	Converter extends Driver (optional)

Many methods in Driver class does not required for BankDriver and
Converter.  Extending Driver class is overkill for BankDriver and
Converter.  Even Driver class itself has many methods which does not
required by core.  For example Driver.calculateChecksum(IPatch, int,
int, int) is a method only to implement
Driver.calculateChecksum(IPatch).  We don't have to implement
Driver.calculateChecksum(IPatch, int, int, int).

We need to make clear what a developer of synth driver has to
implement.


me> 1. interface IDriver (I don't have good name for this now.)
me> 2. class Converter implements IDriver
me> 3. interface IPatchDriver extends IDriver
me> 4. interface ISingleDriver extends IPatchDriver
me> 5. interface IBankDriver extends IPatchDriver

ISingleDriver is the interface for the current Driver class.
IBankDriver is the interface for the current BankDriver class.
Converter class is a class which has only methods required for
Converter.

IDriver is a common set of methods for ISingleDriver, IBankDriver, and
Converter.  This is required for Device.driverList.

IPatchDriver is a common set of methods for ISingleDriver and
IBankDriver.  This is required by classes which handle both Single
Patch and Bank Patch, ex. LibraryFrame.  (I use the name "IDriver" for
this, but I could not find better name for the IDriver above.)
-- 
Hiroo Hayashi

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

[Jsynthlib-devel] Re: [jsynthlib-dev] XML Driver change question for Model/Sender

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

I suppose it would make sense to update them, although I probably
won't have time today.  At least for SysexSender's, I didn't update
them because I'm planning to replace them with a method like
Driver.sendParameter(ParamModel, Patch).


----- Original Message -----
From: Joachim Backhaus <jba...@pi...>
Date: Mon, 2 Aug 2004 16:01:42 +0200
Subject: [jsynthlib-dev] XML Driver change question for Model/Sender
To: "jsy...@ya..." <jsy...@ya...>

 Hi,
 
 I don't really understand why ParamModel
 and SysexSender are not changed to use IPatch.
 
 Now I have to integrate something like the
 following line:
 Patch patch = (Patch) p;
 
 Because the model can't use p anymore, e.g.:
 ComboBoxWidget voiceModeWidget = new ComboBoxWidget("Voice Mode", p, new
 TG100Model(patch, 7), new TG100Sender(0x00), TG100Constants.VOICE_MODE);
 
 Regards,
 Joachim
 
 
Yahoo! Groups Sponsor
 
ADVERTISEMENT
 
 
 ________________________________
 Yahoo! Groups Links
 
To visit your group on the web, go to:
http://groups.yahoo.com/group/jsynthlib-dev/
  
To unsubscribe from this group, send an email to:
jsy...@ya...
  
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Re: [Jsynthlib-devel] How to create a release.

[Hiroo H. <hir...@co...>]

I forgot one thing.

Edit PatchEdit.VERSION at first.

> ------------------------------------------------------------------------
> cd "branch_0_19 directory"
> cvs update -r
> # add tag
> cvs tag rel_0_19_pre2
> # create directories without CVS directories
> cvs export -r rel_0_19_pre2 pre2
> cd pre2
> javac */*/*.java */*.java *.java
> jar cmf misc/mainClass JSynthLib-0.19-pre2.jar @misc/MANIFEST
> ------------------------------------------------------------------------

At this point I have no idea for your question about CVS, sorry.
-- 
Hiroo Hayashi

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

[Hiroo H. <hir...@co...>]

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

Re: [Jsynthlib-devel] How to create a release.

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

Hi Hiroo,

Hiroo Hayashi wrote:
>>BTW, do you have any idea how to move the midiprovider directory from
>>"cvs.sourceforge.net:/cvsroot/jsynthlib/JSynthLib" to
>>"cvs.sourceforge.net:/cvsroot/jsynthlib/midiprovider"?
> 
> 
>>This would prevent downloading the midiprovider with a checkout of
>>JSynthLib.  But maybe I should ask the guys from sourceforge.
> 
> 
> We cannot remove a directory from CVS repository.  Because we have to
> be able to recreate (check out) old directory structure.  But as I show
> you a CVS manual before (I've put it at the bottom of this mail), by
> doing 'cvs update' with -P option cvs does not create a empty directory.

Sorry, my question wasn't clear enough.
I know the problem with removing directories and this wasn't my topic.

I meant another point:
If someone want to checkout JSynthLib he type the command:
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/jsynthlib co JSynthLib.

Now I like to move the midiprovider to an own directory in the jsynthlib path,
so a user can checkout midiprovider with a command like:
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/jsynthlib co midiprovider.

For this it's necessary to create the path /cvsroot/jsynthlib/midiprovider.
My hope was that you have an idea how to create this path resp. if this means to create a new project.

Do you have any ideas?

>>We don't get many bugreports in the past and and I like to create a
>>0.19-pre2 release with all fixes of the last time.  How I can upload
>>a new release to the sourceforge file section?
> 
> 
> You are one of administrator.  By going FILE section you can upload as
> I could.  It's well designed.  You don't need my bad English
> explanation:-)  If you have question, let me know.
> 
> FYI, I did the following steps to create jar file.
> 
> ------------------------------------------------------------------------
> cd "branch_0_19 directory"
> cvs update -r
> # add tag
> cvs tag rel_0_19_pre2
> # create directories without CVS directories
> cvs export -r rel_0_19_pre2 pre2
> cd pre2
> javac */*/*.java */*.java *.java
> jar cmf misc/mainClass JSynthLib-0.19-pre2.jar @misc/MANIFEST
> ------------------------------------------------------------------------

Yes, this was my hope. A concrete tip for making new releases.
I will take a look at the upload function in the FILE section.

Thanks and bye
Torsten

[Jsynthlib-devel] First steps of MidiSystem sequencer support

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

Hi,

I've committed the first changes to support MidiSystem sequencer support.
The intention is to play standard midi files to hear a singular patch instead of a single note.
It's easier to rate the sound of a patch with accords, songs, etc. than with a single note.

Alas currently my code plays the midi file over the standard Javasound synthesizer (this means the soundcard analog output) and not 
over the Midi interface. Even if I connect the sequencer with the proper MidiDevice.
Probably I made some errors or the Linux Javasound implementation is buggy.

If someone want to take a look to this feature he has to set "useSequencer" in core.NoteChooserConfigPanel to "true", recompile and 
make the corresponding settings in the config panel.

I've changed the following files:
- core/AppConfig.java              (to store/restore preferences)
- core/NoteChooserConfigPanel.java (to make the needed settings)
- core/Driver.java                 (to enable playing notes or sequences)
- core/MidiUtil.java               (the whole sequencer code)

The whole code is highly experimental and many things are missing (like start, stop, pause buttons and blocking the sequencer feature 
to avoid multiple use). Also the singular elements like sequencer, transmitter, receiver are not closed properly.

Any suggestions, bugfixes are welcome.

bye
Torsten

[Jsynthlib-devel] How to create a release.

[Hiroo H. <hir...@co...>]

> BTW, do you have any idea how to move the midiprovider directory from
> "cvs.sourceforge.net:/cvsroot/jsynthlib/JSynthLib" to
> "cvs.sourceforge.net:/cvsroot/jsynthlib/midiprovider"?

> This would prevent downloading the midiprovider with a checkout of
> JSynthLib.  But maybe I should ask the guys from sourceforge.

We cannot remove a directory from CVS repository.  Because we have to
be able to recreate (check out) old directory structure.  But as I show
you a CVS manual before (I've put it at the bottom of this mail), by
doing 'cvs update' with -P option cvs does not create a empty directory.

> We don't get many bugreports in the past and and I like to create a
> 0.19-pre2 release with all fixes of the last time.  How I can upload
> a new release to the sourceforge file section?

You are one of administrator.  By going FILE section you can upload as
I could.  It's well designed.  You don't need my bad English
explanation:-)  If you have question, let me know.

FYI, I did the following steps to create jar file.

------------------------------------------------------------------------
cd "branch_0_19 directory"
cvs update -r
# add tag
cvs tag rel_0_19_pre2
# create directories without CVS directories
cvs export -r rel_0_19_pre2 pre2
cd pre2
javac */*/*.java */*.java *.java
jar cmf misc/mainClass JSynthLib-0.19-pre2.jar @misc/MANIFEST
------------------------------------------------------------------------

Here is from CVS info manual.

Removing directories
====================

   In concept removing directories is somewhat similar to removing
files--you want the directory to not exist in your current working
directories, but you also want to be able to retrieve old releases in
which the directory existed.

   The way that you remove a directory is to remove all the files in
it.  You don't remove the directory itself; there is no way to do that.
Instead you specify the `-P' option to `cvs update' or `cvs checkout',
which will cause CVS to remove empty directories from working
directories.  (Note that `cvs export' always removes empty directories.)
Probably the best way to do this is to always specify `-P'; if you want
an empty directory then put a dummy file (for example `.keepme') in it
to prevent `-P' from removing it.

   Note that `-P' is implied by the `-r' or `-D' options of `checkout'.
This way CVS will be able to correctly create the directory or not
depending on whether the particular version you are checking out
contains any files in that directory.
-- 
Hiroo Hayashi

[Jsynthlib-devel] Re: [jsynthlib-dev] JSynthLib-0.19-pre1is released.

[Hiroo H. <hir...@co...>]

> But currently the patch<=>device/driver assignment isn't very
> usefull yet.  I think we should store this assignment in the
> core.IPatch class. But not as deviceNum/driverNum.

> I preferr a human readable format like "YamahaDX7/singleVoice". This
> would also allow JSynthLib to load the required device if it isn't
> already loaded.

> If we store this information while requesting a patch, creating a
> new patch or load/save a "patchlib" file the "p.chooseDriver()" call
> isn't needed furthermore. Only an import of sysex files would need
> the p.chooseDriver() call.

Patch object does not have to have the human readable format string.
But I agree with you the string should be saved in Patch data in
storage.  I guess this also help the XML driver.

But we have the following problem you wrote.

> In the past I tried to store this information in the "patchlib"
> file, but this wasn't compatible with the current file format. So I
> let it.

We need a extendable file format.
My take is a combination of binary Sysex data and XML as I wrote before.
-- 
Hiroo Hayashi

[Jsynthlib-devel] Re: [jsynthlib-dev] Package structure

[Hiroo H. <hir...@co...>]

Rib,

Thank you for your explanation.  Now I'm on the same page with you.

Rib> I was thinking that the devicelist wouldn't be used with XML drivers. 
Rib> Instead JSynthLib would search a user customisible path at startup. 
Rib> This makes it easier to distribute or update drivers separately from
Rib> JSynthLib.

I think we can use the devicelist by changing DevDrvPatchSelector and
AppConfig.addDevice only.  We don't have to change other core classes. 
You are implementing the XML driver and you are seeing other problems.
Correct me if I'm missing something.

Having user customizable path is good idea.
-- 
Hiroo Hayashi

[Jsynthlib-devel] Let's start using jsynthlib-devel@lists.sourceforge.net

[Hiroo H. <hir...@co...>]

Let's start using jsy...@li....

For a whole we will receive mails to jsy...@ya.... 
When you reply to them, change the return address to
jsy...@li....

On Fri, 16 Jul 2004 23:59:07 -0500
Hiroo Hayashi <hir...@co...> wrote:

Hiroo> Dear jsynthlib-dev mailing list subscribers,
Hiroo> 
Hiroo> This is important message for those who are subscribing jsynthlib-dev
Hiroo> mailing list. Please read this mail and take an action if you like.
Hiroo> 
Hiroo> I've set up a mailing list on SourceForge.net.
Hiroo> 
Hiroo>  jsy...@li...
Hiroo> 
Hiroo> This will be used instead of the current jsy...@ya....
Hiroo> 
Hiroo> If you will keep subscribe JSynthLib mailing list, subscribe the new
Hiroo> mailing list at;
Hiroo> 
Hiroo>   https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
Hiroo> 
Hiroo> The new mailing list will start August 1st, 2004. Until then don't post
Hiroo> to the mailing list and keep using the current mailing list,
Hiroo> jsy...@ya....
Hiroo> 
Hiroo> Best Regards,
Hiroo> -- 
Hiroo> Hiroo Hayashi
Hiroo> 
Hiroo> 
Hiroo> 
Hiroo> ------------------------ Yahoo! Groups Sponsor --------------------~--> 
Hiroo> Yahoo! Domains - Claim yours for only $14.70
Hiroo> http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/W4wwlB/TM
Hiroo> --------------------------------------------------------------------~-> 
Hiroo> 
Hiroo>  
Hiroo> Yahoo! Groups Links
Hiroo> 
Hiroo> <*> To visit your group on the web, go to:
Hiroo>     http://groups.yahoo.com/group/jsynthlib-dev/
Hiroo> 
Hiroo> <*> To unsubscribe from this group, send an email to:
Hiroo>     jsy...@ya...
Hiroo> 
Hiroo> <*> Your use of Yahoo! Groups is subject to:
Hiroo>     http://docs.yahoo.com/info/terms/
Hiroo>  

-- 
Hiroo Hayashi