We are reviewing your findings and likely will have questions soon, thanks!
OK, I’ll keep it here. I should also mention that though I can’t prove it, the problem seems to have gotten worse with the beta release. Before installing the beta, I would bump into this maybe once or twice a week during nightly rehearsals, now I’ve bumped into 2 or 3 times per rehearsal.
Ok, could you please try out CC:113 value 1-3 instead for me?
Just to see
Well, I’m not sure what that would prove since yesterday I caught it failing on this command as well:
Stop: CC 1 43 0 [stop song]
Does it still make sense to try your experiment, and if so, why?
What I haven’t tried yet is to try to reproduce the problem with the Beat Buddy out of the loop. it’s sending clock and time sig (sysex) messages which perhaps are colliding with the CC messages. I’ll try to spend some time today seeing if I can reproduce in Freeform mode with the beat buddy MIDI disconnected.
Note that since you can monitor these messages after Aeros, they are fully functional messages, not hidden by any other message
My guess would be that the firmware just loses some messages for any possible reason And at this point it could be anything, but it sure could be because Aeros is busy handling some other message
I’m just saying that by guessing it might be impossible to solve this problem Best to let SS people solve this
I’m trying an experiment: Since, as pointed out above, the Aeros is seeing the MIDI events well enough to send them out its MIDI out but once in a while (seemingly randomly) not responding to them, I’ve programmed the MM to send each command twice (they show up in my MIDI monitor 1 millisecond apart). (I REALLY appreciate the flexibility of the MM!). Last night’s rehearsal (with this new configuration) went without Aeros incident, so, so far so good. I’ll report back if I see any future failures or if a week or so goes by without any missed commands. Perhaps (I hope) this will serve as a workaround until this problem can be fixed…
When sending double commands, the problem still happens occasionally (I might try triple commands next). Using the single commands, I can now reproduce the problem pretty quickly even when not syncing to the BeatBuddy, but only if the BeatBuddy is still sending clocks (disconnecting the MIDI out from the BeatBuddy seems to cure the problem). Note that I’m currently using an external MIDI merge box to merge the MM and BB signals – I switched to using the merge box after first encountering this problem while relying on the MM to do the merge. As before, monitoring the MIDI stream entering and leaving the Aeros shows no errors, the unit simply does not react to commands, randomly.
Here’s the order of commands I’ve been using to test with just a few seconds between commands:
- CC 1 113 101 (begin record part 1)
- CC 1 113 102 (begin record part 2)
- CC 1 113 101 (play part 1)
- CC 1 43 0 (stop)
- CC 1 42 0 (clear)
[repeat until error]
Running this test I’ll usually see an error in under 5 minutes of repeated testing, and the failures I’ve seen have been on either the play, stop, or clear commands (essentially, random).
Hope this helps the tech team reproduce this super bad problem – makes the unit very unreliable.
Thanks,
Slim
So much for my workaround. I tried sending 4 of the same command for every button press, which basically works and may indeed reduce the frequency of the random misses, but last night using this configuration two CC 1 113 101 commands failed in a row using the 4-for-1 configuration on the MM, a third button press finally caused the Aeros to respond.
Worth noting that I’ve yet to be able to reproduce the problem when the BB is not connected (IOW, removing the clock and time sig events from the MIDI stream).
I’d appreciate it if someone from the Aeros support team would acknowledge that the dev team is aware of this issue and whether or not they’ve been able to reproduce the problem as this is a very serious issue when using your three great units together as they were (apparently) designed to be used.
Thanks,
- Slim
Hey there,
Good news! We think we fixed the issue and the fix should be available when we update the beta with a new 5.2.1. You can try it out when it is out and let us know.
Thank you for your patience and for reporting!
Fingers crossed… If this is fixed I will be a very happy camper :-).
Is anyone else having this problem? Im using the 6x6 mode on my Aeros Looper, im connected to the beatbuddy and the midi maestro to switch between parts. Recently, Ive noticed that when I press a song part on the midi maestro it sometimes fails to switch parts on the looper although itll switch parts on the beatbuddy… im on the most recent firmware update, but ive noticed it happening with the previous firmware as well. Ive also noticed that its happening more frequently as well. I have a big gig coming up and im worried that itll continue to fail to switch parts. Does anyone have any insight into this issue? Or do i just wait until a firmware fixes this?
Thanks guys,
Brian
Hey there,
What exactly are you sending out of the midi maestro? Are you sending the command to a channel the Aeros is listening to?
Could you send a picture of the custom mode button set up(s) on your phone for the button(s) you are using to change parts? I’m assuming you are using a custom mode and not the default mode
Mind that the BeatBuddy will only change the Aeros song part in 6x6 if a song part other than the current one is selected, you can avoid this issue by having both units respond
Are you currently on version 5.0.3?
Let me know!
Hey Brennan,
Thanks for the quick reply, much appreciated. Im using it in the default mode (aeros) ive pre-recorded all of my tracks on the looper and saved them. So, when I perform im not adding any new loops just switching song parts and singing and playing guitar. I have the breakout midi cable for the Beatbuddy and its going to both the looper and midi pedal. It works normally id say 80% of the time… however somtimes when i try to switch from a verse part to chorus part only the beat buddy will switch parts and the aeros will remain on the verse part… most of the time it will work fine but like i said ive noticed it getting more frequent. Ive updated all firmware on all devices.
I just wanted to add, that I had the same issue with the beatbuddy before I got the Midi Maestro and was using it in 2x2 mode. The beatbuddy sometimes failed to transition the parts… but that was fixed in a firmware update and didnt have an issue after that with thr beatbuddy…but now its doing the same thing with the midi maestro.
If you could please send a video report of what you mean and what you are experiencing to support@singularsound.com that would be very helpful, that does seem odd
Have you updated to version 5.0.3 for the Aeros, 4.1.4 for the BeatBuddy, and you’re using MIDI Maestro version 1.1.9 along with the latest apps and default modes on the 1.6.1 app?
If you are not fully update on all devices, please do so, and let us know if the issue persists!
If you are not yet on 5.0.3 you may wish to stay on 4.1.3 until after your gig, a lot has changed, but this bug should not be there either
Thanks
Hey Brennan, so Ive finally been able to take the time to record a video of the Midi Maestro failing to switch parts on the Aeros Looper. Where can I send the video clip?
Sorry, I just checked your previous message… ill send a link as soon as i upload it. Cheers! Thanks for the help
Cool, just stay in contact with support and you’ll communicate there!
Thanks for reporting
I am seeing this behavior as well. The next part seems to sometimes change the beat buddy and not the aeros looper. I have found that if I hold down the button when this is happening, the beat buddy will trigger and the aeros will trigger maybe a second after, like a delay of some sort.