From: Joe E. <jo...@em...> - 2005-03-05 01:55:08
|
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 |