sample , cycle mode bug

I created an instrument ( name :fast arp ) …made out of two waveforms …square and saw .

Each having its own instr.evelope …

Then created a phrase …note order c ,d# ,a ,g# …

Set instrument overlap to cycle mode …

So normaly when playing the phrase …the square wave would be note c ,

saw note d# , again square note a , and finnaly saw g#.

This is not always the case .

Sometimes the whole note phrase sequence is played by one wave …ignoring the cycle mode ( which should be applied on each note trigger in the phrase sequence and thus triggering the next waveform )

See xnrs file , track name 'wrong cycle mode and look at samples …you’ll see the cycle triggering is sometimes wrong .

If it doesn’t go wrong from the first time , just manually trigger the instrument ( fast arp ) then play song again .

https://app.box.com/s/fjxudgfhmod4pmkh9xc7

https://app.box.com/s/7pwa0jlwq10gi5v0dhvq

Yep, there is definitely something fishy going on.

Seems to happen only when notes are within a phrase - when I play it manually, or put notes into the pattern editor it works fine (changing wave for every note played), but inside the phrase it repeats the same waveform up to four times before switching.

Cycling mode is applied/memorized per note. So you need to play the same note twice to let it cycle.

Understand that this behavior seems “wrong” in this example. Question is how else cycling should be applied and memorized then instead?

D’oh. That per-key memorizing is of course something to consider.

I frankly never considered this when we were talking about alternative ways to map cycle mode to the keyzone.

Still, gentleclockdivider’s example seems to exhibit some random qualities, shouldn’t it play the same each time?

Still, gentleclockdivider’s example seems to exhibit some random qualities, shouldn’t it play the same each time?

yep , that’s what I was thinking too …

verry obvious in this example

https://app.box.com/s/j8l52bxb1i5p8zty47gl