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: frankster <jsy...@te...> - 2011-09-04 11:37:32
|
Thanks for reporting this, its probably me that broke it because I added some images for the waveforms into the editor yesterday. It was working for me though! I'll have a look at this later on and see if I can get it to happen as well. frankie On 09/04/11 11:19, Martin Tarenskeen wrote: > Using the latest SVN versions of JSynthLib I am getting an error when > trying to open the Yamaha TX81Z voice editor: > > > The error was: > 99 > The exception text is: > java.lang.ArrayIndexOutOfBoundsException: 99 > at > synthdrivers.YamahaTX81z.YamahaTX81zSingleEditor.<init>(YamahaTX81zSingleEditor.java:121) > at > synthdrivers.YamahaTX81z.YamahaTX81zSingleDriver.editPatch(YamahaTX81zSingleDriver.java:67) > at core.Patch.edit(Patch.java:181) > at > core.AbstractLibraryFrame.editSelectedPatch(AbstractLibraryFrame.java:348) > at core.Actions$1Worker.run(Actions.java:969) > > > I have learnt how to compile and run Java code, but that's where my Java > skills more or less end. But it looks like this error was introduced > during the recent SVN activity. Maybe someone can take a look at this? > > I have also been doing a few improvements on the envelope graphics for > the Yamaha DX7 and DX100/TX81z family (EG and PEG). (All were missing a > Sustain segment, which I have fixed now). I will send some > patches/proposals later, after the above bug has been fixed and after I > have done some more testing with my locally modified copy. > |
|
From: frankster <jsy...@te...> - 2011-09-04 11:31:11
|
Thanks for reporting this, its probably me that broke it because I added some images for the waveforms into the editor yesterday. It was working for me though! I'll have a look at this later on and see if I can get it to happen as well. frankie On 09/04/11 11:19, Martin Tarenskeen wrote: > Using the latest SVN versions of JSynthLib I am getting an error when > trying to open the Yamaha TX81Z voice editor: > > > The error was: > 99 > The exception text is: > java.lang.ArrayIndexOutOfBoundsException: 99 > at > synthdrivers.YamahaTX81z.YamahaTX81zSingleEditor.<init>(YamahaTX81zSingleEditor.java:121) > at > synthdrivers.YamahaTX81z.YamahaTX81zSingleDriver.editPatch(YamahaTX81zSingleDriver.java:67) > at core.Patch.edit(Patch.java:181) > at > core.AbstractLibraryFrame.editSelectedPatch(AbstractLibraryFrame.java:348) > at core.Actions$1Worker.run(Actions.java:969) > > > I have learnt how to compile and run Java code, but that's where my Java > skills more or less end. But it looks like this error was introduced > during the recent SVN activity. Maybe someone can take a look at this? > > I have also been doing a few improvements on the envelope graphics for > the Yamaha DX7 and DX100/TX81z family (EG and PEG). (All were missing a > Sustain segment, which I have fixed now). I will send some > patches/proposals later, after the above bug has been fixed and after I > have done some more testing with my locally modified copy. > |
|
From: frankster <jsy...@te...> - 2011-09-04 11:24:20
|
On 09/03/11 15:38, Joe Emenaker wrote: > Well, I was using the space as quantifiable evidence that the codebase > is so heavily skewed toward synthdrivers... by a factor of about 6:1. > So, svn checkouts take 7x as long, making an archive of the code takes > 7x as long... etc. Every time I zip, unzip, or checkout a copy of the > code, "core" goes by pretty fast, and then I get to watch this endless > string of synths where I'm thinking "Wow... look at all of these synths > that I've never owned, never *will* own, and don't even know what they > look like... good thing I've got drivers for 'em...". And this > lopsidedness is just going to get more-lopsided. Although in the jar that people download its about 1.5Mb for groovy and a few hundred k for JSL including all drivers IIRC. so wierdly its lopsided in the other direction as far as users are concerned. > > Also, it just irks me that we have to generate a synthdrivers.properties > file any time a driver is added. The ".properties" system is just so... > yucky. JSL should be able to quickly and dynamically find all of its > drivers by itself. Yeah you could imagine a nice web service which accepts a device query string and then provides a list of one or more drivers that claim to support it. Although the downside on this is that it would require that a server was maintained, and I notice that the patch upload website's search box doesn't work. So relying on a web service possibly isn't something that this project has historically been good at? |
|
From: Joachim <li...@sd...> - 2011-09-04 11:16:21
|
Hi, well, he can't do more damage there than in the SVN repository: I'm ok with that. Cheers Joachim Am 03.09.2011 16:42, schrieb Joe Emenaker: > 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 > > ------------------------------------------------------------------------------ > 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 > |
|
From: Martin T. <m.t...@zo...> - 2011-09-04 10:19:19
|
Using the latest SVN versions of JSynthLib I am getting an error when trying to open the Yamaha TX81Z voice editor: The error was: 99 The exception text is: java.lang.ArrayIndexOutOfBoundsException: 99 at synthdrivers.YamahaTX81z.YamahaTX81zSingleEditor.<init>(YamahaTX81zSingleEditor.java:121) at synthdrivers.YamahaTX81z.YamahaTX81zSingleDriver.editPatch(YamahaTX81zSingleDriver.java:67) at core.Patch.edit(Patch.java:181) at core.AbstractLibraryFrame.editSelectedPatch(AbstractLibraryFrame.java:348) at core.Actions$1Worker.run(Actions.java:969) I have learnt how to compile and run Java code, but that's where my Java skills more or less end. But it looks like this error was introduced during the recent SVN activity. Maybe someone can take a look at this? I have also been doing a few improvements on the envelope graphics for the Yamaha DX7 and DX100/TX81z family (EG and PEG). (All were missing a Sustain segment, which I have fixed now). I will send some patches/proposals later, after the above bug has been fixed and after I have done some more testing with my locally modified copy. -- MT |
|
From: Joe E. <jo...@em...> - 2011-09-03 14:57:45
|
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've changed. So far, it's the big-picture window/desktop stuff. I don't think I've touched any of the widget stuff. I think I've also left the "action" parts of Action.java alone. By that, I mean... the stuff where each action has a unique ID and they register their place in the menus and their hot-keys and such. But those inner classes in Actions like Actions.MenuDesktop and Actions.MenuFrame, I'm pretty sure that's all been yanked to a dedicated set of UI classes... so that a class named "Actions" doesn't need to be importing BorderLayout and Dimension. I should have a concrete list for you in a day. - Joe |
|
From: Joe E. <jo...@em...> - 2011-09-03 14:42:26
|
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 |
|
From: Joe E. <jo...@em...> - 2011-09-03 14:39:10
|
On 9/3/2011 2:16 AM, William Zwicky wrote: > On Fri, Sep 2, 2011 at 6:55 PM, Joe Emenaker<jo...@em...> 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 user rummage around either > SourceForge or a custom GUI for what amounts to a tiny download, and then > they need to do this repeatedly if they have several synths. With an > integrated download, they get the latest core, and ALL the latest synths at > once. Well, that's a fair concern. I don't necessarily think we should release the core *without* any drivers. I just think we should be able to release new drivers without having to do another release. I'm thinking kind of how MIDI Quest does it, where a large part of the driver set is included, but they're always adding more to the website. Also, they don't necessarily have to go rummaging, either. With the MIDI inquiry feature, we could have JSL query a synth, get an ID string back, and then magically grab that over the net for the user. >> Also, I just looked at the disk usage for my latest checkout of trunk, >> and the "core" package takes about 1MB while "synthdrivers" takes almost >> 6MB. So, most of the space and compile-time is going into the >> synthdrivers, and most users only need one or two of those. Just seems >> like a lot of waste. >> > Well then it's time to upgrade your 486. 6MB is not worth worrying about, > even on an SSD. User time is more precious than disk space. Well, I was using the space as quantifiable evidence that the codebase is so heavily skewed toward synthdrivers... by a factor of about 6:1. So, svn checkouts take 7x as long, making an archive of the code takes 7x as long... etc. Every time I zip, unzip, or checkout a copy of the code, "core" goes by pretty fast, and then I get to watch this endless string of synths where I'm thinking "Wow... look at all of these synths that I've never owned, never *will* own, and don't even know what they look like... good thing I've got drivers for 'em...". And this lopsidedness is just going to get more-lopsided. Also, it just irks me that we have to generate a synthdrivers.properties file any time a driver is added. The ".properties" system is just so... yucky. JSL should be able to quickly and dynamically find all of its drivers by itself. - Joe |
|
From: frankster <jsy...@te...> - 2011-09-03 14:00:15
|
* which files are you planning to include in the refactor so I can avoid changing those files? * is it possible to submit the refactoring in several stages to that only a few files are off limits at a time? this depends how far you are through it I guess frankie On 09/03/11 14:53, Joe Emenaker wrote: > 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: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] > trunk/JSynthLib/core/Actions.java > Date: Sat, 03 Sep 2011 12:46:24 +0000 > From: fra...@us... > To: jsy...@li... > > > > Revision: 1104 > http://jsynthlib.svn.sourceforge.net/jsynthlib/?rev=1104&view=rev > Author: frankster > Date: 2011-09-03 12:46:23 +0000 (Sat, 03 Sep 2011) > Log Message: > ----------- > add an accelerator for new patch: ctrl-shift-p (probably cmd-shift-p on a mac but not sure). > so you can now do ctrl-l, ctrl-shift-p to create a new library then create a patch within the library > > Modified Paths: > -------------- > trunk/JSynthLib/core/Actions.java > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > > > ------------------------------------------------------------------------------ > 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-cvs mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-cvs > > > ------------------------------------------------------------------------------ > 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 |
|
From: frankster <jsy...@te...> - 2011-09-03 13:56:10
|
On 09/03/11 10:16, William Zwicky wrote: > > I'll admit, the list is pretty short. > * Release 0.21. > * Sweep up outstanding bugs and patches. > * Release 0.22. > * Emenaker's Grand Refactoring. > * Release 0.30. This "Release Plan" sounds goods to me. frankie |
|
From: frankster <jsy...@te...> - 2011-09-03 13:55:51
|
On 09/03/11 04:14, William Zwicky wrote: > > And 3a is the best simply because one should stay away from merging wherever > possible. And it's pretty much free, since it's always good to create a tag > for every version that is released. > Or use mercurial/git because they do a slightly better job of merging ;) frankie |
|
From: Joe E. <jo...@em...> - 2011-09-03 13:54:03
|
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: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java Date: Sat, 03 Sep 2011 12:46:24 +0000 From: fra...@us... To: jsy...@li... Revision: 1104 http://jsynthlib.svn.sourceforge.net/jsynthlib/?rev=1104&view=rev Author: frankster Date: 2011-09-03 12:46:23 +0000 (Sat, 03 Sep 2011) Log Message: ----------- add an accelerator for new patch: ctrl-shift-p (probably cmd-shift-p on a mac but not sure). so you can now do ctrl-l, ctrl-shift-p to create a new library then create a patch within the library Modified Paths: -------------- trunk/JSynthLib/core/Actions.java This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ------------------------------------------------------------------------------ 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-cvs mailing list Jsy...@li... https://lists.sourceforge.net/lists/listinfo/jsynthlib-cvs |
|
From: Vladimir A. <vl...@gm...> - 2011-09-03 12:37:37
|
On 09/03/2011 04:16 AM, William Zwicky 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 user rummage around either > SourceForge or a custom GUI for what amounts to a tiny download, and then > they need to do this repeatedly if they have several synths. With an > integrated download, they get the latest core, and ALL the latest synths at > once. > > This would allow anyone outside the project release drivers to public easily. This would allow any user that can not or does not want to build himself to use binary drivers from any source. This would allow anyone to use any version of driver with any version of application, without being forced to upgrade everything when wanting to upgrade just one. It is all about freedom of choice really. -- Vladimir |
|
From: Vladimir A. <vl...@gm...> - 2011-09-03 12:32:20
|
Hey, I do not see a way I can assign bug report to myself. Is this administrator only function? -- Vladimir |
|
From: William Z. <wrz...@po...> - 2011-09-03 09:16:59
|
On Fri, Sep 2, 2011 at 6:55 PM, Joe Emenaker <jo...@em...> 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 user rummage around either SourceForge or a custom GUI for what amounts to a tiny download, and then they need to do this repeatedly if they have several synths. With an integrated download, they get the latest core, and ALL the latest synths at once. > Also, I just looked at the disk usage for my latest checkout of trunk, > and the "core" package takes about 1MB while "synthdrivers" takes almost > 6MB. So, most of the space and compile-time is going into the > synthdrivers, and most users only need one or two of those. Just seems > like a lot of waste. > Well then it's time to upgrade your 486. 6MB is not worth worrying about, even on an SSD. User time is more precious than disk space. > But at this point, we have much bigger fish to > > fry. > > Like? Do you mean bug-reports and feature-requests in the tracker, or do > you have other stuff in mind? > I'll admit, the list is pretty short. * Release 0.21. * Sweep up outstanding bugs and patches. * Release 0.22. * Emenaker's Grand Refactoring. * Release 0.30. I view all of those as more important than the plugin system. -Bill Zwicky |
|
From: William Z. <wrz...@po...> - 2011-09-03 03:14:34
|
On Fri, Sep 2, 2011 at 6:23 PM, Joe Emenaker <jo...@em...> wrote: > 3a) Branch off 2.0 and let bug-fixing happen there while new features > and development toward 3.0 happen in trunk. > 3b) Branch off a copy of trunk for work on 3.0, while the bug fixes > for 2.0 happen in trunk. When 2.0 is released, a tag is made for the > current state of trunk, and then the 3.0 branch is merged back into > trunk, and then the 3.0 branch can be deleted. > Nice thing about Subversion is that there is no difference between "tags" and "branches". Each is a copy of the repository as of some point in time. Or more precisely, *a* repository, since you can make branches off of other branches. Or branches from tags. Or tags from branches. You can check out a tag, then commit changes as if it was a branch. Because it *is* a branch. So /trunk is nothing more than the "blessed branch". And the difference between /tags and /branches is entirely political, and not at all technical. In general, /tags is mean to hold *past* states of the system (i.e. we branch /trunk to form /tags/release_20, then continue development on /trunk). And /branches is mean to hold *future* states of the system (i.e. we continue updating drivers under /trunk, while Joe builds his new version under /branches/emenaker_refactor). And 3a is the best simply because one should stay away from merging wherever possible. And it's pretty much free, since it's always good to create a tag for every version that is released. -Bill Zwicky |
|
From: Joe E. <jo...@em...> - 2011-09-03 01:55:58
|
On 09/02/2011 05:18 PM, William Zwicky wrote: > On Fri, Sep 2, 2011 at 7:38 AM, Joe Emenaker<jo...@em...> 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 new release of JSL in order to get a new driver >> out to the world > Who would such a thing serve? The core JSL group doesn't need it, since we > can post a new release with the changes. 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. Also, I just looked at the disk usage for my latest checkout of trunk, and the "core" package takes about 1MB while "synthdrivers" takes almost 6MB. So, most of the space and compile-time is going into the synthdrivers, and most users only need one or two of those. Just seems like a lot of waste. > That said, a plugin system is not a *bad* thing; it will get us thinking > about stabilizing the API. But at this point, we have much bigger fish to > fry. Like? Do you mean bug-reports and feature-requests in the tracker, or do you have other stuff in mind? - Joe |
|
From: Joe E. <jo...@em...> - 2011-09-03 01:24:00
|
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 different from how I've heard revision-control systems described in the past. Basically, the story I usually hear is: 1 - Trunk is dynamic, and always in flux. *Most* of the time, compiling from trunk will give you an application with bugs or half-implemented features. But trunk *should* compile without errors, generally. Bugs, where things in the successfully-compiled application don't work quite right, those are okay. 2 - When a release is coming up on a quiet or small project (let's call it 2.0), the devs can issue a feature-freeze and focus only on bug fixes in trunk until a release is made. Then, a tag is created for that release, and then work can begin on the new round of features in the next version (3.0). This method doesn't allow for issuing bug fixes for older versions, however. If an end user wants a bug fixed, they have to wait for the next release. Fine for small projects. 3 - If there's the need to issue bug fixes for past releases, then you need to branch, and you've got two options: 3a) Branch off 2.0 and let bug-fixing happen there while new features and development toward 3.0 happen in trunk. 3b) Branch off a copy of trunk for work on 3.0, while the bug fixes for 2.0 happen in trunk. When 2.0 is released, a tag is made for the current state of trunk, and then the 3.0 branch is merged back into trunk, and then the 3.0 branch can be deleted. I think 3a is a much better way to go than 3b, for the following reasons: - With 3b, all of the devs need to be told (and they have to remember) when the purpose of trunk changes. For example, when there's a feature-freeze, they all need to be told "bug fixes only in trunk until further notice". Then, when 2.0 gets released, they must be told that new features can now be introduced into trunk again. 3a avoids this; trunk always is the place for new features and bug-fixes which aren't version-specific. - 3a doesn't require any merging of branches. Merging always brings the possibility of conflicts, so it's nice when they can be avoided. - 3b doesn't really allow for bug fixes to previous versions. If you merge the 3.0 code back into trunk and then want to make a 2.01, what do you do? If you branch off the 2.0 revision of trunk to work on it separately, then you're basically doing the 3a method, so why not just start off that way? So, if it were up to me, I'd branch releases (and only if there were going to be bug-fix work on old releases. If not, just make tags) and keep trunk "cutting edge". The only other time I'd make a branch is when there's some major development to be done which is going to make things *not compile* properly. If that happens in trunk, then other devs can't test their changes, so that needs to be avoided. - Joe |
|
From: William Z. <wrz...@po...> - 2011-09-03 00:26:41
|
On Fri, Sep 2, 2011 at 7:59 AM, Vladimir Avdonin <vl...@gm...> wrote: > Hey, please do not hide you development. The branch does not need to be > tidy and compilable. You could dump your work in progress freely on it. > This way other developers would be able to plug in early. I for one is > looking forward to get into this development. Looks exciting > When you put it that way, it makes excellent sense. In fact, I'm now having trouble figuring out the value of checking the new JSynthLib into trunk on top of the old one. If that much stuff has changed, maybe you should just put it under trunk/JSynthLib3, and we'll flag the old one as deprecated. Also, my pet peeve is having all the source code directly under the root directory. I prefer to keep my source under a "src" sub-dir. How much longer will it take to make the new version ready for checkin? If it'll be a while, could you shoot me a copy to look at? -Bill Zwicky |
|
From: William Z. <wrz...@po...> - 2011-09-03 00:18:20
|
On Fri, Sep 2, 2011 at 7:38 AM, Joe Emenaker <jo...@em...> 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 new release of JSL in order to get a new driver > out to the world. > Who would such a thing serve? The core JSL group doesn't need it, since we can post a new release with the changes. Outside developers probably won't use it, because we're still version 0.x, and serious developers will need to overhaul the core to meet their needs. That said, a plugin system is not a *bad* thing; it will get us thinking about stabilizing the API. But at this point, we have much bigger fish to fry. > 1 - Will we want to manage the source for JSL and the drivers > *separately* at that point? Would we have a branch for every driver, or > have a branch for *all* of the drivers? Or is there a better way to do > this than to use branches? > We already have trunk/JSynthLib, so: trunk/drivers/default would build a single plugin containing the current set of drivers. trunk/drivers/* would be for developers who have access to JSL's subversion, but want to maintain their driver separately. For external developers, they can keep their source wherever they want. > 2 - How do we want to *distribute* the drivers? What I'm getting at here > is that I think Brian still has control over jsynthlib.org, but he's > hardly ever here, so I think there's little chance of us being able to > store the drivers on his server. Do we want to store them on > SourceForge? Do we want to store them on my server or someone else's? If > we store it on someone's server, do we want to use some descriptive > domain name (like jsldrivers.org or something)? > Primary distribution point will be SourceForge for our drivers. For external drivers, the external devs will need to arrange hosting initially. If JSL becomes big and popular, then we can consider building a "3rd Party Drivers" page on jsynthlib.org. If we (or Brian) can't update jsynthlib.org, then we'd be better off with a new product name and domain rather than something silly like jsldrivers.org. -Bill Zwicky |
|
From: William Z. <wrz...@po...> - 2011-09-02 21:06:10
|
On Fri, Sep 2, 2011 at 10:13 AM, Vladimir Avdonin <vl...@gm...> wrote: > Well, I have different phylosophy - I believe no development shall > happen trunk, it shall stay clean and functional at any moment. The only > commits that shall go there should be from tested working branch. > ... > What if we do not want to go back? Breaking up things is inevitable in > process of changing. And broken period can take extended time. > Your suggestions are good for a large and highly active project staffed with professional engineers. But many of the people contributing to JSL are amateurs, and only contribute for a short period of time before moving on. We want a system that maximizes *their* productivity, and ensures their changes make it into trunk. Also bear in mind, I believe that this current burst of activity will fade to nothing. It always happened in the past, so I must assume it will happen again. With that in mind, I want a system that maximizes the productivity of this current group of contributors before they leave, and also leaves JSL in a clear and obvious state for the next group when they pick it up in a year or two. Thus I believe the simplest solution is the best for JSL. And the simplest solution is to simply encourage everyone to contribute directly to trunk. This will increase the chances that someone will damage the code, but I believe the risk of damage is insignificant to the advantages of getting everyone's code into trunk where it is immediately useable. -Bill Zwicky |
|
From: Joachim <li...@sd...> - 2011-09-02 17:55:59
|
> it shall stay clean and functional at any moment. If only clean stuff is commited this would still be possible. > What if we do not want to go back? Breaking up things is inevitable in > process of changing. And broken period can take extended time. We could still use a refactoring branch. > And like is said, what if there will be no common agreement in the list? > Start voting? I do not think we should limit peoples creativity with > democracy If that is the case we can still think about a solution like yours. Anyway: How would you fit this into the project. > I think I would rest my case here. I'm just expressing my opinion like you are. I'm not the dictator of JSynthLib or something like that. Cheers Joachim Am 02.09.2011 19:13, schrieb Vladimir Avdonin: > On 09/02/2011 11:57 AM, Joachim wrote: >> Ah, I don't think it makes sense to make a branch for every bug. > > Not every bug, just complicated ones, involving non-obvious changes and > requiring extensive testing > >> >> > and it might be not clear at start towards what release it >> > will be targeted >> >> The target release is not a problem if the development takes place >> in the trunk. > > Well, I have different phylosophy - I believe no development shall > happen trunk, it shall stay clean and functional at any moment. The only > commits that shall go there should be from tested working branch. > > This way any parallel developments that happen on branches will not > break each others during syncing with trunk. > >> >> > it probably would break everything in the project >> >> Remember: We can always go back and only working code should be >> checked in, so the mess up shouldn't be too much anyway. >> I don't see a big danger there. > > What if we do not want to go back? Breaking up things is inevitable in > process of changing. And broken period can take extended time. > >> >> > suppose I got some stupid >> > idea that i am not even sure it make sense >> >> Develop it lokally and ask the list if it shall be added or not. >> I would ask prior to putting any effort in it.;) > > And like is said, what if there will be no common agreement in the list? > Start voting? I do not think we should limit peoples creativity with > democracy > >> >> Such a concept would only complicate the development process in my eyes >> and I still don't see a benefit. > > I think I would rest my case here. Whatever goes > |
|
From: Vladimir A. <vl...@gm...> - 2011-09-02 17:13:22
|
On 09/02/2011 11:57 AM, Joachim wrote: > Ah, I don't think it makes sense to make a branch for every bug. Not every bug, just complicated ones, involving non-obvious changes and requiring extensive testing > > > and it might be not clear at start towards what release it > > will be targeted > > The target release is not a problem if the development takes place > in the trunk. Well, I have different phylosophy - I believe no development shall happen trunk, it shall stay clean and functional at any moment. The only commits that shall go there should be from tested working branch. This way any parallel developments that happen on branches will not break each others during syncing with trunk. > > > it probably would break everything in the project > > Remember: We can always go back and only working code should be > checked in, so the mess up shouldn't be too much anyway. > I don't see a big danger there. What if we do not want to go back? Breaking up things is inevitable in process of changing. And broken period can take extended time. > > > suppose I got some stupid > > idea that i am not even sure it make sense > > Develop it lokally and ask the list if it shall be added or not. > I would ask prior to putting any effort in it.;) And like is said, what if there will be no common agreement in the list? Start voting? I do not think we should limit peoples creativity with democracy > > Such a concept would only complicate the development process in my eyes > and I still don't see a benefit. I think I would rest my case here. Whatever goes -- Vladimir |
|
From: Joachim <li...@sd...> - 2011-09-02 16:57:31
|
Ah, I don't think it makes sense to make a branch for every bug. > and it might be not clear at start towards what release it > will be targeted The target release is not a problem if the development takes place in the trunk. > it probably would break everything in the project Remember: We can always go back and only working code should be checked in, so the mess up shouldn't be too much anyway. I don't see a big danger there. > suppose I got some stupid > idea that i am not even sure it make sense Develop it lokally and ask the list if it shall be added or not. I would ask prior to putting any effort in it. ;) Such a concept would only complicate the development process in my eyes and I still don't see a benefit. Cheers Joachim Am 02.09.2011 18:43, schrieb Vladimir Avdonin: > On 09/02/2011 11:25 AM, Joachim wrote: >> Hi, >> >> > I could think of three directories: fixes, features, users. >> >> Normally branches are made for different releases. I don't see >> a benefit in these three suggested branches as bug fixes have to >> be merged with new features anyway. The users branch is a concept >> I didn't get. >> > > Oh, those are not branches themselves, those would be just directories > to organize branches of similar purpose together. > > Probably use examples would help to justify. > > Fixes is easy one - each branch in there could be for an accepted bug in > bug tracker. It would leave there until the fix is tested and accepted > at which point changes merge to trunk and branch is deleted. > > Feature is also more or less clear. Say a major feature effort is > undertaken, like adding visual themes for example. Several people would > work on that, and it might be not clear at start towards what release it > will be targeted, or even when it would be completed. And at the > beginning it probably would break everything in the project. It will > eventually be implemented at which point it would merge to either trunk, > or pre-release brunch, and changes will be deleted. > > For users I would illustrate it like this - suppose I got some stupid > idea that i am not even sure it make sense, but I want to try it anyway. > Like, say, adding sequencer. It would not fit in features in my view, > because not everyone would agree that the project needs such feature at > all. The features would have only agreed lines of development. Users are > free to put anything in their personal branches. The advantage would be > capturing any potentially useful development. > > Anyway, this all is just suggestion. I would not insist on any > |
|
From: Joachim <li...@sd...> - 2011-09-02 16:44:37
|
Sounds to me like the mimetype is not the problem but a binary flag is set. I'd say you may try it. If it doesn't work you can still go back to the current revision of the file. Cheers Joachim Am 02.09.2011 18:27, schrieb frankster: > I ran into that problem and got around it by using the --force argument. > > But taking the attribute off would also be good IMO, its not like it > contains any binary data blobs or anything. > > frankie > > On 09/02/11 17:15, Vladimir Avdonin wrote: >> Hey, >> >> Is anyone else having problem not being able to diff build.xml from svn >> clients. I get this error: >> >> $ svn diff -r 1094 build.xml >> Index: build.xml >> =================================================================== >> Cannot display: file marked as a binary type. >> svn:mime-type = application/xml >> >> >> Apparently this is because of the svn property on that file >> svn:mime-type = application/xml that seem have been there since start of >> time. >> >> Does anybody still need that property on the file for some reason? >> >> If noone will respond, I would remove the property off the file. Or >> anyone cares that it shall be change to mime-type = text/xml? >> > > > ------------------------------------------------------------------------------ > 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 > |
89 messages has been excluded from this view by a project administrator.
