Re: [Jsynthlib-devel] Modifications to the AppConfig class and preferences GUI

On 12/5/2011 12:36 PM, Chris Wareham wrote: > It looks like there was an intention at some > point to make the preferences panels embeddable in other dialogs, but > this doesn't seem to have come to pass, and the result is a lot of dead > code paths. That was possibly my doing. I think the point w

Re: [Jsynthlib-devel] 10th anniversary

On 9/24/2011 3:50 PM, William Zwicky wrote: > In my mind, "studio" is just a collection of equipment, and "project" > is the equipment plus everything required for a song or set. So it > makes sense that a project would contain *a* studio plus some > libraries, rather than a studio containing a

Re: [Jsynthlib-devel] 10th anniversary

On 9/24/2011 2:25 PM, William Zwicky wrote: > I've enclosed a sketch of a new GUI, I haven't had time to look it over in detail, but I like the idea of a "Studio" window. In fact, my vision for the GUI is that the Studio window would actually be a pane/frame on the desktop which is always there.

Re: [Jsynthlib-devel] 10th anniversary

On 9/23/2011 4:58 PM, Frankie Fisher wrote: > On 23/09/2011 19:56, William Zwicky wrote: >> I'd also like to remove synths from the Preferences page. You should pick >> synth(s) when creating libraries and scenes. >> > how does this fit in with the auto-scan process - do you anticipate > doing an

Re: [Jsynthlib-devel] 10th anniversary

On 9/23/2011 11:50 AM, William Zwicky wrote: > On Fri, Sep 23, 2011 at 9:04 AM, Joe Emenaker wrote: > >> - Going further with the "sync" notion, we could have JSL deal, in a >> smart way, with changed patches it sees from the synth. For example, >> suppose I&#x

Re: [Jsynthlib-devel] jsynthlib.org expired in the last couple of days!

On 9/23/2011 11:19 AM, Joachim wrote: > Hi, > > > I'm thinking that we might want some combination of two words: what it > > does stuff *with*, and what it *does* with them. > > most applications have a name that doesn't imply it's use but are catchy, > right? > Gimp, Apache, Tomcat, JBoss,

Re: [Jsynthlib-devel] 10th anniversary

On 9/23/2011 6:21 AM, frankster wrote: > From the docs (which have fallen off the internet in the last couple > of days!): "The advantage of a scene is that it contains the locations > for the patches in the synth's memories in addition to the patches > themselves" So a scene has more to do with

Re: [Jsynthlib-devel] jsynthlib.org expired in the last couple of days!

On 9/23/2011 8:17 AM, Vladimir Avdonin wrote: > Hey, maybe this would be good moment to maybe contemplate on maybe > uhmm... name change? Actually, when we're on the verge of actually getting control of the domain... that would be the *last* time to contemplate it. :) The time to contemplate it

Re: [Jsynthlib-devel] jsynthlib.org expired in the last couple of days!

Whoops. Sorry. 40 days. Should we mark our calendar? Or maybe TUCOWS or some other registrar has a "grab this for me the moment it becomes available" option... - Joe -- All of the data generated in your IT infrastructur

Re: [Jsynthlib-devel] jsynthlib.org expired in the last couple of days!

On 9/23/2011 7:59 AM, frankster wrote: > I don't know how autorenew works, but judging by the whois, it looks > like tucows have got the domain for a bit. Looks like the grace period at TUCOWS for .org is 30 days... --- To renew or “redeem” a domain, please contactyour Domain Provider

Re: [Jsynthlib-devel] jsynthlib.org expired in the last couple of days!

On 9/23/2011 7:43 AM, frankster wrote: > I have managed to get copies of info.html, doc.html, project.html and > 3 zip files of packages - that's everything I could find apart from > synths.html which is in svn) via the wayback machine. Yeah... my vote would be for us to register jsynthlib.org (

Re: [Jsynthlib-devel] 10th anniversary

On 9/21/2011 11:19 PM, Roger Westerlund wrote: > 2011/9/20 William Zwicky: >> On Mon, Sep 19, 2011 at 11:28 PM, Roger Westerlund >> wrote: >>> Or why don't we release a 1.0. That would be a bold move. >> 3.11 Enterprise Edition. Comfortable now? Let's do it like Chrome, where we roll out a new

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1158] trunk/JSynthLib/core

On 9/20/2011 12:42 PM, William Zwicky wrote: > How about this: jsl only saves a list of which ports were DISabled, by > name. That's exactly what I was going to suggest. > I also believe that jsl should be port-agnostic -- if a synth moves to > another port, jsl should assume it's the same synt

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1158] trunk/JSynthLib/core

On 9/20/2011 12:40 AM, Frankie Fisher wrote: > off the top of my head, the only time i can think of where it would be > an advantage not to be using all ports is in the "autoscan" > functionality because it takes a while to scan each port. Keep in mind that I'm talking about the MIDI layer *list

Re: [Jsynthlib-devel] no details available

On 9/19/2011 6:11 PM, Frankie Fisher wrote: > Does anybody else see "no details available" in the input midi devices? Yes, and it bugs me. > Currently the device name that is displayed to the user is constructed > by concatenating DESCRIPTION and NAME, but I wonder if it should instead > be based

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1158] trunk/JSynthLib/core

On 9/19/2011 6:08 PM, franks...@users.sourceforge.net wrote: > fixed crash which can occur at startup when less midi devices are installed > than when prefs were saved. > > The problem was that the midi device is stored in the prefs as an integer. > When the prefs are loaded, the device number is

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

On 9/14/2011 2:19 PM, Frankie Fisher wrote: > I have been looking at doing a driver for the Roland U220 at the > moment and that uses the same memory-mapped bulk data transfer as the > MT32, I wonder if there is scope for commonality between some of the > Roland drivers. I think I put that idea

Re: [Jsynthlib-devel] 10th anniversary

On 9/16/2011 7:24 AM, frankster wrote: > Just noticed that the sf.net page was registered in december 2001, which > means that JSL is nearly 10 years old! Should we release a special "Collector's Edition"? It could come with a certificate of authenticity signed by all of us. :-) Or, maybe... we

Re: [Jsynthlib-devel] default look and feel

On 9/18/2011 8:32 AM, Joachim wrote: > Hi, > > would this mean that JSynthlib runs only with JRE 1.6? > > Anyway: Is anyone even using a version prior to JRE 1.6? > 1.6 has been out for a couple of years. I'm using 1.6 exclusively. Another benefit of 1.6 is that it supports splash-screens on appl

[Jsynthlib-devel] Tip-of-the-day system

I'm sure everybody here has seen those "Tip of the day" pop-ups that many apps have, where the user is shown some random bit of information about what they can do with the app. And then there are buttons for "See Next" and "Stop Showing These on Startup" actions. I think that JSL could benefit

Re: [Jsynthlib-devel] Compiling for linux

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 linuxchar

[Jsynthlib-devel] Compiling for linux

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 seem

Re: [Jsynthlib-devel] Two refactoring questions

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/recour

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

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

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

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.(Lorg/codehaus/groovy/control/CompilerConfiguration;Ljava/security/CodeSource

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

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 &

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

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 th

[Jsynthlib-devel] Two refactoring questions

Just wanted to get some opinions/preferences from the group: 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.widg

Re: [Jsynthlib-devel] Call for version 0.21

On 9/8/2011 8:59 AM, frankster wrote: > On 09/08/11 16:44, Joe Emenaker wrote: >>SVN, I'm told, *does* >> support moving, so it's my hope that this will preserve the revision >> history when the files get moved. > svn mv core/X org/jsynthlib/X Yup. It&

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

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

Re: [Jsynthlib-devel] Call for version 0.21

On 9/8/2011 3:10 AM, William Zwicky wrote: > Note that I don't have permissions to post a binary, so we'll need a > volunteer for that. And if you'd prefer to be the one to BUILD the binary, > let me know. I can probably post the binary, but I probably shouldn't build it. I don't use ant or make

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

On 9/8/2011 3:01 AM, William Zwicky wrote: > What if the delay depends on the nature of the change? Maybe parameter > changes are no problem, but those huge patch sets take a few seconds > to digest. It might be possible to send a request that is only > answered when the synth is done, or you mi

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

On 9/8/2011 2:31 AM, frankster wrote: > Can anyone think of anything simpler that would do the job? Although one > advantage of this is that it would > keep the driver simple, and all the complexity would be in core base > classes. I'm thinking this: - There should be a application-wide rate limit

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

On 9/7/2011 10:54 PM, William Zwicky wrote: > I worry that for some synths, the rate limiting is synth-specific. Is there > (or are you thinking of) a framework to plug rate limiting into? Or would > we need to implement a layer on top of sendSysex()? It has been a while since I worked on the ra

Re: [Jsynthlib-devel] Can't figure out how to branch...

On 9/6/2011 3:04 PM, Joachim wrote: > Hi Joe, > > according to the CVS-list it worked now. > Can you tell us the commands you used? Well, you're going to be a bit disappointed. First, I used the Subversion tool in Jetbrains IDEA. So, I didn't use command-line. Next, if you look closely, you'll

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

On 9/6/2011 10:44 AM, frankster wrote: > On 04/09/2011 23:33, Joe Emenaker wrote: >> I'm a little surprised that so few lines have been altered. I'm also >> surprised that MidiUtil is the top of the list, but I just looked at my >> copy and I now remember that I&

[Jsynthlib-devel] Can't figure out how to branch...

I'm such a SVN n00b... I can't make a branch for my refactor. When I try it from the command line on my Ubuntu box, I do... > svn copy > https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/trunk@r1051 > https://jsynthlib.svn.sourceforge.net/svnroot/jsynthlib/branches/UIRefactor-jemenake >

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1116] trunk/JSynthLib/doc/synths.html

On 09/04/2011 05:57 PM, William Zwicky wrote: > I just checked in an overhaul of DeviceListWriter that does just that. > Doesn't work very well, cuz: > * There's no source for the code to get those short comments, and the long > infoText is WAY to big for this table. > * Probing the device capa

Re: [Jsynthlib-devel] [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1116] trunk/JSynthLib/doc/synths.html

On 09/04/2011 01:44 PM, franks...@users.sourceforge.net wrote: > Updated list of supported synths: > > I have added all the drivers in SVN that are not mentioned. I have judged > whether patch/bank/editing is supported based on the existence of files with > Driver/Editor in their names, but have

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

On 09/04/2011 02:08 PM, frankster wrote: > On 03/09/2011 15:57, Joe Emenaker wrote: >> On 9/3/2011 6:59 AM, frankster wrote: >>> * which files are you planning to include in the refactor so I can avoid >>> changing those files? >> I've tracked down which re

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

On 9/3/2011 6:59 AM, frankster wrote: > * which files are you planning to include in the refactor so I can avoid > changing those files? I've tracked down which revision I started the refactor on (it's from back in 2006... yeah, really), so now I'm doing a diff on all of the files to see what I

Re: [Jsynthlib-devel] assigning bug reports

On 9/3/2011 5:32 AM, Vladimir Avdonin wrote: > Hey, > > I do not see a way I can assign bug report to myself. Is this > administrator only function? I think so. If nobody has any objections, I think I can make you a tracker-admin... - Joe

Re: [Jsynthlib-devel] Separating the synth drivers from JSL (Was: Name for refactored branch)

On 9/3/2011 2:16 AM, William Zwicky wrote: > On Fri, Sep 2, 2011 at 6:55 PM, Joe Emenaker wrote: >> Well, it seems a little silly to me that we would need to make a new >> release number any time someone makes a new driver. > Really? It's seems silly to me to make the use

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

I think it would be a help if people could minimize changes to Actions.java for a little bit. It's one of the files that getting modified quite a bit in the re-factor, so I'm worried about how the merge is going to go with that... - Joe Original Message Subject:[Jsyn

Re: [Jsynthlib-devel] Separating the synth drivers from JSL (Was: Name for refactored branch)

On 09/02/2011 05:18 PM, William Zwicky wrote: > On Fri, Sep 2, 2011 at 7:38 AM, Joe Emenaker wrote: >> Once I finish this refactor, the next thing I want to set to work on is >> making it so that drivers can be loaded as plugins. This will allow us >> to *not* have to make a

Re: [Jsynthlib-devel] Name for refactored branch

On 09/02/2011 10:13 AM, Vladimir Avdonin wrote: > Well, I have different phylosophy - I believe no development shall > happen trunk, it shall stay clean and functional at any moment. That sounds like you're saying that, at all times, checking out from trunk should give you a release. That's differ

[Jsynthlib-devel] Separating the synth drivers from JSL (Was: Name for refactored branch)

On 9/2/2011 5:22 AM, frankster wrote: > It seems to me that as there are several extra synths supported since > version 0.20, it would be worth getting some kind of release out > (perhaps alpha quality / unstable version), so that people can make use > of the work people have done over the last 6 y

[Jsynthlib-devel] Name for refactored branch

Okay, I think I understand Subversion enough to be dangerous. I'll need to make a branch to upload my refactored version to. All of the branches seem to be named after version numbers, but my understanding is that we can name them anything (like "my_cool_branch"). Should I name it some step fo

[Jsynthlib-devel] Required java version for JSL?

So, I'm looking through my JSL code (looks like I last touched it was 2006 or 2007... oy!). I'm finding some places which could be updated to using the newer java collections (like ArrayList, HashMap, etc.) as well as a few spots which could use the newer Java "foreach" loop. I think those all

Re: [Jsynthlib-devel] fixed build error in trunk

On 9/1/2011 7:49 AM, Vladimir Avdonin wrote: > Regarding you experimental work: > > The mechanism for such activity provided by subversion is branch. Once you > created you branch you can screw it around in any way you please, it would > not affect main line of development and releases. Once your

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

hecked... it looks like I might be a project admin, so I can grant SVN access to people. > Google also reveals that there is also some refactoring effort or > something that someone was doing a couple of years ago: > https://github.com/jpcaruana/jsynthlib - dunno if this is the same > ref

Re: [Jsynthlib-devel] fixed build error in trunk

On 8/31/2011 4:14 PM, Michael Hawkins wrote: > I ran into some rather tough jsynthlib admin's a couple of years back. I > think it was you Bill! I don't think Bill is an "admin" (in the sense that he can't authorize people to upload to the svn repository); I think only Joachim and Brian are. Th

Re: [Jsynthlib-devel] Any admins still active

On 4/4/2011 8:52 AM, Vladimir Avdonin wrote: > Hey, > > I would like to spend some time developing for JSynthLib. Calling admins of > the project to allow me join the project. > > I created a librarian plugin for yamaha SY77 that I would like to commit, and > I am willing to do some improvements

Re: [Jsynthlib-devel] XioSynth patch editor, 2nd try

Rib Rdb wrote: > I'd recommend migrating to svn so we could use > http://codereview.appspot.com One advantage of SVN is that it supports *moving* of files to different directories. Long ago, in a galaxy far away, we had talked about refactoring all of the core JSL code into a more-sensible pack

Re: [Jsynthlib-devel] Please add me as a developer

Michael Hawkins wrote: > Hi Jsynthlib ppl, > > I have been sending emails to admin's to try to get me added as a developer > but no one is home. I am not even sure the lights are on. LOL > I got an email a while back from *someone*... don't know if it was you... and they asked to be a develo

Re: [Jsynthlib-devel] XioSynth patch editor, 2nd try

Robert Wirski wrote: > Hi everyone, > of course we have new admin from some time, it is Joe Emenaker. > Hello Joe! Are you still on this list? > Yeah... still here. I was hoping that some other lazy admin would pipe up. Didn't want to be "the new guy who gets s

Re: [Jsynthlib-devel] Developer team

Robert Wirski wrote: > Hi Joe, would you consider adding me to the JSL developer team? > I'm officially considering it. Any idea what part you planned to work on? - Joe - This SF.Net email is sponsored by the Moblin Your M

Re: [Jsynthlib-devel] A dilemna about jsynthlib

Robert Wirski wrote: > I am writing this to point out that the project suffers from bad > luck. The are no active admins and developers. Being a frequent > jsynthlib user I am ready to spend some time to contribute as well as > prepare packages for OS X but it requires at least one active >

Re: [Jsynthlib-devel] JSynthLib on c't shareware CD

Gerrit Gehnen wrote: > I think, that makes no problem for us, esp. since c't is probably the > most serious magazine in germany. > Well, it certainly can't *hurt*. If it even drew 1 or 2 enthusiastic programmers to the project, it would be a plus. -