FWIW, as the one who coded most of the tab feature, I second lasconic in his opposition to anything tied to a specific instrument; for instance, the piano Ped. feature is there, but it is not specifically tied to a staff being a piano staff, for it being used or usable (the user is ultimately responsible for using each feature when it musically makes sense!).
I am not very familiar with modern plucked string usages (my background is more on Renaissance and early Baroque instruments), but I am not immediately convinced that the capo concept applies to this case, even a "capo independent for each string" concept. If I am not mistaken, capo ultimately works in the other direction: with a capo on the, say, 3rd fret, the fourth fret would be numbered 1. I suspect that having an additional parameter for each string, holding a numerical offset to the resulting fret value, might be one way to go, but I have not given *a lot* of thinking to this. This would affect how a computed fret value is turned into a textual representation. I also suspect that: 1) this feature should be incompatible (non-available or automatically set to 0) with the "open" flag 2) it should be separate from a (future) capo feature, but interact with it, as the latter may override the former. Examples: As far as I understand the 5-string banjo case, normally there is a delta of +5 between the first string and the other; assuming a capo on the 1st, 2nd, or 3rd fret, this delta would be reduced to +4, +3, +2 and so on. But from the 5th fret on (capo on the 5th, 6th, ..., fret), the progression does not continue and the delta remains fixed at 0. ___________________________ Another, different, view could be to introduce the concept of "minimum available fret"; in this view, the first string of the 5-string banjo would be tuned on 4th lower than 'G' (at least internally, the value actually displayed to the user in the string table might be adjusted) and frets from 0 to 4 simply non-existent, not usable. This would affect which note can actually be assigned to which string (and, in fact, in this banjo case, it is not possible to place, say, an F# at the 4th fret of the first string: that fret does not exist!). ___________________________ The points IMHO most important to keep in mind while designing this feature (and to choose between these two views above or any other one might think of) are the usual: performance and code maintainability. *Performance*: the validity of the cached fret value and its textual representation are computed each time a layout takes place (as a rule of thumb, each time something changes somewhere in the score); the fret value itself is re-computed less frequently, only if the cached value, once checked, turns out to be no longer valid. But please note: if the note belongs to a chord, the invalidity of a single note triggers the recomputing of all the fret values of the chord. So, all these routines should be as streamlined as possible, with a little preference for the two former steps (validity check and string). *Maintainability*: this has to do with proper commenting, meaningful symbols names and so on, as usual. But also with keeping as much as possible with coding patterns and paradigms already used in the rest of the code base (the whole of it, not only the tab feature), to reduce the numbers of "minds" and habits required to understand the code. Thanks, M. -- View this message in context: http://dev-list.musescore.org/Tablature-question-how-to-determine-if-in-a-5-staff-line-banjo-tab-or-not-tp7579658p7579690.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ Mscore-developer mailing list Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer
