View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004943 | ardour | bugs | public | 2012-06-22 23:14 | 2013-09-28 10:08 |
| Reporter | JaaxxOne | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Target Version | 3.X | ||||
| Summary | 0004943: Hidden Mixer strips remain bound to control surface in Mackie mode and Generic Midi | ||||
| Description | Just as in description. Hidden tracks/strips remain bound to control surface strips and respond to the control surface just as if they were not hidden. This behavior appears the same with both Generic Midi devices and Mackie devices. Tested here with Korg NanoKontrol, BCF2000. | ||||
| Tags | No tags attached. | ||||
|
|
This is not likely to get fixed before 3.0. Hiding doesn't obviously have any clear implications for external surface control. Hiding/showing tracks does not change the remote control IDs used to bind MIDI controllers to tracks. Even more clearly, if you look at protocols like Mackie Control Protocol, there is simply no notion of hiding being a part of the design of the protocol. We can do that, perhaps, post-3.0, but the precise semantics will need to be thought about quite carefully and, i suspect, for quite a long time. |
|
|
I see your point and in that context, perhaps I should have filed this as a feature. Maybe I'm nuts, but I seem to remember that being the default behavior with the Mackie implementation in A2 (or was it pre beta A3?) It used to be that hiding a track simply bumped all the track assignments to the left. I found it useful when working with large multi-track templates early on in a project when all the tracks weren't populated, but I wanted to preserve the layout for future captures. Conceptually, I don't see a problem with simply ignoring the remote IDs of hidden strips and reassigning bindings accordingly. Seems that hiding a strip implies that the user does not currently want/need to see/edit any parameters on that strip. One example might be several layered tracks which are in in an edit group together with all params synced. Hiding all but one strip of the group frees up screen space and makes more efficient use of the control surface at the same time. Perhaps a bind/don't bind strip attribute would work, but it seems like 99.9% of the time a user wouldn't need to see an unbound strip in the mixer gui anyway. |
|
|
paul, i wonder: when i remove a track or bus while a MCP device is in use, it vanishes on the device, and all following tracks move to the left. so there is already some sort of mechanism in place to propagate new remote control IDs at runtime. could this not be used for hiding as well? it would be really, really useful. another good usecase for dynamically re-assigned remote IDs: moving the MCP "viewport" by single channels, not by entire banks. sometimes a group of faders you need is across a bank boundary. i know protools does this, you can move either by banks or single strips... |
|
|
re: moveing the viewport by single channels: our MCP support can already do this - i do it on the SSL nucleus that i have here. i would have to take a look at how to access it. re: hiding - the code currently assumes that a remote ID is an important property of a route. changing the RID just because a route is hidden violates that assumption, which means "trouble ahead". in addition, "hidden" status is only in the GUI, which means (a) which GUI is it hidden in (b) the GUI has to drive the whole thing. it spells trouble, |
|
|
thanks for the clarification. i'll take a look at the +/- one channel thing. all i can say for now is that the obvious buttons on my qcon are not bound to this function. i'll grep through the sources for a similar command to "next-bank" etc, see what i can find. re hiding: i agree. i used to consider the surface a representation of the mixer only (in this case the solution would be straightforward: the mixer gui "hidden" status determines what the surface displays), but since i've used the standard mcp bindings, which include many editor commands, i've come to re-think my usage and see it as an editing tool as well. if you say it's conceptually hairy to have the gui initiate remote ID changes, i'm convinced for now... set to wontfix? |
|
|
suggested workaround: move hidden mixer strips to the end. yeah, a bit lame, but it will let you work more quickly, with less bank switching. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-06-22 23:14 | JaaxxOne | New Issue | |
| 2012-06-23 12:44 | cth103 | cost | => 0.00 |
| 2012-06-23 12:44 | cth103 | Target Version | => 3.0 |
| 2012-06-23 19:21 | paul | Note Added: 0013679 | |
| 2012-06-23 19:21 | paul | Target Version | 3.0 => 3.X |
| 2012-06-24 18:25 | JaaxxOne | Note Added: 0013687 | |
| 2013-09-10 21:44 | nettings | Note Added: 0015318 | |
| 2013-09-10 22:36 | paul | Note Added: 0015320 | |
| 2013-09-11 22:31 | nettings | Note Added: 0015324 | |
| 2013-09-28 10:08 | nettings | Note Added: 0015353 |
