Custom block options

Blocks could be configurable with checkbox-based options. For example, when designing an Envelope Generator blocks, you may wish to define alternate behaviours for retriggering, different curves, or an option between constant rate or constant time segments.

A child element of <block>, an <option> element could be rendered as a checkbox in the inspector, and a #define in the body of the code immediately prior to the block's code. Additionally, an #undef could appear at the end of the code to prevent conflicts.

<option name="LOG_ATTACK"  info="Logarithmic Attack" />

becomes

#define LOG_ATTACK

Block designers could then

#ifdef LOG_ATTACK

Further, a group of options could be rendered as a radio button group, for example (ignoring the awful element naming):

<option name="ATTACK_CURVE" info="Attack Curve">
    <optionval info="Linear" value="0" />
    <optionval info="Exponential" value="1" />
    <optionval info="Logarithmic" value="2" />
</option>

Which would render (if logarithmic were selected):

#define ATTACK_CURVE    2

Additionally, options could be extended to support user-assignable compile-time constants. For instance, when configuring a delay block, the user may wish to specify a maximum delay for the block, to conserve space.

<option name="MAX_SAMPLES" info="Maximum length" value="1500" editable="1" />

While the XML conventions used would need more consideration and better design, the functionality of this feature is powerful. Conditional compilation could allow block designers to make a single block that supports many configurations.

Right now, if an ADSR designer wanted to give users a variety of options for block configuration, there are two choices: one inefficient block or many efficient blocks. Neither of these options are attractive.

Comments (2)