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

Re: AW: [Jsynthlib-devel] midibox sid bugfix

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

Hi,

I'm here! :)

The bugfix is already submitted to the CVS. Main problem was, that 
with a "beautification" change before the 0.20-beta release, the 
SysEx structure of the MIDIbox SID editor had been corrupted, so 
that invalid data was sent to the synth. I haven't checked, if other 
drivers are also affected.

However, since beta releases are very rare, I provide a precompiled
binary at my website:
http://www.midibox.org/jsynthlib/JSynthLib-0.20.0_midibox_mod1.jar.zip

On Monday 16 January 2006 09:45, Joachim Backhaus wrote:
> Haven't heard something from the main developers for a
> long time. 
> It looks like JSynthLib is currently in something like
> a "coma". ;-)

Btw.: does anybody know what happened with Hiroo Hayashi?
He was one of the most active members, but there is no sign of life 
from him since months :-(

Best Regards, Thorsten.

AW: [Jsynthlib-devel] AN1X Support

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

Hi,

I don't see anything stupid. ;-)

Haven't heard of anybody working on Yamaha AN1X support
so I think you can start without fear. ;-)
Please then open a feature request and post your code there.

If it is finished and working I can then add your code to
the JSynthLib CVS so that it will be included in the next
release.

Cheers,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von an...@ti...
> Gesendet: Montag, 16. Januar 2006 22:56
> An: jsy...@li...
> Betreff: [Jsynthlib-devel] AN1X Support
>=20
> Hi there,
>=20
> I'm just new to JSynth and to this mailinglist, so correct me if I'm=20
> asking anything stupid.
> I saw on the supported list and on the on the Future Request page on=20
> SourceForge that=20
> there isn't any Yamaha AN1X support on the way, am I correct ?
> If this is the case, me and a friend of mine would like to try and=20
> implement the AN1X.
> We're both sort of programmers in training, so it shouldn't be to big=20
> a problem for us.
>=20
> Greetings,
> Imco Veenstra
> (The Netherlands)
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web. =20
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

[Jsynthlib-devel] AN1X Support

[<an...@ti...>]

Hi there,

I'm just new to JSynth and to this mailinglist, so correct me if I'm 
asking anything stupid.
I saw on the supported list and on the on the Future Request page on 
SourceForge that 
there isn't any Yamaha AN1X support on the way, am I correct ?
If this is the case, me and a friend of mine would like to try and 
implement the AN1X.
We're both sort of programmers in training, so it shouldn't be to big 
a problem for us.

Greetings,
Imco Veenstra
(The Netherlands)

AW: [Jsynthlib-devel] midibox sid bugfix

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

Hi,

Torsten Klose is in the developer list:
http://sourceforge.net/project/memberlist.php?group_id=3D41208

So he can submit changes himself.

> So, you really are back developing jsynthlib?

I'm currently not developing anything, I just responded
to some messages on the mailing list.
Haven't heard something from the main developers for a
long time.=20
It looks like JSynthLib is currently in something like
a "coma". ;-)

Cheers,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von David Griffith
> Gesendet: Montag, 16. Januar 2006 09:34
> An: jsy...@li...
> Betreff: [Jsynthlib-devel] midibox sid bugfix
>=20
>=20
> Yay!  Traffic!  So, you really are back developing jsynthlib?=20
>  Have you
> incorporated Thorsten Klose's midibox sid fixes into the codebase?
>=20
>=20
> --=20
> David Griffith
> dg...@cs...
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web. =20
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

[Jsynthlib-devel] midibox sid bugfix

[David G. <dg...@cs...>]

Yay!  Traffic!  So, you really are back developing jsynthlib?  Have you
incorporated Thorsten Klose's midibox sid fixes into the codebase?


-- 
David Griffith
dg...@cs...

AW: [Jsynthlib-devel] DTXtreme IIs Editor/Librarian

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

Hi,

doesn't the DTXtreme II manual contain the SysEx Data Format =
description?

At least it is described in the "Data Format" manual which you can
download on the Yamaha Manuals Library:
http://www2.yamaha.co.jp/manual/pdf/emi/english/ssdrums/DTXTREMEIIsE2.pdf=


Reading this is easier than to reverse engineer the MIDI data. ;-)

You don't have to be an expert in Java to program driver support,
it is IMHO very simple just look at the other drivers and if you need
help ask your development questions here. :-D

Cheers,
Joachim=20

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von aca...@de...
> Gesendet: Dienstag, 10. Januar 2006 00:13
> An: jsy...@li...;=20
> UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR
> Betreff: [Jsynthlib-devel] DTXtreme IIs Editor/Librarian
>=20
> Hi,
> I am new in this group. I have a Yamaha DTXtreme IIs drumkit.=20
> The supplied
> CD-ROM contains the USB driver under XP. It can be used to=20
> transmit any
> kind of midi data from PC to DTXtreme IIs and viceversa. Do=20
> you think it
> can be used as a base to write a jsynthlib editor/librarian ?=20
> Does this
> require an expert C++/Java programmer ?
> Thanks a lot
> Regards
> Angelo
> Bologna, Italy
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web. =20
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

AW: [Jsynthlib-devel] Yamaha 01v & Roland JD800 drivers

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

Hi,

sorry for the late answer:

You can see the "official" list of "work in progress" drivers at:
http://sourceforge.net/tracker/?group_id=3D41208&atid=3D430007=20

I think for a Roland JD800 driver you can use the exisiting
driver for the Roland JV80 as a good base.

If you start developing such a driver, please do also open a
"feature request" so that other developers and users can see it.

I'm still working on the drivers for the E-mu XL-7 and Waldorf Q
since they have a lot of parameters and I don't have much time
at the moment.

Cheers,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von wi...@op...
> Gesendet: Freitag, 30. Dezember 2005 16:54
> An: jsynthlib-devel
> Betreff: [Jsynthlib-devel] Yamaha 01v & Roland JD800 drivers
>=20
> Hello, I am a new user of JsynthLib as Apple abandoned the=20
> SoundDiver developement.  I wonder if anybody works on=20
> drivers for Yamaha 01v mixer and Roland JD800, as I am a=20
> volunteer to develope them.
> Best,
> Robert
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web. =20
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

Re: [Jsynthlib-devel] Can't get patches when using Linux (Windows works)

[jsynthlib <jsy...@ba...>]

(some success)

Patches can be send/received now (woohoo): Unlike the others, the first 
device given in "Synth Driver" tab is never choosable when getting 
patches (in Linux only). If anyone knows why I would be happy to see an 
answer.
The strange starting message and equal names for the UM880 are unchanged.

JSynthLib ist great! This really fills a gap for starting to make music 
with my old synths again (if enough time can be found).

Big thanks to everybody envolved in JSynthLib!

	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

[Jsynthlib-devel] Can't get patches when using Linux (Windows works)

[jsynthlib <jsy...@ba...>]

Hello,

using JSynthLib on Windows rocks. On Linux (on the same PC) I can't 
choose  patches.

Can anybody help my me with the following?
- I have a K4 at he 2nd Interface of an UM880 (8 midi-interfaces in 1 
unit). When pressing in JSynthLib Auto-Scan the K4 is found. When then 
creating a library and choosing "Patch" -> "Get" the K4 can only be 
chosen in Windows. In Linux every DropDownListbox after "Patch" -> "Get" 
is empty (tried with every possible Interfaces of the UM880 in the 
MIDI-Preferences). Any idea where the problem is?
- Starting in Linux (Windows runs fine): The text "Unable to load user 
preferences" appears. Should I do something against this? If yes - how?
- MIDI-Preferences can be set. Alle 8 MIDI-Interfaces of the UM880 (and 
in Linux ALSA gives a 9th for Controlling) are listed in the 
MIDI-Preferences as "UM880 [hw:1,0]" (in Windows they are numbered). Is 
there a way to find out in Linux which Interface is Number 1, 2 etc? 
(Strange: Sequencers like RosenGarden show in Linux the different 
UM880-Numbers)
- After some clicks the JavaGUI seems to look strange: Windows are cut 
off, Buttons do not appear. Any idea why this happens?
- Using DeMuDi (a Debian based Distribution), I had to build a Java 
package. I chose jdk-1_5_0_04-linux-i586.bin. Anyone using Debian and 
JDK1.5 with JSynthLib and can confirm that this works?


Thanks for any help,
Bastian


P. S. Please excuse my poor English

	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

[Jsynthlib-devel] DTXtreme IIs Editor/Librarian

[<aca...@de...>]

Hi,
I am new in this group. I have a Yamaha DTXtreme IIs drumkit. The supplied
CD-ROM contains the USB driver under XP. It can be used to transmit any
kind of midi data from PC to DTXtreme IIs and viceversa. Do you think it
can be used as a base to write a jsynthlib editor/librarian ? Does this
require an expert C++/Java programmer ?
Thanks a lot
Regards
Angelo
Bologna, Italy

[Jsynthlib-devel] Yamaha 01v & Roland JD800 drivers

[<wi...@op...>]

Hello, I am a new user of JsynthLib as Apple abandoned the SoundDiver developement.  I wonder if anybody works on drivers for Yamaha 01v mixer and Roland JD800, as I am a volunteer to develope them.
Best,
Robert

[Jsynthlib-devel] Jsynthlib on NetBSD take two

[David G. <dg...@cs...>]

Poking around with debug options, I got this:

$ java -verbosecall  -jar JSynthLib-0.20.0.jar
[snip]
soft_trace: java/beans/PropertyChangeSupport.firePropertyChange(Ljava/
 lang/String;Ljava/lang/Object;Ljava/lang/Object;)V
soft_trace: java/beans/PropertyChangeEvent.<init>(Ljava/lang/
 Object;Ljava/lang/String;Ljava/lang/Object;Ljava/lang/Object;)V
soft_trace: java/util/EventObject.<init>(Ljava/lang/Object;)V
soft_trace:
java/beans/PropertyChangeSupport.firePropertyChange(Ljava/beans/
 PropertyChangeEvent;)V
soft_trace: javax/swing/plaf/metal/MetalLookAndFeel.
 initComponentDefaults(Ljavax/swing/UIDefaults;)V

At this point, the process hangs.  What's wrong?  What needs to be fixed?


-- 
David Griffith
dg...@cs...

[Jsynthlib-devel] NetBSD and Yamaha TX7

[David G. <dg...@cs...>]

I've been having a nasty time trying to get Jsynthlib to give any feedback
whatsoever.  It just hangs.

Also, I have a Yamaha TX7, which I understand is supported but untested.
I'll have that test for you just as soon as I get Jsynthlib actually
running.

-- 
David Griffith
dg...@cs...

[Jsynthlib-devel] OSX 10.4 installation

[Matthew P. <ma...@ti...>]

Hi!  The CAProrovider.jar doesn't work with OSX 10.4.  I can't get 
jsynthlib working with midi on tiger.  Any ideas?

thanks!
Matt
-- 
*Matthew Polashek*
Home e-mail: ma...@ti...
URL: www.tinysongs.com

Get Firefox! <http://www.spreadfirefox.com/?q=affiliates&id=0&t=67>

[Jsynthlib-devel] Hi!

[Capi C. <dec...@ya...>]

JSynthLib looks very promising, and i will watch the
development of it. :)
I´m a Novation Supernova 2 owner, and i have always
wanted a editor for it even if it is easy to control
it with all the knobs and sliders, i still wish that
all the submenu parameters and arpeggiator could have
an interface so one could edit those parameters too.
I hope you can add 100% Novation Supernova 2 support.I
really would like to see an advanced patch randomizer
and arpeggiator editor in JSynthLib.
Keep up the good work!

T


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: [Jsynthlib-devel] Problem disabling Play option in menu

[Fred J. K. <fj...@xs...>]

Hi Joe,

Thank you for your reply. You wrote:

> Fred Jan Kraan wrote:
>
>> For the LXP5 editor, I want to disable the Play option in the context 
>> menu. The Edit..., Send and Store... options can be disabled by 
>> removing the respective methods from the java file (which also 
>> changes the behaviour of Play), but this option is not available for 
>> Play.
>> The problem with Play is that it implicitly also does a sendPatch 
>> which isn't always desirable. The behaviour is defined in 
>> BankEditorFrame and PatchEditorFrame (playSelectedPatch method) with 
>> no obvious way to control it.
>
>
> Since I'm 90% done with adding the ability to make a printout of the 
> patches in a bank, I'm becoming familiar with how the dynamic menu 
> enabling/disabling works. So, I can probably take care of this for you.
>
> Which do you prefer, do you want to disable Play altogether, or do you 
> want a way to Play without calling sendPatch?

Whatever would fit best in the JSynthLib design. It could be I do not 
use JSynthLib correctly, but not all items I want to handle are 
playable. So an option to disable the Play function just like Send and 
Store... seems most useful. For me in the current situation this will do ok.

My current project, the Lexicon LXP-5, is a effect device 
(delay/reverb/pitch). So Play is not very useful. The current 
implementation however, can change the contents of the bank.

>
> - Joe

Greetings & thank you,

Fred Jan Kraan

Re: [Jsynthlib-devel] Problem disabling Play option in menu

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

Fred Jan Kraan wrote:

> For the LXP5 editor, I want to disable the Play option in the context 
> menu. The Edit..., Send and Store... options can be disabled by 
> removing the respective methods from the java file (which also changes 
> the behaviour of Play), but this option is not available for Play.
> The problem with Play is that it implicitly also does a sendPatch 
> which isn't always desirable. The behaviour is defined in 
> BankEditorFrame and PatchEditorFrame (playSelectedPatch method) with 
> no obvious way to control it.

Since I'm 90% done with adding the ability to make a printout of the 
patches in a bank, I'm becoming familiar with how the dynamic menu 
enabling/disabling works. So, I can probably take care of this for you.

Which do you prefer, do you want to disable Play altogether, or do you 
want a way to Play without calling sendPatch?

- Joe

[Jsynthlib-devel] Problem disabling Play option in menu

[Fred J. K. <fj...@xs...>]

Hi there,

For the LXP5 editor, I want to disable the Play option in the context 
menu. The Edit..., Send and Store... options can be disabled by removing 
the respective methods from the java file (which also changes the 
behaviour of Play), but this option is not available for Play.
The problem with Play is that it implicitly also does a sendPatch which 
isn't always desirable. The behaviour is defined in BankEditorFrame and 
PatchEditorFrame (playSelectedPatch method) with no obvious way to 
control it.

Re: [Jsynthlib-devel] XML Library format (was: Roland MT32 files ready ...)

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

Joachim Backhaus wrote:

>>1 - There are attribute values named "author" and "date". This is what
>>they are called in core.Patch. However, in the LibraryFrame, they were
>>apparently changed at some point to "Field1" and "Field2". 
>>    
>>
>hmm, maybe we should change core.Patch because sooner or later
>this will lead to confusions.
>
>I haven't looked deeper, but as far as I can see changing
>this and the corresponding getter and setter methods to
>"field1" and "field2" should be relatively easy with Eclipse.
>  
>
Well, the problem hasn't been the effort in changing the Patch class. 
That's easy. The problem (as I understand it) has been that, if you 
change the data elements of Patch at all, it will no longer work with 
older serialized objects (as in... all .patchlib files).

>So to avoid confusion I suggest to re-name "author" "field1"
>and "date" "field2" in the XML format.
>If real "author" and "date" fields are required later,
>we can easily add them.
>  
>
Well, I have a problem with using "Field1" and "Field2" at all. Being 
generic, they're obviously not used by JSL for anything useful... which 
means that they're only of use to the user. The only thing I can imagine 
the *user* using them for is for additional comment fields. So, we can 
handle this one of two ways. We could either just have the user put all 
comments in the *existing* comment field and we can eliminate Field1 and 
Field2 altogether, or we can allow the user to create as many additional 
user-defined fields as they want (which could lead to problems).

My vote is to eliminate Field1 and Field2 entirely. The XML file will 
then only have comments and sysex data, but that's all we really need, I 
guess.

- Joe

Re: AW: AW: [Jsynthlib-devel] Joe's changes to MidiUtil

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

Quoting Joachim Backhaus <jba...@pi...>:

> I think I remember the discussions about the
> "sleep" solution and I like your solution,
> if it really works. ;-)

Another argument for tossing the current implementation is that there 
was a big
comment in MidiUtil somewhere where someone wrote:

   /* This is not correct! This should be fixed! */

Okay.... this is me fixing it. :)

- Joe

[Jsynthlib-devel] XML Library format (was: Roland MT32 files ready ...)

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

Hi,

> 1 - There are attribute values named "author" and "date". This is what
> they are called in core.Patch. However, in the LibraryFrame, they were
> apparently changed at some point to "Field1" and "Field2".=20

hmm, maybe we should change core.Patch because sooner or later
this will lead to confusions.

I haven't looked deeper, but as far as I can see changing
this and the corresponding getter and setter methods to
"field1" and "field2" should be relatively easy with Eclipse.

I can do that if no one disagrees.

So to avoid confusion I suggest to re-name "author" "field1"
and "date" "field2" in the XML format.
If real "author" and "date" fields are required later,
we can easily add them.

What do the others think about that?

> It's not very fancy, so far.

I like simple things. :)

Regards,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von Joe Emenaker
> Gesendet: Dienstag, 11. Oktober 2005 03:39
> An: jsy...@li...
> Betreff: Re: AW: [Jsynthlib-devel] Roland MT32 files ready=20
> for inclusion in JSynthLib source tree
>=20
> Joachim Backhaus wrote:
>=20
> >>I made some non-trivial changes to the code that interacts=20
> >>with it (so=20
> >>that it can also load XML libraries if it needs to), and I haven't=20
> >>tested my changes very thoroughly.
> >>   =20
> >>
> >Sounds interesting but I think we should wait for the "core"=20
> developers
> >to state their opinion (a week or so?).
> >
> >How does the XML format look like?
> >Can you post an example?
> > =20
> >
> Here's an excerpt from one of my libraries:
>=20
> > <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> > <patchlib>
> >   <patch author=3D"" date=3D"" comment=3D"Probably a Alesis=20
> Patch, Size: 7431">
> >     <patchData>8AAADgUAAB1PN0AgDgYCQQAwEAQAcDEcDCcLCWBTOH9+...
> >       ...KQABf2J/f3Qvf39Ff394X39/fg/3</patchData>
> >   </patch>
> >   <patch author=3D"" date=3D"" comment=3D"Probably a Roland=20
> Patch, Size: 18108">
> >     <patchData>EEEQADASAAAAAAAAPwEGAAQBAAABAQYGBgMDAwMDAwMDA...
> >        ....AMyLX8ACAsAACwBFkb3</patchData>
> >   </patch>
> >   <patch author=3D"Patch A1 & A2" date=3D"Studio Voc"=20
> comment=3D"Probably a
> > DOD Electronics Patch, Size: 1786">
> >     <patchData>8AAAEAAkQgAYAQAUABBHAG9pbmcg...
> >          ...fw5PZH48OSMTeH8OTwNkfjkj9w=3D=3D</patchData>
> >   </patch>
> >   <patch author=3D"Factory 1, 2, & 3" date=3D"Studio Voc"
> > comment=3D"Probably a DOD Electronics Patch, Size: 2679">
> >     <patchData>8AAAEAAkQgAYAQAUABBTAHR1ZG...
> >       =20
> ...H4PYAN4Wj8CD2B+D2BvE3h/Dk9kfjw5IxN4fw5PA2R+OSP3</patchData>
> >   </patch>
> > </patchlib>
>=20
> A few things about this:
> 1 - There are attribute values named "author" and "date". This is what
> they are called in core.Patch. However, in the LibraryFrame, they were
> apparently changed at some point to "Field1" and "Field2".=20
> So, what the
> *user* sees as "Field1" and "Field2" are actually held in the "author"
> and "date" strings in core.Patch.  One of the nice things about XML
> (over serialization) is that we can add/remove fields at any=20
> time... and
> we can give them whatever names we want. So, I decided to name these
> "author" and "date", and if we want other, generic comment=20
> fields later,
> then we can add them in and let LibraryFrame. The "comment"=20
> attribute is
> the same as the comment in LibraryFrame.
> 2 - The patchData element holds the actual sysex data, in BASE64
> encoding. This is for two reasons. First, it's simpler to=20
> store it this
> way than to try to allow each device class or driver to=20
> define their own
> XML tags (like <equalizerMidGain>, <LFO1freq>, etc). Second, and
> more-importantly, is that the actual physical device is the *ultimate*
> authority regarding the correctness of the data. If we didn't=20
> store the
> sysex data and, instead, stored values that the driver=20
> derived from the
> data... and if there ended up being a bug in the driver, then=20
> we'd have
> no way of getting the pristine data (unless we could get access to the
> physical device again, and if the device still had that patch=20
> or bank on
> it).
>=20
> It's not very fancy, so far. However, is *is* storing all=20
> data in every
> Patch object within a library, so it's not "incomplete", either.
>=20
> - Joe
>=20

AW: AW: [Jsynthlib-devel] Joe's changes to MidiUtil

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

Hi,

I think I remember the discussions about the=20
"sleep" solution and I like your solution,=20
if it really works. ;-)
If it is also compatible with the old way I think
it's ok to commit the changes to CVS with the
prior CVS tagging that Bill mentioned.

Bugs will be found and fixed. :-) (Hopefully ;-) ).

Regards,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von Joe Emenaker
> Gesendet: Dienstag, 11. Oktober 2005 00:02
> An: jsy...@li...
> Betreff: Re: AW: [Jsynthlib-devel] Roland MT32 files ready=20
> for inclusion in JSynthLib source tree
>=20
> Joachim Backhaus wrote:
>=20
> >>2 - I've also changed the way sysex messages are delivered to the=20
> >>drivers. I think that this new design is much better and more=20
> >>flexible.... but, again, my *implementation* of it might have=20
> >>some bugs.
> >>   =20
> >>
> >
> >Can you explain the changes a bit deeper?
> > =20
> >
> Well, I'll explain the problem I had to solve, first.
>=20
> I was writing a bank-driver for a device and it turned out=20
> that I had to=20
> request a bank from the device by requesting each of the individual=20
> patches individually. This presented timing issues because, if I=20
> requested the next patch before the last one was done=20
> sending, the patch=20
> data could get interrupted, etc.
>=20
> So, I needed to do something in my bank driver like:
>=20
>   for(int i=3D0; i<patches; i++) {
>     send( /* sysex bytes to request patch # i */ );
>     sleep( some number of milliseconds );
>  }
>=20
> This isn't a good solution, because the sleep time has to be=20
> made long=20
> enough to accomodate the worst-case scenario. So, it ended up=20
> resulting=20
> in some long waits while I received a bank.
>=20
> The reason for all of this seems to be due to how=20
> SysexGetDialog works.=20
> It sends the sysex request, and then starts polling MidiUtil to keep=20
> track of the bytes received. Then, when the user presses "Done", then=20
> SysexGetDialog tries to deliver the sysex message(s) to the driver.
>=20
> In my opinion, there are three problems with this:
> 1 - The driver doesn't get updates as sysex data is coming in=20
> (to allow=20
> the driver to send the request for the next patch immediately=20
> after the=20
> last one came in).
> 2 - Polling is wasteful.
> 3 - An additional problem is that MidiUtil only seems to make *sysex*=20
> messages available to the rest of the parts of JSL...=20
> stripping out all=20
> other midi messages. This limits the usefulness of MidiMonitor.
>=20
> What I did was change MidiUtil so that any other class could=20
> ask to be=20
> notified when any complete midi message was received. This=20
> way, multiple=20
> parts of JSL (SysexGetDialog, MidiMonitor, individual drivers, etc)=20
> could request to be notified when a message was received.=20
> Additionally,=20
> each "listener" could specify a filter (much like how=20
> java.io.FilenameFilter works) which would let them specify which=20
> messages they were notified of (which would allow MidiMonitor to give=20
> the user checkboxes to enable/disable note-on/off, CC, PC,=20
> etc. messages.
>=20
> Because this makes the midi message delivery within JSL more=20
> efficient=20
> and flexible, I was able to do things like giving the=20
> individual synth=20
> drivers access to a progress bar in SysexGetDialog, so that it could=20
> accurate represent how much of the patch/bank request was complete.
>=20
> - Joe
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,=20
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

Re: AW: [Jsynthlib-devel] Roland MT32 files ready for inclusion in JSynthLib source tree

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

Joachim Backhaus wrote:

>>I made some non-trivial changes to the code that interacts 
>>with it (so 
>>that it can also load XML libraries if it needs to), and I haven't 
>>tested my changes very thoroughly.
>>    
>>
>Sounds interesting but I think we should wait for the "core" developers
>to state their opinion (a week or so?).
>
>How does the XML format look like?
>Can you post an example?
>  
>
Here's an excerpt from one of my libraries:

> <?xml version="1.0" encoding="UTF-8"?>
> <patchlib>
>   <patch author="" date="" comment="Probably a Alesis Patch, Size: 7431">
>     <patchData>8AAADgUAAB1PN0AgDgYCQQAwEAQAcDEcDCcLCWBTOH9+...
>       ...KQABf2J/f3Qvf39Ff394X39/fg/3</patchData>
>   </patch>
>   <patch author="" date="" comment="Probably a Roland Patch, Size: 18108">
>     <patchData>EEEQADASAAAAAAAAPwEGAAQBAAABAQYGBgMDAwMDAwMDA...
>        ....AMyLX8ACAsAACwBFkb3</patchData>
>   </patch>
>   <patch author="Patch A1 & A2" date="Studio Voc" comment="Probably a
> DOD Electronics Patch, Size: 1786">
>     <patchData>8AAAEAAkQgAYAQAUABBHAG9pbmcg...
>          ...fw5PZH48OSMTeH8OTwNkfjkj9w==</patchData>
>   </patch>
>   <patch author="Factory 1, 2, & 3" date="Studio Voc"
> comment="Probably a DOD Electronics Patch, Size: 2679">
>     <patchData>8AAAEAAkQgAYAQAUABBTAHR1ZG...
>        ...H4PYAN4Wj8CD2B+D2BvE3h/Dk9kfjw5IxN4fw5PA2R+OSP3</patchData>
>   </patch>
> </patchlib>

A few things about this:
1 - There are attribute values named "author" and "date". This is what
they are called in core.Patch. However, in the LibraryFrame, they were
apparently changed at some point to "Field1" and "Field2". So, what the
*user* sees as "Field1" and "Field2" are actually held in the "author"
and "date" strings in core.Patch.  One of the nice things about XML
(over serialization) is that we can add/remove fields at any time... and
we can give them whatever names we want. So, I decided to name these
"author" and "date", and if we want other, generic comment fields later,
then we can add them in and let LibraryFrame. The "comment" attribute is
the same as the comment in LibraryFrame.
2 - The patchData element holds the actual sysex data, in BASE64
encoding. This is for two reasons. First, it's simpler to store it this
way than to try to allow each device class or driver to define their own
XML tags (like <equalizerMidGain>, <LFO1freq>, etc). Second, and
more-importantly, is that the actual physical device is the *ultimate*
authority regarding the correctness of the data. If we didn't store the
sysex data and, instead, stored values that the driver derived from the
data... and if there ended up being a bug in the driver, then we'd have
no way of getting the pristine data (unless we could get access to the
physical device again, and if the device still had that patch or bank on
it).

It's not very fancy, so far. However, is *is* storing all data in every
Patch object within a library, so it's not "incomplete", either.

- Joe

Re: AW: [Jsynthlib-devel] Roland MT32 files ready for inclusion in JSynthLib source tree

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

Joachim Backhaus wrote:

>How does the XML format look like?
>Can you post an example?
>  
>
Yeah. I'll try to post it later today.

>>2 - I've also changed the way sysex messages are delivered to the 
>>drivers. I think that this new design is much better and more 
>>flexible.... but, again, my *implementation* of it might have 
>>some bugs.
>>    
>>
>
>Can you explain the changes a bit deeper?
>  
>
Well, I'll explain the problem I had to solve, first.

I was writing a bank-driver for a device and it turned out that I had to 
request a bank from the device by requesting each of the individual 
patches individually. This presented timing issues because, if I 
requested the next patch before the last one was done sending, the patch 
data could get interrupted, etc.

So, I needed to do something in my bank driver like:

  for(int i=0; i<patches; i++) {
    send( /* sysex bytes to request patch # i */ );
    sleep( some number of milliseconds );
 }

This isn't a good solution, because the sleep time has to be made long 
enough to accomodate the worst-case scenario. So, it ended up resulting 
in some long waits while I received a bank.

The reason for all of this seems to be due to how SysexGetDialog works. 
It sends the sysex request, and then starts polling MidiUtil to keep 
track of the bytes received. Then, when the user presses "Done", then 
SysexGetDialog tries to deliver the sysex message(s) to the driver.

In my opinion, there are three problems with this:
1 - The driver doesn't get updates as sysex data is coming in (to allow 
the driver to send the request for the next patch immediately after the 
last one came in).
2 - Polling is wasteful.
3 - An additional problem is that MidiUtil only seems to make *sysex* 
messages available to the rest of the parts of JSL... stripping out all 
other midi messages. This limits the usefulness of MidiMonitor.

What I did was change MidiUtil so that any other class could ask to be 
notified when any complete midi message was received. This way, multiple 
parts of JSL (SysexGetDialog, MidiMonitor, individual drivers, etc) 
could request to be notified when a message was received. Additionally, 
each "listener" could specify a filter (much like how 
java.io.FilenameFilter works) which would let them specify which 
messages they were notified of (which would allow MidiMonitor to give 
the user checkboxes to enable/disable note-on/off, CC, PC, etc. messages.

Because this makes the midi message delivery within JSL more efficient 
and flexible, I was able to do things like giving the individual synth 
drivers access to a progress bar in SysexGetDialog, so that it could 
accurate represent how much of the patch/bank request was complete.

- Joe

[Jsynthlib-devel] Re: Roland MT32 files ready for inclusion in JSynthLib source tree

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

Ok, thanks.  I twiddled the controls and it all looks good, so I'll 
assume it works.  I've checked it in to update the existing MT32 
driver.  Note that I've dropped GUI_struct.java.txt (apparantly contains 
spare code fragments) and license.txt (redundant).

-Bill


Fred Jan Kraan wrote:

> I do not have permission to check it in. This was on purpose as I 
> didn't plan to make more than two drivers: Roland MT-32 and Lexicon LXP5.
> Testing is not required, just making sure it compiles without problems 
> (the previous version had obsolete code).
> The current java classes version 0.10 can be found at: 
> http://electrickery.xs4all.nl/digaud/mt32/