View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003117 | ardour | bugs | public | 2010-05-09 00:38 | 2011-11-15 17:27 |
| Reporter | oofus | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Platform | Dell D830 core2duo T9300 2.5GHz | OS | Mandriva | OS Version | 2010 |
| Target Version | 3.0 | ||||
| Summary | 0003117: When set to slave to incoming MTC the transport no longer sends MMC commands even if set to do so. | ||||
| Description | When set to slave to incoming MTC the transport no longer sends MMC commands even if set to do so. It may be desirable to use the Ardour transport keys to initiate the external device going into play, but then wait for and then chase the MTC that that external device generates. | ||||
| Tags | No tags attached. | ||||
|
|
there's some kind of tricky balance here to make clear the potential disaster that will occur if there is an MMC "feedback" loop. i think that i turned this off (inadvisably, i admit) because its fairly typical in a MTC-driven scenario to have either the MTC master device or something else send MMC. if ardour sends MMC in response, it seems relatively easy to get into a situation where both "ends" start ping-ponging MMC messages back and forth. |
|
|
Would any device need to send an MMC command in response. If one device sends play does (or should) the receiving device respond by resending that play command. Feels like it shouldn't, but I could be wrong. This, though, is a different situation I think. The external device is the source of the MTC, not MMC, but I want to send an MMC play to make it start, and then chase its MTC. Before I change Ardours sync from internal to MTC this works fine (minus the chasing) ie Arodur sends an MMC play and the remote device starts playing and generating MTC. Because Arodur is still set to internal it doesn't move. Now I set Ardour to sync to MTC but I can no longer send the MMC play. I think this is separate from a potential MMC loop, which, if it was going to happen would have done so when Ardour was still set to internal. |
|
|
revisiting this issue again makes me think that the basic problem is that hitting the transport buttons doesn't connect to MMC commands directly. they initiate internal Ardour operations, like "start transport". if slaved to MTC, these turn into no-ops because we don't believe that we're in charge. sending MMC can't be directly connected to the GUI buttons, because that would mean that if you used a h/w controller that didn't send MMC, ardour wouldn't send MMC then either, since the GUI button wasn't clicked. so the sending of MMC has to be done by the common, internal backend code that is invoked from OSC, MIDI or the GUI ... but if the MMC send is done unconditionally at the start of the internal operation, before we decide "uh, no timecode" or "uh, not locked to timecode", then we run the risk of sending MMC commands when ardour's own logic indicates doing the opposite, or nothing. my guess is that moving these send-MMC calls to *just* before a check on the slave status is the right thing, but they may require information we get from the timecode master. i'll take a look. |
|
|
just another datapoint: it also occured to me to note that the mackie d8b will not send MMC commands unless it sees valid, lockable, incoming timecode. i think this is true only if it has *ever* seen timecode. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-05-09 00:38 | oofus | New Issue | |
| 2010-05-09 00:46 | paul | Note Added: 0007839 | |
| 2010-05-09 01:14 | oofus | Note Added: 0007841 | |
| 2010-05-09 19:48 | cth103 | Status | new => confirmed |
| 2010-07-21 02:35 | cth103 | cost | => 0.00 |
| 2010-07-21 02:35 | cth103 | Target Version | => 3.0-beta1 |
| 2010-12-13 17:09 | paul | Note Added: 0009613 | |
| 2010-12-13 17:32 | oofus | Relationship added | related to 0001767 |
| 2010-12-13 22:58 | paul | Note Added: 0009617 | |
| 2011-11-15 17:27 | cth103 | Target Version | 3.0-beta1 => 3.0 |
