Great video @Joe
Just some comments as I was watching:
The procedure for creating DSP objects might seem rather verbose:
local f0 = self:createObject("GainBias","f0")
because you might think that you could just create an object like this:
local f0 = app.GainBias("f0")
and you can create objects like this also. However, they won’t be stored in the Unit’s object table if you do this and hence will not be accessible outside of this method`s scope. The 2nd argument is the name used to store the object in the objects table so that you can access it later (in this case as
self.objects.f0) especially in onLoadViews or onLoadMenu or serialize or deserialize methods.
It might be better to collect all of the stereo-ification code into one chunk so that you don’t need to create objects needed only for the stereo case when the unit has only one channel.
After some thought, it seems I might have misnamed the
Parameter class. It should probably be call
Variable because they can be both inputs and outputs whereas a parameter might sound more like an input. For example,
MinMax class has Min, Max and Center parameters (in addition to its In inlet). However, these are values calculated and updated dynamically based on the signal at the
MinMax input. So in this case Min, Max and Center are parameters that you would get the values of, not set. The
TapTempo object is another example where it is measuring the period or frequency of the incoming pulse train and providing that as readable parameters (in this case,
Base Frequency, and
The purpose of the
GainBias object (f0) is to literally to determine exactly what the gain and bias values in the unit control`s sub display are affecting. This object does that actual gain and bias calculation. The
Unit.ViewControl.GainBias, instantiated later in onLoadViews, wraps this GainBias (or similar) object along with the branch (what sub-chain should I dive into when the user presses S1?) and the range object (how do I draw the final modulation value in the unit control?).
The reasons for existence of
- Provide the necessary meta-data that the unit insert menu requires (name of the unit, category, keywords) because it would be very wasteful to have to instantiate each and every unit just to get its description.
- You can also provide aliases in case you want to replace a unit with a new implementation but still have old presets and quicksaves still work but with the newly named unit.
- Combine multiple units into one library of units for distribution as one entity.
So, the information that you provide in the table being returned at the bottom of the ```init.lua`` code is actually a description of your library which would usually contain more than one unit.
You can create new unit categories at will. The ER-301 will just add the categories to the unit insert menu as it encounters them during the menu construction process.