2.17 "Next part" when recording does not end correctly

I don’t understand the sentence

I mean you introduce technical constraints related to midi orchestration (if I understand well), where I discuss feature. I never ever had any device especially when dealing with real-time that had any of its actions triggered at release-time of a button. From a usability point of view there is absolutely no scenario that could validate that.
I am definitely what you would call a veteran looper. I am using loopers for years and years. And this is exactly because at some point I have to manage real-time loops far more complex than just one-part loops with simple overdubs that I turned to the Aeros…

Now, what I understand from your answer, is that there is no way to end one part and directly switch to another, meaning that for example in the case 2x2 the I would have to make the second at least run once (by hitting the play button) before I am able to switch back to the first one (with the next part button). Am I right ?

You are correct. For that to be possible you would need to release the next part button on the right beat (I fully understand why that is not useful). This is a major reason we built the MIDI Maestro, to deal with these corner cases where buttons act on the release, which is not conducive to perfect timing in every instance in freeform mode. 2x2 is tricky because every button has a hold command, maybe a work around would be to create a changing part mode like that in 6x6 so you first toggle and then give a command that reacts on the press. Not ideal, but again, this is a limitation of the simple design, still I don’t believe it’s insurmountable.

I’m waiting the midi implementation to avoid all the problems due to release buttons.

1 Like

While there are limits what can be done with 4 buttons and a scroll wheel, there are some ways to get a bit more functionality on the device without resorting to midi expansion (and to have real-time actions on press). It’s not obvious, but not rocket science.

Your mileage may vary on what commands are most important to have at your feet.

1 Like

Yet I bought a supposedly standalone device, which primary purpose should be to provide a great stand-alone experience. Otherwise just clearly state that the Aeros is a satellite of the BeatBuddy or requires a non-optional-non-provided MIDI pedal-board. This was not what I understood from Singular Sound communication.

Do not misunderstand me, I like interoperability, and people requesting MIDI integration are perfectly right, but clearly MIDI should help integrating the device into a broader ecosystem (be it as slave or master), but no way drive the features design of the standalone usage… MIDI should enhance the experience and provide more freedom not limit anything for the standalone users. And I perfectly agree with @Quad, 4 buttons and a wheel form a fantastic platform versatile enough to build pretty interesting user flows. Yet binding anything requiring accuracy to the release-time of a button cannot be considered as a feature, it’s simply a bug…

I agree with you and we will find those solutions.

From what I saw the Aeros is able to create your recordings exactly with functions on the press. The problem here is you need the next part feature to be expanded upon to make it possible for it to be done on the press and not require a loop playback. I understand the need for this feature, and I am working with you on a solution that doesn’t require reformatting the entire layout of the machine. While I totally understand the fact that this is an important feature for you, this is not a crucial function for all users.

The Aeros is meant to be a cross roads between synchronized looping and standalone looping, and you are helping to make it that so we very much appreciate your passion and your input.

It’s not really a bug if the machine is meant to work that way, that being said I can see the need for a workaround for the sake of this case. My solution may require two button presses, but it is a solution. MIDI will make it achievable in one press, which as you say will “enhance the experience and provide more freedom”.

We’re working with you guys here, I get your concerns and they are real and valid and heard.

1 Like

@BrennanSingularSound

To be constructive, my requirements can fit within a single sentence, that I will call the master 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.

Binding any action that needs to be precise from a timing standpoint to a button release is not a workaround, but a dead-end. It could potentially have been possible if we would have been able to keep the foot pushing the button and releasing it on time (I would not like it, but from a usability point of view it could have been valid), but as long-press actions exist, it means that we would have to both release it on time and doing it quickly… This is simply not reasonable, I would call that an oxymoron.

In the specific case of the “next part” button, an action, which is outside of the record flow (i.e. access to mixer), has been assigned to a long press. Fair enough. You can apply this behavior as long as it does not conflict with master rule, i.e. in the context of an in-progress recording, the “next part” button should simply ignore the long press action to access the mixer. Is there anyway someone who really wants to access the mixer during the recording especially as during a recording it does nothing (or at least nothing you have a feedback of, until you come back to the recording and actually stop it) ?!? On top of this, I would be curious of humanly feasible use cases during recording…

What do you think of that ?

2 Likes

+1
it is clearly the rule number 1 to be able to make music.

Hello Brennan, I previously asked this but don’t believe I got a response: Would it be possible in 2x2 to program the Next Part button to open the mixer with a double tap (instead of Hold), thus possibly freeing the button to be able to react to a command on press instead of release? Not being a programmer I may be missing something very basic.

@meadowbrook
Unfortunately I doubt it would change anything. The problem being that if a button has to react to any secondary action (either bound to long press or double tap), the system has to wait one way or another until it’s sure that you don’t want to actually trigger any of these secondary actions.
Thus if you want an action to be triggered immediately when you press it (like any action requiring a precise timing, see master rule), the only solution is to (at least temporarily) completely put on hold the reaction of that button to those potential secondary actions.
This is why, what I requested was to completely ignore long presses on this “next part” button during recording. To ensure that the system can immediately react to on-press events without the the need to wait to be sure anything else happen (double or long press)…
@BrennanSingularSound do you confirm my analysis ?

This is a good idea for a midway-point solution for this issue, we’ll look into it. I get the need for more time to adequately enact a release.

Hey there, sadly this would not be an all solving solution and also would create issues like @LaurentB proposed above. We are looking into all the ways we can improve freeform looping.

That seems to make sense. Thanks

1 Like

Thanks! Came up through Roland, Digitech, T.C. & Boomerang - hoping Aeros would finally cover all the bases. 6X6 so far getting me mostly where I want to go but it’d be great if the less tap-dancing 2X2 could also become a fully functional free form machine. I also agree with those who don’t want to have to buy a Maestro to initiate basic commands, unless you made a really small & simple 1 or 2 button box. Looking forward to the ®evolution!

:stop_sign: Since the 2.17 has been replaced by the 3.0 which has been officially released, this topic has been superseded by this one.

And within that new topic, which is more generic, I made a solution proposal here to the problem I did initially raise in this current topic.

Sorry for the change, but as it appeared the problem is wider, it did make more sense to have a generic topic about the underlying problem of which this particular problem is only one of the use cases…

@BrennanSingularSound

You can close this topic which is superseded by an implemented request…