2 Feb
2005
2 Feb
'05
3:02 p.m.
I wanted to post this to the root of the thread since
this isn't a reply to
any particular post, but I lost the beginning of the thread somehow.
This is my initial stab at a development plan. I'm tentatively calling this
project Scortch. Because of fundamental differences in design, I don't think
I can directly build anything off of Rosegarden, but I intend to use it (and
denemo and kguitar) for inspiration. (I have a couple of very hacked up
versions of these programs, mostly demonstrating to me how difficult it would
be to directly branch from one these.)
This isn't meant to be the "ultimate music development system", perfect for
everyone's needs. Rather, I have the needs of a particular audience (me!) in
I continue to think that this crazy. If you *have* to do this, you'd
be much better off starting from a genuinely modular system like
pd. I've seen tools built by creative people (hi Orm! hi Frank!) in pd
that have as much if not more functionality than you are describing,
albeit in different areas. You'd cut your development time in half,
and make a much more useful tool as a result.
Let me mention just a few of the issues you may have forgotten about
as you sketch out this grand plan:
a) what happens with overlapping audio?
b) how many threads does this system require, how do they
communicate in a suitable fashion, and how
are data structures shared between them?
c) how do you propose to (re)tackle all the engraving issues
that lilypond has already addressed?
d) what does it mean to change the meter of a representation
of a composition that is stored as a series of
points measured along an absolute wallclock-based timeline?
Ditto for the tempo.
e) what widget set will you use to draw all of this stuff?
You might think otherwise, but I can assure you that you are proposing
nothing less than a full implementation of the same goals as Ardour,
Rosegarden, Muse, maybe even Beast and others. These tools have taken
*years* to get to their current state, and although you could
doubtless speed up development by reusing code and ideas and
experience from their source code, the speedup will probably be less
than you think.
The pool of available developer resources for linux audio projects is
small, much smaller than you might guess. You have some specific
issues with existing tools, but no issues that could not be
fixed. Fixing them would be a *lot* of work, but enormously less work
than what you are proposing.
Obviously, nobody can stop you from doing whatever you want. But
writing the kind of audio application you are talking about is really,
really complex, and takes a long, long time to get right. I think
you're making a big mistake when there are existing projects that
could benefit from your insights, knowledge, skill and time.
--p