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

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

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