MantisBT - ISSUES

0002633: Timestamp not recognized when importing audio

tmennola <tmennola@example.com> — 2010-03-09T20:21:44-0800

When I try to import an existing audio file into a session, its timestamp is not correctly recognized when the imported file is placed in the session. Steps to reproduce:
1. Create a session and record some audio. Start the recording somewhere else than at the beginning of the session.
2. Export the recorded audio region. Make sure to set export format to BWF.
3. Close the session and create a new one.
4. Import the exported file into the new session. Select "use file timestamp" in the Insert: selection box.

The desired result would be that the imported file appears at the location determined by the timestamp.

However, what happens is that the file appears at the beginning of the session, as if there had been no timestamp in the file. Also, when the imported region appears in the Regions list, its start position is given as 001|01|0000, regardless of what the original timestamp was. I have tried both "to selected tracks" and "as new tracks" in the Add files: selection box. I have also tried launching the import dialog in various ways (Session->Import, right-click on a track, right-click on the Region list), but the outcome is always the same.

The correct timestamp is however shown in the Timestamp: field of the Add existing media dialog, so I do not believe there is anything wrong with the file that I try to import. I have also checked the file with sndfile-info -b, and there seems to be correctly formed broadcast information present. The timestamp shown by sndfile-info is correct and matches with the timestamp shown in the dialog box in ardour.

0003043: ardour crashes on startup after entering session name

ralf <ralf@example.com> — 2010-03-08T12:47:10-0800

Macbook Pro intel,
Snow Leopard,
Ardour 2.8.7
Jack 0.85
Mbox 2 Pro Firewire interface with digidesign core audio drivers installed,
no Pro Tools on the system,

It's a new computer and pretty much fresh installation. Ardour just won't start up, with or without Jack running. I didn't get it to run on my system so far.

in addition it gives me a second error message : "core midi quit unexpectedly while using the directio plugin" and "required software extensions are missing" with a link to the PACE webpage, even though i never had any of their software installed.

0003042: limits.conf warnings inconsistent

Hollunder <Hollunder@example.com> — 2010-03-07T05:59:36-0800

There are two ways to warn the user about his limits.conf settings, a popup (gtk2_ardour/ardour_ui.cc) and stdout.

The popup appears if memlock is set to anything lower than 3/4 of the available memory.
stdout apparently warns whenever limits.conf is set to anything but unlimited, even if the number specified in limits.conf is equal to the total available memory.
It seems to simply check for 'unlimited' but I don't know where this code resides.

I think this should be consistent with the popup, whatever the correct figure might be.

0002503: ardour crashes with allocation error when starting up to load an existing project (i18n related?)

sobukus <sobukus@example.com> — 2010-03-06T09:38:42-0800

It does not depend on type of project apparently...
I created a new project with just a stereo master bus, closed ardour, then:

ardour2 ~/test-project/

This sometimes works, but often ardour crashes with this:

(process:26733): GLib-ERROR (recursed) **: gmem.c:156: failed to allocate 2032 bytes

The byte count can differ and also sometimes the error appears as (unhandled) Std::BadAlloc exception.
The machine is not really out of memory, so this is confusing. There's 1G of RAM and also 2G of swap... overcommit in kernel not being disabled.
About 200M physical RAM are used for stuff other than ardour/jackd.

Interestingly, a workaround seems to be to disable internationalization: When I run

LANG=C ardour2 ~/test-project/

I was yet unable to reproduce the crash. So, it may even be some gtk bug.
My system is a sort of custom x86-64 GNU/Linux pure 64 bit install with gcc-4.3.2, glibc 2.9, gtk+2.14.5 and glib 2.18.3.
I am attaching console output and backtrace from gdb... perhaps some wise ardour dev folks can derive the cause from that.

0002912: 2.8.4 crash when started with 'export LANG=en_US.UTF-8'

nowhiskey <nowhiskey@example.com> — 2010-03-05T14:06:38-0800

2.8.4 as well as Revision 6090.

-in terminal type 'export LANG=en_US.UTF-8'
-start ardour from the same terminal
-add a 4-band-parm-eq (by fons) to the master channel pre-fader redirect
-left-double-click on a plugin name in order to open the plugin ui
-crash

i am using ardour for years now with the LANG=en_US.UTF-8 prefix withut this problem. if i start ardour in german language, which is a default for this machine, the crash does not happen.

attached is the backtrace...no idea if it is useful or not.

cheers,
doc

0002497: crash after export

nowhiskey <nowhiskey@example.com> — 2010-03-05T07:18:08-0800

ongoing@4333

-start jackd with -Xseq option
'jackd -v -p1024 -t5000 -dalsa -r44100 -p1024 -n4 -D -Chw:0 -Phw:0 -s -Xseq '
-create new session
-with range tool, make one range. no need to import any audio, just do it by dragging the mouse in the master track area.
-now go ->session->export->export selection to audio file
-do the default export
-everything good
-as long as i stay in this session, everything will work and i can do an export more times
-now close the session
-open the same, or create another session
- do the same steps - creating the range and exporting the selection, ardour will crash
-every next time i try to export now with this session, or if i open/create another session, ardour will crash, until i do a reboot.
-after the reboot in the first session i do, everything will work, but from the second session i open after the reboot, every next session will crash after export.

in the moment when crash happens, jackd 'stops working' and the terminal shows:

load = 100.0000 max usecs: 706800.000, spare = 0.000
freewheeling stopped, waiting for thread
freewheel came to an end, naturally
freewheel thread has returned
client event poll on 14 for ardour starts at 659334715
back from client event poll after 431 usecs

when i stop ardour, jackd still is not continuing to work and nothing happens in the console.
'ps ax' is showing as jackd is still running,
if i now try to start ardour, it will not start, but 'ps ax' will show it running too.

attached is the backtrace i got out of this.

cheers,
doc

0002386: Track sizing handles should show a 'sizing vertically' mouse cursor

colinf <colinf@example.com> — 2010-03-04T13:24:04-0800

It'd make it more obvious what the track sizing handles are for if the mouse cursor changed when moved over them.

I guess this isn't difficult: when I get a spare moment I'll see if I can't work out how to do it...

0003040: Would be usefull if, when resizing the strip silence window, the waveform resized with the window.

oofus <oofus@example.com> — 2010-03-04T07:03:40-0800

Would be usefull if, when resizing the strip silence window, the waveform resized with the window.

0003041: Would be useful and faster if the silence indication on the strip silence waveform changed as the parameters were changed

oofus <oofus@example.com> — 2010-02-28T12:29:52-0800

Would be useful and faster if the silence indication on the strip silence waveform changed as the parameters were changed.

0003039: Strip silence places the new regions at the incorrect point in time.

oofus <oofus@example.com> — 2010-02-28T12:26:13-0800

Strip silence places the new regions at the incorrect point in time, so far always at the beginning of the timeline.

The new regions do seem to be split correctly relative to each other but are all moved to the wrong point on the timeline.

0003038: Strip silence cannot be undone.

oofus <oofus@example.com> — 2010-02-28T12:23:13-0800

Strip silence cannot be undone.

0001930: segfault when importing a large number of WAVs (2.0-ongoing@2563)

gellyfish <gellyfish@example.com> — 2010-02-25T19:34:20-0800

Hi,
When importing all (312 in total) of the WAV files in a directory I get a segfault after it has done ~50 or so of them.

Backtrace follows:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47303834293984 (LWP 16069)]
0x00002b05c5996cb7 in sigc::internal::trackable_callback_list::remove_callback
() from libs/sigc++2/libsigc++2.so
(gdb) thread apply all bt

Thread 17 (Thread 1100954208 (LWP 16087)):
#0 0x00002b05c69ae836 in poll () from /lib64/libc.so.6
#1 0x00002b05c2ca1ed1 in ARDOUR::Session::midi_thread_work ()
from libs/ardour/libardour.so
#2 0x00002b05c2ca26c1 in ARDOUR::Session::_midi_thread_work ()
from libs/ardour/libardour.so
#3 0x00002b05c63c437e in start_thread () from /lib64/libpthread.so.0
#4 0x00002b05c69b753d in clone () from /lib64/libc.so.6
#5 0x0000000000000000 in ?? ()

Thread 16 (Thread 1100450400 (LWP 16086)):
#0 0x00002b05c69ae836 in poll () from /lib64/libc.so.6
#1 0x00002b05c2c863fc in ARDOUR::Session::butler_thread_work ()
from libs/ardour/libardour.so
#2 0x00002b05c2c8782f in ARDOUR::Session::_butler_thread_work ()
from libs/ardour/libardour.so
#3 0x00002b05c63c437e in start_thread () from /lib64/libpthread.so.0
#4 0x00002b05c69b753d in clone () from /lib64/libc.so.6
#5 0x0000000000000000 in ?? ()

Thread 15 (Thread 1099950400 (LWP 16085)):
#0 0x00002b05c69ae836 in poll () from /lib64/libc.so.6
#1 0x00002b05c62a92ce in jack_client_core_wait (client=Error accessing memory address 0x418fd038: No such process.
) at client.c:1342
Error accessing memory address 0x418fe098: No such process.
Segmentation fault

__

It kills jackd with a timeout when running in the debugger but doesn't without.

Let me know what other information I can provide.

0002977: Trimming the end of a region, involved in a multiple drop in record, reveals material incorrectly.

oofus <oofus@example.com> — 2010-02-25T14:41:23-0800

Trimming 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.

0002911: Ardour Window Twitches Around When Performing Mouse Clicks

Chauncellor <Chauncellor@example.com> — 2010-02-25T09:14:45-0800

I believe this was introduced a few minor versions ago (was not present in 2.7.*).

When I click my mouse to do anything from using the menu to dragging a track, the window will jump one pixel to the right, then to the left on the next clip.

I have noticed that Ardour is one or two pixels too large for my display when I unmaximize it. I cannot resize it to make it smaller, so it goes off the screen a very little bit. Perhaps this is related.

I attached a short demonstration video.

0002652: AAF / OMF support

Lcut <Lcut@example.com> — 2010-02-24T22:38:43-0800

AAF / OMF support in Ardour can't be at the moment developped because of a lack of sponsorship.
So I've decided to create this features request in order to help its development.

Why this features is so important ?

Because EDL format like AAF/OMF allow project transfers from a software to another, with the wave track data, plugins and automation parameters saved inside.
Absolutly necessary to mix a project in ardour while tracks were recorded and edited with another DAW (Cubase, Protools, Nuendo), or to transfer the soundtrack of a video project from the video sofware (Avid, FinalCut, Premiere) into Ardour in order to edit and mix it.
Like the vst support question in Ardour was a bit conflictual (vst is a crappy system, it comes from the windows world, etc...) nevertheless AAF/OMF support is an essential condition for professional audio world to be able to switch on an Ardour/Linux based system production.
Ardour is a great system, I just want to make things progress!

There was a person called John E in the forum that was ready to start coding the AAF/OMF features for Ardour if some sponsors could be found.
http://ardour.org/node/2288 [^]

So we just have to get involved and donate to see this great feature arrive !

0003037: import/export plugin presets

neitcho <neitcho@example.com> — 2010-02-24T10:08:09-0800

It would be nice to be able to import/export plugin presets from/to a separate file, for the development and distribution of good presets.

0003036: Warning message makes no sense

Pablo_F <Pablo_F@example.com> — 2010-02-23T11:22:24-0800

Ardour version: 2.8.8 (rev. 6690)

Edition point is mark.
I don't have a selected mark.

If I press delete while recording
it appears the message:
"the edit point is Selected Marker\n
but there is no selected marker."
This message doesn't make sense even if
my action doesn't make sense either.

Nothing happens apart from this .

0003035: Parts of regions between two higher regions sometimes don't play

colinf <colinf@example.com> — 2010-02-23T07:51:17-0800

I've noticed this a few times now. ASCII are is probably the best way to describe it.

Three regions on the same track, layered thus:

|--r2.1---| |--r2.2-----|
|--r1.1---------------------------------|
w x y z

Sometimes, the part of region r1.1 between x & y doesn't play, even though it should. One or more of moving or resizing r2.1 or r2.2, or splitting r1.1 at w or z will eventually cause it to become audible again.

0003034: OS X 2.8.7 | the tracks sometimes loose their alignment with their left-hand-side settings section

peimankh <peimankh@example.com> — 2010-02-19T04:47:54-0800

2.8.7 the tracks sometimes loose their alignment with their left-hand-side settings section. This happens randomly when you scroll up/down vertically.

The only way to restore is to restart the session.

Please see the picture attached.

0003033: editor; color for mute and record

rtp405 <rtp405@example.com> — 2010-02-16T08:54:21-0800

It's a blip on the radar and I understand the origins for the design.

Should physically adjacent mute and record buttons both be Red? My answer is no.

We don't look at the details of the editor while producing. Our eye scans, detects Red, we call "rolling", the band begins to play and we don't see any regions being drawn. Because the Red was for mute and not record.

In an editor where the two buttons are next to each other it's annoying. While working as the drummer for another engineer I endured his errors from this confusing design and so the issue is mildly interesting.

0002875: Ardour crashes often when dragging regions beneath another

realhangman <realhangman@example.com> — 2010-02-14T20:18:59-0800

Hi,
I'm doing heavy editing of regions. In most cases, I have about 3 stacked regions. When I split all regions and drag them beneath another, Ardour crashes very often. I'm not sure if it's the dragging or the creation of crossfades which also takes place when regions are not audible.
I cannot reproduce this with a fresh session, but I provide a backtrace attached.

0002636: MIDI editing/sequencer functionality in ardour

hg87 <hg87@example.com> — 2010-02-14T04:00:02-0800

I know that work on that part is going on on ardour 3.0, and i really like to see that feature in it.
The recent versions of that 3.0 show that this will get really great, but until now there is no final release of that things in ardour.

I don't want to talk much on that topic, but i just wanted to start an "Bug Report" with detonations when this stuff is finished.

Hopefully this is a good idea, and doesn't bother anyone.

For my part i'll detonate 50$ when this stuff is finished.

0003031: Ardour cannot start maximized

Chauncellor <Chauncellor@example.com> — 2010-02-14T00:58:22-0800

Generally, programs remember if you maximize them or not, but Ardour always starts as a window. When I'm doing a lot of work across sessions, it gets annoying having to maximize the window every time. I believe that Ardour's behavior should mimic other programs and stay maximized, or at least provide a config option.

0002324: Font scaling makes Profile->set_small_screen() less necessary

colinf <colinf@example.com> — 2010-02-12T20:23:18-0800

Now that Ardour's fonts are scaleable, it's quite possible for the whole GUI to fit and be workable on a 1024 x 768 display, without the hiding of UI elements that is done by Profile->set_small_screen().

0002950: ardour doesn't fit screen (gnome 1024*768)

rozea <rozea@example.com> — 2010-02-12T20:21:42-0800

Ardour doesn't fit screen (gnome 1024*768)

On Gnome a matter of of 1- 3 centimeters.

(On KDE it's a matter of millimeters. On fluxbox it's OK.)