Subject: Re: [linux-audio-dev] My 2 cents
From: Adam Zygmunt (azygmun_AT_bgnet.bgsu.edu)
Date: ti elo 10 1999 - 19:53:35 EDT
On Tue, 10 Aug 1999, David Slomin wrote:
> On Tue, 10 Aug 1999, Adam Zygmunt wrote:
>
> > Multitrack editing and realtime effects would come last, or be more
> > likely handled by a decent audio sequencer.
>
> That's the first time I've heard the term "audio sequencer", but I rather
> like what it implies... all the power and then some of an audio-extended
> MIDI sequencer (Jazz++, Cakewalk Pro Audio, Cubase VST, etc) without the
> MIDI stuff getting in the way. The right interface for the right task,
> not some half-hearted attempt to combine the two.
>
I don't necessarily think the two shouldn't be combined, which is what I
meant by audio sequencer. Until recently, audio-extended sequencers have
been half-hearted, but they've certainly gotten a lot better. The newest
version of Vision DSP, for example, has significant improvements on both
the audio and MIDI fronts, and actually works quite capably as a
multitrack recorder. It even has a few nifty features like analyzing the
beats in an audio file and quantizing the MIDI to it.
A good example, though, of an audio-only type program that works extremely
well with nonlinear multitrack audio (save for splicing, but you can't
have everything now, can you?) is the multitrack view of Cool Edit Pro.
I hadn't thought of the concept of audio-only sequencer before, but this
probably fits the bill. Other than pan and volume, though, there are no
realtime effects. These are either done to the source files beforehand or
to the final mix.
I would say that there is enough commonality between sequencing and
multitrack recording that even if they are separate programs, they could
certainly share a lot of code and have similar look-and-feel.
> you really can't edit the tracks the way you can in a sequencer. Which of
> the multitrack recorder projects in our community here would you folks
> consider worthy of the "audio sequencer" name?
>
I would say Multitrack would be the closest thing, though it's certainly
got its issues. Namely, the source code thing and the proprietary SVGA
interface (new X interface was very unstable for me, I'm afraid). It's
exceptionally responsive, but it's so "unique" that getting it to play
nice with others might be difficult.
> > What I would suggest would be that cutting, pasting, and copying MIDI
> > events be as easy as possible. Ditto for adding/editing velocity,
> > duration, and custom continuous controllers.
>
> Here, here. For simply entering notes, the piano roll is my tool of
> choice (other than live recording), but for anything advanced, you need a
> well-designed, powerful event list view. The shameful thing is that this
> is much easier to implement than a good piano roll, but everybody seems to
> forget to do it!
So true, but being able to draw in extra parameters easily is good too.
Most sequencers already do this. Some do it better than others. Some of my
pet peeves with various sequencers are (if you're open to suggestions):
1. Event lists that don't list ALL the events. ESPECIALLY initialization
events.
2. Sequencers that force all the MIDI events in one track onto one
channel. Particularly a problem with some imported MIDI files.
3. Sequencers that only allow you to change a few controllers by GM name,
instead of all by number. Not everything, especially external stuff, works
according to GM (having all the XG controllers named is nice, though).
4. Sequencers that force a GM reset at the beginning of a piece.
Especially bad when combined with 1. 3 and 4 are why I use Jazz++ almost
exclusively for sequencing (for a Yamaha CS1x), despite its clunkiness.
5. Other general stupidity. One sequencer I used, for example, would send
a patch change AFTER a note whenever they had the same time code! I ended
up having to manually find all the patch changes (orchestra piece squeezed
down to 16 MIDI tracks) and retype their times a little earlier in the
event list. Only sequencer I had access to at the time, though.
> I'm not a Score user, but I have been using Encore extensively for years,
> and have experimented with Finale, Lilypond, and numerous others. Based
> on this experience, I would say that it would not be impossible for
> someone from our open source community to do it properly, only difficult.
>
> The key thing is a concept that you left out... do not limit the scope to
> only simple features, but keep simple tasks simple. Encore, and almost
> all sequencers which include notation capabilities fail because they only
> have simple features. Score and Finale fail not from lack of features but
> because they do not keep simple actions simple for the user.
So true!
> My hope for the future on this front lies with Guido (see Dave's page for
> a link), which is based around just what I've described. At the moment,
> they've only implemented the simple features, but their design plan is
> very clearly spelled out to continue to fill in the advanced stuff without
> sacrificing usability at all.
I've checked out Guido, and I would not necessarily say it keeps simple
things simple. There's too much punctuation to keep track of and too much
typing to do for anything past Three Blind Mice. It's not interactive,
either, which as I said before, is a major drawback. Even Score is more of
an interpreter than a compiler. I looked at the docs, and the simple
Beethoven Quartet example is hellishly like TeX gone wrong.
The thought of having to deal with
\crescBegin<dx=1.28,dy=-5.76> d2/8 \space<6.4>
\merge( b1/16 \crescEnd<dy-5.76>
to get a simple crescendo is frightening, and I don't scare easily.
Especially trying to work without feedback this way. That the docs were
obviously set in TeX, to so it is probably safe to assume the authors are
not real human beings, but are rather some of those odd creatures still
fluent in TeX. Not only that, but Guido's language structure simply does
not seem abstract enough for music. Complex things will necessarily get
REAL complex. It doesn't even look like this is a suitable core for a
interactive shell, as there's WAY too much grammar involved and not enough
control over individual objects.
Score's got plenty of faults, and it's not what choose to use for most
projects, but it does have one good feature. It's internal representation
of things is so elegant, there's little room for improvement. The
representation is numerical, but could easily have one-word substitutions
where appropriate to make it easier to deal with. For example, a line of
code could be:
note quarter 1 50.0 3 1, for a quarter note on the first staff, 50.0
whatevers from the left margin, middle line (3 whole space units up from
baseline), regular size (1). note tells the printer (or interactive outer
layer) what the rest of the parameters stand for and quarter stands for
whatever number represents a quarter note in the font table.
note quarter 1 50.0 3 1 up for same note, stem up
note quarter 1 50.0 3 1 default 2 for same note, default stem direction, 2
staff-unit-length stem, and so on. Notice default is sort of a
placeholder, and less-used options are assigned positions further down the
list. Score's method of object representation is only a little more
complicated, the main addition being a 1 in there somewhere for duration
(used for spacing) which should probably be in there explicitly and not
assumed from quarter.
It would be up to the outer, interactive layer of the program to
calculate good horizontal positions of objects, provide for easy selection
of objects, allow editing, and do MIDI translation. It's an abstract
enough format that with the proper selection of primitives, it can be made
to do anything relatively simply. You want feathered beaming, just draw in
another beam. Copy the line representing the beam you want to feather,
change the parameter for vertical height, and presto! Another advantage
of this sort of development is that the translation from this sort of text
representation to an actual printout would be quite a bit simpler than the
other Unix notation packages out there, could be used right away, and
could have an iteractive outer layer that could be expanded bit by bit.
Not to mention the possibility of a selection of outer layers.
I personally use Sibelius right now for notation (easy to use, yet as
flexible as Finale and certainly smarter), but jumping into a
Sibelius-type program immediately would be insanity. It could eventually
be built on top of something like this, though.
> Just my two centimes (use them while you can, before the Euro obsoletes
> them),
> Div.
>
Adam Zygmunt
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST