[Rosegarden-devel] notation thoughts

[D. M. M. <mic...@ro...>]

Playing with Finale Allegro and Sibelius, I'm not so far along yet, but I'm 
beginning to have concrete ideas for Rosegarden, instead of vaguely groping 
around for something I want, but can't describe.  So far Finale Allegro is 
the clear winner for me in terms of which one is easier to use without 
reading any instructions, and it also seems their first time wizard is the 
most obvious one from which to draw inspiration, using our existing 
infrastructure.

First thing we'd need is a File -> New Document from Wizard as an alternative 
to File -> New.

The first page of the wizard should be the equivalent of our current 
Composition -> Edit Document Properties -> About page.  I'd like to see this 
same content redone with less obnoxious widgets.  I really hate whatever 
widgets are used currently.  I don't see any need to be able to edit 
the "key" portion either, since we don't print or export things that don't 
match fixed "keys" anyway.  Replace the ability to make up your own keys with 
a simple text entry box for adding comment text using that ubiquitous KDE 
editor-in-a-box widget I'm sure exists, but don't know by name.

Next, picking instruments.  Sibelius does this by ensemble first, brass band, 
orchestra, whatever, and you can pick instruments grouped by categories 
like "common instruments," "band instruments," etc.  I've mad suggestions to 
this effect myself as a way to improve the existing preset database, but we 
don't have these groupings now, and adding something to choose based on these 
groupings could conceivably happen at a later time.  For now, we could do 
something more like Sibelius, which is almost free.

Left pane in Finale is the simple category of brass, winds, etc., the middle 
pane lists instruments in that category, and the right pane is the list of 
instrument parts that will go onto the score.  I don't know what widget this 
is either, but it's the same sort of thing the edit-your-own-toolbars 
interface from KDE uses.  So you wind up with something like this after 
making some various selections in the first two parts of the dialog:

category           instrument         score arranger
------------       ------------       ---------------
                   Piccolo Trumpet    Flute in Eb
brass       [>]    Trumpet in Bb   [>]Trumpet in Bb
                Horn in Eb            Horn in F
                Horn in F             Percussion
                Tuba in Eb
                blah

Ordering is accomplished with a combo under the arranger  portion of the 
dialog.  You can choose orchestral, band, and so on, and it rearranges the 
contents of the third list accordingly.

Next up, it asks for the initial tempo, initial time and initial key signature 
for the piece in concert pitch.  Notably, the tempo option lets you specify 
the written tempo indication in the dialog, rather than adding it manually 
after the fact.  I quite like that.

(Feature request:  I'd like to have tempo indications that display 
intelligently when they're needed.  Only on the top part of a grouping, but 
displayed on individual parts or individual sub-groupings.  Maybe something 
detached from the text mechanism and done an entirely different way.)

We could get most of the elements for the above dialog from existing dialogs 
or code rearranged.  It doesn't have to be, and indeed should not be a clone 
of Finale, but I think it's a good model.

Next up, the MIDI question.  Both Finale and Sibelius assign patches and 
channels and whatever invisibly, so the user has no control (not immediately 
apparently anyway) over how anything gets played.  One or the other of them 
defaults to "Microsoft Wavetable GS Synth" on some combo box.  We really 
should try to come up with something similar, and add a General MIDI-based 
program assignment to the presets in our database.  It's not possible to come 
up with something sensible for all bazillion instruments, but I think we 
should just fake our way through the best way possible, and should make these 
program and channel assignments by default, assuming the first playback 
device is a GM device.  Possibly with some facility for overriding the 
defaults in a configurable and repeatable way when they're always going to be 
wrong for a given user.  (Somebody always composes with their Fancy Synth 
3000 with the Orchestral Wonder Instruments Expansion Pack that isn't 
remotely GM compatible.  I bet these other apps have some way to cope with 
that, and I should play with that and mine them for inspiration how to work 
that into a Rosegarden context.)

Then of course, you just build a new document with new tracks and empty 
segments appropriately (I'd like different segment colors for every part, 
maybe color by instrument family, red for brass, blue for winds, etc. or 
something) and you're off to a good start.

Now I'll move into some of the other niggling bitchy problems.

Voices.

Finale handles voices as layers, with a simple [1][2][3][4] at the bottom of 
the composer window thingie.  Sibelius has the same four buttons on a 
floating toolpad I haven't figured out how to use yet.  I think Finale is on 
the right track because I figured out how to input notes into Voice 3 
immediately.  Layers could be overlapping segments, the off notes displayed 
in gray, the active ones in black, with a quick chooser to bring the right 
layer to the fore, and a mode to turn off all but the active layer.  We can 
already display overlapping segments, so this doesn't seem too terribly 
impossible to me.  The main thing would be creating a new overlapping segment 
for the user without involving the segment canvas when they click the [2] 
button.  There could well be other issues, as with voices that are sometimes 
beamed together as part of the same kind of chord construction, etc.  
Currently our segments cannot merge together in this fashion, nor can they 
export in this fashion either.  I have no idea as yet how Finale or Sibelius 
handle that same problem, and it bears investigating.

Grand staffs.

There are a number of problems I can't see how to solve using the 
treble-and-bass-in-independent-segments model.  It almost seems to me we need 
a new dedicated staff type where the staff *is* a grand staff, and events 
would have to carry some new property to show which staff they belong to.  
Only with something that takes it that far can I see our ever having the 
ability to do kneed beams, for instance, or easily moving a note from one 
staff to the other by dragging it through the gap between staves.

Repeats.

The current way we do repeats is horrible, and exportable only first/second 
endings are even worse.  We really need an entirely notation-based mechanism 
that insulates the user from the vagaries of dicking around at the segment 
level.  I documented a "fold here" request which I think is a viable way to 
solve the problem.  In addition to what else has been suggested on that 
comment thread, I think we ought to give some real thought to more than one 
set of verses to a song.  I hate songs, and don't write lyrics, but a million 
people do, and there is no sane or reasonable way to handle this problem at 
present at all.

Proper segnos, codas (part of the "fold here" idea) and such should be 
implemented natively.  Some of these are exportable through that schlock I 
piggybacked onto the Text tool, but LilyPond directives are EVIL.

Ability to print and export groups of parts, or single parts, automatically.  
Print the full score, print a subset of the score, print out individual 
parts.  IN INDIVIDUAL PARTS LONG STRETCHES OF REST MUST MUST MUST BE 
MULTI-BAR RESTS!!!!!!!!!!  That last one is a serious pain in my ass, because 
everything in the world for instruments other than strings has ass loads of 
multi-bar rests everywhere.  When you print out the part, you don't want 
three pages of whole rests, you want a damn |==54==| in one bar somewhere.  
This currently has to be fixed tediously by hand in LilyPond, and I don't see 
any reasonable way to export as multi-bar rests with the existing scheme of 
things, or I would have done it months ago.  How do I know at export time I'm 
supposed to be using a multi-bar rest?  I can't figure that out, and anyway, 
they should exist in Rosegarden too.  Display three pages of whole rests on a 
multi-part view, and a multi-bar rest on a single part view.  That would be 
fine.

And last but not least, grace notes.  Good old grace notes.  They've been 
broken for eternity, and I'm at a stage of playing with music where every 
third thing I want to rearrange or transpose has grace notes all over the 
fricking place.  This is annoying me to no end.  They don't work in 
Rosegarden, and they don't export correctly to LilyPond.

I think that's about all it would take to make Rosegarden pretty well usable, 
but I have no idea if any of it is worth even trying at this point, because 
the list feels a mile high, and about all I could do myself is some of the 
dialog diddling for the first time setup thing.  I have no bloody idea how to 
make it actually do anything, and no bloody idea how to address myriad 
notation view complaints, and 40,000 year old bugs I would have fixed two 
years ago if I knew enough to do it.

I'm on the fence at the moment.  Finale Allegro looks mighty tempting compared 
with continuing this effort (now that I have a copy of Windows again, sigh), 
but it has also been somewhat inspirational to see how some of these problems 
are actually solved by successful commercial packages.  I guess first I need 
to find out what is broken about Allegro compared with its big brother.  I 
think Sibelius can be written off as too damn complicated to use, and not a 
good fit with Rosegarden's existing scheme of things.

It is of course important not to directly rip anything off too, and I'm not 
thinking that way.  I'm just thinking about implementing their ideas within 
an appropriately Rosegarden framework.

notes to self:
* look at how they handle adapting to the Super Orchestra Wonder Wizard card
* look at what happens when multiple voices mix say four eights on the bottom 
and 8 4 8 on top WRT beaming

-- 
D. Michael McIntyre