I noticed that almost since the very beginning, and I am clearly not sure something could be done as it really looks like an hardware issue. But nevertheless, as it is really painful I report it just in case. And even if it cannot be addressed with the current hardware, just to ensure you take that in account for the future devices…
When powering on or off the Aeros it generates a huge sound in the output.
My Aeros is directly connected to my mixer and I took the habit to just mute the tracks until the Aeros is fully booted or before stopping it.
The problem is that:
I can forget
If I am not at home and my Aeros is plugged on some amp system I do not manage myself
The sound it generates is loud, and even when at home where I do not push too much the volume. When I forget I always feel like I could have damaged my speakers…
As a comparison, my Kemper which is connected to the same mixer does not require to take care of this at all. When I switch it on or off it doesn’t generate even the slightest sound…
but this is not what you expect from a modern device.
And this is not like the ultra-cutting-edge latest released device you could find. Meaning it’s possible to treat this problem correctly… I always prefer solutions by design than solutions by work-around.
It is not just the normal power click you get with electronics, it’s only aeros that does this out of all the things I’ve got plugged into mixer. An incredibly loud pop. True bypass pedals install anti-pop resistors to avoid it.
I also agree it’s probably a hardware change needed to fix it, by so I’ve not got any hope and have the same workaround as you.
Obviously without the schematics, we can’t be sure that it can’t be worked around in firmware, but I think the odds are against it.
I agree that this pop is a problem. I also think the on/off-button should be at the rear, rather than the right hand side. I’ve experienced many times that the pedal on the right hand side of the Aeros moves a bit, and BOOM, Aeros gone.
My Headrush looperboard has the on/off switch at the back, and it is a “soft switch”, as you would expect on any computer device. That way you are always asked to confirm to turn the unit off, and must choose if any unsaved changes should be saved.
Don’t misunderstand, I would not trade the Headrush for the Aeros. But the on/off-button is one of the few flaws of my beloved Aeros.
Not sure the position of the switch would change your problem (I experienced slightly touching the power cord to produce the same, which btw produces the sound that in this case you cannot prevent by cutting the sound on the mixer beforehand… ) but definitely for a soft switch with confirmation…
But we all agree that we are discussing about the next gen device Xmas wishlist here don’t we ? …
Thank you for your feedback guys, I agree this was probably something we should have foreseen happening and dealt with a long time ago. It does happen to me too, occasionally. Like you say, more modern devices have this safety. The best we can do is try and see if there’s anything in the software or we can do to minimize and prevent this issue. I’ve reported it
What I can say is that the Aeros is not the only musical device that does this, and in fact in any professional setting, it is best to always turn on devices before turning on the device receiving that signal.
This can get tricky if using a mixer that is both sending to and receiving signal to and from the Aeros, what I do is keep all my faders down as I turn it on/ allow it to start up.
This is exactly what I currently do and what I call a workaround as opposed to solution by design. A solution by design is safe whatever happens it prevents you from doing the error, a workaround works in most cases until you do an error, which statistically will always happen… You just have no seat belt…
I am actually a bit confused. Do you think something could be done with the current hardware ? The sound really occurs when switching the device on or off.
Doesn’t sound at all like something that could be managed at software level.
I hope to be wrong. Do not hesitate to share devs feedback.
Hey there, unfortunately there is nothing we can do about this issue, this is something that is not technically a bug but more a precluded behavior with the hardware as it is. Because of this, I will tag not a bug, this is not a software fix, we will have to make a newer unit design that supports this.
Btw, there must be a way to tag it a bit differently … #not-a-bug is ok as I agree with you this is not software related, but something on top like #require-hardware-change or something to ensure this requirement is captured for the next-gen device.