dce@smsc.sony.com (David Elliott) (04/13/90)
This mostly applies to something like Thunder, but with MIDI software
chaining becoming easier to do, it may be applicable to more
traditional controllers.
In general, MIDI controllers are stateless. When a message is sent,
the current state of the system is ignored. Key down always generates
NOTE ON and key up always generates NOTE OFF. Even adding a MIDI
mapper does little to change this -- you can change all NOTE ON channel
3 note 54 messages to something else, but its always the same something
else.
A stateful controller would have controls that act as finite-state
machines. As a simple example, assume a keyboard key that has two
states associated with it. In the traditional model of a keyboard with
no release velocity, the state table might look something like:
down -> NOTE ON <channel> <note> <velocity>
up -> NOTE ON <channel> <note> 0
pressure -> PRESSURE <value>
With two states, one could change the key to be a toggle:
1 down -> NOTE ON <channel> <note> <velocity>
STATE = 2
2 down -> NOTE ON <channel> <note> 0
STATE = 1
While it's not something you would use every day, this type of
controller does have its uses. For example, you could use it
to play a chord and then "arpeggiate" the releases.
Now, extend this a little more so that a) each controller has multiple
states and b) controllers can send each other messages. The result
looks a heck of a lot like Apple's HyperCard (hmm, maybe I should
copyright the name HyperControl -- I just did ;-) -- object-oriented
MIDI controllers.
So tell me, Chris K, Chris M, and all of the other Thunder owners,
how much of this can Thunder already do? How much generalization
of this type is useful? Does it unneccesarily complicate things?
--
David Elliott
dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce
(408)944-4073
"Only four of us? Who escaped?"