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

Re: [Jsynthlib-devel] Possible bug in Driver.java

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

Hiroo Hayashi wrote:

>As I wrote on comment, I think the lines after '// Maybe you don't get
>the expected patch.' are used only for programming error of a Driver.
>My take is to remove those lines and to show an error dialog to let users
>send a bug report to us.
>  
>
How about this, instead? Since it seems that JSL always has a generic
device driver in the list of synthdrivers, why not have
DriverUtil.chooseDriver return the Generic Driver if it can't find a
more-appropriate one?

- Joe

[Jsynthlib-devel] "Generic Device"

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

At the location I like to work on JSL drivers, I don't have access to 
the actual midi devices. So, it would be helpful if I could capture a 
sysex dump into JSL and then take my laptop somewhere else to work on 
the driver for it. This would also help when trying to reverse-engineer 
a sysex dump that you don't have a spec for.

I'd think that Generic Device is the driver to use for this, but I'm 
having trouble.

First, it seems that there's always a mandatory Generic Device in my 
synthdrivers list, but it's not available in the drop-down box when I 
try to "Get" a patch. If I add *another* Generic Device in my 
synthdriver list, the second one *does* show up in the "Get" drop-down box.

However, once I select Generic Device in the "Get" dialog box, I get an 
exception because patchNumbers is null.

Amy I trying to use Generic Device contrary to how it was intended? Or 
has it fallen into disrepair?

- Joe

AW: [Jsynthlib-devel] Special handling of changing DeviceID or Channel on a device?

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

Hello,

IMHO it should not be possible to set the channel
with an editor.

1. It means redundancy, as you set them in the preferences
dialog.
2. The problems you have listed occur.

Regards,
Joachim=20

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von Joe
> Emenaker
> Gesendet: Donnerstag, 14. April 2005 10:27
> An: JSynthLib Development
> Betreff: [Jsynthlib-devel] Special handling of changing DeviceID or
> Channel on a device?
>=20
>=20
> On many synths, you can send a sysex message which will=20
> change the midi=20
> channel and/or deviceID it uses for sysex communication.
>=20
> Obviously, this can cause problems if you change the channel of the=20
> physical device with a JSL editor and then forget to change=20
> the channel=20
> in your synth properties in JSL.
>=20
> It seems to me that it might be useful if there was a special=20
> way that a=20
> synthdriver could notify JSL that it just changed the deviceID and/or=20
> basic-channel of the physical device.
>=20
> I'm not saying that we need to do this *right now*. I'm just=20
> asking if=20
> anyone thinks that the ideal JSL application should have this=20
> feature.=20
> (or does JSL already do this?)
>=20
> - Joe
>=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] Special handling of changing DeviceID or Channel on a device?

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

On many synths, you can send a sysex message which will change the midi 
channel and/or deviceID it uses for sysex communication.

Obviously, this can cause problems if you change the channel of the 
physical device with a JSL editor and then forget to change the channel 
in your synth properties in JSL.

It seems to me that it might be useful if there was a special way that a 
synthdriver could notify JSL that it just changed the deviceID and/or 
basic-channel of the physical device.

I'm not saying that we need to do this *right now*. I'm just asking if 
anyone thinks that the ideal JSL application should have this feature. 
(or does JSL already do this?)

- Joe

Re: [Jsynthlib-devel] Virtual device consoles?

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

Joe,

I think what you are proposing is a generic fader controller. I vote for
your proposal.

Joe> Some of the sysex-capable devices I have define some sysex messages to 
Joe> let your emulate button-presses on the device itself. For example, 
Joe> sending a certain sysex command to the synth might make it behave as 
Joe> though you had just pressed the "bypass" button... or the cursor-left, 
Joe> or whatever.
Joe> 
Joe> What this would enable someone to do is to make a photo-realistic 
Joe> console on your PC... where you had an image of the device, and you 
Joe> could click on the buttons in the image and have them actually affect 
Joe> the real device. Of course, you wouln't have to make it photo-realistic. 
Joe> You could have a frame with a bunch of swing buttons in it which did the 
Joe> same thing.
Joe> 
Joe> Has there ever been any discussion or desire to do this with JSL? I 
Joe> guess you could do it with Senders, but... in this case, the buttons 
Joe> you're pressing don't necessarily cause any changes to a patch (like 
Joe> with cursor movement... or bypass... or panic), so it might not be 
Joe> entirely correct to put something like this in an Editor. Maybe there 
Joe> could be a ConsoleDriver or VirtualConsole class or something.
Joe> 
Joe> Does this concept appeal to anybody else? Or should I just forget it?
Joe> 
Joe> - Joe
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Nomenclature

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

Hi Joe,

When I joined this project, there was no description about Device class
in programming.html.  I guess Device class was added after a term `synth
driver' was introduced.

I tried to use the following terminology when I updated programming.html.
If you see CVS log of the file, you will find most of changes are done
by non-native English writers.  Please clean up it.

Joe>  - The thing we write which subclasses Device?
   Device [class]

Joe>  - The things we write which subclass Driver and/or Editor?
   single Driver [class] and/or single editor
   bank Driver [class] and/or bank editor

Joe>  - The set of the previous two? ("synthdriver"?)
   synth driver

Joe>  - The actual hardware devices that JSL talks to? ("synths"? Even though 
Joe> it doesn't just talk to synths anymore?)
   MIDI device

Thanks.

On Sun, 03 Apr 2005 15:04:30 -0700
Joe Emenaker <jo...@em...> wrote:

Joe> (Sorry to throw all of the messages to the list at once. I've been 
Joe> wondering about some of them for a while, and I just got around to 
Joe> posting them all to the list. This is the last one....)
Joe> 
Joe> Is there a standard nomenclature to use when we're discussing things on 
Joe> the list?
Joe> 
Joe> For example, even though the main piece of a synthdriver package is 
Joe> something which subclasses "Device", I think some people refer to it as 
Joe> a "Driver", which could cause people to confuse it with things which 
Joe> sub-class Driver.
Joe> 
Joe> So, to clarify, what do we call:
Joe>  - The thing we write which subclasses Device?
Joe>  - The things we write which subclass Driver and/or Editor?
Joe>  - The set of the previous two? ("synthdriver"?)
Joe>  - The actual hardware devices that JSL talks to? ("synths"? Even though 
Joe> it doesn't just talk to synths anymore?)
Joe> 
Joe> - Joe
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Possible bug in Driver.java

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

Joe,

As I wrote on comment, I think the lines after '// Maybe you don't get
the expected path.' are used only for programming error of a Driver.
My take is to remove those lines and to show an error dialog to let users
send a bug report to us.

On Wed, 06 Apr 2005 17:04:05 +0000
Joe Emenaker <jo...@em...> wrote:

Joe> Around line 290 in Driver,java is the following method createPatches():
Joe> 
Joe> >    public IPatch[] createPatches(SysexMessage[] msgs) {
Joe> >         byte[] sysex = MidiUtil.sysexMessagesToByteArray(msgs);
Joe> >         IPatch[] patarray = DriverUtil.createPatches(sysex, getDevice());
Joe> >
Joe> >         // Maybe you don't get the expected patch!
Joe> >         // Check all devices/drivers again! Call fixpatch() if
Joe> > supportsPatch
Joe> >         // returns false.
Joe> >         // XXX Why don't we simply cause error? Hiroo
Joe> >         for (int k = 0; k < patarray.length; k++) {
Joe> >    ...
Joe> 
Joe> Due to a mistake on my part, I made a driver which didn't recognize the
Joe> sysex that I sent it. As a result, DriverUtil.createPatches() returned a
Joe> null which was then assigned to patarray[]. This caused an exception
Joe> when execution got to the patarray.length.
Joe> 
Joe> I didn't want to mess with this, since I didn't write it and I'm not
Joe> sure how it was intended to work.
Joe> 
Joe> Granted, it was a bug in my driver which exposed this bug.... but I
Joe> still think that this is a bug. It should handle this more gracefully.
Joe> What's the preferred behavior here? Should Driver.createPatches check
Joe> for a null patarray[], or should DriverUtil.createPatches be reworked so
Joe> as to guarantee that it never returns a null?
Joe> 
Joe> - Joe
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Request to make the export method public instead of public final

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

Hi,

What you need to override is Driver.sendPatch(Patch).  To make this
clear Driver.send(byte[]) is a final method.

Ton> I am working on a synth driver for the ADA MP2 midi guitar preamp.
Ton> It's is a rather old device with variable sized patches. Values greater
Ton> than 0x40 are preceded by a byte containing 0x41. Values greater than
Ton> 0x80, are two bytes long preceded by 0x42.
Ton> In order to get it working, I have to convert each patch to a fixed
Ton> size, in which each value is represented by exact one byte.
Ton> The only backdraw is that when I want to export the patch, it is in a
Ton> format only my synth driver can handle. When I want to send the exported
Ton> sysex with other software (like midiOx etc.) it is in the wrong format,
Ton> so my ADA MP2 can't handle it.
Ton> When the export method is changed from public final to public, I can
Ton> override it and write a conversion method to change the patch to the
Ton> right format.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Change to Utility.hexDump?

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

Joe> I'm adding a couple of methods to Utility to allow for the 
Joe> address/offset to be printed on the left side of the line, and for the 
Joe> equivalent characters to be printed on the right side (more like a 
Joe> conventional hex editor). This shouldn't affect any existing code.

That's good.

Joe> Also, hexDumpOneLine contained, essentially, two duplicates of code in 
Joe> hexDump, so I replaced it with two calls to hexDump. Again, this 
Joe> shouldn't affect anything, since the behavior seems to be unchanged.

I'm a man who doesn't like duplicates of code, too.  There might be a
reason I coun't not use two calls to hexDump.  I can not recall what I
did on the code at a glance.  But the following problem may be a reason,
but I'm not sure.

Joe> However, I noticed that hexDump, when creating multi-line dumps, 
Joe> prepends two spaces to lines after the first one. For example:
Joe>   0A 1E 7E ...
Joe>     ED A3 4F...
Joe>     BC F1 28...
Joe> 
Joe> Can I remove that indenting... or does someone need it for something?

Please fix the method as you need.

Thanks.
-- 
Hiroo Hayashi

[Jsynthlib-devel] Change to Utility.hexDump?

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

I'm adding a couple of methods to Utility to allow for the 
address/offset to be printed on the left side of the line, and for the 
equivalent characters to be printed on the right side (more like a 
conventional hex editor). This shouldn't affect any existing code.

Also, hexDumpOneLine contained, essentially, two duplicates of code in 
hexDump, so I replaced it with two calls to hexDump. Again, this 
shouldn't affect anything, since the behavior seems to be unchanged.

However, I noticed that hexDump, when creating multi-line dumps, 
prepends two spaces to lines after the first one. For example:
  0A 1E 7E ...
    ED A3 4F...
    BC F1 28...

Can I remove that indenting... or does someone need it for something?

- Joe

[Jsynthlib-devel] Need some music to play?

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

What's a synth without some MIDI to feed it?  This guy is scanning old 
piano rolls, and converting them to MIDI.  Currently 2650 songs 
available for download!

http://members.shaw.ca/smythe/archive.htm

There's a good open-source MIDI song editor over here:

http://www.jazzware.com/

-Bill

[Jsynthlib-devel] Possible bug in Driver.java

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

Around line 290 in Driver,java is the following method createPatches():

>    public IPatch[] createPatches(SysexMessage[] msgs) {
>         byte[] sysex = MidiUtil.sysexMessagesToByteArray(msgs);
>         IPatch[] patarray = DriverUtil.createPatches(sysex, getDevice());
>
>         // Maybe you don't get the expected patch!
>         // Check all devices/drivers again! Call fixpatch() if
> supportsPatch
>         // returns false.
>         // XXX Why don't we simply cause error? Hiroo
>         for (int k = 0; k < patarray.length; k++) {
>    ...

Due to a mistake on my part, I made a driver which didn't recognize the
sysex that I sent it. As a result, DriverUtil.createPatches() returned a
null which was then assigned to patarray[]. This caused an exception
when execution got to the patarray.length.

I didn't want to mess with this, since I didn't write it and I'm not
sure how it was intended to work.

Granted, it was a bug in my driver which exposed this bug.... but I
still think that this is a bug. It should handle this more gracefully.
What's the preferred behavior here? Should Driver.createPatches check
for a null patarray[], or should DriverUtil.createPatches be reworked so
as to guarantee that it never returns a null?

- Joe

[Jsynthlib-devel] Request to make the export method public instead of public final

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

Hi,

I am working on a synth driver for the ADA MP2 midi guitar preamp.
It's is a rather old device with variable sized patches. Values greater
than 0x40 are preceded by a byte containing 0x41. Values greater than
0x80, are two bytes long preceded by 0x42.
In order to get it working, I have to convert each patch to a fixed
size, in which each value is represented by exact one byte.
The only backdraw is that when I want to export the patch, it is in a
format only my synth driver can handle. When I want to send the exported
sysex with other software (like midiOx etc.) it is in the wrong format,
so my ADA MP2 can't handle it.
When the export method is changed from public final to public, I can
override it and write a conversion method to change the patch to the
right format.

Thanks in advance,

Ton Holsink

Re: [Jsynthlib-devel] Re: patchlib file format (was JSL 1.0 and 2.0)

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

Bill Zwicky wrote:

>> Why not just let the XML routines get a list of an editor's 
>> ParamModels? It should be able to learn everything it needs from that 
>> in order to generate the XML.  Keep in mind that one possible problem 
>> with not storing the original sysex data is that some parts of a 
>> sysex dump aren't spec'd and can't be changed. 
>
> Can ParamModels be grouped or nested?

If they can't, I think that they should. That way, you could create sets 
of ParamModels which depend upon other settings (ie, if 
Effect=="Flanger", then use ParamSetA, if Effect=="Chorus", use 
ParamSetB, etc.). But that's probably for a later discussion.

> Perhaps there needs to be a higher level element that describes a 
> "blank" sysex with these unchangable bits filled in.  Or alternately, 
> a constant, non-editable ParamModel that provides these bytes.

That's a thought. Something like ConstantParamModel or something.

>> Overall, I see this as being of marginal value. What's the point of 
>> editing the XML by hand? 
>
> *The* point of XML is data exchange and (to a lesser degree) 
> hand-editing.  If we don't need either feature, then why do we need to 
> change the save format at all?

I don't think that hand-editing was much of the idea. To me, XML's 
strength is the fact that its universal enough so that it's easy to get 
a parser for it, yet you can easily specify its format in a way that a 
universal parser can understand. A result of this is that you can alter 
the format in many ways which: 1) are compatible with previous formats 
of the XML files or your own code, and 2) don't require any modification 
of the parser.

For example, what if Brian, someday, decided that having a "Field1" and 
"Field2" was too limiting and wanted to add a "Field3"? Using the 
current format, I imagine that we'd have to alter our code to detect if 
we were reading an older format file and, if so, read it in the old way, 
etc. It could be done.... but it probably wouldn't be pleasant. On the 
other hand, if it were in XML, all we'd have to do is add a Field3 to 
the doctype-definition and then have our code look for it.

The *main* reason for changing the format seems to be that the current 
format uses serialization or something which is preventing us from 
moving the stuff in core.* into nice, separate packages. I'm guessing 
that there are also a few extra things that people would like to see 
added to the format but weren't worth changing the format for by 
themselves. Now, if we *do* change the format, my vote (and it seems the 
vote of many) is for XML. The reason *I* would like to use it is because 
it would be easy for use to ammend the format later without causing any 
upheaval.

- Joe

Re: [Jsynthlib-devel] Re: patchlib file format (was JSL 1.0 and 2.0)

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

> Then you either force all of the editor authors to also write XML 
> methods (and risking bugs each time), or you let some drivers save 
> their patches in binary format while others save in parameter format.

That's what I said.  By default, all drivers save as hex.  This would be 
built into JSL so that all drivers get it for free.  If someone 
specifically wants readable XML, then they code a driver to return 
Element[] instead of byte[].

Of course, I don't see any use for this either, but making it available 
would be easy.

> Why not just let the XML routines get a list of an editor's 
> ParamModels? It should be able to learn everything it needs from that 
> in order to generate the XML.  Keep in mind that one possible problem 
> with not storing the original sysex data is that some parts of a sysex 
> dump aren't spec'd and can't be changed. 

Can ParamModels be grouped or nested?  Otherwise the XML output would be 
a flat list of key-value pairs, which is perfectly reasonable.  Perhaps 
there needs to be a higher level element that describes a "blank" sysex 
with these unchangable bits filled in.  Or alternately, a constant, 
non-editable ParamModel that provides these bytes.

> Overall, I see this as being of marginal value. What's the point of 
> editing the XML by hand? 

*The* point of XML is data exchange and (to a lesser degree) 
hand-editing.  If we don't need either feature, then why do we need to 
change the save format at all?

-Bill

[Jsynthlib-devel] Nomenclature

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

(Sorry to throw all of the messages to the list at once. I've been 
wondering about some of them for a while, and I just got around to 
posting them all to the list. This is the last one....)

Is there a standard nomenclature to use when we're discussing things on 
the list?

For example, even though the main piece of a synthdriver package is 
something which subclasses "Device", I think some people refer to it as 
a "Driver", which could cause people to confuse it with things which 
sub-class Driver.

So, to clarify, what do we call:
 - The thing we write which subclasses Device?
 - The things we write which subclass Driver and/or Editor?
 - The set of the previous two? ("synthdriver"?)
 - The actual hardware devices that JSL talks to? ("synths"? Even though 
it doesn't just talk to synths anymore?)

- Joe

[Jsynthlib-devel] Dataspace overloading in Editors

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

Many sysex specifications use the same data locations to mean different 
things depending upon what other values are. For example, when the 
modulation effect is set to "Chorus", a certain location might be used 
to control the wet-mix and have valid values from 0 to 100. Or, when the 
effect is "Flanger", the same location might be used for the pre-delay, 
with valid values from 0 to 64.

I won't go into the variety of problems that this presents, since most 
of you already know. What I want to know is: Is there already a standard 
way of handling this in JSL which makes the coding go smoothly?

- Joe

[Jsynthlib-devel] Virtual device consoles?

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

Some of the sysex-capable devices I have define some sysex messages to 
let your emulate button-presses on the device itself. For example, 
sending a certain sysex command to the synth might make it behave as 
though you had just pressed the "bypass" button... or the cursor-left, 
or whatever.

What this would enable someone to do is to make a photo-realistic 
console on your PC... where you had an image of the device, and you 
could click on the buttons in the image and have them actually affect 
the real device. Of course, you wouln't have to make it photo-realistic. 
You could have a frame with a bunch of swing buttons in it which did the 
same thing.

Has there ever been any discussion or desire to do this with JSL? I 
guess you could do it with Senders, but... in this case, the buttons 
you're pressing don't necessarily cause any changes to a patch (like 
with cursor movement... or bypass... or panic), so it might not be 
entirely correct to put something like this in an Editor. Maybe there 
could be a ConsoleDriver or VirtualConsole class or something.

Does this concept appeal to anybody else? Or should I just forget it?

- Joe

Re: [Jsynthlib-devel] Re: patchlib file format (was JSL 1.0 and 2.0)

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

Bill Zwicky wrote:

> Joe Emenaker wrote:
>
>> Since the data encoding is something which pertains the using XML 
>> files, I think that the code for is should be in the XML routines and 
>> not in the Driver system.
>> I'm a little uneasy about the idea of having any XML-awareness in the 
>> synthdrivers.
>
> The idea is this:  What if someone wants to hand-edit patches ouside 
> of JSL?

Then maybe they shouldn't be using JSL. :P Seriously, though... someone 
would want to use JSL just to convert sysex into XML? I don't buy it.

> It's excessively difficult to edit the hex, but would be possible if 
> the patch data was itself a bunch of XML.  I don't know of any way to 
> automate this (unless we can leech off the XML editor stuff) but if we 
> leave it up to the driver, then anyone who needed it could update the 
> driver to create and parse it.

Then you either force all of the editor authors to also write XML 
methods (and risking bugs each time), or you let some drivers save their 
patches in binary format while others save in parameter format.

Why not just let the XML routines get a list of an editor's ParamModels? 
It should be able to learn everything it needs from that in order to 
generate the XML.

Keep in mind that one possible problem with not storing the original 
sysex data is that some parts of a sysex dump aren't spec'd and can't be 
changed. For example on the Alesis SR-16, there are lots of regular 
parameter locations. However, there are some places where the spec says 
"DON'T CARE" and, even worse, some that say "DON'T CHANGE". For these, a 
syntheditor author would probably just not bother to make a ParamModel 
for it. So, even letting the XML layer get a list of ParamModels has 
some problems.

Overall, I see this as being of marginal value. What's the point of 
editing the XML by hand? How would you send it back to the synth? You'd 
have to use JSL. The only reason, then, to avoid using a GUI editor is 
if JSL supported some kind of console-mode, where you could send patches 
to a synth from a command-prompt.... which means having command-line 
switches for midi channel and interface selection. Ugh. I really don't 
see it getting used nearly enough to justify the effort.

- Joe

Re: [Jsynthlib-devel] FW: Re: What is the JSL way to deal with negative param values?

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

Steven Schmidt wrote:

> Do you know of an existing editor that works in this manner?

What part is giving you trouble?  Are you familiar enough with binary 
and boolean math to work through this?  Here are some links with an 
excessive amount of detail:

http://mathforum.org/dr.math/faq/faq.bases.html
http://mathforum.org/library/drmath/view/54311.html
http://mathforum.org/library/drmath/sets/select/dm_twos_complement.html

The "twos complement" link is most relevant, as it explains how negative 
numbers work.  I can't find a good, decisive tutorial on binary math, 
but if you search around that site, you should be able to find answers.

Anyway, to answer your question, my own Casio CZ editor is reasonably 
similar.  You need to chop your numbers into 7-bit chunks, and the CZ 
works with 4-bit chunks.  The math is the same, only the constants 
differ. I've pulled all the code into a common superclass:
    synthdrivers/CasioCZ1000/CZModel.java

-Bill

Re: [Jsynthlib-devel] FW: Re: What is the JSL way to deal with negative param values?

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

Bill Zwicky wrote:

> Steven Schmidt wrote:
>
>> displays the correct value of -5 for the MSB/LSB combo of  7f 7b
>> (I haven't looked at why I had to subtact 128 (base val) to get it 
>> right, but that's a suspiciously even number)
>> So, have we a bug?  I'll try a slider and see if I have the same 
>> problem and report back.
>>
> Are the bytes still correct when the spinner reads -129?
>
> In a sysex message, the high bit must always be zero, and (I'm 
> guessing) your synth simply sticks the remaining 14 bits together to 
> form a number.  7f 7b is
>  0111 1111 0111 1011
> and if we drop the high bits and regroup the nybbles, we get
>  11 1111 1111 1011
> If you add 5 to that, you get zero.  So 7f 7b is exactly -5 in 14 
> bits.  (If you're running Microsoft Windows, you can try this with the 
> included calculator; it can handle both hex and binary.)

Do you know of an existing editor that works in this manner?

Re: [Jsynthlib-devel] Re: patchlib file format (was JSL 1.0 and 2.0)

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

Joe Emenaker wrote:

> Since this format would support multiple patches in a single file... 
> would we want to *use* that capability, or would we keep all of the 
> patches separate?

We'll use the feature.  JSL already supports it, and Brian uses it.

> Since the data encoding is something which pertains the using XML 
> files, I think that the code for is should be in the XML routines and 
> not in the Driver system.
> I'm a little uneasy about the idea of having any XML-awareness in the 
> synthdrivers.

The idea is this:  What if someone wants to hand-edit patches ouside of 
JSL?  It's excessively difficult to edit the hex, but would be possible 
if the patch data was itself a bunch of XML.  I don't know of any way to 
automate this (unless we can leech off the XML editor stuff) but if we 
leave it up to the driver, then anyone who needed it could update the 
driver to create and parse it.

It's also difficult and annoying to write such code, so it'd be up to 
the driver writer to take the time.  By the default, we just dump the 
sysex to MIME64.

<data>
  <dco1 wave1="saw" wave2="pulse">
    <amp-envelope>
      <step rate="99" level="99" sustain="true"/>
      <step rate="50" level="0"/>
    </amp-envelope>
  </dco1>
</data>

-Bill

Re: [Jsynthlib-devel] FW: Re: What is the JSL way to deal with negative param values?

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

Steven Schmidt wrote:

> displays the correct value of -5 for the MSB/LSB combo of  7f 7b
> (I haven't looked at why I had to subtact 128 (base val) to get it 
> right, but that's a suspiciously even number)
> So, have we a bug?  I'll try a slider and see if I have the same 
> problem and report back.
>
Are the bytes still correct when the spinner reads -129?

In a sysex message, the high bit must always be zero, and (I'm guessing) 
your synth simply sticks the remaining 14 bits together to form a 
number.  7f 7b is
  0111 1111 0111 1011
and if we drop the high bits and regroup the nybbles, we get
  11 1111 1111 1011
If you add 5 to that, you get zero.  So 7f 7b is exactly -5 in 14 bits.  
(If you're running Microsoft Windows, you can try this with the included 
calculator; it can handle both hex and binary.)

-Bill

Re: [Jsynthlib-devel] FW: Re: What is the JSL way to deal with negative param values?

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

Bill Zwicky wrote:

> Steven Schmidt wrote:
>
>> I’ve been casting it as a byte and while it seems to work up to a 
>> point – I’m not getting the negative values to display.    
>> I thought it should work the way I’m doing it, but it stops at zero.  
>> Please have a look at this snippet and make recommendations if you 
>> can:  
>> The purpose of this method is to subtract the max value for the 
>> widget if the param value is greater than the max value.  
>
> You realize that "the math" prints get()+max-max, which is the same as 
> rawval? So if rawval has the right value, then you don't have a 
> problem. What is the value for min and max? If max is less than zero 
> but the spinner control itself won't go negative, then we have a bug. 
> Try using a SliderWidget, I know those work.
>
> -Bill

Yes - min val is less than zero and the spinner won't go negative, 
although it does go negative in other instances.
This:

addWidget(p21_osc18va, new SpinnerWidget("**Tune", patch, -1200, +1200, 
-128,
                new TritonMultiCompModel(patch, 311, 1,1200), new 
TritonSender(311)), 3,
                8, 1, 1, 15);

displays the correct value of -5 for the MSB/LSB combo of  7f 7b
(I haven't looked at why I had to subtact 128 (base val) to get it 
right, but that's a suspiciously even number)
So, have we a bug?  I'll try a slider and see if I have the same problem 
and report back.

Re: [Jsynthlib-devel] Re: patchlib file format (was JSL 1.0 and 2.0)

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

I like the look of this.

Since this format would support multiple patches in a single file... 
would we want to *use* that capability, or would we keep all of the 
patches separate?

Bill Zwicky wrote:

> Hey looky, I have two cents too!  Here's my suggestion:
>
> <patchlib>
>  <patch synth="CZ" name="fatlottagood">
>    <description>sounds like that sound from the song about the people 
> .. y'know the one</description>
>    <field1>CZ401A</field1>
>    <field2>CZ401.SYX</field2>
>    <field name="author">Mr. Bill</field>
>    <data>
>      6238768263917634762873
>      7169374619384612387468
>      1349061032964912734883
>    </data>
>  </patch>
>  <etc./>
> </patch>

...

> <data> can be base 16 or 64 or something, and is generated by the 
> Driver superclass.

Since the data encoding is something which pertains the using XML files, 
I think that the code for is should be in the XML routines and not in 
the Driver system.

Also, I've come across binary data encoded in XML before, so I don't 
know if there's a standard for it or if everyone just creates their own 
solution. If we have to implement our own, we should see if there's a 
MIME64 encoder/decoder either in the foundation classes or freely available.

> Sub-classes can override and provide a human-readable XML element tree 
> if they really want.

I'm a little uneasy about the idea of having any XML-awareness in the 
synthdrivers.

> Converting from the old format is easy.  It's a serialized object 
> stream, right?  We can create a converter that deserializes the file, 
> then produces the new object model on command.

I agree. We already have all of the code to read the current format in 
the current JSL. All we need to do is make the code to write the *new* 
format (which we'd have to do anyway) and hook them together.

- Joe