Both sides previous revision
Previous revision
|
|
dev:notation_layout_staff_types_etc [2010/10/17 02:53] jeanettewells |
dev:notation_layout_staff_types_etc [2010/10/17 03:20] michael repair vandalism |
makes life easier with [[http://www.bestessays.com.ua|essay papers]] and you will own your success! | |
| =====Notation layout, staff types etc===== |
| |
| [[http://sourceforge.net/mailarchive/forum.php?thread_name=200603080947.42888.ztraveler%40adelphia.net&forum_name=rosegarden-devel|Mail archive thread link]] (a long discussion about potential future changes) |
| |
| See also [[Notation editor improvement thoughts|Notation editor improvements]]. |
| |
| See also [[Score layout, not just notation layout]]. |
| |
| |
| |
| **Note: this is not a description of code actually in Rosegarden, it's part of a discussion about future work. |
| |
| That particular discussion didn't really go anywhere, but it's possible material for later.** |
| |
| |
| On Tuesday 21 Mar 2006 16:00, Michelle Donalies wrote: |
| > SingleStaff -- the traditional classical staff |
| > GrandStaff -- needs to know essentially the same stuff as |
| > SingleStaff. The only real difference is to which part (upper or lower) an event belongs. |
| > TabStaff -- normal tablature as found in books, with traditional notation above and tab lines below. |
| > CompactTabStaff -- only one part, with no traditional notation. |
| > PercussionStaff -- this is a different animal. Clefs and key sigs are completely absent. |
| > PercussionStaffLine -- like a PercussionStaff, but with only one line, which represents an "instrument" |
| > ChordStaff |
| |
| A good summary, thanks. |
| |
| So, how do these differ? |
| |
| The first thing that strikes me (given the recent thread, and my |
| comments in it) is that there are not many fundamental differences |
| between how these different staffs handle horizontal layout. |
| |
| I clipped some of your descriptions above, but I didn't see anything |
| substantial in there that couldn't be explained as "one staff shows |
| event type X but the other one doesn't". Since a staff already gets to |
| choose what events it selects from the underlying segment (via |
| Staff::wrapEvent), this suggests that nothing outside of the staff |
| itself should actually care whether a staff has (say) clefs and keys in |
| it or not. Time signature and bar lines (which are not events) are a |
| different matter, but it ought still to be a simple question of testing |
| a flag to determine whether to lay them out or not, for any staff type. |
| |
| However, there are certainly differences in implementation in |
| Rosegarden, many of which are caused by the current implementation of |
| NotationHLayout doing more than it should. These are examples of |
| things that appear to me to be really different and potentially |
| problematic: |
| |
| 1. Vertical layout. NotationVLayout could certainly be done by a staff |
| type rather than a layout class. Different staffs have quite different |
| vertical layout techniques and there's no call to reconcile between |
| them. (btw I'm also not sure that the NotationView's current code to |
| position the staffs on the page will do the right thing if the staffs |
| are of unequal heights.) |
| |
| 2. Accidentals. The current HLayout manages which of these are shown |
| and how they are spaced based on the current clef and key, which of |
| course may differ or disappear in other staff types. This is confined |
| to the HLayout::scanStaff area and would be easy to suppress, but it |
| would not be so tidy a thing to do as just suppressing the appearance |
| of clefs and keys for example. |
| |
| 3. The HLayout does several things which are not strictly its job at |
| all, such as assigning stem lengths for beamed groups. (Well, it |
| doesn't do these things itself, but it does cause them to happen.) It |
| does so just because it's in the right place: after vertical layout but |
| before horizontal positioning is finalised. A more correct |
| implementation would probably have an intermediate pass between |
| vertical and horizontal layout for these. This is again a fairly small |
| amount of code in the HLayout class, but it's untidy. |
| |
| 4. Properties calculated in the layout phase are stored in the Event |
| object, with names unique to the NotationView instance so that |
| different views can do different layouts (e.g. in different sizes, or |
| one in a page layout and another in a linear one). However, these are |
| View-specific, not Staff-specific. If it became possible to have the |
| same event on more than one staff in the same view at the same time, |
| this would break. |
| |
| I don't see any obvious disadvantages to refactoring 1, and I think 2 |
| and 3 are both candidates for things that could usefully be refactored |
| to improve the code even if we had no intention of adding any more |
| staff types in the first place, although there may be some tricky |
| details. Also I'm not especially happy with the way that beamed groups |
| and tuplets are handled anyway. (Our reconciliation of simultaneous |
| events on different staffs is quite good though, which is partly why I |
| took badly to your observation that doing anything better than |
| selecting the widest minimum spacing was "overkill" -- it isn't at all, |
| it makes a big difference and we do far better than that now.) |
| |
| > This still doesn't solve the basic disconnect with a staff representing a Segment rather than a Track. |
| |
| If you're thinking about that, then you might perhaps also think about |
| multi-voice staffs, for which the general underlying thought has been |
| that the user may choose optionally to show different segments (even on |
| different tracks) as different voices on the same staff, via some sort |
| of part arranger interface. Most of the basic layout code supports |
| this already. |
| |
| [ separate email, actually earlier ] |
| |
| The original idea for the HLayout and VLayout classes was to use |
| something like the "visitor" design pattern to separate out the layout |
| logic from the staff container or the low-level drawing functions (both |
| of which are either in, or invoked from, the staff class). This is not |
| so much because you might want to use more than one type of layout for |
| a given staff, as to keep the layout-related reasoning separate for |
| code management purposes. |
| |
| The fact that the things we want to do next aren't easily possible using |
| the current classes implies that something is wrong, of course, but I'm |
| not sure that making the staff class so much more complicated is a good |
| idea on the road to fixing it. |
| |
| Attached is a "whiteboard diagram" I sketched on paper (you can gather |
| that I'm still not getting much time at the computer to think about |
| these things at the moment). This shows the stages of the layout |
| procedure (from memory, so doubtless some omissions) with the classes |
| that currently carry them out. Start reading at top-left; the vertical |
| division is broadly into single-staff layout at top, multi-staff |
| reconcile and layout etc in the middle, drawing at the bottom. |
| |
| So, for each of the steps on this diagram, which is the most appropriate |
| class to do the work? Assuming for the moment that there's no |
| obligation to use the existing class structure (there is an obligation |
| effectively to use the existing _code_, but it can be rearranged at |
| will). It seems that the existing classes mostly do multiple tasks |
| that are not necessarily closely related but that share some of the |
| same data or domain knowledge (e.g. the HLayout class doing things with |
| beamed groups and accidentals), and there may well be a case for |
| pulling these things out into more than one class rather than just |
| changing which of the existing classes they go into. |
| |
| {{:whiteboard.jpg|}} |