[trunk] Figured bass: next steps?
Locked
 
|
Hi,
First of all, thanks to Werner for starting implementing support for B.c.! As a base is now in place, I have thought a little about it, in particular how to make it visually correct, easy to enter and, to some extent, parsable. As I see it, it is better to assume F.b. elements, like current Harmony elements, follow some 'rules', allowing some degree of separation between the 'meaning' and the visual form. As for Harmony elements, (at least) two ways are possible: 1) User-editable text separated from 'surface rendered' text. This is mainly oriented to quick data entering. A FiguredBass element maintains TWO 'texts': a 'structure' text and a 'display' text (actually the structure text may be internally stored as a set of properties rather than a real text). The structure text recognizes, for instance, the following 'vocabulary': "0-9 / \ + # b h ( )" and constructs a visible text replacing: *) 'b', '#', 'h' with flat, sharp and natural signs resp. *) a digit (0-9) followed by either '/', '\', '+' with compound symbols. A score style parameter controls whether 'modern' symbols are used (slashed figures and figures-plus-cross) or 'historic' symbols ('swashed' figures and 'crossed' figures). *) parentheses with a _parenthesized member flag. While editing, the structure text is shown: this text is easy to type, being made only of characters present in all (?) keyboards, and to understand (of course, having some notions of B.c.!). Upon leaving editing, the structure text is parsed and the display text is constructed from it and displayed. The layout applies to the display text and manages vertical alignment and continuation lines (see below). In principle, properties like base, root, degrees, etc could be extracted from the structure text (and the current bass note) and made available (of course, assuming the cyphering follows some standard practice). Any structure text which does not follow the 'rules' is left as it is (to cope with the inevitable odd case, always possible with music notation). 2) Set of harmonic properties. A FiguredBass element also has (an array of) sets of formalized properties (figure, alteration, parenthesized, ...). A dlg box -- similar to the Harmony Properties dlg box -- allows to access and modify these properties in a controlled environment. From these properties, a display text (and possibly a structure text) are constructed. Question: 3) Currently FiguredBass derives from Lyrics. I assume there have been reasons for this, but I think that Harmony would be a better base class, as it provides most of the required machinery, either directly or via method re-implementation. Worth re-thinking? Notes: 4) Duration. A FiguredBass element (or the segment it is attached to) also has to have a duration (again, as Harmony elements). In the current Harmony implementation, it is possible to enter more than one chord name in sequence under a 'long' bass note, as long as some other part moves. This is good, but there seems to be no way to enter a chord name at a tick where no part moves. A way-around is to add another voice (in the MuseScore sense) with the required rhythm, entering the chord name at the proper point, delete the added voice. It works, but it is cumbersome. It would be better to have a way to explicitly set the required duration (in the minority of cases when it is needed), for instance through the note value palette (currently disabled during text entering and which could be enabled). 5) Continuation lines. This is the only point -- I think -- where Lyrics implementation provides an element not provided by (or not sub-classable from) Harmony. It could be copied over (with some modification) from Lyrics. Cont. line length is linked to the F.b. element duration (see above). 6) Glyphs. A sample font is attached; in it, I tried to: *) match (well, copy!) the shapes for digits of the main MuseScore font; *) provide modern and historic shapes; *) occupy enough of the em height to have a good looking vertical advance by a simple newline; *) avoid Unicode points outside BMP for simplicity. The font is usable (I have used it), but can be improved. 7) MusicXML. I do not know enough of MusicXML to know of any specific requirement to import/export F.b.: please advise! 8) Lilypond: same as above. But is Lilypond input/output actively maintained? 9) Finally, I think I can implement most of the above myself (possibly, with some help from the guru(s) here and there...), if the PTB (<g>) trust me enough... Comments, corrections, additions, etc... welcome, of course! Thanks, M. mscore-20_BC.ttf |
|
I know almost nothing about Figured Bass, except it's a popular
request, so forgive any misunderstanding. Some thoughts : - Figured Bass is implemented on Lyrics mainly for spacing issue I assume. Currently only Lyrics space out nicely horizontally and vertically. And they offer continuation line. - Having an internal representation of FiguredBass like we have for Harmony means we want to go further with it right? Putting aside the fact that we need a way to enter them, will figured bass be transposable? Playable? - Regarding the font, what's wrong with the current one from Matthew Hindson ? - Regarding Harmony entry, implementation differs in the trunk and in MuseScore 1.X. Currently, there is no way to enter several chords on a single note. In 1.1, harmony entry goes note by note or beat by beat, depending which one is the closest. It makes Harmony entry a lot faster than having a real new voice and having to specify duration everytime. Of course, it's also less powerful. I favor the 1.1 behavior but I don't know how it would apply to FiguredBass. - Regarding MusicXML : http://www.recordare.com/musicxml/dtd/note-module Search for figured-bass. And here is a MusicXML example : http://kainhofer.com/musicxml/69/lily-e19b6b11.xml One interesting thing is that they are stored in column, one figured-bass element having several figures element and a duration. - I would not worry about Lilypond export (Import is already removed) just now. If we have MusicXML export right, Lilypond users can use music2ly. Hope it helps, Lasconic 2012/2/11 Miwarre <[hidden email]>: > Hi, > > First of all, thanks to Werner for starting implementing support for B.c.! > > As a base is now in place, I have thought a little about it, in particular > how to make it visually correct, easy to enter and, to some extent, > parsable. As I see it, it is better to assume F.b. elements, like current > Harmony elements, follow some 'rules', allowing some degree of separation > between the 'meaning' and the visual form. > > As for Harmony elements, (at least) two ways are possible: > > > 1) User-editable text separated from 'surface rendered' text. > > This is mainly oriented to quick data entering. A FiguredBass element > maintains TWO 'texts': a 'structure' text and a 'display' text (actually the > structure text may be internally stored as a set of properties rather than a > real text). > > The structure text recognizes, for instance, the following 'vocabulary': > "0-9 / \ + # b h ( )" and constructs a visible text replacing: > *) 'b', '#', 'h' with flat, sharp and natural signs resp. > *) a digit (0-9) followed by either '/', '\', '+' with compound symbols. A > score style parameter controls whether 'modern' symbols are used (slashed > figures and figures-plus-cross) or 'historic' symbols ('swashed' figures and > 'crossed' figures). > *) parentheses with a _parenthesized member flag. > > While editing, the structure text is shown: this text is easy to type, being > made only of characters present in all (?) keyboards, and to understand (of > course, having some notions of B.c.!). > > Upon leaving editing, the structure text is parsed and the display text is > constructed from it and displayed. The layout applies to the display text > and manages vertical alignment and continuation lines (see below). In > principle, properties like base, root, degrees, etc could be extracted from > the structure text (and the current bass note) and made available (of > course, assuming the cyphering follows some standard practice). > > Any structure text which does not follow the 'rules' is left as it is (to > cope with the inevitable odd case, always possible with music notation). > > > 2) Set of harmonic properties. > > A FiguredBass element also has (an array of) sets of formalized properties > (figure, alteration, parenthesized, ...). A dlg box -- similar to the > Harmony Properties dlg box -- allows to access and modify these properties > in a controlled environment. From these properties, a display text (and > possibly a structure text) are constructed. > > > Question: > > 3) Currently FiguredBass derives from Lyrics. I assume there have been > reasons for this, but I think that Harmony would be a better base class, as > it provides most of the required machinery, either directly or via method > re-implementation. Worth re-thinking? > > > Notes: > > 4) Duration. A FiguredBass element (or the segment it is attached to) also > has to have a duration (again, as Harmony elements). > > In the current Harmony implementation, it is possible to enter more than one > chord name in sequence under a 'long' bass note, as long as some other part > moves. This is good, but there seems to be no way to enter a chord name at a > tick where no part moves. > > A way-around is to add another voice (in the MuseScore sense) with the > required rhythm, entering the chord name at the proper point, delete the > added voice. It works, but it is cumbersome. > > It would be better to have a way to explicitly set the required duration (in > the minority of cases when it is needed), for instance through the note > value palette (currently disabled during text entering and which could be > enabled). > > 5) Continuation lines. This is the only point -- I think -- where Lyrics > implementation provides an element not provided by (or not sub-classable > from) Harmony. It could be copied over (with some modification) from Lyrics. > Cont. line length is linked to the F.b. element duration (see above). > > 6) Glyphs. A sample font is attached; in it, I tried to: > *) match (well, copy!) the shapes for digits of the main MuseScore font; > *) provide modern and historic shapes; > *) occupy enough of the em height to have a good looking vertical advance by > a simple newline; > *) avoid Unicode points outside BMP for simplicity. > The font is usable (I have used it), but can be improved. > > 7) MusicXML. I do not know enough of MusicXML to know of any specific > requirement to import/export F.b.: please advise! > > 8) Lilypond: same as above. But is Lilypond input/output actively > maintained? > > 9) Finally, I think I can implement most of the above myself (possibly, with > some help from the guru(s) here and there...), if the PTB (<g>) trust me > enough... > > > Comments, corrections, additions, etc... welcome, of course! > > Thanks, > > M. > > http://musescore-developer.685061.n2.nabble.com/file/n7275860/mscore-20_BC.ttf > mscore-20_BC.ttf > > > -- > View this message in context: http://musescore-developer.685061.n2.nabble.com/trunk-Figured-bass-next-steps-tp7275860p7275860.html > Sent from the MuseScore Developer mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Mscore-developer mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/mscore-developer ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mscore-developer mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
|
|
I have entered the f.b. for a few pieces (trunk) using Harmony rather than Lyrics and I found no spacing issue. F.b. figures are in average shorter than some of the bulky chord names I have seen used: if Harmony can accommodate them, it can accommodate F.b. too. Support for continuation lines is lacking in Harmony, this is true, and should be copied over from Lyrics. However, some changes are anyway required; for instance, cont. lines may stop at arbitrary places, even when the following note has no F.b. figures, which current Lyrics implem. does not support, I think. These are the reasons why I do not see a compelling reason to derive from Lyrics and many to derive from Harmony. This is the idea! Playable: I think definitely not: automatic basso continuo realization is way beyond the scope of current MuseScore implementation (it would require hard-wiring several entire harmony treatises and could raise the obvious question: does automatic continuo realization make any sense?) Transposable: maybe: figures in themselves are transparent to transposition (a 6 or a 6+ remain the same after transposition); accidentals might be more complex, as they involve the conventions adopted, which are not constant. But, often they are transparent too. Hindson has been very kind to lend his font for MuseScore. However, it does not match MuseScore digit shapes (which happen to be the shapes commonly used in printed B.c. music!); it does not contains some of the historic shapes; it is complex to enter, with its multi-level figures. I have not attempted to enter F.b. in 1.1. I have at hand an early XVIII c. Italian trio sonata I just entered in trunk using Harmony: it has 188 continuo figures; of them a dozen are not on a bass note AND out of a beat; 6 are placed where no part moves. As I see it, only in these last 6 cases it would have been necessary to specify an explicit duration; for the other 182, the current trunk Harmony implementation is fine. Interesting! Because this is more or less exactly what I had in mind. Thanks for the link! Good! It does indeed! Thanks, M. |
Re: [trunk] Figured bass: next steps?
|
In reply to this post by Miwarre
Miwarre,
do not worry about MusicXML support for figured bass. I can do that (was on my list of things to do anyway) or assist anyone who is willing to work on it. May take some time though, as I am now focusing on 1.2, as the issue list shows. I also still need to sync a number of fixes from the branch to the trunk. Leon. |
|
|
Thanks Leon! My concern at the moment is to get things right since the beginning and having all data, info, ..., which can be reasonable useful; so I'll have a look at the MusicXML support for F.b. anyway. Oh don't worry, it is not going to happen overnight... Thanks, M. |
|
|
Hi,
A note just to let everybody know I'm trying to advance a few steps in the F.B. The attached screen shot shows a sample of where I am now: it shows a non-trivial F.B. figure combination as formatted for display (on the left) and as input (on the right). The idea was to allow to enter complex shapes as simply as possible through the keyboard, without exoteric key combinations or cumbersome symbol dragging. The numbers hardly make any musical sense: it was mostly a test for alignment and glyph combining (more modern forms are also available). I have tried not to touch at anything outside the figuredbass.cpp/.h files, to avoid side effects as much as possible (I mostly succeeded), also keeping FiguredBass derivation from Lyrics. Still missing: continuation lines, placing chord figures on arbitrary ticks (currently only possible rightly below staff notes), some additional UI for style parameters. I'm afraid I will need some help for these points... Then, a question, for those more knowledgeable than me: I noticed there seem to be two ways for vertical positioning Lyrics/FiguredBass items: 1) via the Score::styleS(ST_figuredBassDistance) parameter of 'global score' style 2) via the TextStyle::offset() or TextStyle::offset(qreal spatium) parameter of the individual text style. Is there any policy for preferring one way or the other? I think I understand both but I am not sure which one to use. Thanks, M. trunk_figuredbass_test_1.png |
|
|
Hi,
Having got my feet wet on figured bass impementation, I think I have a clearer picture of some details. In previous posts of this thread, lasconic and I, we discussed about deriving FiguredBass from Lyrics or from Harmony; I now think class hierarchy to be secondary. The major point is rather: Should FiguredBass elements be stored: A) as sub-elements of a ChordRest (like Lyrics) or B) as sub-elements of a Segment (like Harmony)? The major differences are: A1) pro: it is easier to space chords horizontally to accommodate the width of added elements A2) con: it is more complex (impossible?) to place figured bass where there is no chord in that part. B1) pro: it is very easy to place figured bass at any tick when any of the parts has a segment (typically, a chord) and I think it is possible to add a new segment for f.b. even at a tick when no part has one. B2) con: it is more complex (impossible?) to space chords nicely to accommodate largish symbols or texts below the notes. I think A2) limitation to be definitely worse than B2) limitation: nice spacing is a thing nice to have, of course, perhaps *very* nice to have. But if it not possible to place a figured bass element whenever one is needed, the whole feature is jeopardized. (Just to give an example [quick count, may be off of a few units]: in the first sonata of Corelli's Op. 3 (ed. Komarek 1698), there are 356 f.b. indications, 300 on a bass note, 56 (ca. 1/7) off of any bass note) So, I think FiguredBass elements should be moved from belonging to a ChordRest to belonging to a Segment, probably in _annotations (or in _elist?) Does anybody see reasons against this? As for class hierarchy, as figured bass notations are made of just text (and have no reason to contain any formatting), deriving from SimpleText will be probably enough. As always, any feedback is welcome! Thanks, M. |
Re: [trunk] Figured bass: next steps?
|
On Feb 22, 2012, at 5:00 AM, Miwarre <[hidden email]> wrote: Should FiguredBass elements be stored: A) as sub-elements of a ChordRest (like Lyrics) or B) as sub-elements of a Segment (like Harmony)? I agree that the awkwardness in placing chords at ticks with no notes makes B) the better choice overall. However, it's not impossible; many of us had workarounds for placing chords at note-less positions - eg, use of invisible notes in another voice, or placing multiple chords on "1" then dragging them into position. So it's at least conceivable that the potential for easier automatic spacing could give the nod to A). But really, I'd stll rather see B), and then have some work eventually go into finding a way for both chords and figured bass to affect spacing. Improving automatic layout, and collision avoidance in particular (chords, text, articulations, slurs, hairpins, etc) is probably a major project, but one worth undertaking at some point. -- Marc Sabatella ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mscore-developer mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
|
|
Hi,
I have a patch ready which extends FiguredBass implementation; it is not 100% complete, but it should be testable / usable and cover most uses. I can either provide the patch or directly commit it: please advise. If somebody with the needed authorisation (Thomas?) could add a new "Figured Bass" page to the Handbook's "New features for MuseScore 2.0" section, I will add some preliminary usage instructions. Description: I decided to go with FiguredBass elements attached to Segment's (in _annotations; solution B of previous post). Each FiguredBass element contains all the (1, 2 or 3; rarely more) 'stacked' notations making up a f.b. indication. Each notation (a digit, an accidental, or a combination of them) is implemented by a FiguredBassItem. What is there: *) FB elements can be placed whenever at least one part (not necessarily the part to which FB is added) already has notes (like Harmony does now). *) FB elements can be entered from keyboard (including accidentals and slashed / crossed shapes, which are entered as digit + suffix and combined internally). *) Individual items (each FB 'digit') are parsed into properties (harmonic and typographic; in theory, the corresponding note/chord could be computed). *) Supported accidentals: the 5 'standard' accidentals, before of after. *) Supported suffixes (for combined shapes): cross, backslash, slash. *) Supported parentheses: open and closed parenthesis, both round and squared (brackets). They can be applied to any component (accidental, digit, suffix, even to continuation lines). *) Items are correctly aligned vertically and horizontally (including accidentals and parentheses 'hanging' at the left or right of the main character). *) Continuation lines can be entered and are stored, but not properly formatted yet. *) A font matching the digit shapes of the MuseScore main font, with modern and historic combined shapes. Parts still missing: *) No way yet to set the duration of a FiguredBass element, if different from the chord under which it is placed (this is required for proper continuation line formatting). *) Proper cont. line formatting (currently, a 'symbolic', token short line is appended, only to confirm the line is there). *) Styles (at least: above/below selector, staff-FB dist., line height, modern/historic selector): in "Styles | General styles | Page", like Lyrics styles currently are? Or in a tab of its own? *) Moving font info and encoding to a configuration file (currently, these data are hard-coded in figuredbass.cpp). Added files: *) mscore\fonts\mscore-BC.sfd/.ttf: new font Summary of changed files: *) mscore\libmscore\figuredbass.cpp/.h: main implem./def. files *) mscore\libmscore\chordrest.cpp: removed references to figured bass in ChordRest::readProperties(), ChordRest::add() and ChordRest::remove() *) mscore\libmscore\measure.cpp: added reference to figured bass in Measure::read() *) mscore\libmscore\segment.cpp: added FIGURED_BASS case to Segment::add() and Segment::remove() *) mscore\libmscore\style.cpp: changed figured bass default style to use the new font *) mscore\mscore\actions.cpp: changed FB default shortcut to [Ctrl][G] (as in "fiGured bass"!) *) mscore\mscore\keyb.cpp: keystroke mngmt for FB separated from Lyrics' keystrokes *) mscore\mscore\scoreview.h: added figuredBassEndEdit() and figuredBassTab() prototypes *) mscore\mscore\scoreview.cpp: added call to figuredBassEndEdit() in ScoreView::endEdit() Reference to new font added to: *) mscore\libmscore\mscore.cpp *) mscore\mscore\CMakeLists.txt *) mscore\mscore\musescore.qrc *) mscore\mtest\mtest.qrc *) mscore\player-qt\mscoreplay.qrc Thanks, M. |
|
|
Looks great!
I will let Werner answer about the commit. Regarding the handbook page, I don't have the rights to create a page out of the handbook and that's how MuseScore 2.0 pages are created, except http://musescore.org/en/handbook/custom-palettes This page should be removed from the handbook book to work nicely with the PDF creation. As suggested a couple of time, it would be great to create a new book from scratch for 2.0. Unchanged stuff will be copy pasted. Lasconic 2012/2/26 Miwarre <[hidden email]>: > Hi, > > I have a patch ready which extends FiguredBass implementation; it is not > 100% complete, but it should be testable / usable and cover most uses. > > I can either provide the patch or directly commit it: please advise. > > If somebody with the needed authorisation (Thomas?) could add a new "Figured > Bass" page to the Handbook's "New features for MuseScore 2.0" section, I > will add some preliminary usage instructions. > > Description: > > I decided to go with FiguredBass elements attached to Segment's (in > _annotations; solution B of previous post). Each FiguredBass element > contains all the (1, 2 or 3; rarely more) 'stacked' notations making up a > f.b. indication. Each notation (a digit, an accidental, or a combination of > them) is implemented by a FiguredBassItem. > > What is there: > > *) FB elements can be placed whenever at least one part (not necessarily the > part to which FB is added) already has notes (like Harmony does now). > *) FB elements can be entered from keyboard (including accidentals and > slashed / crossed shapes, which are entered as digit + suffix and combined > internally). > *) Individual items (each FB 'digit') are parsed into properties (harmonic > and typographic; in theory, the corresponding note/chord could be computed). > *) Supported accidentals: the 5 'standard' accidentals, before of after. > *) Supported suffixes (for combined shapes): cross, backslash, slash. > *) Supported parentheses: open and closed parenthesis, both round and > squared (brackets). They can be applied to any component (accidental, digit, > suffix, even to continuation lines). > *) Items are correctly aligned vertically and horizontally (including > accidentals and parentheses 'hanging' at the left or right of the main > character). > *) Continuation lines can be entered and are stored, but not properly > formatted yet. > *) A font matching the digit shapes of the MuseScore main font, with modern > and historic combined shapes. > > Parts still missing: > > *) No way yet to set the duration of a FiguredBass element, if different > from the chord under which it is placed (this is required for proper > continuation line formatting). > *) Proper cont. line formatting (currently, a 'symbolic', token short line > is appended, only to confirm the line is there). > *) Styles (at least: above/below selector, staff-FB dist., line height, > modern/historic selector): in "Styles | General styles | Page", like Lyrics > styles currently are? Or in a tab of its own? > *) Moving font info and encoding to a configuration file (currently, these > data are hard-coded in figuredbass.cpp). > > Added files: > > *) mscore\fonts\mscore-BC.sfd/.ttf: new font > > Summary of changed files: > > *) mscore\libmscore\figuredbass.cpp/.h: main implem./def. files > *) mscore\libmscore\chordrest.cpp: removed references to figured bass in > ChordRest::readProperties(), ChordRest::add() and ChordRest::remove() > *) mscore\libmscore\measure.cpp: added reference to figured bass in > Measure::read() > *) mscore\libmscore\segment.cpp: added FIGURED_BASS case to Segment::add() > and Segment::remove() > *) mscore\libmscore\style.cpp: changed figured bass default style to use the > new font > *) mscore\mscore\actions.cpp: changed FB default shortcut to [Ctrl][G] (as > in "fiGured bass"!) > *) mscore\mscore\keyb.cpp: keystroke mngmt for FB separated from Lyrics' > keystrokes > *) mscore\mscore\scoreview.h: added figuredBassEndEdit() and > figuredBassTab() prototypes > *) mscore\mscore\scoreview.cpp: added call to figuredBassEndEdit() in > ScoreView::endEdit() > > Reference to new font added to: > > *) mscore\libmscore\mscore.cpp > *) mscore\mscore\CMakeLists.txt > *) mscore\mscore\musescore.qrc > *) mscore\mtest\mtest.qrc > *) mscore\player-qt\mscoreplay.qrc > > Thanks, > > M. > > -- > View this message in context: http://musescore-developer.685061.n2.nabble.com/trunk-Figured-bass-next-steps-tp7275860p7319772.html > Sent from the MuseScore Developer mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Mscore-developer mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/mscore-developer ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mscore-developer mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
Re: [trunk] Figured bass: next steps?
Administrator
|
@lasconic http://musescore.org/en/handbook/custom-palettes is removed from the handbook outlines
@miwarre I added the Figured Bass page to the handbook, see at the bottom: http://musescore.org/en/handbook I'll make a new content type this week on musescore.org to kick off the handbook for MuseScore 2.0 |
Re: [trunk] Figured bass: next steps?
|
In reply to this post by Miwarre
Hi Miwarre,
Great work! Please commit your patch directly. For style options i would suggest to create a dedicated tab for FiguredBass. Werner On 02/26/2012 08:39 PM, Miwarre wrote: > Hi, > > I have a patch ready which extends FiguredBass implementation; it is not > 100% complete, but it should be testable / usable and cover most uses. > > I can either provide the patch or directly commit it: please advise. > > If somebody with the needed authorisation (Thomas?) could add a new "Figured > Bass" page to the Handbook's "New features for MuseScore 2.0" section, I > will add some preliminary usage instructions. > > Description: > > I decided to go with FiguredBass elements attached to Segment's (in > _annotations; solution B of previous post). Each FiguredBass element > contains all the (1, 2 or 3; rarely more) 'stacked' notations making up a > f.b. indication. Each notation (a digit, an accidental, or a combination of > them) is implemented by a FiguredBassItem. > > What is there: > > *) FB elements can be placed whenever at least one part (not necessarily the > part to which FB is added) already has notes (like Harmony does now). > *) FB elements can be entered from keyboard (including accidentals and > slashed / crossed shapes, which are entered as digit + suffix and combined > internally). > *) Individual items (each FB 'digit') are parsed into properties (harmonic > and typographic; in theory, the corresponding note/chord could be computed). > *) Supported accidentals: the 5 'standard' accidentals, before of after. > *) Supported suffixes (for combined shapes): cross, backslash, slash. > *) Supported parentheses: open and closed parenthesis, both round and > squared (brackets). They can be applied to any component (accidental, digit, > suffix, even to continuation lines). > *) Items are correctly aligned vertically and horizontally (including > accidentals and parentheses 'hanging' at the left or right of the main > character). > *) Continuation lines can be entered and are stored, but not properly > formatted yet. > *) A font matching the digit shapes of the MuseScore main font, with modern > and historic combined shapes. > > Parts still missing: > > *) No way yet to set the duration of a FiguredBass element, if different > from the chord under which it is placed (this is required for proper > continuation line formatting). > *) Proper cont. line formatting (currently, a 'symbolic', token short line > is appended, only to confirm the line is there). > *) Styles (at least: above/below selector, staff-FB dist., line height, > modern/historic selector): in "Styles | General styles | Page", like Lyrics > styles currently are? Or in a tab of its own? > *) Moving font info and encoding to a configuration file (currently, these > data are hard-coded in figuredbass.cpp). > > Added files: > > *) mscore\fonts\mscore-BC.sfd/.ttf: new font > > Summary of changed files: > > *) mscore\libmscore\figuredbass.cpp/.h: main implem./def. files > *) mscore\libmscore\chordrest.cpp: removed references to figured bass in > ChordRest::readProperties(), ChordRest::add() and ChordRest::remove() > *) mscore\libmscore\measure.cpp: added reference to figured bass in > Measure::read() > *) mscore\libmscore\segment.cpp: added FIGURED_BASS case to Segment::add() > and Segment::remove() > *) mscore\libmscore\style.cpp: changed figured bass default style to use the > new font > *) mscore\mscore\actions.cpp: changed FB default shortcut to [Ctrl][G] (as > in "fiGured bass"!) > *) mscore\mscore\keyb.cpp: keystroke mngmt for FB separated from Lyrics' > keystrokes > *) mscore\mscore\scoreview.h: added figuredBassEndEdit() and > figuredBassTab() prototypes > *) mscore\mscore\scoreview.cpp: added call to figuredBassEndEdit() in > ScoreView::endEdit() > > Reference to new font added to: > > *) mscore\libmscore\mscore.cpp > *) mscore\mscore\CMakeLists.txt > *) mscore\mscore\musescore.qrc > *) mscore\mtest\mtest.qrc > *) mscore\player-qt\mscoreplay.qrc > > Thanks, > > M. > > -- > View this message in context: http://musescore-developer.685061.n2.nabble.com/trunk-Figured-bass-next-steps-tp7275860p7319772.html > Sent from the MuseScore Developer mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Mscore-developer mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/mscore-developer > ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Mscore-developer mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/mscore-developer |
«
Return to MuseScore Developer
|
1 view|%1 views
Loading...
| Powered by Nabble | See how NAML generates this page |
