Subject: [linux-audio-user] Linux music notation editor criteria
From: Dave Phillips (dlphilp_AT_bright.net)
Date: Thu Jul 15 2004 - 01:00:05 EEST
Greetings:
As promised, here's a set of test criteria used by Alan Belkin in his
1994 review of notation programs for the Macintosh. I hope that the
authors of Linux music notation software will consider this list against
the features of their own efforts.
I'm not interested in comparing "ours against theirs". The Mac
programs tested were all WYSIWYG notation editors, including Finale,
Composer's Mosaic, Encore, Lime, and Nightingale, while some of the best
Linux music notation software is devoid of any GUI. Nevertheless, the
criteria seem adequate as base requirements for any music notation
software, and I'm very interested in the opinions and evaluations of the
Linux developers of such software. I know that the authors of NoteEdit,
LilyPond, MusE/Musescore, Denemo, Rosegarden, Common Music Notation, and
perhaps other significant notation editors are represented on the
LAD/LAU lists, and I hope they will respond on-list to the criteria
presented here. I also welcome comments from users regarding the
presence or absence of the listed features in their favorite Linux
notation program.
I have only slightly altered Mr Belkin's original criteria where it
was Mac-specific. The evaluations in his original article were either
qualitative (good, bad, ugly, etc), quantitative, (1, 4, 12, etc), or
affirmative/negative (yes/no). So, here we go:
Note entry:
mouse & keyboard
MIDI step-time
MIDI realtime w. flexible quantization
audition other saves while recording
retain performance data for playback
number of independent rhythmic layers per staff
maximum number of staves per system
Entry of slurs, articulations, dynamics, etc.:
intelligent default placement
apply to multiple staves at once
Selection in regional edits:
vertical, horizontal slices within and across measures, staves,
system, pages, etc.
non-contiguous
conditional selection
Editing:
click & drag positioning of symbols
transposition (note, staff, selection, etc)
enharmonic change by region
rhythm: change note values (ease of use)
rhythm: auto-rebar
cut/copy/paste: music
cut/copy/paste: non-musical items, formats, etc.
mirroring (intelligent copies)
Special/custom notation:
unusual staves
simultaneous key signatures
unconventional time signatures
additive time signatures
simultaneous different time signatures
drawing tool
user-created symbols
user-selectable fonts for all elements
chord notation: graphic, playback, learn via MIDI
fretboard notation
figured-bass notation
unusual note heads (slashes, harmonics, etc)
easily adjustable cross-staff beaming
Lyrics:
mass create
create on page
import from text editor
auto layout
multiple fonts
flexible placement
MIDI playback:
ALSA or OSS support
channel support
playback includes modifiers (crescendi, dynamics, etc)
direct editing of MIDI data
import patch lists (GM, GS, etc)
scrolling playback
edit during playback
Entry layout:
flexible engraver spacing within measure
account for dynamics, slurs, annotative text, etc.
Page layout:
auto layout with engraver spacing
reduce or enlarge symbols, staves, text, systems, by any percent,
locally or globally
full control of measures per system
full control of systems per page
remove empty staves within systems
flexible spacing of staves within systems
Part extraction:
automatic with new layout
dynamic links to master score
File operations:
follow Linux standards (?)
simultaneous multiple files open
printed output: PS, PDF, DVI, etc.
Interface/overall ease of use:
undo/redo any operation
user-defined key bindings
user control over notational defaults
views: scroll, page, template, any percent, multiple simultaeous views
priorities clear
logical organization
simple language and icons
overall speed
on-line help
documentation
ease of learning
general solidity and stability
In his article Mr Belkin also addressed the problem of tuplets, noting
that at that time only Finale realized anything other than triplets when
converting from MIDI input (file or realtime). I should also note that
this list is hardly meant to be a complete set of expected features:
after all, it's from an article published ten years ago. I'm sure we've
advanced well beyond the state of the art in 1994... right ? :)
Best regards,
Dave Phillips
This archive was generated by hypermail 2b28 : Thu Jul 15 2004 - 00:25:34 EEST