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

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

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

On 9/6/2011 10:44 AM, frankster wrote:
> On 04/09/2011 23:33, Joe Emenaker wrote:
>> I'm a little surprised that so few lines have been altered. I'm also
>> surprised that MidiUtil is the top of the list, but I just looked at my
>> copy and I now remember that I've made the whole thing its own process
>> thread which dispatches MIDI messages to the appropriate driver, etc.
> Is this thread separation only for receiving messages, or is it also for
> sending messages?

Well, sending doesn't really need to be threaded, but I guess it *can* 
be to guard against UI pauses during sending of long SYSEX stuff.

Looking at my copy of MidiUtil, it looks like what I did was make a 
thread which listens on all of the incoming MIDI interfaces for incoming 
stuff and it handles the problem of re-assembling multi-part SYSEX by 
itself. Only when it has a complete SYSEX message does it give it to any 
of the "observers". I think I set it up kind of like how Java Swing does 
UI notifications with "listeners" being able to sign up for notification 
when things happen.

> The TX81z seems to have a hardware limitation whereby an error message
> can appear on its screen talking about its midi message buffer being
> full. I am assuming this is because there needs to be some kind of rate
> limit on messages sent to it.

Oooh. A rate-limited "sendSysex()" or something could be a good addition.

> The Proteus 2000 seems to have very long single patch dumps - 2k+! The
> Proteus 2000 provides 2 transfer mechanisms - one  where you just send
> it blind, and another where there is some handshaking. So the Proteus
> driver could just send the patches in the blind method, which might be
> ok for 1 patch, but I shudder to think about sending an entire bank of
> patches that way without flow control! So to do a good job on the driver
> I think it will need to support handshaking.

Well, you could send one patch (or piece), and then wait for 
notification from MidiUtil about it transferring okay, and then send the 
next piece, etc. We may have to brainstorm on this one a bit.

- Joe

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

[frankster <jsy...@te...>]

On 04/09/2011 23:33, Joe Emenaker wrote:
> 308 JSynthLib.1051/JSynthLib/core/MidiUtil.java
>
>
> I'm a little surprised that so few lines have been altered. I'm also 
> surprised that MidiUtil is the top of the list, but I just looked at my 
> copy and I now remember that I've made the whole thing its own process 
> thread which dispatches MIDI messages to the appropriate driver, etc. 
>

Is this thread separation only for receiving messages, or is it also for
sending messages? Both the current TX81Z driver and my planned Proteus
2000 series driver look like they may need some kind of asynchronous
sending mechanism so I've been thinking of how best to achieve this.

The TX81z seems to have a hardware limitation whereby an error message
can appear on its screen talking about its midi message buffer being
full. I am assuming this is because there needs to be some kind of rate
limit on messages sent to it.

The Proteus 2000 seems to have very long single patch dumps - 2k+! The
Proteus 2000 provides 2 transfer mechanisms - one  where you just send
it blind, and another where there is some handshaking. So the Proteus
driver could just send the patches in the blind method, which might be
ok for 1 patch, but I shudder to think about sending an entire bank of
patches that way without flow control! So to do a good job on the driver
I think it will need to support handshaking.

While I could imagine implementing the TX81z flow control as a generic
mechanism that could apply to various drivers (a simple setting each
could set), the P2k handshaking protocol maybe doesn't lend itself to a
generic implementation.

I wonder if there are any other drivers that use some kind of flow
control or rate limitation mechanism (beyond freezing the UI for a few
ms! ).

frankie

Re: [Jsynthlib-devel] Can't figure out how to branch...

[Vladimir A. <vl...@gm...>]

On 09/06/2011 11:19 AM, Joe Emenaker wrote:
> I can't make a branch for my refactor. When I try it from the command
> line on my Ubuntu box, I do...
>
>> >  svn copy
>> >  https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/trunk@r1051
>> >  https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/branches/UIRefactor-jemenake
>> >  --username blahblahblah --password blahblahblah

Looks like it should have worked. I just made a sandbox in my user 
project on SF, created two revisions and brunched from earlier. Here is 
exact command line i used:

svn copy 
svn+ssh://vl...@sv.../u/vldmr/jsynthlib/code/build.xml@1 
svn+ssh://vl...@sv.../u/vldmr/jsynthlib/code/branches

For some reason, it prompted for password 4 times, but otherwise worked 
as expected.

In general, I find that it is easier in many cases to work with svn 
using good gui client. On windows turtoise svn is very good, on linux I 
use kde-svn.
-- 
Vladimir

[Jsynthlib-devel] Can't figure out how to branch...

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

I'm such a SVN n00b...

I can't make a branch for my refactor. When I try it from the command 
line on my Ubuntu box, I do...

> svn copy 
> https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/trunk@r1051 
> https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/branches/UIRefactor-jemenake 
> --username blahblahblah --password blahblahblah

to try to copy release 1051 to a branch called "UIRefactor-jemenake" 
(because my changes are all based off of r1051).

When  I try to do this, however, SVN tells me that the second URL is 
going to be ignored, and then gives me the option to abort/continue/edit.

Do I have to make the branch in the SourceForge web interface or something?

- Joe

[Jsynthlib-devel] Anyone with a Waldorf Microwave 2, XT or XT keyboard?

[Joachim <li...@sd...>]

Hi,

I checked my old code in the repository and I think there are still some bugs in my Microwave 2/XT/XTK driver:

New issues occured:
- Requested banks & single sounds didn't work anymore!

Old issue:
- Storing banks doesn't work (checksum errors in the synth)

Unfortunately I sold my Microwave XT in 2005 so I can't fix or check them myself.

Joachim

Re: [Jsynthlib-devel] up to date supported synths list

[Joachim <li...@sd...>]

I hope the one maintaining the website (was it Brian Klock?) is still
listed here.

The best thing of course would be to have a site with a small CMS
or a Wiki or something like that.

Joachim

Am 04.09.2011 23:00, schrieb frankster:
> I have copied the supported synths list from the website
> (http://jsynthlib.org/synths.html ) into SVN and updated it so that it
> mentions all the newer drivers in SVN, so that whenever a release next
> occurs the website can be updated more easily.
>
> frankie
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

Re: [Jsynthlib-devel] mysterious manufacturer ID!

[Vladimir A. <vl...@gm...>]

On 09/04/2011 06:33 AM, frankster wrote:
> Assuming that it is the Keystation Pro 88 that is responding, then of

Did you try to autoscan when nothing but keystation is connected?

-- 
Vladimir

Re: [Jsynthlib-devel] mysterious manufacturer ID!

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

On Sun, Sep 4, 2011 at 4:33 AM, frankster <jsy...@te...>wrote:

> I was testing the scanning for my Proteus 2000 so I was expecting to see
> one response to the Device Inquiry message, however I also received
> responses from an additional device! The Proteus 2000 is connected to
> the midi interface on my M-audio Keystation Pro 88 keyboard which in
> turn is connected via usb to my PC, so I would assume that the response
> is coming from this. However, the manufacturer ID that I would expect
> this to generate would be 00H 01H 05H according to the list at
> http://www.midi.org/techspecs/manid.php while the ID that I see is
> actually 00 20 08!
>

I found an extended list, but your code is still missing:

http://www.hinton-instruments.co.uk/reference/midi/protocol/pg04.htm

You might try getting the official MIDI spec from M-Audio, that should tell
you what their code is.

-Bill Zwicky

[Jsynthlib-devel] mysterious manufacturer ID!

[frankster <jsy...@te...>]

So I've been playing with the auto scan functionality a little bit this 
weekend (I've made a standalone class which invokes MidiScan without a 
GUI which makes testing the device identification a little easier).

In case anyone reading this is unfamiliar with the auto-scan, it 
basically sends out sysex Device Inquiry messages, which should elicit a 
response from compatible devices allowing the appropriate driver to be 
identified.

I was testing the scanning for my Proteus 2000 so I was expecting to see 
one response to the Device Inquiry message, however I also received 
responses from an additional device! The Proteus 2000 is connected to 
the midi interface on my M-audio Keystation Pro 88 keyboard which in 
turn is connected via usb to my PC, so I would assume that the response 
is coming from this. However, the manufacturer ID that I would expect 
this to generate would be 00H 01H 05H according to the list at 
http://www.midi.org/techspecs/manid.php while the ID that I see is 
actually 00 20 08!

f0 7e 7f 06 02 *00 20 08* 4d 14 35 01 20 31 30 31 f7

And on that manufacturer id list there is no entry for 00 20 08, 
although that list is incomplete and I would have to spend £50 to get 
them to post me the complete midi spec.

Assuming that it is the Keystation Pro 88 that is responding, then of 
course I will have to implement librarian support for the "patches" on 
they keyboard although there's no mention of sysex in its manual.

Anyway, the question that remains from all this is: does anybody have 
any idea what this manufacturer id is?

cheers,
Frankie

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1116] trunk/JSynthLib/doc/synths.html

[frankster <jsy...@te...>]

On 05/09/2011 01:57, William Zwicky wrote:
> On Sun, Sep 4, 2011 at 5:32 PM, Joe Emenaker <jo...@em...> wrote:
>
>> Would it be worthwhile to make a method which could interrogate all of
>> the synthdriver classes and generate the synths.html file automatically,
>> and to include that with the part of build.xml which generates the
>> properties file?
>>

This sounds like a good plan.

frankie

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1116] trunk/JSynthLib/doc/synths.html

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

On Sun, Sep 4, 2011 at 10:45 PM, Joe Emenaker <jo...@em...> wrote:

> Well, I was *also* thinking that, if we're going to have
> dynamically-loadable or downloadable synthdrivers, then there's going to
> need to be some kind of way to interrogate the synthdrivers to ask them
> what they can do. We may be able to get some mileage out of merely
> parsing the classnames and pulling off "BankDriver" off of the end and
> whatnot... and we can also use Java's inspection features to find out
> what each class' superclass is (ie, Driver or BankDriver, etc.).
>
> However, one could argue that the *right* way to do it is to add some
> static identifier methods (like getManufacturer(), getSynthName(),
> getDriverType(), etc.) which would be abstract in Driver or BankDriver
> (so that every synthdriver had to define them). If we decided to do
> this, we should implement it sooner than later, because there will only
> be more drivers in the future.
>

You might look at
ServiceLoader<http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html>.
Granted, Devices aren't services, but this seems to implement some of the
mechanism we want.  Not all of it; I don't think it will load jar files
after the app has started up.

However, the really right way to do it is with a config file that allows us
to examine available drivers without actually loading the classes.  This
conserves memory, and also holds down startup time.  This isn't a problem
for us right now, but some professional apps have plugin synths that are
incredibly huge.  If by some fluke JSynthLib becomes popular, we may need
this.

Googling 'round the net, I also found a toy system:
   http://sourceforge.net/projects/javasps/
A more powerful system:
   http://jpf.sourceforge.net/
And extreme overkill:
   http://en.wikipedia.org/wiki/OSGi

-Bill Zwicky

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1116] trunk/JSynthLib/doc/synths.html

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

On 09/04/2011 05:57 PM, William Zwicky wrote:
> I just checked in an overhaul of DeviceListWriter that does just that.
> Doesn't work very well, cuz:
>   * There's no source for the code to get those short comments, and the long
> infoText is WAY to big for this table.
>   * Probing the device capabilities requires calling
> constructor(Preferences), which fails in a few cases.
>   * Probing for the patch editor requires *creating* the patch editor, which
> crashes and/or hangs in most cases.

Well, I was *also* thinking that, if we're going to have 
dynamically-loadable or downloadable synthdrivers, then there's going to 
need to be some kind of way to interrogate the synthdrivers to ask them 
what they can do. We may be able to get some mileage out of merely 
parsing the classnames and pulling off "BankDriver" off of the end and 
whatnot... and we can also use Java's inspection features to find out 
what each class' superclass is (ie, Driver or BankDriver, etc.).

However, one could argue that the *right* way to do it is to add some 
static identifier methods (like getManufacturer(), getSynthName(), 
getDriverType(), etc.) which would be abstract in Driver or BankDriver 
(so that every synthdriver had to define them). If we decided to do 
this, we should implement it sooner than later, because there will only 
be more drivers in the future.

- Joe

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1116] trunk/JSynthLib/doc/synths.html

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

On Sun, Sep 4, 2011 at 5:32 PM, Joe Emenaker <jo...@em...> wrote:

> Would it be worthwhile to make a method which could interrogate all of
> the synthdriver classes and generate the synths.html file automatically,
> and to include that with the part of build.xml which generates the
> properties file?
>

Grape minds drink alike!

I just checked in an overhaul of DeviceListWriter that does just that.
Doesn't work very well, cuz:
 * There's no source for the code to get those short comments, and the long
infoText is WAY to big for this table.
 * Probing the device capabilities requires calling
constructor(Preferences), which fails in a few cases.
 * Probing for the patch editor requires *creating* the patch editor, which
crashes and/or hangs in most cases.

Feel free to improve it.

-Bill Zwicky

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1116] trunk/JSynthLib/doc/synths.html

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

On 09/04/2011 01:44 PM, fra...@us... wrote:
> Updated list of supported synths:
>
> I have added all the drivers in SVN that are not mentioned. I have judged whether patch/bank/editing is supported based on the existence of files with Driver/Editor in their names, but have not performed any checks beyond this.

This, coming on the heels of Bill's alteration of build.xml so that it 
always builds a new synthdrivers.properties gave me a thought...

Would it be worthwhile to make a method which could interrogate all of 
the synthdriver classes and generate the synths.html file automatically, 
and to include that with the part of build.xml which generates the 
properties file?

- Joe

Re: [Jsynthlib-devel] synthdrivers.properties

[frankster <jsy...@te...>]

On 05/09/2011 00:38, Vladimir Avdonin wrote:
> Hey,
>
> Why do we have the synthdrivers.properties file under version control? 
> It is autogenerated during build, right. Am I missing something?
>
it wasn't part of the build process until this weekend when Bill Zwicky
added it to ant's build.xml. It would probably make sense to remove it
from SVN now that it is automatically generated.

frankie

[Jsynthlib-devel] synthdrivers.properties

[Vladimir A. <vl...@gm...>]

Hey,

Why do we have the synthdrivers.properties file under version control? 
It is autogenerated during build, right. Am I missing something?

-- 
Vladimir

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

[frankster <jsy...@te...>]

On 04/09/2011 23:33, Joe Emenaker wrote:
> On 09/04/2011 02:08 PM, frankster wrote:
>> On 03/09/2011 15:57, Joe Emenaker wrote:
>>> On 9/3/2011 6:59 AM, frankster wrote:
>>>> * which files are you planning to include in the refactor so I can avoid
>>>> changing those files?
>>> I've tracked down which revision I started the refactor on (it's from
>>> back in 2006...  yeah, really), so now I'm doing a diff on all of the
>>> files to see what I've changed.
>> Must be some kind of world record!
> For procrastination? :-O

Getting in the record books is an achievement regardless of the method,
right? ;)


>
> Okay, here's a sort-of list. What I did was run diff on every file from 
> revision 1051 to compare it to my refactoring code and then I ran each 
> diff into a line-counter so that I could see what files have changed the 
> most...
>
> 308 JSynthLib.1051/JSynthLib/core/MidiUtil.java
> 224 JSynthLib.1051/JSynthLib/core/Actions.java
> 74 JSynthLib.1051/JSynthLib/core/SysexGetDialog.java
> 74 JSynthLib.1051/JSynthLib/core/DriverUtil.java
> 60 JSynthLib.1051/JSynthLib/core/AbstractLibraryFrame.java
> 53 JSynthLib.1051/JSynthLib/midiprovider/OSX/CAProvider/CAMIDISource.java
> 38 JSynthLib.1051/JSynthLib/core/Scene.java
> 36 JSynthLib.1051/JSynthLib/core/DevDrvPatchSelector.java
> 32 JSynthLib.1051/JSynthLib/core/BankEditorFrame.java
> 28 JSynthLib.1051/JSynthLib/core/PatchEdit.java
> 23 JSynthLib.1051/JSynthLib/core/PatchEditorFrame.java
> 12 JSynthLib.1051/JSynthLib/org/jsynthlib/editorbuilder/EditorBuilder.java
> 8 JSynthLib.1051/JSynthLib/JSynthLib.java
> 8 JSynthLib.1051/JSynthLib/core/ErrorMsg.java
>
>

Thanks for the list. Probably best if I stay away from Actions.java
after all as its such a big one.

cheers,
frankie

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

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

On 09/04/2011 02:08 PM, frankster wrote:
> On 03/09/2011 15:57, Joe Emenaker wrote:
>> On 9/3/2011 6:59 AM, frankster wrote:
>>> * which files are you planning to include in the refactor so I can avoid
>>> changing those files?
>> I've tracked down which revision I started the refactor on (it's from
>> back in 2006...  yeah, really), so now I'm doing a diff on all of the
>> files to see what I've changed.
> Must be some kind of world record!

For procrastination? :-O

Okay, here's a sort-of list. What I did was run diff on every file from 
revision 1051 to compare it to my refactoring code and then I ran each 
diff into a line-counter so that I could see what files have changed the 
most...

308 JSynthLib.1051/JSynthLib/core/MidiUtil.java
224 JSynthLib.1051/JSynthLib/core/Actions.java
74 JSynthLib.1051/JSynthLib/core/SysexGetDialog.java
74 JSynthLib.1051/JSynthLib/core/DriverUtil.java
60 JSynthLib.1051/JSynthLib/core/AbstractLibraryFrame.java
53 JSynthLib.1051/JSynthLib/midiprovider/OSX/CAProvider/CAMIDISource.java
38 JSynthLib.1051/JSynthLib/core/Scene.java
36 JSynthLib.1051/JSynthLib/core/DevDrvPatchSelector.java
32 JSynthLib.1051/JSynthLib/core/BankEditorFrame.java
28 JSynthLib.1051/JSynthLib/core/PatchEdit.java
23 JSynthLib.1051/JSynthLib/core/PatchEditorFrame.java
12 JSynthLib.1051/JSynthLib/org/jsynthlib/editorbuilder/EditorBuilder.java
8 JSynthLib.1051/JSynthLib/JSynthLib.java
8 JSynthLib.1051/JSynthLib/core/ErrorMsg.java

I'm a little surprised that so few lines have been altered. I'm also 
surprised that MidiUtil is the top of the list, but I just looked at my 
copy and I now remember that I've made the whole thing its own process 
thread which dispatches MIDI messages to the appropriate driver, etc. 
After that, Actions is the class that has been modified pretty heavily.

- Joe

Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

[frankster <jsy...@te...>]

On 03/09/2011 15:57, Joe Emenaker wrote:
> On 9/3/2011 6:59 AM, frankster wrote:
>> * which files are you planning to include in the refactor so I can avoid
>> changing those files?
> I've tracked down which revision I started the refactor on (it's from 
> back in 2006...  yeah, really), so now I'm doing a diff on all of the 
> files to see what I've changed.

Must be some kind of world record!

> So far, it's the big-picture window/desktop stuff. I don't think I've 
> touched any of the widget stuff. I think I've also left the "action" 
> parts of Action.java alone. By that, I mean... the stuff where each 
> action has a unique ID and they register their place in the menus and 
> their hot-keys and such. But those inner classes in Actions like 
> Actions.MenuDesktop and Actions.MenuFrame, I'm pretty sure that's all 
> been yanked to a dedicated set of UI classes... so that a class named 
> "Actions" doesn't need to be importing BorderLayout and Dimension.
>
> I should have a concrete list for you in a day.

I'm also planning on making it so that when you right click on an empty
part of the background of a library or scene, it will pop up a "new
patch" menu. It sounds from what you said like I will be able to do this
without interfering with your refactoring. But I will hold off until I
hear back from you.

regards,
Frankie

[Jsynthlib-devel] up to date supported synths list

[frankster <jsy...@te...>]

I have copied the supported synths list from the website
(http://jsynthlib.org/synths.html ) into SVN and updated it so that it
mentions all the newer drivers in SVN, so that whenever a release next
occurs the website can be updated more easily.

frankie

Re: [Jsynthlib-devel] TX81z editor error

[frankster <jsy...@te...>]

On 04/09/2011 21:32, Martin Tarenskeen wrote:
>
>
> On Sun, 4 Sep 2011, frankster wrote:
>
>> I have submitted your patches into SVN - although I have kept the DX7
>> algorithm images in their own directory (as its marginally neater than
>> mixed in with the Java files I think) but I have moved the images
>> directory into the DX7/common directory which solves the crash similarly
>> to your patch.
>
> I already knew about your DX7 images directory fix. I accidentally
> attached an old patchfile to my previous mail that was still on my
> harddisk.
>
> The patch attached now is the one I wanted to send: it fixes the DX7
> envelope graphics.
>

Ah I wasn't sure if it was a mistake or not. Anyway I have submitted
your new patch as well.

Cheers,
Frankie

Re: [Jsynthlib-devel] TX81z editor error

[Martin T. <m.t...@zo...>]

On Sun, 4 Sep 2011, frankster wrote:

> I have submitted your patches into SVN - although I have kept the DX7
> algorithm images in their own directory (as its marginally neater than
> mixed in with the Java files I think) but I have moved the images
> directory into the DX7/common directory which solves the crash similarly
> to your patch.

I already knew about your DX7 images directory fix. I accidentally 
attached an old patchfile to my previous mail that was still on my 
harddisk.

The patch attached now is the one I wanted to send: it fixes the DX7 
envelope graphics.

-- 

MT

Re: [Jsynthlib-devel] TX81z editor error

[frankster <jsy...@te...>]

On 04/09/2011 19:26, Martin Tarenskeen wrote:
>
>
> On Sun, 4 Sep 2011, frankster wrote:
>
>> sorry for the double post before.
>> I have put a fix to SVN. If you still have this problem, could you send
>> me a sysx file containing a patch that triggers it?
>
> Thanks. Problem has gone.
>
>>>> I have also been doing a few improvements on the envelope graphics for
>>>> the Yamaha DX7 and DX100/TX81z family (EG and PEG). (All were
>>>> missing a
>>>> Sustain segment, which I have fixed now). I will send some
>>>> patches/proposals later, after the above bug has been fixed and
>>>> after I
>>>> have done some more testing with my locally modified copy.
>
> I have attached patches for the Yamaha DX7, DX100, and TX81z Single
> Voice editor. They change the Envelope Generator (level and pitch)
> graphics.
> 1. A sustain segment is now correctly Bdisplayed.
> 2. DX7 EG, PEG and DX21 PEG: The start level is the same as the end
> level (DX7 Level/Pitch 4, DX21 PEG Level 3). (read the DX7 manual) 3.
> The DX21/TX81Z envelope is a hard one. I have choosen to draw a
> horizontal line after the D1L point. This is only true if D2R=0. But
> it's as good as I could get it.
>
> I hope someone who knows how SVN works can merge my ideas into the
> trunk. (I guess I should learn how to use it before asking to get
> write access myself)
>

I have submitted your patches into SVN - although I have kept the DX7
algorithm images in their own directory (as its marginally neater than
mixed in with the Java files I think) but I have moved the images
directory into the DX7/common directory which solves the crash similarly
to your patch.

frankie

Re: [Jsynthlib-devel] TX81z editor error

[Martin T. <m.t...@zo...>]

On Sun, 4 Sep 2011, frankster wrote:

> sorry for the double post before.
> I have put a fix to SVN. If you still have this problem, could you send
> me a sysx file containing a patch that triggers it?

Thanks. Problem has gone.

>>> I have also been doing a few improvements on the envelope graphics for
>>> the Yamaha DX7 and DX100/TX81z family (EG and PEG). (All were missing a
>>> Sustain segment, which I have fixed now). I will send some
>>> patches/proposals later, after the above bug has been fixed and after I
>>> have done some more testing with my locally modified copy.

I have attached patches for the Yamaha DX7, DX100, and TX81z Single Voice 
editor. They change the Envelope Generator (level and pitch) graphics.
1. A sustain segment is now correctly Bdisplayed.
2. DX7 EG, PEG and DX21 PEG: The start level is the same as the end 
level (DX7 Level/Pitch 4, DX21 PEG Level 3). (read the DX7 manual) 
3. The DX21/TX81Z envelope is a hard one. I have choosen to draw a 
horizontal line after the D1L point. This is only true if D2R=0. But it's 
as good as I could get it.

I hope someone who knows how SVN works can merge my ideas into the trunk. 
(I guess I should learn how to use it before asking to get write access 
myself)

-- 

MT

Re: [Jsynthlib-devel] TX81z editor error

[frankster <jsy...@te...>]

sorry for the double post before.
I have put a fix to SVN. If you still have this problem, could you send 
me a sysx file containing a patch that triggers it?

thanks
frankie
On 09/04/11 12:37, frankster wrote:
> Thanks for reporting this, its probably me that broke it because I added
> some images for the waveforms into the editor yesterday. It was working
> for me though! I'll have a look at this later on and see if I can get it
> to happen as well.
>
> frankie
>
> On 09/04/11 11:19, Martin Tarenskeen wrote:
>> Using the latest SVN versions of JSynthLib I am getting an error when
>> trying to open the Yamaha TX81Z voice editor:
>>
>>
>> The error was:
>>      99
>> The exception text is:
>> java.lang.ArrayIndexOutOfBoundsException: 99
>>    	at
>> synthdrivers.YamahaTX81z.YamahaTX81zSingleEditor.<init>(YamahaTX81zSingleEditor.java:121)
>>    	at
>> synthdrivers.YamahaTX81z.YamahaTX81zSingleDriver.editPatch(YamahaTX81zSingleDriver.java:67)
>>    	at core.Patch.edit(Patch.java:181)
>>    	at
>> core.AbstractLibraryFrame.editSelectedPatch(AbstractLibraryFrame.java:348)
>>    	at core.Actions$1Worker.run(Actions.java:969)
>>
>>
>> I have learnt how to compile and run Java code, but that's where my Java
>> skills more or less end. But it looks like this error was introduced
>> during the recent SVN activity. Maybe someone can take a look at this?
>>
>> I have also been doing a few improvements on the envelope graphics for
>> the Yamaha DX7 and DX100/TX81z family (EG and PEG). (All were missing a
>> Sustain segment, which I have fixed now). I will send some
>> patches/proposals later, after the above bug has been fixed and after I
>> have done some more testing with my locally modified copy.
>>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel