Framework for physical Audio User Interfaces

[^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.

[^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:

Code: Select all

$classname-$instancename.png

Fallback:
In case, no icon file is found for an entity, an optional fallback icon must exist:

Code: Select all

$classname.png

[^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]

[^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.