View Issue Details

IDProjectCategoryView StatusLast Update
0002977ardourbugspublic2010-08-28 16:52
Reporteroofus Assigned To 
Status acknowledgedResolutionopen 
PlatformDell D830 core2duo T9300 2.5GHzOSMandrivaOS Version2009.1
Target Version3.X 
Summary0002977: Trimming the end of a region, involved in a multiple drop in record, reveals material incorrectly.
DescriptionTrimming the end of a region, involved in a multiple drop in record, reveals material incorrectly.

Record arm a track. Arm the master record and press play. A region starts to record. Press the master record button to drop out of recording, but leave the transport in play. Wait a while. Drop back into record again and record a second region. Now press stop. There are now 2 regions with a space between them.

Now drag the end of the first region. The region will extend revealing more audio. The audio it reveals is in fact the contents of the second recorded region.

A region should not be allowed to be trimmed beyond its own material.
TagsNo tags attached.



2009-12-28 23:02

developer   ~0007266

Assumption is that this is a function of every record pass being recorded into the same file, regardless of how many regions are dropped in.


2010-02-14 15:58

developer   ~0007378

Further thinking. Shouldn't a multiple drop in record (to the same file) record silence into the file between drop ins. ie the resulting file should be 'audio''Silence''audio' not 'audio''audio', with the silence not present.

Any thoughts.


2010-02-25 17:11

administrator   ~0007385

the idea of the single file is as a repository of that's take's audio, not as a literal record of the gaps as well as the audio.

the idea probably needs to be revisited. the main benefit that it brings is that a single capture/take is represented by a single file and can thus be destroyed more easily than if a multi-punch take consists of N different files.

unix filesystems would allow ardour to seek in between the punches and thus create "fake" silence.


2010-02-25 22:41

developer   ~0007388

The biggest problem I see is that if this file is opened in another audio application then it would be a continuous stream of audio with an odd change part way through.

Issue History

Date Modified Username Field Change
2009-12-28 22:59 oofus New Issue
2009-12-28 23:02 oofus Note Added: 0007266
2010-02-14 15:58 oofus Note Added: 0007378
2010-02-25 17:11 paul Note Added: 0007385
2010-02-25 22:41 oofus Note Added: 0007388
2010-04-24 10:28 cth103 Category bugs => bugs2
2010-04-24 10:29 cth103 Category bugs2 => bugs
2010-07-21 15:38 cth103 cost => 0.00
2010-07-21 15:38 cth103 Target Version => 3.X
2010-08-28 16:52 cth103 Status new => acknowledged