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

Re: [Jsynthlib-devel] Compiling for linux

[groumpf <dqu...@fr...>]

> 
> While we're on the topic, is the Mac stuff in midiprovider used?

I think so, the CAProvider is the javax.midi implemention for OSX. The jar has to be installed in a special directory to be recognized by java.

A long time ago I made the first OSX classes for JSynthLib but they have been replaced by the CAProvider to have a common MIDI interface.

--
Denis

> 
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop 
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops?   How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

Re: [Jsynthlib-devel] Compiling for linux

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

On 9/12/2011 12:06 PM, Frankie Fisher wrote:
> On 12/09/2011 19:49, Joe Emenaker wrote:
>> Does anybody build JSL for Linux?
>>
>> I'm getting some build errors when I try to build the stuff in
>> midiprovider.LinuxCharDev.
> i've not been building linuxchardev. I don't think you need it anyway on
> JDK>= 1.5

Looks like you're right. Since we're requiring Java 1.5 or higher now, 
is there any objection to getting rid of the LinuxCharDev stuff, then?

While we're on the topic, is the Mac stuff in midiprovider used?

Re: [Jsynthlib-devel] Compiling for linux

[Frankie F. <jsy...@te...>]

On 12/09/2011 19:49, Joe Emenaker wrote:
> Does anybody build JSL for Linux?
>
> I'm getting some build errors when I try to build the stuff in 
> midiprovider.LinuxCharDev.
i've not been building linuxchardev. I don't think you need it anyway on
JDK >= 1.5

frankie

[Jsynthlib-devel] Compiling for linux

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

Does anybody build JSL for Linux?

I'm getting some build errors when I try to build the stuff in 
midiprovider.LinuxCharDev.

For starters, the source code is listing its package as just being 
"LinuxCharDevMidiProvider", instead of 
"midiprovider.LinuxCharDev.LinuxCharDevMidiProvider". This seems to be 
handled by the build.sh script which is in that same folder; it compiles 
it from that folder and then rolls the classes into a jar file that you 
then add as a library.

However, even when I run the build.sh script, I'm getting an error 
(which I also get in IDEA), that LinuxCharDevMidiProvider is not 
abstract and doesn't override getTransmitters() from 
javax.sound.midi.MidiDevice.

Is anybody here successfully using JSL on Linux, or has it been broken 
and nobody has noticed?

- Joe

Re: [Jsynthlib-devel] Two refactoring questions

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

On 9/12/2011 6:01 AM, Roger Westerlund wrote:
> My suggestion is to use a Maven style directory structure.
> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html)
>
> src/main/java
> src/main/recources
> src/test/java (we do test, do we?)
> src/test/recources

Well, that's a little bit of a project-management directory structure. 
I'm not opposed to adding this, but I was mostly asking about the 
*package* structure of the java code (ie, how we're going to distribute 
files under the src/main/java folder)

- Joe

Re: [Jsynthlib-devel] Two refactoring questions

[Roger W. <ro...@us...>]

2011/9/12 Frankie Fisher <jsy...@te...>:
> On 12/09/2011 14:01, Roger Westerlund wrote:
>>
>> I am not sure that Maven is the way to go for JSynthLib. I have been
>> using Maven in my work for the last couple of years and I have seen
>> Maven being bent over backwards to build a system. It is not a pretty
>> sight. I think nothing beats Maven when it comes to dependency
>> management and modularization but it is too easy to misuse Maven. I
>> would rather look for something like Gradle (http://www.gradle.org/)
>> when it comes to replacing Ant. I have not used it myself but I have
>> hear people saying good things about it (people smarter than me so I
>> trust them).
>
> Interesting, I'm only familiar with ant - what are the problems with ant?

For starters, it uses XML as it's "language" and XML was made for
machines to read so it is not the most human readable format available
(imho). Have a look at Gant (http://gant.codehaus.org/) which is based
on Ant to see the difference.

Ant scripts tends to grow wildly and if you don't fully understand Ant
then it is easy to start mixing target dependencies with antcalls and
then you have a problem.

You also have to do some backwards thinking to use conditional
triggering of targets. Something that is so easy to do in a
programming language with an if statement becomes really awkward in
Ant.

Also if you have a modularized application, which I would say that
JSynthLib should be, then the Ant build scripts you would need to
maintain would be quite some work.

I still think that Ant is a good tool if used properly but the XML
drags it down.

Regards,

Roger

Re: [Jsynthlib-devel] TC Electronic M350

[Frankie F. <jsy...@te...>]

On 11/09/2011 01:42, Frankie Fisher wrote:
> So we've now got a working single patch librarian and editor for the
> M350. There isn't any proper documentation in the manual, so I had to
> work the SysEx out myself. (For future reference I've documented the
> format at
> http://francisfisher.me.uk/problem/2011/deciphering-tc-electronic-m350-sysex-format/
> ).
>
> There's one thing still missing - I need to make a bank librarian. I am
> not aware of any specific SysEx messages that would download the entire
> bank so I need to request a single patch 99 times. Is there a better way
> of doing it than something like this:
>
> for (i=1; i<99;++i)
> {
>   singleDriver.reqestPatchDump(0,i);
>   sleep(100);
> }
>
> I am guess this would block the UI thread until it's requested which I
> don't really want to do!
>
> cheers,
> frankie
>
>

I tried this method and it did freeze the application until it finished
as expected. I think in the long run I will have to make some progress
dialogue that can get displayed while fetching banks - unless anyone
knows a driver that does this already tbat I can steal the code from?
But I don't want to do this yet while Joe is still working on his UI
refactoring. So I think for now I will leave the bank driver alone and
come back to it in the future.

frankie

Re: [Jsynthlib-devel] Two refactoring questions

[Frankie F. <jsy...@te...>]

On 12/09/2011 14:01, Roger Westerlund wrote:
>
> I am not sure that Maven is the way to go for JSynthLib. I have been
> using Maven in my work for the last couple of years and I have seen
> Maven being bent over backwards to build a system. It is not a pretty
> sight. I think nothing beats Maven when it comes to dependency
> management and modularization but it is too easy to misuse Maven. I
> would rather look for something like Gradle (http://www.gradle.org/)
> when it comes to replacing Ant. I have not used it myself but I have
> hear people saying good things about it (people smarter than me so I
> trust them).

Interesting, I'm only familiar with ant - what are the problems with ant?

>
> And then we have Subversion... :-) Having used it in a setting where
> branching and merging is a daily activity, I know how Subversion
> performs. You don't really want to merge with Subversion. You do not
> really want to move files when you use branching and merging. And
> definitely not move files and edit in branches. I would rather try
> something like Git which was built for merging.
>

I would be very happy to use git or mercurial instead of svn.

frankie

Re: [Jsynthlib-devel] Two refactoring questions

[Roger W. <ro...@us...>]

My suggestion is to use a Maven style directory structure.
(http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html)

src/main/java
src/main/recources
src/test/java (we do test, do we?)
src/test/recources

and so on. That will also separate production code from tests and such.

I am not sure that Maven is the way to go for JSynthLib. I have been
using Maven in my work for the last couple of years and I have seen
Maven being bent over backwards to build a system. It is not a pretty
sight. I think nothing beats Maven when it comes to dependency
management and modularization but it is too easy to misuse Maven. I
would rather look for something like Gradle (http://www.gradle.org/)
when it comes to replacing Ant. I have not used it myself but I have
hear people saying good things about it (people smarter than me so I
trust them).

And then we have Subversion... :-) Having used it in a setting where
branching and merging is a daily activity, I know how Subversion
performs. You don't really want to merge with Subversion. You do not
really want to move files when you use branching and merging. And
definitely not move files and edit in branches. I would rather try
something like Git which was built for merging.

I am so happy to see that this project has woken up again and I too
started refactoring the application many years ago but the work was
too overwhelming. I don't know how much time I can spend on this
project but I will try to follow the development and inject my
development experience whenever I can.

Regards,

Roger

2011/9/9 William Zwicky <wrz...@po...>:
> My first suggestion is to move all source code into /src.  Optionally,
> synthdrivers can be move to /src-synthdrivers or just /synthdrivers in
> preparation for the plugin framework.  Synths should be repackaged as well,
> so the final directory will actually be
> /synthdrivers/org/jsynthlib/synthdrivers/*.
>
> On Thu, Sep 8, 2011 at 9:30 AM, Joe Emenaker <jo...@em...> wrote:
>
>>
>> 1 - When I move all of the stuff from "core" into "org.jsynthlib", how
>> should it be organized? I'm planning all of the "*ConfigPanel" stuff
>> moving into org.jsynthlib.config, and probably all of "*Widget" going
>> into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably
>> going into org.jsynthlib.utils. There's a lot more stuff, however, that
>> needs a home. Any suggestions for further categorization are welcome.
>> I'm thinking that we might also want a dedicated package for the classes
>> which the synthdrivers use for superclasses (ie, PatchEditorFrame,
>> LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers
>> which were subclassing some fairly strange frames... possibly because
>> they were the first ones that they came across which seemed like they'd
>> work or something.
>>
>
> These are all excellent ideas.  I might suggest an 'app' package for the
> main JSynthLib app, windows, menus, etc.
>
> 2 - Some of the classes have their *type* implied in the name. For
>> example, there's an abstract class called "AbstractLibraryFrame" and
>> there are some interfaces called "IDriver" and "IBankPatch". These
>> aren't really the way the base Java libraries do it and, personally, I
>> find it confusing (I keep asking myself "What the heck is an 'abstract
>> library'?"). My preference would be to rename AbstractLibraryFrame to
>> just LibraryFrame, and IDriver to just Driver, etc. Any objections?
>>
>
> I agree.  I myself favor systems like "interface Driver" and "abstract class
> DriverBase".  The system is then carefully coded to only require Driver so
> people can write fully custom implementations, but DriverBase is available
> as a starting point.
>
> I understand the reasoning behind names like IDriver and CDriver, but I
> always need the docs around when I code, so I've never found that trick
> useful.
>
> -Bill Zwicky
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

Re: [Jsynthlib-devel] SysEx header offset

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

On 09/12/2011 04:27 AM, Martin Tarenskeen wrote:
>
> I don't know much about the internals of JSynthLib. But I have a feeling
> SysEx bank/patch recognition can be improved.
[...]
> If I would be a Java programmer I would take a look at it myself.
> But I have succesfully used tricks like these in my own projects like
> YSEDITOR (Atari) and DXconvert (Python script).
>

I could take a look at the code if you could provide example files with 
description of expected results upon import.

Also if the source code of the programs you refer is available, it would 
help if I could take a look at that and run the test data through those. 
(I mean python, for me would be too much of a trouble to learn about 
atari just for this task)

Regards
-- 
Vladimir

[Jsynthlib-devel] SysEx header offset

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

I don't know much about the internals of JSynthLib. But I have a feeling 
SysEx bank/patch recognition can be improved.

Am I right if I think this happens? : When importing a SysEx bank file 
JSynthLib reads the first bytes to identify the Manufacturer and Device, 
and then automatically selects the appropriate synth driver for this file.

I have noticed this procedure fails in many cases.
I have tried some files with the Yamaha DX100 (a synth that I own).

There are some things JSynthLib does not seem to consider:

- SysEx files do not always start with F0. Yes, they should, but several 
programs exist(ed) that produce files with an extra header before the real 
SysEx data start.

- Files that can contain DX100 SysEx data do not always start with DX100 
SysEx data. It is possible to concatenate several different SysEx dumps 
and save them in one file. This is also true for SysEx in MIDI files.

- Files can contain more than one block of DX100 banks. For example a 
Yamaha YS200 or V50 file contains 4 banks of DX100 (more or less) 
compatible SysEx bank dumps, and the first usable sysex block does NOT 
start at the first byte. (There is a block identification sysex block 
first)


What could be improved:

JsynthLib should scan a file it wants to import to find the SysEx 
header(s) it is looking for, read the sysex data from there (Offset for FO 
can be byte nr 0, but can also be elsewhere in the file), and continue to 
find more data, if any, until the complete file has been scanned.

This way more files with great sounds that can be found on the internet 
can be imported directly in JSynthLib without extra conversions.

Maybe someone is interested to look into the JSynthjLib code to see waht 
can be done about this.

If I would be a Java programmer I would take a look at it myself.
But I have succesfully used tricks like these in my own projects like 
YSEDITOR (Atari) and DXconvert (Python script).

-- 

MT

[Jsynthlib-devel] TC Electronic M350

[Frankie F. <jsy...@te...>]

So we've now got a working single patch librarian and editor for the
M350. There isn't any proper documentation in the manual, so I had to
work the SysEx out myself. (For future reference I've documented the
format at
http://francisfisher.me.uk/problem/2011/deciphering-tc-electronic-m350-sysex-format/
).

There's one thing still missing - I need to make a bank librarian. I am
not aware of any specific SysEx messages that would download the entire
bank so I need to request a single patch 99 times. Is there a better way
of doing it than something like this:

for (i=1; i<99;++i)
{
  singleDriver.reqestPatchDump(0,i);
  sleep(100);
}

I am guess this would block the UI thread until it's requested which I
don't really want to do!

cheers,
frankie

Re: [Jsynthlib-devel] Groovy causing exception at compile time...

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

On 9/10/2011 3:49 PM, frankster wrote:
> I get a different set of errors if I try and compile the uirefactor
> branch! I assume that you have already fixed these in your copy but not
> submitted them to SVN, so I won't bother trying to fix them myself ;)

Yeah. I've got those fixed. And the compile-time error I was getting was 
because IDEA was trying to use its built-in Groovy compiler, which I was 
able to turn off.

So, I've got it compiling now... and now I've progressed to 
NullPointerExceptions before the GUI even opens. Progress!

- Joe

Re: [Jsynthlib-devel] Groovy causing exception at compile time...

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

On 10/09/2011 14:25, Joe Emenaker wrote:
> So, I finally got rid of all of the compile-time errors from my 
> refactored code... and now I'm getting this error at the end of the compile:
>
>> java.lang.NoSuchMethodError: 
>> org.codehaus.groovy.control.CompilationUnit.<init>(Lorg/codehaus/groovy/control/CompilerConfiguration;Ljava/security/CodeSource;Lgroovy/lang/GroovyClassLoader;)V
>>     at 
>> org.jetbrains.groovy.compiler.rt.GroovycRunner$4.<init>(GroovycRunner.java:375)
>>     at 
>> org.jetbrains.groovy.compiler.rt.GroovycRunner.createCompilationUnit(GroovycRunner.java:375)
>>     at 
>> org.jetbrains.groovy.compiler.rt.GroovycRunner.main(GroovycRunner.java:123)
>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>     at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>     at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>     at java.lang.reflect.Method.invoke(Method.java:597)
>>     at 
>> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:75)
> I tried compiling trunk and I also get this error. I even tried the 
> latest copy of the groovy JAR and I get this.
>
> I'm using Jetbrains IDEA as my IDE.
>
> Any thoughts?
>
> - Joe
>
>


I get a different set of errors if I try and compile the uirefactor
branch! I assume that you have already fixed these in your copy but not
submitted them to SVN, so I won't bother trying to fix them myself ;)

javac -g -classpath .:asm.jar:groovy.jar core/AbstractLibraryFrame.java
core/AbstractLibraryFrame.java:60: cannot find symbol
symbol  : method getNewJSLFrame(java.lang.String,boolean)
location: class org.jsynthlib.desktop.JSLDesktop
        menuFrame = PatchEdit.getDesktop().getNewJSLFrame(title, true);
                                          ^
./org/jsynthlib/desktop/sdi/SDIJFrame.java:145: incomparable types:
org.jsynthlib.desktop.JSLFrame and org.jsynthlib.desktop.sdi.SDIJFrame
        return (desktop.getSelectedJSLFrame() == this);
                                              ^
./core/PatchEdit.java:115: inconvertible types
found   : org.jsynthlib.desktop.JSLFrame
required: javax.swing.JFrame
        if(frame instanceof JFrame) {
           ^
./core/PatchEdit.java:116: inconvertible types
found   : org.jsynthlib.desktop.JSLFrame
required: javax.swing.JFrame
            return (JFrame) frame;
                            ^
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
4 errors
make: *** [core/AbstractLibraryFrame.class] Error 1


frankie

Re: [Jsynthlib-devel] Groovy causing exception at compile time...

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

He used the refactor branch not trunk.

Am 10.09.2011 15:53, schrieb Vladimir Avdonin:
>
>
> On 09/10/2011 08:25 AM, Joe Emenaker wrote:
>>
>> So, I finally got rid of all of the compile-time errors from my
>> refactored code... and now I'm getting this error at the end of the compile:
>>
>
>>
>> I tried compiling trunk and I also get this error. I even tried the
>> latest copy of the groovy JAR and I get this.
>>
>> I'm using Jetbrains IDEA as my IDE.
>>
>> Any thoughts?
>>
>
> Just updated trunk, run ant clean, then ant dist, no errors just few
> warnings in from javadoc.
>
> I have sun jdk 6.26 and ant 1.8.1 installed from standard packages on
> ubuntu 11.4
>

Re: [Jsynthlib-devel] synth support that's not made it into SVN!!

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

Hi Fred Jan,

I have had a look at version 0.10 on your website and it seems to be the 
same as the one in JSynthLib, apart from some minor changes.

cheers,
Frankie

On 09/01/11 18:26, F.J. Kraan wrote:
> Hi,
>
> At http://electrickery.xs4all.nl/digaud/mt32/ is a more recent version
> of the Roland MT-32 driver. Still incomplete. There is also a
> rudimentary driver for the Lexicon LXP5. It shows the settings of a
> patch, which is not possible on the LXP5 itself.
>
> I didn't touch the code or tested it with the devices in quite some
> time, so add an warning ;-).
>
> Greetings,
>
> Fred Jan
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

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

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

On 09/09/11 15:40, Joe Emenaker wrote:
> On 9/9/2011 7:17 AM, frankster wrote:
>> On 09/09/11 15:03, Joe Emenaker wrote:
>>> On 9/9/2011 1:56 AM, William Zwicky wrote:
>>>> I think my example above matches that last case. Once the message
>>>> for widget A has started sending, other messages can be queued, but
>>>> they can't be sent until widget A says 'handshake complete'!
>>> My initial reaction to this is that this isn't an issue with the rate of
>>> data sent by the MIDI layer, so the MIDI layer shouldn't be involved.
>>> I'm thinking that the synthdriver should be able to manage all of this
>>> itself. The only reason we'd need to trouble the MIDI layer with this is
>>> if your synthdriver either needed special transfer-rate limits *or* if
>>> your synthdriver needed to block all traffic for *other* synths on that
>>> interface while the communication were happening. Otherwise, this should
>>> be able to be managed by the synthdriver.
>> I think it does concern the midi layer because transmitting data to one
>> synth could overload a different synth on the same port. Although we can
>> expect a synth driver to know how much traffic its device can handle, we
>> can't expect a synth driver to care or know about other synths.
> Well, that's a different case (but it's one that we've still discussed,
> and I think there does need to be a way for a synthdriver to tell the
> MIDI layer "I can't handle more than X bytes per second... no matter
> *what* synth it's for, so don't let any data onto the wires faster than
> that"). What *Bill* seems to be referring to is that there seems to be a
> synth which requires an orchestrated series of messages for updating
> synth settings. For example:
>
> Where I imagine most synths use self-contained messages, like:
> Msg: Update parameter 27 to value 10
> Msg: Update parameter 27 to value 12
> Msg: Update parameter 27 to value 14
>
> Bill seems to have a synth which requires something like:
>
> Msg: Begin messing with parameter 27
> Msg: Set parameter to value 10
> Msg: Set parameter to value 12
> Msg: Set parameter to value 14
> Msg: Done messing with parameter 27
>
> You can see how things would get messed up if there was a second "begin"
> message before the "end" message for the first.
>
> So, my point was that this kind of awareness of the *context* (not the
> data-rate) of the messages is probably best kept in the synthdrivers.
>
ah ok i was getting confused with the other situation

frankie

Re: [Jsynthlib-devel] Groovy causing exception at compile time...

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

On 09/10/2011 08:25 AM, Joe Emenaker wrote:
>
> So, I finally got rid of all of the compile-time errors from my
> refactored code... and now I'm getting this error at the end of the compile:
>

>
> I tried compiling trunk and I also get this error. I even tried the
> latest copy of the groovy JAR and I get this.
>
> I'm using Jetbrains IDEA as my IDE.
>
> Any thoughts?
>

Just updated trunk, run ant clean, then ant dist, no errors just few 
warnings in from javadoc.

I have sun jdk 6.26 and ant 1.8.1 installed from standard packages on 
ubuntu 11.4

-- 
Vladimir

[Jsynthlib-devel] Groovy causing exception at compile time...

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

So, I finally got rid of all of the compile-time errors from my 
refactored code... and now I'm getting this error at the end of the compile:

> java.lang.NoSuchMethodError: 
> org.codehaus.groovy.control.CompilationUnit.<init>(Lorg/codehaus/groovy/control/CompilerConfiguration;Ljava/security/CodeSource;Lgroovy/lang/GroovyClassLoader;)V
>     at 
> org.jetbrains.groovy.compiler.rt.GroovycRunner$4.<init>(GroovycRunner.java:375)
>     at 
> org.jetbrains.groovy.compiler.rt.GroovycRunner.createCompilationUnit(GroovycRunner.java:375)
>     at 
> org.jetbrains.groovy.compiler.rt.GroovycRunner.main(GroovycRunner.java:123)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
>     at 
> com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:75)

I tried compiling trunk and I also get this error. I even tried the 
latest copy of the groovy JAR and I get this.

I'm using Jetbrains IDEA as my IDE.

Any thoughts?

- Joe

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

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

On 9/9/2011 7:17 AM, frankster wrote:
> On 09/09/11 15:03, Joe Emenaker wrote:
>> On 9/9/2011 1:56 AM, William Zwicky wrote:
>>> I think my example above matches that last case. Once the message 
>>> for widget A has started sending, other messages can be queued, but 
>>> they can't be sent until widget A says 'handshake complete'! 
>> My initial reaction to this is that this isn't an issue with the rate of
>> data sent by the MIDI layer, so the MIDI layer shouldn't be involved.
>> I'm thinking that the synthdriver should be able to manage all of this
>> itself. The only reason we'd need to trouble the MIDI layer with this is
>> if your synthdriver either needed special transfer-rate limits *or* if
>> your synthdriver needed to block all traffic for *other* synths on that
>> interface while the communication were happening. Otherwise, this should
>> be able to be managed by the synthdriver.
> I think it does concern the midi layer because transmitting data to one
> synth could overload a different synth on the same port. Although we can
> expect a synth driver to know how much traffic its device can handle, we
> can't expect a synth driver to care or know about other synths.
Well, that's a different case (but it's one that we've still discussed, 
and I think there does need to be a way for a synthdriver to tell the 
MIDI layer "I can't handle more than X bytes per second... no matter 
*what* synth it's for, so don't let any data onto the wires faster than 
that"). What *Bill* seems to be referring to is that there seems to be a 
synth which requires an orchestrated series of messages for updating 
synth settings. For example:

Where I imagine most synths use self-contained messages, like:
Msg: Update parameter 27 to value 10
Msg: Update parameter 27 to value 12
Msg: Update parameter 27 to value 14

Bill seems to have a synth which requires something like:

Msg: Begin messing with parameter 27
Msg: Set parameter to value 10
Msg: Set parameter to value 12
Msg: Set parameter to value 14
Msg: Done messing with parameter 27

You can see how things would get messed up if there was a second "begin" 
message before the "end" message for the first.

So, my point was that this kind of awareness of the *context* (not the 
data-rate) of the messages is probably best kept in the synthdrivers.

- Joe

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

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

On 09/09/11 15:03, Joe Emenaker wrote:
> On 9/9/2011 1:56 AM, William Zwicky wrote:
>> We could let each synthdriver decide their own queue policy (ie, only
>>> hold one message per widget, or hold all of them). A more-complicated
>>> solution would be for widgets to indicate which messages belong as a
>>> set... but I don't see a need for that.
>>>
>> I think my example above matches that last case.  Once the message for
>> widget A has started sending, other messages can be queued, but they can't
>> be sent until widget A says 'handshake complete'!
> My initial reaction to this is that this isn't an issue with the rate of
> data sent by the MIDI layer, so the MIDI layer shouldn't be involved.
> I'm thinking that the synthdriver should be able to manage all of this
> itself. The only reason we'd need to trouble the MIDI layer with this is
> if your synthdriver either needed special transfer-rate limits *or* if
> your synthdriver needed to block all traffic for *other* synths on that
> interface while the communication were happening. Otherwise, this should
> be able to be managed by the synthdriver.

I think it does concern the midi layer because transmitting data to one 
synth could overload a different synth on the same port. Although we can 
expect a synth driver to know how much traffic its device can handle, we 
can't expect a synth driver to care or know about other synths. So it 
could make sense for the midi layer to have the ability to enforce the 
lowest common denominator throughput if required.

I would think drivers would need to be able to specify a maximum number 
of bytes to occur in a specified timeframe. But maybe for a driver the 
problems occur only while processing large sysex messages, in which case 
maybe it would need to lock its port for e.g. 30ms after sending a message.

frankie

Re: [Jsynthlib-devel] Two refactoring questions

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

Its funny you should say this because I was talking to my friend last 
week, and he was saying that maven now is what ant was 10 years ago. 
i.e. 10 years ago ant was the standard build system, but these days 
maven is.

In the longer run it could be interesting to look into the benefits that 
maven would provide over ant (or even make).

cheers,
Frankie
On 09/09/11 10:14, denis queffeulou wrote:
> I don't read all the mails, but have you think of using Maven to build
> modules (libraries) instead of having one big build project ?
> Maybe you could have one project for the core, one for the synthdrivers etc.
>
> Just a suggestion as maven is used all the time in java projects. It
> helps to separate code entities and reuse them with the dependancies system.
>
> --
> Denis
>
>> My first suggestion is to move all source code into /src.  Optionally,
>> synthdrivers can be move to /src-synthdrivers or just /synthdrivers in
>> preparation for the plugin framework.  Synths should be repackaged as well,
>> so the final directory will actually be
>> /synthdrivers/org/jsynthlib/synthdrivers/*.
>>
>> On Thu, Sep 8, 2011 at 9:30 AM, Joe Emenaker<jo...@em...>   wrote:
>>
>>> 1 - When I move all of the stuff from "core" into "org.jsynthlib", how
>>> should it be organized? I'm planning all of the "*ConfigPanel" stuff
>>> moving into org.jsynthlib.config, and probably all of "*Widget" going
>>> into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably
>>> going into org.jsynthlib.utils. There's a lot more stuff, however, that
>>> needs a home. Any suggestions for further categorization are welcome.
>>> I'm thinking that we might also want a dedicated package for the classes
>>> which the synthdrivers use for superclasses (ie, PatchEditorFrame,
>>> LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers
>>> which were subclassing some fairly strange frames... possibly because
>>> they were the first ones that they came across which seemed like they'd
>>> work or something.
>>>
>> These are all excellent ideas.  I might suggest an 'app' package for the
>> main JSynthLib app, windows, menus, etc.
>>
>> 2 - Some of the classes have their *type* implied in the name. For
>>> example, there's an abstract class called "AbstractLibraryFrame" and
>>> there are some interfaces called "IDriver" and "IBankPatch". These
>>> aren't really the way the base Java libraries do it and, personally, I
>>> find it confusing (I keep asking myself "What the heck is an 'abstract
>>> library'?"). My preference would be to rename AbstractLibraryFrame to
>>> just LibraryFrame, and IDriver to just Driver, etc. Any objections?
>>>
>> I agree.  I myself favor systems like "interface Driver" and "abstract class
>> DriverBase".  The system is then carefully coded to only require Driver so
>> people can write fully custom implementations, but DriverBase is available
>> as a starting point.
>>
>> I understand the reasoning behind names like IDriver and CDriver, but I
>> always need the docs around when I code, so I've never found that trick
>> useful.
>>
>> -Bill Zwicky
>> ------------------------------------------------------------------------------
>> Why Cloud-Based Security and Archiving Make Sense
>> Osterman Research conducted this study that outlines how and why cloud
>> computing security and archiving is rapidly being adopted across the IT
>> space for its ease of implementation, lower cost, and increased
>> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
>> _______________________________________________
>> Jsynthlib-devel mailing list
>> Jsy...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

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

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

On 9/9/2011 1:56 AM, William Zwicky wrote:
> We could let each synthdriver decide their own queue policy (ie, only
>> hold one message per widget, or hold all of them). A more-complicated
>> solution would be for widgets to indicate which messages belong as a
>> set... but I don't see a need for that.
>>
> I think my example above matches that last case.  Once the message for
> widget A has started sending, other messages can be queued, but they can't
> be sent until widget A says 'handshake complete'!

My initial reaction to this is that this isn't an issue with the rate of 
data sent by the MIDI layer, so the MIDI layer shouldn't be involved. 
I'm thinking that the synthdriver should be able to manage all of this 
itself. The only reason we'd need to trouble the MIDI layer with this is 
if your synthdriver either needed special transfer-rate limits *or* if 
your synthdriver needed to block all traffic for *other* synths on that 
interface while the communication were happening. Otherwise, this should 
be able to be managed by the synthdriver.

> Finally, I'd like to vote against the user rate-limit option that was
> proposed earlier.  Rate limiting is not a real feature, it's a workaround to
> cope with flaky synths.  And these workarounds should be properly researched
> and coded in the driver so that the user doesn't need to worry about it at
> all.  It *might* be useful as an emergency feature to cope with situations
> the developer didn't discover, but it should *not* be part of the normal
> operation of JSynthLib.

Okay... just so we're clear, you're referring to *user* rate-limit. The 
idea of the end user being able to determine how often widgets send 
updates to the synth, right? But raw data throughput limiting in the 
MIDI layer is still a useful feature?

- Joe

Re: [Jsynthlib-devel] Two refactoring questions

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

I don't read all the mails, but have you think of using Maven to build 
modules (libraries) instead of having one big build project ?
Maybe you could have one project for the core, one for the synthdrivers etc.

Just a suggestion as maven is used all the time in java projects. It 
helps to separate code entities and reuse them with the dependancies system.

--
Denis

> My first suggestion is to move all source code into /src.  Optionally,
> synthdrivers can be move to /src-synthdrivers or just /synthdrivers in
> preparation for the plugin framework.  Synths should be repackaged as well,
> so the final directory will actually be
> /synthdrivers/org/jsynthlib/synthdrivers/*.
>
> On Thu, Sep 8, 2011 at 9:30 AM, Joe Emenaker<jo...@em...>  wrote:
>
>> 1 - When I move all of the stuff from "core" into "org.jsynthlib", how
>> should it be organized? I'm planning all of the "*ConfigPanel" stuff
>> moving into org.jsynthlib.config, and probably all of "*Widget" going
>> into org.jsynthlib.widget. Things like Base64 and XMLFileUtils probably
>> going into org.jsynthlib.utils. There's a lot more stuff, however, that
>> needs a home. Any suggestions for further categorization are welcome.
>> I'm thinking that we might also want a dedicated package for the classes
>> which the synthdrivers use for superclasses (ie, PatchEditorFrame,
>> LibraryFrame, BankEditorFrame, etc.). I've come across some synthdrivers
>> which were subclassing some fairly strange frames... possibly because
>> they were the first ones that they came across which seemed like they'd
>> work or something.
>>
> These are all excellent ideas.  I might suggest an 'app' package for the
> main JSynthLib app, windows, menus, etc.
>
> 2 - Some of the classes have their *type* implied in the name. For
>> example, there's an abstract class called "AbstractLibraryFrame" and
>> there are some interfaces called "IDriver" and "IBankPatch". These
>> aren't really the way the base Java libraries do it and, personally, I
>> find it confusing (I keep asking myself "What the heck is an 'abstract
>> library'?"). My preference would be to rename AbstractLibraryFrame to
>> just LibraryFrame, and IDriver to just Driver, etc. Any objections?
>>
> I agree.  I myself favor systems like "interface Driver" and "abstract class
> DriverBase".  The system is then carefully coded to only require Driver so
> people can write fully custom implementations, but DriverBase is available
> as a starting point.
>
> I understand the reasoning behind names like IDriver and CDriver, but I
> always need the docs around when I code, so I've never found that trick
> useful.
>
> -Bill Zwicky
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

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

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

On Thu, Sep 8, 2011 at 8:54 AM, Joe Emenaker <jo...@em...> wrote:

> On 9/8/2011 8:13 AM, frankster wrote:
> > What about if the midi layer will never queue more than 1 message from
> > a particular widget (so the midi layer would have to track the source
> > of each message) and if multiple messages appeared from the same
> > widget's Sender class, it would discard all but the most recent.
>
> This strikes me as a great way to do it. We could even do it without the
> widget losing its place in the queue. We could just replace the old
> message with the new one.
>

That actually sounds pretty decent.  But what if my synth won't tolerate a
queue? i.e. Maybe I need to strictly control the ordering of messages, or
maybe the synth won't accept the second message until the first message has
properly completed all handshaking.

We could let each synthdriver decide their own queue policy (ie, only
> hold one message per widget, or hold all of them). A more-complicated
> solution would be for widgets to indicate which messages belong as a
> set... but I don't see a need for that.
>

I think my example above matches that last case.  Once the message for
widget A has started sending, other messages can be queued, but they can't
be sent until widget A says 'handshake complete'!

Maybe we need lockSynth() and unlockSynth() to block the queue until some
code is complete.  And if the synth is really flaky, lockBus() and
unlockBus() to prevent other messages from confusing the synth.

Speaking of lockBus(), I believe this only needs to block transmission to
synths downstream (i.e. farther from the computer) from the flaky synth, as
upstream synths will not pass thru messages targeted at themselves.  Are
there any synths that pass thru all their own messages?  Do we need an API
to flag synths that behave in non-standard ways?

Finally, I'd like to vote against the user rate-limit option that was
proposed earlier.  Rate limiting is not a real feature, it's a workaround to
cope with flaky synths.  And these workarounds should be properly researched
and coded in the driver so that the user doesn't need to worry about it at
all.  It *might* be useful as an emergency feature to cope with situations
the developer didn't discover, but it should *not* be part of the normal
operation of JSynthLib.

-Bill Zwicky