View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010147 | ardour | bugs | public | 2026-01-31 14:49 | 2026-02-02 18:20 |
| Reporter | kamilner | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | random |
| Status | new | Resolution | open | ||
| Platform | Linux | OS | Kubuntu | OS Version | 24.04 |
| Product Version | 9.0-rc | ||||
| Summary | 0010147: Clip recording - Countdown clock inconsistent behaviour | ||||
| Description | When recording a clip intom a slot, the countdown clock often behaves inconststantly if the playhead is not at the start of the project. This is most noticeable if you record a clip into a slot and then clear the slot and record into it without returning the playhead to the begining. Typically, if you do not return the playhead to the start of the track, the countdown clock does not appear at all and recording starts immediately. Sometimes, returning the playhead to the begining results in the countdown starting at a much higher value, such as 20 or more seconds. Tested using Jack/Pipewire audio | ||||
| Steps To Reproduce | 1. Start a new project and create a MIDI track with GMSynth 2. Open Cue view, select a slot in the track and set to 4 or 8 bars 3. Arm track and slot to record and press space to start recording - Countdown clock will normally start from 4 seconds before recording 4. Record a clip for the duration until it starts playing back 5. Stop transport but do not return playhead to start 6. Clear the clip from the slot, arm to record and press play to start - Countdown is absent or truncated 7 Repeat the above but this time return the playhead to the start - countdown works, but is sometimes extended | ||||
| Tags | No tags attached. | ||||
|
|
Video showing issue: https://drive.google.com/file/d/1QUWnbSIrDGUkhRVqclJhDhCiA1ASfLt4/view?usp=sharing |
|
|
The playhead not counting in properly appears to be caused by the computation in triggerbox.cc: if (t_beats == now_beats) { t_bbt = tmap->bbt_walk (t_bbt, slot.quantization()); t_beats = tmap->quarters_at (t_bbt); t_samples = tmap->sample_at (t_beats); } This computes the future start point for recording (t_beats), but only if the playhead is bar-aligned. If the playhead is not bar aligned, the computation isn't done, which can result in t_beats only being a tiny bit past now_beats, the count-in either doesn't happen or is cut short. It is suggested to remove this test and always "walk" the playhead forward so that at least a quantisation_period of count-in is done: t_bbt = tmap->bbt_walk (t_bbt, slot.quantization()); t_beats = tmap->quarters_at (t_bbt); t_samples = tmap->sample_at (t_beats); |
|
|
The count-down being extended to large value is reliably reproduced by rewinding the playhead after the slot record-arm has been set. This appears to be because the count-in is computed in Triggerbox::arm_from_another_thread at the time the slot is record armed. So, as an example: If the playhead is at exactly bar 12, and the slot is armed (assuming a quantisation of 1 bar & 4/4 time sig): t_beats= 48, now_beats=48, which results in t_beats being "walked" to 52, 1 bar ahead. If the playhead is now rewound to the start, this, effectively, sets now_beats to zero. Thus, when the transport is started, the count-in lasts for 52 beats. |
|
|
A possible solution would be to update the t_beats in TriggerBox::non_realtime_transport_stop |
