Posted
tl;dr: Let us place some notation elements inside Synfire which will then be exported to XML, to improve the workflow when using notation software programs.
If you also need this, please support the thread with your comments and opinions.
See the attachments for the image at full resolution.
Notation is IMHO very important for a software that wants to be a music prototyping software. Synfire's (and other composition programs') goal is not, obviously, to create beautiful scores, because they already have so many other things to do; therefore advanced notation things (and certainly style and pagination) should be done externally with programs like MuseScore or Dorico.
This however means that exporting should be complete and functional (hopefully we're getting there?) and that it should also include some basic notation indications like e.g. accents, in order to make the process of notation less tedious. Not only it's tedious to e.g. put all the accents in a very long piece, but if you were to change anything in Synfire and then re-export, you would have to do all that work again.
Therefore, the feature that I ask for is very simple, and I think not technically hard to do at all: let us apply some basic notation markings to segments and/or symbols.
To avoid confusion for those that don't need the feature, make it off by default and let the users activate it via Preferences.
Pro:
- Extreme improvement in the workflow for those who care about notation.
- Regardless, increased value of the software, because notation is a fundamental part in music composition, teaching, etc.
Cons:
- None
If there are any issues with readability, one can simply (and optionally) display things like this:
Old text for reference
A list of the most useful features that come to mind:
- Before anything else: comments; just text for the composer; could be exported e.g. as a <words> element, maybe with some color for easier individuation. A first version could be just this and nothing else.
- Accents, staccatos, trills and tenutos applied to symbols
- Tempo indications (that the user can simply manually type, e.g. rallentando); just text!
- Expressive markings (that the user can simply manually type, e.g. crescendo, rubato, or dolce); no need for hairpins
For missing features, one can simply type comments and then apply the actual thing via one's favorite notation software program.
Tue, 2022-03-01 - 17:39 Permalink
The idea to add additional tags is fine. At least for tuplets that would make sense. Automatic detection of tuplets is really hard (ambiguity).
The notation export was originally intended for songwriters to export a lead sheet with chords and lyrics. Over time it got more extensive.
Fri, 2022-05-20 - 02:11 Permalink
This idea was actually more for accents and similar things. For tuplets it would be very much preferable to have a different feature dedicated to that, well integrated into Synfire, and it would probably require a bit more work than what I was proposing here. And it would probably have to work with groups of notes instead of single notes.
Tue, 2022-05-24 - 21:48 Permalink
OP and thread title updated
Discarded the old idea of exporting just "comments" and simply asking for basic notation support, which is practically the exact same thing from a technical point of view.
Thu, 2022-07-28 - 23:07 Permalink
Do you think there's any chance of implementing comments/text only, any soon? Because I've got the hang of MuseScore's plugins development, so if you implement exporting comments to notation in Synfire (either as a StaffText element or whichever), which I suppose is very easy to do, then with QML I could do everything else that I need.
There would still be the tuplets issues, but even those can be worked around with this feature: add to a segment the text "7:5", and then I can, either manually or via plugins, adjust that measure.
If you do this, then you can basically forget about notation for quite a while (except the MIDI resolution increase thingy for tuplets, that's very much needed), so it sounds like a good deal. :)
By the way, there's not even the need for the visualization right now, even just a super simple asterisk near the segment (or something like that) to indicate that there is a comment there, would be enough for now; I just need this functionality very badly. And it will always be needed even if Synfire later gets crazy internal notation support anyway, because there will always be something that you can only do via notation editors.
It will also be useful for users who do not program, because plugins for the various notation editors could be shared by the community.
Thu, 2022-08-04 - 09:58 Permalink
Attaching text to a segment is not a problem.
It's not clear how to export this information to MusicXML. How to express which notes are included, to which voices it applies. Extending MusicXML is beyond our capacity. Maybe you know a particular tag that could be used.
Rhythmic information becomes meaningless once you move or stretch a segment. Attaching anything that depends on absolute position and other context violates a core principle of Synfire: Everything is movable, transformable and reusable. There must be a very strong and popular use case to break with that rule.
For the same reason it is not possible to edit MIDI output in Synfire. Or edit the pixels of a rendered scene in Blender.
Thu, 2022-10-20 - 15:24 Permalink
Attaching anything that depends on absolute position and other context violates a core principle of Synfire: Everything is movable, transformable and reusable.
Don't forget about this idea though:
Option to disable MIDI pos and length manipulations when exporting
An option in the global export settings to disable Shift, Pause, Flow and Step parameters for the entire arrangement when exporting. This way, if the user wants to export to notation (or to MIDI and then to notation) and don't use those parameters, things like rubato will not affect the output.
There must be a very strong and popular use case to break with that rule.
Not if it's an optional checkbox. Moreover, we may be only three dudes actively discussing notation things, but notation is very important for such a type of software program regardless of how many users are discussing it.
It doesn't seem so crazy to me that one wouldn't care about Shift, Flow, Morphing, etc., but would care about the great Harmony and Factories features. You should give support to both user cases, especially because we are talking optional stuff: you are not going to force anything to the users.
I'm open to other ideas though; there might be better ways to implement this. Something else that comes to my mind is to tag stuff in the output (this wouldn't violate much of any principle because it's not about changing the actual MIDI output, it's just applying tags); if then you change something, stuff will be lost: whatever, I'll apply my accents again; you will likely apply notation tags only when the piece is already almost complete. With some simple tricks you could also make the software remember what he applied and where, so if you only change small things, it wouldn't lose the tags. The former solution seems better to me, though.
Point is, the Palette, the Progression page, and the Factories are currently the best in the market in what they do. These however are indirectly made almost useless to those who care about notation, because it forces them to a very annoying workflow.
Thu, 2022-10-20 - 16:16 Permalink
I don't use the notation output but I really don't understand why you would want to omit Shift, Pause, flow, step, etc when exporting to a scoring app. Just wondering what the use case would be for this?
This would mean potentially your sheet music version would bear no relation to the audio version. Aren't you complaining the notated score doesnt match the audio exactly, so you want to make it worse?
I can understand from Andre's point of view why he would not want to implement this functionality. What you are asking to be omitted (optionally) are not parameters that are ever "exported" and wouldnt be understood by the notation software if they were. They affect the note pitches, timing and whether whole phrases are included or not. Andre would have to change the renderer so the export could re-render the whole tune with those features disabled, export the resulting midi as xml (or whatever format is chosen), then re-enable those parameters and re-render the whole tune again, only to produce a notated output that could be different from the audio.
A work around which you could try at a push if desperate: save your tune, optionally create an 'export container' covering the duration of the tune and snapshot into it (may not be required depending on how complicated your tune is), delete the parameters (using the green parameter indicators) you dont want to export, export to notation, then reload your tune.
Thu, 2022-10-20 - 16:52 Permalink
The users who want to export to notation are forced to write already quantized figurations, so they cannot use (currently) those mentioned features of Synfire (not that I care about those anyway, I only use Synfire for the harmony and factories features, I prefer then to change the figurations manually without using that kind of workflow). In your mind you probably think that you can use them anyway and just use the quantization options in the export settings, and then get a good music sheet; sadly this doesn't work because notation and automatic quantization are currently very bad and tuplets are not fully supported; so unless you compose Happy Birthday, the result will be bad; so we need to create figurations that are already in their final state, and avoid features like Shift, etc.
Moreover, the feature request of this very thread cannot be implemented if those features are used, because then Synfire wouldn't know anymore which note is which symbol.
So it's not that I'm using those features and then I want to disable them. I'm not using them at all, except for some things like rubato or staccato, which serves only for the audio export. I hope this clarifies it for you.
Anyway, your snapshot trick does indeed work, for things like rubato, so you can just remove rubato before exporting; however you need to do that on every container that contains those kind of parameters, and so it's easy to e.g. miss a Flow inside some container which was used to render a staccato playing, but that you wanted to disable to export the full note value to notation.
Thu, 2022-10-20 - 18:14 Permalink
If you create a snapshot in a container that is as long as you want to export then you only need to disable/delete parameters in that one container.There is a video tutlorial somewhere hanging around that shows technique although its use was for something else using v1 (may have been to transfer to a different project).
Editted to add, you would probably have to leave an "empty" parameter in the container for all those parameters you dont want included in the export.
Thu, 2022-10-27 - 13:03 Permalink
Convert to sheetmusic or Music XML is for Pro version only. I think 80% own Express.
Fri, 2022-10-28 - 12:28 Permalink
So what. If anything, it's one more reason to improve the feature, so the Pro version is more appetible.
Tue, 2023-03-14 - 21:30 Permalink
create a snapshot in a container that is as long as you want to export + disable/delete parameters in that one container.
Hm, that could be an interesting workaround to remove these parameters for better music notation export, even if a bit fiddly.
It's not even that fiddly, but it only solves the part about removing audio rendition elements from the resulting MIDI/XML. We're still left with not having any useful information in the resulting score other than the notes (hence the title of this old thread).
Tue, 2023-03-14 - 23:50 Permalink
Rhythmic information becomes meaningless once you move or stretch a segment. Attaching anything that depends on absolute position and other context violates a core principle of Synfire: Everything is movable, transformable and reusable. There must be a very strong and popular use case to break with that rule.
For the same reason it is not possible to edit MIDI output in Synfire. Or edit the pixels of a rendered scene in Blender.
I've noticed recently that you can already apply articulations to symbols and segments though. So, if rhythm is out of the equation, it seems fine to apply other info to symbols (or just add more options to articulations).
This is why I was proposing is a simple checkbox in the Global Export settings to tell Synfire that you're operating in that sense, that you are not going to care about Shift, Morphing, and so on (maybe you even used those features, but you then snapshotted them! - along the lines of the good input from blacksun), and that you want Synfire to attach something to a symbol because it's going to result 100% of the time to a corresponding note anyway.
The core principle of drawing figurations and getting different MIDI output depending on the harmony and other settings is still there, so it doesn't sound like a dealbreaker to me. Only the rhythmic part would be turned off, and it would be optional.
I'm open to other solutions, I don't know.
Note that I'm talking more about things like accents (so, technical indications in the score) rather than the tuplets issue, that really only requires better automatic quantization: just see MuseScore who is importing them fine from any MIDI ever, so Synfire could just improve that part of the code to match the quantization, removing the unusable and brutal "X/Y + Z" dropdown menus).
Then there is the whole issue about voices, but that can be discussed elsewhere, and I think that it's actually easier to fix, it's really just splitting an instrument in two (internally) and edit one or another, in the same way that we can already select different instruments in the Phrase Editor by right-clicking the title; then, for Synfire to treat the two voices accordingly while rendering the output, that's very easy.
Wed, 2023-03-15 - 00:11 Permalink
Seems an elegant solution to me. Especially because then the user can set up what he needs, so it's not up to Synfire to have all possible notation symbols which would be too much to ask and outside the scope.
By having an articulation that doesn't do aything but only add a notation element, we could have things like "mf" and "pp" too. For cases like this, if you want, a different feature other than Articulations could be made, e.g. "Notations", but it would behave very similar to Articulations, so it would be very easy to implement.
See "Attachments" below this post for the image at full resolution.