Many critical flows for recording loops in the freeform mode are simply unusable because of a design flaw in the Aeros. Just because it does not comply with the simple following rule:
Every action requiring precision from a timing standpoint has to be assigned to the on-press event of a button, whatever the flow.
I’ve already identified at least 2 flows which do not comply with this simple rule (but there may be some others and maybe even in the quantized mode, that I do not really use):
Clicking on the “Next part” button while recording the first track of a loop part. The “next part” change occurs on the “on-release” button event.
The complete re-record flow of any track. .i.e. if you “undo” a recording, and then try to re-record, then as opposed to the first recording which behaves correctly, both starting the re-recording (by clicking on the “Record” button) and ending the re-recording (by clicking on the “Play” button) can’t be done accurately as for each of them the action is triggered on the on-release event of the respective buttons.
The result for any flow not complying with this master rule, like the two aforementioned, is that the resulting loop is absolutely unusable !! For the first flow, the end of the loop won’t be correct, for the second flow, both the beginning and the end of the loop won’t be correct (incredible for a such critical flow…) !!
In multiple posts, it has been mentioned by Singular Sound representatives, that this was because of other secondary actions attached to other events of the button. And it’s true.
Let’s take again the example of the “Next part” flow described above. The “Next part” button currently reacts as well to the long-press event to trigger the mixer, resulting in the fact that the “Next part” button cannot, as it is, react to the on-press event but instead has to wait for the on-release event to occur in order to ensure that the user’s goal was not to actually trigger a long-press event to access the mixer.
This is exactly where the problem is, and what I meant by a design flaw as, as it is, this is simply impossible to provide a working flow.
To go a bit deeper, we should first agree on some very basic, but necessary-to-be-re-enforced, assessments:
- The Aeros is a looper, and its primarily goal is to enable the musician to produce accurate multi-parts loops.
- The Aeros is a standalone device not requiring any hardware add-on to achieve its primarily goal and therefore MIDI cannot be the answer to achieve this goal.
- The Aeros can provide extra features gravitating around that primarily goal or even complex and synchronization features using optional MIDI messages.
Ok, now if we agree on the previous assessments it means that any flow on the device which is related to recording a loop is priority over any other flow.
And on top of that, if we agree on the reality behind the master rule (which is quite obvious), it is time to write the rule that, for sure, if you prefer the blue pill and don’t want to know how deep the rabbit hole goes, you should definitely not read. Because it will hurt :… This rule is simply the corollary to the master rule:
Corollary to the Master Rule:
Any action which is NOT covered by the master rule could be potentially relegated to a touch-screen action and/or to a MIDI command, if conflicting. Priority has to be given to time sensitive commands.
What does imply this corollary ?
Simply that everywhere the problem described here above exists, a potentially painful decision has to be taken to remove the secondary actions (those attached to either on-double-tap or on-long-press events) from the buttons which trigger start or end of loops recording in order for them to be able to react to on-press events, like they should.
I warned you, you should not have read until there …
Depending on the case or flow, secondary actions to be removed can be:
- completely removed from the button
- temporarily removed from the button during the recording
- moved to a touchscreen action
- attached to dedicated MIDI message
As you can see critical problems imply potentially drastic but necessary solutions.
So why did I initially open this topic ? Simply to reply to this announcement in the Aeros firmware 3.0 topic page:
My answer to this, is that there cannot be any exception to what I just stated above. All flows, without exception, involving time sensitive commands have to comply with master rule. And if they don’t, they are just fake features as the resulting loops will be, by definition, incorrect. And sometimes it will hurt, as it may be at the expense of another interesting/beloved function, but which will always be less priority (as recording accurately is the highest level of priority).
I have been already replied that this behavior was not a bug, but actually the way things are supposed to work. This cannot be acceptable as the result is not usable.
Thank you if you read until there. It’s a tough topic, but so important for the success of the freeform mode…
Use this topic to:
- Report any other incorrect recording flow using something else than an on-press event to trigger time sensitive command.
- Provide your potential alternatives/suggestions for secondary actions removal for any button involved in any impacted flow.
I will post my own proposals for the two cases (1, 2) that I used as examples in this topic. Do not hesitate to reply, to amend, or propose your own alternatives as long as they follow the master rule and the assessments stated here above.
This bug is the generalization of the 2.17 “Next part” when recording does not end correctly
This bug applies primarily to freeform mode, but if you have example in quantized mode do not hesitate to report here.