Ram limits

So.if not for this the er-301 would have near infinite potential! I’ve ordered one, and there’ s no going back, it will do the minimum of what I need, but I’m wondering:

  1. if there’s any resources for working out what the ram will be able to do (is it just trial and error)
  2. a helpful ball park idea of what the ram can do
  3. whether coding in lua or even c would enable the ram to go further
  4. so does anyone have several for this reason

RAM is not your only limiting factor.

The firmware itself it already done in C or C++ and is bare metal, you will not get anymore efficient than that.
There are tons of videos and threads detailing the many things the 301 can and has done.

My honest opinion is you shouldn’t worry about it. Use yours as you need and reach the limitation when and if your task brings you there.

Every system, no matter how robust, will have limitations. They are not always a bad thing.

i think joe already said that learning lua can usefully help with this, so one would assume c likewise?

i just prefer to know what i’m doing from the beginning, even if i take it no further

Lua, which is a scripting language, will allow you to write custom scripts for building custom chains, but it won’t speed up or make your 301 any more efficient.

Think of it like this:
The 301 is the engine. It will pull whatever you attach. It was made with C and cannot be altered by the user.

The chains you build are workloads. Lua allows you to make a workload differently, but it is a workload none the less. You can modify the load so as to be heavier or lighter but that is not the same thing as modifying the engine.

Hope that makes sense.

makes sense

i get that learning C won’t make the module more efficient, anyway

I trust that Brian is writing optimized code, and I know that he continues to make optimizations as he goes along. I’m sure he can write more optimal code than me. So getting better performance out of the ER-301 in general is not really my goal when I develop in the middle layer. My goal for developing in the middle layer is to create reusable functionality that doesn’t exist as a builtin Unit, and to do it in a more optimal way than can be done in the UI layer.

I am not in music making mode when I work in the middle layer. This is more of a place to create things that you’ll want to re-use again and again when you are actually making music by creating patches in the UI layer. Here’s a link to the units I’ve created in the middle layer. You can kind of compare these with some of @NeilParfitt’s videos to get a sense of how what you might do in the middle layer would be different from UI patching.

In general, I wouldn’t worry about what limits you might hit yet. Sure, they are there as with any digital device. But you really can do amazing things with the ER-301 without hitting them.

Furthermore getting more performance out of a middle layer isn’t improvements in execution but rather as a result of a shortcut taken in the workload.

What I mean by this is that a middle layer will never be more efficient than native execution. Never. It can be as efficient, and that is usually after a lot of work and optimization.

no, ofc

wasn’t meaning to imply the brian’s c code could be improved upon in general!