MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002977ardourbugspublic2009-12-28 14:592010-08-28 09:52
Reporteroofus 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformDell D830 core2duo T9300 2.5GHzOSMandrivaOS Version2009.1
Product Version 
Target Version3.XFixed in Version 
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.
Attached Files

- Relationships

-  Notes
(0007266)
oofus (developer)
2009-12-28 15:02

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.
(0007378)
oofus (developer)
2010-02-14 07:58

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.
(0007385)
paul (administrator)
2010-02-25 09:11

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.
(0007388)
oofus (developer)
2010-02-25 14:41

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 14:59 oofus New Issue
2009-12-28 15:02 oofus Note Added: 0007266
2010-02-14 07:58 oofus Note Added: 0007378
2010-02-25 09:11 paul Note Added: 0007385
2010-02-25 14:41 oofus Note Added: 0007388
2010-04-24 03:28 cth103 Category bugs => bugs2
2010-04-24 03:29 cth103 Category bugs2 => bugs
2010-07-21 08:38 cth103 cost => 0.00
2010-07-21 08:38 cth103 Target Version => 3.X
2010-08-28 09:52 cth103 Status new => acknowledged


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker