diff options
author | John Anderson <ardour@semiosix.com> | 2007-02-15 17:42:17 +0000 |
---|---|---|
committer | John Anderson <ardour@semiosix.com> | 2007-02-15 17:42:17 +0000 |
commit | 4daf15435b39517b4b09d0bd66060b4c55bcf078 (patch) | |
tree | 02d4d72a59bef7fa9b552f8d640b4a693ec2e953 /libs/surfaces | |
parent | 1cf6978cadcfc9a32b3ed52914d0fc80f3359e29 (diff) |
Fix two small bugs in ControlProtocolManager:
1) set_active was being called twice
2) control surface objects were deleted in drop_session, but not recreated in set_session
git-svn-id: svn://localhost/ardour2/trunk@1467 d708f5d6-7413-0410-9779-e7cbd77b26cf
Diffstat (limited to 'libs/surfaces')
-rw-r--r-- | libs/surfaces/mackie/TODO | 6 |
1 files changed, 2 insertions, 4 deletions
diff --git a/libs/surfaces/mackie/TODO b/libs/surfaces/mackie/TODO index 5164c9acda..8e7e795acd 100644 --- a/libs/surfaces/mackie/TODO +++ b/libs/surfaces/mackie/TODO @@ -2,7 +2,6 @@ where ENSURE_CORRECT_THREAD is a macro that is modelled on ENSURE_GUI_THREAD if the handler is not called in the "correct thread", it will use a pseudo-RT-safe-enough technique to get the correct thread to recall "handler" later on, and return. -* occasional hang on startup. deadlock? * finish button mapping * discuss button mapping for Ardour * concurrency for bank switching? And make sure "old" events aren't sent to "new" faders @@ -19,6 +18,7 @@ * power-cycling of surface. fd_midiport doesn't close. * remove couts * jog with transport rolling doesn't work properly +* docs in manual Later ----- @@ -28,7 +28,7 @@ Later Actual Mackie ------------- * docs claim that unit will send a host query on init. -* test Mackie surface object. Apparently led rings don't work +* test Mackie surface object. Apparently led rings don't work. Stereo busses? * timecode & 55 char displays * midi bandwidth @@ -36,8 +36,6 @@ Bugs ---- * get_state isn't called on deactivate -* close existing and load other session doesn't start control surface -* set_state is called twice from the control_manager * routes "forget" their remote_id between session save and the next session load * definitely something wrong with remote_id assignment on session create (master strip assigned 0). |