glad to meet you all (really mean it).
>+> converting audio (voice) to midi - data
_very_ interesting approach. the sounds triggered by this data should not
be pitched (spoken voice doesn't have a steady pitch) but some other kind
of sound... maybe something more complex in timbre and pitch, something a
bit more 'noisy' (but music...).
but what shall we do with the www audience... i don't think general MIDI (a
standard set of sounds) will be enough.
>[maybe a text-to-speech - software could be used to make the text audible
>- mixed with the 'speech melody' provided by the sampler, this could
>become an interesting 'virtual actors voice']
but this would be a [sorry Mon] 'fake' voice, since it wouldn't be
triggered by the real actor on the other side but by the stage-manager or
somebody else on each stage. and the voices speech software provides still
sound quite 'robotic'.
>+> the actors data /oudeis-protocol
>the (virtual) actors data (=vad) includes:
...
>12 bit: midivox data
what would each of this bits contain?
>task IV: gathering choros -data
>--------------------------------------------------------------------
>choros - data comes either
>- as single event, from one client; the due to a shockwave - limitation,
>this data is sent with method 'get'; (shockwave cant post); choros data
>ist delivered as search argument.
>- as 'choros update', extracted from other servers vad. could be written
>directly to a file (vad is probably handled on the same cpu...)
>
>all incoming data should be stored and ordered by timestamp (encoded in
>choros - data).
>
>the same task can manage the 'actual choros - value' - update; (simply
>sends his own client - data to all other servers..)
the actual data needed for the choros' score generation is each client's
click location and his computer's adress (i.e. 'ppp17.ad.net.ar').
(will this information be available?)
the score's variables are as follows:
data range source
_______________ _______________ _________________________________
moment 0" - stas. dur. horizontal location of the click.
moment fraction (1) ppp17.ad.net.ar -> 'adnetar'(2)
duration 1" ... ??? each song has its own duration.
song # 0 ... 40 vertical location of the click.
loudness .25 ... .90 more songs = less volume(3)
stereo loc. -10 ... +10 ppp17.ad.net.ar -> 'ar'(2)(4).
'true' stage(5) 0 ... 7? ppp17.ad.net.ar -> 'adnet'(2).
notes:
(1) this fraction will be added to the moment so that a steady rhythm is
avoided.
(2) a function will transform this text string into a number.
(3) each song's loudness will be calculated just after 'freezing' the
score, before performing it. the program will mantain the balance (more
songs = less volume) for each section of the stasima. sections will be
dynamically calculated from the moments.
(4) if the adress is 'global' (no country) the 'true'(5) song will come
from the center on all stages (no 'RealAudio' songs).
(5) each song is performed in high quality (16 bits / 44100 kHz) only in
one of the stages. on the rest it will be processed to sound 'RealAudish'.
this processing will be previously done.
regarding sound generation:
i think the best way to generate the sounds for the performance will be to
have them recorded on a sampler module (one for each stage) and triggered
via MIDI. each sampler should have one 'multisound' for each stasima (6 in
total). each 'multisound' should have the 40 songs in 'true' and 'RA'
versions (total 80).
parodus/exodus music (before and after the performance) will be
pre-recorded on a CD or DAT for playback (no interactivity in there).
the 'sturm' (or 'net-lag storm') will be generated in real time by a
program operated by someone on each stage (the one who 'pushes the red
button'). this program will use a seventh 'multisample' on the sampler,
containing seven 'sea' sounds and seven 'modem' sounds.
(other ideas?)
>to be continued.....
:waits eagerly.
best,
santiago
music is dressed silence
mailto:jaco@overnet.com.ar
http://www.geocities.com/~yaco