View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003409 | ardour | bugs | public | 2010-08-23 16:57 | 2010-09-19 01:15 |
| Reporter | x42 | Assigned To | paul | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.X | ||||
| Target Version | 3.0-beta1 | ||||
| Summary | 0003409: timecode pull up/down has no effect on JACK transport | ||||
| Description | JACK transport is independent from Properties->Sync->Pull up/down timecode settings. Reproduce: 1) start qjackctl (or some other app that can display the jack-transport time) 2) start ardour3, Set it's sync to JACK and choose some Pull up/down other than "none" 3) move playhead to away from 00:00:00:00 4) Ardour's clock timecode != JACK transport timecode. | ||||
| Additional Information | One solution would be to simply not allow JACK-Transport sync if timecode pull up/down is not "none". Otherwise Ardour should at least print a warning when choosing JACK-Transport with a pull-up/down setting. FWIW: Pull-up/down has effect on MTC, Ardour's internal clock & files-import (resampling). | ||||
| Tags | No tags attached. | ||||
| related to | 0003450 | new | should not be able to change video pull up/down when synced to JACK |
|
|
i'm not sure that this is possible, since i *think* it implies that JACK transport can varispeed (i.e. run at some speed where <apparent-samples> != <actual samples> elapsed). it currently cannot do this (another reason why JACK transport really can't represent MTC correctly either). |
|
|
For exactly those reason (no JACK varispeed) I was suggesting to simply "not allow JACK-Transport sync if timecode pull up/down is not "none". (see the additional note above). |
|
|
this is mostly fixed in rev 7721 you can no longer sync to JACK if video pull up/down is non-zero. missing is a block to changing video pull up/down after setting sync source to JACK. this will have to wait till post-3.0 - I don't consider a critical issue and it requires some fairly significant infrastructure hacks to be done properly. (btw, for the future reader: the hacks need to provide a way to make an option editor ComboOption insensitive and/or providing actions for each possible pull up/down setting) |
|
|
works for me so far. Please close this bug and/or re-target the ComboOption issue to post 3.0-beta1 |
|
|
see notes. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-08-23 16:57 | x42 | New Issue | |
| 2010-08-25 16:50 | cth103 | cost | => 0.00 |
| 2010-08-25 16:50 | cth103 | Target Version | => 3.0-beta1 |
| 2010-08-30 21:44 | paul | Note Added: 0008954 | |
| 2010-08-30 22:06 | x42 | Note Added: 0008956 | |
| 2010-08-30 23:04 | paul | Status | new => assigned |
| 2010-08-30 23:04 | paul | Assigned To | => paul |
| 2010-08-31 01:51 | paul | Note Added: 0008958 | |
| 2010-08-31 01:52 | paul | Product Version | SVN 3.0 => 3.0 |
| 2010-08-31 01:53 | paul | Product Version | 3.0 => 3.X |
| 2010-08-31 01:53 | paul | Note Edited: 0008958 | |
| 2010-09-10 20:53 | x42 | Note Added: 0009023 | |
| 2010-09-13 20:04 | paul | Relationship added | related to 0003450 |
| 2010-09-13 20:04 | paul | Note Added: 0009039 | |
| 2010-09-13 20:04 | paul | Status | assigned => resolved |
| 2010-09-13 20:04 | paul | Resolution | open => fixed |
| 2010-09-19 01:15 | x42 | Status | resolved => closed |
