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

Re: AW: [Jsynthlib-devel] General problem with sending SysEx messages?

[Thorsten K. <Tho...@gm...>]

On Tuesday 21 December 2004 12:02, Joachim Backhaus wrote:
> If you cannot found it there, please report the bug here:
> http://bugs.sun.com/services/bugreport/index.jsp

thanks, I didn't know this database.

I've written a small testcase (the error is still reproducible)
and submitted a bug report

Best Regards, Thorsten.

AW: [Jsynthlib-devel] General problem with sending SysEx messages?

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

> The only thing which is unclear to me is: why doesn't this=20
> problem appear
> on JSynthLib v0.18?

v0.18 uses different MIDI drivers (not the one of the Java API).

Would be good if you search for such a bug in the=20
bug database of Sun:
http://bugs.sun.com

If you cannot found it there, please report the bug here:
http://bugs.sun.com/services/bugreport/index.jsp

Regards,
Joachim Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von
> Thorsten Klose
> Gesendet: Montag, 20. Dezember 2004 12:28
> An: jsy...@li...
> Betreff: Re: [Jsynthlib-devel] General problem with sending SysEx
> messages?
>=20
>=20
>=20
> Hi,
>=20
> I've new input on this topic:
>=20
> I noticed the same problem with another Java application which sends
> SysEx messages via the Javasound API. So, this issue is not related
> on JSynthLib itself, but possibly a general problem with Windows/Java
>=20
> Fortunately I also found a solution which works for me: if=20
> the MIDI output
> is sent to MIDI Yoke, the additional data junk won't be=20
> appended (or will=20
> be filtered). So, following MIDI routing helps:
>=20
>     JSynthLib->MIDI Yoke->MIDI-Ox->MIDI Output Port
>=20
> The only thing which is unclear to me is: why doesn't this=20
> problem appear
> on JSynthLib v0.18? Could it be related to the way how v0.18=20
> initializes
> the MIDI Ports?
>=20
> Best Regards, Thorsten.
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

Re: [Jsynthlib-devel] General problem with sending SysEx messages?

[Thorsten K. <Tho...@gm...>]

Hi,

last input on this topic (for the records): the problem doesn't exist under
Linux with the same MIDI interfaces. So, it seems to be a Windows specific
issue

Best Regards, Thorsten.

Re: [Jsynthlib-devel] General problem with sending SysEx messages?

[Thorsten K. <Tho...@gm...>]

Hi,

I've new input on this topic:

I noticed the same problem with another Java application which sends
SysEx messages via the Javasound API. So, this issue is not related
on JSynthLib itself, but possibly a general problem with Windows/Java

Fortunately I also found a solution which works for me: if the MIDI output
is sent to MIDI Yoke, the additional data junk won't be appended (or will 
be filtered). So, following MIDI routing helps:

    JSynthLib->MIDI Yoke->MIDI-Ox->MIDI Output Port

The only thing which is unclear to me is: why doesn't this problem appear
on JSynthLib v0.18? Could it be related to the way how v0.18 initializes
the MIDI Ports?

Best Regards, Thorsten.

Re: [Jsynthlib-devel] General problem with sending SysEx messages?

[Thorsten K. <Tho...@gm...>]

Hi,

thanks for your hints! Unfortunately it seems that this isn't a trivial
problem. :-/

I tried several things, here are the results:

   o ensured that Master Controller Input is disabled (it was)

   o compiled and started the CVS version with j2sdk v1.4.2_06: problem
still exists

   o tried other MIDI interfaces (M-Audio MIDIsport 2x2 and RME Hammerfall
DSP Multiface): problem still exists

   o tried the older JSynthLib v0.18 release with both java versions: it
works without problems (with Javasound as well as with Wireprovider, I
restarted JSynthLib after each change to ensure this)

   o disabled the sendPatch() function in MIDIboxSIDSingleDriver, so that
the patch won't be sent: parameter changes are sent properly now without
additional junk


Has anybody an idea how I could continue with debugging?

Best Regards, Thorsten.

Re: [Jsynthlib-devel] General problem with sending SysEx messages?

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

Torsten,

Are you enabling Master Controller Input Port in MIDI Preference dialog
window?  If it is enabled, MIDI data from MIDI input is forwarded to
MIDI output port.  If you connect your MIDI devices as a loop, you will
see unexpected data transfer.

This is what I can guess.
-- 
Hiroo Hayashi

Fwd: [Jsynthlib-devel] General problem with sending SysEx messages?

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

Thorsten,

I tested this out with an external Midi monitor
program and it seems to work just fine on my system.
No additional bytes are sent and the messages are the
correct size every time. I'm using Java 1.4.2_05 on
Mac OS X, 10.3.6.

Jeff

--- Thorsten Klose <Tho...@gm...> wrote:

> From: "Thorsten Klose" <Tho...@gm...>
> To: jsy...@li...
> Subject: [Jsynthlib-devel] General problem with
> sending SysEx messages?
> Date: Sat, 18 Dec 2004 01:35:08 +0100 (MET)
> 
> Hi,
> 
> I'm having problems with sending SysEx messages and
> I'm not sure if they are
> related to my Windows/Java5 installation, or to
> inconsistent modules in the
> current CVS view.
> 
> It seems that once a Patch has been sent to the
> synth, each parameter which
> uses the SysexSender has the same size like the
> previous sent patch, and
> therefore not only produces a lot of MIDI traffic,
> but also violates the
> MIDI protocol.
> 
> Could somebody please try out the following with the
> latest CVS version?
> 
>    o open the MIDIboxSID editor, a SysEx string of
> 266 bytes will be sent.
>    o move the volume knob: 11 bytes for the
> parameter change + 255
> additional bytes which contain the previous patch
> data (until 0xf7) will be
> sent
>    o thereafter open the Boss DR660 driver, it will
> also send a lot of
> additional bytes on each parameter change (this
> assured me that it cannot be
> an implementation problem at my side...)
> 
> The integrated MIDI monitor always displays the
> correct SysEx string (XMIT:
> ...) and not the additional junk. Therefore it's
> better to test this with an
> external monitor program like MIDI-Ox
> 
> 
> I already tried to debug this problem, but due to my
> limited java knowledge
> it's not clear to me if the send(Receiver rcv,
> MidiMessage msg) function of
> MidiUtil.java sends the message to the generic
> receiver which is provided by
> Java itself, or to the enhanced implementation
> (where an error could be
> likely) - any hints?
> 
> Best Regards, Thorsten.
> 
> 
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
>
https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
> 

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

[Jsynthlib-devel] General problem with sending SysEx messages?

[Thorsten K. <Tho...@gm...>]

Hi,

I'm having problems with sending SysEx messages and I'm not sure if they are
related to my Windows/Java5 installation, or to inconsistent modules in the
current CVS view.

It seems that once a Patch has been sent to the synth, each parameter which
uses the SysexSender has the same size like the previous sent patch, and
therefore not only produces a lot of MIDI traffic, but also violates the
MIDI protocol.

Could somebody please try out the following with the latest CVS version?

   o open the MIDIboxSID editor, a SysEx string of 266 bytes will be sent.
   o move the volume knob: 11 bytes for the parameter change + 255
additional bytes which contain the previous patch data (until 0xf7) will be
sent
   o thereafter open the Boss DR660 driver, it will also send a lot of
additional bytes on each parameter change (this assured me that it cannot be
an implementation problem at my side...)

The integrated MIDI monitor always displays the correct SysEx string (XMIT:
...) and not the additional junk. Therefore it's better to test this with an
external monitor program like MIDI-Ox


I already tried to debug this problem, but due to my limited java knowledge
it's not clear to me if the send(Receiver rcv, MidiMessage msg) function of
MidiUtil.java sends the message to the generic receiver which is provided by
Java itself, or to the enhanced implementation (where an error could be
likely) - any hints?

Best Regards, Thorsten.

Re: [Jsynthlib-devel] Mac OSX users

[Justin A. <Ju...@Ah...>]

Thanks Denis! It works for them now. The providers go in 
~/Library/Java/Extensions

Justin
----- Original Message ----- 
From: "denis queffeulou" <dqu...@fr...>
To: <jsy...@li...>
Sent: Monday, December 06, 2004 10:38 PM
Subject: Re: [Jsynthlib-devel] Mac OSX users


> Justin Ahrens wrote:
>
>> Hello Everyone - I have developed an editor for the Korg MicroKorg using 
>> the JSynthLib 0.19 pre 2 release. I want to let some Mac users test it, 
>> but when they run the Jar, the Enable Midi checkbox is greyed out. This 
>> doesn't happen on my winXP. I noticed you have the CAProvider.jar on the 
>> sourceforge site. Will this help them? And if so what do they(or I) need 
>> to do with it? Just put it in the same directory as my Jar? Or does it 
>> need to be added to my jar? Thanks for any help, and for this great 
>> software!
>
> yes you have to download CAProvider or PlumStone jar in order to provide a 
> MIDI provider (javasound).
> To install it, you put it in ~/Library/Java (if I remember right), or in 
> the same system directory.
>
> -- 
> Denis
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel 

Re: [Jsynthlib-devel] Mac OSX users

[denis q. <dqu...@fr...>]

Justin Ahrens wrote:

> Hello Everyone - I have developed an editor for the Korg MicroKorg 
> using the JSynthLib 0.19 pre 2 release. I want to let some Mac users 
> test it, but when they run the Jar, the Enable Midi checkbox is greyed 
> out. This doesn't happen on my winXP. I noticed you have the 
> CAProvider.jar on the sourceforge site. Will this help them? And if so 
> what do they(or I) need to do with it? Just put it in the same 
> directory as my Jar? Or does it need to be added to my jar? Thanks for 
> any help, and for this great software!

yes you have to download CAProvider or PlumStone jar in order to provide 
a MIDI provider (javasound).
To install it, you put it in ~/Library/Java (if I remember right), or in 
the same system directory.

-- 
Denis

[Jsynthlib-devel] Mac OSX users

[Justin A. <Ju...@Ah...>]

Hello Everyone - I have developed an editor for the Korg MicroKorg using =
the JSynthLib 0.19 pre 2 release. I want to let some Mac users test it, =
but when they run the Jar, the Enable Midi checkbox is greyed out. This =
doesn't happen on my winXP. I noticed you have the CAProvider.jar on the =
sourceforge site. Will this help them? And if so what do they(or I) need =
to do with it? Just put it in the same directory as my Jar? Or does it =
need to be added to my jar? Thanks for any help, and for this great =
software!

Justin

Re: [Jsynthlib-devel] Driver for Roland JV-80/880

[Sander B. <san...@gm...>]

Hi,

I was mistaken in assuming I could compile 1.5 source code to a lower
bytecode level. I converted my couple of 1.5 constructs back to older
ones.

I'm distributing a test version of my driver on
http://www.geocities.com/sander_brandenburg/ bundled with a JSynthLib
CVS version. I stripped other synth drivers. I hope noone minds.

-Sander

Re: [Jsynthlib-devel] Driver for Roland JV-80/880

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

Hi,

Sander> I'm writing a JSynthLib driver for the Roland JV-80/880 synthesizer. I
Sander> have attached an early version to its RFE in the JSynthLib page at its
Sander> sourceforge site, but I plan on announcing it more loudly when the GUI
Sander> code is done.

If you don't mind and you agree to distribute your driver under GPL, we
are happy to merge your driver into JSynthLib distribution.

Sander> I have a few questions.
Sander> 
Sander> Will the JSynthLib CVS version support (my) Java 1.5 source code?

What do you mean?  The current CVS version works well with Java 1.5
environment.  Actually I started using Java 1.5 recently.  If you mean
you want to use new language feature introduced on Java 1.5, please
don't do that.  I think it is too early to make Java 1.5 as a
requirement instead of Java 1.4.2 at this point.

Sander> Is there any way to simplify writing the GUI code? Some patch editors
Sander> look like they were written by programs. (I hope I didn't insult
Sander> anyone :-)

A guy is working on XML driver.  Once it will be ready, you can create
patch editor by writing XML and some code.  But it seems that he has been
busy for study these days.

# I'll be out of town from tomorrow and I cannot reply for a while.
-- 
Hiroo Hayashi

[Jsynthlib-devel] Driver for Roland JV-80/880

[Sander B. <san...@gm...>]

Hi,

I'm writing a JSynthLib driver for the Roland JV-80/880 synthesizer. I
have attached an early version to its RFE in the JSynthLib page at its
sourceforge site, but I plan on announcing it more loudly when the GUI
code is done.

I have a few questions.

Will the JSynthLib CVS version support (my) Java 1.5 source code?

Is there any way to simplify writing the GUI code? Some patch editors
look like they were written by programs. (I hope I didn't insult
anyone :-)

Regards,
Sander Brandenburg

[Jsynthlib-devel] command line option change proposal

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

Hi,

I'd like to propose the following change.

Now the command line syntax is;

        java JSynthLib [number]

My proposal is;
        usage: java JSynthLib [-D number] [filename...]
           -D number   set debugging flags (argument is a bit mask)
                1       misc
                2       dump stack
                4       MIDI
                8       frame
                ...
                -1      all

1. debug level is specified by using -D option.
2. If file name of library file is specified, the Library window for the
   file is opened.
3. debug level will be a bit mask.  "-D 1" shows debug messages without
   dump stack. "-D 3" (3 = 1 | 2) shows debug messages and dump stack.
4. define new method ErrorMsg.reportError(int, String).  This is almost
   same as current ErrorMsg.reportError(String), except the error
   message is shown only when ORed value of -D option and int argument
   is not zero.  The current debug message for JSLFrame is showed only
   when the 4th bit from LSB is set to 1 on -D option.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] some core update

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

Hi,

Last Saturday I checked in the fix for this issue.  Instead of reverting
my change, I made the following fix;
        1. defined a static field PatchEditorFrame.nFrame which count
           patch editor frame opened.
        2. The first editor frame window is opened, a patch is sent.
        3. When there are only more one editor windows opened, a patch
           is sent every time a editor frame is activated.
        4. When two windows are opened and one of editor is closed, next
           time the other editor remained is activated, a patch is sent.

This covers the case which Torsten pointed out and does not send a patch
every time a patch editor is activated if only one editor window is
opened (most usual case).  Actual code was simpler than my bad English:-)

Hiroo> Torsten> > 3. PatchEditorFrame send the patch being edited only when the window is
Hiroo> Torsten> > opened.
Hiroo> Torsten> > 
Hiroo> Torsten> > Before every time the window is selected, the patch being edited was
Hiroo> Torsten> > sent to synth's edit buffer by using send() method.  This was verbose.
Hiroo> Torsten> 
Hiroo> Torsten> I don't think it's verbose.
Hiroo> 
Hiroo> Torsten> At least not if you edit several patches of one synthesizer
Hiroo> Torsten> at one time.  Maybe this is not the common way, but if you
Hiroo> Torsten> like to edit a patch and simoultanesly hold the original
Hiroo> Torsten> patch for comparison it's helpful.
Hiroo> 
Hiroo> I never thought of the case.  This is a good reason to send the patch
Hiroo> every time a edit window is activated.  I'll revert the change (with
Hiroo> some comments).

-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] some core update

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

> >>I think it should be possible, because BankDriver knows its Device
> >>and the singleSysexID of the single patch, which it's holding.
> > 
> > 
> > It may be possible to use Device and syngleSysexID but it would be an
> > expensive way.
> 
> Do you mean expensive, because the bank driver has to determine the appropriate single driver in a loop?

Yes.  But it's OK, because we have a good alternative,
myModel.getPatchAt(0, 0).getDriver(), as I wrote.

> > But as I wrote, BankPatch.createPatch() is an abstract method.  We
> > cannot do what you wrote in core.  What we can do is to document
> > clearly and to let synth driver developers do that.

> I see.
> I think the best way would be now, if I try to write the code by
> myself and then I will see what happend.  Alas currently I'm a
> little bit busy and don't know how much time I can spend.

I don't see any problem now.  If a synth driver developer knows this,
it is very easy to implement.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] some core update

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

Hi Hiroo,

Hiroo Hayashi wrote:
>>I think it should be possible, because BankDriver knows its Device
>>and the singleSysexID of the single patch, which it's holding.
> 
> 
> It may be possible to use Device and syngleSysexID but it would be an
> expensive way.

Do you mean expensive, because the bank driver has to determine the appropriate single driver in a loop?

Or what do you mean by "expensive"?

>>If yes, we could use the single patch createPatch() method to create
>>the patch and then we can use the BankDriver.putPatch(Patch bank,
>>Patch single, int patchNum) method to replace the old patch from the
>>bank patch.  Is it clear?
> 
> 
> I think I understand you.
> 
> But as I wrote, BankPatch.createPatch() is an abstract method.  We
> cannot do what you wrote in core.  What we can do is to document
> clearly and to let synth driver developers do that.

I see.
I think the best way would be now, if I try to write the code by myself and then I will see what happend.
Alas currently I'm a little bit busy and don't know how much time I can spend.

Bye
Torsten

Re: [Jsynthlib-devel] some core update

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

> > I think it is more consistent for IBankPatch.delete(int) to put a single
> > patch which createPatch() method of the bank driver uses.
> > BankPatch.createPatch() is an abstract method. core code cannot not know
> > what single patch is filled in by createPatch().  What we can do is to
> > document on IBankPatch.delete(int) method.
> 
> I don't know if I understood you right.
> Yes, IBankPatch.delete should replace the desired bank patch place
> with a new, default single patch.

> Is it possible to evaluate the appropriate SinglePatch.createPatch()
> method from the bank patch?

Yes, it is.
BankEditor.java gets the single driver by
	myModel.getPatchAt(0, 0).getDriver()
First I saw the code, I thought it was tricky.  But it should work well.

> I think it should be possible, because BankDriver knows its Device
> and the singleSysexID of the single patch, which it's holding.

It may be possible to use Device and syngleSysexID but it would be an
expensive way.

> If yes, we could use the single patch createPatch() method to create
> the patch and then we can use the BankDriver.putPatch(Patch bank,
> Patch single, int patchNum) method to replace the old patch from the
> bank patch.  Is it clear?

I think I understand you.

But as I wrote, BankPatch.createPatch() is an abstract method.  We
cannot do what you wrote in core.  What we can do is to document
clearly and to let synth driver developers do that.

> BTW, maybe "erasePatch(int)" is a better name for this purpose than delete(int).
Good idea.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] some core update

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

Hi Hiroo,

Hiroo Hayashi wrote:
>>To answer your question I propose to hold the method just for this
>>reason. And I think it doesn't hurt to hold the "delete" method.
>>But as you already mentioned this isn't a forcible reason.  An user,
>>who want to "clean" a bank patch, can copy a default patch to the
>>bank to overwrite an unwanted patch.
> 
> 
> I think it is more consistent for IBankPatch.delete(int) to put a single
> patch which createPatch() method of the bank driver uses.
> BankPatch.createPatch() is an abstract method. core code cannot not know
> what single patch is filled in by createPatch().  What we can do is to
> document on IBankPatch.delete(int) method.

I don't know if I understood you right.
Yes, IBankPatch.delete should replace the desired bank patch place with a new, default single patch.

Is it possible to evaluate the appropriate SinglePatch.createPatch() method from the bank patch?
I think it should be possible, because BankDriver knows its Device and the singleSysexID of the single patch, which it's holding.

If yes, we could use the single patch createPatch() method to create the patch and then we can use the BankDriver.putPatch(Patch bank, 
Patch single, int patchNum) method to replace the old patch from the bank patch.
Is it clear?

BTW, maybe "erasePatch(int)" is a better name for this purpose than delete(int).

Bye
Torsten

Re: [Jsynthlib-devel] some core update

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

Hi Torsten,

> The only reason I found is a "cosmetical" reason.
This is the only reason I also think of.  (And it is good reason.)

> To answer your question I propose to hold the method just for this
> reason. And I think it doesn't hurt to hold the "delete" method.
> But as you already mentioned this isn't a forcible reason.  An user,
> who want to "clean" a bank patch, can copy a default patch to the
> bank to overwrite an unwanted patch.

I think it is more consistent for IBankPatch.delete(int) to put a single
patch which createPatch() method of the bank driver uses.
BankPatch.createPatch() is an abstract method. core code cannot not know
what single patch is filled in by createPatch().  What we can do is to
document on IBankPatch.delete(int) method.


> I hope my intention about this topic gets clearer to you.

Absolutely.  Thanks!
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] some core update

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

Hi Hiroo,

Hiroo Hayashi wrote:
> Torsten> > BTW during this work, a question came to me.
> Torsten> > 
> Torsten> > The bank editor has a command 'delete'.  It 'delete's selected patches 
> Torsten> > (now).  But what the command does is just replace the patch name deleted
> Torsten> > to white spaces.  Do we really need the 'delete' command?
> 
> Torsten> I think so. Because if you like to remove a patch from a bank
> Torsten> you have to replace it manually by another patch.
> 
> My question might be ambiguous.
> 
> In what situation do you like to remove a patch from a bank?  We
> cannot really delete a patch from a bank.  What we can do is changing
> a patch name (the current implementation) or putting a default new
> patch (as you proposed).

You are absolutly right and I thought about the same question without finding a satisfying question.

> Torsten> The old way is easier and clearer.
> 
> Torsten> Maybe it's better to replace the patch with a default (the
> Torsten> "new") patch instead with withe spaces to ensure a valid
> Torsten> patch structure.
> 
> The my question may be "why do you have to have IBankPatch.delete(int)
> (BankDriver.deletePatch(Patch, int) method?".  Your proposal make it
> possible to obsolete IBankPatch.delete(int) method.
> 
> Again I don't understand when we like to remove a patch from a bank.
> Without doing that, I cannot choose a better way.

The only reason I found is a "cosmetical" reason.
For example if you create a bank patch, which includes only patches of a certain sound or for a single song, and don't want to hold any 
not needed patches in this bank.

To answer your question I propose to hold the method just for this reason. And I think it doesn't hurt to hold the "delete" method.
But as you already mentioned this isn't a forcible reason.
An user, who want to "clean" a bank patch, can copy a default patch to the bank to overwrite an unwanted patch.

I agree to you that it's not consistent to hold the "delete" method, because we can't delete single patches from bank patches as you wrote.

I hope my intention about this topic gets clearer to you.

Bye
Torsten

Re: [Jsynthlib-devel] some core update

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

Hi Torsten,

Torsten> > 3. PatchEditorFrame send the patch being edited only when the window is
Torsten> > opened.
Torsten> > 
Torsten> > Before every time the window is selected, the patch being edited was
Torsten> > sent to synth's edit buffer by using send() method.  This was verbose.
Torsten> 
Torsten> I don't think it's verbose.

Torsten> At least not if you edit several patches of one synthesizer
Torsten> at one time.  Maybe this is not the common way, but if you
Torsten> like to edit a patch and simoultanesly hold the original
Torsten> patch for comparison it's helpful.

I never thought of the case.  This is a good reason to send the patch
every time a edit window is activated.  I'll revert the change (with
some comments).

Torsten> > BTW during this work, a question came to me.
Torsten> > 
Torsten> > The bank editor has a command 'delete'.  It 'delete's selected patches 
Torsten> > (now).  But what the command does is just replace the patch name deleted
Torsten> > to white spaces.  Do we really need the 'delete' command?

Torsten> I think so. Because if you like to remove a patch from a bank
Torsten> you have to replace it manually by another patch.

My question might be ambiguous.

In what situation do you like to remove a patch from a bank?  We
cannot really delete a patch from a bank.  What we can do is changing
a patch name (the current implementation) or putting a default new
patch (as you proposed).

Torsten> The old way is easier and clearer.

Torsten> Maybe it's better to replace the patch with a default (the
Torsten> "new") patch instead with withe spaces to ensure a valid
Torsten> patch structure.

The my question may be "why do you have to have IBankPatch.delete(int)
(BankDriver.deletePatch(Patch, int) method?".  Your proposal make it
possible to obsolete IBankPatch.delete(int) method.

Again I don't understand when we like to remove a patch from a bank.
Without doing that, I cannot choose a better way.

Thanks.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] some core update

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

Hi Hiroo,

Hiroo Hayashi wrote:
> 3. PatchEditorFrame send the patch being edited only when the window is
> opened.
> 
> Before every time the window is selected, the patch being edited was
> sent to synth's edit buffer by using send() method.  This was verbose.

I don't think it's verbose.
At least not if you edit several patches of one synthesizer at one time.
Maybe this is not the common way, but if you like to edit a patch and simoultanesly hold the original patch for comparison it's helpful.
In the past you don't need to send the patch explicitly but you only need to activate the window.
Another topic is the fact that playing a patch doesn't send the patch.
So if you like to compare 2 patches you only needed to activate the desired window and play the patch.
Now you have to activate the desired window, send the patch and play the patch.

I think the old way was easier and clearer. If you activated a window the synth holded the current patch.
Now you have to send the patch explicitly. If you forget to send the patch the synth holds not the current patch and you don't hear the 
sound you are expecting.

> BTW during this work, a question came to me.
> 
> The bank editor has a command 'delete'.  It 'delete's selected patches 
> (now).  But what the command does is just replace the patch name deleted
> to white spaces.  Do we really need the 'delete' command?

I think so. Because if you like to remove a patch from a bank you have to replace it manually by another patch.
The old way is easier and clearer.
Maybe it's better to replace the patch with a default (the "new") patch instead with withe spaces to ensure a valid patch structure.

Bye
Torsten

[Jsynthlib-devel] some core update

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

Hi,

I've checked in some core updates.

1. A menu entry is enabled only when the entry is valid.

Before most of (inconsistently not all) methods for menu entry checked
the validity of patches selected and ignored the command silently if the
patches selected is not valid.  This was not good user interface.

Now a menu entry is enabled only when the entry is valid.  Now each
method does not have to the validity check.

Note that 'Edit' command, for example, is not enabled on Scene window. 
As I wrote before,  Scene frame should not change a patch.

2. 'delete' command can delete multiple patches at once.

'copy' and 'cut' should be able to handle multiple patches at once, but
I could not find the way.

3. PatchEditorFrame send the patch being edited only when the window is
opened.

Before every time the window is selected, the patch being edited was
sent to synth's edit buffer by using send() method.  This was verbose.

4. various minor bug fixes and code updates.

These are not refactoring.  I made some changes of the behavior of
JSynthLib.  I might make some bugs.  Let me know if you see anything
wrong.


BTW during this work, a question came to me.

The bank editor has a command 'delete'.  It 'delete's selected patches 
(now).  But what the command does is just replace the patch name deleted
to white spaces.  Do we really need the 'delete' command?

Thanks.
-- 
Hiroo Hayashi