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

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

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

Hi,

Joe> >Please revert your change.
Joe> >
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.  It's up-to you.  Of course revert the change which has a bug
at least :-)

Brian,

I've been waiting for you to create a branch tag.  I have pretty much
JSLFrame related change.  Shall I create a tag after Joe revert the
change?
-- 
Hiroo Hayashi

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

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

Hiroo Hayashi wrote:

>Joe,
>
>Your tool should have a way to know which CVS tags exist.
>
True, but CVS is so complicated that I wasn't sure if IDEA was just 
hiding the tags from me because it wasn't the version that I had checked 
out.

>Please revert your change.
>
Okay. I'll have to do that tonight. However, how much do you want me to 
revert? I added a method to DevicesConfig which is not used by anything 
else except my new JTree, so I don't see the harm in leaving it there 
since it'll be unused by anything once I put the original JList back in 
place of the JTree.

Also, If I could (I almost did this anyway last night), I'd prefer to 
put the whole building and management of the JTree into its own class 
("DeviceTree", for example). Then, I can still work on it, but it won't 
cause any problems because, again, nothing will actually *using* it. In 
short, there'd be unused code in the CVS tree in *anticipation* of 
future revisions.

Would that be okay, or would you rather not have any of the unused code 
there at all?

>If you cannot wait for Brian to create the
>tag, you can create the tag.
>
Well, that would make me feel a little selfish... forking the code just 
because I want my stuff included *now*.

I don't mind reverting my changes, but it would be nice if I could leave 
some of the stuff *in* but *unused* so that I don't have to keep the 
work I've currently done in some text file on my desktop until it's safe 
for me to paste them into the source again.

- Joe

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

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

Joe,

Your tool should have a way to know which CVS tags exist.  Brian has not
create the CVS tag for 0.20 yet.

Please revert your change.  If you cannot wait for Brian to create the
tag, you can create the tag.  The thread "How to create a release"
starting Aug. 1st, 2004 might help you.

Thanks.

Joe> Okay... well I made the synth selection window into a JTree.
Joe> 
Joe> The code is *ugly* (mostly because DevicesConfig needs a major 
Joe> overhaul). In fact, I wasn't expecting it to even *work* the way it is. 
Joe> I was just doing a test to see how close I was getting and, pow, there 
Joe> it went.
Joe> 
Joe> Give it a try and see if it works for you (I hope Brian already branched 
Joe> the 2.0 candidate...). I know that selecting the Emu throws an exception 
Joe> on mine, but I think that's a bug in some other code.
-- 
Hiroo Hayashi

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

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

Okay... well I made the synth selection window into a JTree.

The code is *ugly* (mostly because DevicesConfig needs a major 
overhaul). In fact, I wasn't expecting it to even *work* the way it is. 
I was just doing a test to see how close I was getting and, pow, there 
it went.

Give it a try and see if it works for you (I hope Brian already branched 
the 2.0 candidate...). I know that selecting the Emu throws an exception 
on mine, but I think that's a bug in some other code.

- Joe

Re: [Jsynthlib-devel] Korg Drivers

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

I took a look this issue again.

The correct fix is to replace
    public static JFrame getInstance() {
	return desktop.getSelectedWindow();
    }

in PatchEdit with

    public static JFrame getInstance() {
	return desktop == null ? null : desktop.getSelectedWindow();
    }

Since this helps synth developers, I've checked it the fix.

Hiroo> Put 
Hiroo>         ErrorMsg.reportStatus(e);
Hiroo> at DevicesConfig.java:197 instead of ErrorMsg.reportError().  It should
Hiroo> give you a better stack trace.
Hiroo> 
Hiroo> GUI cannot be used here.
Hiroo> 
Hiroo> Steven> JSynthLib: 0.20-alpha, Java: 1.5.0_01, OS: Linux, 2.4.26-1.ll.rh90.ccrma
Hiroo> Steven> open inport: M1010LT [hw:0,0], port: 0
Hiroo> Steven> open outport: M1010LT [hw:0,0], port: 0
Hiroo> Steven> loadDevices: -> KorgTriton
Hiroo> Steven> loadPrefs: java.lang.NullPointerException
Hiroo> Steven> java.lang.NullPointerException
Hiroo> Steven>     at core.PatchEdit.getInstance(PatchEdit.java:100)
Hiroo> Steven>     at core.ErrorMsg.reportError(ErrorMsg.java:59)
Hiroo> Steven>     at core.DevicesConfig.createDevice(DevicesConfig.java:197)
Hiroo> Steven>     at core.AppConfig.addDevice(AppConfig.java:316)
Hiroo> Steven>     at core.AppConfig.loadPrefs(AppConfig.java:66)
Hiroo> Steven>     at core.PatchEdit.<init>(PatchEdit.java:44)
Hiroo> Steven>     at JSynthLib.main(JSynthLib.java:33)
Hiroo> Steven> ERR> 'Unable to load user preferences. Defaults loaded instead.' reported.
Hiroo> -- 
Hiroo> Hiroo Hayashi
-- 
Hiroo Hayashi

[Jsynthlib-devel] Decoder Plugin Documentation

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

Here's a first attempt at some documentation for the decoder plugins. 
The sample code is in Groovy. Since this is a first draft I expect it
needs improvement.  Please let me know if you have ANY questions or
comments.

------

INITIALIZATION

Decoders are used for reading (and writing) individual parameters from
a sysex message. There is a separate Decoder instance for each type of
sysex message. Before a decoder can be used, it needs to be
initialized by creating Parameter objects describing the sysex
message. Two methods are used for this: newParameter and
finishParameter.  Parameters must be created in the order they occur
in the sysex message, and each parameter must be finished before
creating the next. The Parameter must store any information that the
decoder needs for de/en-coding. For compatibility with the XML driver,
all this information must be accessible via setters starting with
"set" or "add" and taking a String argument.

For example, this XML:

<range>
  <name>Address Mid</name>
  <min>0</min>
  <max>0x7f</max>
  <comment>Some info</comment>
</range>

Could result in these method calls:

  param = decoder.newParameter("range")
  param.setName("Address Mid")
  param.setMin("0")
  param.setMax("0x7f")
  param.addComment("Some info")

When finishParameter is called, the Decoder is not responsible for
storing the parameter, but it needs to save any information necessary
for creating the next paramter. At a minimum it must keep track of the
total size (in bytes) of the sysex message, but it could also store
other state information that needs to be passed to the Parameter
constructor.


USING DECODERS

The methods decode and decodeString take a Parameter and a byte array
of sysex data (not including the beginning sysex byte) and return,
respectively, an int or a string. Conversely, encode and encodeString
store the specified value into a byte array of sysex data.

Also, there is method encode(int, XMLParameter) which returns a hex
string of the encoded value.  This is mainly used for sending single
parameter changes to the synth, as in: 

  device.send(midiMessage(
    "F0 ${paramChangeHeader()} ${decoder.encode(val, param)} F7"))

(Note: This is merely an example of how encode is used, not the exact
syntax used by an XML driver implementation)


IMPLEMENTATION

Currently plugins must be written in Groovy, although it would not be
difficult to add support for Java ones.  The decoder must have a
default constructor and a non-static main method which registers the
plugin.  For example:

  // Simple decoder with a useful default constructor
  PluginRegistry.registerDecoder("MyDecoder", getClass())
  // Decoder which doesn't use default constructor
  c = getClass().getConstructor(new Class[] { Integer.class } )
  PluginRegistry.registerDecoder("MultiDec 1", c, new Object[] { 1 })
  PluginRegistry.registerDecoder("MultiDec 2", c, new Object[] { 2 })

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

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

I haven't really used the librarian part much, but one of my goals
with the XML Editor is to make it easier to create editors that are
more like the "real" ones I've used.  I'm sure there's room for
improvement with the libraries too.  Being able to view all patches
for a single synth definitely sounds like a good idea.

On Fri, 25 Feb 2005 14:44:22 -0800, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> 
> >I used Galaxy + Editors or something like that at school.
> >Also, although I haven't used SoundDiver, some parts of the XML driver
> >are based off ideas from the SoundDiver programming manual.
> >
> >
> Well, the reason that I ask is because JSL's interface is totally unlike
> any other librarian program that I have used in the past. Particularly,
> the notion of mixing patches and banks from different synths in one
> spreadsheet layout just seems very counter-intuitive.
> 
> Every other editor/lib I've ever used first presents the user with a
> list of the devices they've setup for their system. Then,
> double-clicking on one of those devices opens a window containing the
> patches for *that* device only.
> 
> Every time I use JSL, I look at the layout and wonder "Has anyone here
> ever *used* a *real* lib/editor?"
> 
> Has there been any talk about spiffing up the interface?
> 
> - Joe

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

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

Rib Rdb wrote:

>I used Galaxy + Editors or something like that at school.
>Also, although I haven't used SoundDiver, some parts of the XML driver
>are based off ideas from the SoundDiver programming manual.
>  
>
Well, the reason that I ask is because JSL's interface is totally unlike 
any other librarian program that I have used in the past. Particularly, 
the notion of mixing patches and banks from different synths in one 
spreadsheet layout just seems very counter-intuitive.

Every other editor/lib I've ever used first presents the user with a 
list of the devices they've setup for their system. Then, 
double-clicking on one of those devices opens a window containing the 
patches for *that* device only.

Every time I use JSL, I look at the layout and wonder "Has anyone here 
ever *used* a *real* lib/editor?"

Has there been any talk about spiffing up the interface?

- Joe

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

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

I used Galaxy + Editors or something like that at school.
Also, although I haven't used SoundDiver, some parts of the XML driver
are based off ideas from the SoundDiver programming manual.


On Thu, 24 Feb 2005 13:51:57 -0800, Joe Emenaker <jo...@em...> wrote:
> I was wondering if any of the JSynthLib devel folk have ever used a
> program like MidiQuest, SoundDiver, or UniSyn.
> 
> - Joe
> 
> 
>

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

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

--- Joe Emenaker <jo...@em...> wrote:

> I was wondering if any of the JSynthLib devel folk
> have ever used a 
> program like MidiQuest, SoundDiver, or UniSyn.
> 

I'm currently using a Mac OSX beta version of
SoundDiver. However, it doesn't have support for all
my devices and right now the future of this software
on Mac OSX appears to be in serious doubt.


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

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

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

> Of course, we could take this further and have arrays for each type... =

> listing the types in various languages (in anticipation of a =
multi-language version down the road someday).

Maybe we should read the values from property files
with english names as default and naming the files using
locale IDs.

E.g.

gui.properties <- default values
gui_de.properties <- values for german language
gui_fr.properties <- values for french language
gui_en_US.properties <- values for american-english
gui_en_GB.properties <- values for british-english

And e.g. the constants just include the key:

   public static final String DEV_TYPE_SYNTH =3D =
classification.device-type.synthesizer";
   public static final String DEV_TYPE_DRUM =3D =
"classification.device-type.drum-machine");

A content example could be:

English:

classification.device-type.drum-machine =3D Drum Machine

German:

classification.device-type.drum-machine =3D Schlagzeugmodul

Maybe it would be nice to have a "Classification" class
with methods like:

public String getDeviceType(String key) <- Use the system's default =
locale
public String getDeviceType(String key, Locale locale) <- Use a specific =
locale

and the constants.

Multiple classifications could relatively easy be done
by using a String array.

But I don't know if that would be the best way.

Regards,
Joachim Backhaus


-----Urspr=FCngliche Nachricht-----
Von: jsy...@li... =
[mailto:jsy...@li...]Im Auftrag von Joe =
Emenaker
Gesendet: Donnerstag, 24. Februar 2005 22:48
An: JSynthLib Development
Betreff: Re: AW: [Jsynthlib-devel] Switch to JTree for the device list?


Joachim Backhaus wrote:=20
However, it would be even nicer if we could start classifying the=20
devices as, say, synthesizer, drum machine, foot controller,=20
etc.
   =20

I think that's a very good idea.

Hmm, should the classification be done via the Device class
using a new field "classification" or "type" as String?

Should constants be used for the classifcations?

Else it may be that one developer classifies
the driver as being a "synthesizer" and another as "synthesiser" (Great =
britain).
 =20
If I could carve it in stone and send it over email, I would:=20
          Individual synthdrivers should NOT be able to make up their =
own classification string.
          Individual synthdrivers should NOT be able to make up their =
own classification string.
          Individual synthdrivers should NOT be able to make up their =
own classification string.

The only way to do this (that I can see) which won't lead to chaos down =
the road is to have defined constants in the core app, like:
   public static final String DEV_TYPE_SYNTH =3D "Synthesizer";
   public static final String DEV_TYPE_DRUM =3D "Drum Machine";

Of course, we could take this further and have arrays for each type... =
listing the types in various languages (in anticipation of a =
multi-language version down the road someday).

Of course, there are some judgement calls that would have to be made. =
Many keyboard synths are controllers *and* synths (ie a keyboard =
controller and a rackmount synth) in the same box. They're probably best =
categorized together with the rackmount synths.

Ok, I state an example here how I understood it:

Default tree uses manufactures, e.g.:

Behringer
-> FCB-1010
Quasimidi
-> Quasar
Roland
-> JV-80
-> JV-1080

And a possibility is offered (via button or so) to
order it by a classification, e.g.:

MIDI Controller
-> Behringer FCB-1010
Synthesizer
-> Quasimidi Quasar
-> Roland JV-80
-> Roland JV-1080
 =20
Exactly! There'd also be the possibility of multiple levels like:

MIDI Controller
-> Art
---> X-11
---> X-15 Ultrafoot
-> Behringer
---> FCB-1010
Synthesizer
-> Roland
---> JV-80
---> JV-1080

And we could even, someday, do multiple levels of types:
MIDI Controller
-> Foot Controllers
-> Keyboard Controllers
-> Control Surfaces
Synthesizer
-> Keyboard Synthesizer
-> Rackmount Synthesizer
Drum Units
-> Drum Machines
-> Drum Modules/Brains

However, I'm getting a little too far ahead. I don't want to scare =
anybody. I just want to open everyone's eyes to the ultimate =
possibilities. What I'd like to see first, is for us to pick the =
"low-hanging fruit"... which is just getting the manufacturer/model =
JList going.

- Joe

[Jsynthlib-devel] =?iso-8859-1?Q?KnobWidget_size?=

[=?iso-8859-1?Q?<le...@ti...>]

Should it be possible to have a KnobWidget constructor witch=0D=0Aaccept =
size in its parameters (width and heigth) ? By=0D=0Adefault, size of Knob=
Widget is too big and it  have created=0D=0Aa class named LittleKnobWidge=
t to workaround this.=0D=0A=0D=0ARegards,=0D=0AXavier=0D=0A=0A***********=
************* ADSL JUSQU'A 8 MEGA + 3 MOIS DE TELEPHONE GRATUIT *********=
***************=0AL'ultra haut d=E9bit =E0 15EUR/mois seulement ! Et vous=
 t=E9l=E9phonez gratuitement en France vers les postes fixes,=0Ahors num=E9=
ros sp=E9ciaux pendant 3 mois.=0APour profiter de cette offre exceptionne=
lle, cliquez ici : http://register.tiscali.fr/adsl/  (voir conditions sur=
 le site)=0A

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

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

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

I just need a way of recording a sysex message and then viewing the 
bytes. I don't need any of the fancy stuff. I want to get JSL ready to 
receive, then manually do a sysex dump from the device, and have JSL 
record it. As a bonus, it would be nice to be able to view the sysex 
data as hex.

- Joe

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

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

I was wondering if any of the JSynthLib devel folk have ever used a 
program like MidiQuest, SoundDiver, or UniSyn.

- Joe

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

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

Joachim Backhaus wrote:

>>However, it would be even nicer if we could start classifying the 
>>devices as, say, synthesizer, drum machine, foot controller, 
>>etc.
>>    
>>
>
>I think that's a very good idea.
>
>Hmm, should the classification be done via the Device class
>using a new field "classification" or "type" as String?
>
>Should constants be used for the classifcations?
>
>Else it may be that one developer classifies
>the driver as being a "synthesizer" and another as "synthesiser" (Great britain).
>  
>
If I could carve it in stone and send it over email, I would:
          Individual synthdrivers should NOT be able to make up their 
own classification string.
          Individual synthdrivers should NOT be able to make up their 
own classification string.
          Individual synthdrivers should NOT be able to make up their 
own classification string.

The only way to do this (that I can see) which won't lead to chaos down 
the road is to have defined constants in the core app, like:
   public static final String DEV_TYPE_SYNTH = "Synthesizer";
   public static final String DEV_TYPE_DRUM = "Drum Machine";

Of course, we could take this further and have arrays for each type... 
listing the types in various languages (in anticipation of a 
multi-language version down the road someday).

Of course, there are some judgement calls that would have to be made. 
Many keyboard synths are controllers *and* synths (ie a keyboard 
controller and a rackmount synth) in the same box. They're probably best 
categorized together with the rackmount synths.

>Ok, I state an example here how I understood it:
>
>Default tree uses manufactures, e.g.:
>
>Behringer
>-> FCB-1010
>Quasimidi
>-> Quasar
>Roland
>-> JV-80
>-> JV-1080
>
>And a possibility is offered (via button or so) to
>order it by a classification, e.g.:
>
>MIDI Controller
>-> Behringer FCB-1010
>Synthesizer
>-> Quasimidi Quasar
>-> Roland JV-80
>-> Roland JV-1080
>  
>
Exactly! There'd also be the possibility of multiple levels like:

MIDI Controller
-> Art
---> X-11
---> X-15 Ultrafoot
-> Behringer
---> FCB-1010
Synthesizer
-> Roland
---> JV-80
---> JV-1080

And we could even, someday, do multiple levels of types:
MIDI Controller
-> Foot Controllers
-> Keyboard Controllers
-> Control Surfaces
Synthesizer
-> Keyboard Synthesizer
-> Rackmount Synthesizer
Drum Units
-> Drum Machines
-> Drum Modules/Brains

However, I'm getting a little too far ahead. I don't want to scare 
anybody. I just want to open everyone's eyes to the ultimate 
possibilities. What I'd like to see first, is for us to pick the 
"low-hanging fruit"... which is just getting the manufacturer/model 
JList going.

- Joe

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

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

--- Joe Emenaker <jo...@em...> wrote:
> I guess what I'm getting at is... you'll probably
> have to hold my hand a 
> little to get me up to speed on how the higher-level
> stuff 
> (drivers/editors) work in JSL.

I think I've written enough drivers/editors now to
have a fair basic understaning of how they work but I
don't fully understand why they were designed to work
the way they do.

For instance here's one thing that I have never
understood. When you pull up the Get Patch dialog and
make your selections you're telling JSL which driver
and patch you want to request. When you hit the get
button, the selected driver sends the request to the
device and the device sends back the requested patch.
Then JSL searches through all the currently configured
drivers to try to figure out which driver the patch
belongs to. Why is this necessary when I just told it
what driver the patch belongs to?


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 

Re: Fwd: Re: [Jsynthlib-devel] Method to pack/unpack 7-bit bytes to/from 8-bit bytes?

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

On Wed, 23 Feb 2005 18:16:07 -0800, Joe Emenaker <jo...@em...> wrote:
>  Jeff Weber wrote:  
>  Anyhow, I'm still not convinced that each synthdriver author should have to
> re-write nibbilizers each time. I'm sure that there are a fixed number of
> ways were going to see this done in real life... and they're all going to
> need to be accessible to the XML driver *anyway*... so I still vote for
> consolidating them somewhere.

I've got to run now, but I'll try to write some documentation on the
architecture of the XML driver and plugin system today or tomorrow to
help with this.

[Jsynthlib-devel] Fwd: Overriding calculateChecksum

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

--- Joe Emenaker <jo...@em...> wrote:

> Date: Thu, 24 Feb 2005 03:01:42 +0000
> From: Joe Emenaker <jo...@em...>
> To: Jeff Weber <jww...@ya...>
> Subject: Overriding calculateChecksum
> 
> I came across this in your DM5 drivers....
> 
>         /** Calculates the checksum for the DM5 by
calling
>             * this.calculateChecksum(Patch patch,
int start, int end, int offset). This
>             * needs to be included to override the
version in the Driver class.
>             */
>         protected void calculateChecksum(Patch p) {
>             calculateChecksum(p, checksumStart,
checksumEnd, checksumOffset);
>         }
> 
> Actually, I don't think you have to include this. If
> you delete it, the 
> /un-overridden/ *calculateChecksum(Patch)* in Driver
> should /still/ call 
> your /overridden/ version of
> *calculateChecksum(Patch,int,int,int).
> 
> One of the nice things about inheritance.....
> 

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

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

Re: AW: [Jsynthlib-devel] Behringer V-Amp 2 Support

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

--- Joachim Backhaus <jba...@pi...>
wrote:

> Maybe we should add that it is recommended to open
> a feature request on the SourceForge site before
> starting the development of a new driver.

Sorry, I guess I missed this in the past. I opened a
feature request for the V-Amp 2. I've already started
on the drivers. Do I need to assign this to myself?


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250

[Jsynthlib-devel] Re: Behringer FCB1010

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

Joe> Well, your FCB1010 driver is the thing that got
me
Joe> to come out of hiding 
Joe> and rejoin the JSL development. So... thanks.

Thank-you. I'm truly flattered. No, really!

Joe>  (Don't you love the 
Joe> FCB1010? The thing's freakin' killer).

I think it's awsome. And for the price, nothing even
comes close.

Joe> 1 - I was initially stuck just trying to get my
FCB
Joe> into config mode. I 
Joe> even checked the original documentation and still
Joe> couldn't. After 
Joe> futzing around, I discovered that, if the FCB
Joe> (well... *my* FCB... I 
Joe> don't know about anybody else's) detects
something
Joe> on its MIDI *in* 
Joe> port, it doesn't go into config mode. I had to
plug
Joe> in the MIDI *out* 
Joe> and then make sure that the MIDI *in* was NOT
Joe> plugged in. Try this on 
Joe> yours. If you get the same result, you might want
to
Joe> mention it in the 
Joe> initial help blurb when you add the driver in
JSL.

I haven't had any problem getting my FCB into config
mode with another device connected to the MIDI in. I
even tried various combinations of the Merge, Running
Status, and Direct Select settings thinking that might
have something to do with it. I know there are several
eProm versions. Mine is version 2.1 (probably not the
most current). I don't know of any way to get it to
show the version in the display. I think you have to
crack the case to see it. There should be a sticker on
the eProm.

Joe> 2 - In the patch editor, in the Global Settings
tab,
Joe> the text labels 
Joe> look disabled/greyed while the combo boxes are
still
Joe> enabled. Is this 
Joe> intentional?

As I understand it this is a feature of JSL and it's
controlled by something in the core code. If you're
using an external fader box with 16 faders, the
dimming/highlighting of the labels on the widgets is
supposed to show which bank of faders is currently
active. You use the left and right buttons in the
toolbar to swich banks. Apparently it keys off the
fader numbers you assign when creating the widgets in
your editor. For some reason the left and right
buttons don't seem to have any effect on the FCB1010
editor. I haven't really had the time to look into it.
I remember there was some discussion about this
feature a while ago.


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

Re: [Jsynthlib-devel] Korg Drivers

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

Put 
        ErrorMsg.reportStatus(e);
at DevicesConfig.java:197 instead of ErrorMsg.reportError().  It should
give you a better stack trace.

GUI cannot be used here.

Steven> JSynthLib: 0.20-alpha, Java: 1.5.0_01, OS: Linux, 2.4.26-1.ll.rh90.ccrma
Steven> open inport: M1010LT [hw:0,0], port: 0
Steven> open outport: M1010LT [hw:0,0], port: 0
Steven> loadDevices: -> KorgTriton
Steven> loadPrefs: java.lang.NullPointerException
Steven> java.lang.NullPointerException
Steven>     at core.PatchEdit.getInstance(PatchEdit.java:100)
Steven>     at core.ErrorMsg.reportError(ErrorMsg.java:59)
Steven>     at core.DevicesConfig.createDevice(DevicesConfig.java:197)
Steven>     at core.AppConfig.addDevice(AppConfig.java:316)
Steven>     at core.AppConfig.loadPrefs(AppConfig.java:66)
Steven>     at core.PatchEdit.<init>(PatchEdit.java:44)
Steven>     at JSynthLib.main(JSynthLib.java:33)
Steven> ERR> 'Unable to load user preferences. Defaults loaded instead.' reported.
-- 
Hiroo Hayashi

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

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

> However, it would be even nicer if we could start classifying the=20
> devices as, say, synthesizer, drum machine, foot controller,=20
> etc.

I think that's a very good idea.

Hmm, should the classification be done via the Device class
using a new field "classification" or "type" as String?

Should constants be used for the classifcations?

Else it may be that one developer classifies
the driver as being a "synthesizer" and another as "synthesiser" (Great =
britain).

Ok, this can also happen with the manufacturers (e.g. "Sequencital =
Circuits" vs. "Sequential"
vs. "SCI") so I don't know if that's a good argument and if constants =
are really necessary.

Ok, I state an example here how I understood it:

Default tree uses manufactures, e.g.:

Behringer
-> FCB-1010
Quasimidi
-> Quasar
Roland
-> JV-80
-> JV-1080

And a possibility is offered (via button or so) to
order it by a classification, e.g.:

MIDI Controller
-> Behringer FCB-1010
Synthesizer
-> Quasimidi Quasar
-> Roland JV-80
-> Roland JV-1080

Right?

Regards,
Joachim Backhaus

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

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

The list of devices is getting long enough such that I think it might be 
time to turn it into a JTree.

With a JTree, we could categorize the devices by manufacturer (so 
there'd be an Alesis folder, a Roland folder, a Yamaha folder, etc.). 
The individual Device classes already keep the manufacturer and model as 
separate strings, so this should be easy to do.

However, it would be even nicer if we could start classifying the 
devices as, say, synthesizer, drum machine, foot controller, etc. Then, 
the user could choose to have the JTree ordered by type, then 
manufacturer, or manufacturer then type, or just by manufacturer. I've 
written a JTree with this kind of re-ordering behavior before, so it's 
not too difficult.

But, at the very least, I think that the device list should be turned 
into a JTree. If nobody has any objections, I'll go ahead and do it.

- Joe

AW: [Jsynthlib-devel] Behringer V-Amp 2 Support

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

Hello,

the V-Amp uses the same SysEx specs as the V-Amp2 as far as I know.

The changes were only quality improvements of the A/D & D/A converters
and the algorithms.

Another thing:

In "programming.html" we have the following text:
"Check the feature request (RFE) tracker page on JSynthLib SourceForge =
site and=20
drop a line to JSynthLib mailing list to find out if anyone is working =
on adding support for that synth. "

Maybe we should add that it is recommended to open
a feature request on the SourceForge site before
starting the development of a new driver.

Currently there are only 7 feature requests,
all for new synth drivers and 3 are opened.

If the feature requests would be used for any new synth
driver that would give a JSynthLib user or a potential
user who waits for a specific synth to be supported
better information. It also may help to get new users
and they see that something happens in this sector.

Regards,
Joachim Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im=20
> Auftrag von Jeff
> Weber
> Gesendet: Donnerstag, 24. Februar 2005 02:02
> An: JSynthLib Development
> Betreff: Re: [Jsynthlib-devel] Behringer V-Amp 2 Support
>=20
>=20
>=20
> --- Joe Emenaker <jo...@em...> wrote:
>=20
> > No, but I just got my Bass V-Amp today, and there's
> > probably a lot of=20
> > similarity between them. We should probably
> > collaborate and put as many=20
> > common functions into common files.
> >=20
> > - Joe
> >=20
>=20
> Joe,
>=20
> Sounds like a plan. I've already got a set of working
> drivers and was planning to start on the editor this
> weekend. One problem though--I have a sysex spec for
> the original V-Amp but I haven't been able to locate
> one for the V-Amp 2. Behringer doesn't have any specs
> posted for either of the guitar V-Amps, the V-ampire
> or the V-Amp Pro on their website. I haven't checked
> if they have any for the Bass V-Amp.
>=20
> Anyway I figured I'd have to just write some code and
> figure it out the differences on my own.
>=20
> How do you think we should proceed?
>=20
> Jeff
>=20
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around=20
> http://mail.yahoo.com=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.
> 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

[Jsynthlib-devel] Korg Drivers

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

Hello -
Before I go completely nuts trying to decipher this, could someone who 
has had some success with the Korg drivers drop me an email?  I've 
gotten past the easy part of getting the device class to work, but I'm 
stuck at the single driver.  If I load it in the device with  
addDriver(new KorgTritonSingleDriver());, I get a

JSynthLib: 0.20-alpha, Java: 1.5.0_01, OS: Linux, 2.4.26-1.ll.rh90.ccrma
open inport: M1010LT [hw:0,0], port: 0
open outport: M1010LT [hw:0,0], port: 0
loadDevices: -> KorgTriton
loadPrefs: java.lang.NullPointerException
java.lang.NullPointerException
    at core.PatchEdit.getInstance(PatchEdit.java:100)
    at core.ErrorMsg.reportError(ErrorMsg.java:59)
    at core.DevicesConfig.createDevice(DevicesConfig.java:197)
    at core.AppConfig.addDevice(AppConfig.java:316)
    at core.AppConfig.loadPrefs(AppConfig.java:66)
    at core.PatchEdit.<init>(PatchEdit.java:44)
    at JSynthLib.main(JSynthLib.java:33)
ERR> 'Unable to load user preferences. Defaults loaded instead.' reported.

Without calling the single driver, it looks like this:
JSynthLib: 0.20-alpha, Java: 1.5.0_01, OS: Linux, 2.4.26-1.ll.rh90.ccrma
open inport: M1010LT [hw:0,0], port: 0
open outport: M1010LT [hw:0,0], port: 0
loadDevices: -> KorgTriton
loadDevices: -> KorgTriton
deviceList:
[Generic Unknown <Unknown>  -  MIDI Out Port: M1010LT [hw:0,0]  -  MIDI 
Channel: 1,
Korg Triton Rack <Triton Rack>  -  MIDI Out Port: M1010LT [hw:0,0]  -  
MIDI Channel: 1,
Korg Triton Rack <Triton Rack>  -  MIDI Out Port: M1010LT [hw:0,0]  -  
MIDI Channel: 1]


What should I be looking for in the single driver?
What should I be looking for in the MIDI implementation for my synth to 
put in the single driver?

Its late and it might be obvious tomorrow, but maybe you have been here 
before?
Thanks