> If I understand you correctly, in that (1) is immediate and realtime
> and (2) is not, then what I would be interested in doing is a live
> version of (2). (And it's lot more than remixing in the conventional
> sense.)
No, by one (1) LIVE I meant the audience hears it immediately (or it is
recorded to some medium immediately) and (2) REMIX means a dancer
performance accompanied by sound and/or light (without an audience but
with speakers/lights), this recording (of the SIGNALS, not the musical
output) thus being the basis for a unique kind of REMIX. You can play the
signals back and remap the sounds completely, or just make small
adjustments. The advantage of (2) (REMIX) over (3) (soundless/lightless
motion capture) is that the signals captured from a "blind/deaf" performer
are most likely to be very incoherent. You need the "feedback" from the
sound and lights to perform sensibly.
(1) (LIVE) is certainly my final aim, but it requires extreme coordination
and one must get the musical mix exactly right in advance. (2) (REMIX)
enables one to concentrate on getting the rhythm right, and then one can
fiddle with the musical elements later; it's a bit hard to ride the
control system at the same time as I dance. From what I can tell most
presentations so far fall into the REMIX/PLAYBACK category.
Live work really requires someone controlling/mixing as others dance,
but since I work alone and I'm the only one who understands my programme
this is currently out. Hopefully the next version of my software will
be understandable to others, so that I will be able to perform live too
instead of getting sore neck muscles and eyes behing this stupid screen.
(I got into dancing a few years back to cope with computer spock's neck).
---
> Fine. But then you've not answered my question. One can still regard
> the control data generated by a performance (let me rephrase: DURING a
> performance) as an abstraction which can generate (*in realtime*) one
> of an infinite number of different outcomes.
[Which question ? I was just using your thread to start a new one.]
Yes, this is exactly how one can regard the data. I would prefer to
refer to this data as performance signal data; "control data" is perhaps
better reserved for the settings of the control programme that generates
output FROM the signal data, i.e. which determines the signal-to-sense
mapping, the thing that achieves a desired performance idiom.
> (I'm thinking here of another possibility, where both the dancer and
> the musician influence the score through a control system; perhaps the
> musician performs to set up the control points for the score and the
> dancer exercises them.)
We're going to have to agree a bit more on terminology slowly. (Hopefully
my long-promised CMJ paper will help there). Expand on what you mean by
"control points". How does a dancer exercise control points ? There are
ONLY signals and filters (with settings). That's all there is:
INPUT -> FILTERS -> OUTPUT
Here are my suggestions:
input signals = "performance data"
(generated by d(r)ancers)
filter settings = "signal-to-sense algorithm"
(chosen by musical/lighting/stage composers/mixers)
In DranceWare++ the signal-to-sense algorithm is saved as a configuration
file that can be saved or loaded, which I'm sure is how most programmes
work. (G'day rowntree3d !)
Darren
*****************************************************************
Darren Kelly | | |
| \ 0 / |
DESY -MPY- (Deutsches Elektronen-Synchrotron) | * o |
Notkestr.85 | - D E S Y - |
22603 Hamburg | o * |
Germany | / O \ |
| | |
phone: +49-40-8998-4569 | |
fax: +49-40-8998-4305 <--Note change | |
e-mail: kelly@x4u2.desy.de | |
****************************************************************
Amandastr.40a, | HOME |
20357 Hamburg | zu Hause |
phone: +49-40-4322602 | The PLAYhouse |
*****************************************************************