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

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

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

- Joe

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

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

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

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

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

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

Rib Rdb wrote:

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

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

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

Has there been any talk about spiffing up the interface?

- Joe

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

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

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

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

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

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

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

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

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

Brian

Brian wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Like I said. :)

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

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

- Joe

Hello,

Thanks for your feedback. This is the kind of stuff we need to discuss 
to move JSynthLib forward. I've taken some time to digest what you've 
said too see if I can figure how these ideas would fit into the existing 
code base.
My understanding of your complaints is that they fall into two problems:

        ( 1 ) There is a certain amount of functionality you expect from 
a Librarian that JSynthLib lacks
        ( 2 ) Some functionality that JSynthLib does indeed have, you 
can not use because the design of JSynthLib is different than you would 
expect.

I think ( 2 ) at least in the short term is a documentation issue. I've 
been thinking of writing a step by step tutorial w/ screen shots showing 
new users how to perform various tasks for a while. The only reason it 
hasn't materialized already
is that I thought most of it was self explanatory :-). Actually, I think 
once you figure the most basic abstraction behind JSynthLib, it should 
all fall into place anyway. I believe your issue is you are expecting a 
different abstraction

As for ( 1 ) and a more long term view of ( 2)-- let me first explain 
the fundamental abstraction behind JSynthLib, and then explain my 
understanding of the fundamental abstraction you see in your mind for 
what you expect.
Then we can talk about how to merge the two into a more useful program.

JSynthLib as it stands now   (somewhat rambling....)
-----------------------------------

JSynthLib is a disk based Editor/Librarian for Synthesizer patches. It 
provides a rich set of operations for loading patches from your hard 
disk, storing patches from your hard disk, and cataloging your 
collection of patches. This is done by
taking all the patches which would otherwise sit in various .syx files 
on your disk and placing them in .patchlib libraries. Once your patches 
are in .patchlib libraries you can copy them between libraries, and 
generally move the data around
in your computer.

For example, I have two files on my computer. One is a sysex for a 
single patch for my Kawai K4 called "CoolPiano". The other is a sysex of 
an entire bank dump (16 patches) That does not contain CoolPiano. I want 
to add CoolPiano into
that bank. First I create a library and import both the bank and the 
single. Next I open the bank and I can see a grid of all the singles 
that make up that bank. I choose one to overwrite, and I drag-and-drop 
CoolPiano over it. Done! Now I can
either export the modified bank back to disk, or preferably, simply save 
the Library containing the bank, as this lets me maintain comments, etc. 
for the bank.

All "Banks" and "Libraries" in JSynthLib exist on your computer. 
Therefore they are all "Virtual Banks" though they have the same format 
and size as real banks on the synths. The Patches and Banks in JSynthLib 
do not represent any
data currently on the synth, but represent data on your computer.

In the same manner it is possible to take the CoolPiano sound in that 
bank, open it in an editor and change the LFO settings. Then I can 
resave the library and that patch in that bank will be modified. All 
operations are performed directly on
your "Library of patches" stored on your computer's hard drive. In fact 
none of the above operations even require you to have  a Kawai K4 
connected to your computer.

Of course a Librarian also needs to be able to communicate with the 
actual device to be useful, and JSynthLib can do this as well. The 
design behind JSynthLib is to give a simple mechanism for retrieving 
patches from the device, a
simlple mechansism for storing patches back to the device, and a rich 
set of editing primitives that modify the patch while it is stored on 
your computer. I think this is what is different than you are used to. 
JSynthLib makes no attempt
to modify patches that are already loaded on your synth, nor does it 
allow you to view the current environment on your synth. JSynthLib lets 
you view/modify the patches on your computer, and then load/store 
patches back to your synth
when you are done.

JSynthLib has a very loose integration with the actual synth. There is a 
"Get" Command to retrieve a given patch (say Single B-14) from the K4 
and place it in the current library, and a "Store" command to place a 
patch from the current
library to a given location on the K4 (Say Single A-2). Other than that, 
JSynthLib doesn't know/care about your synths layout. All it cares about 
is that the synth has something called an "Edit Buffer" in which 
JSynthLib can place a patch in its library in temporarily in order to 
play it to here what it sounds like. Sounds in the Edit buffer are not 
permentantly stored on the synth, they are stored in the JSynthLIb 
library and only temporarily placed in the edit buffer because otherwise
JSynthLib is unable to play the sound.

The Idea behind JSynthLib is this: Your synth has the ability to load, 
save, and play a patch via midi. It also has its own very limited 
"internal librarian" system built in. It is limited though, because it 
only allows a few patches loaded at a time (maybe 64), if it allows 
editing at all it uses a tiny LCD., it only plays patches for one model 
of synth, it doesn't allow you to add comments to your patches, etc. To 
compensate for this maybe it allows you to save patches to a floppy disk 
to be lost behind your desk and never seen again. JSynthLib sees itself 
as a *replacement* for your synth's internal librarian. You still have 
to use the synth to generate the actual sound ,but everything else is 
done within JSynthLib. The JSynthLib model basically says "A Synthesizer 
is a machine capable of playing a patch that is sent to it" That is all 
that is expected of a synth.

Of course, at some point you want to stop selecting sounds and tweaking 
paramters and actually make your synth "standalone" either to take it to 
a gig or do some sequencing where you want multiple sounds loaded on it. 
At this point you don't
want your synth to be treated as only a glorified "Edit Buffer", but 
want to transfer your current ideas/setup from JSynthLib back to the 
"Internal Librarian" of your synth. There are three ways to do this in 
JSynthLib"

First, if you only want to place a few patches from your JSynthLib 
library into various locations in your synth's internal librarian, you 
can use the "Store" menu option for each. For example you can highlight 
CoolPiano in your current library,
and store it to spot A-5 in your internal librarian. Then you can place 
"FunkyBass" into A-7 for example. This is pretty simplistic.

A better way is to first create a virtual bank in jsynthlib, copy the 
patches you want into it, and then store the entire bank into your synth 
(Say into bank B). This is the way I work with JSynthLib.

The third way is to use a scene, you can copy the patches you want to 
send into your internal librarian into a scene, along with the desired 
desitinations, and then chose "Transfer Scene" This has the advantage 
that one scene
can contain patches and desired locations for many synths and JSynthLib 
can deal automatically with all the different 'internal librarians' to 
get the patches where you want them.

In Summary, JSynthLib is designed as a replacement for your synths 
internal librarian. While you are using JSynthLib, you use it instead of 
an internal librarian. Then, you can use it to seed your more limited 
"internal librarian" in the case
that you need to perform a task like multitimberal sequencing or playing 
live, where you must use the "internal librarian" in order to get at the 
full functionality of your synth. JSynthLib is designed to have a rich 
editing framework for
patches stored on your computer's hardisk, and simple mechanisms to load 
and save patches to and from an actual hardware device. (And a mechanism 
to force the synth to play a patch on the harddrive, since, it JSynth 
can't play it
without some help from the hardware).

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

My Understanding of what you are expecting different

Your ideal program would be, not a librarian to manage patches on your 
disk to replace the internal librarian in your synth, but an extention 
to your synth which provided an easier to use than the front panel 
display into the on board librarian
functionality of your synth. Instead of manipulating patches on your 
computer and storing them to your synth when done, your ideal design 
would give the impression you were editing patches directly on the synth 
in place. With this program,
the primary purpose would not be to edit and catalog patches on your 
hard disk, but to peek and poke at the internal ram on your synth, 
occasionaly copying things from that ram to your disk or vise versa. In 
JSynthLib, there is minimal
store/retrieve from synth and most of the time is spend manipulating 
data on the computer. With your ideal program, most of the time is spent 
manipulating the contents of your synth directly. Is this correct?

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

Synthesis

The question then becomes, how can we make this model of working with 
JSynthLib possible without creating a mixed-metaphore monstrosity. That 
is, can we make a Editor/Librarian that I can work with in the Disk 
Librarian mode I prefer, and that you can work with in the Device 
Manager mode you prefer, without basically having two applications in 
one.  Before I give my proposal, let me mention the constraints we are 
working with:

    1) Backwards Compatability-- People who work with JSynthLib the way 
it currently do should be able to basically continue to do so. File 
formats (.patchlib, .scene) should still exist and work the same way 
they do now. I don't want to
         lose the current functionality to add the new functionality, 
nor do I want to dichotomize it so that a user must choose one or the 
other. They should get all the advantages of current JSynthLib and the 
"Device Manager" abstraction

    2) No Driver Changes- We can't add any new synth specific 
functionality, many of the drivers that work with the current JSynthLib 
are not currently active. In some cases the developers who wrote them 
are no longer active, and in
        other cases, though the developers are active, the synths are no 
longer available (For example, I wrote the Ensoniq ESQ1 driver, but no 
longer own t he synth. )While it is possible to make cosmetic changes to 
the driver API (as we
        have done in the past) We can't add any functionality that 
wouuld need to be programmed per synth. We need to add whatever 
abstractions we add above the driver layer

   3) Gracefully handle partial support- One nice thing about the 
current JSynthLib is that it is very modular. If there exists no Multi 
Driver for your synth, you can't use Multi's but everything else works. 
If there doesn't exist a
        Single Bank Editor, you can't view banks, but you can still work 
with/ modify/ and store all the patches in banks on your synth. This is 
very importand since JSynthLIb is OSS. Not everyone who is willing to 
contribute
        some driver support would do so if it was an all or nothing 
deal. The fact that they can spend a small amount of time to get basic 
driver support working and contribute it is very important. I wouldn't 
want to lose this by making
        everything more integrated such that, it wouldn't work (for 
example) without Bank Editor Support if all you had was a Single Driver 
for a synth.

Proposal
-----------------------

(1) We leave everything that already exists there: Libraries, Banks, 
Scenes, etc. but make evident from the interface that these are 
"Virtual" objects that exist on your computer and that JSynthLib is 
manipulating on your hard disk.
Changes made to these objects are not effecting your Synthesizer but are 
only effecting the state on your JSynthLib "Desktop".

(2) The interface to the actual synths become a much larger part of the 
JSynthLib interface. The functionality remains the same (Receive Patch / 
Store Patch), but the interface to those functions become much more 
expressive.
        Rather than just being  a menu option, I envision the following:

            We have a new Window type in addition to the ones we have 
now, it could be called Device Manager.It is either a box of Icons, or 
maybe a tree view. For the purpose of this discussion, lets assume its a 
tree:
            At the top level you have each synth you own, perhaps with a 
nice picture next to the text. When you delve deeper into the tree, you 
see each datatype supported by a driver for this synth. Under that you 
would have all the available banks. For example, you might have:

Kawai K4
                    Single
                                Internal
                                External                              
                    Multi
                                Internal
                                External
                    Effect
                    Drum
Oberheim Matrix 1000
                    Single
                                Bank 000
                                Bank 100                             

When you click one of the Banks JSynthLib issues a Receive Patch request 
for that bank behind the scenes and populates the subsiquent "Non 
Virtual Bank" window (or perhaps place the patches right in the tree) 
With the
actual patches on that synth currently. You could then right click the 
resulting patches and edit them just like normal, but knowing the 
results will automatically be stored back to the synth when you are done 
with them. In addition,
you could request / send patches between the "Device Manager" actual 
banks and the "Disk Librarian" virtual banks / libraries, by using drag 
and drop or cut and paste rather than having to use the explicit "Get  / 
 Store" menu options.

Plus, we could even make an option in the Preferences to associate a 
"Default" Library with each device that could pop open when you open the 
device in the "Device Manager", this way when you clock on Kawai K4, you 
could
automatically pop open your default 'virtual; library of Kawai K4 patches.

Of course there are lots of technical details to work out and I'm not 
even sure if this is feasable, but if we could do this, would it allow 
you to work the way you wish to?

Technical Issues I see include

    1) How to handle devices for which no Bank Driver exists, I guess we 
could create a Stand in which just iterates through all the patches and 
sends and receives them from the synth serially. This would not allow
         for a true 'Virtual Bank' as these are often compressed .syx 
representations, but it would be enough to view and work with your patches.
    2) Keeping up the metaphore that you are really working "On the 
synth". For example, if I edit a patch that is from the device manager 
and make a change, that change goes into the synths edit buffer, but we 
wouldn't actually
         re-store it in its location until the patch editor was closed. 
(Otherwise we would be sending a lot of sysex info for each fader 
movement). This might violate the abstraction? We need to deal with this 
sensibly. In addition
        we couldn't allow two simultaneious "real" patches to be edited 
on the same synth at the same time as there is only one edit buffer, 
unless we did a send/restore everytime an editor window gained/lost focus.
   3)  Automatically changing to the right patch type. For example,If 
I'm editing K4 Singles and then Click on a K4 Multis, the synth needs to 
automatically change and select the correct multi. On some synths this 
is a patch change with
         an offset, others its a bank change, others its a sysex 
message. This would require new functionality for the drivers, but 
perhaps we could implement a base case that pops up a dialog box saying 
"Hit the Multi Button on your Synth"
        That would get called if that functionality didn't exist for a 
particular device. This would be annoying but it would have the added 
benefit of forcing people to add the functionality to do this 
automatically :)
   4)  Dealing with the user's setup vs. the standard setup for a given 
device. For example, the KawaiK4 has internal and external banks, but if 
the user doesn't have a data card installed, the external banks don't 
work, how could
         JSynthLib deal with this situation?

What do you think?

In addition, I am going to answer some of your more specific questions 
below, though hopefully the discussion above clarify's the way JSynthLib 
works in all these situations and why it does.

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

Thats because you  haven't programmed that checkbox yet :-) The nice 
thing about Open Source is that you can add missing features yourself. 
The bad thing about Open Source is that you can add missing features 
yourself :)

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

Perhaps we should make this more clear somehow? Libraries can hold *any* 
kind of patch for *any* synth. They're flexible like that

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

One of my bandmates is a  Yes fan. I think we need to fix these issues 
so you can get Jon Anderson to use JSynthLib so I can brag to my 
bandmate about it. :-)

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

The functionality does exist, Its the "Store" option from the Patch 
Menu, you select it from the menu and choose the patch number you want 
to send it to. I think after my discussion of the JSynthLib design 
metaphore, this should make
more sense to you?  JSynthLib doesn't have anything currently telling 
you the current "State" of your Synth. To JSynthLib a synth is just 
something it sends data to and gets data back from. There is no facility 
currently to
view the current 'state' of your synth.

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

I did exactly that. Fully and completely and in painstaking detail 
actually before I even wrote a single line of Java. I worked out menu 
layouts, window types, how the user would interact, etc. The thing is 
the spec was fully implemented
by around version 0.10 and since then its basically been "whatever 
someone wants badly enough to write gets added".

Brian

Brian wrote:

> My understanding of your complaints is that they fall into two problems:
>        ( 1 ) There is a certain amount of functionality you expect 
> from a Librarian that JSynthLib lacks
>        ( 2 ) Some functionality that JSynthLib does indeed have, you 
> can not use because the design of JSynthLib is different than you 
> would expect.

Well, true... but you're making me feel selfish when you say "..than 
*you* would expect". Granted, I can only relate my own personal 
experiences and frustrations with JSL, but I cannot believe that I'm 
alone. So, imagine an experiment. Suppose we grab a bunch of synth 
owners with little or no previous editor/librarian experience and sit 
1/3 of them down in front of SoundDiver, 1/3 in front of MidiQuest, and 
1/3 in front of JSL and say "Tweak a sound on your synth". Do you have 
any doubts that the JSL users are going to still be staring at the 
screen after the other users have gone home?

Maybe the current developers have been working on and using JSL for so 
long that their brain just thinks this way now and so they don't see any 
problem. However, I think I'm a pretty smart guy. I have a bachelor's in 
Physics, I think I'm a very competent programmer, and I was one of two 
sound techs for Jon Anderson's solo tour last year. But, when I try to 
use JSL, I find it very unintuitive... forcing me to go to the 
documentation.... which doesn't seem to be any help either. Then, every 
six months or so, I take a crack at writing a Device/Driver and just get 
confused by how it's all supposed to work and I just give up.

Now, I could (and probably will) just keep trying to train myself to 
think in the JSL way and assimilate and then I'll shut up and JSL can 
keep the current UI that it has. Before that day comes, however, I'm 
going to keep insisting that the current UI is a *real* *problem*. I'm 
one of the most persistent people I know and one of the smartest. If it 
takes such a high level of both to use JSL effectively, then JSL is 
certainly driving many potential users away (my current personal slogan 
for JSL is "By programmers.... FOR programmers."). Not only is it 
difficult to learn... but there are no early clues (like some more 
graphics or something... which I can help with) which even get the user 
to believe that there'd be some *payoff* for putting in the effort to 
learn it.

Same goes for writing drivers. I've tried the suggested "Just copy the 
KawaiK4 driver and edit it up..." way suggested in the docs and I'm not 
getting it. I have some very specific suggestions about fixing *that* 
(without requiring a rewrite of the current drivers), but we can discuss 
that later. Suffice it to say that we're probably driving away more than 
a few synthdriver developers, too.

> I think ( 2 ) at least in the short term is a documentation issue. 
> I've been thinking of writing a step by step tutorial w/ screen shots 
> showing new users how to perform various tasks for a while.

I would be more inclined toward a wizard/help-tips system. For example, 
when you run JSL for the first time ever, it could greet you with "It 
looks like you don't have any synths configured. Would you like to do 
that now?". Also, as various tools/windows are invoked during the use of 
JSL, there could be tip dialogs like "This is the bank view for your 
synth. You use it to do blah blah blah." along with a checkbox to "Don't 
show this message again". The nice thing about this is that it's 
context-sensitive. It's like being shown just the portion of the manual 
that relates to what you're trying to do right at that moment. On the 
one hand, you don't have to read the whole manual. Additionally, you 
don't have to read *any* of the manual before you get to jump in and 
start playing.

> Actually, I think once you figure the most basic abstraction behind 
> JSynthLib, it should all fall into place anyway.

Well, once I figured out nuclear physics *that* all fell into place, 
too. :) What's not being talked about is the amount of work you have to 
put in to get to the "figured out" stage. Maybe it's a matter of trying 
to make JSL work like something else that the user is already familiar 
with. The first metaphor that comes to my mind is that of a MP3 player.

With an MP3 player, you have some subset of your entire library of songs 
on your mp3 player. You can open your mp3 player on your PC and drag 
files in and out (like getting/sending patches) or you could drag whole 
playlists over (like sending banks). However, any mp3 librarian program 
is not going to also show you all of your Word and Excel documents on 
your PC. It's not going to show you items that are of no use to your MP3 
player. Likewise, I think that it would be more intuitive if I could 
"open" a Korg M1 icon in JSL and see all of the patches, banks, etc. 
that are available for that synth. The context-free "I want to see all 
of the different piano sounds I have, regardless of what synth they're 
for" scenario that you mentioned earlier, I believe, is a less-common 
case... and should be put into some kind of global-search function.

> My Understanding of what you are expecting different
>
> Your ideal program would be, not a librarian to manage patches on your 
> disk to replace the internal librarian in your synth, but an extention 
> to your synth which provided an easier to use than the front panel 
> display into the on board librarian functionality of your synth.

My ideal program would be both. There are needs for both functionalities 
in different situations.

For example, my girlfriend's Yamaha S-80 lets you modify envelopes on 
the little screen on the synth. However, you modify them by selecting 
one of either attack/sustain/decay/hold and then adjusting the X and Y 
coordinates of it. If you have some graph-paper handy while you do this, 
you might actually be able to get an idea of what the envelope really 
looks like. A guy I know calls this kind of thing "functional, yet 
disfunctional". It's functional in that it's *possible* to do it.... but 
disfunctional in that it's difficult enough such that nobody would 
actually bother.

So, when trying to come up with a certain sound, the only real way to do 
it is with some big-screen graphical display of what's going on.... and 
it has to be an iterative process where she tweaks something, hears what 
it sounds like, tweaks something else, etc. Now, to facilitate this, 
some synths actually let you send sysex messages to them to adjust 
individual parameters in the edit buffer. However, supporting these 
realtime adjustments is almost a bigger hassle than writing a regular 
editor so I'm not expecting that from the synthdrivers. I *do*, however, 
think that it would be a limitation if JSL's infrastructure didn't, at 
least, support that possibility if a synthdriver author *were* inclined 
to actually write support for it.

> The question then becomes, how can we make this model of working with 
> JSynthLib possible without creating a mixed-metaphore monstrosity. 
> That is, can we make a Editor/Librarian that I can work with in the 
> Disk Librarian mode I prefer, and that you can work with in the Device 
> Manager mode you prefer, without basically having two applications in one.

Well, I don't see a major problem with giving JSL two operating modes 
that the user can switch between. Since we're mostly talking about how 
the data is *presented* (ie, whether patches are grouped in separate 
windows by synth type, whether the main operating window is a mixed 
spreadsheed of patches/banks or a graphical one showing the layout of 
the user's studio), most of the underlying machinery can stay the same. 
So, I don't think it would be two applications in one. It would be one 
application with two faces that you could switch between.

> Before I give my proposal, let me mention the constraints we are 
> working with:
>
> 1) Backwards Compatability-- People who work with JSynthLib the way it 
> currently do should be able to basically continue to do so. File 
> formats (.patchlib, .scene) should still exist and work the same way 
> they do now. I don't want to lose the current functionality to add the 
> new functionality, nor do I want to dichotomize it so that a user must 
> choose one or the other. They should get all the advantages of current 
> JSynthLib and the "Device Manager" abstraction.

Ideally, the user would be able to switch between the two "faces" on a 
whim without any disruption of configuration data. If you add a synth in 
"Classic" view, it would be there in the "Pretty" view.

> 2) No Driver Changes

I don't see a need to change any of the drivers, really. My main 
frustration at this point is just being able to *get* to a driver. 
However, like I mentioned above, if there isn't already infrastructure 
to *allow* (not require.... allow) drivers to do real-time tweaking of 
synth parameters, then I think that we could add that without 
traumatizing the existing drivers.

> 3) Gracefully handle partial support

Yes, yes, yes! I'll go one further and say "transparently" handle 
partial support, when at all possible. For example, suppose a 
synthdriver knows how to send/receive single patches, but not banks 
(maybe the synth, itself, doesn't support bank dumps, say)... yet it 
somehow knows how many patches are *in* a bank and how to select them. 
JSL should be able to go "Okay... no bank sysex receive? I'll just go 
get them one-at-a-time.". Or... if an editor doesn't support realtime 
sysex tweaking of parameters, JSL could just send the entire patch to 
the edit buffer. Maybe it already does this. Dunno.

Oh... one more thing. I think that it would be a very nice additional 
feature if it were easier to see what kind of support each synthdriver 
has. As it stands now, you have to actually add the synth and then you 
get a textbox saying "This driver can't do xyz... but it can do abc..." 
and you click OK. I think it would be much more slick if the drivers had 
a method which reported their capabilities (Does it have a patch editor? 
Does it do realtime parameter modification?). If we had an icon to 
represent each one of these capabilities, they could be included in the 
DeviceAddDialog JTree... so you could look down the list and see which 
synths had complete support and which did not. Yes... I know that this 
requires a change to the existing synthdrivers. However, I think that 
this is important enough that I'd be willing to add this method to each 
of the legacy drivers myself.

> I wouldn't want to lose this by making everything more integrated such 
> that, it wouldn't work (for example) without Bank Editor Support if 
> all you had was a Single Driver for a synth.

Well... making it more integrated does not necessitate that we can't 
have partial support. Suppose you write an S-80 driver... but you only 
write support for the "Voice" banks and not the "Performance" banks. 
That doesn't have to mean that we're stuck with a spreadsheet view so 
that you can have just a "Voice Bank" entry. You could still use a 
system where you double-click on your S-80 icon in JSL and you see all 
of the stuff you can do with your S-80... and the Performance bank just 
wouldn't be there... or it would be greyed out, or whatever.

> Proposal
> -----------------------
> (1) We leave everything that already exists there: Libraries, Banks, 
> Scenes, etc. but make evident from the interface that these are 
> "Virtual" objects that exist on your computer and that JSynthLib is 
> manipulating on your hard disk. Changes made to these objects are not 
> effecting your Synthesizer but are only effecting the state on your 
> JSynthLib "Desktop".

How about.... you can open a window to your synth. On the right, you see 
the layout of the banks (or however your driver displays the patch 
layout). On the left, you'd see a list of all of the "saved" patches and 
banks, along with a button to let you search the JSL.org site for more 
patches for that synth?

>        Rather than just being  a menu option, I envision the following:
>
>            We have a new Window type in addition to the ones we have 
> now, it could be called Device Manager.It is either a box of Icons,

Well, for what it's worth... two years ago, I threw together a little 
demo of a panel where you could add a bunch of icons of synths and drag 
them around... arrange them like your studio is laid out... much like 
SoundDiver's main window is. I posted it to the group to see what people 
thought of the idea and I don't recall getting a single comment about 
it. I think that that's one of the things that directly preceeded my 
18-month "vacation" from working on JSL. The lack of any apparent 
interest in making JSL visually appealing and engaging and intuitive 
just kinda sapped my will to put in more effort.

I'm not asking for an apology or anything....   I guess I'm just saying 
that there seems to be a lot of inertia here. In fact, this thread is 
the first time I recall any of the principal developers actually seeming 
to seriously consider making a significant change.

> At the top level you have each synth you own, perhaps with a nice 
> picture next to the text. When you delve deeper into the tree, you see 
> each datatype supported by a driver for this synth. Under that you 
> would have all the available banks....
>
> When you click one of the Banks JSynthLib issues a Receive Patch 
> request for that bank behind the scenes and populates the subsiquent 
> "Non Virtual Bank" window (or perhaps place the patches right in the 
> tree) With the actual patches on that synth currently. You could then 
> right click the resulting patches and edit them just like normal, but 
> knowing the results will automatically be stored back to the synth 
> when you are done with them...

Or, perhaps... if you close the window without saving, it prompts you 
whether you want to save... and maybe even lets you choose where (wth 
the default being where it originally came from).

In fact, maybe we could make it like a regular "Save As..." system that 
people are used to... but, instead of a regular filesystem, we could 
have two "drives", the synth and the local patch storage... with 
subdirectories on the synth representing banks... I dunno. In fact, if 
you went really snazzy, you could have multiple compatible synths in the 
save dialog. For example, if you had two KawaiK4's, they could both show 
up in a save dialog. It's just a thought that crossed my mind....

> Plus, we could even make an option in the Preferences to associate a 
> "Default" Library with each device that could pop open when you open 
> the device in the "Device Manager", this way when you clock on Kawai 
> K4, you could automatically pop open your default 'virtual; library of 
> Kawai K4 patches.

Well, this kinda brings up another metaphor that I was thinking of. The 
PDA metaphor. With PDA's you "sync" them with your PC data. If there 
were a disk-based counterpart for each of your synths, then there's the 
possibility of doing a "sync" where JSL checked for differences between 
the synth copies and the disk copies and allowed you to over-write in 
either direction... and/or save the new one in your disk-based cache of 
patches.

However, this could be confusing to users, to open the device and not 
see stuff that's *in* the device. When I open my refrigerator, I see 
what's *in* my refrigerator, not what *was* in my refrigerator the last 
time *I* looked in it.

The way SoundDiver does it is you open your synth and everything is 
currently *blank*, because it doesn't *know* what's on your synth yet. 
You then request the patches and it fills in the little items in the 
banks. I think we should take this one step further and have a popup 
window asking the user if they want to "refresh" or get all of their 
patches now. I guess, if we had that, we *could*  have default 
libraries. Since the user would be greeted with a dialog to "refresh" 
the library, they'd understand that what they're looking at now isn't 
"fresh".

By the way, I know that I keep saying "SoundDiver does it like this...", 
and it probably seems like I'm just trying to morph JSL into something 
that I've already learned how to use... but that's not quite correct. 
SoundDiver is the one that I didn't have to *learn* how to use at all. 
Of the librarian/editor programs I've used, SoundDiver had the most 
self-explanitory interface of them all.... which is why I keep referring 
to how it works. Granted, I think there are ways that SoundDiver's 
interface could be improved even *more*, but just getting to 
SoundDiver's level would be a step upward for JSL, in my opinion.

> Technical Issues I see include
>
>    1) How to handle devices for which no Bank Driver exists, I guess 
> we could create a Stand in which just iterates through all the patches 
> and sends and receives them from the synth serially. This would not 
> allow for a true 'Virtual Bank' as these are often compressed .syx 
> representations, but it would be enough to view and work with your 
> patches.

Right.

>    2) Keeping up the metaphore that you are really working "On the 
> synth". For example, if I edit a patch that is from the device manager 
> and make a change, that change goes into the synths edit buffer, but 
> we wouldn't actually re-store it in its location until the patch 
> editor was closed. (Otherwise we would be sending a lot of sysex info 
> for each fader movement).

Well, I think the way SoundDiver does it is that there's little button 
in the window to enable/disable realtime updates of parameters. In some 
cases (depending upon how big the single sysex patches are and how 
carefully you're changing settings), this might be worth it. We could 
also have a button for "send and play" (or... hey... how about "Apply", 
since most users have seen that concept before with their OS?) when 
auto-send isn't on. Having to open/adjust/close all the time would be a 
bitch.

> This might violate the abstraction? We need to deal with this 
> sensibly. In addition we couldn't allow two simultaneious "real" 
> patches to be edited on the same synth at the same time as there is 
> only one edit buffer, unless we did a send/restore everytime an editor 
> window gained/lost focus.

Uhhh... well, how about this? An edit window would have a "test" and 
"save" button. If you click "test", it just sends it to the edit buffer. 
If you click "save" it actually saves it to wherever it originally came 
from. Then, you could be popping around to different windows.... 
clicking "test" all you want, without having to send/restore.

> 3)  Automatically changing to the right patch type. For example,If I'm 
> editing K4 Singles and then Click on a K4 Multis, the synth needs to 
> automatically change and select the correct multi. On some synths this 
> is a patch change with an offset, others its a bank change, others its 
> a sysex message. This would require new functionality for the drivers, 
> but perhaps we could implement a base case that pops up a dialog box 
> saying "Hit the Multi Button on your Synth" that would get called if 
> that functionality didn't exist for a particular device. This would be 
> annoying but it would have the added benefit of forcing people to add 
> the functionality to do this automatically :)

Well, this might be worked into a wizard/help-tip system, but I think 
it's very important. Some synths can receive or be instructed to send a 
patch at any time. Others have to be put into a special mode to do so. 
Right now, any info about special proceedures seems to be shown to the 
user at the time they add the synth. This should probably be changed so 
that it happens at the actual time the user tries a send or get. 
However, this is probably something that's left to the individual 
synthdriver author's discretion. I don't have a particular solution to 
offer at the moment... but I feel compelled to point out that there 
probably needs to be something done. As it stands now, if a user tries 
to get a patch and they forgot that their synth needs to be put into 
some "bulk dump" mode, they could end up thinking that JSL is broken, or 
that their midi interface is broken.

> 4)  Dealing with the user's setup vs. the standard setup for a given 
> device. For example, the KawaiK4 has internal and external banks, but 
> if the user doesn't have a data card installed, the external banks 
> don't work, how could  JSynthLib deal with this situation?

Is there no way to discover, via any kind of sysex at all, if the card 
is there? Then you'd have to ask the user, no?

> What do you think?

I think I'm going to pursue a career in alcoholism. :)

> In addition, I am going to answer some of your more specific questions 
> below, though hopefully the discussion above clarify's the way 
> JSynthLib works in all these situations and why it does.
>
>> One problem I had was trying to figure out just what a "Library" is. 
>> It's the only thing I'm able to create at the outset (until I figure 
>> out how to go add synths), yet there were no cues as to what it was a 
>> library *of*. Patches, I figured... but I didn't know for what synth.
>
> Perhaps we should make this more clear somehow? Libraries can hold 
> *any* kind of patch for *any* synth. They're flexible like that.

I still contend that there's no need to mix dissimilar patches and banks 
from different synths.

> One of my bandmates is a  Yes fan. I think we need to fix these issues 
> so you can get Jon Anderson to use JSynthLib so I can brag to my 
> bandmate about it. :-)

Well, I'll do you one better. Currently, I'm the guy he calls when he 
needs his patches messed with. I'd love to use JSL for it but... well, 
we won't go there. However, if JSL had a nice, slick interface, I might 
be able to pester Jon into getting Rick to try it... but not until it's 
slick.

>> I'll explain. Say that you find a neat sound? You went down the list 
>> of patches and heard something that you liked. *Now* what?.... 
>
> .... JSynthLib doesn't have anything currently telling you the current 
> "State" of your Synth. To JSynthLib a synth is just something it sends 
> data to and gets data back from. There is no facility currently to 
> view the current 'state' of your synth.

Do you know of *any* other librarian/editor program which lacks that 
facility?

- Joe

Hi,

I've run over this discussion.  I could not read one word by one word,
so I may misunderstand something.

In this mail I'd like to propose two things.
        1. Let's complete JSynthLib 1.0.
        2. Then start for JSynthLib 2.0 with big changes (User I/F, file
           format, etc.)

First I thank you Brain for his starting this great project.  It's much
more easy to improve existing code or to comment (or criticize) it than
to create it from scratch.  It learned a lot from your program.  There
are many good ideas (ParamModel is one of them).

I have no experience of commercial librarians.  But I guess they cannot
support all of MIDI devices.  They probably have a feature to support
any MIDI device for some degree by letting user set up something, but
there are limit without full programming language.  By having this GPLed
librarian, anyone who can do programming can have librarian for any MIDI
device.

Of course, as anyone including Brian agree, there are lots of things to
be improved.  (I've been doing my best to improve JSL as far as I can.)
As we discussed before, once we will done for the package structure
change, JSL can be version 1.0.

Although Rib and Joe taught me how to change package by Eclipse, it's
not still clear for me.  And they wrote it would be easy, but I'm still
afraid once I start it, it will take lots of time.  I'll move my home
over Pacific Ocean soon. (I'll go back to Japan with my family.)  I will
not be able to spend my time for this project as I did for a couple of
months at least.  So, don't rely on me for the package restructuring work. 
Joe, could you drive this issue? You were pushing this issue very hard,
weren't you?

I agree with Joe on the point there are room to improve the user
interface.  The current UI allow user to put any kind of patch in a
library.  This gives us some freedom.  But I don't think it is worth to
let users select driver (MIDI device) every time they do something. 
(For example, new patch dialog does not have to have Device combo box if
a frame is dedicated for a MIDI device.) And I think we also need to
change the file format.  By having function to import or convert the
current format file, we can change it and go forward.  The combination
of an XML file and binary Sysex files is my proposal.

Again we have to release 1.0 before the big changes.

Regards,
-- 
Hiroo Hayashi

Hiroo Hayashi wrote:

>In this mail I'd like to propose two things.
>        1. Let's complete JSynthLib 1.0.
>        2. Then start for JSynthLib 2.0 with big changes (User I/F, file
>           format, etc.)
>  
>
That is a possibility. However, JSL is currently only at 0.20. Has 
anyone decided what other features JSL needs before it is 1.0?

>Although Rib and Joe taught me how to change package by Eclipse, it's
>not still clear for me.
>
Well, I can either do this myself (and it would take me about 30 
minutes), or I can write for you a step-by-step HOWTO on doing it.

The first step, however, is *deciding* where everything should go. 
Starting with "org.jsynthlib", I suppose, we should probably start with 
deciding which *packages* there should be, and then decide which 
classes/interfaces belong in each one.

>Joe, could you drive this issue? You were pushing this issue very hard,
>weren't you?
>  
>
Yes. I can push for this.

>And I think we also need to
>change the file format.  By having function to import or convert the
>current format file, we can change it and go forward.  The combination
>of an XML file and binary Sysex files is my proposal.
>  
>
XML can store binary values. So, I'd prefer to see *all* XML for JSL's 
default files, with import/export capability for sysex.

- Joe

On Sun, 13 Mar 2005 11:59:09 -0800
Rib Rdb <ri...@gm...> wrote:

Rib> I've recently realized that moving Serializable classes to a different
Rib> package will break file format compatibility.  The full class name is
Rib> stored in the file, so that class has to exist for the file to be
Rib> loaded.  We could work around this by placing a special proxy class in
Rib> the old location, but this seems ugly to me.  If we have plans to
Rib> change the file format, perhaps we should wait to move any classes
Rib> saved in patchlib's or scenelibs until then.

Your note reminds me that I proposed file format change when I realized
the restriction of the Serializable classes.
As you wrote, we have to change the file format before changing package
restructuring.
-- 
Hiroo Hayashi

Hiroo Hayashi wrote:

>Your note reminds me that I proposed file format change when I realized
>the restriction of the Serializable classes.
>As you wrote, we have to change the file format before changing package
>restructuring.
>  
>
Perhaps we should start compiling a "wishlist" of changes that we'd like 
to see for version 2. What are all of the things that people would have 
liked to have, but could not because of file format limitations?

Also, is there any reason why we couldn't provide a converter (which 
would have the old classes in their old locations) to convert from the 
current format to some new one?

- Joe

Joe> Perhaps we should start compiling a "wishlist" of changes that we'd li=
ke=20
Joe> to see for version 2. What are all of the things that people would hav=
e=20
Joe> liked to have, but could not because of file format limitations?

The below is a mail I wrote before.  Any text format is fine.  I'm
proposing XML just because we don't have to reinvent a wheel by using
existing libraries.

Joe> Also, is there any reason why we couldn't provide a converter (which=
=20
Joe> would have the old classes in their old locations) to convert from the=
=20
Joe> current format to some new one?
Do you have any good way to solve the problem?

Forwarded by Hiroo Hayashi <hir...@co...>
----------------------- Original Message -----------------------
From:    Hiroo Hayashi <hir...@co...>
To:      jsy...@ya...
Date:    Fri, 05 Mar 2004 00:59:56 -0600
Subject: Re: [jsynthlib-dev] encoding for xml driver
----

Hi,

I tried to mean that hash is used by editor internally, and byte array
is used outside of editor (sending/receiving or saving/loading patch).=20
We need only one set of conversion method.

JSynthLib can use a patch name which is independent from the real
patch name used by synth.  Patch name used by synth is not long enough
and machine dependent.  For example the data format for JSynthLib can be;

<patch>
  <name>Drum kit for combo jazz with dark sizzle ride symbal</name>
  <file>RolandTD6_0012.syx</file>
  ...
</patch>=20

There are some more merits.  We can use any length of patch name and
non-ascii characters for patch name.  The patch name used by synth is
one of parameter which editor can edit.  We can specify a name for a
bank patch of which a synth cannot have a name.  Librarian does not have
to know anything about the patch format.  XML is not a good language for
binary data (patch data). Binary data is saved in a standard binary file
(raw binary file).  The binary file can be used by other software tools
(ex. cat XXX >/dev/midi :-)).

Rib>> In either way XML driver have to encode to or decode from byte
Rib>> array.  I understand "1" means that XML driver keeps the state
Rib>> of all parameters in byte array and every time it access one of
Rib>> parameters, it have to do conversion.  And "2" or "3" keeps the
Rib>> state of palates in natural format, and conversion is done only
Rib>> before send (or save) patch and after receive (or load) patch.

=2E..

Rib> A hash is a very good idea!  However, I hadn't thought about saving.=
=20
Rib> It seems like we wouldn't want to save these hash maps, but we do
Rib> want to save the information like which patch class handles the patch
Rib> data, and what data goes in which message for a multi-message patch.=
=20
Rib> Also, the librarian only needs to be able to access the name of the
Rib> patch.  The other parameters are only accessed from the editor.=20
Rib> Maybe the XML driver should have two patch classes - one that stores
Rib> the byte arrays and knows how to en/decode the name for the library
Rib> and another that stores all the info in a map that's only passed to
Rib> the editor.  This way the user doesn't have to wait for possibly
Rib> thousands of parameters to be decoded just to change the name. Both
Rib> would follow the same interface, so nothing but the driver really
Rib> should need to know that this was going on.
--=20
Hiroo Hayashi

--=20
Hiroo Hayashi

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

jsynthlib-devel