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: <chr...@ch...>
<chr...@ch...> - 2013-11-07 09:45:27
|
Packe [pa...@ya...] wrote on 05 November 2013 19:08:
>
> Hi again,
>
> I've been away for a week and didn't have time to work on this.
>
> I will now start the work to port the project to Maven.
>
> Chris, did you have the time to look at what you have done in the
> build.xml file in your refactor branch?
>
> From what I could see you just cleaned it up and added PMD and check
> style. Is that correct?
>
> In the Sourceforge admin interface I can see that there are quite some
> developers registered. I will clean this list now. If anyone feels
> they should remain developer on the project don't hesitate to notify
> me. My intention is to be able to get a better control of what is
> being delivered to trunk in order to avoid to much diversion.
> Therefore the standard way to submit a patch to JSynthLib should be
> through the patch interface on Sourceforge. I will then handle the
> merging and so on.
>
> BR
> /Pascal
>
Hi Pascal,
Sorry for not getting back to you sooner about adding Junit support to
the Ant script in my branch. I was planning on adding something like the
following:
<property name='reports' location='reports'/>
<!-- ******************************************************************* -->
<!-- * JUnit * -->
<!-- ******************************************************************* -->
<target name='init-tests' description='Create the test reports directory' depends='build'>
<mkdir dir='${reports}'/>
</target>
<target name='run-tests' description='Run the tests' depends='init-tests'>
<junit printsummary='on' fork='on'>
<classpath>
<path refid='classpath'/>
<path location='${bin}'/>
</classpath>
<formatter type='plain' usefile='yes'/>
<formatter type='xml' usefile='yes'/>
<batchtest todir='${reports}'>
<fileset dir='${src}' includes='**/*Test.java' excludes='**/Abstract*Test.java'/>
</batchtest>
</junit>
</target>
<target name='clean-tests' description='Remove the test reports directory'>
<delete dir='${reports}'/>
</target>
Regards,
Chris
|
|
From: Packe <pa...@ya...> - 2013-11-05 19:08:27
|
Hi again, I've been away for a week and didn't have time to work on this. I will now start the work to port the project to Maven. Chris, did you have the time to look at what you have done in the build.xml file in your refactor branch? From what I could see you just cleaned it up and added PMD and check style. Is that correct? In the Sourceforge admin interface I can see that there are quite some developers registered. I will clean this list now. If anyone feels they should remain developer on the project don't hesitate to notify me. My intention is to be able to get a better control of what is being delivered to trunk in order to avoid to much diversion. Therefore the standard way to submit a patch to JSynthLib should be through the patch interface on Sourceforge. I will then handle the merging and so on. BR /Pascal 22 okt 2013 kl. 11:06 skrev Frankie Fisher <jsy...@te...>: > There is some stuff in the old user guide here: > http://sourceforge.net/p/jsynthlib/wiki/User%20Guide/ > > > On 22/10/2013 09:47, Packe wrote: >> terrorise.me.uk> >> To: Frankie Fisher <jsy...@te...>, >> "chr...@ch..." <chr...@ch...> >> X-Mailer: Apple Mail (2.1510) >> >> Hi, >> >> Frankie, thanks for the feedback. I have made a fix for Mac OS X which should work out of the box so there shouldn't actually need to be any Mac specific docs at all anymore. It would be great if someone else had the time to test the solution on their Mac system as I have only had the chance to run this on my MacBook Pro with OS X 10.8.5. Thorsten Klose said he would like to test it but I haven't heard form him since so I don't know if he found any issues. >> >> If there is nobody who can do anymore Mac OS X testing I think I'll have to stick to executing test cases on my local machine… >> >> I'l search for Mac OS X documentation but if you know any hidden documents or so I would be grateful for suggestions. >> >> Chris, great to hear that you are willing to help me out on the restructuring branch! As I said in my mail below I think the most important part is to get the Ant script and test cases up and running. For my osxmidi4j project I set up an automatic build chain hosted by Cloudbees (https://locurasoft.ci.cloudbees.com/job/osxmidi4j/) and I'm thinking of doing the same with this project. Please get back to me once you have checked what you did so that we can discuss what should be merged now and what can be merged after the release. >> >> BR >> /Pascal >> >> 21 okt 2013 kl. 10:46 skrev Frankie Fisher <jsy...@te...>: >> >>> We've got a release that is kind of ready to go that has multiple new >>> synths since the last official release which was about 5 years ago. >>> There was pretty much 1 reported issue that could block a release, which >>> was that JSL hasn't worked on some versions of macs. There recently were >>> some patches that went in to fix mac support, so provided those stand up >>> to a bit of testing, then the release is probably good to go. The >>> documentation will need to be updated to state how to make it work on >>> Macs (or to state that it should work out of the box on whatever >>> versions of OS X). There is a lot of old documentation describing how to >>> set up midi providers for java, so some of that might need to get updated. >>> >>> >>> On 20/10/2013 21:09, Packe wrote: >>>> Hi again, >>>> >>>> I have now been given admin rights to this project (thanks Joachim). What I understood from Joachim is that there is no active maintainer of the JSynthlib project today. So I'm now willing to assume that role. >>>> >>>> I've been sketching on sort of a roadmap and would like to get some feedback: >>>> >>>> Change project structure and fix ant script >>>> Create system test cases to secure basic driver functionality - assuming that the current drivers work as expected... >>>> Fix existing bugs (can those of you who know any bugs please report them on SF?) >>>> 1.0 release - As discussed in this thread: 10th anniversary >>>> I'm hoping to do that this year or early next >>>> Once the 1.0 release is done I think focus should be on merging the refactor branch to trunk and straighten up the API >>>> >>>> If anybody still believes in this project help is very much appreciated! >>>> >>>> One thing though, I think a problem previously has been that code has been delivered without prior review. Therefore I would like patches being submitted through the patch page on SF instead of direct merges to trunk. I (and possibly another volunteer) will monitor these patches and provide feedback/merge the patches as they are submitted. >>>> >>>> I'll wait one week from now to let you get back with your thoughts before starting any work at all. >>>> >>>> Chris, would you be able to explain what you did for changes to the ant script on the refactor branch? >>>> >>>> BR >>>> /Pascal >>>> >>>> 17 okt 2013 kl. 17:07 skrev Packe <pa...@ya...>: >>>> >>>>> Hi Chris! >>>>> >>>>> I understand your concerns regarding the status of this project. I found it about 6 months ago while I was creating something similar (from scratch..) and thought it would be worth a try to implement drivers for my synthesizers using JSynthlib instead, and it actually was… >>>>> >>>>> What worries me the most is that there doesn't seem to exist any test cases. Especially not for the drivers. Therefore it's extremely risky to do major changes to core. >>>>> >>>>> I would like to perform the improved folder structure change first, then create some test cases. It should be possible to automatically generate test cases by moving around controllers and listening to the MIDI output. >>>>> >>>>> Once that is done I think it would be appropriate to do the (very much needed) cleaning of core. >>>>> >>>>> I have seen too many "complete rewrite" projects just going nowhere. Therefore I think this project is a good start. Even if it is really messy it has one advantage: it works (at least for the synthesizers I own). >>>>> >>>>> BR >>>>> /Pascal >>>>> >>>>> 17 okt 2013 kl. 15:58 skrev "chr...@ch..." <chr...@ch...>: >>>>> >>>>>> Hi Pascal, >>>>>> >>>>>> Packe [pa...@ya...] wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Yes, I have had a look at the refactor branch. My concern about that branch >>>>>>> was that it didn't seem active and that in some mailing list conversation >>>>>>> there was very high aims for what was going to be developed in that branch. >>>>>>> >>>>>> I got to a point with my refactoring where I would have liked some feedback and >>>>>> an indication whether the work was likely to be merged back into trunk. The lack >>>>>> of feedback and list activity in general lead me to the conclusion that >>>>>> JSynthLib is an orphaned project and that I should focus my efforts elsewhere. >>>>>> >>>>>> At the point I left it, the code in my branch compiles and loads the files >>>>>> created in the currently released version. I was somewhat dependent on people >>>>>> testing, since I didn't have any supported synths to test an existing driver. >>>>>> >>>>>>> Therefore I felt that it would take quite a long time to merge those changes >>>>>>> (which seems very good btw) to trunk. >>>>>>> >>>>>> Had there been any activity in the trunk, then I would have merged or ported >>>>>> those changes. From what I can see, there still hasn't been any activity on the >>>>>> trunk since I started my branch. >>>>>> >>>>>>> Regarding Ant vs Maven vs whatever I don't really have a firm opinion. >>>>>>> >>>>>> It's not something I have particularly strong feelings about - I'd be much more >>>>>> concerned in a project like JSynthLib if it mandated the use of a particular >>>>>> IDE. I vaguely recall someone almost doing this by trying to use the GUI builder >>>>>> in NetBeans many years ago. That was when the project seemed more active and I >>>>>> first considered trying to contribute to it - the attempt to enforce NetBean's >>>>>> GUI builder is what put me off. >>>>>> >>>>>>> The benefit of Maven is that it has a resource folder right inside src which >>>>>>> is handy to save resources such as images in. As you mention it is also neat >>>>>>> to handle dependencies. >>>>>>> >>>>>> Maven seems to have adopted existing best practices in this regard. >>>>>> >>>>>>> What would you say is left before we can merge the refactor branch to trunk? >>>>>>> >>>>>> I suspect that my branch is at least as stable as trunk, but with the beginnings >>>>>> of a major API cleanup. It looks like there was a clear design and decent >>>>>> encapsulation at some point, but that they have been broken over the years. >>>>>> Cleaning this up further will be a lot of work, and I wonder if it may not be >>>>>> better to start from scratch with the core, and just using the existing drivers >>>>>> as a form of documentation for new ones. >>>>>> >>>>>>> BR >>>>>>> /Pascal >>>>>>> >>>>>> Regards, >>>>>> >>>>>> Chris >>>>> ------------------------------------------------------------------------------ >>>>> October Webinars: Code for Performance >>>>> Free Intel webinars can help you accelerate application performance. >>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >>>>> the latest Intel processors and coprocessors. See abstracts and register > >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Jsynthlib-devel mailing list >>>>> Jsy...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>>> ------------------------------------------------------------------------------ >>>> October Webinars: Code for Performance >>>> Free Intel webinars can help you accelerate application performance. >>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >>>> the latest Intel processors and coprocessors. See abstracts and register > >>>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Jsynthlib-devel mailing list >>>> Jsy...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >>> the latest Intel processors and coprocessors. See abstracts and register > >>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Jsynthlib-devel mailing list >>> Jsy...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Frankie F. <jsy...@te...> - 2013-10-22 09:06:41
|
There is some stuff in the old user guide here: http://sourceforge.net/p/jsynthlib/wiki/User%20Guide/ On 22/10/2013 09:47, Packe wrote: > terrorise.me.uk> > To: Frankie Fisher <jsy...@te...>, > "chr...@ch..." <chr...@ch...> > X-Mailer: Apple Mail (2.1510) > > Hi, > > Frankie, thanks for the feedback. I have made a fix for Mac OS X which should work out of the box so there shouldn't actually need to be any Mac specific docs at all anymore. It would be great if someone else had the time to test the solution on their Mac system as I have only had the chance to run this on my MacBook Pro with OS X 10.8.5. Thorsten Klose said he would like to test it but I haven't heard form him since so I don't know if he found any issues. > > If there is nobody who can do anymore Mac OS X testing I think I'll have to stick to executing test cases on my local machine… > > I'l search for Mac OS X documentation but if you know any hidden documents or so I would be grateful for suggestions. > > Chris, great to hear that you are willing to help me out on the restructuring branch! As I said in my mail below I think the most important part is to get the Ant script and test cases up and running. For my osxmidi4j project I set up an automatic build chain hosted by Cloudbees (https://locurasoft.ci.cloudbees.com/job/osxmidi4j/) and I'm thinking of doing the same with this project. Please get back to me once you have checked what you did so that we can discuss what should be merged now and what can be merged after the release. > > BR > /Pascal > > 21 okt 2013 kl. 10:46 skrev Frankie Fisher <jsy...@te...>: > >> We've got a release that is kind of ready to go that has multiple new >> synths since the last official release which was about 5 years ago. >> There was pretty much 1 reported issue that could block a release, which >> was that JSL hasn't worked on some versions of macs. There recently were >> some patches that went in to fix mac support, so provided those stand up >> to a bit of testing, then the release is probably good to go. The >> documentation will need to be updated to state how to make it work on >> Macs (or to state that it should work out of the box on whatever >> versions of OS X). There is a lot of old documentation describing how to >> set up midi providers for java, so some of that might need to get updated. >> >> >> On 20/10/2013 21:09, Packe wrote: >>> Hi again, >>> >>> I have now been given admin rights to this project (thanks Joachim). What I understood from Joachim is that there is no active maintainer of the JSynthlib project today. So I'm now willing to assume that role. >>> >>> I've been sketching on sort of a roadmap and would like to get some feedback: >>> >>> Change project structure and fix ant script >>> Create system test cases to secure basic driver functionality - assuming that the current drivers work as expected... >>> Fix existing bugs (can those of you who know any bugs please report them on SF?) >>> 1.0 release - As discussed in this thread: 10th anniversary >>> I'm hoping to do that this year or early next >>> Once the 1.0 release is done I think focus should be on merging the refactor branch to trunk and straighten up the API >>> >>> If anybody still believes in this project help is very much appreciated! >>> >>> One thing though, I think a problem previously has been that code has been delivered without prior review. Therefore I would like patches being submitted through the patch page on SF instead of direct merges to trunk. I (and possibly another volunteer) will monitor these patches and provide feedback/merge the patches as they are submitted. >>> >>> I'll wait one week from now to let you get back with your thoughts before starting any work at all. >>> >>> Chris, would you be able to explain what you did for changes to the ant script on the refactor branch? >>> >>> BR >>> /Pascal >>> >>> 17 okt 2013 kl. 17:07 skrev Packe <pa...@ya...>: >>> >>>> Hi Chris! >>>> >>>> I understand your concerns regarding the status of this project. I found it about 6 months ago while I was creating something similar (from scratch..) and thought it would be worth a try to implement drivers for my synthesizers using JSynthlib instead, and it actually was… >>>> >>>> What worries me the most is that there doesn't seem to exist any test cases. Especially not for the drivers. Therefore it's extremely risky to do major changes to core. >>>> >>>> I would like to perform the improved folder structure change first, then create some test cases. It should be possible to automatically generate test cases by moving around controllers and listening to the MIDI output. >>>> >>>> Once that is done I think it would be appropriate to do the (very much needed) cleaning of core. >>>> >>>> I have seen too many "complete rewrite" projects just going nowhere. Therefore I think this project is a good start. Even if it is really messy it has one advantage: it works (at least for the synthesizers I own). >>>> >>>> BR >>>> /Pascal >>>> >>>> 17 okt 2013 kl. 15:58 skrev "chr...@ch..." <chr...@ch...>: >>>> >>>>> Hi Pascal, >>>>> >>>>> Packe [pa...@ya...] wrote: >>>>>> Hi, >>>>>> >>>>>> Yes, I have had a look at the refactor branch. My concern about that branch >>>>>> was that it didn't seem active and that in some mailing list conversation >>>>>> there was very high aims for what was going to be developed in that branch. >>>>>> >>>>> I got to a point with my refactoring where I would have liked some feedback and >>>>> an indication whether the work was likely to be merged back into trunk. The lack >>>>> of feedback and list activity in general lead me to the conclusion that >>>>> JSynthLib is an orphaned project and that I should focus my efforts elsewhere. >>>>> >>>>> At the point I left it, the code in my branch compiles and loads the files >>>>> created in the currently released version. I was somewhat dependent on people >>>>> testing, since I didn't have any supported synths to test an existing driver. >>>>> >>>>>> Therefore I felt that it would take quite a long time to merge those changes >>>>>> (which seems very good btw) to trunk. >>>>>> >>>>> Had there been any activity in the trunk, then I would have merged or ported >>>>> those changes. From what I can see, there still hasn't been any activity on the >>>>> trunk since I started my branch. >>>>> >>>>>> Regarding Ant vs Maven vs whatever I don't really have a firm opinion. >>>>>> >>>>> It's not something I have particularly strong feelings about - I'd be much more >>>>> concerned in a project like JSynthLib if it mandated the use of a particular >>>>> IDE. I vaguely recall someone almost doing this by trying to use the GUI builder >>>>> in NetBeans many years ago. That was when the project seemed more active and I >>>>> first considered trying to contribute to it - the attempt to enforce NetBean's >>>>> GUI builder is what put me off. >>>>> >>>>>> The benefit of Maven is that it has a resource folder right inside src which >>>>>> is handy to save resources such as images in. As you mention it is also neat >>>>>> to handle dependencies. >>>>>> >>>>> Maven seems to have adopted existing best practices in this regard. >>>>> >>>>>> What would you say is left before we can merge the refactor branch to trunk? >>>>>> >>>>> I suspect that my branch is at least as stable as trunk, but with the beginnings >>>>> of a major API cleanup. It looks like there was a clear design and decent >>>>> encapsulation at some point, but that they have been broken over the years. >>>>> Cleaning this up further will be a lot of work, and I wonder if it may not be >>>>> better to start from scratch with the core, and just using the existing drivers >>>>> as a form of documentation for new ones. >>>>> >>>>>> BR >>>>>> /Pascal >>>>>> >>>>> Regards, >>>>> >>>>> Chris >>>> ------------------------------------------------------------------------------ >>>> October Webinars: Code for Performance >>>> Free Intel webinars can help you accelerate application performance. >>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >>>> the latest Intel processors and coprocessors. See abstracts and register > >>>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Jsynthlib-devel mailing list >>>> Jsy...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >>> the latest Intel processors and coprocessors. See abstracts and register > >>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Jsynthlib-devel mailing list >>> Jsy...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jsynthlib-devel mailing list >> Jsy...@li... >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: Packe <pa...@ya...> - 2013-10-22 08:47:22
|
terrorise.me.uk> To: Frankie Fisher <jsy...@te...>, "chr...@ch..." <chr...@ch...> X-Mailer: Apple Mail (2.1510) Hi, Frankie, thanks for the feedback. I have made a fix for Mac OS X which should work out of the box so there shouldn't actually need to be any Mac specific docs at all anymore. It would be great if someone else had the time to test the solution on their Mac system as I have only had the chance to run this on my MacBook Pro with OS X 10.8.5. Thorsten Klose said he would like to test it but I haven't heard form him since so I don't know if he found any issues. If there is nobody who can do anymore Mac OS X testing I think I'll have to stick to executing test cases on my local machine… I'l search for Mac OS X documentation but if you know any hidden documents or so I would be grateful for suggestions. Chris, great to hear that you are willing to help me out on the restructuring branch! As I said in my mail below I think the most important part is to get the Ant script and test cases up and running. For my osxmidi4j project I set up an automatic build chain hosted by Cloudbees (https://locurasoft.ci.cloudbees.com/job/osxmidi4j/) and I'm thinking of doing the same with this project. Please get back to me once you have checked what you did so that we can discuss what should be merged now and what can be merged after the release. BR /Pascal 21 okt 2013 kl. 10:46 skrev Frankie Fisher <jsy...@te...>: > We've got a release that is kind of ready to go that has multiple new > synths since the last official release which was about 5 years ago. > There was pretty much 1 reported issue that could block a release, which > was that JSL hasn't worked on some versions of macs. There recently were > some patches that went in to fix mac support, so provided those stand up > to a bit of testing, then the release is probably good to go. The > documentation will need to be updated to state how to make it work on > Macs (or to state that it should work out of the box on whatever > versions of OS X). There is a lot of old documentation describing how to > set up midi providers for java, so some of that might need to get updated. > > > On 20/10/2013 21:09, Packe wrote: >> Hi again, >> >> I have now been given admin rights to this project (thanks Joachim). What I understood from Joachim is that there is no active maintainer of the JSynthlib project today. So I'm now willing to assume that role. >> >> I've been sketching on sort of a roadmap and would like to get some feedback: >> >> Change project structure and fix ant script >> Create system test cases to secure basic driver functionality - assuming that the current drivers work as expected... >> Fix existing bugs (can those of you who know any bugs please report them on SF?) >> 1.0 release - As discussed in this thread: 10th anniversary >> I'm hoping to do that this year or early next >> Once the 1.0 release is done I think focus should be on merging the refactor branch to trunk and straighten up the API >> >> If anybody still believes in this project help is very much appreciated! >> >> One thing though, I think a problem previously has been that code has been delivered without prior review. Therefore I would like patches being submitted through the patch page on SF instead of direct merges to trunk. I (and possibly another volunteer) will monitor these patches and provide feedback/merge the patches as they are submitted. >> >> I'll wait one week from now to let you get back with your thoughts before starting any work at all. >> >> Chris, would you be able to explain what you did for changes to the ant script on the refactor branch? >> >> BR >> /Pascal >> >> 17 okt 2013 kl. 17:07 skrev Packe <pa...@ya...>: >> >>> Hi Chris! >>> >>> I understand your concerns regarding the status of this project. I found it about 6 months ago while I was creating something similar (from scratch..) and thought it would be worth a try to implement drivers for my synthesizers using JSynthlib instead, and it actually was… >>> >>> What worries me the most is that there doesn't seem to exist any test cases. Especially not for the drivers. Therefore it's extremely risky to do major changes to core. >>> >>> I would like to perform the improved folder structure change first, then create some test cases. It should be possible to automatically generate test cases by moving around controllers and listening to the MIDI output. >>> >>> Once that is done I think it would be appropriate to do the (very much needed) cleaning of core. >>> >>> I have seen too many "complete rewrite" projects just going nowhere. Therefore I think this project is a good start. Even if it is really messy it has one advantage: it works (at least for the synthesizers I own). >>> >>> BR >>> /Pascal >>> >>> 17 okt 2013 kl. 15:58 skrev "chr...@ch..." <chr...@ch...>: >>> >>>> Hi Pascal, >>>> >>>> Packe [pa...@ya...] wrote: >>>>> Hi, >>>>> >>>>> Yes, I have had a look at the refactor branch. My concern about that branch >>>>> was that it didn't seem active and that in some mailing list conversation >>>>> there was very high aims for what was going to be developed in that branch. >>>>> >>>> I got to a point with my refactoring where I would have liked some feedback and >>>> an indication whether the work was likely to be merged back into trunk. The lack >>>> of feedback and list activity in general lead me to the conclusion that >>>> JSynthLib is an orphaned project and that I should focus my efforts elsewhere. >>>> >>>> At the point I left it, the code in my branch compiles and loads the files >>>> created in the currently released version. I was somewhat dependent on people >>>> testing, since I didn't have any supported synths to test an existing driver. >>>> >>>>> Therefore I felt that it would take quite a long time to merge those changes >>>>> (which seems very good btw) to trunk. >>>>> >>>> Had there been any activity in the trunk, then I would have merged or ported >>>> those changes. From what I can see, there still hasn't been any activity on the >>>> trunk since I started my branch. >>>> >>>>> Regarding Ant vs Maven vs whatever I don't really have a firm opinion. >>>>> >>>> It's not something I have particularly strong feelings about - I'd be much more >>>> concerned in a project like JSynthLib if it mandated the use of a particular >>>> IDE. I vaguely recall someone almost doing this by trying to use the GUI builder >>>> in NetBeans many years ago. That was when the project seemed more active and I >>>> first considered trying to contribute to it - the attempt to enforce NetBean's >>>> GUI builder is what put me off. >>>> >>>>> The benefit of Maven is that it has a resource folder right inside src which >>>>> is handy to save resources such as images in. As you mention it is also neat >>>>> to handle dependencies. >>>>> >>>> Maven seems to have adopted existing best practices in this regard. >>>> >>>>> What would you say is left before we can merge the refactor branch to trunk? >>>>> >>>> I suspect that my branch is at least as stable as trunk, but with the beginnings >>>> of a major API cleanup. It looks like there was a clear design and decent >>>> encapsulation at some point, but that they have been broken over the years. >>>> Cleaning this up further will be a lot of work, and I wonder if it may not be >>>> better to start from scratch with the core, and just using the existing drivers >>>> as a form of documentation for new ones. >>>> >>>>> BR >>>>> /Pascal >>>>> >>>> Regards, >>>> >>>> Chris >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >>> the latest Intel processors and coprocessors. See abstracts and register > >>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Jsynthlib-devel mailing list >>> Jsy...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jsynthlib-devel mailing list >> Jsy...@li... >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: <chr...@ch...>
<chr...@ch...> - 2013-10-21 09:23:50
|
Packe [pa...@ya...] wrote: > > Hi again, > > I have now been given admin rights to this project (thanks Joachim). What I understood from Joachim is that there is no active maintainer of the JSynthlib project today. So I'm now willing to assume that role. > Hi Pascal, Glad to see that you're prepared to revive the project! > > I've been sketching on sort of a roadmap and would like to get some feedback: > > Change project structure and fix ant script > Create system test cases to secure basic driver functionality - assuming that the current drivers work as expected... > Fix existing bugs (can those of you who know any bugs please report them on SF?) > 1.0 release - As discussed in this thread: 10th anniversary > I'm hoping to do that this year or early next > Once the 1.0 release is done I think focus should be on merging the refactor branch to trunk and straighten up the API > My plans for the refactoring branch were to start by modularising the low level MIDI code in the core. Basically, I wanted to produce an interface and implementation class that defined the operations required for System Exclusive messages. For unit testing it would be good to have a dummy MIDI driver that could act as a mock - I don't know whether something like this already exists in another project, but it would be worth checking. I then wanted to produce interfaces for the various higher level operations that a patch editor and librarian performs, and to ensure they were free of GUI code to enable easy unit and integration testing. Then I wanted to look at the GUI related features that the drivers need to have implemented in the core. Finally, I wanted to work through each driver and reduce them to the minimum amount of code possible, with a separate class or classes for the MIDI/SysEx calls that contained no calls to the GUI parts of the core. As with the core, I wanted to have the GUI code for each driver in separate classes to the code that deals with patch data to enable automated testing. > > If anybody still believes in this project help is very much appreciated! > If my ideas outlined above are similar to yours, then I would be very happy to become a contributor to the project. > > One thing though, I think a problem previously has been that code has been delivered without prior review. Therefore I would like patches being submitted through the patch page on SF instead of direct merges to trunk. I (and possibly another volunteer) will monitor these patches and provide feedback/merge the patches as they are submitted. > That sounds very sensible. I suspect that what has happened in the past, is that people have written a synth driver and where they needed access to something in the core they have broken the encapsulation rather than extending a clearly defined API. There also seems to have been a lot of cutting and pasting of code between drivers, where it would have been better to reduce duplication by again extending the core API. > I'll wait one week from now to let you get back with your thoughts before starting any work at all. > > Chris, would you be able to explain what you did for changes to the ant script on the refactor branch? > I'll make time this week to have a look again at my branch. I can add support for unit testing to the Ant script, as well as support for static analysers such as Checkstyle and PMD (I may have already added those). > > BR > /Pascal > Regards, Chris |
|
From: Frankie F. <jsy...@te...> - 2013-10-21 08:46:39
|
We've got a release that is kind of ready to go that has multiple new synths since the last official release which was about 5 years ago. There was pretty much 1 reported issue that could block a release, which was that JSL hasn't worked on some versions of macs. There recently were some patches that went in to fix mac support, so provided those stand up to a bit of testing, then the release is probably good to go. The documentation will need to be updated to state how to make it work on Macs (or to state that it should work out of the box on whatever versions of OS X). There is a lot of old documentation describing how to set up midi providers for java, so some of that might need to get updated. On 20/10/2013 21:09, Packe wrote: > Hi again, > > I have now been given admin rights to this project (thanks Joachim). What I understood from Joachim is that there is no active maintainer of the JSynthlib project today. So I'm now willing to assume that role. > > I've been sketching on sort of a roadmap and would like to get some feedback: > > Change project structure and fix ant script > Create system test cases to secure basic driver functionality - assuming that the current drivers work as expected... > Fix existing bugs (can those of you who know any bugs please report them on SF?) > 1.0 release - As discussed in this thread: 10th anniversary > I'm hoping to do that this year or early next > Once the 1.0 release is done I think focus should be on merging the refactor branch to trunk and straighten up the API > > If anybody still believes in this project help is very much appreciated! > > One thing though, I think a problem previously has been that code has been delivered without prior review. Therefore I would like patches being submitted through the patch page on SF instead of direct merges to trunk. I (and possibly another volunteer) will monitor these patches and provide feedback/merge the patches as they are submitted. > > I'll wait one week from now to let you get back with your thoughts before starting any work at all. > > Chris, would you be able to explain what you did for changes to the ant script on the refactor branch? > > BR > /Pascal > > 17 okt 2013 kl. 17:07 skrev Packe <pa...@ya...>: > >> Hi Chris! >> >> I understand your concerns regarding the status of this project. I found it about 6 months ago while I was creating something similar (from scratch..) and thought it would be worth a try to implement drivers for my synthesizers using JSynthlib instead, and it actually was… >> >> What worries me the most is that there doesn't seem to exist any test cases. Especially not for the drivers. Therefore it's extremely risky to do major changes to core. >> >> I would like to perform the improved folder structure change first, then create some test cases. It should be possible to automatically generate test cases by moving around controllers and listening to the MIDI output. >> >> Once that is done I think it would be appropriate to do the (very much needed) cleaning of core. >> >> I have seen too many "complete rewrite" projects just going nowhere. Therefore I think this project is a good start. Even if it is really messy it has one advantage: it works (at least for the synthesizers I own). >> >> BR >> /Pascal >> >> 17 okt 2013 kl. 15:58 skrev "chr...@ch..." <chr...@ch...>: >> >>> Hi Pascal, >>> >>> Packe [pa...@ya...] wrote: >>>> Hi, >>>> >>>> Yes, I have had a look at the refactor branch. My concern about that branch >>>> was that it didn't seem active and that in some mailing list conversation >>>> there was very high aims for what was going to be developed in that branch. >>>> >>> I got to a point with my refactoring where I would have liked some feedback and >>> an indication whether the work was likely to be merged back into trunk. The lack >>> of feedback and list activity in general lead me to the conclusion that >>> JSynthLib is an orphaned project and that I should focus my efforts elsewhere. >>> >>> At the point I left it, the code in my branch compiles and loads the files >>> created in the currently released version. I was somewhat dependent on people >>> testing, since I didn't have any supported synths to test an existing driver. >>> >>>> Therefore I felt that it would take quite a long time to merge those changes >>>> (which seems very good btw) to trunk. >>>> >>> Had there been any activity in the trunk, then I would have merged or ported >>> those changes. From what I can see, there still hasn't been any activity on the >>> trunk since I started my branch. >>> >>>> Regarding Ant vs Maven vs whatever I don't really have a firm opinion. >>>> >>> It's not something I have particularly strong feelings about - I'd be much more >>> concerned in a project like JSynthLib if it mandated the use of a particular >>> IDE. I vaguely recall someone almost doing this by trying to use the GUI builder >>> in NetBeans many years ago. That was when the project seemed more active and I >>> first considered trying to contribute to it - the attempt to enforce NetBean's >>> GUI builder is what put me off. >>> >>>> The benefit of Maven is that it has a resource folder right inside src which >>>> is handy to save resources such as images in. As you mention it is also neat >>>> to handle dependencies. >>>> >>> Maven seems to have adopted existing best practices in this regard. >>> >>>> What would you say is left before we can merge the refactor branch to trunk? >>>> >>> I suspect that my branch is at least as stable as trunk, but with the beginnings >>> of a major API cleanup. It looks like there was a clear design and decent >>> encapsulation at some point, but that they have been broken over the years. >>> Cleaning this up further will be a lot of work, and I wonder if it may not be >>> better to start from scratch with the core, and just using the existing drivers >>> as a form of documentation for new ones. >>> >>>> BR >>>> /Pascal >>>> >>> Regards, >>> >>> Chris >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jsynthlib-devel mailing list >> Jsy...@li... >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: Packe <pa...@ya...> - 2013-10-20 20:09:35
|
Hi again, I have now been given admin rights to this project (thanks Joachim). What I understood from Joachim is that there is no active maintainer of the JSynthlib project today. So I'm now willing to assume that role. I've been sketching on sort of a roadmap and would like to get some feedback: Change project structure and fix ant script Create system test cases to secure basic driver functionality - assuming that the current drivers work as expected... Fix existing bugs (can those of you who know any bugs please report them on SF?) 1.0 release - As discussed in this thread: 10th anniversary I'm hoping to do that this year or early next Once the 1.0 release is done I think focus should be on merging the refactor branch to trunk and straighten up the API If anybody still believes in this project help is very much appreciated! One thing though, I think a problem previously has been that code has been delivered without prior review. Therefore I would like patches being submitted through the patch page on SF instead of direct merges to trunk. I (and possibly another volunteer) will monitor these patches and provide feedback/merge the patches as they are submitted. I'll wait one week from now to let you get back with your thoughts before starting any work at all. Chris, would you be able to explain what you did for changes to the ant script on the refactor branch? BR /Pascal 17 okt 2013 kl. 17:07 skrev Packe <pa...@ya...>: > Hi Chris! > > I understand your concerns regarding the status of this project. I found it about 6 months ago while I was creating something similar (from scratch..) and thought it would be worth a try to implement drivers for my synthesizers using JSynthlib instead, and it actually was… > > What worries me the most is that there doesn't seem to exist any test cases. Especially not for the drivers. Therefore it's extremely risky to do major changes to core. > > I would like to perform the improved folder structure change first, then create some test cases. It should be possible to automatically generate test cases by moving around controllers and listening to the MIDI output. > > Once that is done I think it would be appropriate to do the (very much needed) cleaning of core. > > I have seen too many "complete rewrite" projects just going nowhere. Therefore I think this project is a good start. Even if it is really messy it has one advantage: it works (at least for the synthesizers I own). > > BR > /Pascal > > 17 okt 2013 kl. 15:58 skrev "chr...@ch..." <chr...@ch...>: > >> Hi Pascal, >> >> Packe [pa...@ya...] wrote: >>> >>> Hi, >>> >>> Yes, I have had a look at the refactor branch. My concern about that branch >>> was that it didn't seem active and that in some mailing list conversation >>> there was very high aims for what was going to be developed in that branch. >>> >> >> I got to a point with my refactoring where I would have liked some feedback and >> an indication whether the work was likely to be merged back into trunk. The lack >> of feedback and list activity in general lead me to the conclusion that >> JSynthLib is an orphaned project and that I should focus my efforts elsewhere. >> >> At the point I left it, the code in my branch compiles and loads the files >> created in the currently released version. I was somewhat dependent on people >> testing, since I didn't have any supported synths to test an existing driver. >> >>> >>> Therefore I felt that it would take quite a long time to merge those changes >>> (which seems very good btw) to trunk. >>> >> >> Had there been any activity in the trunk, then I would have merged or ported >> those changes. From what I can see, there still hasn't been any activity on the >> trunk since I started my branch. >> >>> >>> Regarding Ant vs Maven vs whatever I don't really have a firm opinion. >>> >> >> It's not something I have particularly strong feelings about - I'd be much more >> concerned in a project like JSynthLib if it mandated the use of a particular >> IDE. I vaguely recall someone almost doing this by trying to use the GUI builder >> in NetBeans many years ago. That was when the project seemed more active and I >> first considered trying to contribute to it - the attempt to enforce NetBean's >> GUI builder is what put me off. >> >>> >>> The benefit of Maven is that it has a resource folder right inside src which >>> is handy to save resources such as images in. As you mention it is also neat >>> to handle dependencies. >>> >> >> Maven seems to have adopted existing best practices in this regard. >> >>> >>> What would you say is left before we can merge the refactor branch to trunk? >>> >> >> I suspect that my branch is at least as stable as trunk, but with the beginnings >> of a major API cleanup. It looks like there was a clear design and decent >> encapsulation at some point, but that they have been broken over the years. >> Cleaning this up further will be a lot of work, and I wonder if it may not be >> better to start from scratch with the core, and just using the existing drivers >> as a form of documentation for new ones. >> >>> BR >>> /Pascal >>> >> >> Regards, >> >> Chris > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: Packe <pa...@ya...> - 2013-10-17 15:07:45
|
Hi Chris! I understand your concerns regarding the status of this project. I found it about 6 months ago while I was creating something similar (from scratch..) and thought it would be worth a try to implement drivers for my synthesizers using JSynthlib instead, and it actually was… What worries me the most is that there doesn't seem to exist any test cases. Especially not for the drivers. Therefore it's extremely risky to do major changes to core. I would like to perform the improved folder structure change first, then create some test cases. It should be possible to automatically generate test cases by moving around controllers and listening to the MIDI output. Once that is done I think it would be appropriate to do the (very much needed) cleaning of core. I have seen too many "complete rewrite" projects just going nowhere. Therefore I think this project is a good start. Even if it is really messy it has one advantage: it works (at least for the synthesizers I own). BR /Pascal 17 okt 2013 kl. 15:58 skrev "chr...@ch..." <chr...@ch...>: > Hi Pascal, > > Packe [pa...@ya...] wrote: >> >> Hi, >> >> Yes, I have had a look at the refactor branch. My concern about that branch >> was that it didn't seem active and that in some mailing list conversation >> there was very high aims for what was going to be developed in that branch. >> > > I got to a point with my refactoring where I would have liked some feedback and > an indication whether the work was likely to be merged back into trunk. The lack > of feedback and list activity in general lead me to the conclusion that > JSynthLib is an orphaned project and that I should focus my efforts elsewhere. > > At the point I left it, the code in my branch compiles and loads the files > created in the currently released version. I was somewhat dependent on people > testing, since I didn't have any supported synths to test an existing driver. > >> >> Therefore I felt that it would take quite a long time to merge those changes >> (which seems very good btw) to trunk. >> > > Had there been any activity in the trunk, then I would have merged or ported > those changes. From what I can see, there still hasn't been any activity on the > trunk since I started my branch. > >> >> Regarding Ant vs Maven vs whatever I don't really have a firm opinion. >> > > It's not something I have particularly strong feelings about - I'd be much more > concerned in a project like JSynthLib if it mandated the use of a particular > IDE. I vaguely recall someone almost doing this by trying to use the GUI builder > in NetBeans many years ago. That was when the project seemed more active and I > first considered trying to contribute to it - the attempt to enforce NetBean's > GUI builder is what put me off. > >> >> The benefit of Maven is that it has a resource folder right inside src which >> is handy to save resources such as images in. As you mention it is also neat >> to handle dependencies. >> > > Maven seems to have adopted existing best practices in this regard. > >> >> What would you say is left before we can merge the refactor branch to trunk? >> > > I suspect that my branch is at least as stable as trunk, but with the beginnings > of a major API cleanup. It looks like there was a clear design and decent > encapsulation at some point, but that they have been broken over the years. > Cleaning this up further will be a lot of work, and I wonder if it may not be > better to start from scratch with the core, and just using the existing drivers > as a form of documentation for new ones. > >> BR >> /Pascal >> > > Regards, > > Chris |
|
From: <chr...@ch...>
<chr...@ch...> - 2013-10-17 13:58:37
|
Hi Pascal, Packe [pa...@ya...] wrote: > > Hi, > > Yes, I have had a look at the refactor branch. My concern about that branch > was that it didn't seem active and that in some mailing list conversation > there was very high aims for what was going to be developed in that branch. > I got to a point with my refactoring where I would have liked some feedback and an indication whether the work was likely to be merged back into trunk. The lack of feedback and list activity in general lead me to the conclusion that JSynthLib is an orphaned project and that I should focus my efforts elsewhere. At the point I left it, the code in my branch compiles and loads the files created in the currently released version. I was somewhat dependent on people testing, since I didn't have any supported synths to test an existing driver. > > Therefore I felt that it would take quite a long time to merge those changes > (which seems very good btw) to trunk. > Had there been any activity in the trunk, then I would have merged or ported those changes. From what I can see, there still hasn't been any activity on the trunk since I started my branch. > > Regarding Ant vs Maven vs whatever I don't really have a firm opinion. > It's not something I have particularly strong feelings about - I'd be much more concerned in a project like JSynthLib if it mandated the use of a particular IDE. I vaguely recall someone almost doing this by trying to use the GUI builder in NetBeans many years ago. That was when the project seemed more active and I first considered trying to contribute to it - the attempt to enforce NetBean's GUI builder is what put me off. > > The benefit of Maven is that it has a resource folder right inside src which > is handy to save resources such as images in. As you mention it is also neat > to handle dependencies. > Maven seems to have adopted existing best practices in this regard. > > What would you say is left before we can merge the refactor branch to trunk? > I suspect that my branch is at least as stable as trunk, but with the beginnings of a major API cleanup. It looks like there was a clear design and decent encapsulation at some point, but that they have been broken over the years. Cleaning this up further will be a lot of work, and I wonder if it may not be better to start from scratch with the core, and just using the existing drivers as a form of documentation for new ones. > BR > /Pascal > Regards, Chris |
|
From: denis q. <dqu...@fr...> - 2013-10-17 06:20:40
|
Hi, maven and ant can be used together. For example if you have special things to do for build the package, you can call ant from the pom. My professionnal projects often combine maven and ant as maven is the common build tool for all. Another choice yould be Gradle wich can be viewed as maven+ant in groovy. But it's another thing to install... -- Denis > Hi, > > Yes, I have had a look at the refactor branch. My concern about that branch was that it didn't seem active and that in some mailing list conversation there was very high aims for what was going to be developed in that branch. > > Therefore I felt that it would take quite a long time to merge those changes (which seems very good btw) to trunk. > > Regarding Ant vs Maven vs whatever I don't really have a firm opinion. > > The benefit of Maven is that it has a resource folder right inside src which is handy to save resources such as images in. As you mention it is also neat to handle dependencies. > > What would you say is left before we can merge the refactor branch to trunk? > > BR > /Pascal > > > 16 okt 2013 kl. 12:46 skrev "chr...@ch..." <chr...@ch...>: > >> Packe [pa...@ya...]: >>> Hi again, >>> >>> I have now committed my Roland D50 and Emu Proteus/2 contributions. >>> >>> One thing that annoys me is the source code structure. I have seen in previous threads in this mailing list some >>> people suggesting porting JSynthLib to the Maven folder structure. >>> >>> I think this would be a good idea as that would facilitate adding test cases and possibly in the future modularize >>> the application. >>> >>> I am willing to do the changes but I would just like to know if you guys are ok with it before I put any effort into >>> this. >>> >>> BR >>> /Pascal >>> >> Hi Pascal, >> >> If you look at my "refactor" branch, I restructured most of the source code into a more conventional style. I also started to re-encapsulate the API and re-wrote the Ant scripts so that adding unit testing support would be trivial. Since JSynthLib doesn't have any real dependencies, I'd humbly suggest that Maven is more trouble than it's worth (I use Maven at work on a project with many dependencies, but strongly feel that Ant and Ivy are a better solution). >> >> Regards, >> >> Chris > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: Packe <pa...@ya...> - 2013-10-16 18:50:26
|
Hi, Yes, I have had a look at the refactor branch. My concern about that branch was that it didn't seem active and that in some mailing list conversation there was very high aims for what was going to be developed in that branch. Therefore I felt that it would take quite a long time to merge those changes (which seems very good btw) to trunk. Regarding Ant vs Maven vs whatever I don't really have a firm opinion. The benefit of Maven is that it has a resource folder right inside src which is handy to save resources such as images in. As you mention it is also neat to handle dependencies. What would you say is left before we can merge the refactor branch to trunk? BR /Pascal 16 okt 2013 kl. 12:46 skrev "chr...@ch..." <chr...@ch...>: > Packe [pa...@ya...]: >> >> Hi again, >> >> I have now committed my Roland D50 and Emu Proteus/2 contributions. >> >> One thing that annoys me is the source code structure. I have seen in previous threads in this mailing list some >> people suggesting porting JSynthLib to the Maven folder structure. >> >> I think this would be a good idea as that would facilitate adding test cases and possibly in the future modularize >> the application. >> >> I am willing to do the changes but I would just like to know if you guys are ok with it before I put any effort into >> this. >> >> BR >> /Pascal >> > > Hi Pascal, > > If you look at my "refactor" branch, I restructured most of the source code into a more conventional style. I also started to re-encapsulate the API and re-wrote the Ant scripts so that adding unit testing support would be trivial. Since JSynthLib doesn't have any real dependencies, I'd humbly suggest that Maven is more trouble than it's worth (I use Maven at work on a project with many dependencies, but strongly feel that Ant and Ivy are a better solution). > > Regards, > > Chris |
|
From: <chr...@ch...>
<chr...@ch...> - 2013-10-16 11:31:22
|
Packe [pa...@ya...]: > > Hi again, > > I have now committed my Roland D50 and Emu Proteus/2 contributions. > > One thing that annoys me is the source code structure. I have seen in previous threads in this mailing list some > people suggesting porting JSynthLib to the Maven folder structure. > > I think this would be a good idea as that would facilitate adding test cases and possibly in the future modularize > the application. > > I am willing to do the changes but I would just like to know if you guys are ok with it before I put any effort into > this. > > BR > /Pascal > Hi Pascal, If you look at my "refactor" branch, I restructured most of the source code into a more conventional style. I also started to re-encapsulate the API and re-wrote the Ant scripts so that adding unit testing support would be trivial. Since JSynthLib doesn't have any real dependencies, I'd humbly suggest that Maven is more trouble than it's worth (I use Maven at work on a project with many dependencies, but strongly feel that Ant and Ivy are a better solution). Regards, Chris |
|
From: Maciej Ł. <loz...@o2...> - 2013-10-15 16:39:49
|
That's great for me! cheers Maciek W dniu 14.10.2013 21:56, Packe pisze: > Hi again, > > I have now committed my Roland D50 and Emu Proteus/2 contributions. > > One thing that annoys me is the source code structure. I have seen in previous threads in this mailing list some people suggesting porting JSynthLib to the Maven folder structure. > > I think this would be a good idea as that would facilitate adding test cases and possibly in the future modularize the application. > > I am willing to do the changes but I would just like to know if you guys are ok with it before I put any effort into this. > > BR > /Pascal > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Packe <pa...@ya...> - 2013-10-14 19:56:32
|
Hi again, I have now committed my Roland D50 and Emu Proteus/2 contributions. One thing that annoys me is the source code structure. I have seen in previous threads in this mailing list some people suggesting porting JSynthLib to the Maven folder structure. I think this would be a good idea as that would facilitate adding test cases and possibly in the future modularize the application. I am willing to do the changes but I would just like to know if you guys are ok with it before I put any effort into this. BR /Pascal |
|
From: Packe <pa...@ya...> - 2013-10-03 18:38:58
|
Thanks! I'll check that out. BR /Pascal 1 okt 2013 kl. 21:23 skrev William Zwicky <wrz...@po...>: > There's some kind of "long description" field that appears when the user activates your plugin. I used it to document the two GUI modes of my plugin, you should be able to put your docs there. > > It's one of the fields you pass to the constructor for core.Device. You can see how I do it in synthdrivers/CasioCZ1000/CasioCZ1000Device. > > -Bill Zwicky > > > -Bill Zwicky > > > > On Tue, Oct 1, 2013 at 4:17 AM, Packe <pa...@ya...> wrote: > Thanks, > > So there is no generic way to document limitations? > > Are you referring to this patch interface: http://sourceforge.net/p/jsynthlib/patches/?source=navbar ? I have already uploaded two patches there but I don't think they have been merged yet. Who is in charge of that? > > BR > /Pascal > > 1 okt 2013 kl. 12:47 skrev frankster <jsy...@te...>: > > > Possibly you could pop up a dialogue box when the user selects that > > driver? that doesn't sound ideal though. Maybe you could put some info > > on a wiki page somewhere? > > > > As to uploading the code - you could make a patch then submit it via the > > sourceforge patch interface. > > > > > > On 01/10/13 10:46, Packe wrote: > >> Hi, > >> > >> I have now implemented jSynthlib Sysex support for both the Roland D50 > >> and also the E-MU Proteus/2. > >> > >> 1. There are some limitations to my implementation. How do I document > >> these for the end user? > >> 2. How do I upload the source code to Sourceforge? > >> > >> BR > >> /Pascal > >> ------------------------------------------------------------------------------ > >> October Webinars: Code for Performance > >> Free Intel webinars can help you accelerate application performance. > >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > >> most from > >> the latest Intel processors and coprocessors. See abstracts and register > > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Jsynthlib-devel mailing list > >> Jsy...@li... > >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > >> > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > > the latest Intel processors and coprocessors. See abstracts and register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > _______________________________________________ > > Jsynthlib-devel mailing list > > Jsy...@li... > > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: William Z. <wrz...@po...> - 2013-10-01 19:24:41
|
There's some kind of "long description" field that appears when the user activates your plugin. I used it to document the two GUI modes of my plugin, you should be able to put your docs there. It's one of the fields you pass to the constructor for core.Device. You can see how I do it in synthdrivers/CasioCZ1000/CasioCZ1000Device. -Bill Zwicky -Bill Zwicky On Tue, Oct 1, 2013 at 4:17 AM, Packe <pa...@ya...> wrote: > Thanks, > > So there is no generic way to document limitations? > > Are you referring to this patch interface: > http://sourceforge.net/p/jsynthlib/patches/?source=navbar ? I have > already uploaded two patches there but I don't think they have been merged > yet. Who is in charge of that? > > BR > /Pascal > > 1 okt 2013 kl. 12:47 skrev frankster <jsy...@te...>: > > > Possibly you could pop up a dialogue box when the user selects that > > driver? that doesn't sound ideal though. Maybe you could put some info > > on a wiki page somewhere? > > > > As to uploading the code - you could make a patch then submit it via the > > sourceforge patch interface. > > > > > > On 01/10/13 10:46, Packe wrote: > >> Hi, > >> > >> I have now implemented jSynthlib Sysex support for both the Roland D50 > >> and also the E-MU Proteus/2. > >> > >> 1. There are some limitations to my implementation. How do I document > >> these for the end user? > >> 2. How do I upload the source code to Sourceforge? > >> > >> BR > >> /Pascal > >> > ------------------------------------------------------------------------------ > >> October Webinars: Code for Performance > >> Free Intel webinars can help you accelerate application performance. > >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > >> most from > >> the latest Intel processors and coprocessors. See abstracts and > register > > >> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Jsynthlib-devel mailing list > >> Jsy...@li... > >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > >> > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > > the latest Intel processors and coprocessors. See abstracts and register > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > _______________________________________________ > > Jsynthlib-devel mailing list > > Jsy...@li... > > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Packe <pa...@ya...> - 2013-10-01 11:17:27
|
Thanks, So there is no generic way to document limitations? Are you referring to this patch interface: http://sourceforge.net/p/jsynthlib/patches/?source=navbar ? I have already uploaded two patches there but I don't think they have been merged yet. Who is in charge of that? BR /Pascal 1 okt 2013 kl. 12:47 skrev frankster <jsy...@te...>: > Possibly you could pop up a dialogue box when the user selects that > driver? that doesn't sound ideal though. Maybe you could put some info > on a wiki page somewhere? > > As to uploading the code - you could make a patch then submit it via the > sourceforge patch interface. > > > On 01/10/13 10:46, Packe wrote: >> Hi, >> >> I have now implemented jSynthlib Sysex support for both the Roland D50 >> and also the E-MU Proteus/2. >> >> 1. There are some limitations to my implementation. How do I document >> these for the end user? >> 2. How do I upload the source code to Sourceforge? >> >> BR >> /Pascal >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jsynthlib-devel mailing list >> Jsy...@li... >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >> > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: frankster <jsy...@te...> - 2013-10-01 11:05:24
|
Possibly you could pop up a dialogue box when the user selects that driver? that doesn't sound ideal though. Maybe you could put some info on a wiki page somewhere? As to uploading the code - you could make a patch then submit it via the sourceforge patch interface. On 01/10/13 10:46, Packe wrote: > Hi, > > I have now implemented jSynthlib Sysex support for both the Roland D50 > and also the E-MU Proteus/2. > > 1. There are some limitations to my implementation. How do I document > these for the end user? > 2. How do I upload the source code to Sourceforge? > > BR > /Pascal > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Packe <pa...@ya...> - 2013-10-01 10:06:00
|
Hi, I have now implemented jSynthlib Sysex support for both the Roland D50 and also the E-MU Proteus/2. 1. There are some limitations to my implementation. How do I document these for the end user? 2. How do I upload the source code to Sourceforge? BR /Pascal |
|
From: Packe <pa...@ya...> - 2013-05-15 17:42:58
|
Thanks,
Running it through the ant build worked. Its odd though that it didn't work when calling the java file directly didn't…
BR
/Pascal
13 maj 2013 kl. 23:07 skrev Frankie Fisher <jsy...@te...>:
> I can run it from ant update-drivers with no problem:
>
> $ ant update-drivers
> Buildfile: /home/frankster/jsynthlib/trunk/JSynthLib/build.xml
>
> init:
>
> build-code:
> [javac] Compiling 2 source files to
> /home/frankster/jsynthlib/trunk/JSynthLib/build/bin
> [javac] Note:
> /home/frankster/jsynthlib/trunk/JSynthLib/core/DeviceListWriter.java
> uses unchecked or unsafe operations.
> [javac] Note: Recompile with -Xlint:unchecked for details.
>
> update-drivers:
> [java] In dir .:
> [java] Checking synthdrivers/RolandTD6
> [java] Found synthdrivers.RolandTD6.RolandTD6Device
> ...
>
> I've got java 1.7 - which version are you using?
>
> $ javac -version
> javac 1.7.0_15
>
>
>
> On 13/05/2013 20:20, Packe wrote:
>> Hi,
>>
>> I'm trying to write a driver for my Roland D50. I have added the files and wanted to generate the synthdrivers.properties file.
>>
>> Unfortunately the DeviceListDriver application fails. It creates an empty file only containing the two first lines of comments in the properties file.
>>
>> I have added debug prints which gives me this:
>>
>> In dir .:
>> Checking synthdrivers/AccessVirus
>> Checking synthdrivers/AlesisA6
>> Checking synthdrivers/AlesisDM5
>> Checking synthdrivers/AlesisDMPro
>> Checking synthdrivers/AlesisQS
>> Checking synthdrivers/BehringerFCB1010
>> java.lang.ClassNotFoundException: AccessVirusDevice
>> at core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
>> at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
>> at core.DeviceListWriter.main(DeviceListWriter.java:389)
>> java.lang.ClassNotFoundException: AlesisA6Device
>> at core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
>> at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
>> at core.DeviceListWriter.main(DeviceListWriter.java:389)
>> java.lang.ClassNotFoundException: AlesisDM5Device
>> at core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
>> at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
>> at core.DeviceListWriter.main(DeviceListWriter.java:389)
>> […]
>>
>> When I look at the code I get a bit suspicious about this part:
>>
>> String devName = synthDevices[j].substring(0, synthDevices[j].indexOf('.'));
>> try {
>> if(verbose)
>> System.out.println(" Checking " + actSynthDir.getPath());
>>
>> Class deviceclass = loader.loadClass(devName, true);
>>
>> The exception occurs on the last line of this snippet. From the substring line I guess only the class name is used as argument for the class loader. This should not work according to the API.
>>
>> Is it just me who runs into this problem?
>>
>> BR
>> /Pascal
>>
>>
>> ------------------------------------------------------------------------------
>> AlienVault Unified Security Management (USM) platform delivers complete
>> security visibility with the essential security capabilities. Easily and
>> efficiently configure, manage, and operate all of your security controls
>> from a single console and one unified framework. Download a free trial.
>> http://p.sf.net/sfu/alienvault_d2d
>> _______________________________________________
>> Jsynthlib-devel mailing list
>> Jsy...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
|
|
From: William Z. <wrz...@po...> - 2013-05-13 21:46:04
|
Synth driver code is generally held in a separate folder. If that folder's
not on the classpath, you'll get that error. Use Ant; it'll set everything
up for you and make sure the command is run correctly.
-Bill Zwicky
On Mon, May 13, 2013 at 12:20 PM, Packe <pa...@ya...> wrote:
> Hi,
>
> I'm trying to write a driver for my Roland D50. I have added the files and
> wanted to generate the synthdrivers.properties file.
>
> Unfortunately the DeviceListDriver application fails. It creates an empty
> file only containing the two first lines of comments in the properties file.
>
> I have added debug prints which gives me this:
>
> In dir .:
> Checking synthdrivers/AccessVirus
> Checking synthdrivers/AlesisA6
> Checking synthdrivers/AlesisDM5
> Checking synthdrivers/AlesisDMPro
> Checking synthdrivers/AlesisQS
> Checking synthdrivers/BehringerFCB1010
> java.lang.ClassNotFoundException: AccessVirusDevice
> at
> core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
> at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
> at core.DeviceListWriter.main(DeviceListWriter.java:389)
> java.lang.ClassNotFoundException: AlesisA6Device
> at
> core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
> at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
> at core.DeviceListWriter.main(DeviceListWriter.java:389)
> java.lang.ClassNotFoundException: AlesisDM5Device
> at
> core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
> at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
> at core.DeviceListWriter.main(DeviceListWriter.java:389)
> […]
>
> When I look at the code I get a bit suspicious about this part:
>
> String devName = synthDevices[j].substring(0,
> synthDevices[j].indexOf('.'));
> try {
> if(verbose)
> System.out.println(" Checking " + actSynthDir.getPath());
>
> Class deviceclass = loader.loadClass(devName, true);
>
> The exception occurs on the last line of this snippet. From the substring
> line I guess only the class name is used as argument for the class loader.
> This should not work according to the API.
>
> Is it just me who runs into this problem?
>
> BR
> /Pascal
>
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>
|
|
From: Frankie F. <jsy...@te...> - 2013-05-13 21:25:23
|
I can run it from ant update-drivers with no problem:
$ ant update-drivers
Buildfile: /home/frankster/jsynthlib/trunk/JSynthLib/build.xml
init:
build-code:
[javac] Compiling 2 source files to
/home/frankster/jsynthlib/trunk/JSynthLib/build/bin
[javac] Note:
/home/frankster/jsynthlib/trunk/JSynthLib/core/DeviceListWriter.java
uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
update-drivers:
[java] In dir .:
[java] Checking synthdrivers/RolandTD6
[java] Found synthdrivers.RolandTD6.RolandTD6Device
...
I've got java 1.7 - which version are you using?
$ javac -version
javac 1.7.0_15
On 13/05/2013 20:20, Packe wrote:
> Hi,
>
> I'm trying to write a driver for my Roland D50. I have added the files and wanted to generate the synthdrivers.properties file.
>
> Unfortunately the DeviceListDriver application fails. It creates an empty file only containing the two first lines of comments in the properties file.
>
> I have added debug prints which gives me this:
>
> In dir .:
> Checking synthdrivers/AccessVirus
> Checking synthdrivers/AlesisA6
> Checking synthdrivers/AlesisDM5
> Checking synthdrivers/AlesisDMPro
> Checking synthdrivers/AlesisQS
> Checking synthdrivers/BehringerFCB1010
> java.lang.ClassNotFoundException: AccessVirusDevice
> at core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
> at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
> at core.DeviceListWriter.main(DeviceListWriter.java:389)
> java.lang.ClassNotFoundException: AlesisA6Device
> at core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
> at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
> at core.DeviceListWriter.main(DeviceListWriter.java:389)
> java.lang.ClassNotFoundException: AlesisDM5Device
> at core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
> at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
> at core.DeviceListWriter.main(DeviceListWriter.java:389)
> […]
>
> When I look at the code I get a bit suspicious about this part:
>
> String devName = synthDevices[j].substring(0, synthDevices[j].indexOf('.'));
> try {
> if(verbose)
> System.out.println(" Checking " + actSynthDir.getPath());
>
> Class deviceclass = loader.loadClass(devName, true);
>
> The exception occurs on the last line of this snippet. From the substring line I guess only the class name is used as argument for the class loader. This should not work according to the API.
>
> Is it just me who runs into this problem?
>
> BR
> /Pascal
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
|
|
From: Packe <pa...@ya...> - 2013-05-13 19:41:15
|
Hi,
I'm trying to write a driver for my Roland D50. I have added the files and wanted to generate the synthdrivers.properties file.
Unfortunately the DeviceListDriver application fails. It creates an empty file only containing the two first lines of comments in the properties file.
I have added debug prints which gives me this:
In dir .:
Checking synthdrivers/AccessVirus
Checking synthdrivers/AlesisA6
Checking synthdrivers/AlesisDM5
Checking synthdrivers/AlesisDMPro
Checking synthdrivers/AlesisQS
Checking synthdrivers/BehringerFCB1010
java.lang.ClassNotFoundException: AccessVirusDevice
at core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
at core.DeviceListWriter.main(DeviceListWriter.java:389)
java.lang.ClassNotFoundException: AlesisA6Device
at core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
at core.DeviceListWriter.main(DeviceListWriter.java:389)
java.lang.ClassNotFoundException: AlesisDM5Device
at core.DeviceListWriter$MyClassLoader.loadClass(DeviceListWriter.java:336)
at core.DeviceListWriter.addClasses(DeviceListWriter.java:72)
at core.DeviceListWriter.main(DeviceListWriter.java:389)
[…]
When I look at the code I get a bit suspicious about this part:
String devName = synthDevices[j].substring(0, synthDevices[j].indexOf('.'));
try {
if(verbose)
System.out.println(" Checking " + actSynthDir.getPath());
Class deviceclass = loader.loadClass(devName, true);
The exception occurs on the last line of this snippet. From the substring line I guess only the class name is used as argument for the class loader. This should not work according to the API.
Is it just me who runs into this problem?
BR
/Pascal
|
|
From: Packe <pa...@ya...> - 2013-04-03 21:53:00
|
Hi, I have created a new project on Sourceforge now: https://sourceforge.net/projects/osxmidi4j/. To use this library in jSynthlib I have also created a patch: https://sourceforge.net/p/jsynthlib/patches/9/ Basically what you need to do is to apply the patch on your code and import the latest osxmidi4j jar file into the lib directory and add it to the classpath. Hope this works because I had some upload issues with the osxmidi4j project… BR /Pascal 2 apr 2013 kl. 23:23 skrev Thorsten Klose <Tho...@gm...>: > > Hi Pascal, > > I would like to test it with my synths. > > And I agree that a separate package would be for interest - I've two other Java applications which don't work under MacOS anymore, and would be glad to get them running again. > > Best Regards, Thorsten. > > > Am 02.04.2013 um 23:15 schrieb Packe <pa...@ya...>: > >> Hi, >> >> I have now got the Mac OS X MIDI layer to work with jSynthLib. I have tested and am able to control my DX7 from my Mac. It would be great to upload the code and have it tested by someone else to see if it works on other systems as well. >> >> I have thought that it might be a good idea to put this library in its own project in Sourceforge as it potentially can be used by other Java applications as well. >> >> Any opinions on this? >> >> BR >> /Pascal >> >> 29 mar 2013 kl. 23:01 skrev Packe <pa...@ya...>: >> >>> Hi, >>> >>> I am re-using the CAProvider code and just replacing the Java OSX MIDI API (which doesn't exist anymore) with the CoreMidi framework connected via JNA. >>> >>> Right now I'm able to send standard ShortMessages and am struggling getting syses in place. >>> >>> I don't think CAProvider depended on the MacOSXMidiWrapper.java so I have actually removed that file from my code. >>> >>> BR >>> /Pascal >>> >>> 29 mar 2013 kl. 19:03 skrev dqu...@fr...: >>> >>>> No, it was before CAProvider >>>> I have retrieved the class I made, it was the MacOSXMidiWrapper.java but I doubt it still works >>>> >>>> >>>> ----- Mail d'origine ----- >>>> De: Frankie Fisher <jsy...@te...> >>>> À: jsy...@li... >>>> Envoyé: Fri, 29 Mar 2013 15:31:13 +0100 (CET) >>>> Objet: Re: [Jsynthlib-devel] Re : Re: OS X Midi Provider >>>> >>>> Was it you that made the CAProvider.jar? That no longer works since some >>>> version of MacOSX. >>>> >>>> On 29/03/2013 13:17, dqu...@fr... wrote: >>>>> I'm not sure it's what you"re talking about but I remember had done a MIDI layer for OSX a long time ago because JSYnthLib didn't work on OSX at this time. >>>>> It was direct calls to the Java OSX MIDI API. >>>>> I don't know if the code still exists. >>>>> As I think Java is no more maintained by Apple, I think my old code is useless anyway. >>>>> >>>>> -- >>>>> Denis >>>>> >>>>> ----- Mail d'origine ----- >>>>> De: Frankie Fisher <jsy...@te...> >>>>> À: jsy...@li... >>>>> Envoyé: Thu, 28 Mar 2013 23:03:41 +0100 (CET) >>>>> Objet: Re: [Jsynthlib-devel] OS X Midi Provider >>>>> >>>>> I think this would be very useful - I'm pretty sure that noone has done >>>>> this already. >>>>> >>>>> On 19/03/2013 18:43, Packe wrote: >>>>>> Hi, >>>>>> >>>>>> As discussed with Frankie in the support forum the OS X Midi Provider (CAProvider) doesn't work on later versions of Mac OS X. >>>>>> >>>>>> I have already implemented a JNI layer for new versions of OS X that supports Midi Sysex messages. It has another interface than the Java Midi Device Provider does. >>>>>> >>>>>> I'm thinking of porting my interface to be compatible with the Midi Device Provider so that it can be used by JSynthLib. >>>>>> >>>>>> Have any of you done this already or do you think it would be useful? >>>>>> >>>>>> BR >>>>>> /Pascal >>>>>> ------------------------------------------------------------------------------ >>>>>> Everyone hates slow websites. So do we. >>>>>> Make your web apps faster with AppDynamics >>>>>> Download AppDynamics Lite for free today: >>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>> _______________________________________________ >>>>>> Jsynthlib-devel mailing list >>>>>> Jsy...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Own the Future-Intel(R) Level Up Game Demo Contest 2013 >>>>> Rise to greatness in Intel's independent game demo contest. Compete >>>>> for recognition, cash, and the chance to get your game on Steam. >>>>> $5K grand prize plus 10 genre and skill prizes. Submit your demo >>>>> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 >>>>> _______________________________________________ >>>>> Jsynthlib-devel mailing list >>>>> Jsy...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Own the Future-Intel(R) Level Up Game Demo Contest 2013 >>>>> Rise to greatness in Intel's independent game demo contest. Compete >>>>> for recognition, cash, and the chance to get your game on Steam. >>>>> $5K grand prize plus 10 genre and skill prizes. Submit your demo >>>>> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 >>>>> _______________________________________________ >>>>> Jsynthlib-devel mailing list >>>>> Jsy...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Own the Future-Intel(R) Level Up Game Demo Contest 2013 >>>> Rise to greatness in Intel's independent game demo contest. Compete >>>> for recognition, cash, and the chance to get your game on Steam. >>>> $5K grand prize plus 10 genre and skill prizes. Submit your demo >>>> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 >>>> _______________________________________________ >>>> Jsynthlib-devel mailing list >>>> Jsy...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Own the Future-Intel(R) Level Up Game Demo Contest 2013 >>>> Rise to greatness in Intel's independent game demo contest. Compete >>>> for recognition, cash, and the chance to get your game on Steam. >>>> $5K grand prize plus 10 genre and skill prizes. Submit your demo >>>> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 >>>> _______________________________________________ >>>> Jsynthlib-devel mailing list >>>> Jsy...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> Own the Future-Intel(R) Level Up Game Demo Contest 2013 >>> Rise to greatness in Intel's independent game demo contest. Compete >>> for recognition, cash, and the chance to get your game on Steam. >>> $5K grand prize plus 10 genre and skill prizes. Submit your demo >>> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 >>> _______________________________________________ >>> Jsynthlib-devel mailing list >>> Jsy...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >> >> >> ------------------------------------------------------------------------------ >> Minimize network downtime and maximize team effectiveness. >> Reduce network management and security costs.Learn how to hire >> the most talented Cisco Certified professionals. Visit the >> Employer Resources Portal >> http://www.cisco.com/web/learning/employer_resources/index.html >> _______________________________________________ >> Jsynthlib-devel mailing list >> Jsy...@li... >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Thorsten K. <Tho...@gm...> - 2013-04-02 21:24:01
|
Hi Pascal, I would like to test it with my synths. And I agree that a separate package would be for interest - I've two other Java applications which don't work under MacOS anymore, and would be glad to get them running again. Best Regards, Thorsten. Am 02.04.2013 um 23:15 schrieb Packe <pa...@ya...>: > Hi, > > I have now got the Mac OS X MIDI layer to work with jSynthLib. I have tested and am able to control my DX7 from my Mac. It would be great to upload the code and have it tested by someone else to see if it works on other systems as well. > > I have thought that it might be a good idea to put this library in its own project in Sourceforge as it potentially can be used by other Java applications as well. > > Any opinions on this? > > BR > /Pascal > > 29 mar 2013 kl. 23:01 skrev Packe <pa...@ya...>: > >> Hi, >> >> I am re-using the CAProvider code and just replacing the Java OSX MIDI API (which doesn't exist anymore) with the CoreMidi framework connected via JNA. >> >> Right now I'm able to send standard ShortMessages and am struggling getting syses in place. >> >> I don't think CAProvider depended on the MacOSXMidiWrapper.java so I have actually removed that file from my code. >> >> BR >> /Pascal >> >> 29 mar 2013 kl. 19:03 skrev dqu...@fr...: >> >>> No, it was before CAProvider >>> I have retrieved the class I made, it was the MacOSXMidiWrapper.java but I doubt it still works >>> >>> >>> ----- Mail d'origine ----- >>> De: Frankie Fisher <jsy...@te...> >>> À: jsy...@li... >>> Envoyé: Fri, 29 Mar 2013 15:31:13 +0100 (CET) >>> Objet: Re: [Jsynthlib-devel] Re : Re: OS X Midi Provider >>> >>> Was it you that made the CAProvider.jar? That no longer works since some >>> version of MacOSX. >>> >>> On 29/03/2013 13:17, dqu...@fr... wrote: >>>> I'm not sure it's what you"re talking about but I remember had done a MIDI layer for OSX a long time ago because JSYnthLib didn't work on OSX at this time. >>>> It was direct calls to the Java OSX MIDI API. >>>> I don't know if the code still exists. >>>> As I think Java is no more maintained by Apple, I think my old code is useless anyway. >>>> >>>> -- >>>> Denis >>>> >>>> ----- Mail d'origine ----- >>>> De: Frankie Fisher <jsy...@te...> >>>> À: jsy...@li... >>>> Envoyé: Thu, 28 Mar 2013 23:03:41 +0100 (CET) >>>> Objet: Re: [Jsynthlib-devel] OS X Midi Provider >>>> >>>> I think this would be very useful - I'm pretty sure that noone has done >>>> this already. >>>> >>>> On 19/03/2013 18:43, Packe wrote: >>>>> Hi, >>>>> >>>>> As discussed with Frankie in the support forum the OS X Midi Provider (CAProvider) doesn't work on later versions of Mac OS X. >>>>> >>>>> I have already implemented a JNI layer for new versions of OS X that supports Midi Sysex messages. It has another interface than the Java Midi Device Provider does. >>>>> >>>>> I'm thinking of porting my interface to be compatible with the Midi Device Provider so that it can be used by JSynthLib. >>>>> >>>>> Have any of you done this already or do you think it would be useful? >>>>> >>>>> BR >>>>> /Pascal >>>>> ------------------------------------------------------------------------------ >>>>> Everyone hates slow websites. So do we. >>>>> Make your web apps faster with AppDynamics >>>>> Download AppDynamics Lite for free today: >>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>> _______________________________________________ >>>>> Jsynthlib-devel mailing list >>>>> Jsy...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>>> >>>> ------------------------------------------------------------------------------ >>>> Own the Future-Intel(R) Level Up Game Demo Contest 2013 >>>> Rise to greatness in Intel's independent game demo contest. Compete >>>> for recognition, cash, and the chance to get your game on Steam. >>>> $5K grand prize plus 10 genre and skill prizes. Submit your demo >>>> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 >>>> _______________________________________________ >>>> Jsynthlib-devel mailing list >>>> Jsy...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Own the Future-Intel(R) Level Up Game Demo Contest 2013 >>>> Rise to greatness in Intel's independent game demo contest. Compete >>>> for recognition, cash, and the chance to get your game on Steam. >>>> $5K grand prize plus 10 genre and skill prizes. Submit your demo >>>> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 >>>> _______________________________________________ >>>> Jsynthlib-devel mailing list >>>> Jsy...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> Own the Future-Intel(R) Level Up Game Demo Contest 2013 >>> Rise to greatness in Intel's independent game demo contest. Compete >>> for recognition, cash, and the chance to get your game on Steam. >>> $5K grand prize plus 10 genre and skill prizes. Submit your demo >>> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 >>> _______________________________________________ >>> Jsynthlib-devel mailing list >>> Jsy...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> Own the Future-Intel(R) Level Up Game Demo Contest 2013 >>> Rise to greatness in Intel's independent game demo contest. Compete >>> for recognition, cash, and the chance to get your game on Steam. >>> $5K grand prize plus 10 genre and skill prizes. Submit your demo >>> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 >>> _______________________________________________ >>> Jsynthlib-devel mailing list >>> Jsy...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >> >> >> ------------------------------------------------------------------------------ >> Own the Future-Intel(R) Level Up Game Demo Contest 2013 >> Rise to greatness in Intel's independent game demo contest. Compete >> for recognition, cash, and the chance to get your game on Steam. >> $5K grand prize plus 10 genre and skill prizes. Submit your demo >> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 >> _______________________________________________ >> Jsynthlib-devel mailing list >> Jsy...@li... >> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > 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.
