#283 more staff grouping options

closed
notation (90)
9
2012-09-16
2006-09-16
No

The export to a, what, a system bracket I guess, is a
step in a good direction. I'd like to see this
expanded to something more flexible. Most
particularly being able to render a number of tracks
onto one grand staff. It would be nice to be able to
render a staff as cue size as a solo on top of a grand
staff too, though this is less important because cue
size can be achieved in a rude way through the
LilyPond directives mechanism.

Discussion

  • Heikki Junes

    Heikki Junes - 2006-12-20

    Logged In: YES
    user_id=30776
    Originator: NO

    Could one assign staff groups according to the colors of the first segments in the tracks?

    For example,
    - If the first segment in track 1 and 2 has the same color, they get a new staff group bracket.
    - If the first segment in track 3, 4, and 5 has the same color, they get a new staff group bracket.
    - etc.

    This kind of color coding of bracket groups would be able to present one-level bracketing, but not nested brackets, i.e. brackets inside brackets.

     
  • D. Michael McIntyre

    Logged In: YES
    user_id=663564
    Originator: YES

    Interesting idea, using color for this. It's perhaps not the ideal solution, but I've certainly established my own pattern of hijacking existing things to bring about something new with a minimum of effort.

    I think this idea passes that test, with one reservation. How will I use color to say "put these segments on a grand staff?" The easy thing seems to be to look for a treble and a bass clef, but I'm sure there's some piece for four hands out there somewhere that has the top two hands in treble and the bottom two hands in bass, or something similarly weird. It seems like you'd have to have some other way to specify you want these on a grand staff.

    That suggests a checkbox, and a checkbox suggests some whole new entirely more complicated mechanism for grouping staffs. What do you think about a track level grouping property?

    Offer some arbitrary fixed number of groups (because I'm too lazy to devise some infinitely extensible mechanism) and then dial tracks into those groups by number. Trumpets go into 1 and Horns go into 3 and so forth, and a [x] use grand staff checkbox in there somewhere.

    That seems plausible, not unreasonably complicated to tack into the Track Parameters and the Track class, but I'd probably rather avoid that complication if you can think of a clever way to say "use a grand staff" without a new checkbox and a whole new layer of infrastructure.

    We don't really want another widget in that overstuffed box anyway.

     
  • Heikki Junes

    Heikki Junes - 2006-12-21

    Logged In: YES
    user_id=30776
    Originator: NO

    Certainly, staffs should be grouped in track level. About other things, I am not certain. It is better to have a good specification before doing something that we do really not want to maintain.

    Why do the segments actually have possibility to carry different colors?

     
  • Chris Cannam

    Chris Cannam - 2006-12-21

    Logged In: YES
    user_id=13489
    Originator: NO

    This is an interesting subject and I think it's a really good idea to talk about this just now.

    You know of course that we don't have any staff groupings natively in Rosegarden. The main reason for this is not that the brackets or whatever are hard to represent internally or to draw, but that I failed to come up with a good way for the user to describe what groupings they wanted in the first place.

    If we can come up with a nice, friendly way of getting the user to describe how to arrange groups of staffs -- whether for Lilypond export or for Rosegarden natively -- then we've solved 90% of the problem of doing true score arrangements in Rosegarden, as well as 98% of the problem of doing score arrangements with Rosegarden and Lilypond together.

    So it's an important problem, and I think if we can decide on what the answer is, even if it involves real GUI work (and I think it will), it will happen.

    So I think the right question is the other way around -- not "what is the cheapest thing we can do in Rosegarden to make this sort-of work", but "how would my ideal piece of software solve this problem for me as a user"? The former question works well when you have a thing to do that's simple in concept but doesn't match well with Rosegarden's internals, as is the case with repeats for example. Here the problem is not the match with Rosegarden's internals -- there's no difficulty there -- but what the right GUI approach is in the first place.

     
  • Heikki Junes

    Heikki Junes - 2006-12-22

    Logged In: YES
    user_id=30776
    Originator: NO

    Certainly, tracks should grouped somehow. The process is in principle simple:

    1) Select tracks to be grouped.
    2) Assign a bracket for the group.

    For nested groups, there is one restriction:

    1.1) A group should contain its subgroups entirely.


    The simplest data structure is a singly-linked list:

    all <- violins <- violin 1
    all <- violins <- violin 2
    all <- violins <- viola
    all <- piano <- treble
    all <- piano <- bass
    etc.

    Each leaf has a property called "delimiter" which value is one of the following

    0) none
    1) staff group
    2) grand staff
    3) choir staff

    These groups are listed in section System staff delimiters of LilyPond manual, see

    http://lilypond.org/doc/v2.10/Documentation/user/lilypond/System-start-delimiters#System-start-delimiters

     
  • Chris Cannam

    Chris Cannam - 2006-12-22

    Logged In: YES
    user_id=13489
    Originator: NO

    Well, let's not worry about data structures at the moment -- the big question is what we should do in the GUI to allow users to manage this sort of grouping. As I said in my previous comment, I think this is the tricky part of the problem -- subsequently showing the actual groups, whether through Lilypond or natively in Rosegarden, is a smaller problem.

    My feeling is that this basically takes us most of the way to doing "score layout", and that's intimately associated with things like part extraction and allowing printouts of different groups and subsets of a given set of instruments. Is there a comfortable way of managing that sort of thing from within the track editor itself? Using a control to set a group name or number for each track would kind of work, but it's very unhelpful in terms of visual feedback, particularly if you want to switch from one set of groups to another.

    I rather think we probably want a separate score layout window, in which you can set up (and save and recall) layouts based on identifying tracks by name and choosing the groupings of tracks, and the staff size and so on for each track (with other properties [like the staff type?] that are actually associated with the physical instrument being taken from Track Parameters rather than being defined in the score setup window). It doesn't have to be insanely complicated, but it's obviously enough work that it would be better to get the ideas right first.

    Unless you think there is a comfortable way to do this in the existing track editor?

     
  • Chris Cannam

    Chris Cannam - 2006-12-22

    Logged In: YES
    user_id=13489
    Originator: NO

    And, such a window could also be used to specify that you want certain tracks to share the same staff. Thus putting us one step on the way to doing proper multi-voice staffs in Rosegarden as well.

    I think if we can get this bit done, it would lead in some pretty exciting directions.

     
  • Nobody/Anonymous

    Logged In: NO

    I guess I'm so lazy I can't even imagine what a score arranging window would look like. I can see myself using a "Group" combo box in the TBP somewhere, and being happy enough with that. Happier than just tacking this on the back of color. Better than some fixed list of numbers would be a fixed list of names, and better than either would be arbitrary, user-assignable names. Something like how picking instruments from the studio works, except this affects score layout and export, and isn't MIDI-related.

    I guess in a perfect world, there should be some tie-in between the instrument database and MIDI and the score layout and everything, so I pick an "Eb alto horn" for two tracks, and they magically get assigned to the same score group, and want to play with the same instrument and so forth. That's reaching further than I can think at the moment, with all the holiday nonsense I'm in the middle of.

    Just thoughts off the cuff more than anything I've carefully pondered.

    Ah hell. "Please log in."

    I'm not going to copy this somewhere, log in, then paste it back. SourceForge sucks in this respect, don't you think?

    You probably know who I am already, but in case it isn't obvious, I'm Michael stupid.

     
  • Pedro Lopez-Cabanillas

    Logged In: YES
    user_id=624187
    Originator: NO

    I like to see this discussion going on, and I have some ideas, so...

    Seems that we agree that this issue should be solved on a track basis, so there will be one or several new properties on Tracks describing how the track will be grouped, and other new score rendering attributes. As a first approximation, this suggest some new control(s) to the track parameter box. More on this later.

    The score layout window has been done before on some well known programs. The main point is that score layout should be a visual task, where you can see all the tracks at once, and see a how the score will look. The tracks can be represented as a set of single staves (one staff for each track) perhaps with the track name and the default key and clef. Like a clean preprinted music paper, similar to the ones that you can download from http://people.virginia.edu/~pdr4h/musicpaper/

    Well, but if the score layout window is a composition view, where you can see the tracks, it may be useful to include the track parameter box at the left of this view, and let the user to change the instrument or the key or any other track parameter while he is working on the score layout. At this point we can have a view with the list of tracks at the right part of the window, represented as staffs instead of collections of segments, and the properties panel at the left side. We have already this window: it is the track editor. Perhaps we only need to add a few new elements to our main window:

    • A score layout panel, that can be (de)activated at the same place of the track buttons and segments editor. Perhaps it may be inserted in-between, instead of replacing the track buttons, but in this case the track buttons should to be higher. The new panel having one row for each track, allowing the user to select one or several tracks at once. Each track is represented by a blank staff (no notes), but perhaps including the track or instrument name, and the default clef and key. If there is a selected track in the score layout view, the track parameters can be edited in the track parameters panel. I would like to see here some additional track parameters, related to the score layout: staff size and distance.
    • A staff group menu, with the supported staff styles: Grand Staff (Piano), Staff Group, Choir Staff, No group, Merge as voices into a single staff, Unmerge voices.
     
  • Heikki Junes

    Heikki Junes - 2006-12-23

    Logged In: YES
    user_id=30776
    Originator: NO

    I agree that merging voices into single staff is part of the problem:

    Compared to the current situation this would need
    - to have "Merge with track #number" option in the Track parameter box
    - to print two or more voices in the same staff in the Notation View
    - to mark one of the merged voices active in the Notation View
    - to mark other voices inactive in the Notation View
    - to present a mechanism to select one of the merged voices as the active one in the Notation View
    - to allow editing only the active voice in the Notation View while keeping other voices inactive

     
  • Heikki Junes

    Heikki Junes - 2006-12-23

    Logged In: YES
    user_id=30776
    Originator: NO

    I changed the category from lilypond to notation, as this is becoming an exciting discussion on how to improve the notation engine of Rosegarden.

    More generally, it would be nice to generate several views of the score. This is analogous of creating views of a database (see, for example, "create view" in mysql http://dev.mysql.com/doc/refman/5.0/en/create-view.html).

    That would require a new dialog whose name would be "Views". View could contain several tracks or other views, and have property "Group type", which would be one of "none, ChoirStaff, GrandStaff, StaffGroup".

    As an example, a bunch of possible views:

    View name: violins
    Group type: none
    Track 1
    Track 2

    View name: cello
    Group type: none
    Track 3

    View name: strings
    Group type: Staff group
    violins
    Track 4
    cello

    View name: solo
    Group type: none
    Track 5

    View name: piano
    Group type: Grand staff
    Track 7
    Track 6

    View name: all
    Group type: none
    solo
    strings
    piano

    It would be very nice to work with such kind of views.

     
  • Chris Cannam

    Chris Cannam - 2006-12-24

    Logged In: YES
    user_id=13489
    Originator: NO

    I think the problems with doing this in the track editor per Pedro's suggestion are:

    • There might not be a one-to-one relationship between tracks and staffs

    • The natural order for tracks (when composing and editing) might not be the same as that for staffs (when e.g. printing)

    • In general, score layout is something associated with arrangement and presentation rather than composition -- this means for example it's desirable to be able to switch from one arrangement to another (you don't have to be a very advanced user in order to want to print one part / the whole thing / one part in big with the rest in a smaller size / one part with the rest in a one-staff reduction / etc).

    • So far everything in this discussion has related fairly equally to both Lilypond output and Rosegarden-native score arrangements (which we don't do yet, but hopefully this should be a step toward). A (cowardly sort of) problem with doing the score arrangement in the track editor is that it would leave the GUI in a strange sort of half-way state if we didn't actually support all of it within Rosegarden's notation editor but only in Lilypond export. A separate arrangement window would work better in that situation.

    Re. Heikki's comment about the difficulty of merging staffs within RG -- yes, I agree, but this is the way I think we'd like to be heading anyway so let's not let that difficulty put us off adding support for it (though it does mean it might be better if we can do something that would be natural for Lilypond even if not yet wholly supported in RG natively as I mentioned above).

    Re. "views" -- that's the sort of thing I had in mind with a score layout window -- when I said "setup and save and recall layouts", I was using the word "layout" with the same sort of meaning as you're using "view". I've been sketching a few pictures on paper -- I'll attach or send some to the list at some point, but it won't be right away as I'm about to get stuck in to this Christmas malarkey. I haven't any definite or finished ideas though, so don't let me stop anyone else from adding their thoughts.

     
  • Chris Cannam

    Chris Cannam - 2007-01-05

    Logged In: YES
    user_id=13489
    Originator: NO

    Attaching an image roughly scanned (OK, photographed) from some diagrams on bits of paper... such a pointless fusion of technology old and new.

    I was just starting to sketch what I thought a score management dialog might look like and what it should be doing. It also seems to be related to the "new composition" dialog, so there are some notes about that.

    I'm thinking of a "score" as being a useful term to denote the association of one or more (but not necessarily all) tracks from a composition, in a particular order, with up to the same number of staffs of some configurable type. There may therefore be many possible scores representing some or all of a given composition. (You can argue that only one of those is "the score" and the others are parts or arrangements, but I think we can get away with the terminology for the moment.)

     
  • Chris Cannam

    Chris Cannam - 2007-01-05

    Ramblings about score management dialog

     
  • Chris Cannam

    Chris Cannam - 2007-01-05

    Logged In: YES
    user_id=13489
    Originator: NO

    File Added: rambling.jpg

     
  • D. Michael McIntyre

    Logged In: YES
    user_id=663564
    Originator: YES

    It's fun reading back over this lively and detailed discussion, but over a year since I submitted the original request, nobody has done anything at all.

    I didn't find this while I was brainstorming, so I have taken a whole fresh look at what I actually want to be able to accomplish in the real world, what I can't accomplish without hacking LilyPond manually, and the easiest path to making Rosegarden capable of bridging the gap for me. No grand, idealistic visions here, just dirty street hacking. What I plan to implement is another set of "blind" LilyPond only features that we could and should one day apply to our own native layout, but I will settle for more blind features as better and more useful than nothing in the undoubtedly long interim.

    I've started a staff_group_hacking branch to work on this, and I'm not very organized yet, and there's nothing to see there so far. I've stepped back from my first blind forrays to take a look at where I'm trying to go with this, and I have a plan, but it's too loose to really lay out in firm terms at this time. I don't think there's much danger that I'm going to code myself into any corners that are hard to escape though, so I feel free to wing it, and if it's all crap, I just won't ever merge to trunk/.

    I have in mind one track control for staff bracketing type, of which the most obvious example is a grand staff, and I want this to work in such a fashion that you can produce something like this example score:

    http://www.mutopiaproject.org/ftp/BeethovenLv/O67/Symphony5_1/Symphony5_1-preview.png

    Then another track control for staff size, so you can do the cue size solo with piano bit and that sort of whatnot.

    I'm not planning any groups or arrangements or layouts, and I'm intending to leave 100% of the work of putting what in what order or deciding what to print as which selection in the user's hands. That's currently what we have anyway, and it passes the acid test of being good enough, if a bit tedious. "Good enough, if a bit tedious" is kind of the Rosegarden trademark. So I'm just going to add some new options on top of the existing simple framework, and not aim for the sky.

    I never reach the sky, but I do get dirty done.

    For example, the dirty approach to having one score that prints five different ways is to just use five different sub-groups of copies, and manually export each sub-group. Not pretty, but plausible, and we have lots of examples of this already too. Like dealing with a part that has nested repeats and a DC and a coda section. You have to use two different sets of tracks to get that to come out right; one for printing, one for playing.

    Anyway, I'm not writing out a grand master plan here so much as leaving a note to say that while I am taking this feature request to implement, that doesn't mean I'm any kind of thinking of taking it to some of the heights described in this comment thread.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks