Oddity in Yarns U1 voicing

In the U1 (Unison 1) voice allocation method (testing with 2P layout), there’s something weird about higher/lower notes.

Start by holding e.g. C4 and G4. Then:

  • If you additionally press E4, a voice is immediately reallocated downwards from G4 to E4
  • If instead you additionally press A4, no voice is allocated upwards to it. However, if you press both A4 and B4, a voice is reallocated from G4 to B4. If you keep holding increasingly higher keys, a steal occurs every few key presses.

My best guess is that it’s due to this line:

As an aside, seems like it might be possible to increase the flexibility of the voice allocation methods by using note_by_priority instead of sorted_note in DispatchSortedNotes?

I think I got all the above working! I figured out that the line I highlighted works well for distributing voices when there are at least as many voices as notes, but it creates gaps when there are more notes than voices. Being able to apply different note priorities to the unison algorithms is also cool.

Here’s the diff:

Some notes in case they’re of interest:

a gap occurs when:
floor((num_voices - 1) * num_notes / num_voices) > (num_voices - 1)

4 voices, 1 notes: [0, 1/4, 2/4, 3/4]   -> [0, 0, 0, 0]
4 voices, 2 notes: [0, 2/4, 4/4, 6/4]   -> [0, 0, 1, 1]
4 voices, 3 notes: [0, 3/4, 6/4, 9/4]   -> [0, 0, 1, 2]
4 voices, 5 notes: [0, 5/4, 10/4, 15/4] -> [0, 1, 2, 3]
4 voices, 6 notes: [0, 6/4, 12/4, 18/4] -> [0, 1, 3, 4] GAP
3 voices, 4 notes: [0, 4/3, 8/3]        -> [0, 1, 2]
3 voices, 5 notes: [0, 5/3, 10/3]       -> [0, 1, 3]    GAP
2 voices, 3 notes: [0, 3/2]             -> [0, 1]
2 voices, 4 notes: [0, 4/2]             -> [0, 2]       GAP
2 voices, 5 notes: [0, 5/2]             -> [0, 2]       GAP
2 voices, 6 notes: [0, 6/2]             -> [0, 3]       GAP

It works! Thanks for investigating this. It’ll be part of the next release, even if I’m frowning a bit at yet another menu entry (especially since it only works in conjunction with the unison and “sorted” settings).

Rad!

The restriction to UNISON/SORTED has been nagging at me too. I think the note priority could be used to consolidate POLY/STEAL MOST RECENT into a single voice allocation method, if POLY means “steal oldest”? That would open up some interesting possibilities with applying HIGHEST/LOWEST note priority to the unified POLY method, and improves NP from applying to 3 of 8 VA methods to applying to 4 of 7.

That would leave CYCLIC and VELOCITY as the outliers, and now VELOCITY is looking equivalent to SORTED with a new note priority of HARDEST or whatever. That’d necessitate a new uint8_t velocity_ptr_[capacity + 1] in NoteStack – not sure what the impact of that would be.

Well, layer upon layer of feature requests :confused:

To be clear, I’m not requesting that anyone do anything :slight_smile: I’m planning out how I might implement it, and thinking aloud and documenting my process in case you or anyone finds it interesting – basically, I’m looking for opportunities to give back, in the spirit of open source!

2 Likes