Anybody else have problems with Yarns in polyphonic mode?

Hi guys I posted this over at Muffs and got the advice to post it here:

I’ve set Yarns voice layout to ‘4P’ and its voice allocation method to ‘poly’. When I play a three note chord the first three CV outs send the correct CV to three connected oscs. If I wait a second and play another chord again all is well.

When I play a sequence of three note chords however, it’s like Yarns can’t keep up with the changes. I get a mixture of notes from the previous chord and the current chord, sometimes the fourth CV out lights up, and sometimes it just craps out all together, not sending any CV whatsoever.

I’ve updated Yarns with the latest firmware but alas no change.

I’ve tried two different midi input devices, a keyboard and an ipad, both with similar results. With the ipad I used the app ‘chordpolypad’ where you can hit a pad and it plays an assigned chord. So we can rule out my playing technique too wink

Anybody else experience this or is it just my particular Yarns?

I don’t think this is a defect - that’s how voice allocation works in polysynths!

Let’s say you play the chord C-E-G.

  • Channel 1 will produce a CV for C, gate 1 will be on.
  • Channel 2 will produce a CV for E, gate 2 will be on.
  • Channel 3 will produce a CV for G, gate 3 will be on.
  • Channel 4 will continue spitting whatever CV it was spitting before, gate will be off.

Now you release C-E-G.

  • All gates (1, 2, 3) will go off - but the CVs on channels 1, 2, 3 are still holding the notes C, E, G, to allow the notes to decay.

Now let’s say you play C-F-A.

  • When the module receives the C, it recycles the channel which was previously playing a C (just like when you play C twice on a piano, the second note will cut the first one - because they are played on the same set of strings). Channel 1 will produce a CV for C, Gate 1 will be on.
  • When the module receives the F, it allocates it to the least recently used channel, so channel 4 will produce a CV for F, Gate 4 will be on.
  • When the module receives the A, it allocates it to the least recently used channel, so channel 2 will produce a CV for A, Gate 2 will be on.

At this point, we have:

  • C, gate on on channel 1.
  • A, gate on on channel 2.
  • E, gate off on channel 3 (decaying/dying note).
  • F, gate on on channel 4.

To benefit the most from this configuration, it is best to use 4 oscillators on all 4 channels, 4 envelopes connected to the 4 gate outputs, and 4 VCAs modulating each oscillator output by each envelope. With such a patch - it makes sense since the module does its best to prevent decaying notes to be cut by new ones.

You are probably assuming that channel 1 will play the first note of the chord, channel 2 the second note and so on - but this not how the module works.

Indeed that was what I assumed. Thank you for the detailed explanation!

I’ve already got two requests for something similar to what you describe (assign notes to channel depending on the order in which they are played, or depending on their rank from lowest to highest), so I might address this need in a firmware upgrade.

+1 on this request


yes please, ambika also?

Why would you need that on Ambika?

It could make sense in a modular patch in which each voice would be connected to a different oscillator with its own timbre.

But on Ambika all voicecards are similar so it doesn’t matter which one is struck by a new note.

Well there are Ambikas with different voice cards, I have 5x 4p and 1x SVF

There are more sophisticated ways of handling that - create a separate part and a split?