Hi Maurizio, I think what I've done so far is broadly along the lines you describe. As has been noted, what I've done so far can be seen on a branch here: https://github.com/shadowphiar/MuseScore/tree/capo-chords Incidentally, I'm quite happy if somebody else does implement this first - you'll probably do it more quickly as I'm unfamiliar with the MuseScore code - but wanted to have a go myself as it's a feature I want to use!
(My focus is on the rendering of Harmony elements on pitched staves, but I can see that implementing a capo's effect on TAB staves would be very useful as well. It seems to me that this is a distinct enough part of the problem, that once step 4 (below) has been implemented, anybody else could work on this independently of anything I do with the harmony rendering.) Maurizio M. Gavioli wrote > I think: > > 1) Capo should be an object of its own, derived from Element My CapoText object is derived from Text, which is derived from Element. (I wondered if under some circumstances people may want to edit the text which is displayed? Not really sure if I can come up with a concrete use case for that, but I couldn't rule it out either). Maurizio M. Gavioli wrote > 2) As for its position in the score hierarchy, I would look at how Clef > elements are currently managed. This presumably means adding a Segment to > hold Capo's (in the _elist list). But I'm quoting from memory: the source > code is the ultimate reference here! At the moment, it's going into the same Segment as the chord it is attached to (like Tempo does). Is this a problem? Maurizio M. Gavioli wrote > 3) It should be related to a staff and to a time tick; this means: > 3a) its _track member (inherited from Element) should be set to the id of > first track of the relevant staff upon object creation > 3b) the _tick member of the holding Segment would be initialized to the > time position; in the 'simple' implementation, it would always be set to 0 > (or simply ignored), but could be leveraged later to indicate any time > position. Agreed. I'll double check, but I think both of these are happening already. Maurizio M. Gavioli wrote > 4) There should be functions to retrieve the Capo active for a given staff > and for a given tick. Currently, for Clefs, those functions are methods of > Staff (Staff:addClef(), Staff::removeClef(), Staff::clef() ); Staff also > maintains a list of clefs relevant to it (Staff::clefs). I have no clear > idea if this is suitable for Capo too or if rather it should be accessible > at Score level (with methods like Score::addCapo(int track, int tick), > capo(int track, tick) and so on). These would be the functions used by > StaffTypeTablature and Harmony to get Capo info, if present. This is probably the next thing that I have to look at implementing. I will have a look at Staff, and at TempoMap which was mentioned earlier in the thread; and either extend one of them to hold more generic information or implement a new similar mechanism, depending on what seems most sensible. Maurizio M. Gavioli wrote > 5) Staff also has the concept of "initial clef"; I suspect this not to be > necessary for Capo; it is true that the 'simple' implementation would only > have Capo at the beginning, but I think the initial clefs are used mainly > in the creation of new instruments (there is no "initial time sig", for > instance). I agree most scores will not need a Capo object to exist. Maurizio M. Gavioli wrote > 6) It could be useful to have a text member (SimpleText?), where a text > could be stored to be displayed in the score; in this case, I would > suggest also adding a specific "Capo text" text style. This may be > considered optional, initially, but I expect many users of the Capo > feature would ask for it. Yes, I am working on the assumption that there will be a text style associated with the element. (Equally though, happy to use an existing style if it is considered that the user is getting overloaded with numerous text styles for infrequently-used elements). Thanks for all the input. I'll look into point 4 and see where it gets me. Thanks, Andrew -- View this message in context: http://dev-list.musescore.org/Capo-support-in-tablature-tp7577937p7577972.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
