Posted
Hi,
Thanks a lot for recently resolving some issues we face during editing. I spend most of my time with Synfire editing figures manually, so these updates are much appreciated.
In this context, I thought it might be helpful if I share some other issue I have repeatedly. Perhaps it is just me misunderstanding Synfire or not being aware of some settings, but perhaps this is another bug.
It would be a bit difficult to explain my issue in writing, therefore I am sharing with this message a link to a video demonstrating the issue I face.
For completeness, as I did not address this in the video: I also tried allowing for that chord minor seconds (a b9 introduces exactly that), but it seemingly made not difference.
Wed, 2025-02-19 - 13:19 Permalink
BTW: At the end of the video, the chords in the progression tab and the global parameter suddenly turn grey. Any reason for that?
Thanks!
EDIT: To kind of answer my own question: this behaviour is expected if the harmony parameter is part of a super or child container, and not the currently selected container. Perhaps this was the case, perhaps not, but anyway, after restarting the software the software behaves as expected (i.e. harmonies are grey if the harmony parameter data is part of a different container).
Thu, 2025-02-20 - 10:16 Permalink
Thanks for the video.
There may be multiple reasons why a chord is rendered in a wider voicing than expected.
- The obvious is you requested open voicing in the progression or for the segment (not the case here)
- Green chord symbols map to the middle playing range (unless you change that). The playing range may limit the inversions that can be played, forcing yours into this voicing. Since your Interpretation doesn't have Limit Strictly enabled, it's unlikely though.
- Chords are transposed by inversion. So if you transpose a chord segment (anchor not zero), you are actually wrapping it around. That means its vertical position implies a particular inversion. It could be that there's no other way to play this inversion without introducing minor seconds (since you disabled that by allowing dissonance, not likely either).
- The typical pitch of the playing range suggests an inversion that cannot be rendered closely (i.e. not the root position). I suspect this is the case here. If so you can move the typical pitch or select a specific inversion for the segment or in the progression.
- There's a bug that prevents a close voicing with minor seconds even if they are allowed (will check that).
The best way to check chord response to typical pitch is to add a track with auto-chords interpretation. You can immediately see how the typical pitch affects the chords when you move it around.
Automatic chord inversions work most of the time but sometimes you scratch your head and think WTF is happening here. I believe it would be helpful to have a parameter that modulates the typical pitch, such that it's no longer a constant per track.
That gray progression is odd. Will look into it.
Sat, 2025-02-22 - 18:47 Permalink
The ability to adjust the typical pitch mid track would complicate things further i believe. There are way too many variations that effect chord voicing, this would add another. Maybe create a parameter to conform the track to a specifc inversion. This would Override typical pitch, range, and figure...maybe by using custom voicing like we have with guitar strings.
We can enter numbers that would cause the harmony parameterto confirm to, we could create our own voicing and save them. IDK but something to eliminate the variables.
I sometimes find myself spending an hour adjusting several of these trying to get the chord voicing in my head, into the track. As you can imagine, for RnB, chord voicing is extremely important. Often times, i know the exact voicing i want but find it next to impossible to iterate it in Synfire.
I got it....give us the ability to save custom voicing that can be applies with the "autochords" feature. Not like 1st inversion etc but interms of numbers, we could have double 3rd etc or whatever we want.
Mon, 2025-02-24 - 21:24 Permalink
I've read the manual and been playing around with chord symbols alot but...how do you specify the inversion using the chord symbols? If I move the symbol up, the intervals will change completely, no? This maybe more of a creative or skill based rather than being technical. If you have a technique for this, please let us know or put it in the blog section. Thanks.
Fri, 2025-02-28 - 16:26 Permalink
There may be multiple reasons why a chord is rendered in a wider voicing than expected.
Thanks for your response. I now followed this up with the new piano roll notation support. See the linked video (available for 7 days): https://w-si.link/EwudxFtbxhgsReirS/dG9yc3RlbmFuZGVyc0BnbXguZGU
Basically, the video still shows the same problem I faced, but now it reproduces it in a minimal Synfire project and tries to narrow down a bit further under which conditions this situation happens (in the highest pitch range), and where it does not (the two lower pitch ranges).
I also attached the relevant project (and just for completeness catalogue files) to help reproducing this behaviour.
Thanks!
Tue, 2025-04-01 - 13:21 Permalink
Thank you for seemingly working on this issue. The behaviour is now seemingly different (though unfortunately, I cannot compare the behaviour across versions and I do not have anymore the video shared above). I note this in some sections of some piece, which are now changed.
Unfortunately, however, this behaviour is now worse for me. So, I somewhat expanded the test I shared before to demonstrate this.
Previously, this problem only occured for more complex chords like Gb7b9 for me (using a custom scale): chord symbols seemingly avoid certain pitches that are part of the chord, and how it does that seemingly depends on the chosen playing range in a not quite consistent way. See the Output parameter of container Gb7b9 in the shared accompaniment.
When simplifying the chord to Gb7, the problem disappears (see container Gb7).
However, what seems to be new is that this problem (chord symbols seemingly avoid certain pitches that are part of the chord) now appears also for simply chords like C (C major triad) in a plain vanilla C major scale! See the correspondingly named containers in the arrangement. As you can see in this container, the highest playing range seems to behave as I would expect, but the other two ranges are not. However, this seems to be just conicidence for this particular chord. For Gb7b9, all three playing ranges show this issue, but in different ways (the lower two ranges behave seemingly the same way).
Could you perhaps look into this matter again? Perhaps I am missing something obvious here? I cannot really believe that such a fundamental feature of Synfire should be broken.
Thanks!
Wed, 2025-04-02 - 08:55 Permalink
I will look into this.
Let me explain some background information. Maybe it is helpful.
The last update fixed an issue where squeezing a chord into the playing range (at its margins) resulted in scale tones that are not part of the chord (Synfire used the melody algorithm also for chords). Now it inverts chord tones by octaves to keep their pitch class.
Inversion by octaves leads to wider voicings, of course. Especially if minor seconds are to be avoided. That's why some renderings of Gb7(b9) show these large gaps. If you allow minor seconds, voicings will be more compact. If the target range is e.g. "Upper" and a particular inversion of the chord is requested (by way of the index of the bottom symbol), there sometimes is only one way to play it in a wide voicing.
The relative vertical position of a chord in the Figure denotes an inversion rather than a pitch range (the playing range of the segment does). It is the n-th note in the chord, according to the inversion set for the segment or in the Harmony parameter.
Make sure you set the anchor strength to weak if you want to allow all chord tones all the time. A strong anchor may force VL to limit notes to the underlying triad at certain points.
This enforcement of "vanilla" chords in VL is debatable. I'm inclined to remove it because there are now better ways to control VL (it's a very old part of the code). The easiest solution may be to disable VL for all chord segments, as they are more rigid and less flexible than melodic segments anyway.
Wed, 2025-04-02 - 09:16 Permalink
Suggestion for testing:
Make a snapshot of Interpretation and try different settings for Range (Open, Clips, Shift, Fold) and Alignment, and Dissonance. With "Open" range and disabled Alignment and enabled Dissonance you will probably see output as intuitively expected. But that's of no use, unless your instrument supports the full MIDI pitch range and is tolerant to minor seconds (like most strings).
Unexpected voicings occur when Synfire needs to invert the chord in order to fit it into the playing range AND avoid minor seconds, AND obey the requested inversion, AND keep as many notes as possible from the previous chord (Alignment).
I understand that this complexity is not very intuitive. Maybe we should ignore the requested inversion when things get too crammed. Currently all constraints have the same priority. That may be too strict.
Wed, 2025-04-02 - 13:42 Permalink
I did some more testing: In a minimal test file, the problem of voicing chord symbols too wide seems to happen much less, if containers all specify their own harmony, i.e. if the harmony is not set in a parent container. This seems to work, even if containers specify their own harmony over some weird custom scale. In this case, the problem seem to be reduced to the less severe version reported originally, that occurs with the Gb7b9 chord -- even with min 2nds are explicitly allowed.
However, if there is some gap between containers (even without any notes) and the harmony of the parent container over a certain custom scale takes affect (top-level container in my test) or if some container is depending on the harmony of its parent container, then the whole voicing seemingly gets confused in the way I reported yesterday.
Now, unfortunately this does not help me fix the problem in my piece, because there the problem occurs in the first container already even if the child container specifies its own harmony. So, there are possibly also other issues.
I will do some further testing and then come back later.
Anyway, thanks a lot for taking the time for a detailed response and suggesting a few things I might test!
Wed, 2025-04-02 - 14:05 Permalink
Alignment may be the culprit. There should be a break in the alignment chain whenever a new Harmony parameter comes into effect (i.e. Alignment should happen within a single progression only). I tested that already and it makes a difference.
As a workaround you can disable Alignment for the first chords in your progressions. And maybe also in Interpretation.