$Id: TODO 3669 2011-10-04 20:28:40Z ensonic $

* run 'make todo' to get a list of todo comments from source

* when releasing do:
  * make check
  * cd po;intltool-update -M
  * make dist


* new tests
  * load songs and lookup the parts
    (e.g. bt_machine_get_pattern_by_id)
  * add test for trigger params
  * for ui tests we should have the main-loop under our control:
    * check g_main_context_set_poll_func()g_main_context_set_poll_func
    * or really *run* the main-loop (not just iterate)

* new stats
  * http://www.chris-lott.org/resources/cmetrics/cyclo-2.0.tar.gz
    mcstrip tools.c | cyclo -c | sort -k2 -n

* quality checks
  for file in src/lib/core/*.c; do gtkdoc-depscan -v --book gstreamer-0.10:0.10.8 $file; done
  
* check translation markup
  podebug --rewrite=xxx buzztard.pot aa.po
  LC_ALL=aa ./buzztard-edit
  - this creates a translation with all strings wrapped by 'xxx' (Help -> xxxHelpxxx)
  - it is easy to see what is not marked for translation  

* sparse
  make CC=cgcc


* design issues
  * sim syn uses a string property for notes
    * these cannot be interpolated, we could use a uint like buzz or an enum

* controller api
  * allow to modify interpolation control sequence inplace (scale time or value range)
    - we need a gst_interpolation_control_foreach(cs, callback, user_data)
    - the callback will be called for each controlpoint and can change the
      timestamp and/or value
    - need a way to do it without exposing GstControlPoint internals
      - void callback(GstClockTime *timestamp, GValue *value, gpointer user_data);
  * or have a BtPatternControlSource
    - then we never need to update the timeline controller
    - the individual instances should be relative lightweight and use a central
      controller for some global state
      - we want to pre-cache the tracks for each machine to speed up finding the
        patterns that apply at a given time
    
* special patterns
  - break works as in breaking patterns
  - mute, solo, bypass don't work at all
    - the mute-pattern wold need to control the mute-parameter of a machines
      output-volume (input-volume for master)
    - solo would be interpreted as mute on all other generators
    - bypass would need a (controlable) gobject property
    - break would need to be able to undo mute, solo, bypass
  - for now we would need to handle the special patterns in bt_sequence_repair_global_damage_entry
  - we could see if we can make BtMachine::state controlable
    - we would need a pad-probe to call gst_object_sync()
    - break would set the BtMachine::state=NORMAL
    - we need to avoid setting the song to unsaved when controlling BtMachine::state
    - in sequence.c we need to do handle intern_damage (like global_damage) and we need
      BtMachine::bt_machine_intern_controller_change_value()

* undo/redo/journaling
  - links
    http://www.buzztard.org/index.php/Undo,_redo
    http://www.buzztard.org/index.php/Song_autosaving
  - we do that on the ui level (also the journalling and the replay of it)
  - singleton journal object
    - each undo/redo capabale object registeres with its name there
    - on replay we can take the prefix og the entry and dispatch
    - on journalling we can probably add the prefix
    - it is a stack of journal entries
  - pending parts that need undo/redo
    - machine view
      - machine/wire parameters
    - wavetable view
    - info view

* CPU load per machine
  - as we alway plug the tee-elements on each machine and each wire starts with
    a queue we could do CPU load per thread
    - sources start their own thread
    - effects and the sink live in the thread of one of the incomming wires
    - a hackish way would be to run a pad_probe before the machine and
      send a message to the bus with the thread-id<->machine association
  - ideally we show it on the machine view
    - bar under machine name?
    - extra dialog from tools menu?
    - enable/disable from the view menu

* Allow disabling level-meters
  - we could iterator over machine, check which levels are activated and
    set the 'message' property true/false
  - this could be api on song/setup
  - the recorder would use it for extra speed
  - on slow platforms we could offer that in the UI (where)
    - the view menu?

* eventually merge machine-rename dialog with machine properties
* improve recording dialogs
  - either integrate the progress bar into the recording settings
    - gray out the dialog or progress-bar area depending on phase
  - or use a notebook with hidden pages
    - switch to 2nd page for rendering

