Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

Custom tempo tracking unit—tips from other custom unit developers

custom-unit

#1

Hey, folks. I’ve had my ER-301 for a while but sadly it didn’t get the use I wanted out of it due to personal time constraints. However, I have some more time now and want to dive into some problems I think need solving (for me and perhaps others). I’m a professional developer by trade and am ready to make some custom units (I guess they are called bespoke units now?).

I stated one previous problem I want to solve using the ER-301 here: BPM Trigger. I still haven’t found a good solution to this, so I’m doing a deep dive on intelligent tempo-tracking algorithms. I plan on implementing one in a custom unit to do generalized BPM detection in a manner than is resilient to all forms of incoming audio (breaks, noise, polyrhythms, etc).

I’m looking for any general tips from other custom unit developers on CPU constraints, the API (I guess we work with a thing called the Middle Layer now), and and generally what’s available and high level input. I haven’t had time to dive into the current state of ER-301 development because things move so quickly here, just trying to get my footing after a year of not using the unit much.


#2

custom unit now is generally intended as a unit you build inside the custom unit container and for which you create and assign custom controls, all within the UI. you load custom units by inserting a “custom unit” unit from the unit chooser menu and then loading up a preset. (to phrase it differently: custom units are saved as presets of the “custom unit” unit)
bespoke unit now defines a custom unit that is built in LUA and that appears in the unit chooser menu along factory units.

the only part of the code you can access and develop as of now is the Middle Layer which is coded in LUA and lets you connect,organize,build and assign controls for and set up different existing low level blocks. with this now you can craft bespoke units.

the low level blocks are built in C++, that layer will be open sooner or later so you’ll be able to code your own low level dsp blocks.


#3

@hyena, thanks, that was a very helpful summary. @odevices if I wanted to write some type of custom DSP, even though you haven’t opened up the code, is there some header I could link against to at least mock a unit against some stub APIs and send it your way? Most of this will be just making a tempo tracking algo that is optimized for minimal, steady-state CPU and memory usage and plugging it into whatever framework you have developed.


#4

Looking forward to your efforts. Did the Tap Tempo unit exists last time you used the ER-301? I’m thinking an Envelope Follower unit into the Tap Tempo unit (you can set the threshold for the Tap Tempo input, I think) might be what you were looking for with the BPM trigger?


#5

It did exist in an earlier form. However, it didn’t do the trick for a few reasons. One—this type of tracking is very unreliable. Especially for anything that’s not a four-on-the-floor rhythm. Two, I use the ER-301 as part of an effects loop in a mixer, so I have raw audio in and out. Because the ER-301 doesn’t have DC-biased outputs, I need to basically generate a signal that can be tracked by an envelope follower and converted to a DC gate/trigger anyway for reliable use in the rest of the chain.


#6

OK, yeah, I still think those constraints are in place with the Tap Tempo, as far it looking for a pretty straight clock signal, as far as I know.

All of the API docs that we have available right now are in the first post here, and Q&A follows. The LUA for the builtin units is there too.

All the bespoke units I’ve created are here, if looking them over is helpful in getting up to speed.

@hyena’s summary of the middle layer api is spot on. You can connect the DSP objects that @odevices has created up in a very flexible way, and define your own controls, but the c++ layer is not yet exposed for creating your own DSP.


#7

I was trying to think what other specific tips I might have, and the only thing I’ve really come up with is this. Jump in and start developing some things in the middle layer, even if you can’t meet your current goal without access to the dsp layer.

It’s Lua, but like any other rich SDK built on it, the knowledge of Lua is probably somewhat trivial for a full time developer compared to the knowledge of how to use the SDK itself. You’ll need to know your way around the middle layer even after the DSP layer is available in order to create units, so I’m sure this why @odevices put it out first. There’s a lot there to work with already.

I forgot I had made this unlisted video a while back. I went at it from the angle of someone who hasn’t done much coding, so a good bit of it may be review for you, but maybe it’ll help as a primer.


#8

Good advice, I’ll see what I can whip up in the meantime while waiting on more info.