Bug: Internal modulation / route is not aligned with targeted track.

[dcbb]

I think I found a bug in CV modulation / routing (which is, by the way, absolutely awesome on the Performer – thanks for building this thing). My firmware is 0.1.33.

How to reproduce

• Make a note track with a melody, all gates on, on track 1.
• Set up a route modulating, for example, octave on track 1: +- 1 octave, 5 V bipolar.
• Set the source of the route to CV out of track 2.
• Make a CV track on track 2 with exactly the same length and tempo as track 1. None of the tracks is rotated.
• Set step 1 on the CV track to 5 V, all other steps to 0 V, all gates on.

What I would expect:
The first note on track 1 gets shifted up an octave. All other notes are unaffected.

What's happening:
The second note on track 1 gets shifted. All other notes are unaffected.

This is of course not limited to the first step. The modulation always seems to be one step behind. The problem occurs with note tracks set to CV as well as with curve tracks. To me, it looks like the modulation value is evaluated too late internally. A workaround is to rotate the modulating track, but that's a mess of course because the UI is off with respect to what's actually happening.

[westlicht]

This is a limitation that is probably not documented in the manual. The problem is that tracks are processed linearly first to last. So track 1 is processed before track 2 etc. When you have track 2 modulating track 1 via a routing, the value track 1 sees when it's processed is still the old value on track 2. In order to fix your issue, you should just exchange track 1 with track 2, e.g. have track 1 modulate track 2. This ensures that the output value of track 1 is always up-to-date when track 2 is processed.

I debated implementing some dependency resolution depending on routes. But it's a bit involved, as routes can modulate multiple tracks (or even itself for that matter). In your simple case, this would mean that the sequencer would first process track 2 and then track 1 to guarantee correct behaviour. I will reconsider this feature. For now, just make sure that your route source track number is smaller than your route target number.

[dcbb]

Thanks for your fast response!

Actually, I thought of something like this, and I already tried switching the melody (going to track 2) and the modulating track (going to track 1). However, that does not fix the problem on my unit! I still get the octave shift on step 2 rather than step 1, even with melody on 2 and modulation on 1. I retried just now from a freshly initialised project, just to be sure. But I still have the problem.

If you need more info (screenshots, files, ...) to reproduce, please let me know.

[dcbb]

Here are the screens from my unit: route setup, tracks 1 and 2. Modulation target is octave.

The C on step 2 gets shifted and not the one on step 1. (I added a ratchet just on the second one to be really sure.)

[dcbb]

Hey, any news on this? Can you reproduce it?

Sequenced modulation is one the coolest features on the Performer – please let me know if there's anything I can do to support.

[westlicht]

Hi, sorry for the late response. Yes, I can reproduce it and I was wrong with my reasoning. That only applies to track linking. Routes from track outputs are always delayed by at least one tick. There are various reasons for this. I have looked into possible solutions. It's a bit involved, but I might get to it some time soon.

[dcbb]

I was wondering whether there is an update on this issue. The Performer is such a powerhouse for generative melodies, and CV modulation is key to it, at least for the way I do it.

[westlicht]

@dcbb Thanks for reminding me :D I agree this is an issue that limits Performer quite a bit for accurate inter-modulation. I looked at the problem and came up with a solution this evening. My main concern was that updating the routing system on every tick of a sequence (for subsequent sequences to pick the change up) can explode in terms of computation. There are 8 tracks, 16 routings and 16 patterns. So in a worst case scenario we'd update 8 * 16 * 16=2048 routing targets every tick, which can occur 192000 times per second at 1000bpm. So a total of 393216000 updates per second. That clearly is not going to be handled by the CPU :) The current implementation deals with that by first keeping track of when a track actually changes the CV output. Then, if a track changes it's CV output, the update rate is reduced to a maximum of 40 updates per second. This is more than enough for anything hearable. This makes updating the routing system way more manageable, barley hitting the CPU at all. I will have to review my changes to make sure nothing gets screwed up, but an update should soon come.

As a side note, this implementation still has the limitation that tracks are processed in order, meaning that track 1 can only affect track 2-8 with immediate effect.

[dcbb]

Thanks for the update! I'm really looking forward to the fix.

For me, the Performer becomes more and more a generative music tool, and CV control is key to this. So is, by the way, the index-based approach to scales, which unfortunately so few other sequencers use.

[dcbb]

I finally had the time to update and test the fix, but I'm afraid it does not work.

Still, the note after the modulating step is changed. And, worse, occasionally the note on the modulating step and the one after that is changed.

I made sure that the modulating track is below (lower track number) the target. Also, I'm on a fresh project with both tracks on the same clock divider. I tried with both low and high dividers. The problem occurs with both. I tried with the transpose modulation as well as with octave. I tried with both external and internal clock. Again, the problem appears with both.

Let me know if I can send you anything that helps investigating.

[westlicht]

@dcbb yes please send me the project that still is not working. I've done a few tests and all seemed to work well.

[westlicht]

@dcbb would still be interested in that project file if you have time to send it over.