Aeros ignores Change Song Part setting while recording

More specifically, when recording a new track in a part (as opposed to just playing), a transition triggered by a Record Next Track (via midi CC113:127 followed by CC 41:0), will start the transition at the end of measure, as opposed to the current Change Song Part setting (end of loop in my case).

This is almost certainly a bug? Since if you’re not currently recording a track when attempting to start a recording in a next (or previous) part, it works as expected (i.e. it plays until end of loop, transitions, and starts recording a new track in that next part).

This is quite frustrating to work around, since it takes longer to get all the loops recorded in a live time-critical setting, for a multi-part song.

ALSO accidentally doing this currently is a big No-no - since it cuts off your currently playing loop at the next measure (instead of the End of the loop).

Hi there, when this is happening, are there other tracks in the part? Or is the track the only track in that part at the time?

Also what version are you seeing this issue on?

Thank you for reporting, let us know

Hi thanks for the quick response.

Yeah good question. Firstly I’m in freeform, but I can check if this happens in AQ or quantized - I’d be very surprised if that will be different (more on that below)…

With regards firmware version: I was on 5.2.1 until I upgraded to the new beta for the SuperSwitch (5.4.3) - and there is no difference in the new one, it still works like this.

So usually I lock and record the first two tracks (rhythm / groove - generally short - at one or two bars in lenght), and then record a longer section of usually rhythm guitar - multiples of the lenghts of the short locked tracks, and immediately try to transition and start recording in the next (or later on, in some cases previous) part. And it transitions at the next measure seam - not the end of the loop. So in order to get the desired result I have to wait until the playhead is past the last measure, and just before the end of Loop - which is sometimes tricky, especially if my shortest of those first locked loops were very short.

I can test using only one track or so.

But the thing is, if I commit the recording and start playback of that 3rd longer (non-locked) track in my example above, and do exactly the same midi command sequence (within playback, not actively recording, in the current part) - it works as expected and only transitions at the end of the loop (and immediately starts recording a new track in the other part - as one would like).

I think the problem isn’t necessarily a bug, but it’s a quirk that hasn’t really been thought of for some use cases like this. Since, when you trigger a new recording, while currently recording, that current recording wants to stop itself at the end of the next measure, and start the next one right? Which is surely what you would want and expect when recording tracks quickly, one after the other, within the same part. But this is not what one would like when combined with a transition that you queued, if you have your Change Song Part setting on End of Loop. You want it to keep recording that track in the current part until the end of the loop and then do the transition - similarly to hitting that sequence (queue transition, record new track (in other part) (for example CC113:127 followed by CC41:0)), in playback mode.

So this is what I think the expected logic rule might probably be?:
-When currently recording, a Record new track (CC 41:0) should always stop the current recording at the end of the measure (seam of the shortest loop) …and start the recording of a new track (same as it’s always been, dead simple).
-UNLESS a transition to part has been queued (CC113: 127 (next), 126 (previous), numbered (101-106) - in which case it should continue recording until the transition event happens in accordance with the Change Song Part setting (like end of Loop in my use case). (And then of course start recording a new track in this other part that has been transitioned to).
-The other CC:113 options should act accordingly (71-96), ignoring the current Change Song Part, since these explicitly override it. This will be explicit and avoid confusion of what is expected.

Thank you for the detailed explanation! In order for us to look into this issue and troubleshoot, we first need to reproduce it on our end.

Could you please send us a video to support@singularsound.com showing the issue? Make sure to reset the Aeros to its default settings and demonstrate the problem step by step. This will allow us to replicate the behavior and forward the info to the dev team.

Please also include a link to this forum post, so we know that it is related to this specific issue.