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

[Jsynthlib-devel] Re: MIDI problem

[Rib R. <ri...@gm...>]

I tried CAProvider and the looping problem goes away, but it randomly
crashes.  Bahh.  Does anyone else have this problem with PlumStone?


On Tue, 15 Mar 2005 17:10:36 -0800, Rib Rdb <ri...@gm...> wrote:
> I just tried testing the XML editor with my Motif and I can't get the
> MIDI to work.
> When I try to request a patch, JSynthLib says it receives 8 bytes. But
> those 8 bytes are just my request.  JSynthLib never really transmits
> any data to the midi device.
> 
> Does anyone else have this problem? I'm wondering if it's a problem
> with JSynthLib or plumstone.
>

Re: [Jsynthlib-devel] two bugs

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

Brian wrote:

> Hiroo Hayashi wrote:
>
>> Federico,
>>
>> federico> 1) the MKS7 driver i just developed, controls only one 
>> timbral part.
>> federico> to get control of all three parts (chord,melody,bass), i 
>> have to create federico> 3 driver instances, with 3 different IDs and 
>> MIDICHANs.
>>
>> I don't understand why you have to create 3 driver instances.  Why one
>> driver cannot handle those three parts?
>>  
>>
>
> My understanding is that we have a driver / editor  that would work 
> with a Roland Juno 106.
> The MKS7 is actually three Juno 106's in one box. Each has its own 
> midi channel, and oddly,
> its own independant patch storage. It is no different than having 
> three seperate devices
> on the midi port, because they have no ability to communicate or share 
> information with each other.
>
> Brian

you are right.
(i add only one word) it is like to have three different synths, each 
has its own midi channel, and they all have the same MIDI-SysEx header 
<this is the problem

bye
-- 
Federico

Re: [Jsynthlib-devel] The addWidget(...) design

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

Brian wrote:

> In the future, I would like to do a *much* more sophisticated cross 
> breeder, including this kind of functionality. Two issues though: One 
> is that a "Filter Envelope" would not be a name of a Param Model.

Actually, I've been pondering a few ideas about that. Either ParamModels 
could be made so that they contain *other* ParamModels (like AWT 
containers being able to contain more containers). The utility of this 
(that I can think of right now) would be limited to: 1) You'd be able to 
select the granularity of crossbreeding (ie, you could use the entire 
Filter Envelope from Patch #1, or you could use the Attack point from 
Patch #1 and the Hold point from Patch #2, etc.). 2) If designed well, 
it might make it easier to code for complex data items which appear in 
numerous places. For example, if your synth uses 12 different envelopes 
(and the format of their data in the sysex is the same, just at 
different offsets within the data), then it should be possible to just 
make a FilterEnvelopeParamModel at each of those 12 offsets.

> An envelope widget is actually an editor for many values, each with 
> its own model / sender.

Well, in a nestable-ParamModel design, the overall FilterEnvelope 
probably wouldn't have a sender, but the individual points within it 
would. Granted, this might be making things too complicated, but I 
wanted to just put the idea in your head to see if you could envision 
any extra functionality that it might allow.

> Anyway, this is long term stuff.

Yet, there's no reason we can't be laying the foundation for it early.

> I have some other ideas for the crossbreeder, Right now its pretty 
> stupid, but we can do a lot of interesting stuff with it by giving it 
> some more smarts about the patches its combining.

One interesting idea that I thought of parallels what I've seen some 
photo-editing software do. I think Photoshop Elements does this. You 
tell it that you want to correct the color balance or something, and it 
shows you a 4x4 grid of thumbnails of your image, each with a different 
color correction applied to it. You click on one, and I *think* it then 
shows you another grid, with each of those being variations of what you 
picked. So, you're able to gradually "zero-in" on what you're after.

I think that we could do that with JSL. MidiQuest currently does 
something like this, but it's not itterative. MQ lets you pick some 
number of patches and then it fills the current bank with random blends 
of them. I think that the most-clever tool, however, would be one that 
works like the Photoshop tool, where the user gets to itteratively pick 
the closest sound, and then JSL gradually converges on what the user is 
after.

- Joe

Re: [Jsynthlib-devel] XML Driver Update

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

Rib Rdb wrote:

>I've commited the XML Editor and EditorBuilder. 
>
Cool. I haven't had a chance to check this out yet but I'm looking 
forward to it.

>I want to make a tutorial on how to write an XML driver, but I think
>the Motif is way too complicated. Can anyone suggest a simple synth I
>can write a sample driver for? Should I use the K4 since that's what
>programming.html talks about?
>
>  
>

I don't recommend using the K4. Why expend the effort to recreate a 
driver for a synth we already support? While it would
be nice to eventually have all drivers in XML, at this point I'm happy 
with what we have and would like to go forward
with new drivers being done in XML and let the old ones stay in java for 
now.

I recommend going with a simple synthesizer that you own (otherwise 
testing will be hard.) If you don't already own something
like this, I recommend aquiring something like a Kawai K1 or a Kawai 
XD5. XD5 is very similar to the K4 and has midi spec available on line.
These are pretty cheap to acquire. Hell, if you are willing to take the 
time to write a fully functional editor/librarian support in XML for the 
XD5 and
write a killer tutorial about it to boot, I'll mail you mine if you are 
in the U.S. (Outside the U.S. it would cost more to mail than to buy one :-)

Brian

Re: : [Jsynthlib-devel] BankDriver requests

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

Brian wrote:

>> If I edit a patch and want to send it back to the synth, does store 
>> put it on the synth, and if so - can you point me to the lines of 
>> code that should be sending the sysex containing the patch to the synth?
>>
> Hello,
>
> Generally all interactions with the patches are local (hard drive). 
> There are only three ways in which JSynthLib actually interacts with 
> the synth itself.

Thank you Brian, that is the explanation I was looking for.

Re: [Jsynthlib-devel] The addWidget(...) design

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

In the future, I would like to do a *much* more sophisticated cross 
breeder, including this kind of functionality. Two issues though: One is 
that a "Filter Envelope" would not be a name of a Param Model. An 
envelope widget is actually an editor for
many values, each with its own model / sender. You would not have a 
"Filter Envelope" ParamModel, but instead, a Filte Envelope Attack, 
Filter Envelope Decay, etc.
I think that even better than being able to name parameters by name to 
do a cross breed, it would be cool to highlight controls in an editor 
window. Anyway, this is long term stuff. I have some other ideas for the 
crossbreeder,
Right now its pretty stupid, but we can do a lot of interesting stuff 
with it by giving it some more smarts about the patches its combining.

Brian


>
> Here's my next question. Currently, parameter names are passed to the 
> widget, and not to the ParamModel, right? If they were given to the 
> ParamModel instead (and ParamModel had a getName() method so that the 
> widget could get to it), then it creates the possiblity for 
> user-tunable patch mixing, no?
>
> For example, if I wanted to combine patches 35 and 37, I could 
> actually tell JSL to use "Filter Envelope" from 35, "Pitch LFO" from 
> 37, and to just numerically average all of the others. Or does JSL 
> already do this?
>
> - Joe

[Jsynthlib-devel] XML Driver Update

[Rib R. <ri...@gm...>]

I've commited the XML Editor and EditorBuilder. I think I've cleaned
up all the obvious bugs in EditorBuilder, although it's still lacking
many features.  If anyone wants to try it out, you can load the
parameters from normal_voice.xml in the
org.jsynthlib.jsynthlib.synthdrivers.yamaha.motif package.
Of course you can also try to write your own XML driver. I'll help as
much as I can.

I want to make a tutorial on how to write an XML driver, but I think
the Motif is way too complicated. Can anyone suggest a simple synth I
can write a sample driver for? Should I use the K4 since that's what
programming.html talks about?

[Jsynthlib-devel] MIDI problem

[Rib R. <ri...@gm...>]

I just tried testing the XML editor with my Motif and I can't get the
MIDI to work.
When I try to request a patch, JSynthLib says it receives 8 bytes. But
those 8 bytes are just my request.  JSynthLib never really transmits
any data to the midi device.

Does anyone else have this problem? I'm wondering if it's a problem
with JSynthLib or plumstone.

[Jsynthlib-devel] Sysex Spec for V-Amp 2 Available

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

I put in a request to Behringer a while back asking if
they had an updated spec for the V-Amp 2. The only one
they had at the time was for the original V-Amp.

I just got a reply back from them and they had
attached a new V-Amp 2 spec. I wanted to pass it along
in case anyone (Joe?) is interested, so I've added it
to the tracker issue for the V-Amp 2 (under Feature
Requests).

In the meantime, I've had to put my work on the V-Amp
2 editor on hold for a couple of weeks to take care of
some family business. I'm hoping for things to settle
down in about a week and then I should be able to get
back to it.


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

Re: [Jsynthlib-devel] The addWidget(...) design

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

Brian wrote:

> Joe Emenaker wrote:
>
>> However, if anyone else would like to see this cleaned up, then I'd 
>> like to discuss ideas for it.
>
> I think this should be pretty easy to clean up if you are willing. . 
> The reason patch appears three times is that the Widget itself wants 
> to see the patch,
> the sender wants to see it, and the model wants to see it. My gut 
> reaction to how to fix it would be to create a method in the
> base class for models and senders that does nothing called setPatch 
> (Patch p). This would be called automatically by addWidget
> on the Model and Sender sent to it. Models / Senders could override 
> this to get at the Patch rather than having to  take the Patch
> in their constructor. Existing drivers could remain unchanged but new 
> ones could then get away without having to pass patch three
> times. We could always go back and upgrade older drivers later.

This is very much like what I was thinking.

Here's my next question. Currently, parameter names are passed to the 
widget, and not to the ParamModel, right? If they were given to the 
ParamModel instead (and ParamModel had a getName() method so that the 
widget could get to it), then it creates the possiblity for user-tunable 
patch mixing, no?

For example, if I wanted to combine patches 35 and 37, I could actually 
tell JSL to use "Filter Envelope" from 35, "Pitch LFO" from 37, and to 
just numerically average all of the others. Or does JSL already do this?

- Joe

Re: : [Jsynthlib-devel] BankDriver requests

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

Steven Schmidt wrote:

> Joachim Backhaus wrote:
>
>>> So can you tell me where in the code the locally (hard drive) stored 
>>> patch gets sent back to the synth?
>>>   
>>
>>
>> Should be storePatch for permanent storage
>> and sendPatch for temporary things
>>  
>>
> I was looking for a bit more info.  I'm not sure what you mean by 
> permanent and temporary.  If I edit a patch and want to send it back 
> to the synth, does store put it on the synth, and if so - can you 
> point me to the lines of code that should be sending the sysex 
> containing the patch to the synth?
>
Hello,

    Generally all interactions with the patches are local (hard drive). 
There are only three ways in which JSynthLib actually interacts with the 
synth itself.

The first is the patch - > get menu option which will take a patch from 
the synth and store it in the local library
The second is the patch -> store menu option which will take a patch 
from the current local library (on the hard disk) and send it to a
user supplied location on the synth. This is used to "permanently" store 
a patch back to the synth. The synth will then keep the patch at that 
location.
(usually even if the synth is turned off).

The third is when you use patch -> send or patch -> play. This will send 
the patch from the local library on the hard drive to the synth, but 
rather than
storing it in a particular location, the patch goes into the synth's 
"Edit Buffer" This is temporary storage for the currently edited patch. 
This is
done so that the patch can be auditioned on the synth while you are 
working with JSynthLib.Here, we just overwrite the "Default" or 
"Current" Location.
If the synth supports it we don't actually overwrite the patch permenantly.

The actual code for storing or sending a patch is in Driver.java.
Here basically sendPatch is declared to simply write the sysex contents 
of  the patch directly to the device and storePatch is declared to
set the bank and patch to the requested patch using patch change via 
MIDI and then calls sendPatch.
For some synth models this works fine, but many require special messages 
for send and/or store and this does not work. In those cases
the Driver for that synth will overwrite one of these methods.

Send is here:


  //**
     * Set Device ID and send the sysex data to MIDI output.
     * @see #sendPatch(Patch)
     *//
    *protected* *final* *void* sendPatchWorker(Patch p) {
        *if* (deviceIDoffset > 0)
            p.sysex[deviceIDoffset] = (*byte*) (getDeviceID() - 1);

        send(p.sysex);
    }


Store is here:

    //**
     * Sends a patch to a set location on a synth.<p>
     * Override this if required.
     * @see Patch#send(int, int)
     *//
    *protected* *void* storePatch(Patch p, *int* bankNum, *int* patchNum) {
        setBankNum(bankNum);
        setPatchNum(patchNum);
        sendPatch(p);




Brian

Re: : [Jsynthlib-devel] BankDriver requests

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

Joachim Backhaus wrote:

>>So can you tell me where in the code the locally (hard drive) stored 
>>patch gets sent back to the synth?
>>    
>>
>
>Should be storePatch for permanent storage
>and sendPatch for temporary things
>  
>
I was looking for a bit more info.  I'm not sure what you mean by 
permanent and temporary.  If I edit a patch and want to send it back to 
the synth, does store put it on the synth, and if so - can you point me 
to the lines of code that should be sending the sysex containing the 
patch to the synth?

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

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

>
> Lastly, having centralized checksum methods doesn't *prohibit* having 
> specialized ones, anyway. We could put the 4 or 5 most-common ones in 
> core.* and still allow individual synthdrivers to put in their own.


Since we've already  made the decision long ago to put the normal case 
checksum in core anyway, I don't see why we couldn't have a few in core. 
Its not a question of all in core or none in core, its a question of
is the checksum algorithm in core so much more general than the others 
that it deserves special treatment, or are there a small class of 
algorithms that should all be considered equally generic and go in core.
If there are several synthdrivers using the same algorithm, I see no 
reason not to refactor and place that algorithm in core. However we must 
be very careful not to break any drivers in doing this.

Re: [Jsynthlib-devel] The addWidget(...) design

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

Joe Emenaker wrote:

> Looking at various synth editors for ideas, I'm seeing many bits of 
> code that look like:
>
>    addWidget(leftPane, new CheckBoxWidget("Midi Pitch Bend", patch,
>          new MKSBitModel(patch, 16, 5), new MKSBitSender(patch, 16, 5, 
> 9)), 0, 10, 1, 1, -3);
>
> or...
>
>        addWidget(panel, new ComboBoxWidget("Footswitch Mode", patch,
>                                     new DM5SysInfoModel(patch, 
> headerSize + 0, 32, false),
>                                     new DM5SysInfoSender(patch, 1),....
>
> Notice that "patch" is used 3 times in these method calls. This seems 
> like it could be made a little more streamlined to me.
>
> As usual, I'm willing to do the work to fix it, but I don't want to if 
> everyone else feels that the current system is optimal.
>
> However, if anyone else would like to see this cleaned up, then I'd 
> like to discuss ideas for it.


I think this should be pretty easy to clean up if you are willing. . The 
reason patch appears three times is that the Widget itself wants to see 
the patch,
the sender wants to see it, and the model wants to see it. My gut 
reaction to how to fix it would be to create a method in the
base class for models and senders that does nothing called setPatch 
(Patch p). This would be called automatically by addWidget
on the Model and Sender sent to it. Models / Senders could override this 
to get at the Patch rather than having to  take the Patch
in their constructor. Existing drivers could remain unchanged but new 
ones could then get away without having to pass patch three
times. We could always go back and upgrade older drivers later.

Brian

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

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

Rib Rdb wrote:

>The XML driver is able to choose checksum methods with a string.
>
You're no help. :)

>My personal opinion is that
>we leave current drivers as they are, and work to make the XML driver
>provide a cleaner interface for new drivers.
>  
>
I'm not necessarily saying that we need to change the old drivers. I'm 
saying that we ought to put common checksum methods in a central class 
so that future non-XML drivers can use it. I felt that this would also 
benefit the XML driver, since authors could write something like 
<Checksum type="ROLAND_COMMON" />

- Joe

AW: [Jsynthlib-devel] Suggestion for setBankNum

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

> This is similar to the check-sum handling.=20

Maybe.

> Encapsulating a simple thing
> may make it just complicated.

That's the question.

Benefits of my suggestion:
1. Less redundancy
2. Simplified maintenance as the code
is in the core classes and not copied to
any driver.

Disadvantages:
1. May make the reading of the driver code
more complicated.

But is this really so?

Would it help to include the setBankNum codes
in the JavaDoc and a chapter for that in the
programming.html?

In most cases it makes no difference, because
the default value would be BANK_CHANGE_METHOD_MSB_LSB
which is the same as now.

And for another bank change method you would simply
add
this.setBankChangeMethod(Constants.BANK_CHANGE_METHOD_MSB)
or
this.setBankChangeMethod(Constants.BANK_CHANGE_METHOD_LSB)
in the constructor.
And the core/Constants class would not look that empty
anymore. ;)

Regards,
Joachim Backhaus


> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im=20
> Auftrag von Hiroo
> Hayashi
> Gesendet: Sonntag, 13. M=E4rz 2005 21:35
> An: JSynthLib Development
> Betreff: Re: [Jsynthlib-devel] Suggestion for setBankNum
>=20
>=20
> Joachim,
>=20
> Joachim> Five minutes ago I thought this idea is very good.=20
> Joachim> Now I'm not shure anymore. ;)
>=20
> If a driver uses 'BANK_CHANGE_METHOD_LSB', for example, it is=20
> more clear
> and easy to be read just writing
>=20
>      msg.setMessage(ShortMessage.CONTROL_CHANGE, getChannel() - 1,
>                     0x20, //  Bank Select (LSB)
>                     bankNum); // Bank Number (MSB)
>      send(msg);
>=20
> then using your method, isn't it?
>=20
> This is similar to the check-sum handling.  Encapsulating a=20
> simple thing
> may make it just complicated.
> --=20
> Hiroo Hayashi
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

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

[Rib R. <ri...@gm...>]

On Mon, 14 Mar 2005 22:18:11 -0800, Joe Emenaker <jo...@em...> wrote:
> Bill Zwicky wrote:
> > Does anyone actually *have* the problem you're solving?
> 
> Well, I think the XML driver will. It's going to need (or want) to be
> able to choose checksum methods with a text string.

The XML driver is able to choose checksum methods with a string. It
uses PluginRegistry to locate plugins (which currently must be written
in Groovy) inside the org.jsynthlib.plugins package and also in user
specified directories.
I suppose it would be possible to require these plugins to work with
Patch, but I don't really see the point.  My personal opinion is that
we leave current drivers as they are, and work to make the XML driver
provide a cleaner interface for new drivers.

Working towards this goal, I've converted EditorBuilder to be able to
read parameters from an XML driver and to export XML instead of Java
code.  I've almost finished the parser. Once it (the parser) is done
the XML driver should be ready for simple single editors. Then we need
to start using it so we can improve it. (For example, I think Decoders
need to be extended to allow for cases where multiple parameters are
decoded at once.)

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

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

Bill Zwicky wrote:

> Joe Emenaker wrote:
>
>> I think that we'd have more bug-free checksum methods if they were 
>> centralized in core.*. If there's a bug in one of the checksum 
>> methods that was being used by multiple synthdrivers, it would get 
>> noticed and fixed sooner.
>
> How many buggy checksummers do we have now?

I don't know because: A) some checksum methods might have bugs that only 
show up 1 in 128 or 1 in 16384 times. B) the author of the synthdriver 
might have just copied a buggy one from another synthdriver and just 
coded around it.

I'm assuming that your point is: "It's not that difficult to write a 
checksum method", and you're right. However, if enough of them are 
written from scratch, buggy ones *will* happen. Time will cause the 
improbable to be inevitable.

> What are the odds that fixing a "bug" in a common checksummer will 
> actually break some other synth?

The only way, that I can see, that would cause it to break another 
synthdriver is if that synthdriver *accounted* for the bug with its own 
code. But two wrongs don't make a right. I bug in a checksum method is a 
mistake. Trying to solve the problem by tweaking *other* parts of the 
synthdriver (instead of the checksum method) is *also* a mistake.

> Does anyone actually *have* the problem you're solving?

Well, I think the XML driver will. It's going to need (or want) to be 
able to choose checksum methods with a text string.

More importantly, the problem I'm trying to solve is one of long-term 
code maintenance. Right now, there could be dozens of copies of 
someone's original checksum algorithm. What if a seldom-occuring bug is 
found in the original? I doubt that anybody is going to go find all of 
the other synthdrivers that copied its method.

(My apologies to non-native English speakers at this point, because I 
should probably stop here, but I want to add a couple more points).

I'm also trying to solve future code-bloat. I'm looking forward to the 
day when JSL has support for 1,000+ devices. Even if we are lucky and 
*every* developer in the entire future of JSL writes flawless checksum 
methods, then our best possible outcome is needlessly-bloated code and a 
lot of duplicated effort.

Lastly, having centralized checksum methods doesn't *prohibit* having 
specialized ones, anyway. We could put the 4 or 5 most-common ones in 
core.* and still allow individual synthdrivers to put in their own.

- Joe

[Jsynthlib-devel] The addWidget(...) design

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

Looking at various synth editors for ideas, I'm seeing many bits of code 
that look like:

    addWidget(leftPane, new CheckBoxWidget("Midi Pitch Bend", patch,
          new MKSBitModel(patch, 16, 5), new MKSBitSender(patch, 16, 5, 
9)), 0, 10, 1, 1, -3);

or...

        addWidget(panel, new ComboBoxWidget("Footswitch Mode", patch,
                                     new DM5SysInfoModel(patch, 
headerSize + 0, 32, false),
                                     new DM5SysInfoSender(patch, 1),....

Notice that "patch" is used 3 times in these method calls. This seems 
like it could be made a little more streamlined to me.

As usual, I'm willing to do the work to fix it, but I don't want to if 
everyone else feels that the current system is optimal.

However, if anyone else would like to see this cleaned up, then I'd like 
to discuss ideas for it.

- Joe

[Jsynthlib-devel] Bug: JSLDesktop.java

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

Hi,

I discovered a bug in JSLDesktop.getDefaultLocation.
Maybe this bug has been reported in the past.

I was trying out the Korg X3 single editor in MDI mode, and the 
following error occurred:

ERR> 'Error in PatchEditor.' reported.
ERR> [Exception] / by zero
java.lang.ArithmeticException: / by zero
         at core.JSLDesktop.getDefaultLocation(Unknown Source)
         at core.JSLFrame.moveToDefaultLocation(Unknown Source)
         at core.Actions$EditAction$Worker.run(Unknown Source)

I put some println's in the following code:

Dimension screenSize = getSize();
System.out.println(screenSize.getWidth() + " " + frameSize.getWidth() + 
" " + xofs);

int x = xofs + (xsep * frame_count) % (int) (screenSize.getWidth() - 
frameSize.getWidth() - xofs);
if (x < 0)
    x = 0;

System.out.println(screenSize.getHeight() + " " + frameSize.getHeight() 
+ " " + yofs);

int y = yofs + (ysep * frame_count) % (int) (screenSize.getHeight() - 
frameSize.getHeight() - yofs);
if (y < 0)
    y = yofs + ysep;

This was the result:

setVisible : Korg X3 Single Editor
JSynthLib finalizing...
816.0 567.0 0
488.0 488.0 0

The screen height and frame height are the same and yofs=0, so a 
division by zero occurs.
Whenever you code a division you have to check if the denominator is zero.

Regards,
Ton Holsink

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

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

>
>
>"*Most* synths have a single F0 .. F7 pair in their sysex."
>  
>
>
>Is this true?  I thought only old synth (or for compatibility with old
>synth) uses a single sysex MIDI message even for a large data transfer.
>  
>

In my experience yes, all but one driver I've written use only one  F0 
.. F7 pair, while three or four used
variable length sysex. Still, I own mostly older devices so if there is 
information to contradict this,
no problem. Lets say that most devices have a constant number of F0 .. 
F7 pairs in their sysex
and / or a constant byte size. Using these two methods we should be able 
to tell when a patch is complete
in 99% of devices.

Brian

Re: [Jsynthlib-devel] two bugs

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

Hiroo Hayashi wrote:

>Federico,
>
>federico> 1) the MKS7 driver i just developed, controls only one timbral part.
>federico> to get control of all three parts (chord,melody,bass), i have to create 
>federico> 3 driver instances, with 3 different IDs and MIDICHANs.
>
>I don't understand why you have to create 3 driver instances.  Why one
>driver cannot handle those three parts?
>  
>

My understanding is that we have a driver / editor  that would work with 
a Roland Juno 106.
The MKS7 is actually three Juno 106's in one box. Each has its own midi 
channel, and oddly,
its own independant patch storage. It is no different than having three 
seperate devices
on the midi port, because they have no ability to communicate or share 
information with each other.

Brian

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

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

> Is it only me who does not prefer attachments, because it consumes my
> mail box?

Good point.

@federico:
Btw. the tracker ID for the Roland MKS-7 driver is: 1158890,
further source code should be published there
(you need a SourceForge account, but as it is free it should
be no problem).

Regards,
Joachim Backhaus


> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im=20
> Auftrag von Hiroo
> Hayashi
> Gesendet: Sonntag, 13. M=E4rz 2005 15:59
> An: JSynthLib Development
> Betreff: mail attachment (Re: AW: AW: AW: [Jsynthlib-devel] Okay... so
> why can't I edit a patch with this?)
>=20
>=20
> Joachim> > Does the mailing list handle attachments???
> Joachim>=20
> Joachim> Yes, e.g. federico has attached his MKS-7 code 2 days ago.
>=20
> Is it only me who does not prefer attachments, because it consumes my
> mail box?
>=20
> You can consider to use the tracker on sourceForge site to share your
> file.
> --=20
> Hiroo Hayashi
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from=20
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

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

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

Bill Zwicky wrote:

> And the only *good* solution to that is for each driver to have its 
> own private copy of checksum().  We really *don't* want changes in the 
> common code to break drivers; each driver should have its own code.

I think that we'd have more bug-free checksum methods if they were 
centralized in core.*. If there's a bug in one of the checksum methods 
that was being used by multiple synthdrivers, it would get noticed and 
fixed sooner.

The problem with changes in core breaking synthdrivers isn't a big 
problem because we have CVS. If someone breaks one of the checksum 
methods, we can easily fix it back.

Hiroo Hayashi wrote:

>And my manual for Roland synth explain check sum as follows;
>
>        aa + bb + cc + ... + hh = sum
>        sum / 128 = quotient ... remainder
>        128 - remainder = check sum
>
>It might be even more difficult to understand the method above
>implements this calculation method.
>
I consider it to be understood that there would need to be *plentiful* 
comments in a checksum class, perhaps going as far as to quote the 
checksum method from various manuals, like Hiroo has. In other words, we 
could write "If your sysex specification describes the checksum method 
as: 'aa + bb +...     128 - remainder = check sum', then use the 
following method" directly in the javadoc comment for the method.

- Joe

Re: JSL 1.0 and 2.0 (Re: [Jsynthlib-devel] Anyone here ever used any other librarian programs?)

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

Hiroo Hayashi wrote:

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

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

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

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

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

- Joe