Attach all time sensitive commands (i.e. recording) to on-press events only

Aeros Loop Studio Help, Questions and Bugs
1

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:

Master 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. :astonished: .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.

:warning: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.

@BrennanSingularSound @DavidPackouz , do not hesitate to comment if you feel I have a wrong understanding.

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 :cold_sweat: ::scream:… This rule is simply the corollary to the master rule:

Corollary to the Master Rule:

:bomb: 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 :wink: :pill:…

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.

:clap: Thank you if you read until there. It’s a tough topic, but so important for the success of the freeform mode…

:loudspeaker: 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.

:information_source: This bug is the generalization of the 2.17 “Next part” when recording does not end correctly

:information_source: This bug applies primarily to freeform mode, but if you have example in quantized mode do not hesitate to report here.

3 Likes
2

“Next part during recording” flow fix proposal

Problem statement

If you are recording the first track of of an empty part in freeform mode, to end it you have the possibility to click on the “Play” button, which works as expected, as attached to the on-press event. So I won’t talk about that flow.
But while recording, the “Next part” button is allowed too to end the recording, and that flow falls into the problem of this topic.

When you click on “Next part” at that time, the Aeros is supposed to switch immediately to the next part of the song, but it is attached to the on-release event.
The result is that an extra time is added at the end of the track recorded before actually switching to the next part.

Solution proposal

  1. As the flow is anyway wrong, one possibility is to completely remove the possibility to click on “Next part” to end a recording (grayed or something). I would definitely not vote for it, but it would at least clearly establish that the only valid flow is to end the recording with the “Play” button, listen to the loop once, with the “Next part” button re-enabled when you are back in play mode. With that solution the mixer remains accessible while recording. We don’t really fix the issue but all the flows are now consistent.

  2. The only other solution, is to make the recording ended correctly by the “Next part” button. Which implies at least temporarily, during the recording, disabling the other events on the button than the on-press event. Which obviously implies not being able to access the mixer during a recording anymore. I am really wondering what the use case would be to access the mixer during recording, nevertheless, as it is a minor flow compared to recording that sounds valid.

It doesn’t prevent to have a config flag to toggle between the 2 solutions if needed and in any case to add a MIDI message to complement with the missing feature (the next part for the solution 1 or access to the mixer for the solution 2), but I am wondering if it is necessary as I really think that not being able to access the mixer during the recording is a really acceptable trade-off.

Both solutions comply with the master rule and its corollary.

1 Like
3

“Re-recording of a track” flow fix proposal

That one is a bit more complex as involving two buttons. The “Record” button to start the recording and the “Play” button to end it.

Problem statement

Let’s assume we’ve just performed the “undo” of a track as it is today in freeform mode.

Starting re-recording the loop

In that state the button displays “Record”, but this is not the same “Record” as when you start a brand new track. Here if you long-press it, it will perform the “redo” action, but if want to re-record, you have just to hit the “Record” button which reacts to the much-hated on-release because of the “redo” feature.

Consequence: the loop doesn’t start when it’s supposed to.

I could even add, that from UI perspective there are at time, on the screen, two buttons with the same label (Record) but with two different behaviors… :thinking:

Ending the loop re-recording

In that state, the button displays “Play”, but it reacts as well to a long press to enable to cancel the re-recording. Thus ending the loop reacts to the much-hated on-release because of the “cancel re-record” feature.

Consequence: the loop doesn’t end when it’s supposed to.

Again, even another “Play” button cannot be displayed at the same time, the “Play” button displayed in this context has not the same behavior as the one you had when recording the first version of the track (before the “undo”).

We end-up with a loop which is both wrong in the beginning and at the end.

I would like to add to this, that the “redo” flow is an edge flow compared to “re-record” flow. As a matter of fact, if you undo a record, this is a priori to record something new. The “redo” feature is just there in case you did the “undo” by mistake. Thus priority has clearly to be given to the “re-record” flow over the “redo” flow.

Solution proposal

  • Relegate the “redo” to the touch-screen (maybe touching the waveform, any suggestion welcome), and of course provide a MIDI message to enable a possible more convenient way to do it. That way, while the feature is preserved (even if relegated to actually what it is, i.e. a second-class action), it fully solves the issue of starting the loop.

  • Completely remove the “cancel” attached to the long-press event while re-recording. Maybe provide a MIDI message to do it, as you could always end the recording and then do “undo” again. It is a clear necessity to free the long-press event which fully solves the issue of ending the loop (yet cancelling something before it plays would remain an interesting feature. As far as I understood it is nevertheles not exactly what it currently does. it looks like this long-press simply chains a “stop the record” with an “undo”, which is not exactly the same as cancelling before it plays…).

Choosing is renouncing, and no one will like this, but having the “redo” available as a long-press is nice, yet clearly not at the expense of the re-recording flow which is the real flow supposed to occur at that time. Having the “redo” nevertheless available by touching the waveform for the few cases it is really required seems a pretty acceptable trade-off.
Of course a MIDI message could give immediate access to the “redo” feature for the MIDI users…

2 Likes
4

@LaurentB :clap: what a good job! I completely agree. It is unthinkable to have orders that generate delays. We make music! @DavidPackouz you have people here who have efficient methods.

1 Like
5

Thank you :blush:

6

Such a clear way to put it!! 1000% agree

7

Again, I have to say that Singular sound support is great. The community is also great, the best feedbacks, does a lot of the research job for you!

I completely agree on the main rule. I am new to the Aeros but using loopers on stage for long. I am not able to do a flawless overdub with Aeros!!! You will always notice the beginning because the timing is wrong and also there is a fade in. If I cannot do a recording without being able to notice where the beginning and the previous track end meets, that means that I’m using a toy not a professional device. Aeros is such a great small thing I would like to see it working and use it on stage!

All this said, why don’t you trigger secondary events with double step instead of hold? If you receive a second push on the button, then the secondary event is triggered. But the first event is triggered anyway after the first push, just it would get cancelled in case a second one received. But if this wouldn’t be possible, then just use on screen touches and MIDI for all the rest of the commands. This would solve the timing issues and the most important thing: the recording would go flawless.

1 Like
8

Here we do not really talk about about overdubbing, as overdubbing does not require to be as accurate as when recording the first loop of a track.

When I say “accurate”, this is not in terms of what you play of course, but in terms of when you start or stop the overdub. And this because when overdubbing, you’re already sync’ed with the track you’re overdubbing (in terms of duration) and can stop or start basically whenever you want without impacting the duration of the loop… But I agree with you, as musicians, we always prefer anything triggered by the on-press event… even in this case…

No it is not possible because it’s exactly the same problem as long-press events. If you have a secondary action on a double-tap, the machine has to wait (same as long press) to know if you wanted to tap a second time (and trigger the action bound to the double-tap), and until sure cannot trigger the action bound to the on-press.
To summarize, long-press or double-tap events for secondary actions unfortunately generate exactly the same issue.

9

Amazing

10

Thank you for the thorough post, we are looking into it!

This is what we want to do.

We hope to add a clear track layer to the held undo command, this would provide a solution for needing to re-record a track to freeform. More on this soon.

1 Like
11

Cool :+1:

You mean, instead of current “undo” ? An “undo” without a “redo” or an extra level of “undo” ?

12

Correct! like a clearing option in three layers, undo top layer> undo base layer > clear track

We understand this is a mid-way fix for the logic not recognizing the undone tracks as one would expect, but that may take time to fix.

13

Then I am sorry @BrennanSingularSound that I have to say, that I strongly disagree with this proposal, and I think there are good reasons for that.

Facts:

It doesn’t solve anything for the first levels of undo. There will still be for those levels the exact same problem I have been describing. Meaning that if I plan to “undo” something to re-record in a viable mode, my only option becomes now to use this last level of “undo” (what you refer as the third layer).

So it triggers a couple of questions.

  • Do we agree that if I “undo” something, in the obvious purpose of re-recording something, my only option is to “undo” the track, with no possibility to “redo” ?
  • As the current way to “undo” is kept as it is for the the two first layers, and that I can’t re-record anything correct in these modes, their only purpose becomes then to be able to do “redo”. Can I then ask you something ? What is the point of an “undo” which only purpose is to do be able to do “redo” :stuck_out_tongue_winking_eye: ? Sounds a lot like mute/unmute to me…

Looks like it’s game over there…

So For me it means the following:

  • You are de facto dropping the “redo” feature for the only real “undo” flow.
  • You keep broken flows (the first two), which become even more useless.

Is there somewhere I am wrong ?

14

@LaurentB thank you for your deep thought on this matter and laying everything out in such detail and clarity.

Regarding the Next Part command while recording: I agree. We will disable mixer access with a long hold while recording so this can be on the downpress.

Regarding the undo/redo/re-recording issue, the main debate I see is, do we want:

3 levels of undo, with 3rd level being a complete ‘clear track’:

Advantage: Keeps redo hands free
Disadvantage: You must wait until the 3rd level of clear track to have an accurate ‘re-record’ (more time) – and this may cause frustration in users who are not aware of the necessity of the clear track for an accurate re-record.

OR

Redo is a touchscreen only command - you touch the waveform to redo:
Advantage: all re-recording is on the downpress at all times. Everything is more consistent.
Disadvantage: you have to bend down and touch the screen for the redo command.

I am personally leaning towards @LaurentB’s suggestion of redo as a touchscreen command because I think redo is a rare situation where you did undo by accident. My only hesitation is that quantized mode users do not have the re-record timing problem at all because everything is cued at the end of the measure and they won’t like having the redo command relegated to the touchscreen.

I do not want to make the system work differently in quantized mode and freeform mode because that would cause massive complexity and likely cause many bugs as the modes diverge in operating procedures.

If anyone has any other suggestions to solve this problem, I would love to hear them.

Otherwise, we will probably go with @LaurentB’s suggestion of redo as a touchscreen (and MIDI) command.

2 Likes
15

@DavidPackouz, @BrennanSingularSound

Thank you for acknowledging my analysis. It’s always nice to see that if you voice valid and argued concerns there are people to take them in account.

Nevertheless, I don’t think the trip stops there… (I see you scared :scream:).

You are expressing a very valid concern David, which is:

So I agree with you. If I would be a user of the quantized-mode, I would definitily not like this (necessary) decision.

But is there a way we could go even further, keep a consistency between the quantized and freeform mode in terms of features while not removing features from the quantized mode and of course addressing the issue we are discussing there ?

Good news, I believe we can.

Everything I layed out in this topic is true for the first track of a song part. Then things are a bit different. And would say that after the recording of that initial track, freeform and quantized modes have much more in common, and especially if in the freeform mode you activate the “Sync tracks start & length” setting (which is by far my preferred mode as it has a little flavour of the hybrid mode I had requested prior to this last release).

So my proposal is to, instead of thinking the problem we are discussing in terms of quantized vs freeform, why don’t we think it in terms of immediacy vs deferment :bulb: ?

If the settings (“Sync tracks start & length”, and possibly some others), the mode (quantized vs freeform) and the context (first track vs others) define what we would call an “immediate-action mode”, then everything we said here has to be applied in this mode (master rule applies and secondary actions have to be removed from re-record start and stop button, leading here to the “redo” relegated to the touchscreen…). And if we are not in such a mode (like in quantized mode or for subsequent tracks if synced to start and length in freeform mode), we do not need to apply this master rule at all and can keep the current behavior as it is… That would sound a lot like the best of both worlds.

I don’t really think it complexifies the usage, as the user feels this sense of immediacy depending on the settings/mode/context… I mean, he knows what he defined and the impact it has on when he has to click on this or this…

Now, I’m not saying, this is as priority as what I emphasized earlier in this topic, but I think it definitely worth for you to think about it now, and run an in-depth analysis. And even if at first sight, it may look like a complexification of your code, it is maybe not and actually maybe even a clarification… That could potentially lead eventually to a simplification of settings to be exposed to the end-user…

16

@LaurentB I am concerned that this over complicates things. sometimes redo works on a hold and sometimes it doesn’t? depending on settings?!! Imagine trying to explain that in the quickstart guide to a new user :sweat_smile:

I would prefer to keep everything as consistent as possible.

17

@DavidPackouz

Thanks for the feedback

Obviously this requires a bit of thinking and for example an icon on the screen showing in real-time if we are in immediacy-mode or deferment-mode could do the trick. The internal complexity has not to be exposed to the user and the quickstart guide would just mention the behavior regarding the presence or not of that icon on screen…

I don’t think it’s a bad idea, because today the behavior relies on a combination of so many things (mode/settings) that even if you know it’s not so obvious…

But honestly I won’t struggle for that, I’m fine with what we discussed previously, it was just an idea that I thought if implemented right, could even simplify the understanding from the user point of view. If you don’t, fair enough, I let you write the quickstart guide to explain the combination of settings/modes :rofl:

1 Like
18

I have never in my life read and returned to an online forum as often and with as much interest as I have since the Aeros came out. I was ecstatic about this looper when watching the videos and immediately started sharing my excitement with friends. What this looper potentially makes possible is nothing short of game-changing to me… and that is coming from a very satisfied Boomerang III owner of 6 years!

All of that said… I have not pulled the trigger yet… and I won’t until these types of issues are fixed. I sooooo want this to work. I have never wanted a business/tech venture to be as successful as I want the Areos to be. I appreciate the work you are putting into and I look forward to all of that coming to fruition into a product that inspires the awe and confidence it deserves. I’m still waiting (and I tell my friends to wait) until the day you reach that.

I also appreciate all the hard and patient work of those like LaurentB who clearly have an interest in your success.

I have never written like this on a forum…or of any product. Guess there is a first for eveything.

2 Likes
19

Wow, you made my day (actually night here in France). And I must admit that it is a first time for me too. I never ever contributed to any forum like that before or even thought about saying thank you to a company I bought something from.

And the reason why is that, first of all I want the success of the Aeros too, because like many people here I really feel it’s a disruptive game changer, but as well because this is a place it’s possible to actually contribute, not just applause at a keynote.

I’m reaching one month with the Aeros, and honestly in the beginning I clearly thought I would return it because of so many things not really working like they should have.
One month later not everything changed of course, but things already greatly improved and more importantly I am now convinced it will go towards the right direction.

Obviously I can understand your wait-and-see approach, and hope to see all these issues fixed soon, and of course I do not forget about people expecting the long awaited MIDI implementation. Tough work ahead @DavidPackouz and all team !

3 Likes
20

Clearly, this device must quickly grow towards its expected functionality with exemplary reliability. There are too many people who doubt about the professionalism of this looper. He came out immature and now has to change that reputation by working hard.

1 Like