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

[Jsynthlib-devel] Enhancements to SysexWidgets??

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

I have a couple of suggestions making SysexWidgets a
little more flexible. I have often times run into a
situation where the range of values sent by a
ScrollBarWidget or a KnobWidget needs to go from high
to low rather than from low to high.

I wanted to see what would happen if I created a
KnobWidget with the min and max values switched around
(i.e. min =  127 and max = 0) so I tried it. The
SysexSender already appears to handle this correctly
but the ParamModel just sets the value to zero for all
input values.

The way I have handled this in the past was to
subclass ParamModel to handle the high to low range.
How much effort would it take to modify ParamModel to
handle this situation and make subclassing
unnecessary?

Another issue I ran into happened when I attempted to
create a CheckBoxWidget to control the Drive setting
on the V-Amp 2. This is just an on/off setting and a
CheckBoxWidget would be the obvious choice. Apparently
the CheckBoxWidget is hard wired to send only values
of 0 for "off" or 1 for "on". But the Drive setting on
the V-Amp is turned off by any values in the range
0-63 and on by any values in the range 64-127. Both a
0 and a 1 will turn it off. 

To use a CheckBoxWidget for this right now, I would
need to subclass both a ParamModel and a SysexSender.
But if the CheckBoxWidget had another constructor that
accepted custom on and off values, this would not be
necessary.



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

[Jsynthlib-devel] Latest Roland MT-32 Editor

[Fred J. K. <fj...@xs...>]

The Roland MT-32 editor in the current 0.20 distribution is outdated. A 
newer version is available at: 
http://electrickery.xs4all.nl/digaud/mt32/. I made it quite some time ago
for the 0.19 version. At the moment my Java development environment is 
broken so I cannot
test it with the latest 0.20.

Is there a document describing the current development environment?

Fred Jan Kraan

JSLFrame related fixes (Re: SDI mode (Re: [Jsynthlib-devel] change proposal))

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

Hi,

I've checked in the following fix on the main trunk.

-----------------------
Make JSLDesktop, JSLFrame, and JSLWindowMenu JSynthLib independent.
  Move Menu related code to AppConfig.
  Add configuration option of Tool Bars for frames in SDI mode.
  no toolbar window in SDI mode for Mac OS.
-----------------------

I might break something as usual especially for MacOS X which I cannot
test well.  Let me know if you see anything wrong.

Thanks.

On Sun, 13 Feb 2005 15:04:59 -0600
Hiroo Hayashi <hir...@co...> wrote:

Hiroo> Rib> > The following implementation may be better.
Hiroo> Rib> > 
Hiroo> Rib> >         No toolbar window on MacOS
Hiroo> Rib> >         toolbar is attached on every frame.
Hiroo> Rib> >         toolbar can be removed by user preference.
Hiroo> Rib> >         default is enabled on MacOS, and is disabled on other OSs.
Hiroo> Rib> > 
Hiroo> Rib> > How do you think?
Hiroo> Rib> 
Hiroo> Rib> That sounds really good.
Hiroo> 
Hiroo> OK.  I'll do that.
Hiroo> 
Hiroo> Rib> > I cannot accept "JSLJSLFrame".  "MyFrame" is a candidate.  I don't like
Hiroo> Rib> > it, but have no better name.
Hiroo> Rib> > 
Hiroo> Rib> > Another way is to rename "JSLDesktop"/"JSLFrame" class.  For example
Hiroo> Rib> > "MMDesktop" and "MMFrame".  "MM" stands for "Multi Mode".
Hiroo> Rib> > 
Hiroo> Rib> > Do you have any suggestion?
Hiroo> Rib> 
Hiroo> Rib> How about something like MenuFrame or JSLMenuBarFrame?
Hiroo> 
Hiroo> Sold!
Hiroo> -- 
Hiroo> Hiroo Hayashi
-- 
Hiroo Hayashi

[Jsynthlib-devel] 0.2 tag....

[Joe E. <jo...@em...>]

So... are we allowed to commit regular (non-bugfix) stuff to the CVS again?

- Joe

AW: [Jsynthlib-devel] TC Electronic G-Major

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

Hello,

OK,
I opened a feature request with the number 1154862:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1154862&gro=
up_id=3D41208&atid=3D430007

@Ton:
I you have a SourceForge account you can upload the files
to the feature request so that the JSynthLib developer team
can integrate it.

But as Joe Emenaker explained the release 0.20 has to be tagged
first. So the integration may take a while. Don't worry, you will
not be forgotten. ;)

Regards,
Joachim Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von Ton
> Holsink
> Gesendet: Dienstag, 1. M=E4rz 2005 23:47
> An: JSynthLib Development
> Betreff: [Jsynthlib-devel] TC Electronic G-Major
>=20
>=20
> Hi,
>=20
> Just to let you all know:
> I am busy hacking a driver / editor for the TC Electronic G-Major.
> It's almost finished. I will upload the first version within=20
> a week or so.
>=20
> Regards,
> Ton Holsink.
>=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.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

Re: [Jsynthlib-devel] KnobWidget size

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

me>It it superset of the current KnobWidget?  We can merge your widget into
me>core if it has new constructor with size parameter.

Joe> Well, if it accepts general size parameters, then it's not neccesarily 
Joe> "little". It could be "big" just as easily. Shouldn't it be called 
Joe> something like "SizeableKnobWidget" before it's added to core?
Joe> 
Joe> Even better, would be to just add the new constructor (and other needed 
Joe> code) to KnobWidget and then have the default KnobWidget constructor 
Joe> call the parameterized one with the default sizes.

This is exactly what I tried to write. Sorry for my bad English.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Fwd: Overriding calculateChecksum

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

Hi Jeff,

Jeff> What I've found out is that it appears to be happening
Jeff> because Driver.calculateChecksum(Patch, int, int, int)
Jeff> is defined as a static method.

You are right.

The Java Programming Language Third Edition, Chapter 3 Extending
Classes, 3.3.5 Hiding Static Members starts by the following sentence.

        Static members within a class cannot be overridden, they are always
        hidden --- whether a field or a method.

I completely did not understand this rule.  It was my fault to make 
Driver.calculateChecksum(Patch, int, int, int) static. I'll make it
non-static method.
-- 
Hiroo Hayashi

[Jsynthlib-devel] JSynthLib-0.20.0 is released

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

Hi all,

I've released JSynthLib-0.20.0.

Let's start working for 0.21.  Enjoy!
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] TC Electronic G-Major

[Joe E. <jo...@em...>]

Ton Holsink wrote:

> Just to let you all know:
> I am busy hacking a driver / editor for the TC Electronic G-Major.
> It's almost finished. I will upload the first version within a week or 
> so.

I think the current plan is to only upload bug-fixes to the CVS tree 
until the v0.2 version is branched/tagged.

- Joe

Re: [Jsynthlib-devel] Fwd: Overriding calculateChecksum

[Joe E. <jo...@em...>]

Jeff Weber wrote:

>What I've found out is that it appears to be happening
>because Driver.calculateChecksum(Patch, int, int, int)
>is defined as a static method.
>  
>
I found some discussion about this on the java newsgroups... so it seems 
to be "the way it is".

I find this very disappointing. The potential bugs that this invites 
would be difficult enough to track down that it's almost not worth using 
the static modifier at all.

At the very least, I'd propose that we make all static methods and 
properties *final*. That way, you explicitly can't override them. That 
would ensure that a problem like this doesn't happen.

- Joe

[Jsynthlib-devel] TC Electronic G-Major

[Ton H. <a.j...@ch...>]

Hi,

Just to let you all know:
I am busy hacking a driver / editor for the TC Electronic G-Major.
It's almost finished. I will upload the first version within a week or so.

Regards,
Ton Holsink.

Re: [Jsynthlib-devel] Fwd: Overriding calculateChecksum

[Joe E. <jo...@em...>]

Jeff Weber wrote:

> What I've found out is that it appears to be happening
>
>because Driver.calculateChecksum(Patch, int, int, int)
>is defined as a static method.
>  
>
That's not supposed to even be possible.

From: http://java.sun.com/docs/books/tutorial/java/javaOO/override.html ....
"a subclass cannot override methods that are declared |static| in the 
superclass. In other words, a subclass cannot override a class method."
However, it goes on to say that:
"A subclass can /hide/ a |static| method in the superclass by declaring 
a |static| method in the subclass with the same signature as the 
|static| method in the superclass."

But it seems like hiding would be the opposite problem than what you're 
getting now.

- Joe

AW: [Jsynthlib-devel] KnobWidget size

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

> Well, if it accepts general size parameters, then it's not=20
> neccesarily=20
> "little". It could be "big" just as easily. Shouldn't it be called=20
> something like "SizeableKnobWidget" before it's added to core?

It just creates a KnobWidget with a different size.

> Even better, would be to just add the new constructor (and other =
needed=20
> code) to KnobWidget and then have the default KnobWidget constructor=20
> call the parameterized one with the default sizes.

I would prefer that.

Or does something speak against a new constructor in KnobWidget?

But IMHO it should be done (or commited) after 0.20 is released.

Regards,
Joachim Backhaus

Re: [Jsynthlib-devel] Switch to JTree for the device list?

[Joe E. <jo...@em...>]

Rib Rdb wrote:

>That sounds like a great idea.  Much better than the hack I put in for
>the XML driver (since all XML drivers are instaces of the same class).
>  
>
At the same time, I intend to rename the methods to proper get/set 
naming styles... and the names will make more sense. Instead of 
"deviceNames()", it will be "getDeviceNames" and other lookup things 
will be named things like "getClassnameByDevicename()" so that it will 
be easy to know what the method uses as the lookup key.

Using IDEA's refactor functions, this should magically adjust any other 
classes that call it, so it shouldn't break anything. However, if you're 
currently doing development that interacts with the DevicesConfig class, 
then this would affect the methods you need to use in the future.

- Joe.

Re: [Jsynthlib-devel] Switch to JTree for the device list?

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

That sounds like a great idea.  Much better than the hack I put in for
the XML driver (since all XML drivers are instaces of the same class).


On Mon, 28 Feb 2005 14:51:46 -0800, Joe Emenaker <jo...@em...> wrote:
> Now that (I *think*) my JTree changes were reverted, I'll mention some
> of the other changes I thought of when I was implementing it.
> 
> ------------
> Cleaning up DeviceListWriter and DevicesConfig
> 
> Right now, DeviceListWriter *writes* the synthdrivers.properties file
> while DevicesConfig *reads* it. This isn't very good encapsulation. One
> class should handle all management of the file. This should be either
> DevicesConfig or a new class. DeviceListWriter is only needed for it's
> static main() class so that users can force a scan of the synthdriver
> directories to generate a new synthdriver.properties file, so that's all
> it should really do: scan directories and then request that
> DevicesConfig save the new settings to a file.
> 
> ------------
> Further cleaning of DevicesConfig
> 
> DevicesConfig currently tracks the classname, drivername, IDstring, etc.
> all in separate hashtables mapping each string to the classname. So, to
> find the IDstring by drivername (like "AccessVirus"), it has to go to
> the drivername hashtable, look up the classname for that driver. Then,
> go to the IDstring hashtable and find the key that points to that class
> in *that* hashtable.
> 
> This has two problems. First, it's a little disorganized and
> inefficient. Secondly (and more importantly) is that this will lead to
> problems if we ever have a single class that drives multiple devices
> (like a V-Amp, a Bass V-Amp, and a V-Amp 2). In a case like that,
> multiple keys in the IDstring/drivername hashtables would have the same
> class... and trying to look up a key based upon a value in the hashtable
> will yield unpredictable results.
> 
> The remedy I propose is to make a class called something like
> "DeviceDescriptor" which would house all of the important info about a
> device (name, classname, manufacturer, type, IDstring, etc.) and then
> have DevicesConfig maintain an array or vector of these descriptor objects.
> 
> Provided that I *wait* until the 0.2 release is branched/tagged before
> doing this, does anybody have any other objections to this?
> 
> - Joe
> 
> 
>

Re: [Jsynthlib-devel] Switch to JTree for the device list?

[Joe E. <jo...@em...>]

Now that (I *think*) my JTree changes were reverted, I'll mention some 
of the other changes I thought of when I was implementing it.

------------
Cleaning up DeviceListWriter and DevicesConfig

Right now, DeviceListWriter *writes* the synthdrivers.properties file 
while DevicesConfig *reads* it. This isn't very good encapsulation. One 
class should handle all management of the file. This should be either 
DevicesConfig or a new class. DeviceListWriter is only needed for it's 
static main() class so that users can force a scan of the synthdriver 
directories to generate a new synthdriver.properties file, so that's all 
it should really do: scan directories and then request that 
DevicesConfig save the new settings to a file.

------------
Further cleaning of DevicesConfig

DevicesConfig currently tracks the classname, drivername, IDstring, etc. 
all in separate hashtables mapping each string to the classname. So, to 
find the IDstring by drivername (like "AccessVirus"), it has to go to 
the drivername hashtable, look up the classname for that driver. Then, 
go to the IDstring hashtable and find the key that points to that class 
in *that* hashtable.

This has two problems. First, it's a little disorganized and 
inefficient. Secondly (and more importantly) is that this will lead to 
problems if we ever have a single class that drives multiple devices 
(like a V-Amp, a Bass V-Amp, and a V-Amp 2). In a case like that, 
multiple keys in the IDstring/drivername hashtables would have the same 
class... and trying to look up a key based upon a value in the hashtable 
will yield unpredictable results.

The remedy I propose is to make a class called something like 
"DeviceDescriptor" which would house all of the important info about a 
device (name, classname, manufacturer, type, IDstring, etc.) and then 
have DevicesConfig maintain an array or vector of these descriptor objects.



Provided that I *wait* until the 0.2 release is branched/tagged before 
doing this, does anybody have any other objections to this?

- Joe

Re: [Jsynthlib-devel] KnobWidget size

[Joe E. <jo...@em...>]

Hiroo Hayashi wrote:

>le...@ti...> Should it be possible to have a KnobWidget constructor
>witch
>le...@ti...> accept size in its parameters (width and heigth) ? By
>le...@ti...> default, size of KnobWidget is too big and it  have created
>le...@ti...> a class named LittleKnobWidget to workaround this.
>
>It it superset of the current KnobWidget?  We can merge your widget into
>core if it has new constructor with size parameter.
>  
>
Well, if it accepts general size parameters, then it's not neccesarily 
"little". It could be "big" just as easily. Shouldn't it be called 
something like "SizeableKnobWidget" before it's added to core?

Even better, would be to just add the new constructor (and other needed 
code) to KnobWidget and then have the default KnobWidget constructor 
call the parameterized one with the default sizes.

- Joe

Re: [Jsynthlib-devel] Fwd: Overriding calculateChecksum

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

yes, that's why singleton is preferred to static methods.
A singleton class can use inheritance.

-- 
Denis


> That sounds right. If it's a static method there's no this pointer, so
> there would be no way to figure out which class's method to call at
> runtime. I don't know the language spec, but since Eclipse gives a
> warning whenever a static method is called through an object, I'd
> guess that all static methods are statically resolved at compile time.
> 
> 
> On Mon, 28 Feb 2005 09:25:58 -0800 (PST), Jeff Weber
> <jww...@ya...> wrote:
> 
>>--- Hiroo Hayashi <hir...@co...> wrote:
>>
>>>I can hardly believe what you wrote. If override
>>>does not work, the Java
>>>environment is useless at all.  How did you confirm
>>>it? What happen if
>>>you put print statement in your
>>>calculateChecksum(Patch,int,int,int)?
>>
>>Defies logic doesn't it? I know I have to keep
>>pinching myself. I've tested this numerous times both
>>stepping through with a debugger and using print
>>statements. Finally, I put together a really simple
>>example that demonstrates this (See below).
>>
>>What I've found out is that it appears to be happening
>>because Driver.calculateChecksum(Patch, int, int, int)
>>is defined as a static method.
>>
>>The attached example has a main class (StaticOverride)
>>along with two classes, Rectangle, which inherits from
>>Object, and Square which inherits from Rectangle. Both
>>Rectangle and Draw contain a static draw(int) method
>>that prints a message int number of times. Rectangle
>>has a non-static draw() method that calls the
>>draw(int) method. The main class, StaticOverride
>>creates an object of type Square and calls it's draw()
>>method. Because Square.draw() is commented out, it
>>calls Rectangle.draw() which in turn calls draw(int).
>>You would think that because draw(int) is overridden
>>in the Square class, that Square.draw(int) would be
>>called but nope, Rectangle.draw(int) is called
>>instead.
>>
>>If you make the draw(int) methods non-static in both
>>the Rectangle and Square classes, then it works the
>>way you'd expect and the Square.draw(int) method is
>>called instead. (At least, that's what happens on my
>>system).
>>
>>Go ahead and try it. If you get different results than
>>I did, then something's flakey either with my system
>>or my brain.
>>
>>Here's my example:
>>----------------------------
>>import java.util.*;
>>
>>public class StaticOverride {
>>
>>    public static void main (String args[]) {
>>        Square aSquare = new Square();
>>
>>        aSquare.draw();
>>    }
>>}
>>
>>class Rectangle {
>>    int nbr = 2;
>>
>>        void draw() {
>>                draw(nbr);
>>        }
>>
>>    static void draw (int num) {
>>        for (int i = 0; i < num; i++) {
>>            System.out.println("Drawing a
>>rectangle.");
>>        }
>>    }
>>}
>>
>>class Square extends Rectangle {
>>    //  void draw() {
>>    //        draw(nbr);
>>    //    }
>>
>>    static void draw (int num) {
>>        for (int i = 0; i < num; i++) {
>>            System.out.println("Drawing a square.");
>>        }
>>    }
>>}
>>
>>
>>__________________________________
>>Do you Yahoo!?
>>Yahoo! Mail - Easier than ever with enhanced search. Learn more.
>>http://info.mail.yahoo.com/mail_250
>>
>>
>>-------------------------------------------------------
>>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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Jsynthlib-devel mailing list
>>Jsy...@li...
>>https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>>
> 
> 
> 
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
> 
> 

Re: [Jsynthlib-devel] Fwd: Overriding calculateChecksum

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

That sounds right. If it's a static method there's no this pointer, so
there would be no way to figure out which class's method to call at
runtime. I don't know the language spec, but since Eclipse gives a
warning whenever a static method is called through an object, I'd
guess that all static methods are statically resolved at compile time.


On Mon, 28 Feb 2005 09:25:58 -0800 (PST), Jeff Weber
<jww...@ya...> wrote:
> --- Hiroo Hayashi <hir...@co...> wrote:
> > I can hardly believe what you wrote. If override
> > does not work, the Java
> > environment is useless at all.  How did you confirm
> > it? What happen if
> > you put print statement in your
> > calculateChecksum(Patch,int,int,int)?
> 
> Defies logic doesn't it? I know I have to keep
> pinching myself. I've tested this numerous times both
> stepping through with a debugger and using print
> statements. Finally, I put together a really simple
> example that demonstrates this (See below).
> 
> What I've found out is that it appears to be happening
> because Driver.calculateChecksum(Patch, int, int, int)
> is defined as a static method.
> 
> The attached example has a main class (StaticOverride)
> along with two classes, Rectangle, which inherits from
> Object, and Square which inherits from Rectangle. Both
> Rectangle and Draw contain a static draw(int) method
> that prints a message int number of times. Rectangle
> has a non-static draw() method that calls the
> draw(int) method. The main class, StaticOverride
> creates an object of type Square and calls it's draw()
> method. Because Square.draw() is commented out, it
> calls Rectangle.draw() which in turn calls draw(int).
> You would think that because draw(int) is overridden
> in the Square class, that Square.draw(int) would be
> called but nope, Rectangle.draw(int) is called
> instead.
> 
> If you make the draw(int) methods non-static in both
> the Rectangle and Square classes, then it works the
> way you'd expect and the Square.draw(int) method is
> called instead. (At least, that's what happens on my
> system).
> 
> Go ahead and try it. If you get different results than
> I did, then something's flakey either with my system
> or my brain.
> 
> Here's my example:
> ----------------------------
> import java.util.*;
> 
> public class StaticOverride {
> 
>     public static void main (String args[]) {
>         Square aSquare = new Square();
> 
>         aSquare.draw();
>     }
> }
> 
> class Rectangle {
>     int nbr = 2;
> 
>         void draw() {
>                 draw(nbr);
>         }
> 
>     static void draw (int num) {
>         for (int i = 0; i < num; i++) {
>             System.out.println("Drawing a
> rectangle.");
>         }
>     }
> }
> 
> class Square extends Rectangle {
>     //  void draw() {
>     //        draw(nbr);
>     //    }
> 
>     static void draw (int num) {
>         for (int i = 0; i < num; i++) {
>             System.out.println("Drawing a square.");
>         }
>     }
> }
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> http://info.mail.yahoo.com/mail_250
> 
> 
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

Re: [Jsynthlib-devel] Fwd: Overriding calculateChecksum

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

--- Hiroo Hayashi <hir...@co...> wrote:
> I can hardly believe what you wrote. If override
> does not work, the Java
> environment is useless at all.  How did you confirm
> it? What happen if
> you put print statement in your
> calculateChecksum(Patch,int,int,int)?

Defies logic doesn't it? I know I have to keep
pinching myself. I've tested this numerous times both
stepping through with a debugger and using print
statements. Finally, I put together a really simple
example that demonstrates this (See below).

What I've found out is that it appears to be happening
because Driver.calculateChecksum(Patch, int, int, int)
is defined as a static method.

The attached example has a main class (StaticOverride)
along with two classes, Rectangle, which inherits from
Object, and Square which inherits from Rectangle. Both
Rectangle and Draw contain a static draw(int) method
that prints a message int number of times. Rectangle
has a non-static draw() method that calls the
draw(int) method. The main class, StaticOverride
creates an object of type Square and calls it's draw()
method. Because Square.draw() is commented out, it
calls Rectangle.draw() which in turn calls draw(int).
You would think that because draw(int) is overridden
in the Square class, that Square.draw(int) would be
called but nope, Rectangle.draw(int) is called
instead.

If you make the draw(int) methods non-static in both
the Rectangle and Square classes, then it works the
way you'd expect and the Square.draw(int) method is
called instead. (At least, that's what happens on my
system).

Go ahead and try it. If you get different results than
I did, then something's flakey either with my system
or my brain.

Here's my example:
----------------------------
import java.util.*;

public class StaticOverride {
    
    public static void main (String args[]) {
        Square aSquare = new Square();

        aSquare.draw();
    }
}


class Rectangle {
    int nbr = 2;
    
	void draw() {
		draw(nbr);
	}
    
    static void draw (int num) {
        for (int i = 0; i < num; i++) {
            System.out.println("Drawing a
rectangle.");
        }        
    }
}


class Square extends Rectangle {
    //	void draw() {
    //        draw(nbr);
    //    }
    
    static void draw (int num) {
        for (int i = 0; i < num; i++) {
            System.out.println("Drawing a square.");
        }
    }
}




		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

Re: [Jsynthlib-devel] Fwd: Overriding calculateChecksum

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

Jeff,

Jeff> Funny you should mention this. I was reviewing my code
Jeff> and came across this just last week and I thought the
Jeff> same thing. When I removed it I found that it actually
Jeff> does not call the overridden method. It calls the
Jeff> method in the Driver class. I used a debugger to
Jeff> confirm it. I don't understand why this happens. Maybe
Jeff> it's just something flakey with my system (OSX).

I can hardly believe what you wrote. If override does not work, the Java
environment is useless at all.  How did you confirm it? What happen if
you put print statement in your calculateChecksum(Patch,int,int,int)?
-- 
Hiroo Hayashi

Re: AW: AW: [Jsynthlib-devel] Switch to JTree for the device list?

[Joe E. <jo...@em...>]

Hiroo Hayashi wrote:

>Joe> Okay. I'll have to do that tonight. However, how much do you want me to 
>Joe> revert? I added a method to DevicesConfig which is not used by anything 
>
>I want you to revert all non-bug fix changes.  But I'm just one of
>developers.
>
Well, for the last two years, I've been watching the cvs mailing list, 
and it definitely appears that you're doing a vast majority of the 
commits, so I'd definitely consider you to be the *main* developer at 
this point in time.

>It's up-to you.  Of course revert the change which has a bug
>at least :-)
>  
>
Well, I *think* I may have reverted it. IDEA tells me that the cvs 
commit failed, but I checked out DeviceAddDialog and DevicesConfig again 
and they look like the old versions. Try an update and see if it's back 
to a JList.... and make sure the Emu driver adds without an exception again.

- Joe

Re: [Jsynthlib-devel] KnobWidget size

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

Hi,

le...@ti...> Should it be possible to have a KnobWidget constructor
witch
le...@ti...> accept size in its parameters (width and heigth) ? By
le...@ti...> default, size of KnobWidget is too big and it  have created
le...@ti...> a class named LittleKnobWidget to workaround this.

It it superset of the current KnobWidget?  We can merge your widget into
core if it has new constructor with size parameter.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Re: Behringer FCB1010

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

Jeff> Joe> 2 - In the patch editor, in the Global Settings tab,
Jeff> Joe> the text labels ook disabled/greyed while the combo
Jeff> Joe> boxes l are still enabled. Is this intentional?
=2E..
Jeff> I remember there was some discussion about this
Jeff> feature a while ago.

Yes.  See the comment for PatchEditorFrame.faderHighlight().
--=20
Hiroo Hayashi

SysexGetDialog (Re: [Jsynthlib-devel] Behringer V-Amp 2 Support)

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

Jeff> I think I've written enough drivers/editors now to
Jeff> have a fair basic understaning of how they work but I
Jeff> don't fully understand why they were designed to work
Jeff> the way they do.
Jeff> 
Jeff> For instance here's one thing that I have never
Jeff> understood. When you pull up the Get Patch dialog and
Jeff> make your selections you're telling JSL which driver
Jeff> and patch you want to request. When you hit the get
Jeff> button, the selected driver sends the request to the
Jeff> device and the device sends back the requested patch.
Jeff> Then JSL searches through all the currently configured
Jeff> drivers to try to figure out which driver the patch
Jeff> belongs to. Why is this necessary when I just told it
Jeff> what driver the patch belongs to?

Good point. This is one of many reasons we made IPatch* interfaces. If
your driver implements IPatchDriver interface directly instead of
extending Driver class, it can bypass the unnecessary driver search.
-- 
Hiroo Hayashi