Subject: Re: [linux-audio-dev] My 2 cents
From: David Slomin (dgslomin_AT_CS.Princeton.EDU)
Date: ke elo 11 1999 - 01:04:52 EDT
On Tue, 10 Aug 1999, Adam Zygmunt wrote:
> 1. Event lists that don't list ALL the events. ESPECIALLY initialization
> events.
I certainly agree, but the question can arise as to what constitutes an
event. Is there such a thing as a note, or is it a note on and a note
off? Is an RPN one event or two? In my current design, I support both
forms for each, and provide functions to convert between the two according
to your needs. I plan to propogate this functionality through to the
end-user interface as well.
> 2. Sequencers that force all the MIDI events in one track onto one
> channel. Particularly a problem with some imported MIDI files.
This definitely stems from the piano roll centric view of the world. It's
fairly hard to present tracks containing multiple channels in a manageable
manner in a two dimentional interface. I have a potential plan for how to
handle this reasonably in the piano roll (why do I feel like this is
Fermat's last sequencer?) and it's certainly easy enough in the event list
view.
> 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).
Agreed. To me, a MIDI sequencer should handle raw MIDI. Shortcuts for
GM, XG (Yamaha), GS (Roland), MTC (SMPTE sync), MSC (stage lighting
control) and any other such conventions should definitely be treated as
that... shortcuts, not the primary interface. This is of particular
interest to me, since my own external synth (Yamaha SY22) is older than
GM, and uses its own patch map.
> 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.
I hadn't even thought of adding one, but I guess it would be a nice option
to throw in, as long as people like us who don't need it can turn it off.
> 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.
That brings up a question... is it the job of the sequencer to decide how
to order events with the same timestamp? Should you honor the order they
appeared in the file or came over the wire? Should you leave it up to the
user by adding "nudge" commands to the interface?
> 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.
Agreed. I wouldn't call it a perfect or even decent solution, but a
project that sets intelligent goals.
> 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.
As someone who programs in compiled languages for a living, I've
personally become very used to the edit, compile, test, repeat cycle, but
I wouldn't expect it to work for everyone. I write HTML by hand, too.
> 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.
This is pretty clean. Actually, it looks a lot like CSound score syntax,
which is probably not accidental at all if you trace the history back far
enough (they're both old programs). If I had personal experience with the
real thing, I would probably look towards an open source, portable Score
clone as a target for a notation project.
In any event, the difference is that Score looks like it's very closely
tied to the visual end of notation, whereas Guido tries to stay more
towards the musical expression end (a la Common Music). The Guido
developers want to use it for musical analysis, not just for notation.
It might well be that no single score language or program can decently
do both.
Interesting thoughts though,
Div.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST