Posted
I tried generating quintuplets using a Factories Step Sequencer. While that works in principle, it appears that all the quintuplet note values (e.g., 1/20, 1/10 etc.) are quantised to "straight note values" (values based on powers of two in the denominator -- plus potentially some extra MIDI "ticks"). For example, the quintuplete value 1/20 (subdividing a quarter note into 5 notes) is quantised to 1/32+1/64+6.
The problem resulting from this quantisation that I observed is that a sequence of quintuplets can accumulate rather obvious rounding/quantisation errors, i.e. note values that are neither quintuplets nor straight note values. (Depending on your point of view, good news might be that Synfire tries to not drift completely off from the underlying metric framework and thus seemingly inserts occasionally some odd rhythmic values to get "back on track".)
Is this quantisation a feature of particular Step Factories, or does it point to some underlying requirement/limitation? I understand that Synfire has to internally quantise all MIDI events to the resolution of MIDI "ticks" per quarter note, but AFAIK the MIDI protocol allows to set this resolution to various values.
So, I wonder: how many MIDI ticks per quarter note does Synfire use internally? Can this resolution perhaps be increased somehow if necessary?
Here is a possible way to reproduce an example that exhibits the reported quintuplet rounding errors: under Factory choose the Parameters: Step Sequencer. Set the pattern to 1/10, 1/20, 1/20, the randomness/transformation to Keep and the streaming to Per 2m. The resulting rhythm is always the same, and contains durations below 1/20.
Perhaps the problem observed here is also simply some issue in this particular factory or something else entirely. I just want to confirm that there are no principle problems with tuplets like quintuplets in Synfire.
Thank you!
Di., 03.05.2022 - 13:39 Permalink
Perhaps the problem observed here is also simply some issue in this particular factory or something else entirely.
No, it's indeed messed up, for example you can import a MIDI file and do an extreme zooming in (if it's still possible in V2) and you can visually see the things that you're talking about. Lengths gets quickly messed up, positions maybe.
Moreover, the whole idea of using numbers and fractions is only useful to make your head explode, that's why I proposed to have a selector with the note values icons, and the feature to "tag" tuplets so it's also useful then for exporting to notation and to visually see what you're doing in the figure editor, since you cannot easily see tuplets visually in it.
Di., 03.05.2022 - 19:07 Permalink
MIDI resolution is 1920 ticks per quarter, which is not enough to represent all tuplets as integers. Even 3840 would not be enough.
For proper representation of all tuplets, note durations need to be represented as fractions, i.e. 1/7, 1/9 and all length computation also be done in fractions. While that is possible, it requires a whole extra layer of abstraction to be added to the entire system. That's probably two months of work, lots of unintended side effects to fix and a noticeable performance hit.
There may be a workaround for notation export, but MIDI rendering will always have to deal with rounding errors that add up.
EDIT: 1/5 should work though.
Di., 03.05.2022 - 20:21 Permalink
Thanks a lot for all this feedback, very helpful. At this stage I mainly wanted to better understand the situation. 1920 ticks per quarter is actually a much better resolution than I feared it might be. I thus assume that the problem I reported might be caused by something else after all. I did not do the math, but considering this relatively high resolution, rounding errors -- while potentially present -- should/could actually be pretty small, and not as big as the irregular note I noted in the reported factory. And as 1920 can even be divided by 20, there should not be any rounding error at all in this example.
Though I am not so sure whether the majority of Synfire users cares about complex tuplets that much or at all, personally tuplets are pretty important for me. For example, I really like that Synfire allows to scale arbitrary figure selections rhythmically by an arbitrary fraction. If at all possible, I would welcome if such a feature could be retained, even if that potentially results in rounding errors.
So, considering the likely need of the majority of users, perhaps the underlying rhythmic representation should be left untouched, and instead we users should try to collect corner cases that demonstrated problematic rhythmic behaviour? Perhaps there is a completely different problem somewhere, which might be possible to pinpoint and resolve at a later stage with some reproducible bug reports?
Mi., 04.05.2022 - 00:03 Permalink
Suggestion:
Support 1/3 and 1/5 in any form (multiples of 3 and 5) and ditch 1/7 and 1/9, which probably almost nobody really uses. The former can be represented as integers and should be fine in all situations. The latter are just overkill.
For my particular case this would be good enough, and probably for everyone else.
Because 3 and 5 are common, and the other ones I can just do them in the notation program.
The ideal would be however if in addition you can tag weird tuplets numbers, meaning appending this information to a segment (or to whatever element it makes sense to be a target for this), for exporting.
So if I create a figure with symbols/notes that are laid out just approximately to be 11plets, but I then can tag that group of non-precise symbols/notes to tell Synfire that I want those to be exported as 11plets, that would be ideal, and I assume not hard to do compared to making a perfectly correct 11plet playback which is not even needed because who cares for that precision, those tuplets afterall are more of a modern composer's "flow" indication in a certain sense.
That said, all notation software I've used actually do the playback correctly too, so how is that? More resolution or internal tricks, or what? MuseScore can import and export every kind of tuplets except importing 11plets IIRC.
Mi., 04.05.2022 - 07:36 Permalink
Not sure how easy it would be to automatically tag figures, considering all the possible transformations incl. rhythmic transformations possible with Synfire, which potentially change the situation concerning tuplets. Manually added tags could be different, but that would put the onus on users adding extra information, which can be tricky. (More generally, though, I personally would love to be able to manually add some tags/comments to various musical Synfire data, just as comments for myself. ;-) )
Notation programs use quantisation techniques to deduce metric notation for their MIDI input, even if the input is not strictly quantised. Pretty tricky to do, but several notation programs are actually able to even deduce various tuplets, just as you said.
Mi., 04.05.2022 - 12:19 Permalink
Manually added tags could be different
And that's what I meant. So you basically take off the load from Synfire and you just tag them for yourself. Even without exporting them correctly as notation, it would be cool if you can at least export them as a "comment", in a similar way of how Synfire already does for example with the containers.
But I mean, obviously the best thing would be to just export correctly to notation.
(More generally, though, I personally would love to be able to manually add some tags/comments to various musical Synfire data, just as comments for myself. ;-) )
Very similar to my feature suggestion here: https://users.cognitone.com/topic/tagging-notes-xml-export-easy-solution-complex-notation
where I also show how it may look visually.
Notation programs use quantisation techniques to deduce metric notation for their MIDI input, even if the input is not strictly quantised. Pretty tricky to do, but several notation programs are actually able to even deduce various tuplets, just as you said.
I see.
Anyway, in the end I'm just trying to export in MIDI and open the MIDI with an intelligent importer like MuseScore is (it's even better than Dorico in this regard).
Because I don't see a good and non-bugged XML export in Synfire coming very soon.
This however means that I lose various additional information that could only be exported via XML, e.g. enharmonic notation (luckily Dorico can re-spell notes, but this is yet another import-export-do-stuff-complication in the workflow), but also a possible future "comment" feature. Unless you can append comments in MIDI which I don't think so, especially to a group of notes.
Mi., 04.05.2022 - 16:41 Permalink
User-defined plain text tags added to music notation output would be brilliant for me as well! I have used similar features in other composition environments (more leaning towards users that are also programmers, e.g., Opusmodus and Strasheela), and know the usefulness of something like this from experience.
I would use them, e.g., for denoting artiulations, instrument playing techniques, perhaps annotating more complex tuplets, but also for adding analytical information, like motif names, and in particular also harmonic annotations. When using custom microtonal tunings where the tuning changes on the fly (possible with MTS-ESP), something like that would probably be the only way to export required harmonic information like the current microtonal scale.
In terms of implementation, to make such a feature usable for a reasonable large set of users, it might be best to export such tags as Music-XML text annotations, so that such tags could also be seen without any custom script post-processing the Music-XML output score. For those users who then want to do such post-processing with a custom script, they could use, e.g., special recognisalble text tags that could be detected when their script parses the XML file.
If such a feature will really be added to Synfire at some stage, I would be happy to help and dig out a suitable XML tag for this (e.g., some tag used by other composition software for arbitrary text annotations).
Mi., 04.05.2022 - 16:52 Permalink
> Unless you can append comments in MIDI which I don't think so, especially to a group of notes.
AFAIK, it is possible to add lyrics to a MIDI file, but not to individual notes but time points instead, which is of limited use for the feature you are envisioning here. E.g., see
(https://www.midi.org/specifications/file-format-specifications/standard…)
(https://www.recordingblogs.com/wiki/midi-lyrics-meta-message)
Mi., 04.05.2022 - 19:03 Permalink
Well, we can only hope, I guess.
In my thread there, Andre seemed to be receptive to the idea.
It would be a game changer because now I have to:
- Do something in Synfire
- Export to MIDI because XML is bugged and in an embryonic state.
- Import in MuseScore because despite being open source (or exactly because of that) it's the best software for importing and exporting.
- Export to e.g. XML from MuseScore
- Import to Dorico for notating stuff (because not being open source it's of course better than MuseScore in other regards), with the issues that:
- No other reference than the Synfire project to understand where is where, for comparison between the .cognac project and .dorico one.
- Not having comments, not even inside Synfire either.
- Not knowing where I wanted to put a given marking or something.
And... If I change my mind and I want to change something in Synfire, I have to re-do all those steps again, albeit for only a specific part, and reassigning instruments in Dorico, etc.
Pretty painful.
If a simple commenting feature is made and the XML export is... improved, the steps would be:
- Do something in Synfire
- Export to XML.
- Import in Dorico, and have all your comments for reference («Oh I should put an accent here and a 11plet, and a "con sentimento" marking, ok.»).
If then I want to change something in Synfire, I can export that specific part "e.g. Flute section part #3" in XML, and import it in a Dorico so-called "flow", and then from there do anything that I want.
So. Much. Better.
This would be a game changer, and it's also the only realistic thing that we can expect, because it's understandable that we won't have a fully integrated notation system inside Synfire. But this would be enough already.
The next step would be to have very basic notation stuff like at least accents and simple things like that, but even if that sees no light, I think the rest of the idea is very important to have, because music prototyping without a resulting score doesn't make sense in my opinion. The "notes" are not enough, composing means much more. And currently the notes are even exported wrong because of bugs.
Those other software products you mentioned, maybe they won't create a score ready for publishing, of course, but they at least give a very good starting point for then adding nuances manually. (or they may actually do insane notation things, I never went much further than reading about and watching YouTube videos, regarding those programs; the goals are in any case different, supporting modern crazy stuff, etc.)
Synfire, as you can see in my bug report thread, is currently simply not considering exporting at all: it's still in an embryonic state.
Considering the goal of the project, this is IMHO a very important aspect.
I bought the software anyway because I want to support the development of music prototyping software, and because it already does impressive things, but I already knew from the demo that notation would be a big issue.
P.s. Thanks for the links, yes, MIDI is not suitable. XML is the way to go.
Sorry, I ended up typing a wall of text. But I guess it makes clear how much this feature is needed, lol.
Mi., 04.05.2022 - 20:17 Permalink
I hear you, guys.
With only triplets and quintuplets in play, it will be a lot easier to make things waterproof.
It is basically no problem to attatch notation tags to Figure segments. However, your painstaking work will become meaningless the moment Step, Shift, Variation or Morphing parameters get into play (or any other transformations along the way to final MIDI output).
Even a simple irregular loop changes rhythm semantics dramatically. And you will certainly want to copy/paste and move segments around a lot, as that is what prototyping is all about. All this breaks the sematics of tuplets. A triplet shifted completely out of place is probably no longer notated as a triplet, correct me if I'm wrong.
Therefore the only viable solution is to automatically deduce rhytmic notation from rendered output. That's what the seemingly odd quantization settings for notation export are for. Yes, they need to be improved and bugs fixed.
Attaching tuplet tags to segments will only work where Figure is written as a dynamic substitute for notation.
Do., 05.05.2022 - 01:23 Permalink
However, your painstaking work will become meaningless the moment Step, Shift, Variation or Morphing parameters get into play (or any other transformations along the way to final MIDI output).
That's why in the thread where I post bugs, regarding support for tuplets, I wrote:
For things like the Shift parameter, which would change the resulting notation, that could simply be bypassed with a checkbox in the export settings.
Because those who want to export to notation will probably use Shift only for rubato and things like that:
Attaching tuplet tags to segments will only work where Figure is written as a dynamic substitute for notation.
That's the idea, if one only cares about harmony and not about Step/Shift/Morphing.
But I understand your point, but the whole reason this discussion exists at all is because we are thinking about workarounds that are easier to develop: if Synfire gets MuseScore-quality interpretation of its MIDI output and if it exports a good XML file, then we wouldn't need these workarounds in the first place, only the "comments" thing as a bonus feature. The best solution would be good exporting with MuseScore-quality tuplets recognition, but it doesn't seem to be in your priorities, so I came up with other ideas.
I mean, you don't like it because it's not ideal? Good: but then what you're left with is e.g. having to hire someone to make decent exporting and time/tuplets recognition. There is no shortcut, so to say.