Given the noted bug where the Aeros silences some audio (related to external clock, if I’m understanding correctly), is there currently a way to just turn off midi sync without unplugging the midi? I still need it to receive CC’s. I didn’t see anything in any of the options.
We hope to include this soon, it is not possible at this time, no.
We likely will be handling it with a toggle-able setting
Thank you for your patience on this! We know it is problematic when receiving a clock that doesn’t stop.
1 Like
Is there eventually going to be the ability to have a working midi sync or is that impossible to do?
Hey again,
When you say Working in what sense are you referring? Do you mean at the out with Aeros as master? That is coming in the next few updates, a way to desync is likely coming along with it.
We have some UX redesigns that will also show mismatches and also some new methods to hopefully make a lot of this accessible handsfree in the works.
In essence, we can’t do much about the desyncing while receiving the wrong clock because first we need a design to see a mismatch, allow decoupling digitally through filtering, and we would also like to allow it all hands free too!
I know it sounds like I always say soon, but these are things we are designing actively and are already having preliminary talks about with the devs.
But let me know if you mean something else!
Working as in hooked up to a clock pedal which is the master. A lot of us use controllers to send messages to multiple pedals as well as commands, and to have the Aeros be the clock master simply isn’t feasible or remotely convenient.
1 Like
It does already work this way in quantized mode, are you referring to another behavior?
Okay, I guess I’m confused here. I thought the audio dropout bug had to do with being synced to external clock. Is that not the case? Is that only the case in freeform? If that’s the case, then, yes, just having the clock toggle off (or, if it’s only for freeform, just internally/automatically disengage click) would work.
Am I on the right track, here? Thanks.
There should be no effect of the clock on freeform songs already, maybe this is the misunderstanding.
If you have experienced waveform or audio dropouts in freeform, likely this is an unrelated bug, we have seen dropouts in other cases with the new dynamic read system, we believe the kinks are almost all straightened out.
If you believe that there is a direct link that is reproducible between clock and freeform songs dropping out, let me know! The bug should only happen in quantized songs.
There was also the odd case where your songs in particular disappeared and reappeared later after checking on the computer but because they reappeared and it is not reproducible we cannot say why exactly this happened just yet. There is the variable of the SD and we cannot be certain it is not a flaw or hiccup in the SD.
Since these cases seem to be a one in ten thousand chance of happening or maybe less, we have mostly worked on it slowly hoping we find a way to reproduce any bad behavior. The Active Logger was made for this reason, in part.
I don’t remember if those problems were freeform.
So, if I’m understanding you correctly, the fix you’re working on will allow us to run quantized songs with external clock sync with no dropout issues?
Not exactly, the reason the dropout issues happen in the first place is that the Aeros was recorded at one tempo and is now receiving a new one. The issue people often may have is they don’t expect Aeros to respond still to BeatBuddy for example, and BB is always sending clock when stopped by default (though this setting can be changed, this will not allow Aeros to change tempos w BB if it is stopped or changing songs).
You can already run the Aeros with a clock and no dropout issues, the issue Is really two major things: If there’s a mismatch we don’t notify you, and there’s no way to decouple the Aeros from receiving clock without physically disconnecting it or stopping the clock.
Does this make sense?
I think so… so you’re essentially saying if I recorded something at 100 bpm, but later I load it up when my clock is sending 120 bpm, the bug happens? So your fix will essentially decouple it from the clock when there’s a mismatch? Or just decouple all songs, once they’re saved? Seems like that would work.
Yes, correct
Not exactly, we think the user should be in charge of whether it decouples or not, what we need to do is notify the user it’s happening and also allow a method to decouple in the UI.
This could still happen after those fixes if the user has a mismatch and chooses to start playback anyways, we may consider blocking playback in this event and using a pop-up to notify the user that a mismatch is occurring.
Okay. From a user standpoint, I think the best way would be it’s on by default, that way one doesn’t have to think about it when they record a new song. Then, when I inevitably load up that song later with a different bpm coming out of the clock, it just asks if I want to turn it off. Even better would be a ‘do not ask for this song again’ option on the prompt, as well, so I don’t have to go and respond every time. Whadya think?
Well likely by default it will always be searching for MIDI sync, I do not think we will use a pop up and will have other methods likely for doing this on the unit, but the user will have to turn it off manually.
More news soon, thanks for the questions!
Cool… hopefully as little menu-diving as possible (hence the pop-up - you could just press a yes or no with a button, hands-free).
Not sure if this will solve your problem or not but I just purchased a device called event processor from midi Solutions that allows you to filter midi messages. Seems to work great for me so far and very versatile