The duration feature is not working correctly with fast or eight note Performances/Rhythms/Expressions


there’s a real MAJOR bug in your software.

Using EDIT MODE it’s absolutely IMPOSSIBLE to ‘CLEANLY’ audition performances with rolling eight note stabs (8 eight note strikes per bar) when the DURATION of the chords is set to other values than 1 Bar.

Here’s the problem:

I’m an EDM producer and therefore want to audition chord progressions with rolling “eight note stabs” (8 eight notes per bar).

My tracks usually changes the chords BEFORE the end of the bars. So I need to use the EDIT mode’s ‘DURATION’ feature to make the LAST TWO OR THREE EIGHT NOTES of the bar to play another chord.

Using the ‘Edit’ mode to play a performance/rhythm/expression with rolling “eight note stabs” usually works fine when all the chord DURATION are set to 1 Bar.
If you change the DURATION of an rolling eight notes stabs performance to e.g. 0.66% or 0.75% for the first chord and to 0.33 or 0.25 for the second chord then AT THE POSITION WHERE THE CHORD CHANGE IS SUPPOSED TO HAPPEN SCALER plays BOTH chords at the SAME TIME.

In fact the ‘old’ chord (which should be MUTED/STOPPED when the NEW chord starts to play) is audibly played SUPER SHORT before the NEW chord starts to play the eight notes.

So at the position where the NEW chord starts to play I hear BOTH chords.

So it’s IMPOSSIBLE to ‘cleanly’ audition eight note stabs performances when changing the durations.

I am a programmer and think the problem is that your ‘edit mode’ algorithm is programmed in a way that makes scaler “jump” from the performance of the first chord to the performance of the second chord after the ‘time’ entered in the ‘duration’ dropdown (e.g. after 0.66% of a bar or 0.75% of a bar).

I guess THIS ‘JUMP’ IS THE PROBLEM HERE because using this kind of algorithm the program/cpu/scaler TOO LONG ‘thinks’ it could play the OLD chord.
So scaler or the cpu TOO LATE ‘realizes’ that it has to play a NEW chord.

You don’t ‘ANNOUNCE’ the new chord early enough to the program.
That’s why it super-shortly plays the OLD (wrong) chord at first.

INSTEAD your edit mode should INTERNALLY read (a) the chosen CHORDS and (b) the chosen PERFORMANCES/RHYTHMS and © the chosen DURATIONS and COMBINE them to a "RESULTING MIDI PROGRESSION’ based on the combination of Chords, Durations and Rhythms the user entered in edit mode.
This way you could send this “RESULTING MIDI PROGRESSION” to scaler BEFOREHAND, so Scaler would know BEFOREHAND which notes need to be played at what position.

This way the computer/cpu/scaler would know BEFOREHAND and EARLY ENOUGH which chord has to be played at what position.

ANOTHER (EASIER but LESS ACCURATE) SOLUTION may be to INTERNALLY use LOWER VALUES THAN THE VALUES CHOSEN BY THE USER. For example when the user choses 0.66% you internally send 0.60% to scaler. This way the cpu would jump EARLIER to the new chord. Maybe this works and solves the problem. I don’t know. But it’s definitely not as 'clean’as my first solution. That’s why I definitely recommend my FIRST soultion (at least in the long term).



Hi @Manny

thanks for reporting your issue, we will have a look on our end and get back to you.


Just use trigger notes and quantize (if needed) with DAW sync off.