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

Re: [Jsynthlib-devel] Drivers/Editor for Behringer V-Amp 2

[Bill Z. <wrz...@po...>]

> If there are any showstopper bugs we can fix them without having to go 
> to 0.21.
>
You should go to 0.21 anyway, if any problems appear.  Every public 
release should get a new number and date stamp.  Otherwise everyone has 
to keep track of *which* 0.20 they have.  Fortunately I learned that 
lesson around verion 0.6 at work when we only had 3 users.  
Unfortunately, we still have only 3 users.  =^(

-Bill

Re: [Jsynthlib-devel] Anyone here ever used any other librarian programs?

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

Brian wrote:

> While most Librarians force the user to have only
> one type of patch in a library, I felt that the user should be able to 
> choose the way they wanted to work.

Okay. I choose to work with a desktop metaphor, with all of my midi 
device arranged on a panel. I want to double-click on one of them and 
get a window showing me all of the categories of settings (patches, 
performances, controller configs) that I can mess with, along with a 
list of all of the patches that I have stored locally on the hard disk 
for that synth.

Oddly, I'm not finding the checkbox to turn that "choice" on. :P

> JSynthLib
> supports this kind of operation, you can create all your libraries to 
> hold only patches for one synth. This is how I usually
> work actually, I have one patchlib file for each synth I use that 
> holds all the patches for the synth.

One problem I had was trying to figure out just what a "Library" is. 
It's the only thing I'm able to create at the outset (until I figure out 
how to go add synths), yet there were no cues as to what it was a 
library *of*. Patches, I figured... but I didn't know for what synth.

Keep in mind that all of my friends consider me to have a good ability 
to intuitively figure out software. One friend calls it "the knowing". I 
sit down at some software... Adobe Premiere, Cakewalk, Photoshop, 
AutoCAD, MidiQuest... and I'm able to quickly get a grasp on the way 
it's supposed to be used. Yet JSL just baffles me. To this day, even 
though I've contributed probably over 100 hours into core.* classes.... 
I've only managed (as a user) to get JSL to show me the settings in my 
FCB-1010 foot controller.

Granted, I could experiment and yell and curse and eventually train my 
brain to do things the JSL way. But remember... if this is the kind of 
trouble that a quick-study like myself has, normal users will be 
completely lost. For example, I work with Jon Anderson (the lead singer 
from Yes. You know... "Owner of a Lonely Heart", and "Roundabout", etc?) 
and I wouldn't *dare* tell him to use this with it's current UI.

> I felt that only allowing patches
> for one type of synth in a library was an arbitary technical 
> limitation. With the way JSynthLib works users could, if they so desired
> create a library containing all of their piano patches, for example, 
> regardless of what synth they belonged to. I figured the actual device
> a patch runs on isn't important, users would care about the sounds 
> they had at their fingertips and might want to organize them irrespective
> to the actual details of how the sound is generated.

I take your point here as being: If a user has 3 synths in their 
studio... and they want a spaceship sound, they should be able to browse 
the spaceship sounds for all three together. I see the merit in that.

On the other hand, JSL now has drivers for effects units, drum modules, 
and foot controllers. These are all very dissimilar devices, whose 
patches have almost nothing to do with each other.

> I think its really cool to have a library file full of patches for 
> eight or nine different synths, and to be able to go down the list and 
> click 'play'
> for each one and have the correct synth play the sound.

Yes, that's cool. And I think that it should be retained if the UI is 
ever changed. Personally, I think it's more appropriate in maybe a 
"search" or "browse" window.

> JSynthLIb internally takes care of the 'routing' problems of getting 
> the data file to the
> correct synth to generate the sound.  From the users point of view you 
> don't even care what synth is playing the sound, only the sound itself
> . This is nice for trying to find the sound you want.

Agreed. However, without the context of your synth's internal patch 
storage, it's not very useful.

I'll explain. Say that you find a neat sound? You went down the list of 
patches and heard something that you liked. *Now* what? I think it's 
reasonable to expect that you'd want to store that patch in your synth's 
internal memory somewhere. So, you need to bring up a window showing the 
layout of all of the patches within that synth, right? Does JSL already 
let you right-click and see that synth's current patches? If it does, 
it's not at all intuitive that this is how JSL is supposed to be used. 
Besides, this brings a host of other problems. What if I have two of the 
same synth? What if I want to put it into a virtual bank on the local 
hard disk?

> So at least that was the idea behind the design. In practice, most 
> likely 99% of the usage of jynthlib libraries are like you described 
> with other
> librarians. The design may not necessarily be good, but it was 
> actually intentional and not just done out of ignorance.

Well, I didn't suspect ignorance as much as I suspected that you just 
wrote an interface that did what you needed in the beginning and left 
it... not suspecting that it would grow as big as it has.

> The first few versions
> of JSynthLib, I was the sole developer, and for a the first few months 
> at least, I was the sole user as well. So there are things that maybe 
> no one
> else would choose but it works they way I wanted a librarian to work 
> for me.

Like I said. :)

Has the notion of a software design ever surfaced? By "software design", 
I mean the type with just verbal/graphical descriptions detailing the 
user experience. It's a lot like writing the documentation before the 
app. One nice thing about it is that it allows any developer to work on 
any part at any time, since everybody knows what the finished product is 
supposed to operate like. The even NICER thing about it is that it 
forces the developers to work out the details of the entire user 
experience before they code too much.

I kinda think it might be time for a software design session.

- Joe

[Jsynthlib-devel] BankDriver requests

[Steven S. <ste...@co...>]

Greetings -

So far, I've found that if I take the time to compose an email to ask a 
question to the group, the process of formulating the question usually 
lets me find the answer myself.  Not so with this one.  I would think 
that a bank driver requests a dump of the entire bank to store as a 
patchlib, but the code looks like it looks for a single patch from the 
synth, not from the big dump.  Then again, when requesting a patch from 
the bank driver, I can't select a specific patch.  What exactly is the 
purpose and expected behavior of a bank driver?

Also, my (Korg Triton) device and single driver are working.  Should I 
check them in or wait till the editor is done?

Gracias!

[Jsynthlib-devel] CCSender Class for Alesis DM5

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

There is a CCSender.java file in the AlesisDM5 package
that is not referenced anywhere. If I remember
correctly, I was using this early in the development
of the DM5 editor and then later on I ended up not
needing it anymore. This file can (and should) be
deleted. Can one of you who have admin authority take
care of this?

Thanks,
Jeff


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

Re: [Jsynthlib-devel] Anyone here ever used any other librarian programs?

[Brian <br...@ov...>]

> Has there been any talk about spiffing up the interface? 


I realize this is an old discussion, but I wanted to chime in because 
the JSynthLib Librarian paradigm is 100% my fault.

Before designing the original JSynthLib, I had used many other universal 
librarians including midiquest and sounddiver.
I also researched many others such as Noize and Unisyn to see how they 
handled things. I felt that most universal
librarians shoehorned the user into working in an arbitary way. While 
most Librarians force the user to have only
one type of patch in a library, I felt that the user should be able to 
choose the way they wanted to work. JSynthLib
supports this kind of operation, you can create all your libraries to 
hold only patches for one synth. This is how I usually
work actually, I have one patchlib file for each synth I use that holds 
all the patches for the synth.

Howerver JSynthLib allows you to work this way or to choose to work a 
different way. I felt that only allowing patches
for one type of synth in a library was an arbitary technical limitation. 
With the way JSynthLib works users could, if they so desired
create a library containing all of their piano patches, for example, 
regardless of what synth they belonged to. I figured the actual device
a patch runs on isn't important, users would care about the sounds they 
had at their fingertips and might want to organize them irrespective
to the actual details of how the sound is generated.

I think its really cool to have a library file full of patches for eight 
or nine different synths, and to be able to go down the list and click 
'play'
for each one and have the correct synth play the sound. JSynthLIb 
internally takes care of the 'routing' problems of getting the data file 
to the
correct synth to generate the sound.  From the users point of view you 
don't even care what synth is playing the sound, only the sound itself
. This is nice for trying to find the sound you want.

In addition you can create a library full of all the sounds for a 
particular project rather than having to have a seperate library for 
each synth.
Later on Gerrit introduces 'Scenes' for this purpose so libraries arent' 
necessarily needed for this.

So at least that was the idea behind the design. In practice, most 
likely 99% of the usage of jynthlib libraries are like you described 
with other
librarians. The design may not necessarily be good, but it was actually 
intentional and not just done out of ignorance. :-). The first few versions
of JSynthLib, I was the sole developer, and for a the first few months 
at least, I was the sole user as well. So there are things that maybe no 
one
else would choose but it works they way I wanted a librarian to work for me.

Brian

Re: [Jsynthlib-devel] No-frills sysex device/driver/editor?

[Brian <br...@ov...>]

Joe Emenaker wrote:

> Is there a device/driver/editor for JSL that is just bare-bones?


I think this is something we should have. The "Generic" Driver was a 
start at this. If no driver is installed for a patch type you can still 
use librarian functionality via the "Generic" Driver, but it could be 
more functional.
My Original idea was to have an editor for "Generic" that was just a 
hexeditor, though in retrospect it would be usefull to have hexediting 
support for all patch types. Maybe if we had an "Edit" option and a 
"Edit as Hex" option
on the menu for patches.

I've recently looked into seeing if there are any GPL hex-editor 
controls for Java. Though eclipse has a hex editor plugin, the code is 
quite large and most likely is pretty integrated into eclipse utilities.

Re: [Jsynthlib-devel] Drivers/Editor for Behringer V-Amp 2

[Brian <br...@ov...>]

Hello,

Yes, please go ahead and run commits in head. Hiroo took care of 
business and got 0.20 branched.
I've placed 0.20 on the jsynthlib.org and reworked the website with all 
the new documentation and
releases and everything. If anyone notices any problems, please let me 
know. I've called the current
release 0.20-beta. If no one notices any problems in the next week or 
so, I'll just rename the current
beta to 0.20. If there are any showstopper bugs we can fix them without 
having to go to 0.21.


Jeff Weber wrote:

>I have a set of working drivers and a partially
>completed editor for the V-Amp 2 but I've been waiting
>to run any commits until the activity around version
>0.20 has been completed.
>
>Is it OK to run commits yet? I think someone else
>asked this same question and I never saw a response.
>
>
>	
>		
>__________________________________ 
>Celebrate Yahoo!'s 10th Birthday! 
>Yahoo! Netrospective: 100 Moments of the Web 
>http://birthday.yahoo.com/netrospective/
>
>
>-------------------------------------------------------
>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] Proposal: DeviceDescriptor

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

Rib Rdb wrote:

>Maybe instead of having a ClassName field, DeviceDescriptor should
>have a createDevice(Preferences) method.
>
Ick. I don't really like Preferences much.

>That way the XML driver (and
>any other future driver that supports multiple devices) doesn't have
>to abuse class names or use some other sort of hack.
>
I'm not sure what you mean by "abuse" class names.

>At the moment I
>can't think of a good way to get a DeviceDescriptor from a Java
>driver,
>
My initial thoughts would be that the drivers would have something like:
    public DeviceDescriptors[] getDeviceDescriptors()

Since most of the data items in a descriptor are already fields in the 
device classes anyway, we could probably just add this method to the 
Device superclass and be 95% of the way there.

- Joe

[Jsynthlib-devel] Drivers/Editor for Behringer V-Amp 2

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

I have a set of working drivers and a partially
completed editor for the V-Amp 2 but I've been waiting
to run any commits until the activity around version
0.20 has been completed.

Is it OK to run commits yet? I think someone else
asked this same question and I never saw a response.


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

[Jsynthlib-devel] Change in DeviceAddDialog

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

Okay guys... I changed the JList to a JTree in DeviceAddDialog.

Do a CVS update and try adding a synth. The stuff you see on the screen 
doesn't look like much... but I really cleaned up the underlying code.

---------------------------------
Explaination of the layout
---------------------------------
The tree supports grouping by manufacturer, type (ie, synth, controller, 
drum machine, etc.), manufacturer-then-type, type-then-manufacturer, or 
no grouping at all (in which case it looks just like the old JList, 
pretty much).

It is *currently* configured to group by Type, then by Manufacturer. The 
problem is, devices don't have types yet. In the meantime, so that we 
have something to test, the type is the first letter of the manufacturer 
name. So, a "Kawai K4" will have type "K". This is why the tree 
initially starts out with just a bunch of folders with single-letter 
names. So, the Kawai K4 is in "/K/Kawai/Kawai K4".

If you want to experiment with different groupings, look in 
DeviceSelectionTree and change the groupStyle field to GROUP_NONE, 
GROUP_MANUF, GROUP_TYPE, GROUP_MANUF_TYPE, or GROUP_TYPE_MANUF (which is 
what it is now). Should we just hard-code this a certain way, or let the 
user change it with a setting?

--------------------------------
Things to watch out for
--------------------------------
Keep an eye out for any time the tree isn't in alphabetical order. I 
tried to remember to keep it sorted in all of the different groupings, 
but I might have missed something.

Also, you shouldn't be able to select or double-click on any tree items 
*except* the actual devices. Double-clicking on a type or manufacturer 
shouldn't do anything. Double-clicking on an acutal device, however, is 
treated as though you selected it and clicked OK.

--------------------------
Future possibilities
--------------------------
Sorry I'm obsessing over this, but this is one of the first things a new 
user sees, so I'd like to make it as snazzy as I can....

JTree's support custom icons and images in places of the little 
folder/document icons used for nodes and leafs. When we do, someday, 
support types, I'd like to consider having some little icons which look 
like the various types (drum machine, rackmount synth, keyboard, etc).

Also, if I'm inspired later, I could go in and add support for selecting 
multiple synths at a time.

- Joe

[Jsynthlib-devel] Eclipse instructions

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

I wrote some more detailed instructions for setting up Eclipse for
JSL, which are now available at http://ribrdb.com/jsl/eclipse.html
Should we maybe put this or a link to it in programming.html?

Re: [Jsynthlib-devel] Re: Latest Roland MT-32 Editor

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

Hi,

Fred> With some help from above (RTFM) I got the java compiler working again. 
Fred> I tried Netbeans and Eclipse, but both get very much in the way and
Fred> do not help at all with importing an existing project. Lucky 'javac' 
Fred> stilll works :-).

I would think if there were step by step instruction of importing
JSynthLib into Eclipse.  As far as I remember it was not difficult, but
it was a barrier for me to learn the way.  If someone starts using
Eclipse, let me the step-by-step instruction.  I'll add it to FAQ.

Fred> The MT-32 editor is now updated to be 020 compliant: 
Fred> http://electrickery.xs4all.nl/digaud/mt32/

If you decide to distribute your driver under GPL, we can merge your
driver into JSynthLib distribution.  Each file may already have GPL
copyright notice, but I don't want to send my time to check that.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Proposal: DeviceDescriptor

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

Maybe instead of having a ClassName field, DeviceDescriptor should
have a createDevice(Preferences) method.  That way the XML driver (and
any other future driver that supports multiple devices) doesn't have
to abuse class names or use some other sort of hack.  At the moment I
can't think of a good way to get a DeviceDescriptor from a Java
driver, but it would be really easy to have
XMLDeviceFactory.getDeviceDescriptors() instead of getDeviceNames().


On Thu, 03 Mar 2005 19:31:56 -0800, Joe Emenaker <jo...@em...> wrote:
> I'm done with the initial work on turning the DeviceAddDialog JList into
> a JTree. Now, I'm just working on the parts that group the tree in
> various ways (ie, first by manufacturer and then by type, by
> manufacturer only, by type only, etc). I'm also considering making it
> possible to add multiple synths with a single instance of the dialog.
> 
> Anyway, my current work forced me to go into DevicesConfig an clean
> things up. While I was there, I decided to keep track of devices with a
> class I named "DeviceDescriptor". It's merely a data-holding class which
> keeps DeviceName, ShortName, IDString, Manufacturer, Type, and ClassName
> all together. Then, I'm able to just maintain a list of all of the
> descriptors.
> 
> Right now, DeviceDescriptor is only used by a few classes that I'm
> working on... but I'd like to expand it. The reason is that
> DevicesConfig has a handful of methods like "getClassNameForDeviceName",
> "getShortNameForDeviceName", "getIDStringForDeviceName", and then there
> are more for "getXxxByIDString" or "getXxxByClassName".
> 
> What I'd *like* to do is just have "getDescriptorForDeviceName",
> "getDescriptorForClassName", etc. and then the *calling* method gets the
> whole descriptor and can get whatever data elements it wants out of
> that. This will require me to go modify some classes that are currently
> outside the scope of my development on DeviceAddDialog. They're small
> changes, but I wanted to check to see if anyone had any objections first.
> 
> Ultimately, I think it would make for cleaner design if DeviceDescriptor
> got more widely used, too. Ultimately, it would be nice if this was how
> synthdrivers reported what devices they can interact with. This way, a
> single Device class could offer back an array of DeviceDescriptors for
> various synths that it knew how to control. Of course, that would be
> down the road a ways.... but I just wanted to put that in your heads.
> 
> - Joe
> 
> 
>

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

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

Hi,

Rib> I did a little testing today. It seems that MDI is the default.  I
Rib> think maybe GUI_MDI and GUI_SDI are switched in AppConfig.getGuiStyle.

This is my mistake.  I tend to use the word MDI for multiple window
interface...

And you made a fix for MacUtils.isMac().  I don't think it's good idea
to check the value of property "apple.laf.useScreenMenuBar" in isMac()
method.  isMac() should just check if MacOS or not.  And I think the
condition System.getProperty("java.vm.version").startsWith("1.4") also
should be removed. This does not work for JDK 1.5 or greater.  And 1.4
or greater is requirement for any OS now.

How do you think?

Rib> Also, I wonder if it would be more user friendly to automatically open
Rib> a default library at startup when in SDI mode, and maybe even for MDI
Rib> too.  On a Mac, ~/Documents/JSynthLib.patchlib would probably be a
Rib> good location for this. I don't know about on other OSs. Perhaps the
Rib> location should be an option in AppConfig.

You can specify a library file as a command line argument. I always
invoke a default library by using the argument.

And if we define default file, we can use "Patch Library Path" which
user specifies.  But adding a user preference "default library" may be
better idea.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] How to write requestPatchDump?

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

Bill Zwicky wrote:

> When I look at the source, I just go in circles;

When you figure it out, let me know.

I can't make sense of it, either.

- Joe

[Jsynthlib-devel] How to write requestPatchDump?

[Bill Z. <wrz...@po...>]

I'm trying to update the Casio CZ-1000 to get patches from the synth, 
and I can for the life of me figure it out.  When I look at the source, 
I just go in circles; apparantly reading a MIDI message simply reads 
from JSynthLib's own output queue!

The other problem is that this synth has (what I guess is) an unusual 
protocol:
computer<->synth
Request->
<-ack
ack->
<-patch
F7->

How would I write requestPatchDump to carry out this whole sequence?

-Bill

<cid:par...@po...>

[Jsynthlib-devel] Proposal: DeviceDescriptor

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

I'm done with the initial work on turning the DeviceAddDialog JList into 
a JTree. Now, I'm just working on the parts that group the tree in 
various ways (ie, first by manufacturer and then by type, by 
manufacturer only, by type only, etc). I'm also considering making it 
possible to add multiple synths with a single instance of the dialog.

Anyway, my current work forced me to go into DevicesConfig an clean 
things up. While I was there, I decided to keep track of devices with a 
class I named "DeviceDescriptor". It's merely a data-holding class which 
keeps DeviceName, ShortName, IDString, Manufacturer, Type, and ClassName 
all together. Then, I'm able to just maintain a list of all of the 
descriptors.

Right now, DeviceDescriptor is only used by a few classes that I'm 
working on... but I'd like to expand it. The reason is that 
DevicesConfig has a handful of methods like "getClassNameForDeviceName", 
"getShortNameForDeviceName", "getIDStringForDeviceName", and then there 
are more for "getXxxByIDString" or "getXxxByClassName".

What I'd *like* to do is just have "getDescriptorForDeviceName", 
"getDescriptorForClassName", etc. and then the *calling* method gets the 
whole descriptor and can get whatever data elements it wants out of 
that. This will require me to go modify some classes that are currently 
outside the scope of my development on DeviceAddDialog. They're small 
changes, but I wanted to check to see if anyone had any objections first.

Ultimately, I think it would make for cleaner design if DeviceDescriptor 
got more widely used, too. Ultimately, it would be nice if this was how 
synthdrivers reported what devices they can interact with. This way, a 
single Device class could offer back an array of DeviceDescriptors for 
various synths that it knew how to control. Of course, that would be 
down the road a ways.... but I just wanted to put that in your heads.

- Joe

[Jsynthlib-devel] Re: Latest Roland MT-32 Editor

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

> Fred> Is there a document describing the current development environment? 


> It's been in the JSynthLib distribution. 


> See doc/programming.html.

With some help from above (RTFM) I got the java compiler working again. 
I tried Netbeans and Eclipse, but both get very much in the way and
do not help at all with importing an existing project. Lucky 'javac' 
stilll works :-).

The MT-32 editor is now updated to be 020 compliant: 
http://electrickery.xs4all.nl/digaud/mt32/

> -- Hiroo Hayashi


Fred Jan Kraan

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

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

I did a little testing today. It seems that MDI is the default.  I
think maybe GUI_MDI and GUI_SDI are switched in AppConfig.getGuiStyle.

Also, I wonder if it would be more user friendly to automatically open
a default library at startup when in SDI mode, and maybe even for MDI
too.  On a Mac, ~/Documents/JSynthLib.patchlib would probably be a
good location for this. I don't know about on other OSs. Perhaps the
location should be an option in AppConfig.


On Wed, 02 Mar 2005 07:34:17 -0600, Hiroo Hayashi
<hir...@co...> wrote:
> 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
> 
> -------------------------------------------------------
> 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

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

joe> Do you think we should also make as many static members "final" as well,
joe> to prevent this kind of thing from happening again? After all, I'll bet it
joe> took Jeff a lot of needless head-scratching to find this problem.

As far as I see the calculateChecksum(Patch,int,int,int) was the only
static method in the classes which a synth driver extends.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Fwd: Overriding calculateChecksum

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

I've checked in the fixes in the main branch.

On Wed, 02 Mar 2005 00:34:08 -0600
Hiroo Hayashi <hir...@co...> wrote:

Hiroo> The Java Programming Language Third Edition, Chapter 3 Extending
Hiroo> Classes, 3.3.5 Hiding Static Members starts by the following sentence.
Hiroo> 
Hiroo>         Static members within a class cannot be overridden, they are always
Hiroo>         hidden --- whether a field or a method.
Hiroo> 
Hiroo> I completely did not understand this rule.  It was my fault to make 
Hiroo> Driver.calculateChecksum(Patch, int, int, int) static. I'll make it
Hiroo> non-static method.

-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Fwd: Overriding calculateChecksum

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

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

Do you think we should also make as many static members "final" as well,
to prevent this kind of thing from happening again? After all, I'll bet it
took Jeff a lot of needless head-scratching to find this problem.

- Joe

Re: [Jsynthlib-devel] Latest Roland MT-32 Editor

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

Fred> Is there a document describing the current development environment?

It's been in the JSynthLib distribution.  See doc/programming.html.
-- 
Hiroo Hayashi

[Jsynthlib-devel] Groovy

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

I just updated the version of groovy in CVS.  Now the groovy.jar is
self contained, so you can remove asm.jar from your classpath.

Re: [Jsynthlib-devel] Enhancements to SysexWidgets??

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

Jeff Weber wrote:

>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?
>  
>
I haven't looked at the code, but I can't imagine that it's that tough. 
A few lines of code, perhaps?

>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.
>
Again, I haven't looked at the widgets, yet, but my assumption was that 
the widgets (in order to be suitably generic) would have constructors 
for odd behavior like this. For example:

   CheckboxWidget ( int offVal, int onVal)

and that the default constructor would just look like:

   CheckboxWidget() {
      this( 0, 1 );
   }

If the widgets do *not* have this kind of flexibility, I can go add it 
to them. I'm almost done with my overhaul of DevicesConfig and the 
transformation of the device selection dialog to use a JTree.

- Joe