programmatic access of figured bass

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

programmatic access of figured bass

Jim Newton
I've been successful to enter figured bass into my score.
Now, I can't figure out how to access it programmatically.
I want to experiment with playback.

Can someone help me figure out how to access it.
Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Jim Newton
I found the following, it looks like I need to scan the annotations() of a segment,
find the ones of type Element::Type::FIGURED_BASS.


FiguredBass * FiguredBass::addFiguredBassToSegment(Segment * seg, int track, int extTicks, bool * pNew)
      {
      int         endTick;                      // where this FB is initially assumed to end
      int         staff = track / VOICES;       // convert track to staff
      track = staff * VOICES;                   // first track for this staff

      // scan segment annotations for an existing FB element in the same staff

      FiguredBass* fb = 0;
      for (Element* e : seg->annotations()) {
            if (e->type() == Element::Type::FIGURED_BASS && (e->track() / VOICES) == staff) {
                  // an FB already exists in segment: re-use it
                  fb = static_cast<FiguredBass*>(e);
                  *pNew = false;
                  endTick = seg->tick() + fb->ticks();
                  break;
                  }
            }
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Jim Newton
In reply to this post by Jim Newton
So I looks like I can indeed iterate through the annotations on a segment and find each whose type is Element::Type::FIGURED_BASS.
But once I get such an object, (FiguredBass *), it is not clear to me how to iterate over the FiguredBassItem objects.  The FiguredBass class indeed has a member variable

   std::vector<FiguredBassItem*> items;      // the individual lines of the F.B.

But it is unfortunately private.  I wonder whether that is an error?  Shouldn't it either be public, or there should be a public iteration function I can call to iterate over the items?

I don't immediately see any other way to access these.
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

lasconic
Administrator
Miwarre wrote the figured bass support so it will probably answer more in details.
In the meantime, items are probably not exposed because it was no needed to expose them so far. You can always create a public getter to access the vector.

lasconic

2015-05-14 15:58 GMT+02:00 Jim Newton <[hidden email]>:
So I looks like I can indeed iterate through the annotations on a segment and
find each whose type is Element::Type::FIGURED_BASS.
But once I get such an object, (FiguredBass *), it is not clear to me how to
iterate over the FiguredBassItem objects.  The FiguredBass class indeed has
a member variable

   std::vector<FiguredBassItem*> items;      // the individual lines of the
F.B.

But it is unfortunately private.  I wonder whether that is an error?
Shouldn't it either be public, or there should be a public iteration
function I can call to iterate over the items?

I don't immediately see any other way to access these.



--
View this message in context: http://dev-list.musescore.org/programmatic-access-of-figured-bass-tp7579343p7579345.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Jim Newton
Thanks.  I have not talked to Miwarre before.
Is he/she still an active participant?  What's the handle on IRC?

Your suggestion to create a public accessor for items is more or less what I am doing in the mean time.

Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Maurizio M. Gavioli
Jim Newton wrote
Thanks.  I have not talked to Miwarre before.
You did, you did... It's me...
Your suggestion to create a public accessor for items is more or less what I am doing in the mean time.
I would not encourage creating public accessors to FiguredBassItem's, unless really necessary for other purposes, as they require specific management and house-keeping by the parent FiguredBass element. Their privateness is a design choice, as described in the notes on architecture at the top of figuredbass.h.

A few considerations for script access:

*) In the FiguredBass class, the std::vector<FiguredBassItem*> storing the items needs probably to be replace with some kind fo QQmlListProperty<Ms::FiguredBassItem*> container, if individual access to each FiguredBassItem is required, which I would prefer to keep as read-only, though.

*) The full content of the figured bass element is already directly accessible through its text property in a normalized format. Before allowing to set it however, I think that the Text::setProperty(P_ID::TEXT, v) has to be sub-classed, following the flow in FiguredBass::endEdit().

I don't know if you have any deadline; I'm rather busy for a week or so; after that, I would be glad to improve figured bass support for scripting.

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Jim Newton
Thanks Maurizio,

I will make some small changes in the FiguredBass related classes in order to figure out what it is I need.
I don't need write access.  Mainly I need to iterate over the annotated figures associated with a chord/note.  At each iteration I need to access enough information to generate playback events.

I believe all that is missing is a way to iterate.  I.e., I either need an eachItem function to allow me to pass a visitor function (eachItem would call the visitor once for each FiguredBaseItem), or I need the array or a copy of it so I can iterate myself.

I'll keep you up to date with what I find.

Jim
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Jim Newton
In reply to this post by Maurizio M. Gavioli
Hi Maurizio,  

Small problem with the comment atop figuredbass.h
The explanations for prefix and suffix list PLUS as a possible value.  I believe this should be CROSS.
There is no such value FiguredBaseItem::Modifier::PLUS.

Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Maurizio M. Gavioli
In reply to this post by Jim Newton
Jim Newton wrote
I will make some small changes in the FiguredBass related classes in order to figure out what it is I need.
I don't need write access.  Mainly I need to iterate over the annotated figures associated with a chord/note.  At each iteration I need to access enough information to generate playback events.

I believe all that is missing is a way to iterate.  I.e., I either need an eachItem function to allow me to pass a visitor function (eachItem would call the visitor once for each FiguredBaseItem), or I need the array or a copy of it so I can iterate myself.
You already can do what you want to do, either in plug-ins or in core code, through the text property of the FiguredBass element: split it at each newline and you'll have the contents of each FiguredBassItem (I agree that a direct access to the FiguredBassItem's would make things simpler, but without compromising the control that the parent FiguredBass has over them, though).

If I may, however, it unclear to me how you could generate reasonably meaningful playback events from the B.c. figures; the basic difference between the 'early' and the 'late' stages of B.c. in the meaning of sharp and flat and the gradual emergence of the natural (to put it simply) can be probably coped with. But the under-notated (for our 'modern' feelings) B.c. in most of the XVIII c. music is hard to realize automatically, without a repertoire of the common patterns of the different times and areas, and without analysing in some depth the *following* chords or measures; both tasks are far from trivial to implement in an algorithm within a general notation programme.

If you have reached some breakthrough overcoming these difficulties, would you mind sharing it?

Thanks,

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Maurizio M. Gavioli
Maurizio M. Gavioli wrote
[...] But the under-notated (for our 'modern' feelings) B.c. in most of the XVIII c. music is hard to realize automatically [...]
Of course, it is a typo; I was meaning the "XVII c."!

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Jim Newton
In reply to this post by Maurizio M. Gavioli
So I experimented with playback and it indeed sounds horrible.
What I want to do now, is something like the Explode command.
This I'll have musescore translate the encoded Figured Bass into notes on a staff which the user can then manipulate manually.

With regard to your question of how to interpret ambiguous notation.  Yes of course you are correct.
I suspect the final solution will have a GUI to allow the user to control the meanings of certain ambiguous items.

The first ambiguity I encountered is that sometimes lack of a FB under a note means "don't play a chord", but sometimes it means "play the obvious chord".  I was thinking of using a rule of thumb:  No notation under the tonic, dominant, or subdominant means "play the obvious chord", otherwise it means "no chord".
On the other hand, it is easier to delete a wrong note than enter a correct note.
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Marc Sabatella
I either missed or forgot the background to this, but is there a reason you are tackling figured bass rather than chord symbols?  The concepts would be roughly similar, even if the specifics differ, but the latter would have much braoder appeal.  I know someone else mentioend on IRC they were interested in tackling that; seems these efforts should be coordinated.

On Tue, May 19, 2015 at 7:24 AM, Jim Newton <[hidden email]> wrote:
So I experimented with playback and it indeed sounds horrible.
What I want to do now, is something like the Explode command.
This I'll have musescore translate the encoded Figured Bass into notes on a
staff which the user can then manipulate manually.

With regard to your question of how to interpret ambiguous notation.  Yes of
course you are correct.
I suspect the final solution will have a GUI to allow the user to control
the meanings of certain ambiguous items.

The first ambiguity I encountered is that sometimes lack of a FB under a
note means "don't play a chord", but sometimes it means "play the obvious
chord".  I was thinking of using a rule of thumb:  No notation under the
tonic, dominant, or subdominant means "play the obvious chord", otherwise it
means "no chord".
On the other hand, it is easier to delete a wrong note than enter a correct
note.



--
View this message in context: http://dev-list.musescore.org/programmatic-access-of-figured-bass-tp7579343p7579371.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer



--
Marc Sabatella
[hidden email]

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Jim Newton
Hi Marc, that's indeed a very good question.   I'm actually tackling because it is something I need for my own music.  The main reason I use musescore is to create accompaniment to practice the oboe.  The music that I normally play is baroque.  I take scores such as by JSBach, enter them into musescore to listen to basically how they sound, and then use it to accompany myself in playing the piece on a real instrument.

Another purpose I use musescore for is to take pieces written for one set of instruments, and transcribe it into the instruments I have available to me in my student ensembles.  This music is often written with Figured Bass.  My professor can just look at the figured bass and understand what the harmony instruments should play, but I'm not so clever.  I want musescore to help me write the harmony based on the figures.

I'm very happy to extend what i'm doing to play the chords as well, but I was under the impression that a student was going to be working on this anyway this summer.

Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Marc Sabatella
I am not saying don't work on figured bass playback - i'm just saying that whatever code is written to support it, should *also* be made to support chord symbols.  So if there is someone working on chord symbols, you should coordinate your efforts.  If the other person who was going to work on chord symbol playback does not do so, then you should make sure your own code works for both where possible.  Either way, it doesn't make sense for you to solve the figured bass problem on its own, in my opinion.

Marc

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Maurizio M. Gavioli
In reply to this post by Jim Newton
Jim Newton wrote
So I experimented with playback and it indeed sounds horrible.
What I want to do now, is something like the Explode command.
This I'll have musescore translate the encoded Figured Bass into notes on a staff which the user can then manipulate manually.
Does not sound simple... But I got the impression that you were after a real-time Continuo realisation, which would be much more complex (and would not allow any after-thought corrections).
With regard to your question of how to interpret ambiguous notation.  Yes of course you are correct.
I suspect the final solution will have a GUI to allow the user to control the meanings of certain ambiguous items.

The first ambiguity I encountered is that sometimes lack of a FB under a note means "don't play a chord", but sometimes it means "play the obvious chord".
Ah! You got to the bottom line! The main problem is that "obvious": what is "obvious" for us now is not necessarily what for "obvious" for, say, Telemann, which in turn was different from what was "obvious" for Monteverdi. There is no shortcut out if this conundrum, I believe, except study, study and study under the guide of a good teacher, accompanied by practice, practice and practice...

And, beside, there is "always" a chord, unless you as the performer choose not to have one; the written indication when the author does not want chords is "tasto solo" (roughly meaning: "play just one key", understood: the note actually appearing in the bass part).
I was thinking of using a rule of thumb:  No notation under the tonic, dominant, or subdominant means "play the obvious chord", otherwise it means "no chord".
See above...

EDIT: the penny dropped! By "no chord" you mean "no new chord" (i.e. hold the previous one). This more or less amounts to detect which bass notes are passing notes (if I got the right English term) and which are not. Another point which was "obvious" to "them" and might not be to "us".

As I play a bass instrument, I would like to become a continuist (life span permitting...), but I cannot pretend to be a decent one now. The advice of a "real" Continuo player is required, to arrive at guide lines which could guess the right notes more often than not.

Maurizio
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Jim Newton
BTW does the Figured Bass notation in musescore support the "tasto solo" keyword?
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Jim Newton
In reply to this post by Marc Sabatella
Hi Marc, yes you are right.  
I'm in the very early stages of my development.  But I believe the approach i'm taking will lend itself very easily to chord realization as well.   I'll make a special point to talk to the student about this  and coordinate efforts.
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Maurizio M. Gavioli
In reply to this post by Jim Newton
Jim Newton wrote
BTW does the Figured Bass notation in musescore support the "tasto solo" keyword?
In which sense? By definition "tasto solo" passages have no figures, so there would be nothing to store the flag into.
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Jim Newton
Is there a way to store "tasto solo" in the figured base data structure, and a way for the user to enter it.  Consequently, there would be a way to programmatically detect the difference between missing FB and tasto solo.
Reply | Threaded
Open this post in threaded view
|

Re: programmatic access of figured bass

Maurizio M. Gavioli
Jim Newton wrote
Is there a way to store "tasto solo" in the figured base data structure, and a way for the user to enter it.  Consequently, there would be a way to programmatically detect the difference between missing FB and tasto solo.
As I said, the standard situation is to have no figured bass figures during "tasto solo" passages, so there is no FiguredBass data structure to store that info into. If this info is needed, something else is required.