Realizing Figured Bass
I have created a branch to experiment with realization of Figured Bass (basso continuo).
The branch (and corresponding PR) is called realize-figured-bass.
The concept is very limited at the moment.
What does it do?
Starting with a score which has Figured Bass annotated in it, this function will interpret the notation and creates additional notes in the same staff corresponding to the figure.
Starting with a score such as the following:
The command can be found in the Edit->Tools menu under the title: Realize Figured Bass
The command will update the score as follows:
There are many limitations. I'll list some of them.
- it creates notes in the same staff as the Figured Bass is found. It should write into a different staff, allowing the user to specify
- it assumes only one staff exists with FB annotations. It should allow the user to specify which staff to read from.
- musescore supports multiple FB annotations on a single note. Ie. a quarter note can have to annotations for each of the eighth notes which comprise it. This is not yet supported by the program.
- notes with no FB annotation, should imply the "obvious" chord. This is not yet implemented, and will probably never be implemented perfectly as it is probably impossible in many situations.
- musescore supports several modifiers for the FB notations including +, slash, natural, and a few more. These ARE supported but are not fully tested.
- depending the composer or the period, some notation should be treated differently. This is not yet supported.
| Attachment | Size |
|---|---|
| Screen Shot 2015-05-22 at 18.22.11.png | 88.99 KB |
| Screen Shot 2015-05-22 at 18.23.52.png | 82.68 KB |
Comments
Here is an example score you can try it with.
In reply to Here is an example score you by jim.newton.562
Jim,
I am quite new to musescore. Could you write, please, how to install your figured bass realization. Is it a plugin?
I could not find it.
Please help
Marcel
In reply to Jim,… by m.kozanek
No, it is a source code change, see https://github.com/musescore/MuseScore/pull/2015
It has not yet been accepted/merged
In reply to No, it is a source code… by Jojo-Schmitz
How do I use the source code? What do I have to change?
In reply to How do I use the source code… by BetaBleeds
See further down
I will never use this, but I think it adds a great facility for those who will. Way to go!
:)
In reply to I will never use this, but I by xavierjazz
Hi Xavier. you're right that this feature will be used rarely. The main reason I need it myself, is when capturing baroque music, the basso continuo part is often given. I've never seen it used for any other type of music than baroque.
I recently began attempting to make an arrangement the score shown above. Apparently JS Bach wrote it as a trio, but I'd like to play it as a quartet. So to invent a 4th instrument, I wanted to use the harmonies suggested in the basso continuo.
A nice beginning! To me, though, the hard part is now converting the correct but "naive" renditions of the chords into something resembling actual accompaniment that would be provided by a keyboard player. I'm no expert in baroque accompaniment styles, but I'm pretty sure these low register block chords are not at all what figured bass is meant to imply.
In reply to A nice beginning! To me, by Marc Sabatella
Right Marc, the program does not claim that the notes are in the correct octave. The user can select the notes he's interested in and delete them or change their octave if he likes.
How I use it is by looking at the auto-created notes, and distributing them among the
various staffs to fulfill the indicated harmony, then deleting the auto-created notes, or at least marking that instrument as silent.
That is, the intent is not to play the composition with the figured bass in place, but to use it as a development tool.
Attached is an example of the same composition arranged for an oboe quartet. Oboe, Oboe d'amore, english horn, and baritone oboe.
In reply to Right Marc, the program does by jim.newton.562
You can't actually do that; you cannot realize the continuo parts as supplementary obbligato parts, because the continuo part always includes the fundamental gestures of the actual obbligato parts, and you will wind up with parallel octaves left and right, which you have. When on an isolated continuo instrument in its own, quieter, "ensemble", however, this is within spec. Creating supplementary obbligato parts from continuo figuring is not at all the same conceptual task as continuo realization. You sort of have to subtract out the obbligato part which is there, and reconceptualize the task.
Of course, no one is going to rise up from the Baroque and stop you, but if authenticity to what is understood as continuo realization or Baroque models of texture are considerations, then, no.
Furthermore, even if your intent is to provide a quiver of notes for people to rearrange intelligently, I'd bet my next week's meals on almost everyone using it not knowing that, and simply saying "ah, that's what that means" the same way a sufficiently heavy wrench can be used as a hammer if you don't know what it's for. Figured bass is a mechanism for notating standard gestures by sequences of stacks of numbers. The numbers are but a means to that end.
In reply to You can't actually do that; by [DELETED] 1831606
Not sure what you mean by "can't do that". If I wanted to create a quartet out of a solo + continuo, where would I get the harmony rules for the additional instruments otherwise?
In reply to Not sure what you mean by by jim.newton.562
The harmony and the "harmony rules" are two different matters. From the continuo figures, you most certainly can infer the harmony, although the bass part as written must be there, or the figures of the harmony cannot realize their intents. My suggestion would be to undo the figures into chord symbols, perhaps, then, unfortunately, there is no simpler path than composing two addition lines which, with the obbligato there (which would not be a constraint for a normal realization), create both those harmonies and credible 4-part counterpoint between themselves the bass and the obbligato (and, when it appears, 5 parts with the cantus firmus). That is actually a much more difficult task than realizing the continuo, because you have more constraints/fewer degrees of freedom. A "student" of mine on the site has been supplying alto and tenor voices for Bach "Schemelli" songs which appear as bass, solo, and figures, where the problem is the same, and it is very different than realization in 3 free keyboard sub-voices.
By "can't do that", as I said, the Baroque Police will not arrest you, but, and it may not be of any concern to you, the result will violate the rules of baroque counterpoint unless attention is paid to precisely that.
It is not widely known that continuo voices are allowed freedoms (such as gesture doubling) with respect to obbligato voices that neither are permitted amongst themselves. If you promote the former to the latter, error results.
In reply to The harmony and the "harmony by [DELETED] 1831606
For an amazing case where the difference between keyboard continuo and obbligato part supplementation is so profound that the latter is impossible, see (and my comment there)
https://musescore.com/user/1685616/scores/2143866 . I have verified this arcanum with an esteemed living composer.
In reply to The harmony and the "harmony by [DELETED] 1831606
I agree that the resulting music differs from the original. And the intent was not (in my mind) to reproduce the original, nor is the intent to replace the musician. The intent is just that the software apply some well defined rules to help the user make some pretty music by adding extra voices, and helping him in keeping the harmonies correct. There are infinitely many different ways for the user to do that. The first step, the computer assisted step, in my mind is to look at the figured bass to show what the implied harmony notes are.
In reply to I agree that the resulting by jim.newton.562
It's not just harmony, it's counterpoint. "5/4" doesn't mean "5/4" chord (it's usually written just 4), it means that there's a suspended fourth that is going to resolve to a third in the next "chord". "6/5" doesn't just mean any old minor seventh/"sixth chord", it means that the 5 has to be prepared in the previous chord and resolved as dissonance in the next. Baroque music, Bach vor allem, is the perfect mixture of harmony and counterpoint. Figured bass is a notation for both, which is why composition was taught through these means. The whole domain known as Partimento encodes entire compositions, particularly fugues, in figured bass, because the gestural vocabulary and expansion are so tightly coupled and specified. This is why period figured bass manuals are so thick -- they are about the proper execution of the vocabulary of gestures. The guitar chords of a jazz fake book are pure harmonies -- how you finger the chord is not relevant -- nor is how individual notes of those chords proceed to each other relevant. But figured bass is exactly not that -- it is a harmonic and contrapuntal formalism central to the conceptual skeleta of Baroque music. There is no such thing as "correct harmony" without "correct counterpoint", meaning all the passing notes, suspensions, and so forth, do as intended.
"Chord" is the wrong way to think about it; it's a grocery-order for simple contrapuntal composition.
And I wouldn't say it "tells you what the implied harmony notes are" -- it explicates the harmonic context. What the 'notes are' is up to the realizer as a function of that.
In reply to It's not just harmony, it's by [DELETED] 1831606
Maybe this isn't so crazy, even if it will be misused left and right, and doesn't relieve the need for knowledge. As you rightly observe, you really have to divert the output to a different staff. And solving the problems of figuring unfigured bass notes (you have to know when it means "5/3" and when it means "-", which has to do with the beat pattern -- see my discourse) and changes in the middle of bass notes seem prerequisite. I wish we could call it something humbler than "realize", such as "expand figures to notes".
Is this C++ or javascript code?
6/5 means 6/5/3 by the way.
In reply to Maybe this isn't so crazy, by [DELETED] 1831606
It's in C++. In fact the Java script api is insufficient for implementing such a feature.
In reply to It's in C++. In fact the Java by jim.newton.562
THAT is a dreadful deficiency. I cannot think of anything more natural for user/extension experimentation that figured bass realization (in the rightful sense) and other automatic composition-assist and analysis tasks. Coding such algorithms into the C++ core, freezing them for a year at a time and precluding contributor development, seems phenomenally ill-advised. The more sophisticated the algorithms, the worse the error of freezing them in C++.
I vote for making the figuring information, including its beat position, available to the Javascript API as the most vital and important task concerning figured bass, and where this effort should best be spent.
In reply to THAT is a dreadful by [DELETED] 1831606
Voting is good but not enough, especially with this vocabulary. If it's so "dreadful" and "phenomenally ill-advised", your code contribution is welcome to expose the necessary objects to the plugin framework. I'll be happy to review it.
In reply to Voting is good but not by [DELETED] 5
OK, you're right, you've got me interested. Can you point me to similar code that exposes note features via API? No promises on return time, but it does seem fair I should put my effort behind my views.
In reply to OK, you're right, you've got by [DELETED] 1831606
BSG, are looking to see the C++ code or javascript code?
If you want the existing C++ code, you can find it on the branch realize-figured-bass
pull-request ==> https://github.com/musescore/MuseScore/pull/2015
If you'd like the javascript code, I'd like to see the same thing, so I'm anxious to see if
anyone responds.
In reply to THAT is a dreadful by [DELETED] 1831606
I agree that having a good scripting environment would be extremely useful.
However, architecting one is a HUGE job, and sure to take a long long time
to get right. One reason (it seems to me) that no developer wants to (or is able to)
do it is because the developers who would know how to do it, don't really need
such a scripting environment, they can already do everything they want from the
C++ API. In addition, it is not very often when such an application extension arrises which
would be great to have, but which doesn't make sense to implement as part of the
core product.
Please someone correct me if I'm wrong. It's just my observation.
In reply to I agree that having a good by jim.newton.562
I really don't know what you're saying here. Are you saying that, in general, the scripting environment is not as flexible, powerful or convenient as it should be (my brief experiences with it are bitter, but I see that people have succeed in wrangling it), and perhaps needs massive reconceptualization, or that the addition of bass figuring to the scripting environment in particular is such a "huge job" that it might not be merited? Do you agree or disagree that creative/sophisticated fb realization is a perfect example of "an application extension which would be great to have, but which doesn't make sense ... as part of the core product"? Are you saying that developers are predisposed against exposing capabilities to the extension API because they can add functionality in C++? Is that saying that extension (i.e., scripting) is a consequently lost cause, or identifying that as the likely obstacle to desirable enrichment/development of the scripting environment?
In reply to I really don't know what by [DELETED] 1831606
Hi BSG,
To answer your questions: Additional comments below.
> Are you saying that, in general, the scripting environment is not as flexible, powerful or convenient as it should be
Yes, but I understand why that is. I'm not complaining. Im just stating my opinion about the current state of an except piece of software which has customization limitations.
> or that the addition of bass figuring to the scripting environment in particular is such a "huge job" that it might not be merited?
I think that it is not such a huge job as people think, as long it is not required to be 100% correct t. The result should be human editable.
> Do you agree or disagree that creative/sophisticated fb realization is a perfect example of "an application extension which would be great to have, but which doesn't make sense ... as part of the core product"?
I don't think it needs to be exceedingly sophisticated. As long as the rules can be stated algorithmically, I (or any of many other people) could implement it.
> Are you saying that developers are predisposed against exposing capabilities to the extension API because they can add functionality in C++?
Yes, that is my experience with scripting languages. When the core developers don't use the scripting environments, there is little observed return-on-investment for making it robust.
> Is that saying that extension (i.e., scripting) is a lost cause because of this?
Yes, I'd love to be wrong on this belief, but I don't think a robust scripting environment for MuseScore is really in the cards, unless someone with a vision and lots of time really wants it to happen.
I think scripting languages are extremely useful. Customizing an environment
to a user's or a group of user's needs makes a tool much more powerful.
Tools which have a strong scripting environment (such as emacs, or integrated
circuit design environments (Cadence/SKILL), or architecture Autocad) allow users
to do lots of things the tool was never thought capable of doing, and it avoids
discussions about whether those features should be part of the core tool.
However, having such a capable scripting environment is VERY DIFFICULT.
Doing so requires the core tool to write fool-proof interfaces to let amateur
programmers modify the data base. In the case of C++ which is not garbage
collected, the scripting language would need to be subject to GC, and the core
C++ would have to cooperate with the GC. Any sufficiently useful scripting API
would need to be really vast to be useful. Being almost useful is not good enough.
My belief is that ideally the figured bass realization should be scriptable, but
that that is not practical as the scripting environment is not sufficiently robust.
The philosophy of MuseScore is that extensions are written in C++ and offered
to users through releases.
Therefore, there should be a core capability to create a reasonable realisation,
which the user can thereafter edit with the MuseScore interactive environment.
In reply to Hi BSG, To answer your by jim.newton.562
That is extremely interesting (and unhappy), and deters me from the task of trying to add FB access to the C++ core. What you're saying is that the ability to construct stuff in script ingresses upon the storage-management paradigm in a bad way. By the way, I had a great deal to do with the Emacs extension environment as separable from its implementation environment, way back in 1978 (see http://www.multicians.org/mepap.html), and remain a very great fan of this notion.
Perhaps outboard code hacking MuseXML is a fair way to experiment with realization algorithms.
I do not understand this exchange:
> BSG:Do you agree or disagree that creative/sophisticated fb realization is a perfect example of "an application extension which would be great to have, but which doesn't make sense ... as part of the core product"?
>Jim: I don't think it needs to be exceedingly sophisticated. As long as the rules can be stated algorithmically, I (or any of many other people) could implement it.
What I've been saying is that even simple FB realization needs substantial sophistication, should not be C++ in the core, and makes perfect sense as a scripted extension once a literate user develops one. What you seem to be saying is the exact opposite. Exposure of figured bass to the extension environment would facilitate scripted realization, but you seem to be suggesting elsewhere is that the problem is not that per se, but that creation of notes from scripting, because of storage-management issues.
In reply to That is extremely interesting by [DELETED] 1831606
I am not sure I understand the reference to "storage management issues". If currently notes can't be created from the plugin framework, that's a bug pure and simple. I think I recall something about that being discussed on the plugins forum, there might have even been an attempt to fix it although I don't recall if it was successful. Feel free to look about for more information on that.
But FWIW, I would suggest that figured bass realization *does* potentially belong in the core. Or at least, some sort of framework that plugins could then access for further sophistication. The same capability, after all, would be needed for chord symbol realization, which is a very commonly requested feature that we definitely would like to see at some point (and it was proposed for Goggle Summer of Code, unfortunately none of those proposals made the final cut). There are similar issues where a naive implementation might seem almost useless, but a realistic one would be difficult and start to feel more out of place. We were leaning toward going with a naive implementation that basically placed the naive realization on a separate staff you could then edit to make it more realistic, and that is where possibly a plug could step in.
In reply to I am not sure I understand by Marc Sabatella
I am really confused here. I would send mail privately, but I suspect any other non-current developer would have the same questions. In the posting of 12:34 MuseScore time, Jim says there are issues of interacting with non-garbage-collected C++ that stand in the way of having a powerful scripting environment. Is that so, or not so, and can we have more detail on this? Is the issue that the scripting environment cannot create arbitrary objects without fear of storage leak or pointer dangling? Are there in fact limitations on what kind of objects a script can create, or not, other than those whose need has not yet arisen? What are the facts here?
If I were to (and I wish I could, and am in a fine position to) write a plugin interacting with figured bass, I would want to see the figures and their timing (nothing more or less), and be able to create voices (not "chords") in counterpoint realizing their intent, i.e., generic notes and voices. I would consider the availability of "these are the notes I think the figures represent" a disservice, not a service, in comparison to that. Recovering the figures and their intent would be like disassembling code to figure out what the author said. It is exactly what I would not want.
In reply to I am really confused here. I by [DELETED] 1831606
I gather Jim's primary experience is with Lisp, and hence the focus on garbage-collection, but I don't see it as being relevant to MuseScore in any significant way. As I see it, the plugin framework either works or it doesn't; garbage collection is just a space optimization. If the framework works, great. If it doesn't in some particular case it's a bug, someone needs to file the bug to the issue tracker with precise steps to reproduce and hopefully someone will volunteer to fix it.
In reply to I gather Jim's primary by Marc Sabatella
Javascript, the language in which plugins are written, is, in fact, garbage-collected. I do not know what your API environment does with MuseScore objects represented by Javascript objects that lose all incoming pointers, but I would be surprised if anything happens at that time at all. I infer that that implies that plugin coders presently (Jim or someone correct me if wrong) must take care not to create objects that "leak", i.e., whose management/ownership is not properly accounted within the app's object ownership protocol. I don't know if the script API provides functions to destroy objects, and if it does, I would assume that their incorrect use, corrupting the app, as well as creating unowned objects not destroyed, are the "lack of garbage collector" issues to which Jim refers.
In reply to Javascript, the language in by [DELETED] 1831606
I know that garbage collection happens, but my point is, it is not the issue.
If a plugin writer creates objects that leak, then memory usage grows, but that's the fault of the plugin, not the framework. Even if there is a a leak issue in the framework itself, it's not necessarily a fatal flaw - there are porbably leaks all over the place.
Correctly wirtten code won't break because of garbage collection - only *incorrect* code will break. So if there is code that breaks, that's a bug that needs to be fixed - the code is broken and is broken with or without garbage collection. In other words, garbage collection might be how you find out your code is broken, but don't shoot the messenger.
So, some plugins might be broken, some aspects of the framework might be broken, but these are just bugs, and bugs can be fixed - *if* someone who prioritizes these sorts of bugs highly enough volunteers to work on them. As you know, core notation features usually get top priority.
In reply to Javascript, the language in by [DELETED] 1831606
So far I've only meddled with exposing properties, so I'm not quite an authority on plugins here.
There is a newElement(elementType) function exposed that allows creation of element through a plugin, and it does affect garbage collection (https://github.com/musescore/MuseScore/blob/f0ae34af61b8e5db56c647a8a1a…) however I can not be more specific about the who/what/when/where the proper cleanup is handled.
In reply to Hi BSG, To answer your by jim.newton.562
Allow me to very briefly step in and comment on this particular section:
"> Is that saying that extension (i.e., scripting) is a lost cause because of this?
Yes, I'd love to be wrong on this belief, but I don't think a robust scripting environment for MuseScore is really in the cards, unless someone with a vision and lots of time really wants it to happen.
[...]
The philosophy of MuseScore is that extensions are written in C++ and offered
to users through releases."
I've had the opportunity to chat with the core developers a few weeks back upon this subject and can I assure you that the desire for a good scripting API is present. It's one of the reasons improvements to the plugin manager (for a start) are always part of the GSoC proposals.
However, what you are correct about is the amount of work involved with learning the Qt/QML-plugin system and creating a stable API on top of it (one that can't crash the core application for example). It just might be that a different plugin system would be required.
Due to the amount of work involved and the still huge backlog of core-features (like the new layout engine for v3.0) it is currently a matter of prioritization that renders the plugin framework to be underloved.
Of course coming up with a decent API that has a nice balance between usability/functionality would be the first step to take.
In reply to Allow me to very briefly step by jeetee
I see, that's disappointing. Writing a hard-coded realization algorithm in the immutable core is, as someone else noted, tantamount to writing a hard-coded jazz improvisation algorithm. If you wrote it and it did exactly what you wanted, it might be right, for you, the day it was released, but not a month later, or for anyone else. The bottom line here seems to be that there is not now a usable user-extension medium sufficiently powerful for assisted composition.
If I were Priority Czar, I would place 'make Piano editor not crash on the Mac' and 'make short notes not clobber sound of long notes' miles ahead of anything having to do with figured bass or scripting.
One tweak I would recommend is for the code to shift the existing continuo bass to voice 2 before adding the chords.
This way it would be possible to copy the continuo chords to a separate stave without lengthy editing.
In reply to One tweak I would recommend by ChurchOrganist
About shifting this to voice 2? the only reason I put it into the same voice in this first implementation is because I didn't understand the API put creating chords in a different staff. However, I did find an easy API for adding notes to an existing chord in the same staff/voice.
I used this API to allow me to develop the actual algorithm for the derivation of the notes/pitches themselves.
What I'd like to do is actually derive the notes into another, presumably empty staff. I think this would allow the user to more easily modify them, copy them, delete them, or recreate them.
In reply to About shifting this to voice by jim.newton.562
On several occasions - on develoepr list and/or on IRC, I have tried pointing you to the code for the "fill with slashes" command that has to create chords as well. Are you not seeing my messages?
In reply to On several occasions - on by Marc Sabatella
Hi Marc, I have not been busy with Musescore this week. so I have not seen IRC, and no I don't think I got the dev list mailing your referring to. Nevertheless, next time I look into the Figured Bass code, I'll be sure to check out fill-with-slashes as you suggest.
Thanks for the gentle reminder
First of all, I am not a continuist myself, I have a limited experience of realizing (badly!!!) a basso continuo but, as I play an instrument also used for the 'melodic' part of basso continuo, it happens to me to sit near the 'real' continuist and hear what (s)he does (while playing from his/her same part).
That said, I regret of sounding negative but, the more I think about this 'automatic continuo realisation', the less I understand the rationale for it.
To put things in context, I suggest some comparisons between some well-known scores and their performances by top-rated performers, chosen both by their representativeness and by their general availability:
1) As an example of early Baroque (1637) continuo: S. Landi's Canta la cicaleta. The score is available here and a good performance by M. Beasley with L'Arpeggiata is on YouTube (I know Beasly has his non-supporters, but L'Arpeggiata is beyond dispute and we are speaking of continuo here).
2) As a later example (1728): Pièces de viole by F. Couperin. The score is available on IMSLP both as a modern engraving and as the original 1728 Boivin print (in separate solo and B.c. parts, definitely worth a look). As performance, again on YouTube, you may choose between P. Pandolfo and friends or P. Pierlot and friends. Boysen and Hünninger continuo in the first one is particularly interesting, especially in the slow movements (the two Preludes and the Sarabande).
There are 'real-world' examples of continuo realisation, i.e. 'finished products'. Now, which could be the reasons for such an "automatic continuo realisation" function? I can think of two of them:
1) To help the would-be continuist in his learning process.
2) To give to the non-continuist (or the layman in general) an idea of the 'finished product'.
About the first reason, I believe:
1a) while it might be the role of MuseScore to help creating exercises, examples, charts and, in general, tools for helping teaching and learning, I do not believe it is the role of MuseScore to teach anything directly.
1b) Continuo is not a theory you may look up in a book and implement in an algorithm; it is a practice, taking a few hours of theory class and then years of practise, enlarging the initial theory to more cases and styles, narrowing it to specific instruments (theorbo continuo and keyboard continuo, for instance, are two different beasts), and also contradicting it.
About the second reason:
2a) It does not take too much to realize that anything an algorithm (more: an algorithm implementable in a generic musical notation programme as MuseScore) could produce would have little, if any, relationship with the 'finished product'.
To make an example perhaps more familiar to more users (and much less familiar to me, so please excuse errors or terminology inaccuracy), mutatis mutandis this reminds me of an automatic realisation of jazz improvisation on standards: would it make sense? Most of the answers to this question would also apply to B.c. realisation.
Am I missing something?
To close with a more positive note, it may be quite possible that some aspects of this large field or some specific implementations could make sense in plug-ins, which a user -- directly or by asking to a friend with some JavaScript knowledge -- could tailor to specific needs and goals. So, it may be of interest to investigate which additional pieces the plug-in framework needs to be functional in this area and, if possible, implement them.
Thanks,
M.
In reply to First of all, I am not a by Miwarre
The first thought that springs to mind is that there are so many really bad realisations of figured bass already in print--from major publishers, too, before they 'got religion'--that however simplistic the result a MuseScore algorithm might produce, it wouldn't be hard to find a worse one at $29.95.
That said, your basic question--"Is it useful/necessary...and if so, how?--is a fair one.
I work with a lot of manuscript from the early-mid 18th century, and it's surprising how many of them do not contain bass figuring. What we forget, a lot of us who ought to know better, is that bass figuring is just a shorthand--similar to (but a lot more complex than) writing 'G7' above a melody line for a guitar-player who can't actually read music. Also, we should remember that keyboard music in Bach's time was often written in 'open' format--essentially a score, with each voice on a separate staff. A real continuo player can work from a score as easily as from a figured bass part. About two weeks ago, I had the pleasant--and humbling--experience of handing my unfigured score (alto & tenor recorder + VdG) for a Handel trio sonata to a continuo player and listening to him sight-read/improvise a perfect accompaniment without even wrinkling his brow.
Finally, we should recognise that, for the same piece of music published or copied by different editors, no two figured bass lines are the same...and of course, that no two continuo players will play the same figured bass the same way.
I am NOT a continuo player. I use the bass figuring to help guide me when I'm arranging a solo sonata or trio for a larger ensemble than that for which it was originally written (recorder players being very social animals, I do a lot of that), but if there's no figuring I get the harmony from what's written in the parts. It's relatively rare that even a two-part piece is so harmonically ambiguous that what's wanted isn't pretty obvious to the ear. I would never use a 'realisation algorithm' to generate a harmony.
OTOH--and here is where the question gets interesting--I think I would use a reverse realisation function to generate bass figuring from the written harmony. Writing out bass figuring is a finicky, labour-intensive job, and if MuseScore contained a function that would do it for me, I would at least give it a whirl and hope not to have to make too many corrections.
Your thoughts...?
In reply to The first thought that by Recorder485
Some thoughts in random order...
It is possible to find a lot of incorrectly copied, badly engraved, badly printed, badly <put_your_choice_here> music around and this is no excuse for aiming at (potentially, possibly or probably) bad results.
Differences between different historic prints (sources) and different players (outcomes) do exist; but I believe this is not the core point: Hantaï or Hünninger realisations of the same piece are different, but either could be assumed as a plausible model. I feel that the main point is that the results we could expect from such an algorithm (again: an algorithm applicable within a general music notation programme as MuseScore; highly specialized software could be imagined and might be different) would be of a different kind, a different beast, than any plausible 'real world' example: the two classes do not overlap or the overlap is so small to be irrelevant.
To summarize my rantings above: who would benefit from such a feature?
The only kind of user I can think of who could get some help from this feature would be, say, the re-engraver or the arranger of historic sources, wanting a quick aural confirmation that the figures in the source are correct or that the parts match them, without making all the calculations all the times. I.e., paradoxically, you and me, who already said would not use it! And, in any case, quite a small part of MuseScore user base.
__________
About the reverse figuring you describe: my first impression is that it would be even more restricted in usage than the direct realisation. Which leads me again to plug-ins:
All these thingies are too specialized and probably needed in some different form by each different user to be included in the built-in code base. But they all turn around some common building blocks, ultimately based on a scale which inserts a semitone every two and every three tones.
Possibly, a carefully selected body of basic functions could help in all these cases (and other I cannot think of on the spot) or in several of them, preventing each plug-in author from reinvent all the wheels each time, and helping a greater availability of plug-ins.
The urge to provide a 2.0.x version as much reliable as possible has understandably forced the dev team to leave the script framework (and its documentation) somewhat behind. Probably, it would be the right time to bring it forward again.
Thanks,
M.
In reply to Some thoughts in random by Miwarre
The main reason I want this feature is to give me a starting point for arranging scores which are printed using this notation. I'm perfectly happy if someone wants to implement it using a plugin. I myself don't know anything about the musescore plugin capability. Is it actually sophisticated enough to create GUI controls routines to derive and create simple harmony as I've implemented (and plan to continue) in C++? Maybe the answer is yes, but I don't know.
It might indeed be an interesting exercise to enhance the plugin bindings such that such a program becomes possible, in the interest of having a good and usable plugin system. I can't testify as to whether that is already the case or not. How many musescore users do we have who would like a more capable plugin extension language interface?
In the mean time, I don't see any other way to (currently) implement the feature of Figure Bass realization other than doing so as part of the core C++ code.
In reply to The main reason I want this by jim.newton.562
BTW I started a related discussion about creating plugins.
It is here https://musescore.org/en/node/63796
In reply to BTW I started a related by jim.newton.562
The discussion Plugins vs Core is moot to me. If the coder who can contribute the feature is more at ease with C++, and if the feature is limited to a function call or two and doesn't need a major rewrite of a part of MuseScore, I'm perfectly happy with it being in the core.
Regarding the possible usage, I can't comment on figured bass per se, since I know almost nothing about it. But on a more broader picture, if the expert doesn't want to use it, he can.
My only concern would be the beginner thinking that this is the "right thing to play"... But after all we will hurt this exact same problem if we add more advanced playback features all the time. The same argument was used for articulations, glissando etc...
To conclude, I'm happy jim started this in the core. And I would prefer him to improve it instead of working in a plugin (except if the two conditions at the very beginning of my comment are not true)
In reply to The discussion Plugins vs by [DELETED] 5
Plug-ins: Hmmm... I am a bit surprised by this answer. What about functions to generate 4-part corale harmonization? Or for 12-note series creation and/or manipulation? Or, as I said, to generate jazz "improvisations"? Or orchestrations from piano scores? Or... Would all make sense in the code core? Or would it make more sense to approach them (perhaps selected parts of them) in plug-ins (if possible, of course)?
Note that none of the examples above have 'broader' implications than B.c. realisation; some are actually more well defined than it.
As I am surprised by the current lack of attention for the plug-in framework; there are plug-ins I use practically every time I run MuseScore and allow a huge save of time and more precise results.
Comments on the limitation of the scripting framework abound and between "allowing to do everything from plug-in" and disallowing basic tasks like adding a note or formatting a text, I am sure a better optimisation can be reached, which would increase the availability of plug-in, originated by actual user needs (foreseen or not by the dev team), and Musescore general versatility, without increasing the load in the core development (once the few odd balls like
enums or arrays are sorted out).____________________
Figured Bass: it seems to me that the above posts make clear why this specific feature is likely to turn out either hugely complex, with lots of parameters and selections, or in most cases unsatisfactory (or potentially both).
Its basic goal and the intended 'target audience' are yet unclear; its relationship with actual continuo practice is likely to be minimal and, sorry, I do not buy the " if the expert doesn't want to use it, he can" argument: this amount to say: "if the users dealing with Figured Bass do not want to use it, they can".
And indeed, this same argument is used for articulations, ornamentation and so on, and rightly so, because it applies there too! The more something leaves the plan of pure notation to enter in the field of what persons do with scores once they have notated them, the more the result is likely to be unsatisfactory, open to subjective discussion, overly complex, etc... and potentially more detrimental to MuseScore than helpful.
I believe to have expressed my opinion clearly enough. So, it is time for me to shut my mouth and hope for the best.
Thanks,
Maurizio
In reply to Plug-ins: Hmmm... I am a bit by Miwarre
Speaking just in terms of pretty vague generalities, to me, some sort of rudimentary figured bass realization - optional, default off unless it is much more than rudimentary - seems more "core" worthy than most of the other automatic things mentioned here. Similarly rudimentary accompaniment from chord symbols seems similar.
That's about all that I think makes sense for anything automatic generation of anything in core. Anything else - jazz improvisation, chorale harmonization, generation of tone rows, etc - does indeed feel more like plugin material to me.
I would also suggest that manipulations of existing material - eg, inversion, retrograde, augmentation or diminution - do seem perfectly core-worthy as well, if they can be be described and performed objectively according to fairly universally-agreed-upon standards.
I'm not sure how is following this discussion. But it would be great if someone (some people) would post (attach) musescore scores which have figured bass annotated on them.
The majority of my work so far has been based on one single Bach corale, whose picture is posted above. Does anyone have some examples they are happy to share?
Thanks.
In reply to I'm not sure how is following by jim.newton.562
You may find some scores with Basso continuo at my score site http://www.vistamaremusica.com
In particular:
S. Landi, <i>Quinto Libro</i> ,
S. Landi <i>Sesto Libro ,
J. Richmann, <i>Sonates à V.d.G. et B.c., op. 1 .
For each, you may download the final PDF (to have a look at the 'finished product') and the MuseScore .MSCZ engraving files.
Hoping they may be of some help,
M.
EDIT: They belong to different times and cultural areas, so they present different cases and styles.
I would like to try this Tool on a score I have with figured bass, but I do not see the command in either the Stable Release or the the most recent nightly build.
In reply to I would like to try this Tool by abcoblentz
It's not available in either yet; it's still just experimental code not part of any official build.
I've updated the PR (and corresponding branch) with code which does a good job at realizing the fingered bass.
This code violates several coding standards including improper includes.
I will eventually fix these problems.
The reason I'm appending this comment is so that anyone who is interested can experiment with the functioning code.
The way it works is as follows.
You'll have to compile musescore from the branch realize-figured-bass,
and launch musescore.
You can load a score which has figured bass annotated (or use the attached example Wachet_experimental.mscz).
To trigger the capability, use the menu item Edit->Tools->Realize Figured Bass
This will modify the bass line which contains the figured bass annotation.
The following are some items I need to do before the code is ready for release
* remove the #include "mscore/scoreview.h" dependency
* some annotations imply other annotations, but the rules are inconsistent.
I'm currently implementing the implications from wikipedia but some people do not agree with this source of information. E.g.,
- 2 ==> 2,4,6
- 3 ==> 3,5
- 5 ==> 3,5
- 6 ==> 3,6
- 7 ==> 3,5,7
- 2,4 ==> 2,4,6
These are currently hard coded, but should be determined by a lookup table
* implement a GUI to control some user options (can someone help me with this?)
- how to handle accidentals from other staffs (this seems necessary according to my experiments)
- how to handle "missing" FB annotations
- identify which staff to write the results into
- user definable implications such as 7==>3,5,7 etc.
* remove some inline functions from the c++ code which some people find confusing
* experiment with other samples of Figure Bass scores such as described in this comment
* implement continuation lines
* implement duration
In reply to I've updated the PR (and by jim.newton.562
Thank you. How does one compile from the branch on the given URL?
In reply to Thank you. How does one by abcoblentz
Can someone explain what someone needs to do to checkout a local copy of a PR into his local git repository?
I was looking at this QA from github help. But the "buttons at the bottom" which the page predicts, don't show up for me when I following the instructions.
In reply to Can someone explain what by jim.newton.562
You might try the following
> git clone https://github.com/musescore/MuseScore.git
> cd MuseScore
> git fetch origin pull/2015/head:realize-figured-bass
> git checkout realize-figured-bass
In reply to You might try the following > by jim.newton.562
The following should work
git clone https://github.com/musescore/MuseScore.git
cd MuseScore
git checkout -b jimka2001-realize-figured-bass master
git pull https://github.com/jimka2001/MuseScore.git realize-figured-bass
In reply to The following should by [DELETED] 5
Thanks! But how do I compile MuseScore source code?
I read readme.md, and I inserted "make release" to CMD, but it says 'make' is not recognized as an internal or external command,
operable program or batch file.
In reply to Thanks! But how do I compile… by BetaBleeds
See https://musescore.org/en/handbook/developers-handbook/compilation
In reply to See https://musescore.org/en… by Jojo-Schmitz
I almost made it to compilation, but CMake does not find Qt5Core, Gui, Network, Test, Qml, Quick etc.
And could not find PortAudio!
In reply to I almost made it to… by BetaBleeds
Then pretty likely you didn't follow the steps correctly, I think youre on windows, so see https://musescore.org/en/handbook/developers-handbook/compilation/compi…
In reply to Then pretty likely you didn… by Jojo-Schmitz
I downloaded PortAudio! portaudio.dll and portaudio.h are in the correct destinations!
In reply to I downloaded PortAudio!… by BetaBleeds
That is not part of the instructions...
In reply to That is not part of the… by Jojo-Schmitz
It is a part of Qt MinGW instructions!
In reply to It is a part of Qt MinGW… by BetaBleeds
True, but not (anymore) the recommended way (with is now MSVC), and also easier to grab that dependencies.7z file, as there's more dependencies than just portaudio.
Where exactly did you place those files then?
In reply to True, nut notthe recommended… by Jojo-Schmitz
Alright, now I use Visual Studio. Where am I supposed to place dependencies?
In reply to Alright, now I use Visual… by BetaBleeds
In the folder where you cloned the repository, next to the top-level Cmakelists.txt.
Same file and place as for MinGW as of latest BTW. So for MinGW it is no longer needed to copy stuff into the Qt tools directories, like still documented in the details instructions for MinGW and as done by that Qt-Additions.zip
In reply to In the folder where you… by Jojo-Schmitz
What part of Qt Tools?
In reply to What part of Qt Tools? by BetaBleeds
Wait. I posted that comment in 17:33, but it shows it is posted in 15:33.
In reply to Wait. I posted that comment… by BetaBleeds
16:33 for me. But known issue...
(it is 16:42 here in central Europe now)
In reply to 16:33 for me. But known… by Jojo-Schmitz
So, what folder? Qt Tools? There's only Qt Creator.
In reply to So, what folder? Qt Tools?… by BetaBleeds
CMake does not find Qt5Core, Gui, Network, Test, Qml, Quick etc.
In reply to CMake does not find Qt5Core,… by BetaBleeds
CMake does not find Qt5Core, Gui, Network, Test, Qml, Quick etc.
In reply to CMake does not find Qt5Core,… by BetaBleeds
CMake "can't find resource" failures are probably because the Qt path is not set properly in PATH.
So make sure you've executed "Add C:\Qt\5.12.3\msvc2017_64\binto your PATH variable (C:\Qt\5.12.3\msvc2017\bin for 32-bit)"
Really, just following the instructions to the letter should be all that's required to be able to build MuseScore yourself. Feel free to join the developers channel on Telegram, where you're more likely to get faster turnaround times as that is.. well, a chat ;)
In reply to CMake "can't find resource"… by jeetee
Now I set it to PATH, but it still happens.
In reply to What part of Qt Tools? by BetaBleeds
What part of Qt Tools?
None for MSVC. None anymore for MinGW.
In reply to None for MSVC. None anymore… by Jojo-Schmitz
I changed to original 2015 pull change, but VS2017 says, that PulseAudio, Lame etc. not found, even though I downloaded dependencies. I think VS2017's CMake still searches from the old source code folder. I deleted CMake program. That helped in the old source code folder. I have set everything to PATH. Variables set to NOT FOUND.
In reply to None for MSVC. None anymore… by Jojo-Schmitz
And BTW, does the compilation work in Visual Studio 2019?
In reply to The following should by [DELETED] 5
I changed to original 2015 pull change, but VS2017 says, that PulseAudio, Lame etc. not found, even though I downloaded dependencies. I think VS2017's CMake still searches from the old source code folder. I deleted CMake program. That helped in the old source code folder. I have set everything to PATH. Variables set to NOT FOUND.
In reply to I changed to original 2015… by BetaBleeds
I changed to original 2015 pull change, but VS2017 says, that PulseAudio, Lame etc. not found, even though I downloaded dependencies. I think VS2017's CMake still searches from the old source code folder. I deleted CMake program. That helped in the old source code folder. I have set everything to PATH. Variables set to NOT FOUND.
In reply to I changed to original 2015… by BetaBleeds
If you changed to old code from 2015, MSVC won't work at all, the needed infrastructure had been added some time in 2018. You'd need to rebase to the current code base (and resolved the conflictes), this is needed anyhow,
In reply to If you changed to old code… by Jojo-Schmitz
And how do I do that?
In reply to And how do I do that? by BetaBleeds
not in this forumtopic ;-)
Have another look at the git workflow guidelines and again; either join the developers chat or open your own build issues topic in the development forum.
In reply to The following should by [DELETED] 5
That one doesn't work in MuseScore 3.
Another user requested this: https://musescore.org/en/user/101731/blog/2016/05/01/musescore-3.0-unde…
In reply to Another user requested this: by Isaac Weiss
Actually, my read on his comment is that he is assuming there will be a figured-bass-realisation function, but he wants it to ignore any bass note that is NOT figured. That might be problematic for scores which are figured according to the standard practise of not figuring eights, fives, and threes except when necessity for clarity. IOW, he wouldn't get a realisation of any root position chords.
In reply to Actually, my read on his by Recorder485
It seems more likely to me that it was somebody for whom English is a second language, meaning the "only" to come after the "if I," but you could be right.
In reply to It seems more likely to me by Isaac Weiss
Well, he did lose the 'o' in 'autOmatically,' but maybe he was just typing too fast. ;o)
Actually, his comment is a legitimate concern in the real (i.e. 'performance') world. Few composers or arrangers want the continuo realised as a series of 'piano-style' block chords on every beat. That sort of thing died out in the late 60s (the 1960s, I hasten to specify!). No one wants to see it come back, so the question of what to play and how much of it is germane.
There is a generally-accepted set of guidelines for how to play a figured bass; one concise reference on the subject is by R.O. Morris, Figured Harmony at the Keyboard (Oxford University Press, London, 1933). A more thorough treatment is F.T. Arnold's The Art of Accompaniment from a Thorough Bass as Practised in the XVIIth and XVIIIth Centuries (Ibid). But each continuo player will interpret a figured bass his own way; that's the inevitable nature of improvisation.
I'm surprised that no one brought this to my attention (I am the only author of a MuseScore figured bass manual known to me: https://musescore.com/user/1831606/scores/1745621 .) I deal with and realize correctly figured scores every day, countless examples (mainly Bach, movements large and small) may be found on my profile. Please read my intro.
I would not find any use at all for a feature that expanded block chords with no attention whatsoever to counterpoint. What's more, I'm afraid that such a feature, like the one-registration MuseScore "pipe organ", would provide a temptation for the non-knowledgeable to produce very inauthentic and bad-sounding music. Knowing how to interpret the numbers as meaning notes is but the first step of figured bass: the goal is understanding, Internalization, and macro-modeling of all the harmonic gestures of baroque music as encoded in figured bass (see online-available period primers by Francesco Durante and others). At some level (and this is contentious) awareness of the obbligato parts is desirable.
Although I would enjoy (not volunteering at this time) crafting code that attempted to compose truly credible continuo, that's really thesis-level work, and anyone who would benefit from it or understand its choices should be capable of, and should prefer, doing it themselves.
I vote "nay".
I don't know to which of the many new comments to reply, so I'm adding a new 'base' comment, in the hopes of redirecting the discussion back to the basic questions of need and desireability of creating a figured-bass realisation tool.
It's perfectly understandable that the code experts participating in this discussion have drifted off into the intricate details of HOW such a tool should be elaborated--Javascript, C++, Core, Plugin, API, Garbage Collection, and what-all--but, as no one on this forum is a coder without also being a musician (at least at some level) I hope I will be excused for adding my two-cents' worth. Obviously, I'm not speaking as a coder (you all know that the only code I know is a bit of basic HTML), but I am a musician, composer, and arranger, and a relatively advanced user. So I will attempt to bring that perspective back to the fore, because I think it's important. There is no point in designing a tool which only tool-designers would appreciate...and which many users could/would abuse through ignorance.
I will start with the basic premise that 'just because you can doesn't mean you should.'
Jim started this discussion and wrote his code because he was looking for a tool that would automate the (for him) 'grunt' work of deriving a basic harmony from an existing figured-bass notation. In other words, a short-cut, or crib-sheet, to lighten the work-load for an arranger wishing to expand a solo line plus figured bass into a full orchestration.
There are tools in MuseScore which make life as an arranger and composer MUCH easier than it would be without them. Automatic transposition is a big one which I think everyone appreciates; linked tablature staves are a slightly more arcane example, but one that is particlarly valuable to me: That tool makes intelligent writing for viols (or guitars, or lutes) much easier and faster for a non-player (who doesn't know the fingerings but needs to know what he is asking the players to do!). So yes, having tools of that sort is a good thing.
OTOH, the basic system of continuo figuring is no more complex than standard 5-line staff notation. One can learn to read (but NOT, I hasten to add, learn to play) figured bass notation with the help of a one-page paper crib-sheet downloaded from the internet. The problem is, that to use the information contained in the bass figuring intelligently, one needs to understand harmony first. Otherwise, one probably shouldn't really be arranging music in the first place. You don't choreograph a ballet without knowing the vocabulary of movement the dancers can physically accomplish; you don't write a novel or poem without knowing the grammar and vocabulary of the language in which you are writing. So while I understand Jim's impulse (I can be as lazy as the next guy), I don't see the lack of such a tool as a real problem.
Maurizio (Miwarre) and BSG have both pointed out quite elegantly the incredible complexity of what continuo playing actually involves, and I pointed out (last year, in this same thread) how many really BAD realisations of figured bass parts--realisations which take no account of the contrapuntal requirements, but only block out the chords in leaden, pianistic thumps--have been published by editors unschooled in that art form. If BSG's 'Baroque Police' (I love that term!) were to go looking for offenders, they would find a plethora of perpetrators to incarcerate from the late 1800s right through the mid- to late-1960s. So the question is, do we (the MuseScore community, I mean) really want to create a tool which would enable unschooled editors and composers to generate the kind of garbage realisations that gave Baroque music such a bad name throughout almost a century of poor practise?
I think the answer to that must be a resounding NO. If we were to do so, we would be following in the footsteps of 'Spel-Chek' and 'GramR-Chek' tools which have created a generation of 'writers' who can neither spell nor use their language properly. Having the ability to create tools implies a responsibility to abstain from creating ones which would degrade the very product to which those tools could be applied. I repeat: Just because you can, doesn't mean you should.
But what if, instead of a basic chord-generating plugin, we were to create a figured-bass realisation tool which DID take account of contrapuntal necessity? BSG, who is obviously an accomplished continuo player, made the particularly cogent observation that whatever such a tool would generate (similar to what a jazz improvisation tool might generate) might be good on one particular day for one particular user, but would NOT be good for anyone else at any other time. IMO, such a tool would, at best, create an 'acceptable' realisation, but not a particularly 'musical' one. At worst--and this is really important--it would tend to establish a generic realisation style that would become an accepted standard of quality and, because it is easy and requires no more expertise than clicking a mouse button, would make people think they don't actually have to do the hard work of learning how to play continuo properly.
Please don't do this...or, if you feel you must, do it as a sort of LISP add-on which would enable educated users to automate their own realisation styles. I admire and genuflect before programmers, because they can do things I can't...but when programmers become the arbiters of taste and practise--because their idiot-proof programs take over and idiots become the 'norm'--Art in all its forms is in big, big trouble.
In reply to I don't know to which of the by Recorder485
An eloquent screed, with which I agree completely, in detail as well as motivation and overall argument. A tool that reduced the realization art to pressing chord buttons would set the art back, not forward, because only non-artists will use it, and debase the currency of the art, exactly as @Recorder485 says. An extension to the scripting API that would allow musicians-programmers to research, develop, and experiment with their own realization systems draws the developer/user line more properly, and seems the only boon needed in this direction. Go figure!
In reply to An eloquent screed, with by [DELETED] 1831606
Thank you, my dear sir. I had worried that I might unwittingly offend someone with my rant; I am glad to see that that is not (so far) the case. I will, indeed, 'go figure'--but whenever I do, I check my work with a real continuo player (which I am not: I bought a spinet last fall--a lifetime dream--but learning to play it properly will take me the rest of my life...).
LISP I understand, even if I can't write it very well. I use(d) ACAD in one of my other lives (as a builder and remodeler), and 12 lines of LISP code saved me countless hours of cussing and fussing over the years when I wanted to copy one layer to another. I have no philosophical objection to something similar being developed for MuseScore that would enable users who know what they're doing to automate some of the drudge-work involved in producing an idiomatic continuo realisation. For myself, though, I do NOT produce or publish realisations of figured bass parts. Professionals don't need or want them, and amateurs/students need to do their homework instead of expecting me (or some other editor/publisher) to do it for them.
In reply to Thank you, my dear sir. I had by Recorder485
Well, Jim's and Marc's opinions count here, too, especially after Jim has done all this work which you and I think he should keep to himself.
Lisp (as my career spelled it) is absolutely my favorite programming language (see http://www.multicians.org/mepap.html for that bit of history), but the embedded interpreter in MuseScore is Javascript, not Lisp, which is still a pretty decent language, written well with the Lisp experience in retrospect. As Jim said, the ease of programming the current scripting API needs work/redesign/revision -- the problem is there, not in advantages of Lisp over Javascript.
I hope you have seen my elementary figured-bass manual (see top of my profile). I draw a distinction between "simple" realizations, which I teach there, and complex, ornate "musical" ones intimately involved with the texture and vocabulary of the movement, and provide examples of both among my postings. The former is surely amenable to serious automatic composition.
In reply to Well, Jim's and Marc's by [DELETED] 1831606
FWIW, I have a different take, although not I think completely opposite.
As I see it, MuseScore is, among other things, a tool for *composers*, and a composer is not necessarily required to be an expert in the *playing* of the instruments he writes for. He should know enough to not to do silly things of course, and hopefully even write idiomatically, but that isn't the same as being an expert. In the jazz world, certainly, many of the great composition have been written by people who really don't know much about how a pianist might create chord voicings - they know how to create the chord progression and they let the pianists take care of those details. I would imagine it would be similar when writing continuo. I don't know that the composer would expect the playback provided by MsueScore to be top-of-the-line in realism, but I do think it reasonable to hope to hear *something* being played.
Stated another way: if I give a saxophonist notes to play, I expect to hear him play those notes, and I expect MuseScore's playback to reflect that. If I give a pianist a chord progression to play, I expect to hear him realzie that according to his own expertise, and I'd like MuseScore's playback to at least give me *something* to hear. Similarly, if I write notes for a recorder, I expect to hear those, and if I write continuo for a harpsichord, I expect to hear that. I don't expect MuseScore's playback to be top notch, but I don't think unreasonable to hope to hear something, so as a composer I am not required to actually be a continuou expect any more than I am required to be a jazz piano expert (disclaimer: I *am* a jazz pianist, but again, many great jazz composers were/are not).
So I do think it important to keep the needs of the *composer* in mind, and not require him to be an expert in the playing of the instruments he writes for.
In reply to FWIW, I have a different by Marc Sabatella
So you're talking about realizing figured bass in playback only? What the continuo experts are pleading against (and what Jim worked on, I believe) is an actual notated realization.
In reply to So you're talking about by Isaac Weiss
No, 'playback-only' would make me think I was back in music theory class in 1967, taking dictation. ;o)
When composing, it's not uncommon to find one has created an ambiguous harmonic opportunity. By that I mean to say the melody could suggest/accept several possible harmonies under the same note. If a composer is working at the keyboard (harpsichord, piano, whatever), he'll simply play the different ways that could be harmonised and then scribble down the one he likes. If he's working on a computer, using a scorewriter, he can do the same thing by entering provisional triads to find out if his ear likes B-D-F or D-F-A or F-A-C best under that F in the melody line.
As a matter of fact, I do not even write the bass figuring until after the harmony of my piece is all worked out. I write the bass line--sometimes before the melody itself--but the figuring is done last, and (among other things) I use it as a check against harmonic errrors and typos that have crept into the score. In any event, a figured-bass-realising tool would be of little use to me (although as I mentioned last year, a bass-figuring tool might be worth trying out).
I think that what Jim wants is a tool that will 'guess' the harmony suggested by an existing figured bass and provide it both as playback and notation. That would save the work of seeing a '4/2' in the continuo part and checking a crib sheet to see that that signifies the third inversion of a 7th chord (i.e.: the written bass note above the figures is the 7th itself).
One of the principle problems with automating that is that figured bass is 'shorthand' notation for accomplished musicians; not all the figures are written, not all the notes are figured, and nowhere near all the information required to produce a realistic realisation is contained in the figures that do appear. That information comes from years of study.
In reply to So you're talking about by Isaac Weiss
I would not really want a playback only. I'd want to see what it's playing back.
In reply to FWIW, I have a different by Marc Sabatella
@Marc Sabatella--
Yes, I agree; it is NOT reasonable to think that a composer can play all the instruments for which he is writing. That's why there are orchestration textbooks and courses on orchestration in universities and conservatories. And that's why (for example) I personally find the tablature linked-staff tool so useful when I am writing for viols, because I play viol about as well as my grandmother flew an F-15.
But if I need to hear the full-chord harmony on playback (and that happens), I can/should enter the rest of the triad provisionally above the bass note in the BC part, and then delete it before I publish. IT IS NOT THE BUSINESS OF A COMPOSER TO TELL A MUSICIAN HOW TO PLAY AN IMPROVISED PART. Miles Davis never played the same solo the same way two times in a row. Neither did Coltrane, Grubeck, or Johann Sebastien Bach. Even the constipated, obsessive-compulsive control-freak composers of the late Romantic period (like Wagner!) had to deal with interpretations of their works, much as it made them grind their teeth.
Music is a LIVING art; no attempt to capture its essence as an algorithm can ever be truly successful.
In reply to @Marc Sabatella-- Yes, I by Recorder485
Regarding the suggestion that "if I need to hear the full-chord harmony on playback (and that happens), I can/should enter the rest of the triad provisionally above the bass note in the BC part, and then delete it before I publish" - I guess to me that's just drudge work the program can save me the trouble of. I'm thankful the program saves me the drudge work of rewriting identical passages by providing a copy/paste facility. I'm thankful it saves me the drudge work of connecting beams on eighth notes by doing it automatically. I'm thankful it saves me the drudge work of updaing the part when I edit the score by linking changes. And so on. To me, this is just one more example. Sure, I *could* put in a bare bones simplistic playback staff just so I can hear it, but if the program can do it for me, why not? I don't see harm in that - only good things.
In reply to Regarding the suggestion that by Marc Sabatella
To Marc's comment of 12:02. What is the basis of your surmise that deducing that "7b" means a flat seventh above the bass note is something that needs automatic help? I have realized more continuo parts than I can count, including dozens posted here that you can look at, and I have never, ever, felt that a tool such as that proposed, a solution looking for a problem, or any tool, would be of any help at all. Have you tried to realize continuo parts and felt, "Gee, if I only had a tool that could tell me what these damned numbers meant". Have you realized any continuo parts? Can you find anyone who has who feels that such a tool would be invaluable? It will result in the proliferation of scores on MuseScore with jazz-chart block chords, including disconnected expressions of dissonance, obliterating Baroque compositions. I would like to know the basis of your observation that such a tool merits the clangorous mess it will produce when used by people not competent to understand what it does (or why it exists, in whose ranks I count myself). Those are the bad things that pollute the dreamy observation of "only good things." Your assumption that "it", crude chord playback, is what the continuo numbers "mean", is incorrect. Have you read any of the cited books on continuo?
It doesn't seem like there's much hope for stopping this thing.
In reply to To Marc's comment of 12:02. by [DELETED] 1831606
To be clear: I have never tried to realize continuou parts at all, except as class exercises. But again, I'm not saying I want a tool to tell me what the numebr *mean* - I just want to hear a rough approximation of the harmonization I am creating without needing to do the drudge working of writing one out myself. Same with chord symbols. I don't get how there could be opposition to that.
In reply to To be clear: I have never by Marc Sabatella
"Same with chord symbols." That's the whole problem.
Chord symbols, in fact, can be realized by spilling out notes in some appropriate register. Jazz and rock composers do not compose suspension and cadential gestures and the hundreds of other mini-idioms encoded in figured bass. (To the degree that rock songs with characteristic, complex guitar riffs are flattened to "chord symbols" by people offering such, even that isn't so). Figured bass is not an imperfect Baroque predecessor of chord symbols, but a concise language for gestures.
If you compose your own figured bass, and do not use it for more than a substitute for chord symbols, and not an encoding for gestures, and think this tool will be useful there, I can't argue with you; since you are the figurer, your use case is believable. But for each such use (and I don't think there will be many), 200 unknowledgeable amateurs will apply it to Baroque scores (probably improperly transcribed; you can't even copy figuring unless you understand it some), hurling clumsy block-chords over their carefully manicured landscapes. FDA bottle label warnings, ¡Aviso! Achtung! Warning! Not for use in providing accompaniments! will never be read or observed. That is all it will be used for, and they will probably blame MuseScore for what it's not.
In reply to "Same with chord symbols." by [DELETED] 1831606
It is as naive to believe chord symbols can be realized in any truly effective manner by "spilling out notes in some appropriate manner" as it is to believe the same for continuo. Maybe in the most simplistic musuic this might work OK, but it's certainly not remotely like how actual jazz or rock or funk etc are actually played. Chord symbol realization is at least as subtle and complex art as continuo realization. And yet, simplistic rendering is still useful to a composer, either to hear a very rough approximation without needing to do the drudge work of writing out a simplistic realizationb himself, or to give himself a headstart on actually converting the simplistic realization to a more effective one.
You are worried about 200 unknowledgeable amateurs creating music using figured bass for every more knowledgeable one - frankly, I think you greatly overestimate the popularity of figured bass in modern society :-). I doubt there are that many people composing using figured bass who are *not* knowledgeable.
And in any case, I disagereew with the basic preimse that is wrong to make it easy to create and post music which yuou personally consider bad. There is a *ton* of music out there (whetehr on musescore.com, or YouTube, or wherever else) that any given person might consider bad. The vast majorty of it never uses figured bass at all. It's a fact of life - people wil post music you or I might consider bad. The fact that the figured bass realization tool could potentially be used to create bad music shouldn't dissuade us from creating one.
If the possibility of a tool being used to create music we consider to be bad was a valid reason not to create the tool in the first place, then the next logical step is to suggest Werner should never have created MuseScore.
In reply to It is as naive to believe by Marc Sabatella
I stand corrected on chord symbols.
There seems little point in talking about this any more; it seems that it is in the cards no matter what.
In reply to It is as naive to believe by Marc Sabatella
Hi Marc, I basically agree with you. It's a shame that it's not really possible with the current architecture to make this feature extensible to the end user. But having something that creates a starting point is food. Then the user can interactively change notes which are wrong by using the and keyboard. I know that many people disagree. But that's still my opinion.
I also agree with you that having this feature won't cause 100s of people around the world fall in love with imperfect baroque music. And even if it did, we'd get alot more interest in the product, and you'd have lots more talented programmers wanting to fix and improve things.
My $0.02 worth.
In reply to Regarding the suggestion that by Marc Sabatella
@Marc--I do NOT disagree that eliminating pure drudge work is one of the good things computers can do for us. It's great that I can click the mouse a few times and transpose my first theme to the subdominant for a recap as an oboe solo...BUT I KNOW WHY I'M DOING THAT, and I also know what adjustements to make so that it works musically.
My fear is a deeply philosophical one, based upon having grown up through the dawn of the television age and now in the computer age. Over my lifetime, I have seen a steady degrading of human skills and knowledge among the general population as a result of technology (of whatever sort) DOING THE HARD WORK FOR THEM. Fewer and fewer 'artists' today have spent the time and effort required to really LEARN their art; it's easier and faster to 'let the program do it'. How would you feel, as an accomplished jazz pianist, hearing someone play a software-generated 'realisation' of the piano part for Take Five or one of Oscar Peterson's amazing works? (Hey, barmaid! Get me another Scotch; I'm not drunk enough....)
For non-interpretive, basic functions like automatic transposition, cut-and-paste, read-outs of fingering, beaming, updating changes, letting the computer do it doesn't matter, but for interpretive things like continuo realisation, it absolutely does. What Maurizio said last year bears repeating: Professionals who could use it intelligently won't bother. The great likelihood is that the only people who will use it will MISUSE it.
I feel a bit like Steve Jobs in that speech where he argued vehemently that programmers need to wake up to the responabilities incumbent upon them due to their ability to change the shape of the world. You guys DO have that ability, you know. Create a tool that will help humanity spend more time on important things--like learning--and all is well. But create a tool that will allow humanity to SKIP THE LEARNING PROCESSS WITH A CLICK, and we're doomed.
In reply to @Marc--I do NOT disagree that by Recorder485
Well, such a tool has already been created in music21: http://web.mit.edu/music21/doc/moduleReference/moduleFiguredBassExample… Do you think it's been a damaging force?
In reply to Well, such a tool has already by Isaac Weiss
Whoa! There's a world of difference between that tool and what's being proposed here. The MIT tool actually knows how to realize credible simple figured bass competently (although it disclaims ability for more complex cases). I'd love to experiment with tools like that via MuseScore scripting. But that's not at all what's being proposed.
If such a tool were available in MuseScore (and realizing the real figuring of real scores involves many cases not (yet) handled by the MIT tool), it just might be a thing of use and beauty. I would not at all mind writing one, but it should not be part of a hard-coded core.
What that tool does (its examples on that page) is just beautiful. A beginner could actually learn from what it does.
In reply to Whoa! There's a world of by [DELETED] 1831606
Well, why not try to make a figured bass realization algorithm that's good enough?
In reply to Well, why not try to make a by Isaac Weiss
Well that one, which is in Python, is pretty much "good enough", at least I would be satisfied with it as actually doing the job needed (or is your question about improving that one to handle actual historical scores not written for it?). While I would be very amused to see something like that in MS, I have reservations about both its appropriateness as unmodifiable, untweakable C++ code, as well as its trespass on the area of computers doing creative work for you, where @recorder485 (with some reason) doesn't feel they belong (at least for score tools, not graduate research projects).
In reply to Well, why not try to make a by Isaac Weiss
@ Isaac, that's the plan, but it will take several iterations.
In reply to @Marc--I do NOT disagree that by Recorder485
As a professional jazz pianist and educator, I actually rely on programs that do automatic realization of chord progressions a *lot*, and so does virtually everyone else I know. They are incredibly useful tools for learning, teaching, practicing, etc. We don't generally use them so we can post the results on YouTube; we post them for our own private use, whatever that might be. But we don't worry about the fact that someone else might use them for a purpose we personally don't approve of. I would not want to be without iReal Pro because it helps *me* do *my* job, and I just don't care if someone else uses it for something different that I personally wouldn't need it for.
FWIW, I'm not suggestion a continuou realization do anything much "interpretative" at all. I specifically suggested it *not*, in fact - that it just do the most basic bare bones realization. Ditto with chord progressions. That way, a skilled composer could then take that raw material and work it as he sees fit. Or a plugin could perhaps be developed to do the same. But my reasoning here isn't thast I think a more sopshisticated realization tool is a bad thing - just that it doens't really belong in the MuseScore core program, as it is not central to the primary purpose. But I don't see how development of a tool that helps composers eliminate some drudge work from their lives can possibly be consider to "allow humanity to SKIP THE LEARNING PROCESS". That is a complete red herring that doesn't help the discussion at all.
In reply to As a professional jazz by Marc Sabatella
@Marc--
My friend, I am sorry I seem to have offended you, as that is the last thing I would want to do. I have profited and learned a LOT from you about MuseScore over the years, and I value your knowledge and advice.
I may have failed to position my argument properly, as the current marketing lingo would have it. What I am trying to do is roll back the argument about the value/dangers of THIS particular tool to the broadest generalities, so that the tool we are considering creating can be seen in a global perspective.
I am the type of person anthropologists call a 'tool user.' In my life I have done a lot of different things, and virtually all of them involve using tools. But tools, while they make our lives easier in many ways, carry with them inherent dangers. Many, many years ago, when I was first learning to do woodworking, I nearly cut off two fingers on my left hand because I bought a circular saw and started to use it before I understood what it could--and couldn't--do. I have a nasty scar and a deformed fingernail on those two fingers to this day, and it is a reminder to me that if you don't 'read the operator's manual' before plugging the thing in, you are looking for trouble (and will probably find it).' Unfortunately, in today's world many (I would almost say 'most') people DON'T read the operator's manual. In fact, in certain circles, you can lose your 'man card' for even taking it out of the shrink wrap. I try not to run in those circles, but they outnumber the rest of us a lot worse than 200:1.
But that dictum, banal as it sounds, is an analogy for a basic philosophy of life. In my view, it applies to circular saws, motor vehicles, washing machines, wrenches ('If you don't have any judgement, use a small wrench.), pressure cookers, lawnmowers, steam irons, electric guitars (you know that scene in Back to the Future where Marty McFly blows himself backwards through a wall with a single chord? First time I ever played an electric guitar I damned near did the same thing!)...and, most cogently, computers.
Computers are without a doubt THE single most life-changing addition to the tool universe since Ben Franklin hooked a kite to a coffee pot and invented Mr. Coffee. As such, they wield a power over people's lives that is beyond easy comprehension. While power tools and household appliances make physical tasks, such as sawing wood or washing clothes, easier, computers make mental tasks easier.
The parallel is easy to see. If you asked a carpenter today to make all his cuts using a crosscut saw and a rip-saw, he'd look at you like you were from Mars, and even if he didn't, he wouldn't be able to do a decent job of work because carpenters today have lost the ability to use a hand-saw efficiently and correctly. By the same token, most people can't drive a stick-shift car, use a washboard or a flat-iron, or cook on a wood stove. If the infrastructure ever fails (and there are doom-sayers who delight in predicting that it will!), those people will die a lingering, nasty death and the survivalists will take over. (Shudder!)
But that is nothing to what happens to people who cease to learn and think because 'there's an app for that!' Computers, and the programmers who create the software they run, have made learning basic skills aleatory for most people. You don't need to learn how to spell or match case or tense in your verbs; you don't need to learn how to add and subtract and make change; you don't even need to learn how to count beats in a measure and draw the barline at the proper place! There's an app for all of that. So why bother? Duh....
Granted, people like you or me or anyone involved in this discussion, know enough about music to use this tool intelligently, but we are vastly in the minority. We would be doing no favour to the rest of the users out there by handing them a tool as potentially brutal as a chainsaw or machine gun. Do you really want to see a plethora of new editions with figured-bass realisations like those produced during the dark ages from 1875 to 1975? It took caring, scholarly musicians scores of years to bring Baroque music back to respectability after a century of bad practise. I beg of you, listen to BSG and Maurizio; they know far better than I do what is needed to do this responsibly.
In reply to @Marc-- My friend, I am sorry by Recorder485
This is an elegant essay, and I agree with most of it, but a couple of things have moved me from the "hard-line believers" camp since yesterday. Jim has said to @Isaac, "this is just a start, and I would like to have a 'real' one", and we have seen "a real one" at the MIT music21 project pointed to above - it really, really realizes in a simple, but acceptable, style.
If this really were a project towards a figured-bass realizer of music21's level of accomplishment or better, I would be excited about it (and yearn to contribute) rather than discouraging it. But there many, many questions about such an effort, beginning with its overall appropriateness in a score editor (the good arguments you have raised), and the massive UI that would be required to tell it minor details like the beat-level expectation of the figuring (see my BWV 113.2 for a 4/4 movement where the figuring beat expectation (affects figure-less notes) is eighth-notes), and parameters that vary across the face of Baroque Europe.
The gorilla/elephant in the room though, would be, "Well, I hope to have a figured-bass realizer that would flip out Frederick II of Prussia and his horsemen, but I only got around to something that chunks out parallel chords because of time/resource constraints", at which point all the present criticisms blossom. But all of those arguments would rest quietly if realization functionality could be constructed and "plugged-in" by a knowledgeable user(s) and their friends.
(For what it's worth, "realizing" to block notes is not a good starting point for further realization functionality, as it evaporates differences between 9 and 2, 10 and 3, and so forth; often, the explicit presence of a seemingly implied 5 or 3 informs tradeoffs -- one must see the original figures).
In reply to This is an elegant essay, and by [DELETED] 1831606
@BSG--
The level of complexity of the MIT tool is far above my pay grade, but I can see what it would be capable of doing if used by someone who had, indeed, 'read the operator's manual'. IF the proposed FB realisation tool for MuseScore would be of the same order, I would withdraw most of my objections, leaving only the worry that whatever default setting for the tool was embedded in the core code, that would be what 99% of users would use. So those default settings had better be capable of generating realisations a LOT more idiomatic than Walter Bergmann ever produced. (Bergmann was an important figure in the revival of Baroque recorder literature, but his realisations were, by his own admission, heavily pianistic. In fact, he thought if he didn't write them that way, people would think he didn't know how to do so!)
The practical problems of presenting such a tool in MuseScore are probably already obvious to you. To grant the sort of control the MIT tool comprises, the Figured Bass 'Styles' dialogue would have to include all those rule options (forbid/allow voice overlap; max semitone separation; part movement limits; forbid/allow parallel fifths; etc.). And that page on the MIT site didn't even get into the treatment of suspensions, passing notes, and so forth, a lot of which aren't always figured, but inferred by the continuo player from the score above. (In other words, no one who isn't already an accomplished continuo player will have a clue which radio buttons to check or what parameters to enter, so the default settings will, in most cases, run the tool.)
And this raises yet another spectre of complexity: As you know better than I, figured bass notation is a SHORTHAND notation. Contemporary manuscripts of the period were produced by harried composers and copyists working against deadlines ('Anna-Magdalena!! Stop fussing with my verdammt wig! The parts for this cantata have GOT to be ready for Sunday or I'm gonna be in the scheiss!). In most cases, the composers or copyists knew the harpsichordist/organist who would be playing the part well enough to know what he needed to see and what he didn't (and in Bach's case, the continuo player was most often Bach himself). For that reason, contemporary Baroque figured bass parts leave out a LOT of figures, and while an educated continuo player of today could/should be able to intuit the missing information, a computer program would have to be as 'educated' as you are to do the same thing. Is that possible? I don't know, but you would.
Add to this the reality that continuo players each have different styles and ways of interpreting what's printed on the page (Hank Knox does not play the same way as Eric Milnes or Skip Sempé), and we are faced with a situation wherein the programmers who define the algorithm wind up defining what might very well become THE standard style of continuo interpretation. Is this a good thing?
In reply to @BSG-- The level of by Recorder485
I agree strongly with all of @recorder's (may I call you that?:) observations and sentiments here, in particular the "deep" and "purpose" and "what will it loose upon unsuspecting men and women?"/"what will it do to our world" questions (e.g. "(unwillingly) become the standard"), and "were it that, I would withdraw all my objections", too.
A couple of notes, as it were. Firstly, passing tones are (usually, but not always) not in figures, and when not, not necessary. Suspensions, on the other hand, always are indicated in proper figuring, and their correct realization, through recognition of the patterns in adjacent figure-stacks, is an important part of the art.
Secondly, I would like to further emphasize my point that, in my opinion, music21's realizations are not "really advanced, musical, professional" realizations, but "bare bones/simple correct" realizations, the minimum someone versed in this might consider acceptable. Block chords are not a "bare bones, simple realization", even if they might be useful to someone for some other purpose.
As @Marc said, a negotiation of this term is called for.
In reply to I agree strongly with all of by [DELETED] 1831606
A lot of my concern in this area is due to the facility that digital technology provides for what are now known as P-O-D ('Print-on-Demand') publishers. I am one of them, but I spent 15 years in the graphics and publishing business in 'the old days' when it cost MONEY (and required the attendant expertise to obtain that money) to publish something professionally. Today, any idiot (sorry if that offends anyone) can publish a professional-looking musical edition without all that expert editorial oversight if he owns a PC and a $200 desktop printer.
I do my musical homework, and every edition I offer for sale is the result of months or years of research and consultation with other musicologists and specialists (no figured bass in my editions is ever pubished without being vetted by an expert continuo player, because I am VERY aware that I am not one). I have a GREAT horror of being found lacking by my peers (and superiors), so I DO the grunt work to ensure that I won't be. That's just me. Your mileage may vary....
But I am also aware that my standards of editorial quality are the exception to the current rules. 'Everybody' today has a blog or posts whatever screed they want on their Facebook page, and there is no expert oversight. That is, at the same time, both the benefit and the curse of the internet age. Iconoclastic geniuses with no commercial appeal can, finally, see their work published. But by the same token, jackwagons and jerkballs without a clue in creation can do the same thing. There is, it seems, no silver lining without its attendant dark cloud....
In essence, what bothers me is the prospect of seeing a new proliferation of musical editions published by people who download something from IMSLP and copy it verbatim using MuseScore (or some other scorewriter), and then swap the original solo instrument for the one they happened to play in high school. Recorders become flutes; bass viols become cellos...and harpsichords become (of course!) pianos. And voilà! We wind up with an edition of Handel's Sonata for Recorder in F major equivalent to the garbage published by Southern Music Corporation in 1950-something, edited by the principal flutist of the Cincinati Symphony Orchestra! If anything could destroy the hard work of the last generation of serious Baroque musicians to bring this elegant and sophisticated music back to the fore, this kind of publishing practise would be it. This is the windmill at which I tilt. (Yippeekayay, Rocinanté!!)
If MuseScore offered people like this a one-click tool that would 'realise' a keyboard part from a copied (but not understood) figured bass, they would use it, no matter how bad the musical result. And we would again find ourselves indundated with a flood of bad editions purporting to be authentic, making the general population of sheet-music consumers--which includes music teachers in high schools!--think that Baroque music is personified by Pachelbel's Canon and is effectively no more complex than a I-IV-V-I country song wherein the composer's dog done died, his girlfriend runned away, and his truck broked down.
In reply to A lot of my concern in this by Recorder485
:)
:)
In reply to @Marc-- My friend, I am sorry by Recorder485
First, not to worry, I'm not offended at all, and I hope I am not offending you or anyone else. Strange how the most esoteric of discussions can sometimes get so intense.
But rather than a long point by response, let me just summarize my feelings: a tool that provides a basic bare bones realization that a composer could choose to listen to as is or then edit or apply a plugin to in order to make more realitic would be a useful thing to some. I do not like the idea of depriving MuseScore of a useful feature just because some unnamed amateur musician might use that feature to do something that other disapprove of. A useful feature is a useful feature.
In reply to First, not to worry, I'm not by Marc Sabatella
One assumption in your letter is factually wrong.
A sorted spillout of the indicated scale degrees does not qualify as even a 'basic, bare-bones' realization, in spite of the fact that such a spillout may be useful to you or others in some way other than as an accompaniment to a performance. Not even a first-day continuo learner would play such. And, as I have said in previous response, it throws away information that a competent plugin would need. It is a collection of notes, not continuo realization, not music. Look at the music21 page @Isaac indicated for what a 'basic, bare-bones continuo realization' means.
It is roughly comparable to the "organ" instrument in the synthesizer and MuseScore's support of it with two manual and a pedal staff, which, to people who know nothing about how organs are organized, encourages them to set even the quietest chorale preludes for "organ" using that plenum registration on manuals and pedal. Speaking of manuals, as @recorder485 says, nobody reads them any more. Their absence just encourages accidents.
In reply to One assumption in your letter by [DELETED] 1831606
I never said *what* I thought would consitute a basic bare bones realization. To me, that's the constructive discussion waiting to be had here.
In reply to First, not to worry, I'm not by Marc Sabatella
@Marc--
Well, glad to hear that. You're a stubborn man, Marc Sabatella...but then again so am I. So perhaps we comprise a particularly valuable debating pair. If our exchanges of opposing views can inform the question, that's a good thing in and of itself.
Peace. :o)
In reply to @Marc-- Well, glad to hear by Recorder485
:-)
I should make it clear also that my interest here is really about chord symbols more than figured bass, but I would want whatever facility we designed to be able to serve either purpose so we don't need to implement a separate underlying framework for figured bass if it's psosible for some basic code to be shared between the two. So that means *understanding* what might be required to do whatever makes sense for figured bass so that whatever framework we create would support figured bass, even if the actual figured bass implementation doesn't happen right away (or, for that matter, ever).
In reply to Well, Jim's and Marc's by [DELETED] 1831606
;o)
I only mentioned Lisp because it is one of the few terms you guys were tossing around that rang ANY sort of bell in my consciousness. I really am the compleat ignoramus when it comes to computer code (I still use crib sheets when writing html for webpages...). And I distinctly remember being reminded (IN ALL CAPS!) by a friend that 'JAVASCRIPT IS NOT THE SAME THING AS JAVA!' So you get the idea of where my head starts to explode....
Certainly, Jim has a serious dog in this fight, and Marc's opinions aren't to be ignored, either. All I am trying to do is focus the discussion on what Marc might call the 'use-case' for this tool, and fight the Quixotic fight against 'handing machine guns to children' on a silver platter.
This 'slippery slope' argument is not a new one for me. I have a nephew, a very intelligent design engineer for Honda and the son of a person with a doctorate in education. He canNOT spell to save his life without using 'SpellChek'. His mother, who rose to become a full professor at Ohio State before she retired, doesn't think that's an important lack, 'because the computer can do it for him so why should he bother?' That right there is scary enough to make me want to hide under the bed. If this goes on, as Dilbert might say, 'We're doomed.'
In reply to ;o) I only mentioned Lisp by Recorder485
The idea of a "figured bass assistant" who plays accordion-chord buttons in response to figures, and you can't even affect his crude improvisation at all strikes me as an embarrassment not worthy of this superlative, professional-grade product. Figured bass is not a "guess the triad", "guess the chord-button" game; it is both a descriptive formalism for the harmonic-contrapuntal gesture space of the movement as it is, as well as a prescriptive one to supply background in thinly-scored movements. Figured bass realizers, human or automatic, are supposed to understand and comply with the rules of classical harmony and counterpoint, end of story.
MuseScore's sampled instruments, especially lacking the articulation controls they do, are not the equal of your own live ensemble, but they are damned fine, and any competent composer/arranger, such as many, many on this site, can cause them to create amazingly realistic ensemble sounds, not the equal of a live ensemble, but it sounds remarkably like one.
A playback-time chord-button figured-bass assistant breaks this model of professional results. Why would an amateur composer want figured bass at all? Why would an amateur arranger trying to do a credible rendition of a Baroque piece want a grossly unrealistic, crude fist of a chord that would ruin the otherwise excellent, competent sound of the rendition? Isn't someone aspiring produce credible renditions of Baroque music required to learn a little about the subject? If that's too much, "Are there no concerts? Are there no record players?" YouTube seems to be working well these days....
It is not the business of the composer to tell the improvising player how to improvise, but it is the business of the composer to hire improvising players competent in the style needed. Unless you want breakthrough thesis-work in musical artificial intelligence, no program I know is up to that task. There seems to be a mistaken idea floating in this thread that figured bass does nothing more than identify some notes to play. My shelf of books on the subject seem thicker than that. While vaguely related to jazz/rock chord charts, it is not at all the same thing.
The idea that it would give the unknowledgeable arranger "an idea what the accompaniment would sound like" is false. The figures really do tell what the accompaniment ought sound like, but only when you realize it within spec.
I don't think this is an idea consistent with the quality of this fine product.
In reply to The idea of a "figured bass by [DELETED] 1831606
One more observation against the argument that you need the realized continuo to “know what the movement sounds like.” I invoke the descriptive as opposed to prescriptive function of figured bass: Bach didn't think you needed it to know what the very movement you (and I) use as an example sounds like, for it appears senza basso continuo as the renowned organ chorale-prelude BWV 645.
In reply to Well, Jim's and Marc's by [DELETED] 1831606
@BSG, nice that you're a lisper, I thought I was the only one.
In reply to @BSG, nice that you're a by jim.newton.562
Lisp was a very, very major theme of most of my career, those who influenced me, and those I influenced, and my favorite language; I assume you saw the Emacs paper mentioned above. Msg me and I'll send you access to the "famous Lisp notes" I wrote years ago. Boy, would I love to script MS in Lisp.
In reply to Lisp was a very, very major by [DELETED] 1831606
Yes, I saw the paper. I'll will read it later. It is a significant work. I'm working on my PhD, and perhaps this paper will be interesting for my bibliography.
In reply to Yes, I saw the paper. I'll by jim.newton.562
Jim: I also want to clarify (in response to your top of thread) that "no figure" does not mean "the obvious chord", if a work is figured correctly. It either means "5/3" or "no change of chord; same as last", depending upon whether the note is a "principal beat" or not. Normally, in a 4/4 movement it is quarter notes, in a 12/8 movement it is dotted quarters, etc., in an easily codable way. But in some slow movements, the principal beat is smaller. There are also figuring faults, which are rare, but I have seen them, where an "obvious figure" is left out, but this is not to be expected or composed.
See #288529: Figured bass text could be translated to extra notes
Although I might join the proud group of MS developers, I really do not need all the notification of Windows building problems arriving in my mailbox under the heading of "Realizing figured bass", the latter subject one of deep interest to me, and the former ... "not so much". Can you take this discussion elsewhere? I don't want' to unsubscribe this topic.
How do you do that command of yours?
In reply to How do you do that command… by Dylan_Rocks
How do I find this command?
In reply to How do I find this command? by Dylan_Rocks
If you mean, the experimental code that was being worked on a few years to "realize" figured bass (turn figured bass notations like "65" into actual notates on the staff), that was never actually added to the program. But there are plugins that can attempt to do this sort of thing. probably if someone wanted to do this, writing a plugin would be the way to go.
Or if you just mean, how to create figured bass, the command is Ctrl+G. See the Handbook section on figured bass for more info.
But do note MuseScore does automatically generate the playback info regular chords symbols (like G7/B), and if you want to see that on the staff, use the Realize Chord Symbols command from the Tools menu