Quoting Marcus Andersson (054185595@...):
> 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'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
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.