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

Re: [Jsynthlib-devel] Conditional display of "What do you wish to do with the changed copy of the Patch?"

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

Rib Rdb wrote:
> On 2/6/06, Joe Emenaker <jo...@em...> wrote:
>   
> It looks like you are correct that the dialog is always displayed, and
> I agree that it should only be displayed if the patch was modified.
>   
Okay, then.... there are two ways to handle this:
1 - We can have the PatchEditorFrame superclass make a "before editing" 
copy of the patch (which it probably does anyway, since you can revert 
to it, right?) and then it can do a byte-by-byte comparison of the 
"after editing" data to decide whether anything was changed.
2 - We can have the PatchEditorFrame implement some kind of "boolean 
wasAltered()" method which would always default to "true", but each 
synthdriver could override.

Or, maybe we could have both. Maybe the default behavior would be a 
byte-by-byte comparison, but individual editors could override it in 
cases where the patch data was just too big.

- Joe

Re: [Jsynthlib-devel] (Inofficial) website for JSynthLib snapshot releases

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

Hi Joe,

On Tuesday 31 January 2006 13:01, Joe Emenaker wrote:
> Thorsten Klose wrote:
> > I started a
> > new webpage, which provides a link to a precompiled snapshot
> > release.
> The only one I saw on your webpage had the JSynthLib class compiled, but 
> everything else was *.java files. Was that your intention?

No, it wasn't my intention - most of the .class files are available, just only the 
new synthdrivers which are not part of the Makefile are missing.
I will take care for this during the next snapshot.

> By the way, I've discovered how to get Intellij-IDEA to package the 
> current build into a jar (whilst automatically including all dependent 
> .jars, like groovy.jar) and configure the MANIFEST.MF file to run the 
> appropriate class. That, combined with it's CVS features should let me 
> make you jars of every snapshot on the JSL CVS repository.

I don't know those tools (I'm not a java expert at all, just a user), but
the Makefile mechanism seems to be simple enough for an ingenuous 
guy like me ;-)

Best Regards, Thorsten.

Re: [Jsynthlib-devel] Conditional display of "What do you wish to do with the changed copy of the Patch?"

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

On 2/6/06, Joe Emenaker <jo...@em...> wrote:
> As far as I can tell, PatchEditorFrame.frameClosing displays the "What
> do you wish to do with the changed copy of the Patch?" dialog box
> *regardless* of whether the patch data was edited at all. Is this correct=
?
>
> If it is, then am I the only one who thinks that PatchEditorFrame should
> either compare the "before" and "after" data or there should be some
> "patchWasChanged()" method in each synth's SingleDriver that it could
> call to find out?

It looks like you are correct that the dialog is always displayed, and
I agree that it should only be displayed if the patch was modified.

[Jsynthlib-devel] Conditional display of "What do you wish to do with the changed copy of the Patch?"

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

As far as I can tell, PatchEditorFrame.frameClosing displays the "What
do you wish to do with the changed copy of the Patch?" dialog box
*regardless* of whether the patch data was edited at all. Is this correct?

If it is, then am I the only one who thinks that PatchEditorFrame should
either compare the "before" and "after" data or there should be some
"patchWasChanged()" method in each synth's SingleDriver that it could
call to find out?

- Joe

[Jsynthlib-devel] Added ChangeLog to CVS

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

Hi,

I added a changelog to CVS.

Currently it includes only the new synth drivers
and starts with version 0.20.

Would be nice if all developers have a look at it
and add that the changes which they knew of.

> I will add a "changelog.txt" to CVS.

I named it "ChangeLog" because this seems to be the most
common name for it.

Cheers,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von Joachim Backhaus
> Gesendet: Montag, 30. Januar 2006 09:21
> An: jsy...@li...
> Betreff: AW: [Jsynthlib-devel] Question about install of 0.20.0
>=20
> Hi,
>=20
> I'm using the latest CVS-version which is newer than "0.20-beta".
> But I'm also using it currently only on MS Windows.
>=20
> > and the web=20
> > site says it's a beta version...
>=20
> AFAIK JSynthLib releases where always considered beta, same
> with 0.19 or 0.18.
>=20
> > I wonder if there is a changelog anywhere that shows what=20
> the feature=20
> > additions are between these versions...
>=20
> A changelog does not exist by now, would be a good idea I think.
> So if nothings speaks against it (I will wait a few days for=20
> counter-arguments)
> I will add a "changelog.txt" to CVS.
>=20
> > I wonder what is the best version to be running then...  If 0.20 is=20
> > missing some things (an install directory, online docs...)
>=20
> Online documentation:
> http://www.jsynthlib.org/docs.html
>=20
> I don't really understand why we should need an "install=20
> directory". :-?
>=20
> > I mostly would just like to=20
> > support an ESQ-1
>=20
> Why? It is already supported. See:
> http://www.jsynthlib.org/synths.html
>=20
> But if you want to develop driver support you should always use
> the latest CVS-version of JSynthLib anyway.
>=20
> Cheers,
> Joachim
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: jsy...@li...=20
> > [mailto:jsy...@li...] Im=20
> > Auftrag von Brent Busby
> > Gesendet: Montag, 30. Januar 2006 01:58
> > An: jsy...@li...
> > Betreff: Re: [Jsynthlib-devel] Question about install of 0.20.0
> >=20
> > I wonder what is the best version to be running then...  If 0.20 is=20
> > missing some things (an install directory, online docs...),=20
> > and the web=20
> > site says it's a beta version...do the majority of you all run 0.19=20
> > then?  Or maybe 0.18?
> >=20
> > I notice that 0.18 is offered on the main site, but 0.19 is only on=20
> > Sourceforge.  Does that mean that 0.19 is deprecated?
> >=20
> > I wonder if there is a changelog anywhere that shows what=20
> the feature=20
> > additions are between these versions...  I mostly would=20
> just like to=20
> > support an ESQ-1, and if possible, accept raw sysex from a=20
> variety of=20
> > different synths that are not specifically listed for storing dumps=20
> > (like the Yamaha SY99 for example).
> >=20
> > --=20
> > + Brent A. Busby,   UNIX Systems Admin	 +   "It's like=20
> > being	+
> > + James Franck / Enrico Fermi Institute	 +   =20
> > blindsided by a	+
> > +     The University of Chicago		 +    flying=20
> > dwarf..."	+
> >=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://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&
> > dat=3D121642
> > _______________________________________________
> > Jsynthlib-devel mailing list
> > Jsy...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
> >=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://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

Re: [Jsynthlib-devel] Changes to the GenericDevice

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

On 2/5/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
>
> >I don't really remember this discussion, but your description of data
> >models sounds exactly like the Decoders used by the current XML
> >driver.  Perhaps we should find a way to combine the two ideas instead
> >of having two next-generation classes trying to accomplish the same
> >thing.
> >
> >
> Well, I'll tell you the things that I was trying to "fix" at the time,
> and you can tell me how much it matches what your decoders do.
>
> 1 - Just about every sysex message I've seen from a MIDI device has been
> of the form "0xF0 [manufacturerID] [deviceID] ... 0xF7". I find it a
> little strange that every synthdriver has to handle stripping/ignoring
> these bytes on incoming data and replacing them on outgoing data. I felt
> that each driver should be able to just set some manufacturerID and
> deviceID static variables and then some common code in JSL would handle
> stripping/replacing these automatically. For non-conforming MIDI
> devices, it would still be possible to access the raw patch data.

The XML driver automatically takes care of the 0xF0 at the beginning
and the 0xF7 at the end.  Synth drivers still have to handle the
manufacturer id, but if this is standard enough I suppose we could
change that.  Even so, it's not that hard to do.  For the Motif it
amounts to this:
      <constant>
        <name>YAMAHA ID</name>
        <default>0x43</default>
      </constant>
      <range>
        <name>device Number</name>
        <min>0</min>
        <max>0x0F</max>
      </range>
      <constant>
        <name>Model ID</name>
        <default>0x6B</default>
      </constant>


> 2 - Some synths use 8-bit data for their patch data, and then encode it
> into 7-bits *only* for transmission via the MIDI interface. So, before
> the synthdriver can do anything interesting with the data (ie, look up
> the patch names, edit patch data, etc), it first has to turn the 7-bit
> data back into 8-bit data (and it must do the reverse of this before it
> sends the data back out over the MIDI interface). Since it's tricky to
> write the encoders/decoders for this properly (and also since
> manufacturers, Alesis, for example, tend to use a certain encoding on
> multiple devices), it would be nice if we had a few classes that handled
> the most-common encoding methods.

This is what decoders are for.  They handle encoding and decoding
simple values as well as things such as signed numbers, strings, and
large numbers. Currently there are big and little endian versions of
decoders for synths that send data in either 4 or 7 bit chunks.

> 3 - Same goes for checksums.

There is also a Checksum class for this.  There is a BasicChecksum
which does a simple sum, but is designed to be easily subclassed for
implementing most other types of checksums.

> With just these three issues addressed, it's my hope that a beginner
> synthdriver author would be able to get started with a synthdriver very
> rapidly. For example, imagine some code like this:
>
> public class MyNewSynthDriver extends NextGenDriver {
>   static int manufacturerID =3D 0x41; // Roland
>   static int modelID =3D 0x001B; // GT-3
>   static dataModel =3D new BossDataModel();
>   static checksumModel =3D new BossChecksumModel();
>   static editorFrame =3D new HexDumpEditorFrame();
> }
>
> where they didn't even have to define any methods, yet they'd still be
> able to receive a patch dump from a device, have JSL realize that this
> is the driver for it, and for the user to be able to view a hex-dump of
> the decoded data.
>
> Now, I grant that this is a little over-simplified, but I'm trying to
> make it easy for a new synthdriver author to get *some* success. The
> first few times I tried to make a synthdriver several years ago, I
> couldn't get it to do *anything*, and I eventually went away in
> disappointment. It wasn't until later, after I had examined the Device,
> Driver, and BankDriver superclasses more closely, did I finally have
> some success. And I don't think that this should be necessary.

I agree that making a driver is too complicated.  The XML driver gets
rid of some complexities like modifying the synthdrivers.properties
file, recompiling, and tries to make building editors simpler using
EditorBuilder.

> Another thing I was trying to fix:
>
> 4 - I also feel that it would be helpful to be able to name each
> parameter with a textual name. If we did this, then we'd be able to do
> things with JSL like "Increase the parameter called 'ReverbRegeneration'
> by 10% on the selected patches".

As you can see in the above example, the XML driver supports this.
Drivers include a list of of their parameters, which includes names,
data types, location information used by the decoders, etc.  These
parameters can then be accessed by name.  EditorBuilder uses this
information to allow drag and drop creation of Editor interfaces.

Re: [Jsynthlib-devel] Changes to the GenericDevice

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

Rib Rdb wrote:

>I don't really remember this discussion, but your description of data
>models sounds exactly like the Decoders used by the current XML
>driver.  Perhaps we should find a way to combine the two ideas instead
>of having two next-generation classes trying to accomplish the same
>thing.
>  
>
Well, I'll tell you the things that I was trying to "fix" at the time,
and you can tell me how much it matches what your decoders do.

1 - Just about every sysex message I've seen from a MIDI device has been
of the form "0xF0 [manufacturerID] [deviceID] ... 0xF7". I find it a
little strange that every synthdriver has to handle stripping/ignoring
these bytes on incoming data and replacing them on outgoing data. I felt
that each driver should be able to just set some manufacturerID and
deviceID static variables and then some common code in JSL would handle
stripping/replacing these automatically. For non-conforming MIDI
devices, it would still be possible to access the raw patch data.

2 - Some synths use 8-bit data for their patch data, and then encode it
into 7-bits *only* for transmission via the MIDI interface. So, before
the synthdriver can do anything interesting with the data (ie, look up
the patch names, edit patch data, etc), it first has to turn the 7-bit
data back into 8-bit data (and it must do the reverse of this before it
sends the data back out over the MIDI interface). Since it's tricky to
write the encoders/decoders for this properly (and also since
manufacturers, Alesis, for example, tend to use a certain encoding on
multiple devices), it would be nice if we had a few classes that handled
the most-common encoding methods.

3 - Same goes for checksums.

With just these three issues addressed, it's my hope that a beginner
synthdriver author would be able to get started with a synthdriver very
rapidly. For example, imagine some code like this:

public class MyNewSynthDriver extends NextGenDriver {
  static int manufacturerID = 0x41; // Roland
  static int modelID = 0x001B; // GT-3
  static dataModel = new BossDataModel();
  static checksumModel = new BossChecksumModel();
  static editorFrame = new HexDumpEditorFrame();
}

where they didn't even have to define any methods, yet they'd still be
able to receive a patch dump from a device, have JSL realize that this
is the driver for it, and for the user to be able to view a hex-dump of
the decoded data.

Now, I grant that this is a little over-simplified, but I'm trying to
make it easy for a new synthdriver author to get *some* success. The
first few times I tried to make a synthdriver several years ago, I
couldn't get it to do *anything*, and I eventually went away in
disappointment. It wasn't until later, after I had examined the Device,
Driver, and BankDriver superclasses more closely, did I finally have
some success. And I don't think that this should be necessary.

Another thing I was trying to fix:

4 - I also feel that it would be helpful to be able to name each
parameter with a textual name. If we did this, then we'd be able to do
things with JSL like "Increase the parameter called 'ReverbRegeneration'
by 10% on the selected patches".

- Joe

Re: [Jsynthlib-devel] Changes to the GenericDevice

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

On 2/5/06, Joe Emenaker <jo...@em...> wrote:
> Daniel Appelt wrote:
>
> > For some reasons your changes give me compilation errors.
>
> Um... yeah. I noticed that. Part of the reason for this is because, when
> I made he changes to the GenericDevice, I was also planning on changing
> the way patches are decoded from their sysex messages. As it is now,
> every subclass of Driver or BankDriver has to manuall remove the 0xF0
> and the manufacturer and device ID's from the sysex messages. My plan
> was that we could have a variety of "DataModels" that would know how
> various manufacturers encode their sysex data... and those data models
> would handle all of the stripping of the 0xF0, 0xF7, and any
> manufacturer/device ID's as well as decoding the data back into 8-bit
> data if need be.
>
> When I presented the idea to this list, it caused a fair amount of
> debate, and some devels didn't think it was a good idea, so I didn't
> pursue it further. However, it turns out that the changes I made to
> GenericDevice rely on these DataModels that I was working on. So, now,
> I'm debating whether to just push forward with some next-generation
> Device class (which would CO-EXIST with the current one, not replace
> it), or whether to alter my changes to GenericDevice to use the old way.

I don't really remember this discussion, but your description of data
models sounds exactly like the Decoders used by the current XML
driver.  Perhaps we should find a way to combine the two ideas instead
of having two next-generation classes trying to accomplish the same
thing.

Re: [Jsynthlib-devel] Changes to the GenericDevice

[Daniel A. <dan...@us...>]

Ah, okay. I think I found the relevant thread in the archive - "Limitations
in ParamModel". Until now I only wrote a very simple "editor" for DSI
Evolver waveshape patches which merely consist of only one parameter - a
sampled sinlge-cycle waveform.  This editor extends=20
core.PatchEditorFramefor which the patch has to be passed in it's
constructor so that
stripping/converting of data is handled from there and not in the driver in
my case.

Your data models seem to model a patch as a whole in their parameterised
form which allows something more in the sense of the model-view-controller
pattern. Advantages could be less conversions from and to 7 bit sysex forma=
t
and an easier implementation of multiple views for a patch - although this
is not supported yet through the JSL user interface... Sounds rather useful
I would say.
To me this seems to be more of a specialisation of a patch then of a device
or driver. But then the coupling between the driver and patch implementatio=
n
in the core package is pretty tight... presumably to minimize the number of
classes which have to be written to support a new machine...

Cheers,
Daniel


2006/2/6, Joe Emenaker <jo...@em...>:
>
> Daniel Appelt wrote:
>
> > For some reasons your changes give me compilation errors.
>
> Um... yeah. I noticed that. Part of the reason for this is because, when
> I made he changes to the GenericDevice, I was also planning on changing
> the way patches are decoded from their sysex messages. As it is now,
> every subclass of Driver or BankDriver has to manuall remove the 0xF0
> and the manufacturer and device ID's from the sysex messages. My plan
> was that we could have a variety of "DataModels" that would know how
> various manufacturers encode their sysex data... and those data models
> would handle all of the stripping of the 0xF0, 0xF7, and any
> manufacturer/device ID's as well as decoding the data back into 8-bit
> data if need be.
>
> When I presented the idea to this list, it caused a fair amount of
> debate, and some devels didn't think it was a good idea, so I didn't
> pursue it further. However, it turns out that the changes I made to
> GenericDevice rely on these DataModels that I was working on. So, now,
> I'm debating whether to just push forward with some next-generation
> Device class (which would CO-EXIST with the current one, not replace
> it), or whether to alter my changes to GenericDevice to use the old way.
>
> I'll upload a working fix in a couple of days. So, don't panic... yet.
>
> - Joe
>
>
>

Re: [Jsynthlib-devel] Changes to the GenericDevice

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

Daniel Appelt wrote:

> For some reasons your changes give me compilation errors.

Um... yeah. I noticed that. Part of the reason for this is because, when
I made he changes to the GenericDevice, I was also planning on changing
the way patches are decoded from their sysex messages. As it is now,
every subclass of Driver or BankDriver has to manuall remove the 0xF0
and the manufacturer and device ID's from the sysex messages. My plan
was that we could have a variety of "DataModels" that would know how
various manufacturers encode their sysex data... and those data models
would handle all of the stripping of the 0xF0, 0xF7, and any
manufacturer/device ID's as well as decoding the data back into 8-bit
data if need be.

When I presented the idea to this list, it caused a fair amount of
debate, and some devels didn't think it was a good idea, so I didn't
pursue it further. However, it turns out that the changes I made to
GenericDevice rely on these DataModels that I was working on. So, now,
I'm debating whether to just push forward with some next-generation
Device class (which would CO-EXIST with the current one, not replace
it), or whether to alter my changes to GenericDevice to use the old way.

I'll upload a working fix in a couple of days. So, don't panic... yet.

- Joe

Re: [Jsynthlib-devel] Changes to the GenericDevice

[Daniel A. <dan...@us...>]

For some reasons your changes give me compilation errors. Is it possible
that you forgot to check in some of your changes? The following files do no=
t
seem to be of a proper version in the CVS:

core.LookupManufacturer, core.Utility and synthdrivers.AlesisSR16 (which
seems to be missing altogether in the repository)

Cheers,
Daniel


2006/2/4, Joe Emenaker <jo...@em...>:
>
> I made a couple of changes to GenericDevice that I just checked in.
> They're mostly of use to JSL developers, so we'll probably want a way to
> turn them on or off.
>
> One change is that, if you select "Edit" for a patch that isn't
> recognized by any driver (and, hence, is given to GenericDevice), then
> it brings up a hex dump of the patch. You'll sometimes have to wait a
> little bit for large patches, though. I'll add a progress bar soon.
>
> Another thing is that you can now use Generic in the "Get Patch" dialog
> to send a sysex identity request. The response from the synth (if any)
> will be put in the library and, if you try to Edit it, you'll see the
> ManufacturerID, DeviceID, etc.
>
> - Joe
>
>
>

[Jsynthlib-devel] Changes to the GenericDevice

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

I made a couple of changes to GenericDevice that I just checked in. 
They're mostly of use to JSL developers, so we'll probably want a way to 
turn them on or off.

One change is that, if you select "Edit" for a patch that isn't 
recognized by any driver (and, hence, is given to GenericDevice), then 
it brings up a hex dump of the patch. You'll sometimes have to wait a 
little bit for large patches, though. I'll add a progress bar soon.

Another thing is that you can now use Generic in the "Get Patch" dialog 
to send a sysex identity request. The response from the synth (if any) 
will be put in the library and, if you try to Edit it, you'll see the 
ManufacturerID, DeviceID, etc.

- Joe

Re: [Jsynthlib-devel] (Inofficial) website for JSynthLib snapshot releases

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

Thorsten Klose wrote:
> I started a
> new webpage, which provides a link to a precompiled snapshot
> release.
The only one I saw on your webpage had the JSynthLib class compiled, but 
everything else was *.java files. Was that your intention?

By the way, I've discovered how to get Intellij-IDEA to package the 
current build into a jar (whilst automatically including all dependent 
.jars, like groovy.jar) and configure the MANIFEST.MF file to run the 
appropriate class. That, combined with it's CVS features should let me 
make you jars of every snapshot on the JSL CVS repository.

- Joe

AW: [Jsynthlib-devel] (Inofficial) website for JSynthLib snapshot releases

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

Hi,

well JSynthLib has 4 project admins but none of them seems
to respond anymore.

@Brian, Gerrit, Hiroo, Torsten:

Where are you?

Would be nice if you can just post a quick note that you
all currently have no time or something like that.

Regards,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von Thorsten Klose
> Gesendet: Samstag, 28. Januar 2006 18:51
> An: jsy...@li...
> Betreff: [Jsynthlib-devel] (Inofficial) website for JSynthLib=20
> snapshot releases
>=20
>=20
> Hi *,
>=20
> since updates at jsynthlib.org are very rare, and I wanted to publish=20
> (just another) important bugfix in my MIDIbox drivers, I started a
> new webpage, which provides a link to a precompiled snapshot
> release. I will create new snapshots infrequently on requests, so
> if somebody has updated his own driver, or wants to publish
> a new one, then just drop me a mail.
>=20
> -> http://www.ucapps.de/jsynthlib.html
>=20
> Best Regards, Thorsten.
>=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://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&
> dat=3D121642
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

AW: [Jsynthlib-devel] Question about install of 0.20.0

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

Hi,

I'm using the latest CVS-version which is newer than "0.20-beta".
But I'm also using it currently only on MS Windows.

> and the web=20
> site says it's a beta version...

AFAIK JSynthLib releases where always considered beta, same
with 0.19 or 0.18.

> I wonder if there is a changelog anywhere that shows what the feature=20
> additions are between these versions...

A changelog does not exist by now, would be a good idea I think.
So if nothings speaks against it (I will wait a few days for =
counter-arguments)
I will add a "changelog.txt" to CVS.

> I wonder what is the best version to be running then...  If 0.20 is=20
> missing some things (an install directory, online docs...)

Online documentation:
http://www.jsynthlib.org/docs.html

I don't really understand why we should need an "install directory". :-?

> I mostly would just like to=20
> support an ESQ-1

Why? It is already supported. See:
http://www.jsynthlib.org/synths.html

But if you want to develop driver support you should always use
the latest CVS-version of JSynthLib anyway.

Cheers,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von Brent Busby
> Gesendet: Montag, 30. Januar 2006 01:58
> An: jsy...@li...
> Betreff: Re: [Jsynthlib-devel] Question about install of 0.20.0
>=20
> I wonder what is the best version to be running then...  If 0.20 is=20
> missing some things (an install directory, online docs...),=20
> and the web=20
> site says it's a beta version...do the majority of you all run 0.19=20
> then?  Or maybe 0.18?
>=20
> I notice that 0.18 is offered on the main site, but 0.19 is only on=20
> Sourceforge.  Does that mean that 0.19 is deprecated?
>=20
> I wonder if there is a changelog anywhere that shows what the feature=20
> additions are between these versions...  I mostly would just like to=20
> support an ESQ-1, and if possible, accept raw sysex from a variety of=20
> different synths that are not specifically listed for storing dumps=20
> (like the Yamaha SY99 for example).
>=20
> --=20
> + Brent A. Busby,   UNIX Systems Admin	 +   "It's like=20
> being	+
> + James Franck / Enrico Fermi Institute	 +   =20
> blindsided by a	+
> +     The University of Chicago		 +    flying=20
> dwarf..."	+
>=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://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&
> dat=3D121642
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

Re: [Jsynthlib-devel] Question about install of 0.20.0

[Brent B. <br...@ke...>]

I wonder what is the best version to be running then...  If 0.20 is 
missing some things (an install directory, online docs...), and the web 
site says it's a beta version...do the majority of you all run 0.19 
then?  Or maybe 0.18?

I notice that 0.18 is offered on the main site, but 0.19 is only on 
Sourceforge.  Does that mean that 0.19 is deprecated?

I wonder if there is a changelog anywhere that shows what the feature 
additions are between these versions...  I mostly would just like to 
support an ESQ-1, and if possible, accept raw sysex from a variety of 
different synths that are not specifically listed for storing dumps 
(like the Yamaha SY99 for example).

-- 
+ Brent A. Busby,   UNIX Systems Admin	 +   "It's like being	+
+ James Franck / Enrico Fermi Institute	 +    blindsided by a	+
+     The University of Chicago		 +    flying dwarf..."	+

Re: [Jsynthlib-devel] Question about install of 0.20.0

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

Brent Busby wrote:

> I am installing JSynthlib 0.20.0 on Linux.
> ...

> Next is says, "Then create a file linuxdevices.conf under the main 
> JSynthLib Directory to reflect your setup." Huh? What directory? I 
> don't have any directories. Both of these programs were offered as 
> bare jar files. I never extracted anything, and I don't have any 
> directories. What do they mean by this?

The directory for linuxdevices.conf is the same, as where 
JSynthLib-0.20.0.jar is in. At least JSynthLib found only 
MIDI-Interfaces when the linuxdevices.conf was in the same directory.

I never got a fully working JSynthLib and using J2re1.4 with 
MIDI-Provider. It worked after reinstalling with Java 1.5 (and 
linuxdevices.conf is not needed anymore).

> (In a related but less important question, I notice that when I click 
> on the "Help" option in the pulldown menus, it's trying but failing to 
> pull up documentation from a subdirectory "./doc" underneath of 
> JSynthLib's installed location. Is there supposed to be more to this 
> program than the jar file? If so, where do I get the rest of it?)

Same problem here...

Hth,
Bastian


	

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

[Jsynthlib-devel] Question about install of 0.20.0

[Brent B. <br...@ke...>]

I am installing JSynthlib 0.20.0 on Linux.

On the jsynthlib.org web site, the install instructions say to copy the 
executable jar file to a directory (presumably /usr/local/bin is ok) and 
run it with 'java -jar JSynthLib-XXX.jar' (where XXX is replaced with 
the real version number in the filename).  This part all makes sense, 
and launches the program as expected.

However, it also says in the section concerning Linux users who have 
pre-1.5 versions of Java that it is necessary to download and install 
the LinuxCharDev.jar and copy it to ./jre/lib/ext/ beneath whatever 
directory your Java is installed in.  That part makes sense too, and 
I've done that....

Next is says, "Then create a file linuxdevices.conf under the main 
JSynthLib Directory to reflect your setup."  Huh?  What directory?  I 
don't have any directories.  Both of these programs were offered as bare 
jar files.  I never extracted anything, and I don't have any 
directories.  What do they mean by this?

(In a related but less important question, I notice that when I click on 
the "Help" option in the pulldown menus, it's trying but failing to pull 
up documentation from a subdirectory "./doc" underneath of JSynthLib's 
installed location.  Is there supposed to be more to this program than 
the jar file?  If so, where do I get the rest of it?)

-- 
+ Brent A. Busby,   UNIX Systems Admin	 +   "It's like being	+
+ James Franck / Enrico Fermi Institute	 +    blindsided by a	+
+     The University of Chicago		 +    flying dwarf..."	+

[Jsynthlib-devel] (Inofficial) website for JSynthLib snapshot releases

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

Hi *,

since updates at jsynthlib.org are very rare, and I wanted to publish 
(just another) important bugfix in my MIDIbox drivers, I started a
new webpage, which provides a link to a precompiled snapshot
release. I will create new snapshots infrequently on requests, so
if somebody has updated his own driver, or wants to publish
a new one, then just drop me a mail.

-> http://www.ucapps.de/jsynthlib.html

Best Regards, Thorsten.

Re: [Jsynthlib-devel] DSI Evolver Support

[Daniel A. <dan...@us...>]

Hi Joachim,

Maybe the program "Active Ports" or "aports" helps but you should note
> the
> following information from symantec:
> http://securityresponse.symantec.com/avcenter/venc/data/securityrisk.apo
> rts.html


Thank you for this information. I will eventually take a look at
portscanners. For now the solution with port 443 works quite well.

> 2.) The file synthdrivers.properties seems to be write protected in
> the CVS which raises an exception when running core/DeviceListWriter.
>
> Why not simply remove the "write protection"?


I did that, of course. But before doing so my first attempt was to look int=
o
DeviceListWriter to make sure that everything was set up correctly in there=
.
So it took me some minutes to find the problem...

A solution could be to delete synthdrivers.properties in the repository and
re-submitting it as read-write file. Otherwise I would recommend to mention
the problem in the Programming Documentation. It would make life a little
bit simpler for people who want to start writing a new driver.

PS: Please open a feature request for the DSI Evolver driver support to
> inform other people that you are currently working on it.
> See the other feature requests for examples.
>

Done.

Greetings,
Daniel

AW: [Jsynthlib-devel] DSI Evolver Support

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

Hi Daniel,

> 1.) CVS checkout via pserver did not work for me. This seems to be
caused by firewall=20
> settings on my adsl router or in Windows XP. Could anyone give me=20
> advice on how to configure these? Inbound connections for the port
2401=20
> are allowed and forwarded to my client pc in the router.=20

Maybe the program "Active Ports" or "aports" helps but you should note
the
following information from symantec:
http://securityresponse.symantec.com/avcenter/venc/data/securityrisk.apo
rts.html


> 2.) The file synthdrivers.properties seems to be write protected in
the CVS which raises an exception when running core/DeviceListWriter.

Why not simply remove the "write protection"?

I don't know why but when I check out or update JSynthLib stuff
the files are always write protected.

The global "-w" option doesn't help:
" -w

Make new working files read-write. Overrides the setting of the $CVSREAD
environment variable. Files are created read-write by default, unless
$CVSREAD is set or `-r' is given."

E.g. I used this command:
cvs -w up -dP

Cheers,
Joachim

PS: Please open a feature request for the DSI Evolver driver support to
inform other people that you are currently working on it.
See the other feature requests for examples.



________________________________

	Von: jsy...@li...
[mailto:jsy...@li...] Im Auftrag von
Daniel Appelt
	Gesendet: Freitag, 27. Januar 2006 03:15
	An: jsy...@li...
	Betreff: [Jsynthlib-devel] DSI Evolver Support
=09
=09
	Hi there,
=09
	I started to work on support for Dave Smith Instruments' Evolver
the other day. A first version of a single driver is finished and will
be tested on the weekend hopefully.
=09
	I stumbled across the following problems:
=09
	1.) CVS checkout via pserver did not work for me. This seems to
be caused by firewall settings on my adsl router or in Windows XP. Could
anyone give me advice on how to configure these? Inbound connections for
the port 2401 are allowed and forwarded to my client pc in the router.
CVS checkout via port 443 as described in the SourceForge documentation
on firewalled access works fine though...
=09
	2.) The file synthdrivers.properties seems to be write protected
in the CVS which raises an exception when running core/DeviceListWriter.
=09
	Cheers,
	Daniel
=09
=09

[Jsynthlib-devel] DSI Evolver Support

[Daniel A. <dan...@us...>]

Hi there,

I started to work on support for Dave Smith Instruments' Evolver the other
day. A first version of a single driver is finished and will be tested on
the weekend hopefully.

I stumbled across the following problems:

1.) CVS checkout via pserver did not work for me. This seems to be caused b=
y
firewall settings on my adsl router or in Windows XP. Could anyone give me
advice on how to configure these? Inbound connections for the port 2401 are
allowed and forwarded to my client pc in the router. CVS checkout via port
443 as described in the SourceForge documentation on firewalled access work=
s
fine though...

2.) The file synthdrivers.properties seems to be write protected in the CVS
which raises an exception when running core/DeviceListWriter.

Cheers,
Daniel

Re: [Jsynthlib-devel] Compile Problems

[denis q. <dqu...@fr...>]

try to use Ant with the build.xml which is in CVS tree.
It's better to use Ant to compile Java since it handles src dir and  
lib dir without the need to list all paths.

--
Denis

> Well, it seems that my compile problems keep coming.
>
> If I try the first line, it already fails:
>
> javac -classpath '.:Groovy.jar:asm.jar' org/jsynthlib/*/*/*.java
> org/jsynthlib/*/*.java
>
> I get the following error:
>
> javac -classpath '.:Groovy.jar:asm.jar' org/jsynthlib/*/*/*.java
> org/jsynthlib/*/*.java
>
> Does anyone know what this can be ? I tried to compile every directory
> by hand but I still got errors wich is strange cause I didn't change
> anything from the standard distribution ...
>
> Greetz,
> Imco
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>
>

[Jsynthlib-devel] Compile Problems

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

Well, it seems that my compile problems keep coming.

If I try the first line, it already fails:

javac -classpath '.:Groovy.jar:asm.jar' org/jsynthlib/*/*/*.java 
org/jsynthlib/*/*.java

I get the following error:

javac -classpath '.:Groovy.jar:asm.jar' org/jsynthlib/*/*/*.java 
org/jsynthlib/*/*.java

Does anyone know what this can be ? I tried to compile every directory 
by hand but I still got errors wich is strange cause I didn't change 
anything from the standard distribution ...

Greetz,
Imco

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

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

Hi there,

I'm not a main developer ofcourse, but we are still active ;-) I'm 
waiting for my new MIDI interface to arrive, wich should be tomorrow 
and then we will commence working on the AN1X driver. I still have some 
small compile problems with Java but thats already been taking care of.

The site says the MKS-50 is only tested on a MKS-50, we own an Alpha 
Juno 2 so we could test that driver for the Alpha Juno's (I think their 
internal structures are identical).

Greetz,
Imco