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

Re: [Jsynthlib-devel] Is anybody even *seeing* these emails?

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

Hi,

Just to say that I'm not working on JSynthLib right now but I continue to look 
at list.
Actually, I'm developping a MacOSX/Cocoa editor for the micro Q Waldorf because 
Java is too slow on my eMac, especially with many Swing widgets.

Also I want to have a look at Cocoa features like GUI and MIDI.

But if someone need information on the micro Q, I'm still able to give my 
experience on this little but powerful synthesizer ;o)


-- 
Denis


Joe Emenaker wrote:
> Has everyone just finally added me to their blacklist or something?
> 
> I send "What does everybody think about this idea?" messages to the list 
> and nobody says a single thing.
> 
> - Joe

[Jsynthlib-devel] Is anybody even *seeing* these emails?

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

Has everyone just finally added me to their blacklist or something?

I send "What does everybody think about this idea?" messages to the list 
and nobody says a single thing.

- Joe

Re: [Jsynthlib-devel] Proposal: PatchNameModel?

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

Joe Emenaker wrote:

>If we had
>several different implementations of PatchNameModel like:
>
>    FixedLengthPatchNameModel(int patchNameStart, patchNameSize);
>    TerminatedPatchNameModel(int patchNameStart, byte terminator);
>
>Then it could make it easier to accomodate other name-storage methods.
>  
>
I just thought of another one. For some time, I've felt that it would be
nice to be able to give names to patches which, in the hardware device
itself, doesn't have a name. The Behringer FCB1010 is an example; it has
no display on it and the patch format doesn't support names.

However, what if there was something like:
    HashValueNameModel(Preferences pref);

The idea is that, when the user triggered a "setPatchName", the
HashValueNameModel would calculate the hashvalue of the patch data and
store the name in a preferences file (probably the one that JSL gave to
the driver when it was instantiated)... and could also look them up from
getPatchName.

- Joe

[Jsynthlib-devel] I've started a wiki...

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

Okay... so I've started putting together a Wiki aimed at helping people
learn how to write synthdrivers. Only the "SimpleExample" is there (and
only partially so) yet.... but it's enough to get an idea.

http://joe.emenaker.com/Wikka/wikka.php?wakka=SimpleExample

[Jsynthlib-devel] Proposal: PatchNameModel?

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

What are people's thoughts about replacing patchNameStart and
patchNameSize in core.Driver with some interface (PatchNameModel, for
example)?

The problem with the current system is that some synths use
null-terminated strings instead of fixed-length strings. If we had
several different implementations of PatchNameModel like:

    FixedLengthPatchNameModel(int patchNameStart, patchNameSize);
    TerminatedPatchNameModel(int patchNameStart, byte terminator);

Then it could make it easier to accomodate other name-storage methods.

I know that developers can override getPatchName and setPatchName (it's
what I'm doing now). I'm just tossing around some ideas which I think
would clean things up a bit.

If I were willing to do all of the work of converting existing
synthdrivers to something like this, what are people's thoughts about
it? This isn't that different from the idea of having some standard
checksum models (to replace checksumOffset, checksumStart, and
checksumEnd in core.Driver as well).

- Joe

[Jsynthlib-devel] deviceIDoffset

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

core.Driver has a variable called "deviceIDoffset" which is used to set
the deviceID in outgoing patches.

However, I can't find any trace of this being used in conjunction with
sysexID or "acceptsPatch". Is there any code to check the incoming
deviceID value against that of the synthdrivers?

If not, how does JSL keep track of things if there are several identical
pieces of hardware which differ only by DeviceID? For example, if I have
two Access Virus synths, one with DeviceID of 1 and the other with a
DeviceID of 2, can JSL tell which one a patch came from?

- Joe

[Jsynthlib-devel] Eliminating numSysexMsgs

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

There is a variable in the core.Driver class called numSysexMsgs. The
comment says "Not used now". I did a scan for all classes using it and,
indeed, it appears to not be used by anything in core, although some
synthdrivers set values for it.

If nobody objects, I'm going to remove all references to numSysexMsgs.

- Joe

[Jsynthlib-devel] Meeting?

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

Are there any people working on the project who live anwhere between Los 
Angeles and San Francisco or in northern New Mexico?

At some point in the near future (a few months), I'd be interested in 
meeting up with some of the primary developers to brainstorm on ideas 
for JSL.

- Joe

[Jsynthlib-devel] AW: [jsynthlib-dev] Boss DR-660

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

Hello imkindadead,

the Yahoogroups mailing list isn't used anymore.

Instead we have a SourceForge mailing list:
http://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

This mail goes also to this list.

Regards,
Joachim Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@ya...
> [mailto:jsy...@ya...]Im Auftrag von imkindadead
> Gesendet: Montag, 2. Mai 2005 23:24
> An: jsy...@ya...
> Betreff: [jsynthlib-dev] Boss DR-660
>=20
>=20
> Hi,
> I have a DR-660, and am trying to use it with Jsynthlib 0.2-beta.
> However, I do not know the parameters I have to set both to in order
> to get them to interface, and send SysEx to each other. Can anyone
> please help me?
> regards
>=20
>=20
>=20
>=20
>=20
> =20
> Yahoo! Groups Links
>=20
> <*> To visit your group on the web, go to:
>     http://groups.yahoo.com/group/jsynthlib-dev/
>=20
> <*> To unsubscribe from this group, send an email to:
>     jsy...@ya...
>=20
> <*> Your use of Yahoo! Groups is subject to:
>     http://docs.yahoo.com/info/terms/
> =20
>=20
>=20
>=20
>=20

[Jsynthlib-devel] Use of "patchSize" to automatically finish getting a patch?

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

So, for the last couple of days, I've been experimenting with the way 
that JSL requests patches. Today, I tried setting patchSize in my driver 
for the first time.

I noticed that setting patchSize didn't cause the "Get Patch" dialog to 
automatically close. I still had to click "Done".

Two questions:
 1 - Is there a reason we would *not* want JSL to autmatically close the 
"Get Patch" dialog box if the patch sizes match *and* the driver returns 
"true" for "acceptsPatch"?

 2 - If patchSize isn't used for this, what *is* it used for? Is it only 
used in the default acceptsPatch() method in Driver?

I think we talked about #1 a couple of months ago... where someone 
mentioned that it might be helpful for a driver to indicate that, 
although more sysex messages were needed to complete what the driver was 
expecting, the set of sysex messages received so far were correct. In 
other words, a way for a driver to say "It's a good start, but I need 
more...".

- Joe

Re: [Jsynthlib-devel] Re: Wiki

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

Mikael Kurula wrote:

>I think that's a good Idea. In particular if it is kept up-to-date. :)
>  
>
Well, if I don't hear from Brain in the next couple of days regarding 
putting it on jsynthlib.org, then I'll just put it on my own website.

- Joe

[Jsynthlib-devel] Feature requests

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

Hi,

> No... there's a *request* for S80 support. :) However, some=20
> of the JSL=20
> devels use the RFE's to signify that, if someone doesn't=20
> write a driver=20
> for it first, then they'll write one eventually.

Sorry Joe, that's wrong.

Normally the developer who is currently working on driver support
opens (or should open) a feature request for it to notify it to other
developers who want to write one, too.

It is not necessary to be a project developer for opening a feature
request.

Unfortunately I currently have no time to go on working on the drivers
I opened feature requests for (E-mu XL-7, Waldorf Q).=20
And the "Korg Triton" is not developed
but by Steven Schmidt and "JV1080" by daxav. They are just assigned
to me which means that I'm the one who will check the code into
CVS when finished.

Regards,
Joachim



> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von Joe
> Emenaker
> Gesendet: Samstag, 30. April 2005 08:40
> An: Daniel Lyons
> Cc: jsy...@li...
> Betreff: Re: [Jsynthlib-devel] Yamaha S80 development?
>=20
>=20
> Daniel Lyons wrote:
>=20
> >I just downloaded JSynthLib and noticed that there was a=20
> Yamaha S80 development going on according the the sourceforge=20
> RFE list.
> > =20
> >
> No... there's a *request* for S80 support. :) However, some=20
> of the JSL=20
> devels use the RFE's to signify that, if someone doesn't=20
> write a driver=20
> for it first, then they'll write one eventually.
>=20
> >so I was wondering if he (you? jemenake) might want me to go=20
> ahead and give the S80 a shot (I've got an S80 and am excited=20
> about having a patch editor GUI plus load/save).
> > =20
> >
> Go right ahead. I haven't seen the S80 sysex spec anywhere. If you've=20
> got it, I'd appreciate a copy.
>=20
> >I'm mainly a C++/PERL programmer, but I don't think it'll=20
> give me too many troubles.
> > =20
> >
> Famous last words. :)
>=20
> Seriously, though... I find the JSL API to be very=20
> counter-intuitive and=20
> awkward. I'm gradually figuring out the least-painful way to=20
> write for=20
> it... but it required looking at lots of the core code. To=20
> prevent this=20
> from happening to anyone in the future, I'm hoping to make a=20
> nice Wiki=20
> or, at least, a set of web pages called "JSL coding for=20
> dummies", which=20
> are a bit more explanitory about how to get things done in=20
> JSL and why=20
> it does things the way it does them.
>=20
> So, if you get stuck anywhere... don't hesitate to let me know.
>=20
> - Joe
>=20

AW: [Jsynthlib-devel] Behringer Bass V-Amp

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

Hi,

> The impression I got from the author of the V-Amp author (I=20
> think it was either Jeff or Joachim)

I'm innocent. ;-)

And for the V-Amp 2 (by Jeff Weber):
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1151153&gro=
up_id=3D41208&atid=3D430007


Reminder ;-) :
There is also a feature request for the Bass Vamp:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1150873&gro=
up_id=3D41208&atid=3D430007

Regards,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von Joe
> Emenaker
> Gesendet: Freitag, 29. April 2005 23:09
> An: jsy...@li...
> Betreff: Re: [Jsynthlib-devel] Behringer Bass V-Amp
>=20
>=20
> Manuel Aristar=E1n wrote:
>=20
> > So, what's the status of existing V-Amp driver?
> > Guitar V-Amp and Bass V-Amp have very similar SysEx specs,
> > so I guess the existing code can be reused for the Bass driver.
>=20
> The impression I got from the author of the V-Amp author (I=20
> think it was=20
> either Jeff or Joachim) was that the specs for the V-Amp and=20
> V-Amp 2.0=20
> were identical and that there was probably a lot of=20
> congruency between=20
> the V-Amp and the Bass V-Amp as well. I think I recall some hope that=20
> the same driver could be used for all units in the V-Amp line.
>=20
> However, I'm not sure how a single synthdriver is supposed to support=20
> multiple sysex specs (even if they are very alike). One=20
> problem is that=20
> it appears that it's possible to specify only one sysexID=20
> string in your=20
> subclass of Device.... and the various V-Amp's almost certainly have=20
> different ID strings that they respond with.
>=20
> Rib Rdb and I recently discussed an idea which would enable a=20
> synthdriver to enumerate several different hardware devices it could=20
> talk to.... but everybody here seems pretty averse to even=20
> making minor=20
> changes to the API.
>=20
> So, it looks like you might have to just copy the entire V-Amp=20
> synthdriver to another package and alter it for the Bass=20
> V-Amp. If you=20
> can make it so that it works with the Bass V-Amp and the Bass=20
> V-Amp 2.0,=20
> make sure you put that in the description (like "Bass V-Amp=20
> (1 and 2)"=20
> or "Bass V-Amp & Bass V-Amp 2.0"). As a user, I know that, if I had a=20
> Bass V-Amp and I only saw an entry for "V-Amp 2.0", I'd be=20
> unsure as to=20
> whether the driver would work for my device.
>=20
> - Joe
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4=20
> great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

Re: [Jsynthlib-devel] Yamaha S80 development?

[Daniel L. <soc...@ma...>]

----- Original Message -----
From: "Joe Emenaker" <jo...@em...>
To: jsy...@li...
Subject: Re: [Jsynthlib-devel] Yamaha S80 development?
Date: Sat, 30 Apr 2005 02:20:35 -0700


> >> Go right ahead. I haven't seen the S80 sysex spec anywhere. If=20
> >> you've got it, I'd appreciate a copy.
> >>
> >>
> > The data sheets from Yamaha do leave a bit to the imagination,
> >
> Oh yeah? I'll pit my Digitech Studio 400 "spec" against your Yamaha=20
> S80 any day! :)

My S80 is a lover, not a fighter!=20=20

>=20
> > but I think there's enough there to reverse engineer what isn't=20
> > in the documentation
> >
> For what it's worth, I wrote a hex-dump driver which makes it=20
> pretty easy to quickly slurp up a sysex dump and inspect it.=20
> Sometime in the future, I'd like to add the ability to do=20
> comparisons between two sysex's and have the hexdumper list all of=20
> the ranges that are different. That way, you could tweak a setting=20
> on the synth, do another sysex dump, and see what all changed.=20
> Could be handy for reverse-engineering.

Actually, that could be interesting to use.  I've only flipped through the =
MIDI specs and haven't programmed in them before, however - it looked like =
I might be able to separate out the commands from each other with a close i=
nspection.  As for the diff, if each byte or 2 byte sequence were on a diff=
erent line, you could just run diff over it.  Or, what I would do - is have=
 a PERL script make the files into 2 bytes per line, run diff, and strip th=
e output back into the original format.  Diff's luckily already got that al=
gorithm down, which might not be the simplist thing.

Could you send me a copy? :)

> I don't mean to start a religious war (and this ain't the place for=20
> it), but I'm just letting you know two of the things that kinda=20
> helped me "see the light" when moving from C++ to Java.

For this app the speed gains of C++ probably won't do much.  I've heard, fo=
r the record, that you can put a memory management package into C++ if it s=
uits your fancy (I haven't done this).  I tend to use PERL for everything n=
owadays, I've always wondered about pitting PERL against Java.  PERL actual=
ly first compiles the code into it's own internal format which it executes,=
 although there is no mechanism for passing this around (nor do I have a cl=
ue if it's platform independent).  Not that I'd really have the patience to=
 test the two against each other.

Cheers,
Dan

--=20
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: [Jsynthlib-devel] Yamaha S80 development?

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

Daniel Lyons wrote:

>Well, the JSynthLib developer docs said to check the RFE first.  Heh, I dont know - i assumed since it was 'assigned' to someone that meant something.
>
Well... it should have meant something... but it doesn't. The guy who 
suggested using the RFE's to signify "intent to write" assigned the 
projects to the people who submitted them.... but, like you say... oh well.

>>Go right ahead. I haven't seen the S80 sysex spec anywhere. If 
>>you've got it, I'd appreciate a copy.
>>    
>>
>The data sheets from Yamaha do leave a bit to the imagination,
>
Oh yeah? I'll pit my Digitech Studio 400 "spec" against your Yamaha S80 
any day! :)

>but I think there's enough there to reverse engineer what isn't in the documentation
>
For what it's worth, I wrote a hex-dump driver which makes it pretty 
easy to quickly slurp up a sysex dump and inspect it. Sometime in the 
future, I'd like to add the ability to do comparisons between two 
sysex's and have the hexdumper list all of the ranges that are 
different. That way, you could tweak a setting on the synth, do another 
sysex dump, and see what all changed. Could be handy for 
reverse-engineering.

> so... I figured there might be hope for Java after all! 
>(multiple inheritance rocks the universe, though, they'll never understand that).
>  
>
When I first read about Java, I was horrified. I warmed up to it, 
though. The two main complaints I hear about it (and my responses to 
them) are:
1 - No multiple inheritance: True, but when I read Gosling's 
justification for it, I felt that the man had a true moment of 
inspiration. He noted that the vast majority of the time people use 
multiple inheritance, it isn't because they really need to "inherit" 
anything but because their class needs to advertize that it implements 
certain methods (ie, so that other classes know that they can *call* 
method "xyz"). For that, Gosling made interfaces... and I consider that 
a stroke of incredible insight.
2 - Java is slow: This is true as well. However, this problem goes away 
with time. By that I mean... go write a program in Java and another C++. 
Suppose that the Java program is slow and that the C++ one has memory 
leaks or, even worse, dangling pointers. If you put them on the shelf 
and wait a year and then come back, the Java program will probably be 
usable (still not as fast as the C++, but fast enough to use now), yet 
the C++ will still have the memory leaks and dangling pointers. In 
short, we'll always have faster processors, but we'll never have 
processors that magically figure out what the programmer *meant* to do.

I don't mean to start a religious war (and this ain't the place for it), 
but I'm just letting you know two of the things that kinda helped me 
"see the light" when moving from C++ to Java.

>>So, if you get stuck anywhere... don't hesitate to let me know.
>>    
>>
>I'll take that as a green light.  Alright, if I find myself shaking my
>fist too much, you'll have one frustrated nerd e-mailing you :)
>  
>
Read the archives from a couple of months ago... the list has already 
had a frustrated nerd emailing *them*. I guess I'm due for my pennance.

- Joe

Re: [Jsynthlib-devel] Yamaha S80 development?

[Daniel L. <soc...@ma...>]

----- Original Message -----
From: "Joe Emenaker" <jo...@em...>
To: "Daniel Lyons" <soc...@ma...>
Subject: Re: [Jsynthlib-devel] Yamaha S80 development?
Date: Fri, 29 Apr 2005 23:39:56 -0700

>=20
> Daniel Lyons wrote:
>=20
> > I just downloaded JSynthLib and noticed that there was a Yamaha=20
> > S80 development going on according the the sourceforge RFE list.
> >
> >
> No... there's a *request* for S80 support. :) However, some of the=20
> JSL devels use the RFE's to signify that, if someone doesn't write=20
> a driver for it first, then they'll write one eventually.

Well, the JSynthLib developer docs said to check the RFE first.  Heh, I don=
t know - i assumed since it was 'assigned' to someone that meant something.=
  Well, it's still less of a mess than my apartment, so oh well.


>=20
> > so I was wondering if he (you? jemenake) might want me to go=20
> > ahead and give the S80 a shot (I've got an S80 and am excited=20
> > about having a patch editor GUI plus load/save).
> >
> >
> Go right ahead. I haven't seen the S80 sysex spec anywhere. If=20
> you've got it, I'd appreciate a copy.

The data sheets from Yamaha do leave a bit to the imagination, but I think =
there's enough there to reverse engineer what isn't in the documentation - =
I only see a couple possible combinations of sysex data that'll work.  At l=
east there's a starting point, though:

See:
http://www2.yamaha.co.jp/manual/pdf/emi/english/synth/S80E2.PDF
and
http://www2.yamaha.co.jp/manual/pdf/emi/english/synth/S80E3.pdf

> > I'm mainly a C++/PERL programmer, but I don't think it'll give me=20
> > too many troubles.
> >
> >

> Famous last words. :)

*bonks you on the head*

> Seriously, though... I find the JSL API to be very=20
> counter-intuitive and awkward. I'm gradually figuring out the=20
> least-painful way to write for it... but it required looking at=20
> lots of the core code. To prevent this from happening to anyone in=20
> the future, I'm hoping to make a nice Wiki or, at least, a set of=20
> web pages called "JSL coding for dummies", which are a bit more=20
> explanitory about how to get things done in JSL and why it does=20
> things the way it does them.

There were those dev docs from the main site.  I'll admit I was tempted
to rewrite this glade midi controller to do the job since I'm not a big
fan of Java, but I liked the look to JSynthLib and got it running without
too man yproblems... so... I figured there might be hope for Java after all=
!=20
(multiple inheritance rocks the universe, though, they'll never understand =
that).

> So, if you get stuck anywhere... don't hesitate to let me know.

I'll take that as a green light.  Alright, if I find myself shaking my
fist too much, you'll have one frustrated nerd e-mailing you :)

Cheers,
Dan
--=20
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: [Jsynthlib-devel] Yamaha S80 development?

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

Daniel Lyons wrote:

>I just downloaded JSynthLib and noticed that there was a Yamaha S80 development going on according the the sourceforge RFE list.
>  
>
No... there's a *request* for S80 support. :) However, some of the JSL 
devels use the RFE's to signify that, if someone doesn't write a driver 
for it first, then they'll write one eventually.

>so I was wondering if he (you? jemenake) might want me to go ahead and give the S80 a shot (I've got an S80 and am excited about having a patch editor GUI plus load/save).
>  
>
Go right ahead. I haven't seen the S80 sysex spec anywhere. If you've 
got it, I'd appreciate a copy.

>I'm mainly a C++/PERL programmer, but I don't think it'll give me too many troubles.
>  
>
Famous last words. :)

Seriously, though... I find the JSL API to be very counter-intuitive and 
awkward. I'm gradually figuring out the least-painful way to write for 
it... but it required looking at lots of the core code. To prevent this 
from happening to anyone in the future, I'm hoping to make a nice Wiki 
or, at least, a set of web pages called "JSL coding for dummies", which 
are a bit more explanitory about how to get things done in JSL and why 
it does things the way it does them.

So, if you get stuck anywhere... don't hesitate to let me know.

- Joe

[Jsynthlib-devel] Yamaha S80 development?

[Daniel L. <soc...@ma...>]

Hello,

I just downloaded JSynthLib and noticed that there was a Yamaha S80 develop=
ment going on according the the sourceforge RFE list.

I noticed the same guy who's doing that one also is working on 4-5 others, =
so I was wondering if he (you? jemenake) might want me to go ahead and give=
 the S80 a shot (I've got an S80 and am excited about having a patch editor=
 GUI plus load/save).

I'm mainly a C++/PERL programmer, but I don't think it'll give me too many =
troubles.

Regards,
Dan
--=20
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: [Jsynthlib-devel] Behringer Bass V-Amp

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

Manuel Aristarán wrote:

> So, what's the status of existing V-Amp driver?
> Guitar V-Amp and Bass V-Amp have very similar SysEx specs,
> so I guess the existing code can be reused for the Bass driver.

The impression I got from the author of the V-Amp author (I think it was 
either Jeff or Joachim) was that the specs for the V-Amp and V-Amp 2.0 
were identical and that there was probably a lot of congruency between 
the V-Amp and the Bass V-Amp as well. I think I recall some hope that 
the same driver could be used for all units in the V-Amp line.

However, I'm not sure how a single synthdriver is supposed to support 
multiple sysex specs (even if they are very alike). One problem is that 
it appears that it's possible to specify only one sysexID string in your 
subclass of Device.... and the various V-Amp's almost certainly have 
different ID strings that they respond with.

Rib Rdb and I recently discussed an idea which would enable a 
synthdriver to enumerate several different hardware devices it could 
talk to.... but everybody here seems pretty averse to even making minor 
changes to the API.

So, it looks like you might have to just copy the entire V-Amp 
synthdriver to another package and alter it for the Bass V-Amp. If you 
can make it so that it works with the Bass V-Amp and the Bass V-Amp 2.0, 
make sure you put that in the description (like "Bass V-Amp (1 and 2)" 
or "Bass V-Amp & Bass V-Amp 2.0"). As a user, I know that, if I had a 
Bass V-Amp and I only saw an entry for "V-Amp 2.0", I'd be unsure as to 
whether the driver would work for my device.

- Joe

[Jsynthlib-devel] Behringer Bass V-Amp

[<mar...@gm...>]

Hi,

I just bought a Behringer Bass V-Amp 2 and I would like to write
the driver.
After checking JSynthLib sources out from CVS, I found that there's
(preliminary?) support for a Behringer V-Amp, but it appears to be the
guitar version.
Then, after digging in the list archives, I found a message from Joe
Emenaker about writing the drivers for the Bass V-Amp.
(http://sourceforge.net/mailarchive/message.php?msg_id=3D10985717)

So, what's the status of existing V-Amp driver?
Guitar V-Amp and Bass V-Amp have very similar SysEx specs,
so I guess the existing code can be reused for the Bass driver.

Cheers,


--=20
Manuel Aristar=E1n <mar...@gm...>
http://jazzido.freezope.org/jazzido
Buenos Aires, Argentina

[Jsynthlib-devel] Different patch numbers for different banks.

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

Okay... I'm stuck again.

I've got a device (Digitech Studio 400.... thanks for the tip Joachim!) 
that has a different number of patches in the user bank than in the 
factory bank. However, the Driver subclass only specifies a 
1-dimensional array for patchNumbers.... so you apparently get the same 
patchNumbers array no matter what bank you want to work with.

Am I missing something here? If not, what are peoples' thoughts about 
adding support for a two-dimensional array for patchNumbers?

- Joe

[Jsynthlib-devel] Re: Wiki

[Mikael K. <alc...@gm...>]

Hi! :)

I think that's a good Idea. In particular if it is kept up-to-date. :)
At least the time when I implemented the Roland GP-16 guitar processor
patch editor was a time of quick change.

Also some programming guidelines would be nice, such as coding style,
should I program agains latest stable or CVS... This would surely have
saved considerable work at least in my case. :)

In any case, thank you all for a very nice program! :)

Mikael


On 4/27/05, Joe Emenaker <jo...@em...> wrote:
> Would it be possible to get a Wiki on the JSL website for us to share
> programming notes? As I gradually learn more and more about how the
> various pieces of JSL work, I'd like to be able to put my notes
> somewhere so that nobody else has to go through this again.
>=20
> If Brian's too busy, I can put one up on my website. I just wanted to
> take a shot at having it on the main JSL site.
>=20
> - Joe
>=20
>

[Jsynthlib-devel] Wiki

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

Would it be possible to get a Wiki on the JSL website for us to share
programming notes? As I gradually learn more and more about how the
various pieces of JSL work, I'd like to be able to put my notes
somewhere so that nobody else has to go through this again.

If Brian's too busy, I can put one up on my website. I just wanted to
take a shot at having it on the main JSL site.

- Joe

[Jsynthlib-devel] Extremely wierd behavior

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

I wrote a "HexDumpEditorFrame" which is useful for checking the contents
of your sysex patches before you start working on the editor. It doesn't
allow any *editing*; it just does a hex dump to a textarea. Since it's
pretty generic, I've put it in synthdrivers.Generic. So, to get a quick
look at your patch data, you just add

    protected JSLFrame editPatch(Patch p) {
            return (new synthdrivers.Generic.HexDumpEditorFrame(p));
    }

to your driver. Then, when you try to "Edit..." the patch, you get the
hex dump.

But here's the *really* wierd part. Whenever I use "Edit..." on one of
my patches, JSL appears to *send* the sysex out the midi interface. I've
tracked this down to the core.Actions.Worker.run() method. In that
method, is the following code:

        try {
            JSLFrame frm =
            getSelectedFrame().editSelectedPatch();
            if (frm != null) {
                PatchEdit.getDesktop().add(frm);
                frm.moveToDefaultLocation();
            frm.setVisible(true);

when     frm.setVisible(true)   is run, JSL *sends* the sysex data. But
this should just display the JSLFrame, no?

This has me totally baffled.

- Joe

[Jsynthlib-devel] Odd behavior...

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

This is a little strange.

I wanted to capture a sysex dump from a device that I don't know the 
dump format for.

When I try to capture it with the current JSL, this causes an exception 
createPatches (I think is its name) because chooseDriver returns a null 
because it doesn't find any driver which returns true for acceptsPatch. 
So, I altered my copy of the Generic Device so that it always returns 
true for acceptsPatch.

This is where things got strange.

The next time I ran JSL and loaded a library, the patches that were 
already *in* the library were no unrecognized and the comment fields now 
had entries which said "Probably a Roland..." and "Probably a 
Alesis...", etc. Question #1: Is this behavior intentional when more 
than one driver accepts a patch? Shouldn't there be some kind of 
"priority level" to help JSL pick one?

Next, when I removed the always-true acceptsPatch method from Generic 
Device, the "Probably a Roland.." comments *remained* in the comment 
fields. Don't we want them to disappear when the problem does?

- Joe