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

Re: [Jsynthlib-devel] Help building drivers: first steps

[Christoph E. <ce...@ch...>]

Hi,


> Hi. Responses inline:

perfect with me.

[...]

> Did you get the updated makefile?  What errors are you getting?

yes I did. It started to build fine, but then I get 100 errors like the 
following:

$> make

javac -g -classpath .:jdom.jar:groovy.jar 
synthdrivers/RolandGP16/RolandGP16BankDriver.java

[...]

./synthdrivers/RolandGP16/RolandGP16SingleEditor.java:232: cannot 
resolve symbol
symbol  : class ExpLevScrollBarWidget
location: class synthdrivers.RolandGP16.RolandGP16SingleEditor
  addWidget(eq,new ExpLevScrollBarWidget("Low Level",patch,0,48,-24,new 
ParamModel(patch,0x2C+8),
                   ^

It's all about the RolandGP16 driver; Maybe a missing semi colon? But 
when looking in thte file I cannot see anything.

[...]

> Sounds like a good way to start.

So I did and wrote the steps to a text file for the documentation :) .

[...]

> http://www.borg.com/~jglatt/tech/midispec/identity.htm

Cool, never knew this before. Here's what I got:

Sent:
amidi -p hw:3,0,8 -S "f0 7e 7f 06 01 f7"

Received:
amidi -p hw:3,0,8 -d
F0 7E 7F 06 02 00 01 05 00 00 04 00 01 00 21 00 F7  

*Very* nice :) .

> That depends partly on how you send / recieve the data.  Is the
> global data sent separately from the patchbay definitions?

Yes. It can be requested and it gets sent as soon as one changes any 
setting via the front panel.

There are even separate request commands (and replies) for each 
individual patchbay definition (8 presets).

[lotsa XML stuff removed]

OK, got it, thanks a bunch. Next steps will be to create globals.xml and 
patchbays.xml => tomorrow.

Thanks for the help.

> The decoder and checksum will normally go inside the patch file.  If
> there is no checksum you will probably need to create a checksum
> plugin that does nothing.

OK, I will dive into other checksum plugins and see if I can get done 
anything by myself.


Best regards


ce

Re: [Jsynthlib-devel] Help building drivers: first steps

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

Hi. Responses inline:

On 3/7/06, Christoph Eckert <ce...@ch...> wrote:
> Hi,
>
>
> still I cannot build JSynthLib from CVS, I guess it is due to the
> addition of jdom.

Did you get the updated makefile?  What errors are you getting?

> But anyway I already would like to dive a bit into writing an XML
> driver.
>
> I wonder if I can simply start by creating the directories
> org/jsynthlib/jsynthlib/synthdrivers/maudio/midisport8x8/
> and copy over the file YamahaMotif.xml as MaudioMidisport8x8.xml.

Sounds like a good way to start.

> No I start editing it. The first thing that wonders me is the
> <inquiryid>F07E7F06024300417[CDE]040000007FF7</inquiryid><!-- regex -->
> from the Yamaha Motif file. Is this the answer awaited *from* the device
> after sending a request or is this the Request to be *sent* to the
> device?
>
> As I did reverse engineer the device, I know the requests to be sent to
> it to retreive its memory contents. But I do *not* know if there is a
> special command to simply ask it "are you connected to the MIDI
> network?". Do I need it? Which data do I need to enter into
> <inquiryid></inquiryid>?

Many devices respond to the universal identity request.  You can read
an explanation of it at
http://www.borg.com/~jglatt/tech/midispec/identity.htm
This is the reply your device would send so JSL can automatically
detect it.  If it's not supported you should be able to leave it out
(although I've never tested that).

> Now the driver part. As I'm not that familiar with the Yamaha Motif, the
> example doesn't help here. So step by step:
>
> The memory of the Midisport 8x8 consists of 1 package of 27 bytes
> containing the global data and 8 packages containing one patchbay
> definition each. There's no checksum at all.
>
> So how to start? I read:

That depends partly on how you send / recieve the data.  Is the global
data sent separately from the patchbay definitions?  If so, you should
probably have a separate driver for each.  That would be something
like:

<driver>
  <name>Global Data</name>
  <!-- these are the names shown in the sysex get and send dialogs: -->
  <banknames>
    <name>N / A</name>
  </banknames>
  <patchnames>
    <name>Global Data</name>
  </patchnames>

   <patch file=3D"globals.xml" />
   <class>globals.groovy</class>
</driver>
<driver>
  <name>Patchbay</name>
  <!-- these are the names shown in the sysex get and send dialogs: -->
  <banknames>
    <name>N / A</name>
  </banknames>
  <patchnames>
    <name>Patchbay 1</name>
    <name>Patchbay 2</name>
    <name>Patchbay 3</name>
    <name>Patchbay 4</name>
    <name>Patchbay 5</name>
    <name>Patchbay 6</name>
    <name>Patchbay 7</name>
    <name>Patchbay 8</name>
  </patchnames>

   <patch file=3D"patchbays.xml" />
   <class>patchbays.groovy</class>
</driver>


The decoder and checksum will normally go inside the patch file.  If
there is no checksum you will probably need to create a checksum
plugin that does nothing.

Re: [Jsynthlib-devel] XML patch saving....

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

Okay.  Let me explain a little about how the XML parser I built works.
 The basic idea is that has a list of element names which can have
child elements.  When it encounters the start tag for one of these
elements, it starts building an object.
So if there was an xml file like this:

<patchbasket>
<patch>
<author>foo</author>
</patch>
</patchbasket>

The parser would:
1) Create a patchbasket object
2) create a patch object
3) Use introspection to find (and call) a setter (in the patch)
setAuthor(String) or addAuthor(String)
4) Use introspection to find (and call) a setter in the basket class
setPatch or addPatch which will accept the created patch
5) Return the patchbasket object

So to set up the parser we need to tell it:
1) Which element should cause it to start building an object
2) How to create those objects

With that foundation, my recommendation (which I explained terribly in
my last email) is to allow two generating elements: patchbasket and
patch.  Any other element would be treated as a string property by the
parser.  Then each IPatch implementation has to have some sort of a
write method, plus matching setters.  We should probably have some
sort of helper for binary data.  The implementation would look
somthing like this:

void write(XMLWriter xml) {
  xml.writeProperty("author", self.author);
  xml.writeBinaryProperty("data", self.sysex);
}

void setAuthor(String author) { /* ... */ }
void setData(String data) { self.sysex =3D XMLTools.decodeBinary(data); }


On 3/7/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > I just glanced at the code.  It looks like you're casting everything
> > in the PatchBasket to Patch.
> That was before I realized that SceneLibrary was also saving through the
> same code. So, at the very least, I have to check if it's an instance of
> a Patch or a Scene.
> > That won't work with the XML driver (or
> > any other custom Patch classes).  It looks like a simple solution for
> > doing the output would be to make IPatch extend
> > org.jsynthlib.utils.Writable, and use org.jsynthlib.utils.XMLWriter
> > instead of the JDOM XMLOutputter.  Then each patch implementation only
> > needs to add a write method.
> >
> > Reading the XML files back in is more complicated, because the parser
> > needs to know what it should do with the elements it gets
> This was my first misgiving about having each patch implementation
> define a write method. Your options for reading are:
> 1 - Have the code for reading the XML be in different classes from the
> code for writing them (very, very bad form, in my opinion), or
> 2 - Have each patch implementation define a read method as well.
>
> The problem I have with #2 is that it seems like we'd end up using it
> much like we find the driver for a sysex. We just give it to each driver
> and ask it if it recognizes it. I'd like to avoid that for patch
> implementations.
> > (either call
> > a setter method with the string contents, or build an object, then
> > call a setter).  This probably means we need to decide on some
> > restrictions on how patches can store themselves.
> Well, here's another thought I had. Right now, Patch has some fields
> named Author and Date, I think. However, they're no longer used to hold
> author and date. They're called "Field 1" and "Field 2" in the
> LibraryFrame. We *could* just allow any number of name/value pairs (ie
> "String getValue(String name)" and "void setValue(String name, String
> value)"), and then the XML code would have no trouble at all retrieving
> them and setting them. How the individual classes chose to use them
> would be up to them. If we wanted some tighter controls, we could allow
> Patch subclasses to define an array of allowed value names (ie
> "allowedNames =3D new String[] {'Author', 'Date', 'Comment', 'FromPatch',
> 'FromBank' ") and we could trigger an ErrMsg if the XML file contained a
> non-allowed value name.
>
> To downside to all of this is that it would be a burden for the Patch
> subclasses to access their own data, since they'd probably always have
> to use their own getValue and setValue methods. Also, dealing with any
> data other than String would be a bother.
>
> An alternative would be to have the XML code use inspection to find all
> matched getter/setters, discover the data type, and magically
> save/restore them. The downsides to this would be:
> 1 - The XML code becomes significantly more complex and error-prone
> 2 - We would have to decide on how to have the XML code cope if it
> encounters a getter/setter that it doesn't know how to save (like if a
> getter returns a Vector, or Hashtable, say).
> 3 - Anybody who subclasses Patch would have to remember to make public
> getter *and* setter methods for any new data elements that they want
> saved. If they *forget* to do so, this could lead to a "why isn't my
> field getting saved?" problem that is tough to track down.
>
> - Joe
>
>
>

Re: [Jsynthlib-devel] Help building drivers: first steps

[Christoph E. <ce...@ch...>]

Hi,


still I cannot build JSynthLib from CVS, I guess it is due to the 
addition of jdom.

But anyway I already would like to dive a bit into writing an XML 
driver.

I wonder if I can simply start by creating the directories
org/jsynthlib/jsynthlib/synthdrivers/maudio/midisport8x8/
and copy over the file YamahaMotif.xml as MaudioMidisport8x8.xml.

No I start editing it. The first thing that wonders me is the
<inquiryid>F07E7F06024300417[CDE]040000007FF7</inquiryid><!-- regex -->
from the Yamaha Motif file. Is this the answer awaited *from* the device 
after sending a request or is this the Request to be *sent* to the 
device?

As I did reverse engineer the device, I know the requests to be sent to 
it to retreive its memory contents. But I do *not* know if there is a 
special command to simply ask it "are you connected to the MIDI 
network?". Do I need it? Which data do I need to enter into 
<inquiryid></inquiryid>?

Now the driver part. As I'm not that familiar with the Yamaha Motif, the 
example doesn't help here. So step by step:

The memory of the Midisport 8x8 consists of 1 package of 27 bytes 
containing the global data and 8 packages containing one patchbay 
definition each. There's no checksum at all.

So how to start? I read:

<driver> <!-- should this have another name? -->
    <name>Normal Voice</name>
    <!-- inherit authors? -->
    <banknames>
      <name>User</name>
    </banknames>
    <patchnames>
      <sequence id="patchnums">
       <variable>id</variable>
        <start>0</start>
        <end>127</end>
        <!-- format 0 to A-1, 17 to B-2, etc -->
        <value>"${(char)(65 + id/16)}-${id%16 + 1}"</value>
      </sequence>
    </patchnames>

    <!-- the following are defaults to be inherited by sysex blocks -->
    <decoder type="BE 7bit words" />
    <checksum type="twos complement">
      <start>3</start><!-- byte offset, doesn't include status byte -->
      <end>-2</end>
      <address>-1</address>
    </checksum>

    <patch file="normal_voice.xml" />
    <editor>test2.xml</editor>

    <class>normal_voice.groovy</class>

  </driver>


Sorry, but I really don't know how to translate this for the Midisport 
8x8, so any help would be cool to get me started.


Best regards


ce

Re: [Jsynthlib-devel] JDom dependancy

[Christoph E. <ce...@ch...>]

Hi,


> I thoughts I added the jdom.jar to CVS. So you should only need to
> include it in your classpath along with groovy.jar.

I downloaded the jdom.jar binary. Any hints where to place and where to 
include it?


Thanks,


ce

Re: AW: [Jsynthlib-devel] Help building drivers: first steps

[Christoph E. <ce...@ch...>]

Hi,


> have you read the discussion about the "JDom dependancy"? ;-)

(read, read, read...)

Yes, I have ;-)


Best regards


ce

Re: [Jsynthlib-devel] XML patch saving....

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

Rib Rdb wrote:
> I just glanced at the code.  It looks like you're casting everything
> in the PatchBasket to Patch.
That was before I realized that SceneLibrary was also saving through the 
same code. So, at the very least, I have to check if it's an instance of 
a Patch or a Scene.
> That won't work with the XML driver (or
> any other custom Patch classes).  It looks like a simple solution for
> doing the output would be to make IPatch extend
> org.jsynthlib.utils.Writable, and use org.jsynthlib.utils.XMLWriter
> instead of the JDOM XMLOutputter.  Then each patch implementation only
> needs to add a write method.
>
> Reading the XML files back in is more complicated, because the parser
> needs to know what it should do with the elements it gets
This was my first misgiving about having each patch implementation 
define a write method. Your options for reading are:
1 - Have the code for reading the XML be in different classes from the 
code for writing them (very, very bad form, in my opinion), or
2 - Have each patch implementation define a read method as well.

The problem I have with #2 is that it seems like we'd end up using it 
much like we find the driver for a sysex. We just give it to each driver 
and ask it if it recognizes it. I'd like to avoid that for patch 
implementations.
> (either call
> a setter method with the string contents, or build an object, then
> call a setter).  This probably means we need to decide on some
> restrictions on how patches can store themselves.
Well, here's another thought I had. Right now, Patch has some fields 
named Author and Date, I think. However, they're no longer used to hold 
author and date. They're called "Field 1" and "Field 2" in the 
LibraryFrame. We *could* just allow any number of name/value pairs (ie 
"String getValue(String name)" and "void setValue(String name, String 
value)"), and then the XML code would have no trouble at all retrieving 
them and setting them. How the individual classes chose to use them 
would be up to them. If we wanted some tighter controls, we could allow 
Patch subclasses to define an array of allowed value names (ie 
"allowedNames = new String[] {'Author', 'Date', 'Comment', 'FromPatch', 
'FromBank' ") and we could trigger an ErrMsg if the XML file contained a 
non-allowed value name.

To downside to all of this is that it would be a burden for the Patch 
subclasses to access their own data, since they'd probably always have 
to use their own getValue and setValue methods. Also, dealing with any 
data other than String would be a bother.

An alternative would be to have the XML code use inspection to find all 
matched getter/setters, discover the data type, and magically 
save/restore them. The downsides to this would be:
1 - The XML code becomes significantly more complex and error-prone
2 - We would have to decide on how to have the XML code cope if it 
encounters a getter/setter that it doesn't know how to save (like if a 
getter returns a Vector, or Hashtable, say).
3 - Anybody who subclasses Patch would have to remember to make public 
getter *and* setter methods for any new data elements that they want 
saved. If they *forget* to do so, this could lead to a "why isn't my 
field getting saved?" problem that is tough to track down.

- Joe

AW: AW: [Jsynthlib-devel] Help building drivers: first steps

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

Hi,

I think the first priority is a working CVS source tree.

We can remove the jdom.jar at any time later on, should be no problem.

But someone who doesn't read this mailing list would perhaps
spend some time searching for the compiling errors when trying
to build the latest CVS source. And I see no reason to waste
anybody's time with something like that. ;-)

Cheers,
Joachim=20

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von Joe Emenaker
> Gesendet: Dienstag, 7. M=E4rz 2006 09:51
> An: JSynthLib Development
> Betreff: Re: AW: [Jsynthlib-devel] Help building drivers: first steps
>=20
> Joachim Backhaus wrote:
> > Hi,
> >
> > have you read the discussion about the "JDom dependancy"? ;-)
> >  =20
> Funny.
>=20
> Thanks to Joachim and to Rib Rdb for making the changes to=20
> the build.xml=20
> and makefile.vars. I had meant to make these changes=20
> (including to the=20
> shell script for running JSL in Linux), but I was waiting to see if=20
> anyone had any issues with the XML stuff (*aside* from the=20
> fact that you=20
> had to add jdom.jar by hand, I mean) before I made all of the=20
> other changes.
>=20
> - Joe
>=20

Re: [Jsynthlib-devel] XML patch saving....

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

I just glanced at the code.  It looks like you're casting everything
in the PatchBasket to Patch.  That won't work with the XML driver (or
any other custom Patch classes).  It looks like a simple solution for
doing the output would be to make IPatch extend
org.jsynthlib.utils.Writable, and use org.jsynthlib.utils.XMLWriter
instead of the JDOM XMLOutputter.  Then each patch implementation only
needs to add a write method.

Reading the XML files back in is more complicated, because the parser
needs to know what it should do with the elements it gets (either call
a setter method with the string contents, or build an object, then
call a setter).  This probably means we need to decide on some
restrictions on how patches can store themselves.  Perhaps something
like:
<patchlib type=3D"scene, library, etc">
  <patch type=3D"classname">
    <author>Whatever</author>
    <!-- and other string values as determined by the implementation -->
   <!-- or sub patches for bank patches -->
  </patch>
</patchlib>

On 2/22/06, Joe Emenaker <jo...@em...> wrote:
> As the first step toward getting the classes refactored into a sane
> package hierarchy, I have committed my changes to support saving patches
> to XML.
>
> Here's the rundown:
>  o For the time being, I'm using the jdom.jar library.... so you'll need
> to add jdom.jar to your classpath. Just look for any place where you
> have "groovy.jar" and change it to either "groovy.jar; jdom.jar" or
> "groovy.jar:jdom.jar". I don't remember if the "colon vs. semicolon"
> thing is platform-dependent.
>
>  o Whenever you save any library (*just* libraries.... I haven't done
> scenes, yet), they are saved as the original "something.patchlib" file
> as well as "something.patchlib.xml".
>
>  o When you load a file, you'll still be loading the original
> ".patchlib" versions of your library. To change this, you need to open
> AbstractLibraryFrame and look for "void open(File file)". In that
> method, you'll see two boolean values: "readXMLFile" and "readOldFile".
> IF YOU MAKE BOTH OF THESE TRUE, YOU'LL GET TWO COPIES OF EACH PATCH! I
> did this so that you can load both versions at the same time and then
> open them both in a patch editor and see if there is any difference.
> Just be warned, however, that if you *save* the library after that, both
> the .patchlib and the .patchlib.xml will now have duplicates. So, if you
> load, save, load, save, etc. with both booleans set to "true", your
> library will double each time, and it will get really big really fast. I
> learned this the hard way. :)
>
>  o The patch data is compressed via gzip and then converted to base64
> and then saved in the XML file. As a result, I've seen the XML file be
> anywhere from 10% to 50% the size of the .patchlib.
>
> =3D=3D=3D=3D Things to think about while trying this =3D=3D=3D=3D
>
>  o Right now, so that the XML file is closely associated with the
> .patchlib file, I've named it .patchlib.xml. What extension do we want
> to have permanently?
>
> - Joe
>
>
>

Re: AW: [Jsynthlib-devel] Help building drivers: first steps

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

Joachim Backhaus wrote:
> Hi,
>
> have you read the discussion about the "JDom dependancy"? ;-)
>   
Funny.

Thanks to Joachim and to Rib Rdb for making the changes to the build.xml 
and makefile.vars. I had meant to make these changes (including to the 
shell script for running JSL in Linux), but I was waiting to see if 
anyone had any issues with the XML stuff (*aside* from the fact that you 
had to add jdom.jar by hand, I mean) before I made all of the other changes.

- Joe

AW: [Jsynthlib-devel] Help building drivers: first steps

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

Hi,

have you read the discussion about the "JDom dependancy"? ;-)

Cheers,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von Christoph Eckert
> Gesendet: Montag, 6. M=E4rz 2006 19:49
> An: jsy...@li...
> Betreff: [Jsynthlib-devel] Help building drivers: first steps
>=20
> Hi,
>=20
>=20
> OK, I have checked out the source from CVS, but as I'm not=20
> familiar to=20
> Java I don't know how to build it.
>=20
> I simply tried to invoke make. There's some action but then I=20
> get some=20
> unresolved symbols like the following:
>=20
> ./core/XMLFileUtils.java:103: cannot resolve symbol
> symbol  : class JDOMException
> location: class core.XMLFileUtils
>         catch (JDOMException e) {
>                ^
>=20
> The machine is a Gentoo box and 0.2.0 alpha did emerge fine,=20
> so I guess=20
> that I should have installed any dependencies correctly. Do I need to=20
> set some variables like header paths etc.?
>=20
>=20
> Thanks,
>=20
>=20
> ce
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language
> that extends applications into web and mobile media. Attend=20
> the live webcast
> and join the prime developer group breaking into this new=20
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&
> dat=3D121642
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

Re: [Jsynthlib-devel] New member :)

[Christoph E. <ce...@ch...>]

> The XML version of the motif driver is in the
> org.jsynthlib.jsynthlib.synthdrivers.yamaha.motif package.

Ah, got it, sorry. I'm not yet familiar what a "package" is in Java 
meanings, but found the directory now.

> I was 
> writing the XD-5 driver as I was writing the tutorial, and I never
> finished it or the tutorial.

Anyway it will give me a starting point.

Thanks!


Best regards


ce

Re: [Jsynthlib-devel] New member :)

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

On 3/6/06, Christoph Eckert <ce...@ch...> wrote:
>
> > You can also look the the XML version of the Motif driver,
>
> the Yamaha Motif driver seems to be plain Java. Also there seems to be
> no XD-5 driver like mentioned in the tutorial. Can I download them
> somewhere outside the CVS tree?

The XML version of the motif driver is in the
org.jsynthlib.jsynthlib.synthdrivers.yamaha.motif package.  I was
writing the XD-5 driver as I was writing the tutorial, and I never
finished it or the tutorial.

Re: [Jsynthlib-devel] New member :)

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

On 3/6/06, Christoph Eckert <ce...@ch...> wrote:
>
> OK, I'd like to give it a try.  I'll ask the questions and if you agree
> I'll try to document the important steps in the Wiki so others can
> benefit as well. I'm already familiar with writing documentation, so
> yes it will need time but I'll try.

Sounds great!

> Question: Is it even possible to write an editor via XML or only a
> librarian?
>

There is a program called EditorBuilder that will read the XML
description of a patch, and then allow you to create an editor by
draging parameters onto a canvas.  It's been a while since I've worked
on it, so I can't remember exactly how finished it is.  I believe it's
possible to create editors as long as they only have one window and
use simple widgets (ie no widgets that edit multiple parameters like
envelope widgets).  I'll be finishing school in a few weeks though, so
I might actually have some time to start working on it again.=20
Especially if it's being used.

Re: [Jsynthlib-devel] New member :)

[Christoph E. <ce...@ch...>]

> You can also look the the XML version of the Motif driver,

the Yamaha Motif driver seems to be plain Java. Also there seems to be 
no XD-5 driver like mentioned in the tutorial. Can I download them 
somewhere outside the CVS tree?


Thanks,


ce

[Jsynthlib-devel] Help building drivers: first steps

[Christoph E. <ce...@ch...>]

Hi,


OK, I have checked out the source from CVS, but as I'm not familiar to 
Java I don't know how to build it.

I simply tried to invoke make. There's some action but then I get some 
unresolved symbols like the following:

./core/XMLFileUtils.java:103: cannot resolve symbol
symbol  : class JDOMException
location: class core.XMLFileUtils
        catch (JDOMException e) {
               ^

The machine is a Gentoo box and 0.2.0 alpha did emerge fine, so I guess 
that I should have installed any dependencies correctly. Do I need to 
set some variables like header paths etc.?


Thanks,


ce

Re: [Jsynthlib-devel] New member :)

[Christoph E. <ce...@ch...>]

Hi,


> The XML driver is probably the easiest solution if you don't know
> Java. =A0You don't have to compile anything, and the amount of code you
> have to actually write is greatly reduced.

this simply sounds amazing.

> You can find the beginning of a totorial I started writing for XML
> drivers at http://joe.emenaker.com/Wikka/wikka.php?wakka=3DXmlExample
>
> You can also look the the XML version of the Motif driver, and of
> course you can ask questons about it here.

OK, I'd like to give it a try.  I'll ask the questions and if you agree=20
I'll try to document the important steps in the Wiki so others can=20
benefit as well. I'm already familiar with writing documentation, so=20
yes it will need time but I'll try.

Question: Is it even possible to write an editor via XML or only a=20
librarian?


Best regards


ce

Re: [Jsynthlib-devel] New member :)

[Christoph E. <ce...@ch...>]

Hi,


> I have almost all of the messages from the developers' list for the
> past year... but they're stored as individual messages in my IMAP
> server. You probably need them in mbox format.

yes, but thanks anyway!

[...]

> Looks like the MidiSport 8x8 is much like the MOTU MidiXpress. I
> guess it all depends upon whether you can program the 8x8 by sending
> sysex messages to one of the ports on it.

At least on Linux the Midisport appears with 9 ports. The 9th is called 
"Control" and I can send and receive sysex via these ports. I can 
already program the device through these ports. I have written a shell 
script/Qt app which simplifies this process but both "only" generate 
the sysex files to send but cannot communicate with the device for 
themselves.

> Your best bet is probably to try the XML driver. One of the
> developers has put together a system that lets you use XML to
> describe the sysex format and the messages to request and store
> patches and banks. If you're not into programming Java, then this is
> probably the route you want to go.

Sounds very promising, but before I haven't actually done it I won't 
believe it :) .


Thanks & best regards


ce

Re: [Jsynthlib-devel] JDom dependancy

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

On 3/6/06, Joe Emenaker <jo...@em...> wrote:
> Joe Emenaker wrote:
> > It's so much of an improvement that some are expecting that JDOM will
> > eventually be incorporated into J2SE
> > (http://www.jcp.org/en/jsr/results?id=3D93). So, part of why I decided
> > to include jdom.jar is because I expect that, someday, we'll be able
> > to remove it when JDOM (or some other object-oriented XML suite)
> > becomes part of the standard J2SE implementation.
> I stand corrected. It turns out that the author of JDOM has withdrawn
> their bid to get JDOM included in J2SE
> (http://www.jdom.org/pipermail/jdom-interest/2004-September/014191.html).
>
> This leaves me with four courses of action (in increasing preference):
>
> 1 - Leave jdom.jar in JSL. (This is the option I like least)
> 2 - Convert my code in JSL that does XML stuff to use JAXP
> 3 - Get the source code for JDOM and actually include just the parts
> that I need to use into the actual JSL source tree (license permitting).
> 4 - Write my own classes that behave like JDOM (ie, they would have an
> object-oriented front-end while using the yucky JAXP-DOM classes for the
> actual work).
>
> I'll have to take another look at JAXP and see how distasteful it is and
> then I'll decide.

I've already worked on something like #4 for the XML driver (although
it's not based on the JDOM api or anything like that).
If I have time I'll try to look at the stuff you've added and see how
hard it would be to convert to use the XML driver's SAX parser.

And on a side note, Groovy seems to be on schedule with their plans
for integration into J2SE.

Re: [Jsynthlib-devel] JDom dependancy

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

Joe Emenaker wrote:
> It's so much of an improvement that some are expecting that JDOM will 
> eventually be incorporated into J2SE 
> (http://www.jcp.org/en/jsr/results?id=93). So, part of why I decided 
> to include jdom.jar is because I expect that, someday, we'll be able 
> to remove it when JDOM (or some other object-oriented XML suite) 
> becomes part of the standard J2SE implementation.
I stand corrected. It turns out that the author of JDOM has withdrawn 
their bid to get JDOM included in J2SE 
(http://www.jdom.org/pipermail/jdom-interest/2004-September/014191.html).

This leaves me with four courses of action (in increasing preference):

1 - Leave jdom.jar in JSL. (This is the option I like least)
2 - Convert my code in JSL that does XML stuff to use JAXP
3 - Get the source code for JDOM and actually include just the parts 
that I need to use into the actual JSL source tree (license permitting).
4 - Write my own classes that behave like JDOM (ie, they would have an 
object-oriented front-end while using the yucky JAXP-DOM classes for the 
actual work).

I'll have to take another look at JAXP and see how distasteful it is and 
then I'll decide.

- Joe

Re: [Jsynthlib-devel] JDom dependancy

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

Joachim Backhaus wrote:
> since when does JSynthLib depend on JDom?
>   
Please see my post to the developers' list dated Feb 22. 2006, when I 
added XML saving of patch data.
> This weekend I tried to compile the newest JSynthLib
> from the CVS source and got an error message because
> I don't have JDom installed.
>   
I thoughts I added the jdom.jar to CVS. So you should only need to 
include it in your classpath along with groovy.jar.
> IMHO JSynthLib shouldn't use external libraries if
> it cannot be avoided.
>   
I agree whole-heartedly. However, JDOM was the only sensible 
object-oriented XML library I could find for Java. Plain Java has SAX 
and DOM parsers built-in, but all of the examples I've seen for them are 
very ugly. Indeed, *some* of the examples I saw for *writing* XML with 
the built-in SAX and DOM didn't even *use* the XML classes at *all*. 
They just use print statements to print the XML directly... leaving the 
developer responsible for all formatting and well-formedness issues 
(like this one: 
http://www.cafeconleche.org/books/xmljava/chapters/ch03s02.html).

Meanwhile, JDOM allows for the developer to deal with the XML document 
in a completly object-oriented manner. It's so much of an improvement 
that some are expecting that JDOM will eventually be incorporated into 
J2SE (http://www.jcp.org/en/jsr/results?id=93). So, part of why I 
decided to include jdom.jar is because I expect that, someday, we'll be 
able to remove it when JDOM (or some other object-oriented XML suite) 
becomes part of the standard J2SE implementation.

Lastly, I included it because *somebody* (cough, cough...) already 
included groovy.jar... and that's about 10x as big as jdom.jar.

- Joe

[Jsynthlib-devel] JDom dependancy

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

Hi there,

since when does JSynthLib depend on JDom?

This weekend I tried to compile the newest JSynthLib
from the CVS source and got an error message because
I don't have JDom installed.

IMHO JSynthLib shouldn't use external libraries if
it cannot be avoided.

Cheers,
Joachim

[Jsynthlib-devel] New member :)

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

On 3/5/06, Joe Emenaker <jo...@em...> wrote:
> Your best bet is probably to try the XML driver. One of the developers
> has put together a system that lets you use XML to describe the sysex
> format and the messages to request and store patches and banks. If
> you're not into programming Java, then this is probably the route you
> want to go.

The XML driver is probably the easiest solution if you don't know
Java.  You don't have to compile anything, and the amount of code you
have to actually write is greatly reduced.

You can find the beginning of a totorial I started writing for XML
drivers at http://joe.emenaker.com/Wikka/wikka.php?wakka=3DXmlExample

You can also look the the XML version of the Motif driver, and of
course you can ask questons about it here.

Re: [Jsynthlib-devel] New member :)

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

Christoph Eckert wrote:
> a) Can anyone provide a list archive which I can use with kmail? I know 
> the web based archieve on sourceforge, but I dislike reading mail via a 
> HTML gateway
>   
I have almost all of the messages from the developers' list for the past 
year... but they're stored as individual messages in my IMAP server. You 
probably need them in mbox format.
> b) I need support for some devices. There's already a librarian for the 
> Access Virus, but additionally I'd like to see support for the 
> Midisport 8x8, the V-Amp2 and the m-audio TriggerFinger
>   
Looks like the MidiSport 8x8 is much like the MOTU MidiXpress. I guess 
it all depends upon whether you can program the 8x8 by sending sysex 
messages to one of the ports on it. If you can only program it via the 
USB port or through the legacy serial port, then the answer, for now, 
would be "no". JSL does not, at this time, use the USB or serial ports 
on the computer for anything... and I don't recall there ever being any 
plans to. JSL only talks to the outside world through the MIDI ports 
that the OS provides to it.
> c) I have no programming skills except some poor knowledge in Basic, 
> bash and even C++/Qt3. OTOH I'm familiar with sysex for a long time 
> now. I already have read the programming tutorial, but I failed because 
> I don't know how to compile the CVS source I checked out. I get a lot 
> of errors, and I'm not familiar with Java at all. So the question is: 
> Will I be able to write the drivers mentioned above? For all three 
> devices I need to write a programmer, not only a librarian.
>   
Your best bet is probably to try the XML driver. One of the developers 
has put together a system that lets you use XML to describe the sysex 
format and the messages to request and store patches and banks. If 
you're not into programming Java, then this is probably the route you 
want to go.

- Joe

[Jsynthlib-devel] New member :)

[Christoph E. <ce...@ch...>]

Hi all,


I just subscribed to the list, and of course I did because I have some 
questions ;-) .

I have been lurking around JSynthLib for a long time, but as my MIDI 
device isn't supported by OSS but ALSA, JSynthLib was no option for me.

These days I installed Tritonus et voila, JSynthLib was able to talk to 
my Virus via ALSA (though it complained about illegal checksum).

My questions:

a) Can anyone provide a list archive which I can use with kmail? I know 
the web based archieve on sourceforge, but I dislike reading mail via a 
HTML gateway

b) I need support for some devices. There's already a librarian for the 
Access Virus, but additionally I'd like to see support for the 
Midisport 8x8, the V-Amp2 and the m-audio TriggerFinger

c) I have no programming skills except some poor knowledge in Basic, 
bash and even C++/Qt3. OTOH I'm familiar with sysex for a long time 
now. I already have read the programming tutorial, but I failed because 
I don't know how to compile the CVS source I checked out. I get a lot 
of errors, and I'm not familiar with Java at all. So the question is: 
Will I be able to write the drivers mentioned above? For all three 
devices I need to write a programmer, not only a librarian.

For the Midisport 8x8 I have already written a shell script and a Qt-app 
to program it, but I'd like to see it in JSynthLib as well. This device 
seems to be a good starting point because it's a simple one. For the 
V-Amp2 there's a programmer called V-Amp design but it's Win only, not 
Mac or even Linux. For the TriggerFinger there's a programmer called 
Enigma (Mac and Windows), but to be honest, it's not a comfortable app. 
For all these devices I already have collected/reverse engineered some 
sysex commands, but the difficulty remains: Java programming :(


OK, that's it so far. I really appreciate some comments like "No, 
without any Java experiences you'll never be able to do it" or even 
RTFM :) .



Thanks & best regards


ce