Framework for physical Audio User Interfaces

...non-electric cooling, modding old computer chassis to fit a new ATX board, Experimental stuff.

User avatar
^rooker
Site Admin
Posts: 1481
Joined: Fri Aug 29, 2003 8:39 pm

gstreamer, anyone?

Post 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.
User avatar
^rooker
Site Admin
Posts: 1481
Joined: Fri Aug 29, 2003 8:39 pm

Graphical representation: Icons

Post 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:

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
User avatar
^rooker
Site Admin
Posts: 1481
Joined: Fri Aug 29, 2003 8:39 pm

pads! my long lost friends!

Post 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]
User avatar
^rooker
Site Admin
Posts: 1481
Joined: Fri Aug 29, 2003 8:39 pm

the reason

Post 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.
Jumping out of an airplane is not a basic instinct. Neither is breathing underwater. But put the two together and you're traveling through space!
Post Reply