Thanks to the (afterwards somewhat obvious) appearance of "pads" (pins) as a separate class in the framework design, it turns out that they will be quite an important part ioflow
Here's an excerpt of my
current class draft (ugly pseudocode. probably pascal style?)
Code:
=== TPad ===
properties:
- name : string # name handle for pad
- label : string # human readable name of pad (useful for labeling "pins")
- value : variant # current value of data in pad
- offset : numeric # +/- offset to add to the value before sending
- pads : array of pads # existing connections
- inputs : array of pads # connections to listen to (filled once at runtime from "self.pads")
- outputs : array of pads # connections to send to (filled once at runtime from "self.pads")
- flow : [in|out|duplex] # data flow of pad: "sink|source|both"
- type : numeric|string|xxx # type
- keep alive : numeric # interval between re-sending of value (in msec)
- ramping : numeric # time delay between 2 values (in msec)
- calibration : bool # auto calibration on/off
- filter : array of TPadFilter #
- min : numeric # lower range limit
- max : numeric # upper range limit
- precision : numeric # decimals after the comma. for floats.
methods:
- send() #
- recv() #
- bang() # trigger re-sending of previous values
As you can see, most of the magical data conversion (type, range, etc...) will be done in here, as well as preprocessing(filtering) of values.
Oh, btw: Did I mention that the filtering array is actually going to be an "effect rack" style chain? It will be possible to cascade filters.

Currently, the most basic filter is a gate:
Code:
=== TPadFilter ===
properties:
- name : string # name handle for pad
- label : string # human readable name of filter
- in : variant # input
- out : variant # output
- old : array of variant # previous value. useful for differential filters.
=== (TPadFilter)TGate ===
# Blocks values outside a given range
properties:
- min :
- max :
- type : [lowpass|midpass|highpass]