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

AW: [Jsynthlib-devel] A Modest Proposal - Sampler Support for JSynthLib

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

Hi,

sox:
http://sox.sourceforge.net/

Regards,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von Joe
> Emenaker
> Gesendet: Mittwoch, 6. Juli 2005 08:27
> An: Craig A. Vanderborgh
> Cc: jsy...@li...
> Betreff: Re: [Jsynthlib-devel] A Modest Proposal - Sampler Support for
> JSynthLib
>=20
>=20
> Craig A. Vanderborgh wrote:
>=20
> > Well that's kind of silly, isn't it now??  After all, libst.a from=20
> > "sox" is totally unencumbered and supports the=20
> reading/writing of just=20
> > about any sample file format you could care to name.
>=20
> What's "libst.a", and what's "sox"?
>=20
> > Why pick a sample format if you can have them all?  Why is=20
> this even=20
> > an issue??
>=20
> I'm not sure, since I wasn't participating in that thread. I=20
> think the=20
> original idea was to just leave the samples in the native=20
> format of the=20
> instrument they came from. Maybe this was an issue when serialization=20
> was being used to store things... but I think we're moving to=20
> XML now...=20
> so maybe it's not an issue anymore. Dunno.
>=20
> - Joe
>=20

Re: [Jsynthlib-devel] A Modest Proposal - Sampler Support for JSynthLib

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

Craig A. Vanderborgh wrote:

> Well that's kind of silly, isn't it now??  After all, libst.a from 
> "sox" is totally unencumbered and supports the reading/writing of just 
> about any sample file format you could care to name.

What's "libst.a", and what's "sox"?

> Why pick a sample format if you can have them all?  Why is this even 
> an issue??

I'm not sure, since I wasn't participating in that thread. I think the 
original idea was to just leave the samples in the native format of the 
instrument they came from. Maybe this was an issue when serialization 
was being used to store things... but I think we're moving to XML now... 
so maybe it's not an issue anymore. Dunno.

- Joe

AW: [Jsynthlib-devel] A Modest Proposal - Sampler Support for JSynthLib

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

Hi Craig,

as JSynthLib is Open Source Software:

Just implement that feature! ;-)

Regards,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im=20
> Auftrag von Craig
> A. Vanderborgh
> Gesendet: Mittwoch, 6. Juli 2005 06:00
> An: Joe Emenaker
> Cc: jsy...@li...
> Betreff: Re: [Jsynthlib-devel] A Modest Proposal - Sampler Support for
> JSynthLib
>=20
>=20
> Joe Emenaker wrote:
>=20
> > Craig A. Vanderborgh wrote:
> >
> >> Hello Everyone:
> >>
> >> I just got JSynthLib downloaded and working on my Win2K=20
> system.  I'm=20
> >> interested in writing a patch editor for the Mirage, which=20
> I think I=20
> >> can figure out how to do.
> >>
> >> When it suddenly occurred to me:  Why couldn't JSynthLib=20
> also support=20
> >> samplers?  Obviously JSynthLib is already more than capable of=20
> >> managing sampler patches for "program data".  But what about the=20
> >> wavesample data?
> >
> >
> > This has been proposed and, as I recall, most of the JSL=20
> folk were in=20
> > support of it. The conversation stopped when the discussion=20
> turned to=20
> > what format to save the samples in.
> >
> Well that's kind of silly, isn't it now??  After all, libst.a=20
> from "sox"=20
> is totally unencumbered and supports the reading/writing of=20
> just about=20
> any sample file format you could care to name.  Why pick a=20
> sample format=20
> if you can have them all?  Why is this even an issue??
>=20
> Regards,
> craig
>=20
> > So, I think it is already a "to do" item, but we've got some other,=20
> > more pressing bugs/features to work on, first.
> >
> > - Joe
> >
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

Re: [Jsynthlib-devel] A Modest Proposal - Sampler Support for JSynthLib

[Craig A. V. <cr...@vo...>]

Joe Emenaker wrote:

> Craig A. Vanderborgh wrote:
>
>> Hello Everyone:
>>
>> I just got JSynthLib downloaded and working on my Win2K system.  I'm 
>> interested in writing a patch editor for the Mirage, which I think I 
>> can figure out how to do.
>>
>> When it suddenly occurred to me:  Why couldn't JSynthLib also support 
>> samplers?  Obviously JSynthLib is already more than capable of 
>> managing sampler patches for "program data".  But what about the 
>> wavesample data?
>
>
> This has been proposed and, as I recall, most of the JSL folk were in 
> support of it. The conversation stopped when the discussion turned to 
> what format to save the samples in.
>
Well that's kind of silly, isn't it now??  After all, libst.a from "sox" 
is totally unencumbered and supports the reading/writing of just about 
any sample file format you could care to name.  Why pick a sample format 
if you can have them all?  Why is this even an issue??

Regards,
craig

> So, I think it is already a "to do" item, but we've got some other, 
> more pressing bugs/features to work on, first.
>
> - Joe
>

Re: [Jsynthlib-devel] A Modest Proposal - Sampler Support for JSynthLib

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

Craig A. Vanderborgh wrote:

> Hello Everyone:
>
> I just got JSynthLib downloaded and working on my Win2K system.  I'm 
> interested in writing a patch editor for the Mirage, which I think I 
> can figure out how to do.
>
> When it suddenly occurred to me:  Why couldn't JSynthLib also support 
> samplers?  Obviously JSynthLib is already more than capable of 
> managing sampler patches for "program data".  But what about the 
> wavesample data?

This has been proposed and, as I recall, most of the JSL folk were in 
support of it. The conversation stopped when the discussion turned to 
what format to save the samples in.

So, I think it is already a "to do" item, but we've got some other, more 
pressing bugs/features to work on, first.

- Joe

[Jsynthlib-devel] A Modest Proposal - Sampler Support for JSynthLib

[Craig A. V. <cr...@vo...>]

Hello Everyone:

I just got JSynthLib downloaded and working on my Win2K system.  I'm 
interested in writing a patch editor for the Mirage, which I think I can 
figure out how to do.

When it suddenly occurred to me:  Why couldn't JSynthLib also support 
samplers?  Obviously JSynthLib is already more than capable of managing 
sampler patches for "program data".  But what about the wavesample data?

I know, I know.. JSynthLib is a MIDI patch librarian, a wavesample 
editor is a different external program, etc.  But try thinking 
out-of-the-box about this for a moment...

What if JSynthLib provided some sort of sample waveform widget, that 
could work side-by-side with the other JSynthLib widgets and controls.  
Then JSynthLib could be an integrated tool for working with samplers 
that would remove the spurious, needless distinction between MIDI 
program (patch) editing and waveform manipulation.

The result would be an editing environment for samplers that has GREATLY 
IMPROVED WORKFLOW, unmatched by even the best commercial software 
offerings for samplers today.  I don't think that the "wavesample 
widget" would need to be very sophisticated for it to be extremely 
useful either.  Primarily it would have to display and up/download (via 
SDS) to the sampler.

I hope that the JSynthLib crew will think about this powerful idea.  It 
would help JSynthLib become a true "killer app".

Regards,
craig vanderborgh

Re: [Jsynthlib-devel] Xinerama support

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

Rémi Gavrilovic wrote:

> I'm using a Xinerama based dual display. On this environment, JSL 
> centers dialogs over the two displays.
> I suggest you a one line patch to keep dialogs centered on one display.

That seems resonable. I guess I could add that to CVS...

> Please note that this change requires 1.4 or newer JDK.

I think that 1.4 is officially required by JSL now, anyway.... so I 
think that this is okay. I'll check and make sure, though....

- Joe

[Jsynthlib-devel] Xinerama support

[<gav...@us...>]

Hi,

I'm using a Xinerama based dual display. On this environment, JSL=20
centers dialogs over the two displays.
I suggest you a one line patch to keep dialogs centered on one display.

file JSynthLib/core/Utility.java line 134:
replace
Dimension screenSize =3D dialog.getToolkit().getScreenSize();
with
java.awt.Rectangle screenSize =3D=20
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment().getMaximumWind=
owBounds();

Please note that this change requires 1.4 or newer JDK.

--
R=E9mi

Re: [Jsynthlib-devel] RE: Jsynthlib-devel digest, Vol 1 #180 - 1 msg

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

Gor...@ne... wrote:

>Not meaning any disrespect or anything, but what is the goal of
>saving in XML format?
>  
>
The main goal is to switch to something *other* than what we have now 
(which I'll get to), and XML seems like as good of an option as any.

The reason to switch from the current format is related to the 
refactoring goal that some of the developers (including myself) have. 
Basically, those developers feel that having all of the classes in 
core.* is (at a minimum) ugly and confusing to new developers since it's 
not clear what classes deal with which functions of JSL (as opposed to 
having classes in packages like org.jsynthlib.midi, 
org.jsynthlib.library, org.jsynthlib.config, etc). In addition, it's 
probably confusing to *old* developers, too, in the sense that having 
everything in core.* lets them code classes with looser encapsulation 
(which I usually regard as a bad thing) than they'd be forced to with 
the classes spread over more packages.

Okay... got all that?

Now, the *problem* is, we can't move forward with the refactoring. Even 
though Eclipse, among other IDE's, could allow any of us to do it in 
about an hour, it would break all of the existing patchlibs because.... 
(drumroll, please...)    the current patchlib format uses Java 
serialization. So, whole objects (in our case, JSL's JTableModel in 
which it stores all of the patches/banks of a patchlib) are just dumped 
to a file (into which the Java serialization mechanism also stores the 
classnames of the objects). Because of this, if we move any of the 
classes like AbstractLibraryFrame or IPatch or Patch somewhere other 
than core.*, it will probably cause the serialization code to throw an 
exception because it can't find the classes anymore.

The serialization has already caused problems in the past. (And I'm a 
little foggy on this one so, if I don't have it completely right, 
forgive me). If you look at some of the core.* classes, you'll see that 
someone had to hard-code serialization ID's into some of the classes 
because a change was made to that class which changed Java's 
auto-generated serial number for it. I wasn't around when this took 
place, but that's the story I heard.

So... there seemed to be a consensus that, in order to move forward with 
the refactoring (ie, moving all of the classes into a more-sane package 
structure), we had to move away from the serialized patchlib format. 
So... what do we move to? XML seemed to be a reasonable choice because 
there are already plenty of tools which handle all of the checking of 
validity/well-formedness and which make it easy to read/write the 
documents. Lastly, it's both backward and forward compatible. Within 
certain limitations, we could make ammendments to the XML patchlib 
format such that:
  1 - Someone with a copy of JSL which uses the original XML format 
would be able to read/use the newer XML patchlib files, and
  2 - Someone with a newer copy of JSL which used the latest format 
would be able to read/use the older XML patchlib format files.

Is that reason enough? :)

- Joe

[Jsynthlib-devel] RE: Jsynthlib-devel digest, Vol 1 #180 - 1 msg

[<Gor...@ne...>]

Not meaning any disrespect or anything, but what is the goal of
saving in XML format?
Cheers,
Gord Wait

jsy...@li... wrote:

>Send Jsynthlib-devel mailing list submissions to
>    jsy...@li...
>
>To subscribe or unsubscribe via the World Wide Web, visit
>    https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>or, via email, send a message with subject or body 'help' to
>    jsy...@li...
>
>You can reach the person managing the list at
>    jsy...@li...
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Jsynthlib-devel digest..."
>
>
>Today's Topics:
>
>   1. Re: Ideas for XML patchfile format... (Joe Emenaker)
>
>--__--__--
>
>Message: 1
>Date: Fri, 24 Jun 2005 04:06:39 -0700
>From: Joe Emenaker <jo...@em...>
>To: JSynthLib Development <jsy...@li...>
>Subject: Re: [Jsynthlib-devel] Ideas for XML patchfile format...
>
>This is a cryptographically signed message in MIME format.
>
>--------------ms000708060201000702090509
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 7bit
>
>Joe Emenaker wrote:
>
>> I'm starting work on saving patch libraries to XML format instead of
>> the serialization format.
>
>I've got patch saving and loading working for any PatchBasket (ie,
>Library or Scene). I'll have to start working on a standalone converter
>for the old-style patchlibs.
>
>- Joe
>
>--------------ms000708060201000702090509
>Content-Type: application/x-pkcs7-signature; name="smime.p7s"
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment; filename="smime.p7s"
>Content-Description: S/MIME Cryptographic Signature
>
>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJHzCC
>AuowggJToAMCAQICAw65jDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
>ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
>bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTE3MTAxODE3WhcNMDYwNTE3MTAxODE3
>WjBfMREwDwYDVQQEEwhFbWVuYWtlcjEPMA0GA1UEKhMGSm9zZXBoMRgwFgYDVQQDEw9Kb3Nl
>cGggRW1lbmFrZXIxHzAdBgkqhkiG9w0BCQEWEGpvZUBlbWVuYWtlci5jb20wggEiMA0GCSqG
>SIb3DQEBAQUAA4IBDwAwggEKAoIBAQD6KiyIaglrLdWwqc4updTicpSwtmZ7SzJqX14r29LR
>1qFUPn+keetKaDofiYM/uOHb/bHaPNoVWCez3dy5j8IV+UrKMCLhifwJQQgcfTaAsi6hHgPl
>09FkMxhwDvVOjvEDwT27QK0XEV9+TfWExIOeoFSCb1XBMLlTmjY53LKtsZGdGs3vlTsZFldX
>fhcwgZy/HN7CVlhFnSAmFx6Gjf9UEkKYolfcX/57yHJFcezzR9141u760xkqj/+a48u1VDA1
>XidWbyYNGgNf5QuvcNo9nLaJuB0/e5S0Cc4uM1qsB8EYJvzLOMTOpDpmTKQxvDHP3lYOjLBc
>qrrXn3mtqebVAgMBAAGjLTArMBsGA1UdEQQUMBKBEGpvZUBlbWVuYWtlci5jb20wDAYDVR0T
>AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBamNO5AzKx4jeF/Djb/RP7m8WIJmyHWh3cMLJ6
>xVn5wGDex7jx8Z/XEwG6Lf9WU0YcALw1SWTN6JsCZFHpjy5Xn4OJ7OnvTNEOAULfj1Isu9QP
>NVzRpO04LqQh0RgBGXLr0Fr3ORCNdJSzoPgAZwaG2HKcgrxLjICS9e9aujQh0jCCAuowggJT
>oAMCAQICAw65jDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
>d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy
>ZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTE3MTAxODE3WhcNMDYwNTE3MTAxODE3WjBfMREw
>DwYDVQQEEwhFbWVuYWtlcjEPMA0GA1UEKhMGSm9zZXBoMRgwFgYDVQQDEw9Kb3NlcGggRW1l
>bmFrZXIxHzAdBgkqhkiG9w0BCQEWEGpvZUBlbWVuYWtlci5jb20wggEiMA0GCSqGSIb3DQEB
>AQUAA4IBDwAwggEKAoIBAQD6KiyIaglrLdWwqc4updTicpSwtmZ7SzJqX14r29LR1qFUPn+k
>eetKaDofiYM/uOHb/bHaPNoVWCez3dy5j8IV+UrKMCLhifwJQQgcfTaAsi6hHgPl09FkMxhw
>DvVOjvEDwT27QK0XEV9+TfWExIOeoFSCb1XBMLlTmjY53LKtsZGdGs3vlTsZFldXfhcwgZy/
>HN7CVlhFnSAmFx6Gjf9UEkKYolfcX/57yHJFcezzR9141u760xkqj/+a48u1VDA1XidWbyYN
>GgNf5QuvcNo9nLaJuB0/e5S0Cc4uM1qsB8EYJvzLOMTOpDpmTKQxvDHP3lYOjLBcqrrXn3mt
>qebVAgMBAAGjLTArMBsGA1UdEQQUMBKBEGpvZUBlbWVuYWtlci5jb20wDAYDVR0TAQH/BAIw
>ADANBgkqhkiG9w0BAQQFAAOBgQBamNO5AzKx4jeF/Djb/RP7m8WIJmyHWh3cMLJ6xVn5wGDe
>x7jx8Z/XEwG6Lf9WU0YcALw1SWTN6JsCZFHpjy5Xn4OJ7OnvTNEOAULfj1Isu9QPNVzRpO04
>LqQh0RgBGXLr0Fr3ORCNdJSzoPgAZwaG2HKcgrxLjICS9e9aujQh0jCCAz8wggKooAMCAQIC
>AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
>cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
>BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
>ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h
>aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
>BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
>EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF
>AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B
>1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A
>gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
>CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
>dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa
>MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M
>DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa
>C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1
>3iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
>dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
>ZW1haWwgSXNzdWluZyBDQQIDDrmMMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkq
>hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDYyNDExMDYzOVowIwYJKoZIhvcNAQkEMRYE
>FFRAm8IOlwhrP06cRuvtP9bn1cdcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI
>KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgG
>CSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
>aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1
>aW5nIENBAgMOuYwwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK
>ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u
>YWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDrmMMA0GCSqGSIb3DQEBAQUABIIBAFXwt4IoeMVM
>gGWU27MMMnn7HWSsUPI9PZu5KmwMnj/rC13LqQdANdEw/YXcR9LWyVRmQ/0UP76EuZDbPSpX
>r36DeauxkkU9bZfYDHx7mn3fIJ2Yt2TnFDunJMuG/NSabnwNbz4SdH4FAtBn4oXZbsLTz/wU
>uKHk0wTvZv7/hisBEUEEdPZ+UlO9v4ozc7D442yWrmpb0O4k+kr0RIbd/yIwd62eVKmksd7O
>2UDHfM6Sl+ud7yrKaMVVdd9qkeATLkrITjkBcx7HjvLbE7safRGCbfD/Nyg9F7KU/nhPofLT
>S3bTJ9ahSf8dS5MEo8e23o21ssyC1FPhZ+fm1bfuyGYAAAAAAAA=
>--------------ms000708060201000702090509--
>
>
>
>--__--__--
>
>_______________________________________________
>Jsynthlib-devel mailing list
>Jsy...@li...
>https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>
>
>End of Jsynthlib-devel Digest
>

__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp

Re: [Jsynthlib-devel] Ideas for XML patchfile format...

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

Joe Emenaker wrote:

> I'm starting work on saving patch libraries to XML format instead of
> the serialization format.

I've got patch saving and loading working for any PatchBasket (ie,
Library or Scene). I'll have to start working on a standalone converter
for the old-style patchlibs.

- Joe

[Jsynthlib-devel] Ideas for XML patchfile format...

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

I'm starting work on saving patch libraries to XML format instead of the 
serialization format.

What file extension do we want to use for this new file type (since we 
don't want it to be confiused with the *.patchlib ones)? "JPL" (for "JSL 
Patch Library"), "JLB" (for "JSL LiBrary"), or do we not want a 3-char 
extension and want something like ".library", or ".patches"?

Next, anybody want to discuss format? Right now, I'm figuring on 
something like:
<patchlib>
  <patch>
    <name>My First Patch</name>
    <comment>Probably a Alesis patch. Size=1324</comment>
    <sysexData encoding="base64" >
      AHKLKASFLKASFNMWKLRJWQLKQWHWOIQWUE...
      ...
    </sysexData>
  </patch>
</patchlib>

Although, if there will only be one name and one comment, then we can 
make them attributes instead of elements:
<patchlib>
  <patch name="My First Patch" comment="Probably a Alesis patch. 
Size=1324" >
    <sysexData encoding="base64" >
      AHKLKASFLKASFNMWKLRJWQLKQWHWOIQWUE...
      ...
    </sysexData>
  </patch>
</patchlib>

The type (single,bank, etc.) and the particular device they belong to 
don't need to be stored because JSL currently seems to "re-recognize" 
each patch when it reads a patchlib. I also realize that I left "Field1" 
and "Field2" out of the xml example. That's because I think we need to 
decide on a different way to handle them. If we're going to support 
generic fields, then let's make them *truly* generic and let the user 
name them whatever they want, like:

   <userfield name="Field1">Here's some text for Field1</userfield>

Frankly, I don't really like above idea much... but I think it's better 
than our current system of hard-coded (and numbered) field names.

- Joe

Re: [Jsynthlib-devel] Korg M1 Single Driver in progress, but need help!

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

Gor...@ne... wrote:

>Hi Joe, sounds like what you are working on is what I need to make things work.
>
Well, until you're able to download from CVS, it makes no sense for me 
to upload my changes.

>For now (to debug) I'll comment out the set patch/bank/etc sysex messages
>
I think all you have to do is override requestPatchDump. The default one 
(in Driver) sends a bank change, then a patch change, and then uses your 
sysexRequestDump (if it's defined) to request the patch.

- Joe

[Jsynthlib-devel] Korg M1 Single Driver in progress, but need help!

[<Gor...@ne...>]

Hi Joe, sounds like what you are working on is what I need to make things work. 

For now (to debug) I'll comment out the set patch/bank/etc sysex messages that are sent to the M1 so that it won't send back all the handshake stuff and mess up what I'm working on...

Cheers,
Gord


__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp

Re: [Jsynthlib-devel] Korg M1 Single Driver in progress, but need help!

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

Gord Wait wrote:

> The problem seems to be that for each sysex command sent to the M1, it 
> responds with a Sysex message back,

Well, you usually send a single-sysex "request" and get a single-sysex 
"response".... for single patches, anyway. Is this not what you're getting?

> so when JSYnthLib goes to read a patch dump sysex message from the 
> message queue, it gets all these other responses first, and fails to
> find the actual sysex patch.

The "Get Patch" dialog empties the input queue right before it sends the 
request. So, any sysex messages that you see should be as a direct 
result of the request you sent.

> I think also that the M1 is expecting a message by message handshake, 

There are a few other synths that prefer this... and, sadly, it looks 
like JSL doesn't support this yet. Take heart, though... it's going to. 
I'm working on it.

> and the way the X1 driver was structured, it just fires the batch of 
> sysex commands all at once. I think the M1 can't keep up.

Oh... I think I see what you're saying now. When requesting multiple 
patches, JSL needs to "pace" itself so that each next request happens 
after the response from the previous request has come in, right? If 
so... then I've got two things to say:
1 - I've written an improvement for JSL that will allow you to do this 
(basically, its a way for any class to ask to be notified any time a 
sysex message arrives). I haven't committed it to cvs yet, because it's 
kind of a major change to how sysex messages are passed in JSL, and I 
wanted to make sure that there aren't any bugs in it. However, since the 
cvs traffic has been nil for the past couple of months, I'm not sure 
anyone would notice even if I *did* break something.
2 - I thought you were working on a SingleDriver (ie, send/receive 
single patches). If so, what's with sending out multiple requests?

> So, my question is, can I somehow drain out the sysex responses as 
> they arrive, using a get command somehow from inside my 
> KorgM1SingleDriver class?

Not yet.... not that I know of.

> I would like to actually test the responses. The code would go 
> something like this:
>
> send(sysex message to set bank)
> waitfor (sysex message that says that worked)
> send(sysex message to set patch number)
> wait for( sysex message that says patch number setting worked, error 
> if not, yadayada..)

Actually, the way I've written it, it would be more like... you make a 
thread which sends the requests, one at a time. Each time it sends one, 
it pauses itself. Then, another method in the class would get called by 
the low-level midi receive stuff whever a midi message came in. Your 
method would inspect it and, if it was what you were expecting, then it 
tells your sender-thread to continue for another loop. If it wasn't what 
you expected, then your method would abort the sender thread. I guess it 
would be easy enough to wrap this into a "waitFor" method, though.

- Joe

[Jsynthlib-devel] Korg M1 Single Driver in progress, but need help!

[Gord W. <gw...@dc...>]

I'm working on a driver for the Korg M1,
working from the latest downloaded release (cvs wouldn't let me in..).

I'm still learning the ropes, so forgive the stupid questions:
Things are not working just yet, and it seems to be the following:
Trying out a "get" patch from the gui fails.

JSYnthLib is sending out a string of commands to set the bank number, 
patch number etc as I set up in the KorgM1SingleDriver.java file
I'm working on. (I copied KorgX1 stuff and started modifying).

The problem seems to be that for each sysex command sent to the M1, it 
responds with a Sysex message back,
so when JSYnthLib goes to read a patch dump sysex message from the 
message queue, it gets all these other responses first, and fails to
find the actual sysex patch.

I think also that the M1 is expecting a message by message handshake, 
and the way the X1 driver was structured, it just fires the batch
of sysex commands all at once. I think the M1 can't keep up.

So, my question is, can I somehow drain out the sysex responses as they 
arrive, using a get command somehow from inside my KorgM1SingleDriver class?
I would like to actually test the responses. The code would go something 
like this:

send(sysex message to set bank)
waitfor (sysex message that says that worked)
send(sysex message to set patch number)
wait for( sysex message that says patch number setting worked, error if 
not, yadayada..)

Etc.

This way the extra messages are drained, and tested, and the handshake 
slows down the whole works so the M1 can keep up...

Any pointers, or perhaps other synth drivers that use this idea?

Cheers,
Gord Wait

(ps I'm waiting for my email to join the discussion group..)

[Jsynthlib-devel] setDefaultLookAndFeelDecorated

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

Has anyone else noticed that only internal JFrames show the selected 
Look-and-Feel?

The main desktop window looks like a plain native-OS window. So do all 
JDialog windows (like MidiMonitor, or PrefsDialog).

In fact, in SDI mode, *all* windows and dialogs look like native-OS windows.

This can be changed by putting|
    JFrame.setDefaultLookAndFeelDecorated(true);
||    JDialog.setDefaultLookAndFeelDecorated(true);

somewhere before any of the frames are created (a good spot is probably 
in AppConfig.setLookAndFeel()).

Is there any reason I shouldn't do this? Was the native-OS look for the 
main JSL window and the dialogs intentional?

- Joe
|

[Jsynthlib-devel] AW: [jsynthlib-dev] JSynthLib EMU Vintage-Keys-Editor

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

Hello,

please use the Sourceforge list
http://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
as the yahoogroups list isn't used anymore.

> Maybe someone of you has some ideas to fix the problems.

Yeah, I'm not a clairvoyant, so if you don't post the error
messages you shouldn't expect to get an answer! ;-)

Regards,
J. Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@ya...
> [mailto:jsy...@ya...]Im Auftrag von Trame
> Gesendet: Sonntag, 5. Juni 2005 16:58
> An: jsy...@ya...
> Betreff: [jsynthlib-dev] JSynthLib EMU Vintage-Keys-Editor
>=20
>=20
> Hi!
>=20
> I've uploaded the JAVA-Sources of a Vintage-Keys-Editor. It's in an
> early Beta state.
> The export of sysex is not working and there are a few error-messages
> at the start of the editor. I'm working on that.
> Maybe someone of you has some ideas to fix the problems.
>=20
> Trame=20
>=20
>=20
>=20
>=20
>=20
> =20
> Yahoo! Groups Links
>=20
> <*> To visit your group on the web, go to:
>     http://groups.yahoo.com/group/jsynthlib-dev/
>=20
> <*> To unsubscribe from this group, send an email to:
>     jsy...@ya...
>=20
> <*> Your use of Yahoo! Groups is subject to:
>     http://docs.yahoo.com/info/terms/
> =20
>=20
>=20
>=20
>=20

[Jsynthlib-devel] Flaky MIDI interfaces...

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

I'm working on a driver for the Digitech DSP 256XL and I ran into a 
curious problem.

When I tried receiving a bulk dump from the device, I'd usually get a 
few dropped bytes. At first, I suspected that it was something wrong 
with the Digitech, but I tried it on another DSP 256XL and got the same 
results.

Then, I suspected that it was something wrong with the Linux drivers for 
my Roland UM-1 and/or the Java support for MIDI in JDK 1.5 on Linux. So, 
I tried running Windows XP with and using a C++ sysex send/receive 
program... and got the same results. Finally, I tried using the C++ 
sysex program with Windows XP using my MOTU MIDI Express XT, instead of 
the Roland UM-1... and *then* I got consistent sysex sizes.

So, now, I suspect that the Edirol UM-1 is a little flaky. Has anyone 
else experienced corrupt sysex dumps with any of the "cheaper" MIDI 
interfaces (like Soundblaster or UM-1 or MidiMan Uno)?

- Joe

Re: [Jsynthlib-devel] Boss GT-6B

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

joh...@co... wrote:

>Hi, I'm new to the list.  I would be willing to look into providing a driver for the Boss GT-6B.  Is this already being worked on by anybody?  I noticed under the RFE section that there is a request to support the Boss GT-3.  Is there any information from the GT-3 effort that could help me to get start on the GT-6B?
>  
>
Personally, I'd want to look into the sysex specs for the entire GT-? 
line to see how similar the specs are. Since there are now 4 different 
guitar GT's and possibly the same number of bass ones, it sure would be 
nice to be able to do all of them with one synthdriver.

I'm working on a few improvements to JSL which should make this easier 
to do.

- Joe

[Jsynthlib-devel] Boss GT-6B

[<joh...@co...>]

Hi, I'm new to the list.  I would be willing to look into providing a driver for the Boss GT-6B.  Is this already being worked on by anybody?  I noticed under the RFE section that there is a request to support the Boss GT-3.  Is there any information from the GT-3 effort that could help me to get start on the GT-6B?

Thanks,
John

[Jsynthlib-devel] Synth driver for the Yamaha UB99 Magic Stomp

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

I have made a synth driver for the Yamaha Magic Stomp Guitar Effects
Processor with full support.

You can download it here:

https://sourceforge.net/tracker/download.php?group_id=41208&atid=430007&file_id=135480&aid=1206627

Special features:
- abiltity to export and import files in the UB9 format. Files can be
loaded into the official Yamaha editor.
- Knobwidget with a clickable label to fine adjust the knob. The values
can be displayed in several formats.

I hope you like it. Let me know what you think of it.

Have fun,

Ton Holsink

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

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

Joe Emenaker wrote:

>I'm pretty sure that I can overhaul this and make it pretty slick,
>without all of this 10ms looping, and, in the process, put in support
>for MidiMessageFilters and reception of messages other than sysex ones.
>  
>
Well, it turned out to be easier than I had feared. I've now got a midi
input queue system that doesn't have to do any polling. The queues
notify any observers as messages come in. It will be easy, from here, to
add support for midi message filters on a per-observer basis, so we
could do things like... let the MidiMonitor be notified of all messages,
yet let SysexGetDialog only be notified of sysex messages, etc.

Another thing I plan to do soon is to add a "thru-filter". I'm currently
experimenting with a rackmount effects unit which seems to merge all
incoming messages through the out. So, when I request a patch from the
unit, the first thing I get back is the request I sent. I think I'm
going to have the midi sender keep a rotating queue of, say, the last 5
or so messages it sent out. If something comes in which exactly matches
it, it could be ignored.

- Joe

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

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

Rib Rdb wrote:

>...it might also be useful to specify how long a filter would last -
>ie "I'm only expecting one message like this, and I want to give up
>after 30 seconds"
>  
>
I think this is doable. There's already a "getMessage(int timeout)", so
we could make a "getMessage(MidiMessgageFilter filt, int timeout)".

However, things are getting a little odd as I'm looking at the low-level
midi code in JSL.

First off, MidiUtil is the second-largest file in core.*, at 33K. I
think it's a good candidate for being broken up into smaller classes,
because it's doing a lot of loosely-related things. One of its duties is
managing all of the sysex input queues (ie, arranging to have the JVM
deliver all incoming messages to the various queues, etc), and I think
all of that can be broken off into a "InputQueueManager" or something.

But that's not the scary part. The scary part is this. When MidiUtil
receives a SysexMessage object from the JVM, it puts it in the queue,
waiting for some part of JSL to come claim it. The problem is that these
SysexMessage objects from the JVM might *not* be complete sysex
messages, since large sysex messages can get broken up into smaller
chunks for transmission (with the device I was testing my code with, the
sysex dump was getting broken into two chunks). When this happens, I
think I recall that all but the last message has the 0xF7 stripped.

This causes a problem because, from the looks of it, MidiUtil leaves
these messages separated in the queue, and only combines them into a
single SysexMessage when you actually call getMessage(). Because they
aren't combined before then, my new code (which notifies various
"listeners" or "observers" about new messages when they arrive) ends up
notifying the listeners *multiple* times for each *complete* sysex message.

I'm thinking that a modest re-write of the input-queue parts of MidiUtil
is in order... especially since there are several comments in
getMessage() like "// THIS IS NOT CORRECT BEHAVIOR. !!!FIXIT!!!". There
are also some other practices in MidiUtil.getMessage() that aren't
really ideal. For example, if you call getMessage() and only the first
part of a long sysex message is in the queue, then it goes into a loop
where it checks for the rest of the sysex message every 10ms for
anywhere from 1s up to 10s.

I'm pretty sure that I can overhaul this and make it pretty slick,
without all of this 10ms looping, and, in the process, put in support
for MidiMessageFilters and reception of messages other than sysex ones.
However, this code in MidiUtil is so rough around the edges, that I'm
afraid that there might be synthdrivers which have coded around some of
its bugs.... and that "fixing" MidiUtil might break something else.

But I gotta try....

- Joe

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

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

One of the reasons I was thinking about filters is so that drivers
could accept messages that aren't part of a patch. For example, when
sending a patch to the synth a driver could register that it's
expecting a patch dump succeeded or patch dump failed message. In this
case it might also be useful to specify how long a filter would last -
ie "I'm only expecting one message like this, and I want to give up
after 30 seconds"

On 5/14/05, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
>=20
> >On 5/14/05, Joe Emenaker <jo...@em...> wrote:
> >
> >
> >>Also, what does everyone else think about JSL being able to receive a
> >>patch even when the SysexGetDialog isn't open? For example, if JSL is
> >>just sitting there, and you dump a patch from a synth, it could pop up =
a
> >>message saying "JSL just received a patch dump which looks like a Alesi=
s
> >>DM5 Bank. Would you like to save it in your current library or discard
> >>it?". Then, all the SysexGetDialog class would need to do is arrange to
> >>send out dump requests (and notify the receiving mechanism that a
> >>certain type of patch is expected).
> >>
> >>
> >
> >Would it even need to do the notification? We'd just need to make sure
> >the incoming messages were routed correctly, wouldn't we.

> Well, I think that, from a user-experience point of view, you wouldn't
> want various sysex dumps just accumulating in your libraries. If the
> SysexGetDialog were open, then it could automatically insert them... but
> I think that, if you didn't have the dialog open, then you're not really
> "expecting" anything coming in, so it's probably nice to have JSL ask
> the user.

Good point. I didn't think about that


> I've thought about it some more... and here's another idea of how the
> sysex input queues could work:
> 1 - A message comes into a given MIDI interface.
> 2 - The queue manager would get a list of all of the synthdrivers using
> that interface as the input (unless the user has selected to not use
> mutliple MIDI interfaces, in which case it gets a list of all of the
> synthdrivers).
> 3 - It checks to see if any of those synthdrivers recognize the patch
> *taking into account* the input interface and channel/deviceID of the
> patch versus that of the synthdriver.
> 4 - If it finds a perfect match, then it adds it to the current library.
> If it doesn't then it checks all of the synthdrivers to see if they
> recognize the patch *without* taking into account the input interface
> and channel/deviceID. If it *does* find a match this time, then there
> are a few possible reasons, which the user might want to choose between:
>   A - This is a one-time patch dump from some device. Accept it and do
> nothing else.
>   B - This is a dump from one of the hardware devices in the synthdriver
> list, but it has changed interfaces and/or channel/deviceID without that
> data being updated in JSL. Accept the patch *and* change the
> interface/channel/deviceID of the matching synthdriver to match that of
> the incoming patch.
>   C - This is a dump from a new device. Accept the patch, and add a new
> device to the list of synthdrivers.
>   D - Discard the patch entirely.
>=20
> The nice thing is that "B" would be handy for handling problems where a
> misconfiguration is preventing any communication between JSL and the
> hardware device.
>=20
> "C" would make it *super* easy to add new instruments to the list of
> synthdrivers *provided* that JSL could somehow go through all of the
> available drivers... not just the ones in the users list of configured
> ones. If it did this, imagine how easy this would be for new users.
> Basically, they could run JSL, plug their MIDI interface into something,
> do a patch dump from it, and JSL would magically configure the driver
> for it. It would make it pretty difficult to *not* have success with JSL.