Version 3.3.0. I use an external device (TEMPODE) to provide MIDI Clock and Transport commands. When using this as an external clock, I get a split second audio drop out at the transition of the Loop End and Loop Start. The problem does not exist if I use the AEROS internal clock using an identical workflow. I can post a video if it will help in diagnosing. It doesn’t matter what options I choose for any of the switch, workflow patterns or timing behaviors (I think I tried them all). The culprit seems to be tied to the external clock (maybe someone reading this can test and replicate the issue?)
Has the tempo (bpm) or time signature changed with the external clock since you recorded the track?
A disagreement between the recorded Midi click and the external clock can lead to that type of issue. Might be more to this…
Yeah the TEMPODE clock remains the same at all times. Maybe I should set the AEROS BPM and the TEMPODE BPM the same before running the track. I view a Master Clock as an override and never bother to set a tempo of the slave device. I’ve used the TEMPODE this way with numerous other loopers and they didn’t have such problems.
I am doing the exact same thing and have the same problem. While I understand the problem and it’s causes b/c of the way aeros was implemented here, I don’t understand why it was implemented the way it has been at all.
I want aeros to accept an external midi clock, and quantize to the bars of that midi clock. That midi clock very likely will change. I also have used external clocks (like my MPC, or another sequencer or such, with no such problems with other loopers and devices. )
In fact I used to sync many devices, including my boomerang looper to the beatbuddy and the boomerang did not suffer this problem when I tap tempo’d a new time into the beat buddy and it’s midi clock was sent to the boomerang to quantize to! That the aeros suffers from this is really bad. thanks.
That’s the main problem, it hamstrings the Aeros from being used in a larger MIDI sync setup, which is why I’ve never been able to use it live. If I’m just using the Aeros as a stand alone unit, it’s pretty good with all the improvements, but as a MIDI device, it’s a massive let down. I already gave up waiting for a MIDI API, but I stuck my toe back in the water not imagining that it would have a problem like this. It’s not even a matter of “MIDI is on the roadmap” and when, I don’t have much faith in its actual implementation. It seems too bolted on, lacking a clear API pattern. I would LOVE to be proven wrong.
When AEROS II gets made, I hope they make it a “MIDI First” design and that the developers have to add all functions to the MIDI API and use it internally.
Thanks Quad for the help on this forum and TGP. I tested the idea that the Clock speed had to be set the same in both Aeros and my Master Clock device and it does indeed fix this issue and become serviceable.
Even more, I can reliably reproduce what appears to be happening. The external Master Clock is controlling the tempo with regard to Click and measure scroll speed, but the Aeros Clock continues to dictate the length of the recorded loop, so if I have my Master Clock set for 100 BPM and the Aeros set for 120 BPM, the recording cuts out way before the end of the measure. I can consistantly test this using different Tempo values in each devices and empericaly noting the difference. The problem I originally had when it was cutting out just for a “split second” was because the tempos were set very close to the same, but you can magnify the problem easily.
Even though you understand the problem and can workaround, this is a bug for SS to fix with a warning or some form of stretching/scaling of the loop (which many would want to leave disabled if this has any audio quality impact).
Yes this is due to the mismatch in BPM, we are exploring ways to improve this, but we can only do so much at a time, hoping for a year of plenty of improvements and growth so this can be a day of the past. We have already covered significant ground!
Does this problem happen with the BeatBuddy-> Aeros? I don’t remember it being the case and I recently (last week) sold my Beat Buddy to get a Mini BB. It’s in this interim period that ran into this issue, or so it feels like.
Can the Beat Buddy be set to the midi clock master for aeros and can the BB’s tempo change without this problem? Or does the BB/aeros have to have their BPM’s sync’d as well?
The Aeros only has issues once the song has been recorded to. The tempo will change immediately as the BeatBuddy’s does if there is an incoming MIDI clock signal from the BeatBuddy into the Aeros.
Currently, there is no way to filter the incoming clock signal from the BeatBuddy, meaning if the Aeros is recorded to in 100BPM, and the BeatBuddy shifts to 120BPM, the Aeros will respond (mind whether the BeatBuddy is set to always send clock even when stopped). This causes the Aeros to playback what was recorded in 120 BPM but it is not built to handle recalculation of the audio from one tempo to another.
This mismatch is the root of the issue, we hope to find solutions to this problem soon.
To be clear this can happen with any clock feeding into the Aeros, not just the BeatBuddy.