Re: [linux-audio-dev] Developing a music editor/sequencer

>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
Received on Thu Feb 3 00:15:05 2005