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

[Jsynthlib-devel] TC Electronic G-Major

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

There's a tarred version available of the synth driver.
https://sourceforge.net/tracker/index.php?func=detail&aid=1156735&group_id=41208&atid=430007

Let me know what you think. I'm open to any suggestions.

Regards,
Ton Holsink

Re: [Jsynthlib-devel] Re: GPL copyright notice

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

Bill Zwicky wrote:

> Who should get the copyright for the files I've modified?  The editor 
> is safely mine, but the device and driver had other names before I 
> started.

i'm sorry, i forgot to mention previous authors of the editor... really 
i started from Roland MKS-50 Editor and made some quick search&replace 
before sending my mods.
i noticed that they miss the GPL header too, so i was thinking it is 
added automatically by the cvs server.

i apologize for my missing cvs knowledge, but at this time i really have 
other things to do than read the cvs documentation :)
i just wanted the f**in' mks7 editor become real :D
you can add my name or not, i don't mind.
i'm happy if you do :)

bye!
-- 
Federico

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

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

>
>
>> There's one question though:  Is the JSL driver set strong enough to 
>> make this automatic?  Can they create a patch from a random set of 
>> sysexs?  Or would we need a [Save as Patch] button so the user could 
>> tell JSL when one complete patch has been sent?
>
>
> I think that it might be. I don't know enough about it to be sure, but 
> I was thinking the same kind of thing. I was thinking that JSL could 
> have an "auto-receive" switch on a library window. Then, any sysex 
> that came in would be checked to see if any driver recognized it and, 
> if so, automatically put into the library. That way, you could just 
> turn it on and walk around the room sending stuff from all of your 
> synths.
>
> Or maybe a "semi-auto-receive", where it prompted the user first: "JSL 
> has just received a Kawai K4 Bank. Would you like to discard it or add 
> it to the current library?".
>
I haven't looked at the recieve code in a while, but there is an issue 
that needs to be resolved first. We need to resolve this anyway since I 
want to allow automated reception of patches for the SynthExplorer 
window I'm working on.

Originally, JSynthLib didn't track MidiIn ports for each device. Only 
the recieve window even dealt with MidiIn. So when you did a patch 
receive you would give the port you wanted to receive on, and then would 
always have to do the dump
manually from the synth. You would see bytes received and when you knew 
the dump was done, hit OK. At that point JSynthLib would look for a 
matching driver.

This was improved upon greatly several versions back by having JSynthLib 
track a MidiIn for each synth and to request patch dumps by selecting a 
Driver rather than a port. Now we know in advance what type of patch we 
are getting.
So the question then, can we figure a way to let the driver say, "This 
is enough, this patch is complete" So we don't have to count on the user 
to tell us?

My idea is this.  *Most* synths have a single F0 .. F7 pair in their 
sysex, and many have a constant known size. Maybe drivers could have a 
function like isFullPatch(Arry of Bytes), that the receive would call 
every so often.
The base Driver class would be set to just check for an F7. This way 95% 
of the drivers would remain the same. The remaining drivers would have 
to override this method.

Anyone willing to take a look into this. We also need to make sure to 
divorce the receive dialog from the actual recieve logic. We need to be 
able to call a Get function from anywhere, not just the dialog. 
Something lke

    doGetPatch (Driver , PatchNum) or doGetPatch (Driver, BankNum , 
PatchNum)


Brian

Re: [Jsynthlib-devel] Re: GPL copyright notice

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

Generally its not cool to remove someone elses name from the copyright 
line of a file, but If you've made substantial changes there's no problem
with adding your name to it. Having a name at the top of each file is 
just a formality for the GPL anyway. Realistically most files in JSynthLib
could be considered derrivative works of other files, so no one really 
owns a clean copyright to enough of JSynthLib to do anything with it
outside of the rights granted by the GPL.

Independant of the copyright is the authorsName field of drivers which 
is shown to users of the software if they look at the driver info.
Here anyone who has done substantial work on the driver can add their 
name after existing names. This isn't used for anything except bragging 
rights :)



Brian

Bill Zwicky wrote:

> Who should get the copyright for the files I've modified?  The editor 
> is safely mine, but the device and driver had other names before I 
> started.
>
> -Bill
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>
>

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

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

>
> Do you know of any technical barrier to putting all of the various 
> checksum algorithms into one class, so that something like the 
> hypothetical EvenMoreConformingDriver could use something like:
>   setChecksumType(YAMAHA_PRE_1996);
> in the constructor? I didn't say *psychological* barriers.... I said 
> *technical*. :)

No. I think that would be a good idea if someone is willing to put in 
the time. The only barrier is how to get people to know which checksum 
to use. But if you know the different checksum types in use
and how to name them such that people will know which one to pick, 
please do. The major problem I've had so far is that most manuals don't 
say "We use the foo algorithm" for checksumming, they
usually just give the step by step algorithm. From a driver writers pov, 
I've found it easier just to take this algorithm from the manual and 
type it in for each driver, than to check all the other drivers already 
written
and try to figure which one is doing the same thing. If the checksum 
algorithms can really be boiled down to things like YAMAHA_PRE_1996, 
than that would be great.

Please note also that there is ongoing work to allow future drivers to 
be written as XML files which describe the device rather than having to 
write everything in java. If we are going to add some niceties to the 
driver writing
process it might be worthwhile to see how the niceties could be carried 
over such that they are available to XML drivers as well.

Brian

[Jsynthlib-devel] Suggestion for setBankNum

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

Hi,

currently setBankNum(int bankNum) in the core/Driver class only supports
bank changes with MIDI Controller 0 AND 32.
So a driver may have to overwrite it, e.g. if just Controller 0
is used for bank changes.

Therefore I have the following suggestion:

1.) A new method setBankChangeMethod(int method)
to define whether Controller 0 AND 32
or 0 alone or 32 alone should be used.

I don't know if any synth uses just Controller 32
but if it is so we can support it. :)

The code may look the following way:

/**
* Constant for using MIDI Controller 0 & 32 for bank changes
*/
public static final int BANK_CHANGE_METHOD_MSB_LSB =3D 0;
/**
* Constant for using MIDI Controller 0 for bank changes
*/
public static final int BANK_CHANGE_METHOD_MSB =3D 1;
/**
* Constant for using MIDI Controller 32 for bank changes
*/
public static final int BANK_CHANGE_METHOD_LSB =3D 2;

private int bankChangeMethod =3D BANK_CHANGE_METHOD_MSB_LSB;

protected final void setBankChangeMethod(int method) {
    this.bankChangeMethod =3D method;
}

protected void setBankNum(int bankNum) {
    try {
        ShortMessage msg =3D new ShortMessage();

        switch (this.bankChangeMethod) {
            case BANK_CHANGE_METHOD_MSB_LSB:
                msg.setMessage(ShortMessage.CONTROL_CHANGE, getChannel() =
- 1,
                    0x00, //  Bank Select (MSB)
                    bankNum / 128); // Bank Number (MSB)
                send(msg);
                msg.setMessage(ShortMessage.CONTROL_CHANGE, getChannel() =
- 1,
                    0x20, //  Bank Select (LSB)
                    bankNum % 128); // Bank Number (MSB)
                send(msg);
                break;
            case BANK_CHANGE_METHOD_MSB:
                msg.setMessage(ShortMessage.CONTROL_CHANGE, getChannel() =
- 1,
                    0x00, //  Bank Select (MSB)
                    bankNum); // Bank Number (MSB)
                send(msg);
                break;
            case BANK_CHANGE_METHOD_LSB:
                msg.setMessage(ShortMessage.CONTROL_CHANGE, getChannel() =
- 1,
                    0x20, //  Bank Select (LSB)
                    bankNum); // Bank Number (MSB)
                send(msg);
                break;
        }                              =20
    } catch (InvalidMidiDataException e) {
        ErrorMsg.reportStatus(e);
    }
}

Five minutes ago I thought this idea is very good.=20
Now I'm not shure anymore. ;)

What do you think?

Regards,
Joachim Backhaus

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

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

Bill Zwicky wrote:

> If the Driver can't request a patch, then you get a different diaglog:
>
> Please start manual patch dump.
> All dumps will be saved.
> [Done]

... or words to that effect. I'd be a little more explicit, like "Please 
manually send the patch(es) from your device. If you send multiple 
patches, they will each be added to the library separately".

> We might want want a Channel Number selector, if there might be stray 
> packets flying around the MIDI bus.

Doesn't JSL already keep track of the channel for each device?

> There's one question though:  Is the JSL driver set strong enough to 
> make this automatic?  Can they create a patch from a random set of 
> sysexs?  Or would we need a [Save as Patch] button so the user could 
> tell JSL when one complete patch has been sent?

I think that it might be. I don't know enough about it to be sure, but I 
was thinking the same kind of thing. I was thinking that JSL could have 
an "auto-receive" switch on a library window. Then, any sysex that came 
in would be checked to see if any driver recognized it and, if so, 
automatically put into the library. That way, you could just turn it on 
and walk around the room sending stuff from all of your synths.

Or maybe a "semi-auto-receive", where it prompted the user first: "JSL 
has just received a Kawai K4 Bank. Would you like to discard it or add 
it to the current library?".

- Joe

[Jsynthlib-devel] Re: GPL copyright notice

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

Who should get the copyright for the files I've modified?  The editor is 
safely mine, but the device and driver had other names before I started.

-Bill

Re: [Jsynthlib-devel] Re: Latest Roland MT-32 Editor

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

Hi Fred,

Fred> All source files contain the GPL copyright notice and are ready  to 
Fred> merge into the JSynthLib distribution. They should replace the previous 
Fred> version.
Fred> http://electrickery.xs4all.nl/digaud/mt32

I've imported your file on my environment and found your driver is using
deprecated methods and class (NameValue) on 0.20 release.  Those methods
are already removed from the files in CVS head.  So I cannot compile
your code.  Please make your code compile without deprecated warning
error with 0.20 release (or CVS head).  On each @deprecated javadoc tag,
there is description how to fix it.

Thanks.
-- 
Hiroo Hayashi

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

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

Joe Emenaker wrote:

> My primary example of a *missing* window is in the "Get" process. I 
> try to get a patch, and I see a window telling me that this driver 
> doesn't support patch requesting, so I should initiate a dump from the 
> device. And there's an OK button.

Yeah, that whole thing's pretty goofy.  But I think I have an even 
simpler proposal:

If Driver can request a patch, then you get:

Select patch
[Device       ]
[Driver        ]
[Bank         ]
[Patch         ]
[Get]   [Done]

[Paste] is redundant, since if the user clicks [Get], we know they want 
the patch, so we can just toss it into the library.  [Done] just closes 
the window, so [Cancel] is redundant too.

If the Driver can't request a patch, then you get a different diaglog:

Please start manual patch dump.
All dumps will be saved.
[Done]

That's it.  If JSL gets a sysex, it feeds it to a driver, gets the 
patch, and stuffs it into the library.  Again, if the window is open, we 
know the user wants to download patches, so other buttons are 
redundant.  We might want want a Channel Number selector, if there might 
be stray packets flying around the MIDI bus.

There's one question though:  Is the JSL driver set strong enough to 
make this automatic?  Can they create a patch from a random set of 
sysexs?  Or would we need a [Save as Patch] button so the user could 
tell JSL when one complete patch has been sent?

-Bill

Re: AW: AW: [Jsynthlib-devel] BankDriver requests

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

Joachim Backhaus wrote:

>Hi Steven,
>
>it may be helpful if you can post your code
>for retrieving the patch and for storing the patch.
>  
>
>>Yes, but I'm not sure what you mean by Bank E, Patch 9 is 
>>correct.  That 
>>*is* where it gets saved.
>>    
>>
>
>Yes, but is that correct? Is it what you want?
>Or do you want to have it saved to Bank G, Patch 10?
>
>How have you created the patch numbers?
>  
>
Well - it seems a bit different than I thought,  This time It saved what 
was in the edit buffer on the synth to the requested location, then went 
back to the GM patch behaviour.   I must be missing something that sends 
the patchlib patch.  MidiMonitor only shows the outgoing write request 
but no payload.  Here's the device and single driver files - nothing  
new in them.  Problems are in the send and store  methods.  Retrieving 
works perfectly.
Thanks!

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

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

Brian wrote:

>>
>> For a real-world example, tell me how many of JSL's current 
>> synthdrivers set their "sysexID" variable to a string that does NOT 
>> begin with "F0"? I haven't stumbled across any yet. In fact, how many 
>> deviate from the "[F0][ManufacturerID][DeviceID][payload][F7]" 
>> format? Every device I currently own conforms to this message style. 
>> Yet, every JSL driver has to manually craft sysex messages itself. 
>> How many of the current drivers, do you estimate, all have an, 
>> essentially, identical bit of code in createNewPatch which takes the 
>> data of the patch and just slaps the F0 and the manuf and device ID's 
>> on the beginning and the F7 on the end?
>
>
>
> Alot  do, actually a lot of synths have pretty complex "Default 
> Patches", so the drivers actually store a dump of a "Default Patch" in 
> a file and load it in when create new patch is performed.
>
>>
>> Right! JSL asked for a sysex message, and that's all that it grabs 
>> off of the wires. What I'm getting at is that, a vast majority of the 
>> time, JSL might as well lop the F0 and the F7 and give the driver the 
>> stuff inside.
>
> I dunno. Some synths have a patch dump made up of multiple F0..F7 
> pairs. For example, the Boss DR-660 Driver, a patch is actually i 
> think 14 sysex messages sent in quick succession. Lopping off the 
> first and last byte but leaving the others in place would be kind of 
> odd and it would be a nightmare to have to insert a bunch of F0 and 
> F7's all throughout the patch in order to send or receive data. 
> Especially since not all the sub-messages have a fixed size.

Two things:
1 - If the driver receives multiple F0...F7 pairs, then you could lop 
the F0's and F7's off of all of them and the driver could just get an 
array of sysex payloads. I dunno. The more we discuss stripping the 
F0/F7, the more I think "This is silly to raise such a fuss over just 
two bytes". The two arguments I have in support of raising a fuss. 
First, I suspect that a majority of the drivers all have code to 
strip/disregard those bytes on incoming messages and to replace them on 
outgoing ones. Each time someone does it, it raises the possibility of a 
bug and it contributes to code-bloat. The second argument is that, the 
first time I ever looked at an existing driver (as the programming.html 
suggested), the first thing I saw at the top of the file was a 
fully-formed sysex ID string. The thought that went through my mind 
"Wait a minute... I thought the whole point of the design was to 
*insulate* me from the minutae of sysex and allow me to just deal with 
the data *within* the sysex messages.". As a programmer, it caused me to 
have doubts about the wisdom of the design of the program... which made 
me reluctant to invest much effort in learning how to code for it. In 
short, I think looking at current driver implmentations could be scaring 
some potential developers away.

2 - I'm not saying that we have to make every driver use some new 
design. That's what sublcassing is for. Imagine having Driver, with its 
complicated way of doing things. You could make a subclass of that 
called, say, MoreConformingDriver, which is designed for patch dumps 
with a single sysex message which have [F0][data][F7] format and the 
programmer just deals with that [data]. Then, you could have a subclass 
of *that* called EvenMoreConformingDriver, which is just like its 
superclass, but deals with patch dumps of the format 
[F0][ManufacturerID][DeviceID][data][F7] and, again, the programmer just 
deals with the [data] part and everything else is handled transparently.

Now, from what you tell me, it sounds like the Boss DR-660 wouldn't be 
able to make use of EvenMoreConformingDriver. Fine. It would continue to 
subclass Driver. However, I think that it would save a lot of coding 
(and look more inviting to potential new developers) if driver 
constructors contained a few simple commands like I'm doing with the 
driver I'm working on:

   setManufacturerID("00000E");
   setDeviceID("05");
   setDecodingType(ALESIS);

Just those three commands, and then my createNewPatch and editPatch 
methods get to just deal with the (decoded to 8-bit) bytes after the 
DeviceID and before the F7. Heck, someone could make a subclass of 
*that* called "EvenMoreConformingAlesisDriver" and then all you'd need 
to do is set your deviceID!

Maybe it's just me... but I feel that, if you're writing for a device 
that is fairly standard, then subclasses like this could save a lot of 
time, because you only deal with the level of complexity that you need to.

> I think It's easier to tell a driver writer, whatever bizzare data 
> your manufacture prepends to the patch, insert that here... and have 
> it always work, then have to explain put your manufactuer ID here, 
> your device ID here, this is the standard sysex representation of that 
> data, if your synth doesn't use that than subclass this instead

One thing that I find disconcerting, however, is the fact that it's not 
easy to know what data elements you have to set. For example, while 
writing my driver, I tried to "Get" a patch... and I got an exception 
thrown. After I hunted around, I figured out that it was because I 
hadn't initialized "String[] patchNames". Well... how silly of me! 
*Everybody* knows that you have to initialize patchNames. :P

So, I think that it would make driver development a little smoother if 
it were easier to know what info you needed to provide for things to 
work. One idea would be to have EvenMoreConformingDriver an abstract 
class and to make some abstract methods for getDeviceID and 
getManufacturerID. Then, if you try to subclass it, you'll get compile 
errors if you don't implement them. This is good for two reasons: First, 
compile-time errors are generally better than runtime-errors since the 
*user* can't encounter a compile-time error, and secondly, because it 
would be easier for the developer to tell, from the error, what the 
problem was. Of course, using abstract classes is just one possiblity. 
Maybe it could be done with interfaces... I dunno. But you get the idea.

> Plus I would hate to write an editor where I had to worry that what 
> the manual was calling byte number 55, was actually byte number 48 in 
> the array I was passed because some stuff had been stripped off the front.

I've got the opposite problem, where my spec calls the byte after the 
deviceID "byte 0". So, nyeah! :)

> That said, it is a good idea to look back occasionally at what has 
> evolved and look to see if it can be refactored without losing anything.

And keep in mind that I'm willing to put in a lot of effort to aid any 
refactoring. I'm not the kind to say "This all sucks... you guys fix it 
and call me when you're done.". If it is decided to make a change, I'll 
be the first one diving in to help convert old stuff so that it works 
with the new stuff, if need be.

> One example of this, is that we provide a default "Compute Checksum" 
> method so that many synths don't have to implement it themselves, but 
> if (again all to commonly) the synth uses some other approach to 
> checksum computation or even uses multiple checksums (again way too 
> common), the author can override this.

Do you know of any technical barrier to putting all of the various 
checksum algorithms into one class, so that something like the 
hypothetical EvenMoreConformingDriver could use something like:
   setChecksumType(YAMAHA_PRE_1996);
in the constructor? I didn't say *psychological* barriers.... I said 
*technical*. :)

- Joe

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

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

Brian wrote:

> For every person like you who comes on the developer's list and 
> complains loudly about something, there are hundreds more who just 
> silently hit the delete key.

Oh man.... I think I just heard angels singing. :)

> I'm not going to remove the ability to have patches from different 
> synths in one library simply because I'm not about to remove a feature 
> that I and many other people find useful and commonly use. Removing 
> this feature would destroy the ability to emulate *my* preferred 
> workflow in JSynthLib.

Well, I believe I already acknowledged that I could see the usefulness 
of that... and that it should be retained in any future interface. So, I 
don't say it should be tossed. I'm just saying that the user probably 
shouldn't encounter it so early in the experience.

As an example, I remember one time I tried JSL years ago. I managed to 
add some synths, make a new library and then I added a patch bank. Then 
I added another... and another. The thought that went through my head 
was "I *know* I don't have this many banks on my synth.... so which 
one(s) are the ones on my synth?"

> Give me some time to work up some interface mockups-- You'll have a 
> chance to complain about them too. :-)

Oh... ouch! :)

>> I just think that a lot of it is unintuitive. There are a lot of 
>> windows that the user sees that they don't need to.... there are some 
>> that they should see but don't, and the overall UI interaction, 
>> although I agree that it can be learned, is not very natural.
>
> I can see what windows you think the user needs that we don't offer, 
> but what windows that we do expose to the user do you think should be 
> hidden?

My primary example of a *missing* window is in the "Get" process. I try 
to get a patch, and I see a window telling me that this driver doesn't 
support patch requesting, so I should initiate a dump from the device. 
And there's an OK button.

Well, do I click OK *before* I initate the dump or *after*? At what 
point is JSL listening for sysex? (Yes, I know I can go look in the 
source and find out, but I'm speaking in the voice of the newbie user 
here). So, I do some combination of OK and patch dump from the device, 
and I am returned to the original patch-request dialog. Seemingly, 
nothing happened at all. However, if I look carefully, I notice that 
there's a subtle change: There's now a little text label saying "1430 
bytes received". Oh! Okay... I guess JSL got something. So I click okay 
and, hey... there's my patch!

Now, I managed to stumble my way through it by trying a couple of 
different combinations and by paying close attention to changes in the 
dialog box that I was returned to. Now, imagine the process with a 
*single* dialog added and some working changed:

User decides to get a patch and there's no patch requester for it. User 
gets a dialog saying "This driver doesn't support requesting of patches. 
You'll have to send the patch from the device manually. Please click 
'OK' to begin listening for the data, *then* initiate a patch dump from 
the device". (Notice that the sequence of the OK and the patch dump is 
explained).

*Then*, the user gets the new dialog. It's titled "Waiting for patch 
dump...", has a label in it saying "0 bytes received", and there's an OK 
(or "Done Sending") and a Cancel button. If I have to explain what the 
two buttons do, then I need to go back an redesign the dialog. :)

My example of a *unnecessary* dialog are the ones that say "Ooops! This 
driver doesn't support blah blah blah". I *think* it was when I tried 
"Store" or "Send" or something with the driver I'm writing. Obviously, I 
shouldn't have been *offered* to store or send. This probably isn't a UI 
design issue as much as I suspect the way that JSL decides what a driver 
can do. It *looks* like the Driver class is trying to use inspection 
methods to figure out if a given driver implements certain methods... 
and that it's mis-reading something. I don't know why Driver uses 
inspection instead of interfaces (whose primary purpose is to signify 
implementation of methods), but I imagine I'm about to find out. :)

- Joe

Re: [Jsynthlib-devel] Re: two bugs

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

>>
>> F0
>> <id:roland>
>> <model:mks7>
>> <opcode:param_change/tone_change>
>> <midi channel>
>> <data ...>
>> F7
>>
>
> Is the <midi channel>  different for each part? 

yes

> If so and <opcode> is a fixed size, you could write a SysexID that 
> would only match the correct patches that want on that channel.
>
note: the channel should remain user-configurable.
forcing to channels 1, 2 and 3, make the patch not-portable (by the 
driver implementation)

> We need to figure out an interface that would allow multiple synths of 
> the same type to work better than they do now without hardcoding midi 
> channels or ports or anything, since these are setup dependant and 
> could be changed when
> the library is re-opened.

possible solution: add a column (a field) in the patchlib db to force 
the SynthID value to match that specified in the driver settings.

if this field is empty, then the SynthID is guessed from sysex header.
if this field is set, try to match it with SynthID in the driver's 
preferences.
if the match fails, fall back to automatic SynthID guessing.

> PatchLibs  /SceneLibs could store some sort of driverID unique to your 
> setup with each patch that could be either set or blank. If it is set, 
> that driver is used, if it is blank or if the driverID does not exist, 
> JSynthLib sets the driver using
> the SysexID.

i guess we are talking about the same thing :-D

> The driverID would be kind of a cache for the results of the patch 
> assign process which is also modified by the "Reassign" command.

i think this is the better solution.
let's wait for other's opinions

-- 
Federico

Re: [Jsynthlib-devel] Re: two bugs

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

>
>
>>
>
> as i said, dev_id and midi_ch are set to the same number, which is the 
> midi channel.
> here is the MKS7 sysex header (one byte per line):
>
> F0
> <id:roland>
> <model:mks7>
> <opcode:param_change/tone_change>
> <midi channel>
> <data ...>
> F7
>

Is the <midi channel>  different for each part? If so and <opcode> is a 
fixed size, you could write a SysexID that would only match the correct 
patches that want on that channel.

Basically you would have two different Devices, one for the Juno 106 
which would contain one SingleDriver w/ the <midi channel> always set to 
whatever the setting in preferences was.

You would have one device for the Mk& which would contain three copies 
of the single driver which would all be the same except rather than just 
all using the setting from preference, they
could either be set via their configuration screen, or just use the 
setting in preferences for the first, preferences +1 for second and 
preferences +2 for third.

This might be a good short term solution.

> when you turn on the device, melody is channel 1, bass is channel 2, 
> chord is channel 3 (however you change them with a button) and there 
> isn't other method to distinguish parts.
>
> i thought another approach: make three tabs, one for part. but this 
> would drive into a  DOUBLE problem: conceptually doesn't exists 
> anymore the patch, but only the BANK concept, since the driver 
> controls an entire bank (bank on synthesizer, not a jsl's bank); you 
> can't specify three midichannels in the driver's settings.
> so i decided to abandone this way.
>
> the really optimal way would be make possible to have many driver 
> instances (think the surreal situation in which you have 3 
> synthesizers, same brand, same model ;D) 


It is possible to have many driver instances, the issue is that 
.patchlib files are setup independant, that is you could write one on 
your computer, mail it to me and I should be able to open it. Even if I 
have different synths than you, if
one of mine is compatable with yours it should work. So if you were to 
create an MKS7 patch, save it, uninstall the Mks7 driver, install a Juno 
106 driver, and reopen the patch, JSynthLib would consider it a Juno106 
patch, then if you also
installed an MkS7 driver, you could reassign it and use it with either.

We need to figure out an interface that would allow multiple synths of 
the same type to work better than they do now without hardcoding midi 
channels or ports or anything, since these are setup dependant and could 
be changed when
the library is re-opened.

>
>
> maybe add a column to the patchlib database would solve the prbl, i.e. 
> a field to specify midi channel for a patch (uhm, this may be heavily 
> redundant).
> otherwise is it possible access FIELD1/FIELD2 from the editor/driver?

Adding a midi channel would make it non-portable between setups. Editors 
can not see field1/field2 because they only exist for Libraries. By the 
time an editor sees a patch, that patch could be in a library, or it 
could be in a scene, or a bank, neither
of which have a field1/field2 assigned to each patch.

As for the long term solution to the multiple device problem, I'm open 
to suggestions. Just to brain storm, how about this:

PatchLibs  /SceneLibs could store some sort of driverID unique to your 
setup with each patch that could be either set or blank. If it is set, 
that driver is used, if it is blank or if the driverID does not exist, 
JSynthLib sets the driver using
the SysexID. The driverID would be kind of a cache for the results of 
the patch assign process which is also modified by the "Reassign" command.

Brian




>
>
>
> about the midi problem, i quote here your message:
>
>> What platform are you using? (Operating System / Java Version / Midi 
>> Provider?
>>
> Linux 2.6
>
> java version "1.4.2-01"
> Java(TM) 2 Runtime Environment, Standard Edition (build 
> Blackdown-1.4.2-01)
> Java HotSpot(TM) Client VM (build Blackdown-1.4.2-01, mixed mode)
>
> Advanced Linux Sound Architecture Driver Version 1.0.7.
> Compiled on Mar  5 2005 for kernel 2.6.10-gentoo-r6.
>
> i access midi through the /dev/snd/midi* and /dev/midi* devices.
>
>

Re: [Jsynthlib-devel] Re: two bugs

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

Brian wrote:

> JSynthLib does not play nice with having more of one of the same 
> synthesizer.

d'oh! :-O

> Menu. This will assign the patch to a different instance of the synth. 
> However, you would have to do this each time you load a library.

yes, it's terrible! :-)

> As for your specific case its a little differnt, you don't have three 
> different synths, but one synth with different midi channels that
> you want to use. What is the ID field you are talking about that 
> contains "MKS-7-B", etc. Is this a part of the actual sysex for the MK-7?

no. it is the Synth ID i given to the three instances of driver.
the midi channel and the device id are set to the mks's receiving midi 
channel

> Is there someway that it is possible to tell which part 
> (chord,melody,bass) a patch belongs in based on looking at the patch?

as i said, dev_id and midi_ch are set to the same number, which is the 
midi channel.
here is the MKS7 sysex header (one byte per line):

F0
<id:roland>
<model:mks7>
<opcode:param_change/tone_change>
<midi channel>
<data ...>
F7

when you turn on the device, melody is channel 1, bass is channel 2, 
chord is channel 3 (however you change them with a button) and there 
isn't other method to distinguish parts.

> If so,
> maybe you could have the MK7 Device have three drivers each being 
> identical except having a sysex_id that will only match the
> patches which should be for that part? That would be the optimal way 
> to do it.
>
uhm i think it is not possible (see above)

i thought another approach: make three tabs, one for part. but this 
would drive into a  DOUBLE problem: conceptually doesn't exists anymore 
the patch, but only the BANK concept, since the driver controls an 
entire bank (bank on synthesizer, not a jsl's bank); you can't specify 
three midichannels in the driver's settings.
so i decided to abandone this way.

the really optimal way would be make possible to have many driver 
instances (think the surreal situation in which you have 3 synthesizers, 
same brand, same model ;D)

maybe add a column to the patchlib database would solve the prbl, i.e. a 
field to specify midi channel for a patch (uhm, this may be heavily 
redundant).
otherwise is it possible access FIELD1/FIELD2 from the editor/driver?



about the midi problem, i quote here your message:

> What platform are you using? (Operating System / Java Version / Midi 
> Provider?
>
Linux 2.6

java version "1.4.2-01"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-01)
Java HotSpot(TM) Client VM (build Blackdown-1.4.2-01, mixed mode)

Advanced Linux Sound Architecture Driver Version 1.0.7.
Compiled on Mar  5 2005 for kernel 2.6.10-gentoo-r6.

i access midi through the /dev/snd/midi* and /dev/midi* devices.


-- 
Federico

Re: [Jsynthlib-devel] two bugs

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

>
>
>>
>> 2) it happens sometimes that JSL stop receiving (or transmitting... i 
>> don't know) MIDI from the master keyboard.
>> i have to open Preferences->MIDI, make some change, undo it, and 
>> apply. this solves the problem.
>

What platform are you using? (Operating System / Java Version / Midi 
Provider?

Thanks

[Jsynthlib-devel] Re: two bugs

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

federico wrote:

> 1) the MKS7 driver i just developed, controls only one timbral part.
> to get control of all three parts (chord,melody,bass), i have to 
> create 3 driver instances, with 3 different IDs and MIDICHANs.
>
> so i created patches with ID 'MKS-7-B','MKS-7-M','MKS-7' (for the main 
> part).
> but when i save patchlib, close and reopen it, all sounds get remapped 
> to the main id ('MKS-7').
>
> i guess this ID is not stored in the file, so gets matched by the 
> sysex_id of the driver...
> or otherwise please enlighten me.



JSynthLib does not play nice with having more of one of the same 
synthesizer. Origionally this did not work at all. Now it works, but
not in the best way possible. Basically you are correct. When you open a 
patchlib everything is matched by the sysex_id of the driver,
so the first driver loaded gets assigned all the patches. To change 
which driver gets the patch, you have to use "Reassign" in the Patch
Menu. This will assign the patch to a different instance of the synth. 
However, you would have to do this each time you load a library.

As for your specific case its a little differnt, you don't have three 
different synths, but one synth with different midi channels that
you want to use. What is the ID field you are talking about that 
contains "MKS-7-B", etc. Is this a part of the actual sysex for the MK-7?
Is there someway that it is possible to tell which part 
(chord,melody,bass) a patch belongs in based on looking at the patch? If 
so,
maybe you could have the MK7 Device have three drivers each being 
identical except having a sysex_id that will only match the
patches which should be for that part? That would be the optimal way to 
do it.

Brian

[Jsynthlib-devel] two bugs

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

1) the MKS7 driver i just developed, controls only one timbral part.
to get control of all three parts (chord,melody,bass), i have to create 
3 driver instances, with 3 different IDs and MIDICHANs.

so i created patches with ID 'MKS-7-B','MKS-7-M','MKS-7' (for the main 
part).
but when i save patchlib, close and reopen it, all sounds get remapped 
to the main id ('MKS-7').

i guess this ID is not stored in the file, so gets matched by the 
sysex_id of the driver...
or otherwise please enlighten me.

2) it happens sometimes that JSL stop receiving (or transmitting... i 
don't know) MIDI from the master keyboard.
i have to open Preferences->MIDI, make some change, undo it, and apply. 
this solves the problem.

i cannot give steps to reproduce the problem because it happen randomly.

thanks
-- 
Federico

Re: [Jsynthlib-devel] MIDI SDS (sample dump standard)

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

Brian wrote:

> It's something we need. I have an Akai S2000 (which I'm selling) and 
> my main synth now is a Kurzweil K2600S. Both support SDS.
> I think to handle samples we need some interface improvements first.

not necessarily.
at least, not for now.
i don't want to turn JSL into a sound editor. there are plenty of sound 
editor, that you can pick up the right one for you :)
the primary goal is make the sample transfer work (also a waveform_view 
widget would be nice, and a file-selector obj is pretty necessary).

to achieve this i agree that should be planned some additional interface 
in the JSL core (i talk about data transmission flow).
the main information i collected about SDS is that supports two types of 
transmission: with handshaking and without it.

the handshaking version is more complex, because require a sorta of 
client/server communication (you use both midi in and midi out), an 
abstraction of packets, time waits, crc checks, abort, maybe it requires 
threading, etc...

on the other hand, direct version (non-handshaking) sends a sample in 
one way, withouth checking it's integrity nor syncing with the 
synthesizer, so to avoid buffer underruns, you have to put pauses in 
your dump (generally more than the needed), slowing the dump procedure.

unfortunately i cannot find so much information about the 
non-handshaking method, so i guess it applyes only the midi-out part of 
handshaking dump.
even if is not adviceable to use the non-handshk method, i think 
actually is only possible to implement this last one.

maybe we should give the user some interface to tweak the timing of 
these dumps... ;)
sure it needs some more accurate study of the point.

here you can find some resources about midi SDS:
http://www.borg.com/~jglatt/tech/sds.htm
http://www.omega-art.com/midi/msds.html

historical article about sds:
http://web.inter.nl.net/hcc/davies/samk0789.html

sds-program with sources:
http://www.geocities.com/leibowitz.geo/midi_sds.html

> P.S. Does anyone know where I can get a good sysex spec for the K2600? 
> I've been trying and so far I've struck out. Even K2500 would be Ok, 
> as K2600 is just a superset. I just want to get something started.

i found those archives of kurz-list. try do a search inside ;)
www.google.com/search?q=site%3Akurzlist.sonikmatter.com+txt

helo
-- 
Federico

Re: [Jsynthlib-devel] MIDI SDS (sample dump standard)

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

It's something we need. I have an Akai S2000 (which I'm selling) and my 
main synth now is a Kurzweil K2600S. Both support SDS.
I think to handle samples we need some interface improvements first. You 
don't want to just shove samples into Libraries.

Joe, how does MidiQuest handle this?


P.S. Does anyone know where I can get a good sysex spec for the K2600? 
I've been trying and so far I've struck out. Even K2500 would be Ok, as 
K2600 is just a superset. I just want to get something started.

Brian

federico wrote:

>    is there someone working on some SDS drver?
>
> as now, the only driver i miss is the one for Akai S1000.
> would be great develop at least a generic SDS driver: this is useful 
> to transfer samples to samplers via midi.
>
> the really great job would came specializing that generic SDS-driver 
> class, to support specific features of samplers.  ...although i'm 
> pretty busy now because school & work, and s1000's sysex 
> implementation is quite complex.... so i prefer working on something 
> more useful and generic, so i am asking here if there are sampler's 
> users that are interested ;)
>

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

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

 >OK, I must admit that I at least didn't really understand
> what you really want to improve on the JSynthLib GUI.


I think I have a pretty good idea of where he's going with this. I plan 
 to write a semi-functional interface mockup and post
 either screen shots or actual java code so we can discuss it further on 
 list. Hopefully I'll have something next week, but
 I'm notoriously bad around here with getting stuff done when I want to.  
 Right now I have a little free time to work on this
 stuff, but at any time  something can pop up at work and I'm back to 
 crazy hours again. With some luck though, I'll have a
 mockup done soon.

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

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

>
> Lastly, I wasn't (and still am not) certain that there's even a 
> readiness to discuss a different interface.


True, we are not willing to shutdown JSynthLib and start up a 
JSoundDiver. Nor do we all agree with you that the SoundDiver/Midiquest 
interface is good and the JSynthLib interface is bad. I've used 
SoundDiver and Midiquest and found
their interfaces intrusive and annoying. Though I must admit I was able 
to figure out how they worked easily, I quickly came to regret that they 
worked that way.  This was before I began JSynthLib, so its not a matter 
of liking what I'm used to
either.

Still, you've made it clear that there exists a prefered workflow for 
many people where that kind of interface is preferred. In addition, I 
see that that this way of working is not easy to emulate in JSynthLib's 
current interface. This is a problem.  For every person like you who 
comes on the developer's list and complains loudly about something, 
there are hundreds more who just silently hit the delete key.

So while I don't think we are about to *change* our interface, I do 
think we can *augment* and *improve* it. There are fights you aren't 
going to win here :-). I'm not going to remove the ability to have 
patches from different synths in one library simply because I'm not 
about to remove a feature that I and many other people find useful and 
commonly use. Removing this feature would destroy the ability to emulate 
*my* preferred workflow in JSynthLib.

Still, I agree with some of your points and have some ideas of how we 
can have our cake and eat it to. We can develop an interface that we 
both can like. Give me some time to work up some interface mockups-- 
You'll have a chance to complain about them too. :-)


> I just think that a lot of it is unintuitive. There are a lot of 
> windows that the user sees that they don't need to.... there are some 
> that they should see but don't, and the overall UI interaction, 
> although I agree that it can be learned, is not very natural.


I can see what windows you think the user needs that we don't offer, but 
what windows that we do expose to the user do you think should be hidden?

>
> In that light, I think it's safe to say that anybody who currently 
> chooses to use JSL over something like MidiQuest is probably because 
> it's free. And the primary alure of one's product being the fact that 
> you're giving it away isn't exactly a flattering testament.


Most definately some do use it for that reason, but I really don't think 
its the major cause. Someone who is willing to pay thousands of dollars 
for a synthesizer isn't going to use a program the hate just to save a 
couple hundred bucks. People use JSynthLib because it gets the job done 
for them and does what they want it to. JSynthLib isn't nearly as flashy 
as the commercial Librarians, nor does it have all the features and 
support all the synths they do. But for many people, JSynthLib
gets the job done for them, so they use it. I think the primary alure of 
JSynthLib is that its 'good enough'. Would I like JSynthLib to compete 
directly with SoundDiver and MidiQuest on features and abilities? Sure, 
and if someone wanted to give
us the same budget they have, we could do it. None of us work on 
JSynthLib full time, its always a few hours here or there that I'm able 
to sit and look at it. This has two effects, first it slows development 
down, and second, people tend to work on particular features they are 
interested in their limited time rather than doing some of the more 
boring but necessary code mainenance. Still, I'm very happy with where 
JSynthLib stands today. We are way beyond any other attempts at a free 
universal librarian/editor. JSynthLib is widely used, and many people 
find it useful.

The Commecial's definately do have some advantages over us, so what are 
our advantages over them?

    1st) Like you said, we kick their asses in the price department :)

    2nd) We support Linux. Many of our developers and users are on Linux 
Platforms. We kick all their asses on Linux. They don't even run :)

    3rd) We give away source code. Don't like something, feel free to 
change it. If others like the change, you can even get it incorporated 
into the standard code base.
             
    4th) Its permament. If Apple decides to do way with SoundDiver, 
thats it. No More SoundDiver.No new versions. As long as someone remains 
interested in JSynthLib ,it will continue to be improved.
             Even if all the current developers were to leave and move 
on, any one else could come in and continue development. They have the 
source, and more important, our license gives them the right to do so.

    5th) Half the fat and calories of SoundDiver!

Brian

[Jsynthlib-devel] MIDI SDS (sample dump standard)

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

    is there someone working on some SDS drver?

as now, the only driver i miss is the one for Akai S1000.
would be great develop at least a generic SDS driver: this is useful to 
transfer samples to samplers via midi.

the really great job would came specializing that generic SDS-driver 
class, to support specific features of samplers.  ...although i'm pretty 
busy now because school & work, and s1000's sysex implementation is 
quite complex.... so i prefer working on something more useful and 
generic, so i am asking here if there are sampler's users that are 
interested ;)

-- 
Federico

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

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

>
> For a real-world example, tell me how many of JSL's current 
> synthdrivers set their "sysexID" variable to a string that does NOT 
> begin with "F0"? I haven't stumbled across any yet. In fact, how many 
> deviate from the "[F0][ManufacturerID][DeviceID][payload][F7]" format? 
> Every device I currently own conforms to this message style. Yet, 
> every JSL driver has to manually craft sysex messages itself. How many 
> of the current drivers, do you estimate, all have an, essentially, 
> identical bit of code in createNewPatch which takes the data of the 
> patch and just slaps the F0 and the manuf and device ID's on the 
> beginning and the F7 on the end?


Alot  do, actually a lot of synths have pretty complex "Default 
Patches", so the drivers actually store a dump of a "Default Patch" in a 
file and load it in when create new patch is performed.

>
> Right! JSL asked for a sysex message, and that's all that it grabs off 
> of the wires. What I'm getting at is that, a vast majority of the 
> time, JSL might as well lop the F0 and the F7 and give the driver the 
> stuff inside.

I dunno. Some synths have a patch dump made up of multiple F0..F7 pairs. 
For example, the Boss DR-660 Driver, a patch is actually i think 14 
sysex messages sent in quick succession. Lopping off the first and last 
byte but leaving the
others in place would be kind of odd and it would be a nightmare to have 
to insert a bunch of F0 and F7's all throughout the patch in order to 
send or receive data. Especially since not all the sub-messages have a 
fixed size.

> Why am I telling you this? I'm not sure. I doubt anybody else is going 
> to use it because it's not the established JSL way. I guess I'm just 
> hoping that somebody else will see that doing it this way is A) 
> simpler and less prone to mistakes, and B) applicable to probably 75% 
> or more of the devices we'll come across (and the remaining 25% are 
> still free to use subclass Driver directly).


I appreciate what you are trying to do, but belive me, you are making 
things much harder on yourself by doing this. This kind of thing always 
seems like it would be simpler, but it ends up causing problems. There 
are many different interfaces and API's JSynthLib has to support for 
patches. In every case, whenever I tried to design something clever to 
make driver writing easier, it ended up making things more complicated 
because some synth manufacturer did some attrocious thing with their 
sysex spec. I think It's easier to tell a driver writer, whatever 
bizzare data your manufacture prepends to the patch, insert that here... 
and have it always work, then have to explain put your manufactuer ID 
here, your device ID here, this is the standard sysex
representation of that data, if your synth doesn't use that than 
subclass this instead.... True it would make it a tiny bit easier in 75% 
of the cases, but it would make things a nightmare for the other 25%.

Please understand that we have an "established JSL way" not because we 
want to be subborn or because we want to make your life more difficult 
but because our way works for all supported synths. Collectively, we 
have written
driviers for over fify synthesizer models. The interfaces and paradigms 
evolve over time as one after another any pleasing abstraction we use 
gets smashed by some amazingly atrocious sysex spec which goes ahead and 
does something completely incompatable with our assumptions and 
abstractions. In truth, I fear any abstraction at a higher level than "A 
patch is an array of bytes." Is going to be violated by some as of yet 
unsupported synth.

Plus I would hate to write an editor where I had to worry that what the 
manual was calling byte number 55, was actually byte number 48 in the 
array I was passed because some stuff had been stripped off the front.

That said, it is a good idea to look back occasionally at what has 
evolved and look to see if it can be refactored without losing anything. 
We've been doing this for quite some time. If you think the current 
source is driving you insane,
go find a copy of version 0.16.  Helper classes which make the common 
case easier to implement are a *good thing* as long they are easy and 
intuitive to work around in the (unfortunately all to common) case where 
a synth spec
refuses to cooperate. One example of this, is that we provide a default 
"Compute Checksum" method so that many synths don't have to implement it 
themselves, but if (again all to commonly) the synth uses some other 
approach to
checksum computation or even uses multiple checksums (again way too 
common), the author can override this. I don't think that having to 
subclass a different version of driver just to work around some simple 
thing is viable.

Brian