View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004253 | ardour | bugs | public | 2011-08-08 20:17 | 2020-04-19 20:15 |
| Reporter | royvegard | Assigned To | paul | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Target Version | 3.0 | ||||
| Summary | 0004253: Monitor bus does not appear as destination | ||||
| Description | The monitor bus does not appear as a destination in the connection matrices. It looks like the only way to connect to the monitor bus is with the "Tracks and Busses" window. | ||||
| Tags | No tags attached. | ||||
|
|
The design of the monitor bus is such that the user isn't supposed to connect anything to it. Would be useful to understand what your requirements might be. |
|
|
One might want to set up an effect bus with confidence-building reverb for a vocalist during recording. Hardware is still used as dry, zero-latency monitor. In this situation the delay in the reverb effect is not a big problem. The most appropriate place to route this effect bus would be to the monitor bus. Another use case could be talk back routed to the monitor bus. Routing to the monitor bus can be done with the "Tracks and Busses" window (and of course with a generic router like Patchage), so my requirement is met as it is now. I just thought that the monitor bus not appearing seemed like a bug. Maybe you could revisit the design, keeping in mind that you really can't prevent the user from routing to the monitor bus. I guess this issues turns into a feature request then. |
|
2011-08-29 18:23
|
4253.patch (681 bytes)
diff --git a/gtk2_ardour/port_group.cc b/gtk2_ardour/port_group.cc
index 7523e8b..f02b065 100644
--- a/gtk2_ardour/port_group.cc
+++ b/gtk2_ardour/port_group.cc
@@ -347,12 +347,6 @@ PortGroupList::gather (ARDOUR::Session* session, ARDOUR::DataType type, bool inp
for (RouteList::const_iterator i = routes->begin(); i != routes->end(); ++i) {
- /* we never show the monitor bus inputs */
-
- if (inputs && (*i)->is_monitor()) {
- continue;
- }
-
/* keep track of IOs that we have taken bundles from,
so that we can avoid taking the same IO from both
Route::output() and the main_outs Delivery
|
|
|
Patch attached which puts the monitor bus in the connection matrix. I've no strong feelings either way about whether it should be there or not. |
|
|
* bump * I think this should be applied. |
|
|
The monitor bus is not there for "monitoring" in the sense that you're thinking of. Its intended for an engineer in a control situation to route to speakers, even if the master bus goes elsewhere. Setting up monitor mixes for performers is entirely different, and does *not* involve the monitor bus. Documentation (if we had it) would make that clear. Yes, we can't stop people connecting to the monitor bus as long as it has JACK ports for input, but that could change. |
|
|
see notes |
|
|
Issue has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-08-08 20:17 | royvegard | New Issue | |
| 2011-08-08 20:34 | oofus | Note Added: 0011268 | |
| 2011-08-08 21:45 | royvegard | Note Added: 0011269 | |
| 2011-08-08 22:01 | oofus | Note Edited: 0011268 | |
| 2011-08-08 22:41 | cth103 | cost | => 0.00 |
| 2011-08-08 22:41 | cth103 | Target Version | => 3.0-beta1 |
| 2011-08-29 18:23 | cth103 | File Added: 4253.patch | |
| 2011-08-29 18:24 | cth103 | Note Added: 0011414 | |
| 2011-11-15 15:09 | cth103 | Target Version | 3.0-beta1 => 3.0 |
| 2011-12-01 17:24 | royvegard | Note Added: 0012253 | |
| 2012-10-17 22:46 | paul | Note Added: 0014089 | |
| 2012-10-18 13:23 | paul | Note Added: 0014092 | |
| 2012-10-18 13:23 | paul | Status | new => resolved |
| 2012-10-18 13:23 | paul | Resolution | open => no change required |
| 2012-10-18 13:23 | paul | Assigned To | => paul |
| 2020-04-19 20:15 | system | Note Added: 0022707 | |
| 2020-04-19 20:15 | system | Status | resolved => closed |
