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

Re: [Jsynthlib-devel] synth driver interface change proposal

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

Rib> That's a good question. I know I had a reson at the time, but I can't
Rib> really remember it.  The only reason I can think of right now would be
Rib> for EditorBuilder, where the widgets need to be created without having
Rib> any drivers or patches.

Well, but EditorBuilder still can use other constructor.  I think it
cannot be the reason.

If you don't disagree, I'd like to revert the changes.

Thanks.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] synth driver interface change proposal

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

Hi Rib,

I have a question for you.

When you checked in the bunch of changes for the initial support for XML
at the end of August, you removed the following constructor from
PatchNameWidget class.

    /**
     * Creates a new <code>PatchNameWidget</code> instance.
     * @param label a label text.
     * @param patch a <code>Patch</code>, which is edited.
     */
    public PatchNameWidget(String label, IPatch patch) {
        this(label, patch, ((ISingleDriver) patch.getDriver()).getPatchNameSize());
    }

and replace many lines something like;

    new PatchNameWidget("Program Name ", patch)
to
    new PatchNameWidget("Program Name ", patch, ((Driver) patch.getDriver()).getPatchNameSize()),

Most of the change for the synth drivers on the commit were for this
change.  (More than 40 lines.)


Why you did make the change?
Why you did not keep the constructor and dir not define
IDriver.getPatchNameSize() (or IPatch.getNameSize())?


I'm thinking to revert the change.  But, of course, I cannot do that
without confirming your intention.

Thanks.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] synth driver interface change proposal

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

Hi Rib,

Rib> > IPatchDriver.export(IPatch)         -> IPatch.export()
Rib> > IPatchDriver.send(IPatch, int, int) -> send(int, int)
Rib> ...
Rib> > ISingleDriver.play(IPatch) -> ISinglePatch.play()
Rib> > ISingleDriver.send(IPatch) -> ISinglePatch.send()
Rib> 
Rib> We've talked in the past about multiple drivers that use the same
Rib> patch format.  That's why I never proposed moving play and send to the
Rib> Patch.  I tried to keep everything that would be device dependent in
Rib> the driver. Although I don't know how often this happens and how
Rib> important it is to support.

Well, even now Patch class has 'driver' field.  The driver is used by
default for most usage.  A user can specify any driver by using 'Send
to ...", "Store to ...", or "Reassign" command.

You comment reminded me that I forgot to write one important thing.  The
current implementation does not change Patch.driver field value on 'Send
to ..." nor "Store to ...".  But I'd like to call IPatch.setDriver
method before calling ISinglePatch() as follows;

    protected void doit () {
        p.setDriver((IPatchDriver) driverComboBox.getSelectedItem());
        ((ISinglePatch) p).send();
        ...

This means these command change the Patch.driver field.  I believe this
is better behavior for most of cases.  If a users speechifies a driver,
he or she wants to use the same driver next time for the patch.

Note that the current implementation does not save driver information
when a library is saved into a file.  Every time a library is reloaded,
the first matching driver in the list of possible drivers is selected. 
The choice may not be good for users.  To solve this problem, we have to
save the driver information in library file.  This requires a new file
format.

I think a patch should have driver information.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] synth driver interface change proposal

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

Hi Torsten,

Torsten> > IPatchDriver.isNullDriver()	    -> IPatch.hasNullDriver()
Torsten> Currently I'm not understanding what a NullDriver is.
Torsten> Is it the currently used generic driver?

Yes, it is.  But it is used only for the following usage.

Torsten> Or is this just a method to determine if no driver is
Torsten> assigned to a patch?

So I chose the name 'Null Driver'.

Torsten> > ISingleDriver.play(IPatch) -> ISinglePatch.play()
Torsten> > ISingleDriver.send(IPatch) -> ISinglePatch.send()
Torsten> Good.

Torsten> But maybe IPatch.play()/IPatch.send() are more advisable,
Torsten> because of concerning future (more) general kinds of patches
Torsten> (like collected Patches).
Torsten> For example, if we introduce a "collecting Patch", which
Torsten> collect the TX7 voice patch and the TX7 performance patch
Torsten> (both determine the voice completely), it's more useful to
Torsten> send/play both together than each one separated.
Torsten> I hope the term "collected patch" is clear. I don't know the
Torsten> common term for what I mean.  Of course I know that both
Torsten> methods are useless for bank patches, so the base definition
Torsten> has to check what kind of patch is actually choosen.

To handle this case, core can use ISinglePatch.play()|send() for each
Single Patch in the 'collecting Patch'.  No special support is
required for synth drivers.

Torsten> But maybe larger code changes are necessary to implement my
Torsten> idea, so it's ok to make your step first.

No change will be necessary (if I understand correctly).

=2E..
Torsten> > IBankDriver.getPatchName(IPatch, int)	  -> IBankPatch.getName(in=
t)
Torsten> > IBankDriver.setPatchName(IPatch, int, String)  -> IBankPatch.set=
Name(int, String)
=2E..
Torsten> Very good.
Torsten> We also need ISinglePatch.getName()
Torsten> resp. ISinglePatch.setName(), but both are already defined in
Torsten> IPatch interface.
Torsten> Why we need to define these methods in IBankPatch interface again?
Torsten> Is IBankPatch class not extending/implementing the IPatch interfac=
e?

Both ISinglePatch and IBankPatch extend IPatch.  Note that
IBankPatch.getName(int) and IBankPatch.setName(int, String) has 'int'
parameter which specifies a single patch in the Bank Patch.

Torsten> > new IPatch methods
Torsten> > 	getType()
Torsten> > 	isSinglePatch()
Torsten> > 	isBankPatch()
Torsten> Don't we need a method isConverterPatch() ?

A converter generates ISinglePatch (or IBankPatch).
--=20
Hiroo Hayashi

Re: [Jsynthlib-devel] synth driver interface change proposal

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

Hi Hiroo,

Hiroo Hayashi wrote:
> Hi,
> 
> I'd like to propose another core interface change.
> 
> summary:
>   1. more OO (Object Oriented) interfaces for Patch related methods.
>   2. introduce ISinglePatch and IBankPatch interfaces instead of
>      ISingleDriver and IBankDriver interfaces.
>   3. number of interface methods was reduced by 6 (=9-3).
>   4. most of delegation methods in Driver class was removed.  (For
>      example we need Driver.export(Patch) but don't need
>      Driver.export(IPatch) any more.
>   5. No affect on synth drivers (except minor changes for the XML driver
>      which uses new interfaces.)
These items sound very good.

> I found this during I made the change for calculateChecksum() I made
> last week.  I see this makes code clearer and think this is the way to
> go.  (This may be one of proposals Rib and/or Torsten made before, but I
> could not understand at that time.)
> 
> If you have any comments, let me know.
> 
> ------------------------------------------------------------
> IPatchDriver.export(IPatch) 	    -> IPatch.export()
> IPatchDriver.send(IPatch, int, int) -> send(int, int)
> IPatchDriver.hasEditor()	    -> IPatch.hasEditor()
 > IPatchDriver.edit(IPatch)	    -> IPatch.edit()
All OK.

> IPatchDriver.isNullDriver()	    -> IPatch.hasNullDriver()
Currently I'm not understanding what a NullDriver is.
Is it the currently used generic driver?
Or is this just a method to determine if no driver is assigned to a patch?

> ISingleDriver.play(IPatch) -> ISinglePatch.play()
> ISingleDriver.send(IPatch) -> ISinglePatch.send()
Good.
But maybe IPatch.play()/IPatch.send() are more advisable, because of concerning future (more) general kinds of patches (like collected 
Patches).
For example, if we introduce a "collecting Patch", which collect the TX7 voice patch and the TX7 performance patch (both determine the 
voice completely), it's more useful to send/play both together than each one separated.
I hope the term "collected patch" is clear. I don't know the common term for what I mean.
Of course I know that both methods are useless for bank patches, so the base definition has to check what kind of patch is actually 
choosen.

But maybe larger code changes are necessary to implement my idea, so it's ok to make your step first.

> IBankDriver.getNumPatches()			  -> IBankPatch.getNumPatches()
> IBankDriver.getNumColumns()			  -> IBankPatch.getNumColumns()
> IBankDriver.getPatchName(IPatch, int)		  -> IBankPatch.getName(int)
> IBankDriver.setPatchName(IPatch, int, String)	  -> IBankPatch.setName(int, String)
> IBankDriver.getPatch(IPatch, int)		  -> IBankPatch.get(int)
> IBankDriver.checkAndPutPatch(IPatch, IPatch, int) -> IBankPatch.put(IPatch, int)
> IBankDriver.deletePatch(IPatcha, int)		  -> IBankPatch.delete(int)
Very good.
We also need ISinglePatch.getName() resp. ISinglePatch.setName(), but both are already defined in IPatch interface.
Why we need to define these methods in IBankPatch interface again?
Is IBankPatch class not extending/implementing the IPatch interface?

> new IPatch methods
> 	getType()
> 	isSinglePatch()
> 	isBankPatch()
Don't we need a method isConverterPatch() ?

> removed IPatch methods
> 	play()
> 	send()
> 	getNumPatches()
> 	getNumColumns()
> 	getName(int)
> 	setName(int, String)
> 	get(int)
> 	put(IPatch, int)
> 	delete(int)
OK.

Hope it's help.

Bye
Torsten

[Jsynthlib-devel] synth driver interface change proposal

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

Hi,

I'd like to propose another core interface change.

summary:
  1. more OO (Object Oriented) interfaces for Patch related methods.
  2. introduce ISinglePatch and IBankPatch interfaces instead of
     ISingleDriver and IBankDriver interfaces.
  3. number of interface methods was reduced by 6 (=9-3).
  4. most of delegation methods in Driver class was removed.  (For
     example we need Driver.export(Patch) but don't need
     Driver.export(IPatch) any more.
  5. No affect on synth drivers (except minor changes for the XML driver
     which uses new interfaces.)

I found this during I made the change for calculateChecksum() I made
last week.  I see this makes code clearer and think this is the way to
go.  (This may be one of proposals Rib and/or Torsten made before, but I
could not understand at that time.)

If you have any comments, let me know.

------------------------------------------------------------
IPatchDriver.export(IPatch) 	    -> IPatch.export()
IPatchDriver.send(IPatch, int, int) -> send(int, int)
IPatchDriver.hasEditor()	    -> IPatch.hasEditor()
IPatchDriver.edit(IPatch)	    -> IPatch.edit()
IPatchDriver.isNullDriver()	    -> IPatch.hasNullDriver()

ISingleDriver.play(IPatch) -> ISinglePatch.play()
ISingleDriver.send(IPatch) -> ISinglePatch.send()

IBankDriver.getNumPatches()			  -> IBankPatch.getNumPatches()
IBankDriver.getNumColumns()			  -> IBankPatch.getNumColumns()
IBankDriver.getPatchName(IPatch, int)		  -> IBankPatch.getName(int)
IBankDriver.setPatchName(IPatch, int, String)	  -> IBankPatch.setName(int, String)
IBankDriver.getPatch(IPatch, int)		  -> IBankPatch.get(int)
IBankDriver.checkAndPutPatch(IPatch, IPatch, int) -> IBankPatch.put(IPatch, int)
IBankDriver.deletePatch(IPatcha, int)		  -> IBankPatch.delete(int)

new IPatch methods
	getType()
	isSinglePatch()
	isBankPatch()

removed IPatch methods
	play()
	send()
	getNumPatches()
	getNumColumns()
	getName(int)
	setName(int, String)
	get(int)
	put(IPatch, int)
	delete(int)
------------------------------------------------------------
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] checksum handling

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

Hi Hiroo,

Hiroo Hayashi wrote:
> Hi Torsten,
> 
> Thank you for your prompt reply.

My pleasure :-)
Even if I didn't wrote comments in the last time I'm still watching the mailinglist and the work you (and others) are doing.
BTW, great job.

> Torsten> I have no objections, but I think calculateChecksum is needed
> Torsten> in some defined cases.
> 
> Torsten> 1. If we import a patch or request a patch from a synth to
> Torsten> check the integrity of the received patch.
> 
> Core does not do this now.  If it will do this, I'll propose to add
> 'boolean IPatch.checkChecksum()' method.
> 
> # validateChecksum() may be better? :-)
> 
> Torsten> 2. if we change a patch; for example if we edit a single
> Torsten> patch or if we change the content of a bank patch.
> 
> Torsten> But I don't think that we need to call calculateChecksum if
> Torsten> we only send or store a patch from library to the synth,
> Torsten> because all patches which are stored resp. hold in the
> Torsten> library should have the right Checksum. If not, we made a
> Torsten> mistake while importing, loading, requesting a patch
> Torsten> resp. editing or changing the content of a bank patch.
> Torsten> Because of this scenario I don't think we need to call
> Torsten> calculateChecksum for every send or store action.  Of course
> Torsten> we need to call calculateChecksum if we are working in the
> Torsten> editor and send/play a patch for test purpose.
> 
> Good point.
> 
> Here is what I thought.
> 
> Checksum must be calculated after a patch is modified and before the
> patch goes to outside of JSynthLib.  I thought of the following three
> options.
> 
> 1. Calculate checksum every time a patch goes to outside of synth
>    driver. (my proposal)
> 
> Calculate checksum at the checkpoint of the borderline. (We can do this,
> because we reduced the number of road crossing the borderline.)
> 
> As you wrote, we have to calculate checksum even if the patch has
> correct checksum.  But I think this is minor for performance.
> 
> 2. Calculate checksum every time a patch is modified.
> 
> Before the patch goes to outside of JSynthLib, the patch may be
> modified multiple times.  We don't have to calculate checksum multiple
> times.  But this is not so bad.
> 
> Problem is that some synth drivers has to calculate checksum in send()
> methods, because patch number and/or bank number information is a part
> of sysex message.  Unless I check every synth driver carefully, I have
> to calculate checksum in send() methods as we do for option 1.  Then
> there is no advantage to option 1.
> 
> 3. Mark a patch as 'modified' every time a patch is modified, and
>    calculate checksum every time a patch goes to outside of synth
>    driver if the patch is marked as 'modified'.
> 
> This is the best way.  But this requires more efforts than option 2.
> This is an extension of option 1.  If we want to do this, we can do this
> after we do option 1.
> 
> As a result I chose option 1.

Performance wasn't the main issue of my remarks.
I lost a little bit the overview of the current core structure.
So I thought a little bit about the general question if a call of calculateChecksum is necessary or not if a certain action is started.
Another topic is that I only know my DX7 (and his brothers/sisters) which has a simple checksum handling.

But I don't want to start a discussion about the most sophisticated checksum handling.
You have absolutly right with looking for a pragmatic solution.
And making option 1 as the first step is looking good.

Option 3 (marking a changed patch as modified) is looking very interesting for the actions "send", "play", "store", "export", "pasting
into library", etc...
But as you wrote this can be a future step.

BTW, your mentioned method validateChecksum() would also calculate the checksum of "imported" or "requested" patches. The only
difference would be (from my point of view) that validateChecksum() compares the calculated checksum with the original checksum of the
imported/requested patch (and start some while calculateChecksum() replaces the checksum of the patch without comparing immediatly.
I don't know if the information of a wrong checksum of an imported/requested patch will give us an additional benefit.

> Torsten> I also think this is the right time to decide, if it's not
> Torsten> better to put all the calculateChecksum stuff in an own core
> Torsten> class and remove it from the drivers. Of course the drivers
> Torsten> must contain the necessary information (in the constucto?) of
> Torsten> the kind of checksum (2's complement, ...), the start and end
> Torsten> of data which are concerned by the checksum, the place of the
> Torsten> checksum itself in the patch, ...
> 
> As the result of my proposal, core does not care about checksum at
> all.  It will be driver's responsibility to pass a patch with correct
> checksum to core.
> 
> As you wrote checksum is dependent with each driver.  I don't think
> there is many code which core can have for checksum.  Now we have
> DriverUtil.calculateChecksum() method.  We can add some other similar
> method for other algorithm.
> 
> I'm thinking to define a new IPatch class which supports a patch
> consists from multiple sysex messages.  The new patch class will have
> methods  and fields of the checksum (ex.  the start and end of data
> which are concerned by the checksum, the place of the checksum itself in
> the patch, etc.).  For different checksum algorithm, overriding is the
> easiest way, I think. As you see DriverUtil.calculateChecksum() method,
> it a simple method.

I see and I agree to you.
calculateChecksum() should be driver's task.
This is the most flexible way (and maybe the easiest :-) ).


Bye
Torsten

Re: [Jsynthlib-devel] Small Patchsize

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

Hiroo,

Ok, I commented out the lines, retested and then
committed the change.

Jeff

--- Hiroo Hayashi <hir...@co...> wrote:

> Jeff,
> 
> Jeff> If you think you can safely delete these lines
> (or
> Jeff> change the 20 to a lower threshold), I will
> include a
> Jeff> driver/editor for this patch. But if it's
> going to
> Jeff> cause other problems, don't worry about it. It
> only
> Jeff> includes a few settings, all of which can be
> adjusted
> Jeff> from the front panel very easily, so it's not
> a big
> Jeff> deal.
> 
> I don't think the lines make sense.  Just remove
> them.  (Or comment them out
> and add comments if you prefer.)
> -- 
> Hiroo Hayashi
> 
> 


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: [Jsynthlib-devel] checksum handling

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

Hi Torsten,

Thank you for your prompt reply.

Torsten> I have no objections, but I think calculateChecksum is needed
Torsten> in some defined cases.

Torsten> 1. If we import a patch or request a patch from a synth to
Torsten> check the integrity of the received patch.

Core does not do this now.  If it will do this, I'll propose to add
'boolean IPatch.checkChecksum()' method.

# validateChecksum() may be better? :-)

Torsten> 2. if we change a patch; for example if we edit a single
Torsten> patch or if we change the content of a bank patch.

Torsten> But I don't think that we need to call calculateChecksum if
Torsten> we only send or store a patch from library to the synth,
Torsten> because all patches which are stored resp. hold in the
Torsten> library should have the right Checksum. If not, we made a
Torsten> mistake while importing, loading, requesting a patch
Torsten> resp. editing or changing the content of a bank patch.
Torsten> Because of this scenario I don't think we need to call
Torsten> calculateChecksum for every send or store action.  Of course
Torsten> we need to call calculateChecksum if we are working in the
Torsten> editor and send/play a patch for test purpose.

Good point.

Here is what I thought.

Checksum must be calculated after a patch is modified and before the
patch goes to outside of JSynthLib.  I thought of the following three
options.

1. Calculate checksum every time a patch goes to outside of synth
   driver. (my proposal)

Calculate checksum at the checkpoint of the borderline. (We can do this,
because we reduced the number of road crossing the borderline.)

As you wrote, we have to calculate checksum even if the patch has
correct checksum.  But I think this is minor for performance.

2. Calculate checksum every time a patch is modified.

Before the patch goes to outside of JSynthLib, the patch may be
modified multiple times.  We don't have to calculate checksum multiple
times.  But this is not so bad.

Problem is that some synth drivers has to calculate checksum in send()
methods, because patch number and/or bank number information is a part
of sysex message.  Unless I check every synth driver carefully, I have
to calculate checksum in send() methods as we do for option 1.  Then
there is no advantage to option 1.

3. Mark a patch as 'modified' every time a patch is modified, and
   calculate checksum every time a patch goes to outside of synth
   driver if the patch is marked as 'modified'.

This is the best way.  But this requires more efforts than option 2.
This is an extension of option 1.  If we want to do this, we can do this
after we do option 1.

As a result I chose option 1.

Torsten> I also think this is the right time to decide, if it's not
Torsten> better to put all the calculateChecksum stuff in an own core
Torsten> class and remove it from the drivers. Of course the drivers
Torsten> must contain the necessary information (in the constucto?) of
Torsten> the kind of checksum (2's complement, ...), the start and end
Torsten> of data which are concerned by the checksum, the place of the
Torsten> checksum itself in the patch, ...

As the result of my proposal, core does not care about checksum at
all.  It will be driver's responsibility to pass a patch with correct
checksum to core.

As you wrote checksum is dependent with each driver.  I don't think
there is many code which core can have for checksum.  Now we have
DriverUtil.calculateChecksum() method.  We can add some other similar
method for other algorithm.

I'm thinking to define a new IPatch class which supports a patch
consists from multiple sysex messages.  The new patch class will have
methods  and fields of the checksum (ex.  the start and end of data
which are concerned by the checksum, the place of the checksum itself in
the patch, etc.).  For different checksum algorithm, overriding is the
easiest way, I think. As you see DriverUtil.calculateChecksum() method,
it a simple method.

Torsten> To be honour I have no idea how to implement this and it
Torsten> remains the point of changing core classes if a new kind of
Torsten> checksum is needed by a new driver. I have also no idea how
Torsten> to implement this if a driver separate a patch in several
Torsten> sysex messages because of it's large size. And shurely I
Torsten> missed some items.

Torsten> Bye
Torsten> Torsten
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] checksum handling

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

Hi Hiroo,

Hiroo Hayashi wrote:
> Hi,
> 
> I'd like to propose another core change of checksum handling.
> 
> One of my questions when I made my synth driver was when I had to call
> calculateChecksum method.  Some of core methods calculate checksum.  And
> a synth driver also calculate checksum.  It seems that calculateChecksum
> is called many times unnecessarily.  I guess this situation occurred
> because it was not clear who has to calculate checksum and some method
> calculated it for safe.
> 
> Now we define the boundary between core and synthdrivers by defining
> interfaces (IDriver, etc.).  Now a patch goes to outside of synthdriver
> via the following methods.
>         case 1. void IPatchDriver.send(IPatch, int, int)
>         case 2. void ISingleDriver.send(IPatch)
>         case 3. byte[] IPatch.getByteArray()
>         case 4. void Driver.send(byte[])
> 
> Here is my proposal
> Proposal a) call calculateChecksum(Patch) in Driver.send(IPatch, int,
> int) and Driver.send(IPatch).
> 
> This cover the case 1 and 2.  This does not require any synthdriver
> change.
> 
> Proposal b) Define IPatch.export(IPatch) which returns a byte array as
> getByteArray() after it calculate checksum.  This does not require any
> synthdriver change, either.
> 
> This cover the case 3.  case 3 is for exporting Patch.
> 
> For case 4, before Driver.send(byte[]) is called, calculateChecksum() is
> always called already.
> 
> By the simple proposal a) and b),  both core and synth drivers do not
> have to call calculateChecksum() method any more.  We can get rid of 
> IPatchDriver.calculateCheckSum(IPatch) interface method instead of
> adding IPatchDriver.export().
> 
> Driver class taking care of all of its subclass.  A Synth driver
> extending Driver class does not have to call calculateChecksum method. 
> And core does not have to call calculateChecksum method, either.
> 
> This sounds good, doesn't it?
> 
> I made fix locally.  If there is no objection, I'll check it in a few
> days later.
> 
> Any feedback is welcome.

I have no objections, but I think calculateChecksum is needed in some defined cases.

1. If we import a patch or request a patch from a synth to check the integrity of the received patch.
2. if we change a patch; for example if we edit a single patch or if we change the content of a bank patch.

But I don't think that we need to call calculateChecksum if we only send or store a patch from library to the synth, because all 
patches which are stored resp. hold in the library should have the right Checksum. If not, we made a mistake while importing, loading, 
requesting a patch resp. editing or changing the content of a bank patch.
Because of this scenario I don't think we need to call calculateChecksum for every send or store action.
Of course we need to call calculateChecksum if we are working in the editor and send/play a patch for test purpose.

I also think this is the right time to decide, if it's not better to put all the calculateChecksum stuff in an own core class and 
remove it from the drivers. Of course the drivers must contain the necessary information (in the constucto?) of the kind of checksum 
(2's complement, ...), the start and end of data which are concerned by the checksum, the place of the checksum itself in the patch, ...
To be honour I have no idea how to implement this and it remains the point of changing core classes if a new kind of checksum is needed 
by a new driver. I have also no idea how to implement this if a driver separate a patch in several sysex messages because of it's large 
size. And shurely I missed some items.

Bye
Torsten

[Jsynthlib-devel] checksum handling

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

Hi,

I'd like to propose another core change of checksum handling.

One of my questions when I made my synth driver was when I had to call
calculateChecksum method.  Some of core methods calculate checksum.  And
a synth driver also calculate checksum.  It seems that calculateChecksum
is called many times unnecessarily.  I guess this situation occurred
because it was not clear who has to calculate checksum and some method
calculated it for safe.

Now we define the boundary between core and synthdrivers by defining
interfaces (IDriver, etc.).  Now a patch goes to outside of synthdriver
via the following methods.
        case 1. void IPatchDriver.send(IPatch, int, int)
        case 2. void ISingleDriver.send(IPatch)
        case 3. byte[] IPatch.getByteArray()
        case 4. void Driver.send(byte[])

Here is my proposal
Proposal a) call calculateChecksum(Patch) in Driver.send(IPatch, int,
int) and Driver.send(IPatch).

This cover the case 1 and 2.  This does not require any synthdriver
change.

Proposal b) Define IPatch.export(IPatch) which returns a byte array as
getByteArray() after it calculate checksum.  This does not require any
synthdriver change, either.

This cover the case 3.  case 3 is for exporting Patch.

For case 4, before Driver.send(byte[]) is called, calculateChecksum() is
always called already.

By the simple proposal a) and b),  both core and synth drivers do not
have to call calculateChecksum() method any more.  We can get rid of 
IPatchDriver.calculateCheckSum(IPatch) interface method instead of
adding IPatchDriver.export().

Driver class taking care of all of its subclass.  A Synth driver
extending Driver class does not have to call calculateChecksum method. 
And core does not have to call calculateChecksum method, either.

This sounds good, doesn't it?

I made fix locally.  If there is no objection, I'll check it in a few
days later.

Any feedback is welcome.
-- 
Hiroo Hayashi

Fwd: Re: [Jsynthlib-devel] Small Patchsize

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

Hiroo,

The patch that I'm having the problem with is the
system info patch for the DM5. It has a seven byte
header and the data is only three bytes. With the eox
byte, that makes 11. All it contains is some global
settings like device ID, the patch number of the
currently selected drum set, and one byte of on/off
settings for stuff like program change enable, control
change enable, etc. SoundDiver supports this patch so
I thought I should include a driver and editor for it
too. 

I tried running a test where I commented out those
lines and it appears to solve the problem from my
perspective. But I did not test for any other
side-effects. 

If you think you can safely delete these lines (or
change the 20 to a lower threshold), I will include a
driver/editor for this patch. But if it's going to
cause other problems, don't worry about it. It only
includes a few settings, all of which can be adjusted
from the front panel very easily, so it's not a big
deal.

Thanks,
Jeff 


--- Hiroo Hayashi <hir...@co...> wrote:

> From: Hiroo Hayashi <hir...@co...>
> To: JSynthLib Development
> <jsy...@li...>
> Subject: Re: [Jsynthlib-devel] Small Patchsize
> Date: Tue, 28 Sep 2004 22:39:18 -0500
> 
> Jeff,
> 
> I've been having the question on the lines.  If
> there are really patches
> less than 20bytes long, there is no reason for them.
>  My take is getting
> rid of the lines.
> 
> On Tue, 28 Sep 2004 17:07:12 -0700 (PDT)
> Jeff Weber <jww...@ya...> wrote:
> 
> Jeff> I found was in the method
> Jeff> SysexGetDialog.pasteIntoSelectedFrame. The
> first two
> Jeff> lines in that method are:
> Jeff> if (sysexSize < 20)
> Jeff>     return;
> Jeff> 
> Jeff> pasteIntoSelectedFrame won't do anything if
> the patch
> Jeff> is less than 20 bytes. The driver that I'm
> having the
> Jeff> problem with is for the system info patch for
> the DM5,
> Jeff> which is only 11 bytes long (including the
> header and
> Jeff> eox byte). Why does pasteIntoSelectedFrame
> ignore
> Jeff> patches that are less than 20 bytes? Can
> anyone
> Jeff> suggest a workaround?
> 
> -- 
> Hiroo Hayashi
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide
> on ITManagersJournal
> Use IT products in your business? Tell us what you
> think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates!
> Click to find out more
>
http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> 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 

Re: [Jsynthlib-devel] Small Patchsize

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

Jeff,

I've been having the question on the lines.  If there are really patches
less than 20bytes long, there is no reason for them.  My take is getting
rid of the lines.

On Tue, 28 Sep 2004 17:07:12 -0700 (PDT)
Jeff Weber <jww...@ya...> wrote:

Jeff> I found was in the method
Jeff> SysexGetDialog.pasteIntoSelectedFrame. The first two
Jeff> lines in that method are:
Jeff> if (sysexSize < 20)
Jeff>     return;
Jeff> 
Jeff> pasteIntoSelectedFrame won't do anything if the patch
Jeff> is less than 20 bytes. The driver that I'm having the
Jeff> problem with is for the system info patch for the DM5,
Jeff> which is only 11 bytes long (including the header and
Jeff> eox byte). Why does pasteIntoSelectedFrame ignore
Jeff> patches that are less than 20 bytes? Can anyone
Jeff> suggest a workaround?

-- 
Hiroo Hayashi

[Jsynthlib-devel] Small Patchsize

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

During this past week I started working on drivers for
the Alesis DM5 and I've run into an issue. It happens
when I try to do a Get on one of the patches. The DM5
has five different patch types (so I need five
drivers). The problem is the Get works on all of them
except for one. At first I thought there was a problem
with the driver for that particular patch so I tried
to use my debugger to figure out the problem. But I
couldn't get it to stop at any of my breakpoints.
Finally, I set up breakpoints for a different driver
that works and I worked my way up the call stack. What
I found was in the method
SysexGetDialog.pasteIntoSelectedFrame. The first two
lines in that method are:
if (sysexSize < 20)
    return;

pasteIntoSelectedFrame won't do anything if the patch
is less than 20 bytes. The driver that I'm having the
problem with is for the system info patch for the DM5,
which is only 11 bytes long (including the header and
eox byte). Why does pasteIntoSelectedFrame ignore
patches that are less than 20 bytes? Can anyone
suggest a workaround?

Thanks,
Jeff


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

[Jsynthlib-devel] createPatch and Converter interface change

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

Hi,

I've checked in the following interface changes.

        IDriver
        - IPatch[] createPatch(byte[] sysex);

        IPatchDriver
        + IPatch createPatch(byte[] sysex);
        - IPatch[] createPatch(SysexMessage[] msgs);
        + IPatch[] createPatches(SysexMessage[] msgs);

        IConverter
        + IPatch[] createPatches(byte[] sysex);

        IConverter does not extend IDriver any more.

IDriver createPatch(byte[] sysex) was divided into
IPatch.IPatchDriver.createPatch(byte[] sysex) and
IConverter.createPatches(byte[] sysex). 

IPatchDriver.createPatch(SysexMessage[] msgs)
was renamed to IPatchDriver.createPatches(SysexMessage[] msgs).

This change simplify method calls for these methods a little.  More
importantly I don't have to have independent Driver class for Converter.
Now a Single Driver can also implement IConverter.

No changes are required for the current synth drivers.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] incompatible Scene class

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

Hiroo,

I'm using a GUI tool called MacCVS Pro. I had zero
experience with CVS when I started on this project so
I thought a GUI tool would help keep me from screwing
things up. Whenever I select multiple files for commit
it apparently generates a separate commit command for
each file. I just went back and looked at the
documentation to see if there was a way to make it
commit a whole directory or use wildcards.
Unfortunately it doesn't appear to have that
capability.

If this is really a problem for you, I suppose I could
learn to use the command line.

Jeff
--- Hiroo Hayashi <hir...@co...> wrote:

> Jeff,
> 
> Thank you for your report.  I'm glad to hear.
> 
> BTW which cvs tool are you using?  It seems you
> commit files one by one. 
> If you are using command line cvs, you can do, "cvs
> commit" or "cvs
> commit *.java" and you can commit the files at once.
>  This help us a
> little, because we will receive only one mail per
> directory.  Just FYI.
> 
> On Wed, 22 Sep 2004 17:55:08 -0700 (PDT)
> Jeff Weber <jww...@ya...> wrote:
> 
> Jeff> Hiroo,
> Jeff> 
> Jeff> I tried drag & drop for every possible
> combination of
> Jeff> different window types. It appears to be
> working fine
> Jeff> now.
> Jeff> 
> Jeff> Jeff
> 
> -- 
> Hiroo Hayashi
> 
> 


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Fwd: Re: [Jsynthlib-devel] incompatible Scene class

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

Hiroo,

I tried drag & drop for every possible combination of
different window types. It appears to be working fine
now.

Jeff
--- Hiroo Hayashi <hir...@co...> wrote:

> From: Hiroo Hayashi <hir...@co...>
> To: JSynthLib Development
> <jsy...@li...>
> Subject: Re: [Jsynthlib-devel] incompatible Scene
> class
> Date: Tue, 21 Sep 2004 20:29:22 -0500
> 
> Hi,
> 
> Last night I checked in the various change for
> drag&drop (cut&paster,
> TransferHandler/Transferable) related code.
> 
> The most important update is that now we can
> drag&drop Scene and can
> drag&drop Patch and Scene between a LibraryFrame and
> a SceneFrame.  This
> has been a known bug for a long time.
> 
> Hiroo> Jeff> I'm getting the following exception
> when I try to drag
> Hiroo> Jeff> a patch from a bank window to a library
> window. Can
> Hiroo> Jeff> anyone reproduce this?
> Hiroo> 
> Hiroo> Hiroo> Yes, I can.  I guess my bug fix made
> this bug.  I'll take a look.
> 
> I also made a fix for this, but I don't understand
> why the fix is
> necessary.  For example if I drag&drop a Patch from
> a LibraryFrame to
> another LibraryFrame, you will see the following
> debug message if you
> run JSynthLib with debug option ('2').
> 
> DBG>PatchListTransferHandler.createTransferable
> [Roland TD6 Drumkit] f0 41 00 00 3f 12 41 62 00 00
> 41 63 75 53 74 69 .. 02 74 f7
> DBG>Patch.isDataFlavorSupported
>
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=[Lcore.IPatch;]
> DBG>Patch.getTransferData:
>
flavor=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=[Lcore.IPatch;]
> DBG>Patch.getTransferData: Patch=[Roland TD6
> Drumkit] f0 41 00 00 3f 12 41 62 00 00 41 63 75 53
> 74 69 .. 02 74 f7, MIDI-OX
> DBG>PatchTransferHandler.importData:
>
t=java.awt.dnd.DropTargetContext$TransferableProxy@57828d
> DBG>PatchTransferHandler.importData: Patch=[null] f0
> 41 00 00 3f 12 41 62 00 00 41 63 75 53 74 69 .. 02
> 74 f7MIDI-OX
> 
> This means that the Patch.driver field was set
> properly when
> Patch.getTransferData returns a patch.
> 
> But when PatchTransferHandler.importData receives
> the data, the value of driver
> field becomes 'null'.  Patch.driver field is private
> access now, and
> is set only by Patch.setDriver(IPatchDriver) method.
>  When the argument
> Patch.setDriver() is null, setDriver method sets
> driver field Generic
> Driver.  This means there is no way to set 'null' on
> Patch.driver field.
> 
> Scene also has similar problem.  driver field for a
> Patch in a Scene
> becomes 'null' when it is received by a importData
> method.
> 
> For now I've fixed this bug by adding the following
> code.
>         p.setDriver((IPatchDriver)
> DriverUtil.chooseDriver(p.getByteArray()));
> 
> This is very strange.  I don't understand why this
> line is required.  If
> you have any clue, let me know.
> -- 
> Hiroo Hayashi
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE.
> Be one of 170
> Project Admins to receive an Apple iPod Mini FREE
> for your judgement on
> who ports your project to Linux PPC the best.
> Sponsored by IBM.
> Deadline: Sept. 24. Go here:
> http://sf.net/ppc_contest.php
> _______________________________________________
> 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 

Re: [Jsynthlib-devel] incompatible Scene class

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

I see the problem.

Hiroo> But when PatchTransferHandler.importData receives the data, the value of driver
Hiroo> field becomes 'null'.  Patch.driver field is private access now, and

Drag&drop and cut&paste have to do data transfer between independent
application.  For this reason serialization has to be used and the value
of transient field driver is lost.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] incompatible Scene class

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

Hi,

Last night I checked in the various change for drag&drop (cut&paster,
TransferHandler/Transferable) related code.

The most important update is that now we can drag&drop Scene and can
drag&drop Patch and Scene between a LibraryFrame and a SceneFrame.  This
has been a known bug for a long time.

Hiroo> Jeff> I'm getting the following exception when I try to drag
Hiroo> Jeff> a patch from a bank window to a library window. Can
Hiroo> Jeff> anyone reproduce this?
Hiroo> 
Hiroo> Hiroo> Yes, I can.  I guess my bug fix made this bug.  I'll take a look.

I also made a fix for this, but I don't understand why the fix is
necessary.  For example if I drag&drop a Patch from a LibraryFrame to
another LibraryFrame, you will see the following debug message if you
run JSynthLib with debug option ('2').

DBG>PatchListTransferHandler.createTransferable [Roland TD6 Drumkit] f0 41 00 00 3f 12 41 62 00 00 41 63 75 53 74 69 .. 02 74 f7
DBG>Patch.isDataFlavorSupported java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=[Lcore.IPatch;]
DBG>Patch.getTransferData: flavor=java.awt.datatransfer.DataFlavor[mimetype=application/x-java-serialized-object;representationclass=[Lcore.IPatch;]
DBG>Patch.getTransferData: Patch=[Roland TD6 Drumkit] f0 41 00 00 3f 12 41 62 00 00 41 63 75 53 74 69 .. 02 74 f7, MIDI-OX
DBG>PatchTransferHandler.importData: t=java.awt.dnd.DropTargetContext$TransferableProxy@57828d
DBG>PatchTransferHandler.importData: Patch=[null] f0 41 00 00 3f 12 41 62 00 00 41 63 75 53 74 69 .. 02 74 f7MIDI-OX

This means that the Patch.driver field was set properly when
Patch.getTransferData returns a patch.

But when PatchTransferHandler.importData receives the data, the value of driver
field becomes 'null'.  Patch.driver field is private access now, and
is set only by Patch.setDriver(IPatchDriver) method.  When the argument
Patch.setDriver() is null, setDriver method sets driver field Generic
Driver.  This means there is no way to set 'null' on Patch.driver field.

Scene also has similar problem.  driver field for a Patch in a Scene
becomes 'null' when it is received by a importData method.

For now I've fixed this bug by adding the following code.
        p.setDriver((IPatchDriver) DriverUtil.chooseDriver(p.getByteArray()));

This is very strange.  I don't understand why this line is required.  If
you have any clue, let me know.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] incompatible Scene class

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

I came up with an solution for this.  By adding the following line onto
Scene.java, I can load old scene file.
    static final long serialVersionUID = -7048122592493606437L;

I found this by thinking how Patch file worked.  The signature of Patch
class also changed, but we can load old library files.  I don't really
understand how does this work.  But I guess (hope) this works because
the signature change is only changing Patch class to compatible IPatch
interface.

Let us know if you see any problem.

Hiroo> You made a change in Scene.java;
Hiroo>     private Patch patch;
Hiroo> into;
Hiroo>     private IPatch patch;
Hiroo> 
Hiroo> This change breaks Scene file compatibility.  Now JSynthLib in CVS head
Hiroo> cannot read Scene file which was created before the change.  This is bad.
Hiroo> 
Hiroo> To keep file compatibility we need to revert the change on Scene.java
Hiroo> and make a new Scene class (NScene ?) which uses IPatch so far.
Hiroo> 
Hiroo> As a long term solution we need define new file format.  One way is to
Hiroo> use Storable class.  Another way is XML base format as we discuss before.
-- 
Hiroo Hayashi

[Jsynthlib-devel] incompatible Scene class

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

Rib,

You made a change in Scene.java;
    private Patch patch;
into;
    private IPatch patch;

This change breaks Scene file compatibility.  Now JSynthLib in CVS head
cannot read Scene file which was created before the change.  This is bad.

To keep file compatibility we need to revert the change on Scene.java
and make a new Scene class (NScene ?) which uses IPatch so far.

As a long term solution we need define new file format.  One way is to
use Storable class.  Another way is XML base format as we discuss before.

Jeff> I'm getting the following exception when I try to drag
Jeff> a patch from a bank window to a library window. Can
Jeff> anyone reproduce this?

Hiroo> Yes, I can.  I guess my bug fix made this bug.  I'll take a look.

Before fixing this bug and other bugs in SceneFrameLibrary, I made
LibraryFrame and SceneFrame class clean.  Most of their methods were
exactly same.  I made AbstractLibraryFrame class which was an interface
as an abstract class.  The change should not change behavior of
JSynthLib.
-- 
Hiroo Hayashi

[Jsynthlib-devel] ANT build.xml file changed

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

Hello,

I've updated the ANT build.xml file.

Regards,
Joachim

> -----Ursprungliche Nachricht-----
> Von: Joachim Backhaus [mailto:jba...@pi...]
> Gesendet: Mittwoch, 8. September 2004 11:57
> An: JSynthLib Development
> Betreff: AW: compiiling the current CVS head (Re: 
> [Jsynthlib-devel] XML
> Dr ivers)
> 
> 
> > Please update build.xml. > someone
> 
> Currently I have no time for testing that.
> 
> At the weekend I will have a look at it.
> 
> Regards,
> J.Backhaus
> 
> > -----Ursprungliche Nachricht-----
> > Von: Hiroo Hayashi [mailto:hir...@co...]
> > Gesendet: Mittwoch, 8. September 2004 06:05
> > An: JSynthLib Development
> > Betreff: compiiling the current CVS head (Re: [Jsynthlib-devel] XML
> > Drivers)
> > 
> > 
> > Rib> missing.  I've added two jar files which you will need 
> > to put in your
> > Rib> classpath.  These are for the Groovy scripting language, 
> > which has
> > 
> > I've updated the compile procedure in doc/programming.html 
> as follows;
> > 
> > javac core/*.java
> > javac synthdrivers/*/*/*.java synthdrivers/*/*.java
> > javac -classpath '.;Groovy.jar' org/jsynthlib/*/*/*.java 
> > org/jsynthlib/*/*.java
> > javac *.java
> > 
> > Please update Makefile and build.xml. > someone
> > -- 
> > Hiroo Hayashi
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by BEA Weblogic Workshop
> > FREE Java Enterprise J2EE developer tools!
> > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> > _______________________________________________
> > Jsynthlib-devel mailing list
> > Jsy...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
> > 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
> 

[Jsynthlib-devel] programming.html update and DriverUtil

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

Hi,

I've checked two changes.

1. programming.html
I've updated programming.html to be consistent with the current API.  I
had to update many lines.  And as you see, English is not my first
language.  Please take a look, and give me your feedback.

After waiting for your feedback, I'll change references to classes and
methods to hyperlinks.

2. DriverUtil class
There are some static classes for Synth Driver.  I made a new utility
class, DriverUtil class.  The following methods are moved into the class.

  Driver.generateNumbers
  Driver.calculateChecksum(Patch, int, int, int)
  Patch.valueOf(byte[])
  Patch.getPatchHeader(byte[])
  Patch.chooseDriver(byte[])
  Patch.chooseDriver(byte[], Device)

-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Exception dragging from bank window to library window

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

Jeff> I'm getting the following exception when I try to drag
Jeff> a patch from a bank window to a library window. Can
Jeff> anyone reproduce this?

Yes, I can.  I guess my bug fix made this bug.  I'll take a look.
-- 
Hiroo Hayashi

[Jsynthlib-devel] Exception dragging from bank window to library window

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

Hi all,

I'm getting the following exception when I try to drag
a patch from a bank window to a library window. Can
anyone reproduce this?

java.lang.NullPointerException
	at core.Patch.getDevice(Patch.java:166)
	at
core.LibraryFrame$PatchListModel.getValueAt(LibraryFrame.java:591)
	at javax.swing.JTable.getValueAt(JTable.java:1771)
	at
javax.swing.JTable.prepareRenderer(JTable.java:3724)
	at
javax.swing.plaf.basic.BasicTableUI.paintCell(BasicTableUI.java:1149)
	at
javax.swing.plaf.basic.BasicTableUI.paintCells(BasicTableUI.java:1051)
	at
javax.swing.plaf.basic.BasicTableUI.paint(BasicTableUI.java:974)
	at
javax.swing.plaf.ComponentUI.update(ComponentUI.java:154)
	at
javax.swing.JComponent.paintComponent(JComponent.java:541)
	at javax.swing.JComponent.paint(JComponent.java:808)
	at
javax.swing.JComponent.paintChildren(JComponent.java:647)
	at javax.swing.JComponent.paint(JComponent.java:817)
	at javax.swing.JViewport.paint(JViewport.java:720)
	at
javax.swing.JComponent.paintChildren(JComponent.java:647)
	at javax.swing.JComponent.paint(JComponent.java:817)
	at
javax.swing.JComponent._paintImmediately(JComponent.java:4707)
	at
javax.swing.JComponent.paintImmediately(JComponent.java:4489)
	at
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:436)
	at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:117)
	at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
	at
java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
	at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
	at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:184)
	at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178)
	at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:170)
	at
java.awt.EventDispatchThread.run(EventDispatchThread.java:100)



		
_______________________________
Do you Yahoo!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool