| 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|}} |
