Page 2 of 2
gstreamer, anyone?
Posted: Tue Sep 23, 2008 11:17 am
by ^rooker
"halex" (from monome-forums) has expressed this idea using his knowhow about gstreamer:
http://mediati.org/temp/router.html
The term "pads" is an excellent description of what I previously called "ports" or "inputs/outputs" of elements/widgets/etc.
Graphical representation: Icons
Posted: Sat Oct 11, 2008 4:56 pm
by ^rooker
Almost each entity (gear, element, ...) will have a visual representation in form of an icon.
All icons reside in one folder, separated by naming convention.
The icons are stored as PNG, (forced) lowercase filenames like this:
Fallback:
In case, no icon file is found for an entity, an optional fallback icon must exist:
pads! my long lost friends!
Posted: Sat Oct 11, 2008 4:59 pm
by ^rooker
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: Select all
=== 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: Select all
=== 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]
the reason
Posted: Tue Nov 25, 2008 10:41 am
by ^rooker
Here's a short text describing the project and its aims:
(similar to an abstract, but bundled with motivation info)
== work in progress... ===
The status quo of creating and performing music using electronic devices is less than ideal for musicians. Often it requires a quite high level of technical- (sometimes even programmer-) skills to simply use your gear. In order to nurture the progress of developing useful physical user interfaces, it is necessary to provide an "instrument-like" machine to the people.