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

Re: [Jsynthlib-devel] Okay... so why can't I edit a patch with this?

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

Hiroo Hayashi wrote:

>Joe> So... tell me what an idiot I'm being.
>
>If you were idiot, it might be because you did not give us the real code
>which you used:-)
>
>1. Your code cannot be compiled.
>  
>
Sorry. I left the beginning junk (like the import statements, package 
statement, etc.) and an ending curly bracket. I figured people would be 
able to look at the code segment and tell what I was doing wrong.

>2. Even if you fix the syntax errors, JSynthLib cannot find your driver.
>  
>
Well, it seems to *find* it okay because my device and driver show up in 
the "New Patch..." dialog. I can create a new patch... it just doesn't 
edit it.

- Joe

Re: MIDI Output Buffer Size and MIDI Output Delay preference (Re: [Jsynthlib-devel] Signal Errors on Mac OSX)

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

Jeff> Using the loopback test for detecting signal errors
Jeff> might be worth a try. But I think you would probably
Jeff> want to have it send a longer message. Right now it
Jeff> only sends 11 bytes. Even sending multiple short
Jeff> messages might skew the results because woudn't be
Jeff> much different than setting the buffer size to 11
Jeff> bytes and sending a long message.

Now the test sends up to 491 byte long message. We may want to change
MidiTest.MAX_SYSEX_SIZE to 10000.

And this loop
        for(int i=10; i<sysexpayload.length; i+=20)
needs to be changed to something like;
        for(int i=10; i<sysexpayload.length; i*=2)

I'm really interested that this test can detect your problem.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] RolandMKS7 Driver+Editor

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

I checked this in for Federico, I hope noone minds.  Federico, we'd 
appreciate it if you'd update from CVS to make sure your files got there 
safely.

Thanks!
-Bill

Re: [Jsynthlib-devel] Okay... so why can't I edit a patch with this?

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

Joe> So... tell me what an idiot I'm being.

If you were idiot, it might be because you did not give us the real code
which you used:-)

1. Your code cannot be compiled.
2. Even if you fix the syntax errors, JSynthLib cannot find your driver.

P.S.
I played Roundabout, Heart of the Sun Rise, and some more in my high
school band.  Lonely Heart was not released yet.  A long long time ago...
I'm glad to feel that I become closer to one of the great band members.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Okay... so why can't I edit a patch with this?

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

Hmm .. my guess is JSL can't recognize the patch you made.  A patch is 
expected to be a full sysex message by itself, and Driver.sysexID must 
be able to match it.  (By default, it's an exact copy of the message 
your synth sent back as a dump.)  So try copying the sysexID bytes to 
the beginning, and F7 at the end.

As far as I know, JSL doesn't really associate a driver with a patch, 
even though it displays one in the list.  If  supportsPatch says nay, 
then you can't edit it.

-Bill

[Jsynthlib-devel] Okay... so why can't I edit a patch with this?

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

This is making me really depressed. I'm trying.... again... to make a 
synthdriver. I figured I'd start with baby steps. All I wanted to do is 
make a driver that can receive  a sysex message and dump it to the console.

Before I even do *that*, I figured that I'd skip the sysex part and just 
try to create a blank patch and then see if I could dump it to the 
console. The dump is supposed to happen when I go to "Edit.." the patch.

So, I made a Device class:

> public class AlesisSR16Device extends Device {
>
>    public AlesisSR16Device () {
>        super("Alesis", "SR-16", "000000000000000E0E000.00........f7",
>              "Let's see how this goes....",
>              "Joe Emenaker");
>    }
>
>    public AlesisSR16Device(Preferences prefs) {
>        this();
>        this.prefs = prefs;
>
>        addDriver (new HexDumpDriver ());
>    }
>  }


Then, I made HexDumpDriver.....

> public class HexDumpDriver extends Driver {
>
>     public HexDumpDriver() {
>         super("Sysex", "Joe Emenaker");
>         sysexID = "F000000E13****";
>     }
>
>     public HexDumpDriver(String patchType, String authors) {
>         super(patchType, authors);
>     }
>
>     boolean hasEditor() {
>             return true;
>     }
>
>     protected JSLFrame editPatch(Patch p) {
>         SysexMessage[] messages = p.getMessages();
>         for(int i=0; i<messages.length; i++) {
>             
> System.out.println(core.Utility.hexDump(messages[i].getData(),0,-1,16));
>         }
>         return null;
>     }
>
>     protected Patch createNewPatch() {
>         byte[] b = new byte[20];
>         for(int i=0; i<b.length; i++) {
>             b[i] = (byte) i;
>         }
>         Patch p = new Patch(new byte[20]);
>         editPatch(p);
>         return(p);
>     }

I overrode editPatch() and I even overrode hasEditor(), but I still get 
no editor choice when I right-click on a new patch that I create.

So... tell me what an idiot I'm being.

- Joe

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

Re: [Jsynthlib-devel] Re: [PD] colored/swooping cables

[federico <xa...@in...>]

i pickup the wrong list :/
forgive my posts & sorry for the traffic :)

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

[Brian <br...@ov...>]

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

[Jsynthlib-devel] Re: [PD] colored/swooping cables

[federico <xa...@in...>]

rob...@be... wrote:

>I was looking around online and saw this website:
>http://lab.andre-michelle.com/
>if you scroll down to the "velocity" category, and click on cables, it bring up a very interesting idea. Is there an extern that makes one of the following:
>1. colored cables (in the main window, not some gui thing. but in the place where most patches are normally made).
>OR
>2. Swooping cables (i think this would be rather bothersome though, having cables swoop all over the place, etc.)
>thanks,
>Robert
>  
>
i would prefer "intelligent cables".

this is a feature that PCB software has (tools for designing circuits).
given a netlist (here, a collection of inlets) with nodes that should be 
connected together, the program find the best path for each connection, 
i.e. by following a grid. (there are well known algorithms about this)

this "best" path should be a segmented (or bezier, or exp, or ...) line 
that try to not accross wires nor objects, to make reading (and MAKING) 
a patch easier, especially in the cases of many->one inlet or vice-versa 
(or other situations i don't remember ;)).

what do you think about it?

-- 
Federico

Re: [Jsynthlib-devel] RolandMKS7 Driver+Editor

[federico <xa...@in...>]

MKS7ToneSingleEditor.java.diff
bugfix
* wrong sub_osc_level range
* wrong transmission of param #4 (vca_&_vcf)

Re: MIDI Output Buffer Size and MIDI Output Delay preference (Re: [Jsynthlib-devel] Signal Errors on Mac OSX)

[Jeff W. <jww...@ya...>]

--- Joe Emenaker <jo...@em...> wrote:
> Jeff, how were you testing for errors? We you using
> the loopback test, 
> or something else? If the loopback test can catch
> these signaling 
> errors, then it could be integrated into an
> "auto-tuning" wizard which 
> would keep increasing the buffer sizes and delay
> times until the 
> loopback test succeeds.

I didn't try the loopback test because I'm lazy and
didn't want to reroute cables. I just noticed the
frequency of signal errors increased dramatically when
I started sending FCB1010 patches a couple weeks ago.
Since that device has a 6010 byte patch, it led me to
suspect there might be a correlation between the size
of the patch and the frequency of signal errors.
That's when I tweaked the buffer size and added the
timeout on my local copy of MidiUtil.java.

Since then, I've been running with a 256 byte buffer
and a 100 msec timeout and while it hasn't eliminated
the signal errors entirely, it has dramatically cut
down on the frequency. I just downloaded the most
recent change (with the buffer and timeout settings in
the preferences) and I'm going to try a 128 bytes/100
msec for a while and see how that goes.

Using the loopback test for detecting signal errors
might be worth a try. But I think you would probably
want to have it send a longer message. Right now it
only sends 11 bytes. Even sending multiple short
messages might skew the results because woudn't be
much different than setting the buffer size to 11
bytes and sending a long message.



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

Re: MIDI Output Buffer Size and MIDI Output Delay preference (Re: [Jsynthlib-devel] Signal Errors on Mac OSX)

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

Joe> >Now you can specify MIDI output buffer size and MIDI output delay time
Joe> >by MIDI preference dialog.
Joe> >
Joe> What are your thoughts about making this a little simpler for the 
Joe> end-user. Perhaps a slider which slides between "fast" and "safe". In 
Joe> the full documentation, we could explain what actual values "fast" and 
Joe> "safe" actually correspond to.

As I document (and tooltip help shows) the default setting is safe and
fast *normally*.  This is what I could think for users.

Joe> >Jeff> However I did some
Joe> >Jeff> experimentation with CAProvider yesterday and
Joe> >Jeff> discovered a couple of modifications to the
Joe> >Jeff> core.MidiUtil.java class that will at least cut down
Joe> >Jeff> on the frequency of signal errors.
Joe> >
Joe> Jeff, how were you testing for errors? We you using the loopback test, 
Joe> or something else? If the loopback test can catch these signaling 
Joe> errors, then it could be integrated into an "auto-tuning" wizard which 
Joe> would keep increasing the buffer sizes and delay times until the 
Joe> loopback test succeeds.

If this works, it's a good idea.
-- 
Hiroo Hayashi

Re: MIDI Output Buffer Size and MIDI Output Delay preference (Re: [Jsynthlib-devel] Signal Errors on Mac OSX)

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

Hiroo Hayashi wrote:

>Now you can specify MIDI output buffer size and MIDI output delay time
>by MIDI preference dialog.
>
What are your thoughts about making this a little simpler for the 
end-user. Perhaps a slider which slides between "fast" and "safe". In 
the full documentation, we could explain what actual values "fast" and 
"safe" actually correspond to.

>Jeff> However I did some
>Jeff> experimentation with CAProvider yesterday and
>Jeff> discovered a couple of modifications to the
>Jeff> core.MidiUtil.java class that will at least cut down
>Jeff> on the frequency of signal errors.
>
Jeff, how were you testing for errors? We you using the loopback test, 
or something else? If the loopback test can catch these signaling 
errors, then it could be integrated into an "auto-tuning" wizard which 
would keep increasing the buffer sizes and delay times until the 
loopback test succeeds.

- Joe

MIDI Output Buffer Size and MIDI Output Delay preference (Re: [Jsynthlib-devel] Signal Errors on Mac OSX)

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

Hi Jeff,

Now you can specify MIDI output buffer size and MIDI output delay time
by MIDI preference dialog.  These have been on my TODO list and I've
finally implemented them.

Enjoy.

Jeff> Just a note Mac OSX signal errors. I tried Plumstone
Jeff> but was unable to get it working. However I did some
Jeff> experimentation with CAProvider yesterday and
Jeff> discovered a couple of modifications to the
Jeff> core.MidiUtil.java class that will at least cut down
Jeff> on the frequency of signal errors. First of all, I was
Jeff> having a lot of problems with the Behringer FCB1010.
Jeff> This device only has one type of patch with a length
Jeff> of 2352. Since it's a fairly large patch and since I
Jeff> wasn't getting as many signal errors as with the other
Jeff> devices, I suspected that the problem might be some
Jeff> kind of a timing issue.
Jeff> 
Jeff> First, I changed the value of BUFSIZE from 0 to 256
Jeff> which causes the MIDI data to be sent in multiple
Jeff> blocks of 256 bytes. Then I added a 100 millisecond
Jeff> delay at the end of the send(Receiver rcv, MidiMessage
Jeff> msg) method. The whole thing looks like this:
Jeff>     /**
Jeff>      * MIDI Output buffer size.  If set to '0', Whole
Jeff> Sysex data is
Jeff>      * sent in one packet.  Set '0' unless you have
Jeff> problem.
Jeff>      */
Jeff>     private static final int BUFSIZE = 256;
Jeff> 
Jeff>     /**
Jeff>      * Send a <code>MidiMessage</code>.  If BUFSIZE is
Jeff> non-zero, data
Jeff>      * size will be limited to the size.
Jeff>      */
Jeff>     public static void send(Receiver rcv, MidiMessage
Jeff> msg)
Jeff>         throws MidiUnavailableException,
Jeff> InvalidMidiDataException {
Jeff>             int size = msg.getLength();
Jeff>             
Jeff>             if (BUFSIZE == 0 || size <= BUFSIZE) {
Jeff>                 rcv.send(msg, -1);
Jeff>                 log("XMIT: ", msg);
Jeff>             } else {
Jeff>                 // divide large System Exclusive
Jeff> Message into multiple
Jeff>                 // small messages.
Jeff>                 byte[] sysex = msg.getMessage();
Jeff>                 byte[] tmpArray = new byte[BUFSIZE +
Jeff> 1];
Jeff>                 for (int i = 0; size > 0; i +=
Jeff> BUFSIZE, size -= BUFSIZE) {
Jeff>                     int s = Math.min(size, BUFSIZE);
Jeff>                     
Jeff>                     if (i == 0) {
Jeff>                         System.arraycopy(sysex, i,
Jeff> tmpArray, 0, s);
Jeff>                         ((SysexMessage)
Jeff> msg).setMessage(tmpArray, s);
Jeff>                     } else {
Jeff>                         tmpArray[0] = (byte)
Jeff> SysexMessage.SPECIAL_SYSTEM_EXCLUSIVE;
Jeff>                         System.arraycopy(sysex, i,
Jeff> tmpArray, 1, s);
Jeff>                         ((SysexMessage)
Jeff> msg).setMessage(tmpArray, ++s);
Jeff>                     }
Jeff>                     rcv.send(msg, -1);
Jeff>                     log("XMIT: ", msg);
Jeff>                     try {
Jeff>                         Thread.sleep (100);
Jeff>                     } catch (Exception e) {}
Jeff>                 }
Jeff>             }
Jeff>         }
Jeff> 
Jeff> I realize this is only a temporary workaround. While
Jeff> it doesn't totally eliminate signal errors I'm getting
Jeff> way fewer of them than I was getting.
Jeff> 
Jeff> I have only made these changes to my local copy and I
Jeff> don't plan on committing the changes, since they would
Jeff> only apply to Mac users and would only be a temporary
Jeff> workaround at best. But for any of you who are Mac
Jeff> users and don't want to use Plumstone, this might be
Jeff> another alternative.
-- 
Hiroo Hayashi

Re: JSLFrame related fixes (Re: SDI mode (Re: [Jsynthlib-devel] change proposal))

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

Hiroo> I agree with you it's good idea to add preference option to specify the
Hiroo> default library file for any OSs.  I can do that easily.

It's in head.
-- 
Hiroo Hayashi

Re: file access (Re: [Jsynthlib-devel] JSynthLib-0.20.0 is released)

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

Thorsten> > It's actually very easy, Java already has the hooks.  For MIDIboxFM, 
Thorsten> > you'd use:
Thorsten> >     algIcon[0]=new 
Thorsten> > ImageIcon(MIDIboxFMDevice.class.getResource("images/alg_0.gif"));
Thorsten> > 
Thorsten> > You can use device.getClass() instead if you want.

I prefer

        algIcon[0] = new ImageIcon(getClass().getResource("images/alg_0.gif"));

because it is shorter.  I've updated programming.html and
YamahaTX81zSingleEditor.java which is refereed by programming.html.

Thorsten> I've commited the changes - can anybody tell me how I can bring this
Thorsten> also into the the branch_0_20 (I'm not too lazy for reading the docs, I
Thorsten> just don't want to make anything wrong ;-)

I'll take care of branch_0_20.  Could anyone volunteer to fix other
synthdrivers?

Thanks.
-- 
Hiroo Hayashi

Re: file access (Re: [Jsynthlib-devel] JSynthLib-0.20.0 is released)

[Thorsten K. <Tho...@gm...>]

On Sunday 06 March 2005 22:48, Bill Zwicky wrote:
> It's actually very easy, Java already has the hooks.  For MIDIboxFM, 
> you'd use:
>     algIcon[0]=new 
> ImageIcon(MIDIboxFMDevice.class.getResource("images/alg_0.gif"));
> 
> You can use device.getClass() instead if you want.

thank you - it works!

I've commited the changes - can anybody tell me how I can bring this
also into the the branch_0_20 (I'm not too lazy for reading the docs, I
just don't want to make anything wrong ;-)

Best Regards, Thorsten.

[Jsynthlib-devel] GIFs are corrupt?

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

My Eclipse is telling me that all the MIDIboxFM gifs are in ASCII mode, 
and indeed many of them are corrupt on my machine.  Can someone delete 
and re-add these as binary?  You'll probably have to do this for every 
image in JSynthLib.

Thanks!
-Bill

Re: file access (Re: [Jsynthlib-devel] JSynthLib-0.20.0 is released)

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

Thorsten Klose wrote:

>Isn't there a simpler method? So far I can see this would require some
>lines of code to derive the filename, load the file into a buffer and 
>forward it to ImageIcon() - and it would require an error handling.
>  
>
It's actually very easy, Java already has the hooks.  For MIDIboxFM, 
you'd use:
    algIcon[0]=new 
ImageIcon(MIDIboxFMDevice.class.getResource("images/alg_0.gif"));

You can use device.getClass() instead if you want.

-Bill

Re: file access (Re: [Jsynthlib-devel] JSynthLib-0.20.0 is released)

[Thorsten K. <Tho...@gm...>]

On Sunday 06 March 2005 17:09, Hiroo Hayashi wrote:
> I could find the method in trouble.  But I guess the method open file
> directly (?).  You have to open a file as DriverUtil.createNewPatch()
> does.
> 
>     InputStream fileIn = driver.getClass().getResourceAsStream(fileName);

ooof! 

Isn't there a simpler method? So far I can see this would require some
lines of code to derive the filename, load the file into a buffer and 
forward it to ImageIcon() - and it would require an error handling.

If there is no other way - how about a new util function in the core library?

I copied this part of code from the Yamaha driver, a "grep" tells me that
changes have to be made in:

   MIDIboxFM/MIDIboxFMDrumEditor.java
   MIDIboxFM/MIDIboxFMPatchEditor.java
   RolandJV80/RolandJV80PatchEditor.java
   WaldorfPulse/WaldorfPulseSingleEditor.java
   YamahaDX100/YamahaDX100SingleEditor.java
   YamahaFS1R/YamahaFS1RVoiceEditor.java
   YamahaTX81z/YamahaTX81zSingleEditor.java

Best Regards, Thorsten.

[Jsynthlib-devel] RolandMKS7 Driver+Editor

[federico <xa...@in...>]

here it is!

this editor works for all the three synth parts (in chord part noise is 
not available; i bass part some features are not present).
i know, it may be visually better, but this is my first test :))

if you have one Roland MKS-7 (or also a Juno106 or HS-60 *) please give 
it a try

* AFAIK they are the same synthesizer. mks7 is the rackmount version, 
with a juno106 multitimbral split in 4+2voices plus a bass voice)

there are alo 3 patches attached.

bye

-- 
Federico

Re: [Jsynthlib-devel] Complex sysex parameters

[federico <xa...@in...>]

Jeff Weber wrote:

>--- federico <xa...@in...> wrote:
>  
>
>>how can i make 4 different widgets that manipulate
>>the same param_number?
>>    
>>
>
>You can subclass a ParamModel and then make all four
>widgets use the subclassed ParamModel.
>
>Check out the AlesisDM5.BitModel. This is a ParamModel
>subclass that manipulates the individual bits of a
>single sysex byte. There is one additional parameter
>on the constructor, which is a bitmask. There are a
>bunch of public static final int definitions at the
>beginning. These are masks provided for the DM5. You
>specify one of these masks when you create the
>BitModel on your widget. You can copy this code and
>modify the masks for your own purposes. 
>
>  
>
>>please consider that if go to change octave range, i
>>should mask other 
>>bits, like this:
>> new_val = (old_val & 0x28) | (oct_range & 0x03)
>>to avoid re-setting to zero saw/pulse/chorus
>>    
>>
>
>This might be a little more complicated to answer. You
>could just use the BitModel subclass with a mask of
>00000111 and then have your widget pass values of 1,
>2, or 4. The easy way would be to use a
>ScrollBarLookupWidget or a KnobLookupWidget but that
>would limit you to those types of widgets. If you
>wanted to use a ComboBoxWidget (which I'm guessing
>would be a more appropriate choice), then you would
>have to further subclass BitModel to change the value
>0 to 1, 1 to 2, and 2 to 4.
>  
>
thanks a lot!
i am going to finish the editor...
maybe in two ours will be on the list

bye!

-- 
Federico

file access (Re: [Jsynthlib-devel] JSynthLib-0.20.0 is released)

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

Hi,

Thorsten> I noticed that the small images for waveforms and algorithms
Thorsten> are not displayed in the MIDIbox FM editor when JSynthLib
Thorsten> is started from the .jar file (java -jar JSynthLib-0.20.0.jar)
Thorsten> 
Thorsten> They are displayed when I unpack the .jar and start JSynthLib
Thorsten> with "java JSynthLib"

I could find the method in trouble.  But I guess the method open file
directly (?).  You have to open a file as DriverUtil.createNewPatch()
does.

    InputStream fileIn = driver.getClass().getResourceAsStream(fileName);

Don't ask me what this is.  I just know this works.

'driver.getClass()' can be replace by 'this.getClass()' (or 'this.class').

# This must be documented in programming.html.

Please try.

FYI. You can create jar file by doing;
        jar cmf misc/mainClass xxx.jar @misc/MANIFEST
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Complex sysex parameters

[Jeff W. <jww...@ya...>]

--- federico <xa...@in...> wrote:
> how can i make 4 different widgets that manipulate
> the same param_number?

You can subclass a ParamModel and then make all four
widgets use the subclassed ParamModel.

Check out the AlesisDM5.BitModel. This is a ParamModel
subclass that manipulates the individual bits of a
single sysex byte. There is one additional parameter
on the constructor, which is a bitmask. There are a
bunch of public static final int definitions at the
beginning. These are masks provided for the DM5. You
specify one of these masks when you create the
BitModel on your widget. You can copy this code and
modify the masks for your own purposes. 

> please consider that if go to change octave range, i
> should mask other 
> bits, like this:
>  new_val = (old_val & 0x28) | (oct_range & 0x03)
> to avoid re-setting to zero saw/pulse/chorus

This might be a little more complicated to answer. You
could just use the BitModel subclass with a mask of
00000111 and then have your widget pass values of 1,
2, or 4. The easy way would be to use a
ScrollBarLookupWidget or a KnobLookupWidget but that
would limit you to those types of widgets. If you
wanted to use a ComboBoxWidget (which I'm guessing
would be a more appropriate choice), then you would
have to further subclass BitModel to change the value
0 to 1, 1 to 2, and 2 to 4.


	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/