View Issue Details

IDProjectCategoryView StatusLast Update
0001767ardourbugspublic2020-04-19 20:12
Reporteroofus Assigned Tocth103  
Status closedResolutionfixed 
PlatformCentrino 1.6GHz LaptopOSLinuxOS VersionMandriva 2007
Product Version2.0 
Target Version3.0 
Summary0001767: When locking to MTC, Ardour sends an 'MMC stop', thus stopping the MTC generating device !
DescriptionWhen locking to MTC and 'send MMC' is enabled, Ardour sends an 'MMC stop' and locate the moment it starts to receive MTC. This then stops the device that is generating the MTC.

So with 'send MMC' enabled it is impossible to slave to MTC.
Steps To ReproduceEnable MTC, from the Internal, MTC, Jack drop down menu.
Enable Send MMC in the options menu.
start the external device sending MTC.


related to 0003117 confirmed When set to slave to incoming MTC the transport no longer sends MMC commands even if set to do so. 



2007-07-14 14:18

developer   ~0004131

In fact it looks like Ardour sends MMC messages (when send MMC is enabled) just about every time Ardour has any vague change in transport state, even when this change has been initiated from an external device. I think ardour should only send MMC messages when the user has actively changed something within Ardour ie pressed play, pressed stop, located the playhead etc.


2007-07-17 02:47

administrator   ~0004133

excellent discovery, and a useful diagnosis. yes, i agree that if "slave to MTC" is set, then "send MMC" should probably be ignored. even more so if "use MMC" is set also.


2007-07-17 11:32

developer   ~0004140

No, don't disable it entirely, just restrict when the messages are sent to when transport keys are clicked or the playhead is re-located.
If send MMC is enabled then MMC messages should be sent.
If use MMC is enabled then MMC messages should be used.
In a closed lop system this is where getting the IDs correct is imperative, bi-directional communication is quite impressive when it works and is setup correctly.

My use case is :
A master machine that sends MTC, Ardour set to slave to MTC. I start and stop the master machine, Ardour follows.
If I press play on Ardour an MMC play message is sent to the master machine which starts playing, Ardour puts it's self into deferred play I think it is, the master machine generates MTC and Ardour then follows.
This gives me bi-directional transport control between Ardour and the master machine. I can start and stop from either.


2010-08-22 16:34

administrator   ~0008878

the problem with this is that Ardour goes to great lengths to NOT make distinctions about where an "action" originates. I.e. we don't know whether a request to start the transport came from the computer keyboard, OSC, the mouse, a MIDI binding or .... there's no way to tell at the point where we have to device whether to send the MMC message what the source was ...


2010-08-23 11:08

developer   ~0008881

OK, I think I see that, but in my example the only action taken is to press the play button which should send an MMC play command, which it does. I still think the fundamental problem here is that for some reason an MMC Stop message is generated when Ardour first receives MTC, when it is set to chase MTC. That MMC Stop isn't coming from any key press, OSC message, mouse click etc, the triggering event has been the reception of MTC !


2010-10-01 21:20

administrator   ~0009202

With current SVN, I'm seeing transmission of some MMC locates and a deferred play when Ardour locks to incoming MTC. Is this different to what you are seeing?


2011-01-04 11:41

developer   ~0009818

I'm seeing different things in different situations, but the fundamental problem still exists. Why, when Ardour is set to chase MTC, does it generate anything (MMC wise) when it starts receiving the MTC ?


2011-01-30 04:51

administrator   ~0009997

rev 8617 contains a potential fix for this.


2011-03-02 02:30

administrator   ~0010241

any feedback on this?


2011-03-02 09:19

developer   ~0010246

Unfortunately not. Hope to re-visit this within a few weeks.


2011-11-15 17:21

administrator   ~0012049

ping oofus...?


2012-06-18 23:50

administrator   ~0013581

Hi oofus, I'll close this for now, leave a note if it's still a problem :)


2020-04-19 20:12

developer   ~0021537

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.

Issue History

Date Modified Username Field Change
2007-07-14 14:09 oofus New Issue
2007-07-14 14:18 oofus Note Added: 0004131
2007-07-17 02:47 paul Note Added: 0004133
2007-07-17 11:32 oofus Note Added: 0004140
2010-05-02 18:51 cth103 Tag Attached: MTC
2010-07-22 15:44 oofus Target Version => 3.0-beta1
2010-08-22 16:34 paul Note Added: 0008878
2010-08-23 11:08 oofus Note Added: 0008881
2010-10-01 21:20 cth103 Note Added: 0009202
2010-10-01 21:36 cth103 Status new => feedback
2010-12-13 17:32 oofus Relationship added related to 0003117
2011-01-04 11:41 oofus Note Added: 0009818
2011-01-30 04:51 paul Note Added: 0009997
2011-03-02 02:30 paul Note Added: 0010241
2011-03-02 09:19 oofus Note Added: 0010246
2011-11-15 17:21 cth103 cost => 0.00
2011-11-15 17:21 cth103 Note Added: 0012049
2011-11-15 17:21 cth103 Target Version 3.0-beta1 => 3.0-beta2
2012-01-10 20:46 cth103 Target Version 3.0-beta2 => 3.0-beta3
2012-02-14 17:20 paul Target Version 3.0-beta3 => 3.0 beta4
2012-05-23 15:09 cth103 Target Version 3.0 beta4 => 3.0
2012-06-18 23:50 cth103 Note Added: 0013581
2012-06-18 23:50 cth103 Status feedback => resolved
2012-06-18 23:50 cth103 Resolution open => fixed
2012-06-18 23:50 cth103 Assigned To => cth103
2020-04-19 20:12 system Note Added: 0021537
2020-04-19 20:12 system Status resolved => closed