On 5/16/2011 9:22 PM, Ian Piumarta wrote:
Dear Josh,
Thanks for posting this!
Thought you guys would get a kick out of this YAML->WAV sequencer written in
Ruby:
https://github.com/jstrait/beats
I think this is pretty cool. (It puts us well on the way to archiving the
entire output of Kraftkwerk as ASCII files. ;-) However...
Music is one area where direct manipulation clearly wins over the command line.
So... I'm curious what you (generically) think about what's missing from this
representation, and how it might be added back, to reach the expressiveness of
(for example) a well-made MIDI track. (The largest amount of time assembling a
nice-sounding MIDI track is not inputting the basic timing and pitch/instrument
information but rather in tweaking the velocities, expression, etc., to make it
sound like humans are performing.)
FWIW, in some of my own stuff before, I had converted MIDI (fairly
directly) to/from an ASCII representation. I had done a few things with
this. unlike a few other (vaguely similar) things I had seen, I didn't
really abstract over it much at all, and so the ASCII representation was
not all that far removed from the binary command-stream.
I considered the possibility of using this to create "original" music,
but not being particularly musically inclined, this never really got
much beyond being a drum-machine.
more elaborate was at one point trying to use MIDI-style audio synthesis
in a TTS (Text-To-Speech) engine, but this was nowhere near being
comprehensible (I was basically trying to use MIDI to represent the
formant-control data).
note that in this attempt, extended samples (via an extended sample
bank) were used, with most of these extended samples containing derived
formants and similar.
IIRC, I had at one point considering a tweak (to the synthesizer) to
allow also supporting a channel bank, such that one could use 32 or 64
channels in a track (vs 15 or so), and maybe have multiple percussive
instruments at once. never got to this though.
likewise for allowing customizable (per-track) sample-banks. so that
arbitrary sound effects could be used in addition to any standard
samples (currently, there is a compromise, but it involves registering
sounds with the synthesizer via API calls, and these samples are
"global" rather than track-specific).
as-is, in my case, my MIDI synthesizer, main mixer, and TTS engine,
ended up remaining as separate components (each doing different things).
so: MIDI manages music; TTS manages speech synthesis; and the mixer
manages assigning audio-streams to point-sources (and accounting for
spatial location/velocity and doing doppler-shifting and so on). this
is, vs, say, some sort of unified super-mixer...
and, meaning, say, one would presently need to playback multiple MIDI
streams if they want instruments in different spatial locations (but,
nothing near this elaborate is presently done, me mostly using MIDI for
unattenuated background music and similar in a 3D engine).
yeah, I wrote pretty much all my own code here, as I guess I am funny
that way (well, and want to keep full legal control over my code, which
generally means staying clear of GPL and similar).
I'm also curious what you (generically) think could/should be added to this to
make a full-blown sequencing language, capable of representing (e.g.) anything
that can be programmed/manipulated graphically in something like Ableton Live.
I've always had a slightly frustrating experience with Ableton (and Garbage
Band, etc.) feeling that the semantic content of an assembled track is a lot
less than the amount of manipulation required to achieve the final result: copy
and paste is a (very) poor substitute for subroutines! On the other hand, I
have no idea if a written representation could be much more (or even anything
like) as concise. Maybe a combination of the two is needed?
FWIW, it's worth following the link to the author's other projects. Degrafa,
in particular, is very interesting.
can't say... little personal experience here...
some of my efforts (such as the TTS experience) did involve "printing"
the textually-serialized ASCII representation, which was generally
handled in C code (IIRC, largely by the usual combination of "while()"
loops and "switch()" blocks...).
a bit lacking though is the inability to produce multiple independent
streams and have them be combined by the synthesizer just prior to (or
during) playback (as is, it would require using the API to convert them
all into binary globs, and then use other calls to merge them all into a
single track, which would then be played).
granted, the above may not matter as much in musical settings, since
then it is more a matter of composition, rather than needing real-time
control over the output.
but, as-is, music is still not really my area...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
