
Optimizations:

- Deactivated units should be skipped in computation once their output falls
  below a certain threshold.

Features:

- Experimental support for passive controls in fsynth~ (faust~ instrument)
  objects is now available, but the problem remains how to aggregate the
  values of the different voices: sum, average, median, min, max? Right now we
  always use the maximum, since that's the only aggregate which will give
  sensible readings no matter what the aggregated values are. Maybe this
  should be configurable using some meta variable?

- Add support for polyphonic aftertouch and channel pressure messages. It
  should be possible to map these to Faust controls as well.

- Add support for specifying the value ranges in OSC controller mappings (such
  as '[osc: /path a b]') as well as mapping of xy style OSC controllers which
  emit multiple values in a single message (e.g., TouchOSC). Currently this
  requires an external tool like OSCulator to remap the OSC messages, which is
  rather inconvenient.

- Add support for erasing and editing already recorded automation data. This
  might use something like "touch mode" in DAWs, or an explicit "punch in/out"
  control. (Suggested by Julius Smith.)

Design Issues:

- Refactor the sources so that fsynth~ and fdsp~ share more code.

- Voice controls (freq, gain, gate) are currently addressed using their
  basename only (without path), and only one of these (the first one) will be
  used if different instances of a voice control exist in different subgroups.
  This is done for efficiency, but it might be useful to handle multiple
  instances of the voice controls in different subgroups. Also, we may want to
  make the basenames of the voice controls configurable. Finally, we also want
  to provide compatibility with the emerging "Faust polyphony standard" here.

- There's no special handling of coarse/fine MIDI controllers in the current
  implementation. Maybe there should be a way to map them to a single Faust
  control?

- To accommodate buggy and/or incomplete MMC implementations in sequencer
  programs, the oscseq object always assumes an SMPTE framerate of 30 when
  interpreting MMC locate commands. At present there's no way to configure the
  framerate either, so you should check that your sequencer indeed uses the
  30fps value in order to get accurate playback positions.

- Add support for syncing via Jack transport (now available in Pd through
  pd-jacktime).

- We don't distinguish between different external MIDI and OSC controllers in
  write mode right now. Maybe we should keep track of the external source that
  initiated a control change, so that the new data can still be written back
  to all other external devices. This is necessary if we want parameters to be
  kept in sync across different devices.
