Basic Notation features (add XML elements to symbols)

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.

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.

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.

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.

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.

So what. If anything, it's one more reason to improve the feature, so the Pro version is more appetible.

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).

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.

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.