Inconsistency/bug in OFFSET/COMP submenu when adding a note on an existing step that has offset
[PART 1 (see part 2 in comments)]
SIMPLIFIED SUMMARY:
While in step recording mode, the sequencer should treat adding 2nd (3rd, etc.) notes to pre-existing steps containing at least one note the same way whether it's in relation to gate time or step offset value in order to make sense musically.
This means, for example, that if a given step has an existing note and a gate length of 1, if while in step recording mode the user adds an additional note to that step, the sequencer should assign a gate length of 1 to the newly added note (WHICH IT DOES)
BUT, when talking about OFFSET, if a given step has an existing note with a configured offset value of 35, if while in step recording mode the user adds an additional note to that step, the sequencer should assign an offset value of 35 to the newly added note (WHICH IT DOES NOT, instead it adds the default offset value of "0", which is not musically relevant as it can cause 2 notes on the same step to sound completely disjointed)
DETAILED EXPLANATION:
Currently the behaviour of the step sequencer in the "OFFSET"/"COMP" (component) submenu is fully predictable but problematic in some ways as there is a specific inconsistency in the sequencer's behaviour (depending on whether the user is inputting Gate vs Velocity vs Offset) that does not appear to make sense musically.
This is a rather complex set of implications to describe here so please bear with me:
I'll start with an example to describe the observed sequencer behaviours in relation to adding VEL, GATE or OFFSET data in step recording mode, and then I'll show by contrast the main problem that occurs when dealing with OFFSET values on polyphonic steps:
*****For the GATE value:*****
If:
1. the user selects the "GATE" submenu and puts the step sequencer's focus on an empty step, (by first activating the "select rectangle" button and then by tapping on a random empty step)
2. and subsequently presses a note on the keyboard
Then:
- A note with a gate default length of 0.5 will be associated to that step.
- Even if the user activates real-time recording, presses a note down on the keyboard to generate a step with a gate length different from 0.5 (for example: 1.0), once the user gets back in step recording mode and tries to add another step, that step will invariably have a 0.5 gate length.
- Even if the user disables the "selection rectangle" button, activates a step by pressing one of the 16 visible step buttons, and adjusts the GATE value on that specific step to a value different from 0.5, if the user then tries to activate another step, that step will still have a gate length of 0.5.
(The takeaway here is that the sequencer doesn't rely on the gate length that was last chosen to define the gate length of a subsequently added new step. I understand this behaviour as a design decision to largely mitigate impractical use-cases that could occur otherwise)
(NO PROBLEM SO FAR, I'm just explaining the behaviour baseline of the sequencer for GATE value.)
*****For the VELOCITY value:*****
If:
1. the user selects the "VEL" submenu and puts the step sequencer's focus on an empty step, (by first activating the "select rectangle" button and then by tapping on a random empty step)
2. and then, while the Velocity keyboard option is activated, the user presses a note on the keyboard at a specific Y-axis value
Then:
- A note with a velocity value matching what was played on the keyboard will be associated to that step.
- Subsequently if the user chooses to activate another step, that step will REMEMBER the previous Velocity level that was last used on that previous step to define the Velocity value of the newly added step. Most people would agree that this behaviour is perfectly sensible and musical.
(NO PROBLEM SO FAR, I'm just explaining the behaviour baseline of the sequencer for VEL value.)
*****For the OFFSET value:*****
If:
1. the user selects the "OFFSET" submenu and puts the step sequencer's focus on an empty step, (by first activating the "select rectangle" button and then by tapping on a random empty step)
2. and subsequently presses a note on the keyboard
Then:
- A note with an Offset value of "0" will be associated to that step, which makes sense musically.
- Even if the user activates real-time recording, presses a note down on the keyboard to generate a step with a timing that has an offset value different from "0", once the user gets back in step recording mode and tries to add another step, that step will invariably have an offset value of "0" which makes sense musically.
- Even if the user disables the "selection rectangle" button, activates a step by pressing one of the 16 visible step buttons, and adjusts the OFFSET value on that specific step to a value different from "0", if the user then tries to activate another step, that step will still have an Offset value of "0". This makes sense musically in most cases, but there are numerous instances where it does not. This behaviour is related to the problem that I'm currently describing.
[SEE PART 2 in comments]
Comments
[PART 2]
PROBLEM DESCRIPTION:
In step recording mode, in instances where the user wishes to add multiple notes to a preexisting given step with preexisting offset information, the user will potentially encounter multiple issues. I'll begin by describing the behaviour depending on these submenus: "VEL", "GATE", "OFFSET" and indirectly "COMP":
- In relation to VEL:
Any additional note added will factor in the velocity value recorded at the time of the last keyboard note press, which will most likely be a value that differs from the first note that was added (if the Velocity option is activated for the keyboard controller). The velocity of each note will be remembered for that given step.
HOWEVER, if the user then goes to the "VEL" submenu and adjusts the VEL slider for a given step, the velocity value of each step will be overridden in a destructive manner by a uniform velocity value dictated by the velocity slider adjustment that was just made.
This behaviour doesn't make the most sense musically, but it is not a "dealbreaker". To describe things loosely, a more musical design could be to respect the velocity value relative offset between each notes and to extrapolate an average velocity value of the group of notes that would then be controlled by adjusting the velocity slider in the "VEL" submenu in a non-destructive manner.
- In relation to GATE:
During live recording, any additional unique note effectively added on a preexisting step will factor in the unique gate value recorded for that particular note.
Alternatively, in step recording mode, adding a note to an existing step will mirror the GATE value specified for that given step in the "GATE" submenu. This is great, but it illustrates by contrast the inconsistency that I intended to explain, as offset values do not mirror this behaviour as I will explain just below:
- In relation to OFFSET [**THIS IS WHERE THE PROBLEM IS**]:
Any additional unique note added via step recording on a preexisting step will DISREGARD any Offset value (different from zero) defined in the "OFFSET" submenu. The added note will therefore have an offset value of ZERO. This causes an extremely unpleasant behaviour from a musical standpoint, as the 2 notes present on a given step could sound completely disjointed from each-other. The logical and more musical behaviour the sequencer should adopt in this case would be to at least align the offset value of any subsequently added note with the offset value of the initial note's offset value which is reflected in the OFFSET submenu, similarly to how the sequencer handles gate values in step recording for polyphonic steps.
HOWEVER, just like how the sequencer behaved for VEL and GATE, going to the dedicated "OFFSET" submenu AFTER the 2nd (or 3rd, etc.) note was added for a given step and using the offset slider on that step WILL override any preexisting offset discrepancies between notes present on that step, therefore eliminating the problematic "disjointed feel" that was initially heard the first time the step sequencer triggered that step where we had just added a 2nd note.
There could be a more musical approach to handle relative timing offsets in between notes in relation to the main offset slider in the OFFSET (as opposed to the COMP menu) similar to what I suggested for velocity.
That wraps it up. *sweat*
Yes, and I've already reported this 10 days ago.
Drambo started with offsets per note only and the offset bars were added later.
Offsets should not only apply to all notes on a step *when adjusted by the offset bars in step sequencer*, but the same offset should apply to p-locks on steps as well.
@rs2000 I see! The P-lock timing not matching step offset timing "thing" was the other issue I had created a discussion for (which you had also commented on), so they all stem from the same root cause if I understand you correctly?
What did you think of the potentially more "elegant" idea I loosely suggested regarding management of velocity but that could also apply similarly to Offset (here's the part where I mentioned it):
"To describe things loosely, a more musical design could be to respect the velocity value relative offset between each notes and to extrapolate an average velocity value of the group of notes that would then be controlled by adjusting the velocity slider in the "VEL" submenu in a non-destructive manner."
To expand on what I meant by a "non-destructive manner", I was trying to convey my awareness of what would happen (in a hypothetical context) if someone moved the velocity slider all the way to 127 (in the VEL sub-menu) on a given step containing multiple notes each with their unique velocity values.
The "cryptic" implication here was that if the sequencer behaviour respected the relative velocity offsets between notes and was optimally non-destructive, it could potentially do something like this for example:
A given step has 3 notes, with 3 distinct velocity values (visible in the COMP sub-menu):
note 1: 65 (at the time of being originally recorded in step mode)
note 2: 85 (at the time of being originally recorded in step mode)
note 3: 115 (at the time of being originally recorded in step mode)
The sequencer could then calculate:
(65+85+115)/3 = 88.33
With that value it could then display in the VEL sub-menu a slider showing a velocity value of 88.33
Then, if the user was to adjust the velocity slider in the VEL sub-menu all the way up to 127, each note would have these velocity values:
note 1: 65 + (127 - 88.33) = 103.67
note 2: 85 + (127 - 88.33) = 123.67
note 3: 115 + (127 - 88.33) = 153.67 -> rounded down to 127 (as it is the maximum value allowed)
And, if the user was to subsequently adjust the velocity slider in the VEL sub-menu back down to 80 for example, each note would then revert to their "fully manifested" relative velocity offset, meaning that the system would remember that:
the note that has the lowest velocity value (which would act as the anchor point around which all other velocities offsets are articulated)
was:
note 1 (anchor) (at the time of being originally recorded in step mode)
note 2 had +20 relative velocity compared to note 1 (at the time of being originally recorded in step mode)
note 3 had +50 relative velocity compared to note 1 (at the time of being originally recorded in step mode)
So when readjusting the velocity slider in the VEL sub-menu back down to 80 for example, the velocity values of each notes would then be:
note 1: 103.67 + (80 - 127) = 56.67
note 2: 123.67 + (80 - 127) = 76.67
note 3: 153.67 + (80 - 127) = 106.67
As you can see with what I've described when I adjusted the main velocity slider back down to 80, the notes fully "recovered" their respective velocity offset values (which were note 1(anchor): +0 relative velocity , note 2: +20 relative velocity , note 3: +50 relative velocity)
The same principle could be applied for handling timing offsets which would be amazingly musical. Wouldn't that be awesome?