View Issue Details

IDProjectCategoryView StatusLast Update
0003117ardourbugspublic2011-11-15 17:27
Reporteroofus Assigned To 
Status confirmedResolutionopen 
PlatformDell D830 core2duo T9300 2.5GHzOSMandrivaOS Version2010
Target Version3.0 
Summary0003117: When set to slave to incoming MTC the transport no longer sends MMC commands even if set to do so.
DescriptionWhen 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.
TagsNo tags attached.


related to 0001767 closedcth103 When locking to MTC, Ardour sends an 'MMC stop', thus stopping the MTC generating device ! 



2010-05-09 00:46

administrator   ~0007839

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.


2010-05-09 01:14

developer   ~0007841

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.


2010-12-13 17:09

administrator   ~0009613

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.


2010-12-13 22:58

administrator   ~0009617

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.

Issue History

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