[linux-audio-user] Linux music notation editor criteria

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