Great, thanks so much. I am very excited to receive the Aeros!
My pleasure, and that’s great!
Do you have a feature roadmap available that I could look at? Very interested in what is coming next. Thanks.
The next big 3 are MIDI implementation, Lock tracks, and auto-quantize in that order, we haven’t prioritized past that so far.
Perfect, thank you.
Do you plan a real-time wave analysis (which I doubt could be 100% reliable) or more something like we discussed here ?
It will most likely be with simple division, we will be getting to it soon, so stay tuned on that.
Hi, this forum is really helpful! This is exactly what I wanted to know. Now I’m planning to buy the Aeros. Do you have any expectation of the timing for the update?
By the way, I’m using Boss RC series (RC-20 and RC-50) from 2002 and I think the auto-quantize thing is really important for people who used RC series to shift to the Aeros.
Thank you for your quick reply. I really look forward the update!
Auto quantize with Bpm generetor have to work in freeform mode. When you aren’t in freeform mode, no needs a bpm generator (you put it manually or it come from an external clock)
Auto-quantize and Freeform are going to be treated as separate modes. We are not 100% on how it will look yet, but it will most likely be like choosing quantized and freeform and give a third hybrid option. That being said, being able to keep everything in time and generate an adequate Master clock with immediate calculations of tempo after the first track is recorded will probably not be easy and will mean we need to probably look at re-sync algorithm for the specific case. This is an advanced feature for us and will not be included in the first iteration of Auto-Quanntize.
We will explore the possibility eventually, but it is definitely seen as an enhancement. That being said, there are no promises here, no looper that I know of has both the ability to auto quantize and act as a seamless master to an external MIDI device. But please let me know of any loopers that can do this!
My 2 cents! At the very least, it could start with just taking the setting of the time signature from the track settings and, after closing the recording the first time, creating the click track That doesn’t address any MIDI issues, but from the point of view of “live looping” it provides a very much wanted and practical result. You set your time signature, record the track and you’ll immediately have a click track available for the rest of the band to follow and further looping.
When the aeros is master it is generating the clock so there is nothing to resync to, and freeform mode shows aeros already syncs itself just fine. Master devices don’t resync. What would they resync to? Aeros has, in fact, already done the difficult sync problem… As a non-master. Master is always the easy half of protocols.
As for calculating the BPM… It would be fairly simple to do a first pass. The length of the first loop is a known quantity, that time can be converted to a “core” BPM (but as I’ve banged on about before, it should be stored internally as a time not as a reciprocal). Knowing that time the possible BPMs (given a 4/4 time signature, but the same principle applies for any meter) are all the integer rations of that time.
Those integer rations will rapidly fall into the possible/impossible range. So you narrow down the list, probably about 10. First implementation then would be to just pick one in the more common range. It’ll work well enough to start transmitting a midi master clock that would keep other devices in time, or at least a multiple of the right time. Those calculations would be literally trivial for a one dollar microcontroller, let alone something as powerful as the aeros.
The second and more difficult pass is to test each potential BPM against the audio with a correlation algorithm. It would be like a full best detection algorithm but is actually much simpler because you have a list of potential BPMs to try, no need for it to be capable of detecting any beat at all.
If it were me I would cross correlate the loop sample against a generated pulse train wave representing each of the potential BPM rates. The one with maximum correlation is your beat.
After that there are increasingly harder beat detection algorithms. And they have to run in the time for one sample on the aeros so that you can get the MIDI clock as soon as the loop is closed. That part does indeed sound harder, and only experimentation will tell you if you can get the answer quick enough to do the job. But I think you are massively exaggerating how difficult this would be to get something workable. Freeform mode is almost it (with its sync options active), so all that’s really missing is the ability for aeros to transmit MIDI master messages representing the clock it already maintains in freeform mode.
Hey there, the resync is a major part of how the BB + Aeros relationship works, some loopers experience a drift even using MIDI sync. The Aeros resyncs to the BeatBuddy constantly to avoid this. I am referring to the re-syncing the BeatBuddy will likely have to do to Aeros’s newly created tempo.
I will forward your suggestions, thanks for your feedback
That’s the beat buddy firmware but we were talking about the aeros firmware and auto quantise mode. Aeros won’t resync in master mode. The master device on a midi bus, by definition, cannot drift. It defines the clock.
Hence resync will not…
Since it’s nothing to do with auto quantise/midi master on the aeros. Are you really not going to implement features on aeros because of beat buddy? What about for people who don’t have a beat buddy?
As for beat buddy needing to support slave clock mode: yes that might be harder, but fortunately you’ve already done it in aeros so have a well working algorithm… Use that. To be honest, it’s not good that beat buddy isn’t already able to be a midi slave.
I don’t have a Beat Buddy. I only use free form. Creating a one bar percussive locked loop seems to recognize my measures. I love how this works for me. Maybe I’m not understanding what exactly others are asking for.
Let’s take a step back because we are starting to drift away from the focus of this thread and you are also pointing out some things I would like to clarify.
We cannot allow for our products to have major mishaps between them, one very common application of AutoQuantize and MIDI Master being functional is that both our products work well together in AutoQuantize mode with the Aeros as master. The BeatBuddy will be our internal way of verifying that this is working the way it should. This should only be beneficial to the Aeros working with 3rd party products so I’m not sure I understand the point you’re making here.
We do not wish to pair the AutoQ ability and MIDI master ability releases as one, we would prefer to keep it to one major feature per release to keep the team sharp and focused. Yes, this will make AutoQ a purely standalone Aeros feature at first, but it will be the best way to build into the MIDI Master release which is slated for right after if we divide and conquer. We have not discussed it but it’s even possible these could be worked on in parallel, we have to discuss that, and that is coming soon.
There is no current issue with the BeatBuddy working as a MIDI receiver, just to be clear, I am just speaking about what is already present in the relationship with BB as transmitter and Aeros as receiver, that being a very solid re-sync algorithm on top of the Clock and also support for songs with and without intros.
Like I said, the developers across both devices have not looked at this with enough closeness for me to be saying anything other than speculation, but given the precision needed and the high quality expected, I don’t wish to tell anyone it seems easy until I hear it myself from our own developers.
I have already forwarded your very in-depth response to the developers as far as how you think it could work.
Users require the Aeros to send MIDI clock in this state to synchronize other MIDI devices to it, this is the major benefit of Auto Quantize, which is expected to include various tempos allowed in a song, one tempo per part (based on first track).
In essence it’s full potential will come with the following release when Aeros can act as MIDI master.
Thanks for the question!
Thank you for an interesting reply.
My core point was that you seemed to be misunderstanding what midi master on aeros implies - you said resync is hard but there is no resync in the master, so it’s actually very easy to implement midi master on the aeros (given the facilities we know it has simply by observation), with the proviso that you already know the BPM (and you do, by tap or by setting). Once you have set the tempo on the aeros you have all that you need. You just start transmitting the midi message at the right time.
Auto quantise is a method of inferring the BPM not from a tap or from an explicit input from the user, but from the size of a loop.
So… Midi master on aeros is, to my mind trivial - aeros is already 99% there, it only needs to emit the clock it must already be maintaining in standalone mode, and it’s done (perhaps you’ll want to add a time signature message like BB does). I completely understand that you would want BeatBuddy to function well in that case, but i that is not an aeros issue, that’s a beat buddy issue.
Auto quantise is, really, nothing to do with midi master. It’s simply that it only serves a practical purpose when midi master is available (it might be nice to draw the subdivisions correctly on the display but that’s not a huge feature jump). Auto quantise job though is as a method of setting the internal beat clock of the aeros. Again, nothing to do with beat buddy, and in truth, useful for more than just BeatBuddy. As I described above, I think there are levels of difficulty to this, but I’d encourage doing simple first and getting it out and in use.
If you are internally tying these together in your project planning, making the Gantt chart so that one only happens when the other is done, you’re making a mistake. They are all independent features. Now, of course it’s true that they are each useful for verifying that the other is working, but don’t create artificial dependencies in project plans just because of that, there are other ways to test these things. Parallelism encourages modularity and modularity encourages abstraction of interfaces and abstraction of interfaces reduces internal complexity. And reduced complexity reduces bugs. It doesn’t sound like you disagree with that, but I do think you’ve got the ordering wrong. I can’t think what use auto quantise has without midi master already in place, even if they are and should be developed independently.
I know I’m not a project manager at singular, so this is all just noise. I only say it because I care. The singular product range seems to have such potential, and I want to see it fulfilled.
Interesting, thanks for your feedback!
It occurred to me how to work around this high speed requirement. Thought I’d share in case you’re interested.
There’s a lot of work to do to run a full beat detection algorithm in the time for one audio sample (or less, since the “end loop” click could come any time in a sample period, but let’s pretend the button is synced to the sample clock). So much work, that it seems really unlikely it could be done fast enough to make auto quantise work.
However, the option that I thought of is that you could spread some of the work during the loop recording phase. If you ran a low priority task that spread over N samples, you could already have done a lot of auto correlation of the loop as it’s being recorded. That would give you a secondary list of potential BPM values ready for when the loop closes. When it does close you can compare the potential list from the loop length with the potential list from the auto correlation. That should let you pick the appropriate BPM quickly and with more confidence.
Taking that further, you can rule out impractical BPM values early on. Let’s say the fastest possible is a very generous 400 BPM. That means you can expect at least 150ms per beat. So you can pick an algorithm that takes that long because you know that if the loop closes sooner than that it was less than a beat and so insufficient for analysis. Then add in that you probably also are going to require that the time signature be set, it’s not unreasonable to require at least one measure of beats to do best detection, so you would have 300ms (in 2/4 at 400bpm) at least to do some pre calculations.