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

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

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

On Fri, 13 Aug 2004 07:56:17 -0500, Hiroo Hayashi
<hir...@co...> wrote:
> Rib> Does anyone have any problems with these interface ideas? I'd like to
> Rib> commit this and the package reorganization before I work more on the
> Rib> XML drivers, and I'd like to try to get the XML drivers mostly working
> Rib> before school starts in about a month.
> 
> Of course I don't see problem.
> 
> Do you plan to do both implementing new interfaces and package
> reorganization at the same time?  I was thinking to do interface first.
> We may make 0.20 before package reorganization because it affects on synth
> drivers a lot.

I was planning to do the interfaces first, then the package structure.
 I was thinking that it would just be reorganization, and that other
than imports all that would be affected are things like the devicelist
writer.  If I'm wrong, maybe we can at least decide which package the
XML driver files should go in, so that the cvs history can stay
together for these new files. Then we can move the other stuff when
we're ready.

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

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

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.

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

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

Rib,

Rib> You should be able to change the method signiture in Driver back to
Rib> Patch using the refactoring, then add the new method that uses IPatch.

I tried what you wrote.  It works great.  Eclipse is a really great tool.

Now only subclasses of SysexWidget and Converter class use IPatch under
synthdrivers.  If we decide to create IConverter class I can let
subclass of Converter not to use IPatch, but I don't think it is worth
to do.

Probably I see why you did not let ParamModel use IPatch.  The current
ParmModel depends on Patch class.  We may want to introduce IParamModel
interface.

I have one question about Eclipse.  I'm using the auto-build feature. 
It causes fails on files under midiprovider directory.  I can ignore them,
but I don't want to see the fails in Problem view.  How do you handle
this issue?

Thanks.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Edit Command Disabled

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

Jeff Weber wrote:
> I'm finishing up with the drivers for the Line6 Bass
> Pod and started to work on the editor and I noticed
> the Edit... command is disabled when I select a single
> patch in the Library window (but it's still enabled
> for bank patches).  I tried loading up the TX81z
> drivers and creating a new patch and the same thing
> happens. I know there was some discussion about having
> the edit command disabled in Scene windows but this is
> happening in the Library window.
> 
> By the way, I hope you reconsider having the edit
> command disabled in Scene windows. If I'm
> understanding it correctly, he user would have to drag
> the patch to the Library window to edit it and then
> drag it back to the Scene window. It seems like an
> inconvenience for the user, imho.

This was a bug in the core.driver.hasEditor() method.
It uses still Patch instead IPatch.

I've fixed this some days ago. Please try the last recent cvs version and give us a feedback if the bug is still existent.

Bye
Torsten

Re: [Jsynthlib-devel] MT-32 and other great JSynthLib editors

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

Read the bottom of your mail:-)
You may want to subscribe jsynthlib-cvs also.

On Mon, 09 Aug 2004 01:25:50 +0000
narfman96 <nar...@ya...> wrote:

narfman96> Hiroo, 
narfman96>  How do I get on the list to follow  the progress on the latest 
narfman96> version? You're not on Yahoo Groups any more are you??? Narfman
narfman96> 
narfman96> 
narfman96> 
narfman96> -------------------------------------------------------
narfman96> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
narfman96> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
narfman96> one more big change to announce. We are now OSTG- Open Source Technology
narfman96> Group. Come see the changes on the new OSTG site. www.ostg.com
narfman96> _______________________________________________
narfman96> Jsynthlib-devel mailing list
narfman96> Jsy...@li...
narfman96> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Edit Command Disabled

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

Jeff> I'm finishing up with the drivers for the Line6 Bass
Jeff> Pod and started to work on the editor and I noticed
Jeff> the Edit... command is disabled when I select a single
Jeff> patch in the Library window (but it's still enabled
Jeff> for bank patches).  I tried loading up the TX81z
Jeff> drivers and creating a new patch and the same thing
Jeff> happens. I know there was some discussion about having
Jeff> the edit command disabled in Scene windows but this is
Jeff> happening in the Library window.

Which version of JSynthLib you are using?

I cannot reproduce the bug.  I can editor TX81z patch created by
'creating new patch' function.

Note that the editor function is disabled, if Driver.editPatch is not
overridden.  But this does not explain your problem.

Jeff> By the way, I hope you reconsider having the edit
Jeff> command disabled in Scene windows. If I'm
Jeff> understanding it correctly, he user would have to drag
Jeff> the patch to the Library window to edit it and then
Jeff> drag it back to the Scene window. It seems like an
Jeff> inconvenience for the user, imho.

Problem is that current JSynthLib creates a copy of Patch when it
creates a scene.  If a user edit a scene, the patch in Library is not
updated.  Library does not work as a library.
-- 
Hiroo Hayashi

[Jsynthlib-devel] Re: [jsynthlib-dev] Re-animation of storePatch(Patch) etc.

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

Joachim> Hiroo > If we define the following method in Driver class, the change was
Joachim> not
Joachim> Hiroo > necessary and we can keep compatibility of synth drivers.
Joachim> 
Joachim> I see no reason to re-animate the old storePatch(Patch ...) method.
Joachim> The change is done, why should it be re-animated?
Joachim> 
Joachim> Do I forget something?

There may be (probably 'are', I guess) drivers outside CVS.

Joachim> But what is on major API changes like from Version 0.18
Joachim> to 0.19?

We made the changes with good reasons.  On this case I don't see a good
reason to lose compatibility (except the change is done).

I read help pages of Eclipses and knew the refracturing is a great
feature.  I'll play with it and revert the change if it is easy for me. 
I agree with you it is not worth to much work.

Joachim> Perhaps we should make a list which supported synthesizers
Joachim> each one of us has.

What do you mean by 'us'?  The current ML subscriber or reader (I think
the latter is less than the former).  I agree.  It would be better the
list of tested driver when we release a version.
-- 
Hiroo Hayashi

[Jsynthlib-devel] MT-32 and other great JSynthLib editors

[narfman96 <nar...@ya...>]

Hiroo, 
 How do I get on the list to follow  the progress on the latest 
version? You're not on Yahoo Groups any more are you??? Narfman

[Jsynthlib-devel] Edit Command Disabled

[Jeff W. <jww...@ya...>]

I'm finishing up with the drivers for the Line6 Bass
Pod and started to work on the editor and I noticed
the Edit... command is disabled when I select a single
patch in the Library window (but it's still enabled
for bank patches).  I tried loading up the TX81z
drivers and creating a new patch and the same thing
happens. I know there was some discussion about having
the edit command disabled in Scene windows but this is
happening in the Library window.

By the way, I hope you reconsider having the edit
command disabled in Scene windows. If I'm
understanding it correctly, he user would have to drag
the patch to the Library window to edit it and then
drag it back to the Scene window. It seems like an
inconvenience for the user, imho.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Jsynthlib-devel] Re: Subclassing the Converte

[Jeff W. <jww...@ya...>]

Thanks to all for your comments about the IPatch
interface. Now I have a better idea where you're
headed with changes to the API.

I think I'm going to go ahead and use ParamModel to do
what I need to do at least for the time being.


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

[Jsynthlib-devel] New 0.19-pre2 release

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

Hi,

I've added a new tag "rel_0_19_pre2" to the branch "branch_0_19" of CVS repository.

I've also add the new "JSynthLib-0.19-pre2.jar" release to sourceforges file section.

If I'm not wrong this jar file will only work on Linux and Windows OS.
Ryan, maybe you want to create a MacOSX release?

Hiroo, I needed to try a little bit while creating and uploading this prerelease.
I hope I didn't break anything in the CVS repository and sourceforges file section.

To all, please test this new prerelease to find any remaining bugs.
Please report your experience with this prerelease.

Bye
Torsten

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

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

Hi Hiroo,

while following your instructions I run into some trouble.

Is it possible that you misspelled the mentioned line?

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

cvs export -r rel_0_19_pre2 -d pre2 JSynthLib

>>cd pre2
>>javac */*/*.java */*.java *.java
>>jar cmf misc/mainClass JSynthLib-0.19-pre2.jar @misc/MANIFEST
>>------------------------------------------------------------------------

Thanks and bye
Torsten

[Jsynthlib-devel] Re: [jsynthlib-dev] Re-animation of storePatch(Patch) etc.

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

Hi Joachim,

Joachim Backhaus wrote:
> Perhaps we should make a list which supported synthesizers
> each one of us has.
> 
> Just my 2 cents.
> 
> Here are my synths that are currently supported by JSynthLib:
> Yamaha FS1R
> Quasimidi Quasar
> Yamaha TG-100
> 
> An Alesis Andromeda is on my "to buy" list but it will take
> some time until I buy one.

I have just the "Yamaha DX7 Mark1".

But writing the drivers for:
-Yamaha TX7
-Yamaha DX7-II
-Yamaha DX7s
-Yamaha TX802
I got to know these synths pretty well from manual side (at least I think so).
So it shouldn't be a major problem to change these drivers for future API changes.

I also know the:
-Yamaha DX1
-Yamaha DX5
-Yamaha TX816
from the manual side.
But alas I'm missing some specification and (mainly) the practice to control these synths.
But I will change these drivers too, even if someone breaks (currently only a rudimentary DX5 driver exists).

What I want to say is that the whole DX7 family is (at least till now) in my responsibility.
But of course everyone is welcome to improve these drivers.

Bye
Torsten

Re: AW: [Jsynthlib-devel] Deprecated methods questions

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

Hi

Hiroo Hayashi wrote:
> Hi,
> 
> Joachim> Hmm, I suggest to replace the playPatch(IPatch) method
> Joachim> on the other synthdrivers with playPatch(),
> This OK.  But...
> 
> Joachim> remove the deprecated tag from playPatch(IPatch)
> Joachim> and change playPatch(IPatch) in the Driver class
> Joachim> to be an empty method, so that no new synthdriver
> Joachim> will use it until the method is overriden.
> 
> My take is to leave Driver.playPatch(IPatch) marked as @deprecated until
> next release (0.20).  It it just call Driver.playPatch().  This does not
> break any code and synth driver developer can know what's going on.
> 
>
> BTW I have a basic question.  Why we need playPatch() in each
> synth drivers?  I think a driver independent dialog window is enough.  It
> will include Torsten's MIDI sequencer.

I see only the reason that the playPatch() method needs the information of the assoziated MIDI port of the concerned driver.
But generally I aggree to Hiroo.

Bye
Torsten

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

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

Hi Hiroo,

Hiroo Hayashi wrote:
> Torsten,
> 
> 
>>>Last two days I was out of town, I've not see the recent changes yet.
>>>
>>>If I understand correctly we will not use Patch class in core anymore
>>>(except in Patch class itself). 
>>>
>>>The second change should be;
>>>       IPatch pk = patarray[k];
>>
>>OK, but IPatch doesn't know the sysex byte array yet.
>>
>>So we run into trouble while compiling because the following call failes:
>>
>>line 206-209:
>>
>>pk.setComment("Probably a "
>>                         + LookupManufacturer.get(pk.sysex[1],
>>                                                  pk.sysex[2],
>>                                                  pk.sysex[3])
>>                         + " Patch, Size: " + pk.sysex.length);
> 
> 
> When I wrote my reply I did not realize this problem.  But now this
> can be solved by getByteArray() as Rib wrote.
> 
> But what shall we do for the line 165 of SysexGetDialog.java.
> 
>     Patch p = new Patch(patchSysex, driver);
> 
> I think we need IPatchDriver.newPatch(byte[]) method.
> 
> # IPatchDriver is the interface for single patch driver and bank patch
> # driver.
> 
> By introducing IPatch interface, a driver can have its own patch
> class.  To enjoy the merit, we will need
> IPatchDriver.newPatch(byte[]).
> 
> Any comments? > all

If I understood your previous proposals to the interfaces right, IPatchDriver will collect all methods which are needed for library
functions.
So IPatchDriver will also have a definition of createNewPatch. Am I right?
 From this point it would be clever to define also a function IPatchDriver.newPatch(...). I don't know if we need several newPatch(...)
methods with different parameters like (byte[]), (byte[], Driver), ...

Bye
Torsten

Re: [Jsynthlib-devel] Re: [jsynthlib-dev] Subclassing the Converte

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

Hi Jeff,

Jeff> But before I do I would like to get a better
Jeff> understanding of the rest of your message. You said,
Jeff> "By defining your patch class which implements IPatch
Jeff> interface, you will be able to do what you wrote." I
Jeff> took a look at the IPatch interface and I don't really
Jeff> understand how that helps me. Can you explain a little
Jeff> more about what you meant?

Let me try...

IPatch interface was just introduced.  Some of core classes still access
Patch.sysex byte array directly.  When the transition will be done, the
method call of a patch class implementing IPatch will be the only way to
access to patch data.  The class can hold its data in any form (for
example unnibbled data as you did).  When a method of IPatch interface
(for example byte[] getByteData()), your patch class can convert the
data from its internal form to an external form (ex. byte[] or
MidiMessage[]) requested by a core class.
-- 
Hiroo Hayashi

[Jsynthlib-devel] Re: [jsynthlib-dev] Subclassing the Converte

[Jeff W. <jww...@ya...>]

Hiroo,

Thanks for your help. When I sat down to write my
driver, I went back and forth over whether to convert
the whole patch at once or to use a paramModel to do
it on the fly as you suggested. Apparently I made the
wrong choice. Shouldn't be too much work to change it
though.

But before I do I would like to get a better
understanding of the rest of your message. You said,
"By defining your patch class which implements IPatch
interface, you will be able to do what you wrote." I
took a look at the IPatch interface and I don't really
understand how that helps me. Can you explain a little
more about what you meant?

Thanks,
Jeff


 --- In jsy...@ya..., Hiroo Hayashi
<hiroo.hayashi@c...> wrote:
> Hi,
> 
> Patch.sysex has to include byte data as same format
of Sysex message.
> 'Niblize' and 'unniblize' was ParamModel's job.
> 
> But yesterday IPatch interface was checked-in into
CVS.  By defining
> your patch class which implements IPatch interface,
you will be able to
> do what you wrote.
> 
> On Sat, 31 Jul 2004 17:17:38 +0000 jwweber55434
> <jwweber55434@y...> wrote:
> 
> > I'm currently working on drivers/editors for Line6
products,
> > specifically the POD and the Bass POD. These
devices have a couple
> > of quirks (as I'm sure all devices do). First of
all, the response
> > to a patch dump sometimes sends two patches along
with some garbage
> > data. Secondly, the response comes in a
"nibbilized" format, where
> > all the data is stored in the low order four bits.
I have to
> > "unnibilize" the data and put all the bytes back
together in order
> > for my editor to see them properly. I figured out
how to solve this
> > problem by subclassing Converter and overriding
the extractPatch
> > method do do all my conversions.  I've got all of
this working but I
> > have a couple of questions.
> > 
> > First of all before I send the data back to the
device, I have to
> > renibbilize the data. To do this I just added a
static method to my
> > subclassed Converter, which I call directly from
the driver. This
> > all seems to work just fine except for the Export
functionality. The
> > Export works but it saves the data in the
unnibbilized form. The
> > export needs to save a nibbilized form (the way it
comes from the
> > device) in order to be compatabile with other
patch/ librarian
> > software.
> > 
> > I wonder if there's a better solution than just
calling a static
> > method in the Converter that would solve both
problems. I haven't
> > been able to find anything in the JSynthlib
architecture or any of
> > the code for the other devices. I would be really
interested to know
> > if I'm doing this the "right way" or if anyone has
a better
> > suggestion.
> 
> -- 
> Hiroo Hayashi


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

Re: AW: [Jsynthlib-devel] Eclipse - Displayed Tab Width

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

Joachim> Hiroo > I'd like to ask developers to set the value to 8.
Joachim> 
Joachim> I personally would prefer to stay with 4.
Joachim> 
Joachim> 8 is IMHO too much and not good for good readibility.

You are misunderstanding me.
Indentation level should be 4 as documented in core/programming.html.  I
wrote about how Tab character (0x09) is displayed.

In team work all of members need to use same value.
-- 
Hiroo Hayashi

AW: [Jsynthlib-devel] Eclipse - Displayed Tab Width

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

Hiroo > I'd like to ask developers to set the value to 8.

I personally would prefer to stay with 4.

8 is IMHO too much and not good for good readibility.

Ehm, and in my code I use blank spaces for tabs
so that there is no difference for a text editor
that uses another tab indent value.

That's no problem with UltraEdit which is the text
editor I currently use.

And in Eclipse there is also an option to use blank
spaces for tabs. I have just the german version
installed so I cannot tell you were to go.
There are two places: One in the "Code formatting tool"
(I assume that's the english name) and one in "Editor"
preferences.

Conversion from tabs to blank spaces, and vice versa
is possible in UltraEdit and I think it should
be possible with the "Code formatting tool" in Eclipse
but I haven't tested it.

Regards,
Joachim

> -----Ursprungliche Nachricht-----
> Von: Hiroo Hayashi [mailto:hir...@co...]
> Gesendet: Mittwoch, 4. August 2004 03:45
> An: JSynthLib Development
> Betreff: [Jsynthlib-devel] Eclipse - Displayed Tab Width (Re:
> [jsynthlib-dev] Bug 998494 and SceneListModel/SceneFrame suggestions)
> 
> 
> Hi Rib,
> 
> When someone wrote about Eclipse on this mailing list months ago, I
> downloaded the Eclipse, but forgot about it before installing.  This
> time I installed Eclipse 3.0, tried "Hello World", and did 
> CVS check out
> JSynthLib.
> 
> Cool tool!  I found some features what I want to use.  It has so many
> features that I need time to learn.  Thank you for your advice.
> 
> I found one problem.  The default coding style is "The Java 
> Programming
> Language" which we recommend in programming.html.  This is 
> really good.
> 
> The problem is the default "Displayed Tab Width"
> (Preferences->Java->Editor) is set to 4.  This is bad choice.  Most
> tools (ex. cat on console, CVS browser on JSynthLib 
> SourceForge site, ....)
> assumes "Displayed Tab Width" is 8.  I see indentation of some code is
> broken in JSynthLib.  This default value may be one of the reason.
> 
> I'd like to ask developers to set the value to 8.
> 
> If there is no objection, I'll add this on programming.html.
> 
> On Wed, 28 Jul 2004 01:37:07 -0700
> Rib Rdb <ri...@gm...> wrote:
> 
> Rib> Hi Hiroo.  I just wanted to make sure you know that you can use
> Rib> Eclipse to automatically do this sort of refactoring.  (ie moving
> Rib> methods to a super class).  I think you just select a 
> method and then
> Rib> choose Pull Up from the refactoring menu.  I've found 
> eclipse isn't
> Rib> too bad to use once I enable the emacs keys, even though 
> it has some
> Rib> small problems, the refactoring stuff makes it worth the effort
> Rib> sometimes.
> -- 
> Hiroo Hayashi
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the 
> changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source 
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
> 

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

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

Torsten,

> > Last two days I was out of town, I've not see the recent changes yet.
> > 
> > If I understand correctly we will not use Patch class in core anymore
> > (except in Patch class itself). 
> > 
> > The second change should be;
> >        IPatch pk = patarray[k];
> 
> OK, but IPatch doesn't know the sysex byte array yet.
> 
> So we run into trouble while compiling because the following call failes:
> 
> line 206-209:
> 
> pk.setComment("Probably a "
>                          + LookupManufacturer.get(pk.sysex[1],
>                                                   pk.sysex[2],
>                                                   pk.sysex[3])
>                          + " Patch, Size: " + pk.sysex.length);

When I wrote my reply I did not realize this problem.  But now this
can be solved by getByteArray() as Rib wrote.

But what shall we do for the line 165 of SysexGetDialog.java.

    Patch p = new Patch(patchSysex, driver);

I think we need IPatchDriver.newPatch(byte[]) method.

# IPatchDriver is the interface for single patch driver and bank patch
# driver.

By introducing IPatch interface, a driver can have its own patch
class.  To enjoy the merit, we will need
IPatchDriver.newPatch(byte[]).

Any comments? > all
-- 
Hiroo Hayashi

[Jsynthlib-devel] Re: AW: [jsynthlib-dev] Bug 998494 and SceneListModel/SceneFrame sugg estions

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

On Tue, 27 Jul 2004 15:22:34 +0200
Joachim Backhaus <jba...@pi...> wrote:

Joachim> Hiroo > Both windows need to handle both Patch and Scene data.
Joachim> 
Joachim> Why?
Joachim> 
Joachim> The scene contains the Patch, so only Scene data is needed IMHO.

I misunderstood that you wrote about drag&drop on SceneFrame.
-- 
Hiroo Hayashi

[Jsynthlib-devel] Eclipse - Displayed Tab Width (Re: [jsynthlib-dev] Bug 998494 and SceneListModel/SceneFrame suggestions)

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

Hi Rib,

When someone wrote about Eclipse on this mailing list months ago, I
downloaded the Eclipse, but forgot about it before installing.  This
time I installed Eclipse 3.0, tried "Hello World", and did CVS check out
JSynthLib.

Cool tool!  I found some features what I want to use.  It has so many
features that I need time to learn.  Thank you for your advice.

I found one problem.  The default coding style is "The Java Programming
Language" which we recommend in programming.html.  This is really good.

The problem is the default "Displayed Tab Width"
(Preferences->Java->Editor) is set to 4.  This is bad choice.  Most
tools (ex. cat on console, CVS browser on JSynthLib SourceForge site, ....)
assumes "Displayed Tab Width" is 8.  I see indentation of some code is
broken in JSynthLib.  This default value may be one of the reason.

I'd like to ask developers to set the value to 8.

If there is no objection, I'll add this on programming.html.

On Wed, 28 Jul 2004 01:37:07 -0700
Rib Rdb <ri...@gm...> wrote:

Rib> Hi Hiroo.  I just wanted to make sure you know that you can use
Rib> Eclipse to automatically do this sort of refactoring.  (ie moving
Rib> methods to a super class).  I think you just select a method and then
Rib> choose Pull Up from the refactoring menu.  I've found eclipse isn't
Rib> too bad to use once I enable the emacs keys, even though it has some
Rib> small problems, the refactoring stuff makes it worth the effort
Rib> sometimes.
-- 
Hiroo Hayashi

Re: AW: [Jsynthlib-devel] Deprecated methods questions

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

Hi,

Joachim> Hmm, I suggest to replace the playPatch(IPatch) method
Joachim> on the other synthdrivers with playPatch(),
This OK.  But...

Joachim> remove the deprecated tag from playPatch(IPatch)
Joachim> and change playPatch(IPatch) in the Driver class
Joachim> to be an empty method, so that no new synthdriver
Joachim> will use it until the method is overriden.

My take is to leave Driver.playPatch(IPatch) marked as @deprecated until
next release (0.20).  It it just call Driver.playPatch().  This does not
break any code and synth driver developer can know what's going on.


BTW I have a basic question.  Why we need playPatch() in each
synth drivers?  I think a driver independent dialog window is enough.  It
will include Torsten's MIDI sequencer.
-- 
Hiroo Hayashi

Re: AW: [Jsynthlib-devel] Deprecated methods questions

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

Hi Joachim,

Joachim Backhaus wrote:
>>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.
> 
> 
> Hmm, these are both written by "Kenneth L. Martinez".
> 
> Does anyone on this list own an Alesis Andromeda
> or Sequential Circuits Prophet 600?
> 
> I think removing the playPatch method there wouldn't
> change anything:
> 
> // Kludge: A6 doesn't seem to receive edit buffer dump, so user mix 127
>   // is being used for that purpose.
>   public void playPatch(IPatch p)
>   {
>     byte sysex[] = new byte[1182];
>     System.arraycopy(((Patch)p).sysex, 0, sysex, 0, 1180);
>     sysex[6] = 0; // user bank
>     sysex[7] = 127; // mix # 127
>     sysex[1180] = (byte)(0xC0 + getChannel() - 1); // program change
>     sysex[1181] = (byte)127; // mix # 127
>     IPatch p2 = new Patch(sysex);
>     try
>     {
>       super.playPatch(p2);
>     }
>     catch (Exception e)
>     {
>       ErrorMsg.reportStatus (e);
>     }
>   }
> 
> 
> The newly created Patch p2 is simply ignored
> as "super.playPatch(p2)" just calls "super.playPatch()".
 >
 > So the whole code in the A6 driver looks superfluous.
 >

It calls only "super.playPatch()" because of my changes.
Original it calls "super.playPatch(Patch)", but the old driver.playPatch(Patch p) method did nothing with Patch p.
 From this point your are right.
But I don't what the 2 lines "sysex[1180]..." and "sysex[1181]..." should do.
These two lines doesn't appear in the sendPatch(IPatch) method.

> In the Prophet 600 at least playPatch(IPatch) can
> be changed to playPatch() as the changes are send
> before using the Driver class's "send" method.
> 
> Hmm, I suggest to replace the playPatch(IPatch) method
> on the other synthdrivers with playPatch(),
> remove the deprecated tag from playPatch(IPatch)
> and change playPatch(IPatch) in the Driver class
> to be an empty method, so that no new synthdriver
> will use it until the method is overriden.
> 
> Is that OK?

For me it's OK.
I'm always a little bit carefull because I don't like to break someones code.

Bye
Torsten

AW: [Jsynthlib-devel] Deprecated methods questions

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

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

Hmm, these are both written by "Kenneth L. Martinez".

Does anyone on this list own an Alesis Andromeda
or Sequential Circuits Prophet 600?

I think removing the playPatch method there wouldn't
change anything:

// Kludge: A6 doesn't seem to receive edit buffer dump, so user mix 127
  // is being used for that purpose.
  public void playPatch(IPatch p)
  {
    byte sysex[] = new byte[1182];
    System.arraycopy(((Patch)p).sysex, 0, sysex, 0, 1180);
    sysex[6] = 0; // user bank
    sysex[7] = 127; // mix # 127
    sysex[1180] = (byte)(0xC0 + getChannel() - 1); // program change
    sysex[1181] = (byte)127; // mix # 127
    IPatch p2 = new Patch(sysex);
    try
    {
      super.playPatch(p2);
    }
    catch (Exception e)
    {
      ErrorMsg.reportStatus (e);
    }
  }


The newly created Patch p2 is simply ignored
as "super.playPatch(p2)" just calls "super.playPatch()".

So the whole code in the A6 driver looks superfluous.

In the Prophet 600 at least playPatch(IPatch) can
be changed to playPatch() as the changes are send
before using the Driver class's "send" method.

Hmm, I suggest to replace the playPatch(IPatch) method
on the other synthdrivers with playPatch(),
remove the deprecated tag from playPatch(IPatch)
and change playPatch(IPatch) in the Driver class
to be an empty method, so that no new synthdriver
will use it until the method is overriden.

Is that OK?

Regards,
Joachim Backhaus

> -----Ursprungliche Nachricht-----
> Von: tt_...@gm... [mailto:tt_...@gm...]
> Gesendet: Dienstag, 3. August 2004 07:29
> An: jsynthlib-devel@sourceforge
> Betreff: Re: [Jsynthlib-devel] Deprecated methods questions
> 
> 
> 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
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the 
> changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source 
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>