You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(11) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(38) |
Feb
(27) |
Mar
(5) |
Apr
|
May
|
Jun
(82) |
Jul
(42) |
Aug
(11) |
Sep
(23) |
Oct
(9) |
Nov
(42) |
Dec
(3) |
2004 |
Jan
(8) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
(7) |
Mar
(11) |
Apr
(9) |
May
(1) |
Jun
(5) |
Jul
(3) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
2006 |
Jan
(22) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
(12) |
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Marcus A. <054...@te...> - 2002-12-17 17:29:57
|
Jan Punter wrote: > > Hi all, > > I'm currently adapting & gnu-izing & documenting (a tiny bit) some > source files and I will publish those later this week - I'm starting > with the patch reader stuff. This a set of two pascal units - one that > reads module knowledge from a text file and another that reads nm > patches and that can make use of the module knowledge gathered by the > first module. > > This is a test - of course :-) Works fine. What kind of parser have you written? Handmade or based on a grammar? Marcus |
From: Marcus A. <054...@te...> - 2002-12-17 17:25:28
|
wires wrote: > > > Aiming for win, mac and unix, I think we should investigate available > > cross platform technologies that has already been proven to work. Java > > is one, C++ and wxWindows (www.wxwindows.org) is another. > > > Take a look at Audacity (www.sf.net/projects/audacity), a cross > > platform audio application that uses wxWindows. Does gtkmm work on win > > and mac? I'm sure there are other useable technologies. > > I'd rather skip Java and just write it in C++ (with some toolkit)... > > Or atleast the core stuff (MIDI talking, protocol parsing, patch > parsing, etc.) and stuff that in a library. We could then bind this lib > to Python or Delphi or whatever and create the editor application on top > of that. I agree. One or more libraries written in C++ is probably the best way. I just don't want to rule out Java completely. If someone wants to do a parallel implementation based on the same specifications and grammars, it should be possible. > Obviously wxWindows is more portable than gtkmm and might be the right > way to go. gtkmm doesn't work on windows, but it does on mac. Personally > I think gtkmm is much nicer to work with than wxW. I haven't used either. Is there a strong argument to exclude windows from the start? I know I'm not going to develop for or test on windows, but maybe someone else wants to do that. > > - PC<->NM protocol specification > > Ultimately we would like to specify the protocol and the PCH format in a > computer parsable format (say XML or BNF) and then use a tool to create > a parser from that (bison/bison++). I would say that the use of a grammar is the only sensible way to write a parser. The next step is to find a parser generator that produces a parse tree utilizing the visitor pattern. Then it becomes very powerful and simple. Marcus |
From: Jan P. <J.P...@ia...> - 2002-12-16 22:23:04
|
Hi all, I'm currently adapting & gnu-izing & documenting (a tiny bit) some source files and I will publish those later this week - I'm starting with the patch reader stuff. This a set of two pascal units - one that reads module knowledge from a text file and another that reads nm patches and that can make use of the module knowledge gathered by the first module. This is a test - of course :-) Jan. |
From: wires <wi...@xs...> - 2002-12-16 18:06:16
|
Hi Marcus! Quoting Marcus Andersson (054...@te...): > now we're rolling. Nice work Jelle, setting the site up. Thanks! > Introducing myself, I am a hobby musician, dreaming about the perfect > home studio. I have had the NM since the v2.0 days and have made a few > usable patches, but mostly enjoyed the fantastic work of others. > > Daytime, I work as a software consultant in Sweden. This means I will > only have a couple of hours a week to spend on this project, but that > should only make me more efficient I think. I'm a student, so I'm quite limited in my time too. > I am also involved in the Ardour project, ardour.sf.net. If you haven't > heard of it before, check it out. It is getting really useful by now. Ofcourse I know Ardour, excellent application! I'm involved with gAlan, http://galan.sf.net/, I assume you also read LAD and may have heard about galan there. About your other mail: > Aiming for win, mac and unix, I think we should investigate available > cross platform technologies that has already been proven to work. Java > is one, C++ and wxWindows (www.wxwindows.org) is another. > Take a look at Audacity (www.sf.net/projects/audacity), a cross > platform audio application that uses wxWindows. Does gtkmm work on win > and mac? I'm sure there are other useable technologies. I'd rather skip Java and just write it in C++ (with some toolkit)... Or atleast the core stuff (MIDI talking, protocol parsing, patch parsing, etc.) and stuff that in a library. We could then bind this lib to Python or Delphi or whatever and create the editor application on top of that. Obviously wxWindows is more portable than gtkmm and might be the right way to go. gtkmm doesn't work on windows, but it does on mac. Personally I think gtkmm is much nicer to work with than wxW. Either way, I think it's a good idea to base all this on a library because that opens up a lot of possibilities, for example, we could turn the editor application into some kind of Logic plugin and use Logic's automation to sequence the patches (or swap cables even?). Etc etc. > I think it should be possible to develop this in stages, each stage > generating a useable result on its own. (This doesn't mean that we can't > start with a later stage before the earlier are finished though.) Yes, so do I. > - PCH file specification > - In memory PCH data structures, the patch model > - PCH file parser > - PCH file writer AFAIK Jan already has all of this, although it's delphi code, but we can use that to base a C/C++ version on. > - PC<->NM protocol specification Ultimately we would like to specify the protocol and the PCH format in a computer parsable format (say XML or BNF) and then use a tool to create a parser from that (bison/bison++). If needed we could then use another tool/script to convert the computer parsable format into a human readable format (Latex) to publish on the website or stuff in the documentation. We need two parsers, on for the PCH and one for the PC<->NM protocol. > - PC<->NM MIDI protocol interface Yes, I see this as the basis of a library to base the editor/loader on. > - Patch loader > - Graphical patch editor If Jan decides to release his code under GPL license (which prohibits commecial use) we could see if it's possible to that, that is a complete patch editor, right? We could then later decide to rewrite into C++ using wxW or GTKmm. cheerz -- http://defekt.nl/ |
From: Marcus A. <054...@te...> - 2002-12-16 17:14:17
|
Hi, now we're rolling. Nice work Jelle, setting the site up. Introducing myself, I am a hobby musician, dreaming about the perfect home studio. I have had the NM since the v2.0 days and have made a few usable patches, but mostly enjoyed the fantastic work of others. Daytime, I work as a software consultant in Sweden. This means I will only have a couple of hours a week to spend on this project, but that should only make me more efficient I think. I am also involved in the Ardour project, ardour.sf.net. If you haven't heard of it before, check it out. It is getting really useful by now. Marcus |