Menu
▾
▴
jsynthlib-devel — Mailing list for developers and users interested in improving the JSynthLib.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(90) |
Sep
(38) |
Oct
(22) |
Nov
(3) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(40) |
Feb
(119) |
Mar
(236) |
Apr
(41) |
May
(45) |
Jun
(10) |
Jul
(9) |
Aug
(12) |
Sep
(5) |
Oct
(17) |
Nov
(2) |
Dec
(3) |
| 2006 |
Jan
(23) |
Feb
(36) |
Mar
(49) |
Apr
|
May
|
Jun
(1) |
Jul
(11) |
Aug
(11) |
Sep
(15) |
Oct
(30) |
Nov
(36) |
Dec
(13) |
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(7) |
Jul
(4) |
Aug
(1) |
Sep
(19) |
Oct
(1) |
Nov
(2) |
Dec
(5) |
| 2008 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(5) |
Dec
|
| 2009 |
Jan
(26) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(26) |
Sep
(6) |
Oct
(5) |
Nov
(6) |
Dec
(6) |
| 2010 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(6) |
Aug
(8) |
Sep
(220) |
Oct
(9) |
Nov
(27) |
Dec
(33) |
| 2012 |
Jan
|
Feb
(4) |
Mar
(9) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2013 |
Jan
(6) |
Feb
(20) |
Mar
(6) |
Apr
(3) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(17) |
Nov
(2) |
Dec
|
| 2014 |
Jan
(9) |
Feb
(1) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Maciej Ł. <loz...@o2...> - 2011-09-19 20:34:11
|
Hi I have two ideas that could improve jsynthlib. One, easier to do is implementing randomization of patches. It would be not much work, as we already have all parameter ranges for patches where there are PatchEditors present. There could be two options - randomize all parameters, or only parameters designated by programmer (because some parameters should not be randomized). I think it would be great editing patches starting from some weird sounds and polish them to be "listenable" ;-) I have such option in my Waldotf MicroQ and I think it would be great to have this on any of my synths :-) What do you think? Could it be implemented as a part of ongoing code refactoring? Second idea is more complicated and to be honest I have no idea how to realize it :-D But It would be great to be able to translate patches between synths, at least to some extent. Let's assume that we have synth A with a filter where we can edit cutoff freq from say 100 Hz (midi hex value 0x00) to 1000 Hz (0xFF) and synth B wih filter cutoff from 10 Hz (0x00) to 500 Hz (0x7F). So 0x28 would be 200 Hz on synth A, and on synth B it would be 0x17 and we could translate patches this way. Of course 10Hz (0x00) on B couldn't be translated to A, and we would be forced to use 50 Hz. And there is also a problem with FM and Wavetable synths, but idea is tempting, isn't it? ;-> cheers Maciek |
|
From: Joe E. <jo...@em...> - 2011-09-19 18:04:17
|
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 forward a long time ago; the idea of having common methods for a whole manufacturer, since a manufacturer will often use certain data encoding methods in several synths. So, we could have a bunch of general Roland routines in synthdrivers.Roland and then the individual synths could be below that (like synthdrivers.Roland.BS420). The general consensus, as I recall, was "don't do that". For starters, it creates interdependency between synthdrivers (ie, it would break the possibility of having plugable/modularized synthdrivers). The other fear was this. Suppose that Roland comes out with some synth, the BFD-100. Someone makes a synthdriver for it, along with some data decoding routines in the "common" Roland section. Then, Roland comes out with another synth, the BFD-200, and someone else starts writing a synthdriver for *that*. Let's say that the data encoding in the BFD-200 is just a *little* different, such that the author of the BFD-200 synthdriver thinks that the *first* author made a slight mistake in the common code (and the second author doesn't know the specifics of the BFD-100, so they really don't know) and they change it to work properly for this BFD-200. This could break the BFD-100 driver. Of course, that doesn't stop you from just copying some code from other Roland drivers. The downside is that, if a actual bug *is* found in either copy, there's little likelihood that the person who fixes it will know to go fix it in the other drivers. - Joe |
|
From: frankster <jsy...@te...> - 2011-09-19 17:52:40
|
On 09/19/11 18:31, Joe Emenaker wrote: > 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 could just do a release at all. > haha well why don't we call 0.21 the 10 year anniversary release? maybe get a mention on some website because of it. I guess 0.21 will be out before December but whatever! frankie |
|
From: Joe E. <jo...@em...> - 2011-09-19 17:31:27
|
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 could just do a release at all. - Joe |
|
From: Roger W. <ro...@us...> - 2011-09-19 11:48:33
|
> 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. Java 1.5 (and before) is End Of Life so there is no reason to support anything older than 1.6. (And 1.6 has been around for ages.) Regards, Roger |
|
From: Martin T. <m.t...@zo...> - 2011-09-19 06:57:50
|
Hi, If I go inside my local svn copy of trunk/JSynthLib and type "make jar" on my commandline a file jsynthlib.jar is created. If I try to run this file with "java -jar jsynthlib.jar" I am getting the following error message: Failed to load Main-Class manifest attribute from jsynthlib.jar Something wrong with the Makefile ? -- MT |
|
From: Frankie F. <jsy...@te...> - 2011-09-18 21:53:25
|
On 18/09/2011 21:06, William Zwicky wrote: > On Sun, Sep 18, 2011 at 9:48 AM, Joe Emenaker <jo...@em...> wrote: > >> However, supporting Nimbus doesn't mean *requiring* 1.6. We could just >> have JSL check to see what version of Java it's running under. >> >> Personally, my preference for the behavior would be: >> - JSL's *default* look-n-feel would be Metal for 1.5 and earlier and >> Nimbus for 1.6 and later. >> - If the user has ever *changed* the setting to something, then it tries >> to stick to that whenever it can, instead of the default. >> - The gotcha here is when the user chooses Nimbus on 1.6 and then, for >> some reason, goes back to 1.5. In this case, JSL should switch back to >> Metal. (The easiest way to achieve this, probably, is to switch JSL back >> to "default" when someone chooses Nimbus). >> > I doubt we need to check the version number at all. Just: > - activate user's preference. If that fails or crashes, > - activate Nimbus. If that fails or crashes, > - activate Metal. > > I've implemented: - if a user preference exists, load it. otherwise load nimbus. - if anything fails then it will remain at the system default - probably metal. |
|
From: William Z. <wrz...@po...> - 2011-09-18 20:07:07
|
On Sun, Sep 18, 2011 at 9:48 AM, Joe Emenaker <jo...@em...> wrote: > > However, supporting Nimbus doesn't mean *requiring* 1.6. We could just > have JSL check to see what version of Java it's running under. > > Personally, my preference for the behavior would be: > - JSL's *default* look-n-feel would be Metal for 1.5 and earlier and > Nimbus for 1.6 and later. > - If the user has ever *changed* the setting to something, then it tries > to stick to that whenever it can, instead of the default. > - The gotcha here is when the user chooses Nimbus on 1.6 and then, for > some reason, goes back to 1.5. In this case, JSL should switch back to > Metal. (The easiest way to achieve this, probably, is to switch JSL back > to "default" when someone chooses Nimbus). > I doubt we need to check the version number at all. Just: - activate user's preference. If that fails or crashes, - activate Nimbus. If that fails or crashes, - activate Metal. -Bill Zwicky |
|
From: Frankie F. <jsy...@te...> - 2011-09-18 19:54:46
|
well I anticipate that when it creates a configuration for the first time, it checks if nimbus exists and if so sets it to that. otherwise it would default to metal as current. so no, it has no version implications (apart from looking better on 1.6+) frankie On 18/09/2011 16:32, 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. > > Joachim > > Am 18.09.2011 11:35, schrieb frankster: >> I noticed that its possible to change the look and feel of JSL to nimbus >> (with Java 6). IMO it looks a lot more modern than the default metal >> theme. I am inclined to put some code in that will default to this when >> creating the settings for the first time, unless anybody has any objections? >> >> http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/nimbus.html >> >> frankie >> >> ------------------------------------------------------------------------------ >> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >> http://p.sf.net/sfu/rim-devcon-copy2 >> _______________________________________________ >> Jsynthlib-devel mailing list >> Jsy...@li... >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >> > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: Joe E. <jo...@em...> - 2011-09-18 16:48:27
|
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 application loading (so I wouldn't have to write one myself, which would require over-riding the classloader). However, supporting Nimbus doesn't mean *requiring* 1.6. We could just have JSL check to see what version of Java it's running under. Personally, my preference for the behavior would be: - JSL's *default* look-n-feel would be Metal for 1.5 and earlier and Nimbus for 1.6 and later. - If the user has ever *changed* the setting to something, then it tries to stick to that whenever it can, instead of the default. - The gotcha here is when the user chooses Nimbus on 1.6 and then, for some reason, goes back to 1.5. In this case, JSL should switch back to Metal. (The easiest way to achieve this, probably, is to switch JSL back to "default" when someone chooses Nimbus). - Joe |
|
From: Joachim <li...@sd...> - 2011-09-18 15:32:50
|
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. Joachim Am 18.09.2011 11:35, schrieb frankster: > I noticed that its possible to change the look and feel of JSL to nimbus > (with Java 6). IMO it looks a lot more modern than the default metal > theme. I am inclined to put some code in that will default to this when > creating the settings for the first time, unless anybody has any objections? > > http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/nimbus.html > > frankie > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Michael H. <kor...@ya...> - 2011-09-18 14:58:43
|
Yes please! ________________________________ From: frankster <jsy...@te...> To: jsy...@li... Sent: Sunday, September 18, 2011 5:35 AM Subject: [Jsynthlib-devel] default look and feel I noticed that its possible to change the look and feel of JSL to nimbus (with Java 6). IMO it looks a lot more modern than the default metal theme. I am inclined to put some code in that will default to this when creating the settings for the first time, unless anybody has any objections? http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/nimbus.html frankie ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 _______________________________________________ Jsynthlib-devel mailing list Jsy...@li... https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: Martin T. <m.t...@zo...> - 2011-09-18 10:34:57
|
On Sun, 18 Sep 2011, frankster wrote: > So I have changed a little bit what happens when you choose the delete > duplicates action: > * opens the progress dialogue > * deletes duplicates > * closes the progress dialogue > * displays the number deleted dialogue Looks much better. But I have not been able to see the progress dialogue. Maybe because it is simply going too fast to meet the eye? I have tested with a atificially created library with 1000+ duplicates! (Just did Ctr+c and a lot of Ctrl+v in a library) -- MT |
|
From: frankster <jsy...@te...> - 2011-09-18 09:58:26
|
On 09/18/11 10:36, Martin Tarenskeen wrote: > >> Are you sure it is completely fixed ? Yes, I am not getting that >> error message anymore. But I still see the strange combination of >> these two dialogs "Working... Deleting duplicates..." and "xxx >> PatchesAndScenes were Deleted" on my desktop. (Screendump attached) >> >> And clicking OK does not help, I have to click the windows close button. > > Still having the same issue, even with a small library with only 4 > patches. I have attached this a small example.patchlib (4 patches, > including 2 dups). The "Working..." dialog is hidden behind the "2 > Patches and Scenes were deleted" dialog. I had to move the dialog to > see them both and then took a screenshot. Also attached. > So I have changed a little bit what happens when you choose the delete duplicates action: * opens the progress dialogue * deletes duplicates * closes the progress dialogue * displays the number deleted dialogue Can you give the code in SVN a go and see if this behaves better? frankie |
|
From: Martin T. <m.t...@zo...> - 2011-09-18 09:36:29
|
On Sat, 17 Sep 2011, Martin Tarenskeen wrote: > On Sat, 17 Sep 2011, frankster wrote: > >> I have fixed bug 3410743 but can't mark it as fixed. Could someone** > > Are you sure it is completely fixed ? Yes, I am not getting that error > message anymore. But I still see the strange combination of these two dialogs > "Working... Deleting duplicates..." and "xxx PatchesAndScenes were Deleted" > on my desktop. (Screendump attached) > > And clicking OK does not help, I have to click the windows close button. Still having the same issue, even with a small library with only 4 patches. I have attached this a small example.patchlib (4 patches, including 2 dups). The "Working..." dialog is hidden behind the "2 Patches and Scenes were deleted" dialog. I had to move the dialog to see them both and then took a screenshot. Also attached. -- MT |
|
From: frankster <jsy...@te...> - 2011-09-18 09:36:23
|
I noticed that its possible to change the look and feel of JSL to nimbus (with Java 6). IMO it looks a lot more modern than the default metal theme. I am inclined to put some code in that will default to this when creating the settings for the first time, unless anybody has any objections? http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/nimbus.html frankie |
|
From: frankster <jsy...@te...> - 2011-09-17 21:11:04
|
On 09/17/11 15:50, Martin Tarenskeen wrote: > > > On Sat, 17 Sep 2011, frankster wrote: > >> I have fixed bug 3410743 but can't mark it as fixed. Could someone** > > Are you sure it is completely fixed ? Yes, I am not getting that error > message anymore. But I still see the strange combination of these two > dialogs "Working... Deleting duplicates..." and "xxx PatchesAndScenes > were Deleted" on my desktop. (Screendump attached) > > And clicking OK does not help, I have to click the windows close > button. Seems to be harmless, but not elegant > (I am using Linux Fedora 11 with LXDE desktop) > it kind of works ok for me. There's the progress dialogue but it barely stays up for any time in the test case i've tried. then when the operation completes it displays the notification about how many things its deleted and when I click ok, both dialogues disappear. It sounds like you're getting something a bit different to what you experience. Can you go into a bit more detail about what you find? It looks like you're using quite a large library compared to the one I tested with - maybe thats why I don't see the same as you. Do you have the same problem with clicking ok if you make a library with 3 or 4 patches in it? Also if you don't like having two dialogues, what do you think would be better - there should just be the progress dialogue and it should show the message about how many things were deleted itself? > And while you are looking at it: can you put some spaces in > "PatchesAndScenes" and change "Deleted" to lowercase "deleted" > Done but I bet you could make a patch that does this even though you've not much java experience ;) frankie (replying to the list in case anyone else has any input about this dialogue/progress bar) |
|
From: frankster <jsy...@te...> - 2011-09-17 18:19:00
|
I suppose that a separate file would be best as it would mean that programming skills (however minimal) wouldn't be required to add tips. A quick google search says that there is a control called JEditorPane which can display html. frankie On 09/17/11 16:38, Joe Emenaker wrote: > 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 from something like this. I'm willing to > write it, but I won't be able to get to it immediately. If someone else > wants to do it, that's fine. > > But I wanted to discuss how we should manage the tips. It would be nice > to be able to color/bolden/italicize/underline different sections of > text for emphasis. My guess is that Java includes some kind of HTML > viewer panel, but I'm not sure. If it does, then we could just store all > of the tips as HTML. If we did that, would we want to store all of the > tips as strings within the class file that handles displaying them? Or > do we want to keep them in a separate file? Do we want to support > images? External links to the wiki or web documentation? > > - Joe > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: Joe E. <jo...@em...> - 2011-09-17 15:38:18
|
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 from something like this. I'm willing to write it, but I won't be able to get to it immediately. If someone else wants to do it, that's fine. But I wanted to discuss how we should manage the tips. It would be nice to be able to color/bolden/italicize/underline different sections of text for emphasis. My guess is that Java includes some kind of HTML viewer panel, but I'm not sure. If it does, then we could just store all of the tips as HTML. If we did that, would we want to store all of the tips as strings within the class file that handles displaying them? Or do we want to keep them in a separate file? Do we want to support images? External links to the wiki or web documentation? - Joe |
|
From: Joachim <li...@sd...> - 2011-09-17 09:36:26
|
Frankie, you should be able to manage tracker items now. Joachim Am 17.09.2011 10:59, schrieb frankster: > I have fixed bug 3410743 but can't mark it as fixed. Could someone** > with the ability to update bug statuses do this for me, or alternatively > give me the ability to do this. > > thanks, > Frankie > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: frankster <jsy...@te...> - 2011-09-17 08:59:42
|
I have fixed bug 3410743 but can't mark it as fixed. Could someone** with the ability to update bug statuses do this for me, or alternatively give me the ability to do this. thanks, Frankie |
|
From: Martin T. <m.t...@zo...> - 2011-09-17 05:25:59
|
Hi, Has anyone else noticed problems with the "remove duplicates" lately ? Two dialogs are stuck on my screen. One saying xxx duplicates have been removed, the other saying "working....". (see attachment) I have submitted a bugreport in the SF tracker. -- MT |
|
From: frankster <jsy...@te...> - 2011-09-16 14:25:11
|
Just noticed that the sf.net page was registered in december 2001, which means that JSL is nearly 10 years old! |
|
From: Frankie F. <jsy...@te...> - 2011-09-14 21:19:17
|
On 01/09/2011 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 ;-). > 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. frankie |
|
From: Roger W. <ro...@us...> - 2011-09-13 11:19:17
|
2011/9/12 Joe Emenaker <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) I think both are equally important, project structure is easier, though, since you only have to set it once (normally). Package structure has to evolve as you go. I don't have a fresh view of the package tree but I recall that there was a monster package with too much different functionality combined. Packages should be quite small and focused on a limited functionality. I wish I had the time to dive into the code and have some ideas regarding this but right now is not the time for me. Regards, Roger |
89 messages has been excluded from this view by a project administrator.
