View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001767 | ardour | bugs | public | 2007-07-14 14:09 | 2020-04-19 20:12 |
| Reporter | oofus | Assigned To | cth103 | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | Centrino 1.6GHz Laptop | OS | Linux | OS Version | Mandriva 2007 |
| Product Version | 2.0 | ||||
| Target Version | 3.0 | ||||
| Summary | 0001767: When locking to MTC, Ardour sends an 'MMC stop', thus stopping the MTC generating device ! | ||||
| Description | When 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 Reproduce | Enable MTC, from the Internal, MTC, Jack drop down menu. Enable Send MMC in the options menu. start the external device sending MTC. | ||||
| Tags | 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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 ... |
|
|
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 ! |
|
|
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? |
|
|
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 ? |
|
|
rev 8617 contains a potential fix for this. |
|
|
any feedback on this? |
|
|
Unfortunately not. Hope to re-visit this within a few weeks. |
|
|
ping oofus...? |
|
|
Hi oofus, I'll close this for now, leave a note if it's still a problem :) |
|
|
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 |
|---|---|---|---|
| 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 |
