Hi all,
Dan let me know about the discussion about trackers taking place on this
list, and I thought you'd like a heads up on my recent work, as it appears
to be relevant...
The ICMC paper that Dan linked (
http://www.nashnet.co.uk/files/ICMC2011-Nash&Blackwell.pdf) is about
virtuosity and flow in the user experience of trackers, with some initial
results from my PhD studies. The final thesis also includes a significant
number of further results, and was submitted a couple of weeks ago.
(Further publications are in the works. ;) ) One of the most important
themes revolves around maintaining the feeling of "liveness" in notation
editing - this adapts a programming concept by Steve Tanimoto (1990) and
applies it to music (as explained in
[1]<
http://www.ppig.org/workshops/22nd-programme.html>).
It basically concerns to what degree domain feedback (e.g. music/sound) is
integrated in the editing of a visual notation. Sequencers resort to live
performance hardware (Level 4 liveness) to mitigate slow and cumbersome,
mouse-based GUI-based editing (Level 2 liveness). Trackers, coupled with
skilled use of the program and computer keyboard, support a faster, tighter
edit-audition cycle that supports high liveness while editing the tracker
pattern - useful for iterative working, sketching, and
learning-by-tinkering (and -by-ear). Of course, SC also boasts good
liveness, but focuses on control of processes, rather than the arrangement
of individual sounds/notes which is the focus of trackers and sequencers.
I believe bridging this process-level and note-level divide is one of the
most exciting and important challenges for furthering the role of the
computer in music at the moment. And, as this thread has already touched
on, trackers offer an opportunity to move beyond the model of an advanced
step-sequencer and introduce elements of programming, borrowing from the
idea of formulas in spreadsheets. Formulas are great because they can
extend the standard functionality of the spreadsheet, and give users
complete freedom over the complexity of code they wish to use. Formulas can
be ignored, used sparingly, or used to create very advanced, dynamic
behaviour; thus supporting a scalable learning experience. Formulas also
act as a stepping stone to macro / automation scripting, and more advanced
programming skills and activities (e.g. typing > formulas > VBA > VB/VC++;
or even tracking > formulas > scripting > supercollider).
Over the last few months, I have developed a working prototype of a formula
system for the reViSiT tracker <
http://revisit.nashnet.co.uk> [2], as a
major component of reViSiT v2.0 ("Project Manhattan"). This
image<
http://www.nashnet.co.uk/files/revisit-formula.png> [3]
shows it in action. In the background you can see reViSiT's traditional
pattern UI, which is styled on *Impulse Tracker 2*. Hitting the '='
displays the formula list for the current cell, allowing you to specify a
formula for each parameter in the cell (pitch, instrument, volume, effect,
etc.). In the example, Channel 4, Row 4 specifies the pitch a Major 3rd
(+4) above that to its left ([-1:+0]), and a random value for both volume
(0 to 64) and the effect parameter (in the example, filter cutoff
frequency; 0 to 127 [=7F in hex]). reViSiT's formulas offer a full set of
mathematical functions (sin, mod, log, exp, ...) and operators (+, -, /, *,
^, ...), as well as if-then-else statements for basic conditional clauses.
Formulas are executed at playback, so that, for example, the rnd() function
will produce a different value each listen. Trackers support repeats (whole
patterns within a song, or even sections within a pattern) such that
formulas can be used to completely rewrite the music as it plays - possibly
even changing the musical form and structure.
Here are some basic formula examples, that already work in the prototype:
"[4].pitch" - grabs the pitch from Row 4 of the current column.
"[32:0].volume" - grabs the volume from the first cell of Channel 32.
"[-1].pitch" - grabs the pitch from previous cell in the column column.
"[+1].pitch" - grabs the current pitch of the next cell in the column
(NOTE: this value could subsequently change, depending on its own formula)
".volume = [-1].volume * 0.8" - entered in consecutive rows will produce
a slowing (non-linear) volume slide down.
".effect.parameter = 112" - enter the effect parameter as a formula, to
avoid having to think in hex
Some more funky stuff:
"[rnd(0,63):rnd(0,63)]" - plucks a random cell from the pattern
"[16:[4].volume].pitch" - uses the volume value of row 4 to index a pitch
from Channel 16.
".effect.type = [-1].effect.parameter > #20 ? E : F" - if the previous
effect parameter was above 32, slide pitch down, otherwise slide it up
Other stuff that will also be available in v2.0, but not yet fully-coded:
"_at_label1.pitch" - reference existing labels in the pattern (e.g.
"label1"), for use in place of cell coordinates/subscripts
"_at_array1[4].volume" - use subscripts with labels ("array1") to gain
implicit array functionality (e.g. dump constants / arrays in unused, muted
tracker channels)
"current.pitch + 1" - take whatever the currently *playing* note's pitch
is and increment it
".volume = current.repeat > 0 ? 64 : 0" - enable (unmute) note on second
repeat
"midi("9c pp vv")" - special functions for device control (in this
example, sending note on MIDI message on the instrument's current MIDI
channel [c], specified pitch [pp] and volume [vv])
"notify(####)" - special functions for process synchronisation (trigger
events in OSC, Max/MSP, Win32, etc.)
+ custom tracker effects (define preset formulae that can be specified as
a traditional tracker effect with 1 or 2 parameters
It's pretty unreal seeing the tracker pattern reconfigure itself as the
playback cursor steps through the music, and there seem so many avenues for
taking the idea further. I'd be really interested to hear what anyone
thinks of the endeavour (and my research), and will be sure to stay tuned
the list. Over the coming weeks, I'm going to be putting together a demo
video to show the idea in action, as well as updating the reViSiT site to
include details about the project. Perhaps, if there's enough interest, I
could arrange an informal discussion / tech demo for those in the
neighbourhood (London / Brighton).
All the best,
Chris Nash
[1] - Church, Nash, and Blackwell, 2010 _at_
http://www.ppig.org/workshops/22nd-programme.html
[2] - reViSiT Website _at_
http://revisit.nashnet.co.uk
[3] - reViSiT Formula Screenshot _at_
http://www.nashnet.co.uk/files/revisit-formula.png
Received on Tue Jan 03 2012 - 21:32:07 GMT
