jsynthlib-devel Mailing List for JSynthLib (Page 39)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> Does the mailing list handle attachments???

Yes, e.g. federico has attached his MKS-7 code 2 days ago.

Regards,
J.Backhaus

--- Joachim Backhaus <jba...@pi...>
wrote:
> And it would at least be very helpful for me and I
> hope also
> for others if you can draw an image or something
> like that
> with your GUI suggestions for improvement and post
> it here.

Does the mailing list handle attachments???

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

Joachim Backhaus wrote:

>By the way: It would be helpful if you don't ask questions
>first and then explain your real intention a few mails
>afterwards. It would speed up the process if you come
>in with your intention first. ;)
>  
>
Point taken.

However, there are two reasons why I try to ask questions first.

The first reason is because I'm not familiar enough with it to know if 
it even *does* certain things or why. So I ask.... "Is this the way my 
Device is supposed to interact with JSL?", or "Why do Driver classes 
have to deal with the leading/trailing F0/F7 at all?". Granted, I 
haven't asked those exact questions, but that's sometimes the spirit in 
which I'm asking.

The second reason I ask them is that I sometimes have serious doubts 
about some piece of JSL structure. I know how *I* would do it if I were 
coding that piece from scratch, but the way that it *is* coded might be 
just as (if not more) flexible or it might be *necessary* for a certain 
task that JSL needs to do. So, rather than come right out and proclaim a 
certain portion of the code to be "screwed up", I think that the least I 
can do is to give other developers a chance to explain the reason the 
code needed to be or should be the way that it is.

It's only when they don't provide me with a convicing argument when I 
suggest an alternative. :)

>And it would at least be very helpful for me and I hope also
>for others if you can draw an image or something like that
>with your GUI suggestions for improvement and post it here.
>  
>
Well, you can look at 
http://www.midiquestxl.com/images/MQ9/MQ9.1280x1024.jpg and kinda see 
how the synths are all arranged in one window and then all of the things 
you can mess with on each of those items is shown grouped with that synth.

Also, I'm not a very good artist, so the drawings wouldn't be very exciting.

Lastly, I wasn't (and still am not) certain that there's even a 
readiness to discuss a different interface.

>OK, I must admit that I at least didn't really understand
>what you really want to improve on the JSynthLib GUI.
>  
>
I just think that a lot of it is unintuitive. There are a lot of windows 
that the user sees that they don't need to.... there are some that they 
should see but don't, and the overall UI interaction, although I agree 
that it can be learned, is not very natural.

Here, look at MidiQuest again: 
http://www.squest.com/Windows/Instruments/nanopno/Patch.GIF

Now, don't worry about the fact that it's more pretty. Notice the 
"flow". You open your Alesis NanoPiano and you get to see all of the 
categories you can adjust on it. If you select a bank, then... to the 
right, you see the patch layout for that bank. If you select a patch 
within the bank, again...to the right, you see the editor for the patch.

Look at this one: http://www.squest.com/Windows/Instruments/vfx/Preset.GIF

Again, you open that device and you see all of the things you can do to 
that device.... and the flow is always from the left, where it's more 
general, to the right where it's more specific and detailed. The nice 
thing about it is that there are already several things that the user 
already does that behave this way. The Windows Explorer looks like this 
sometimes, with folders on the left and the contents of the folder on 
the right.

Look at http://www.squest.com/Windows/Instruments/specfilt/Patch.GIF   
...and then tell me that you'd actually have to read the *manual* to 
know how to operate it.

In that light, I think it's safe to say that anybody who currently 
chooses to use JSL over something like MidiQuest is probably because 
it's free. And the primary alure of one's product being the fact that 
you're giving it away isn't exactly a flattering testament.

- Joe

Hi Steven,

it may be helpful if you can post your code
for retrieving the patch and for storing the patch.

> Yes, but I'm not sure what you mean by Bank E, Patch 9 is=20
> correct.  That=20
> *is* where it gets saved.

Yes, but is that correct? Is it what you want?
Or do you want to have it saved to Bank G, Patch 10?

How have you created the patch numbers?

Regards,
Joachim Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: Steven Schmidt [mailto:ste...@co...]
> Gesendet: Dienstag, 8. M=E4rz 2005 20:23
> An: Joachim Backhaus
> Cc: JSynthLib Development
> Betreff: Re: AW: [Jsynthlib-devel] BankDriver requests
>=20
>=20
> Joachim Backhaus wrote:
>=20
> >>From JSL, I select new library.  From 'unsaved library', I select=20
> >>Patch->get.  From that dialog, I choose Bank A, patch 27. =20
> Patch A-27 is=20
> >>retrieved.
> >>I highlight the patch and select 'store'.  From=20
> >>the dialog I=20
> >>select Bank E, patch 9.  Patch 10 from Bank G gets stored=20
> at Bank E,=20
> >>patch 9.
> >>   =20
> >>
> >
> >Do I understand that right?
> >Instead of "Bank A, Patch 27" "Bank G, Patch 10" is saved.
> >But the position "Bank E, Patch 9" to save to is correct?
> > =20
> >
> Yes, but I'm not sure what you mean by Bank E, Patch 9 is=20
> correct.  That=20
> *is* where it gets saved.
>=20
> >What happens if you retrieve Patch 28 instead of 27 of Bank A
> >and try to save it to "Bank E, Patch 9"?
> > =20
> >
> It still saves Patch 10 bank G to "Bank E, Patch 9" - in=20
> other words -=20
> Bank G and (requested store location) patchNum + 1.  If I try to save=20
> whatever to E-20 it will copy G-21 to E-20.
>=20
> >Do the patch numbers of the Korg Triton start with 0 or with 1?
> > =20
> >
> They start with a 0
>=20
> >If it always grabs the GM patch then your request method is=20
> simmply not correct.
> >
> I'm looking into that.  It must be that I'm telling it to do=20
> what it's=20
> doing, right?  I do wish the Midi Implementation for my synth was a=20
> little easier to understand.  Slowly but surely though, I am making=20
> progress.=20
> -Steve
>=20
>=20
>=20

> You mean *other* than the fact that they're already in=20
> javax.sound.midi?
> javax.sound.midi.SysexMessage.SYSTEM_EXCLUSIVE
> javax.sound.midi.ShortMessage.END_OF_EXCLUSIVE

Damn, that's a good point.
Didn't know that.

I'm not a native english speaker so please excuse if I'm
writing in an offensive style.
That's just my bad english.

By the way: It would be helpful if you don't ask questions
first and then explain your real intention a few mails
afterwards. It would speed up the process if you come
in with your intention first. ;)

E.g. with GUI style thing.

And it would at least be very helpful for me and I hope also
for others if you can draw an image or something like that
with your GUI suggestions for improvement and post it here.

I mean you can write tons of text explaining what you mean
and at the end it may still not be clear to everyone.
That's the point at which a visualisation of your ideas
will make it quick and easy to understand.=20

OK, I must admit that I at least didn't really understand
what you really want to improve on the JSynthLib GUI.

Regards,
Joachim Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von Joe
> Emenaker
> Gesendet: Mittwoch, 9. M=E4rz 2005 01:26
> An: JSynthLib Development
> Betreff: Re: AW: [Jsynthlib-devel] Okay... so why can't I edit a patch
> with this?
>=20
>=20
> Joachim Backhaus wrote:
>=20
> >But independet of that I suggest to have constants for the=20
> start and end byte.
> >
> >Like:
> >public static final byte SYSEX_START_BYTE		=09
> =3D (byte) 0xF0;
> >public static final byte SYSEX_END_BYTE		=09
> =3D (byte) 0xF7;
> >
> >I have included them in my synth driver constants classes=20
> which means reduncancy.
> >
> >Does something speak against including them in the=20
> core/Constants class?
> > =20
> >
> You mean *other* than the fact that they're already in=20
> javax.sound.midi?
> javax.sound.midi.SysexMessage.SYSTEM_EXCLUSIVE
> javax.sound.midi.ShortMessage.END_OF_EXCLUSIVE
>=20
> - Joe
>=20

Hi,

you can only use anonymous access to CVS
as you are not a project developer:

"Anonymous CVS Access

This project's SourceForge.net CVS repository can be checked out through =
anonymous (pserver) CVS with the following instruction set. The module =
you wish to check out must be specified as the modulename. When prompted =
for a password for anonymous, simply press the Enter key. To determine =
the names of the modules created by this project, you may examine their =
CVS repository via the provided web-based CVS repository viewer.

cvs -d:pserver:ano...@cv...:/cvsroot/jsynthlib login
=20
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/jsynthlib co =
-P modulename

Information about accessing this CVS repository may be found in our =
document titled, "Basic Introduction to CVS and SourceForge.net (SF.net) =
Project CVS Services".

Updates from within the module's directory do not need the -d parameter.

NOTE: UNIX file and directory names are case sensitive. The path to the =
project CVSROOT must be specified using lowercase characters (i.e. =
/cvsroot/jsynthlib)"

Regards,
Joachim Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: federico [mailto:xa...@in...]
> Gesendet: Dienstag, 8. M=E4rz 2005 19:03
> An: Joachim Backhaus; jsynthlib-list
> Betreff: Re: AW: [Jsynthlib-devel] RolandMKS7 Driver+Editor
>=20
>=20
> Joachim Backhaus wrote:
>=20
> >>btw: how to get a cvs account?
> >>why don't add a CVS section in the documentation, to explain=20
> >>how to get=20
> >>an account and check in a driver?
> >>   =20
> >>
> >
> >Because SourceForge already explains that:
> >http://sourceforge.net/cvs/?group_id=3D41208
> > =20
> >
>=20
> i just signed up to sf.net,
> but i quickly run in trouble with cvs:
>=20
>  xaero@giove JSynthLib $ export CVS_RSH=3Dssh
>  xaero@giove JSynthLib $ cvs -z3=20
> -d:ext:fed...@cv...:/cvsroot/jsynthlib
> co -P synthdrivers/RolandMKS7
> fed...@cv...'s password:
> Permission denied, please try again.
>=20
> what i am doing wrong?
> i issued correct commands?
> in that case maybe i have to wait some hour...
>=20

Steven> Why use the terms Bank(n) Slider(n) as tooltips in Editor screens?  
Steven> Shouldn't banks just be Sybth banks, not Banks of parameters?  Its a bit 
Steven> confusing.

I agree with you.  I've fixed. Now the tooltips says "Fader Bank xx ...".
-- 
Hiroo Hayashi

Brian wrote:

> Yes. I can see the teminology being confusing .Its not refering to 
> "Banks of Patches" but "Fader Banks" 

Talk about confusing, is it just my bad luck, or is the Midi 
implementation document I downloaded from Korg only as inaccurate as 
most others?  As I add controls to my editor, I'm finding that the table 
is close but definately wrong in several places.  Patches retrieved from 
the Triton are all 627 bytes, so I'm hoping that once I get through 
mapping one patch accurately, they will all work.  Am I just deluded?

Joachim Backhaus wrote:

>But independet of that I suggest to have constants for the start and end byte.
>
>Like:
>public static final byte SYSEX_START_BYTE			= (byte) 0xF0;
>public static final byte SYSEX_END_BYTE			= (byte) 0xF7;
>
>I have included them in my synth driver constants classes which means reduncancy.
>
>Does something speak against including them in the core/Constants class?
>  
>
You mean *other* than the fact that they're already in javax.sound.midi?
javax.sound.midi.SysexMessage.SYSTEM_EXCLUSIVE
javax.sound.midi.ShortMessage.END_OF_EXCLUSIVE

- Joe

Brian wrote:

>>
>> So... what happens if the world, someday, comes up with MIDI2 with 
>> some new sysex begin/end bytes instead of F0/F7? We go back and 
>> rewrite all of the drivers?
>
> No. That would be unnecessary. Even if someday MIDI2 comes out, all 
> existing synths will still be using MIDI1, so all existing drivers 
> will work fine.

Well, imagine if MOTU then came out with a MIDI2 version of their 
MidiExpress split/merge box.... and you've got all of your synths 
plugged into that. Suppose, also, that the box had a "feature" that 
reformatted all old-style sysex messages into newfangled (ie, using 
something other than F0/F7) new-style ones. Then, you'd have legacy JSL 
drivers receiving patches from legacy hardware... but with new-style 
messages coming into JSL.

Granted... it's a *completely* contrived scenario... and it will 
probably *never* happen. But my point is this: sysex is a *transfer* 
protocol. It's a way of getting a data payload between two devices. 
Drivers should concern themselves with the payload, not with how it 
arrived.... because it causes unnecessary work for everybody and it 
makes it hard to adapt to future protocols. If it came in by midi (with 
F0/F7) or my carrier-pigeon or through morse-code on a telegraph, most 
drivers don't need to see the F0 and F7.

For a real-world example, tell me how many of JSL's current synthdrivers 
set their "sysexID" variable to a string that does NOT begin with "F0"? 
I haven't stumbled across any yet. In fact, how many deviate from the 
"[F0][ManufacturerID][DeviceID][payload][F7]" format? Every device I 
currently own conforms to this message style. Yet, every JSL driver has 
to manually craft sysex messages itself. How many of the current 
drivers, do you estimate, all have an, essentially, identical bit of 
code in createNewPatch which takes the data of the patch and just slaps 
the F0 and the manuf and device ID's on the beginning and the F7 on the end?

> ... we ran into problems with some synths that would send dumps like 
> this:
>
> <JSynthLib sends Request Dump Message>
>
> Symth Sends Back:
>
> C0 0 0 FF FE F0 .  .  .  .F7 FE FE C0 0 0, etc.
>
> If we treat the entire string as a patch and save it, when we try to 
> load it back to the synth, the synth will not understand it.
> We have to extract the "Sysex" part of the midi stream from the rest 
> of the stream.

Right! JSL asked for a sysex message, and that's all that it grabs off 
of the wires. What I'm getting at is that, a vast majority of the time, 
JSL might as well lop the F0 and the F7 and give the driver the stuff 
inside.

Well... getting back to my original problem, it turns out that the 
reason I couldn't edit the patch was exactly the reason most people 
suggested: the sysex message that I made in createNewPatch didn't match 
what I set sysexID to. Since I, personally, don't anticipate ever 
writing a driver that creates patches that it doesn't recognize (duh!), 
I don't see a reason why createNewPatch shouldn't use sysexID as the 
header of the sysex message in the patch. That way, it would be 
impossible to create a patch that didn't get an affirmative response 
from acceptsPatch() (or whatever that method is).

What I ultimately did is made a subclass of Driver called LDDriver that 
just lets me set the manufacturerID and deviceID strings. Then, my 
*real* driver is a subclass of *that*, which only worries about the 
actual payload of the sysex message. When createNewPatch() is called in 
LDDriver, it gets the data payload from the subclass, an then slaps the 
F0, the manufID, and devID on the front and the F7 on the end. 
editPatch() will strip the same stuff *off* before passing it on to the 
subclass. So now... the actual driver subclass merely sets the manufID 
and devID in the constructor and then just worries about the data payload.

Why am I telling you this? I'm not sure. I doubt anybody else is going 
to use it because it's not the established JSL way. I guess I'm just 
hoping that somebody else will see that doing it this way is A) simpler 
and less prone to mistakes, and B) applicable to probably 75% or more of 
the devices we'll come across (and the remaining 25% are still free to 
use subclass Driver directly).

Anyway... the nice doctors with their scalpels are at the door now, so 
I'll stop complaining and conform now..

- Joe

doh!
bit7 	HI START OFFSET 	0:OFF, 1:ON 	
	02,02 	
------ 	
------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------
230 bit6 	HI REVERSE 	0:OFF, 1:ON 	
	02,03 	
------ 	
------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------
b0~~6 	HI SAMPLE NO.(MSB)

Steven Schmidt wrote:

> 231     HI SAMPLE NO.(LSB) How do you interpret this?  The value is 
> dec 306  but it must be only 1 byte.
>

231     HI SAMPLE NO.(LSB) 
 How do you interpret this?  The value is dec 306  but it must be only 1 
byte.

Yes. I can see the teminology being confusing .Its not refering to 
"Banks of Patches" but "Fader Banks"
JSynthLib lets you use a controller surface, which is a midi device with 
lots of sliders on it, to control the editors on screen.
For example, you would move fader (slider) 4 on your controller surface 
and the onscreen slider Bank 0 Slider 4 would move with you.
Since you usually have more faders in an editor than on your controller 
surface, the faders are split into banks which can be changed
using the arrows on the tool bar. It should probably say something like 
Fader Bank (n) Slider 3, and also should only be enabled
if you enable fader's in the preference window.

Brian

Steven Schmidt wrote:

> Why use the terms Bank(n) Slider(n) as tooltips in Editor screens?  
> Shouldn't banks just be Sybth banks, not Banks of parameters?  Its a 
> bit confusing.
>
>
>
> -------------------------------------------------------
> 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
>
>

Why use the terms Bank(n) Slider(n) as tooltips in Editor screens?  
Shouldn't banks just be Sybth banks, not Banks of parameters?  Its a bit 
confusing.

Joachim Backhaus wrote:

>>From JSL, I select new library.  From 'unsaved library', I select 
>>Patch->get.  From that dialog, I choose Bank A, patch 27.  Patch A-27 is 
>>retrieved.
>>I highlight the patch and select 'store'.  From 
>>the dialog I 
>>select Bank E, patch 9.  Patch 10 from Bank G gets stored at Bank E, 
>>patch 9.
>>    
>>
>
>Do I understand that right?
>Instead of "Bank A, Patch 27" "Bank G, Patch 10" is saved.
>But the position "Bank E, Patch 9" to save to is correct?
>  
>
Yes, but I'm not sure what you mean by Bank E, Patch 9 is correct.  That 
*is* where it gets saved.

>What happens if you retrieve Patch 28 instead of 27 of Bank A
>and try to save it to "Bank E, Patch 9"?
>  
>
It still saves Patch 10 bank G to "Bank E, Patch 9" - in other words - 
Bank G and (requested store location) patchNum + 1.  If I try to save 
whatever to E-20 it will copy G-21 to E-20.

>Do the patch numbers of the Korg Triton start with 0 or with 1?
>  
>
They start with a 0

>If it always grabs the GM patch then your request method is simmply not correct.
>
I'm looking into that.  It must be that I'm telling it to do what it's 
doing, right?  I do wish the Midi Implementation for my synth was a 
little easier to understand.  Slowly but surely though, I am making 
progress. 
-Steve

Joachim Backhaus wrote:

>>btw: how to get a cvs account?
>>why don't add a CVS section in the documentation, to explain 
>>how to get 
>>an account and check in a driver?
>>    
>>
>
>Because SourceForge already explains that:
>http://sourceforge.net/cvs/?group_id=41208
>  
>

i just signed up to sf.net,
but i quickly run in trouble with cvs:

 xaero@giove JSynthLib $ export CVS_RSH=ssh
 xaero@giove JSynthLib $ cvs -z3 
-d:ext:fed...@cv...:/cvsroot/jsynthlib
co -P synthdrivers/RolandMKS7
fed...@cv...'s password:
Permission denied, please try again.

what i am doing wrong?
i issued correct commands?
in that case maybe i have to wait some hour...

> btw: how to get a cvs account?
> why don't add a CVS section in the documentation, to explain=20
> how to get=20
> an account and check in a driver?

Because SourceForge already explains that:
http://sourceforge.net/cvs/?group_id=3D41208

Check in works only if you are a project developer.

Regards,
Joachim Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von
> federico
> Gesendet: Dienstag, 8. M=E4rz 2005 18:39
> An: Bill Zwicky; jsynthlib-list
> Betreff: Re: [Jsynthlib-devel] RolandMKS7 Driver+Editor
>=20
>=20
> Bill Zwicky wrote:
>=20
> > I checked this in for Federico, I hope noone minds.  Federico, we'd=20
> > appreciate it if you'd update from CVS to make sure your files got=20
> > there safely.
> >
> uhm... i really have no experience in CVS (except checking=20
> out sources &=20
> compiling, following the famous three steps)
>=20
> btw: how to get a cvs account?
> why don't add a CVS section in the documentation, to explain=20
> how to get=20
> an account and check in a driver?
>=20
> thanks
>=20
> --=20
> Federico
>=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

Bill Zwicky wrote:

> I checked this in for Federico, I hope noone minds.  Federico, we'd 
> appreciate it if you'd update from CVS to make sure your files got 
> there safely.
>
uhm... i really have no experience in CVS (except checking out sources & 
compiling, following the famous three steps)

btw: how to get a cvs account?
why don't add a CVS section in the documentation, to explain how to get 
an account and check in a driver?

thanks

-- 
Federico

>
> So... what happens if the world, someday, comes up with MIDI2 with 
> some new sysex begin/end bytes instead of F0/F7? We go back and 
> rewrite all of the drivers?

No. That would be unnecessary. Even if someday MIDI2 comes out, all 
existing synths will still be using MIDI1, so all existing drivers will 
work fine. At that time,
we would merely have to code in MIDI2 support so that new drivers could 
be written for new synths. Existing drivers would not change.

Please keep in mind that we've been developing JSynthLib for five years 
now. It may not always be clear why the code works the way it does, but 
It was put that way
by someone intentionally to work around various issues that arose. In 
this case, the origional code did not insist on F0...F7, and we ran into 
problems with some synths that
would send dumps like this:

<JSynthLib sends Request Dump Message>

Symth Sends Back:

C0 0 0 FF FE F0 .  .  .  .F7 FE FE C0 0 0, etc.

If we treat the entire string as a patch and save it, when we try to 
load it back to the synth, the synth will not understand it.
We have to extract the "Sysex" part of the midi stream from the rest of 
the stream. Many synths send active sensing messages constantly.
Others will sporadically send controller messages in response to the 
slightest vibrations in the room. And of course, you always have the user
accidently hitting a key on the synth during the dump. Extracting only 
system exclusive messages is important in getting clear and proper data
from a synth. I'd be surprised if Sounddiver didn't do something 
similar. It's a feature, not a bug :)

Brian

jsy...@li... wrote:

> 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

All source files contain the GPL copyright notice and are ready  to 
merge into the JSynthLib distribution. They should replace the previous 
version.
http://electrickery.xs4all.nl/digaud/mt32

Fred Jan Kraan

> So... what happens if the world, someday, comes up with MIDI2=20
> with some=20
> new sysex begin/end bytes instead of F0/F7? We go back and=20
> rewrite all=20
> of the drivers?

Sorry, but that's absolute nonsense!
The MIDI specs are programmed into the ROM of most of
the synths so they cannot be changed.

But independet of that I suggest to have constants
for the start and end byte.

Like:
public static final byte SYSEX_START_BYTE			=3D (byte) 0xF0;
public static final byte SYSEX_END_BYTE			=3D (byte) 0xF7;

I have included them in my synth driver constants classes which means
reduncancy.

Does something speak against including them in the core/Constants class?

This would also mean that we could remove the following code
from the core/SysexMatcher class:
public final byte F7 =3D (byte)0xF7;
public final byte F0 =3D (byte)0xF0;

I think the naming is confusing as the name contains
already the value.

Regards,
Joachim Backhaus

Hi,

the source says:

...
 * Use SysexHandler.NameValue instead of this class. This class exists =
only for
 * backward compatibility.
 * @deprecated Use SysexHandler.NameValue instead of this class.
...

So I think it can be easily removed if no class uses
it anymore.

Regards,
J. Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von Rib
> Rdb
> Gesendet: Sonntag, 6. M=E4rz 2005 03:30
> An: JSynthLib Development
> Betreff: [Jsynthlib-devel] NameValue.java
>=20
>=20
> NameValue doesn't seem to be used anywhere.  Should we remove it?
>=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

> From JSL, I select new library.  From 'unsaved library', I select=20
> Patch->get.  From that dialog, I choose Bank A, patch 27.  Patch A-27 =
is=20
> retrieved.
> I highlight the patch and select 'store'.  From=20
> the dialog I=20
> select Bank E, patch 9.  Patch 10 from Bank G gets stored at Bank E,=20
> patch 9.

Do I understand that right?
Instead of "Bank A, Patch 27" "Bank G, Patch 10" is saved.
But the position "Bank E, Patch 9" to save to is correct?

What happens if you retrieve Patch 28 instead of 27 of Bank A
and try to save it to "Bank E, Patch 9"?

Steven> Whoops - spoke to soon.  I can request any patch from the synth =
and save=20
Steven> it in a patchlib, but when I try to store a patch from a =
patchlib to the=20
Steven> synth, it grabs the GM patch (bank G) at patchNum + 1 and saves =
it to=20
Steven> the bank I specified.

Ok, now it sounds like a "0 to 127" vs. "1 - 128" problem.

Do the patch numbers of the Korg Triton start with 0 or with 1?

If it always grabs the GM patch then your request method is simmply not =
correct.
Perhaps you just have to set the correct bank in the sysex bytes.

Regards,
J. Backhaus

Bill Zwicky wrote:

> Hmm .. my guess is JSL can't recognize the patch you made.  A patch is 
> expected to be a full sysex message by itself

... even though the patch never appeared on any midi interface? Am I the 
only one who sees this as odd?

> So try copying the sysexID bytes to the beginning, and F7 at the end.

So... what happens if the world, someday, comes up with MIDI2 with some 
new sysex begin/end bytes instead of F0/F7? We go back and rewrite all 
of the drivers?

- Joe

Joe,

Once the patch has been created by createNewPatch() and is sitting in your
library, does JSynthLib mark it as belonging to the AlesisSR16 Device?
If not, it
is being assigned to the "Generic Device" which provides no editing support.

SynthDrivers use the SysexID to determine whether or not they support
a given patch.
After being created, the patch gets inserted into the library, at
which point JSynthLib
will ask each driver in turn whether they want to be associated with
it. If no-one volunteers, the Generic Device driver gets it.

This is necessary, for example if a patch is imported from disk, there
is no knowledge
of who created him, plus many synths are compatable so as long as you
have one of the synths loaded that can support the patch, it will be
correctly assigned.

My guess is that the SysexID for HexDumpDriver is not matching the patch you are
creating. Try putting a proper header on the patch so that your driver
gets associated
with the patch. This should unshade the "Edit" option.

Brian

2004	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (90)	Sep (38)	Oct (22)	Nov (3)	Dec (13)
2005	Jan (40)	Feb (119)	Mar (236)	Apr (41)	May (45)	Jun (10)	Jul (9)	Aug (12)	Sep (5)	Oct (17)	Nov (2)	Dec (3)
2006	Jan (23)	Feb (36)	Mar (49)	Apr	May	Jun (1)	Jul (11)	Aug (11)	Sep (15)	Oct (30)	Nov (36)	Dec (13)
2007	Jan	Feb (1)	Mar	Apr (1)	May (3)	Jun (7)	Jul (4)	Aug (1)	Sep (19)	Oct (1)	Nov (2)	Dec (5)
2008	Jan	Feb (2)	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct (4)	Nov (5)	Dec
2009	Jan (26)	Feb	Mar	Apr	May	Jun	Jul	Aug (26)	Sep (6)	Oct (5)	Nov (6)	Dec (6)
2010	Jan (3)	Feb	Mar (5)	Apr	May (1)	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar	Apr (2)	May	Jun	Jul (6)	Aug (8)	Sep (220)	Oct (9)	Nov (27)	Dec (33)
2012	Jan	Feb (4)	Mar (9)	Apr	May	Jun (1)	Jul	Aug	Sep	Oct (4)	Nov	Dec
2013	Jan (6)	Feb (20)	Mar (6)	Apr (3)	May (4)	Jun	Jul	Aug	Sep	Oct (17)	Nov (2)	Dec
2014	Jan (9)	Feb (1)	Mar (11)	Apr	May	Jun	Jul	Aug	Sep	Oct (2)	Nov	Dec (2)
2018	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

jsynthlib-devel Mailing List for JSynthLib (Page 39)

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