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

Middle Layer SDK (aka patching with Lua)



I’m sure I’m doing something goofy, but this is not working quite this way for me. If I do this, it has the expected result, with the input being filtered above 400 Hz.

local lpI1 = self:createObject("StereoLadderFilter","lpI1")
local lpI1f0 = self:createObject("GainBias","lpI1f0")

If I do this I’m pretty sure the filter fundamental remains at 0 Hz (I get no signal out):

local lpI1 = self:createObject("StereoLadderFilter","lpI1")

Is it because hardSet only works on parameters, and not Inlets?

If so, is there a different method for setting an Inlet to a constant value without creating a DSP such as GainBias or ConstantOffset object to do so?


Sorry, I forgot to make a distinction between Ports (i.e. Inlets and Outlets) and Parameters. :bowing_man:

Like you suspected, you cannot call hardSet on an Inlet, only parameters. Inlets and Outlets are streaming ports that only accept audio rate signals. Parameters are updated at the frame rate and accessible from the UI layer. If you want to feed an Inlet a constant stream of values then you would create a Constant object (*), hardSet the “Value” parameter and then connect its “Out” outlet to the desired inlet.

(*) or a GainBias object if you want more control.


I assume a Constant is more efficient than a ConstantGain, ConstantOffset, or GainBias? I know you told me to not worry about it but I am planning on creating a pretty large number of DSP objects in this project. :wink:


That is correct. The difference is tiny but in terms of CPU usage:

Constant < ConstantGain = ConstantOffset < GainBias


What is the preferred method of testing out code? Moving a uSD back and forth is getting old.

I’ve been coding using Atom for helping with the syntax. Is there anything better you’d recommend? Is there a way to make sure the code even runs on my computer before I transfer the file?


first post:



Is that available now? Think I missed that one, that would help enormously!! Any info on how to?


no, i think it’s on the 2Do list of things.


Ahhhh… I was all exited then for a second or two :smiley:


That will definitely be nice. Been doing a lot in the middle layer today and I’ve definitely been playing SD card jockey. :slight_smile: It’s all good though, I knew what I was getting into. The debug info that comes back in crash.log and error.log is pretty good now though, so I don’t usually end up with more than 1 round trip for an actual error. I can figure out what’s wrong.


@odevices I wonder if it would be all the same amount of work to port it to VCVRack? That way you get a complete modular environment to test your code in - this would be incredibly useful!!


That is of course already being considered :wink:


:open_mouth: :open_mouth: :open_mouth: 20 characters


I never like to presume anything… most of the time I am wrong!

But fantastic to hear this is being considered, I offer my most sincere encouragement, consider it very enthusiastic and without any reserve - this would make life so much easier!

I am pretty much up to speed on the Lua side of things, in principle anyway, but the one thing that is stopping me is the very physical development environment.


Actually, I would pay a premium for it, I am sure lots of other folk would too!


if it’s reasonable why not! or i might suggest: free for hardware 301 owners, fair price for the rest.
from a marketing point of view tho free for all might be a better choice…once one understands what an awful lot of different things the 301 can accomplish (and you really get it only when you start fiddling with it) and how easy it is, i guess sales might improve (if that is needed).
but a fair price might do as well. imagine people spending something like 20 dollars to be able to fully try before buy the real thing! no brainer if you are seriously interested in the hardware version but have some doubts.


Good point, free for hardware owner would probably be a sensible move, I’ve seen this before and it’s always a nice touch, many other companies don’t seem to show any consideration like this though - I learned to just accept it.

The only thing I really care about is that the development process for the middle layer is improved somewhat :slight_smile:


I would prefer to see USB programming and debugging over an emulator, as cool as it sounds. It seems to me that even with a faithful emulation you’d want a fast and reliable way to upload units. Especially once coding new units in C++ becomes a reality. Besides, the difference in complexity between the two options has got to be at least an order of magnitude.


Sure… anything in the right direction at this point would be very welcome!


I have been logging some significant hours in middle layer code last couple of days. A few random thoughts.

One of the advantages I didn’t realize is just how fast a complex native/bespoke unit loads compared a complex custom unit. I guess a lot of the load time must be spent drawing out the UI for all of the units and subchains in a UI layer CU, where in a bespoke unit the DSP objects only have the UI components you put there. Granted, we’re only talking about a few seconds to load up something like Evil Twin or Ultraviolet, but if these were built in the middle layer, the load time would prob be almost instant. :slight_smile:

So far I’m leaning toward @miminashi’s thoughts that the USB connection would be a more useful first step for 3rd party devs. It would probably also be really useful if there was some kind of stdout to write to for debugging purposes. VCV rack would definitely be cool eventually though and might be good publicity for O|D.