#812 notation editor has limitations and may confuse

closed
notation (282)
8
2012-09-16
2005-10-01
Chris Cannam
No

I'm creating this bug for general ideas and
discussion about ways to make the notation editor
more reliable, predictable and comprehensible.
I'm going to leave it unassigned and unprioritised
for the moment.

This is partly in response to Michael's comment in
another bug report about how the notation editor
has stopped evolving during the last couple of
years. We've reached a point where most of the
obvious bug and feature work available is stuff
that is easy to describe and explain the need for,
but very hard to conceive of even the first steps
towards actually achieving in the GUI and code,
which is why even the most basic features (e.g.
piano staffs, alternative repeats) keep getting
stalled.

Much of the difficulty arises from Rosegarden's
form as a combined sequencer/notation editor. I
would like to find ways to overcome the difficulties
that arise from this form, rather than boringly
accepting that some things just can't be done or
will have to be excessively complicated to use.

I'll try to start this off shortly (if nobody else nips in
first) with some thoughts about polyphony, part
writing, and rests.

Discussion

  • Chris Cannam
    Chris Cannam
    2005-10-01

    Logged In: YES
    user_id=13489

    OK, so, one problem people often have with the
    notation editor (this one came to mind first because
    it's one of the things Michael was complaining about) is
    the rather obscure way it handles rests and the
    tendency to end up with rests in apparently wrong
    places but that the notation editor just won't get rid of.

    There's a simple combination of circumstances at
    work here, and this is a good example of what I meant
    about problems directly arising from the combination of
    sequencer and notation.

    Some salient points:

    a) Rests in Rosegarden are actual events that the user
    can actually enter and that have a concrete existence
    in the score, but they are also generated automatically
    to fill gaps in the note events -- and in practice, for
    probably a majority of users, they are always generated
    automatically except where RG puts in unwanted rests
    that then have to be deleted (if possible).

    b) Rosegarden aims always to be able to produce
    notation from arbitrary MIDI. I started out with the
    intention that the notation editor should always do its
    best to produce something vaguely meaningful, no
    matter what sort of polyphonic mess of MIDI events it
    was given (and that at least shouldn't lie about the
    events by e.g drawing neatly aligned chords for notes
    that are in fact of quite differing lengths and only
    vaguely similar start times, as most sequencers with
    notation capability do). Consequently we have a
    notation editor that doesn't formally support multiple
    voices or overlapping notes (it doesn't like you to enter
    them and mostly won't get them right) but that still has
    all sorts of troublesome edge cases in which it tries to
    deal with drawing them, given segments that start out
    containing messy overlapping notes. In some cases
    these actively impede the entry of the sort of music it
    does claim to support -- for example, it's harder than
    it should be to enter chords, and the situation with
    rests is unpredictable.

    So, here's a suggestion for a remould.

    1. We make the notation editor only able to show
      non-overlapping notes within a single segment. If you
      enter notes that overlap, it will always split and tie
      them (although see below). If notes are recorded that
      overlap, it will truncate them into tidy chords. There will
      never be an ambiguity within a single segment (at least
      as far as the notation editor is concerned) as to which
      notes belong to which chords, because if two notes are
      playing simultaneously and in the same segment, they
      are ipso facto in the same chord (this is not the case
      at present).

    2. We implement proper part-writing support so as to
      have separate segments able to display as separate
      parts in the same staff in the notation editor.

    3. We (somehow) make it very easy to create new
      segments for new parts in notation. You want to insert
      a minim at the same time as (but different pitch from)
      an existing crotchet? Hit ctrl-something to create a
      new part and make it active, and then insert the note
      in that new part -- it will appear on the same staff just
      as if you'd entered it directly, but it'll be a quite
      separate theme. If you don't do that, the note gets
      split and tied with the old one.

    This scheme could work if all segments for a given part
    are on the same track (overlapping), or it could work if
    the segments were on separate tracks. An ideal
    situation would allow both. The former would require a
    better way to show overlapping segments in other
    situations like the main segment canvas (something I
    thought I might experiment with this week anyway).
    The latter would require a way to control which tracks
    get their segments merged into staffs in the notation
    view (I do have a fuzzy idea for a notation arranger
    widget, but I haven't got very far with that one yet).

    Any and all comments welcome. Particularly of interest
    are comments about the user experience resulting
    from 1, 2, and 3 above, and why they might be awkward
    and inadequate, or might make your life complete, or
    might not make any difference to you at all. Just add a
    follow-up comment to this bug report. If you can't be
    bothered to log in, just stick your name and preferably
    email address at the bottom.

    Chris

     
  • Chris Cannam
    Chris Cannam
    2005-10-01

    Logged In: YES
    user_id=13489

    I'm sorry, I forgot the important part 4 of the
    suggestion.

    1. Rests are either auto-generated or manual. At the
      moment if you insert a rest, you get the same thing as
      if Rosegarden creates a rest for you. Either way it may
      be rearranged on the next edit. What I suggest is that
      Rosegarden always creates the rests for you -- perhaps
      they might change to not even being stored in the
      segment
      , although the thought is too radical for me to
      fully comprehend at the moment -- and then any rests
      you create or edit yourself become a different event
      type, the "fixed" rest, that could even show up in a
      different colour and that is treated as if it were a note
      by the automatic-rest algorithm.

    Advantages, disadvantages, creative nonsense sought.
    No more than three consecutive posts per user please.

     
  • Logged In: YES
    user_id=663564

    I like your thoughts so far WRT the user experience of being able to
    handily create some new segment and stick things into it for part
    writing. It would be useful if this could work retroactively, so that I
    could go back and layer compositions that are currently spread out
    onto multiple segments in multiple tracks.

    I haven't given a lot of thought to the rest issue, though at first glance
    the notion of having "hard" and "soft" rests seems appealing, much
    like hard page breaks vs. computed ones in a text editor, for example.

    Going beyond all of this to some of the other issues I've talked about, I
    want to throw in my "fold it up" idea for the record here.

    I thought this out at some length on the devel list, and hopefully you
    have a copy of that message on your hard drive already. The
    summary version, then, is that my approach to dealing with repeats
    and complex flow control issues reconciled with our fundamental
    nature as a MIDI sequencer is this:

    Deal with everything in a linear fashion on the segment canvas, the
    same way any user of any other MIDI sequencer would have to do in
    order to render a performance. If we start with a linear sequence of
    real events (even if the events are automatically copied into segments
    that are generated in similar fashion to the part writing scheme you
    discussed) then there's no need to physically move playback around
    when it hits a DS or what have you. It solves all the problems about
    not knowing which iteration of a multiple ending repeat we're on when
    the user presses play in bar 42. It even opens the door to allow for
    repeats that aren't physically identical, as is frequently the case in
    multi-verse lyric music, and thus, by extension, to multi-verse lyrical
    music as well.

    Friendliying up this stringing out process is probably the subject of a
    different debate entirely, and the heart of my thinking on this front is to
    invent some new form of directives that can be inserted into this linear
    progression in order to instruct the notation editor how to "fold up"
    three pages of events into a compact single page. Mark this section
    as the first ending, this as the second ending, mark the segno here,
    mark the coda there, and so forth, and have the notation editor
    interpret these things in order to produce a finished result.

    Using some kind of "fold it up" metaphor might open the door to easy
    multi-bar rests too. They could display for pages at a time if required,
    or on a single track, single staff view, they could compress down to
    one measure. Since pre-processing to figure out what to do with all
    these "fold here" directives would be necessary, this could easily be
    thrown into the pot, I think.

    It might be counterintuitive to edit like this initially, but Rosegarden isn't
    a notation interpreter, and this feels like a very plausible way to deliver
    complex notation capabilities to what remains fundamentally a
    sequencer-based model. It wouldn't please everyone, but a lot of
    those "everyone's" are really looking for something more like
    NoteEdit in the first place. Rosegarden isn't a notation interpreter, and
    can't reasonably be a notation interpreter at the same time it is a true
    sequencer.

    This whole concept probably makes exporting to Lilypond a horrible
    proposition, and I noticed that the guy looking to improve our Lilypond
    export was not terribly enthusiastic about any of this. I leave that
    question on someone else's priority list. I acknowledge that Lily looks
    better, but for my uses I'm perfectly happy with Rosegarden's existing
    output, and I would likely never use Lilypond at all (as, indeed, I don't
    currently use it at all.) Rosegarden by itself looks considerably better
    than any other notation producing package I've ever used (which does
    rule out the big dollar offerings like Sibelius and Finale, admittedly) and
    the results are really quite dramatically crisp and legible when
    compared with some real engraved scores I have about. Especially
    since I bought a printer that does a more faithful job of rendering what
    Rosegarden has been sending it all along.

     
  • Tommi Uimonen
    Tommi Uimonen
    2005-10-27

    Logged In: YES
    user_id=458329

    I encountered some problems when note durations are not
    exactly the same as the real duration of the event. For
    instance, one eight-note has duration 640, but event with
    duration 650 will still show as eight-note in the notation
    editor.

    I have a little suggestion that would be easy enough to
    implement and would help users to recognize if some bars
    don't have enough notes or have too many notes.

    ( I had many 7.5/8 bars and few 8.5/8 in a score and someone
    who was trying to play the score really went nuts because he
    had hard time learning them until he realized that some bars
    are not 4/4, he even suggested to BUY MAC and bashed linux
    for a while, but I got over it)

    The idea is to 'render' the notation back to events one bar
    at a time and then calculate if the rendered bar duration
    matches to the real duration; 3840 for 4/4 bar or whatever
    the time signature is for the current bar. Then color all
    notes with red that don't match with the event duration, and
    users can then easily see where the bogus bars are.

     
  • TubaSoldier
    TubaSoldier
    2006-10-29

    Logged In: YES
    user_id=1346914

    If you are serious about improving the notation editor then
    seriously look at the actual user interface. Coming from a
    Windows environment where notation editors are quite mature
    this is quite important in impressing and keeping new linux
    users.

    1 - The ability to input notes with the mouse is nice. Being
    able to use a midi keyboard is nice. However, Some of the
    computer keyboard shortcuts are extremely unintuitive. This
    opinion comes from not only using other notation editors,
    but also from trying to remember RG's shortcuts.
    For Example: ` should equal |o| - Double Whole note
    1 should equal o - whole note
    2 should equal a half note
    ect...
    Just keep them sequential.

    The numbers chosen to represent a duration are currently a
    pain in the rear.

    2 - Have the ability to use a computer keyboard for note
    input. Now I understand this can already be done by
    "playing" the keyboard. But I was thinking something more
    intuitive. RG has a nice cursor that moves horizontally
    through the music staves. I would suggest a much smaller,
    second "blinking cursor" that moves vertically. Assign some
    keys for note input and it would create a text editor for
    notation. (like ENTER or SPACE to acutally enter the note
    and/or vice versa for rests.) Of course since the up/down
    arrows are already in use for acutally moving a note some
    other keys would have to be assigned. Possibly the number pad?

    3 - keyboard shortcuts for drop down menus. Having to select
    a drop down menu every time I want to assign a clef to a
    track is rather cumbersome. Ease of use would be having
    letters or a combination of keys + a letter implemented to
    select these options. (shift, ctl, alt)
    For Example: k = key signature
    t = tempo or time siganture
    c = clef

    These are just a few ideas. I hope to see them acutally. The
    notation interface works but it takes a lot of time and
    getting used to. Using keyboard shortcuts that would make
    more sense to new RoseGarden users would ensure that they
    stay RoseGarden users.

     
  • Logged In: YES
    user_id=663564
    Originator: NO

    We should probably mine this one for the salient goals not yet reached, and then get rid of it.

     
  • Given the resources we have, I think we've probably reached the limit on how far we're going to be able to improve the notation experience. I'd still like to do proper alternative endings, have a better definition of what a bar is, and a few other things on a short list of pet projects, but the notation editor has more or less seen as many big sweeping improvements as it ever will during the massive rewrite effort. We added the ability to create a new "layer segment" quickly, we replaced a lot of the LilyPond hacks with real entities (like the coda symbol), we revamped the toolbar and added icons for a lot of actions that used to be available only through hard-to-discover keyboard shortcuts (the icons are useful in of themselves, and also serve to make the shortcuts discoverable). We made it easier to tell which segment you're editing. I did most of the work on that stuff myself, and I brought a lot of fresh ideas into the game. We didn't achieve everything we would have liked to, but you and I, Chris, aren't finding ourselves with more and more time for Rosegarden as time goes by. Sometimes you just have to step back and call something as finished as it's ever going to get, and I think the notation editor has pretty much reached that point. Not entirely, no, but the time for huge new thinking and sweeping improvements has probably drawn to a close, I'd say.