| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Cases that need more complex sort orders (e.g. all routes, then all vcas then master) need
to take of this themselves
|
|
remote control ID and "order keys" have been removed.
|
|
and used. The controls now own their own state, rather than proxy for state in their owners.
Massive changes all over the code to accomodate this. Many things are not finished. Consider this a backup safety commit
|
|
|
|
|
|
|
|
order keys. unless the user explicitly switches to UserOrdered, Route::_remote_control_id is an unallocated pointer, and Route::remote_control_id() simply returns a value based on the relevant order_key() value. Also, change the key used in the Route::order_keys std::map<> from a string to an enum, since there is no evidence that we are benefitting from the theoretical benefit of using a string. Generally tidy up allocation of order keys so that the master and monitor busses always get a "special" MixerSort key value, based on the MMC ID for master (already defined within Ardour), and all other tracks/busses start at zero. Syncing keys between editor and mixer will leave the MixerSort key for the master and monitor bus alone, reflecting the fact that we display these in their own distinct parts of the GUI and they are not orderable like other tracks or busses within the mixer window
git-svn-id: svn://localhost/ardour2/branches/3.0@12923 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
feedback, and preserve the route graph in the state
that it was in before the feedback was introduced. The
intent being to simplify the code, reduce the number of
areas of code which must consider feedback, and fix a
few bugs.
git-svn-id: svn://localhost/ardour2/branches/3.0@10510 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
