APPLICATION ERROR #804

Profile not found.

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.
Previous non-fatal errors occurred. Page contents follow.

MantisBT
View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9697 [ardour] bugs minor sometimes 2024-04-24 19:19 2024-04-24 19:32
Reporter: Joysn71 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour reports “disk system was not able to keep up with Ardour” when moving MIDI note or loop end marker during looping
Description: When a region is looping, and I move a MIDI note or the loop end marker, the message “disk system was not able to keep up with Ardour” is reported.
It happens quite often, but not always.
I attached a Ardour session where it happens.
I muted the tracks as it does not matter.
I can reproduce it starting with a small loop region, and while looping, move the loop end marker to increase the looping region.

Ardour logs the following message to the console when the issue happens:
underrun for player:Zyn Kick 1 1-10.1 Available samples: 0 required: 1024

During my attempts to force the issue, Ardour crashed with the following message while I was clicking into the MIDI track "Kick 1". Althouth this is not related :)
terminate called after throwing an instance of 'std::logic_error'
  what(): basic_string::_M_construct null not valid
Aborted
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028675)
Joysn71   
2024-04-24 19:32   
The Ardour session can found here: https://drive.google.com/file/d/1qHukFJuT8xsmNy5XncST0ixTeJ37UpVW/view?usp=sharing

And, as I noticed it: can it be that Ardour keeps states of removed plugins in the sessions plugin folder?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9696 [ardour] bugs crash always 2024-04-23 10:01 2024-04-24 08:34
Reporter: johne53 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: urgent OS Version: 10  
Status: new Product Version: Mixbus 9.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mixbus10 crashes when enabling / disabling Atmos
Description: Firstly, this is affecting the new MB ver10, rather than MB ver9. Also, be sure to back up your test session as the following can cause data loss...

1) Load any session which already has Immersive Panning enabled
2) Disable it for a few seconds then try to re-enable it. On my system (Windows 10) this invariably causes Mixbus to disappear from my screen
3) My About box shows me revision 10.0 and running from a Command Line gives this output when the crash occurs:-

(Mixbus:11312): glibmm-ERROR **: 08:27:00.031:
unhandled exception (type std::exception) in signal handler:
what: Required Vapor Processor not found.
Tags:
Steps To Reproduce:
Additional Information: A Mixbus user called Dingo tried (on an Intel Mac system). He couldn't reproduce the problem although enabling or disabling Immersive Panning apparently takes a long time on MacOS. So I tried leaving a much longer time between disabling and re-enabling but it doesn't help on Windows. So I ran Mixbus in a debugger this morning and the exception gets thrown at this line in LV2PluginInfo::load() :-

    try {

         [...]

         plugin.reset(new LV2Plugin(session.engine(), session, lp, session.sample_rate())); // <--- EXCEPTION THROWN HERE !!!!

         [...]

         } catch (failed_constructor& err) {
            return PluginPtr((Plugin*)0);
         }

So to me, it looks like the crash should be affecting all platforms. Or maybe (on Windows) that particular plugin can only be reset (or instantiated?) once for some reason???
System Description
Attached Files:
Notes
(0028672)
x42   
2024-04-24 02:50   
what: Required Vapor Processor not found.

Is this the official binary, or your MSVC build?
(0028673)
x42   
2024-04-24 02:53   
I cannot reproduce this on Win7 with Mixbus 10.0.11 (official binary from harrison).
(0028674)
johne53   
2024-04-24 08:34   
Hi Robin - it's the official binary (which reports itself as ver 10.0) Ordinarily I'd suggest that I update to 10.0.11 but I tried an MSVC build from the latest code and that also fails...

I've done some more tests this morning and realised that it doesn't affect all sessions. For example, I create a new session using the 'Empty' template, then I save (and close) the session after first selecting Immersive Panning and assigning a Master Output. If I then follow the instructions above, that one doesn't crash. But if I do exactly the same thing except using the 'Jazz-Backing-Band' template, that one does exhibit the crash.

And I've managed to narrow it down a bit further... the duff code is in Lilv at this line within the function 'lilv_plugin_instantiate()':-

result->lv2_handle = ld->instantiate(
    ld, sample_rate, bundle_path,
    (features) ? features : local_features); // <--- HERE !!!!

I can't find the declaration for 'features' but it seems to contain 2 x fields called 'URI' and 'data'. After disabling Immersive Panning and then re-enabling, 'data' ends up having a value of 0xcdcdcdcdcdcdcdcd (which MSVC uses to indicate that something's uninitialized). So my guess would be that disabling Immersive Panning caused 'data' to get deleted somewhere.

That's probably about as close as I can get...

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9102 [ardour] bugs crash always 2022-11-17 22:57 2024-04-23 13:27
Reporter: Zelv Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when editing MIDI region after loading it as clip
Description: After creating a MIDI region in the timeline, it is possible to load it in the clip launcher. However when trying to further edit the MIDI region, Ardour crashes.
Tags: clip, crash, MIDI region
Steps To Reproduce: 1. Create a new session
2. Add a MIDI track
3. Create a MIDI region with a few notes
4. Load the region in the clip launcher
5. Edit or add notes in the MIDI region
Additional Information:
System Description
Attached Files:
Notes
(0026911)
paul   
2022-11-20 04:43   
Just as a side note: this won't do what you want. The region in the timeline is independent of the one in the clip launcher slot.
(0026926)
Zelv   
2022-11-21 22:54   
Fair enough, I can deal with reloading the region after modifications.

I can see how that could be difficult to handle a shared region between clip and timeline. That could be a nice feature though.
(0026927)
paul   
2022-11-22 00:45   
Actually, it's not hard, and a few months ago, that was how things worked.

The potential for user confusion, however, was too great, so we changed things.
(0028671)
lievenmoors   
2024-04-23 13:27   
I'm experiencing the same issue.

Trying to edit midi regions, that are already loaded as clips, crashes ardour consistently.
This happens e.g. when you try to add a new note, or lengthen an existing note.

My version of Ardour is:
       Ardour8.6.0 (built using 8.6 and GCC version 13.2.1 20230801)
And my distro is Arch Linux.

As a side note, I would find it very convenient if "realtime" editing of clips would be possible,
and I was under the impression that it worked that way. When you import a region as a clip,
it doesn't get another name, so I assumed that it still referred to the same region.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9695 [ardour] bugs minor always 2024-04-22 14:14 2024-04-22 14:56
Reporter: Dobropicker Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Shift+S does not work on the edit screen when in internal edit mode
Description: When I am in internal edit mode (working with midi notes) the Shift+S keyboard command is not working to show/hide Summary. When I am not in internal edit mode it works fine.
Tags: Editor
Steps To Reproduce: Open project. While in edit screen press "e" for internal edit mode. press Shift+S
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0028670)
x42   
2024-04-22 14:56   
Various keyboard shortcuts are context dependent.
When using the Draw or internal Edit Tool, the "MIDI" shortcuts are used. See Menu > Window > Keyboard Shortcuts.

Shift+S splits selected notes.

One thing that does occasionally annoy me is that keyboard shortcuts that are not assigned in the "MIDI" tab should fall back to use Editor keyboard bindings. (e.g. Ctrl+I to Import)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9694 [ardour] bugs minor always 2024-04-22 09:07 2024-04-22 09:50
Reporter: fjalar Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Recording curve is not shown after combining two regions
Description: When combining two adjacent regions in a track, the recording curve is not being shown as of version 8, but covered. The whole combined region appears as a solid block. Tested with 8.2, 8.4, 8.6.
Tags: Ardour 8.0
Steps To Reproduce: Select to adjacent regions in a track, then select "combine".
Additional Information:
System Description
Attached Files: before combine.png (16,188 bytes) 2024-04-22 09:07
https://tracker.ardour.org/file_download.php?file_id=4826&type=bug
png

after combine.png (12,732 bytes) 2024-04-22 09:07
https://tracker.ardour.org/file_download.php?file_id=4827&type=bug
png

Peek 2024-04-22 11-45.webm (140,454 bytes) 2024-04-22 09:50
https://tracker.ardour.org/file_download.php?file_id=4828&type=bug
Notes
(0028668)
fjalar   
2024-04-22 09:16   
see also https://discourse.ardour.org/t/track-display-after-combining-regions/110093
(0028669)
axra   
2024-04-22 09:50   
I cannot confirm. Working in Ardour 8.6 and in Ardour 8.6.9
Cinnamon Desktop. Manjaro Linux.
Maybe a color theming issue...? I use xcolors.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2652 [ardour] features major unable to reproduce 2009-05-03 11:43 2024-04-22 08:24
Reporter: Lcut Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 3.X  
Summary: AAF / OMF support
Description: 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 !
Tags:
Steps To Reproduce:
Additional Information: I founded some stuffs in the ardour forum that can be usefull :

- an open source project to read and write OMF project : http://sourceforge.net/projects/deck2omf
- Symek's EDL2SHK.py script
Attached Files:
Notes
(0005980)
johne53   
2009-05-07 14:20   
Hi LCut. Thanks for kickstarting the sponsorship for this issue but I've got some news that might get you up & running pretty soon. Check out my web site which gives some preliminary information about my AAF plugin which is now called ArdourXchange:-

http://www.creativepost.co.uk

At the time of writing it only supports importing (not exporting) and it's only available for Indamixx - but here's some great news....

If you've never heard of Indamixx it's a complete "studio-in-a-box" aimed at pro and semi-pro musicians. It includes Ardour, along with some other great Linux audio packages which all run under a distro called Transmission 2 (which I believe is a variant of 64studio).

Currently, you can buy Indamixx complete with suitable hardware (i.e. a laptop or handheld device) starting at around $499 - but even better, you'll soon be able to buy the software only (on a USB memory stick) for under $100. In fact, I think it's even less if you don't want the memory stick!! That'll get you a working, ready-to-go studio (including AAF support) for not much more than your sponsorship amount.

I've probably jumped the gun a bit here because the 's/ware only' version is still being tested - but anyway, I hope that's of interest.
(0005986)
Lcut   
2009-05-09 17:39   
Hi John. Thanks for your answer.

It's great that an AAF plugin exists, and the Indamixx system looks like an interesting Linux-based system.

But my aim here is to sponsor an Open Source AAF/OMF patch for Ardour. I'm a semi-professional sound engineer and use Cubase and Protools software, so AAF support is'nt a problem for me. But I believe in open source software, and try my best to support Ardour as a great open source DAW.
Sorry to tell that, but even if Indamixx cost 10 bocks, then it would'nt more interest me. I want to have the choice what hardware and software to use. It's a basic principle of open source world, and I don't want to use Ardour on a propriatary system, even with AAF format support.

I know that there're a lots of work to achieve, and all of that can't be free.
That's why I open this issue.

If there are ways to open your work to the community it would be great !
(0005987)
johne53   
2009-05-10 06:48   
Well, introducing this feature to the community was the main reason for doing a deal with Indamixx. FWIW I'm treating any income generated by Indamixx as being sponsorship too. Therefore people can sponsor me the conventionsl way (i.e. making a pledge and waiting for others to join in). Or they can sponsor me by buying Indamixx.

From a developer's perspective the Indamixx connection delivers 2 important advantages:- (1) It gives users a choice and at least some kind of solution in the short term. (2) People can be using (and therefore testing) software that would otherwise just be sitting on my personal PC, waiting for enough sponsors to come forward. The end result is that people like you (who are happy to wait for the source code) should hopefully get a more stable product in reward for their patience.
(0006022)
openmediaforge   
2009-05-21 09:12   
I would recommend using the official SDK and manuals for interacting with AAF files. I know that there is some work to add this support to Blender as well and both using the same libraries would allow flawless transitions from Ardour for audio to Blender for video editing.

http://aaf.sourceforge.net/

I mean why replicate work that has already been done.
(0006027)
johne53   
2009-05-22 09:19   
Hi openmediaforge - you might have misunderstood the problem with Ardour and AAF. Ardour can already support AAF via a plugin (that I wrote) which does indeed use the AAF SDK. However, that plugin is an adaptation of something totally different that I wrote a long time ago for Windows. Therefore although it works, at present it has 3 drawbacks:-

1) It isn't open source.
2) Anyone who wants it would need to be able to build Ardour themselves.
3) Even when installed, it requires Wine (or Crossover Mac) to run.

The quest for sponsorship is to enable me (or someone else) to provide AAF support as a standard, open source feature within Ardour itself (i.e. not as a separate, closed source plugin). At the current level of sponsorship, around 300-400 sponsors would be needed to make this viable. But at the time of writing (and despite its apparent popularity) this feature has only 3 sponsors. That's what's holding us up at the moment.
(0006057)
johne53   
2009-06-08 10:22   
IMPORTANT NOTE: If anyone's interested in helping to test my plugin, I've just released a time-limited version, FREE OF CHARGE for early adopters. You can get a copy COMPLETELY FREE as long as you satisfy the following conditions:-

1) You pledge at least $50 to this feature request; AND/OR
2) You already contribute to Ardour in some other way, either financially or technically (developer / translator / tester etc); AND
3) You will not be distributing the plugin for commercial gain

Depending on when you install it, the time-limited copy will work at least until the end of July 2010. Hopefully, that'll be enough time for enough people to come forward and sponsor an open source version. There are a few limitations, described in my preceding post (mostly, you need to be able to build Ardour from source).

If you'd like a free copy, use the 'Contact' link on my web page:-

http://www.creativepost.co.uk/
(0006623)
philicordas   
2009-09-01 19:04   
Hello. I am interested in this being open source, and have pledged $50.

I would like to see OMF support too eventually, as my 'other daw' is Cubase, but first things first eh!
(0006637)
olaf   
2009-09-03 09:49   
final cut and nuendo provide xml versions of their sessions

this could also be a way to go instead of omf or aaf support

maybe its more easy?
(0007352)
Lcut   
2010-02-09 04:01   
Just to say that a guy wrote some code for .OMF support in reaper daw, and I've thought it could be interesting here, because he decided to release the plugin's source code.

- initial forum (his name is 404notfound) :

http://forum.cockos.com/showthread.php?t=24943&highlight=omf&page=4

- sources :

http://404notfound.bplaced.net/reaper/

Cheers

l_cut
(0007360)
paul   
2010-02-10 22:44   
I don't consider this work to satisfy the feature request here, but it will soon. I thought that everyone attached to this bug should be aware of stuff I've just committed (to ardour3 only at this time). This is from my post to the ardour-dev mailing list.
------------------------------------------------------------------------------

Thanks to Hannes Breul, who developed code for Reaper under a BSD-ish
license, I have just added the ability to import OMF sessions as
Ardour sessions. This needs testing and it also needs further
development. Right now, its not even very easy to run it because of
its use of the uninstalled version of libpbd ...

Caveats:

* it imports ONLY OMF2 files. OMF1 is not supported
* it will not identify audio files that Ardour cannot read (e.g.
embedded MP3 files) but no[ problematic errors result from this

Build:

cd tools/omf
make

(requirements: sqlite3, sndfile)

Run:

(ardour3 only)

LD_LIBRARY_PATH=/path/to/ardour/build/default/lib/pbd ./omftool [ -v
version ] [ -r sample rate ] [ -n session name ] OMF2_session_file

this will create an ardour session whose name will based on the omf
file name OR the -n argument. it will be created in the current
working directory.

Future:

I don't have much time to spend on this myself. The basic stuff is all
there, I've been able to load at least a couple of test OMF sessions
from other DAWs and get audio from them. Someone needs to step up and
make this puppy their own. Bug fixes/integration with waf/usability
fixes/GUI ... its all yours for the taking. I may fix trivial errors,
but I need to get back to other things now that this is basically
working.

Incidentally, this also provides a fairly good guide for how to create
an Ardour session from scratch, should anyone want to do this for
other "session" formats.
(0007364)
johne53   
2010-02-11 06:57   
On a personal level, there were never enough sponsors to tempt me to get started on this - and now I'm too busy with other projects... :-(

Having said that, wasn't there another developer (last year sometime) who wanted to get involved in OMF development? I can't remember his name just now but I'm sure I remember someone who expressed an interest.
(0008007)
calimerox   
2010-05-24 21:20   
this is a real newbie question, sorry: how can i sponsor on that issue? i just made an account on tracker, but i dont know how i can actually donate. when i click on sponsor, it shows the sum i d like to sponsor, do i have to sponsor then the same amount through the normal ardour sponsoring paypal thing? thx folks...
(0017127)
x42   
2015-08-31 17:36   
@calimerox: you pledge an amount here and pay only once the issue is resolved (usually by making a donation to the person who fixed it or to ardour.org and Paul will re-distribute, but we'll get to that later).

Then again the chances that ardour will gain OMF/AAF support are slim, see the last comment at https://community.ardour.org/node/8491 but since ardour is free-software, anyone can pick up this issue and claim the bounty.
(0020154)
arnwas   
2018-02-18 22:24   
is there reference docs for AAF/OMF anywhere? thx, Arno
(0020157)
johne53   
2018-02-19 07:34   
(Last edited: 2018-02-19 07:36)
I don't think there's anything available for OMF anywhere but AAF is still alive (though I'm not sure if it's being developed any more...) However, its previous owner (the AAF Association) changed its name about 10 years ago and is now known as AMWA (Advanced Media Workflow Association). You can contact them here and ask if they've got any documentation available:-

https://www.amwa.tv/about.shtml

A word of caution though, if you're thinking about adding AAF support to Ardour... At various times I've offered to do this work myself (for Mixbus). What's stopping it is a conflict between the AAF licensing terms and Ardour's (GPL) license. I've forgotten what the conflict is (maybe someone else can explain better...)

(0020158)
paul   
2018-02-19 13:44   
AAF relies on some technology from Microsoft that is licensed in a way that prevents its use in open source projects. There was an attempted reimplementation (it is basically "filesystem in a file" stuff) by the GNU project, but it was never really finished and wasn't fully compatible with the MS stuff that AAF relies upon.

By the way, AAF is the WORST specification I have ever read. It is the epitome of design by committee. The people involved show no signs of understanding at least half of the technology their specification relies on. When I try to imagine a less elegant specification for this purpose, I cannot.

And to repeat what is written already: there has never been any documentation available for OMF. At once time, I made a stab at using the library developed in connection with Reaper, but soon found out that it was incredibly incomplete (there are lots and lots of OMF files it cannot open). This is partially because every implementation of OMF has no specification to adhere to, and so they all differ in incompatible ways.
(0020164)
johne53   
2018-02-20 08:33   
Hi Paul - I've studied the AAF license quite extensively and I'm still not sure what the problem is. The license does state that AAF contains contributions from different parties but that each contributor grants a worldwide, compensation-free, nonexclusive license to the recipient, subject to certain requirements. AFAICT those requirements are:-

1) That you must not re-brand the AAF code as if it's your own.

2) If you modify the AAF code you must make those modifications available somehow.

3) If you incorporate the AAF code as part of some larger project, the larger project can use a different license as long as it's made clear that the AAF part is governed by its own (separate) license.

You're absolutely right about the design though!! And considering they're supposedly for multimedia use, AAF and OMF have some highly questionable limitations (e.g the fact that they don't support MIDI...)
(0020450)
martindelille   
2018-11-04 18:44   
(Last edited: 2018-11-04 18:44)
Hi,

Have you see this project? https://github.com/PixarAnimationStudios/OpenTimelineIO
It seems AAF is supported.
Wouldn't it be a good starting point for AAF import/export?

(0020451)
x42   
2018-11-04 18:58   
(Last edited: 2018-11-04 19:08)
Thanks for the heads up!

"OTIO supports clips, timing, tracks, transitions, markers, metadata, etc. but not embedded video or audio. Video and audio media are referenced externally."

Thats is kinda nice.

I'm not sure if/how we can map transitions, also python is going to be an issue (we don't yet bundle nor include a python interpreter nor allow C++11 at this point in time). But it's a whole lot saner than AAF and OMF.

(0020457)
martindelille   
2018-11-05 08:02   
I'm thinking using https://github.com/pybind/pybind11 at the beginning. Another solution would be to port the code to C++.
(0020458)
martindelille   
2018-11-05 08:04   
Good news! A C++ implementation is in progress: https://github.com/PixarAnimationStudios/OpenTimelineIO/pull/319
(0020794)
agfline   
2019-10-24 22:58   
Hi,

almost ended a C coded, FOSS implementation of AAF for a french television.
Currently running as a POC in test with ardour and some interface to build ardour sessions from AAF (thanks to ptformat and session_utils)
It's working great.

Hope to release it soon, before the end of the year (if some ardour devs are interested in integrating it as an ardour functionality ;)

Note that my library is currently only for parsing (embedded/external audio/video files, fade in/out/x, clip/track gains constant/automation, clip positions...), but not for writing AAF.

https://github.com/agfline/LibAAF
(0025185)
zamaudio   
2020-11-01 03:32   
Hi agfline, what is the status of your project? I wrote ptformat, do you need some help integrating this?
(0025275)
johne53   
2020-12-02 09:47   
Also (agfline) which OS's does your project support? AAF makes heavy usage of a Microsoft technology called COM (Component Object Model). Essentially it's a way for programmers to use a standard 'C' coding interface while also writing object oriented programs. I'm pretty sure it got ported to Mac - because many AAF apps run on both Windows and Mac. But I've no idea if it ever found its way into Linux. Are there already apps on Linux which support AAF?
(0025277)
agfline   
2020-12-03 12:08   
@zamaudio, the project was held in abeyance. It was working perfectly until some guy thought it was not enough expensive I guess... I'm currently working on other stuff, but I really don't want to give up on it (It was too much work). So I could resume the project in a few weeks / months when I have time. ptformat was already very helpful, but any help will be appreciated !

@johne53, I don't know about COM, but I know about CFB/OLE file formats, all of those appearing to be the same thing (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cfb/50708a61-81d9-49c8-ab9c-43c98a795242). CFB/OLE/COM is not that complicated, it's actually FAT32 in a file. Since I'm working on Linux, I already wrote a library for parsing CFB (libCFB) which is part of LibAAF, thus I don't see any difficulty in porting LibAAF under Windows/MacOS.
(0025278)
johne53   
2020-12-03 13:35   
@agfline wrote:-
" CFB/OLE/COM is not that complicated, it's actually FAT32 in a file. "

Interesting stuff.... the earlier OMF format was based on a similar concept from Apple, called bento. Historically though, COM (or more correctly its license) was one of the main stumbling blocks to incorporating AAF support in Ardour - but if you've found a way around that, maybe it'd be worth us taking another look? FWIW Ardour recently added VST3 support which uses the exact same principle - i.e. it uses its own-brand version of COM which (I'm assuming) doesn't need a license from Microsoft. Does your code make use of the official AAF libraries or is it all your own work?
(0025280)
agfline   
2020-12-03 17:52   
My lib only shares a few header files of the original SDK (for constant values macro definition only).

Well, what you call the COM part (I call it CFB for Compound File Binary since it is called that way in the spec) was really not the most difficult part to understand and implement (in read only, as I said). As in the FAT filesystem, you have tables (FAT and DiFAT) and sectors, that let you access to a tree structure of nodes (directories) and "files". Basically "files" represent objects, and sometimes refer to other "files" and nodes. An object can describe a sequence, a track, a clip, an effect, a media essence, etc. Finally, the most complicated part in my opinion is to interpret all this mess. The meaning of "classes" and their content, used to describe sequences, clips, essences, etc. with each time a lot of different ways to represent things, despite the standard and the AAF Edit Protocol. That is why there is so much incompatibility between softwares when it comes to the exchange of AAF files, and this is what took me the most time and effort to implement and test against many different files, from different softwares, with different export settings.

The low level Compound File Binary format spec :
https://sourceforge.net/p/aaf/code2/ci/master/tree/doc/aafcontainerspec-v1.0.1.pdf?format=raw

The data structure of FAT "files" :
https://sourceforge.net/p/aaf/code2/ci/master/tree/doc/aafstoredformatspec-v1.0.1.pdf?format=raw

The AAF Class/Object Model :
https://sourceforge.net/p/aaf/code2/ci/master/tree/doc/aafobjectspec-v1.0.1.pdf?format=raw
(0025283)
johne53   
2020-12-04 08:40   
Thanks @agfline - have you thought about posting on the Mixbus forum:- http://forum.harrisonconsoles.com/forum-1.html

Harrison Mixbus is based on Ardour and it has a long history of supporting AAF through various 3rd-party apps (one of which I wrote!!) Since version 6 it's had no internal support for AAF but I'll bet there are lots of users who'd like to see it return...
(0025284)
agfline   
2020-12-04 09:17   
I didn't know that ! You're talking about ArdourXchange is that right ? Can you tell me more about how you implemented it ? Is that based on the official SDK ? Do you have Git somewhere ?

Yes I know a bit about Mixbus, never used it though. For me the GPL aspect of Ardour is fundamental, and I would love to see free software coming into broadcast and post-production. And for that, the AAF support is absolutely essential. But any improvement to Ardour can benefit to Mixbus so there is no problem !
(0025285)
johne53   
2020-12-04 10:05   
Yes - ArdourXchange was my baby! It took a long time to get it right, so the original plan was that once I'd sold a certain number of copies I'd donate the code to Ardour. By that time however, Paul had discovered some conflict between AAF's license and GPL - so it all ended up in the skip :-(

AxC doesn't have a code repo anywhere but yes, it was based on the original AAF library. Your stuff might be more acceptable, if it doesn't rely on the AAF code + licensing. And Harrison will likely be more amenable to resurrecting it - especially if it can include some experienced devs, such as me and @zamaudio, if he's interested. Ardour had some bad experiences a few years back when it tried to implement OMF - so it's unlikely they'd want to repeat the experience with AAF.

Try posting something on the Mixbus forum and see if there's still any interest there...
(0027514)
johne53   
2023-03-26 07:50   
Hi @agfline I just remembered this thread overnight...

Did your library ever get to the stage of being released? There's been some renewed discussion about this on the Mixbus forum:-

https://forum.harrisonconsoles.com/thread-8998-post-63326.html#pid63326

That's probably a better place for you to announce your library, rather than here on Mantis- Mantis is mostly for bug reports :-(
(0027579)
wargreen   
2023-04-14 00:41   
Hi,
Another bump to the wall.
I have more and more music video to mix for bands and show with which i work usually on stage.

Sooooo.. I need to got the sound from the video edit. Sometime it's a cuts, edits... And it's lot of time for re-align all the clips.
Any news about this topic ?
I can put some € if needed. Not so much, but if it can help !
(0027580)
paul   
2023-04-14 00:54   
The core developers have no plans to do anything with this. Recently a github repository was discovered that gets some significant way toward making AAF import in Ardour possible, but the work has not been proposed as a pull request and we do not have the bandwidth to consider it.
(0027581)
paul   
2023-04-14 03:20   
This the library I referenced: https://github.com/agfline/LibAAF
(0027582)
johne53   
2023-04-14 08:02   
I just took a look at the code and AFAICT most of the files are either uncopyrighted or they're copyrighted to Robin! So I'm quite surprised that the project's been discontinued. Did it ever get to the stage of being runnable?
(0027583)
johne53   
2023-04-14 09:23   
Follow-up to my previous post...

It looks like the AAF library contains a pre-built shell script and binary for Linux:- https://github.com/agfline/LibAAF/tree/master/ardour

So not easily useable by me but maybe they'd be useful for @wargreen ?

If you follow the above link, the script and binary are in the 'bin' folder
(0027587)
agfline   
2023-04-16 12:50   
Hi,

It's been quite some time since I haven't work on libaaf. The library itself is quite working well and has been tested against multiple AAF files coming from a variety of editors. Also I repeat, libaaf is currently read only and wont be able to write AAF files.

Regarding Ardour, the implementation was left with a working POC, a standalone CLI tool that creates a valid Ardour session (including video mixdown track) based on an AAF file (https://github.com/agfline/LibAAF/blob/master/ardour/ardour_aafimport.cc). This tool was made based on https://github.com/Ardour/ardour/tree/master/session_utils files, hence the copyrights @johne53 ;)

If someone wants to implement libaaf into Ardour, I will be happy to help and to provide libaaf support. However I just can't do it on my own. I don't master Ardour's code/architecture, I'm more C than Cpp , plus I have no time to fully work on it.
(0027593)
johne53   
2023-04-17 07:00   
@agfline - please consider making an announcement on the Mixbus forum:-

https://forum.harrisonconsoles.com/thread-8998-post-63326.html#pid63326

Maybe just say that you've a Linux tool available for AAF import and you're looking for help with testing and development. The problem with posting here is that this forum (Mantis) is a bug fixers forum. It's much more likely you'll see some interest if you announce it on an actual user forum, such as Mixbus.

I'm running on Windows here but the most recent reporter (at Mixbus) mentioned that he's looking for something to run on Kubuntu so that'll surely be the best place to start.
(0027741)
johne53   
2023-06-12 13:18   
@agfline - over on the Mixbus forum, me and another user have been trying to contact you because we can't launch your importer app. Do you still have a runnable version anywhere or is it too out of date now?
(0028632)
johne53   
2024-04-04 09:47   
Lcut / calimerox et al...

Just wanted to let you know that agfline's AAF implementation is working now if you're still interested in helping with beta-testing. Unfortunately it didn't work in the official release (Ardour 8.4) but you can obtain it quite easily from the Ardour nightlies:-

https://nightly.ardour.org/

I've also started a thread on Ardour's forum where you can post your experiences and suggestions:-

https://discourse.ardour.org/t/aaf-beta-testing-suggestions-and-observations/110054

Hoping everyone's still interested after all these years... (better late than never I guess !!)
(0028641)
johne53   
2024-04-12 09:30   
It's just been announced that Ardour 8.5's been released so AAF import should be working now in the official release. Please can someone here try a few AAF imports for us? It's been working brilliantly for me but I'd love to hear if others can use it - any platform would be useful but especially the non-Windows ones.
(0028644)
Schmitty2005   
2024-04-13 23:59   
When importing AAF's that use looped or reused audio, a new .wav file is created instead and wrote to disk instead of reusing the existing wav and adding a new region to Ardour track. This caused excessive disk usage after several wav files containing the same information were created. The AAF was exported from Cubase , and the cubase song used the same audio in several spots using the Cubase Arrangment track.
(0028645)
Schmitty2005   
2024-04-14 00:00   
Worked well with Win10 to Linux AAF All in One export of STEMS
(0028649)
johne53   
2024-04-14 10:58   
Schmitty2005, I've been trying to contact agfline (Adrien) who's the main AAF developer but I think he lives in France and I've just realised that French schools are on holiday right now - so he might be taking a break somewhere with his family.

Anyway, getting back to your troublesome AAF project... do you have anywhere you could upload it so I could download it and take a look? e.g. a Google drive maybe or a Dropbox account?

It'd be great if you could upload it here or on the main Ardour forum but AFAIK neither of these sites have ever allowed that.
(0028650)
agfline   
2024-04-14 19:17   
One can have a break with his laptop ;)

From my understanding of @Schmitty2005 last post on Ardour forum, it seems that issue is coming from the extract of one essence file per region, even if multiple regions rely on same essence file, leading to a disk space overload. So I guess that what appeared to be "broken external file references" in the log, was in fact missing extracted files when the disk was full.

So we have to make the import process extracts each audio file only once and link audio regions correctly.
(0028654)
Schmitty2005   
2024-04-15 13:19   
@agfline Yes, any errors I ran into were caused by running out of disk space. As I made more free space, less regions were missing in Ardour when I tried to import again. I don't think there is a need to upload the project. The AAF import function did what it was designed to do.
(0028655)
johne53   
2024-04-15 14:14   
@Schmitty2005- if you do have somewhere where you can upload your session (maybe inside a zip file) I think it might be handy for us to have available as a test file. I looked through my own files yesterday and while I've got various Cubase exports in OMF format, I don't seem to have one in AAF format.
(0028656)
Schmitty2005   
2024-04-15 18:13   
Here is a link to an AAF export from Cubase. I used random media clips include with Cubase. It uses loops so it is similar to the AAF import that ate my drive space, but not as large:

https://drive.google.com/file/d/18T9mVUE13rUzfyBxyC4q2429vGxXYN5e/view?usp=sharing

Hopefully this helps. Let me know if you need another type of export.
(0028667)
johne53   
2024-04-22 08:24   
@Schmitty2005 - if you've still got your original AAF project (the one where you discovered nearly 2GB imports!) please could you keep it for a short while? @agfline has fixed the bug now but it might be a week or so before the fix finds its way into Ardour. I'll let you know once we've made the fix available and it'd be great if you could then re-test it for us.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9583 [ardour] bugs major always 2023-12-19 20:03 2024-04-21 17:53
Reporter: Mal Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Sticking notes with certain VST plugins
Description: Certain combinations of instruments will cause notes to stay ON.
Tags: sticking notes
Steps To Reproduce: Install Spitfire Audio Labs Frozen Strings: Cello and Soundpaint Piano - 1928 Steinway: Main Sustain TF, both are free. Press and release multiple notes at the same time.
Additional Information: With Spitfire Audio Labs Frozen Strings: Cello on one channel and Soundpaint Piano 1928 Steinway Main Sustain TF on a second channel, and using a keyboard, play multiple notes at one time, then release. Quite often one or more notes will stick ON. This problem happens in Ardour 8.2 and Mixbus 9.2 but does not happen in Mixbus 8.2. The combination Spitfire Audio Labs Frozen Strings: Cello and Sine Player Layers Full Orchestra also will cause the problem. I have tested numerous other instruments and they have all worked fine. I have uninstalled and reinstalled Mixbus and the instruments. Ardour was a new installation.
System Description Windows 11
Attached Files:
Notes
(0028664)
Mal   
2024-04-21 16:15   
Just wanted to update, I installed MB v10 yesterday and it fixed the issue and one other issue that I was having. I'm guessing that means the problem was also fixed in Ardour.
(0028666)
x42   
2024-04-21 17:53   
While I'm glad that the issue is gone, I cannot explain it.

I do not see any changes between Ardour 8.2 and Ardour 8.6 (Mixbus 10.0 is based on Ardour 8.6.2) pertaining to this.

Is this only for VST2 -- or also VST3?
Are you using the same Audio/MIDI Engine settings in Ardour and Mixbus?


The only MIDI related change is from @paul "15eae21c37 - fix failure to record MIDI notes that are already on when capture starts" - but that won't have any effect on live playback.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9693 [ardour] features minor N/A 2024-04-21 16:37 2024-04-21 17:42
Reporter: Shuffle777 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 8.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Naming output channels (Export dialog)
Description: When I have to export mono splits, I would like to be able to tell the respective name of each output channel to Ardour, instead of tediously renaming them afterwards each time I have to re-export.
Those names should be stored in the .ardour file, so that I don't have to re-enter them every time the program is closed, otherwise the feature would be pointless.
Of course, the number of names the user has to enter shall match the number of output channels (that the user provides in the top-left spinbox). And from a filesystem perspective, a check is necessary to ensure each channel name is unique.

I have attached a mock-up of what that could look like in my mind, but you are of course free to design this in a more suitable way ;-)
If you are going with my suggestion, it might be wise to also add a vertical scrollbar (which I did not draw) in case someone needs to output a lot of channels for some obscure reason. But I'll leave it to you to decide that.
Note that the suggested default names make the feature retro-compatible with the current naming scheme, which is probably a good thing...
Tags: export, export audio, feature request, GUI, improvements, multichannel, ui
Steps To Reproduce:
Additional Information:
Attached Files: 8.6_2024-04_Channel names on Export screen.png (46,391 bytes) 2024-04-21 16:37
https://tracker.ardour.org/file_download.php?file_id=4825&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9692 [ardour] features feature N/A 2024-04-21 09:18 2024-04-21 17:42
Reporter: Shuffle777 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 8.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Naming output channels (Export dialog)
Description: When I have to export mono splits, I would like to be able to tell the respective name of each output channel to Ardour, instead of tediously renaming them afterwards each time I have to re-export.
Those names should be stored in the .ardour file, so that I don't have to re-enter them every time the program is closed, otherwise the feature would be pointless.

Of course, the number of names the user has to enter shall match the number of output channels (that the user provides in the top-left spinbox). And from a filesystem perspective, a check is necessary to ensure each channel name is unique.

I have attached a mock-up of what that could look like in my mind, but you are of course free to design this another way ;-)
If you are going with my suggestion, it might be wise to also add a vertical scrollbar (which I did not draw) in case someone needs to output a lot of channels for some obscure reason.
Note that the suggested default names make the feature retro-compatible with the current naming scheme, which is probably a good thing...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0028665)
Shuffle777   
2024-04-21 16:43   
I had an error when submitting, and the attachment was dropped.

Also, sorry for duplicate 0009693...

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9691 [ardour] features feature N/A 2024-04-21 09:13 2024-04-21 09:13
Reporter: Shuffle777 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 8.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Custom naming scheme for output files (Export dialog)
Description: Having readily available checkboxes and comboboxes (session/snapshot, label, revision, etc.) to build up the output file name is quick and convenient, but also very static. I would like to be able to set it up in a more flexible way.

A common solution to this is to make variables available and let the user input a template in a textbox.

An example of variable names could be:
%n -- session name
%p -- snapshot name
%r -- revision number (still needs the current spinbox to input the value)
%s -- timespan name
%d -- date (should keep the current combobox to select the date format)
%t -- time (should keep the current combobox to select the time format)
%c -- channel name (for mono splits)
%% -- a literal percent sign

This way, the user can build a string that matches the current naming scheme, e.g. "%n labels are still entered literally %r %s %d %t", or provide their own custom template, e.g. "%n %r %d (another literal label)".

If you deem the percent sign followed by a single letter problematic for some reason, feel free to come up with another convention, I am not particularly attached to that... although it is common practice (the dollar sign is another common example)

This new feature would make the "Current (approximate) filename" feature absolutely essential, because those variables would be expanded there, providing immediate visual feedback to the user.

The only downside I see to this approach is that the list of variables has to be readily available somewhere, because users cannot be asked to (and will not) remember that. I suggest either showing it in a two-columned fashion between the "Build filename(s) from these components:" label and the (newly added) textbox for the template, OR a button that triggers a dialog where they are listed and explained (which is less convenient but much more compact on the Export dialog and allows for extended details if needed).

The user-set template should be stored in the .ardour session file to avoid setting it again every time the project is reopened.

Additionally, a default template (modifiable from the Preferences dialog, perhaps in the General > Export section?) could be stored in Ardour's 'config' file to have a default for new projects.
Tags: export, export audio, feature request, GUI, improvements, settings, ui, usability
Steps To Reproduce:
Additional Information: If you think this would be too complicated for some (or most) users, please consider adding it anyway and allow the user to choose between the 'classic' mode and this new 'advanced' mode, for example using two radio buttons.

The 'classic' mode can be emulated using the 'advanced' mode, as stated in one of my examples above, so it is possible to unify them internally ('classic' mode feeds the input of 'advanced' mode) to avoid having two parts of code doing the same thing (produce output file names). This is a win in terms of code maintenance.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9690 [ardour] bugs minor always 2024-04-15 16:50 2024-04-17 15:26
Reporter: piergi Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tempo ramp after BBT marker do not work
Description: Having a tempo ramp after a BBT marker do not work, and there are graphic inconsistencies: the tempo ruler shows the new tempo, but the measure length and the tempo button in the top bar do not change. After the second tempo marker appears another blue line, as if the two tempo were overlapping (see screenshot).
Tags:
Steps To Reproduce: Start a new session; place a BBT marker (a new tempo marker is set automatically); place a tempo marker somewhere after the BBT, with a different tempo; right-click on the tempo marker on the BBT and set to "rampp to next".
Additional Information: Ardour 8.6.0 "Kite Stories" (rev 8.6) Intel 64-bit, downloaded from ardour.org
System Description
Attached Files: image.png (151,894 bytes) 2024-04-15 16:50
https://tracker.ardour.org/file_download.php?file_id=4823&type=bug
png

Screenshot from 2024-04-17 17-17-50.png (36,590 bytes) 2024-04-17 15:24
https://tracker.ardour.org/file_download.php?file_id=4824&type=bug
png
Notes
(0028662)
piergi   
2024-04-17 15:24   
Update:
I tried adding a BBT *after* having added a tempo ramp.

1. New Tempo at bar 17 (marker 1)
2. new tempo at bar 24, set to 200 BPM
3. edit marker 1, set ramped
4. add a BBT marker at bar 17
5. the tempo map get really confused: there are extra grid lines, and —although the markers are set to 120 to 200 BPM—the tempo goes up to 0000127:0000383 BPM.
(0028663)
piergi   
2024-04-17 15:26   
point 5 above should read "the tempo goes up to circa 383 BPM"

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9673 [ardour] other minor always 2024-03-20 07:22 2024-04-16 22:51
Reporter: psr3739 Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: waf build script of patched GTK+ does not meat macOS requirements
Description: The DISABLE_VISIBILITY flag must be defined to build the patched GTK+ included in the repository, but it is not described in the wscript, so Ardour is not buildable on MacOS. I patched like below it works fine.

From c6300e0a430fe07a6d6efe78acab831245a0b390 Mon Sep 17 00:00:00 2001
From: paseri3739 <tael43@icloud.com>
Date: Tue, 5 Mar 2024 11:10:34 +0900
Subject: [PATCH] fix compiler flags in ytk and ydk on OSX (define
 DISABLE_VISIBILITY)

---
 libs/tk/ydk/wscript | 1 +
 libs/tk/ytk/wscript | 1 +
 2 files changed, 2 insertions(+)

diff --git a/libs/tk/ydk/wscript b/libs/tk/ydk/wscript
index 45e04326b3..e2eb99ee32 100644
--- a/libs/tk/ydk/wscript
+++ b/libs/tk/ydk/wscript
@@ -188,6 +188,7 @@ def build(bld):
         obj.cflags += ['-xobjective-c']
         obj.uselib += ' OSX' # -framework Cocoa -framework CoreFoundation -framework ApplicationServices
         obj.includes += ['ydk/quartz', 'ydk/quartz/gdk', 'ydk/gdk/quartz']
+ obj.defines += ['DISABLE_VISIBILITY']
         obj.export_includes += ['ydk/gdk']
         obj.export_includes += ['ydk/quartz']
     elif bld.env['build_target'] == 'mingw':
diff --git a/libs/tk/ytk/wscript b/libs/tk/ytk/wscript
index a921a79863..3701fcf02a 100644
--- a/libs/tk/ytk/wscript
+++ b/libs/tk/ytk/wscript
@@ -300,6 +300,7 @@ def build(bld):
         obj.source = libytk_sources + libytk_quartz_sources
         obj.cflags += ['-xobjective-c']
         obj.uselib += ' OSX' # -framework Cocoa -framework CoreFoundation -framework ApplicationServices
+ obj.defines += ['DISABLE_VISIBILITY']
     elif bld.env['build_target'] == 'mingw':
         obj.source = libytk_sources + libytk_win32_sources
         obj.defines += [ 'INSIDE_GTK_WIN32', 'DLL_EXPORT', 'PIC' ]
--
2.39.3 (Apple Git-145)

Tags:
Steps To Reproduce: run
CC=clang CXX=clang++ ./waf configure --arm64 --strict --ptformat --libjack=weak --optimize
Additional Information:
System Description
Attached Files: Screenshot 2024-03-21 at 7.00.13.png (691,491 bytes) 2024-03-20 22:33
https://tracker.ardour.org/file_download.php?file_id=4809&type=bug
Notes
(0028602)
x42   
2024-03-20 13:08   
What is the actual error you get?

We build Ardour on macOS just fine on various systems, not to mention the official Binaries.
(0028603)
psr3739   
2024-03-20 13:40   
../libs/tk/ydk/gdkaliasdef.c:2376:70: error: aliases are not supported on darwin
extern __typeof (gdk_draw_rgb_image) gdk_draw_rgb_image __attribute((alias("IA__gdk_draw_rgb_image"), visibility("default")));
                                                                     ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

../libs/temporal/tempo.cc:2612:11: warning: unused variable 'beats_delta' [-Wunused-variable]
                                Beats beats_delta = _meters.front().to_quarters (delta);
                                      ^
../libs/temporal/tempo.cc:3837:6: warning: variable 'cnt' set but not used [-Wunused-but-set-variable]
        int cnt = 0;
            ^
2 warnings generated.

Waf: Leaving directory `/Users/masato/Desktop/ardour/build'
Build failed
 -> task in 'libydk' failed with exit status 1 (run with -v to display more information)
 -> task in 'libydk' failed with exit status 1 (run with -v to display more information)


This error appears when not using --no-ytk build option (build GTK+ from source)

When building GTK+ from source on mac you must need --disable-visibility option in make command or define DISABLE_VISIBILITY variable in another build system like waf.
Reference also:
https://discourse.ardour.org/t/mac-library-build-gtk-2-24-23-fails/109598/4
https://gitlab.gnome.org/GNOME/gtk-osx/-/issues/20
https://developer-old.gnome.org/gtk2/stable/gtk-building.html
(0028604)
x42   
2024-03-20 18:42   
It seems this is a conflict with some system-wide installed libraries (GTK?) on your machine. Though it is unclear where this message "aliases are not supported on darwin" comes from.

With your patch the GTK symbols would be in the global namespace, which is never a good idea.
If at all, we could make this an option for some specific systems like yours.
(0028605)
x42   
2024-03-20 18:47   
I do not get this error on macOS BigSur 10.0 (Ardour nightly builder), and also not on macOS Ventura 14.4 (clang 15.0, XCode 15.3; current latest version).

Various other developers have also not reported this, so this is likely due to some library conflict on your system.
(0028606)
psr3739   
2024-03-20 22:33   
Version: Sonoma 14.3.1
zsh ~/Desktop/ardour $ uname -v
Darwin Kernel Version 23.3.0: Wed Dec 20 21:33:31 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T8112
zsh ~/Desktop/ardour $ clang --version
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: arm64-apple-darwin23.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Official Build Log:
https://nightly.ardour.org/i/A_MAC_arm64/build_log.txt

Ardour Configuration
 * Will build against private GTK dependency stack in /Users/ardour/gtk/inst : yes
 * Will use explicit linkage against libintl in /Users/ardour/gtk/inst : yes
 * Will build against private Ardour dependency stack : no
No Carbon support available for this build

Ardour Configuration of me:
 * Will build against private GTK dependency stack : no
 * Will use explicit linkage against libintl in /Users/masato/gtk/inst : yes
 * Will build against private Ardour dependency stack : no
No Carbon support available for this build

My configuration is slightly different from the official build log. I found gtk/inst/ is hard-coded in the root wscript and the log above shows official build environment have gtk/inst.
I don't have the structure because I've never build Ardour before.
I believe that the developers who have already participated in the project are using the previous builds and environment that have ~/gtk/inst/, so this error does not occur I think.
(0028659)
matt2000   
2024-04-16 22:47   
I am also experiencing this issue. I'm on Sonoma 14.4.1 and I have glib2 @2.80.0 via MacPorts.
(0028660)
x42   
2024-04-16 22:50   
We do not support building Ardour with macPorts or homebrew. You're on your own there, I'm sorry.
(0028661)
x42   
2024-04-16 22:51   
PS. I build Ardour on macOS 14.4.1 on daily basis just fine with dependencies listed at https://nightly.ardour.org/list.php#build_deps

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9211 [ardour] bugs minor always 2023-01-29 14:57 2024-04-16 13:22
Reporter: dking952012 Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: normal OS Version: 11  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Grid editor does not visually change when using triplets/tuplets
Description: When changing the grid to triplet and tuplet variations, the visual markers only reflect /4 subdivisions. For example, a 16th note triplet selection only shows straight 16ths on the grid. The cursor/marker will still snap to triplet start locations, but this does not match up visually.
Tags:
Steps To Reproduce: New session

New midi track

change grid to 1/3 or 1/6 triplets

ruler does not mark triplets correctly

can still edit notes to snap to triplet position, they just appear "off"
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0027636)
Alcorpmasta   
2023-05-03 05:40   
is duplicate of https://tracker.ardour.org/view.php?id=9316
( I dont know how to do the duplicate link )
(0027644)
Alcorpmasta   
2023-05-09 07:35   
Any way to increase criticity / priority ?
I use triplet / tuplets for all my tracks since ages.
Since this bug appeared, I now have to measure things with a junior school ruler on PC Monitor screen display to position notes .
So annoying.
(0027784)
Alcorpmasta   
2023-06-17 12:01   
Any news about this topic ?
Since bug introduction has been identified by Peder in between builds d77db816de and 23a0efc28 should be easy to fix ?
(0027881)
x42   
2023-07-09 19:49   
@paul do you recall why you changed the grid between d77db816de and 23a0efc28 ?
(0027883)
paul   
2023-07-09 21:27   
what i remember is there was too much being done in the GUI to generate the grid. that ought to be the work of TempoMap::get_grid(), not left to the GUI to interpolate and so forth.

but apparently I didn't do it right.
(0028202)
Alcorpmasta   
2023-10-14 18:52   
One major version later and still not resolved
(0028204)
paul   
2023-10-14 18:53   
It has never been our goal (nor would it ever be possible) to solve every reported bug before a major release.
(0028213)
Alcorpmasta   
2023-10-16 11:40   
Ok. Or please kindly give possibility to divide by 48 or any multiplier of 3 equal or above 48 in master Measure field
(0028658)
Alcorpmasta   
2024-04-16 07:38   
Tested yesterday . It seems resolved as of version 8.6
Thank you dev team for the hard work.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9316 [ardour] bugs minor always 2023-04-24 10:58 2024-04-16 07:37
Reporter: peder Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Grid lines for triplets and tuplets are shown as ordinary subdivisions
Description: As reported by Vudone in https://discourse.ardour.org/t/grid-lines-not-adjust-to-definition/108633 the grid lines don't change accordingly when selecting triplets or tuplets.
It worked in 7.0-31-gaaddf5f385 but not in 7.2-10-gedd68d8682 or later
Tags:
Steps To Reproduce: Select a triplet or tuplet in the Grid Mode drop-down.
The lines stick to the ordinary subdivisions, so 1/3 will look the same as 1/8 and 1/5 the same as 1/16
Additional Information:
System Description
Attached Files:
Notes
(0027630)
peder   
2023-04-28 13:53   
The problem is introduced in between d77db816de and 23a0efc28
(0027635)
Alcorpmasta   
2023-05-03 05:39   
is duplicate of https://tracker.ardour.org/view.php?id=9211
( I dont know how to do the duplicate link )
(0027643)
Alcorpmasta   
2023-05-09 07:34   
Any way to increase criticity / priority ?
I use triplet / tuplets for all my tracks since ages.
Since this bug appeared, I now have to measure things with a junior school ruler on PC Monitor screen display to position notes .
So annoying.
(0027783)
Alcorpmasta   
2023-06-17 12:01   
Any news about this topic ?
Since bug introduction has been identified by Peder in between builds d77db816de and 23a0efc28 should be easy to fix ?
(0028203)
Alcorpmasta   
2023-10-14 18:52   
One major version later and still not resolved
(0028214)
Alcorpmasta   
2023-10-16 11:41   
Ok. Or please kindly give possibility to divide by 48 or any multiplier of 3 equal or above 48 in master Measure field
(0028657)
Alcorpmasta   
2024-04-16 07:37   
Tested yesterday . It seems resolved as of version 8.6
Thank you dev team for the hard work.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9688 [ardour] bugs crash always 2024-04-13 20:29 2024-04-14 23:06
Reporter: jondbennett Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when removing monitor section
Description: I get a hard crash (application vanishes from the display) whenever I try to remove the monitor section from a session. Running Ardour from the terminal shows a segmentation fault.
Tags:
Steps To Reproduce: I simply go to the session menu->Monitor Section->Use Monitor Section
and de-select it.
Additional Information:
System Description
Attached Files: Guitar_Test_2024-04-13_161627.ardour-session-archive (8,886 bytes) 2024-04-13 20:29
https://tracker.ardour.org/file_download.php?file_id=4820&type=bug
Notes
(0028642)
x42   
2024-04-13 21:20   
It works fine here with Ardour 8.6.0 on Linux (w/ALSA backend).

If you can still reproduce this with recent Arodur 8.6, please provide a backtrace (see https://ardour.org/debugging_ardour). Thanks
(0028646)
jondbennett   
2024-04-14 02:39   
x42, when you wrote "It works fine here..." did you try and open the session archive that I provided and then deactivate the monitor section? I"m asking because I don't have 8.6.0 installed on this machine. If you can re-produce it from the file that I provided then I won't have to find a way to install 8.6.

Separately, can I install multiple versions of Ardour on the same machine?

Thank you for your help.
(0028647)
x42   
2024-04-14 03:07   
Yes, I used your session archive.

Official binaries from ardour.org can be installed in parallel to distro versions and you can also install different versions of them.
You can also try with https://nightly.ardour.org/ (demo is fine to test).
(0028648)
jondbennett   
2024-04-14 04:20   
OK, I've downloaded and run the 8.6 debug version. I am able to add and remove the monitor section with no problems. So, I don't see the bug in the 8.6 code.
Thank you for your help and patience. I really do appreciate it.
Please close the bug report.
(0028653)
x42   
2024-04-14 23:06   
It was fixed sometime between Ardour 7.5 and 8.6

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9689 [ardour] bugs crash always 2024-04-14 13:41 2024-04-14 22:39
Reporter: MyLoFy Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when deleting MIDI automation nodes
Description: see below
Tags:
Steps To Reproduce: - Create MIDI track
- Add Sustain Pedal automation (Controller 64 channel1)
- Select automation node with mouse. Click and drag needs to start inside of the MIDI region (see screencast)
- press Delete
=> Ardour crashes
Additional Information: gdb output attached
System Description
Attached Files: ardour_crash_14Apr2024.webm (524,288 bytes) 2024-04-14 13:41
https://tracker.ardour.org/file_download.php?file_id=4821&type=bug
ardour_gdb_14Apr2024.txt (164,671 bytes) 2024-04-14 13:41
https://tracker.ardour.org/file_download.php?file_id=4822&type=bug
Notes
(0028651)
x42   
2024-04-14 21:25   
==2013016==ERROR: AddressSanitizer: heap-use-after-free on address 0x603004876d80 at pc 0x7f2a4634f5ef bp 0x7ffd268b2d20 sp 0x7ffd268b2d18
READ of size 8 at 0x603004876d80 thread T0 (ArdourGUI)
    #0 0x7f2a4634f5ee in std::__cxx11::list<Evoral::ControlEvent*, std::allocator<Evoral::ControlEvent*> >::erase(std::_List_const_iterator<Evoral::ControlEvent*>) /usr/include/c++/10/bits/list.tcc:157
    0000001 0x7f2a463387a3 in Evoral::ControlList::erase(std::_List_iterator<Evoral::ControlEvent*>) ../libs/evoral/ControlList.cc:1041
    #2 0x55645e2c073b in Editor::cut_copy_points(Editing::CutCopyOp, Temporal::timepos_t const&) ../gtk2_ardour/editor_ops.cc:4844
    #3 0x55645e2bd95d in Editor::delete_() ../gtk2_ardour/editor_ops.cc:4569
    0000004 0x55645dfff1ed in sigc::bound_mem_functor0<void, Editor>::operator()() const /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
    0000005 0x55645dfe5c0d in sigc::adaptor_functor<sigc::bound_mem_functor0<void, Editor> >::operator()() const /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
    #6 0x55645dfe5c34 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, Editor>, void>::call_it(sigc::internal::slot_rep*) /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
    #7 0x7f2a455d6f47 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) (/lib/x86_64-linux-gnu/libglibmm-2.4.so.1+0x64f47)
    0000008 0x7f2a4552c0a1 in g_closure_invoke (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x140a1)
    0000009 0x7f2a4553e601  (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x26601)
    0000010 0x7f2a455446ce in g_signal_emit_valist (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2c6ce)
    0000011 0x7f2a45544c3e in g_signal_emit (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2cc3e)
    0000012 0x7f2a445abd17 in _gtk_action_emit_activate ../libs/tk/ytk/gtkaction.c:795
    0000013 0x7f2a445abe06 in IA__gtk_action_activate ../libs/tk/ytk/gtkaction.c:826
    0000014 0x7f2a44dd18f5 in Gtk::Action::activate() ../libs/tk/ytkmm/action.cc:443
    #15 0x7f2a45784c2d in Gtkmm2ext::Bindings::activate(Gtkmm2ext::KeyboardKey, Gtkmm2ext::Bindings::Operation) ../libs/gtkmm2ext/bindings.cc:511
    0000016 0x55645dc5ea4e in ARDOUR_UI::key_press_focus_accelerator_handler(Gtk::Window&, _GdkEventKey*, Gtkmm2ext::Bindings*) ../gtk2_ardour/ardour_ui_keys.cc:219
    #17 0x55645dc5d110 in ARDOUR_UI::key_event_handler(_GdkEventKey*, Gtk::Window*) ../gtk2_ardour/ardour_ui_keys.cc:103
    0000018 0x55645db79684 in sigc::bound_mem_functor2<bool, ARDOUR_UI, _GdkEventKey*, Gtk::Window*>::operator()(_GdkEventKey* const&, Gtk::Window* const&) const /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:2143
    0000019 0x55645db6aaf8 in sigc::adaptor_functor<sigc::bound_mem_functor2<bool, ARDOUR_UI, _GdkEventKey*, Gtk::Window*> >::deduce_result_type<_GdkEventKey* const&, Gtk::Window*&, void, void, void, void, void>::type sigc::adaptor_functor<sigc::bound_mem_functor2<bool, ARDOUR_UI, _GdkEventKey*, Gtk::Window*> >::operator()<_GdkEventKey* const&, Gtk::Window*&>(_GdkEventKey* const&, Gtk::Window*&) const /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:108
    0000020 0x55645db572ee in sigc::bind_functor<-1, sigc::bound_mem_functor2<bool, ARDOUR_UI, _GdkEventKey*, Gtk::Window*>, Gtk::Window*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::deduce_result_type<_GdkEventKey* const&, void, void, void, void, void, void>::type sigc::bind_functor<-1, sigc::bound_mem_functor2<bool, ARDOUR_UI, _GdkEventKey*, Gtk::Window*>, Gtk::Window*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::operator()<_GdkEventKey* const&>(_GdkEventKey* const&) /usr/include/sigc++-2.0/sigc++/adaptors/bind.h:1136
    0000021 0x55645db4214c in sigc::internal::slot_call1<sigc::bind_functor<-1, sigc::bound_mem_functor2<bool, ARDOUR_UI, _GdkEventKey*, Gtk::Window*>, Gtk::Window*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, bool, _GdkEventKey*>::call_it(sigc::internal::slot_rep*, _GdkEventKey* const&) /usr/include/sigc++-2.0/sigc++/functors/slot.h:170
    0000022 0x7f2a44fd3dee in sigc::slot1<bool, _GdkEventKey*>::operator()(_GdkEventKey* const&) const /usr/include/sigc++-2.0/sigc++/functors/slot.h:665
    0000023 0x7f2a44fb6313 in Widget_signal_key_press_event_callback ../libs/tk/ytkmm/widget.cc:1493
    #24 0x7f2a446a78b7 in _gtk_marshal_BOOLEAN__BOXED ../libs/tk/ytk/gtkmarshalers.c:84
    0000025 0x7f2a4552c0a1 in g_closure_invoke (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x140a1)
    0000026 0x7f2a4553e412  (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x26412)
    0000027 0x7f2a45544258 in g_signal_emit_valist (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2c258)
    0000028 0x7f2a45544c3e in g_signal_emit (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2cc3e)
    0000029 0x7f2a44820215 in gtk_widget_event_internal ../libs/tk/ytk/gtkwidget.c:5010
    0000030 0x7f2a4481fd3b in IA__gtk_widget_event ../libs/tk/ytk/gtkwidget.c:4807
    0000031 0x7f2a446a58da in IA__gtk_propagate_event ../libs/tk/ytk/gtkmain.c:2420
    0000032 0x7f2a446a43c4 in IA__gtk_main_do_event ../libs/tk/ytk/gtkmain.c:1641
    0000033 0x7f2a4621eb90 in gdk_event_dispatch ../libs/tk/ydk/x11/gdkevents-x11.c:2425
    0000034 0x7f2a45920e6a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51e6a)
    0000035 0x7f2a45921117  (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x52117)
    0000036 0x7f2a4592140a in g_main_loop_run (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5240a)
    0000037 0x7f2a446a3959 in IA__gtk_main ../libs/tk/ytk/gtkmain.c:1213
    0000038 0x7f2a44ea65e0 in Gtk::Main::run_impl() ../libs/tk/ytkmm/main.cc:537
    0000039 0x7f2a44ea6044 in Gtk::Main::run() ../libs/tk/ytkmm/main.cc:480
    0000040 0x7f2a457ddb3a in Gtkmm2ext::UI::run(Receiver&) ../libs/gtkmm2ext/gtk_ui.cc:305
    0000041 0x55645ea8cbf4 in main ../gtk2_ardour/main.cc:471
    0000042 0x7f2a439fbd09 in __libc_start_main ../csu/libc-start.c:308
    0000043 0x55645da3fd79 in _start (/home/rgareus/src/ardour/build/gtk2_ardour/ardour-8.6.19+0x2706d79)

0x603004876d80 is located 0 bytes inside of 24-byte region [0x603004876d80,0x603004876d98)
freed by thread T0 (ArdourGUI) here:
    #0 0x7f2a4a6ac017 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
    0000001 0x7f2a49ef5925 in __gnu_cxx::new_allocator<std::_List_node<Evoral::ControlEvent*> >::deallocate(std::_List_node<Evoral::ControlEvent*>*, unsigned long) /usr/include/c++/10/ext/new_allocator.h:133
    #2 0x7f2a49ef2e0d in std::allocator_traits<std::allocator<std::_List_node<Evoral::ControlEvent*> > >::deallocate(std::allocator<std::_List_node<Evoral::ControlEvent*> >&, std::_List_node<Evoral::ControlEvent*>*, unsigned long) /usr/include/c++/10/bits/alloc_traits.h:492
    #3 0x7f2a49eed813 in std::__cxx11::_List_base<Evoral::ControlEvent*, std::allocator<Evoral::ControlEvent*> >::_M_put_node(std::_List_node<Evoral::ControlEvent*>*) /usr/include/c++/10/bits/stl_list.h:446
    0000004 0x7f2a46356aaa in std::__cxx11::list<Evoral::ControlEvent*, std::allocator<Evoral::ControlEvent*> >::_M_erase(std::_List_iterator<Evoral::ControlEvent*>) /usr/include/c++/10/bits/stl_list.h:1930
    0000005 0x7f2a4634f621 in std::__cxx11::list<Evoral::ControlEvent*, std::allocator<Evoral::ControlEvent*> >::erase(std::_List_const_iterator<Evoral::ControlEvent*>) /usr/include/c++/10/bits/list.tcc:158
    #6 0x7f2a463387a3 in Evoral::ControlList::erase(std::_List_iterator<Evoral::ControlEvent*>) ../libs/evoral/ControlList.cc:1041
    #7 0x55645e2c073b in Editor::cut_copy_points(Editing::CutCopyOp, Temporal::timepos_t const&) ../gtk2_ardour/editor_ops.cc:4844
    0000008 0x55645e2bd95d in Editor::delete_() ../gtk2_ardour/editor_ops.cc:4569
    0000009 0x55645dfff1ed in sigc::bound_mem_functor0<void, Editor>::operator()() const /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
    0000010 0x55645dfe5c0d in sigc::adaptor_functor<sigc::bound_mem_functor0<void, Editor> >::operator()() const /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
    0000011 0x55645dfe5c34 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, Editor>, void>::call_it(sigc::internal::slot_rep*) /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
    0000012 0x7f2a455d6f47 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) (/lib/x86_64-linux-gnu/libglibmm-2.4.so.1+0x64f47)

previously allocated by thread T0 (ArdourGUI) here:
    #0 0x7f2a4a6ab647 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
    0000001 0x7f2a4636273d in __gnu_cxx::new_allocator<std::_List_node<Evoral::ControlEvent*> >::allocate(unsigned long, void const*) /usr/include/c++/10/ext/new_allocator.h:115
    #2 0x7f2a46361d7e in std::allocator_traits<std::allocator<std::_List_node<Evoral::ControlEvent*> > >::allocate(std::allocator<std::_List_node<Evoral::ControlEvent*> >&, unsigned long) /usr/include/c++/10/bits/alloc_traits.h:460
    #3 0x7f2a4636049c in std::__cxx11::_List_base<Evoral::ControlEvent*, std::allocator<Evoral::ControlEvent*> >::_M_get_node() /usr/include/c++/10/bits/stl_list.h:442
    0000004 0x7f2a4635c3bd in std::_List_node<Evoral::ControlEvent*>* std::__cxx11::list<Evoral::ControlEvent*, std::allocator<Evoral::ControlEvent*> >::_M_create_node<Evoral::ControlEvent*>(Evoral::ControlEvent*&&) /usr/include/c++/10/bits/stl_list.h:634
    0000005 0x7f2a46356cd8 in std::_List_iterator<Evoral::ControlEvent*> std::__cxx11::list<Evoral::ControlEvent*, std::allocator<Evoral::ControlEvent*> >::emplace<Evoral::ControlEvent*>(std::_List_const_iterator<Evoral::ControlEvent*>, Evoral::ControlEvent*&&) /usr/include/c++/10/bits/list.tcc:92
    #6 0x7f2a4634f752 in std::__cxx11::list<Evoral::ControlEvent*, std::allocator<Evoral::ControlEvent*> >::insert(std::_List_const_iterator<Evoral::ControlEvent*>, Evoral::ControlEvent*&&) /usr/include/c++/10/bits/stl_list.h:1309
    #7 0x7f2a463300fe in Evoral::ControlList::editor_add(Temporal::timepos_t const&, double, bool) ../libs/evoral/ControlList.cc:705
    0000008 0x55645ddffb3d in AutomationRegionView::add_automation_event(Temporal::timepos_t const&, double, bool) ../gtk2_ardour/automation_region_view.cc:206
    0000009 0x55645ddfee70 in AutomationRegionView::add_automation_event(_GdkEvent*) ../gtk2_ardour/automation_region_view.cc:161
    0000010 0x55645e26b246 in Editor::button_release_handler(ArdourCanvas::Item*, _GdkEvent*, ItemType) ../gtk2_ardour/editor_mouse.cc:1898
    0000011 0x55645e11de33 in Editor::canvas_region_view_event(_GdkEvent*, ArdourCanvas::Item*, RegionView*) ../gtk2_ardour/editor_canvas_events.cc:270
    0000012 0x55645f5f2e38 in RegionView::canvas_group_event(_GdkEvent*) ../gtk2_ardour/region_view.cc:278
    0000013 0x55645ddfe9df in AutomationRegionView::canvas_group_event(_GdkEvent*) ../gtk2_ardour/automation_region_view.cc:138
    0000014 0x55645faf2b3d in sigc::bound_mem_functor1<bool, TimeAxisViewItem, _GdkEvent*>::operator()(_GdkEvent* const&) const /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:2066
    #15 0x55645faf1fc0 in sigc::adaptor_functor<sigc::bound_mem_functor1<bool, TimeAxisViewItem, _GdkEvent*> >::deduce_result_type<_GdkEvent* const&, void, void, void, void, void, void>::type sigc::adaptor_functor<sigc::bound_mem_functor1<bool, TimeAxisViewItem, _GdkEvent*> >::operator()<_GdkEvent* const&>(_GdkEvent* const&) const /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:89
    0000016 0x55645faf0733 in sigc::internal::slot_call<sigc::bound_mem_functor1<bool, TimeAxisViewItem, _GdkEvent*>, bool, _GdkEvent*>::call_it(sigc::internal::slot_rep*, _GdkEvent* const&) /usr/include/sigc++-2.0/sigc++/functors/slot.h:451
    #17 0x55645fca72b7 in sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::operator()(sigc::slot<bool (_GdkEvent*), sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil> const&) const /usr/include/sigc++-2.0/sigc++/signal.h:860
    0000018 0x55645fca579d in sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool>::operator*() const /usr/include/sigc++-2.0/sigc++/signal.h:319
    0000019 0x55645fca33ae in bool ArdourCanvas::Item::EventAccumulator<bool>::operator()<sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool> >(sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool>, sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool>) ../libs/canvas/canvas/item.h:257
    0000020 0x55645fca0e8a in sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::emit(sigc::internal::signal_impl*, _GdkEvent* const&) /usr/include/sigc++-2.0/sigc++/signal.h:879
    0000021 0x55645fc9e9c7 in sigc::signal1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::emit(_GdkEvent* const&) const /usr/include/sigc++-2.0/sigc++/signal.h:2955
    0000022 0x55645fc9ce6c in sigc::signal1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::operator()(_GdkEvent* const&) const /usr/include/sigc++-2.0/sigc++/signal.h:2971
    0000023 0x7f2a45f519d3 in ArdourCanvas::GtkCanvas::deliver_event(_GdkEvent*) ../libs/canvas/canvas.cc:879
    #24 0x7f2a45f563a1 in ArdourCanvas::GtkCanvas::on_button_release_event(_GdkEventButton*) ../libs/canvas/canvas.cc:1224
    0000025 0x7f2a44fbf87b in Gtk::Widget_Class::button_release_event_callback(_GtkWidget*, _GdkEventButton*) ../libs/tk/ytkmm/widget.cc:4327
    0000026 0x7f2a446a78b7 in _gtk_marshal_BOOLEAN__BOXED ../libs/tk/ytk/gtkmarshalers.c:84
    0000027 0x7f2a4552c0a1 in g_closure_invoke (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x140a1)

SUMMARY: AddressSanitizer: heap-use-after-free /usr/include/c++/10/bits/list.tcc:157 in std::__cxx11::list<Evoral::ControlEvent*, std::allocator<Evoral::ControlEvent*> >::erase(std::_List_const_iterator<Evoral::ControlEvent*>)

(0028652)
x42   
2024-04-14 22:39   
Thanks for the report. fixed in 8.6-2-g4b6e372ce7

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6862 [ardour] features feature N/A 2016-04-20 08:39 2024-04-12 17:29
Reporter: efenstor Platform: PC  
Assigned To: OS: Debian Linux  
Priority: normal OS Version: Jessie  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Subtracks instead of stacked layers
Description: I know it would probably be not easy to implement, but what about aborting the concept of "stacked" and "overlaid" layers in favour of sub-tracks? The sub-track thing would be a great asset for multi-take recording. Of course, currently I can use the track group feature for something similar but every full-scaled track produces a CPU overhead which is completely unneeded in this case.

The main downsides of the stacked layers concept:

1. Complex rearranging of many regions between layers sometimes produces a mess, because every single overlap expands the track area vertically.

2. No way to create automatic micro-overlaps between adjacent regions instead of micro-gaps. The micro-overlaps would be the default fades overlapped, instead of following each other, as of now. The micro-overlaps would greatly help in re-arranging flute recordings and other similar instruments, where the gaps produced by a fade-out followed by a fade-in are very easily heard, no matter how short it is.

This is how the sub-tracks would work:

1. If the sub-track feature is tuned on, a new sub-track would be created every time you start a new recording; in other words, every new take is placed in a new sub-track.

2. The "Choose top" feature remains, but now it rearranges the sub-tracks.

3. If the corresponding feature is selected in the preferences, cutting regions would produce a micro-overlap between them. Putting regions together with the snap to region option on would also produce a micro-overlap between them by slightly shifting the region being moved towards the region it is being glued to.

4. When there are no regions left in a sub-track it is automatically removed.

5. When you start dragging a region from the top sub-track upwards a new sub-track is temporarily created when the cursor is near the split between tracks. Dragging it back down without releasing a mouse button removes the temporary sub-track. Releasing a mouse button makes the sub-track permanent and places a region being dragged into it.
Tags: comping comps take-management, feature request
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018154)
efenstor   
2016-04-20 08:42   
"When you start dragging a region from the top sub-track upwards" - from every sub-track would be much better, of course. )))

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9687 [ardour] features minor have not tried 2024-04-12 17:27 2024-04-12 17:28
Reporter: efenstor Platform: PC x64  
Assigned To: OS: Debian Linux  
Priority: normal OS Version: Stretch  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Sticky/pinned/reference track
Description: When recording a track I often use another track as a reference and it would be great if it could be pinned to be always visible at the top.
Tags: feature request, recording, track
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9686 [ardour] bugs major always 2024-04-12 16:47 2024-04-12 16:47
Reporter: YugoNumachi Platform: Microsoft  
Assigned To: OS: Windows  
Priority: high OS Version: 11  
Status: new Product Version: 8.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Multiple issues with MIDI regions and cues on Windows
Description: There are multiple issues with MIDI regions on Windows that make them completely unusable, especially when combined with cues.

1. Creating a new MIDI region and populate the notes manually successfully creates the region, but the created region is unusable in Cues.
- Drag/drop of the region from Sources tab to a Cue slot correctly populates the slot, but the MIDI content is wrong and only contains the first note, like if it was cropped to only the beginning.
- Drag/drop of the region from the Regions tab to a Cue slot simply does nothing.

2. When copy/pasting the region created in step 1 in Edit mode, the newly created regions appears twice in the Sources tab with different sequence numbers, and not at all in the Regions tab.
- Drag/drop of any of the the two new regions from the Sources tab to a Cue slot works as expected.

3. Editing anything (notes, automation, velocity, etc.) from the region pasted in step 2 freezes Ardour and the only thing to do is to kill the application completely.

I understand Ardour is open source, and I am happy to contribute financially to its development, but it is a bit unfortunate that two of the major aspects of Ardour, being MIDI and Cues, do not work at all, which makes the application unusable for my use case.
Tags: cue, MIDI region
Steps To Reproduce: Follow the description above.
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9684 [ardour] bugs minor always 2024-04-10 06:27 2024-04-12 05:32
Reporter: miniupuchaty Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Inputs/Outputs window always starts wrong size
Description: Each time I open the Inputs or Outputs for the track it starts a bit too small. With not enough space for R and L channels to be visible and window has to be scaled up.
Tags: Linux, ui
Steps To Reproduce:
Additional Information: Tested on Gnome and Sway.
Wayland.
Tested on git cde26c5205f98da62688c6403af3ba32f5f59759 and 8.4.0 from arch repo.
System Description
Attached Files: image.png (11,905 bytes) 2024-04-10 06:27
https://tracker.ardour.org/file_download.php?file_id=4819&type=bug
png
Notes
(0028640)
miniupuchaty   
2024-04-12 05:32   
For now I've added some additional width in `PortMatrix::max_size()`.

I'm up for looking into which widget reports incorrect size or what else is the problem so if anyone has some pointers into what to look into first it would help :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9594 [ardour] bugs minor always 2024-01-05 22:53 2024-04-10 22:40
Reporter: b2jammer Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Cue Track Breaks if Played Past End of Loop Range
Description: If a loop range is set and a MIDI cue is playing when the playhead jumps to the start loop marker, the clip is abruptly cut off and will not be triggered again unless playback is stopped.
Tags: 8.2, clip, cue, loop, Midi
Steps To Reproduce: 1. Create an empty project.
2. Add a MIDI track, ensuring "Show on Cue Page" is checked.
3. In the Cue window, drag a MIDI clip (e.g. 1_groove_16beat1.mid) to cue slot A of that track.
4. Set both follow actions of track 1 cue A to "Stop," and set its Launch Quantize to "None."
5. In the Edit window, add a Loop range from the start of measure 1 to the end of measure 2.
6. Add Cue Marker A to either the beginning of measure 1, or anywhere in measure 2 after beat 1.
7. Enable "Play Loop Range" and press Play.

Actual behavior: The cue will trigger once, but will abruptly cut off and never trigger again once the playhead loops.
Expected behavior: The cue will continue playing after the playhead jumps back and can be triggered again under normal cue rules.
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0028638)
Schmitty2005   
2024-04-10 22:28   
This also happens in Linux 8.4 from Ardour.org on Ubuntu 22.04 LTS and Windows 10 Ardour 8.4 downloaded from Ardour.org

A semi related bug is that I have occasionally found that CUE tracks are possibly exported when muted. Causing a doubling effect on audio mixdowns of the CUE track. When I can replicate successfully, I will add to tracker.
(0028639)
Schmitty2005   
2024-04-10 22:40   
Interestingly, when CUE is not playing after looping, if you disable looping(Shortcut = L 'Loop Playback Range'), the CUE will start back up wherever you are at in the loop range.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9670 [ardour] bugs crash always 2024-03-12 02:47 2024-04-10 12:22
Reporter: musew Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crashes when loading session file.
Description: Crashes upon loading a very simple session that I used maybe once. Since then I have reinstalled the OS (Manjaro) but everything is up to date. I am using the ardour 8.4-1 from the repo, as the appimage from this site has trouble loading certain plugins (I have seen that issue discussed before in forums). Crashes just after clicking okay on the ulimits message.
Tags:
Steps To Reproduce: Start ardour, load the session file.
Additional Information: (gdb) thread apply all bt

Thread 74 (Thread 0x7fff6f7fe6c0 (LWP 287724) "autoconnect"):
#0 0x00007ffff53acebe in ??? () at /usr/lib/libc.so.6
0000001 0x00007ffff53af750 in pthread_cond_wait () at /usr/lib/libc.so.6
#2 0x00007ffff78a8139 in ARDOUR::Session::auto_connect_thread_run() () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff78a865e in ARDOUR::Session::auto_connect_thread(void*) () at /usr/lib/ardour8/libardour.so.3
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 73 (Thread 0x7fff6ffff6c0 (LWP 287723) "SessionSignals"):
#0 0x00007ffff53acebe in ??? () at /usr/lib/libc.so.6
0000001 0x00007ffff53af750 in pthread_cond_wait () at /usr/lib/libc.so.6
#2 0x00007ffff78e9935 in ARDOUR::Session::emit_thread_run() () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff78e996e in ARDOUR::Session::emit_thread(void*) () at /usr/lib/ardour8/libardour.so.3
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 72 (Thread 0x7fff78ffd6c0 (LWP 287722) "ArdourGUI"):
#0 0x00007ffff54200bf in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff5e43ab5 in ??? () at /usr/lib/libusb-1.0.so.0
#2 0x00007ffff5e46bd8 in libusb_handle_events_timeout_completed () at /usr/lib/libusb-1.0.so.0
#3 0x00007ffff5e46c2f in libusb_handle_events () at /usr/lib/libusb-1.0.so.0
0000004 0x00007ffff75e82de in ??? () at /usr/lib/ardour8/libardour.so.3
0000005 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
--Type <RET> for more, q to quit, c to continue without paging--c
#6 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 71 (Thread 0x7fff797fe6c0 (LWP 287721) "libusb_event"):
#0 0x00007ffff54200bf in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff5e48226 in ??? () at /usr/lib/libusb-1.0.so.0
#2 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#3 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 70 (Thread 0x7fff79fff6c0 (LWP 287720) "Generic MIDI"):
#0 0x00007ffff54200bf in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff641c2f6 in ??? () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff63beb97 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff6f5cbda in PBD::Thread::_run(void*) () at /usr/lib/ardour8/libpbd.so.4
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 69 (Thread 0x7fff909ff6c0 (LWP 287719) "ArdourGUI"):
#0 0x00007ffff54200bf in poll () at /usr/lib/libc.so.6
0000001 0x00007fff7a33ed01 in juce::MessageManager::dispatchNextMessageOnSystemQueue(bool) () at /usr/lib/lv2/helm-synth.lv2/helm-synth.so
#2 0x00007fff7a33eda8 in juce::MessageManager::runDispatchLoop() () at /usr/lib/lv2/helm-synth.lv2/helm-synth.so
#3 0x00007fff7a281f20 in ??? () at /usr/lib/lv2/helm-synth.lv2/helm-synth.so
0000004 0x00007fff7a30696e in juce::Thread::threadEntryPoint() () at /usr/lib/lv2/helm-synth.lv2/helm-synth.so
0000005 0x00007fff7a31cd8e in threadEntryProc () at /usr/lib/lv2/helm-synth.lv2/helm-synth.so
#6 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#7 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 68 (Thread 0x7fff937fe6c0 (LWP 287714) "LV2Worker"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait() () at /usr/lib/ardour8/libpbd.so.4
#2 0x00007ffff799ab1b in ARDOUR::Worker::run() () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff6f5cbda in PBD::Thread::_run(void*) () at /usr/lib/ardour8/libpbd.so.4
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 67 (Thread 0x7fffb1ffb6c0 (LWP 287712) "midiUI"):
#0 0x00007ffff54200bf in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff641c2f6 in ??? () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff63beb97 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff6f5cbda in PBD::Thread::_run(void*) () at /usr/lib/ardour8/libpbd.so.4
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 66 (Thread 0x7fffb376c6c0 (LWP 287711) "butler"):
#0 0x00007ffff54206bc in read () at /usr/lib/libc.so.6
0000001 0x00007ffff58d8178 in ??? () at /usr/lib/libsndfile.so.1
#2 0x00007ffff58fa2ea in sf_read_float () at /usr/lib/libsndfile.so.1
#3 0x00007ffff793b266 in ARDOUR::SndFileSource::read_unlocked(float*, long, long) const () at /usr/lib/ardour8/libardour.so.3
0000004 0x00007ffff75b53e4 in ARDOUR::AudioSource::read(float*, long, long, int) const () at /usr/lib/ardour8/libardour.so.3
0000005 0x00007ffff75a6f1a in ARDOUR::AudioRegion::read_from_sources(std::vector<std::shared_ptr<ARDOUR::Source>, std::allocator<std::shared_ptr<ARDOUR::Source> > > const&, long, float*, long, long, unsigned int) const () at /usr/lib/ardour8/libardour.so.3
#6 0x00007ffff75a753a in ARDOUR::AudioRegion::read_at(float*, float*, float*, long, long, unsigned int) const () at /usr/lib/ardour8/libardour.so.3
#7 0x00007ffff757beb9 in ARDOUR::AudioPlaylist::read(float*, float*, float*, Temporal::timepos_t const&, Temporal::timecnt_t const&, unsigned int) () at /usr/lib/ardour8/libardour.so.3
0000008 0x00007ffff760915b in ARDOUR::DiskReader::audio_read(float*, float*, float*, long&, long, ARDOUR::DiskReader::ReaderChannelInfo*, int, bool) () at /usr/lib/ardour8/libardour.so.3
0000009 0x00007ffff7609b48 in ARDOUR::DiskReader::refill_audio(float*, float*, float*, long, bool) () at /usr/lib/ardour8/libardour.so.3
0000010 0x00007ffff760a6fc in ARDOUR::DiskReader::do_refill_with_alloc(bool, bool) () at /usr/lib/ardour8/libardour.so.3
0000011 0x00007ffff760a8ed in ARDOUR::DiskReader::seek(long, bool) () at /usr/lib/ardour8/libardour.so.3
0000012 0x00007ffff7854230 in ARDOUR::Route::non_realtime_locate(long) () at /usr/lib/ardour8/libardour.so.3
0000013 0x00007ffff791a1b3 in ARDOUR::Session::non_realtime_locate() () at /usr/lib/ardour8/libardour.so.3
0000014 0x00007ffff7922222 in ARDOUR::Session::butler_transport_work(bool) () at /usr/lib/ardour8/libardour.so.3
#15 0x00007ffff75e437c in ARDOUR::Butler::thread_work() () at /usr/lib/ardour8/libardour.so.3
0000016 0x00007ffff6f5cb2a in ??? () at /usr/lib/ardour8/libpbd.so.4
#17 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000018 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 65 (Thread 0x7fff92ffd6c0 (LWP 287710) "RT-2-(nil)"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait() () at /usr/lib/ardour8/libpbd.so.4
#2 0x00007ffff768d4a6 in ARDOUR::Graph::run_one() () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff7696359 in ARDOUR::Graph::helper_thread() () at /usr/lib/ardour8/libardour.so.3
0000004 0x00007fffe88e4a02 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) () at /usr/lib/ardour8/backends/libjack_audiobackend.so
0000005 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#6 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 64 (Thread 0x7fffb3fff6c0 (LWP 287709) "RT-1-(nil)"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait() () at /usr/lib/ardour8/libpbd.so.4
#2 0x00007ffff768d4a6 in ARDOUR::Graph::run_one() () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff7696359 in ARDOUR::Graph::helper_thread() () at /usr/lib/ardour8/libardour.so.3
0000004 0x00007fffe88e4a02 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) () at /usr/lib/ardour8/backends/libjack_audiobackend.so
0000005 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#6 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 63 (Thread 0x7fffb17fa6c0 (LWP 287708) "RT-main-(nil)"):
#0 0x00007fff90d5b659 in SurgeLv2Ui::setParameterAutomated(int, float) () at /usr/local/lib/lv2/Surge.lv2/Surge.so
0000001 0x00007fff90b16f43 in SurgeSynthesizer::loadOscalgos() () at /usr/local/lib/lv2/Surge.lv2/Surge.so
#2 0x00007fff90b1999b in SurgeSynthesizer::processControl() () at /usr/local/lib/lv2/Surge.lv2/Surge.so
#3 0x00007fff90b1a8a8 in SurgeSynthesizer::process() () at /usr/local/lib/lv2/Surge.lv2/Surge.so
0000004 0x00007fff90d5d129 in SurgeLv2Wrapper::run(void*, unsigned int) () at /usr/local/lib/lv2/Surge.lv2/Surge.so
0000005 0x00007ffff79ac9d7 in ARDOUR::LV2Plugin::run(unsigned int, bool) () at /usr/lib/ardour8/libardour.so.3
#6 0x00007ffff79b15e6 in ARDOUR::LV2Plugin::connect_and_run(ARDOUR::BufferSet&, long, long, double, ARDOUR::ChanMapping const&, ARDOUR::ChanMapping const&, unsigned int, long) () at /usr/lib/ardour8/libardour.so.3
#7 0x00007ffff77b57bf in ARDOUR::PluginInsert::connect_and_run(ARDOUR::BufferSet&, long, long, double, unsigned int, long, bool) () at /usr/lib/ardour8/libardour.so.3
0000008 0x00007ffff77b7e48 in ARDOUR::PluginInsert::run(ARDOUR::BufferSet&, long, long, double, unsigned int, bool) () at /usr/lib/ardour8/libardour.so.3
0000009 0x00007ffff783bbce in ARDOUR::Route::process_output_buffers(ARDOUR::BufferSet&, long, long, unsigned int, bool, bool) () at /usr/lib/ardour8/libardour.so.3
0000010 0x00007ffff783d03a in ARDOUR::Route::run_route(long, long, unsigned int, bool, bool) () at /usr/lib/ardour8/libardour.so.3
0000011 0x00007ffff785006e in ARDOUR::Route::no_roll_unlocked(unsigned int, long, long, bool) () at /usr/lib/ardour8/libardour.so.3
0000012 0x00007ffff7742289 in ARDOUR::MidiTrack::no_roll_unlocked(unsigned int, long, long, bool) () at /usr/lib/ardour8/libardour.so.3
0000013 0x00007ffff7847ccc in ARDOUR::Route::no_roll(unsigned int, long, long, bool) () at /usr/lib/ardour8/libardour.so.3
0000014 0x00007ffff7693a02 in ARDOUR::Graph::process_one_route(ARDOUR::Route*) () at /usr/lib/ardour8/libardour.so.3
#15 0x00007ffff768f3e6 in ARDOUR::GraphNode::run(ARDOUR::GraphChain const*) () at /usr/lib/ardour8/libardour.so.3
0000016 0x00007ffff76961f9 in ARDOUR::Graph::main_thread() () at /usr/lib/ardour8/libardour.so.3
#17 0x00007fffe88e4a02 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) () at /usr/lib/ardour8/backends/libjack_audiobackend.so
0000018 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000019 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 62 (Thread 0x7fffb27fc6c0 (LWP 287517) "ArdourGUI"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417337 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff63891b4 in ??? () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff638921c in g_async_queue_pop () at /usr/lib/libglib-2.0.so.0
0000004 0x00007ffff5f6fc48 in ??? () at /usr/lib/libpangoft2-1.0.so.0
0000005 0x00007ffff63efa45 in ??? () at /usr/lib/libglib-2.0.so.0
#6 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#7 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 60 (Thread 0x7fff927fc6c0 (LWP 287515) "pool-ardour-8.4"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417d13 in g_cond_wait_until () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff6389185 in ??? () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff63892e7 in g_async_queue_timeout_pop () at /usr/lib/libglib-2.0.so.0
0000004 0x00007ffff63f23be in ??? () at /usr/lib/libglib-2.0.so.0
0000005 0x00007ffff63efa45 in ??? () at /usr/lib/libglib-2.0.so.0
#6 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#7 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 59 (Thread 0x7fff7bfff6c0 (LWP 287508) "ArdourGUI"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417337 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff63891b4 in ??? () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff638921c in g_async_queue_pop () at /usr/lib/libglib-2.0.so.0
0000004 0x00007ffff5f6fc48 in ??? () at /usr/lib/libpangoft2-1.0.so.0
0000005 0x00007ffff63efa45 in ??? () at /usr/lib/libglib-2.0.so.0
#6 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#7 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 48 (Thread 0x7fff93fff6c0 (LWP 287486) "AudioEngine 1"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait() () at /usr/lib/ardour8/libpbd.so.4
#2 0x00007ffff768da31 in ARDOUR::Graph::routes_no_roll(std::shared_ptr<ARDOUR::GraphChain>, unsigned int, long, long, bool) () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff78e0c0b in ARDOUR::Session::no_roll(unsigned int) () at /usr/lib/ardour8/libardour.so.3
0000004 0x00007ffff78e9574 in ARDOUR::Session::process_with_events(unsigned int) () at /usr/lib/ardour8/libardour.so.3
0000005 0x00007ffff78e0f92 in ARDOUR::Session::process(unsigned int) () at /usr/lib/ardour8/libardour.so.3
#6 0x00007ffff75940a6 in ARDOUR::AudioEngine::process_callback(unsigned int) () at /usr/lib/ardour8/libardour.so.3
#7 0x00007fffe88ebc95 in ARDOUR::JACKAudioBackend::process_thread() () at /usr/lib/ardour8/backends/libjack_audiobackend.so
0000008 0x00007ffff65123f5 in ??? () at /usr/lib/spa-0.2/support/libspa-support.so
0000009 0x00007ffff33acdb2 in ??? () at /usr/lib/libpipewire-0.3.so.0
0000010 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000011 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 47 (Thread 0x7fffb0ff96c0 (LWP 287485) "pw-ardour"):
#0 0x00007ffff542de66 in epoll_wait () at /usr/lib/libc.so.6
0000001 0x00007ffff6520bd9 in ??? () at /usr/lib/spa-0.2/support/libspa-support.so
#2 0x00007ffff651258d in ??? () at /usr/lib/spa-0.2/support/libspa-support.so
#3 0x00007ffff33f391d in ??? () at /usr/lib/libpipewire-0.3.so.0
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 46 (Thread 0x7fffb2ffd6c0 (LWP 287484) "pw-ardour"):
#0 0x00007ffff542de66 in epoll_wait () at /usr/lib/libc.so.6
0000001 0x00007ffff6520bd9 in ??? () at /usr/lib/spa-0.2/support/libspa-support.so
#2 0x00007ffff651258d in ??? () at /usr/lib/spa-0.2/support/libspa-support.so
#3 0x00007ffff33f391d in ??? () at /usr/lib/libpipewire-0.3.so.0
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 24 (Thread 0x7fffc94656c0 (LWP 287283) "gdbus"):
#0 0x00007ffff54200bf in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff641c2f6 in ??? () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff63beb97 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff4b9319c in ??? () at /usr/lib/libgio-2.0.so.0
0000004 0x00007ffff63efa45 in ??? () at /usr/lib/libglib-2.0.so.0
0000005 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#6 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 23 (Thread 0x7fffc9dd66c0 (LWP 287282) "gmain"):
#0 0x00007ffff54200bf in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff641c2f6 in ??? () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff63bc162 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff63bc1b2 in ??? () at /usr/lib/libglib-2.0.so.0
0000004 0x00007ffff63efa45 in ??? () at /usr/lib/libglib-2.0.so.0
0000005 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#6 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 22 (Thread 0x7fffcb8d46c0 (LWP 287281) "pool-spawner"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417337 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff63891b4 in ??? () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff63f1ace in ??? () at /usr/lib/libglib-2.0.so.0
0000004 0x00007ffff63efa45 in ??? () at /usr/lib/libglib-2.0.so.0
0000005 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#6 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 15 (Thread 0x7fffcaf536c0 (LWP 287268) "ArdourGUI"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417337 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff63891b4 in ??? () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff638921c in g_async_queue_pop () at /usr/lib/libglib-2.0.so.0
0000004 0x00007ffff5f6fc48 in ??? () at /usr/lib/libpangoft2-1.0.so.0
0000005 0x00007ffff63efa45 in ??? () at /usr/lib/libglib-2.0.so.0
#6 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#7 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 14 (Thread 0x7fffca7526c0 (LWP 287267) "ArdourGUI"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417337 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff63891b4 in ??? () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff638921c in g_async_queue_pop () at /usr/lib/libglib-2.0.so.0
0000004 0x00007ffff5f6fc48 in ??? () at /usr/lib/libpangoft2-1.0.so.0
0000005 0x00007ffff63efa45 in ??? () at /usr/lib/libglib-2.0.so.0
#6 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#7 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 10 (Thread 0x7fffe91786c0 (LWP 287260) "DeviceList"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417337 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7594b38 in ARDOUR::AudioEngine::do_devicelist_update() () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff6f5cbda in PBD::Thread::_run(void*) () at /usr/lib/ardour8/libpbd.so.4
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 9 (Thread 0x7fffe9c886c0 (LWP 287259) "EngineWatchdog"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417337 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7595ce8 in ARDOUR::AudioEngine::do_reset_backend() () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff6f5cbda in PBD::Thread::_run(void*) () at /usr/lib/ardour8/libpbd.so.4
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 6 (Thread 0x7fffea7fc6c0 (LWP 287255) "Analyzer"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417337 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7572cac in ARDOUR::Analyser::work() () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff6f5cbda in PBD::Thread::_run(void*) () at /usr/lib/ardour8/libpbd.so.4
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 5 (Thread 0x7fffeaffd6c0 (LWP 287254) "PeakFileBuilder"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417337 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff793af23 in ??? () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff6f5cbda in PBD::Thread::_run(void*) () at /usr/lib/ardour8/libpbd.so.4
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 4 (Thread 0x7fffeb7fe6c0 (LWP 287253) "PeakFileBuilder"):
#0 0x00007ffff542b88d in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6417337 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff793af23 in ??? () at /usr/lib/ardour8/libardour.so.3
#3 0x00007ffff6f5cbda in PBD::Thread::_run(void*) () at /usr/lib/ardour8/libpbd.so.4
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 3 (Thread 0x7fffebfff6c0 (LWP 287252) "LXVSTEventLoop"):
#0 0x00007ffff53f9335 in clock_nanosleep () at /usr/lib/libc.so.6
0000001 0x00007ffff54043e7 in nanosleep () at /usr/lib/libc.so.6
#2 0x00007ffff63ec3b9 in g_usleep () at /usr/lib/libglib-2.0.so.0
#3 0x00005555561c8a27 in ??? ()
0000004 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
0000005 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 2 (Thread 0x7ffff05ff6c0 (LWP 287251) "Trigger Worker"):
#0 0x00007ffff54200bf in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff6f48add in CrossThreadChannel::poll_for_request() () at /usr/lib/ardour8/libpbd.so.4
#2 0x00007ffff6f48b63 in CrossThreadChannel::receive(char&, bool) () at /usr/lib/ardour8/libpbd.so.4
#3 0x00007ffff7989284 in ARDOUR::TriggerBoxThread::thread_work() () at /usr/lib/ardour8/libardour.so.3
0000004 0x00007ffff6f5cb2a in ??? () at /usr/lib/ardour8/libpbd.so.4
0000005 0x00007ffff53b055a in ??? () at /usr/lib/libc.so.6
#6 0x00007ffff542da3c in ??? () at /usr/lib/libc.so.6

Thread 1 (Thread 0x7ffff0b0ba80 (LWP 287246) "ArdourGUI"):
#0 0x00007ffff61cb680 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
0000001 0x00007ffff67794a4 in ??? () at /usr/lib/ardour8/libytk.so.2
#2 0x00007ffff667bd65 in ??? () at /usr/lib/ardour8/libytk.so.2
#3 0x00007ffff677956a in ??? () at /usr/lib/ardour8/libytk.so.2
0000004 0x00007ffff677956a in ??? () at /usr/lib/ardour8/libytk.so.2
0000005 0x00007ffff677956a in ??? () at /usr/lib/ardour8/libytk.so.2
#6 0x00007ffff667bd65 in ??? () at /usr/lib/ardour8/libytk.so.2
#7 0x00007ffff677956a in ??? () at /usr/lib/ardour8/libytk.so.2
0000008 0x00007ffff667bd65 in ??? () at /usr/lib/ardour8/libytk.so.2
0000009 0x00007ffff677956a in ??? () at /usr/lib/ardour8/libytk.so.2
0000010 0x00007ffff667bd65 in ??? () at /usr/lib/ardour8/libytk.so.2
0000011 0x00007ffff677956a in ??? () at /usr/lib/ardour8/libytk.so.2
0000012 0x00007ffff667bd65 in ??? () at /usr/lib/ardour8/libytk.so.2
0000013 0x00007ffff677956a in ??? () at /usr/lib/ardour8/libytk.so.2
0000014 0x00007ffff667bd65 in ??? () at /usr/lib/ardour8/libytk.so.2
#15 0x00007ffff677956a in ??? () at /usr/lib/ardour8/libytk.so.2
0000016 0x00007ffff667bd65 in ??? () at /usr/lib/ardour8/libytk.so.2
#17 0x00007ffff677956a in ??? () at /usr/lib/ardour8/libytk.so.2
0000018 0x00007ffff677956a in ??? () at /usr/lib/ardour8/libytk.so.2
0000019 0x00007ffff67797eb in ??? () at /usr/lib/ardour8/libytk.so.2
0000020 0x000055555598b28e in ??? ()
0000021 0x00007ffff6e302b5 in Gtk::Widget_Class::show_callback(_GtkWidget*) () at /usr/lib/ardour8/libytkmm.so.2
0000022 0x00007ffff61bd6c0 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
0000023 0x00007ffff61ebb7a in ??? () at /usr/lib/libgobject-2.0.so.0
#24 0x00007ffff61dca42 in ??? () at /usr/lib/libgobject-2.0.so.0
0000025 0x00007ffff61dcc77 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000026 0x00007ffff61dcd34 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
0000027 0x00007ffff690fa48 in gtk_widget_show () at /usr/lib/ardour8/libytk.so.2
0000028 0x00007ffff6e300c6 in Gtk::Widget_Class::show_all_vfunc_callback(_GtkWidget*) () at /usr/lib/ardour8/libytkmm.so.2
0000029 0x0000555555a27af4 in ??? ()
0000030 0x00005555561e81d7 in ??? ()
0000031 0x0000555555a38f9b in ??? ()
0000032 0x0000555555981d8d in ??? ()
0000033 0x00005555560d6bb3 in ??? ()
0000034 0x00007ffff6d98b3d in ??? () at /usr/lib/ardour8/libytkmm.so.2
0000035 0x00007ffff61bd6c0 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
0000036 0x00007ffff61ebdbb in ??? () at /usr/lib/libgobject-2.0.so.0
0000037 0x00007ffff61dca42 in ??? () at /usr/lib/libgobject-2.0.so.0
0000038 0x00007ffff61dcc77 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000039 0x00007ffff61dcd34 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
0000040 0x00005555560d3448 in ??? ()
0000041 0x00007ffff6d98b3d in ??? () at /usr/lib/ardour8/libytkmm.so.2
0000042 0x00007ffff61bd6c0 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
0000043 0x00007ffff61ebdbb in ??? () at /usr/lib/libgobject-2.0.so.0
0000044 0x00007ffff61dca42 in ??? () at /usr/lib/libgobject-2.0.so.0
0000045 0x00007ffff61dcc77 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000046 0x00007ffff61dcd34 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
0000047 0x00007ffff6e20615 in ??? () at /usr/lib/ardour8/libytkmm.so.2
0000048 0x00007ffff61bd6c0 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
0000049 0x00007ffff61ebdbb in ??? () at /usr/lib/libgobject-2.0.so.0
0000050 0x00007ffff61dca42 in ??? () at /usr/lib/libgobject-2.0.so.0
0000051 0x00007ffff61dcc77 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000052 0x00007ffff61dcd34 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
0000053 0x00007ffff68deb91 in ??? () at /usr/lib/ardour8/libytk.so.2
0000054 0x00007ffff677a2bb in _gtk_marshal_BOOLEAN__BOXED () at /usr/lib/ardour8/libytk.so.2
0000055 0x00007ffff61bd6c0 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
0000056 0x00007ffff61ec0ea in ??? () at /usr/lib/libgobject-2.0.so.0
0000057 0x00007ffff61dc335 in ??? () at /usr/lib/libgobject-2.0.so.0
0000058 0x00007ffff61dcc77 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000059 0x00007ffff61dcd34 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
0000060 0x00007ffff6910a3d in ??? () at /usr/lib/ardour8/libytk.so.2
0000061 0x00007ffff6775d3f in gtk_propagate_event () at /usr/lib/ardour8/libytk.so.2
0000062 0x00007ffff6779e2b in ??? () at /usr/lib/ardour8/libytk.so.2
0000063 0x00007ffff6b48812 in ??? () at /usr/lib/ardour8/libydk.so.2
0000064 0x00007ffff63bdf69 in ??? () at /usr/lib/libglib-2.0.so.0
0000065 0x00007ffff641c3a7 in ??? () at /usr/lib/libglib-2.0.so.0
0000066 0x00007ffff63beb97 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
0000067 0x00007ffff6779283 in gtk_main () at /usr/lib/ardour8/libytk.so.2
0000068 0x00007ffff6fed8a9 in Gtkmm2ext::UI::run(Receiver&) () at /usr/lib/ardour8/libgtkmm2ext.so.0
0000069 0x0000555555970557 in main ()
System Description
Attached Files:
Notes
(0028590)
musew   
2024-03-12 02:57   
Update: exact same thing happens using the Appimage version.
(0028591)
x42   
2024-03-12 03:23   
Sadly the backtrace is not useful since there are no debug symbols (all "???").
Can you try with a debug version from https://nightly.ardour.org (demo is fine)

But first , does the session load when you enable "[x] Safe mode: disable all plugins" in the recent session dialog?
(0028636)
resolutionfu   
2024-04-10 12:17   
Hi, I recently updated ardour (8.4.1) and pipewire and had the same issue. I tried with disable plugins and same result. It crashes just after the "index plugins" stage of opening (I guess when the main GUI starts to open). There is no issue with ALSA, so it seems to be connected to pw-jack. Because both software was updated at the same time, it is not obvious to me which change is the culprit (or maybe both). In journalctl I get this error for pipewire if it helps:

14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 20, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 21, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 22, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 23, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 24, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 25, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 26, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 27, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 28, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 29, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 30, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 31, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 32, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 33, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 34, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 35, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 36, expected 3
14:03:49 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 37, expected 3
14:03:56 hostname pipewire[2324085]: pw.core: 0x59805c5c9bf0: error -22 for resource 0: invalid mem id 38, expected 3

Here is a back trace that hopefully is informative:

Starting program: /usr/lib/ardour8/ardour-8.4.0
Downloading separate debug info for system-supplied DSO at 0x7ffff7fc6000
[###]
Download failed: Connection reset by peer. Continuing without separate debug info for system-supplied DSO at 0x7ffff7fc6000.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Downloading separate debug info for /usr/lib/liblrdf.so.2
[###]
Download failed: Connection reset by peer. Continuing without separate debug info for /usr/lib/liblrdf.so.2.
Downloading separate debug info for /usr/lib/libpsl.so.5
[###]Download failed: Connection reset by peer. Continuing without separate debug info for /usr/lib/libpsl.so.5.
Downloading separate debug info for /usr/lib/libogg.so.0
[###Downloading separate debug info for /usr/lib/libvorbisenc.so.2
[###Download failed: Connection reset by peer. Continuing without separate debug info for /usr/lib/libvorbisenc.so.2.
Downloading separate debug info for /usr/lib/libvorbis.so.0
[###]
Download failed: Connection reset by peer. Continuing without separate debug info for /usr/lib/libvorbis.so.0.
[New Thread 0x7ffff05ff6c0 (LWP 2637819)]
[New Thread 0x7fffefe006c0 (LWP 2637820)]
[New Thread 0x7fffef4006c0 (LWP 2637821)]
[New Thread 0x7fffeea006c0 (LWP 2637822)]
[New Thread 0x7fffee0006c0 (LWP 2637823)]
[New Thread 0x7fffed6006c0 (LWP 2637824)]
[Thread 0x7fffed6006c0 (LWP 2637824) exited]
[New Thread 0x7fffed6006c0 (LWP 2637842)]
[Thread 0x7fffed6006c0 (LWP 2637842) exited]
[New Thread 0x7fffed6006c0 (LWP 2637845)]
[New Thread 0x7fffecc006c0 (LWP 2637846)]
[New Thread 0x7fffe3e006c0 (LWP 2637847)]
Downloading separate debug info for /usr/lib/libvorbisfile.so.3
[###]Download failed: Connection reset by peer. Continuing without separate debug info for /usr/lib/libvorbisfile.so.3.
[New Thread 0x7fffe2e006c0 (LWP 2637869)]
[New Thread 0x7fffe24006c0 (LWP 2637887)]
[New Thread 0x7fffe1a006c0 (LWP 2637888)]
[Thread 0x7fffe24006c0 (LWP 2637887) exited]
[New Thread 0x7fffe24006c0 (LWP 2637889)]
[Thread 0x7fffe2e006c0 (LWP 2637869) exited]
[New Thread 0x7fffe2e006c0 (LWP 2637890)]
[Thread 0x7fffe2e006c0 (LWP 2637890) exited]
[New Thread 0x7fffe2e006c0 (LWP 2637891)]
[New Thread 0x7fffe10006c0 (LWP 2637892)]
[Thread 0x7fffe2e006c0 (LWP 2637891) exited]
[Thread 0x7fffe10006c0 (LWP 2637892) exited]
[New Thread 0x7fffe10006c0 (LWP 2637893)]
[Thread 0x7fffe10006c0 (LWP 2637893) exited]
[New Thread 0x7fffe10006c0 (LWP 2637894)]
[New Thread 0x7fffe2e006c0 (LWP 2637895)]
[Thread 0x7fffe2e006c0 (LWP 2637895) exited]
[Thread 0x7fffe10006c0 (LWP 2637894) exited]
[New Thread 0x7fffe2e006c0 (LWP 2637896)]
[New Thread 0x7fffe10006c0 (LWP 2637897)]
[New Thread 0x7fffd7e006c0 (LWP 2637898)]
[New Thread 0x7fffd74006c0 (LWP 2637899)]
[New Thread 0x7fffd6a006c0 (LWP 2637900)]
[New Thread 0x7fffd60006c0 (LWP 2637901)]
[New Thread 0x7fffd56006c0 (LWP 2637902)]
[New Thread 0x7fffd4c006c0 (LWP 2637903)]
[New Thread 0x7fffcbe006c0 (LWP 2637904)]
[New Thread 0x7fffcb4006c0 (LWP 2637905)]
[New Thread 0x7fffcaa006c0 (LWP 2637906)]
[New Thread 0x7fffca0006c0 (LWP 2637907)]
[New Thread 0x7fffc96006c0 (LWP 2637908)]
[Thread 0x7fffcaa006c0 (LWP 2637906) exited]
[Thread 0x7fffd56006c0 (LWP 2637902) exited]
[Thread 0x7fffca0006c0 (LWP 2637907) exited]
[Thread 0x7fffcb4006c0 (LWP 2637905) exited]
[Thread 0x7fffd6a006c0 (LWP 2637900) exited]
[Thread 0x7fffd4c006c0 (LWP 2637903) exited]
[Thread 0x7fffd60006c0 (LWP 2637901) exited]
[Thread 0x7fffd74006c0 (LWP 2637899) exited]
[Thread 0x7fffe3e006c0 (LWP 2637847) exited]
[New Thread 0x7fffd60006c0 (LWP 2637996)]
[Thread 0x7fffd60006c0 (LWP 2637996) exited]
[New Thread 0x7fffd60006c0 (LWP 2637997)]
[New Thread 0x7fffd74006c0 (LWP 2637998)]
[New Thread 0x7fffd4c006c0 (LWP 2637999)]
[New Thread 0x7fffd6a006c0 (LWP 2638109)]
[New Thread 0x7fffd56006c0 (LWP 2638110)]
[New Thread 0x7fffcb4006c0 (LWP 2638111)]
[Thread 0x7fffcb4006c0 (LWP 2638111) exited]
[New Thread 0x7fffcaa006c0 (LWP 2638112)]
[Thread 0x7fffd6a006c0 (LWP 2638109) exited]
[Thread 0x7fffcbe006c0 (LWP 2637904) exited]
[New Thread 0x7fffcbe006c0 (LWP 2638132)]
[New Thread 0x7fffd6a006c0 (LWP 2638133)]
[New Thread 0x7fffcb4006c0 (LWP 2638155)]
[Thread 0x7fffcb4006c0 (LWP 2638155) exited]
[New Thread 0x7fffca0006c0 (LWP 2638156)]
[New Thread 0x7fffcb4006c0 (LWP 2638157)]
[New Thread 0x7fffc8c006c0 (LWP 2638158)]
[New Thread 0x7fffb3e006c0 (LWP 2638159)]
[New Thread 0x7fffb34006c0 (LWP 2638160)]
[New Thread 0x7fffb2a006c0 (LWP 2638161)]
[New Thread 0x7fffb20006c0 (LWP 2638162)]
[New Thread 0x7fffb16006c0 (LWP 2638163)]

Thread 38 "AudioEngine 1" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd4c006c0 (LWP 2637999)]
get_buffer_output (buf=0x0, stride=4, frames=<optimized out>, p=0x555556ce86f0) at ../pipewire/pipewire-jack/src/pipewire-jack.c:1517

                                                                                                                                                                                                            
1517 d->chunk->offset = 0;

Thread 53 (Thread 0x7fffb16006c0 (LWP 2638163) "RT-6-(nil)"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait (this=0x555558fdc604) at ../libs/pbd/semutils.cc:120
#2 PBD::Semaphore::wait (this=this@entry=0x555558fdc604) at ../libs/pbd/semutils.cc:117
#3 0x00007ffff768d4a6 in ARDOUR::Graph::run_one (this=this@entry=0x555558fdc4d0) at ../libs/ardour/graph.cc:320
0000004 0x00007ffff7696359 in ARDOUR::Graph::helper_thread (this=0x555558fdc4d0) at ../libs/ardour/graph.cc:372
0000005 0x00007fffecc97a02 in boost::function0<void>::operator() (this=0x7fffb15f7b50) at /usr/include/boost/function/function_template.hpp:771
#6 ARDOUR::JACKAudioBackend::_start_process_thread (arg=<optimized out>) at ../libs/backends/jack/jack_audiobackend.cc:970
#7 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
0000008 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 52 (Thread 0x7fffb20006c0 (LWP 2638162) "RT-5-(nil)"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait (this=0x555558fdc604) at ../libs/pbd/semutils.cc:120
#2 PBD::Semaphore::wait (this=this@entry=0x555558fdc604) at ../libs/pbd/semutils.cc:117
#3 0x00007ffff768d4a6 in ARDOUR::Graph::run_one (this=this@entry=0x555558fdc4d0) at ../libs/ardour/graph.cc:320
0000004 0x00007ffff7696359 in ARDOUR::Graph::helper_thread (this=0x555558fdc4d0) at ../libs/ardour/graph.cc:372
0000005 0x00007fffecc97a02 in boost::function0<void>::operator() (this=0x7fffb1ff7b50) at /usr/include/boost/function/function_template.hpp:771
#6 ARDOUR::JACKAudioBackend::_start_process_thread (arg=<optimized out>) at ../libs/backends/jack/jack_audiobackend.cc:970
#7 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
0000008 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 51 (Thread 0x7fffb2a006c0 (LWP 2638161) "RT-4-(nil)"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait (this=0x555558fdc604) at ../libs/pbd/semutils.cc:120
#2 PBD::Semaphore::wait (this=this@entry=0x555558fdc604) at ../libs/pbd/semutils.cc:117
#3 0x00007ffff768d4a6 in ARDOUR::Graph::run_one (this=this@entry=0x555558fdc4d0) at ../libs/ardour/graph.cc:320
0000004 0x00007ffff7696359 in ARDOUR::Graph::helper_thread (this=0x555558fdc4d0) at ../libs/ardour/graph.cc:372
0000005 0x00007fffecc97a02 in boost::function0<void>::operator() (this=0x7fffb29f7b50) at /usr/include/boost/function/function_template.hpp:771
#6 ARDOUR::JACKAudioBackend::_start_process_thread (arg=<optimized out>) at ../libs/backends/jack/jack_audiobackend.cc:970
#7 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
0000008 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 50 (Thread 0x7fffb34006c0 (LWP 2638160) "RT-3-(nil)"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait (this=0x555558fdc604) at ../libs/pbd/semutils.cc:120
#2 PBD::Semaphore::wait (this=this@entry=0x555558fdc604) at ../libs/pbd/semutils.cc:117
#3 0x00007ffff768d4a6 in ARDOUR::Graph::run_one (this=this@entry=0x555558fdc4d0) at ../libs/ardour/graph.cc:320
0000004 0x00007ffff7696359 in ARDOUR::Graph::helper_thread (this=0x555558fdc4d0) at ../libs/ardour/graph.cc:372
0000005 0x00007fffecc97a02 in boost::function0<void>::operator() (this=0x7fffb33f7b50) at /usr/include/boost/function/function_template.hpp:771
#6 ARDOUR::JACKAudioBackend::_start_process_thread (arg=<optimized out>) at ../libs/backends/jack/jack_audiobackend.cc:970
#7 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
0000008 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 49 (Thread 0x7fffb3e006c0 (LWP 2638159) "RT-2-(nil)"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait (this=0x555558fdc604) at ../libs/pbd/semutils.cc:120
#2 PBD::Semaphore::wait (this=this@entry=0x555558fdc604) at ../libs/pbd/semutils.cc:117
#3 0x00007ffff768d4a6 in ARDOUR::Graph::run_one (this=this@entry=0x555558fdc4d0) at ../libs/ardour/graph.cc:320
0000004 0x00007ffff7696359 in ARDOUR::Graph::helper_thread (this=0x555558fdc4d0) at ../libs/ardour/graph.cc:372
0000005 0x00007fffecc97a02 in boost::function0<void>::operator() (this=0x7fffb3df7b50) at /usr/include/boost/function/function_template.hpp:771
#6 ARDOUR::JACKAudioBackend::_start_process_thread (arg=<optimized out>) at ../libs/backends/jack/jack_audiobackend.cc:970
#7 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
0000008 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 48 (Thread 0x7fffc8c006c0 (LWP 2638158) "RT-1-(nil)"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait (this=0x555558fdc604) at ../libs/pbd/semutils.cc:120
#2 PBD::Semaphore::wait (this=this@entry=0x555558fdc604) at ../libs/pbd/semutils.cc:117
#3 0x00007ffff768d4a6 in ARDOUR::Graph::run_one (this=this@entry=0x555558fdc4d0) at ../libs/ardour/graph.cc:320
0000004 0x00007ffff7696359 in ARDOUR::Graph::helper_thread (this=0x555558fdc4d0) at ../libs/ardour/graph.cc:372
0000005 0x00007fffecc97a02 in boost::function0<void>::operator() (this=0x7fffc8bf7b50) at /usr/include/boost/function/function_template.hpp:771
#6 ARDOUR::JACKAudioBackend::_start_process_thread (arg=<optimized out>) at ../libs/backends/jack/jack_audiobackend.cc:970
#7 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
0000008 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 47 (Thread 0x7fffcb4006c0 (LWP 2638157) "RT-main-(nil)"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6f5ed1b in PBD::Semaphore::wait (this=0x555558fdc610) at ../libs/pbd/semutils.cc:120
#2 PBD::Semaphore::wait (this=this@entry=0x555558fdc610) at ../libs/pbd/semutils.cc:117
#3 0x00007ffff76961ab in ARDOUR::Graph::main_thread (this=0x555558fdc4d0) at ../libs/ardour/graph.cc:403
0000004 0x00007fffecc97a02 in boost::function0<void>::operator() (this=0x7fffcb3f7b50) at /usr/include/boost/function/function_template.hpp:771
0000005 ARDOUR::JACKAudioBackend::_start_process_thread (arg=<optimized out>) at ../libs/backends/jack/jack_audiobackend.cc:970
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 46 (Thread 0x7fffca0006c0 (LWP 2638156) "ArdourGUI"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408487 in g_cond_wait (cond=0x55555dc01ac8, mutex=0x55555dc01ac0) at ../glib/glib/gthread-posix.c:1552
#2 0x00007ffff6378454 in g_async_queue_pop_intern_unlocked (queue=0x55555dc01ac0, wait=1, end_time=-1) at ../glib/glib/gasyncqueue.c:375
#3 0x00007ffff63784bc in g_async_queue_pop (queue=queue@entry=0x55555dc01ac0) at ../glib/glib/gasyncqueue.c:409
0000004 0x00007ffff5bd6c48 in fc_thread_func (data=0x55555dc01ac0) at ../pango/pango/pangofc-fontmap.c:959
0000005 0x00007ffff63dc065 in g_thread_proxy (data=0x555557a890c0) at ../glib/glib/gthread.c:835
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 44 (Thread 0x7fffd6a006c0 (LWP 2638133) "pool-ardour-8.4"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408e43 in g_cond_wait_until (cond=<optimized out>, mutex=0x5555569f0650, end_time=<optimized out>) at ../glib/glib/gthread-posix.c:1677
#2 0x00007ffff6378425 in g_async_queue_pop_intern_unlocked (queue=0x5555569f0650, wait=1, end_time=229041177068) at ../glib/glib/gasyncqueue.c:378
#3 0x00007ffff63e1c1b in g_thread_pool_wait_for_new_task (pool=0x555556ab0e60) at ../glib/glib/gthreadpool.c:260
0000004 g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/glib/gthreadpool.c:325
0000005 0x00007ffff63dc065 in g_thread_proxy (data=0x7fffac0068f0) at ../glib/glib/gthread.c:835
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 43 (Thread 0x7fffcbe006c0 (LWP 2638132) "pool-ardour-8.4"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408e43 in g_cond_wait_until (cond=<optimized out>, mutex=0x5555569f0650, end_time=<optimized out>) at ../glib/glib/gthread-posix.c:1677
#2 0x00007ffff6378425 in g_async_queue_pop_intern_unlocked (queue=0x5555569f0650, wait=1, end_time=229041177087) at ../glib/glib/gasyncqueue.c:378
#3 0x00007ffff63e1c1b in g_thread_pool_wait_for_new_task (pool=0x555556ab0e60) at ../glib/glib/gthreadpool.c:260
0000004 g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/glib/gthreadpool.c:325
0000005 0x00007ffff63dc065 in g_thread_proxy (data=0x7fffac001390) at ../glib/glib/gthread.c:835
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 42 (Thread 0x7fffcaa006c0 (LWP 2638112) "ArdourGUI"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408487 in g_cond_wait (cond=0x55555aa59028, mutex=0x55555aa59020) at ../glib/glib/gthread-posix.c:1552
#2 0x00007ffff6378454 in g_async_queue_pop_intern_unlocked (queue=0x55555aa59020, wait=1, end_time=-1) at ../glib/glib/gasyncqueue.c:375
#3 0x00007ffff63784bc in g_async_queue_pop (queue=queue@entry=0x55555aa59020) at ../glib/glib/gasyncqueue.c:409
0000004 0x00007ffff5bd6c48 in fc_thread_func (data=0x55555aa59020) at ../pango/pango/pangofc-fontmap.c:959
0000005 0x00007ffff63dc065 in g_thread_proxy (data=0x55555787df80) at ../glib/glib/gthread.c:835
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 40 (Thread 0x7fffd56006c0 (LWP 2638110) "pool-ardour-8.4"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408e43 in g_cond_wait_until (cond=<optimized out>, mutex=0x5555569f0650, end_time=<optimized out>) at ../glib/glib/gthread-posix.c:1677
#2 0x00007ffff6378425 in g_async_queue_pop_intern_unlocked (queue=0x5555569f0650, wait=1, end_time=229041177067) at ../glib/glib/gasyncqueue.c:378
#3 0x00007ffff63e1c1b in g_thread_pool_wait_for_new_task (pool=0x555556ab0e60) at ../glib/glib/gthreadpool.c:260
0000004 g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/glib/gthreadpool.c:325
0000005 0x00007ffff63dc065 in g_thread_proxy (data=0x7fffac0066b0) at ../glib/glib/gthread.c:835
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 38 (Thread 0x7fffd4c006c0 (LWP 2637999) "AudioEngine 1"):
#0 get_buffer_output (buf=0x0, stride=4, frames=<optimized out>, p=0x555556ce86f0) at ../pipewire/pipewire-jack/src/pipewire-jack.c:1517
0000001 get_buffer_output_float (p=0x555556ce86f0, frames=<optimized out>) at ../pipewire/pipewire-jack/src/pipewire-jack.c:5283
#2 0x00007fffecca3c23 in ARDOUR::JACKAudioBackend::get_buffer (this=<optimized out>, port=..., nframes=256) at ../libs/backends/jack/jack_portengine.cc:742
#3 0x00007ffff77f2dd8 in ARDOUR::PortManager::silence_outputs (this=0x55555676e640, nframes=256) at ../libs/ardour/port_manager.cc:1387
0000004 0x00007ffff7594853 in ARDOUR::AudioEngine::process_callback (this=0x55555676e640, nframes=nframes@entry=256) at ../libs/ardour/audioengine.cc:488
0000005 0x00007fffecc9ec95 in ARDOUR::JACKAudioBackend::process_thread (this=0x555556ed3760) at ../libs/backends/jack/jack_audiobackend.cc:1003
#6 0x00007ffff65123f5 in loop_iterate_cancel (object=<optimized out>, timeout=<optimized out>) at ../pipewire/spa/plugins/support/loop.c:454
#7 0x00007ffff2f5fe52 in do_loop (user_data=0x555556b97ed0) at ../pipewire/src/pipewire/data-loop.c:65
0000008 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
0000009 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 37 (Thread 0x7fffd74006c0 (LWP 2637998) "pw-ardour"):
#0 0x00007ffff551de66 in epoll_wait (epfd=27, events=events@entry=0x7fffd73f7770, maxevents=32, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
0000001 0x00007ffff6520cf9 in impl_pollfd_wait (object=<optimized out>, pfd=<optimized out>, ev=0x7fffd73f7940, n_ev=<optimized out>, timeout=<optimized out>) at ../pipewire/spa/plugins/support/system.c:137
#2 0x00007ffff651258d in loop_iterate (object=0x555556c6bbb8, timeout=-1) at ../pipewire/spa/plugins/support/loop.c:471
#3 0x00007ffff2fa709d in do_loop (user_data=0x555556ab2600) at ../pipewire/src/pipewire/thread-loop.c:295
0000004 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
0000005 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 36 (Thread 0x7fffd60006c0 (LWP 2637997) "pw-ardour"):
#0 0x00007ffff551de66 in epoll_wait (epfd=19, events=events@entry=0x7fffd5ff7770, maxevents=32, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
0000001 0x00007ffff6520cf9 in impl_pollfd_wait (object=<optimized out>, pfd=<optimized out>, ev=0x7fffd5ff7940, n_ev=<optimized out>, timeout=<optimized out>) at ../pipewire/spa/plugins/support/system.c:137
#2 0x00007ffff651258d in loop_iterate (object=0x555556c5b8d8, timeout=-1) at ../pipewire/spa/plugins/support/loop.c:471
#3 0x00007ffff2fa709d in do_loop (user_data=0x555556b5ab50) at ../pipewire/src/pipewire/thread-loop.c:295
0000004 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
0000005 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 34 (Thread 0x7fffc96006c0 (LWP 2637908) "threaded-ml"):
#0 0x00007ffff55100bf in __GI___poll (fds=fds@entry=0x7fff640071d0, nfds=nfds@entry=2, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff338d9b7 in poll (__timeout=-1, __nfds=2, __fds=0x7fff640071d0) at /usr/include/bits/poll2.h:39
#2 poll_func (ufds=0x7fff640071d0, nfds=2, timeout=-1, userdata=0x555556bdb280) at ../pulseaudio/src/pulse/thread-mainloop.c:70
#3 0x00007ffff337745c in pa_mainloop_poll (m=m@entry=0x555556bb5380) at ../pulseaudio/src/pulse/mainloop.c:863
0000004 0x00007ffff338161c in pa_mainloop_iterate (m=m@entry=0x555556bb5380, block=block@entry=1, retval=retval@entry=0x0) at ../pulseaudio/src/pulse/mainloop.c:945
0000005 0x00007ffff33816d1 in pa_mainloop_run (m=0x555556bb5380, retval=0x0) at ../pulseaudio/src/pulse/mainloop.c:963
#6 0x00007ffff3391bf2 in thread (userdata=0x555556bb5330) at ../pulseaudio/src/pulse/thread-mainloop.c:101
#7 0x00007ffff27c42b7 in internal_thread_func (userdata=0x555556bb5660) at ../pulseaudio/src/pulsecore/thread-posix.c:81
0000008 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
0000009 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 24 (Thread 0x7fffd7e006c0 (LWP 2637898) "gdbus"):
#0 0x00007ffff55100bf in __GI___poll (fds=0x7fffa0000b90, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff640d306 in g_main_context_poll_unlocked (priority=2147483647, n_fds=2, fds=0x7fffa0000b90, timeout=<optimized out>, context=0x555556ae32a0) at ../glib/glib/gmain.c:4521
#2 g_main_context_iterate_unlocked.isra.0 (context=0x555556ae32a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:4212
#3 0x00007ffff63aedc7 in g_main_loop_run (loop=0x555556ae3010) at ../glib/glib/gmain.c:4419
0000004 0x00007ffff4bb383c in gdbus_shared_thread_func (user_data=0x555556ae3270) at ../glib/gio/gdbusprivate.c:284
0000005 0x00007ffff63dc065 in g_thread_proxy (data=0x555556ae33a0) at ../glib/glib/gthread.c:835
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 23 (Thread 0x7fffe10006c0 (LWP 2637897) "gmain"):
#0 0x00007ffff55100bf in __GI___poll (fds=0x555556ad2e80, nfds=2, timeout=7273) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff640d306 in g_main_context_poll_unlocked (priority=2147483647, n_fds=2, fds=0x555556ad2e80, timeout=<optimized out>, context=0x555556ad2be0) at ../glib/glib/gmain.c:4521
#2 g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x555556ad2be0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:4212
#3 0x00007ffff63ad712 in g_main_context_iteration (context=0x555556ad2be0, may_block=may_block@entry=1) at ../glib/glib/gmain.c:4282
0000004 0x00007ffff63ad762 in glib_worker_main (data=<optimized out>) at ../glib/glib/gmain.c:6442
0000005 0x00007ffff63dc065 in g_thread_proxy (data=0x555556ad2e20) at ../glib/glib/gthread.c:835
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 22 (Thread 0x7fffe2e006c0 (LWP 2637896) "pool-spawner"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408487 in g_cond_wait (cond=0x555556ad1de8, mutex=0x555556ad1de0) at ../glib/glib/gthread-posix.c:1552
#2 0x00007ffff6378454 in g_async_queue_pop_intern_unlocked (queue=0x555556ad1de0, wait=1, end_time=-1) at ../glib/glib/gasyncqueue.c:375
#3 0x00007ffff63dd29e in g_thread_pool_spawn_thread (data=<optimized out>) at ../glib/glib/gthreadpool.c:297
0000004 0x00007ffff63dc065 in g_thread_proxy (data=0x555556a990f0) at ../glib/glib/gthread.c:835
0000005 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#6 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 15 (Thread 0x7fffe24006c0 (LWP 2637889) "ArdourGUI"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408487 in g_cond_wait (cond=0x555556e4afb8, mutex=0x555556e4afb0) at ../glib/glib/gthread-posix.c:1552
#2 0x00007ffff6378454 in g_async_queue_pop_intern_unlocked (queue=0x555556e4afb0, wait=1, end_time=-1) at ../glib/glib/gasyncqueue.c:375
#3 0x00007ffff63784bc in g_async_queue_pop (queue=queue@entry=0x555556e4afb0) at ../glib/glib/gasyncqueue.c:409
0000004 0x00007ffff5bd6c48 in fc_thread_func (data=0x555556e4afb0) at ../pango/pango/pangofc-fontmap.c:959
0000005 0x00007ffff63dc065 in g_thread_proxy (data=0x555556e16230) at ../glib/glib/gthread.c:835
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 14 (Thread 0x7fffe1a006c0 (LWP 2637888) "ArdourGUI"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408487 in g_cond_wait (cond=0x555556f5aae8, mutex=0x555556f5aae0) at ../glib/glib/gthread-posix.c:1552
#2 0x00007ffff6378454 in g_async_queue_pop_intern_unlocked (queue=0x555556f5aae0, wait=1, end_time=-1) at ../glib/glib/gasyncqueue.c:375
#3 0x00007ffff63784bc in g_async_queue_pop (queue=queue@entry=0x555556f5aae0) at ../glib/glib/gasyncqueue.c:409
0000004 0x00007ffff5bd6c48 in fc_thread_func (data=0x555556f5aae0) at ../pango/pango/pangofc-fontmap.c:959
0000005 0x00007ffff63dc065 in g_thread_proxy (data=0x555556f49760) at ../glib/glib/gthread.c:835
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 10 (Thread 0x7fffecc006c0 (LWP 2637846) "DeviceList"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408487 in g_cond_wait (cond=0x55555676f080, mutex=0x55555676f090) at ../glib/glib/gthread-posix.c:1552
#2 0x00007ffff7594b38 in ARDOUR::AudioEngine::do_devicelist_update (this=0x55555676e640) at ../libs/ardour/audioengine.cc:760
#3 0x00007ffff6f5cbda in boost::function0<void>::operator() (this=0x555556780778) at /usr/include/boost/function/function_template.hpp:771
0000004 PBD::Thread::_run (arg=0x555556780750) at ../libs/pbd/pthread_utils.cc:488
0000005 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#6 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 9 (Thread 0x7fffed6006c0 (LWP 2637845) "EngineWatchdog"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408487 in g_cond_wait (cond=0x55555676f050, mutex=0x55555676f060) at ../glib/glib/gthread-posix.c:1552
#2 0x00007ffff7595ce8 in ARDOUR::AudioEngine::do_reset_backend (this=0x55555676e640) at ../libs/ardour/audioengine.cc:724
#3 0x00007ffff6f5cbda in boost::function0<void>::operator() (this=0x5555567809b8) at /usr/include/boost/function/function_template.hpp:771
0000004 PBD::Thread::_run (arg=0x555556780990) at ../libs/pbd/pthread_utils.cc:488
0000005 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#6 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 6 (Thread 0x7fffee0006c0 (LWP 2637823) "Analyzer"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408487 in g_cond_wait (cond=0x7ffff7ead3e0 <ARDOUR::Analyser::SourcesToAnalyse>, mutex=0x7ffff7ead3d8 <ARDOUR::Analyser::analysis_queue_lock>) at ../glib/glib/gthread-posix.c:1552
#2 0x00007ffff7572cac in ARDOUR::Analyser::work () at ../libs/ardour/analyser.cc:95
#3 0x00007ffff6f5cbda in boost::function0<void>::operator() (this=0x5555567423b8) at /usr/include/boost/function/function_template.hpp:771
0000004 PBD::Thread::_run (arg=0x555556742390) at ../libs/pbd/pthread_utils.cc:488
0000005 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#6 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 5 (Thread 0x7fffeea006c0 (LWP 2637822) "PeakFileBuilder"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408487 in g_cond_wait (cond=0x7ffff7eaf780 <ARDOUR::SourceFactory::PeaksToBuild>, mutex=0x7ffff7eaf798 <ARDOUR::SourceFactory::peak_building_lock>) at ../glib/glib/gthread-posix.c:1552
#2 0x00007ffff793af23 in peak_thread_work () at ../libs/ardour/source_factory.cc:75
#3 0x00007ffff6f5cbda in boost::function0<void>::operator() (this=0x555556742898) at /usr/include/boost/function/function_template.hpp:771
0000004 PBD::Thread::_run (arg=0x555556742870) at ../libs/pbd/pthread_utils.cc:488
0000005 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#6 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 4 (Thread 0x7fffef4006c0 (LWP 2637821) "PeakFileBuilder"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6408487 in g_cond_wait (cond=0x7ffff7eaf780 <ARDOUR::SourceFactory::PeaksToBuild>, mutex=0x7ffff7eaf798 <ARDOUR::SourceFactory::peak_building_lock>) at ../glib/glib/gthread-posix.c:1552
#2 0x00007ffff793af23 in peak_thread_work () at ../libs/ardour/source_factory.cc:75
#3 0x00007ffff6f5cbda in boost::function0<void>::operator() (this=0x555556742d78) at /usr/include/boost/function/function_template.hpp:771
0000004 PBD::Thread::_run (arg=0x555556742d50) at ../libs/pbd/pthread_utils.cc:488
0000005 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#6 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 3 (Thread 0x7fffefe006c0 (LWP 2637820) "LXVSTEventLoop"):
#0 0x00007ffff54e9335 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffefdf7950, rem=rem@entry=0x7fffefdf7960) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
0000001 0x00007ffff54f43e7 in __GI___nanosleep (req=req@entry=0x7fffefdf7950, rem=rem@entry=0x7fffefdf7960) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2 0x00007ffff63ddd09 in g_usleep (microseconds=<optimized out>) at ../glib/glib/gtimer.c:275
#3 g_usleep (microseconds=<optimized out>) at ../glib/glib/gtimer.c:263
0000004 0x00005555561c8a27 in gui_event_loop (ptr=<optimized out>) at ../gtk2_ardour/linux_vst_gui_support.cc:468
0000005 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#6 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 2 (Thread 0x7ffff05ff6c0 (LWP 2637819) "Trigger Worker"):
#0 0x00007ffff55100bf in __GI___poll (fds=fds@entry=0x7ffff05f6aa0, nfds=nfds@entry=1, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff6f48add in poll (__timeout=-1, __nfds=1, __fds=0x7ffff05f6aa0) at /usr/include/bits/poll2.h:39
#2 CrossThreadChannel::poll_for_request (this=<optimized out>) at ../libs/pbd/crossthread.posix.cc:108
#3 0x00007ffff6f48b63 in CrossThreadChannel::receive (this=this@entry=0x55555670d1a0, msg=@0x7ffff05f6b07: 0 '\000', wait=wait@entry=true) at ../libs/pbd/crossthread.posix.cc:133
0000004 0x00007ffff7989284 in ARDOUR::TriggerBoxThread::thread_work (this=0x55555670d170) at ../libs/ardour/triggerbox.cc:4880
0000005 0x00007ffff6f5cb2a in fake_thread_start (arg=0x5555566569d0) at ../libs/pbd/pthread_utils.cc:101
#6 0x00007ffff54a055a in start_thread (arg=<optimized out>) at pthread_create.c:447
#7 0x00007ffff551da3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 1 (Thread 0x7ffff06e1a80 (LWP 2637749) "ArdourGUI"):
#0 __GI___getdents64 (fd=42, buf=buf@entry=0x555558f340f0, nbytes=<optimized out>) at ../sysdeps/unix/sysv/linux/getdents64.c:32
0000001 0x00007ffff54e9f3e in __GI___readdir64 (dirp=0x555558f340c0) at ../sysdeps/unix/sysv/linux/readdir64.c:47
#2 0x00007ffff638f0a7 in g_dir_read_name (dir=0x555558c0aa00) at ../glib/glib/gdir.c:269
#3 0x00007ffff62d95ce in Glib::Dir::begin (this=this@entry=0x7fffffffac78) at glib/glibmm/fileutils.cc:80
0000004 0x00007ffff78cdf04 in ARDOUR::SessionDirectory::sources_root[abi:cxx11]() const (this=0x555557cdcea0) at ../libs/ardour/session_directory.cc:151
0000005 0x00007ffff78ce519 in ARDOUR::SessionDirectory::sound_path[abi:cxx11]() const (this=0x555557cdcea0) at ../libs/ardour/session_directory.cc:208
#6 0x00007ffff78e6731 in ARDOUR::Session::ensure_subdirs (this=0x555558fe12e0) at /usr/include/boost/smart_ptr/scoped_ptr.hpp:110
#7 0x00007ffff78818a0 in ARDOUR::Session::Session (this=this@entry=0x555558fe12e0, eng=<optimized out>, fullpath="/home/user/Documents/ardour/why_crash", snapshot_name="why_crash", bus_profile=bus_profile@entry=0x0, mix_template="", unnamed=<optimized out>, sr=<optimized out>, this=<optimized out>, eng=<optimized out>, fullpath=<optimized out>, snapshot_name=<optimized out>, bus_profile=<optimized out>, mix_template=Python Exception <class 'gdb.error'>: value has been optimized out
, unnamed=<optimized out>, sr=<optimized out>) at ../libs/ardour/session.cc:442
0000008 0x0000555555a26a2f in ARDOUR_UI::load_session_stage_two (this=0x555556d63280, path="/home/user/Documents/ardour/why_crash", snap_name="why_crash", mix_template="") at ../gtk2_ardour/ardour_ui_session.cc:410
0000009 0x00005555561e81d7 in ARDOUR_UI::load_session(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) [clone .constprop.0] (this=this@entry=0x555556d63280, path="/home/user/Documents/ardour/why_crash", snap_name="why_crash", mix_template="") at ../gtk2_ardour/ardour_ui_session.cc:379
0000010 0x0000555555a38f9b in ARDOUR_UI::load_session_from_startup_fsm (this=0x555556d63280) at ../gtk2_ardour/ardour_ui_startup.cc:702
0000011 ARDOUR_UI::sfsm_response (this=0x555556d63280, r=<optimized out>) at ../gtk2_ardour/ardour_ui_startup.cc:555
0000012 0x0000555555981d8d in sigc::internal::signal_emit1<void, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, sigc::nil>::emit (impl=0x5555569f26e0, _A_a1=...) at /usr/include/sigc++-2.0/sigc++/signal.h:1041
0000013 0x00005555560d6bb3 in sigc::signal1<void, StartupFSM::Result, sigc::nil>::emit (_A_a1=@0x7fffffffc360: StartupFSM::LoadSession, this=0x555556d9d4b0) at /usr/include/sigc++-2.0/sigc++/signal.h:2960
0000014 sigc::signal1<void, StartupFSM::Result, sigc::nil>::operator() (_A_a1=@0x7fffffffc360: StartupFSM::LoadSession, this=0x555556d9d4b0) at /usr/include/sigc++-2.0/sigc++/signal.h:2977
#15 StartupFSM::dialog_response_handler (this=0x555556d9d360, response=-5, dialog_id=<optimized out>) at ../gtk2_ardour/startup_fsm.cc:337
0000016 0x00007ffff6d98b3d in sigc::slot1<void, int>::operator() (_A_a1=@0x7fffffffc4ac: -5, this=0x555556c567b8) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:675
#17 (anonymous namespace)::Dialog_signal_response_callback (self=<optimized out>, p0=<optimized out>, data=0x555556c567b0) at ../libs/tk/ytkmm/dialog.cc:85
0000018 0x00007ffff61aa730 in g_closure_invoke (closure=0x555556b5e900, return_value=0x0, n_param_values=2, param_values=0x7fffffffc690, invocation_hint=0x7fffffffc5e0) at ../glib/gobject/gclosure.c:834
0000019 0x00007ffff61d9c1b in signal_emit_unlocked_R.isra.0 (node=node@entry=0x7fffffffc780, detail=detail@entry=0, instance=instance@entry=0x555556ba6ed0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc690) at ../glib/gobject/gsignal.c:3961
0000020 0x00007ffff61ca7a2 in signal_emit_valist_unlocked (instance=instance@entry=0x555556ba6ed0, signal_id=signal_id@entry=89, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffc8e0) at ../glib/gobject/gsignal.c:3520
0000021 0x00007ffff61ca9d7 in g_signal_emit_valist (instance=0x555556ba6ed0, signal_id=89, detail=0, var_args=var_args@entry=0x7fffffffc8e0) at ../glib/gobject/gsignal.c:3263
0000022 0x00007ffff61caa94 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../glib/gobject/gsignal.c:3583
0000023 0x00005555560d3448 in StartupFSM::start_audio_midi_setup (this=0x555556d9d360) at ../gtk2_ardour/startup_fsm.cc:541
#24 0x00007ffff6d98b3d in sigc::slot1<void, int>::operator() (_A_a1=@0x7fffffffcb1c: -3, this=0x555556b66078) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:675
0000025 (anonymous namespace)::Dialog_signal_response_callback (self=<optimized out>, p0=<optimized out>, data=0x555556b66070) at ../libs/tk/ytkmm/dialog.cc:85
0000026 0x00007ffff61aa730 in g_closure_invoke (closure=0x555556b66b80, return_value=0x0, n_param_values=2, param_values=0x7fffffffcd00, invocation_hint=0x7fffffffcc50) at ../glib/gobject/gclosure.c:834
0000027 0x00007ffff61d9c1b in signal_emit_unlocked_R.isra.0 (node=node@entry=0x7fffffffcdf0, detail=detail@entry=0, instance=instance@entry=0x555556ab0cb0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffcd00) at ../glib/gobject/gsignal.c:3961
0000028 0x00007ffff61ca7a2 in signal_emit_valist_unlocked (instance=instance@entry=0x555556ab0cb0, signal_id=signal_id@entry=89, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffcf50) at ../glib/gobject/gsignal.c:3520
0000029 0x00007ffff61ca9d7 in g_signal_emit_valist (instance=0x555556ab0cb0, signal_id=89, detail=0, var_args=var_args@entry=0x7fffffffcf50) at ../glib/gobject/gsignal.c:3263
0000030 0x00007ffff61caa94 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../glib/gobject/gsignal.c:3583
0000031 0x00007ffff6e20615 in sigc::slot2<void, Gtk::TreePath const&, Gtk::TreeViewColumn*>::operator() (_A_a2=@0x7fffffffd038: 0x555556b66ee0, _A_a1=..., this=0x555556ab1c78) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:813
0000032 (anonymous namespace)::TreeView_signal_row_activated_callback (self=<optimized out>, p0=0x555556c5a060, p1=<optimized out>, data=0x555556ab1c70) at ../libs/tk/ytkmm/treeview.cc:550
0000033 0x00007ffff61aa730 in g_closure_invoke (closure=0x555556b708c0, return_value=0x0, n_param_values=3, param_values=0x7fffffffd240, invocation_hint=0x7fffffffd190) at ../glib/gobject/gclosure.c:834
0000034 0x00007ffff61d9c1b in signal_emit_unlocked_R.isra.0 (node=node@entry=0x7fffffffd340, detail=detail@entry=0, instance=instance@entry=0x555556ab2cd0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd240) at ../glib/gobject/gsignal.c:3961
0000035 0x00007ffff61ca7a2 in signal_emit_valist_unlocked (instance=instance@entry=0x555556ab2cd0, signal_id=signal_id@entry=117, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffd4a0) at ../glib/gobject/gsignal.c:3520
0000036 0x00007ffff61ca9d7 in g_signal_emit_valist (instance=0x555556ab2cd0, signal_id=117, detail=0, var_args=var_args@entry=0x7fffffffd4a0) at ../glib/gobject/gsignal.c:3263
0000037 0x00007ffff61caa94 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../glib/gobject/gsignal.c:3583
0000038 0x00007ffff68deb91 in gtk_tree_view_button_press (widget=0x555556ab2cd0 [gtkmm__GtkTreeView], event=0x555556b78990) at ../libs/tk/ytk/gtktreeview.c:2887
0000039 0x00007ffff677a2bb in _gtk_marshal_BOOLEAN__BOXED (closure=0x555556d9a4e0, return_value=0x7fffffffd7e0, n_param_values=<optimized out>, param_values=0x7fffffffd870, invocation_hint=<optimized out>, marshal_data=<optimized out>) at ../libs/tk/ytk/gtkmarshalers.c:84
0000040 0x00007ffff61aa730 in g_closure_invoke (closure=0x555556d9a4e0, return_value=0x7fffffffd7e0, n_param_values=2, param_values=0x7fffffffd870, invocation_hint=0x7fffffffd7c0) at ../glib/gobject/gclosure.c:834
0000041 0x00007ffff61d9f4a in signal_emit_unlocked_R.isra.0 (node=node@entry=0x7fffffffd960, detail=detail@entry=0, instance=instance@entry=0x555556ab2cd0, emission_return=emission_return@entry=0x7fffffffd9e0, instance_and_params=instance_and_params@entry=0x7fffffffd870) at ../glib/gobject/gsignal.c:3928
0000042 0x00007ffff61ca095 in signal_emit_valist_unlocked (instance=instance@entry=0x555556ab2cd0, signal_id=signal_id@entry=33, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffdac0) at ../glib/gobject/gsignal.c:3533
0000043 0x00007ffff61ca9d7 in g_signal_emit_valist (instance=0x555556ab2cd0, signal_id=33, detail=0, var_args=var_args@entry=0x7fffffffdac0) at ../glib/gobject/gsignal.c:3263
0000044 0x00007ffff61caa94 in g_signal_emit (instance=instance@entry=0x555556ab2cd0, signal_id=<optimized out>, detail=detail@entry=0) at ../glib/gobject/gsignal.c:3583
0000045 0x00007ffff6910a3d in gtk_widget_event_internal (widget=0x555556ab2cd0 [gtkmm__GtkTreeView], event=0x555556b78990) at ../libs/tk/ytk/gtkwidget.c:5010
0000046 0x00007ffff6775d3f in IA__gtk_propagate_event (event=0x555556b78990, widget=0x555556ab2cd0 [gtkmm__GtkTreeView]) at ../libs/tk/ytk/gtkmain.c:2503
0000047 IA__gtk_propagate_event (widget=widget@entry=0x555556ab2cd0 [gtkmm__GtkTreeView], event=event@entry=0x555556b78990) at ../libs/tk/ytk/gtkmain.c:2440
0000048 0x00007ffff6779e2b in IA__gtk_main_do_event (event=0x555556b78990) at ../libs/tk/ytk/gtkmain.c:1698
0000049 0x00007ffff6b48812 in gdk_event_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../libs/tk/ydk/x11/gdkevents-x11.c:2425
0000050 0x00007ffff63ae199 in g_main_dispatch (context=0x555556d3dbe0) at ../glib/glib/gmain.c:3344
0000051 0x00007ffff640d3bf in g_main_context_dispatch_unlocked (context=0x555556d3dbe0) at ../glib/glib/gmain.c:4152
0000052 g_main_context_iterate_unlocked.isra.0 (context=0x555556d3dbe0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:4217
0000053 0x00007ffff63aedc7 in g_main_loop_run (loop=0x555556b9eca0) at ../glib/glib/gmain.c:4419
0000054 0x00007ffff6779283 in IA__gtk_main () at ../libs/tk/ytk/gtkmain.c:1270
0000055 0x00007ffff6fed8a9 in Gtkmm2ext::UI::run (this=this@entry=0x555556d63280, old_receiver=warning: RTTI symbol not found for class 'TextReceiver'
...) at ../libs/gtkmm2ext/gtk_ui.cc:305
0000056 0x0000555555970557 in main (argc=<optimized out>, argv=<optimized out>) at ../gtk2_ardour/main.cc:471
(0028637)
resolutionfu   
2024-04-10 12:22   
Oh, and that error for pipewire appears here:

src/pipewire/core.c starting at line 76:

static void core_event_add_mem(void *data, uint32_t id, uint32_t type, int fd, uint32_t flags)
{
    struct pw_core *this = data;
    struct pw_memblock *m;

    pw_log_debug("%p: add mem %u type:%u fd:%d flags:%08x", this, id, type, fd, flags);

    m = pw_mempool_import(this->pool, flags, type, fd);
    if (m->id != id) {
        pw_log_error("%p: invalid mem id %u, fd:%d expected %u",
                this, id, fd, m->id);
        pw_proxy_errorf(&this->proxy, -EINVAL, "invalid mem id %u, expected %u", id, m->id);
        pw_memblock_unref(m);
    }
}

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9642 [ardour] bugs crash always 2024-02-22 16:00 2024-04-04 21:54
Reporter: skaterodder Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when using file import dialog
Description: Just downloaded/installed 8.4 and was trying to import some WAV files to work on, but each time I browse to the directory via the import dialog, Ardour crashes out before it can list the files in the directory.

However, dragging files into a session from the OS file manager works fine so I assume there’s something afoot with how the import dialog traverses the file tree?
Tags:
Steps To Reproduce: Open new Ardour session -> Bring up import file dialog (Ctrl-I or Session -> import) -> browse to directory of files
Additional Information: Issue seems to only be when using the import dialog flow. Dragging files into the session from the OS file browser (Dolphin in my case) works as expected.
System Description
Attached Files: ardour8.4_debug.log (54,357 bytes) 2024-02-22 16:35
https://tracker.ardour.org/file_download.php?file_id=4794&type=bug
ardour-8_4_11_debug.log (53,958 bytes) 2024-02-23 14:49
https://tracker.ardour.org/file_download.php?file_id=4797&type=bug
ardour8.4.18_debug.zip (60,525 bytes) 2024-02-24 15:20
https://tracker.ardour.org/file_download.php?file_id=4798&type=bug
audio-x-wav.svg (325 bytes) 2024-04-02 01:48
https://tracker.ardour.org/file_download.php?file_id=4817&type=bug
svg
Notes
(0028534)
paul   
2024-02-22 16:02   
Works fine here with 8.4.

Please read https://ardour.org/debugging_ardour and try to provide a full backtrace (you'll need a debug build from nightly.ardour.org - there are free/demo versions available if you're not a subscriber)
(0028535)
skaterodder   
2024-02-22 16:35   
I just downloaded the nightly and ran it through GDB. Output is attached
(0028537)
Daniele1971   
2024-02-22 19:21   
If may help, not issue at all here on openSUSE. Tested wav, flac, mp3 (even with different samplerate).
(0028538)
x42   
2024-02-22 23:30   
OK, I just realized that Ardour's gtk looks up the system theme `gtk_settings_get_for_screen` and queries `gtk-icon-theme`. If unset, the fallback is `hicolor`.
Then icons from /usr/share/icons/THEME-NAME/* are loaded.

So this explains why it works on some systems, but not others. As for why it fails with when loading audio-x-generic xpm is still unclear.
(0028539)
x42   
2024-02-23 00:50   
Can you try if the issue persists with tomorrow's (~12h from now) nightly build Ardour 8.4.11 (or later)? Thanks.
(0028540)
skaterodder   
2024-02-23 04:43   
will do. Thanks!
(0028543)
skaterodder   
2024-02-23 14:49   
just downloaded/installed 8.4.11 nightly. Still having the same issue on import. GDB output is attached.
(0028547)
x42   
2024-02-24 03:27   
Thanks for your patience.

So even with updated gdk-pixbuf that has a fix for "Handle large XPM without crashing" this is still an issue.
Looking at the backtrace I fail to see why this crashes. the buffer is valid, and has 4096 bytes (SNIFF_BUFFER_SIZE). The tmp file also exists, so there is no obvious reason why this fails.

I've enabled GTK debugging in tomorrow's build. This will allow us to see which file it is that causes it. In a terminal window please run

GTK_DEBUG=icontheme Ardour8

That will print theme files as they are being loaded. The last one before the crash should be some XPM file (icon for music files). Apparently that is a rather large file with a file header > 4kB.
Please upload that file so we can continue investigating.
(0028548)
skaterodder   
2024-02-24 05:25   
Thank you all! I'm more than happy to help where I can.

I'll give it a go with tomorrow's build.

Cheers
(0028550)
skaterodder   
2024-02-24 15:14   
8.4.18 gdb output attached

GTK_DEBUG=icontheme Ardour8 --gdb | tee ardour8.4.18_debug.log
(0028551)
skaterodder   
2024-02-24 15:20   
well, I thought it was attached. Maybe there's an attachment file size limit here? I've compressed the file so hopefully this one attaches ;-)
(0028552)
x42   
2024-02-24 21:06   
(Last edited: 2024-02-24 21:15)
OK this is less useful that I hoped. but it shows that Arodur checks 3 top-level theme folders

* /home/dfj/.local/share/icons/hicolor
* /usr/share/icons/Adwaita/
* /usr/share/icons/hicolor/

On my system there are no XPM files in "hicolor" and "Adwaita" system themes. Can you confirm that this is also true on your system
find /usr/share/icons/Adwaita/ /usr/share/icons/hicolor/ -iname "*.xpm"


Can you find the xpm causing the crash?
  grep -rli audio-x-generic /usr/share/icons/Adwaita/ | grep xpm
  grep -rli audio-x-generic /usr/share/icons/hicolor/ | grep xpm
  grep -rli audio-x-generic /home/dfj/.local/share/icons | grep xpm


Does it help to temporarily move away your local icon folder? mv /home/dfj/.local/share/icons home/dfj/.local/share/icons.bak
(0028553)
skaterodder   
2024-02-25 04:22   
Here's the results of my find. Greps returned nothing

find /usr/share/icons/Adwaita/ /usr/share/icons/hicolor/ -iname "*.xpm"
/usr/share/icons/hicolor/16x16/apps/vlc.xpm
/usr/share/icons/hicolor/32x32/apps/vlc-xmas.xpm
/usr/share/icons/hicolor/32x32/apps/vlc.xpm
/usr/share/icons/hicolor/32x32/apps/puredata.xpm
(0028554)
skaterodder   
2024-02-25 04:25   
also - moving local icon folder didn't resolve the issue
(0028614)
coenplanetc   
2024-03-24 15:05   
I have the same issue, Ardour crashes when using Ace Fluidsynth and trying to load/browse for a soundfont file. Also import crashes Ardour.
Two machines, both the same issue on 8.4 (not on 8.2)
Ubuntu studio 23.04 with Plasma session
Ubuntu studio 22.04 with XFDE session (but Plasma installed)
If needed, I can test.

---syslog
2024-03-24T15:50:13.141804+01:00 DAWN kernel: [ 4153.386036] ArdourGUI[6086]: segfault at 63d5bec0 ip 000075889f48245e sp 00007fff7517fb00 error 4 in libc.so.6[75889f426000+17f000] likely on CPU 1 (core 1, socket 0)
2024-03-24T15:50:13.141823+01:00 DAWN kernel: [ 4153.386052] Code: 41 57 41 56 41 55 41 54 55 48 89 f5 53 48 0f af ea 48 83 ec 18 48 85 ed 0f 84 c1 00 00 00 49 89 fe 49 89 f5 49 89 d4 48 89 cb <f7> 01 00 80 00 00 75 4b 48 8b b9 88 00 00 00 80 3d cc 40 18 00 00
2024-03-24T15:50:14.260034+01:00 DAWN kwin_x11[1639]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 55581, resource id: 83888435, major code: 15 (QueryTree), minor code: 0
2024-03-24T15:50:14.261550+01:00 DAWN kwin_x11[1639]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 55611, resource id: 83889693, major code: 15 (QueryTree), minor code: 0
---ardour
Segmentation fault (core dumped)
coen@DAWN:/opt/Ardour-8.4.0/bin$ ardour-request-device: watched PID no longer exists - releasing device.
(0028620)
canau   
2024-03-30 01:15   
Same issue here with 8.4.110-dbg. Ubuntu Studio 22.04. Crash with KDE or GNOME.
Just open in a dialog a directory with any sound file, MP3, MID, ...
GDB and logs similar to the cases above.

If needed, I can test things.
Thanks.
(0028621)
coenplanetc   
2024-03-31 09:11   
musical (16th note) Icon from certain styles do cause the crash, others styles don't.

Adwaita, Breeze, ePapirus, Humanity etc have this icon and Ardour crashes
High Contrast, Gnome, elementary xfce, Oxygen have an other icon and don't crash
(0028622)
Daniele1971   
2024-03-31 21:59   
I use Plasma 6 with Dark Breeze no crash. I did a quick test with Adwaita still no crash. openSUSE TW.
(0028624)
coenplanetc   
2024-04-01 13:53   
Here's one other thing.
I have a (Ubuntu XFCE 22.04) system with also the Adwaita icon theme.
The mime-type icon which is show in Ardour when importing or filebrowsing is a different one on this machine. It's the 512x512 png version (audio-x-generic.png), not the scalable svg icon.
And this png-version gives no problem, no crash.
Why on this system this icon is chosen and not the scalable audio-x-generic-symbolig.svg which is also present, I don't know
I've copied this file to my other system (Ububtu Studio/Plasma) and the problem is "solved". No crash.
(0028625)
paul   
2024-04-01 14:14   
What's the name of the scalable svg icon file?
(0028626)
coenplanetc   
2024-04-01 15:38   
with full path:
/usr/share/icons/Adwaita/scalable/mimetypes/audio-x-generic-symbolic.svg
(0028627)
x42   
2024-04-01 21:18   
The version of gtk-pixbuf that comes with Ardour 8.4 does not support loading SVG. I have limited it to only load PNG, XPM and XBM (icons that Arodur itself uses - I was not thinking about system themes).
(0028628)
ccaudle   
2024-04-02 01:48   
Here is a copy of one of the svg files just for reference. Presumably crashing instead of just gracefully ignoring the unsupported file is just an oversight.
(0028629)
x42   
2024-04-02 08:33   
The backtrace shows the crash happens when loading a XPM file.
(0028630)
Daniele1971   
2024-04-02 16:08   
Here the icon is named "audio-x-generic.svg". There's no icons with "symbolic" in the name.

adwaita-icon-theme-46.0-1.2.noarch
(0028631)
ccaudle   
2024-04-02 16:21   
see note from x42 that the crash occurs with an XPM file, not an SVG file. I was mislead by an entry in the Ardour forums where someone posted that the problem had been narrowed to using adwaita icons rather than gnome icons, and at least on my system the adwaita icon theme only contains png and svg files. Perhaps there are version or distribution specific differences; on my Fedora installation there is only one xpm icon, and that came along with a game installation, so presumably is not present on a lot of Fedora installations.
Note also that I have not had time to try reproducing on my installation, so I probably steered the discussion off track unintentionally by putting too much emphasis on that web forum post which claimed svg was the problem and uploading the audio svg icon in an attempt to be helpful, which maybe was just distracting rather than helpful.
(0028633)
x42   
2024-04-04 11:00   
OK, with Ubuntu VM, I found the icon file causing the issue: /usr/share/pixmaps/audio-x-generic.xpm (file comes from aeolus - the organ synth)

Until the issue is fixed, you can work-around this by making that file unreadable (sudo chmod 0 /usr/share/pixmaps/audio-x-generic.xpm) or move it away.
(0028634)
x42   
2024-04-04 20:57   
(Last edited: 2024-04-04 21:54)
This should be fixed since 8.4.118

Please test, https://nightly.ardour.org/ builds will be up around 8 hours from now.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9683 [ardour] bugs major always 2024-04-03 14:57 2024-04-03 14:57
Reporter: loyak Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tiny cursor on HIDPI monitor
Description: I just installed the ready-to-run binary of Ardour from the site. On my 2560x1440 monitor it scales fine, but the mouse cursor remains unscaled. I'm running X11.

As you can see in the attached video, the problem occurs with the Ardour's cursor, the system one is fine.
So there should be a way to resize Ardour's cursors, since this way it's unusable.
Tags: cursor, hidpi, Linux
Steps To Reproduce: 1. Opens Ardour on a HIDPI monitor.
2. Apply scaling.
Additional Information: Seems to be the same issue as https://tracker.ardour.org/view.php?id=8084
System Description
Attached Files: 2024-04-03 16-47-43.mp4 (372,689 bytes) 2024-04-03 14:57
https://tracker.ardour.org/file_download.php?file_id=4818&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9682 [ardour] features feature N/A 2024-04-03 07:12 2024-04-03 07:12
Reporter: MatthiasT Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Limit Number of Pins on Insert a Plugin
Description: There are many VST Plugins out there which support 64, 128 or 256 IO pins. If you add such a plugin to Ardour, it will create all those pins as input and output busses.

This takes really much time (maybe especially if you are using a Jack audio connection?).

My wish is:

Add a preferences setting which limits the number of pins during insert of a plugin or put this value into the insert dialog where the question of "replace / add" is done.
Tags: limit, pins, plugin
Steps To Reproduce: NA
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9681 [ardour] bugs major always 2024-03-30 17:50 2024-04-01 08:16
Reporter: MatthiasT Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Copy and Paste of selected midi parts: wrong position of parts in editor
Description: If you select some midi parts in the editor and you press control+c and you afterwards press control+v on a new position in the editor: the parts are not in the same order as they have been copied. (see pdf file)

The special situation here is: There are empty tracks in between the selcted midi parts and after control+v this gaps are gone and the midi parts of the ollowing tracks have been moved to the former empty tracks
Tags: copy, Midi, paste
Steps To Reproduce: see above
Additional Information:
System Description
Attached Files: picturers.pdf (165,988 bytes) 2024-03-30 17:50
https://tracker.ardour.org/file_download.php?file_id=4815&type=bug
tracks-in-a-group.png (25,539 bytes) 2024-04-01 08:16
https://tracker.ardour.org/file_download.php?file_id=4816&type=bug
png
Notes
(0028623)
MatthiasT   
2024-04-01 08:16   
This also happens if the midi parts are in one group. See picture: the red midi parts are a copy of the yellow ones on the left side. The parts are al in gropus to make an arrangement with them. As you can see: in the red copied group, the gaps between the midi parts collapsed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9678 [ardour] bugs major always 2024-03-27 08:02 2024-03-27 21:36
Reporter: MatthiasT Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour and a multi monitor setup und Linux
Description: This ticket is about Ardour and a multi monitor setup und Linux

I know that this scenario is very rare, but at least for me it is also very annoying, how Ardour is acting if you have more than one monitor connected. The main topic is the positioning of the dialog boxes and the plugin windows.

Under Linux, a multi monitor setup is made of a large virtual desktop canvas on which the different monitors are placed and operated by xrandr. The size of this big canvas is calculated of the maximums and minimums of all x and y positions and dimension of all "connected" monitors, that are needed to place onto this big canvas. One of the monitors is the primary screen. This primary screen is the one where e.g. the program launch bar is shown. Also Ardour uses the primary screen to present the GUI.

The issue(s):

It seems to be that Ardour is using this big canvas as the border of the a "Monitor" for positioning sub-windows or dialog boxes. It is starting with the splash image: This is positioned on the middle of the big canvas and not in the middle of that primary monitor.

After loading all pluigins, the main GUI of Ardour is shown on the primary monitor. But: If you open a dialog of a plugin, it is shown (randomly?) on any screen of your setup. The same with the dialog boxes like: "Do you really want to delete this?..."

The main problem I have here: My screens are registered at xrandr as screens, but can be switched on and off. Normally, xrandr will detect that but if you connect a monitor by using an AV-Receiver, this is not always the case. So, in my case here, the dialog boxes and plugin windows were shown on this switched-off screen :-).

My suggestion to fix that quickly:

I would suggest to fix this problem by using the dimensions and position of the primary screen on the big canvas for showing dialog and plugin GUI windows. Even if there are more monitors, the dialog boxes should always be shown in front of the user and not on any monitor.

I know, that this is not easy to fix, because the window manager Ardour is running on my differ from installation to installation and this could cause different behaviors. Also to test that is not easy.

I offer you, that I do beta testing for a possible bugfix of this issue. Just send me a mail.
Tags: dialog boxes, GUI, multi displays
Steps To Reproduce: see text above
Additional Information:
System Description
Attached Files:
Notes
(0028619)
Daniele1971   
2024-03-27 21:36   
Look here: https://tracker.ardour.org/view.php?id=9084

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
344 [ardour] features feature always 2004-03-19 15:11 2024-03-25 07:47
Reporter: marukqs Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 3.X  
Summary: Edit the region in external audio editor
Description: Popular multitracks as Cubase or Cakewalk allow to edit the selected audio data in external WAV editors such as SoundForge or CoolEdit.
It is not easy to edit the recorded in data in external audioeditors which allow to do such common tasks as denoising, etc.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0000852)
paul   
2004-05-26 12:44   
this requires either (1) support by external editors for the notion of a "region" or (2) writing the region to disk before editing. regions are not files (and in fact, future versions of ardour may support regions that use multiple files).

i do want to add this feature, but its highly non-trivial.
(0003251)
taybin   
2007-02-14 21:45   
I'm marking this as a feature.
(0011148)
ddurham   
2011-07-17 06:18   
Hi, (author of ReZound speaking)
  I've recently completed my first semi-large project using Ardour2 and it's really incredible stuff. Thank you!

  Concerning this feature request, I also found that my typical work-flow could benefit from being able to edit clips in an external editor.

  I considered diving into the code and trying to implement this as feature to contribute back a little to the project, but first I figured I should check the latest alpha releases and feature requests to see what, if any, work had already been done on this.

  So, I found this bug report / feature request and a few questions are raised by Paul's comments.

Could you explain a little further about what was meant that (1) an external editor has to be aware of regions? Do you mean to say that a region is possibly a collection of files instead and not just one? I'm wondering this because of (2).

Could the feature request be a little simpler by allowing the user to select an actual audio file to be edited and not selecting specifically a region? Is this even feasible in complex mixes from a UX perspective? If the file is (somehow) shared among regions, I could see how that might be a problem, and the user should be fore-warned. Or is there a possibility of letting the user choose between that or creating a copy, reassigning the copy to the region that was selected and editing the copy. Perhaps that raises some other complications though, and I would let you speak to that.

In at least a couple of instances, I found myself exiting Ardour, locating the .wav file in the "interchange/<proj>/audiofiles/" folder and editing it directly. That may be considered a no-no, but it worked nonetheless.

Obviously, if the user changes the length or number of channels of the audiofile, then something will need to be decided about how Ardour deals with that when the external editor is finished.

This raises another question: I'm sure Ardour is caching certain data about the file (e.g. peak data, analyses, etc), and it will have to somehow know that the external editor is finished so that the cache can be invalidated and things can be redrawn. One possibility is that for Ardour to check the timestamp on the file before assuming any cached info is still valid. Is it doing this already, or is that potentially a sweeping change through the code.

I'd appreciate some pointers on the matter. Perhaps I can be talked out of trying to implement the change myself :).

I'm rambling on to be sure. So, we can also take this discussion somewhere else if need-be, but the archive of the expanded info on your comments might be helpful.

Thanks
(0011155)
ddurham   
2011-07-18 04:18   
Okay, so I did some digging into the code and perhaps have a better understanding of the situation:

The reason for your concern is that a region is made up of an audiofile per channel in the region. (e.g. it's "sources"). Is this correct?

So, if the user were to want to edit a region in an external editor, either (1) the editor will have to understand that these (e.g. 2 for stereo) files are two channels of the same file, or (2) Ardour would need to stitch all the channels back together into a single file, open that in the external editor, and then separate the multi channel file back into the multiple files when the external editor is finished.

Am I understanding your original comment correctly now?

Assuming so: I don't suppose Ardour3 is planning to change directions and internally use multi-channel audio frames, is it? Though, I can image some reasons why this design decision was made originally.

There's also something about "master_sources", but I can't see exactly how this relates to any functionality I've ever used. Are master sources relevant to the feature request?
(0028616)
gaurangarora   
2024-03-25 07:47   
My use case will greatly benefit from this feature.
We dub TV shows in Local Languages, and sometimes close micing is unavoidable due to recording environment constrains.
To remove pops and clicks, we regularly need to export regions from Ardour, fix using Audacity's spectral editing tools, re-import back in Ardour and resync. Audacity's pitch shift and time stretch also work better for voice recordings. Other tools like Clip Fix and Click Removal come in handy too.

The way this can be achieved is: With a mono or stereo Region selected:
1. set Range Selection from the selected region
2. bounce the Range without processing
3. open exported file in Audacity
4. user fixes/processes the file in Audacity and saves a new file.
5. back in Ardour, with the same range already selected,
(a) user drops the fixed file back in place and manually syncs it OR
(b) a new Replace Region feature is implemented in Ardour, which can essentially be the same function that is called when a Bounce Range or Consolidate Operation is executed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9669 [ardour] bugs major always 2024-03-11 15:05 2024-03-24 12:01
Reporter: MatthiasT Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Insert Time does not move VCA Automation
Description: If you select all tracks in your project, also the VCA tracks which have only automation inside (in my case) and you want to insert time before all tracks (here position 0:0:0), all tracks that have midi data are moved but not the automation of the VCA tracks. Please see attached picture.

Tags: insert, time, VCA
Steps To Reproduce: - create some midi/instrument tracks at time 0:0:0
- create some VCA tracks with automation of the faders also at 0:0:0
- select all midi and all other tracks
- start "Insert Time" feature and insert some beats at position 0:0:0
- all midi tracks are moved but the automation of the VCA tracks are not moved
Additional Information:
System Description
Attached Files: image.png (52,447 bytes) 2024-03-11 15:05
https://tracker.ardour.org/file_download.php?file_id=4807&type=bug
png
Notes
(0028612)
PMB Sound   
2024-03-24 12:01   
I can reproduce this issue on MacOS

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9652 [ardour] bugs minor have not tried 2024-03-02 16:41 2024-03-24 11:55
Reporter: stemsee Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: rightclick menu navigation.
Description: neither touchscreen nor muse cursor can select rightclick submenu item.
Tags:
Steps To Reproduce: rightclick menu on waveform in editor > click on gain > then neither cursor nor touchscreen is active to select item, must use arrow keys to navigate.
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0028611)
PMB Sound   
2024-03-24 11:55   
I've tried to reproduce this in Windows 10 22H2 and Windows 11 21H2, but to no avail. As I understand you can hover with cursor at gain submenu but no option is highlighted as you hover and clicks are not registered as you try to select some option?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9675 [ardour] bugs minor always 2024-03-23 09:05 2024-03-23 09:05
Reporter: PMB Sound Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Session name that contain diacritic letters is blocking video import
Description: Hello, I found a bug where session name that contain diacritic letters is blocking video import. This happens on Windows but not on MacOS.
Tags: Import, session, session file, video
Steps To Reproduce: 1. Create session with a name that contain diacritic letter (1 char Ä is enough)
2. Open video, import it with transcoding
3. Error should come out
Additional Information: I think that could be ffmpeg issue, not ardour's. For a quick fix in ardour I propose more clear error window in that case eg. "Your session name should contain only letters of the ISO basic Latin alphabet"
System Description
Attached Files: 2024-03-23 082932.png (11,443 bytes) 2024-03-23 09:05
https://tracker.ardour.org/file_download.php?file_id=4813&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9674 [ardour] bugs major always 2024-03-21 11:25 2024-03-21 16:45
Reporter: PMB Sound Platform: PC, Mac  
Assigned To: x42 OS: Windows, MacOS  
Priority: normal OS Version: 10 22H2, Big Sur  
Status: resolved Product Version: 8.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Deactivating audio track with long name resizes track menu width
Description: Hello, I found a bug where deactivating audio track with long name resizes track menu width. It happens on windows and macos.
Tags: track, ui
Steps To Reproduce: 1. Create an audio track with a long name (let's say about 50 characters)
2. Deactivate that track
3. Activate that track

After step 2 the track menu width will be expanded to the name length
After step 3 the track menu width will be normal with abbreviated name, but the gap is here
Additional Information: Overall, I think that deactivated tracks should stay with abbreviated name as activated ones.
Attached Files: photo_2024-03-21_12-18-29.jpg (71,860 bytes) 2024-03-21 11:25
https://tracker.ardour.org/file_download.php?file_id=4810&type=bug
jpg

photo_2024-03-21_12-18-43.jpg (68,792 bytes) 2024-03-21 11:25
https://tracker.ardour.org/file_download.php?file_id=4811&type=bug
jpg

photo_2024-03-21_12-18-56.jpg (69,157 bytes) 2024-03-21 11:25
https://tracker.ardour.org/file_download.php?file_id=4812&type=bug
jpg
Notes
(0028607)
x42   
2024-03-21 16:44   
Thanks. Fixed in 8.4-94-gbd4d6b4cba

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9547 [ardour] bugs major always 2023-11-22 13:13 2024-03-17 22:10
Reporter: mhartzel Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Using "Snapshot and switch to new version" repeatedly becomes veru very slow after some time
Description: I routinely use "Snapshot and switch to new version" when composing new music with Ardour. I have been bitten by a corrupted session and lost work a couple of years ago and started to use this feature to save a new version of the session every time I have recorded an idea that I don't want to lose.

Recently I started a new project with Ardour 8.0 and after about 40 times of using "Snapshot and switch to new version" it became very very slow. A normal session "save" however is still very very quick, only "Snapshot and switch to new version" is unbearably slow now. The session is on a SSD - disk which is working fast and flawlessly.

I made a video of me saving the 51st version with "Snapshot and switch to new version" and it took 2 minutes and 4 minutes to complete. The video is here: https://drive.google.com/file/d/10ojQZAhhnpTLm2mszU2FeHVRTUucDIzO/view?usp=drive_link

Here is the session stripped of all audio: https://drive.google.com/file/d/1ZdyqWDsWPuvnkLK2Mh9I0r4LjbOeH1f8/view?usp=drive_link

- Manjaro Linux KDE
- Ardour binary is from your website, I used 8.0 for the first 50 sessions I created and 8.1 for the last one in the video.
- Processor: AMD Ryzen Threadripper 2950X 16-Core Processor, 64 GB Ram.

There are 23 696 midi files in the session and I suspect that might have something to do with the problem. I myself have not made so many midi regions, I suspect they might have been duplicated every time I created a new version of the session.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028597)
mhartzel   
2024-03-17 07:27   
I have now confirmed that Ardour 8 (also version 8.4) makes duplicates of each midi file in the session when using "snapshot and switch to new version". The extra copies makes each new session slower and slower to use.

The expected behavior would be to just make a copy of the session file and not anything else. I can't think of a reason for Ardour making duplicates this way so I assume it is a bug of some sorts.

I have now stopped using "snapshop ..." and instead shut down Ardour and make a copy of the session file myself and the start Ardour again and load the new session file. This keeps my sessions lean and fast.
 
Here is a video of a newly created 8.4 session with the file manager showing the "midifiles" folder. In the video I first create a simple 2 pattern midi rhythm and then make 100 copies of it to get a drum beat of little over 6 minutes, Then I use "snapshot and switch to new version" and the file manager shows how Ardour each time makes unnecessary duplicates of these 100+ midi files.

https://drive.google.com/file/d/1-WUJ9KSXGkDrcMZ-X0YX0I6XYtHkYSgw/view?usp=drive_link
(0028598)
colinf   
2024-03-17 18:24   
I replied here: https://discourse.ardour.org/t/ardour-duplicating-midi-files/110028/2, but clearly the behaviour is not ideal for cases where there are many MIDI files.

The example here is maybe not the best: making 100 identical copies of a MIDI region would probably best be done as linked regions (sharing the same underlying MIDI file) unless there's an intent to modify each one of them individually afterwards, but I can certainly see that there are workflows where large numbers of MIDI files can get created, and clearly the impact of this on the performance of "Snapshot" in this case is not good.

One solution would be some kind of copy-on-write for MIDI regions, where MIDI regions can be flagged to have their underlying MIDI file copied when the region's MIDI is first edited, and for snapshot saving to set this flag on all MIDI regions in the snapshot, but I can see how this could be both complex to implement and potentially confusing to use.
(0028599)
mhartzel   
2024-03-17 20:23   
Thanks for the info. The "copy on write" only needs to make a copy of a midi region for the session version currently loaded in Ardour, it does not need to touch any regions that are not modified. This is how file system snapshots works, it is the exactly same principle. Only make a copy of the data that is being modified and don't touch any other data. I can't think of why it would be complicated to use as it would be completely hidden from the user.

Anyway thank you for helping me out.
(0028600)
mhartzel   
2024-03-17 22:10   
Just talking random thoughts out loud here: this corner case seems to stem from the fact that midi data is stored externally to the session file. The session has no other way of owning its own copy of midi than making duplicates of the external files.

If however midi data were to embedded inside the session, then the session would own it’s own copy of the data and there would be no risk of overwriting data of other session copies ever.

Or if the all midi data in a session was stored in one file owned by the session then this category of problems would also go away.

Seems this is more about how the data is stored than if midi files are individual or linked.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9672 [ardour] bugs major always 2024-03-16 18:43 2024-03-16 19:29
Reporter: PeterAMeyer Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.4  
Product Build: Resolution: not fixable  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Amsynth no longer loads
Description: Hi:

Moving from ardour 8.2 to 8.4, the amsynth vst no longer works.
Tags: 8.4 LXVST, amsynth
Steps To Reproduce: Create midi track
select amsyth (assumes that amsyth package has already been installed)
Additional Information: 2024-03-16T14:38:51 [ERROR]: Could not load VST2 plugin '/usr/lib/vst/amsynth_vst.so': /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0: undefined symbol: g_task_set_name
2024-03-16T14:38:51 [ERROR]: LXVST: cannot load module from "/usr/lib/vst/amsynth_vst.so"
System Description
Attached Files:
Notes
(0028595)
x42   
2024-03-16 19:28   
That is expected behavior. GTK2 is end of life and all plugins that still require GTK2 are no longer supported.

amsynth will also no longer be packaged by various GNU/Linux distros.
Debian is about to remove it, and the next version of Ubuntu[Studio] 24.04 comes without any plugins that need GTK2 (amsynth, EQ10Q, calf, invada etc)

See also https://discourse.ardour.org/t/ardour-8-4-calf-plugins-error-failed-to-instantiate-lv2-gui/109936/4
(0028596)
x42   
2024-03-16 19:29   
(this has to be resolved upstream at amsynth)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9650 [ardour] bugs minor always 2024-03-01 11:36 2024-03-16 18:41
Reporter: alastA4204 Platform: latest Manjaro ( Vulcan)  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Shuttle Pro detected but doesnt work
Description: My Shuttle Pro is detected by ardour but the program does not respond to the wheel or the buttons . In preferences- control surfaces ardour reports it detected. I had previously thought that this may be defective hardware however I installed from AUR shuttlepro-v2-git which shows that the computer sees the button presses and wheel events.
Tags:
Steps To Reproduce: happens all of the time
Additional Information:
System Description
Attached Files: Screenshot_2024-03-16_18-32-12.png (176,844 bytes) 2024-03-16 18:41
https://tracker.ardour.org/file_download.php?file_id=4808&type=bug
png
Notes
(0028594)
alastA4204   
2024-03-16 18:41   
I have added the following udev file to /etc/udev/rules.d/

SUBSYSTEM=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0030", MODE="660", GROUP="audio"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0020", MODE="660", GROUP="audio"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0010", MODE="660", GROUP="audio"

the wheel now works briefly then ardour crashes with the attached error ( Screen shot ) I have to admit I found this googling , I am a little out of my depth here :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9671 [ardour] features minor N/A 2024-03-15 15:33 2024-03-15 15:33
Reporter: colinf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Parallelise audio file import SRC
Description: When importing many audio files at once that need to be resampled, the resampling proceeds one file at a time, using 100% of one CPU core. It'd be nice to parallelise the import sample rate conversion in this case.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9668 [ardour] bugs major always 2024-03-11 08:10 2024-03-13 04:09
Reporter: MatthiasT Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Context Menus outside of Main Window
Description: If you put Ardour to fullscreen mode and you open a context windows like the group selection of the stripes and you have more than 10 groups, the lowest group names are outside of the application window or even outside of the screen. This happens at the bottom and the right side of the application window.

To select a group outside of the screen you have to first select the lowest possible group name and repeat this until you can select the desired group.
Tags: contextmenu, GUI
Steps To Reproduce: please see my description above
Additional Information:
System Description
Attached Files:
Notes
(0028589)
MatthiasT   
2024-03-11 12:19   
The method mentioned to reach elements outside of the screen is not working for me. So please ignore this:
"To select a group outside of the screen you have to first select the lowest possible group name and repeat this until you can select the desired group."
(0028592)
x42   
2024-03-13 04:08   
This should be fixed since 8.4-30
(0028593)
x42   
2024-03-13 04:09   
You could try with a https://nightly.ardour.org build

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9084 [ardour] bugs major always 2022-11-08 17:07 2024-03-13 04:08
Reporter: Daniele1971 Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: problems with multi monitor setup
Description: I have already written on the forum about this problem (https://discourse.ardour.org/t/ardour-7rc2-menu-always-opens-to-the-right/107687/4), few more info here..
With all official build from 6.9 to 7.1 Ardour is not confined to main screen but spawn some windows and tooltip bwtween screens.

On loading, splashscreen on screen 1 but session load/config and plugin scanning windows are on screen 2. Attached pictures clearly showh the problem.

Does not happens with the openSUSE build, for this I didn't notice before..

openSUSE TW, with Plasma desktop on Xorg.
vcard: Radeon rx 550
Tags:
Steps To Reproduce: start Ardour with 2 (maybe more) monitors
Additional Information:
System Description
Attached Files: ardour2screen.jpeg (348,659 bytes) 2022-11-08 17:07
https://tracker.ardour.org/file_download.php?file_id=4282&type=bug
ardour_tooltip.jpg (30,329 bytes) 2022-11-08 17:07
https://tracker.ardour.org/file_download.php?file_id=4283&type=bug
jpg
Notes
(0028545)
Daniele1971   
2024-02-23 18:01   
Now that gtk are in bundle with Ardour, bug happens even with the build for openSUSE. Is there a way to avoid this ? Remove them from the source ?
(0028546)
x42   
2024-02-23 20:42   
I see. both our official builder and apparently also openSuSe compiles Ardour in an enviromnent without `libxrandr-dev` and without `libxcb-xinerama0-dev`.

Will fix.
(0028558)
x42   
2024-02-27 17:31   
Ardour nightly builds since 8.4-30 should no longer have this issue.
I've also contacted the openSuSe packager about this issue
(0028563)
Daniele1971   
2024-02-27 19:32   
Yep, nightly build it's OK. The openSUSE build is almost ok. Splash screen starts on the wrong monitor, after plugin scan it moves to the right one. Session->Open the open window it's always on the wrong monitor.. Only that window !
I think we can consider the bug fixed.
Tips on what to check in the openSUSE build are welcome :)
Thanks.
(0028565)
x42   
2024-02-27 20:14   
can you check openSUSE's build log, does the configuration stage show

Checking for 'xrandr' >= 1.2.99                      : yes
Checking for 'xrandr' >= 1.5.0                       : yes
Checking for header X11/extensions/Xinerama.h        : yes


Compare to https://nightly.ardour.org/i/A_Linux_x86_64-gcc5abi/build_log.txt

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9657 [ardour] bugs major always 2024-03-05 07:56 2024-03-08 23:17
Reporter: MatthiasT Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Surround Sound Panning Automation not working
Description: If you automize the surround sound panner. on playback you see that the panner is moving. But: All surround channels are not playing a sound.

If you open the surround sound panner by hand, you hear the sound and you can pan by hand.

So: You can record or design an automation for the surround sound panner but it is not working during play back. All channels are internally muted on play back.
Tags: automation, pan, Surround
Steps To Reproduce: Automize a surround sound panner on a midi / instrument channel by setting dedicated points in the automation track or by recording a movement.

switch to automation playback and start playback of your production

the panner is moving but the surround sound channels do not play a sound.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8446 [ardour] bugs minor always 2020-10-19 11:46 2024-03-08 23:17
Reporter: nettings Platform: AMD64 Ryzen 9  
Assigned To: OS: Linux  
Priority: normal OS Version: openSUSE Tw  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Multichannel panner does not pass the audio signal when playing back automation
Description: see subject
Tags: automation, panner
Steps To Reproduce: Create a session with 5-channel master, and a mono track connected to the master.
Import some audio, play it. All is well.
Now write some automation to azimuth, width, or both. Set automation mode to "play" on these parameters.
What I see: the panner moves as automated, but there is no more audio from this track reaching the master. Metering "post-fader" shows level, "output" doesn't.
What I expect: audio signal should still reach the master bus from an automated n-channel panner.
When automation is switched off on all panner parameters, the audio again reaches the master.
Additional Information: current ardour git (rev 6.3-200-g16d9e72c31) on latest openSUSE Tumbleweed, compiled with VST3 support.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8364 [ardour] bugs minor always 2020-08-17 16:56 2024-03-08 23:17
Reporter: AliMacD Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: acknowledged Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: >2ch tracks panning mutes in Play, Touch or Latch
Description: In a track with more than 2 channels (I tried 3, 4, 5 & 6) when switching Pan automation from Manual to Play, Touch or Latch, sound is muted. Additionally, switching back to Manual with a 4 channel file (without having changed any automation) audio is now MONO centre
switching back to Manual with a 6 channel audio is MONO left channel output only
in both cases circular panner remains top centre
Tags: automation, pan, panner
Steps To Reproduce: to empty session, import audio file
add 4ch audio track
drag file onto track (I tried both stereo and 4ch files, same problem)
play file to check sound
select Automation > Pan on the track
switch from Manual to Play (sound is now muted)
Switch back to Manual (sound is back but now MONO, centre)

add 6ch audio track
drag file onto track (I tried both stereo and 6ch files, same problem)
play file to check sound
select Automation > Pan on the track
switch from Manual to Play (sound is now muted)
Switch back to Manual (sound is back but now MONO, left)
Additional Information:
System Description
Attached Files:
Notes
(0024938)
x42   
2020-08-18 19:41   
The VBAP panner does currently not support automation.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6156 [ardour] bugs major always 2015-01-29 23:42 2024-03-08 23:16
Reporter: boehmATmlab Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: vbap panner nearly mutes signal in automation mode
Description: a track with 4 outputs creates a vbap panner. if i playback the track in manuell mode (no automation) and manually move the point in the panner circle the panner works very good and outputs signal to the 4 outputs depending on the position of the circle. if i activate automation the signal output is very, very low.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016313)
x42   
2015-01-30 10:40   
The VBAP panner does currently not support automation.

see https://github.com/Ardour/ardour/blob/master/libs/panners/vbap/vbap.cc#L362

Ideally, the automation lanes would be unavailable until the time when VPAP automation is
implemented (but doing so is more work than implementing VBAP automation in the first place, hence the current situation)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9667 [ardour] bugs major always 2024-03-08 11:16 2024-03-08 11:16
Reporter: MatthiasT Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: The Arrangement Copy and Paste is not working correctly
Description: If you try to arrange your song by the arrangement feature, the copy and paste of parts is not working correctly

Tags: arrangement, copy, paste
Steps To Reproduce: I have some midi parts in the first frame of some tracks. These midi frames are duplicated without copying the midi data itself (I call it cloning) to create a track-part.

These track-parts are part of arangement parts.

Picture 1 (in pdf):
I have two arrangement parts and I want to copy and paste the second arrangement part to a third position (after the second arrangement part)

The second arrangement part is already a copy of the first arrangement part, but with added automations (not visible in the pictures / pdf).

Picture 2:
If I do the copy and paste to the current postion marker (which is at the end of the second arrangement part), the new part is inserted at the beginning of the arrangement / song.

And some further things went wrong.

Please see attached PDF with two pictures of the situations.

I expect that the copy of the second part will be put at the current position marker and the rest of the arrangement should be left like it is.
Additional Information:
System Description
Attached Files: arrangement-01.pdf (181,660 bytes) 2024-03-08 11:16
https://tracker.ardour.org/file_download.php?file_id=4806&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9666 [ardour] bugs tweak always 2024-03-07 19:40 2024-03-07 19:40
Reporter: aceku Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: automation in percent does not scale correctly with midfaders
Description: i use a vst windows plugin in linux. everything works fine, i can animate the parameters. only when i map them to a midicontroller the range is only 99.2% - 100%

it seems that the fader of the plugin is in percentage and so i can't use the full fader range.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: ardour_morph.jpg (35,919 bytes) 2024-03-07 19:40
https://tracker.ardour.org/file_download.php?file_id=4805&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9658 [ardour] bugs minor always 2024-03-06 05:25 2024-03-07 13:51
Reporter: BrentBaccala Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Wall Clock does not display on Ubuntu
Description: The "Wall Clock" in the status line does not display, at all, on either of my Ubuntu systems. Both are running Ardour compiled from git master (very recent).

I can resolve the problem, and get the wall clock to display, by commenting out this line in ardour_ui_ed.cc:

- _status_bar_visibility.add (&wall_clock_label, X_("WallClock"), _("Wall Clock"), false);

My guess is that the hbox->pack_end call 20 lines earlier conflicts with the _status_bar_visibility_add. Ironically enough, I'm guessing that the wall clock displays on macOS but not on anything else, which is exactly the reverse of the desired behavior.

My suggestion is to remove the call to _status_bar_visibility_add completely, and only call hbox->pack_end if we're not on __APPLE__.

It works for me.

I also fixed the call to "set_name" earlier in the code, because it couldn't possibly be right, though I don't understand what it does.

Suggested patch:

--- a/gtk2_ardour/ardour_ui_ed.cc
+++ b/gtk2_ardour/ardour_ui_ed.cc
@@ -783,7 +783,7 @@ ARDOUR_UI::build_menu_bar ()
 
        wall_clock_label.set_name ("WallClock");
        wall_clock_label.set_use_markup ();
- timecode_format_label.set_name ("WallClock");
+ timecode_format_label.set_name ("Timecode");
        timecode_format_label.set_use_markup ();
        peak_thread_work_label.set_name ("PeakThreadWork");
        peak_thread_work_label.set_use_markup ();
@@ -814,7 +814,10 @@ ARDOUR_UI::build_menu_bar ()
 #endif
 
        hbox->pack_end (error_alert_button, false, false, 2);
+#ifndef __APPLE__
+ // OSX provides its own wallclock, thank you very much
        hbox->pack_end (wall_clock_label, false, false, 10);
+#endif
 
        hbox->pack_end (*ev_dsp, false, false, 6);
        hbox->pack_end (disk_space_label, false, false, 6);
@@ -838,10 +841,6 @@ ARDOUR_UI::build_menu_bar ()
        _status_bar_visibility.add (&sample_rate_label, X_("Audio"), _("Audio"), true);
        _status_bar_visibility.add (&disk_space_label, X_("Disk"), _("Disk Space"), !Profile->get_small_screen());
        _status_bar_visibility.add (&dsp_load_label, X_("DSP"), _("DSP"), true);
-#ifndef __APPLE__
- // OSX provides its own wallclock, thank you very much
- _status_bar_visibility.add (&wall_clock_label, X_("WallClock"), _("Wall Clock"), false);
-#endif
 
        ev->signal_button_press_event().connect (sigc::mem_fun (_status_bar_visibility, &VisibilityGroup::button_press_event));
 
Tags: GUI
Steps To Reproduce: Run Ardour on Ubuntu. No wall clock on the status line. Does it appear on macOS? I don't know.
Additional Information:
System Description
Attached Files:
Notes
(0028586)
x42   
2024-03-07 13:23   
How about other optional optional items? Can you toggle "File Format", "Path to Session", etc?
I just verified that all those work here with local build (Debian) as well as the official binary.

ALso check `~/.config/ardour8/config` for `UI status-bar="..."` does that list include "WallClock"?
(0028587)
x42   
2024-03-07 13:51   
PS. "set_name" is used for theming and unrelated for the issue at hand

Thanks for catching that. I've just fixed that.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9663 [ardour] features feature have not tried 2024-03-07 06:24 2024-03-07 13:14
Reporter: Werner Back Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Control surface settings should be set global
Description: Currently the control surface settings are saved with the project, which means every time you open a (older) project you have to reassure that those settings are still correct. Wouldn't it be better to save those globally? I mean, who changes the control surface between projects? In most cases you have one surface which should be set once and then you dont't have to think about it further.
Tags: control surface
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0028585)
x42   
2024-03-07 13:14   
Control Surface settings are saved with global preferences and these settings are used with new sessions.
However loading existing sessions will override the global settings. This is by design.

There is one exception: Generic MIDI is always per session, since MIDI Learned bindings are session specific.

Since Ardour 7.5. Control Surfaces are also auto-detected (Faderport 8/16, LaunchPad Pro/Mini, Push2, Console1, ShuttlePRO, ShuttleXpress), unless you manually disable a given surface.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9662 [ardour] bugs minor always 2024-03-07 06:18 2024-03-07 06:18
Reporter: Werner Back Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Control surface button assignment not visable
Description: In the protocol settings/function keys the current assignments only show for the function buttons F1-F8. Other assignments do not appear in the dropdown.
Tags:
Steps To Reproduce: 1. Activate a control surface, in my case Mackie
2. Go to the protocol settings
3. Go to function keys
4. Assign functions to keys other than F1-F8

The assigned functions will only show as long you remain in that session. As soon as you close and reopen the session, the entries disappear, although they keep being assigned.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8509 [ardour] features minor always 2020-12-18 20:28 2024-03-06 22:39
Reporter: dgdgddgd Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Fold the Piano Roll && Display the desired number of keys in piano roll
Description: Hi

1-Fold the Piano Roll
https://youtu.be/2TZcC1v7eQw?t=51

2-Display the desired number of keys in piano roll
https://discourse.ardour.org/t/display-the-desired-number-of-keys-in-ardour-piano-roll/105171

best
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_2020-12-16_10-45-34.png (156,404 bytes) 2020-12-18 20:28
https://tracker.ardour.org/file_download.php?file_id=3887&type=bug
png

Screenshot_2020-12-16_10-46-17.png (48,711 bytes) 2020-12-18 20:28
https://tracker.ardour.org/file_download.php?file_id=3888&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9661 [ardour] bugs major always 2024-03-06 13:45 2024-03-06 13:45
Reporter: MatthiasT Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi Track Automation damaged or gone after Part Movement
Description: If you create a Midi Instrument Track with Automation Data and you move the Part, you will see that either die Autoomation is moved to the point after the new position of the part or it is cutted at the beginning or end or points of a recporded automation are gone.
Tags: automation, instrument, Midi
Steps To Reproduce: Create a midi intrstrument track

Record some notes

Open an automation channel and put some control points into the automation

In the part editor: Move the part where the midi notes and the automation are in

Observe the track automation data after moving
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9659 [ardour] bugs minor always 2024-03-06 05:59 2024-03-06 05:59
Reporter: BrentBaccala Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Move track up/down keyboard shortcuts don't work in mixer view
Description: The menu bar items work, but not the shortcuts.

Question: should the shortcuts be CNTL-left and CNTL-right in the mixer view?
Tags:
Steps To Reproduce: Click on "mix". Select a track. Try to use CNTL-up and CNTL-down.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9649 [ardour] bugs minor always 2024-02-29 00:45 2024-03-06 00:43
Reporter: eschwartz Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Build failure with -flto: ODR violations
Description: ```
19:42:17 runner ['x86_64-pc-linux-gnu-gcc', '-I/var/tmp/portage/media-sound/ardour-8.4/work/Ardour-8.4.0', '-march=native', '-fstack-protector-all', '-O2', '-pipe', '-fdiagnostics-color=always', '-frecord-gcc-switches', '-U_FORTIFY_SOURCE', '-D_FORTIFY_SOURCE=3', '-fstack-clash-protection', '-Wformat', '-Werror=format-security', '-flto', '-Werror=odr', '-Werror=lto-type-mismatch', '-Werror=strict-aliasing', '-Werror=implicit-function-declaration', '-Werror=implicit-int', '-Werror=int-conversion', '-Werror=incompatible-pointer-types', '-lboost_system', '-DHAVE_RF64_RIFF', '-DCOMPILER_INT128_SUPPORT', '-DWAF_BUILD', '-DNDEBUG', '-fshow-column', '-pipe', '-DARCH_X86', '-mmmx', '-msse', '-mfpmath=sse', '-DUSE_XMMINTRIN', '-DBUILD_SSE_OPTIMIZATIONS', '-DLXVST_64BIT', '-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', '-DBOOST_SYSTEM_NO_DEPRECATED', '-DBOOST_BIND_GLOBAL_PLACEHOLDERS', '-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="8"', '-Wstrict-prototypes', '-Wmissing-prototypes', '-fPIC', '-fPIC', '-fPIC', '-Ilibs/tk/ztk', '-I../libs/tk/ztk', '-Ilibs/tk', '-I../libs/tk', '-Ilibs/tk/ztk/ztk', '-I../libs/tk/ztk/ztk', '-Ilibs/tk/ztk/ztk/atk', '-I../libs/tk/ztk/ztk/atk', '-I/usr/include/glib-2.0', '-I/usr/lib64/glib-2.0/include', '-I/usr/lib64/libffi/include', '-I/var/tmp/portage/media-sound/ardour-8.4/work/Ardour-8.4.0/build', '-DINTERNAL_SHARED_LIBS=1', '-DYTK=1', '-DHAVE_SUIL=1', '-DHAVE_ALSA=1', '-DHAVE_PULSEAUDIO=1', '-DHAVE_GLIB=1', '-DHAVE_GTHREAD=1', '-DHAVE_GLIBMM=1', '-DHAVE_SNDFILE=1', '-DHAVE_GIOMM=1', '-DHAVE_CURL=1', '-DHAVE_ARCHIVE=1', '-DHAVE_LO=1', '-DHAVE_TAGLIB=1', '-DHAVE_VAMPSDK=1', '-DHAVE_VAMPHOSTSDK=1', '-DHAVE_RUBBERBAND=1', '-DHAVE_USB=1', '-DHAVE_RUBBERBAND_3_0_0=1', '-DEXPORT_VISIBILITY_HIDDEN=0', '-DENABLE_NLS=1', '-DLXVST_SUPPORT=1', '-DVST3_SUPPORT=1', '-DUSE_FUTEX_SEMAPHORE=1', '-DFPU_AVX512F_SUPPORT=1', '-DFPU_AVX_FMA_SUPPORT=1', '-DCONFIG_ARCH="x86_64"', '-DHAVE_TOOLS_SANITY_CHECK=1', '-DHAVE_FFTW3F=1', '-DHAVE_UDEV=1', '-DHAVE_HIDAPI=1', '-DHAVE_AUBIO=1', '-DHAVE_AUBIO4=1', '-DHAVE_GOBJECT=1', '-DHAVE_GIO=1', '-DHAVE_LIBPNG=1', '-DHAVE_PANGO=1', '-DHAVE_CAIRO=1', '-DHAVE_PANGOCAIRO=1', '-DHAVE_GIO_UNIX=1', '-DHAVE_RANDR=1', '-DHAVE_RANDR15=1', '-DHAVE_GMODULE=1', '-DHAVE_X11=1', '-DHAVE_XEXT=1', '-DHAVE_SIGCPP=1', '-DHAVE_CAIROMM=1', '-DHAVE_PANGOMM=1', '-DHAVE_LV2_1_16_0=1', '-DHAVE_XML=1', '-DHAVE_EXECINFO=1', '-DHAVE_POSIX_MEMALIGN=1', '-DHAVE_GETMNTENT=1', '-DHAVE_LOCALTIME_R=1', '-DHAVE_CONTROL_PROTOCOL=1', '-DHAVE_MIDI_SURFACE=1', '-DHAVE_WEBSOCKETS=1', '-DHAVE_LRDF=1', '-DHAVE_SAMPLERATE=1', '-DHAVE_LV2=1', '-DHAVE_LV2_1_10_0=1', '-DHAVE_LV2_1_17_2=1', '-DHAVE_LV2_1_18_6=1', '-DHAVE_SERD=1', '-DHAVE_SORD=1', '-DHAVE_SRATOM=1', '-DHAVE_LILV=1', '-DLV2_SUPPORT=1', '-DLV2_EXTENDED=1', '-DHAVE_OGG=1', '-DHAVE_FLAC=1', '-DHAVE_FFTW35F=1', '-DUSE_RUBBERBAND=1', '-DCURRENT_SESSION_FILE_VERSION=7003', '-DHAVE_SYS_VFS_H=1', '-DHAVE_SYS_STATVFS_H=1', '-DHAVE_UNISTD=1', '-DHAVE_BOOST_SCOPED_PTR_HPP=1', '-DHAVE_BOOST_PTR_CONTAINER_PTR_LIST_HPP=1', '-DHAVE_BOOST_SHARED_PTR_HPP=1', '-DHAVE_BOOST_FORMAT_HPP=1', '-DHAVE_LV2_1_0_0=1', '-DHAVE_PANGOFT2=1', '-DHAVE_FONTCONFIG=1', '-DHAVE_READLINE=1', '-DHAVE_DBUS=1', '-DHAVE_CONFIG_H', '-D_LARGEFILE64_SOURCE', '-D_REENTRANT', '-DG_LOG_DOMAIN="Gdk"', '-DATK_COMPILATION', '-D_FILE_OFFSET_BITS=64', '-DG_DISABLE_SINGLE_INCLUDES', '-DATK_DISABLE_SINGLE_INCLUDES', '-DG_DISABLE_DEPRECATED', '-DATK_DISABLE_DEPRECATED', '-DATK_LOCALEDIR=""', '../libs/tk/ztk/atknoopobject.c', '-c', '-o/var/tmp/portage/media-sound/ardour-8.4/work/Ardour-8.4.0/build/libs/tk/ztk/atknoopobject.c.1.o']
../libs/pbd/pbd/file_archive.h:35:18: error: type ‘struct FileArchive’ violates the C++ One Definition Rule [-Werror=odr]
   35 | class LIBPBD_API FileArchive
      | ^
../libs/pbd/pbd/file_archive.h:35:18: note: a different type is defined in another translation unit
   35 | class LIBPBD_API FileArchive
      | ^
../libs/pbd/pbd/file_archive.h:167:39: note: the first difference of corresponding definitions is field ‘_current_entry’
  167 | struct archive_entry* _current_entry;
      | ^
../libs/pbd/pbd/file_archive.h:167:39: note: a field of same name but different type is defined in another translation unit
  167 | struct archive_entry* _current_entry;
      | ^
/usr/include/archive.h:186:8: note: type name ‘archive_entry’ should match type name ‘PBD::archive_entry’
  186 | struct archive_entry;
      | ^
../libs/pbd/pbd/file_archive.h:167:24: note: the incompatible type is defined here
  167 | struct archive_entry* _current_entry;
      | ^
lto1: some warnings being treated as errors
lto-wrapper: fatal error: x86_64-pc-linux-gnu-g++ returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
```
Tags:
Steps To Reproduce: CFLAGS="-march=native -fstack-protector-all -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-clash-protection -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wformat -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Werror=int-conversion -Werror=incompatible-pointer-types"
CXXFLAGS="-march=native -fstack-protector-all -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-clash-protection -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wformat -Werror=format-security"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wl,--defsym=__gentoo_check_ldflags__=0"


But in particular, see "-flto -Werror=odr".

emerge -1 =ardour-8.4
Additional Information: This was originally reported at https://bugs.gentoo.org/917095 for ardour 7.5, but still reproduces today with ardour 8.4.
System Description
Attached Files: build.log (397,239 bytes) 2024-02-29 00:45
https://tracker.ardour.org/file_download.php?file_id=4801&type=bug
Notes
(0028572)
x42   
2024-02-29 02:40   
This is an odd one. can you check if 8.4-38-g2fe22eeab5 addresses it? Thanks.
(0028573)
eschwartz   
2024-02-29 03:09   
Maybe? It's somewhat awkward because I still get an error, it's just a different error.

22:03:32 runner ['x86_64-pc-linux-gnu-g++', '-I/var/tmp/portage/media-sound/ardour-9999/work/ardour-9999', '-march=native', '-fstack-protector-all', '-O2', '-pipe', '-fdiagnostics-color=always', '-frecord-gcc-switches', '-U_FORTIFY_SOURCE', '-D_FORTIFY_SOURCE=3', '-fstack-clash-protection', '-Wformat', '-Werror=format-security', '-flto', '-Werror=odr', '-Werror=lto-type-mismatch', '-Werror=strict-aliasing', '-std=c++11', '-lboost_system', '-DHAVE_RF64_RIFF', '-DCOMPILER_INT128_SUPPORT', '-DWAF_BUILD', '-DNDEBUG', '-fshow-column', '-pipe', '-DARCH_X86', '-mmmx', '-msse', '-mfpmath=sse', '-DUSE_XMMINTRIN', '-DBUILD_SSE_OPTIMIZATIONS', '-DLXVST_64BIT', '-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', '-DBOOST_SYSTEM_NO_DEPRECATED', '-DBOOST_BIND_GLOBAL_PLACEHOLDERS', '-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="8"', '-Woverloaded-virtual', '-Wno-unused-local-typedefs', '-D__STDC_LIMIT_MACROS', '-D__STDC_FORMAT_MACROS', '-DCANVAS_DEBUG', '-DBOOST_ERROR_CODE_HEADER_ONLY', '-fPIC', '-pthread', '-pthread', '-pthread', '-pthread', '-pthread', '-Ilibs/ardour', '-I../libs/ardour', '-Ilibs/vst3', '-I../libs/vst3', '-Ilibs/ctrl-interface/control_protocol', '-I../libs/ctrl-interface/control_protocol', '-Ilibs', '-I../libs', '-Ilibs/midi++2', '-I../libs/midi++2', '-Ilibs/evoral', '-I../libs/evoral', '-Ilibs/temporal', '-I../libs/temporal', '-Ilibs/audiographer', '-I../libs/audiographer', '-Ilibs/audiographer/src', '-I../libs/audiographer/src', '-Ilibs/ptformat', '-I../libs/ptformat', '-Ilibs/pbd', '-I../libs/pbd', '-Ilibs/lua', '-I../libs/lua', '-Ilibs/zita-resampler', '-I../libs/zita-resampler', '-Ilibs/zita-convolver', '-I../libs/zita-convolver', '-Ilibs/libltc/ltc', '-I../libs/libltc/ltc', '-Ilibs/fluidsynth/fluidsynth', '-I../libs/fluidsynth/fluidsynth', '-Ilibs/tk/suil', '-I../libs/tk/suil', '-I/usr/include/glib-2.0', '-I/usr/lib64/glib-2.0/include', '-I/usr/include/sigc++-2.0', '-I/usr/lib64/sigc++-2.0/include', '-I/usr/include/glibmm-2.4', '-I/usr/lib64/glibmm-2.4/include', '-I/usr/lib64/libffi/include', '-I/usr/include/libxml2', '-I/usr/include/libusb-1.0', '-I/usr/include/opus', '-I/usr/include/raptor2', '-I/usr/include/giomm-2.4', '-I/usr/lib64/giomm-2.4/include', '-I/usr/include/libmount', '-I/usr/include/blkid', '-I/usr/include/taglib', '-I/usr/include/serd-0', '-I/usr/include/sord-0', '-I/usr/include/lilv-0', '-I/usr/include/sratom-0', '-I/usr/include/zix-0', '-I/var/tmp/portage/media-sound/ardour-9999/work/ardour-9999/build', '-DINTERNAL_SHARED_LIBS=1', '-DYTK=1', '-DHAVE_SUIL=1', '-DHAVE_ALSA=1', '-DHAVE_PULSEAUDIO=1', '-DHAVE_GLIB=1', '-DHAVE_GTHREAD=1', '-DHAVE_GLIBMM=1', '-DHAVE_SNDFILE=1', '-DHAVE_GIOMM=1', '-DHAVE_CURL=1', '-DHAVE_ARCHIVE=1', '-DHAVE_LO=1', '-DHAVE_TAGLIB=1', '-DHAVE_VAMPSDK=1', '-DHAVE_VAMPHOSTSDK=1', '-DHAVE_RUBBERBAND=1', '-DHAVE_USB=1', '-DHAVE_RUBBERBAND_3_0_0=1', '-DEXPORT_VISIBILITY_HIDDEN=0', '-DENABLE_NLS=1', '-DLXVST_SUPPORT=1', '-DVST3_SUPPORT=1', '-DUSE_FUTEX_SEMAPHORE=1', '-DFPU_AVX512F_SUPPORT=1', '-DFPU_AVX_FMA_SUPPORT=1', '-DCONFIG_ARCH="x86_64"', '-DHAVE_TOOLS_SANITY_CHECK=1', '-DHAVE_FFTW3F=1', '-DHAVE_UDEV=1', '-DHAVE_HIDAPI=1', '-DHAVE_AUBIO=1', '-DHAVE_AUBIO4=1', '-DHAVE_GOBJECT=1', '-DHAVE_GIO=1', '-DHAVE_LIBPNG=1', '-DHAVE_PANGO=1', '-DHAVE_CAIRO=1', '-DHAVE_PANGOCAIRO=1', '-DHAVE_GIO_UNIX=1', '-DHAVE_RANDR=1', '-DHAVE_RANDR15=1', '-DHAVE_GMODULE=1', '-DHAVE_X11=1', '-DHAVE_XEXT=1', '-DHAVE_SIGCPP=1', '-DHAVE_CAIROMM=1', '-DHAVE_PANGOMM=1', '-DHAVE_LV2_1_16_0=1', '-DHAVE_XML=1', '-DHAVE_EXECINFO=1', '-DHAVE_POSIX_MEMALIGN=1', '-DHAVE_GETMNTENT=1', '-DHAVE_LOCALTIME_R=1', '-DHAVE_CONTROL_PROTOCOL=1', '-DHAVE_MIDI_SURFACE=1', '-DHAVE_WEBSOCKETS=1', '-DHAVE_LRDF=1', '-DHAVE_SAMPLERATE=1', '-DHAVE_LV2=1', '-DHAVE_LV2_1_10_0=1', '-DHAVE_LV2_1_17_2=1', '-DHAVE_LV2_1_18_6=1', '-DHAVE_SERD=1', '-DHAVE_SORD=1', '-DHAVE_SRATOM=1', '-DHAVE_LILV=1', '-DLV2_SUPPORT=1', '-DLV2_EXTENDED=1', '-DHAVE_OGG=1', '-DHAVE_FLAC=1', '-DHAVE_FFTW35F=1', '-DUSE_RUBBERBAND=1', '-DCURRENT_SESSION_FILE_VERSION=7003', '-DHAVE_SYS_VFS_H=1', '-DHAVE_SYS_STATVFS_H=1', '-DHAVE_UNISTD=1', '-DHAVE_BOOST_SCOPED_PTR_HPP=1', '-DHAVE_BOOST_PTR_CONTAINER_PTR_LIST_HPP=1', '-DHAVE_BOOST_SHARED_PTR_HPP=1', '-DHAVE_BOOST_FORMAT_HPP=1', '-DHAVE_LV2_1_0_0=1', '-DHAVE_PANGOFT2=1', '-DHAVE_FONTCONFIG=1', '-DHAVE_READLINE=1', '-DHAVE_DBUS=1', '../libs/ardour/luabindings.cc', '-c', '-o/var/tmp/portage/media-sound/ardour-9999/work/ardour-9999/build/libs/ardour/luabindings.cc.2.o']
../libs/audiographer/private/gdither/gdither.h:67:9: error: ‘gdither_new’ violates the C++ One Definition Rule [-Werror=odr]
   67 | GDither gdither_new(GDitherType type, uint32_t channels,
      | ^
../libs/audiographer/private/gdither/gdither.cc:75:1: note: ‘gdither_new’ was previously declared here
   75 | gdither_new (GDitherType type, uint32_t channels,
      | ^
lto1: some warnings being treated as errors

It's somewhat awkward to tell the full set of build errors since restarting waf appears to go back and recompile many already compiled files.
(0028582)
eschwartz   
2024-03-06 00:43   
Is there any more information you need from me?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9648 [ardour] bugs major always 2024-02-28 17:39 2024-03-04 22:00
Reporter: Eickmeyer Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Build fails with Python 3.12
Description: This is mostly a heads-up when Debian switches to Python 3.12. itstool is largely unmaintained and has a few breakages due to Python 3.12 and is throwing issues into STDOUT, causing translations to fail to build. Ignoring STDERR output makes it build properly.

A one-line change in /wscript fixes this:

--- wscript
+++ wscript
@@ -1003,7 +1003,7 @@ def configure(conf):
 
     # freedesktop translations needs itstool > 1.0.3 (-j option)
     if Options.options.freedesktop:
- output = subprocess.Popen("itstool --version", shell=True, stderr=subprocess.STDOUT, stdout=subprocess.PIPE).communicate()[0].splitlines()
+ output = subprocess.Popen("itstool --version", shell=True, stderr=subprocess.DEVNULL, stdout=subprocess.PIPE).communicate()[0].splitlines()
         o = output[0].decode('utf-8')
         itstool = o.split(' ')[0]
         version = o.split(' ')[1].split('.')

Tags:
Steps To Reproduce: Simply build in Ubuntu Noble Numbat (future Ubuntu 24.04 LTS). Eventually, after Debian transitions to Python 3.12, this will be reproducible there. Really, there's no reason to be monitoring STDOUT here.
Additional Information: I have attached the patch being used in Ubuntu, this can also be used in Debian or reimplemented for your use. Thanks to Gianfranco Costamonga for the fix.
System Description
Attached Files: fix-build-python-3.12.patch (1,794 bytes) 2024-02-28 17:39
https://tracker.ardour.org/file_download.php?file_id=4800&type=bug
Notes
(0028580)
x42   
2024-03-04 14:31   
Thanks. applied as 8.4-43-g338cd09a4a

Do you know where those `SyntaxWarning: invalid escape sequence` come from?
(0028581)
Eickmeyer   
2024-03-04 16:28   
It comes from `itstool` being incompliant with new Python 3.12 rules, and largely unmaintained upstream. However, though it's throwing the warnings, it's still doing its job with the translations, so there's no reason to panic. The only issue was that the wscript was seeing these warnings as errors and the entire build process was shutting-down as a result.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9656 [ardour] bugs minor always 2024-03-04 17:30 2024-03-04 17:30
Reporter: mkoziol2137 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Launchpad Mini pads "queued" status issue
Description: When switching between slots during playback, the blinking green indicator works only if changing from empty slot
Tags:
Steps To Reproduce: - go to cues view
- add some clips in one column (optionally set quantitize to 4 bars)
- start a clip -> the pad should blink green
- switch to another clip in a column -> no blinking
- select an empty slot
- select a slot with a clip -> green blinking
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9655 [ardour] bugs major always 2024-03-04 17:22 2024-03-04 17:22
Reporter: mkoziol2137 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Launchpad Mini integration - arrow keys
Description: Launchpad Mini Arrow keys are not working correctly - up/down - no effect, so only first 8 rows are accessible, using left/right causes the lights to disappear and you need to click transport stop/play to make them appear again
Tags:
Steps To Reproduce: - connect Launchpad Mini
- start ardour
- go to cues
- add some clips to slots (at this moment pad light are OK)
- play some slots
- try to use arrow keys
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9651 [ardour] bugs tweak sometimes 2024-03-01 18:50 2024-03-04 13:20
Reporter: BrentBaccala Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: low OS Version: (any)  
Status: resolved Product Version: 8.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Adding a track from the mixer view with position "First" will actually add it Last
Description: I've seen this with both Audio and MIDI tracks.

It doesn't do this on every project, but it does it consistently on the once I'm attaching.

Once I've added a single track, then further track adds work properly.

I'm using Ardour compiled from a current (Feb 29 2024) repository, but I first noticed it on a version of Ardour compiled from the git repository of 21 Jan 2024.

It's very sensitive to the PresentationInfo order attribute in the project file. I've only seen this behavior on projects where the "Master" route has order="0", but I've also seen Ardour save a project with "Master" route order="1" and the first track with route order="0" and it doesn't do this.
Tags: GUI
Steps To Reproduce: 1. Load the attached project file
2. Immediately add a track by right-clicking in the blank track space, selecting "First" for the position.
3. On my system, it gets added last.
Additional Information:
System Description
Attached Files: piano and drums.ardour (180,393 bytes) 2024-03-01 18:50
https://tracker.ardour.org/file_download.php?file_id=4803&type=bug
Notes
(0028579)
x42   
2024-03-04 13:20   
Thanks, fixed in 8.4-41-ged98ff97b2

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9654 [ardour] bugs minor always 2024-03-03 22:18 2024-03-03 22:18
Reporter: automaciej Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Revision number behaves unexpectedly in the export dialog
Description: The revision number in the export dialog should not be tied to the format tab. If you're exporting in multiple formats, your exports should share the revision number.

As in, this is probably not what the user wants when exporting a mix:

My Tune_r2_format1.wav
My Tune_r1_format2.wav (because they forgot to increment r1 to r2 in the second tab)

They probably want:

My Tune_r2_format1.wav
My Tune_r2_format2.wav
My Tune_r2_(...).wav
(...)

As in, the revision number should be the same in all the formats.

Original description with screenshot is on the forums:
https://discourse.ardour.org/t/keeping-the-revision-number-in-sync-between-formats/109972

Tags:
Steps To Reproduce: 1. Open the export dialog.
2. Pick a revision number, say "r1"
3. Add a new format. It will have the same revision number.
4. Increment the second format's revision number. It should be "r2" now.
5. Go back to the first format (first tab) and look at the revision number.

It should be "r2" (it's the revision of the mix, not a revision of the format) but it's "r1".
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9653 [ardour] bugs minor always 2024-03-03 20:14 2024-03-03 20:17
Reporter: mahlon Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: 23.10  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Inconsistent behavior with midi ranges that contain notes of a 0 length
Description: I had imported a midi file that had generated 0 length notes interleaved with "normal" length notes. (Weird, for sure, but I guess still valid midi?)

While the imported range was the only present on the track, Ardour did what I suppose should be expected -- ignored the notes when playing.

As soon as a new range was drawn on the same track (even empty), those regularly invisible notes were played (with a seemingly long length). If the range is removed, the initial behavior is restored.

This is independent of the import function, you can draw/edit notes to create the same inconsistency.
Tags:
Steps To Reproduce: Create a midi track. Draw some overlapping notes. Select all, edit their length to 0. Play. Silence!

Draw a new range elsewhere on the same track. Play again. Chaos!

Delete the new range. All good again.


Obviously, you'll only hear this with a midi instrument that has a release long enough to matter.
Additional Information: I just noticed this after updating to 8.4, so I don't know if it's new behavior or has been hanging out for awhile.
System Description
Attached Files:
Notes
(0028578)
mahlon   
2024-03-03 20:17   
I put a screen recording demonstrating this here:

https://martini.nu/public/ardour/ardour-midi-2024-03-02_23.23.00.mkv

... and a fresh 8.4 session with appropriately labeled ranges (using the Vital synth, but again anything with a long release should do.) Ironically I am also crashing when trying to make an archive (I'll see if I can get a backtrace and throw in a separate bug from that), so it's just a manual tarball.

https://martini.nu/public/ardour/reprod-session.tgz

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8840 [ardour] bugs minor always 2021-12-18 21:04 2024-03-01 02:17
Reporter: timetre Platform: GNU  
Assigned To: OS: Fedora  
Priority: normal OS Version: 33  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Using OSC crashes Ardour when strip has Aux Send
Description: Using ToucOSC to control Ardour
Works fine except if:
A track has an Aux Send and the track is selected (either via ToucOSC or via the Ardour UI itself).
It crashes Ardour every time (core dump)
If the track is not selected it stays usable.
Whether the Aux Send is before or after the fader doesn't make a difference.
If the Aux Send is removed, then all is OK and it no longer crashes
Seems to be tied to the feedback.
Tags: osc
Steps To Reproduce: In a session put an Aux Send on one track
With the OSC client connected and receiving feedback, select the track that has the send
Additional Information:
System Description
Attached Files:
Notes
(0028576)
Sogolumbo   
2024-02-29 18:48   
I found a bug which is probably related:
Ardour will crash if a bus has receives a send or if it has a track as an input when using the following setup.
Also the ID sent over OSC will be off by one (see logs below).

Steps to reproduce:
Version: Ardour8.4.0 (built using 8.4 and GCC version 13.2.0)
Add one track, one bus and one foldback bus to an empty project, enable OSC (Open Sound Control).
Add a send from the bus to the foldback bus.
Case 1: Do nothing
Case 2: Add send from track to bus
Case 3: Add track as input to bus
Start open-stage-control and connect to the foldback bus using OSC (using config [1]) .

[1] https://github.com/Sogolumbo/ardour-control/blob/1f1744d5133191366b9502320eac95bf39ac0fd0/ardour-foldback-strip.json

Results:
Case 1: Nothing bad happens, all controls in open-stage-control work.
Case 2: Ardour crashes.
Case 3: Ardour crashes.

bash log from Ardour:
/usr/include/c++/13.2.0/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = float; _Alloc = std::allocator<float>; reference = float&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

open stage control log (using -d command line option)
Case 1:
(DEBUG, OSC) Out: { address: '/cue/bus', args: [ { type: 'f', value: 1 } ] } To: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/name/1', args: 'Foldback' } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/name', args: 'Foldback' } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/mute', args: 0 } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/name', args: '0.00' } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/fader', args: 0.7817867398262024 } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/send/name/1', args: 'Bus 1' } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/send/name/1', args: '-0.03' } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/send/fader/1', args: 0.7809523940086365 } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/send/enable/1', args: 1 } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/signal', args: 0 } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/name', args: 'Foldback' } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/send/name/1', args: 'Bus 1' } From: 127.0.0.1:3819
Case 2 & 3 (same log):
(DEBUG, OSC) Out: { address: '/cue/bus', args: [ { type: 'f', value: 1 } ] } To: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/name/1', args: 'Foldback' } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/name', args: 'Foldback' } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/mute', args: 0 } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/name', args: '0.00' } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/fader', args: 0.7817867398262024 } From: 127.0.0.1:3819
(DEBUG, OSC) In: { address: '/cue/send/name/2', args: 'Bus 1' } From: 127.0.0.1:3819
(0028577)
Sogolumbo   
2024-03-01 02:17   
Update to my previous note:
I found this bug using the version 8.4.0 from flathub https://flathub.org/apps/org.ardour.Ardour
To try and further investigate the issue I downloaded the latest free debug nightly build (8.4.38). With that version I couldn't reproduce my issue.
Then I tested with the version 8.4.0 downloaded straight from ardour.org. Again I couldn't reproduce the issue.
Finally I got back to the version 8.4.0 from flathub. I uninstalled and reinstalled it just to check and the issue remained.

I have no idea what's going on to cause this issue but now we have a nice workaround for my issue: use the official version.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9620 [ardour] features feature always 2024-01-25 14:26 2024-02-29 08:56
Reporter: 9427421240 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Delay the display of the MIDI-info at the pointer while entering MIDI-notes and automation (or add a setting for it)
Description: While entering MIDI-notes with a (mouse-)pointer, Ardour displays information about the Note (note-name, note-number, channel, velocity, length) that will be added or is pointed at.
That info partially blocks the view towards the bottom-right of the pointer, and the text is changing/flickering quickly between note-names and numbers while moving the pointer in the MIDI-region.

Only showing the info after the pointer is not moving for a short time (~0.5-1 seconds), would prevent the flickering and the view-blocking while moving the pointer.
Additionally, fading the info in/out quickly (~50-100ms) would probably make it less distracting than the instant-change it does now.

A similar change could be applied to automation-point-info.
Moving the pointer along a drawn automation-curve with many densely placed points can also result in a flickering info-text.
The pointer also flickers a lot while doing that.

Alternatively, there could be an option to change the delay or to completely disable the info-text.
Tags: Accessibility, automation, Editor, Midi, workflow
Steps To Reproduce: MIDI-notes:
Add a MIDI-region, make it large enough, move the pointer up and down across notes while in pencil-mode (or move the cursor over existing notes, going past them, while in edit-mode).

Automation:
Add an automation-track to a MIDI-region, make it large enough, draw a curvy line to have a dense group of automation-points lined up, move the pointer along the automation points.
Additional Information:
Attached Files: Ardour-MIDI-info-text-flickering.webm (921,538 bytes) 2024-02-29 08:56
https://tracker.ardour.org/file_download.php?file_id=4802&type=bug
Notes
(0028575)
9427421240   
2024-02-29 08:56   
The flickering text in the piano-roll-editor makes me unable to compose/sequence/edit with the piano-roll-editor.
I usually quickly got a headache from that flickering when i tried to use the piano-roll-editor, because the flickering text is very distracting while i need to focus and do things quickly.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9629 [ardour] bugs minor always 2024-02-01 03:15 2024-02-29 03:32
Reporter: kamilner Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Content audition instrument GUI not correct when changing audition instrument
Description: When auditioning content in the Cue page, the default instrument is the General MIDI synth. If you change this to a new instrument, and then select the "show selected audition instrument's GUI" button, it shows the previously selected instrument's GUI initially. As soon as you audition a clip, it switches to the correct GUI

For example, if the previous instrument was General MIDI Synth, changing the instrument to Surge and then clicking the button will still show the General MIDI synth GUI.
Tags:
Steps To Reproduce: 1. Launch Ardour with a new session
2. Go to Cue screen
3. Select some bundled content and audition it
4. Change the audition instrument using the option beneath the content list
5. Select the "show selected audition instrument's GUI"

At this point the original General MIDI synth GUI is incorrectly shown.

6. Audition some content
7. Click on the "show selected audition instrument's GUI"

At this point the selected instrument's GUI is correctly shown.
Additional Information: This seems to occur regardless of the instrument chosen. And it happens consistently. So, for instance, switching back from Surge to General MIDI synth and clicking on the button will show the Surge GUI even thought he GM Synth has been selected.
System Description
Attached Files: Ardour bug screenshot.png (55,150 bytes) 2024-02-01 03:15
https://tracker.ardour.org/file_download.php?file_id=4779&type=bug
png
Notes
(0028485)
kamilner   
2024-02-01 05:28   
Config:

Build documentation: False
Debuggable build: False
Export all symbols (backtrace): False
Install prefix: /usr
Strict compiler flags: []
Internal Shared Libraries: True
Use External Libraries: False
Library exports hidden: True
Free/Demo copy: False

ALSA DBus Reservation: True
Architecture flags: None
ARM NEON support: False
Aubio: True
AudioUnits: False
Build target: x86_64
Canvas Test UI: False
Beatbox test app: False
CoreAudio: False
CoreAudio 10.5 compat: False
Debug RT allocations: False
Debug Symbols: False
Denormal exceptions: False
Dr. Mingw: False
FLAC: True
FPU optimization: True
FPU AVX512F support: False
FPU AVX/FMA support: True
Futex Semaphore: True
Freedesktop files: False
Libjack linking: weak
Libjack metadata: True
Lua Binding Doc: False
Lua Commandline Tool: True
LV2 UI embedding: True
LV2 support: True
LV2 extensions: True
LXVST support: True
Mac VST support: False
NI-Maschine: False
OGG: True
Phone home: True
Process thread timing: False
Program name: Ardour
Samplerate: True
PT format: True
PTW32 Semaphore: False
Threaded WaveViews: True
Translation: True
Unit tests: False
Use LLD linker: False
VST3 support: True
Windows VST support: False
Wiimote support: False
Windows key: Mod4><Super

PortAudio Backend: False
CoreAudio/Midi Backend: False
ALSA Backend: True
Dummy backend: True
JACK Backend: True
PulseAudio Backend: True

Buildstack: 7a0b7d4
Mac i386 Architecture: False
Mac ppc Architecture: False
Mac arm64 Architecture: False

C compiler flags: ['-I/home/ardour/linux-x86_64-v5/ardour', '-I/home/ardour/linux-x86_64-v5/gtk/inst/include', '-DHAVE_RF64_RIFF', '-DCOMPILER_INT128_SUPPORT', '-DWAF_BUILD', '-DNDEBUG', '-std=c99', '-pedantic', '-Wshadow', '-Wall', '-Wcast-align', '-Wextra', '-Wwrite-strings', '-Wunsafe-loop-optimizations', '-Wlogical-op', '-fshow-column', '-O3', '-fomit-frame-pointer', '-ffast-math', '-fstrength-reduce', '-pipe', '-DARCH_X86', '-mmmx', '-msse', '-mfpmath=sse', '-DUSE_XMMINTRIN', '-DBUILD_SSE_OPTIMIZATIONS', '-DLXVST_64BIT', '-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', '-DBOOST_SYSTEM_NO_DEPRECATED', '-DBOOST_BIND_GLOBAL_PLACEHOLDERS', '-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="8"', '-Wstrict-prototypes', '-Wmissing-prototypes', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gtk-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/gtk-2.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pango-1.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/atk-1.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/cairo', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pixman-1', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gdk-pixbuf-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/libpng16', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/harfbuzz', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/fribidi', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/glib-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/glib-2.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/uuid', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/libxml2', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/freetype2', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gtkmm-2.4', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/gtkmm-2.4/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/atkmm-1.6', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gtk-unix-print-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gtk-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gdkmm-2.4', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/gdkmm-2.4/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/giomm-2.4', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/giomm-2.4/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pangomm-1.4', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/pangomm-1.4/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/glibmm-2.4', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/glibmm-2.4/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/cairomm-1.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/cairomm-1.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/sigc++-2.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/gtk-2.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pango-1.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/atk-1.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/cairo', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pixman-1', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gdk-pixbuf-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/libpng16', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/harfbuzz', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/fribidi', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/glib-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/glib-2.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/uuid', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/libxml2', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/freetype2']
C++ compiler flags: ['-I/home/ardour/linux-x86_64-v5/ardour', '-I/home/ardour/linux-x86_64-v5/gtk/inst/include', '-DHAVE_RF64_RIFF', '-DCOMPILER_INT128_SUPPORT', '-DWAF_BUILD', '-DNDEBUG', '-Wnon-virtual-dtor', '-Woverloaded-virtual', '-fstrict-overflow', '-Wall', '-Wcast-align', '-Wextra', '-Wwrite-strings', '-Wunsafe-loop-optimizations', '-Wlogical-op', '-fshow-column', '-O3', '-fomit-frame-pointer', '-ffast-math', '-fstrength-reduce', '-pipe', '-DARCH_X86', '-mmmx', '-msse', '-mfpmath=sse', '-DUSE_XMMINTRIN', '-DBUILD_SSE_OPTIMIZATIONS', '-DLXVST_64BIT', '-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', '-DBOOST_SYSTEM_NO_DEPRECATED', '-DBOOST_BIND_GLOBAL_PLACEHOLDERS', '-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="8"', '-std=c++11', '-DBOOST_NO_AUTO_PTR', '-DBOOST_BIND_GLOBAL_PLACEHOLDERS', '-Woverloaded-virtual', '-Wno-unused-local-typedefs', '-D__STDC_LIMIT_MACROS', '-D__STDC_FORMAT_MACROS', '-DCANVAS_DEBUG', '-DBOOST_ERROR_CODE_HEADER_ONLY', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gtk-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/gtk-2.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pango-1.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/atk-1.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/cairo', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pixman-1', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gdk-pixbuf-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/libpng16', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/harfbuzz', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/fribidi', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/glib-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/glib-2.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/uuid', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/libxml2', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/freetype2', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gtkmm-2.4', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/gtkmm-2.4/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/atkmm-1.6', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gtk-unix-print-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gtk-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gdkmm-2.4', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/gdkmm-2.4/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/giomm-2.4', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/giomm-2.4/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pangomm-1.4', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/pangomm-1.4/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/glibmm-2.4', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/glibmm-2.4/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/cairomm-1.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/cairomm-1.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/sigc++-2.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/gtk-2.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pango-1.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/atk-1.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/cairo', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/pixman-1', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/gdk-pixbuf-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/libpng16', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/harfbuzz', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/fribidi', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/glib-2.0', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/lib/glib-2.0/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/uuid', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/libxml2', '-isystem', '/home/ardour/linux-x86_64-v5/gtk/inst/include/freetype2']
Linker flags: ['-L/home/ardour/linux-x86_64-v5/gtk/inst/lib']
(0028555)
kamilner   
2024-02-26 06:01   
Still not working correctly on 8.4
(0028559)
x42   
2024-02-27 17:41   
(Last edited: 2024-02-27 17:42)
> At this point the original General MIDI synth GUI is incorrectly shown.

General MIDI Synth has no GUI. This is a default MIDI Program selector.

Here It shows the default MIDNAM file (subtle difference from General MIDI synth), and yes. Surge does not provide MIDI Patch files to Ardour, so Ardour uses the default.
On MIDI tracks you can change this in the track-header, there is currently no support to tweak this for Audition.

I'll put it on the list to add proper support for plugin UIs. -- We started doing this and dropped it.
(0028574)
kamilner   
2024-02-29 03:32   
To be clear: this bug report wasn't about the audition synth GUIs themselves (which, by the way, seem to all work OK for me).

It's about the fact that the wrong thing is shown when you click on the "Show selected audition instrument's GUI" button after you select an instrument. That happens irrespective of whether the instruments have a GUI or not.
For example:
If I have "padthv1" selected as my audition instrument and have auditioned a clip with it, then when I click on the "show GUI" button, I get the appropriate pop-up box (which is, basically, a blank box with a description drop down, as the padthv1 instrument has neither a GUI, nor any controls). I'm fine with that.

BUT... If I then select "General MIDI Synth" as the audition instrument and then click on the "show GUI" button, I still get the blank padthv1 pop-up, instead of the General MIDI Synth one.

This happens regardless of which synth is previously or subsequently selected, or whether it has controls, or a GUI, or not.

To me it looks like, when a new audition instrument is selected, Ardour doesn't switch to that instrument straight away. Instead, the switch is done just before the actual audition is performed. Because of this, the wrong pop-up is shown.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9625 [ardour] bugs crash always 2024-01-28 07:01 2024-02-28 08:18
Reporter: antice Platform: Linux  
Assigned To: OS: Linux Mint  
Priority: normal OS Version: 21.3  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when I run Audacity at the same time
Description: One of my workflows is the following:
- Use Ardour to record and create songs
- Export audio to file
- Edit the file in Audacious (Ardour must be on at the background)
- Crash

I have included a crash report to this issue. I can provide more details but I believe the crash is in the report. These lines were outputted when it happened:

```[Thread 0x7fff917fa640 (LWP 14797) exited]
HostPlaying changed: inQuarter: 285.956771, lastQuarter 286.169792 currentQuarter 294.418681
HostPlaying changed: inQuarter: 281.894271, lastQuarter 282.107813 currentQuarter 282.250035
terminate called after throwing an instance of 'std::logic_error'
  what(): basic_string::_M_construct null not valid

Thread 38 "pw-ardour" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffc0ffd640 (LWP 14782)]
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140736431380032) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
```
Tags:
Steps To Reproduce: - Use Ardour to record and create songs
- Export audio to file
- Edit the file in Audacious (Ardour must be on at the background)
- Crash
Additional Information: Ardour 8.2.0, "Tracks and Traces", (rev 8.2), Intel 64-bit (prebuilt binary from the website)
Linux ***** 6.5.0-14-generic 00000140000047:0000022.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Nov 20 18:15:30 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Linux Mint 21.3 Xfce Edition
Attached Files: ardour_crash.log (61,012 bytes) 2024-01-28 07:01
https://tracker.ardour.org/file_download.php?file_id=4776&type=bug
ardour-145-crash.log (97,241 bytes) 2024-02-19 14:36
https://tracker.ardour.org/file_download.php?file_id=4781&type=bug
Notes
(0028490)
paul   
2024-02-09 14:21   
(Last edited: 2024-02-09 14:23)
This is most likely a pipewire issue, and not Ardour's fault.

That said, please get a debug build (e.g. from nightly.ardour.org) and then get a full backtrace from that so we can see line numbers.
(0028494)
antice   
2024-02-13 08:01   
> That said, please get a debug build (e.g. from nightly.ardour.org) and then get a full backtrace from that so we can see line numbers.

Didn't I do full backtrace? I will compile a nightly version but, how do I do full backtrace?
(0028495)
paul   
2024-02-13 15:38   
You did a full backtrace, but it was on a non-debug build which makes the information significantly less useful.
(0028496)
x42   
2024-02-13 17:33   
unrelated to this pipewire issue, I am curious what post processing you do in Audacious, would you mind to elaborate?
(0028498)
antice   
2024-02-14 04:44   
> unrelated to this pipewire issue, I am curious what post processing you do in Audacious, would you mind to elaborate?

I record my vocals using Ardour and then edit out the breathing sounds using Audacity. I just realized I was talking about Audacity in the title, but I said Audacious in the text itself. This was my mistake, I often mix those two because of the similar names.
(0028499)
antice   
2024-02-14 05:52   
I tried to run the nightly build, but it won't start:

```
./ardour-8.2.115 --gdb
./ardour-8.2.115: error while loading shared libraries: libardourcp.so: cannot open shared object file: No such file or directory
```
(0028500)
paul   
2024-02-14 06:16   
You need to use "ardour8". "ardour-X.Y.Z" requires some stuff being setup in the environment - "ardour8" is a script that does that.
(0028501)
antice   
2024-02-14 10:14   
Oh my :/

```
./ardour8 --gdb
gdb: symbol lookup error: /lib64/libbabeltrace.so.1: undefined symbol: g_string_free_and_steal
```
(0028502)
paul   
2024-02-14 14:07   
Yeah, this is a recent development on some linux distros. No way to run gdb on the version of ardour that we build.
(0028503)
paul   
2024-02-14 14:50   
now fixed, will be in the next nightly and 8.3 ... (just the gdb error)
(0028504)
antice   
2024-02-17 07:54   
I'm sorry, I had a rough work week and didn't have time to get into this. I still get the same error even when I downloaded a newer nightly build:

```
./ardour8 --gdb
gdb: symbol lookup error: /lib64/libbabeltrace.so.1: undefined symbol: g_string_free_and_steal

./ardour8 --version
bind txt domain [gtk2_ardour8] to /opt/Ardour-8.2.138-dbg/share/locale
Ardour8.2.138 (built using 8.2-138-g20d813cd17 and GCC version 6.3.0 20170516)
```
(0028505)
x42   
2024-02-17 15:43   
Oh dear my fault. Fixed in 8.2-144. Short of waiting for the nightly build, you could edit ardour8 and remove line 45 (like https://github.com/ardour/ardour/commit/0bd1a10709)
(0028520)
antice   
2024-02-19 14:36   
Now I got it to work, thank you x42 and Paul for your help! I noticed that I cannot reproduce the issue with an empty project or using a project that had some audio and MIDI tracks in it. I had to use one of my "main" projects, so to speak. I think WINE also plays some part here since I had to use a project that used WINE and yabridge to be able to reproduce the issue. Also I am no longer using Linux Mint since I needed a newer kernel for my sound card so this was done on Fedora 39, x86_64. I can provide any additional info upon request.

```
uname -a
Linux Machine 6.8.0-0.rc3.20240210gt4a7bbe75.231.vanilla.fc39.x86_64 0000001 SMP PREEMPT_DYNAMIC Sat Feb 10 06:20:49 UTC 2024 x86_64 GNU/Linux

username@Machine /o/A/bin> ./ardour8 --version
bind txt domain [gtk2_ardour8] to /opt/Ardour-8.2.145-dbg/share/locale
Ardour8.2.145 (built using 8.2-145-g0e88df426e and GCC version 6.3.0 20170516)
```
(0028571)
antice   
2024-02-28 08:18   
Did you find the reason for this? @paul or @x42?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9647 [ardour] features tweak always 2024-02-27 19:47 2024-02-27 22:01
Reporter: Attila S. Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow inserting bus into another bus without feedback loop problem indication
Description: First, to make it clear, this report is about inserting a bus into another bus, and NOT about inserting a bus into a track.

So allow inserting bus into another bus without feedback loop problem indication.

- Because it seems to work correctly.

- Because it is a most useful thing: for example I can set up an elaborated multiband compression or broadcast processor scheme in a bus (used as a plugin chainer) and I can insert it to my main bus as a single and easily bypassable "plugin".

- Because it is not the case of "an audio signal chain is plugged back to its input" as the user manual describes what the Feedback indicator really shows: "Feedback - Blinks when Ardour detects a feedback loop, which happens when the output of an audio signal chain is plugged back to its input. This is probably not wanted and can be dangerous for the hardware and the listener."
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028566)
x42   
2024-02-27 20:21   
> First, to make it clear, this report is about inserting a bus into another bus, and NOT about inserting a bus into a track.

Same things. Tracks are really just busses with a disk-reader. (We call those "Routes")
When it comes to processing, the smallest unit is a Route, which is monolithic. You cannot insert a Route to be processed inside a route. Sorry.


Feedback indicates that the process graph is not acyclic. Or In other words: there is a cyclic dependency. Route A depends on route B, and Route B depends on Route A. A feedback loop (unrelated but correlated to audible feedback).
(0028567)
Attila S.   
2024-02-27 20:33   
"You cannot insert a Route to be processed inside a route. Sorry."

Right.
At the same time why can I do it in Ardour and why is it working?
And if I insert an intermediate Jack passthrough then how is that different? Is that different or correct? Because then the feedback indicator does no blinking.
(0028568)
x42   
2024-02-27 21:08   
Ardour allows you to temporarily create feedback. e.g. connect first (feedback) then disconnect (feedback resolved).
This was motivated for for live mixing where you don't want to interrupt signal flow.
During the intermediate state the old process graph and process order is used. Ardour switches to the new graph once the feedback is resolved.

> And if I insert an intermediate Jack passthrough then how is that different?

It is delayed by 2 process cycles.

Ardour's route runs: reads data in jack's input. and writes data for jack client to process next cycle.
Ardour finishes processing. jack client wakes up, processes data and writes it to the port for Ardour to use.
(0028569)
Attila S.   
2024-02-27 21:51   
I see. Thank you Robin for informing me.
One more question: Should/could I create future request for a plugin chainer?
The current plugins section from a bus would be good as a single plugin.
(0028570)
Attila S.   
2024-02-27 22:01   
future request = feature request :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9015 [ardour] bugs crash always 2022-10-20 13:52 2024-02-27 20:12
Reporter: murk Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Using the plugin "EQ10Q Mono" crashes Ardour
Description: I have a project that I started with ardour 6, and had used the plugin "EQ10Q Mono" for quite many stereo tracks. After updating Arch, Ardour updated from 6 to 7. Then after I opened the Ardour 6 project, Ardour 7 crashed. I tested with a new project on Ardour 7, and noticed that "EQ10Q Mono" works for mono tracks, but adding the plugin to a stereo track causes a crash.

The crash message is

```
ardour-7.0.0: /usr/lib/lv2/atom.lv2/forge.h:198: lv2_atom_forge_pop: Assertion `frame == forge->stack' failed.
/usr/bin/ardour7: line 1: 262008 Aborted (core dumped) ardour7
```
Tags:
Steps To Reproduce: 1. Open new project
2. Add a stereo track
3. Add "EQ10Q Mono" plugin to the track
-> Ardour crashes
Additional Information:
System Description
Attached Files: eq10q MONO GDB (42,403 bytes) 2024-02-27 18:58
https://tracker.ardour.org/file_download.php?file_id=4799&type=bug
Notes
(0026654)
x42   
2022-10-20 14:00   
Perhaps try Ardour's binary from ardour.org and the EQ10Q from https://eq10q.sourceforge.net/?page_id=16

The crash being in /usr/lib/lv2/atom.lv2/forge.h suggests that it is be something related to you distro.
A complete backtrace (https://ardour.org/debugging_ardour) may provide further information.
(0028562)
mhermozap   
2024-02-27 18:58   
Hi, I have the exact same issue. I used Ardour 5 for several years without problems and now when I jumped from Ardour 5 to Ardour 8.4 I realized eq10q MONO crashes Ardour when the plugin is loaded on:
- the master stereo track
- simple midi track
- midi bus

I'm attaching the debug output related to the "master stereo track" use case.
Hope this could be solve in the short term.

Thank you in advance!
(0028564)
x42   
2024-02-27 20:12   
There is a conflict between the GTK version EQ10Q uses and the one that is now built into Ardour.

See also https://discourse.ardour.org/t/ardour-8-4-calf-plugins-error-failed-to-instantiate-lv2-gui/109936/4
which mentions EQ10Q as well. Debian will drop packaging EQ10Q next week, Arch will as well in the not too distant future.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9646 [ardour] bugs major always 2024-02-26 13:53 2024-02-27 18:24
Reporter: Attila S. Platform: GNU  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Insert produces mono output for 3-4 in a 4ch bus
Description: In a four channel bus the Insert's "Return/Input" part produces mono output for 3-4. Actually passes 4 to 3-4.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028557)
Attila S.   
2024-02-26 16:57   
This happens if I return 2 stereo bus. But works correctly with a returned 4 channel bus.
(0028560)
x42   
2024-02-27 17:44   
Could this be caused by the VBAP panner? Does bypassing the panner help?
(0028561)
Attila S.   
2024-02-27 18:24   
Actually bypassing the VBAP panner "causes" this problem.

This is how the situation looks:

If the VBAP panner enabled on Stereo Bus 1 and 2 then:
- Bus 1 is not returned, there is no sound on 1-2.
- Bus 2 is returned correctly to 3-4.

If the VBAP panner bypassed on Stereo Bus 1 and 2 then:
- Bus 1 is returned correctly to 1-2.
- Bus 2 is returned with the described mono sound to 3-4.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9631 [ardour] bugs crash always 2024-02-03 04:23 2024-02-26 06:04
Reporter: kamilner Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Opening synth plugn GUI for Cue content audition crashes on some instruments
Description: When in the Cue page and auditioning MIDI clip content, if the audition instrument is changed to a different synth and the synth GUI is opened, it causes Ardour to crash.

This seems to only happen with synth plugins that have a non-system GUI. WHen I have tried it with ACE Fluidsynth, for example, it does not seem to crash.

Note adding the above synth plugins to a track and opening the plugin GUI from there does not cause the crash. This seems to be limited to using the plugin GUI from the Cue page auditioner.
Tags:
Steps To Reproduce: 1. Launch Ardour and open a new session
2. Navigate to Cue page
3. Make sure autoplay is unticked
4. Select some MIDI content to audition from the content list
5. Select a synth plugin with a non system GU (e.g. dexed, Surge, Vitalium, ZynAddSubFx)
6. Click the audition play to play the content to allow the plugin GUI to be accessed (see bug report 0009629 https://tracker.ardour.org/view.php?id=9629 )
7. Click on the button to select the audition instrument GUI
8. Wait a few seconds...


Additional Information: In GDB, at the point of crash I get the following:

corrupted double-linked list

Thread 1 "ArdourGUI" received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737299503360) at ./nptl/pthread_kill.c:44
Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c.
44 ./nptl/pthread_kill.c: No such file or directory.
System Description
Attached Files: Ardour bug report backtrace.txt (74,911 bytes) 2024-02-03 04:23
https://tracker.ardour.org/file_download.php?file_id=4780&type=bug
Notes
(0028556)
kamilner   
2024-02-26 06:04   
This doesn't seem to be crashing on v8.4, although the audition playback seems to falter when you change instruments and then click the play button to audition. It's is as if Ardour doesn't notice that the instrument has changed until it starts trying to audition, and then tries to switch plugin (which also aligned with the behaviour in 0009629)

https://tracker.ardour.org/view.php?id=9629

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9645 [ardour] bugs block always 2024-02-24 17:51 2024-02-24 17:51
Reporter: Djkato Platform: PC  
Assigned To: OS: Garuda Linux x86_64  
Priority: high OS Version: 6.7.5-zen1-1-zen  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on Arch - 'ardour8' terminated by signal SIGILL (Illegal instruction)
Description: Trying to use ardour8, no matter what sound API I try or what window thingy I use (Wayland, X11), I cannot get past the project creation screen. The furthest I got is by selecting new session, Advanced Session, using PulseAudio api. It asks me for template setup (master bus channels, auto connect stuff) pressing ok crashes, or pressing cancel and trying to import audio crashes. I am using Pipewire as my main audio thingy, and have all the compatibility layers for alsa, jack, pipewire.
Tags: crash
Steps To Reproduce: install from anywhere on garuda (yay ardour-git, sudo pacman -S ardour, yay ardour), try to open, fail.
Additional Information: Ardour8.4.0 (built using 8.4 and GCC version 13.2.1 20230801)
Ardour: [INFO]: Your system is configured to limit Ardour to 1048576 open files
Ardour: [INFO]: Loading system configuration file /etc/ardour8/system_config
Ardour: [INFO]: Loading user configuration file /home/djkato/.config/ardour8/config
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: AVX512F capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 7 7700X 8-Core Processor
Ardour: [INFO]: Using AVX512F optimized routines
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour8/plugin_metadata/plugin_tags
Ardour: [INFO]: add_lrdf_data '/home/djkato/.config/ardour8/rdf:/usr/share/ardour8/rdf:/usr/local/share/ladspa/rdf:/usr/share/ladspa/rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/ladspa.rdfs'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/ladspa-rubberband.rdf'
Ardour: [INFO]: Loading default ui configuration file /etc/ardour8/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/djkato/.config/ardour8/ui_config
Ardour: [INFO]: Loading 459 MIDI patches from /usr/share/ardour8/patchfiles
Ardour: [INFO]: Loading colour file /usr/share/ardour8/themes/dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file /etc/ardour8/clearlooks.rc
start clocking
Ardour: [INFO]: Loading bindings from /etc/ardour8/ardour.keys
Loading ui configuration file /etc/ardour8/clearlooks.rc
Found nothing along /home/djkato/.config/ardour8/templates:/usr/share/ardour8/templates
Set cursor set to default
start clocking
Setting time domain
fish: Job 1, 'ardour8' terminated by signal SIGILL (Illegal instruction)

Ardour8.4.0 (built using 8.4 and GCC version 13.2.1 20230801)
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9644 [ardour] bugs crash always 2024-02-23 10:17 2024-02-24 14:53
Reporter: r1911 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: After updating Ardour from 8.2 to 8.4, my session started crashing
Description: I've attached the "Ardour8 --gdb" output to this ticket
Tags:
Steps To Reproduce: Update Ardour from 8.2 to 8.4. See the existing session crash Ardour when opened.
Additional Information:
System Description
Attached Files: ardour_8.4_crash.txt (48,150 bytes) 2024-02-23 10:17
https://tracker.ardour.org/file_download.php?file_id=4795&type=bug
test 1.ardour (585,475 bytes) 2024-02-23 13:12
https://tracker.ardour.org/file_download.php?file_id=4796&type=bug
Notes
(0028541)
r1911   
2024-02-23 13:12   
the session file in question
(0028542)
x42   
2024-02-23 14:34   
The crash happens in Surge.lv2 -- Which version of Surge are you using?

There were various known issues with older versions of Surge.
If I remember correctly for the LV2 variant, you need Surge >= 1.3.0
(0028549)
r1911   
2024-02-24 13:23   
Surge is 5:1.7.1-1kxstudio1. I'm now using Surge VST3 and the session is back alive

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9513 [ardour] bugs crash always 2023-10-28 18:08 2024-02-24 14:53
Reporter: akik Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.1  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 8.1.0 debug nightly build crashes with my session created in Ardour 7.5.0 non-debug build
Description: Ardour 8.1.0 debug nightly build crashes with my session created in Ardour 7.5.0 non-debug build

I couldn't find the Ardour 7.5.0 debug nightly build so I used the newer version

The session started crashing in Ardour 7.5.0 non-debug build and that's why I opened this bug report
Tags:
Steps To Reproduce: I followed the instructions on page https://ardour.org/debugging_ardour
Additional Information:
System Description
Attached Files: ardour_gdb_backtrace.txt (48,599 bytes) 2023-10-28 18:08
https://tracker.ardour.org/file_download.php?file_id=4687&type=bug
ardour_gdb_backtrace_2.txt (54,643 bytes) 2023-11-08 22:32
https://tracker.ardour.org/file_download.php?file_id=4705&type=bug
test 1.ardour (289,347 bytes) 2023-11-08 22:34
https://tracker.ardour.org/file_download.php?file_id=4706&type=bug
test 1-2.ardour (319,913 bytes) 2023-11-25 13:34
https://tracker.ardour.org/file_download.php?file_id=4722&type=bug
image.png (16,467 bytes) 2024-02-19 15:35
https://tracker.ardour.org/file_download.php?file_id=4782&type=bug
png

image-2.png (15,740 bytes) 2024-02-19 15:35
https://tracker.ardour.org/file_download.php?file_id=4783&type=bug
png
Notes
(0028266)
akik   
2023-10-28 18:16   
Here's the log from the terminal when i started Ardour 7.5.0 non-debug build in it (ends up in segmentation fault):

https://akik.kapsi.fi/ardour/startup_log.txt
(0028267)
x42   
2023-10-28 22:23   
Which thread crashed? That part is missing form the backtrace.

It could be caused by jack timebase master. Stop JACK, load the session using ALSA or PulseAudio backend, then Session > Properties > Sync, disable Ardour is JACK time master

It could also be caused by surge. See if the session loads when you use "[x] safe mode: disable plugins" in the recent session dialog.

..Or it could be caused by parsing MIDI CCs Automation Mode from XML.
(0028269)
akik   
2023-10-28 22:45   
If I stop Jack, I can't even open the saved/crashing session.
(0028270)
akik   
2023-10-28 22:50   
Here's a more complete gdb backtrace:

https://akik.kapsi.fi/ardour/ardour_gdb_backtrace2.txt
(0028271)
x42   
2023-10-28 23:59   
OK so it is surge (LV2 plugin) that crashes..
The session should load in safe mode, can you confirm hat?
(0028272)
x42   
2023-10-29 00:59   
Solve via discussion on IRC: Removing and re-adding surge make the session load again.

reason unknown.
(0028308)
akik   
2023-11-08 22:31   
Now Ardour 8.1.0 started crashing also after removing the midi track that I earlier had the Yoshimi plugin on.

I've attached the gdb backtrace from 8.1.40-dbg and the .ardour session file.
(0028309)
akik   
2023-11-08 22:32   
gdb backtrace for ardour 8.1.40-dbg
(0028310)
akik   
2023-11-08 22:34   
my empty ardour 8.1.0 session file with 4 midi tracks: 1) for korg 01w, 2) for korg triton, 3) for zynaddsubfx, 4) for surge
(0028323)
akik   
2023-11-14 01:29   
problem was magically fixed
(0028355)
akik   
2023-11-25 13:33   
Here's the Ardour session that doesn't crash any more. It includes two midi tracks for my two hw synths, and then a midi track each for ZynAddSubFX, Surge and Yoshimi + an empty midi track
(0028356)
akik   
2023-11-25 13:34   
(0028357)
x42   
2023-11-25 13:54   
Does it crash here, but I don't lack some of the plugins (I miss Surge.lv2 and Yoshimi LV2) - ZynAddSubFX loads fine.

Does it crash when you open the session in safe mode (disable all plugins)? Checkbox in Ardour's recent session dialog?
Chances are the the crash is the same as above in Surge LV2.
(0028358)
akik   
2023-11-25 13:58   
surge is from kxstudio and yoshimi from ubuntu 22.04 repos. of course it works when i disable the plugins on session load requestor
(0028359)
x42   
2023-11-25 14:13   
Well, there's nothing we can do, other than suggest you get a recent version of SurgeXT VST3.

(I doubt that they fix bus in old Surge LV2)
(0028360)
akik   
2023-11-25 14:17   
not sure if you read what i wrote in my previous comment "Here's the Ardour session that doesn't crash any more."

it's just a bug in ardour. surge loads just fine now. as you can see i have 0 midi regions in those sessions so it shouldn't be so hard to debug
(0028521)
lmat   
2024-02-19 15:35   
I tried to reproduce this just now and was unable. I loaded the problem session file and it looks fine. It looks like Ardour used ZynAddZubFx plugin rather than Yoshimi. Here are versions:

* Surge 1.9.0-3
* zynaddsubfx 3.0.6-5
* Arch Linux
* XFCE
* Ardour 8.1-1

I'm opening with a pulseaudio backend. I installed yoshimi 2.3.1.3-1, replaced the plugin, saved the project and reopened again without issue (see second screen shot).

Let me know if there is some other instruction to reproduce.
(0028522)
akik   
2024-02-19 15:42   
I don't have the crashing problem any more. Fixed it months ago

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9641 [ardour] bugs major always 2024-02-22 04:33 2024-02-24 00:45
Reporter: Werner Back Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Wrong behaviour Shift+Click in groups
Description: I created a group in the mixer for having a better view, not using the functions of the group. All checkboxes were unchecked (except "Active" of course).
Then I wanted to set one Fader to 0dB with shift+click. Unexpectedly ALL faders changed. This ruined my mix.
Tags: mixer groups shortcuts
Steps To Reproduce: 1. Create group with some channels in it
2. Uncheck all the checkboxes except "Active"
3. Set the faders to different levels
4. Make sure there is no channel selected
5. Click shift+click on one fader

All channels will move. Since the "Volume" checkbox is unchecked the expected behaviour is that only the selected fader moves.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7741 [ardour] features minor always 2019-03-20 23:22 2024-02-24 00:45
Reporter: colinf Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 5.X git (version in description)  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Group gain sharing should never happen for groups where it's not enabled
Description: If I want a group to have gain sharing (either absolute or relative), I'll enable it in the group's properties. If I don't want a group to have gain sharing by default, I certainly don't want it to have gain sharing when I <Shift>+Click on any of the groups faders. There are more use cases for groups without gain sharing than with it, in my experience, especially now that we have VCAs, which do all that group gain sharing could and more.
Tags:
Steps To Reproduce:
Additional Information: I have a vague memory of making this report before, but I can't find it now...
Attached Files: grouped-fader-shift-click.ods (11,974 bytes) 2022-05-22 13:56
https://tracker.ardour.org/file_download.php?file_id=4189&type=bug
0001-gtk2_ardour-only-allow-shift-click-to-disengage-fade.patch (1,219 bytes) 2022-05-22 17:58
https://tracker.ardour.org/file_download.php?file_id=4190&type=bug
0001-gtk2_ardour-only-allow-shift-click-to-disengage-fade-2.patch (1,213 bytes) 2022-07-15 16:41
https://tracker.ardour.org/file_download.php?file_id=4198&type=bug
0002-gtk2_ardour-disable-reset-to-default-on-shift-click-.patch (1,275 bytes) 2022-07-23 14:58
https://tracker.ardour.org/file_download.php?file_id=4201&type=bug
0001-libs-widgets-allow-fader-to-opt-out-of-shift-click-r.patch (1,553 bytes) 2022-07-23 14:58
https://tracker.ardour.org/file_download.php?file_id=4202&type=bug
Notes
(0020925)
colinf   
2020-01-22 12:34   
This still bothers me. I might have just grouped some tracks to record-enable them together more easily, or even just to make them all the same colour - I really never want gain-sharing for such a group, shift pressed or not.

I do find <shift>+click on faders to reset them occasionally useful, but if I accidentally<shift>+click a grouped fader it'll reset all the faders of the group, regardless of what the group is for. Worse, it doesn't even do it consistently: it depends on the setting of the group's 'Relative' gain tick box (which isn't even enabled if 'Gain' is unticked) as to whether the other faders in the group will all reset to 0dB, or keep their gains relative to the 0dB level of the <shift>+clicked fader. Worse still, even if 'Relative' is ticked, faders that would have gone above +6dB are clamped to +6dB, and even the relative balance of the group faders is lost.
(0020930)
bluebones   
2020-01-25 13:27   
+1

Would be nice to have the handy shift+click gain reset back affecting just one track, given that Gain is unticked on group settings.
(0020931)
bluebones   
2020-01-25 13:39   
I'd add that this happens even with group's side label deactivated, which actually makes me think of it as a bug rather than a feature request.
(0020937)
colinf   
2020-01-27 19:30   
And it's no less inconsistent when a group has 'gain' sharing enabled: in that case, <shift>+click on a grouped fader resets just that fader to 0dB, except if the group itself is disabled, in which case it resets all the faders, relatively or absolutely according to the 'relative' setting.
(0020938)
colinf   
2020-01-27 19:34   
I believe that <shift> was originally supposed to invert the enabled status of a group when clicking on elements of tracks with that group, but even that doesn't seem consistent: some mixer strip controls (e.g. record arm) treat <ctrl > in that way instead.
(0026433)
johne53   
2022-05-05 09:20   
This relates to a bug we've been discussing on the Mixbus forum. Mixbus has a few problems of its own but AFAICT, when the Shift key is being pressed, neither Mixbus nor Ardour take any notice of a group's Gain Sharing status :-(

Surely this can't be difficult to fix ?
(0026453)
x42   
2022-05-21 21:13   
This is intended behavior. Holding down the primary modifier key inverts group behavior: `InverseGroup` (enable disabled groups, disable enabled groups or group-settings)
(0026454)
johne53   
2022-05-22 10:46   
Hi Robin - the problem is that different controls exhibit different behaviours. Mixbus has some additional issues (controls on the Mixer don't always behave like they do in the Editor) but let's just concentrate on Ardour for now...

1) Add 2 tracks to a group and then edit the group to remove the gain control.
2) Each fader behaves (correctly) as though it's not part of the group. And using Shift+ inverts that behaviour (correctly, as we now know...)
3) Now try removing some buttons from the group (let's say the Muting button)
4) Each Mute button now behaves (correctly) as if it's not part of the group - BUT... using Shift+ makes no difference (i.e. it doesn't invert the behaviour)
(0026455)
colinf   
2022-05-22 13:56   
I made a spreadsheet (I know, sorry) enumerating the the <Shift>+click fader behaviour for all the possible states of group enabled/gain sharing/relative to see if it made any more sense seeing it in a table like that. Here it is: is this really all intended behaviour?
(0026456)
colinf   
2022-05-22 14:01   
Incidentally, there's also this comment in gtk2_ardour/gain_meter.cc:586

        // XXX hack allow to override group
        // (this breaks group'ed shift+click reset)

I'd argue that breaking <shift>+click reset to 0dB is rather a steep price to pay to allow three different ways to override disabling group gain sharing to exist.
(0026457)
colinf   
2022-05-22 14:06   
Also, it seems perverse to me that a disabled (greyed-out) tick box in the group properties should affect the behaviour of the group.
(0026458)
colinf   
2022-05-22 17:58   
Attached a (trivial) patch to only allow <shift>+click to disable gain sharing if it's enabled in the active group's properties, and not to enable it if it's disabled. I personally think this is better: if the behaviour of enabling gain sharing in a disabled group is also required I really do believe something rather more clever is required than the current code.
(0026505)
colinf   
2022-07-15 16:41   
Updated patch to fix merge conflict after 6089ae93 attached. I still find it hard to believe that the behaviour of <shift>+click on faders of channels in disabled groups without this patch is either intended or desirable.
(0026519)
colinf   
2022-07-23 14:58   
An alternative approach, if the <Shift> override to enable gain sharing is really deemed more important than <Shift>+click to reset to 0dB could be disabling the reset to 0dB behaviour for grouped tracks. I don't like it, but at least it removes the "Oops, I just set all these faders and I don't know how to put them back" on <Shift>+click behaviour, which was my original motivation for this report.

Alternative hacky patches attached (001-libs-widgets-allow-fader-to-opt-out-of-shift-click-r.patch & 0002-gtk2_ardour-disable-reset-to-default-on-shift-click-.patch) to do this, in case anyone's interested.
(0028439)
colinf   
2023-12-28 16:07   
Now that gain fader adjustments work on all selected tracks, the behaviour is even more confusing, especially since a click in the fader doesn't actually select the track.

Now, <shift>+click on a fader in an inactive group still, adjusts the faders of all tracks in the group, regardless of whether they are selected, but doesn't affect the faders of other selected tracks, whilst adjusting the fader of a selected track in an inactive group adjusts all selected faders.

In my opinion, this was bonkers before, and it's double-plus-bonkers now.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9643 [ardour] features minor have not tried 2024-02-23 06:45 2024-02-23 17:08
Reporter: Werner Back Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: More assignable options for remote in monitor section
Description: I would love to have more options to assign to buttons on my remote for the monitor section. At the moment I only have the options "Mute", "Dim", "Mono", which is a bit poor...why can't we have the buttons like "SIP", "PFL", "AFL" and so on? I use them a lot and having those on my remote would be very conveniant.
BTW, the already assigned options show up only for the function keys, the other assignments don't show after a fresh start (but keep being assigned).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0028544)
x42   
2024-02-23 17:08   
The short answer: those buttons are not automatable controls (like Mute, solo), which are evaluated in realtime context.
Controls are always bindable (MIDI learn) and remote controllable from any UI and any thread.

Solo options are not controls, but global session configuration. An entirely different mechanism is used for those.
Only the GUI can safely change those.

It would require a bit of work to make those safely accessible to control surfaces.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2741 [ardour] bugs block always 2009-06-20 14:38 2024-02-22 15:26
Reporter: nettings Platform: core2duo, openSUSE 11.1  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: 2.6.29.5-rt21  
Status: resolved Product Version: SVN/2.0-ongoing  
Product Build: r5218 Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: installation fails: update-mime-database does not work if directory does not exist
Description: prefix is /usr/local
when you run "sudo scons install", you get this error message:

scons: Building targets ...
update-mime-database /usr/local/share/mime
update-mime-database: I don't have write permission on /usr/local/share/mime.
Try rerunning me as root.

the actual reason is that /usr/local/share/mime does not exist. a workaround is to symlink it to /usr/share/mime, but ardour should detect this. plus an error here should not abort the actual installation of the ardour2 binary.

should be a blocker for 2.8.1 imho.
Tags:
Steps To Reproduce: sudo scons install
(where PREFIX=/usr/local and your distro does not have /usr/local/share/mime)
Additional Information:
Attached Files:
Notes
(0006141)
nettings   
2009-06-20 14:59   
should have noted that you need to enable FREEDESKTOP=1 to trigger this issue
(0010845)
paul   
2011-06-11 16:57   
i'm more likely to just disable the FREEDESKTOP option, to be honest. we handle this very differently in 3.0, and for 2.X, integration with the desktop is best left for distros.
(0028530)
lmat   
2024-02-20 19:35   
Are you able to reproduce this error still?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9599 [ardour] bugs major always 2024-01-11 02:25 2024-02-22 00:01
Reporter: Schmitty2005 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 9.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Regions Disappear from Editor List When Renamed.
Description: When the MIDI region is renamed by selecting the region in the Editor List, using a right-click , rename. The region disappears from the Editor List. If the region is then split, the names will reappear. When renaming the children of the split, they do not disappear and function as they should. This does not affect audio regions
 
Tags: Midi, region
Steps To Reproduce: 1. Create New project
2. Create new MIDI track, step edit to create new MIDI.
3. Select region from Editor List, right-click and rename.
4. Watch region disappear!

Optional Steps :
5. Split MIDI region
6. Watch MIDI region names appear.
Additional Information: Mixbus 9.2.current Win 10
Mixbus 9.2 Current Linux
Win 10 with Ardour 8.2 downloaded from Ardour.org
Ubuntu 22.04 LTS with Ardour downloaded from Ardour.org.
System Description
Attached Files:
Notes
(0028454)
Schmitty2005   
2024-01-11 02:30   
Affects Mixbus 32C 9.2.172 Linux / Windows
Ardour 8.2 Linux / Windows
(0028456)
Schmitty2005   
2024-01-13 16:00   
After region is renamed and disappeared, region can be grabbed and moved, thus making the name reappear in the Editor List box, but this is definitely not an ideal solution, just stating for debug purposes.
(0028459)
leatherswarm   
2024-01-17 01:54   
The name may be made to return in the Editor List box by grabbing and moving the region after it has been renamed and vanished. However, this is not the best way to do it and is just mentioned for debugging purposes.
(0028460)
Schmitty2005   
2024-01-17 02:32   
Audio regions are not affected by this bug.
(0028462)
Schmitty2005   
2024-01-17 03:36   
After Session is saved, closed, and reopened, the regions will appear in the editor list, and can be renamed. After adding additional MIDI tracks and renaming region on that new track, the region name disappears for that region on the new MIDI track.

This bug also affects copy and pasted regions. They will not show in editor list until project is closed and reopened.
(0028533)
Schmitty2005   
2024-02-22 00:01   
Still exists in Ardour 8.4 downloaded from here.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5437 [ardour] bugs block always 2013-04-06 23:18 2024-02-20 20:19
Reporter: nettings Platform: x86_64 (core i5)  
Assigned To: OS: openSUSE Tumbleweed  
Priority: normal OS Version: Linux 3.7.2  
Status: new Product Version:  
Product Build: 3.0-185-g096fe04 Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Copy operations of route processors (drag-and-drop and create from template) are not or incompletely implemented
Description: It seems there is a fundamental problem in A3 when new route processors are instantiated based on existing ones:

It is no longer possible to use templates containing Aux sends because of duplicate port IDs.

It is no longer possible to copy sends from one track to the next.

Plugins copied via drag and drop will end up with duplicate MIDI controllable IDs, breaking MIDI binding and leading to crashes down the road.

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028531)
lmat   
2024-02-20 20:19   
I believe this is fine on Ardour 8. Can you still reproduce?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3722 [ardour] bugs block always 2011-01-20 08:57 2024-02-20 16:22
Reporter: cassiel Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.8.11  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Freeze/block when exporting range markers to multiple audio files
Description: Cancel button doesn't respond, ie hitting cancel won't stop exporting range markers. The dialog window disappear, the export of all subsequent ranges continues but the first is interrupted.

Moreover, choosing a different location using the "browse" button, suddenly freezes ardour and ranges are not exported at all. The output of "ps -ax" shows ardour in a "Z" (defunct) state.
Tags:
Steps To Reproduce:
Additional Information: I can reproduce the same problem across projects on the same box. Did not try on another machine.
Attached Files:
Notes
(0028529)
lmat   
2024-02-20 16:22   
Here's what I did:

1. Created empty project in ardour
1. Created midi track with some notes in it
1. Added two ranges
1. Chose "Export to Audio File" (Alt+e)
1. In Time Span tab, selected the two ranges
1. In Time Span tab, I chose "RT" for the two ranges so it would take longer to export
1. Exported the audio
1. Quickly chose "Stop Export"

If I clicked fast enough, neither range was exported. If I waited a bit to click stop, only one range was exported.

Are you still able to reproduce?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9559 [ardour] bugs block always 2023-11-30 13:17 2024-02-20 15:21
Reporter: LucasGGamerM Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Pop at the start of exported file
Description: This happens when there is a midi synth that starts playing the same time as the the init tag, and the seek bar isn't on the init tag position.
Tags:
Steps To Reproduce: Create a track, add any synth (I used surgeXT for my track), place a midi region at the start of the session, place some notes there that start on the zeroth second, move seek bar to somewhere other than the zeroth second (a few seconds further than the zeroth second) , export the track, and there will be a pop noise at the start of the exported file.
Additional Information: This is the same pop noise when you start playing a track from the 10th second, and without pausing, clicks to move the seekbar to the start of the session.

I am using PipeWire on Pop!_OS, and starting the export when the seekbar is on the zeroth second of the song fixes the problem.
System Description
Attached Files: repro.mp3 (97,219 bytes) 2024-02-19 15:47
https://tracker.ardour.org/file_download.php?file_id=4784&type=bug
repro.ardour (29,618 bytes) 2024-02-19 15:47
https://tracker.ardour.org/file_download.php?file_id=4785&type=bug
image.png (88,229 bytes) 2024-02-19 15:47
https://tracker.ardour.org/file_download.php?file_id=4786&type=bug
png

image-2.png (3,506 bytes) 2024-02-19 22:16
https://tracker.ardour.org/file_download.php?file_id=4789&type=bug
png

repro-2.ardour (33,681 bytes) 2024-02-20 15:21
https://tracker.ardour.org/file_download.php?file_id=4790&type=bug
Take1_General MIDI Synth-2.mid (124 bytes) 2024-02-20 15:21
https://tracker.ardour.org/file_download.php?file_id=4791&type=bug
repro-2.mp3 (6,396 bytes) 2024-02-20 15:21
https://tracker.ardour.org/file_download.php?file_id=4792&type=bug
Selection_003.png (59,817 bytes) 2024-02-20 15:21
https://tracker.ardour.org/file_download.php?file_id=4793&type=bug
png
Notes
(0028523)
lmat   
2024-02-19 15:47   
I'm unable to reproduce. Here's what I did:

1. Open Ardour
1. Create new midi track (it gets the default General MIDI Synthesizer)
1. Use draw tool to draw a new empty region on the file (start tag gets lined up with the beginning of this region automatically)
1. Use draw tool to add some notes to the region
1. Export the audio

Attached is my export (converted to .mp3), a screen shot of my session, and my session's `.ardour` file.

I'm using the following versions:

* Arch Linux
* XFCE4
* ardour 8.1 (I tried on master (15eae21c37 right now) and was still unable to reproduce)

Let me know if I should be doing something differently.
(0028526)
LucasGGamerM   
2024-02-19 22:16   
So you missed an important aspect for this bug to occur. The first note *must* be on the precise start of the region.

I have sent an image for what I mean
(0028527)
lmat   
2024-02-20 15:19   
Thank you for the clarification. I lined up a midi region with the start tag, but I didn't put a note at the beginning. Changing that, I don't think I hear a click. I also tried adding four notes to the beginning of the region like your example shows.

If you're able to reproduce, a minimum example (.ardour file and .mid file? or just instructions) would be great.
(0028528)
lmat   
2024-02-20 15:21   
It looks like my attachments were lost. Attaching here.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6322 [ardour] bugs block always 2015-05-13 19:33 2024-02-19 17:53
Reporter: gremlink2 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 4.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI note at beginning of regions does not play
Description: MIDI notes do not play at beginning of regions if the playback head starts prior to region start. If the playback head starts at the point at which the region starts, MIDI plays normally.

This is an intolerable way to work. I am thinking of cancelling my subscription until it's fixed. I don't really feel like paying for a major feature that puts a huge dent in my workflow. I don't see how this should be a difficult fix.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: ardour-6322.mp4 (121,439 bytes) 2024-02-19 17:53
https://tracker.ardour.org/file_download.php?file_id=4788&type=bug
Notes
(0016685)
gremlink2   
2015-05-13 19:49   
Affects MIDI CC, too.
(0028525)
lmat   
2024-02-19 17:53   
I'm unable to reproduce. I created an ardour project with a midi track with a midi not at the beginning of the region and the playhead starting prior to region start. When playing, I head the first note. This is a very old bug report, so the likelihood that it is already fixed seems high to me. Let me know if I should be doing anything else to reproduce.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9497 [ardour] bugs block always 2023-10-21 10:39 2024-02-19 17:37
Reporter: benald Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: I can no longer open the plugin editor in my FX bus.
Description: I have a Cardinal FX plugin containing a Plateau module and midi sidechaining from another track. Since upgrading Ardour from 8.0.19(nightly) to 8.1 I found I could no longer open the plugin editor (I tried double clicking on the plugin in the mixer, being the only way I know of to do this). To test the reproducibility I added another FX bus and noticed that the plugins now have a beautifully usable CC automation interface - so, I have started using that. I may just use the CC interface instead of sidechaining for the foreseeable future but thought you might like to know in case there is some useful information here re sidechaining into a bus.
The new FX bus *does* allow me to edit the plugin.
The project is too large to upload in a zip file.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files: image.png (197,515 bytes) 2024-02-19 17:37
https://tracker.ardour.org/file_download.php?file_id=4787&type=bug
png
Notes
(0028524)
lmat   
2024-02-19 17:37   
I am not able to reproduce. I started cardinal, added a plateau module, sent output from a midi track to the cardinal plugin via sidechain. After that, I was able to open the cardinal FX GUI (see screen shot). Should I be doing something else to reproduce? I'm using the following versions:

* Arch Linux
* Cardinal 23.10
* Ardour 8.1

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9612 [ardour] bugs major random 2024-01-22 10:59 2024-02-19 16:06
Reporter: magnetophon Platform: linux  
Assigned To: OS: NixOS  
Priority: normal OS Version: 24.05pre  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour sometimes loses it's routing when using pipewire
Description: When I open a session while running pipewire, sometimes (part of) the routing is gone.
Either just the master and monitor routing or all the routing is gone.

On the Unfa Discord, there is another user with the exact same symptoms.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0028464)
x42   
2024-01-23 15:50   
Does this also happen when you use jackd instead of pipewire?
If not, it is a pipewire bug.
(0028465)
x42   
2024-01-23 15:56   
Next time this happen, please make a copy of the .ardour session file right after the session is loaded (before saving).

Then we can see if the problem is that connections are not properly saved, or if the issue is restoring them.
For the Route Monitor, there should be something like
<IO name="Monitor" id="11024" direction="Output" default-type="audio">
  <Port name="Monitor/audio_out 1" type="audio" direction="Output">
    <ExtConnection for="JACK"/>
    <ExtConnection for="JACK" other="system:playback_1"/>
  </Port>
  <Port name="Monitor/audio_out 2" type="audio" direction="Output">
    <ExtConnection for="JACK"/>
    <ExtConnection for="JACK" other="system:playback_2"/>
  </Port>
</IO>

(0028478)
magnetophon   
2024-01-27 08:40   
I'm not sure cause I hardly use jack anymore.
I'll do some more testing and report back in a while.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9556 [ardour] bugs major always 2023-11-28 20:19 2024-02-19 16:06
Reporter: martin.vlk Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Audio and MIDI connections sometimes not saved
Description: I am using Ardour 8.1 on Linux with Pipewire over the JACK backend.

It rather often happens to me that I save a project and then when I load it next, most or all of my audio and MIDI connections are gone and I have to reconnect everything.

It is not consistently forgetting all connections. Sometimes it would lose only some, and sometimes even none.

I tried using ALSA backend, but it seems to behave the same.
Is there some known issue around this, or can I do something to help debug this and find the problem?
Tags: saving
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028370)
x42   
2023-11-28 20:44   
External connections are saved per backend and device. So when switching JACK <-> ALSA each will have a different set of connections.
However connections being lost is not a known issue.

Are only external connections (to/from soundcard) affected, or also internal ones (Ardour Track -> Ardour Master)?

First step would be to establish, if the issue is **saving** the connections or **restoring** the connections.
In the .ardour session file there are there "Connection" and "ExtConnection" entries for each "IO/port"?

Can you perhaps upload a session file where connections are lost?
(0028371)
martin.vlk   
2023-11-28 20:57   
Both external and internal connections are affected.

https://drive.google.com/file/d/1VQ9AtXiDdx4fgP2xs4AisYuVE5oY11UI/view?usp=sharing
(0028372)
martin.vlk   
2023-11-28 20:58   
...the session file is 30MB, is this expected/normal?
(0028387)
martin.vlk   
2023-12-05 19:38   
I think I have spotted what the problem is!

When I make changes to midi or audio connections, these are not registered as a change (I don't get this little asterisk in the title bar) and so when I then hit Ctrl+S, nothing gets saved.
(0028388)
martin.vlk   
2023-12-05 19:49   
And it looks like even when I make some other change to the session, so that real saving gets triggered, even then some of my connections changes are not saved. But perhaps this at least provides some pointers to why this is happening?
(0028419)
martibs   
2023-12-13 22:12   
In my case, some MIDI and audio connections are sometimes (most of the time, but can not say for sure that it is all of the time) lost when a session is opened with the audio buffer size set to a different value from what it was when the session was saved.
(0028425)
martin.vlk   
2023-12-15 19:28   
I have tested @martibs's observation and I can confirm that my connections are saved just fine when I:
 1) don't change buffer size from within Ardour
 2) make sure I also make some "real" change in the session, apart from changing the connections
(0028506)
x42   
2024-02-18 16:43   
> these are not registered as a change (I don't get this little asterisk in the title bar) and so when I then hit Ctrl+S, nothing gets saved.

When using Ctrl+S (or Menu Session > Save), the session is always saved regardless of it being marked as modified.
The only difference is that when you close the session, there is no dialog asking you to save.

Anyway it is likely a pipewire issue, not informing ardour about port connection changes. There were various issues like this in the past with pipewire.
(0028516)
martin.vlk   
2024-02-18 21:43   
It happens with plain ALSA too, so I don't think it is caused by Pipewire.

M.
(0028518)
x42   
2024-02-18 22:54   
I use Ardour/ALSA daily and extensively during development and have not noticed this.
 Perhaps there is some additional factor that can explain this. I see "Master" is called "Rizeni" [sic] in your case. I wonder if translation and non ASCII chars in port-names can explain this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9638 [ardour] bugs crash always 2024-02-19 15:32 2024-02-19 15:32
Reporter: ax11 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Editor freezes after quickly pressing "next marker" on MIDI controller
Description: Whenever I get somewhat into flow with the editor and my Korg Nanocontrol2 and try jumping 3 matkers back or forward by hitting "nect" or "previous" marker on the controller the editor immediately freezes.
Tags: 8.2, MIDI control
Steps To Reproduce: Use a Nanokontrol2 (or any other controller with "next marker" and "previous marker" mappings) and try to jump a few markers. I'm getting am editor freeze every time I try.
Additional Information: Nanokontrol set to "CC" mode as required by the default mapping that comes with Ardour.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9633 [ardour] bugs block always 2024-02-08 13:53 2024-02-19 03:31
Reporter: DnBlck Platform: Arch  
Assigned To: paul OS: Garuda Linux  
Priority: high OS Version: 231029  
Status: feedback Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: First midi note does not recorded
Description: In all version of Ardour to this day I run in this error, when a midi track with instrument armed for record, and the count in turned on, the first midi note/notes played, but never recorded. If it not looped, and the playhead rolled a while, it records the notes without a problem. It only happens when i want to start recording at exact 00:00 after the count-in, or as soon as the recording started. This happens with all sound servers, distros and kernels with both my akai lpk25 and arturia minilab mkii.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028492)
x42   
2024-02-09 17:27   
Can you reproduce this without a sound-server, just direct Ardour/ALSA (and ALSA Sequencer as MIDI system)?
(0028493)
DnBlck   
2024-02-10 13:37   
Hey x42
Yes, with ALSA the problem is the same
(0028519)
paul   
2024-02-19 03:31   
commit 15eae21c3 contains a change that means we will record notes that were already "on" when capture started.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9636 [ardour] bugs minor always 2024-02-09 22:40 2024-02-18 22:01
Reporter: Bleuzen Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: First Stereo Plugin on Mono Flexible-I/O track affects right channel more than left channel
Description: Hi, if a Stereo plugin is on a Mono track in Flexible-I/O mode, it does do more to the right channel than the left channel and thus breaks the Stereo Balance.
For example if Ardours Stereo Compressor is put on a Mono track:
- Balance is fine if Compressor is set up to do nothing (Ratio: 1)
- If Compressor reduces the gain it affects both channels differently and after the plugin the left channel is loader than the right channel
This only happens for the first Stereo Plugin on a Mono track. Other Stereo plugins after that handle the balance fine. Also not all plugins are affected but most I tested so far.
The issue can be worked around if "Manual Config" is enabled in Pin Configuration of the first Stereo Plugin on the track.
Tags:
Steps To Reproduce: 1.) Create a Mono Audio Track in Flexible-I/O mode
2.) Record something on it for testing
3.) Add a Stereo Plugin to the track, for example "ACE Compressor (stereo)"
4.) Make sure the plugin is the first on the track
5.) Set up the compressor to compress the signal
6.) Look at the stereo balance of the output (should be centered - but it is not - left channel is now louder than right channel)
Additional Information: This issue likely appeared at some point within the last 13 months. I noticed in an older project of which I still have an export from January 2023. If I play back or export the same project again, without any changes, but with the latest Ardour version, the stereo balance of some sounds is noticeably different compared to the export from last year.
System Description
Attached Files:
Notes
(0028507)
x42   
2024-02-18 17:22   
Fixed in ACE comp 8.2-148-g9386847cc9
(0028511)
Bleuzen   
2024-02-18 17:57   
cool, however since you only mentioned ACE comp, does the fix also apply to other plugins?
because it also happens with x42 eq and comp and some reverb plugins for example
(0028512)
x42   
2024-02-18 18:10   
Those plugins do not correctly handle stereo in-place processing then and need fixing.
(0028513)
x42   
2024-02-18 18:15   
Ardour could be changed to provide two separate input buffers to work around issues in plugins. but in plugins are expected to handle this.

Here: left input buffer is identical to left output buffer.

So for the issue at hand, the plugin processes the left channel writes to the left output and thereby modifies the input.
When the right channel is processed. changes already applied to the left channel are used as input.
(0028514)
x42   
2024-02-18 18:25   
Thanks for the heads up, x42-eq v8.8-1 fixed. I'll investigate more plugins

But let's take a step back. What are you actually trying to accomplish here?
(0028515)
Bleuzen   
2024-02-18 21:38   
> What are you actually trying to accomplish here?

well I hope for this to 'just work':
If a track is planned to output Stereo, I tend to use Stereo plugins on it, even if the input is Mono - because mixing Stereo and Mono plugins on the same track can cause some pain when changing the plugins order later (like loosing pin connections or breaking the stereo balance due to switching between single/multi-instace mode...).

Also I would like my old sessions to sound the way they were intended without having to re-do the pin configuration on every affected track again.
Did Ardour have a workaround for this in the past? Because I do not hear this problem in my older exports.
(0028517)
x42   
2024-02-18 22:01   
A quick search shows that this optimization was added in 6.0, specifically git revision 00ecc545bc6

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9624 [ardour] bugs minor always 2024-01-27 20:04 2024-02-18 17:54
Reporter: MichaelSchramm Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Setting of 0db in the send is not possible
Description: I have the problem that I can’t set the send in the channel strips to 0db with the mouse. -0.08 dB is possible.

MacOS AND Linux
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028509)
x42   
2024-02-18 17:50   
You can either Shift + click on the small inline control to set it to 0dB.

..or hold down Ctrl while dragging for fine-grained. and Ctrl+Alt for extra fine-grained control while dragging or scroll-wheelin'

..or double-click the and then use the larger fader or numeric entry.
(0028510)
x42   
2024-02-18 17:54   
Note the pixel granularity of the small inline faders depend on screen scaling, mixer-strip width, font-size.

While it's inconvenient that is is to not necessarily possible to directly drag to the small inline-fader to 0dB, various other options exist to achieve that goal.

Any objections to mark this as "no change required".

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9634 [ardour] bugs minor always 2024-02-08 15:43 2024-02-18 17:44
Reporter: ddtex Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Automation - Channel Volume
Description: If you add the Channel Volume automation to a track, then remove it without changing it, it will set the Channel Volume to zero.
Tags:
Steps To Reproduce: 1. Right-click on a midi track track header, select Automation > Controllers > Channel Volume > Channel 1
2. This will place a Channel 1 Volume control to the left of the track
3. Do not change anything on the volume control
4. Click the X to close the Channel 1 Volume
5. Click Session > Save
6. Click Session > Recent & re-load the session you just saved.
7. Play the track again & it will be silent. The Channel 1 volume is now set to zero.
8. Open the Virtual Keyboard - it will be silent for Channel 1.
9. Change Virtual Keyboard to Channel 2 & will play fine.
10. Add the Channel 1 Volume Control back to the track & increase the volume, and Channel 1 will then play fine.
Additional Information:
System Description
Attached Files:
Notes
(0028508)
x42   
2024-02-18 17:44   
Fixed in 8.2-149-gd423810784

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9637 [ardour] bugs major always 2024-02-10 21:09 2024-02-13 19:19
Reporter: relascope Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI loop recording loses newly recorded notes
Description: Setting up e.g. Black Pearl MIDI Track to create the drums while looping.
Record the bass first, then the snare, then the next MIDI notes.

The record mode is sound on sound.

The new notes create the sound and the notes are displayed in the MIDI region, but the new run of the loop skips the new notes.
Tags: loop recording, Midi, MIDI region, Sound on Sound
Steps To Reproduce: Supposed workflow:

Setup:
- create a range of a few bars
- arm+record
- record mode: sound on sound
- loop range

Main Task:
- first loop record bass
- second loop record snare
...

Suggested:
1. notes sound
2. notes appear on the MIDI grid
3. notes are recorded, kept and played in the next iteration of the loop
Additional Information: Using "Play Range" while recording keeps the notes.

I somewhere read about a feature, where all layers are active (and therefore produce sound) but couldn't find it.

IMHO as a quick fix, the "Loop Range" could be implemented as an endless "Play Range".


Bug in [github tagged] Ardour 8.2 and the nightly of 2024/02/10
AVLinux, Debian 11
System Description
Attached Files:
Notes
(0028497)
paul   
2024-02-13 19:19   
At this time, Ardour does not provide the sort of MIDI looping I think you are looking for. Each loop while loop recording creates a new region, it does not add data to an existing region.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9630 [ardour] bugs crash always 2024-02-03 00:36 2024-02-09 14:28
Reporter: graylion Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when fast scroll in import file list
Description: I have more tracks in the import file list than the selection box can show. I am in the habit of scrolling to the other end by just giving the mouse wheel a push and letting inertia move me to the end or beginning. Thhis works fine in Windows. When I do that in Linux, Ardour crashes.
Tags:
Steps To Reproduce: as above
Additional Information:
System Description
Attached Files:
Notes
(0028491)
paul   
2024-02-09 14:28   
Please read https://ardour.org/debugging_ardour and try to get a complete backtrace for this crash.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9161 [ardour] bugs crash always 2022-12-12 16:09 2024-02-09 14:20
Reporter: DonJaime Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI patches before the start of a MIDI region are shown on the timeline until the zoom level is changed.
Description: Some MIDI tracks are shown with patches at the start that are not attached to a MIDI region. Clicking on one of these causes a crash.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: drag-patch-change.gif (575,113 bytes) 2023-06-16 16:01
https://tracker.ardour.org/file_download.php?file_id=4574&type=bug
Full session.png (162,157 bytes) 2023-06-17 13:28
https://tracker.ardour.org/file_download.php?file_id=4576&type=bug
png

If_2023-06-17_150955.ardour-session-archive (16,968 bytes) 2023-06-17 13:28
https://tracker.ardour.org/file_download.php?file_id=4577&type=bug
Archive.png (52,722 bytes) 2023-06-17 13:28
https://tracker.ardour.org/file_download.php?file_id=4578&type=bug
png

Backtrace (42,506 bytes) 2023-06-17 13:38
https://tracker.ardour.org/file_download.php?file_id=4579&type=bug
Notes
(0027057)
DonJaime   
2022-12-13 18:56   
Still there in 7.2
(0027638)
DonJaime   
2023-05-03 16:08   
This still occurs on newly-opened (old?) sessions in 7.4
(0027775)
x42   
2023-06-16 16:01   
Sadly I was not able to reproduce this, not in 7.2 nor 7.4 or current git.

Can you provide step-by-step instructions or a session that has this issue? or better yet, a backtrace of the crash (https://ardour.org/debugging_ardour)?
Thanks in advance.
(0027785)
DonJaime   
2023-06-17 13:28   
The patches are not attached to the midi regions (Full session.png). Here is an archive of a cut-down version that still shows the problem when I open it (Archive.png).
(0027786)
DonJaime   
2023-06-17 13:38   
(0027788)
x42   
2023-06-17 16:22   
Thanks for the session archive, that is helpful.
Your screenshot shows that the Patch-change apparently exists outside of a MIDI region.

Here, with a debug build, Ardour already crashes way earlier during session-load, when converting the tempo-map from Ardour v6. Which is likely the root-cause:

Thread 1 "ArdourGUI" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
0000001  0x00007ffff0f3d537 in __GI_abort () at abort.c:79
#2  0x00007ffff358b16d in Temporal::TempoMap::map_assert(bool, char const*, char const*, int)
    (expr=false, exprstr=0x7ffff34ef420 "qn >= _quarters", file=0x7ffff34eec80 "../libs/temporal/tempo.cc", line=511) at ../libs/temporal/tempo.cc:4573
#3  0x00007ffff3536d68 in Temporal::TempoPoint::superclock_at(Temporal::Beats const&) const (this=0x60e0001a7920, qn=...) at ../libs/temporal/tempo.cc:511
0000004  0x00007ffff359b274 in Temporal::TempoMetric::superclock_at(Temporal::Beats const&) const (this=0x7fffffff3fc0, qn=...) at ../libs/temporal/temporal/tempo.h:496
0000005  0x00007ffff3560677 in Temporal::TempoMap::set_meter(Temporal::Meter const&, Temporal::timepos_t const&) (this=0x617000171100, m=..., time=...) at ../libs/temporal/tempo.cc:1995
#6  0x00007ffff358ac5d in Temporal::TempoMap::set_state_3x(XMLNode const&) (this=0x617000171100, node=...) at ../libs/temporal/tempo.cc:4507
#7  0x00007ffff3578ff0 in Temporal::TempoMap::set_state(XMLNode const&, int) (this=0x617000171100, node=..., version=6000) at ../libs/temporal/tempo.cc:2978
0000008  0x00007ffff64d95fb in ARDOUR::Session::set_state(XMLNode const&, int) (this=0x6260000f6100, node=..., version=6000) at ../libs/ardour/session_state.cc:1749
0000009  0x00007ffff64be40f in ARDOUR::Session::post_engine_init() (this=0x6260000f6100) at ../libs/ardour/session_state.cc:286
0000010 0x00007ffff62cce7b in ARDOUR::Session::Session(ARDOUR::AudioEngine&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, ARDOUR::BusProfile const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool)
...
(0028337)
DonJaime   
2023-11-18 21:52   
I'm still getting detached patches in 8.1. They disappear when the zoom level is adjusted, and seem to be mainly harmless, as long as I don't click on them.
(0028483)
DonJaime   
2024-01-31 10:52   
In version 8.2 the ghost patches no longer cause crashes. It looks like they are in the MIDI file but before the start of the MIDI region. If I move the start of the region to include the patch I can delete it.
A shame I can't rename the bug to "MIDI patches before the start of a MIDI region are shown on the timeline until the zoom level is changed."

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9635 [ardour] bugs minor always 2024-02-09 00:37 2024-02-09 00:37
Reporter: wargreen Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Editor scroll up when ctl-drag the tempo ruler
Description: Hi,
When we ctrl-drag the tempo ruller for adgusting the tempo with an audio clip of reference, the editor scroll up, then we can't see anymore our track if it is not among the first.
Tags:
Steps To Reproduce: Create session with lot of tracks (more that the display can show)
Ctrl-drag the tempo ruler.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9266 [ardour] bugs minor always 2023-03-03 07:23 2024-02-07 15:09
Reporter: Greaseball Platform: PC  
Assigned To: paul OS: Linux Mint, Windows  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Automation lanes are not correctly moved along with audio after ( undone ) changes.
Description: Automation lanes are not correctly moved along with audio after ( undone ) changes.

The only solution I've found for this is a workaround.
But this is very inconvenient because it is very time consuming for large areas.
Tags: Ardour, audio, automation, Linux, pan, track, Windows
Steps To Reproduce: - Create Audio Track
- Import an audio file and place it on Audio Track.
- Activate some automation lanes ( f.e. PAN and FADER ).
- Draw some nodes on the automation lanes under the audio file.
- Now you can move the audio file without any problems to left and right. The nodes on the automation lanes follow correctly.
- Activate Range Mode, mark and delete a small part of the audio file. Undo the changes with CTRL+ Z
- Activate Drag Mode. If you now move the audio file left or right, the nodes on the automation lanes no longer follow correctly.
- The only workaround i have found to enable moving correctly again is the follow.

- Activate Range Mode and mark the entire area of the audio file.
- Right click on it and click "Consolidate" from context menu.
- Confirm by clicking on "Bounce".
- Only now is it again possible to correctly move the audio along with the nodes on the automation lanes.
Additional Information: This bug exists since Ardour 6.9 on Linux and Windows.
Attached Files:
Notes
(0027427)
paul   
2023-03-05 15:47   
6.9 and 7.x are very different code bases. Does this bug exist in 7.3 ?
(0027428)
Greaseball   
2023-03-05 15:57   
Yes. From 6.9 to 7.3.

Take a look if you want. I made a video of it.

https://www.dropbox.com/s/skgq7fqzuo096yb/Ursache_der_Zerst%C3%B6rten_AutomationLanes.mkv?dl=0
(0028487)
Greaseball   
2024-02-07 11:21   
Hello Paul.

Is there any news about this bug? Unfortunately, it exists still in version 8.2.0.
When can we expect a bug fix?

Thanks in advance

BR
(0028489)
paul   
2024-02-07 15:09   
I can't give any info on that, I am not working on bug fixes right now.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8589 [ardour] features minor have not tried 2021-02-26 10:45 2024-02-07 11:35
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow panning the timeline in X/Y using middle mouse button
Description: In many programs that feature any form of canvas, the middle mouse button can be held down on empty space to pan the canvas.

I think Ardour would also benefit from such a feature.

How would it work:

When the user hold down MMB while not hovering over any region, the horizontal mouse movement translates to panning the timeline horizontally.
The vertical movement has a dead zone and some increment before it shifts the view vertically, to avoid crazy track scrolling.

On conjunction with the mouse wheel zoom this would greatly improve user's options of quickly navigating the timeline.

Alternatively, a modifier key could be used to alter MMB's function to allow using pan even if the mouse is hovering over an object, as that'd be much less error-prone,
Though I'd personally use panning much more often, so it'd make more sense to me to have pan be default, and moving regions vertically require a modifier key (Shift for example).

What do you think?
Tags: ui, usability, UX
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025558)
x42   
2021-02-26 11:41   
tl;dr: Configure your OS or Hardware to do that.

Thinkpads do this unconditionally. Mac Systems likewise offer X/Y scrolling OOTB via magic-mouse or their touchpad.

This is not something application developers should do. Efficient use it depends on the mouse or interface you have.
Furthermore there are additional preferences (natural scrolling), or with some multi-button trackballs you may prefer buttons other than middle-click.
(0026332)
Thovthe   
2022-02-18 03:31   
I agree with the original poster.

Navigating the canvas with come combination of middle-mouse and a key (personally `ctrl+mmb`) becomes natural for anyone who uses 2D or 3D graphics/cad programs. It should be more than one to one mouse movement to canvas movement (1.5 or 3) particularly in the x direction, might make sense for y to be a lower amount though. I find myself trying desperately to drag around before I end up zooming in and out a bunch just to move over a bit.

On windows a different method of interaction that fulfills the same function would probably be covered by the standard middle-mouse-click action but on other platforms this would be a good feature.
(0026524)
acollsen   
2022-07-26 19:24   
I would love this feature. So far this is the hardest thing for me to get used to, to not have this feature.
(0026525)
unfa   
2022-07-26 22:18   
@x42 I don't know of applications that rely on special hardware or OS configurations to do this kind of scrolling.
The grand majority of creative software that has a 2D canvas of some kind I have used (both open-source and proprietary) has this basic feature of panning the canvas by dragging it with a mouse.
Some of the tools are: Inkscape, Blender, GIMP, Krita, Carla, Bespoke Synth, Natron, Godot, Adobe Substance Designer, Adobe Substance Painter, Corel Draw,

It seems strange to me to dismiss that need. Maybe in an alternate reality programs don't need to do that and OS can handle it, I have never witnessed that in action.
(0026526)
x42   
2022-07-26 22:48   
I'm not really opposed to adding this feature, but since there is a better solution, that should be preferred:

On GNU/Linux X11 provides this

xinput set-prop $deviceId "libinput Button Scrolling Button" 2 # Using middle button.
xinput set-prop $deviceId "libinput Natural Scrolling Enabled" 1 # for natural scrolling.

You can get the deviceID via `xinput list`

Chances are that your desktop's mouse configuration tool also allows to configure it. Search for "Auto Scroll".
This will then work consistently for all UI applications! e.g. Chromium/Chrome doesn't support this by default, and in Firefox it's an option.
(0026527)
paul   
2022-07-27 15:12   
@x42 not sure that's an equivalent "solution". I think what is being asked for here is not changing the default scroll button, but adding h-scroll behavior from a middle-button drag.
(0026528)
paul   
2022-07-27 15:13   
@acollsen, @unfa: do you not have scroll wheels with horizontal scroll behavior?
(0026530)
acollsen   
2022-07-28 07:49   
For example: If I click and hold the middle mouse button on the editor canvas I would love for the canvas to stick to the mouse pointer so i could drag the canvas around with the mouse without any delay or smooth scrolling. The Firefox auto-scroll is NOT what I mean.

Try opening Inkscape for example and middle click and drag on the canvas. Blender uses Shift+middle-click I think.

Thanks.
(0028486)
yeenking   
2024-02-07 10:51   
I would appreciate an option to drag the view by pressing the middles mouse buttons.
It would speed up the navigation through big project in my opinion. Because I'm used to it
In most software I'm using like blender3d, gimp, Krita.
(0028488)
yeenking   
2024-02-07 11:35   
For example:
Scrolling Moussewheel could be ZoomIn, ZoomOut
Pressing middle mouse buttons could be drag/pan view like in the most picture viewers.

For example
https://josm.openstreetmap.de/raw-attachment/wiki/Help/MapView/labels_hiding.gif

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9628 [ardour] bugs minor always 2024-01-28 20:37 2024-01-31 20:50
Reporter: enorrmann Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: strange note split behaviour
Description: when selecting a note for splitting in Edit mode, the first time works ok, but any attempt to split another note will result in the behaviour shown in the video
https://www.youtube.com/watch?v=ZDbbPeE5gwQ
attached is the test project
Tags: 8.2, Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files: test.zip (1,013,350 bytes) 2024-01-28 20:37
https://tracker.ardour.org/file_download.php?file_id=4777&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9516 [ardour] bugs crash always 2023-10-30 11:20 2024-01-31 11:33
Reporter: Salmana Steve Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Application closes when using Remove Time
Description: Trying to remove one bar at the start causes app to crash if option to move time signature and tempo changes is selected
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9163 [ardour] bugs major always 2022-12-13 19:50 2024-01-31 11:12
Reporter: DonJaime Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Converting session with tempo changes puts some MIDI regions in wrong position
Description: Opening some Ardour 6 sessions with variable tempo containing MIDI regions that do not start at the start of the session leads to the MIDI regions being misplaced on the timeline in Ardour 7.
Tags: meter
Steps To Reproduce: Open the attached session file in Ardour 7.2 (7.1 crashed). The piano, bass and drums regions are in the wrong place. Piano and bass should start in bar 6, drums in bar 13. In version 7 they start in bars 13 and 20, respectively. The short regions in the bass track in bars 11 14 and 31 end up in bars 18, 21 and 40.
Additional Information:
System Description
Attached Files: bug.zip (175,483 bytes) 2022-12-14 14:42
https://tracker.ardour.org/file_download.php?file_id=4326&type=bug
2023-01-16-6000.ardour (494,707 bytes) 2024-01-31 11:12
https://tracker.ardour.org/file_download.php?file_id=4778&type=bug
Notes
(0027084)
DonJaime   
2022-12-14 13:35   
not tempo change, meter changes
(0027086)
DonJaime   
2022-12-14 13:51   
Maybe uploading the file will work now...
(0027087)
DonJaime   
2022-12-14 13:53   
File upload failed again
(0027089)
DonJaime   
2022-12-14 14:42   
(0027408)
DonJaime   
2023-02-23 11:09   
Still there in 7.3
(0027639)
DonJaime   
2023-05-03 16:35   
Still there in 7.4, except even more things end up in the wrong place..
(0028328)
DonJaime   
2023-11-14 10:44   
Still there in 8.1-101-g5723c9bf9c.
(0028329)
DonJaime   
2023-11-14 10:59   
Workaround: if I unglue the affected regions from bars and beats in 6.9, they are in the right place in 8.1.
(0028484)
DonJaime   
2024-01-31 11:12   
Still there in 8.2.
Looks like the regions are ending up twice as far from the origin as they should. The attached file file shows that quite clearly: the regions in the "Metro gnome" track are/should be all jammed together with no gaps.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9627 [ardour] bugs major always 2024-01-28 18:23 2024-01-29 16:25
Reporter: pinecone460 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Learn in Cue Control applies to the clip to the right of the one selected
Description: There seems to be some sort of off-by-one error in Cue Control's MIDI Learn function. Any learning and un-learning that takes place applies to the clip directly to the right of the selected one (i.e same letter cue on the next track).
Tags: cue, Midi, MIDI learn
Steps To Reproduce: Create two adjacent tracks in cue control, and load clips into both of them in the same row. Right click the one on the left and click "MIDI Learn", play a note on a connected MIDI controller (I'm using jack-keyboard, connecting it to Ardour Cue Control in), and then play the note again to trigger the clip. Instead of the clip selected on the left for MIDI learn, the clip on the right will be triggered. MIDI un-learn seems to have the same behavior.
Additional Information: Ardour 8.2.0~ds
"Tracks and Traces"
(rev 8.2.0~ds-1)
Intel 64-bit

Debian Testing ("trixie")
System Description
Attached Files:
Notes
(0028482)
pinecone460   
2024-01-29 16:25   
I looked around a little more -- it seems there's a little more to this issue than is described above. While I was mainly experiencing this as an off-by-one error, that appears to be because of my setup of cue and non-cue tracks. While I don't fully understand the relation between where "Midi Learn" is called and what the learned call triggers, it seems to be offset by tracks not visible in the cue editor, and when tracks are moved around. It seems that the learned data may be stored with a track number that doesn't take either of these things into account.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9605 [ardour] bugs major always 2024-01-18 19:12 2024-01-29 08:52
Reporter: pablomme Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Importing Ardour 6.9 session with tempo/time-signature changes into Ardour 8.2 results in misplaced MIDI regions
Description: I am currently using Ardour 6.9 but would like to switch to 8.2 to finish a few sessions I am working on, particularly because I think I could make good use of the "mixer scenes" feature. However some of these sessions have tempo and time-signature changes and I run into issues when I try to import them in Ardour 8.2. (I had the same issue when I tried 7.0 a few months ago too.)

I have made a minimal session with just the relevant bit of MIDI to illustrate the bug. I've attached a tarball of the session directory after importing in version 8.2 (so there is a -6000 session file with the original Ardour 6.9 session); this can be loaded into either version of Ardour and "zoom to session" should show the right bit.

As shown in the attached screenshots, the original Ardour 6.9 session has a MIDI track formed of adjacent MIDI regions (from three different takes), but when imported into 8.2 there are gaps between the regions after the tempo + time-signature change, and some of the regions are rather out of tempo.

I suppose there must have been a rework of the way Ardour handles tempo and time signatures, but older sessions would ideally be loaded correctly. Alternatively, maybe there is an easy way of fixing the converted session file?
Tags: 6.9, 8.2, Midi, MIDI regions misplaced, tempo change, time signature change
Steps To Reproduce:
Additional Information:
System Description
Attached Files: midi-tempo-bug.tar.gz (142,657 bytes) 2024-01-18 19:12
https://tracker.ardour.org/file_download.php?file_id=4763&type=bug
ardour-midi-tempo-bug-orig.png (108,315 bytes) 2024-01-18 19:12
https://tracker.ardour.org/file_download.php?file_id=4764&type=bug
png

ardour-midi-tempo-bug-in-v8.png (100,345 bytes) 2024-01-18 19:12
https://tracker.ardour.org/file_download.php?file_id=4765&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9623 [ardour] other trivial always 2024-01-27 09:58 2024-01-27 09:58
Reporter: mikelupe Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Launchpad Mini MK3 clip launching mode ; truncated port names / pretty-name
Description: Launchpad Mini MK3 clip launching mode ; truncated port names / pretty-name

# aplaymidi -l
------------
 Port Client name Port name
 32:0 Launchpad Mini MK3 Launchpad Mini MK3 LPMiniMK3 DA
 32:1 Launchpad Mini MK3 Launchpad Mini MK3 LPMiniMK3 MI
------------

# cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version k6.7.2-1-liquorix-amd64

Port names are the same with stock Debian 12 kernel 6.x.

Quote IRC:
Jan 18 23:39:33 <las> MikeLupe_: yeah, that's going to fail. the port names are being truncated
Jan 18 23:40:30 <MikeLupe_> las, too long? Is this here a newer version of the LPM?
Jan 18 23:53:34 <las> MikeLupe_: no, your version of ALSA is truncating the port names
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: A8_LPM_MIDI-IOs.png (116,527 bytes) 2024-01-27 09:58
https://tracker.ardour.org/file_download.php?file_id=4775&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9622 [ardour] bugs minor always 2024-01-26 00:27 2024-01-26 00:42
Reporter: henningsprang Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Opening project fails after a previous segfault crash
Description: Background:

On my way to analyze a problem that I have with push2 control surface (https://discourse.ardour.org/t/push2-first-looking-good-than-failing/109808),
I just "saved as" a project from yesterday, ticking the box "i want it to be empty".

Then while trying to setup push, Ardour froze and then crashed with a segfault.

Because I thought the instability of push might come from the fact that I have also the ubuntu version of ardour installed, I removed that, then rebooted my machine.

But when trying to open the last project now that was open when ardour crashed, I get an error message:


Something went seriously wrong. Ardour cannot continue.
Here are a few hints at what might be wrong:
ERROR: Cannot get existing session information from /path/to/project.ardour


Tags:
Steps To Reproduce: I assume that reproducibility also needs the project file I have. I attach it below.

Also, I can only reproduce the behavior with this file - I did not try to reproduce crashes that result in such an unloadable session, but I am happy to do that on request if seen as necessary or helpful. As I experienced multiple crashes yesterday, too, I know that in most cases a crash just results in Ardour asking me to recover the last session.
But this doesn't happen with my session now.

Steps:

* start Ardour8 again after a crash, then see the session select dialog.

* chose the last session when ardour crashed

* see that it looks different then the others - it shows "??" in the sample rate column, and "--" in the file resolution column.

* select it and click open

* expect it to start the session

* instead get this message(project file path changed):

Something went seriously wrong. Ardour cannot continue.
Here are a few hints at what might be wrong:
ERROR: Cannot get existing session information from /path/to/project.ardour
Additional Information: I think it's important because even though this is an empty session that I did not record anything into yet, nor any configuration etc, It could have been that I just had setup many channels for routing midi/audio and had put significant work in, that shouldn't get lost.

Let me know if I can provide any further information.
System Description
Attached Files: jamuary_2024-01-25.tar.xz (15,548 bytes) 2024-01-26 00:27
https://tracker.ardour.org/file_download.php?file_id=4774&type=bug
Notes
(0028477)
henningsprang   
2024-01-26 00:42   
When trying to recover from this problem and continuing my work, I ran into the same problem, but with a newly "saved as" project.

What I did:

* deleted the unloadable session
* loaded the original project that had project data again
* chose "save as" and "new project should be empty"
* got an error about jack not being started, eve though qjackctl looked running fine
* pressed ctrl-s and stopped ardour
* restarted jack with qjackctl
* started ardour

again the new "saved as" session looked different than other sessions, as described above, and it couldn't be loaded.

Only in a third run the saved as project could be loaded as expected

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9619 [ardour] bugs tweak always 2024-01-25 04:21 2024-01-25 17:37
Reporter: bonsembiante Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST3 non-optimal calls to plugin methods worsen DSP performance
Description: Testing different setups to achieve low latency audio processing on Linux with Windows VST plugins (using yabridge), I discovered a significant difference between Reaper and Ardour performance when changing VST3 parameters. Both programs works well when I don't change any plugin parameter, but in Ardour when I make continuous and sudden changes of a parameter, lets say Master Volume knob in the plugin GUI, audio starts to sounds full of missing samples (a lot of jitter, multiples xruns). Also DSP load meter goes through 100%. When I stop moving the parameter, everything goes stable again. It is important to say that this problem is audible when I use a very low buffer size (32 samples for buffer and 44.1 kHz of sampling freq.). I did the tests with same OS.

Intrigued with that performance difference between Reaper and Ardour, I did some debug with Yabridge option to log method calls. I found that Ardour make many calls (between 7 or 8) to some methods for each plugin "performEdit" call to host, as opposed to Reaper that only makes 1 call after each "performEdit". I cloned Ardour repo, and commented two lines on libs/ardour/vst3_plugin.cc -> VST3PI::performEdit method: the call to normalizedParamToPlain and to OnParameterChange. This, of course, left me with no parameter synchronization inside Ardour state but also with no method calls after each "performEdit" call from plugin and also removed the jitter problem (and DSP load stop to increase on each parameter continuous and sudden change).

I have been a software developer for several years and I'm really available to make the necessary changes in Ardour code to fix this issue, but as it is my first time getting into Ardour code I thought that It would be important to share my analysis here so we can get the best approach for it.
Tags: latency, performance, VST3
Steps To Reproduce:
Additional Information: In order to evidence the issue, I did a bunch of tests using:

Ardour version: 8.2.85 (dbg) master version (latest commit cefab85dabcbee7ede26808a880b0265e5817472)
OS: Ubuntu 22.04
Audio device: Onboard, 2 periods, 1024 samples @ 48kHz [image attached: audio_device_config.png]
Yabridge version: 5.1.0
Wine version: 9.0 (Staging)
VST3 Plugin: Warmy EP1A v2 (Windows binary) [image attached: warmy_screenshot.png]

I ran ardev with environment variable YABRIDGE_DEBUG_LEVEL=1,+editor so a got yabridge debug info in stderr with plugin <-> host method calls.
I created only one Audio track and attached a instance of the VST plugin. Later, I prepared the stderr and then clicked in reset button of DSP meter. Almost inmediatly after that I moved the "Boost knob" of the plugin GUI from 0 to 10 and again to 0, moderately fast and in a continuous way. Then I took a screenshot of DPS meter and copied the Yabridge logs where "performEdit" and other method calls were displayed in that window of time when I make the knob movement. The results are the following.

No modified version of Ardour:
Minimum: 0.39 [ms]
Maximum: 5.2 [ms]
Average: 1.362 [ms]
Std.Dev: 0.392 [ms]
[image attached: 20240124_22-21_ardour-dbg-8.2.85_master_warmy_dsp-load.png]
Methods calls: https://pastebin.com/kr7prmwH

Modified version of Ardour (with that two lines commented):
Minimum: 0.49 [ms]
Maximum: 2.12 [ms]
Average: 1.261 [ms]
Std.Dev: 0.2 [ms]
[image attached: 20240124_22-35_ardour-dbg-8.2.85_modded_warmy_dsp-load.png]
Methods calls: https://pastebin.com/6GKdDC5D
System Description
Attached Files: 20240124_22-21_ardour-dbg-8.2.85_master_warmy_dsp-load.png (19,357 bytes) 2024-01-25 04:21
https://tracker.ardour.org/file_download.php?file_id=4770&type=bug
png

20240124_22-35_ardour-dbg-8.2.85_modded_warmy_dsp-load.png (19,072 bytes) 2024-01-25 04:21
https://tracker.ardour.org/file_download.php?file_id=4771&type=bug
png

audio_device_config.png (32,905 bytes) 2024-01-25 04:21
https://tracker.ardour.org/file_download.php?file_id=4772&type=bug
png

warmy_screenshot.png (300,045 bytes) 2024-01-25 04:21
https://tracker.ardour.org/file_download.php?file_id=4773&type=bug
Notes
(0028472)
bonsembiante   
2024-01-25 04:25   
I will try to make a PR in Github with some code changes for a possible solution but any comments or guidelines that might be helpful for that are welcome.
(0028473)
x42   
2024-01-25 04:33   
Can you check that when you use automation, rather than manual changes, this is not an issue?
(0028474)
x42   
2024-01-25 04:44   
That is an interesting find. It'd be great to track down where those duplicate calls originate from.
(0028475)
bonsembiante   
2024-01-25 05:22   
Hi x42, thanks for replying.
I just did the test with the automation thing and yes, is an issue, it has the same behavior.
Also, I forgot to mention that the issue is not present only when using plugin internal GUI but also when using Ardour inline controls for a plugin parameter, but in this case the methods called between host and plugin have not the exact same sequence.

I did a dirty stack trace analysis for each plugin method call from ardour when a parameter is changed, maybe I could do it better so we can understand which core method or something like that is responsible of each plugin method call.

First of all, there are plenty calls to "normalizedParamToPlain" for the same value, so maybe a possible solution could be a kind of mapping where to store the plain value if we already have it. If not, we do the call, but only one time.
(0028476)
x42   
2024-01-25 17:37   
So the issue here is that various UI elements in Ardour request parameter conversion (interface_to_internal, internal_to_interface) ?

normalizedParamToPlain is usually cheap, some basic math, at most a few CPU instructions.
Except with yabridge, there is a context switch, which can introduce significant overheard.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9621 [ardour] translation feature always 2024-01-25 17:06 2024-01-25 17:13
Reporter: 9427421240 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Note-name-translations should be changeable separately from the UI-language
Description: Different languages can have different names for the same notes.

There are various situations in which changing note-names separately from the UI-language is useful, such as:
- While someone has a preference for note-names in a specific language.
- While someone is learning from tutorials about composing music, while the tutorials are in another language with different note-names.
- While collaborating (internationally) with people who use different note-names.

There should be a separate language-setting that only changes the note-names.
It should default to the language of the UI.
Tags: Midi, notes, settings, translations
Steps To Reproduce: Set Ardour up to use a translation with translated note-names, such as the german translation.
Create a MIDI-track, add a MIDI-region to it, make the MIDI-track large enough, and then check the note-names shown in the info that appears near the pointer while it is pointing at various note-rows in the MIDI-region while draw-mode is active.
Additional Information: I use Ardour with the german translation, but prefer the english note-names over the german note-names.

English note-names:
A, A#, B, C, C#, D, D#, E, F, F#, G, G#

German note-names:
A, Ais, H, C, Cis, D, Dis, E, F, Fis, G, Gis
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9618 [ardour] bugs crash sometimes 2024-01-24 14:21 2024-01-24 14:21
Reporter: colinf Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: TEMPO MAP LOGIC FAILURE: [qn >= _quarters] at ../libs/temporal/tempo.cc:507
Description: Dragging bar lines to match tempo map to a live performance provokes "TEMPO MAP LOGIC FAILURE: [qn >= _quarters] at ../libs/temporal/tempo.cc:507", followed by a dump of the tempo map, before Ardour aborts.
Tags:
Steps To Reproduce: Happens pretty regularly (though not every time) when I drag bar lines in the attached session.
Additional Information: Tempo map dump & backtrace also attached.
System Description
Attached Files: IdburyHill.ardour (444,746 bytes) 2024-01-24 14:21
https://tracker.ardour.org/file_download.php?file_id=4767&type=bug
tempo-map-failure.txt (8,779 bytes) 2024-01-24 14:21
https://tracker.ardour.org/file_download.php?file_id=4768&type=bug
tempo-map-bt.txt (78,604 bytes) 2024-01-24 14:21
https://tracker.ardour.org/file_download.php?file_id=4769&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9601 [ardour] bugs crash always 2024-01-14 13:23 2024-01-24 07:39
Reporter: GtheGreat Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: urgent OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Renaming channel strip in Mixer View exits Ardour 8.2
Description: As title says, renaming channel strip in Editor works fine, renaming audio, midi, bus channel strip in Mixer view exits the program without warning
Tags: renaming; mixer ; strip
Steps To Reproduce: Open (existing) project,
-Make channel strip(s) if new;
-rename strip in Editor. Fine!
-rename strip in Mixer;
Ardour exits itself without warning..
Additional Information:
System Description
Attached Files: image.png (4,959 bytes) 2024-01-17 02:41
https://tracker.ardour.org/file_download.php?file_id=4759&type=bug
png
Notes
(0028457)
GtheGreat   
2024-01-15 16:15   
Vanilla Debian 12 Bookworm, Gnome 43.9 on Wayland, AMD 6 core with AMD RX 470, standard kernel, jackserver realtime with sufficient buffer
(0028458)
axra   
2024-01-16 06:35   
I cannot confirm. Working here. Ardour 8.2, Manjaro Linux, Kernel 6.7, AMD APU, Cinnamon Desktop, Alsa Backend.
(0028461)
Schmitty2005   
2024-01-17 02:41   
It works fine with Ardour 8.2 downloaded from here, but I get this error in log with home build Ardour 8.2.53 and no fatal crashes:

g_log:gtk_box_pack:assertion 'child->parent == NULL' failed
(0028469)
GtheGreat   
2024-01-24 07:39   
Tested again. Does crash with Wayland , does not crash with Xorg. Tested on a intel with intel graphics: no crash. Maybe combination RX GPU / Vulkan with Wayland?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9609 [ardour] bugs minor always 2024-01-21 20:24 2024-01-21 20:24
Reporter: audiodef Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mulit-duplicating a MIDI region groups duplicated regions.
Description: Upgraded from 7 to 8.2. Did not import any old settings. Basically a fresh install. Multi-duplicating a MIDI region results in the duplicate regions being grouped. They can be un-grouped. "MIDI region copies are independent" is already set. Re-setting it doesn't fix it.
Tags:
Steps To Reproduce:
Additional Information: Let me know if I can provide additional info, logs, etc.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9608 [ardour] bugs crash always 2024-01-21 19:02 2024-01-21 19:02
Reporter: sniew Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 8.2 on MAC crashes directly on start
Description: Whin starting Ardour 8.2 it's crashes directly. Tried in safe mode with same result. Ardour 7.5.0 works fine (luckily).

Note: it also crashes when there is no hardware connected.

Tags:
Steps To Reproduce: Start Ardour
Additional Information: -------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process: Ardour8 [873]
Path: /Applications/Ardour8.app/Contents/MacOS/Ardour8
Identifier: org.ardour.Ardour8
Version: 8.2.0 (8.2.0)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 501

Date/Time: 2024-01-21 19:59:52.7391 +0100
OS Version: macOS 12.7.2 (21G1974)
Report Version: 12
Bridge OS Version: 3.0 (14Y910)
Anonymous UUID: D454E33E-A468-8A99-8192-337C2760CCCD


Time Awake Since Boot: 450 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x7ff804193ffe __pthread_kill + 10
1 libsystem_pthread.dylib 0x7ff8041ca1ff pthread_kill + 263
2 libsystem_c.dylib 0x7ff804115d14 abort + 123
3 libc++abi.dylib 0x7ff804186082 abort_message + 241
4 libc++abi.dylib 0x7ff80417725d demangling_terminate_handler() + 266
5 libobjc.A.dylib 0x7ff804073e41 _objc_terminate() + 104
6 libc++abi.dylib 0x7ff8041854a7 std::__terminate(void (*)()) + 8
7 libc++abi.dylib 0x7ff804187d05 __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 27
8 libc++abi.dylib 0x7ff804187ccc __cxa_throw + 116
9 libglibmm-2.4.1.dylib 0x109e1ff28 0x109e19000 + 28456
10 libglibmm-2.4.1.dylib 0x109e37504 0x109e19000 + 124164
11 libglibmm-2.4.1.dylib 0x109e47243 0x109e19000 + 188995
12 libpbd.dylib 0x109c32769 StringPrivate::Composition& StringPrivate::Composition::arg<Glib::ustring>(Glib::ustring const&) + 25
13 libpbd.dylib 0x109c32611 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > string_compose<Glib::ustring>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, Glib::ustring const&) + 81
14 libpbd.dylib 0x109c2f881 PBD::run_functor_for_paths(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&, PBD::Searchpath const&, bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, void*), void*, bool, bool, bool, bool) + 1313
15 libpbd.dylib 0x109c2feec PBD::find_files_matching_filter(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&, PBD::Searchpath const&, bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, void*), void*, bool, bool, bool) + 28
16 libardour.dylib 0x10ab24fe4 ARDOUR::Session::possible_states(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 84
17 Ardour8 0x1089e9591 0x108182000 + 8811921
18 Ardour8 0x1089ebb93 0x108182000 + 8821651
19 Ardour8 0x108a75de2 0x108182000 + 9387490
20 Ardour8 0x10823a13b 0x108182000 + 753979
21 libgtkmm2ext.dylib 0x109b91ddd Gtkmm2ext::UI::run(Receiver&) + 301
22 Ardour8 0x10862e5dc 0x108182000 + 4900316
23 dyld 0x11139452e start + 462

Thread 1:
0 libsystem_pthread.dylib 0x7ff8041c5f48 start_wqthread + 0

Thread 2:
0 libsystem_pthread.dylib 0x7ff8041c5f48 start_wqthread + 0

Thread 3:
0 libsystem_kernel.dylib 0x7ff80419409a poll + 10
1 libpbd.dylib 0x109c20acc CrossThreadChannel::receive(char&, bool) + 76
2 libardour.dylib 0x10abb83f2 ARDOUR::TriggerBoxThread::thread_work() + 66
3 libardour.dylib 0x10abb82c1 ARDOUR::TriggerBoxThread::_thread_work(void*) + 97
4 libpbd.dylib 0x109c3b346 fake_thread_start(void*) + 86
5 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
6 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 4:
0 libsystem_kernel.dylib 0x7ff8041903da __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x7ff8041caa6f _pthread_cond_wait + 1249
2 libglib-2.0.0.dylib 0x10a064f4c g_cond_wait + 44
3 libardour.dylib 0x10ab74a0c peak_thread_work() + 156
4 libpbd.dylib 0x109c3bde5 PBD::Thread::_run(void*) + 69
5 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
6 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 5:
0 libsystem_kernel.dylib 0x7ff8041903da __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x7ff8041caa6f _pthread_cond_wait + 1249
2 libglib-2.0.0.dylib 0x10a064f4c g_cond_wait + 44
3 libardour.dylib 0x10ab74a0c peak_thread_work() + 156
4 libpbd.dylib 0x109c3bde5 PBD::Thread::_run(void*) + 69
5 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
6 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 6:
0 libsystem_kernel.dylib 0x7ff8041903da __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x7ff8041caa6f _pthread_cond_wait + 1249
2 libglib-2.0.0.dylib 0x10a064f4c g_cond_wait + 44
3 libardour.dylib 0x10a6ead44 ARDOUR::Analyser::work() + 132
4 libpbd.dylib 0x109c3bde5 PBD::Thread::_run(void*) + 69
5 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
6 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 7:
0 libsystem_kernel.dylib 0x7ff8041903da __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x7ff8041caa6f _pthread_cond_wait + 1249
2 libglib-2.0.0.dylib 0x10a064f4c g_cond_wait + 44
3 libardour.dylib 0x10a7214cc ARDOUR::AudioEngine::do_reset_backend() + 252
4 libpbd.dylib 0x109c3bde5 PBD::Thread::_run(void*) + 69
5 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
6 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 8:
0 libsystem_kernel.dylib 0x7ff8041903da __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x7ff8041caa6f _pthread_cond_wait + 1249
2 libglib-2.0.0.dylib 0x10a064f4c g_cond_wait + 44
3 libardour.dylib 0x10a721cdb ARDOUR::AudioEngine::do_devicelist_update() + 203
4 libpbd.dylib 0x109c3bde5 PBD::Thread::_run(void*) + 69
5 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
6 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 9:
0 libsystem_malloc.dylib 0x7ff803fe5503 nanov2_free_definite_size + 62
1 libpbd.dylib 0x109c50338 XMLNode::clear_lists() + 120
2 libpbd.dylib 0x109c5025e XMLNode::~XMLNode() + 14
3 libpbd.dylib 0x109c50309 XMLNode::clear_lists() + 73
4 libpbd.dylib 0x109c5025e XMLNode::~XMLNode() + 14
5 libpbd.dylib 0x109c50309 XMLNode::clear_lists() + 73
6 libpbd.dylib 0x109c5025e XMLNode::~XMLNode() + 14
7 libpbd.dylib 0x109c50309 XMLNode::clear_lists() + 73
8 libpbd.dylib 0x109c5025e XMLNode::~XMLNode() + 14
9 libpbd.dylib 0x109c50309 XMLNode::clear_lists() + 73
10 libpbd.dylib 0x109c5025e XMLNode::~XMLNode() + 14
11 libpbd.dylib 0x109c50309 XMLNode::clear_lists() + 73
12 libpbd.dylib 0x109c5025e XMLNode::~XMLNode() + 14
13 libpbd.dylib 0x109c4f6cb XMLTree::~XMLTree() + 27
14 libmidipp.dylib 0x109720a2d MIDI::Name::MIDINameDocument::MIDINameDocument(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 157
15 libardour.dylib 0x10a8fcd0f MIDI::Name::MidiPatchManager::load_midi_name_document(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 47
16 libardour.dylib 0x10a8fca18 MIDI::Name::MidiPatchManager::add_midnam_files_from_directory(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 616
17 libardour.dylib 0x10a8fd433 MIDI::Name::MidiPatchManager::load_midnams() + 147
18 libpbd.dylib 0x109c3bde5 PBD::Thread::_run(void*) + 69
19 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
20 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 10:
0 libsystem_pthread.dylib 0x7ff8041c5f48 start_wqthread + 0

Thread 11:
0 libsystem_kernel.dylib 0x7ff804195d4a __select + 10
1 libcurl.4.dylib 0x10a348112 Curl_poll + 786
2 libcurl.4.dylib 0x10a342446 Curl_multi_wait + 1270
3 libcurl.4.dylib 0x10a33beab curl_easy_perform + 299
4 Ardour8 0x1081bb35c 0x108182000 + 234332
5 Ardour8 0x10878481c 0x108182000 + 6301724
6 libpbd.dylib 0x109c3b346 fake_thread_start(void*) + 86
7 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
8 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 12:
0 libsystem_pthread.dylib 0x7ff8041c5f48 start_wqthread + 0

Thread 13:: AMCP Logging Spool
0 libsystem_kernel.dylib 0x7ff80418d9a6 semaphore_wait_trap + 10
1 caulk 0x7ff80ccce2e6 caulk::mach::semaphore::wait_or_error() + 16
2 caulk 0x7ff80ccb6148 caulk::concurrent::details::worker_thread::run() + 36
3 caulk 0x7ff80ccb5e0c void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 41
4 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
5 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 14:
0 libsystem_pthread.dylib 0x7ff8041c5f48 start_wqthread + 0

Thread 15:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0x7ff80418d96a mach_msg_trap + 10
1 libsystem_kernel.dylib 0x7ff80418dcd8 mach_msg + 56
2 CoreFoundation 0x7ff80429129d __CFRunLoopServiceMachPort + 319
3 CoreFoundation 0x7ff80428f928 __CFRunLoopRun + 1276
4 CoreFoundation 0x7ff80428ed6c CFRunLoopRunSpecific + 562
5 AppKit 0x7ff806e3b98e _NSEventThread + 132
6 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
7 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 16:
0 libsystem_kernel.dylib 0x7ff80419233e kevent + 10
1 libgio-2.0.0.dylib 0x10a5b17d8 _kqueue_thread_func + 168
2 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
3 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 17:: gmain
0 libsystem_kernel.dylib 0x7ff804195d4a __select + 10
1 libglib-2.0.0.dylib 0x10a0250ea g_poll + 554
2 libglib-2.0.0.dylib 0x10a014931 g_main_context_iterate + 433
3 libglib-2.0.0.dylib 0x10a016788 glib_worker_main + 120
4 libglib-2.0.0.dylib 0x10a0402fa g_thread_proxy + 90
5 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
6 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 18:: pool
0 libsystem_kernel.dylib 0x7ff8041903da __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x7ff8041caaa4 _pthread_cond_wait + 1302
2 libglib-2.0.0.dylib 0x10a065151 g_cond_wait_until + 129
3 libglib-2.0.0.dylib 0x109fe153e g_async_queue_pop_intern_unlocked + 142
4 libglib-2.0.0.dylib 0x10a0412ba g_thread_pool_thread_proxy + 122
5 libglib-2.0.0.dylib 0x10a0402fa g_thread_proxy + 90
6 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
7 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 19:: pool
0 libsystem_kernel.dylib 0x7ff8041903da __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x7ff8041caaa4 _pthread_cond_wait + 1302
2 libglib-2.0.0.dylib 0x10a065151 g_cond_wait_until + 129
3 libglib-2.0.0.dylib 0x109fe153e g_async_queue_pop_intern_unlocked + 142
4 libglib-2.0.0.dylib 0x10a0412ba g_thread_pool_thread_proxy + 122
5 libglib-2.0.0.dylib 0x10a0402fa g_thread_proxy + 90
6 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
7 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15

Thread 20:: pool
0 libsystem_kernel.dylib 0x7ff8041903da __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x7ff8041caaa4 _pthread_cond_wait + 1302
2 libglib-2.0.0.dylib 0x10a065151 g_cond_wait_until + 129
3 libglib-2.0.0.dylib 0x109fe153e g_async_queue_pop_intern_unlocked + 142
4 libglib-2.0.0.dylib 0x10a0412ba g_thread_pool_thread_proxy + 122
5 libglib-2.0.0.dylib 0x10a0402fa g_thread_proxy + 90
6 libsystem_pthread.dylib 0x7ff8041ca4e1 _pthread_start + 125
7 libsystem_pthread.dylib 0x7ff8041c5f6b thread_start + 15


Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000 rbx: 0x000000011140f600 rcx: 0x00007ff7b7d7c858 rdx: 0x0000000000000000
  rdi: 0x0000000000000103 rsi: 0x0000000000000006 rbp: 0x00007ff7b7d7c880 rsp: 0x00007ff7b7d7c858
   r8: 0x00007ff7b7d7c720 r9: 0x00007ff804188f9b r10: 0x0000000000000000 r11: 0x0000000000000246
  r12: 0x0000000000000103 r13: 0x0000003000000008 r14: 0x0000000000000006 r15: 0x0000000000000016
  rip: 0x00007ff804193ffe rfl: 0x0000000000000246 cr2: 0x0000000000000000
  
Logical CPU: 0
Error Code: 0x02000148
Trap Number: 133


Binary Images:
    0x7ff80418c000 - 0x7ff8041c3fff libsystem_kernel.dylib (*) <c37bfe8a-c5ae-3fe0-b722-33483d9017b9> /usr/lib/system/libsystem_kernel.dylib
    0x7ff8041c4000 - 0x7ff8041cffff libsystem_pthread.dylib (*) <e097f78f-fcfb-30f3-9164-dbc9709ba134> /usr/lib/system/libsystem_pthread.dylib
    0x7ff804094000 - 0x7ff80411cfff libsystem_c.dylib (*) <4ecd1661-9d96-3669-bb31-4c6d5c685d4c> /usr/lib/system/libsystem_c.dylib
    0x7ff804176000 - 0x7ff80418bfff libc++abi.dylib (*) <69ac868b-1157-364a-984a-5ef26973f661> /usr/lib/libc++abi.dylib
    0x7ff804056000 - 0x7ff804090fff libobjc.A.dylib (*) <b36a2b52-68a9-3e44-b927-71c24be1272f> /usr/lib/libobjc.A.dylib
       0x109e19000 - 0x109e54fff libglibmm-2.4.1.dylib (*) <5214af7f-c807-35b2-954d-efdaf776fc31> /Applications/Ardour8.app/Contents/lib/libglibmm-2.4.1.dylib
       0x109c0f000 - 0x109c5efff libpbd.dylib (*) <bbf6cf6d-3f57-38a9-9868-046b336b697f> /Applications/Ardour8.app/Contents/lib/libpbd.dylib
       0x10a6d3000 - 0x10b01afff libardour.dylib (*) <23de9229-8279-344e-a301-368537c1390e> /Applications/Ardour8.app/Contents/lib/libardour.dylib
       0x108182000 - 0x108db5fff org.ardour.Ardour8 (8.2.0) <2afd3324-ca6e-32b1-adee-e6c0ee288e0d> /Applications/Ardour8.app/Contents/MacOS/Ardour8
       0x109b67000 - 0x109bb2fff libgtkmm2ext.dylib (*) <c1349234-cd8b-3fc7-8f8c-295e24a48b1b> /Applications/Ardour8.app/Contents/lib/libgtkmm2ext.dylib
       0x11138f000 - 0x1113fafff dyld (*) <499010ac-3054-326e-a050-fefffb5ce89a> /usr/lib/dyld
       0x109fd9000 - 0x10a0f8fff libglib-2.0.0.dylib (*) <7e7ad53a-0fad-3980-a1ff-ed0c51250738> /Applications/Ardour8.app/Contents/lib/libglib-2.0.0.dylib
    0x7ff803fe3000 - 0x7ff80400efff libsystem_malloc.dylib (*) <2ea05464-fac2-32fe-8e03-94252869554d> /usr/lib/system/libsystem_malloc.dylib
       0x1096fa000 - 0x109735fff libmidipp.dylib (*) <208601c5-31ee-3eaa-92b9-3ac15eb9caf9> /Applications/Ardour8.app/Contents/lib/libmidipp.dylib
       0x10a316000 - 0x10a381fff libcurl.4.dylib (*) <dff44b67-a7d1-3cd1-aa04-e5286c4c6653> /Applications/Ardour8.app/Contents/lib/libcurl.4.dylib
    0x7ff80ccb4000 - 0x7ff80ccd5fff com.apple.audio.caulk (1.0) <f04b5c91-d0ec-33c6-8a81-b80a3ebf827f> /System/Library/PrivateFrameworks/caulk.framework/Versions/A/caulk
    0x7ff804211000 - 0x7ff804713fff com.apple.CoreFoundation (6.9) <fb79a14a-fda9-3a3b-bc97-6eb525b794a6> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7ff806c8f000 - 0x7ff807b1efff com.apple.AppKit (6.9) <322c1378-24a3-3361-97a1-8a487166d15b> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
       0x10a4c5000 - 0x10a5f0fff libgio-2.0.0.dylib (*) <03a98384-cfc9-3c2e-aabe-1d29add9387f> /Applications/Ardour8.app/Contents/lib/libgio-2.0.0.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=985.0M resident=0K(0%) swapped_out_or_unallocated=985.0M(100%)
Writable regions: Total=626.6M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=626.6M(100%)

                                VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Accelerate framework 256K 2
Activity Tracing 256K 1
CG backing stores 1920K 4
ColorSync 212K 24
CoreAnimation 2176K 1
CoreGraphics 12K 2
Foundation 16K 1
Kernel Alloc Once 8K 1
MALLOC 343.9M 50
MALLOC guard page 32K 8
MALLOC_LARGE (reserved) 2508K 3 reserved VM address space (unallocated)
MALLOC_NANO (reserved) 256.0M 1 reserved VM address space (unallocated)
STACK GUARD 56.1M 21
Stack 18.2M 21
VM_ALLOCATE 68K 15
__CTF 756 1
__DATA 24.8M 435
__DATA_CONST 14.3M 194
__DATA_DIRTY 638K 110
__FONT_DATA 4K 1
__LINKEDIT 672.5M 114
__OBJC_RO 82.9M 1
__OBJC_RW 3200K 2
__TEXT 312.5M 446
__UNICODE 592K 1
dyld private memory 2048K 3
mapped file 81.5M 20
shared memory 772K 17
=========== ======= =======
TOTAL 1.8G 1500
TOTAL, minus reserved VM space 1.6G 1500



-----------
Full Report
-----------

{"app_name":"Ardour8","timestamp":"2024-01-21 20:00:04.00 +0100","app_version":"8.2.0","slice_uuid":"2afd3324-ca6e-32b1-adee-e6c0ee288e0d","build_version":"8.2.0","platform":1,"bundleID":"org.ardour.Ardour8","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS 12.7.2 (21G1974)","incident_id":"297F29DD-5F20-4661-9487-1B0EEB02793E","name":"Ardour8"}
{
  "uptime" : 450,
  "procLaunch" : "2024-01-21 19:59:48.9298 +0100",
  "procRole" : "Foreground",
  "version" : 2,
  "userID" : 501,
  "deployVersion" : 210,
  "modelCode" : "MacBookPro13,3",
  "procStartAbsTime" : 453303202945,
  "coalitionID" : 940,
  "osVersion" : {
    "train" : "macOS 12.7.2",
    "build" : "21G1974",
    "releaseType" : "User"
  },
  "captureTime" : "2024-01-21 19:59:52.7391 +0100",
  "incident" : "297F29DD-5F20-4661-9487-1B0EEB02793E",
  "bug_type" : "309",
  "pid" : 873,
  "procExitAbsTime" : 457109231067,
  "cpuType" : "X86-64",
  "procName" : "Ardour8",
  "procPath" : "\/Applications\/Ardour8.app\/Contents\/MacOS\/Ardour8",
  "bundleInfo" : {"CFBundleShortVersionString":"8.2.0","CFBundleVersion":"8.2.0","CFBundleIdentifier":"org.ardour.Ardour8"},
  "storeInfo" : {"deviceIdentifierForVendor":"2588DD05-B1A3-5ECE-9D23-0C7EC11EC9FE","thirdParty":true},
  "parentProc" : "launchd",
  "parentPid" : 1,
  "coalitionName" : "org.ardour.Ardour8",
  "crashReporterKey" : "D454E33E-A468-8A99-8192-337C2760CCCD",
  "bridgeVersion" : {"build":"14Y910","train":"3.0"},
  "sip" : "enabled",
  "isCorpse" : 1,
  "exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"},
  "asi" : {"libsystem_c.dylib":["abort() called"]},
  "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
  "faultingThread" : 0,
  "threads" : [{"triggered":true,"id":11536,"threadState":{"r13":{"value":206158430216},"rax":{"value":0},"rflags":{"value":582},"cpu":{"value":0},"r14":{"value":6},"rsi":{"value":6},"r8":{"value":140701918021408},"cr2":{"value":0},"rdx":{"value":0},"r10":{"value":0},"r9":{"value":140703197335451},"r15":{"value":22},"rbx":{"value":4584437248,"symbolLocation":0,"symbol":"_main_thread"},"trap":{"value":133},"err":{"value":33554760},"r11":{"value":582},"rip":{"value":140703197380606,"matchesCrashFrame":1},"rbp":{"value":140701918021760},"rsp":{"value":140701918021720},"r12":{"value":259},"rcx":{"value":140701918021720},"flavor":"x86_THREAD_STATE","rdi":{"value":259}},"queue":"com.apple.main-thread","frames":[{"imageOffset":32766,"symbol":"__pthread_kill","symbolLocation":10,"imageIndex":0},{"imageOffset":25087,"symbol":"pthread_kill","symbolLocation":263,"imageIndex":1},{"imageOffset":531732,"symbol":"abort","symbolLocation":123,"imageIndex":2},{"imageOffset":65666,"symbol":"abort_message","symbolLocation":241,"imageIndex":3},{"imageOffset":4701,"symbol":"demangling_terminate_handler()","symbolLocation":266,"imageIndex":3},{"imageOffset":122433,"symbol":"_objc_terminate()","symbolLocation":104,"imageIndex":4},{"imageOffset":62631,"symbol":"std::__terminate(void (*)())","symbolLocation":8,"imageIndex":3},{"imageOffset":72965,"symbol":"__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*)","symbolLocation":27,"imageIndex":3},{"imageOffset":72908,"symbol":"__cxa_throw","symbolLocation":116,"imageIndex":3},{"imageOffset":28456,"imageIndex":5},{"imageOffset":124164,"imageIndex":5},{"imageOffset":188995,"imageIndex":5},{"imageOffset":145257,"symbol":"StringPrivate::Composition& StringPrivate::Composition::arg<Glib::ustring>(Glib::ustring const&)","symbolLocation":25,"imageIndex":6},{"imageOffset":144913,"symbol":"std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > string_compose<Glib::ustring>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, Glib::ustring const&)","symbolLocation":81,"imageIndex":6},{"imageOffset":133249,"symbol":"PBD::run_functor_for_paths(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&, PBD::Searchpath const&, bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, void*), void*, bool, bool, bool, bool)","symbolLocation":1313,"imageIndex":6},{"imageOffset":134892,"symbol":"PBD::find_files_matching_filter(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&, PBD::Searchpath const&, bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, void*), void*, bool, bool, bool)","symbolLocation":28,"imageIndex":6},{"imageOffset":4530148,"symbol":"ARDOUR::Session::possible_states(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)","symbolLocation":84,"imageIndex":7},{"imageOffset":8811921,"imageIndex":8},{"imageOffset":8821651,"imageIndex":8},{"imageOffset":9387490,"imageIndex":8},{"imageOffset":753979,"imageIndex":8},{"imageOffset":175581,"symbol":"Gtkmm2ext::UI::run(Receiver&)","symbolLocation":301,"imageIndex":9},{"imageOffset":4900316,"imageIndex":8},{"imageOffset":21806,"symbol":"start","symbolLocation":462,"imageIndex":10}]},{"id":11567,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":11568,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":11570,"frames":[{"imageOffset":32922,"symbol":"poll","symbolLocation":10,"imageIndex":0},{"imageOffset":72396,"symbol":"CrossThreadChannel::receive(char&, bool)","symbolLocation":76,"imageIndex":6},{"imageOffset":5133298,"symbol":"ARDOUR::TriggerBoxThread::thread_work()","symbolLocation":66,"imageIndex":7},{"imageOffset":5132993,"symbol":"ARDOUR::TriggerBoxThread::_thread_work(void*)","symbolLocation":97,"imageIndex":7},{"imageOffset":181062,"symbol":"fake_thread_start(void*)","symbolLocation":86,"imageIndex":6},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11571,"frames":[{"imageOffset":17370,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27247,"symbol":"_pthread_cond_wait","symbolLocation":1249,"imageIndex":1},{"imageOffset":573260,"symbol":"g_cond_wait","symbolLocation":44,"imageIndex":11},{"imageOffset":4856332,"symbol":"peak_thread_work()","symbolLocation":156,"imageIndex":7},{"imageOffset":183781,"symbol":"PBD::Thread::_run(void*)","symbolLocation":69,"imageIndex":6},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11572,"frames":[{"imageOffset":17370,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27247,"symbol":"_pthread_cond_wait","symbolLocation":1249,"imageIndex":1},{"imageOffset":573260,"symbol":"g_cond_wait","symbolLocation":44,"imageIndex":11},{"imageOffset":4856332,"symbol":"peak_thread_work()","symbolLocation":156,"imageIndex":7},{"imageOffset":183781,"symbol":"PBD::Thread::_run(void*)","symbolLocation":69,"imageIndex":6},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11573,"frames":[{"imageOffset":17370,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27247,"symbol":"_pthread_cond_wait","symbolLocation":1249,"imageIndex":1},{"imageOffset":573260,"symbol":"g_cond_wait","symbolLocation":44,"imageIndex":11},{"imageOffset":97604,"symbol":"ARDOUR::Analyser::work()","symbolLocation":132,"imageIndex":7},{"imageOffset":183781,"symbol":"PBD::Thread::_run(void*)","symbolLocation":69,"imageIndex":6},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11577,"frames":[{"imageOffset":17370,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27247,"symbol":"_pthread_cond_wait","symbolLocation":1249,"imageIndex":1},{"imageOffset":573260,"symbol":"g_cond_wait","symbolLocation":44,"imageIndex":11},{"imageOffset":320716,"symbol":"ARDOUR::AudioEngine::do_reset_backend()","symbolLocation":252,"imageIndex":7},{"imageOffset":183781,"symbol":"PBD::Thread::_run(void*)","symbolLocation":69,"imageIndex":6},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11578,"frames":[{"imageOffset":17370,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27247,"symbol":"_pthread_cond_wait","symbolLocation":1249,"imageIndex":1},{"imageOffset":573260,"symbol":"g_cond_wait","symbolLocation":44,"imageIndex":11},{"imageOffset":322779,"symbol":"ARDOUR::AudioEngine::do_devicelist_update()","symbolLocation":203,"imageIndex":7},{"imageOffset":183781,"symbol":"PBD::Thread::_run(void*)","symbolLocation":69,"imageIndex":6},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11579,"frames":[{"imageOffset":9475,"symbol":"nanov2_free_definite_size","symbolLocation":62,"imageIndex":12},{"imageOffset":267064,"symbol":"XMLNode::clear_lists()","symbolLocation":120,"imageIndex":6},{"imageOffset":266846,"symbol":"XMLNode::~XMLNode()","symbolLocation":14,"imageIndex":6},{"imageOffset":267017,"symbol":"XMLNode::clear_lists()","symbolLocation":73,"imageIndex":6},{"imageOffset":266846,"symbol":"XMLNode::~XMLNode()","symbolLocation":14,"imageIndex":6},{"imageOffset":267017,"symbol":"XMLNode::clear_lists()","symbolLocation":73,"imageIndex":6},{"imageOffset":266846,"symbol":"XMLNode::~XMLNode()","symbolLocation":14,"imageIndex":6},{"imageOffset":267017,"symbol":"XMLNode::clear_lists()","symbolLocation":73,"imageIndex":6},{"imageOffset":266846,"symbol":"XMLNode::~XMLNode()","symbolLocation":14,"imageIndex":6},{"imageOffset":267017,"symbol":"XMLNode::clear_lists()","symbolLocation":73,"imageIndex":6},{"imageOffset":266846,"symbol":"XMLNode::~XMLNode()","symbolLocation":14,"imageIndex":6},{"imageOffset":267017,"symbol":"XMLNode::clear_lists()","symbolLocation":73,"imageIndex":6},{"imageOffset":266846,"symbol":"XMLNode::~XMLNode()","symbolLocation":14,"imageIndex":6},{"imageOffset":263883,"symbol":"XMLTree::~XMLTree()","symbolLocation":27,"imageIndex":6},{"imageOffset":158253,"symbol":"MIDI::Name::MIDINameDocument::MIDINameDocument(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)","symbolLocation":157,"imageIndex":13},{"imageOffset":2268431,"symbol":"MIDI::Name::MidiPatchManager::load_midi_name_document(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)","symbolLocation":47,"imageIndex":7},{"imageOffset":2267672,"symbol":"MIDI::Name::MidiPatchManager::add_midnam_files_from_directory(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)","symbolLocation":616,"imageIndex":7},{"imageOffset":2270259,"symbol":"MIDI::Name::MidiPatchManager::load_midnams()","symbolLocation":147,"imageIndex":7},{"imageOffset":183781,"symbol":"PBD::Thread::_run(void*)","symbolLocation":69,"imageIndex":6},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11594,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":11609,"frames":[{"imageOffset":40266,"symbol":"__select","symbolLocation":10,"imageIndex":0},{"imageOffset":205074,"symbol":"Curl_poll","symbolLocation":786,"imageIndex":14},{"imageOffset":181318,"symbol":"Curl_multi_wait","symbolLocation":1270,"imageIndex":14},{"imageOffset":155307,"symbol":"curl_easy_perform","symbolLocation":299,"imageIndex":14},{"imageOffset":234332,"imageIndex":8},{"imageOffset":6301724,"imageIndex":8},{"imageOffset":181062,"symbol":"fake_thread_start(void*)","symbolLocation":86,"imageIndex":6},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11611,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":11612,"name":"AMCP Logging Spool","frames":[{"imageOffset":6566,"symbol":"semaphore_wait_trap","symbolLocation":10,"imageIndex":0},{"imageOffset":107238,"symbol":"caulk::mach::semaphore::wait_or_error()","symbolLocation":16,"imageIndex":15},{"imageOffset":8520,"symbol":"caulk::concurrent::details::worker_thread::run()","symbolLocation":36,"imageIndex":15},{"imageOffset":7692,"symbol":"void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*)","symbolLocation":41,"imageIndex":15},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11641,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":11644,"name":"com.apple.NSEventThread","frames":[{"imageOffset":6506,"symbol":"mach_msg_trap","symbolLocation":10,"imageIndex":0},{"imageOffset":7384,"symbol":"mach_msg","symbolLocation":56,"imageIndex":0},{"imageOffset":524957,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":319,"imageIndex":16},{"imageOffset":518440,"symbol":"__CFRunLoopRun","symbolLocation":1276,"imageIndex":16},{"imageOffset":515436,"symbol":"CFRunLoopRunSpecific","symbolLocation":562,"imageIndex":16},{"imageOffset":1755534,"symbol":"_NSEventThread","symbolLocation":132,"imageIndex":17},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11645,"frames":[{"imageOffset":25406,"symbol":"kevent","symbolLocation":10,"imageIndex":0},{"imageOffset":968664,"symbol":"_kqueue_thread_func","symbolLocation":168,"imageIndex":18},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11646,"name":"gmain","frames":[{"imageOffset":40266,"symbol":"__select","symbolLocation":10,"imageIndex":0},{"imageOffset":311530,"symbol":"g_poll","symbolLocation":554,"imageIndex":11},{"imageOffset":244017,"symbol":"g_main_context_iterate","symbolLocation":433,"imageIndex":11},{"imageOffset":251784,"symbol":"glib_worker_main","symbolLocation":120,"imageIndex":11},{"imageOffset":422650,"symbol":"g_thread_proxy","symbolLocation":90,"imageIndex":11},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11650,"name":"pool","frames":[{"imageOffset":17370,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27300,"symbol":"_pthread_cond_wait","symbolLocation":1302,"imageIndex":1},{"imageOffset":573777,"symbol":"g_cond_wait_until","symbolLocation":129,"imageIndex":11},{"imageOffset":34110,"symbol":"g_async_queue_pop_intern_unlocked","symbolLocation":142,"imageIndex":11},{"imageOffset":426682,"symbol":"g_thread_pool_thread_proxy","symbolLocation":122,"imageIndex":11},{"imageOffset":422650,"symbol":"g_thread_proxy","symbolLocation":90,"imageIndex":11},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11651,"name":"pool","frames":[{"imageOffset":17370,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27300,"symbol":"_pthread_cond_wait","symbolLocation":1302,"imageIndex":1},{"imageOffset":573777,"symbol":"g_cond_wait_until","symbolLocation":129,"imageIndex":11},{"imageOffset":34110,"symbol":"g_async_queue_pop_intern_unlocked","symbolLocation":142,"imageIndex":11},{"imageOffset":426682,"symbol":"g_thread_pool_thread_proxy","symbolLocation":122,"imageIndex":11},{"imageOffset":422650,"symbol":"g_thread_proxy","symbolLocation":90,"imageIndex":11},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":11652,"name":"pool","frames":[{"imageOffset":17370,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27300,"symbol":"_pthread_cond_wait","symbolLocation":1302,"imageIndex":1},{"imageOffset":573777,"symbol":"g_cond_wait_until","symbolLocation":129,"imageIndex":11},{"imageOffset":34110,"symbol":"g_async_queue_pop_intern_unlocked","symbolLocation":142,"imageIndex":11},{"imageOffset":426682,"symbol":"g_thread_pool_thread_proxy","symbolLocation":122,"imageIndex":11},{"imageOffset":422650,"symbol":"g_thread_proxy","symbolLocation":90,"imageIndex":11},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]}],
  "usedImages" : [
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703197347840,
    "size" : 229376,
    "uuid" : "c37bfe8a-c5ae-3fe0-b722-33483d9017b9",
    "path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
    "name" : "libsystem_kernel.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703197577216,
    "size" : 49152,
    "uuid" : "e097f78f-fcfb-30f3-9164-dbc9709ba134",
    "path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
    "name" : "libsystem_pthread.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703196332032,
    "size" : 561152,
    "uuid" : "4ecd1661-9d96-3669-bb31-4c6d5c685d4c",
    "path" : "\/usr\/lib\/system\/libsystem_c.dylib",
    "name" : "libsystem_c.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703197257728,
    "size" : 90112,
    "uuid" : "69ac868b-1157-364a-984a-5ef26973f661",
    "path" : "\/usr\/lib\/libc++abi.dylib",
    "name" : "libc++abi.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64h",
    "base" : 140703196078080,
    "size" : 241664,
    "uuid" : "b36a2b52-68a9-3e44-b927-71c24be1272f",
    "path" : "\/usr\/lib\/libobjc.A.dylib",
    "name" : "libobjc.A.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4460744704,
    "size" : 245760,
    "uuid" : "5214af7f-c807-35b2-954d-efdaf776fc31",
    "path" : "\/Applications\/Ardour8.app\/Contents\/lib\/libglibmm-2.4.1.dylib",
    "name" : "libglibmm-2.4.1.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4458606592,
    "size" : 327680,
    "uuid" : "bbf6cf6d-3f57-38a9-9868-046b336b697f",
    "path" : "\/Applications\/Ardour8.app\/Contents\/lib\/libpbd.dylib",
    "name" : "libpbd.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4469895168,
    "size" : 9732096,
    "uuid" : "23de9229-8279-344e-a301-368537c1390e",
    "path" : "\/Applications\/Ardour8.app\/Contents\/lib\/libardour.dylib",
    "name" : "libardour.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4430766080,
    "CFBundleShortVersionString" : "8.2.0",
    "CFBundleIdentifier" : "org.ardour.Ardour8",
    "size" : 12795904,
    "uuid" : "2afd3324-ca6e-32b1-adee-e6c0ee288e0d",
    "path" : "\/Applications\/Ardour8.app\/Contents\/MacOS\/Ardour8",
    "name" : "Ardour8",
    "CFBundleVersion" : "8.2.0"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4457918464,
    "size" : 311296,
    "uuid" : "c1349234-cd8b-3fc7-8f8c-295e24a48b1b",
    "path" : "\/Applications\/Ardour8.app\/Contents\/lib\/libgtkmm2ext.dylib",
    "name" : "libgtkmm2ext.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4583911424,
    "size" : 442368,
    "uuid" : "499010ac-3054-326e-a050-fefffb5ce89a",
    "path" : "\/usr\/lib\/dyld",
    "name" : "dyld"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4462579712,
    "size" : 1179648,
    "uuid" : "7e7ad53a-0fad-3980-a1ff-ed0c51250738",
    "path" : "\/Applications\/Ardour8.app\/Contents\/lib\/libglib-2.0.0.dylib",
    "name" : "libglib-2.0.0.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703195607040,
    "size" : 180224,
    "uuid" : "2ea05464-fac2-32fe-8e03-94252869554d",
    "path" : "\/usr\/lib\/system\/libsystem_malloc.dylib",
    "name" : "libsystem_malloc.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4453277696,
    "size" : 245760,
    "uuid" : "208601c5-31ee-3eaa-92b9-3ac15eb9caf9",
    "path" : "\/Applications\/Ardour8.app\/Contents\/lib\/libmidipp.dylib",
    "name" : "libmidipp.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4465975296,
    "size" : 442368,
    "uuid" : "dff44b67-a7d1-3cd1-aa04-e5286c4c6653",
    "path" : "\/Applications\/Ardour8.app\/Contents\/lib\/libcurl.4.dylib",
    "name" : "libcurl.4.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703343263744,
    "CFBundleShortVersionString" : "1.0",
    "CFBundleIdentifier" : "com.apple.audio.caulk",
    "size" : 139264,
    "uuid" : "f04b5c91-d0ec-33c6-8a81-b80a3ebf827f",
    "path" : "\/System\/Library\/PrivateFrameworks\/caulk.framework\/Versions\/A\/caulk",
    "name" : "caulk"
  },
  {
    "source" : "P",
    "arch" : "x86_64h",
    "base" : 140703197892608,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.CoreFoundation",
    "size" : 5255168,
    "uuid" : "fb79a14a-fda9-3a3b-bc97-6eb525b794a6",
    "path" : "\/System\/Library\/Frameworks\/CoreFoundation.framework\/Versions\/A\/CoreFoundation",
    "name" : "CoreFoundation",
    "CFBundleVersion" : "1866"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 140703242448896,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.AppKit",
    "size" : 15269888,
    "uuid" : "322c1378-24a3-3361-97a1-8a487166d15b",
    "path" : "\/System\/Library\/Frameworks\/AppKit.framework\/Versions\/C\/AppKit",
    "name" : "AppKit",
    "CFBundleVersion" : "2113.60.148"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" : 4467740672,
    "size" : 1228800,
    "uuid" : "03a98384-cfc9-3c2e-aabe-1d29add9387f",
    "path" : "\/Applications\/Ardour8.app\/Contents\/lib\/libgio-2.0.0.dylib",
    "name" : "libgio-2.0.0.dylib"
  }
],
  "sharedCache" : {
  "base" : 140703194316800,
  "size" : 19331678208,
  "uuid" : "8ec191b8-2f89-31dc-ab61-d4a7547258ef"
},
  "vmSummary" : "ReadOnly portion of Libraries: Total=985.0M resident=0K(0%) swapped_out_or_unallocated=985.0M(100%)\nWritable regions: Total=626.6M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=626.6M(100%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nAccelerate framework 256K 2 \nActivity Tracing 256K 1 \nCG backing stores 1920K 4 \nColorSync 212K 24 \nCoreAnimation 2176K 1 \nCoreGraphics 12K 2 \nFoundation 16K 1 \nKernel Alloc Once 8K 1 \nMALLOC 343.9M 50 \nMALLOC guard page 32K 8 \nMALLOC_LARGE (reserved) 2508K 3 reserved VM address space (unallocated)\nMALLOC_NANO (reserved) 256.0M 1 reserved VM address space (unallocated)\nSTACK GUARD 56.1M 21 \nStack 18.2M 21 \nVM_ALLOCATE 68K 15 \n__CTF 756 1 \n__DATA 24.8M 435 \n__DATA_CONST 14.3M 194 \n__DATA_DIRTY 638K 110 \n__FONT_DATA 4K 1 \n__LINKEDIT 672.5M 114 \n__OBJC_RO 82.9M 1 \n__OBJC_RW 3200K 2 \n__TEXT 312.5M 446 \n__UNICODE 592K 1 \ndyld private memory 2048K 3 \nmapped file 81.5M 20 \nshared memory 772K 17 \n=========== ======= ======= \nTOTAL 1.8G 1500 \nTOTAL, minus reserved VM space 1.6G 1500 \n",
  "legacyInfo" : {
  "threadTriggered" : {
    "queue" : "com.apple.main-thread"
  }
},
  "trialInfo" : {
  "rollouts" : [
    {
      "rolloutId" : "61af99aeda72d16a4beb7756",
      "factorPackIds" : {
        "SIRI_DIALOG_ASSETS" : "629fe54ebc762c0b6f758b6b"
      },
      "deploymentId" : 240000409
    },
    {
      "rolloutId" : "61301e3a61217b3110231469",
      "factorPackIds" : {
        "SIRI_FIND_MY_CONFIGURATION_FILES" : "652886aa2c02f032beae8316"
      },
      "deploymentId" : 240000028
    }
  ],
  "experiments" : [

  ]
}
}

Model: MacBookPro13,3, BootROM 522.0.0.0.0, 4 processors, Quad-Core Intel Core i7, 2,6 GHz, 16 GB, SMC 2.38f12
Graphics: Intel HD Graphics 530, Intel HD Graphics 530, Built-In
Graphics: Radeon Pro 450, AMD Radeon Pro 450, PCIe, 2 GB
Display: Color LCD, 2880 x 1800 Retina, Main, MirrorOff, Online
Memory Module: BANK 0/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x80CE, 0x4B3445424533303445422D45474347202020
Memory Module: BANK 1/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x80CE, 0x4B3445424533303445422D45474347202020
AirPort: spairport_wireless_card_type_wifi (0x14E4, 0x15A), Broadcom BCM43xx 1.0 (7.77.111.1 AirPortDriverBrcmNIC-1710.4)
AirPort:
Bluetooth: Version (null), 0 services, 0 devices, 0 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB30Bus
USB Device: Apple T1 Controller
Thunderbolt Bus: MacBook Pro, Apple Inc., 41.5
Thunderbolt Bus: MacBook Pro, Apple Inc., 41.5
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9607 [ardour] bugs minor random 2024-01-21 08:41 2024-01-21 08:41
Reporter: SereTuAmantisBandido Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [Manjaro-Plasma-Wayland] Sometimes Ardour fails to launch
Description: Sometimes Ardour crashes before showing any window.

systemctl shows the following error messages:

ene 21 09:11:01 manjaro plasmashell[2203]: Found nothing along /home/user_name/.config/ardour8/templates:/usr/share/ardour8/templates
ene 21 09:11:07 manjaro plasmashell[2203]: The program 'ardour-8.2.0' received an X Window System error.
ene 21 09:11:07 manjaro plasmashell[2203]: This probably reflects a bug in the program.
ene 21 09:11:07 manjaro plasmashell[2203]: The error was 'BadWindow (invalid Window parameter)'.
ene 21 09:11:07 manjaro plasmashell[2203]: (Details: serial 2518 error_code 3 request_code 38 minor_code 0)
ene 21 09:11:07 manjaro plasmashell[2203]: (Note to programmers: normally, X errors are reported asynchronously;
ene 21 09:11:07 manjaro plasmashell[2203]: that is, you will receive the error a while after causing it.
ene 21 09:11:07 manjaro plasmashell[2203]: To debug your program, run it with the --sync command line
ene 21 09:11:07 manjaro plasmashell[2203]: option to change this behavior. You can then get a meaningful
ene 21 09:11:07 manjaro plasmashell[2203]: backtrace from your debugger if you break on the gdk_x_error() function.)
ene 21 09:11:07 manjaro plasmashell[2294]: ardour-request-device: watched PID no longer exists - releasing device.
ene 21 09:11:07 manjaro systemd[740]: app-ardour8-2b89d79162c84e92b1220cacbc3b03fa.scope: Consumed 2.195s CPU time.

I am using an up to date Manjaro (LTS kernel):
 -Linux manjaro 6.6.10-1-MANJARO 0000001 SMP PREEMPT_DYNAMIC Fri Jan 5 17:38:36 UTC 2024 x86_64 GNU/Linux
 -plasma-desktop 5.27.10-1
 -plasma-wayland-session 5.27.10-2
 -pipewire 1:1.0.0-2
Tags: 8.2, bug, crash
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9606 [ardour] bugs crash always 2024-01-19 18:27 2024-01-19 18:27
Reporter: LucasGGamerM Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Removing ACE Gain plugin causes crash
Description: I am running a track with a mono input, and a stereo output. I have attached the screenshot of the mixer strip.

Removing the Gain plugin always causes a crash.

I have Ardour monitoring enabled for the track, and Disk is not enabled.
Tags:
Steps To Reproduce: Create an empty session, add a track with 1 input and 2 outputs, add a Guitar effects plugin (I use Guitarix.vst3 from brummer) and try to remove the Gain plugin.
Additional Information:
System Description
Attached Files: image.png (5,545 bytes) 2024-01-19 18:27
https://tracker.ardour.org/file_download.php?file_id=4766&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9604 [ardour] other minor always 2024-01-18 12:35 2024-01-18 12:35
Reporter: mario1313 Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Background color of the tracks in the global overview of the session
Description: The background color of the tracks in the global overview of the session cannot be changed!
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: summary.jpg (24,872 bytes) 2024-01-18 12:35
https://tracker.ardour.org/file_download.php?file_id=4762&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9603 [ardour] bugs crash always 2024-01-17 20:16 2024-01-17 20:18
Reporter: arnikz Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Truncated SysEx data after recording/playing a MIDI track
Description: Hi, I imported some MIDI files into Ardour but the tracks were not played back on my synth (Yamaha CS1x) as expected. The reason for this was that the user patches (called Performances; SysEx data), which were placed at the very beginning of the tracks, failed to load.
Tags: Midi, SysEx
Steps To Reproduce: 1. Open the MIDI Tracer and set the Port to CS1x/midi_in 1.
2. Record SysEx data from the synth (a single patch dump) into a MIDI track.

Tracer log
176800978 Sysex (57) = [f0 43 00 4b 00 2e 60 00 00 75 6d 20 54 72 61 78 32 11 7f 40 29 40 7f 40 21 5d 79 40 7f 40 40 40 40 40 40 40 40 00 13 00 11 02 00 03 00 60 20 40 40 02 00 5b 15 07 05 4a f7]
176814993 Sysex (34) = [f0 43 00 4b 00 17 60 00 30 13 00 43 00 4d 00 00 26 00 46 00 30 00 47 00 00 00 7f 40 40 30 00 3a 6a f7]
176828558 Sysex (20) = [f0 43 00 4b 00 09 60 00 50 29 00 00 50 40 00 00 00 00 0e f7]
176843255 Sysex (52) = [f0 43 00 4b 00 29 60 01 00 3f 04 00 00 40 08 00 7f 42 34 40 00 7f 3a 00 01 02 40 40 40 40 40 01 40 40 40 40 01 7f 40 40 03 40 40 40 40 40 40 40 40 40 76 f7]
176857822 Sysex (52) = [f0 43 00 4b 00 29 60 02 00 3f 05 00 01 40 08 00 64 40 40 40 00 7f 3a 00 01 02 40 40 40 40 40 00 40 40 40 40 01 7f 40 40 03 40 40 40 40 40 40 40 40 40 05 f7]
176872395 Sysex (52) = [f0 43 00 4b 00 29 60 03 00 3f 06 00 01 40 08 00 64 40 40 40 00 7f 3a 00 01 02 40 40 40 40 40 00 40 40 40 40 01 7f 40 40 03 40 40 40 40 40 40 40 40 40 03 f7]
176886954 Sysex (52) = [f0 43 00 4b 00 29 60 04 00 3f 07 00 01 40 08 00 64 40 40 40 00 7f 3a 00 01 02 40 40 40 40 40 00 40 40 40 40 01 7f 40 40 03 40 40 40 40 40 40 40 40 40 01 f7]

3. Set the Port to CS1x/midi_out 1 and play the recorded track.

Tracer log
180204634 Sysex (52) = [f0 43 00 4b 00 29 60 04 00 3f 07 00 01 40 08 00 64 40 40 40 00 7f 3a 00 01 02 40 40 40 40 40 00 40 40 40 40 01 7f 40 40 03 40 40 40 40 40 40 40 40 40 01 f7]

Clearly, only the last 52 bytes (out of 319) were transmitted to the synth, which failed to init. Thanks for your help!
Additional Information:
System Description
Attached Files: test-sysex.zip (26,019 bytes) 2024-01-17 20:16
https://tracker.ardour.org/file_download.php?file_id=4760&type=bug
Pf_Wurlitza.syx (319 bytes) 2024-01-17 20:16
https://tracker.ardour.org/file_download.php?file_id=4761&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9602 [ardour] features minor have not tried 2024-01-14 13:28 2024-01-14 13:28
Reporter: GtheGreat Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Request for option to make your Control Surfaces default for all projects instead of per-project
Description: As title says: If you always use the same controller and or midi setup, give option to make it as default for all new and or used projects
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9593 [ardour] bugs crash always 2024-01-04 14:09 2024-01-12 12:17
Reporter: bragolin Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ardour crashing with GLib-ERROR when starting with a session as argument
Description: I wanted to start Ardour directly into a session from command line, e.g.
"C:\Program Files\Ardour8\bin\ardour.exe" mySession
(the help says Usage: Ardour [ OPTIONS ] [ SESSION-NAME ] but I also tried with the full path to the ardour-file of the session with the same result.)

It starts up (showing the splashscreen) until in the commandline I can see:
Ardour: [INFO]: Loading bindings from C:\Program Files\Ardour8\share\ardour8\ardour.keys
Loading ui configuration file C:\Program Files\Ardour8\share\ardour8\clearlooks.rc

(ardour.exe:7176): GLib-ERROR **: 14:48:55.982: creating thread 'gmain': Error setting new thread priority: Falscher Parameter.

I also tried creating a windows shortcut to ardour with the argument which also results in ardour not starting up (I expect the same error)

When I give a non-existing session name, it shows the audio/midi setup and crashes after I press the start button.

When I give a session that used another audio setup before, I also receive the audio/midi setup and it crashes after I press the start button.
So it loads the session to some extend and then crashes.

Any help is very appreciated, I will support the best I can
Best regards
Tags:
Steps To Reproduce: Start windows cmd
enter the following:
"C:\Program Files\Ardour8\bin\ardour.exe" mySession
Additional Information: I am currently using the demo version
System Description
Attached Files: Ardour-8.2.0-crash-1704377198.txt (12,500 bytes) 2024-01-04 14:09
https://tracker.ardour.org/file_download.php?file_id=4755&type=bug
Notes
(0028455)
bragolin   
2024-01-12 12:17   
Resulting of a forum thread the cause seems to be the WinMME MIDI system. Setting it to None, everything works fine from the command line (except that MIDI is not available then of course).
The behaviour is the same on 3 different PCs where I did a fresh install of 8.2.0.
Opening the session from the GUI with activated WinMME midi works fine, from command line it doesn't

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9600 [ardour] other minor always 2024-01-11 20:57 2024-01-11 20:57
Reporter: automaciej Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Missing symbols/icons in the audio analysis window (displayed after exporting audio)
Description: There are 3 icons that the audio analysis can display, as far as understand:

blue speaker
green tick
red "x"

On MacOS, of the three, only the green tick appears. Places where other symbols/icons would normally appear as empty (black). Screenshot attached.

I'm observing this since I started using Ardour on Mac about a year (and half?) ago.
Tags:
Steps To Reproduce: Install Ardour on a Mac, make a session with some audio, export it enabling audio analysis, look at the displayed window.
Additional Information:
System Description
Attached Files: Screenshot 2024-01-08 at 15.06.29.png (640,206 bytes) 2024-01-11 20:57
https://tracker.ardour.org/file_download.php?file_id=4758&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9598 [ardour] bugs minor always 2024-01-09 00:14 2024-01-11 02:29
Reporter: Schmitty2005 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Regions Disappear from Editor List When Renamed.
Description: When the MIDI region is renamed by selecting the region in the Editor List, using a right-click , rename. The region disappears from the Editor List. If the region is then split, the names will reappear. When renaming the children of the split, they do not disappear and function as they should. This does not affect audio regions
 
Tags:
Steps To Reproduce: 1. Create New project
2. Create new MIDI track, step edit to create new MIDI.
3. Select region from Editor List and rename.
4. Watch region disappear!

Optional Steps :
5. Split MIDI region
6. Watch MIDI region names appear.
Additional Information: Ubuntu 22.04 LTS with Ardour downloaded from Ardour.org.
System Description
Attached Files:
Notes
(0028450)
Schmitty2005   
2024-01-09 01:25   
Also affects Mixbus 9.2.172
(0028453)
Schmitty2005   
2024-01-11 02:29   
Duplicate of 0009599. Please remove. 0009599 is updated with OS. Mixbus32C

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9581 [ardour] bugs tweak always 2023-12-19 10:56 2024-01-09 15:28
Reporter: axra Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Lollipops at the beginning of a bar are cut in the middle.
Description: Lollipops at the beginning of a bar are cut in the middle.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Bildschirmfoto vom 2023-12-19 11-43-51.png (3,447 bytes) 2023-12-19 10:56
https://tracker.ardour.org/file_download.php?file_id=4748&type=bug
png

Peek 2024-01-09 16-19.gif (277,886 bytes) 2024-01-09 15:24
https://tracker.ardour.org/file_download.php?file_id=4756&type=bug
Bildschirmfoto vom 2024-01-09 16-27-48.png (5,407 bytes) 2024-01-09 15:28
https://tracker.ardour.org/file_download.php?file_id=4757&type=bug
png
Notes
(0028451)
axra   
2024-01-09 15:24   
If I set the Note Mode to percussive the Lollipop at the beginning of a bar dissapears!
(0028452)
axra   
2024-01-09 15:28   

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9335 [ardour] bugs major always 2023-05-14 07:52 2024-01-08 09:30
Reporter: al f Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Edit mode > Ripple All: When deleting objects, location markers move the wrong distance
Description: Edit mode > Ripple All: When deleting objects, location markers move the wrong distance.

Expected behaviour is for marks to move the same distance on the timeline as the time of the deleted object, but they move a much longer distance. If there is not room for the marks to move as long as they "want to", they all pile up at timeline zero.
Tags: delete, editing, Editor, location marker, region, split
Steps To Reproduce: Start session > Record or import audio to several tracks > Add location markers on the timeline > Split audio into multiple regions > Delete one or more regions.
Additional Information: Manjaro KDE, official Ardour 7.4. Using Jack2 started by QjackCtl - Version: 0.9.10 Using: Qt 6.5.0
System Description
Attached Files: Ardour_7-4_01_Before-delete.png (207,973 bytes) 2023-05-14 07:52
https://tracker.ardour.org/file_download.php?file_id=4525&type=bug
png

Ardour_7-4_02_After-delete.png (195,738 bytes) 2023-05-14 07:52
https://tracker.ardour.org/file_download.php?file_id=4526&type=bug
png
Notes
(0027951)
al f   
2023-08-08 11:19   
Still reproducing this in Ardour 7.5.

However, when using Edit > Delete Range Section (instead of deleting regions with backspace), markers move the expected (correct) distance.
(0028350)
al f   
2023-11-22 08:41   
Still reproducing this in Ardour 8.1

However, when using Edit > Delete Range Section (instead of deleting regions with backspace), markers move the expected (correct) distance.
(0028449)
al f   
2024-01-08 09:30   
Still reproducing this in Ardour 8.2

Also tried deleting my profile to start "from scratch". Same result.

Steps to reproduce: Start session > Record or import audio to several tracks > Choose Edit Mode Ripple All > Add location markers on the timeline > Split audio (across tracks) into multiple regions > Delete one or more regions.

When using Edit > Delete Range Section (instead of deleting regions with backspace), markers move the expected (correct) distance.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9597 [ardour] bugs minor always 2024-01-07 19:14 2024-01-07 19:37
Reporter: jihi Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: New track creates duplicate playlist names
Description: Renaming a playlist to an existing name is restricted.

When deleting a track only the track is deleted in session, but the playlist of that track is not.
Creating a new track with the same name as the deleted, a playlist with the same name is created, even if this name is allready in session.

Linking the old playlist to the new track which allready has a playlist with the same name, breaks the gui:
- Renaming does not work
- Playlist selection does not work
Tags:
Steps To Reproduce: -Create a track (automatically named "Audio 1")
-Delete the track "Audio 1"
-Create new track (it is named "Audio 1" again, also the playlist)
-On the new track Playlist->Advanced->Steal from... or Share with...
-select "Audio 1" from unassigned track
Now there are two Playlists with name "Audio 1" assigned to the track

Additional Information:
System Description Windows 11
Attached Files:
Notes
(0028447)
jihi   
2024-01-07 19:36   
When you manually create a playlist with the name "Audio 2" and then create a new track "Audio 2", the new playlist is also "Audio 2". So it has nothing to do with the unassigned tracks.
(0028448)
jihi   
2024-01-07 19:37   
Renaming of playlists, that are created alongside with tracks does not work at all, even in new session without dupplicates. It only works for new created playlists..

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9596 [ardour] features minor always 2024-01-07 17:50 2024-01-07 17:50
Reporter: anarkiisto Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow controlling cues with Generic MIDI control surface
Description: Currently, it's not possible to use the "Generic MIDI" -> "Ctrl+Middle mouse" to assign cue buttons to a MIDI control surface. It would be cool to be able to do so <3
Tags: cue, Midi, MIDI control, MIDI learn
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9595 [ardour] bugs minor always 2024-01-07 13:53 2024-01-07 14:04
Reporter: jihi Platform: Microsoft  
Assigned To: OS: Windows  
Priority: low OS Version: 11  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Windows installer tries to uninstall previous installation from wrong path
Description: Ardour is installed on drive X, but when running the installer for a new version, it tries to uninstall Ardour from drive C instead of X.
Tags: installer
Steps To Reproduce: Install Ardour on a drive other then C and try to reinstall.
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0028445)
jihi   
2024-01-07 13:55   
Running the uninstaller from drive X tries to uninstall correctly from drive X.
(0028446)
x42   
2024-01-07 14:04   
That is a good clue. Thanks!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9486 [ardour] bugs feature always 2023-10-17 09:28 2024-01-03 10:11
Reporter: rastin Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Grid tool moves midi automation points when applying mid-twist
Description: Using the new Grid Tool (Y), applying a mid-twist to a midi region correctly moves the beat grid of that region, and all midi notes stay fixed in space while the grid moves underneath. However, automation points move after the mid-twist is completed resulting in a "decoupling" between the notes and their automation.
Tags:
Steps To Reproduce: 1. Create a midi track
2. Create a short midi region
3. Add some notes to the midi region
4. Add an automation lane to the midi region (such as pitch bender or controller)
5. Add some points to the automation lane
6. Using the Grid Tool (Y), pin some location at or before the start of the midi region. Also pin a second location at or past the end of the midi region.
7. Using the Grid Tool, move a beat marker between the pinned locations created in 6. Notice that the midi notes do not move but the automation points do move.
Additional Information: I'm listing this in the tracker as a bug with severity set to feature because I am unsure if this behavior is intended. When recording midi drums, for example, this type of shift causes the recorded hihat and the hihat pedal to be misaligned, and the playback of that recorded midi section is actually different from what was recorded.

The attached screenshot shows a midi region that was originally created on a uniform grid but has since been mid-twisted using the grid tool. The notes of the midi region are still fixed in their original uniform grid locations, but the automation points follow the new twisted grid.
System Description
Attached Files: Screenshot_20231017_035006.png (169,912 bytes) 2023-10-17 09:28
https://tracker.ardour.org/file_download.php?file_id=4672&type=bug
png

1_before_midtwist.png (335,112 bytes) 2024-01-03 10:11
https://tracker.ardour.org/file_download.php?file_id=4753&type=bug
2_after_midtwist.png (337,892 bytes) 2024-01-03 10:11
https://tracker.ardour.org/file_download.php?file_id=4754&type=bug
Notes
(0028443)
rastin   
2024-01-03 10:11   
Attached are two more screenshots, one before applying a midtwist and the other after. In both, there are three automation lanes. The track labeled Vitalium is a midi track and has automation on one of the track's plugins. The track labeled Bass Recording is an audio track and has two automation lanes, one on the panning control (azimuth) and the second automating the gain parameter of the ace gain plugin.

Before the midtwist, there is a peak or a valley aligned with the location marker labeled "Original Peak/Valley" in all three automation lanes. Also, the transport is initially located at the same spot.

After the midtwist, the audio track's automation points remain aligned with the transport where they were located originally. The midi track's automation lane however has shifted to follow the new twisted grid.

The audio behavior is correct as expected. The location marker following the twist also is correct as expected.

The midi behavior definitely feels like a bug, as now the midi notes are decoupled from the midi automation. (Not visible in these latest two screenshots is the fact that the midi notes themselves do not move when the grid is twisted.)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9592 [ardour] features feature have not tried 2023-12-31 19:21 2024-01-03 00:15
Reporter: befloibent Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Track Template Folders (and search)
Description: For folks who rely heavily on Track Templates, I think it would be very useful to be able to use a folder/tree structure in the "Add Track/Bus/VCA" and "Manage Templates" Dialogs (see attached mockups). This would also help maintain order should the idea of "Multi-Track" or "Group" templates ever be implemented, eg:

https://tracker.ardour.org/view.php?id=6752
https://tracker.ardour.org/view.php?id=5691

As a bonus, including a Search functionality as in the "Favorite Plugins" (see "Manage Templates" mockup"). Don't know if this is worthy of a separate Tracker Issue.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Add-Track-Folder-mockup.png (108,757 bytes) 2023-12-31 19:21
https://tracker.ardour.org/file_download.php?file_id=4751&type=bug
png

Track-Folders-mockup.png (74,197 bytes) 2023-12-31 19:21
https://tracker.ardour.org/file_download.php?file_id=4752&type=bug
png
Notes
(0028440)
Schmitty2005   
2024-01-03 00:15   
I like the idea! Under your Track Folders Mockup, I think an additional tab for "Buss Templates" would be helpful.

 This may be getting to be too much but, maybe a tab for 'Ardour Open Source Templates' that would have templates using only open source plugins, and submitted to Github to get included with Ardour.

Another suggestion would be an "Online Templates" tab, where users can share templates, but I could see that getting too messy.

Just some thoughts......

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9590 [ardour] features feature N/A 2023-12-28 23:01 2023-12-28 23:10
Reporter: cammy Platform: Arch  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ability to exclusively arm single tracks for recording
Description: When clicking record on a track, any other track armed will remain armed.

In my workflow, I tend to build a session/composition a track or two at a time; especially when overdubbing my voice. I often go back to components/tracks in the piece and rerecord them.

In Ableton (iirc), the default behavior is to actually disarm all other tracks when the user clicks the record button on a track unless the ctrl key is held, in which case it will treat it similarly to the behavior in many other computer contexts like working with files (adding to selection). Indeed, in Ableton, you can even click record on one track and then shift click on another and all tracks in between will be armed for recording.

When working this way, if I have many tracks in a session and I'm scrolled to a particular set of them in the timeline, I might (and have) inadvertently armed a track I wanted to record to without disarming one I didn't which could result in confusion or even worse accidental loss of data. I recognize this is more an issue for someone with muscle memory from Ableton, but I feel strongly this would be highly-desirable.

It would be fantastic if this were at least an option set in the preferences.

By ctrl+shift+clicking a track, one can already arm and disarm all tracks. That hopefully implies implementing this could be trivial.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9589 [ardour] bugs minor always 2023-12-28 21:02 2023-12-28 21:02
Reporter: v2 Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Importing session file from 2006 fails
Description: I tried importing a session file from 2006 (made with an unknown version of ardour) into Ardour 7.5.0 (mantic packaged version). It failed due to multiple factors. This was discussed on irc with x42 and las. I was able to open the session after the tweaks below, but with two caveats:

1. Major issue with sends: all track sends to buses (reverb buses) failed to connect and Ardour shows 0 outputs for each of these sends
2. Some buses were not visible in the mixer or editor, but were still working and connected to. They did appear after saving the imported session and then restarting ardour with the session

The session file is attached.

The modification process for the file included the following steps:
1) add sample-rate attribute to the root node
2) commented out the borked <extra> section where there was a colon in the XML element name
3) renamed inputs and outputs "*/in X" to "*/audio_in X" - and same for outs,
4) replaced "pre" to "PreFader" and "post" to "PostFader"
5) removed alsa_pcm connections
Tags:
Steps To Reproduce: Open session in a newer version of Ardour
Additional Information:
System Description
Attached Files: _orig_JKK.ardour (289,344 bytes) 2023-12-28 21:02
https://tracker.ardour.org/file_download.php?file_id=4750&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9569 [ardour] bugs minor always 2023-12-09 19:50 2023-12-28 10:06
Reporter: anarkiisto Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Plugin are of Editor Mixer hard to use on short screens
Description: Hi :3

The vertical space afforded to the plugin section of the editor mixer makes it quite difficult and rather annoying to work with or get an over view of attached plugins. (See attached screenshot)

I don't know what solution would be best, but I imagine the ability to minimize the visual gain controls, and in that state only show the number control/representations, would keep functionality while allowing reallocation of the space.

Anyhow, thank you for a wonderful piece of software! Falling more in love with it with every passing hour! <3
Tags: Editor Mixer
Steps To Reproduce:
Additional Information:
System Description
Attached Files: editor-mixer_000.png (54,028 bytes) 2023-12-09 19:50
https://tracker.ardour.org/file_download.php?file_id=4738&type=bug
png
Notes
(0028438)
anarkiisto   
2023-12-28 10:06   
Just in case anyone runs into this issue and don't mind ugly, horrid hacks in their forks, this is what "solved" it for me: https://github.com/ahstro/ardour-m3k/commit/bb8363f32e40c1579778e69fbbedd2908610965f

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9588 [ardour] bugs minor always 2023-12-27 11:04 2023-12-27 11:04
Reporter: surfinspots Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi tempo change - region not draw correctly
Description: If a MIDI region is been cut and one on the new region is tempo change the beginning of the the region doesn't fit anymore.
There is "new space" in front of the first note.
The attached video demonstrates it.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: ardour-bug-2023-12-27_11.52.49.mp4 (211,017 bytes) 2023-12-27 11:04
https://tracker.ardour.org/file_download.php?file_id=4749&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9587 [ardour] bugs crash always 2023-12-26 17:51 2023-12-26 17:51
Reporter: monniaux Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: crash after using pitch shifter
Description: Ardour crashes when playing after using the pitch shifter.
Tags:
Steps To Reproduce: Select an audio region, pitch shift it (say one octave down), and then hit play. Ardour crashes.
 
Note: saving the session just after pitch shifting works.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9274 [ardour] bugs crash always 2023-03-09 01:29 2023-12-26 00:25
Reporter: cjs Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Analog Obsession plugins running via yabridge crash Ardour when oversampling is selected
Description: Analog Obsession vst3 (windows) plugins running via yabridge that have been problem free in Ardour 7.2 and prior, and Mixbus 32c 8.2.66 and prior, now crash in Ardour 7.3 and Mixbus versions higher than 8.2.66 when the oversampling button (the Analog Obsession logo on the plugin GUI) is clicked selecting oversampling. The playback ceases when oversampling is selected, and clicking again on the Analog Obsession logo to turn oversampling back off does turn the GUI's indicator back to show no oversampling, but Ardour (and Mixbus) are un-responsive after the oversampling selection event, and Gnome eventually pops up a window offering a force quit or wait.

Tags:
Steps To Reproduce:  Set up a new session, install yabridge, get a plugin from Analog Obsession (they are donationware), such as LALA, insert said plugin in a channel, then click on the Analog Obsession logo on the plugin GUI to select oversampling.
Additional Information: I have tried this on a few different kernels and both Fedora based (Nobara) and Arch based (Manjaro) setups and the same crash happens.
Also if a session that has been saved for example in Ardour 7.2 with an Analog Obsession plugin activated that has oversampling on, that session will not load into Ardour 7.3, instead, the startup splash hangs and eventually Ardour must be force-quit.

I have never submitted a backtrace before but will read the directions attempt to do so.
System Description
Attached Files: clint localhost opt Ardour.txt (33,745 bytes) 2023-03-31 16:36
https://tracker.ardour.org/file_download.php?file_id=4455&type=bug
clint localhost gdb attach.txt (79,297 bytes) 2023-03-31 18:07
https://tracker.ardour.org/file_download.php?file_id=4456&type=bug
clint73168 localhost gdb GNU.txt (92,593 bytes) 2023-04-01 19:23
https://tracker.ardour.org/file_download.php?file_id=4459&type=bug
Notes
(0027481)
cjs   
2023-03-18 22:08   
I did what the manual said about creating a backtrace but I guess this is not a crash, but rather some other state that I do not know the name of, where the DAW simply stops responding and the option to wait or force quit pops up on each Ardour window. So I guess with no crash, there is no way to generate a crash report.
(0027488)
paul   
2023-03-21 18:10   
(Last edited: 2023-03-21 18:10)
Actually, there is.

You need to use this command to get the PID of (hung/stopped) ardour: ps aux | grep ardour

Then start debugging as you normally would, but at the first gdb) prompt, type: attach PID

where PID is the PID (number) you determined

Then use: thread apply all bt

to get the backtrace
(0027504)
cjs   
2023-03-22 23:08   
Thanks for the further instructions, maybe I can get that done after this album, but for now I found that the VST2.x versions of the Analog Obsession plugins work properly with oversampling activated via Yabridge in Ardour 7.3.x, so I'll just replace the VST3 versions in my current sessions.
(0027519)
cjs   
2023-03-31 16:36   
I am trying to follow the directions but cannot get the PID unless Ardour is running, which I must initiate by typing run at the first prompt, thus not allowing me to attach PID at first prompt because the PID will not exist at first prompt. Here's what happened in my terminal window when I tried
(0027520)
paul   
2023-03-31 16:52   
Ah, misunderstanding here.

You will be operating in two terminals (or two tabs). One will be running Ardour. In the other, you will use the shell to get the PID, then start up gdb and use the PID there.
(0027521)
cjs   
2023-03-31 18:07   
Ok, here goes!
(0027522)
x42   
2023-03-31 23:27   
(Last edited: 2023-03-31 23:27)
I'm curious if the problem also exists on Windows (without all the yabridge threads)
(0027523)
cjs   
2023-04-01 03:52   
The only Windows rig I have runs 7 but the Analog Obsession plugins say they want 10 or higher, yet Ardour 7.3.164 worked anyway, only, well, when I clicked on oversampling or anything else on the LALA plugin, playback paused but resumed. I did not get the full-on seizure. I guess I should install Ardour 7.2 on Windows and see if it's trouble free like the Linux 7.2 version is for this situation.
(0027525)
cjs   
2023-04-01 19:23   
Here's another backtrace based on 7.3.168
(0027527)
x42   
2023-04-01 21:49   
Looks like a yabridge issue. The main realtime process thread is blocked in asio::read revc.

Thread "RT-main-0x7efd3" (ardour's realtime audio process)
 * holds the main engine-process mutex
 * holds the VST3 parameter/process mutex
 * and hangs/waits in libyabridge-vst3.so << THIS IS THE ISSUE

Thread "host-callbacks" (yabridge thread)
 * waits for the VST3 parameter/process mutex

Thread "ArdourGUI"
 * waits for the main engine-process lock
(0027528)
cjs   
2023-04-02 01:19   
Did this process change from 7.2 to 7.3? is this something I need to pester Robbert about?
(0027529)
x42   
2023-04-02 01:37   
Yes, VST3 host changed significantly in Ardour 7.3.

Aside from adding multi-out, various issues that yabridge worked around were fixed (eg. non const Vst::IParameterChanges).
This also included making processing and restartComponent mutually exclusive (unless restartComponent is called directly from the plugin's process). This seems to be pertinent here.

I already and I asked Robbert on IRC about this issue.
(0027530)
cjs   
2023-04-02 01:48   
That's good to know- thanks for the help with my probably extremely obscure problem!
(0028119)
cjs   
2023-09-27 02:23   
Anomaly persists in 8.0rc1.20
(0028123)
x42   
2023-09-29 09:01   
Very likely a yabridge issue
(0028437)
cjs   
2023-12-26 00:25   
Issue is fixed now with Yabridge 5.1.0 and Ardour 8.2.7.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9560 [ardour] bugs crash always 2023-11-30 15:34 2023-12-25 00:58
Reporter: M.F. Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Spectral analysis crashes Ardour
Description: when tryin Spectral Analys, Ardour just shutdown itself immediately.
Tags:
Steps To Reproduce:
Additional Information: AV Linux 21.2.1, 6.0.0-10.1-liquorix-amd64

Jack in use, Ardour-8.1.144-x86_64 and Ardour-8.1
System Description
Attached Files: ardour8 crash2 (119,022 bytes) 2023-11-30 16:26
https://tracker.ardour.org/file_download.php?file_id=4727&type=bug
Ardour8 crash1 (125,428 bytes) 2023-11-30 16:26
https://tracker.ardour.org/file_download.php?file_id=4728&type=bug
Screenshot 2023-11-30 at 17.34.59.png (141,426 bytes) 2023-11-30 16:35
https://tracker.ardour.org/file_download.php?file_id=4729&type=bug
png

Screenshot 2023-11-30 at 17.34.47.png (291,230 bytes) 2023-11-30 16:35
https://tracker.ardour.org/file_download.php?file_id=4730&type=bug
gdb.core.dump_2023-12-07 (115,302 bytes) 2023-12-07 10:38
https://tracker.ardour.org/file_download.php?file_id=4734&type=bug
crash.log (91,139 bytes) 2023-12-07 13:41
https://tracker.ardour.org/file_download.php?file_id=4735&type=bug
Notes
(0028375)
x42   
2023-11-30 16:00   
I cannot reproduce this. Spectral analysis works reliably here.

Does it happen with every session? Every time you try this?

Even with a new simple session (1 track, record a short region)? What Sample-rate do you use (not that it should make a difference).

Ideally a backtrace of the crash would be helpful: https://ardour.org/debugging_ardour
(0028376)
dspasic   
2023-11-30 16:26   
Hi, i managed to crash few times. Though Spectral Analysis works (it does not freeze or block Ardour.)
scenario:
1. open new project
2. import audio file (so i can analyze something)
3. do spectral analysis several times, and it will crash

MBPro M1 (Ventura)
please check logs. Thanks
(0028378)
x42   
2023-11-30 16:30   
Sadly those crash reports are not useful. Ardour Debug symbols are missing.

It might even be unrelated different issue. The Crash Log shows a macOS specific crash in openGL/Metal abstraction (which can't be present on Linux).
(0028379)
dspasic   
2023-11-30 16:35   
Hi Robin,
I just downloaded debug version (again) and it seems that it is really not a debug version.
Can you help? Thanks
(0028381)
x42   
2023-11-30 18:40   
@dspasic that setting is unrelated, it pertains to Ardour itself producing a stack-trace, not a debugger doing so.

Do you use "Show frequency power range" display option? If so, that could explain the issue
(0028385)
x42   
2023-12-03 15:23   
Does this still happen with Ardour 8.1.145 or later?
(0028390)
avard   
2023-12-07 10:38   
Chiming in,

- spectral analysis on selected region = OK
- spectral analysis on region = crash

Fedora fc38 (kernel 6.6.3, if that's useful) - Ardour8.1.0 (built using 8.1 and GCC version 13.2.1 20231011 (Red Hat 13.2.1-4)) - downloaded tar-ball from git

First time gdb w. ardour, please also guide to good ways to debug and provide crash-reports.
(0028391)
batinste   
2023-12-07 13:40   
- spectral analysis on selected region = ok
- spectral analysis on selected range = crash

Ardour 8.1.151-demo-dbg & linux mint 6.2.0-37-generic 00000380000047:0000022.04.1-Ubuntu SMP PREEMPT_DYNAMIC
(0028392)
batinste   
2023-12-07 13:41   
oops, forgot the log
(0028393)
x42   
2023-12-07 14:09   
That is helpful. Thanks. Not what I'd expected.

@paul are those over-reads caused by a TimeDomain mismatch?
(0028394)
paul   
2023-12-07 14:17   
@batinste how easily reproducible is this error?
(0028395)
batinste   
2023-12-07 14:52   
@paul i tried about 10 times and every range spectral analysis crashed ardour. Region spectral analysis is always ok, though.
(0028396)
x42   
2023-12-07 15:13   
FWIW, I cannot reproduce this at all.
(0028397)
x42   
2023-12-07 15:14   
@batinste do you use Audio Time or Music (Beat) Time (Session > Properties >Misc)?
(0028398)
batinste   
2023-12-07 15:39   
Ha, good catch : I used Music Time.
Setting this to Audio Time and analyzing the same range (same magnet settings) does not produce the crash and the analysis works.
Then i can select another range and analyze it correctly.
If i switch back to Music Time, i can analyze the same -still selected- range correctly too. If i then select another range, the analysis crashes.
(0028399)
avard   
2023-12-07 15:41   
same cure here :-)
(0028401)
x42   
2023-12-08 22:54   
OK. it's not a cure, but it can explain this.

Bar/Beat/Tick is resolution is more coarse than audio-sample-time. (e.g. with 120BPM @48kHz, one tick equals to 12.5 audio-samples)
It seems possible that the GUI requests more data from an audio-region for analysis than there is actually present in the file. :(
(0028406)
paul   
2023-12-12 00:48   
Nominally fixed in commit 3c687bfa9fd
(0028408)
colinf   
2023-12-12 13:19   
@paul: not pushed yet?

colinf@colinf-xps15:~/src/ardour/ardour$ git show 3c687bfa9fd
fatal: ambiguous argument '3c687bfa9fd': unknown revision or path not in the working tree.
(0028409)
paul   
2023-12-12 14:27   
It was pushed yesterday, about 15 hours ago.
(0028410)
colinf   
2023-12-12 15:01   
@paul: do you mean f184acfb?
(0028411)
paul   
2023-12-12 15:02   
No, I mean this:

-----

commit 3c687bfa9fd7a11eaf466e9daca893e4c259dc66
Author: Paul Davis <paul@linuxaudiosystems.com>
Date: Mon Dec 11 16:51:16 2023 -0700

    prevent crash in AudioPlaylist::write() due to lossy time domain convert

diff --git a/libs/ardour/audio_playlist.cc b/libs/ardour/audio_playlist.cc
index cfe011b0c9..d751152d4c 100644
--- a/libs/ardour/audio_playlist.cc
+++ b/libs/ardour/audio_playlist.cc
@@ -275,9 +275,15 @@ AudioPlaylist::read (Sample *buf, Sample *mixdown_buffer, float *gain_buffer, ti
 
         samplepos_t read_pos (i->range.start().samples());
         samplecnt_t read_cnt (i->range.start().distance (i->range.end()).samples());
- assert (start.distance (i->range.start()).samples() < scnt);
- assert (start.distance (i->range.start()).samples() + read_cnt <= scnt);
- samplecnt_t nread = i->region->read_at (buf + start.distance (i->range.start()).samples(), mixdown_buffer, gain_buffer, read_pos, read_c
nt, chan_n);
+ samplecnt_t soffset = start.distance (i->range.start()).samples();
+
+ assert (soffset < scnt);
+
+ if (soffset + read_cnt > scnt) {
+ read_cnt = scnt - soffset;
+ }
+ assert (soffset + read_cnt <= scnt);
+ samplecnt_t nread = i->region->read_at (buf + soffset, mixdown_buffer, gain_buffer, read_pos, read_cnt, chan_n);
         if (nread != read_cnt) {
             std::cerr << name() << " tried to read " << read_cnt << " from " << nread << " in " << i->region->name() << " using range "
                       << i->range.start() << " .. " << i->range.end() << " len " << i->range.length() << std::endl;
(0028412)
paul   
2023-12-12 15:03   
hmm. same commit contents

not sure what's going on there and off to a doctor's appt now
(0028413)
colinf   
2023-12-12 15:06   
Ah, weird, that's exactly the commit that's published as f184acfb. Anyway, thanks for fixing - I hit this a few times at the weekend.
(0028414)
paul   
2023-12-12 18:19   
i forgot that i had to rebase before pushing, hence the different commit hashes.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8768 [ardour] bugs minor always 2021-07-03 10:58 2023-12-22 12:31
Reporter: DaniDeSaro Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardor 6.8 does not close
Description: Since the last versions 'nightlies' (Ardor-6.7.288 or Ardor-6.7.302) I have seen that, opening a new session, and saving it even if you don't do anything in it, when you want to close the program to finish, it stays in the middle close without responding to further mouse events. The ArdorGUI process needs to be terminated in order to terminate Ardor.
I have done tests with other versions of Ardor installed on the same system: Both with Ardor5 and Ardor6.7.0, this does not happen, and the program ends correctly.
Attached log of qjack in case it was useful.
Tags:
Steps To Reproduce: 1. Login with QjackCtl.
2. Open Ardor2.8 and create a new session.
3. Save the session.
4. Try to close the program, activating the Ardor menu 'Exit'.
Additional Information: SO:Linux Mint Ulyssa
Kernel: 5.0.8-59-lowlatency
PC: Acer Aspire
RAM: 16GB
Soft for vst: yabridge + linvst
System Description
Attached Files: conf-inicial-qjack.png (94,176 bytes) 2021-07-03 10:58
https://tracker.ardour.org/file_download.php?file_id=4075&type=bug
png

cuelgue-ardour.png (61,573 bytes) 2021-07-03 10:58
https://tracker.ardour.org/file_download.php?file_id=4076&type=bug
png

mensajes-jack-bug-ardour.txt (114,940 bytes) 2021-07-03 10:58
https://tracker.ardour.org/file_download.php?file_id=4077&type=bug
backtrace.txt (17,971 bytes) 2022-02-26 22:46
https://tracker.ardour.org/file_download.php?file_id=4162&type=bug
ardour-backtrace_2022-05-18_17-00 (7,249 bytes) 2022-05-18 18:44
https://tracker.ardour.org/file_download.php?file_id=4188&type=bug
backtrace-2.txt (17,235 bytes) 2022-10-20 06:05
https://tracker.ardour.org/file_download.php?file_id=4235&type=bug
Notes
(0026026)
DaniDeSaro   
2021-07-03 12:03   
Important note: This bug does not happen in the Ardor6.8.0 release version, that version closes without problems. The bug only happens in the 'nigthlie' version of Ardor.
(0026036)
x42   
2021-07-07 04:11   
(Last edited: 2021-07-07 04:13)
Does it still happen with recent 6.8.xx nightlies? debug version?

If so. please run `Ardour6 --gdb` , then inside gdb:
run

then get arodur to hang. back on the gdb window: ctrl+c
this returns you to the gdb prompt, there call:
bt

and
thread apply all bt


this prints a backtrace where ardour hangs. see also https://ardour.org/debugging_ardour

(0026037)
DaniDeSaro   
2021-07-07 09:58   
As I said, this problem was fixed in version 6.8 release. That is why I have not continued to download 'nigthlies' versions. In order to be able to answer you, I just downloaded and installed version 6.8.83-x86_x64-gcc5 (it is not a debug version) and it seems that this failure no longer occurs. Therefore it has been a temporary bug that no longer gives problems. Consider this report more than anything informative.
Greetings, if I can help you here you have me, x42.
(0026038)
x42   
2021-07-07 11:30   
OK. I was asking because there is no obvious difference between 6.7.302 and 3.8 (really 3.7.305) that would explain the difference.
(0026041)
DaniDeSaro   
2021-07-08 12:28   
If no one else has reported it, it may be a product of my bad configuration, although I tried it on two different Mint linux systems and the same thing happened to me ...
(0026313)
niklasliebig   
2022-01-27 20:57   
I'm using Ardour6.5.0~ds0 (built using 6.5.0~ds0-1 and GCC version 10.2.1 20210110) and I'm having a similar (if not the same) problem with Debian 11.2 LXDE. However, it is not 100 percent reproducible. If I only open my project for a short time to play the song and make minor changes, it sometimes closes without any problems. The longer a recording session lasts and the more edits I make, the more likely it seems I'll have to kill Ardour to exit. It happens for both Jack and Alsa backend. Saving my project file works fine. I'm not very familiar with the debug mode described above, but I think I managed to capture the backtrace. I will insert i below. I hope this will help solve this problem and make Ardour more stable.

(gdb) bt
#0 __pthread_clockjoin_ex (threadid=140736697612032,
    thread_return=0x7fffffffc4c0, clockid=<optimized out>,
    abstime=<optimized out>, block=<optimized out>)
    at pthread_join_common.c:145
0000001 0x00007ffff3992150 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#2 0x00007ffff39732bc in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#3 0x00007ffff39746b5 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000004 0x00007ffff39951e1 in jack_client_close ()
   from /lib/x86_64-linux-gnu/libjack.so.0
0000005 0x00007fffe8aadad6 in ARDOUR::JackConnection::close() ()
   from /usr/lib/ardour6/backends/libjack_audiobackend.so
#6 0x00007fffe8ab2e60 in ARDOUR::JACKAudioBackend::stop() ()
   from /usr/lib/ardour6/backends/libjack_audiobackend.so
#7 0x00007ffff769a040 in ARDOUR::AudioEngine::stop(bool) ()
   from /usr/lib/ardour6/libardour.so.3
0000008 0x0000555555a40947 in ?? ()
0000009 0x00007ffff6e2df48 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000010 0x00007ffff6d830a2 in g_closure_invoke ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000011 0x00007ffff6d95602 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000012 0x00007ffff6d9b6cf in g_signal_emit_valist ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
0000013 0x00007ffff6d9bc3f in g_signal_emit ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000014 0x00007ffff684ea01 in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#15 0x00007ffff6d830a2 in g_closure_invoke ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000016 0x00007ffff6d950aa in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff6d9b6cf in g_signal_emit_valist ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000018 0x00007ffff6d9bc3f in g_signal_emit ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000019 0x00007ffff6a30d94 in gtk_widget_activate ()
   from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000020 0x00007ffff6924af5 in gtk_menu_shell_activate_item ()
   from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000021 0x00007ffff6924e09 in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000022 0x00007ffff69121ab in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000023 0x00007ffff6d830a2 in g_closure_invoke ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#24 0x00007ffff6d94e6e in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000025 0x00007ffff6d9b259 in g_signal_emit_valist ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000026 0x00007ffff6d9bc3f in g_signal_emit ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
0000027 0x00007ffff6a31fe4 in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000028 0x00007ffff69107d4 in gtk_propagate_event ()
   from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000029 0x00007ffff6910c4b in gtk_main_do_event ()
   from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000030 0x00007ffff677aafc in ?? () from /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
0000031 0x00007ffff6c91e6b in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000032 0x00007ffff6c92118 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000033 0x00007ffff6c9240b in g_main_loop_run ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000034 0x00007ffff690fb2a in gtk_main ()
   from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000035 0x00007ffff6fbea7b in Gtkmm2ext::UI::run(Receiver&) ()
   from /usr/lib/ardour6/libgtkmm2ext.so.0
0000036 0x0000555555a081f1 in main ()
(gdb) thread apply all bt

Thread 26 (Thread 0x7fffd0de3700 (LWP 1317) "audioengine"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff3993c42 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#2 0x00007ffff39769d5 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#3 0x00007ffff3975438 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000004 0x00007fffe8ab13d2 in ARDOUR::JACKAudioBackend::process_thread() () from /usr/lib/ardour6/backends/libjack_audiobackend.so
0000005 0x00007ffff39758eb in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#6 0x00007ffff3991dbc in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#7 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000008 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 25 (Thread 0x7fffd100d700 (LWP 1316) "audioengine"):
#0 __libc_read (nbytes=4, buf=0x7fffd100c7d0, fd=16) at ../sysdeps/unix/sysv/linux/read.c:26
0000001 __libc_read (fd=16, buf=0x7fffd100c7d0, nbytes=4) at ../sysdeps/unix/sysv/linux/read.c:24
#2 0x00007ffff3992fee in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#3 0x00007ffff399675d in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000004 0x00007ffff39965a2 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
--Type <RET> for more, q to quit, c to continue without paging--
0000005 0x00007ffff3991dbc in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#6 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 24 (Thread 0x7fffd3c0d700 (LWP 1306) "audioengine"):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x5555572a32c8) at ../sysdeps/nptl/futex-internal.h:186
0000001 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5555572a3270, cond=0x5555572a32a0) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=0x5555572a32a0, mutex=0x5555572a3270) at pthread_cond_wait.c:638
#3 0x00007ffff399287e in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000004 0x00007ffff3986d45 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000005 0x00007ffff3991dbc in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#6 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 15 (Thread 0x7fffd32cb700 (LWP 1284) "gdbus"):
#0 0x00007ffff560c3ff in __GI___poll (fds=0x555556a5a450, nfds=2, timeout=-1) a--Type <RET> for more, q to quit, c to continue without paging--
t ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff6c920ae in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff6c9240b in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff4b79a36 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
0000004 0x00007ffff6cbb0bd in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000005 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 14 (Thread 0x7fffd3aee700 (LWP 1283) "gmain"):
#0 0x00007ffff560c3ff in __GI___poll (fds=0x555556a4cc10, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff6c920ae in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff6c921cf in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff6c92221 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000004 0x00007ffff6cbb0bd in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000005 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
--Type <RET> for more, q to quit, c to continue without paging--

Thread 8 (Thread 0x7fffe93d9700 (LWP 1277) "DeviceList"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6ce334f in g_cond_wait () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff769bb45 in ARDOUR::AudioEngine::do_devicelist_update() () from /usr/lib/ardour6/libardour.so.3
#3 0x00007ffff6e1edb2 in ?? () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000004 0x00007ffff6cbb0bd in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000005 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7fffea2ca700 (LWP 1276) "EngineWatchdog"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6ce334f in g_cond_wait () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff769c6b7 in ARDOUR::AudioEngine::do_reset_backend() () from /usr/lib/ardour6/libardour.so.3
#3 0x00007ffff6e1edb2 in ?? () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000004 0x00007ffff6cbb0bd in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000005 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c--Type <RET> for more, q to quit, c to continue without paging--
:477
#6 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 5 (Thread 0x7fffeaffd700 (LWP 1274) "Analyzer"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6ce334f in g_cond_wait () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7659c5f in ARDOUR::Analyser::work() () from /usr/lib/ardour6/libardour.so.3
#3 0x00007ffff6e1edb2 in ?? () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000004 0x00007ffff6cbb0bd in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000005 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7fffeb7fe700 (LWP 1273) "PeakFileBuilder"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6ce334f in g_cond_wait () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7c6a28f in ?? () from /usr/lib/ardour6/libardour.so.3
#3 0x00007ffff6e1edb2 in ?? () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
--Type <RET> for more, q to quit, c to continue without paging--
0000004 0x00007ffff6cbb0bd in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000005 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fffebfff700 (LWP 1272) "PeakFileBuilder"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6ce334f in g_cond_wait () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7c6a28f in ?? () from /usr/lib/ardour6/libardour.so.3
#3 0x00007ffff6e1edb2 in ?? () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000004 0x00007ffff6cbb0bd in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000005 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7ffff0925700 (LWP 1271) "LXVSTEventLoop"):
#0 0x00007ffff55dec61 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7ffff0924780, rem=0x7ffff0924790) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
0000001 0x00007ffff55e4443 in __GI___nanosleep (requested_time=<optimized out>, rema--Type <RET> for more, q to quit, c to continue without paging--
ining=<optimized out>) at nanosleep.c:27
#2 0x00007ffff6cbcb4f in g_usleep () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00005555563978d6 in ?? ()
0000004 0x00007ffff5d52ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000005 0x00007ffff5616def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7ffff09bbcc0 (LWP 1267) "ArdourGUI"):
#0 __pthread_clockjoin_ex (threadid=140736697612032, thread_return=0x7fffffffc4c0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
0000001 0x00007ffff3992150 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#2 0x00007ffff39732bc in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#3 0x00007ffff39746b5 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000004 0x00007ffff39951e1 in jack_client_close () from /lib/x86_64-linux-gnu/libjack.so.0
0000005 0x00007fffe8aadad6 in ARDOUR::JackConnection::close() () from /usr/lib/ardour6/backends/libjack_audiobackend.so
#6 0x00007fffe8ab2e60 in ARDOUR::JACKAudioBackend::stop() () from /usr/lib/ardour6/backends/libjack_audiobackend.so
#7 0x00007ffff769a040 in ARDOUR::AudioEngine::stop(bool) () from /usr/lib/ardou--Type <RET> for more, q to quit, c to continue without paging--
r6/libardour.so.3
0000008 0x0000555555a40947 in ?? ()
0000009 0x00007ffff6e2df48 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000010 0x00007ffff6d830a2 in g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000011 0x00007ffff6d95602 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000012 0x00007ffff6d9b6cf in g_signal_emit_valist () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000013 0x00007ffff6d9bc3f in g_signal_emit () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000014 0x00007ffff684ea01 in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#15 0x00007ffff6d830a2 in g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000016 0x00007ffff6d950aa in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff6d9b6cf in g_signal_emit_valist () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000018 0x00007ffff6d9bc3f in g_signal_emit () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000019 0x00007ffff6a30d94 in gtk_widget_activate () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000020 0x00007ffff6924af5 in gtk_menu_shell_activate_item () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
0000021 0x00007ffff6924e09 in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000022 0x00007ffff69121ab in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000023 0x00007ffff6d830a2 in g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#24 0x00007ffff6d94e6e in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000025 0x00007ffff6d9b259 in g_signal_emit_valist () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000026 0x00007ffff6d9bc3f in g_signal_emit () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000027 0x00007ffff6a31fe4 in ?? () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000028 0x00007ffff69107d4 in gtk_propagate_event () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000029 0x00007ffff6910c4b in gtk_main_do_event () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000030 0x00007ffff677aafc in ?? () from /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
0000031 0x00007ffff6c91e6b in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000032 0x00007ffff6c92118 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000033 0x00007ffff6c9240b in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000034 0x00007ffff690fb2a in gtk_main () from /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000035 0x00007ffff6fbea7b in Gtkmm2ext::UI::run(Receiver&) () from /usr/lib/ardour6--Type <RET> for more, q to quit, c to continue without paging--
/libgtkmm2ext.so.0
0000036 0x0000555555a081f1 in main ()
(gdb)
(0026314)
x42   
2022-01-27 21:02   
This specific backtrace shows that Ardour waits for JACK to close the connection. -- In any case could try with Ardour 6.9.0?
(0026319)
niklasliebig   
2022-01-29 15:46   
Currently I have to stick with the version from the official Debian sources. However, I'm colaborating with another musician who uses Ardor 6.9 on Linux Mint, so we are exchanging the same project file. He always runs the Alsa backend and actually told me that Ardor also freezes when closing. And again no problems with saving the file. Maybe something to do with the project file anyway? Any incompatibility issues between 6.5 and 6.9?
(0026337)
niklasliebig   
2022-02-26 22:46   
After completing my current project, I switched to Ardor 6.9.0 "After Bach" (rev 6.9) Intel 64-bit. Unfortunately, it's the same as for my fellow musician. Ardour doesn't close sometimes and it affects both: Jack and Alsa back end. I attached another backtrace when running Ardour with Alsa back end.
(0026447)
s0600204   
2022-05-18 18:44   
I appear to be having the same problem as @niklasliebig: when attempting to close Ardour the UI freezes and the application has to be force-closed. The backtrace (see attached) is also similar to that given above in note 0008768:0026313.

My symptoms differ in that, having tried running with both the JACK and ALSA backends, closing a session using the ALSA backend does not appear (on the surface) to be problematic.

With the JACK backend, it might be worth noting that at the point that Ardour freezes, QJackCtl's "Connect" dialog shows that Ardour's web of connections has been reduced to two ports: `physical_audio_input_monitor_enable` and `physical_midi_input_monitor_enable` (in the "Audio" and "MIDI" tabs respectively). Neither remain connected to anything.

Further experimentation shows that it doesn't matter whether JACK is using the internal soundcard or an external USB soundcard.

With the ALSA backend, although the UI doesn't freeze when closing (for more than a second), when running Ardour from the terminal the very last line printed is: `Process is still running! trying SIGKILL`. It is unclear what process this is referring to, or if this is an expected message. There isn't any apparent crash, and thus no backtrace.

----

System : ArchLinux
`ardour6 -v` : Ardour6.9.0 (built using 6.9 and GCC version 11.2.0)
(0026652)
flirora   
2022-10-20 06:05   
I can also reproduce this issue with Ardour7.0.51 (built using 7.0-51-g73ab0d3472 and GCC version 12.2.0), on the JACK backend connected to PipeWire.
(0026659)
x42   
2022-10-20 22:39   
> I can also reproduce this issue with Ardour7.0.51 (built using 7.0-51-g73ab0d3472 and GCC version 12.2.0), on the JACK backend connected to PipeWire.

That backtrace shows a classic deadlock

Ardour takes the "process lock" and asks pipewire to terminate ardour's jack connection (jack_client close),
At the same time pipewire calls into Ardour using a different thread and tries to change the buffersize (jack_buffersize callback).
Since buffersize changes cannot happen while processing. This also requires the process-lock.

Now Pipewire apparently cannot handle the "close request" while it is waiting for the buffersize request. -- Anyway this is clearly another pipewire threading bug.

--

The original issue with libjack hanging in __pthread_clockjoin_ex (as shown in https://tracker.ardour.org/view.php?id=8768#c26313) was a bug in glibc/pthread: https://sourceware.org/bugzilla/show_bug.cgi?id=29214
(0026662)
flirora   
2022-10-21 05:21   
Thanks for the info.

I’ve reported the issue to PipeWire: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2781

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9582 [ardour] bugs minor always 2023-12-19 19:10 2023-12-20 15:59
Reporter: Mal Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: Mixbus 9.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Halion Sonic scan failed
Description: Mixbus 8.2, Mixbus 9.2, and Ardour 8.2 will not scan Halion Sonic.
Tags: Halion
Steps To Reproduce: Install Halion Sonic, scan for plugins
Additional Information: I uninstalled and reinstalled both versions of Mixbus. Adour was a new installation. I have extended the Scan Time Out to the maximum. Both caches and Ignorelists were first cleared before scanning. The Standalone version of Halion works fine, as does Cakewalk and Audacity.

VST3 module-path 'C:\Program Files\Common Files\VST3\Steinberg\HALion Sonic.vst3\Contents\x86_64-win\HALion Sonic.vst3'
[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinberg\HALion Sonic.vst3
[Info]: FactoryInfo: 'Steinberg Media Technologies' 'http://www.steinberg.net' 'mailto:info@steinberg.de'
[Info]: Class count: 4
[Info]: Class: 0 'HALion Sonic' 'Audio Module Class'
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 0
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 0
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 16
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: - bus: 1 count: 2
[Info]: VST3: - bus: 2 count: 2
[Info]: VST3: - bus: 3 count: 2
[Info]: VST3: - bus: 4 count: 2
[Info]: VST3: - bus: 5 count: 2
[Info]: VST3: - bus: 6 count: 2
[Info]: VST3: - bus: 7 count: 2
[Info]: VST3: - bus: 8 count: 2
[Info]: VST3: - bus: 9 count: 2
[Info]: VST3: - bus: 10 count: 2
[Info]: VST3: - bus: 11 count: 2
[Info]: VST3: - bus: 12 count: 2
[Info]: VST3: - bus: 13 count: 2
[Info]: VST3: - bus: 14 count: 2
[Info]: VST3: - bus: 15 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 16
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 0
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Skipping non-effect class: Preset Compatibility Class
[Info]: Skipping non-effect class: Preset Version Class
[Info]: Found Plugin: HALion Sonic
Scan Failed.
System Description Windows 11
Attached Files:
Notes
(0028430)
Mal   
2023-12-19 21:44   
I have read 0009273 and it does not seem to me to be the same problem. The scan is not hanging up, its finishing with a scan failed error message. I've tried deleting the cache and the blacklist and the problem is still there.
(0028433)
Mal   
2023-12-20 15:59   
Should I be adding notes to this issue or should I be adding to 0009273?

In Mark Knecht's final note it looks like the problem is still there. "1) The laptop has Mixbus32C-7, Mixbus32C-9 and Ardour-7.3.0. On that machine all 3 versions of the programs cause the error for the sforzando VST3 which is, on this machine, the only plugin that uses this new Steinberg directory structure. This machine has some Native Instrument plugins. They don't use the structure and they are fine."

It looks like the solution to the "scan not finishing" problem that Mark Knecht came up with was to let the scan program run for 4 minutes. I used the scan program and let it run for over 30 minutes and it still did not finish and did not create a cache file.

c:\Program Files\Ardour8\bin>ardour-vst3-scanner.exe -v-f "C:\Program Files\Common Files\VST3\Steinberg\HALion Sonic.vst3"

c:\Program Files\Ardour8\bin>[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinberg\HALion Sonic.vst3
[Info]: FactoryInfo: 'Steinberg Media Technologies' 'http://www.steinberg.net' 'mailto:info@steinberg.de'
[Info]: Class count: 4
[Info]: Class: 0 'HALion Sonic' 'Audio Module Class'
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 0
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 0
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 16
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: - bus: 1 count: 2
[Info]: VST3: - bus: 2 count: 2
[Info]: VST3: - bus: 3 count: 2
[Info]: VST3: - bus: 4 count: 2
[Info]: VST3: - bus: 5 count: 2
[Info]: VST3: - bus: 6 count: 2
[Info]: VST3: - bus: 7 count: 2
[Info]: VST3: - bus: 8 count: 2
[Info]: VST3: - bus: 9 count: 2
[Info]: VST3: - bus: 10 count: 2
[Info]: VST3: - bus: 11 count: 2
[Info]: VST3: - bus: 12 count: 2
[Info]: VST3: - bus: 13 count: 2
[Info]: VST3: - bus: 14 count: 2
[Info]: VST3: - bus: 15 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 16
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 0
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Skipping non-effect class: Preset Compatibility Class
[Info]: Skipping non-effect class: Preset Version Class
[Info]: Found Plugin: HALion Sonic

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9579 [ardour] bugs minor always 2023-12-19 09:20 2023-12-19 22:41
Reporter: joachim Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Drawing new notes in the piano roll triggers multiple note on/off events
Description: When drawing new notes with the mouse in the piano roll, more than one note on/off event is generated.
This is easy to hear when programming note sequences for a synth playing a simple waveform rich in harmonics.
I discovered this with the SurgeXT synthesizer set to the default "Init Saw" patch.
Imagine you do melody first and sound design after.
Tags: Midi, pianoroll
Steps To Reproduce: Start with an empty session, set to musical time.

1. Add a MIDI track and choose the SurgeXT synthesizer. (I used the VST3 version)
2. Add the ACE MIDI Monitor to the same track.
3. Create a new region to Draw notes in.
4. Draw one note.

Expected result:
One note off event followed by one note on event

Actual result:
Two note on events followed by four note off events.
Additional Information: You can confirm this behavour is happening outside of Ardour using The Drumstick MIDI monitor by feeding it with the MIDI out port for the SurgeXT track.

1. Install Drumstick MIDI Monitor.
2. Launch Drumstick MIDI Monitor, it starts up in recording mode by default.
3. Connect the "SurgeXT/midi_out 1" port to the input of "Kmidimon" port in your patchbay. (I use qpwgraph)
4. Draw one note in the piano roll.

Ardour version: 8,2 official release "Tracks and Traces" Intel 64-bit - debug
Ardour launched from Konsole, with the "-n" flag.
OS: Arch Linux
System Description
Attached Files: Screenshot_20231219_095856.png (66,376 bytes) 2023-12-19 09:20
https://tracker.ardour.org/file_download.php?file_id=4745&type=bug
png

Screenshot_20231219_100457.png (189,137 bytes) 2023-12-19 09:20
https://tracker.ardour.org/file_download.php?file_id=4746&type=bug
png
Notes
(0028432)
paul   
2023-12-19 22:41   
for us to take further action with this, you would need to show it affects things other than a post-Surge XT situation.

I just tried it with the builtin GM synth and there is no doubled note in the MIDI monitor placed after it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9578 [ardour] bugs minor always 2023-12-19 07:24 2023-12-19 22:17
Reporter: surfinspots Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Change tempo doesn't work
Description: Changing the tempo of the added sample doesn't work in 8.1 and 8.2.
It doesn't matter if the file is wave or flac ... both don't work.
Tags:
Steps To Reproduce: - Open a new session 48 khz, 24 bit
- dag'n'drop the added sample into Ardour to create a new track
- press T and than shrink or grow the sample


Additional Information:
System Description
Attached Files:
Notes
(0028427)
surfinspots   
2023-12-19 07:27   
Additional info: It seems that with 120 bpm set shrinking the sample to one bar seem to work
(0028429)
surfinspots   
2023-12-19 19:00   
Is only a problem if I build Ardour from source or use the Debian provided versions but does not happen with the official build
(0028431)
paul   
2023-12-19 22:17   
not an issue with ardour.org builds.

maybe an issue with the version of librubberband used on some distros, but unclear.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9273 [ardour] bugs crash always 2023-03-08 00:50 2023-12-19 19:52
Reporter: Mark Knecht Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour/Mixbus32C VST scan hangs on HALion 7, DAW Crashes - but HALion works after editing blacklist file
Description: I am resubmitting this report in a shortened version. I just spent 30 minutes typing in a detailed report only to have the submission fail due to some sort of time out in Mantis.

Using the 30-day Halion 7 demo the stand alone version works fine. However Ardour 7.2 from the subscription service and both Mixbus32C-7.2 and Mixbus32C-8.2 hang and crash during the plugin scan in the Plugin Manager window.

It appears that all the files necessary to use HALion 7 are created but the vst3_x64_blacklist.text file has it listed so it's not selectable as a plugin. However removing it from the blacklist file let's the DAW use it and it works fine. No crashes at all. All features work fine.
Tags: crash, VST3
Steps To Reproduce: 1) Install HALion 7 demo file

2) Scan for new plugins in any of the 3 versions of the DAW listed above.
Additional Information: I will attempt to attach some files after this report is submitted.
System Description
Attached Files: ed88f2b4c7d4b3ff3583533ad8c95e8e16d6bb52.v3i (587 bytes) 2023-03-08 00:52
https://tracker.ardour.org/file_download.php?file_id=4435&type=bug
vst3_x64_blacklist.txt (93 bytes) 2023-03-08 00:53
https://tracker.ardour.org/file_download.php?file_id=4436&type=bug
All_VSTS.txt (3,094 bytes) 2023-03-11 23:52
https://tracker.ardour.org/file_download.php?file_id=4437&type=bug
vst3_x64_blacklist-2.txt (93 bytes) 2023-03-12 14:19
https://tracker.ardour.org/file_download.php?file_id=4439&type=bug
ed88f2b4c7d4b3ff3583533ad8c95e8e16d6bb52-2.v3i (587 bytes) 2023-03-12 14:19
https://tracker.ardour.org/file_download.php?file_id=4440&type=bug
Mixbus32C-8 error.png (21,165 bytes) 2023-03-22 18:32
https://tracker.ardour.org/file_download.php?file_id=4447&type=bug
png

HALion-vst3-scan.png (124,872 bytes) 2023-04-04 21:47
https://tracker.ardour.org/file_download.php?file_id=4472&type=bug
png
Notes
(0027436)
Mark Knecht   
2023-03-08 00:52   
In all 3 DAW versions an XML file is created for HALion 7. The file is attached.
(0027437)
Mark Knecht   
2023-03-08 00:53   
The blacklist file that was created is attached. Removing the HALion entry allows all 3 versions of the DAW to use HALion 7
(0027438)
x42   
2023-03-08 01:01   
This is odd. Ardour launches an external tool to scan the plugin to prevent crashes. The plugin scanner may crash, but it should not be able to take the Ardour down.
(0027439)
Mark Knecht   
2023-03-08 13:35   
OK, so if Ardour launches the scanner and I'm watching the progress bar I see it going back and forth, it comes to a point where the progress bar just stops moving. At that point Ardour is waiting but the answer doesn't come from the scanning app. The problem is the buttons to cancel the scan don't work and everything is hung. Ardour isn't 'taken down', it's just hung waiting. I click the upper right window 'X'' to close Ardour and everything in the application goes kind of blurry white and the program stops.

Keep in mind that it appears the external tool appears to have worked because the XML file and the blacklist entry are created. It seems more like it failed at the very end of whatever process it's using to return a response to Ardour.

Is the external plugin scan tool something I can run at the command line and provide feedback?
(0027440)
x42   
2023-03-09 00:32   
> Is the external plugin scan tool something I can run at the command line and provide feedback?

Yes, with the official binary. on Linux
LD_LIBRARY_PATH=/opt/Ardour-7.2.0/lib/ /opt/Ardour-7.2.0/lib/ardour-vst3-scanner -vf ~/.vst3/Surge\ XT.vst3


On Windows open a cmd.exe terminal, cd C:\Program Files\Ardour7\bin\
and run ardour-vst3-scanner.exe C:\..path-to-the...\plugin.vst3
(0027441)
Mark Knecht   
2023-03-09 03:59   
Thanks for clear directions. The scanner returns nothing for HALion 7. It does return results for other plugins.

C:\Program Files\Ardour7\bin>ardour-vst3-scanner.exe "c:\Program Files\Common Files\VST3\Harrison\AVA\AVA-BF_64bit.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\Harrison\AVA\AVA-BF_64bit.vst3
[Info]: Found Plugin: AVA Bass Flow
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\f3d9791b16e4996acc257552df742a1576913bcc.v3i

C:\Program Files\Ardour7\bin>ardour-vst3-scanner.exe "c:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3

C:\Program Files\Ardour7\bin>


I don't know if it's valid to do this with a VST3 that's actually licensed under Windows but I copied the HALion 7.vst3 file to another directory where MiniMonsta2 exists. MiniMonsta2 works, the HALion7 copy does not work:

C:\Program Files\Ardour7\bin>ardour-vst3-scanner.exe "c:\Program Files\Common Files\VST3\Minimonsta2.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\Minimonsta2.vst3
[Info]: Found Plugin: Minimonsta2
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\a0c47334ba3b8e0d9e562d42b330986dab8bebfe.v3i

C:\Program Files\Ardour7\bin>ardour-vst3-scanner.exe "c:\Program Files\Common Files\VST3\HALion7Copy.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\HALion7Copy.vst3
Cannot load VST3 module: 'c:\Program Files\Common Files\VST3\HALion7Copy.vst3'

C:\Program Files\Ardour7\bin>
(0027442)
Mark Knecht   
2023-03-09 04:01   
C:\Program Files\Ardour7\bin>dir "C:\Program Files\Common Files\VST3
 Volume in drive C has no label.
 Volume Serial Number is E8DF-F3F4

 Directory of C:\Program Files\Common Files\VST3

03/08/2023 08:56 PM <DIR> .
03/08/2023 08:56 PM <DIR> ..
01/31/2023 10:12 AM 106,967,064 HALion7Copy.vst3
06/15/2022 01:08 PM <DIR> Harrison
02/21/2023 01:39 PM 11,860,480 Minimonsta2.vst3
03/06/2023 11:41 AM <DIR> Scaler2
02/26/2023 01:12 PM <DIR> sforzando
03/06/2023 01:18 PM <DIR> Steinberg
               2 File(s) 118,827,544 bytes
               6 Dir(s) 816,342,151,168 bytes free

C:\Program Files\Ardour7\bin>
(0027443)
Mark Knecht   
2023-03-11 16:43   
A little more info showing ardour-vst3-scanner working with Scaler2 but failing to do anything with Halion 7.

C:\Program Files\Ardour7\bin>ardour-vst3-scanner -v "c:\Program Files\Common Files\VST3\Scaler2\Scaler2.vst3

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\Scaler2\Scaler2.vst3
[Info]: FactoryInfo: 'Plugin Boutique' 'http://www.pluginboutique.com/' ''
[Info]: Class count: 2
[Info]: Class: 0 'Scaler 2' 'Audio Module Class'
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 1
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 1
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 16
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Found Plugin: Scaler 2
[Info]: Touch cachefile: set mtime = 1678552461 (2023-03-11 09:34:21), plugin mtime = 1675183798 (2023-01-31 09:49:58)
        <VST3Cache version="2" bundle="c:\Program Files\Common Files\VST3\Scaler2\Scaler2.vst3" module="c:\Program Files\Common Files\VST3\Scaler2\Scaler2.vst3">
          <VST3Info uid="ABCDEF019182FAEB654D616953636C32" name="Scaler 2" vendor="Plugin Boutique" category="Instrument" version="2.7.3" sdk-version="VST 3.7.2" url="http://www.pluginboutique.com/" email="" n_inputs="2" n_outputs="2" n_aux_inputs="0" n_aux_outputs="0" n_midi_inputs="1" n_midi_outputs="1">
          </VST3Info>
        </VST3Cache>
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\7aecbfdc3bac602537b65d5e1b390c993ba29584.v3i

C:\Program Files\Ardour7\bin>ardour-vst3-scanner -v "c:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3

C:\Program Files\Ardour7\bin>
(0027444)
Mark Knecht   
2023-03-11 16:46   
Possibly ardour-vst3-scanner doesn't like (DOT)vst3 in the path name?

Here I show the sforzando vst3 being scanned correctly when the directory is just sforzando, but failing to do anything when the directory is renamed sforzando.vst3 like the HALion install did with its vst3


C:\Program Files\Ardour7\bin>ardour-vst3-scanner -v "c:\Program Files\Common Files\VST3\sforzando\Contents\x86_64-win\sforzando.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\sforzando\Contents\x86_64-win\sforzando.vst3
[Info]: FactoryInfo: 'Plogue Art et Technologie, Inc' 'https://www.plogue.com' 'mailto:info@plogue.com'
[Info]: Class count: 2
[Info]: Class: 0 'sforzando' 'Audio Module Class'
valid signature detected for C:\Program Files\Plogue\Aria\aria_x64.dll
Engine path:C:\Program Files\Plogue\Aria\aria_x64.dll
queried details:ARIA Engine v1.973 (Win x64)
**ARIA_ENGINE_INFO**
1973
1973
ARIA Engine v1.973 (Win x64)
productName:sforzando
vendorName :Plogue Art et Technologie, Inc
productId:1014
slots:1
supportURL:https://www.plogue.com
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 0
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 0
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 1
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 0
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Found Plugin: sforzando
[Info]: Touch cachefile: set mtime = 1678552911 (2023-03-11 09:41:51), plugin mtime = 1667581110 (2022-11-04 09:58:30)
        <VST3Cache version="2" bundle="c:\Program Files\Common Files\VST3\sforzando\Contents\x86_64-win\sforzando.vst3" module="c:\Program Files\Common Files\VST3\sforzando\Contents\x86_64-win\sforzando.vst3">
          <VST3Info uid="5C5CA79682FC437AB6539BA204BAB349" name="sforzando" vendor="Plogue Art et Technologie, Inc" category="Instrument" version="2.1.0.5" sdk-version="VST 3.7.6" url="https://www.plogue.com" email="mailto:info@plogue.com" n_inputs="0" n_outputs="2" n_aux_inputs="0" n_aux_outputs="0" n_midi_inputs="1" n_midi_outputs="0">
          </VST3Info>
        </VST3Cache>
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\79d9aed65a1068beacdbfdb4b47a474ae39825ee.v3i

C:\Program Files\Ardour7\bin>ardour-vst3-scanner -v "c:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3

C:\Program Files\Ardour7\bin>
(0027445)
Mark Knecht   
2023-03-11 16:56   
And finally, here is the scanner working with HALion 7 when the ".vst3" is removed from the directory name:

C:\Program Files\Ardour7\bin>ardour-vst3-scanner -v "c:\Program Files\Common Files\VST3\Steinberg\HALion 7\Contents\x86_64-win\HALion 7.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\Steinberg\HALion 7\Contents\x86_64-win\HALion 7.vst3
[Info]: FactoryInfo: 'Steinberg Media Technologies' 'http://www.steinberg.net' 'mailto:info@steinberg.de'
[Info]: Class count: 4
[Info]: Class: 0 'HALion 7' 'Audio Module Class'
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 1
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 33
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: - bus: 1 count: 2
[Info]: VST3: - bus: 2 count: 2
[Info]: VST3: - bus: 3 count: 2
[Info]: VST3: - bus: 4 count: 2
[Info]: VST3: - bus: 5 count: 2
[Info]: VST3: - bus: 6 count: 2
[Info]: VST3: - bus: 7 count: 2
[Info]: VST3: - bus: 8 count: 2
[Info]: VST3: - bus: 9 count: 2
[Info]: VST3: - bus: 10 count: 2
[Info]: VST3: - bus: 11 count: 2
[Info]: VST3: - bus: 12 count: 2
[Info]: VST3: - bus: 13 count: 2
[Info]: VST3: - bus: 14 count: 2
[Info]: VST3: - bus: 15 count: 2
[Info]: VST3: - bus: 16 count: 2
[Info]: VST3: - bus: 17 count: 2
[Info]: VST3: - bus: 18 count: 2
[Info]: VST3: - bus: 19 count: 2
[Info]: VST3: - bus: 20 count: 2
[Info]: VST3: - bus: 21 count: 2
[Info]: VST3: - bus: 22 count: 2
[Info]: VST3: - bus: 23 count: 2
[Info]: VST3: - bus: 24 count: 2
[Info]: VST3: - bus: 25 count: 2
[Info]: VST3: - bus: 26 count: 2
[Info]: VST3: - bus: 27 count: 2
[Info]: VST3: - bus: 28 count: 2
[Info]: VST3: - bus: 29 count: 2
[Info]: VST3: - bus: 30 count: 2
[Info]: VST3: - bus: 31 count: 2
[Info]: VST3: - bus: 32 count: 6
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 33
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 4
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 0
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Skipping non-effect class: Preset Compatibility Class
[Info]: Skipping non-effect class: Preset Version Class
[Info]: Found Plugin: HALion 7
[Info]: Touch cachefile: set mtime = 1678553721 (2023-03-11 09:55:21), plugin mtime = 1675185166 (2023-01-31 10:12:46)
        <VST3Cache version="2" bundle="c:\Program Files\Common Files\VST3\Steinberg\HALion 7\Contents\x86_64-win\HALion 7.vst3" module="c:\Program Files\Common Files\VST3\Steinberg\HALion 7\Contents\x86_64-win\HALion 7.vst3">
          <VST3Info uid="3B63D74130B34AE397AF92A9659137D5" name="HALion 7" vendor="Steinberg Media Technologies" category="Instrument|Sampler" version="7.0.0" sdk-version="VST 3.7.5" url="http://www.steinberg.net" email="mailto:info@steinberg.de" n_inputs="0" n_outputs="70" n_aux_inputs="2" n_aux_outputs="0" n_midi_inputs="1" n_midi_outputs="0">
          </VST3Info>
        </VST3Cache>
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\0fc720aed6787b66171763b0e87f86b731d0de3f.v3i

C:\Program Files\Ardour7\bin>
(0027446)
Mark Knecht   
2023-03-11 17:02   
Please note that I was pointed in this direction by Nathan @ Mixbus Support when he gave me this pointer:

https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Locations+Format/Plugin+Format.html

which says the directories are supposed to have the NAME.vst3/Contents format.

This note appears under the Windows section:

Note
In previous SDKs, the VST 3 plug-in was defined as a single dll file with the .vst3 extension. This is deprecated since VST 3.6.10
(0027447)
x42   
2023-03-11 22:33   
Ardour does support both. a single [dll] .vst3 file as well as the bunle-structure MyPlugin.vst3/Contents/x86_64-win/MyPlugin.vst3

Your change make Ardour fall back to assume the old version: traverse into sub-directories without .vst3 suffix, until a .vst3 file or folder is found. After your change a .vst3 file is found and loaded as dll.
It's a neat workaround you found.

However there is indeed an oddity. The specs [1] read "MyPlugin.vst3/Contents/x86_64-win/MyPlugin.vst3" is a **folder** containing the plugin dll.
In many cases it's not a folder by a dll.

Anyway to fix this, before you renamed the bundle dir:
Is C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3 a file or a directory, and if it is a directory, what file is contained therein?



[1] https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Locations+Format/Plugin+Format.html#for-the-windows-platform
(0027448)
Mark Knecht   
2023-03-11 22:46   
All of these are directories: Steinberg\HALion 7.vst3\Contents\x86_64-win

The final HALion 7.vst3 is the actual dll.

And I'm sure you understand but but for clarity the change I made by hand was renaming the HALion 7.vst3 directory just under Steinberg.

If this is real I'm sure you can probably take an existing VST3.dll file and create directories that do what I think the spec says and create the problem. If not maybe I'm on the wrong track.
(0027449)
Mark Knecht   
2023-03-11 22:54   
I agree, it is different than before. In this path

C:\Program Files\Ardour7\bin>ardour-vst3-scanner.exe "c:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3"

the last HALion 7.vst3 is the executable. It does not have a ".dll" at the end.

I'm currently in Ubuntu. I'll double check in Windows but I'm pretty sure that's the way it works.
(0027450)
Mark Knecht   
2023-03-11 23:00   
Here's an actual directory listing:

Microsoft Windows [Version 10.0.19045.2604]
(c) Microsoft Corporation. All rights reserved.

C:\Users\Titan-R7>cd "C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win"

C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win>dir
 Volume in drive C has no label.
 Volume Serial Number is E8DF-F3F4

 Directory of C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win

03/08/2023 09:02 PM <DIR> .
03/08/2023 09:02 PM <DIR> ..
01/31/2023 10:12 AM 106,967,064 HALion 7.vst3
01/31/2023 10:12 AM 856,576 Rex Shared Library.dll
01/31/2023 10:12 AM 136,088 WebView2Loader.dll
               3 File(s) 107,959,728 bytes
               2 Dir(s) 816,802,988,032 bytes free

C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win>
(0027451)
x42   
2023-03-11 23:04   
Odd. this should work as-is, then. Ardour should load

HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3 as DLL according to

https://github.com/Ardour/ardour/blob/master/libs/ardour/vst3_scan.cc#L315-L316
(0027452)
x42   
2023-03-11 23:18   
> And I'm sure you understand but but for clarity the change I made by hand was renaming the HALion 7.vst3 directory just under Steinberg.

Yes. As described above, that works around the issue.

Thanks for the info, I'll investigate why this fails, currently I cannot recreate this however. It seems in your above sfz example you have also removed the .vst suffix from sfzorando.vst3 bundle

Testing the same here. note that the verbose output below has

 bundle="C:\Program Files\Common Files\VST3\sforzando.vst3"
 module="C:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3"

C:\Users\rgareus>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -fv "C:\Program Files\Common Files\VST3\sforzando.vst3"

[Info]: Scanning: C:\Program Files\Common Files\VST3\sforzando.vst3
[Info]: Found cache file: 'C:\Users\rgareus\AppData\Local\Ardour7\cache\vst\5e934701448d7ce1dd0ef71f2815b950bccb2a85.v3i'
[Info]: Cache file timestamp is valid.
[Info]: Cache file is valid and up-to-date.
[Info]: FactoryInfo: 'Plogue Art et Technologie, Inc' 'https://www.plogue.com' ' mailto:info@plogue.com'
[Info]: Class count: 2
[Info]: Class: 0 'sforzando' 'Audio Module Class' valid signature detected for C:\Program Files\Plogue\Aria\aria_x64.dll
Engine path:C:\Program Files\Plogue\Aria\aria_x64.dll
queried details:ARIA Engine v1.967 (Win x64)
**ARIA_ENGINE_INFO**
1967
1967
ARIA Engine v1.967 (Win x64)
productName:sforzando
vendorName :Plogue Art et Technologie, Inc
productId:1014
slots:1
supportURL:http://www.plogue.com
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 0
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 0
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 1
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 0
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Found Plugin: sforzando
[Info]: Touch cachefile: set mtime = 1678576322 (2023-03-12 00:12:02), plugin mtime = 1589295654 (2020-05-12 17:00:54)
        <VST3Cache version="2" bundle="C:\Program Files\Common Files\VST3\sforzando.vst3" module="C:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3">
          <VST3Info uid="5C5CA79682FC437AB6539BA204BAB349" name="sforzando" vendor="Plogue Art et Technologie, Inc" category="Instrument" version="2.0.6.6" sdk-version="VST 3.6.12" url="https://www.plogue.com" email="mailto:info@plogue.com" n_inputs="0" n_outputs="2" n_aux_inputs="0" n_aux_outputs="0" n_midi_inputs="1"  n_midi_outputs="0">
          </VST3Info>
        </VST3Cache>
[Info]: Saved VST3 plugin cache to C:\Users\rgareus\AppData\Local\Ardour7\cache\vst\5e934701448d7ce1dd0ef71f2815b950bccb2a85.v3i
(0027453)
Mark Knecht   
2023-03-11 23:29   
Unless I've messed up something I think the only thing I changed what the directory name. On my machine I have this installed:

C:\Program Files\Common Files\VST3>dir
 Volume in drive C has no label.
 Volume Serial Number is E8DF-F3F4

 Directory of C:\Program Files\Common Files\VST3

03/11/2023 10:09 AM <DIR> .
03/11/2023 10:09 AM <DIR> ..
03/11/2023 10:09 AM <DIR> Cherry Audio
06/15/2022 01:08 PM <DIR> Harrison
02/21/2023 01:39 PM 11,860,480 Minimonsta2.vst3
03/06/2023 11:41 AM <DIR> Scaler2
02/26/2023 01:12 PM <DIR> sforzando
03/11/2023 10:00 AM <DIR> Steinberg
               1 File(s) 11,860,480 bytes
               7 Dir(s) 816,514,883,584 bytes free

C:\Program Files\Common Files\VST3>

In the case of sforzando the directory isn't called sforzando.vst3, so the current code finds the vst3 file in its Contents directory:

C:\Program Files\Common Files\VST3>dir sforzando
 Volume in drive C has no label.
 Volume Serial Number is E8DF-F3F4

 Directory of C:\Program Files\Common Files\VST3\sforzando

02/26/2023 01:12 PM <DIR> .
02/26/2023 01:12 PM <DIR> ..
02/26/2023 01:12 PM <DIR> Contents
               0 File(s) 0 bytes
               3 Dir(s) 816,514,113,536 bytes free

C:\Program Files\Common Files\VST3>

My ___GUESS___ is that the current code traverses the directory structure just looking for SOMETHING.vst3 and tries to load it. In the case of Halion the first thing it finds is the new directory and stops there. I suspect it doesn't keep going down to actually find the executable.

Logically I think what should happen is that when the code finds _anything_ named SOMETHING.vst3 it should test it to see if it's a directory or a file. If it's a file, then load it and see if it works. If it's a directory then traverse the hierarchy below it to find a vst3 with the same name.

I completely defer to your vastly larger experience on how to deal with this.
(0027454)
x42   
2023-03-11 23:50   
No need to guess, you can read the source (and your guess is wrong).

When a directory named .vst3 is found, Ardour checks if it is a bundle and if so, tries to loads it as bundle. Also in this case Ardour does not traverse further into this folder.
Otherwise Ardour recursively scans subfolders until either a file or a folder with the suffix .vst3 is found.
If a file named .vst3 is found it is loaded as dll. directly (old style)

I currently have no explanation why this failed for ...\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3

When I Installed sforzando to test it was deployed to C:\Program Files\Common Files\VST3\sforzando.vst3\ as bundle, and it matches the VST3 spec.
It's odd that this differs on your machine and the .vst3 suffix is missing.
(0027455)
Mark Knecht   
2023-03-11 23:52   
I hope this helps. Here's a tree view of everything currently in my VST3 directory. As you can see Minimonsta2 installs the file at the top, some (Scaler2) install multiple in a single directory, some like Harrison created a subgroup AVA directory, some like sforzando followed the new spec but didn't have a dot in the name so the current code worked, and some like Halion followed the new spec but had a dot in the path name and failed.

Mantis isn't allowing me to post the tree output for some reason so I'm attaching a text version hoping that's allowed.
(0027456)
Mark Knecht   
2023-03-12 00:23   
OK, I must have changed it while debugging and forgotten to change it back. I uninstalled and reinstalled and it is sforzando.vst3 as you say. Now neither sforzando or Halion 7 scan correctly, or at least on my system the scanner doesn't output anything to this terminal:

C:\Program Files\Ardour7\bin>ardour-vst3-scanner.exe "c:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3

C:\Program Files\Ardour7\bin>ardour-vst3-scanner.exe "c:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3

C:\Program Files\Ardour7\bin>

whereas these both do. Sines is a new install and scan so the extra stuff makes sense. Minimonsta2 has been scanned before:

C:\Program Files\Ardour7\bin>ardour-vst3-scanner.exe "c:\Program Files\Common Files\VST3\Minimonsta2.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\Minimonsta2.vst3
[Info]: Cache file is valid and up-to-date.
[Info]: Skipping scan.

C:\Program Files\Ardour7\bin>

C:\Program Files\Ardour7\bin>ardour-vst3-scanner.exe "c:\Program Files\Common Files\VST3\Cherry Audio\Sines.vst3"

C:\Program Files\Ardour7\bin>[Info]: Scanning: c:\Program Files\Common Files\VST3\Cherry Audio\Sines.vst3
[Info]: Found Plugin: Sines
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\dccb46cc6f75fcaf87dac46c25e92d6103461d84.v3i

C:\Program Files\Ardour7\bin>

I'm not a programmer so reading the code is not a reasonable use of my time.
(0027457)
x42   
2023-03-12 00:50   
You need to specify options the scanner -v (for verbose) and -f (to force a rescan)

try

C:\Program Files\Ardour7\bin>ardour-vst3-scanner.exe -v -f "c:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3"
(0027458)
Mark Knecht   
2023-03-12 08:35   
On my system, with the period removed from the folder name it scans. With the period in if doesn't do anything,


C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -f -v "C:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3


C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -f -v "C:\Program Files\Common Files\VST3\sforzandovst3\Contents\x86_64-win\sforzando.vst3

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\sforzandovst3\Contents\x86_64-win\sforzando.vst3
[Info]: FactoryInfo: 'Plogue Art et Technologie, Inc' 'https://www.plogue.com' 'mailto:info@plogue.com'
[Info]: Class count: 2
[Info]: Class: 0 'sforzando' 'Audio Module Class'
valid signature detected for C:\Program Files\Plogue\Aria\aria_x64.dll
Engine path:C:\Program Files\Plogue\Aria\aria_x64.dll
queried details:ARIA Engine v1.973 (Win x64)
**ARIA_ENGINE_INFO**
1973
1973
ARIA Engine v1.973 (Win x64)
productName:sforzando
vendorName :Plogue Art et Technologie, Inc
productId:1014
slots:1
supportURL:https://www.plogue.com
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 0
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 0
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 1
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 0
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Found Plugin: sforzando
[Info]: Touch cachefile: set mtime = 1678609439 (2023-03-12 01:23:59), plugin mtime = 1667581110 (2022-11-04 09:58:30)
        <VST3Cache version="2" bundle="C:\Program Files\Common Files\VST3\sforzandovst3\Contents\x86_64-win\sforzando.vst3" module="C:\Program Files\Common Files\VST3\sforzandovst3\Contents\x86_64-win\sforzando.vst3">
          <VST3Info uid="5C5CA79682FC437AB6539BA204BAB349" name="sforzando" vendor="Plogue Art et Technologie, Inc" category="Instrument" version="2.1.0.5" sdk-version="VST 3.7.6" url="https://www.plogue.com" email="mailto:info@plogue.com" n_inputs="0" n_outputs="2" n_aux_inputs="0" n_aux_outputs="0" n_midi_inputs="1" n_midi_outputs="0">
          </VST3Info>
        </VST3Cache>
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\8b734b44b11890474f2a15748a25fffc680c973b.v3i

C:\Users\Titan-R7>




For HALion it doesn't scan with the period in. With the period removed it says it's not a valid bundle



C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -f -v "C:\Program Files\Common Files\VST3\Steinburg\HALion 7vst3\Contents\x86_64-win\HALion 7.vst3"

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinburg\HALion 7vst3\Contents\x86_64-win\HALion 7.vst3
VST3 not a valid bundle: 'C:\Program Files\Common Files\VST3\Steinburg\HALion 7vst3\Contents\x86_64-win\HALion 7.vst3'

C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -f -v "C:\Program Files\Common Files\VST3\Steinburg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3"

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinburg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3

C:\Users\Titan-R7>


So, what does it mean "VST3 is not a valid bundle"
(0027460)
x42   
2023-03-12 13:06   
(Last edited: 2023-03-12 13:06)
Looks like you made some typos.

Steinburg -> Steinberg

Hint: You can Drag/Drop the bundle folder from an explorer to the cmd.exe terminal.

sforzando.vst3 does not scan because it does not exist since you have removed the .vst3 suffix from the bundle dir.
(0027461)
Mark Knecht   
2023-03-12 14:11   
I'm getting so tired of Mantis not accepting new info and the back button not working. Someone needs to fix this thing. I will work to reenter all the work I just did.

Thanks for teaching me the drag and drop trick with cmd.exe. Saves a lot of time and fewer errors.
(0027462)
Mark Knecht   
2023-03-12 14:13   
With '.vst3' in the path name neither sforzando or HALion 7 scan in cmd.exe:

C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -v -f "C:\Program Files\Common Files\VST3\Scaler2\Scaler2.vst3"

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\Scaler2\Scaler2.vst3
[Info]: FactoryInfo: 'Plugin Boutique' 'http://www.pluginboutique.com/' ''
[Info]: Class count: 2
[Info]: Class: 0 'Scaler 2' 'Audio Module Class'
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 1
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 1
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 1
[Info]: VST3: - bus: 0 count: 16
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Found Plugin: Scaler 2
[Info]: Touch cachefile: set mtime = 1678630310 (2023-03-12 07:11:50), plugin mtime = 1675183798 (2023-01-31 09:49:58)
        <VST3Cache version="2" bundle="C:\Program Files\Common Files\VST3\Scaler2\Scaler2.vst3" module="C:\Program Files\Common Files\VST3\Scaler2\Scaler2.vst3">
          <VST3Info uid="ABCDEF019182FAEB654D616953636C32" name="Scaler 2" vendor="Plugin Boutique" category="Instrument" version="2.7.3" sdk-version="VST 3.7.2" url="http://www.pluginboutique.com/" email="" n_inputs="2" n_outputs="2" n_aux_inputs="0" n_aux_outputs="0" n_midi_inputs="1" n_midi_outputs="1">
          </VST3Info>
        </VST3Cache>
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\4592086e7db3afb2705f8303f5c9645e125cc8ab.v3i

C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -v -f "C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3"

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3

C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -v -f "C:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3"

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3

C:\Users\Titan-R7>
(0027463)
Mark Knecht   
2023-03-12 14:19   
Running Rescan All in Ardour eventually hangs on HALion 7. Skip This Plugin doesn't work. Ardour has a red X in the upper right. Clicking it says "Ardour.exe is not responding". I click it and Windows says it's sending info to M$.

After Ardour crashes I have a vst3_x86_blacklist.txt file and the vst directory is populated including an entry for Halion
(0027464)
Mark Knecht   
2023-03-12 14:22   
I note that the SDK referenced in the HALion file attached above (3.7.5) is newer than any of the versions referenced in other files in the cache/vst directory.

Steinberg's release info talks about new changes:

https://forums.steinberg.net/t/vst-3-7-5-sdk-released/786928

The GITHUB page shows that there's a later 3.7.7 version also.

https://forums.steinberg.net/t/vst-3-7-7-sdk-released/822572
(0027465)
Mark Knecht   
2023-03-12 14:37   
And after the Ardour crash if I remove the HALion line from the blacklist file Halion becomes usable inside of Ardour. Screenshot attached - I had to crop to meet the 2MB limit in Mantis.
(0027466)
Mark Knecht   
2023-03-12 14:49   
Screenshot of HALion 7 in Ardour:

https://drive.google.com/file/d/1dyzeuBIPsKLVqfxhTmro6CcNYkpLhsLP/view?usp=share_link
(0027467)
x42   
2023-03-12 15:29   
What you describe is exactly what I would excpect. except that Ardour should not hang.

1. Create a blacklist entry
2. Scan the plugin
3. Remove the blacklist entry

Since you kill Ardour at Step 2, the plugin remains backlisted.

Also "bundle="C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3" module="C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3"
now looks correct. The bundle is correctly detected.

Now the big question is: Does the VST3 scanner also hang when you launch it manually, or does it only happen if you use the GUI. Please run

"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -v -f "C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3"
(0027468)
Mark Knecht   
2023-03-12 16:27   
Ah, so creating the blacklist entry ahead of time, then removing it if it worked is something I did not consider. thanks for the explanation.

The specific command you requested appears to me to work correctly:

C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -v -f "C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3"

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3
[Info]: Found cache file: 'C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\ed88f2b4c7d4b3ff3583533ad8c95e8e16d6bb52.v3i'
[Info]: Cache file timestamp is valid.
[Info]: Cache file is valid and up-to-date.
[Info]: FactoryInfo: 'Steinberg Media Technologies' 'http://www.steinberg.net' 'mailto:info@steinberg.de'
[Info]: Class count: 4
[Info]: Class: 0 'HALion 7' 'Audio Module Class'
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 1
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 33
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: - bus: 1 count: 2
[Info]: VST3: - bus: 2 count: 2
[Info]: VST3: - bus: 3 count: 2
[Info]: VST3: - bus: 4 count: 2
[Info]: VST3: - bus: 5 count: 2
[Info]: VST3: - bus: 6 count: 2
[Info]: VST3: - bus: 7 count: 2
[Info]: VST3: - bus: 8 count: 2
[Info]: VST3: - bus: 9 count: 2
[Info]: VST3: - bus: 10 count: 2
[Info]: VST3: - bus: 11 count: 2
[Info]: VST3: - bus: 12 count: 2
[Info]: VST3: - bus: 13 count: 2
[Info]: VST3: - bus: 14 count: 2
[Info]: VST3: - bus: 15 count: 2
[Info]: VST3: - bus: 16 count: 2
[Info]: VST3: - bus: 17 count: 2
[Info]: VST3: - bus: 18 count: 2
[Info]: VST3: - bus: 19 count: 2
[Info]: VST3: - bus: 20 count: 2
[Info]: VST3: - bus: 21 count: 2
[Info]: VST3: - bus: 22 count: 2
[Info]: VST3: - bus: 23 count: 2
[Info]: VST3: - bus: 24 count: 2
[Info]: VST3: - bus: 25 count: 2
[Info]: VST3: - bus: 26 count: 2
[Info]: VST3: - bus: 27 count: 2
[Info]: VST3: - bus: 28 count: 2
[Info]: VST3: - bus: 29 count: 2
[Info]: VST3: - bus: 30 count: 2
[Info]: VST3: - bus: 31 count: 2
[Info]: VST3: - bus: 32 count: 6
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 33
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 4
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 0
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Skipping non-effect class: Preset Compatibility Class
[Info]: Skipping non-effect class: Preset Version Class
[Info]: Found Plugin: HALion 7
(0027469)
x42   
2023-03-12 16:31   
" appears to me to work correctly:"

Unless the output was truncated at the end. the scanner does not seem to complete. The XML cache should be printed at the end.
(0027470)
Mark Knecht   
2023-03-12 16:35   
Actually, you are correct. The CLI did NOT return to the windows command line prompt. It's just sitting there after the Found Plugin: Halion 7 line.

It does not respond to Ctrl-C. I don't use Windows enough to know if that's expected but it's hung in the terminal.

Good catch!
(0027473)
x42   
2023-03-14 03:00   
> It does not respond to Ctrl-C.

OK. That can also explains why Ardour hangs.
The scan does not complete. Ardour tries to stop the plugin-scanner after a timeout by calling TerminateProcess() and then wait the child process to quit..

Now the big question is how killing the process ends up writing the cache file and why the scanner does not complete in the first place.
(0027474)
Mark Knecht   
2023-03-14 14:17   
OK, let me make sure I've given you all the info on what I'm seeing.

1) I erase the blacklist file and all files in the cache directory.

2) If I run the vst3 scanner on the actual vst3 file it does nothing other than return at the command line. Nothing is written into the cache directory. No blacklist file is created:

C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -v -f "C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3"

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3

C:\Users\Titan-R7>

3) However if I run the vst3 scanner on the HALion 7.vst3 directory just under Steinberg, the scanner does run and appears to finish correctly. The info about the vst3 file 2 directories down is shown on the screen and the cache file is created:

C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -v -f "C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3"

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3
[Info]: FactoryInfo: 'Steinberg Media Technologies' 'http://www.steinberg.net' 'mailto:info@steinberg.de'
[Info]: Class count: 4
[Info]: Class: 0 'HALion 7' 'Audio Module Class'
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 1
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 33
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: - bus: 1 count: 2
[Info]: VST3: - bus: 2 count: 2
[Info]: VST3: - bus: 3 count: 2
[Info]: VST3: - bus: 4 count: 2
[Info]: VST3: - bus: 5 count: 2
[Info]: VST3: - bus: 6 count: 2
[Info]: VST3: - bus: 7 count: 2
[Info]: VST3: - bus: 8 count: 2
[Info]: VST3: - bus: 9 count: 2
[Info]: VST3: - bus: 10 count: 2
[Info]: VST3: - bus: 11 count: 2
[Info]: VST3: - bus: 12 count: 2
[Info]: VST3: - bus: 13 count: 2
[Info]: VST3: - bus: 14 count: 2
[Info]: VST3: - bus: 15 count: 2
[Info]: VST3: - bus: 16 count: 2
[Info]: VST3: - bus: 17 count: 2
[Info]: VST3: - bus: 18 count: 2
[Info]: VST3: - bus: 19 count: 2
[Info]: VST3: - bus: 20 count: 2
[Info]: VST3: - bus: 21 count: 2
[Info]: VST3: - bus: 22 count: 2
[Info]: VST3: - bus: 23 count: 2
[Info]: VST3: - bus: 24 count: 2
[Info]: VST3: - bus: 25 count: 2
[Info]: VST3: - bus: 26 count: 2
[Info]: VST3: - bus: 27 count: 2
[Info]: VST3: - bus: 28 count: 2
[Info]: VST3: - bus: 29 count: 2
[Info]: VST3: - bus: 30 count: 2
[Info]: VST3: - bus: 31 count: 2
[Info]: VST3: - bus: 32 count: 6
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 33
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 4
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 0
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Skipping non-effect class: Preset Compatibility Class
[Info]: Skipping non-effect class: Preset Version Class
[Info]: Found Plugin: HALion 7
[Info]: Touch cachefile: set mtime = 1678802571 (2023-03-14 07:02:51), plugin mtime = 1675185166 (2023-01-31 10:12:46)
        <VST3Cache version="2" bundle="C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3" module="C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3">
          <VST3Info uid="3B63D74130B34AE397AF92A9659137D5" name="HALion 7" vendor="Steinberg Media Technologies" category="Instrument|Sampler" version="7.0.0" sdk-version="VST 3.7.5" url="http://www.steinberg.net" email="mailto:info@steinberg.de" n_inputs="0" n_outputs="70" n_aux_inputs="2" n_aux_outputs="0" n_midi_inputs="1" n_midi_outputs="0">
          </VST3Info>
        </VST3Cache>
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\ed88f2b4c7d4b3ff3583533ad8c95e8e16d6bb52.v3i

C:\Users\Titan-R7>


4) If I then run the vst3 scanner a SECOND time on the HALion 7.vst DIRECTORY, that's when the scanner fails at the command line and doesn't return to the DOS prompt:

C:\Users\Titan-R7>"C:\Program Files\Ardour7\bin\ardour-vst3-scanner.exe" -v -f "C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3"

C:\Users\Titan-R7>[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3
[Info]: Found cache file: 'C:\Users\Titan-R7\AppData\Local\Ardour7\cache\vst\ed88f2b4c7d4b3ff3583533ad8c95e8e16d6bb52.v3i'
[Info]: Cache file timestamp is valid.
[Info]: Cache file is valid and up-to-date.
[Info]: FactoryInfo: 'Steinberg Media Technologies' 'http://www.steinberg.net' 'mailto:info@steinberg.de'
[Info]: Class count: 4
[Info]: Class: 0 'HALion 7' 'Audio Module Class'
[Info]: VST3: media: kAudio dir: kInput type: kMain n_busses: 1
[Info]: VST3: media: kAudio dir: kInput type: kAux n_busses: 1
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: media: kAudio dir: kOutput type: kMain n_busses: 33
[Info]: VST3: - bus: 0 count: 2
[Info]: VST3: - bus: 1 count: 2
[Info]: VST3: - bus: 2 count: 2
[Info]: VST3: - bus: 3 count: 2
[Info]: VST3: - bus: 4 count: 2
[Info]: VST3: - bus: 5 count: 2
[Info]: VST3: - bus: 6 count: 2
[Info]: VST3: - bus: 7 count: 2
[Info]: VST3: - bus: 8 count: 2
[Info]: VST3: - bus: 9 count: 2
[Info]: VST3: - bus: 10 count: 2
[Info]: VST3: - bus: 11 count: 2
[Info]: VST3: - bus: 12 count: 2
[Info]: VST3: - bus: 13 count: 2
[Info]: VST3: - bus: 14 count: 2
[Info]: VST3: - bus: 15 count: 2
[Info]: VST3: - bus: 16 count: 2
[Info]: VST3: - bus: 17 count: 2
[Info]: VST3: - bus: 18 count: 2
[Info]: VST3: - bus: 19 count: 2
[Info]: VST3: - bus: 20 count: 2
[Info]: VST3: - bus: 21 count: 2
[Info]: VST3: - bus: 22 count: 2
[Info]: VST3: - bus: 23 count: 2
[Info]: VST3: - bus: 24 count: 2
[Info]: VST3: - bus: 25 count: 2
[Info]: VST3: - bus: 26 count: 2
[Info]: VST3: - bus: 27 count: 2
[Info]: VST3: - bus: 28 count: 2
[Info]: VST3: - bus: 29 count: 2
[Info]: VST3: - bus: 30 count: 2
[Info]: VST3: - bus: 31 count: 2
[Info]: VST3: - bus: 32 count: 6
[Info]: VST3: media: kAudio dir: kOutput type: kAux n_busses: 33
[Info]: VST3: media: kEvent dir: kInput type: kMain n_busses: 4
[Info]: VST3: - bus: 0 count: 16
[Info]: VST3: media: kEvent dir: kOutput type: kMain n_busses: 0
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Skipping non-effect class: Preset Compatibility Class
[Info]: Skipping non-effect class: Preset Version Class
[Info]: Found Plugin: HALion 7



So in my mind the question is why does the scanner care that the cache file already exists? If using the -f option shouldn't it erase the existing cache file and write a new on in it's place? Granted, possibly it doesn't know the cache file exists? The cache file name is NOT the same as the long VST3Info uid inside the file.
(0027475)
Mark Knecht   
2023-03-14 14:57   
I need to double check this but I believe this also suggests how I got Halion to work originally. There's no cache file and I do a scan, either scan all or certainly scan new, then the scanner writes the cache file and the vst3 becomes available for use. If I rescan all vst3 then the scanner finds the cache file, fails and the blacklist item is left in the blacklist file. I then hand edit the blacklist file and the old cache file becomes usable again.

If any of that requires checking to help you figure this out let me know. Very happy to have your attention.
(0027498)
Mark Knecht   
2023-03-22 18:32   
So I've continued to look at this problem:

1) Uninstalled Mixbus32C-7, Mixbuis32C-8 and Ardour
2) Attempted to clean up old directories that hold the VST cache type stuff along with anything else that looked like it was left over. The only thing left on purpose was session files.
3) Purchased the full version of what Steinberg calls 'Absolute 6' which includes HALion 7 and a bunch of other stuff. All of this works fine in stand alone mode on the Windows desktop.

4) Installed Mixbus32C-8 and run it for the first time. It indexes but does not scan the plugins. In the Mixbus8->plugin_metadata directory there is a scan_log file which I will attach. However at this point it's alredy complaining about an "Invalid Module Path "

  <PluginScanLogEntry type="VST3" path="C:\Program Files\Common Files\VST3\Minimonsta2.vst3" scan-log="" scan-result="1"/>
  <PluginScanLogEntry type="VST3" path="C:\Program Files\Common Files\VST3\Scaler2\Scaler2.vst3" scan-log="" scan-result="1"/>
  <PluginScanLogEntry type="VST3" path="C:\Program Files\Common Files\VST3\Scaler2\ScalerAudio2.vst3" scan-log="" scan-result="1"/>
  <PluginScanLogEntry type="VST3" path="C:\Program Files\Common Files\VST3\Steinberg\Backbone.vst3" scan-log="" scan-result="1"/>
  <PluginScanLogEntry type="VST3" path="C:\Program Files\Common Files\VST3\Steinberg\Backbone.vst3\Contents\x86_64-win\Backbone.vst3" scan-log="Invalid Module Path " scan-result="4"/>
  <PluginScanLogEntry type="VST3" path="C:\Program Files\Common Files\VST3\Steinberg\Groove Agent.vst3" scan-log="" scan-result="1"/>
  <PluginScanLogEntry type="VST3" path="C:\Program Files\Common Files\VST3\Steinberg\Groove Agent.vst3\Contents\x86_64-win\Groove Agent.vst3" scan-log="Invalid Module Path " scan-result="4"/>

In the screenshot attached below you can see the 'Error' listed for a couple of the new Steinberg VST3's
(0027499)
Mark Knecht   
2023-03-22 18:35   
Continued from above...

At this point I can select a single VST, such as sforzando.vst3 and tell Mixbus to Rescan Selected. It works and prints this info in the bottom window of the plugin manager:

VST3 module-path 'C:\Program Files\Common Files\VST3\sforzando.vst3\Contents\x86_64-win\sforzando.vst3'
[Info]: Scanning: C:\Program Files\Common Files\VST3\sforzando.vst3
valid signature detected for C:\Program Files\Plogue\Aria\aria_x64.dll
Engine path:C:\Program Files\Plogue\Aria\aria_x64.dll
queried details:ARIA Engine v1.973 (Win x64)
**ARIA_ENGINE_INFO**
1973
1973
ARIA Engine v1.973 (Win x64)
productName:sforzando
vendorName :Plogue Art et Technologie, Inc
productId:1014
slots:1
supportURL:https://www.plogue.com
[Info]: Found Plugin: sforzando
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Mixbus8\cache\vst\5e934701448d7ce1dd0ef71f2815b950bccb2a85.v3i
(0027500)
Mark Knecht   
2023-03-22 18:41   
Continued from above...

At this point I try scanning HALion Sonic and get the same failure I see for HALion 7. The scan starts but appears to hang. The cache file is written into Mixbus8 and HALion Sonic is written into the blacklist file. However I let it sit for literaly 2-3 inutes and it eventually returns. The blacklist entry is removed. The following info is in the bottom window:

VST3 module-path 'C:\Program Files\Common Files\VST3\Steinberg\HALion Sonic.vst3\Contents\x86_64-win\HALion Sonic.vst3'
[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinberg\HALion Sonic.vst3
[Info]: VST3: \ ignored bus: 1 type: kMain count: 2
[Info]: VST3: \ ignored bus: 2 type: kMain count: 2
[Info]: VST3: \ ignored bus: 3 type: kMain count: 2
[Info]: VST3: \ ignored bus: 4 type: kMain count: 2
[Info]: VST3: \ ignored bus: 5 type: kMain count: 2
[Info]: VST3: \ ignored bus: 6 type: kMain count: 2
[Info]: VST3: \ ignored bus: 7 type: kMain count: 2
[Info]: VST3: \ ignored bus: 8 type: kMain count: 2
[Info]: VST3: \ ignored bus: 9 type: kMain count: 2
[Info]: VST3: \ ignored bus: 10 type: kMain count: 2
[Info]: VST3: \ ignored bus: 11 type: kMain count: 2
[Info]: VST3: \ ignored bus: 12 type: kMain count: 2
[Info]: VST3: \ ignored bus: 13 type: kMain count: 2
[Info]: VST3: \ ignored bus: 14 type: kMain count: 2
[Info]: VST3: \ ignored bus: 15 type: kMain count: 2
[Info]: Found Plugin: HALion Sonic
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Mixbus8\cache\vst\623c584c77832ba982eb59fdb0f799cdf055bc9b.v3i
(0027501)
x42   
2023-03-22 18:43   
Note that uninstalling Mixbus does not remove the config or any of the prior plugin caches. In fact un/reinstalling Mixbus should be a no-op.

Remove %localappdata%\mixbus9\ to clear the preferences and plugin-cache.
(0027502)
Mark Knecht   
2023-03-22 18:48   
Continued from above...

Finally I brave the HALion 7 scan. It hangs for about 4 minutes but eventually completes with this info in the bottom window:

VST3 module-path 'C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3'
[Info]: Scanning: C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3
[Info]: VST3: \ ignored bus: 0 type: kAux count: 2
[Info]: VST3: \ ignored bus: 1 type: kMain count: 2
[Info]: VST3: \ ignored bus: 2 type: kMain count: 2
[Info]: VST3: \ ignored bus: 3 type: kMain count: 2
[Info]: VST3: \ ignored bus: 4 type: kMain count: 2
[Info]: VST3: \ ignored bus: 5 type: kMain count: 2
[Info]: VST3: \ ignored bus: 6 type: kMain count: 2
[Info]: VST3: \ ignored bus: 7 type: kMain count: 2
[Info]: VST3: \ ignored bus: 8 type: kMain count: 2
[Info]: VST3: \ ignored bus: 9 type: kMain count: 2
[Info]: VST3: \ ignored bus: 10 type: kMain count: 2
[Info]: VST3: \ ignored bus: 11 type: kMain count: 2
[Info]: VST3: \ ignored bus: 12 type: kMain count: 2
[Info]: VST3: \ ignored bus: 13 type: kMain count: 2
[Info]: VST3: \ ignored bus: 14 type: kMain count: 2
[Info]: VST3: \ ignored bus: 15 type: kMain count: 2
[Info]: VST3: \ ignored bus: 16 type: kMain count: 2
[Info]: VST3: \ ignored bus: 17 type: kMain count: 2
[Info]: VST3: \ ignored bus: 18 type: kMain count: 2
[Info]: VST3: \ ignored bus: 19 type: kMain count: 2
[Info]: VST3: \ ignored bus: 20 type: kMain count: 2
[Info]: VST3: \ ignored bus: 21 type: kMain count: 2
[Info]: VST3: \ ignored bus: 22 type: kMain count: 2
[Info]: VST3: \ ignored bus: 23 type: kMain count: 2
[Info]: VST3: \ ignored bus: 24 type: kMain count: 2
[Info]: VST3: \ ignored bus: 25 type: kMain count: 2
[Info]: VST3: \ ignored bus: 26 type: kMain count: 2
[Info]: VST3: \ ignored bus: 27 type: kMain count: 2
[Info]: VST3: \ ignored bus: 28 type: kMain count: 2
[Info]: VST3: \ ignored bus: 29 type: kMain count: 2
[Info]: VST3: \ ignored bus: 30 type: kMain count: 2
[Info]: VST3: \ ignored bus: 31 type: kMain count: 2
[Info]: VST3: \ ignored bus: 32 type: kMain count: 6
[Info]: Found Plugin: HALion 7
[Info]: Saved VST3 plugin cache to C:\Users\Titan-R7\AppData\Local\Mixbus8\cache\vst\ed88f2b4c7d4b3ff3583533ad8c95e8e16d6bb52.v3i
(0027503)
Mark Knecht   
2023-03-22 19:20   
I found the Mixbus32C Preferences window in the Plugins section has buttons to clear cache and the Ignore List for both vst2 & vst3. It's probably there in Ardour also.

From my POV it appears that at least with the full version of HALion 7 that simply letting it sit for 4-5 minutes was enough to allow Mixbus to complete successfully. I assume Ardour also which I could check if it's important to you.

Even though it works there are, I think, 2 issue left outstanding:

1) All of the Steinberg VSTs that came in this package still have 'Invalid Module PAth' errors left in the Plugin Manager window.

2) If I hit the 'Ignore unresponsive plugins' buttons while waiting for HALion to scan it does cause Mixbus and Ardour to be marked as crashed and sends a report to M$.

It would be good to figure out the fixes for both of these. I'm here to help if you need me.
(0027534)
x42   
2023-04-04 21:47   
Nathan tested this today on a Windows 10 system and the plugin scanned without issue in Mixbus 32C, and directly showed up.

He said it took 3 install steps
* Steinberg Downloader
* Activation Manager
* Steinberg Library


After that I logged into the machine and installed an Ardour debug build to verify that the bundle is scanned and this works correctly as expected.

I cannot see a codepath in Ardour 7 or Mixbus 9 that would require the plugin folder to be renamed. It remains a mystery why [only] your system is affected by this.
(0027535)
Mark Knecht   
2023-04-04 23:04   
I guess I'm unlucky.

A couple of things for the record:

1) Nathan emailed me that he's on Win 11. Possibly that's a misprint. I'm on Win 10.

2) I reported earlier that if the cache files and blacklist are deleted then the scan doesn't fail.

3) I find that almost none of the Steinberg stuff works after the session has been saved and reloaded. It's fine when first instantiated.

4) If there's only 2 machines tested (that I know of) and one works/one fails, I don't think that's much of a data set but yes, it's so far only my machine that fails.
(0027536)
x42   
2023-04-04 23:46   
Re (3) do you mean https://tracker.ardour.org/view.php?id=9287 (different issue, unrelated to scanning)?
(0027563)
Mark Knecht   
2023-04-07 20:31   
OK, interesting news concerning the %PLUGIN%.vst3/Contents/x86_64-win/%PLUGIN%.vst3 "Invalid path" problem.

I will leave it to you to decide to call it resolved or leave it open.

I set up my only 2 Windows machines with lots of plugins, but to be transparent they aren't the same set beyond what the installs give me.

1) The laptop has Mixbus32C-7, Mixbus32C-9 and Ardour-7.3.0. On that machine all 3 versions of the programs cause the error for the sforzando VST3 which is, on this machine, the only plugin that uses this new Steinberg directory structure. This machine has some Native Instrument plugins. They don't use the structure and they are fine.

2) The big machine has Mixbus32C-8, Mixbus32C-9 and the nightly from last night Ardour-7.3.187. On this machine in BOTH versions of Mixbys32C all plugins with the new directory structure fail with the "Invalid path" message but 7.3.187, which solved the Halion VST scan problem, does not have the "Invalid path" problem. Nothing marked 'Error' anymore.

Is it solved by the same fix, or by something else? I don't know, but for now it appears to be fixed at least for Ardour nightly.

If you choose to close this bug report I think that's reasonable. If I see the problem again I'll open a new bug report with new data.

I don't know how these updates get to Harrison but I'll hope they get there sooner than later and test each update they make available.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8925 [ardour] features feature N/A 2022-06-14 23:09 2023-12-19 14:06
Reporter: nika.hrlyn Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: save and restore plugin views
Description: i would like to be able to open and close groups of plugins with a shortcut. like all my analyser plugins organized on my second screen. or all the related bus EQ. or the two bus plugin chain. all in the neat positions that i arranged when i saved the plugin view.similar maybe to saving editor views
Tags: plugin, preset, safe view, workflow
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026494)
x42   
2022-07-05 15:16   
Ardour already remembers the position of plugin windows.

Is this about having multiple arrangements, rather than a single position information for plugins?

Or do you simply want to open/close the UIs in groups? e.g. show/HIde all EQs, or Show all plugins of selected tracks(s)?
(0026495)
nika.hrlyn   
2022-07-06 08:38   
I simply want to open/close the UIs in groups.
But if there are multiple arrangements that could be interesting also.
For example in one plugin view I open all the Plugins on the 2Bus and there the Spectrum analyzer is in the bottom right.. but in a second view, in which I have all my EQ open, the spectrum analyzer fills half of the screen.

But honestly that would go beyond my expectaions.. for now id just like to be able to open/close in groups :)
(0028428)
nika.hrlyn   
2023-12-19 14:06   
Hey, i thought I'd give this request a bump to ask about its status :)
cheers an merry christmas

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9574 [ardour] bugs minor always 2023-12-15 06:23 2023-12-19 14:05
Reporter: joachim Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: The "Mixer: Show Mixer List" View menu function is broken.
Description: Showing or hiding the The Tracks and Busses List by clicking the View menu, then "Mixer: Show Mixer List" does nothing.

Hitting "Shift+L" as hinted in the menu item itself does however work.
Tags: 8.2, broken, editor list, menu
Steps To Reproduce: In a session, empty or not, click "View" on the main menu, then "Mixer: Show Mixer List"

Expected result:
The Mixer list should appear or dissapear, depending on it's previous viewable state.

Actual result:
The checkbox in the menu item is toggled but the viewable state of the mixer list does not change.

Workaround:
Hit "Shift+L" to change the viewable state of the mixer list.
Additional Information: Tested with the the following versions, all with the same behaviour:
8.1-182-g066df7cc1a
Ardour 8.1.0 official release "The Drop", obtained from the Arch Linux extra repository
Ardour 8.2.0 official release "Tracks and Traces", obtained via https://community.ardour.org/download?architecture=x86_64&type=source
System Description
Attached Files: Show_Mixer_List-20231215_071612.png (187,351 bytes) 2023-12-15 06:23
https://tracker.ardour.org/file_download.php?file_id=4741&type=bug
png
Notes
(0028423)
joachim   
2023-12-15 08:38   
Forgot to test this function from the Mixer view/window.
To clarify, turns out this function works as expected from the mixer window, but not from the editor window.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9580 [ardour] other trivial always 2023-12-19 09:55 2023-12-19 09:55
Reporter: joachim Platform: Arch  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Visual inconsistency with Ardour icons.
Description: I've noticed that there is a new icon for Ardour which has a curve and some white shading on it.
It stands out from the flat version. I like the new version better.
Tags: icon, visual
Steps To Reproduce: 1. Launch Ardour
2. Open the "About" dialog box from the Help menu.
3. Take a look at your taskbar and compare the icons.
Additional Information: Screenshot is from my KDE Plasma taskbar, with a panel height set to 40 pixels.
The left Icon is for the editor/mix window, the right icon is the the "About" dialog box.

If you zoom in to the titlebar for Ardour's window, you'll also see the new icon with shading.
System Description
Attached Files: KDE-Plasma-Taskbar-Icons_20231219_104733.png (1,946 bytes) 2023-12-19 09:55
https://tracker.ardour.org/file_download.php?file_id=4747&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9577 [ardour] bugs major always 2023-12-18 13:10 2023-12-18 13:10
Reporter: gudmunduringimarsson Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when trying to remove a track after reopening Ardour
Description: Every time i import a track from a template or try to remove a track after saving and opening Ardour again, the app crashes.
Tags:
Steps To Reproduce: This happens every time.
Additional Information: These are tracks that have plugins on them. But happens with any plugins.
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9576 [ardour] bugs minor always 2023-12-16 10:05 2023-12-17 02:58
Reporter: axra Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: confirmed Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Toolbox Mousemodes - Audition Mode missing + No Info about grid Mode on Mouse over
Description: Seems that in the toolbox the Audition Mode is missing as described in https://manual.ardour.org/ardours-interface/the-toolbox/
And there is no Info about Grid Mode when Mouse hovering.
Tags:
Steps To Reproduce: When hovering over toolbox Mousemodes there should be an Info Box displayed.
But Info is missing about Grid Mode. Maybe missing translation?
Additional Information:
System Description
Attached Files: Peek 2023-12-16 10-44.gif (115,696 bytes) 2023-12-16 10:05
https://tracker.ardour.org/file_download.php?file_id=4742&type=bug
gif

with audition mode.png (14,093 bytes) 2023-12-16 10:05
https://tracker.ardour.org/file_download.php?file_id=4743&type=bug
png

without audition mode.png (6,354 bytes) 2023-12-16 10:05
https://tracker.ardour.org/file_download.php?file_id=4744&type=bug
png
Notes
(0028426)
x42   
2023-12-17 02:58   
Thanks for the heads up, the documentation needs to be updated.

The Audition tool was replaced with the audition action, new grid tool lacks documentation.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9575 [ardour] bugs tweak always 2023-12-15 16:25 2023-12-15 17:37
Reporter: Pizza98 Platform: Linux  
Assigned To: OS: openSuse Tumbleweed  
Priority: normal OS Version: 15.12.2023  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When using a midi channels keyboard in the note editor with the mouse it collapses the channel on double clicking
Description: when clicking the piano roll keyboard in the midi editor the left click events apply like they would when clicking on the channel. so it resizes
Tags: pianoroll
Steps To Reproduce: double click the piano roll keyboard
Additional Information: using this build from the obs https://software.opensuse.org/package/ardour
Attached Files:
Notes
(0028424)
joachim   
2023-12-15 17:37   
This has already been reported.

https://tracker.ardour.org/view.php?id=9572

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9557 [ardour] features feature N/A 2023-11-29 02:05 2023-12-15 06:32
Reporter: erdavis7 Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Play loop range" should let an intro keep playing.
Description: Currently, "Play loop range" always sends the playhead to the beginning of the loop range. This is good behavior when initiated from a stopped state, but it could be improved for some different playing states:

If the playhead is playing before or within the loop range, then "Play loop range" should cause it to continue playing where it is until it reaches the end of the loop, where it should begin looping. This is useful for auditioning a song which has an intro and then a looping section, as is common in video game soundtracks, for example.

"Play loop range" already behaves well with outros; once it is disabled, the playhead continues where it is and then goes beyond the loop range to play the outro. I think this suggested behavior would be more consistent.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028377)
dspasic   
2023-11-30 16:29   
Hi, i join this request:)
(0028383)
erdavis7   
2023-11-30 23:38   
I'm not sure, but it might be desirable for "Play loop range" to start from the current playhead position any time the playhead is before or within the loop range, even from a stopped state.
(0028384)
erdavis7   
2023-12-01 03:46   
Alternatively, "Play loop range" could be changed to "Toggle loop", which would just toggle whether the playhead would loop upon reaching the end of the loop range.
(0028422)
joachim   
2023-12-15 06:32   
Agreed!
Loop toggling makes more sense.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9573 [ardour] bugs crash always 2023-12-15 04:42 2023-12-15 04:42
Reporter: NotGabe Platform: Redhat  
Assigned To: OS: Fedora  
Priority: high OS Version: 39  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when loading drumkv1, samplv1
Description: Loading drumkv1 or samplv1 freezes Ardour.
Tags: 8.2, drumkv1, plugin, samplv1
Steps To Reproduce: Open Ardour, either add a track or add a plugin to a track, and select the drumkv1 or samplv1 plugin. Ardour should stop responding entirely at that point.
Additional Information: I'm using a self-built Ardour from the tarball at ardour.org. I have included a backtrace and the most relevant parts of the command line output. If I need to, I can upload the exact drumkv1 that is crashing. Running the standalone app or through Carla has no issues whatsoever, but for some reason loading it in Ardour just freezes it.
System Description
Attached Files: ardour_backtrace.txt (40,272 bytes) 2023-12-15 04:42
https://tracker.ardour.org/file_download.php?file_id=4739&type=bug
ardour_cli_output.txt (1,945 bytes) 2023-12-15 04:42
https://tracker.ardour.org/file_download.php?file_id=4740&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9561 [ardour] bugs minor always 2023-11-30 17:35 2023-12-15 02:53
Reporter: bonesofwrath Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Loop Region plays old tempo
Description: Looping of a region appears (at least for MIDI) to be calculated at creation. Editing the tempo after the loop is created plays at the new tempo but the loop jumps at old_tempo * steps = so if you create a loop at 120 bpm and set the tempo to 60 bpm, it will jump back to the beginning halfway through
Tags:
Steps To Reproduce: Create MIDI region
Create Loop
Edit Tempo
Play Loop
Additional Information: git b376f271c4a2140b364901bd50a1da8fe1645c4b
System Description
Attached Files:
Notes
(0028380)
joachim   
2023-11-30 18:08   
Can confirm this happens in rev 8.1-144-gb376f271c4

When increasing the tempo, the loop region is shifted forward and continues looping.
When decreasing the tempo, the loop region is shifted backwards, and loops once, then looping is cancelled and playback continues.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9572 [ardour] bugs minor always 2023-12-14 21:04 2023-12-15 02:50
Reporter: joachim Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Double-clicking on piano roll keys resets the track header's height.
Description: I was testing Drumgizmo in Ardour, which led me to rapidly left click one of the keys in the piano roll.

Expected result:
Rapid triggering of note on/off events to audition samples from Drumgizmo, or any other MIDI instrument.

Actual result:
The track height is unexpectedly set back to it's default height when you click the left mouse button twice fast enough for it to amount to a double-click.

It is my humble opinion that double click events should be ignored on the piano roll keys.
Tags: 8.2, pianoroll, resize, track
Steps To Reproduce: Two conditions can be observed.

Condition 1: Only the Master Bus and one MIDI track in the session.

1. Create one MIDI track.
2. Choose any MIDI instrument for your track
3. Click and drag the bottom of the track header to expand it's size enough to reveal the piano roll keys.
4. Click the left mouse button two times rapidly on one of the piano roll keys, as if you are double clicking.

Result: Double-clicking on the piano roll keys resizes the track height to it's default size, in the same way that double clicking in an empty space in the track header does.

Condition 2: When there are two or more tracks (MIDI or Audio) in the session.

1. Create one MIDI track.
2. Create one or more more track(s), either MIDI or audio, does not matter.
3. Click and drag the bottom of the first MIDI track to expand it enough to partially or completely obscure the header of track number behind the summary view.
4. Click the left mouse button two times rapidly on one of the piano roll keys, as if you are double clicking.

Result: Same as Condition 1, but moving the mouse cursor back near the bottom of the track header of the first track reveals another "magnetic"-like behaviour. It is as if the track header is stuck in resize mode. Left clicking once in the track header while in this state, stops this condition.
Additional Information: This behaviour was first discovered with rev 8.1-181-g6c5d15a1e6
The official 8.2 release has the same behaviour.

OS: Arch Linux x86_64
Kernel: 6.6.6-zen1-1-zen
DE: Plasma 5.27.10
CPU: Intel i5-4670K (4) @ 3.800GHz
GPU: NVIDIA GeForce GTX 970
Memory: 10565MiB / 32036MiB
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9538 [ardour] bugs major always 2023-11-15 12:03 2023-12-14 12:44
Reporter: finotti Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tempo changes after signature change misplaced
Description: When trying to add a new tempo after some signature switches, the new marker does not match the bar (or place clicked).
Tags: tempo change, time signature
Steps To Reproduce: * Create new session.
* Add a 5/8 time signature in bar 2.
* Add a 4/4 time signature in bar 3.
* Right-click on bar 3 to add a new tempo (at bar 3).
* The new tempo marker is placed 1/2 a beat after the start of bar 3 instead of at the start.

Also, using the grid mode tool (edit tempo-map), I cannot click on bar 3 to adjust the tempo.
Additional Information:
System Description
Attached Files:
Notes
(0028421)
finotti   
2023-12-14 12:44   
Bug remains in version 8.2.

Just so I know if I should move on to a different project, is there any chance this might get fixed in the (somewhat) near future? (No pressure, of course. Again, just so I know how to manage my projects. The current one was my priority, and if I move to a new one, it will be a while before I can get back to it. But it is just my "hobby", so that would be OK.)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9480 [ardour] bugs crash always 2023-10-13 09:49 2023-12-14 10:37
Reporter: clemence.aumond@proton.me Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes while scanning vst
Description: 2023-10-13T11:37:15 [INFO]: Scanning folders for bundled LV2s: /opt/Ardour-8.0.0/lib/LV2
2023-10-13T11:37:15 [WARNING]: LV2<http://kxstudio.sf.net/carla/plugins/carlapatchbaycv>: Port 7 ('CV Input 1') has no known data type
2023-10-13T11:37:15 [WARNING]: LV2<http://kxstudio.sf.net/carla/plugins/carlapatchbaycv>: Port 8 ('CV Input 2') has no known data type
2023-10-13T11:37:15 [WARNING]: LV2<http://kxstudio.sf.net/carla/plugins/carlapatchbaycv>: Port 9 ('CV Input 3') has no known data type
2023-10-13T11:37:15 [WARNING]: LV2<http://kxstudio.sf.net/carla/plugins/carlapatchbaycv>: Port 10 ('CV Input 4') has no known data type
2023-10-13T11:37:15 [WARNING]: LV2<http://kxstudio.sf.net/carla/plugins/carlapatchbaycv>: Port 11 ('CV Input 5') has no known data type
2023-10-13T11:37:15 [WARNING]: LV2<http://kxstudio.sf.net/carla/plugins/carlapatchbaycv>: Port 12 ('CV Output 1') has no known data type
2023-10-13T11:37:15 [WARNING]: LV2<http://kxstudio.sf.net/carla/plugins/carlapatchbaycv>: Port 13 ('CV Output 2') has no known data type
2023-10-13T11:37:15 [WARNING]: LV2<http://kxstudio.sf.net/carla/plugins/carlapatchbaycv>: Port 14 ('CV Output 3') has no known data type
2023-10-13T11:37:15 [WARNING]: LV2<http://kxstudio.sf.net/carla/plugins/carlapatchbaycv>: Port 15 ('CV Output 4') has no known data type
2023-10-13T11:37:15 [WARNING]: LV2<http://kxstudio.sf.net/carla/plugins/carlapatchbaycv>: Port 16 ('CV Output 5') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/2Voices>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#fixedBlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/2Voices>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#powerOf2BlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/Capo>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#fixedBlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/Capo>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#powerOf2BlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/Drop>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#fixedBlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/Drop>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#powerOf2BlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/Harmonizer>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#fixedBlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/Harmonizer>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#powerOf2BlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/Harmonizer2>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#fixedBlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/Harmonizer2>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#powerOf2BlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/HarmonizerCS>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#fixedBlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/HarmonizerCS>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#powerOf2BlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/SuperCapo>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#fixedBlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/SuperCapo>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#powerOf2BlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/SuperWhammy>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#fixedBlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/SuperWhammy>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#powerOf2BlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-mono>: Port 1 ('Pitch') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-mono>: Port 2 ('Velocity') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-mono>: Port 3 ('Gate') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-poly>: Port 1 ('Pitch 1') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-poly>: Port 2 ('Pitch 2') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-poly>: Port 3 ('Pitch 3') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-poly>: Port 4 ('Pitch 4') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-poly>: Port 5 ('Velocity') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-poly>: Port 6 ('Gate 1') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-poly>: Port 7 ('Gate 2') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-poly>: Port 8 ('Gate 3') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/midi-to-cv-poly>: Port 9 ('Gate 4') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-audio-to-cv>: Port 1 ('CV Output') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-abs>: Port 0 ('CV Input') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-abs>: Port 1 ('CV Output') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-attenuverter>: Port 0 ('CV Input') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-attenuverter>: Port 1 ('CV Output') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-clock>: Port 0 ('pulse') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-clock>: Port 1 ('square') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-control>: Port 0 ('CV Output') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-gate>: Port 0 ('Gate') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-gate>: Port 1 ('CV Input') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-gate>: Port 2 ('CV Output') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-meter>: Port 0 ('CV input') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-meter>: Port 1 ('CV Output') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-parameter-modulation>: Port 0 ('CV Input') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-parameter-modulation>: Port 1 ('CV Output') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-random>: Port 0 ('Gate In') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-random>: Port 1 ('CV Output') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-range>: Port 0 ('CV Input') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-range>: Port 1 ('CV Output1') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-range>: Port 2 ('CV Output2') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-round>: Port 0 ('CV Input') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-round>: Port 1 ('Round') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-round>: Port 2 ('Ceil') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-round>: Port 3 ('Floor') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-round>: Port 4 ('Fraction') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-slew>: Port 0 ('CV Input') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-slew>: Port 1 ('CV Output') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch1>: Port 0 ('CV in') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch1>: Port 1 ('CV out1') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch1>: Port 2 ('CV out2') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch2>: Port 0 ('CV in1') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch2>: Port 1 ('CV in2') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch2>: Port 2 ('CV out') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch3>: Port 0 ('CV in') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch3>: Port 1 ('CV out1') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch3>: Port 2 ('CV out2') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch3>: Port 3 ('CV out3') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch4>: Port 0 ('CV in1') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch4>: Port 1 ('CV in2') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch4>: Port 2 ('CV in3') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://moddevices.com/plugins/mod-devel/mod-cv-switch4>: Port 3 ('CV out') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<http://ssj71.github.io/infamousPlugins/plugs.html#envfollowerCV>: Port 2 ('CV Out') has no known data type
2023-10-13T11:37:17 [WARNING]: LV2<https://github.com/HiFi-LoFi/KlangFalter>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#fixedBlockLength'.
2023-10-13T11:37:17 [WARNING]: LV2<urn:juce:Vex>: Unsupported required LV2 feature: 'http://lv2plug.in/ns/ext/buf-size#fixedBlockLength'.
Tags: VST
Steps To Reproduce: jack or Alsa
with a new session
without french traduction
Additional Information:
System Description
Attached Files:
Notes
(0028195)
x42   
2023-10-13 19:58   
This is all fine, those are only warnings and normal for the plugins at hand (LV2 plugins not VST).

When does Ardour crash? directly at startup? Can you get a crash-report: https://ardour.org/debugging_ardour
(0028212)
clemence.aumond@proton.me   
2023-10-16 09:30   
Yes, directly
(0028420)
clemence.aumond@proton.me   
2023-12-14 10:37   
Same with 8.1 and 8.2

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9570 [ardour] bugs minor sometimes 2023-12-12 16:38 2023-12-13 21:39
Reporter: Addyl Platform: Apple Macintosh  
Assigned To: paul OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: assigned Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Activate Au Guitar Rig 6
Description: It is hard to activate Au Guitar Rig 6. Vst is easy to activate. Ardour 8.1
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028417)
paul   
2023-12-13 19:35   
Why is it hard?
(0028418)
Addyl   
2023-12-13 21:39   
Hi, I click on the activate mark and notthing happens, I can't hear the Guitar rig working! I try instead the Vst version and it works.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9568 [ardour] bugs minor always 2023-12-07 17:59 2023-12-13 17:46
Reporter: automaciej Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Slow operations on markers
Description: Initially discussed in https://discourse.ardour.org/t/slow-operations-on-markers/109587

A session with 0000010:0000030 regions and 0000102:0000120 markers is slow to make operations on markers.

Slow operations:
Session load
Opening the side panel with the list of markers (shift+L)
Adding / removing markers
Tags: performance
Steps To Reproduce: Import/open the attached session. Open the side panel (shift+L). Try adding a marker and/or removing a marker.

Expected: Operation is near instantaneous.

Observed: There's a spike in CPU usage / one saturated core, for a good few seconds. The desktop opes a dialog saying that Ardour is not responding and asking if I want to force-quit or wait.
Additional Information: Ardour generally works, and it's enough to wait for the marker to be created or removed.

I couldn't reproduce the issue by creating a new session and tapping Tab 120 times.
The issue remained after I removed all the tracks and all the audio sources from the session.
I couldn't pinpoint what exactly about the markers and/or regions makes them slow, because the slowness built up gradually over time. But the slowness is persistent, and I verified that does persist in the session archive I'm uploading.
System Description
Attached Files: Slow markers repro.ardour-session-archive (55,525 bytes) 2023-12-07 17:59
https://tracker.ardour.org/file_download.php?file_id=4737&type=bug
Notes
(0028400)
x42   
2023-12-08 16:44   
Thanks for the session. That helped to track down the issue.
The Slowdown problem is now fixed since Ardour 8.1.156. It was caused by a significant amount of Section and Location Markers.

There is still an issue with your session when undoing a marker change. That apparently results in an endless loop.
(0028402)
automaciej   
2023-12-09 15:47   
I downloaded Ardour-8.1.164 and I can confirm that adding and removing markers are now fast. Thank you!

I'll avoid undoing marker changes for now.
(0028403)
automaciej   
2023-12-09 21:57   
I worked some more using Ardour 8.1.164.

- Loading the session is much faster
- Adding and removing markers is fast just like in an new/empty session
- Opening the markers pane (shift+L) is still slow
- Undoing a marker change is indeed still slow and/or maybe doesn't even work at all, I'm not sure. I realized that I can't avoid undoing marker changes - if I work with markers, and I need to undo a sequence of steps, there's no way other than trying to undo a marker change. Today I tried to undo a chance, I eventually gave up on the undo and instead used an earlier saved session and redid a small amount of work.
(0028404)
x42   
2023-12-10 03:48   
It helps significantly if you never show the Location list or the sidebar. Then undo/redo works just fine.

Once the location UI and/or the sidebar version is shown, here, it can take up to 15 sec here with your session to re-populate that pane.
(0028415)
automaciej   
2023-12-13 13:40   
The location UI is important to my workflow, I use it to navigate around the session. But fortunately I don't use the undo option too often, and I try to separate the times when I work with markers (which don't need undo generally) and when I work with regions (where I need to undo quite often).

I'm wonder what is it about my session that is a challenge for Ardour? It's not like it's millions of markers or millions of regions. Is it about some sort of relationship between the two?
(0028416)
x42   
2023-12-13 17:46   
It's just that GTK performance sucks if there are more than 64 elements in a box - It's entirely a GUI issue.
undo/redo restores the whole state and if locations were added/removed the LocationUI is repopuplated, which can take ages.

Perhaps use the mini-timeline at the top to navigate?

I've checked with a few thousand locations and everything's fine as long as I never show the Location List, and I don't see a way to fix the UI performance of that right now.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9565 [ardour] bugs minor always 2023-12-04 16:45 2023-12-11 15:42
Reporter: herwinc Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: synth plugins on midi busses get reset with cues at end loop
Description: synth lv2 plugins like zyn-fusion, surge xt and helm when put on the midi busses used to play cues (bounced from regions of midi) get reset to their default instrument at the end of the first loop.
Tags: 7.3
Steps To Reproduce: synth plugin on midi bus
set a custom sound
bounce region of midi to a slot
play the cue or slot
result: first loop plays custom sound,
later loops play the default sound (synth seem to be reset after first loop)
Additional Information: tried different synths, same result
same synths in clara and midi from ardour (via vcv rack) to synth, keeps the set custom sound.

nice to have:
to be able to edit the source midi and have the bounced loop changed, or
to be able to edit the bounced midi.
to be able to delete or rename loops in the list
System Description
Attached Files:
Notes
(0028405)
Schmitty2005   
2023-12-11 15:42   
This is caused by the 'Send Patches' being enabled for the clip. On the CUE page, click on the specific clip within the cue track. At the bottom you should see a button labeled 'Send Patches'. Make sure it is not enabled. Otherwise, it does send a patch change, which would likely be the first patch. I had the exact same issue, and disabling 'Send Patches' resolved it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9567 [ardour] bugs crash always 2023-12-07 17:03 2023-12-07 17:03
Reporter: avard Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Dragging end-of-session marker crashes
Description: Dragging the end-location marker crashes ardour. Tried in some various sessions, same behavior:

uname -a -> Linux sigla 6.6.3-100.fc38.x86_64 0000001 SMP PREEMPT_DYNAMIC Tue Nov 28 20:36:17 UTC 2023 x86_64 GNU/Linux

ardour8 built from sources from master @ git this morning, seems to be the same behavior if building from the current tarball.

The current ardour8.1.0 ("The Drop") from my fedora-distro is fine however. Sorry, i dont have much info about those sources...
Tags:
Steps To Reproduce: new session; import an audio-file, try to drag end-of-session marker
Additional Information:
System Description
Attached Files: drag-regions-gdb.core.dump_2023-12-07-16:30 (150,216 bytes) 2023-12-07 17:03
https://tracker.ardour.org/file_download.php?file_id=4736&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9566 [ardour] bugs major always 2023-12-06 04:12 2023-12-06 04:14
Reporter: bonesofwrath Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bouncing MIDI tracks can result in stuck notes.
Description: When bouncing MIDI tracks, some notes appear stuck and carry on until retriggered.
Tags:
Steps To Reproduce: Create two MIDI tracks with no plugins via import
Create an empty MIDI track
Hook up MIDI 1,2 outputs to MIDI 3 and bounce
Additional Information:
System Description
Attached Files: regent_square.mid (1,334 bytes) 2023-12-06 04:12
https://tracker.ardour.org/file_download.php?file_id=4731&type=bug
merge-bug.ardour (68,219 bytes) 2023-12-06 04:12
https://tracker.ardour.org/file_download.php?file_id=4732&type=bug
merge-bug.tgz (112,640 bytes) 2023-12-06 04:14
https://tracker.ardour.org/file_download.php?file_id=4733&type=bug
Notes
(0028389)
bonesofwrath   
2023-12-06 04:14   
Session file - Replaces previous attachment

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8736 [ardour] bugs minor always 2021-06-08 01:20 2023-12-06 00:47
Reporter: Sitruc55 Platform: x86  
Assigned To: x42 OS: Fedora  
Priority: normal OS Version: 34  
Status: resolved Product Version: 6.7  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Import hangs
Description: When trying to import any midi file Ardour hangs upon starting import. Preview of the midi file works fine
Tags:
Steps To Reproduce: Start new project and try to import midi file
Additional Information: Nothing in log file. Must force terminate Ardour to recover
System Description
Attached Files: Cest-si-bon.midi (3,138 bytes) 2021-06-09 02:05
https://tracker.ardour.org/file_download.php?file_id=4058&type=bug
midi_import.png (158,119 bytes) 2021-06-09 02:26
https://tracker.ardour.org/file_download.php?file_id=4059&type=bug
png
Notes
(0025929)
x42   
2021-06-09 01:39   
Importing MIDI files works just fine here. Is this specific to a given .mid file, and if so, can you share that?
What synth do you use when importing MIDI files? Perhaps the issue at hand is the synth plugin?
(0025930)
Sitruc55   
2021-06-09 02:05   
It hangs at the import progress dialog pop-up with no progress shown. Clicking on cancel does nothing and I have to hard terminate Ardour 6.7.
I've tried several different midi files and synths (sfizz, ACE Reasonable synth, ACE fluid synth). Just now I tried to import cest-si-bon.midi using the default ACE Reasonable Synth and it hung-up. I've attached that midi file.
Could this be pipewire 0.3.29 related? There's nothing strange about my set-up and it use to work fine. I also see this in the system log file:

6/8/21 7:02 PM pipewire protocol-native 0x55d3146f8e40: client 0x55d31483e860 error -22 (Invalid argument)

followed by hundreds or more of:

6/8/21 7:04 PM localhost plasmashell[9080] Command [V,R,I,A]:
(0025931)
x42   
2021-06-09 02:26   
The file imports just fine here (using general MIDI synth which comes with Ardour from ardour.org/download)

So either it is indeed PW related, easy to test try Ardour/ALSA or a Pulseaudio, or perhaps some issue with your Ardour built. Is that the official binary from ardour.org?
(0025932)
Sitruc55   
2021-06-09 03:28   
I got Ardour 6.7 from the RPM in the
Fedora jam 34 repository. I don't seem to have the alsa-backend available at the moment, will look into it tomorrow. From the log error it seems to be pw related, I could try to submit an bug report with them. Thanks
(0025934)
x42   
2021-06-09 14:35   
It's an odd choice but Fedora packages Ardour backends (ALSA, Dummy, JACK, etc) separately.
Trying without pipewire first is a good idea. If that works then yes it's a PW issue.
(0025935)
Sitruc55   
2021-06-09 17:06   
I'm unable to select the alsa-backend

I found what looks like a related issue on pipewire gitlab.freedesktop.org. I added a comment to end linking in this report:

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1265
(0025938)
x42   
2021-06-09 20:11   
see also https://tracker.ardour.org/view.php?id=8738 which is apparently fixed in pipewire v0.3.30.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9564 [ardour] features feature have not tried 2023-12-04 04:57 2023-12-04 04:57
Reporter: mtf8 Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add preference to allow user to set default track height
Description: As of now, every track defaults to a size of "normal" which is a completely subjective term. I see Ardour has these canned sizes in the form of small, normal, large, larger, and largest but it's probably time to evolve from that?

Perhaps redefining "normal" in some way as a preference under Preferences, Appearance, Editor would provide a more simple baseline which then would be used to zoom by another user defined step increment. If that refactoring could be done, Ardour would be able to ditch the canned sizes and users would end up having a more simple and customizable environment.
Tags:
Steps To Reproduce:
Additional Information: Please consider how this idea might interact with another zoom-related toggle feature I mention over at https://tracker.ardour.org/view.php?id=9563
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9549 [ardour] bugs minor always 2023-11-25 14:39 2023-12-04 03:23
Reporter: Didi Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: klicking on the Pianoroll shrinks track window
Description: I am new to Linux AND Ardour is my first DAW, So I better tell you in my words first:
Installed Ardour 7.x from AVLMX 21.3 distribution and updated to 8.0 and 8.1 from the ARDOUR Website.
Problem:

 doubleklick on a pianoroll note collapses Track window to height "small"
Tags: Ardour 8.0" pianoroll
Steps To Reproduce: 1. enlarging a Track to see the pianoroll
2. single klick on the pr to listen to the corresponding sound ..... no prob!
3. doubleklick on the same pianoroll note collapses Track window to height "small"
Additional Information:
Attached Files:
Notes
(0028361)
Didi   
2023-11-25 14:49   
Only happens, when doubleclicking the same note on the pianoroll! Not when fast clicking between different notes!
(0028362)
Didi   
2023-11-25 16:25   
Have to correct myself!
track field collapses to "normal" not to "small!"
anyway, shold not collapse at all, but stay in the enlarged height!
(0028386)
mtf8   
2023-12-04 03:23   
I see this bug on Ardour 8.1.0.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9563 [ardour] features feature have not tried 2023-12-04 03:20 2023-12-04 03:20
Reporter: mtf8 Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make f keybinding, "Fit Selection (Vertical)" a toggle.
Description: The current workflow involving f and shift-z seems and feels both odd and unpredictable.

It would be far simpler to have "f" essentially toggle between making a track as large and then, as small as possible. One key to use in order to focus one's attention on a given track and then easy shrink it back down in order to move attention to something else.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9558 [ardour] bugs major always 2023-11-30 12:23 2023-11-30 12:24
Reporter: finotti Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot Import MIDI file
Description: Importing the MIDI file attached, I get only 3 bars, with not apparent content. I see some letters and numbers on top of the tracks that are unfamiliar to me. (See attached image.)

I can play the file with VLC and import it with Muse.
Tags: midi import
Steps To Reproduce: * Create new session
* Session -> Import
* Select file ("deadof.mid")
* Check "Use MIDI Tempo Map" and "Import MIDI Markers" (Optional)
* Choose "Mapping" as "One track per channel"
* Import
Additional Information:
System Description
Attached Files: deadof.mid (75,496 bytes) 2023-11-30 12:23
https://tracker.ardour.org/file_download.php?file_id=4725&type=bug
Screenshot_20231130_072238.png (309,326 bytes) 2023-11-30 12:23
https://tracker.ardour.org/file_download.php?file_id=4726&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9507 [ardour] bugs major always 2023-10-24 12:20 2023-11-29 12:31
Reporter: prokoudine Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unfreezing a region removes it from the timeline
Description: When you unfreeze an audio region, it is immediatey removed from the timeline and the regions list, and this cannot be undone.
Tags:
Steps To Reproduce: 1. Select a region
2. Freeze it
3. Select it again
4. Unfreeze it
5. The region is immediatey removed from the timeline and the regions list, and this cannot be undone
Additional Information:
System Description
Attached Files: ardour_freeze_crash_backtrace.txt (35,657 bytes) 2023-10-26 16:53
https://tracker.ardour.org/file_download.php?file_id=4684&type=bug
Notes
(0028256)
skygge   
2023-10-25 14:51   
In my case "Freeze" is crashing Ardour with core dumped, only if multiple regions are on a single track. If I have single region on a track then Freeze and Unfreeze works as expected.
(0028257)
x42   
2023-10-26 14:15   
I cannot reproduce either issue. Freeze unfreeze works reliably here with multiple regions.

Can you provide a backtrace of the crash?
(0028258)
skygge   
2023-10-26 16:53   
Voilà!
(0028374)
x42   
2023-11-29 12:31   
This should be fixed since Ardour 8.1-115-g4647dd6b41

Please test.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9539 [ardour] bugs crash always 2023-11-17 12:46 2023-11-29 12:29
Reporter: gusnan Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Selecting Freeze on a Region crashes Ardour
Description: Right-clicking on a Region, and selecting Freeze shows a progress bar, and when it's at the end, Ardour crashes. This is on Debian 12, ardour installed from the "Ready-to-run program" download, Ardour-8.1.0-x86_64.run.

Tags:
Steps To Reproduce: As the description, simply use right-click Freeze on a region and it will crash after a progress-bar.
Additional Information: Full gdb session (But not with a lot of debug symbols, even though I ran Ardour with --gdb):

usnan@debian-i7:~ > /opt/Ardour-8.1.0/bin/ardour8 --gdb
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/Ardour-8.1.0/bin/ardour-8.1.0...
(No debugging symbols found in /opt/Ardour-8.1.0/bin/ardour-8.1.0)
(gdb) run
Starting program: /opt/Ardour-8.1.0/bin/ardour-8.1.0
BFD: error: /usr/lib/debug/.build-id/b5/94dc721d75112eb9f2aa7a2c0ae957f373d962.debug(.debug_info) is too large (0x15ef54 bytes)
warning: Can't read data for section '.debug_info' in file '/usr/lib/debug/.build-id/b5/94dc721d75112eb9f2aa7a2c0ae957f373d962.debug'
warning: Section .debug_aranges in /usr/lib/debug/.build-id/b5/94dc721d75112eb9f2aa7a2c0ae957f373d962.debug entry at offset 0 debug_info_offset 0 does not exists, ignoring .debug_aranges.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Ardour8.1.0 (built using 8.1 och GCC version 6.3.0 20170516)
[New Thread 0x7ffff613d6c0 (LWP 20947)]
Ardour: [INFO]: Your system is configured to limit Ardour to 1048576 open files
Ardour: [INFO]: Loading system configuration file /opt/Ardour-8.1.0/etc/system_config
Ardour: [INFO]: Loading user configuration file /home/gusnan/.config/ardour8/config
[New Thread 0x7fffe0fff6c0 (LWP 20948)]
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
Ardour: [INFO]: Using AVX and FMA optimized routines
[New Thread 0x7fffdbfff6c0 (LWP 20949)]
[New Thread 0x7fffdb7fe6c0 (LWP 20950)]
[New Thread 0x7fffdaffd6c0 (LWP 20951)]
Ardour: [INFO]: Loading plugin meta data file /opt/Ardour-8.1.0/share/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin meta data file /home/gusnan/.config/ardour8/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/gusnan/.config/ardour8/plugin_metadata/plugin_stats
Ardour: [INFO]: add_lrdf_data '/home/gusnan/.config/ardour8/rdf:/opt/Ardour-8.1.0/share/rdf:/usr/local/share/ladspa/rdf:/usr/share/ladspa/rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/guitarix.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/swh-aux.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/swh-plugins.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/ladspa.rdfs'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/swh-scales.rdf'
[New Thread 0x7fffda7fc6c0 (LWP 20952)]
[Thread 0x7fffda7fc6c0 (LWP 20952) exited]
[New Thread 0x7fffda7fc6c0 (LWP 20953)]
[Thread 0x7fffda7fc6c0 (LWP 20953) exited]
[New Thread 0x7fffda7fc6c0 (LWP 20954)]
[New Thread 0x7fffc4bff6c0 (LWP 20955)]
[New Thread 0x7fffbebff6c0 (LWP 20956)]
Cannot xinstall SIGPIPE error handler
Ardour: [INFO]: Loading default ui configuration file /opt/Ardour-8.1.0/etc/default_ui_config
Ardour: [INFO]: Loading 457 MIDI patches from /opt/Ardour-8.1.0/share/patchfiles
Ardour: [INFO]: Loading user ui configuration file /home/gusnan/.config/ardour8/ui_config
/usr/share/themes/Clearlooks-Phenix/gtk-2.0/gtkrc:79: error: unexpected identifier 'reliefstyle', expected character '}'
Ardour: [INFO]: Loading color file /opt/Ardour-8.1.0/share/themes/dark-ardour.colors
/usr/share/themes/Clearlooks-Phenix/gtk-2.0/gtkrc:79: error: unexpected identifier 'reliefstyle', expected character '}'
Ardour: [INFO]: Loading ui configuration file /opt/Ardour-8.1.0/etc/clearlooks.rc
Ardour: [INFO]: Loading bindings from /opt/Ardour-8.1.0/etc/ardour.keys
Loading ui configuration file /opt/Ardour-8.1.0/etc/clearlooks.rc
[New Thread 0x7ffff418a6c0 (LWP 20957)]
[New Thread 0x7fffbdfff6c0 (LWP 20958)]
[Thread 0x7fffbdfff6c0 (LWP 20958) exited]
[New Thread 0x7fffbdfff6c0 (LWP 20959)]
[New Thread 0x7fffbd7fe6c0 (LWP 20960)]
[New Thread 0x7fffbcffd6c0 (LWP 20961)]
[New Thread 0x7fffa3fff6c0 (LWP 20962)]
[New Thread 0x7fffa37fe6c0 (LWP 20963)]
[New Thread 0x7fff9bfff6c0 (LWP 20964)]
[New Thread 0x7fffa2ffd6c0 (LWP 20965)]
[New Thread 0x7fffa27fc6c0 (LWP 20966)]
Found nothing along /home/gusnan/.config/ardour8/templates:/opt/Ardour-8.1.0/share/templates
[Thread 0x7ffff418a6c0 (LWP 20957) exited]
[Thread 0x7fffa2ffd6c0 (LWP 20965) exited]
[Thread 0x7fff9bfff6c0 (LWP 20964) exited]
[Thread 0x7fffbcffd6c0 (LWP 20961) exited]
[Thread 0x7fffa27fc6c0 (LWP 20966) exited]
[Thread 0x7fffa3fff6c0 (LWP 20962) exited]
[Thread 0x7fffbd7fe6c0 (LWP 20960) exited]
[Thread 0x7fffbebff6c0 (LWP 20956) exited]
[New Thread 0x7fffa3fff6c0 (LWP 20970)]
[New Thread 0x7ffff35fe900 (LWP 20971)]
[New Thread 0x7fffa27fc6c0 (LWP 20973)]
[New Thread 0x7fffbcffd6c0 (LWP 20974)]
[New Thread 0x7fff9bfff6c0 (LWP 20975)]
[New Thread 0x7fffbd7fe6c0 (LWP 20976)]
[New Thread 0x7fffa2ffd6c0 (LWP 20977)]
[New Thread 0x7fffa1ffb6c0 (LWP 20978)]
[Detaching after vfork from child process 20979]
[New Thread 0x7fffa17fa6c0 (LWP 20980)]
[Thread 0x7fff9bfff6c0 (LWP 20975) exited]
[Thread 0x7fffa27fc6c0 (LWP 20973) exited]
[Thread 0x7fffa2ffd6c0 (LWP 20977) exited]
[Thread 0x7fffbd7fe6c0 (LWP 20976) exited]
[Thread 0x7fffa1ffb6c0 (LWP 20978) exited]
[Thread 0x7fffa37fe6c0 (LWP 20963) exited]
[Thread 0x7fffa17fa6c0 (LWP 20980) exited]
[Detaching after vfork from child process 20981]
[New Thread 0x7fffa17fa6c0 (LWP 20982)]
[Thread 0x7fffa17fa6c0 (LWP 20982) exited]
Set cursor set to default
[New Thread 0x7fffa17fa6c0 (LWP 20983)]
[New Thread 0x7ffff316e900 (LWP 20984)]
[New Thread 0x7ffff30ea900 (LWP 20985)]
[New Thread 0x7ffff2dfe900 (LWP 20986)]
[New Thread 0x7ffff25fe900 (LWP 20987)]
[New Thread 0x7ffff257a900 (LWP 20988)]
[New Thread 0x7ffff24f6900 (LWP 20989)]
[New Thread 0x7ffff21fe900 (LWP 20990)]
[New Thread 0x7fffee9ff6c0 (LWP 20991)]
[New Thread 0x7fffa37fe6c0 (LWP 20992)]
Setting time domain
[New Thread 0x7fffa1ffb6c0 (LWP 20993)]
[New Thread 0x7fffbd7fe6c0 (LWP 20994)]
[New Thread 0x7fff9bfff6c0 (LWP 20995)]
[New Thread 0x7fff9b7fe6c0 (LWP 20996)]
[New Thread 0x7fff9affd6c0 (LWP 20997)]
[Thread 0x7fffbcffd6c0 (LWP 20974) exited]
[New Thread 0x7fffbcffd6c0 (LWP 21003)]
[New Thread 0x7fff99ffc6c0 (LWP 21004)]
[New Thread 0x7fff997fb6c0 (LWP 21005)]
[New Thread 0x7fff98ffa6c0 (LWP 21006)]
[New Thread 0x7fff5bfff6c0 (LWP 21007)]
[New Thread 0x7fff5b7fe6c0 (LWP 21008)]
[New Thread 0x7fff5affd6c0 (LWP 21009)]
[Thread 0x7fffa17fa6c0 (LWP 20983) exited]
[New Thread 0x7fffa17fa6c0 (LWP 21400)]
[Thread 0x7fffa17fa6c0 (LWP 21400) exited]
[New Thread 0x7fffa17fa6c0 (LWP 21793)]
[Thread 0x7fffa17fa6c0 (LWP 21793) exited]

Thread 1 "ArdourGUI" received signal SIGSEGV, Segmentation fault.
0x000055555f380c80 in ?? ()
(gdb) bt full
#0 0x000055555f380c80 in ?? ()
No symbol table info available.
0000001 0x00005555561db491 in ?? ()
No symbol table info available.
#2 0x00005555560cda6b in ?? ()
No symbol table info available.
#3 0x0000555555b647e8 in ?? ()
No symbol table info available.
0000004 0x000055555591ef0a in sigc::internal::signal_emit0<void, sigc::nil>::emit(sigc::internal::signal_impl*) ()
No symbol table info available.
0000005 0x0000555555a4fa62 in ?? ()
No symbol table info available.
#6 0x00007ffff466cc35 in AbstractUI<Gtkmm2ext::UIRequest>::call_slot(PBD::EventLoop::InvalidationRecord*, boost::function<void ()> const&) ()
   from /opt/Ardour-8.1.0/lib/libgtkmm2ext.so.0
No symbol table info available.
#7 0x0000555555a556d8 in ?? ()
No symbol table info available.
0000008 0x0000555555a4bd0b in ?? ()
No symbol table info available.
0000009 0x000055555599155f in ?? ()
No symbol table info available.
0000010 0x000055555598d1ea in ?? ()
No symbol table info available.
0000011 0x000055555598d499 in ?? ()
No symbol table info available.
0000012 0x00005555561daac2 in ?? ()
No symbol table info available.
0000013 0x00005555561ddb13 in ?? ()
No symbol table info available.
0000014 0x00005555561dfd04 in ?? ()
No symbol table info available.
#15 0x00005555558ee5be in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void ()>, boost::_bi::list0>, void>::invoke(boost::detail::function::function_buffer&) ()
No symbol table info available.
0000016 0x00007ffff46673b8 in Gtkmm2ext::UI::do_request(Gtkmm2ext::UIRequest*) () from /opt/Ardour-8.1.0/lib/libgtkmm2ext.so.0
No symbol table info available.
#17 0x00007ffff466d5e5 in AbstractUI<Gtkmm2ext::UIRequest>::handle_ui_requests() () from /opt/Ardour-8.1.0/lib/libgtkmm2ext.so.0
No symbol table info available.
0000018 0x00007ffff422d959 in BaseUI::request_handler(Glib::IOCondition) () from /opt/Ardour-8.1.0/lib/libpbd.so.4
No symbol table info available.
0000019 0x00007ffff4239be9 in cross_thread_channel_call_receive_slot(_GIOChannel*, GIOCondition, void*) () from /opt/Ardour-8.1.0/lib/libpbd.so.4
No symbol table info available.
0000020 0x00007ffff2a5694a in g_main_context_dispatch () from /opt/Ardour-8.1.0/lib/libglib-2.0.so.0
No symbol table info available.
0000021 0x00007ffff2a56ce8 in ?? () from /opt/Ardour-8.1.0/lib/libglib-2.0.so.0
No symbol table info available.
0000022 0x00007ffff2a56d8c in g_main_context_iteration () from /opt/Ardour-8.1.0/lib/libglib-2.0.so.0
No symbol table info available.
0000023 0x00007ffff1b836e1 in gtk_main_iteration () from /opt/Ardour-8.1.0/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#24 0x0000555555b35fc5 in ?? ()
No symbol table info available.
0000025 0x00007ffff325e868 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /opt/Ardour-8.1.0/lib/libglibmm-2.4.so.1
No symbol table info available.
0000026 0x00007ffff2e0f6b5 in g_closure_invoke () from /opt/Ardour-8.1.0/lib/libgobject-2.0.so.0
No symbol table info available.
0000027 0x00007ffff2e22593 in ?? () from /opt/Ardour-8.1.0/lib/libgobject-2.0.so.0
No symbol table info available.
0000028 0x00007ffff2e2c364 in g_signal_emit_valist () from /opt/Ardour-8.1.0/lib/libgobject-2.0.so.0
No symbol table info available.
0000029 0x00007ffff2e2c7e2 in g_signal_emit () from /opt/Ardour-8.1.0/lib/libgobject-2.0.so.0
No symbol table info available.
0000030 0x00007ffff1d0935e in gtk_widget_activate () from /opt/Ardour-8.1.0/lib/libgtk-x11-2.0.so.0
No symbol table info available.
--Type <RET> for more, q to quit, c to continue without paging--
0000031 0x00007ffff1b9f882 in gtk_menu_shell_activate_item () from /opt/Ardour-8.1.0/lib/libgtk-x11-2.0.so.0
No symbol table info available.
0000032 0x00007ffff1b9fcd6 in ?? () from /opt/Ardour-8.1.0/lib/libgtk-x11-2.0.so.0
No symbol table info available.
0000033 0x00007ffff1b918d6 in ?? () from /opt/Ardour-8.1.0/lib/libgtk-x11-2.0.so.0
No symbol table info available.
0000034 0x00007ffff1b85d8c in ?? () from /opt/Ardour-8.1.0/lib/libgtk-x11-2.0.so.0
No symbol table info available.
0000035 0x00007ffff2e0f6b5 in g_closure_invoke () from /opt/Ardour-8.1.0/lib/libgobject-2.0.so.0
No symbol table info available.
0000036 0x00007ffff2e228bd in ?? () from /opt/Ardour-8.1.0/lib/libgobject-2.0.so.0
No symbol table info available.
0000037 0x00007ffff2e2bdc8 in g_signal_emit_valist () from /opt/Ardour-8.1.0/lib/libgobject-2.0.so.0
No symbol table info available.
0000038 0x00007ffff2e2c7e2 in g_signal_emit () from /opt/Ardour-8.1.0/lib/libgobject-2.0.so.0
No symbol table info available.
0000039 0x00007ffff1d0a7ac in ?? () from /opt/Ardour-8.1.0/lib/libgtk-x11-2.0.so.0
No symbol table info available.
0000040 0x00007ffff1b8437d in gtk_propagate_event () from /opt/Ardour-8.1.0/lib/libgtk-x11-2.0.so.0
No symbol table info available.
0000041 0x00007ffff1b84803 in gtk_main_do_event () from /opt/Ardour-8.1.0/lib/libgtk-x11-2.0.so.0
No symbol table info available.
0000042 0x00007ffff166fbbc in ?? () from /opt/Ardour-8.1.0/lib/libgdk-x11-2.0.so.0
No symbol table info available.
0000043 0x00007ffff2a56a87 in g_main_context_dispatch () from /opt/Ardour-8.1.0/lib/libglib-2.0.so.0
No symbol table info available.
0000044 0x00007ffff2a56ce8 in ?? () from /opt/Ardour-8.1.0/lib/libglib-2.0.so.0
No symbol table info available.
0000045 0x00007ffff2a57002 in g_main_loop_run () from /opt/Ardour-8.1.0/lib/libglib-2.0.so.0
No symbol table info available.
0000046 0x00007ffff1b834c7 in gtk_main () from /opt/Ardour-8.1.0/lib/libgtk-x11-2.0.so.0
No symbol table info available.
0000047 0x00007ffff46652b5 in Gtkmm2ext::UI::run(Receiver&) () from /opt/Ardour-8.1.0/lib/libgtkmm2ext.so.0
No symbol table info available.
0000048 0x000055555589d24e in ?? ()
No symbol table info available.
0000049 0x00007ffff54461ca in __libc_start_call_main (main=main@entry=0x55555589cdd0, argc=argc@entry=1, argv=argv@entry=0x7fffffffd0d8)
    at ../sysdeps/nptl/libc_start_call_main.h:58
        self = <optimized out>
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737488343256, -8498598182115354922, 0, 140737488343272, 0, 140737354125344, 8498598180501968598,
                8498577767925667542}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x7fffffffd0d8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
0000050 0x00007ffff5446285 in __libc_start_main_impl (main=0x55555589cdd0, argc=1, argv=0x7fffffffd0d8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffd0c8) at ../csu/libc-start.c:360
No locals.
0000051 0x00005555558a4f6a in ?? ()
No symbol table info available.
(gdb)
System Description
Attached Files:
Notes
(0028345)
paul   
2023-11-21 02:14   
fixed in commit 2bee43fef291

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9553 [ardour] bugs major always 2023-11-27 22:34 2023-11-29 01:28
Reporter: joachim Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour does not sanitize non-UTF-8 characters when importing MIDI
Description: A Reason project file had a unicode control character (U+0100) in one of the mixer channel names.
I exported this project as a MIDI file to re-do the project in Ardour.
I get multiple XML errors when re-opening the Ardour project.

Bug is similar to 0009317, but it seems a MIDI import can sidestep this.
Tags: Import, Midi, UTF-8
Steps To Reproduce: 1. Import the attached MIDI file.
2. Save the project
3. Close Ardour
4. Re-open the project.
Additional Information: Ardour rev 8.1-134-g3355e753bf
System Description
Attached Files: motorway_RSN12_2023-07-05.SquareLeadMIX-1.mid (523 bytes) 2023-11-27 22:34
https://tracker.ardour.org/file_download.php?file_id=4723&type=bug
U+0100_2023-11-27_233143.ardour-session-archive (6,193 bytes) 2023-11-27 22:34
https://tracker.ardour.org/file_download.php?file_id=4724&type=bug
Notes
(0028369)
x42   
2023-11-28 16:40   
This should be fixed since Ardour 8.1-139-g1306a698a7, Please test
(0028373)
joachim   
2023-11-29 01:28   
Fix comfirmed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9554 [ardour] bugs tweak always 2023-11-28 15:28 2023-11-28 16:40
Reporter: fweimer Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: C compatibility issue in localtime_r probe
Description: The localtime_r probe tries to return a pointer from main, which will be an error in future C compilers.

diff --git a/libs/pbd/wscript b/libs/pbd/wscript
index 06b285c79d..f9fc92dc0e 100644
--- a/libs/pbd/wscript
+++ b/libs/pbd/wscript
@@ -115,7 +115,7 @@ def configure(conf):
             define_name='HAVE_GETMNTENT', execute = False, mandatory=False)
     conf.check_cc(
             msg="Checking for function 'localtime_r' in time.h",
- fragment = "#include <time.h>\n int main(void) { return localtime_r(NULL, NULL); }\n",
+ fragment = "#include <time.h>\n int main(void) { return localtime_r(NULL, NULL) == 0; }\n",
             define_name='HAVE_LOCALTIME_R', execute = False, mandatory=False)
 
     # Boost headers
Tags:
Steps To Reproduce: Easiest with a instrumented compiler that logs such C compatibility issues.

Full build log is here: https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/blob/b64924b4082182b521aee43b362e3c070c163c1f/logs/a/ardour6.log
Additional Information:
System Description
Attached Files:
Notes
(0028368)
x42   
2023-11-28 16:40   
Thanks, fixed in Ardour 8.1-141-ga8c26dbfa4

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9542 [ardour] bugs crash always 2023-11-18 08:38 2023-11-27 13:02
Reporter: Federico Loi Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash with Hornet Plugins Tape Mk2
Description: Hi there, I don't know whether to report it here but I have problems with several Hornet plugins, some work badly or don't work, with others like Tape MK2, Ardor and Mixbus they crash.
I also reported the problem to the Hornet developers.
Thank you.
Tags: crash, plugin
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9551 [ardour] bugs minor have not tried 2023-11-26 18:52 2023-11-27 01:10
Reporter: erdavis7 Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: AU Plugin Patch Corruption with Native Instruments FM8
Description: After saving and reloading a file using the Native Instruments FM8 AU plugin, its patches are corrupted.
Tags:
Steps To Reproduce: 1. Create a track for the AU version of FM8. Add a single note. It should have the default sound of a sine wave.

2. Save and reload the file. The patch will have been corrupted, sounding like silence, static, or some other strange thing.
Additional Information:
System Description
Attached Files:
Notes
(0028363)
erdavis7   
2023-11-26 23:02   
I tried using FM8 with the Reaper DAW for comparison, and it works there without problems. Ardour has my favorite interface of any DAW I've tried, though, so I'd really rather not use Reaper, even though it seems to currently be more stable with MIDI.

Thanks to the devs for the great work that they have done.
(0028366)
erdavis7   
2023-11-27 01:10   
When using the VST2 version of FM8, this problem does not happen, so I will just do that.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9550 [ardour] bugs minor always 2023-11-26 18:35 2023-11-26 18:35
Reporter: erdavis7 Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Single-Point MIDI Automation Bug
Description: If a region contains a single automation point at the beginning of a region:

1. Its value will fail to be emitted (see Steps to Reproduce).
2. The point will disappear when the file is saved and reloaded (which is why I am unable to upload an example file).
Tags: automation
Steps To Reproduce: 1. In a single MIDI track, create two regions, each a single beat in length, the first starting on measure 1, and the second starting on measure 2.

2. Add a 16th note to the first beat of each region.

3. Automate a MIDI parameter, e.g. "Sustain On/Off". On the first beat of the first region, add a single point setting the sustain to maximum (on). On the first beat of the second region, add a single point setting the sustain to minimum (off).

4. Play the file from the beginning. If the last point you edited was at maximum, the sustain will remain on for both regions. If the last point you edited was at minumum, the sustain will remain off for both regions. The actual automated points seem to be ignored.

5. Save the file and reload it. Both of the automation points will have disappeared.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5608 [ardour] features feature N/A 2013-07-21 15:55 2023-11-23 10:54
Reporter: Leatuspenguin Platform:  
Assigned To: paul OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 3.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Velocity track idea
Description: The one midi feature which is currently lacking is the lack of proper velocity editing. Unless there's something i'm unaware of, the only current way is to edit individual note velocity, or groups of notes together. The only visual way of telling the velocities of multiple notes is via colour intensity.

One solution to this, and without bringing a whole new window into the equation, would be to make use of an automation track to edit note velocities. I have included a mock up, influenced by qtractors velocity editing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: velocity track.png (137,658 bytes) 2013-07-21 15:55
https://tracker.ardour.org/file_download.php?file_id=2217&type=bug
png

Ardour_MIDI_Velocity_channel.png (31,833 bytes) 2014-12-24 02:08
https://tracker.ardour.org/file_download.php?file_id=2488&type=bug
png

out.patch (5,825 bytes) 2018-06-26 17:31
https://tracker.ardour.org/file_download.php?file_id=3402&type=bug
Velocity_Editor.png (201,856 bytes) 2018-06-29 05:49
https://tracker.ardour.org/file_download.php?file_id=3404&type=bug
png

thinnervline_01.patch (1,055 bytes) 2018-07-08 06:14
https://tracker.ardour.org/file_download.php?file_id=3409&type=bug
Simple_Velocity_Automation_Lane.jpg (115,291 bytes) 2018-07-13 03:38
https://tracker.ardour.org/file_download.php?file_id=3412&type=bug
jpg

ghostlollipop_patch.diff (3,928 bytes) 2018-07-17 10:16
https://tracker.ardour.org/file_download.php?file_id=3413&type=bug
Notes
(0015150)
x42   
2013-07-21 16:46   
Do you have any idea how that can work with polyphony, as well?
(0015151)
Leatuspenguin   
2013-07-21 17:44   
I never thought about that. It was just an idea i had that i thought I'd throw out there. Thinking about it now, i see what you mean. Automation tracks only works on one parameter at a time. So there's no way it could work with an automation track without a lot of work? Is it feasible at all or are there any other thoughts about velocity editing at the moment?
(0015158)
paul   
2013-07-23 02:46   
its not a problem with automation track limits per se.

its a problem with conditions that involve chords. how do you edit the velocity of just one of the notes?
(0015159)
paul   
2013-07-23 02:48   
i suspect lines, not bar charts, will be the likely solution to this, btw. doesn't fully solve the polyphony design problem, but it would allow editing once it was clear what line affected which notes.
(0015164)
Leatuspenguin   
2013-07-23 06:58   
(Last edited: 2013-07-23 11:06)
So the issue isn't a technical one regarding polyphony on an automation track? It's to do with how it would be visually implemented? Other daws allow you to select the note with your mouse to bring it's velocity bar to the top so you can edit it, if there are multiple event notes at the same time. Would something similar not work? Or have I misunderstood?

(0016075)
naught101   
2014-12-23 14:10   
Good editors I've seen have a circle for each note, which can be moved up or down. You could do the same thing with a line that goes out horizontally to the end of the note.
(0016080)
drobilla   
2014-12-23 19:27   
Bars suck. If all we really need is the ability to edit in ramps and so on, seems we can add that easily enough without a clunky bar thing that's confusing as soon as any polyphony is around.
(0016081)
naught101   
2014-12-24 02:08   
UI proposal: designed to fit with the current automation UI design.

The example doesn't include chords, but you can see how it would work for them. Just the red squares are draggable. The green lines are just indicators. If notes are selected in the actual track, then those notes are brought to the top of the stack in the velocity channel, thus allowing chord notes to be velocity-edited independently (if the chord has the same velocity on all notes, just select one note in the track, edit the velocity, select another note, repeat, etc.). If multiple notes are selected in the track, moving one of them in the velocity editor should move all of them.
(0016085)
florianb   
2014-12-24 02:52   
(Last edited: 2014-12-24 02:53)
Love this idea for 3 another reasons:
 
1- It helps a lot to visualize the timing of the notes.
I often have this problem when editing piano notes. e.g. there are 4 notes that are supposed to be at equal distance from each other, but not really on the tempo because plenty of emotion... and something sounds wrong in their timing but I can't hear where because they are too fast or too subtle... It helps a lot to see them on a horizontal timeline. Problems become obvious this way.
 
2- Currently, when scrolling for velocity, each step of scroll is an Undo/Redo action... So you have to undo 8 times to put back your 48 to the 40 it was before you scroll.
Of course this issue could be fixed another way.
 
3. We could get rid of the Alt+Scroll x10 velocity that is very confusing because of the Alt+Scroll for vertical zoom (which is fantastic). I bet nobody knows about this anyway, or they discovered it by mistake when trying to Y-zoom.
This way, we could simply click for large velocity steps.

(0016096)
drobilla   
2014-12-25 01:29   
? The notes *are* on a horizontal timeline. How does a velocity thing make any difference there?

I'm not fundamentally opposed to a separate velocity thing, but it's a massive mount of work completely unlike anything else we currently have for little to no mentioned benefit. I'd rather see a list of exactly what things users need to accomplish that we can't currently do (e.g. ramp up velocity from here to there) than "hey let's just blindly make a bar thing because some other programs do"...

e.g. it seems to me that a velocity tool that lets you edit the velocity of notes in linear ways might be (almost) universally superior. Perhaps we should have a bar thingie, and the benefits outweight the polyphony problems. So, what benefits?

In other words: justify with something other than "program X did it". If "we" are going to do a ton of work on velocity editing, it might as well be thought out properly first...

I am also interested in these questions because making the on-note velocity editing more powerful is something that is *way* more feasible to do relatively shortly than implementing this, and would be good regardless of whether or not we eventually have a bar thing.
(0016099)
florianb   
2014-12-25 01:48   
@drobilla, I don't know about the priority, there are definitely some bugs that I would consider more urgent than this. 0006055 e.g. or the fact that Ardour does not send any NoteOff in record mode. (I need to create a report for this)
 
But my point 1- above is clearly important. Let me show you why a horizontal view is important, what it is, and what it's not...
http://dl.florianbador.com/20141224-ardour-5608.png
In this example, how do you know that the 4 piano notes following my playhead are rhythmically at equal distance from each other?
It's a piano part, not a drum, so it's not supposed to be exactly on a beat, it's just supposed to make sense emotionally.
In this example, I can hear something wrong in the timing of these notes but I can't explain it. If I could visualize these notes with vertical bars next to each other, the problem would become obvious.
 
In other words, with vertical bars, the visualization of the notes timing (X) is not disturbed by their frequency (Y).
 
Having velocity bars would help a lot to visualize the rhythmical side of the music.
I don't care what other programs use.
How urgent is it? I don't know, you judge...
I still think this x10 velocity steps with Alt+Scroll should already disappear.
(0016102)
naught101   
2014-12-26 01:12   
A quick solution that would work in the mean-time would be to <Modifier>+Drag changes the velocity of a note. Scrollwheel is not very precise, and it also doesn't easily let you define multiple scrolls as one event (as opposed to click and release).

But, there are good reasons that a height-based visualisation (not bars - I wouldn't describe my UI design as bars). For one, human colour perception is not that accurate - we don't really have a way of estimating the absolute value of something from the luminosity/saturation, as with the current colour scheme. You *might* be able to improve that by adding a hue change with velocity too (e.g. red->white->blue). We're better at comparing relative colours, but I don't think many people have the ability to easily tell the difference between a note at 65 velocity and one at 70 (in the current color scheme, but it's not going to be easy in any colour scheme), but that can make a big difference, depending on the synth/sampler.

The fundamental problem is that you're trying to show 3 variables (time, pitch, velocity) in 2 dimensions. There are lots of visual variables you could use (e.g. http://jcsites.juniata.edu/faculty/rhodes/ida/images/Figure_6_8.jpg ), but size and colour are probably the only ones that might work in this situation, and size also has problems (like overlapping).

Adding a velocity bar allows you to have two correlated plots of 2 variables each. It's a pretty concise way of displaying and allowing manipulation of the information, without having too much complexity (you could make it 3D, and it'd work, but it'd get visually confusing :D ). If you add a height-guide grid behind the plot (e.g. every 32 velocity, or something), then you get *really good* absolute and relative velocity estimation.
(0016103)
florianb   
2014-12-26 01:21   
(Last edited: 2014-12-26 01:21)
Scroll is VERY precise (and very handy) One scroll step is 1 step of velocity.
Velocity upon scroll is IMO the best idea Ardour ever had... unless you have a crappy mouse.

(0016696)
rgwan   
2015-05-16 15:45   
I think Velocity TRACK is a GREAT idea to edit velocity
(0016871)
ssj71   
2015-07-14 03:49   
I think the goal is to achieve easy "fader rides" for crescendos etc. I propose the second mockup be approached but on a mouse drag to change velocities, apply it to all notes of the chord the same way the fader does on a midi track (scale all notes by the same factor). You can scale the highest velocity note to the new velocity or have the behavior in the preferences (highest velocity note, highest pitch note, lowest etc). Basically automating the gain fader from the mixer but applying the effect to each note event.

If an individual note is clicked and dragged in the "velocity track" it changes velocity, but you can also do quick shaping of the overall dynamics a passage through a mouse drag. Perhaps there is a better way than an extra track or bar to achieve this, but I think this is a pretty reasonable definition of the behavior for chords. I would sure appreciate a change to quickly shape drum pattern dynamics the same way I used to do in hydrogen (which does a velocity bar for whichever drum/note is currently selected).
(0019438)
GMaq   
2017-02-26 00:41   
(Last edited: 2017-02-26 00:42)
*Added note from IRC discussion on Feb.25/2017

In asking about the status of this feature on IRC it was suggested that a barrier to integrating this feature was how to handle 'chords' on the MIDI timeline (or multiple notes in the same vertical timeline grid axis). In my experience with other DAW's it occurred to me that visual MIDI velocity editing where the velocity is represented by a vertical 'bar' is often handled by selecting only one group of notes at a time on the same horizontal key/note path. Below are 2 examples from screenshots:

Example 1: http://bandshed.net/images/screenshots/H2.png

Example one is a screenshot of the Hydrogen Drum Machine, as you can see in it's editor window keys/notes (or drumkit pieces) can be selected on the left hand side which highlights the horizontal grid axis and exposes the vertical visual 'bars' to change the velocity of ONLY the notes on that grid axis (or note key). This allows individual adjustment of only single notes at a time without affecting note velocities on other note keys.

Example 2: http://bandshed.net/images/screenshots/EnergyXT.png

Example two is a screenshot of EnergyXT which incidentally also shares the ideology of MIDI within a timeline track like Ardour. EnergyXT does not allow selecting note keys on it's MIDI keyboard on the left like Hydrogen does however if multiple notes are 'drag-selected' then their velocity bars appear in the 'Velocity' lane under the grid. This also allows selection of individual notes on the same horizontal grid axis without changing the velocity of other notes.

This is how 2 other Linux grid-based editors handle visual velocity editing of notes, there are more examples like Seq24...

Perhaps the addition of a new MIDI type or class of track (ie MIDI-Drum track) could incorporate the suggested visual velocity drawing features without modifying or making changes to the existing scroll wheel features in Ardours existing MIDI tracks. In my own workflow and discussion with users it seems this kind of in-depth visual velocity note editing is most often employed in drum and percussion MIDI tracks.

PLEASE consider adding this feature as it is present in almost every other MIDI-capable DAW on every platform and is very much a standard and expected method of drum sequencing, I don't think this is a feature Ardour/Mixbus should be without.

Thanks for reading,
Glen

(0019440)
rghvdberg   
2017-02-26 09:54   
I would like to add that in order for the velocity track/lane to be really useful, it's should be possible to drag a line across several events to adjust the velocity.
(0019445)
GMaq   
2017-02-26 14:57   
(Last edited: 2017-02-26 20:46)
Hi,

@rghvdberg

Good point! Most DAW's employing vertical bars also allow to draw ramps and curves across the velocity 'bars', so this would be desirable as well.

Added Example 3: http://bandshed.net/images/screenshots/ReaperMIDI.png
                 http://bandshed.net/images/screenshots/ReaperMIDI2.png

This example is showing Reaper (Native Linux Version) and it actually combines the features shown above, so a note/key remains highlighted (in pink) and notes shown across that horizontal axis can then be edited without affecting other notes. Actually the Reaper editor is quite full-featured and also shows the numerical velocity values on the drawn note displayed on the grid as well as handling velocity bars of chords in different colors depending on the note selected.

(0020259)
alexmitchellmus   
2018-04-19 03:55   
(Last edited: 2018-04-19 06:14)
I think an in-region MIDI layering system could be used to show additional information for MIDI notes. Data displayed could be selected (flags?) in a layer menu- which would show a graphical, editable overlay. (editing dependent on style and sort of data)

Such overlays could be velocity lines drawn into the notes- and paired with Color, (and a Velocity Track) could make editing of MIDI velocities clearer- and easier for the end user.

The development of a MIDI overlay system, could also be the first step to enable other data that is relevant per note (such as MPE data) to be displayed. A user could choose to enable velocity / pressure / bend etc... all at once (different color automation?) or only one at a time.

Alternatively MPE data may only be shown per selected note, however having an overview of all events that occur in a MIDI region is very powerful, and allows fast editing.

To speed up editing velocity information, it may be necessary to have a dedicated Velocity tool, allows the user to left-click onto a note, and drag while holding down the left-button, to change the velocity.

A few mockups (painted on with Krita - not accurate):

MIDI Velocity in Note:
https://photos.app.goo.gl/fNC4yzKd0Fh7pV323

MIDI MPE Data in Note:
https://photos.app.goo.gl/KOqyF4hTB4WrUdaQ2

(0020303)
ssj71   
2018-06-20 18:43   
(Last edited: 2018-06-20 18:44)
I think that visualizes the event values nicely, but certainly doesn't provide an easy way to manipulate them. I still think that the biggest need is to be able to quickly "draw" dynamics, the same way you can with fader automation on an audio track. I think a lollipop thing to visualize AND manipulate the velocity info, be it overlay or another lane is the most logical way, though it probably needs a few editing modes like snap to value and scale to support a few use cases. I can't think of any way to do this that isn't a departure from current capabilities in ardour.

"To speed up editing velocity information, it may be necessary to have a dedicated Velocity tool, allows the user to left-click onto a note, and drag while holding down the left-button, to change the velocity."
I don't see that as much improvement over the current situation of using mousewheel and color to visualize. I think rghvdberg's point is the essence of this feature request: 1 click+drag to manipulate many notes' velocities.

The problem remains that note events have 3 degrees of freedom (4 if you include channel) and we only have 2D screens to visualize and edit on. When Ardour VR comes out we'll laugh that this was ever an issue. ;)

(0020304)
naught101   
2018-06-21 03:38   
As far as editing goes, a "multiplication ramp" tool might be good, and require very little in the way of new interface.

For example:

1. Select a bunch of notes
2. context menu -> velocity ramp
3. Draw a line in the current midi track, where the bottom of the track = 0, and the top = 1 (or 2?).
4. When the ramp is finished, multiply each note's current velocity value by the value at the corresponding position in the ramp.

This would be nice because it would allow you to maintain some of the relative variation between consecutive notes (rather than just over-writing the values.

The line drawing could have a couple of different options: 2 or more points (linear ramps in between), bezier curves, or free-hand draw. Hit enter to finish and apply the ramp.

If there's a tool configuration dialogue, it could include things like adding humanisation to the ramp (add a random component from 0-50%).
(0020305)
alexmitchellmus   
2018-06-25 10:22   
(Last edited: 2018-06-25 10:54)
VIEW NOTE VELOCITY WHEN NOTE IS SELECTED:
I put together a mock-up in Ardour doing this to gtk2_ardour/note_base.h:

inline static uint32_t meter_style_fill_color(uint8_t vel, bool selected) {
    /*
     if (selected) {
     return _selected_mod_col;
     } else
     */

Example:
https://www.youtube.com/watch?v=xMjDTRr5FO0

I experimented with other ideas:
* Dimming color of note outline
* Dimming color of note fill

However it was not clear to me when I was using Ardour which notes were selected.

If the outline can become 2 pixels then maybe these other methods would work better. However I think that 1 pixel has been chosen for a reason. (maybe only when selected the outline becomes 2 pixels?)

Also this video outlines an issue when changing multiple notes velocities. (which is already evident to any user of MIDI and Ardour) Which is that once the MIDI velocity becomes 0 or 127 there is no way to adjust the additional notes up or down.

Other software solves this issue by saturating the high and low values.

However due to Ardour using the scrollwheel for Velocity adjustment it makes it impossible to calculate 'velocity change start' events. As there can always be velocity change events.

In other software the start event is simply left click when using a dedicated velocity tool. Thus the delta of the mouse movement can be translated to velocity up and down.(Which gives the user the ability to decide how much to move the velocity without loosing too much velocity information for saturated values.)

NOTE:
The only issue with my solution is if the user sets one of the three velocity colors to the same as the selected color there will be no way to see selected notes. However as all colors are user changeable, this could be easily fixed by the user by selecting a 'selected color' that is not present in the velocity colors.

(0020310)
alexmitchellmus   
2018-06-26 16:32   
(Last edited: 2018-06-26 17:40)
Here is a concept of placing velocity line 'inside' each MIDI note:

https://photos.app.goo.gl/C28ahFYy7qDxBwRu6

https://www.youtube.com/watch?v=M_nsnZYAAMA&feature=youtu.be

Combined with the above: VIEW NOTE VELOCITY WHEN NOTE IS SELECTED

Also increased the outline size of all MIDI notes to 2px (originally 1px)

(out.patch above is a Git patch that contains this working concept. Not a pull request, or intended for production- only to work out ideas)

(0020316)
alexmitchellmus   
2018-06-29 05:54   
(Last edited: 2018-06-30 12:11)
+---------------------- IDEA ONLY------------------------+
                   I am not even 100% I like it myself
   posted to build a conversation around Velocity Editing
 +----------------------------------------------------------+
I uploaded an image of an 'In Region' Note Velocity Editor.

The idea is to be able to select notes, then right-click and be able to select from the Note menu the "Velocity Editor".

The Velocity editor would then show (as in the mock-up) the range of notes selected, and show a lollypop graph above the highest selected note.

It would be good to have a 'pen' tool, (for freehand drawing of velocities), and also a bezier curve tool (to allow any sort of velocity ramp to be drawn).

Any note that was not selected (when entering the tool would not be able to be edited. Possibly notes could be included and excluded on-the-fly while the tool is activated?

If notes overlap (as in same temporal position, then the drawn curve velocity would effect all notes (and give them all the same velocity for that time).

There would also be an exit box on the top right to close the tool, and return to normal note editing.

(0020317)
paul   
2018-07-03 15:29   
alex: the master branch now has the basics of your patch, reimplemented as discussed on IRC. What's missing is color management. I think that's all.
(0020318)
paul   
2018-07-03 15:44   
I set up the code to automatically compute the right color based on the fill color. I think that HSV::opposite() is probably too radical .. try playing with HSV::darker() ... ?
(0020319)
paul   
2018-07-03 16:55   
color now works as it did in your patch.
(0020322)
paul   
2018-07-03 20:49   
and the bars can be turned on and off.
(0020345)
alexmitchellmus   
2018-07-06 04:23   
(Last edited: 2018-07-08 11:29)
Absolutely amazing work Paul! Thank you so much for taking the time to implement this.

Here are some additional thoughts (in no order) that I am thinking could help MIDI editing in Ardour work better. (some dot points are simply changing settings- or adding a preference):


* A way to edit velocity of multiple notes (as per this thread) as either an overlay or lane.
* Clearly showing MIDI regions (currently zoomed out- and in, its a bit hard to see the MIDI region from the canvas)-Theme:Cubasish does this well.
* MIDI Region (and Audio Region) end loop tool (drag end of region to loop, loop connects to same region, but can be changed in future edit.
* Making the outline of the white/black note rows able to be translucent, (like the white/black note row colors are) Currently the row outlines can become very busy visually, and actually don't help in locating which note is which as everything looks white(or the set color)
*(DONE) Velocity bar can be thinner? And also able to not show based on note vertical/horizontal height (this could already work).
* In note text (note name and velocity) and/or with velocity? EG: "A#4:127"
* Ability to change note outline thickness (currently 1px, could be 2px?) this may make a good preference.
* Smarter track zooming (when making track vertically larger) the MIDI region could expand to show more content? Instead of simply zooming in?
* When moving a note up/down highlight the whole note bar that it is currently on.
* Resound MIDI notes while changing velocity (as this is an audio software, it is good to hear the note velocity as well as see it)
* For resounding MIDI notes it may be better to have a dedicated velocity tool (or use the current 'Internal Edit Tool' to LMB a note and drag up/down to change velocity) as currently both 'DRAW MODE TOOL' and 'INTERNAL EDIT TOOL' have the same behavior when LMB clicking. (possibly we can use the middle mouse button for velocity change? MMB could be utilized more)
*(DONE) More note state colors: Currently there are 3, which only shows visually Low, Mid, High. [0,64,127] 5 Note states would show: Min, Low, Mid, High, Max. [0,32,64,96,127]

Changes to "DRAW MODE TOOL" & "INTERNAL EDIT TOOL":

Currently RMB is not used for anything in Draw mode (when no notes are selected), it could be used to 'highlight notes' which can then also be moved with the same tool (LMB).
Then we don't need to worry about moving notes with the "Internal Edit Tool". Thus possibly we should be able to control velocity when LMB onto the selected notes in "Internal Edit". (currently both Note Edit, and Internal Edit both do same thing, and I wouldn't consider moving notes to be 'internally editing notes', rather editing 'note content' would be internal. Velocity is currently one of the only internal 'note' attributes we can edit.

If MPE is implemented, 'Internal Edit' could also be used for those values 'inside' notes as well (because LMB would no longer move the whole note):

Per-Note:
* Note-on (strike)
* Note-off (lift)
* Aftertouch (press)
* Pitch-Bend, X-Axis (glide)
* Y-Axis (slide)

If (in the future) MPE is implemented, then showing 'internal' velocity bars is simply just one attribute of "show internal note data". Thus we should be able to select (per track) what sort of internal data we want to display (and edit).

Already there could be two modes for "show velocity bars", Note-on velocity, and Note-off.

(0020350)
alexmitchellmus   
2018-07-08 06:16   
(Last edited: 2018-07-08 11:28)
I attached a patch to make the in-note horizontal velocity lines thinner, with a 1px gap at either end. I think this looks a bit less visually imposing.

see: 'thinnervline_01.patch' above

Screenshot: https://photos.app.goo.gl/dayGEAZuG976G6QL7

(0020351)
alexmitchellmus   
2018-07-08 07:44   
(Last edited: 2018-07-08 11:35)
Another idea I had for a solution to the 'lollipop' display. (Not implemented)

How about showing selected notes velocities vertically as an overlay on the piano roll editor.

https://photos.app.goo.gl/m4ArvA7woFQNRwqE7

User would:

1) Select multiple notes (or one note)
2) RMB notes and select from menu "Lollipop Editor"
3) Lollipop editor shows as overlay on screen, (only selected notes are displayed)
4) Freehand draw with LMB
5) Vector draw with RMB (click to create two points to draw a line between)
6) RETURN key to apply line values to note velocities
7) ESC key to leave "Lollipop Editor" mode

(0020355)
alexmitchellmus   
2018-07-13 03:43   
(Last edited: 2018-07-13 03:59)
Having thought about this for a while, I think that actually a simple velocity automation lane would suffice. (Simple, as in the ideas that I have proposed previous were probably quite complex- not implementation).

Mockup "Simple_Velocity_Autiomation_Lane.jpg"

To solve the 'polyphony issue' I would suggest to only be able to edit selected notes. As this is an automation lane (I know technically its not automation) but due to there being another lane, the user would be able to add or remove editable velocity lollipops by selection in the main midi region view.

Possibly a first iteration of this idea lane could simply be drawing velocity with the pen tool, or changing velocity up - down. No tools for velocity ramps - lines etc. which could come later.

(0020357)
alexmitchellmus   
2018-07-17 09:00   
(Last edited: 2018-07-17 14:17)
Here is an example of a rudimentary (read Hack) change I made to Ghostregions that displays their notes as lollipops in an automation view.

https://youtu.be/1wc2YDuLIjw

Currently there is no editing, but it at least shows what it 'could' look like in Ardour. The lollipop lane is currently just an automation track, (without any automation in it).

I have attached ghostlollipop_patch.diff for anyone interested.

I can see this working such as:

* Automation header menu has 'velocity' checkbox
* When 'velocity' checkbox is toggled, a velocity layer is added
* The velocity lane will always be underneath the associated track
* If no MIDI notes are selected in a MIDI region, then all lollipops will be editable
* If there are selected MIDI notes then only those would be editable in the velocity lane (to preserve polyphonic velocity editing)
* Access to two tools: Pen (to draw velocity in) & Line (to draw lines)

(0020358)
paul   
2018-07-17 12:10   
wow, this is brilliant.

now you need to look into the Drag code (editor_drag.{cc,h}) to see how to implement velocity dragging :)
(0020359)
alexmitchellmus   
2018-07-17 12:56   
(Last edited: 2018-07-17 13:05)
@paul, I personally don't like the idea of velocity dragging for all notes. But I do think that lollipops should be able to be:

* Drawn into
* Adjusted (selected notes)
* Get value from drawn line over all selected lollipops.

In regard to 'velocity automation', enumerating lollipop should allow us to pass this as a automation track type? Which would be drawn along with all the other automation tracks?

It looks like currently global tracks are dealt with elsewhere so I am not sure if this should be the same place.

(0024940)
naught101   
2020-08-19 05:28   
@alexmitchellmus Is that the right patch? I may well be mistaken, but it seems to be a patch relative to another change (there is a line with an ALEX comment removed). Did you perhaps not diff against master?
(0027383)
Reezlaw   
2023-02-16 02:56   
I'm really surprised that there isn't more pressure about this. Minutes ago I was drawing drum notes, I wanted a velocity curve for a roll on the toms and suddenly realised there's no other way than setting the individual velocities one by one. Coming from a well known commercial DAW that I'm determined to abandon - I want to use Linux and open source software exclusively - this is extremely weird to me and it might even be a deal breaker.
(0027384)
paul   
2023-02-16 03:51   
there's less pressure than even i'd expect, and i think it is mostly because the vast majority of people rarely (if ever) do this. it is another one of those workflow things where for one set of users, this is, as you put, a dealbreaker, and for a different (and much larger) set of users, it's mostly of little consequence. that's true of almost all features already present or missing in any given DAW, including ardour.

i do have a plan for this at this point, and it will better than you see in many other DAWs, i believe. designing the details is a bit of a headache, though.
(0027387)
Reezlaw   
2023-02-16 09:45   
This is awesome news. I'm learning to love your software and I really want to stick to it. I guess I'll mousewheel my velocities for a little longer, knowing you're working on something is great
(0028163)
paul   
2023-10-09 03:04   
OK all you whiners :)))

Ardour 8.0 is out with your beloved lollipops implemented, along with freehand drawing.

And Leatuspenguin, I hope you're still at the same email address - this may be the first of your always excellent suggestions that we've actually implemented in a decade now.
(0028354)
Reezlaw   
2023-11-23 10:54   
I finally got a chance to test it and it's amazing. Thank you so much

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9546 [ardour] features minor unable to reproduce 2023-11-22 08:50 2023-11-22 08:50
Reporter: al f Platform: Any  
Assigned To: OS: Any  
Priority: normal OS Version:  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: Wet stem export, preserving the mono/stereo property
Description: When doing a stem export of mono tracks, if I want to keep processing like a compressor or limiter and tick the "Apply track/bus processing", the track is "converted" to stereo.

Could it be possible to keep the track mono, but still apply the processing?

Relevant forum posts:
https://discourse.ardour.org/t/stem-export-now-exports-mono-tracks-as-stereo/108735
https://discourse.ardour.org/t/export-tracks-rather-than-stems-preserving-the-mono-stereo-property/109104
https://discourse.ardour.org/t/wet-stem-export/109511
Tags: export
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9500 [ardour] bugs minor always 2023-10-22 22:23 2023-11-21 07:52
Reporter: skygge Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Time axis view item base" transparency setting doesn't work
Description: "Preferences -> Appearance -> Colors -> Items -> Time axis view item base". If you change this color, the background of audio region changes accordingly.
But changing "Time axis view item base" transparency on the "Transparency" tab does nothing. The background of audio region stays the same.
Tags:
Steps To Reproduce: Record some audio. Go to Preferences -> Appearance -> Colors -> Transparency and move the "Time axis view item base" slider. No effect.
Additional Information: If this item is not responsible for the transparency change of the audio region background, please provide the correct one.
System Description
Attached Files: image.png (3,818 bytes) 2023-10-22 22:23
https://tracker.ardour.org/file_download.php?file_id=4681&type=bug
png
Notes
(0028277)
paul   
2023-10-31 19:27   
This is a complex topic.

If you want the region to be visually non-opaque, you need to make it sonically non-opaque too (from the region's right click menu and then "Gain").

Some years ago we did not force the two "types" of opacity to remain aligned and this caused confusion for lots of people.

Once you've done that, the "transparent region base" transparency choice will affect the region.
(0028279)
skygge   
2023-10-31 19:58   
Ok, it's a bit confusing, I wanted to make the background more transparent while waveform itself more opaque. I've noticed the "Time axis view item base" item in both "Color" and "Transparency" tabs. The color changes while the transparenty doesn't. If this is OK, please close this issue. Thanks!
(0028282)
paul   
2023-10-31 23:56   
It is actually very complex, much more than you'd guess. Turns out that we aggregate regions into a groups and then re-render them with a little bit of alpha ... which allows the grid to appear evenly over all the regions regardless of how many layers there are

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9498 [ardour] bugs major always 2023-10-21 14:54 2023-11-21 07:50
Reporter: skygge Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Freehand velocity drawing on selected notes is changing velocity of not selected notes under the mouse cursor.
Description: If you select notes for editing velocity (freehand or straight line), not only the selected notes will be modified, but also the notes that the line starts with, even if not selected.
Tags:
Steps To Reproduce: Open velocity lane on a MIDI track, select notes in a MIDI region, then draw a velocity line that starts outside selected range. If there are unselected notes under mouse cursor the velocity change will be applied also to these not selected notes.
Additional Information:
System Description
Attached Files: velocity_selected notes.gif (312,352 bytes) 2023-10-31 22:27
https://tracker.ardour.org/file_download.php?file_id=4696&type=bug
Notes
(0028280)
paul   
2023-10-31 20:40   
after the changes made a couple of days ago, notably 1fbb1c65ba22 and ef0938a16d1 is this issue resolved for you?
(0028281)
skygge   
2023-10-31 22:27   
I'm sorry but no. The straight line works <3 <3 <3 Thank you very much!!!
But if you select notes for edit, the not selected notes are edited too.... :(
Attached screencast from Ardour 8.1.56 (rev 8.1-56-g43c5f0ab46)
(0028286)
skygge   
2023-11-01 11:43   
> x42 (administrator) - 2023-11-01 07:03
> Are those layered regions? Can you show a screenshot with Layering > Stacked
> It seems like the issue is that in the lower region no notes are selected, in
> which case drags operate on all notes. (in addition to the selected ones in the
> upper region)

No, there are no layers. Ok, maybe one... ;)
https://youtu.be/WGaYcb3qjrk

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9543 [ardour] bugs major always 2023-11-19 14:18 2023-11-20 19:41
Reporter: pdechery Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Clip loses presets when played on Cue
Description: MIDI Clips doesn't work on Cues, as they does not honor the chosen presets and remove any configuration you did on your plugin window.





Tags: Ardour 8.0, clip, cue, Midi
Steps To Reproduce: Create MIDI track and choose some MIDI instrument. I've tried this with ZynAddSubFx and General MIDI Synth.

Choose a preset on the above mentioned plugin.

Create a region and draw some notes on it. Create a MIDI clip by selecting this region, using "Bounce without processing".

Go to Cue Window and on the same track place the MIDI clip on it.

Create a Cue marker on Timeline to play the Cue where your clip is.

Try to play your project with the "Play Cues" button enabled.

The preset you had chosen should not be played. If you go to the plugin window it should not even be there anymore.




Additional Information:
System Description
Attached Files:
Notes
(0028342)
paul   
2023-11-20 19:41   
"The preset you had chosen should not be played. If you go to the plugin window it should not even be there anymore."

I am confused. Why do you think is? Or is this just a description of what happens or doesn't happen?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9533 [ardour] bugs minor always 2023-11-11 20:34 2023-11-18 22:56
Reporter: erdavis7 Platform: Apple Macintosh  
Assigned To: paul OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: assigned Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Automation Inconsistency
Description: In the attached file, the pitchbend is set at neutral for bars 1-2, and then set to maximum for bars 3-4. When played from the beginning, it sounds as expected. However, if after playing past measure 3, playback is resumed at measure 2, then measure 2 will sound with the pitchbend at maximum (the last value that was played), rather than at neutral (the last value that was set in the timeline).

Whenever resuming playback, automatable parameters ought to be set either to the last value that was set in the timeline, or to neutral if there was no previous setting in the timeline.
Tags: automation
Steps To Reproduce:
Additional Information:
System Description
Attached Files: automation-inconsistency.zip (11,887 bytes) 2023-11-11 20:34
https://tracker.ardour.org/file_download.php?file_id=4713&type=bug
Notes
(0028331)
paul   
2023-11-14 19:39   
does this still happen if you set the automation style for pitchbend as "interpolated" ?
(0028332)
erdavis7   
2023-11-15 02:40   
It happens in both "Discrete" and "Linear" modes.
(0028338)
DonJaime   
2023-11-18 22:06   
This is a manifestation of a more general phenomenon (which could justifiably be seen as a problem): Ardour plays MIDI sequentially and doesn't in general try to restore the track state to what it would have been if it had played from the start. If there are patch changes in a track, for example, this can lead to the wrong "instrument" being played. (I haven't checked if the same problem arises with all CC messages, but if it doesn't, that would be a (welcome) inconsistency.)
(0028340)
paul   
2023-11-18 22:56   
we actually have the internal "technology" to do the "catch up with current total MIDI state" now.

the actual problem is deciding when to emit any MIDI messages. for example, in the specific case of this bug, doing it on completion of a locate is potentially wasteful, because the user may just locate again. they may also edit the information that is earlier than the current playhead position, which will make the MIDI sent be inaccurate. that would suggest doing it just before we start rolling (playing), but it can be tricky to ensure the ordering of messages is 100% accurate.

still thinking.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9323 [ardour] bugs major always 2023-05-03 16:22 2023-11-18 22:22
Reporter: DonJaime Platform: Arch  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Audio regions and location markers are no longer glued to bars and beats in pre-7 sessions
Description: When I open a session saved in version 6.9 with version 7.4, any audio regions and location markers that were glued to bars and beats aren't glued any more.
Tags:
Steps To Reproduce: Open the attached file. Some of the markers and all three audio regions are glued in version 6.9, none of them are in version 7.4
Additional Information:
System Description
Attached Files: Tempo map 6-7 bugs_2023-05-03_180426.ardour-session-archive (625,909 bytes) 2023-05-03 16:22
https://tracker.ardour.org/file_download.php?file_id=4517&type=bug
Notes
(0028339)
DonJaime   
2023-11-18 22:22   
This appears to be by design, so could be closed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7609 [ardour] features minor have not tried 2018-04-30 18:53 2023-11-18 17:22
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Highlight keys on the Piano roll whenever playing from Disk or Input
Description: In many situations I find myself wishing the Piano Roll would highlight notes when I play live on a keyboard, or play back from disk.

Tags:
Steps To Reproduce:
Additional Information: I'm attaching a simple mockup.
Attached Files: Selection_388.png (13,294 bytes) 2018-04-30 18:53
https://tracker.ardour.org/file_download.php?file_id=3382&type=bug
png

Piano_Roll_Offset.jpg (84,897 bytes) 2018-07-13 03:28
https://tracker.ardour.org/file_download.php?file_id=3411&type=bug
jpg
Notes
(0020352)
alirafami   
2018-07-10 06:16   
An external instrument is also great when it’s time to choose a sound for a new track, because you can walk through the various instrument names without ever having to close the Track Info dialog box. See Figure 4-3 for more information.

http://www.rhinoclinic.ir/
(0020354)
alexmitchellmus   
2018-07-13 03:31   
(Last edited: 2018-07-13 03:31)
I also have been looking at the offset of the piano keyboard on the side, and it looks like its 1-2px lower than the Piano Roll. It would be good to get this aligned. The keyboard need not to be realistic (as in beveled corners etc) just line up. If this aspect of the keyboard is intentional then please disregard this suggestion.

See above jpg "Piano_Roll_Offset"

(0020356)
unfa   
2018-07-13 06:45   
I think the shape of the piano roll keyboard is optimized to keep the piano roll rows have the same height.
(0028336)
mtf8   
2023-11-18 17:22   
I just wanted to chime in with my reason for wanting this feature. I suspect I'm surely in the minority of people here who don't read or understand music theory. I tend to loop a few bars of the thing I'm working on, call up an interesting synth patch, and "explore" via my MIDI controller until I get that warm & fuzzy feeling. At that point, I have 2 options; either record it live or just enter the notes into a piano roll. I tend to go for the latter approach since I know I'd end up quantizing any live performance anyway. This is the exact moment this feature would provide me with real value. Because the piano keys don't highlight in any way on input, I have to basically look back and forth between where my finger is on the controller and where I want to draw a note with my mouse. Granted, don't get me wrong...... my neck works just fine and obviously I've been productive. It would just be so cool to benefit from this type of real-time feedback.

By the way, ever since moving to Ardour, I've discovered a tiny hack which improves on the back & forth thing described above. Now, I add the MIIDI monitor plugin into the track so I can see the MIDI note number in the mixer panel when I press a key. Then, in piano roll (with edit mode enabled), I can easily locate the corresponding white or black square representing the note in question. This is cool but obviously just a silly hack :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9541 [ardour] bugs minor sometimes 2023-11-18 02:03 2023-11-18 02:03
Reporter: Schmitty2005 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Barlow Arpreggiator goes into bypass mode in WIN 10. Works in Linux
Description: Using the Barlow Arpreggiator, It will sometimes go into bypass mode at indeterminable times. Times may change based on play head start position. Only affects Windows 10. Linux works with same session.

No errors in log window.


 
Tags: Barlow, Midi, Win10
Steps To Reproduce: Load sample MIDI session included in this tracker issue.

1. Play from beginning.
2. Notice Barlow are goes into bypass at measure 6 ( or 5 if not 6)
3. Repeat steps 1 and 2. It will always bypass at the same measure.
4. Move playhead to measure 2 and start playback
5. Barlow Arp will not go into bypass when reaching measure previously trigger bypass. I was unable to get it to go into bypass for the remainder of track.
6. Repeat step 1 and 2. Notice it goes into bypass at same measure (6 or 5)

Additional Information: Also affects Mixbus 9.1.latest as of Nov 17th 2023.
System Description
Attached Files: ArdourBarlowArpBug.ardour-session-archive (19,649 bytes) 2023-11-18 02:03
https://tracker.ardour.org/file_download.php?file_id=4721&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9540 [ardour] bugs major random 2023-11-18 00:21 2023-11-18 00:21
Reporter: Hajker Platform: Microsoft  
Assigned To: OS: Windows  
Priority: high OS Version: 11  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Recording randomly stops
Description: For some reason today my recordings randomly stopped 2 times now. First time it happened when I unchecked "listen to this device" in windows sound settings, and the second time it stopped for literally no reason, I wasn't even doing anything audio related on the PC.
The program feels very unstable and you can't do anything when the timers stop (aka the recording has frozen), though thankfully you can get the recording off of the temp files.
This is so sad, as this program is the only one that has a feature not available on other recording softwares, even on much more popular ones. I've always used Audacity, but cannot use it anymore just because it lacks that one feature. I will donate more than 1$ if the program will ever get fixed.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9523 [ardour] bugs minor always 2023-11-02 22:53 2023-11-17 17:03
Reporter: admd127 Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 8.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI import overwrrites tempo starting at beginning of session
Description: When importing a midi file into a session using "Use MIDI Tempo Map" and "Insert at playhead" options, the imported tempo map overwrites existing tempo map starting at Bar 1 regardless of the position of the playhead, whereas the rest of the MIDI file is imported at the playhead which ends up moving in Bars:Beats when the existing tempo is overwritten.

This behaviour happens on both Windows and Linux.

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: step1.png (78,460 bytes) 2023-11-11 15:15
https://tracker.ardour.org/file_download.php?file_id=4708&type=bug
png

step2.png (206,900 bytes) 2023-11-11 15:15
https://tracker.ardour.org/file_download.php?file_id=4709&type=bug
png

step3.png (283,341 bytes) 2023-11-11 15:15
https://tracker.ardour.org/file_download.php?file_id=4710&type=bug
step4.png (85,763 bytes) 2023-11-11 15:15
https://tracker.ardour.org/file_download.php?file_id=4711&type=bug
png
Notes
(0028317)
admd127   
2023-11-11 15:15   
Here are the steps to reproduce this behavior/
1) Create a simple session with a tempo change ( see step1.png : example in this case is 2 bars long . The tempo change is at beginning of Bar 2 )
2) Export the region as midi file ( see step2.png )
3) Position the playhead beyond the end of the region created in step 1 and Import the midi file created in step 2 with "Use MIDI Tempo Map" and "Insert at Playhead" options as shown in the attached image ( see step3.png )
4) Observe that the existing tempo change is overwritten ( see step4.png )

step4.png also shows that the original tempo change was not actually exported in step2. This can be verified by reading the MIDI file created in step2 using python mido library.
(0028333)
paul   
2023-11-17 17:03   
as of commit b76c3b11d9 this should be fixed in master and the nightly builds.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9537 [ardour] bugs minor always 2023-11-14 23:36 2023-11-15 02:51
Reporter: gonsolo Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Compile error because of pbd stacktrace
Description: https://github.com/Ardour/ardour/pull/839
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5186 [ardour] features feature have not tried 2012-11-24 10:12 2023-11-14 15:47
Reporter: aleks Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request about drum editing mode
Description: I know it has been suggested earlier in one form or another, but could you add a feature to Ardour3 where in the drum editing mode you could right click a key on the piano roll and assign a short two or three letters name to the key just like you assign a name to a track - for example - K.D. for kick drum, Sn.-snare, Cy-cymbal etc.? That way would be much easier to compose a drum track, when one could easily see the drum instruments, instead of clicking on the keys all the time or trying to remember all the sound placements on the piano roll. I've seen this feature in Reaper, and it doesn't look bad at all.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: CaptureReaper.JPG (57,050 bytes) 2012-11-24 12:10
https://tracker.ardour.org/file_download.php?file_id=1995&type=bug
jpg

nn.png (56,526 bytes) 2023-11-14 15:47
https://tracker.ardour.org/file_download.php?file_id=4720&type=bug
png
Notes
(0014295)
skygge   
2012-11-24 17:42   
+1 vote for this request!
(0028330)
paul   
2023-11-14 15:47   
Unlike Reaper, we have chosen not to create our own file format for this information. This has pros and cons.

If there is a MIDNAM file for the external instrument or plugin, you will already see note names/drum names (see screenshot). MIDNAM is a standard file format defined by the MIDI Manufacturers Association.

However, the downside is that this format is extremely complex, and Ardour does not provide a way to edit what is (or is not) displayed. Creating MIDNAMs is not a simple process (though it can be done in any text editor.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9324 [ardour] bugs major always 2023-05-03 16:29 2023-11-14 15:42
Reporter: DonJaime Platform: Arch  
Assigned To: paul OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tempo map is corrupted when opening old sessions
Description: After a tempo change later tempo changes are in the wrong position and audio and MIDI tracks are no longer in sync.
Tags:
Steps To Reproduce: Save a session with tempo changes in version 6.9 and open it in 7.4
Additional Information: In the attached file the audio track is a recording of the MIDI tracks. In 7.4 the MIDIs are stoned.
System Description
Attached Files: Tempo map 6-7 bugs_2023-05-03_180426.ardour-session-archive (625,909 bytes) 2023-05-03 16:29
https://tracker.ardour.org/file_download.php?file_id=4518&type=bug
Screenshot_20231113_103246.png (313,437 bytes) 2023-11-13 09:54
https://tracker.ardour.org/file_download.php?file_id=4717&type=bug
session.mp3 (366,760 bytes) 2023-11-13 09:54
https://tracker.ardour.org/file_download.php?file_id=4718&type=bug
68.png (54,210 bytes) 2023-11-14 05:27
https://tracker.ardour.org/file_download.php?file_id=4719&type=bug
png
Notes
(0028314)
DonJaime   
2023-11-11 10:39   
No change in version 8.1
Gradually turning into an objective reason to consider not using Ardour in the future.
(0028320)
paul   
2023-11-13 03:12   
So the first problem I notice starting to dig into this is that the session does not load correctly in 6.9 either, if "correctly" means that the MIDI and audio ought to be in sync with each other.

There are also display issues with both 6.9 and 8.1 regarding the length of the notes,
(0028321)
DonJaime   
2023-11-13 09:54   
Well that's ... interesting.
The audio is a recording of the MIDI, so yes, in sync.
Here is a screenshot of the session in Ardour 6.9, and an export of it.
I imagine it's unlikely that this could be a result of using the Arch binary rather than an official download.
(0028324)
paul   
2023-11-14 02:50   
I've managed to track down the root cause of this. It's not solved yet, but it should not take too long once I figure out the way.
(0028325)
paul   
2023-11-14 05:27   
fixed locally. will push soon.
(0028326)
paul   
2023-11-14 05:59   
should be fixed as of ce4d1ffe513750034c
(0028327)
DonJaime   
2023-11-14 10:42   
Compiled that. A medium-sized heap of work in progress now opens as music instead of salad.
Thank you.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9536 [ardour] bugs crash always 2023-11-13 20:06 2023-11-13 21:16
Reporter: np Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 'cleanup sources' removes sources still in use
Description: In certain cases, the cleanup function removes sources that are still in use.
This leads to a crash with the message 'ERROR: Session: XMLNode describing a AudioRegion references an unknown source id =xy' when that session is saved and reopened.
The session can be restored by deleting all 'region' and 'playlist' tags in the *.ardour-file and import the audio files from the 'dead' directory.
Tags: cleanup, cleanup unused sources
Steps To Reproduce: 1. create new session
2. create audio track
3. clean up sources
4. record a region
5. clean up sources again --> the source of the previously recorded region is removed
Additional Information: I'm still using version 7.5.0~ds. But I didn't find a bugfix concerning this issue in the release notes of version 8.0.
System Description
Attached Files:
Notes
(0028322)
x42   
2023-11-13 21:16   
Fixed in 8.1-95-g5b7e008cad

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9535 [ardour] bugs crash sometimes 2023-11-12 21:24 2023-11-12 21:36
Reporter: merryl0 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: midi nodes crash related to D Healeys Vanishing automation post
Description: Drawing in pitch bend information where none previously existed into a midi track. Could initially draw one or two nodes then no more, Lines only have a node at the end and pitch bend is de-limited to the times of the existing midi regions.
Trying to manipulate or delete nodes during playback causes a crash.
Tags:
Steps To Reproduce: Gdb output and session file attached below. The midi track i tried to add pitchbend to is called strings
Additional Information:
System Description
Attached Files: midinodesCrash.txt (94,419 bytes) 2023-11-12 21:24
https://tracker.ardour.org/file_download.php?file_id=4714&type=bug
EIT2.ardour.tar.gz (134,077 bytes) 2023-11-12 21:24
https://tracker.ardour.org/file_download.php?file_id=4715&type=bug
image.png (90,606 bytes) 2023-11-12 21:36
https://tracker.ardour.org/file_download.php?file_id=4716&type=bug
png
Notes
(0028319)
merryl0   
2023-11-12 21:36   
heres a screenshot showing the pitch bend line with no nodes.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9534 [ardour] bugs feature always 2023-11-12 01:01 2023-11-12 01:01
Reporter: laugui Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Meldaproductions free plugins UI are not working normally
Description: MeldaProduction 16.09 free bundle plugins are not controlable via their own UI. Seems OK via the generic UI. Tested on AU and VST3 format.

Does not work either in Audio Hijack utility 4.3.0
But works OK in Audacity 3.4.1
 

Tags: apple silicon, bug, mac, melda, plugin, ui
Steps To Reproduce: Using Ardour 8.1 on MacOS Sonoma 14.1.1 on Mac Mini M2
Installed Melda free bundle 16.09 (https://www.meldaproduction.com/downloads), in formats AU and VST3
Adding any of these plugin to a track, then open the UI. IOt will display correctly, but won(t behave as expected. Controls are hardly responsive to the mouse commands. At some point, I can manage to move some pot, but only upwards.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9532 [ardour] bugs minor always 2023-11-11 19:38 2023-11-11 19:38
Reporter: erdavis7 Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Discontinuous Automation Bug
Description: In an automation lane, it is possible to make a discontinuous curve, which visually appears to jump from one value to another, as in measure 4 of the attached session. But when played, the value does not jump, but remains at the left-bound value. The expected behavior is that the pitch would rise through measure 3 until it reached almost maximum, and then would reset to neutral at the beginning of measure 4. Instead, at measure 4 the pitch remains at maximum.
Tags: automation
Steps To Reproduce:
Additional Information:
System Description
Attached Files: automation-bug.zip (23,098 bytes) 2023-11-11 19:38
https://tracker.ardour.org/file_download.php?file_id=4712&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9517 [ardour] bugs crash have not tried 2023-10-30 17:37 2023-11-11 18:37
Reporter: merryl0 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: crashes when trying to edit
Description: I had previously worked on this small session without any problems
Session contains:
1 mono audio click track
1 midi general midi synth track
1 mono audio bass track
Today I recorded a percussion track.
Stripped silence
snapped to grid
applied x42 para eq.
First i got a disk to slow msg adjusting eq during playback
Created new track add dragged some of the sliced perc regions to it - crashed
Relaunched didnt choose recover from crash
remade new track and dragged perc into it, crashed again
Ran ardour in dbg
selected regions, created track and dragged - crashed
attached gdb report
gdb wont quit by pressing q
Tags:
Steps To Reproduce: as described above
Additional Information: Many thanks
heres a link to the session archive I have made after relaunching Ardour (not in gdb)
https://mega.nz/file/Rd0DlY5S#affWzi6xzM0xEUKoejjEO0msQit_xkBxmh09Oa6W8yA
System Description
Attached Files: crash301023.txt (94,686 bytes) 2023-10-30 17:37
https://tracker.ardour.org/file_download.php?file_id=4689&type=bug
crash2-301023.txt (94,104 bytes) 2023-10-30 19:40
https://tracker.ardour.org/file_download.php?file_id=4690&type=bug
crash2-301023.png (371,645 bytes) 2023-10-30 19:40
https://tracker.ardour.org/file_download.php?file_id=4691&type=bug
crash3-301023.txt (91,999 bytes) 2023-10-30 19:48
https://tracker.ardour.org/file_download.php?file_id=4692&type=bug
stripSlienceCrash.txt (88,349 bytes) 2023-11-02 11:29
https://tracker.ardour.org/file_download.php?file_id=4700&type=bug
Dragcrash081123.txt (300,644 bytes) 2023-11-08 20:25
https://tracker.ardour.org/file_download.php?file_id=4703&type=bug
diskSlow081123-3.png (96,027 bytes) 2023-11-08 20:25
https://tracker.ardour.org/file_download.php?file_id=4704&type=bug
png
Notes
(0028273)
merryl0   
2023-10-30 19:40   
Launched ardour again with gdb, started same session in safe mode.
removed percussion track
Imported percussion track and saved
Quit ardour
Launched ardour again with gdb, started same session (not safe mode)
Stripped silence (-40dB with default other values) and snapped to grid. Saved
created new track
selected 1 slice (of perc region) of percussion, held Ctrl tried to select another slice - crashed
Dbg file attached
Started in safe mode again with gdb
Created new track
selected slice of perc, used CTRl key to select another, crashed on 5th selection
See screenshot
Many thanks
(0028274)
merryl0   
2023-10-30 19:48   
heres the dbg form that last safe mode crash.
It looks like the same error to me

(ardour-8.1.0:3768): glibmm-ERROR **: 19:21:23.449:
unhandled exception (type std::exception) in signal handler:
what: negative distance in timecnt constructor

--Type <RET> for more, q to quit, c to continue without paging--thread apply all bt

Thread 1 "ArdourGUI" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff125e2c3 in g_log_structured_array () from /opt/Ardour-8.1.0-dbg/lib/libglib-2.0.so.0
(gdb)
(0028285)
x42   
2023-11-01 06:12   
> unhandled exception (type std::exception) in signal handler:
> what: negative distance in timecnt constructor

I've seen this before. you somehow managed to drag a region or marker to a location before 00:00:00:00
If you post the .ardour session file I can fix it.

Or you can try this yourself, open the file in a text editor and search for a negative position `start="- ` or `pos="-`
(0028287)
merryl0   
2023-11-01 13:04   
I searched the session file, but found no `start="- ` or `pos="-`
It might be gone, because I removed the track from the session after my original post and the session has been running ok since.
here is a link if you want to look:
https://mega.nz/file/5McSDaAJ#a0nUiN5bu4fsBokrPUyoLGK13gGUCDgI2TDYWXbKpes
Many thanks
(0028289)
x42   
2023-11-01 15:25   
The session you've uploaded loads fine here.

Is that the original that caused this issue? Can you still reproduce the crash?
(0028295)
merryl0   
2023-11-02 08:31   
Since I removed the track and replaced it in a different way, the session has run without problems.
I will try to reproduce the issue in a new project and report back
Many thanks
(0028296)
merryl0   
2023-11-02 11:29   
I got it to crash:
New session
Import audio file
Strip silence - change fade length
select all (region slices) and drag out right sides to create longer slices
create new track
ctrl click region slices to select multiple
drag to new track

Paul said to paste the log to pastebin but I couldnt sign up for some reason so I've attached a text file below
(0028307)
merryl0   
2023-11-08 20:25   
Crashed when dragging regions.
New session.
1 audio track , no plugins, layered mode
5 takes.
Looped takes and playback
cut different takes and dragged region borders as if comping a performance
After a short while, consistently got disk too slow msg almost every edit
crashed soon after
session folder: https://mega.nz/folder/kUUHCA7Q#w-rPzyNz9FvlyruUW2ZFvw
Ardour 8.1.78, AVL 21.3 (up to date), 2017 thinkstation
(0028312)
paul   
2023-11-11 02:39   
that crash is known but there is still no well-defined recipe for it, which makes it essentially impossible for us to debug. others are also trying to find a recipe, so far with no success.
(0028313)
paul   
2023-11-11 02:40   
we definitely need to add more debugging for you to use to try to track down the disk slow messages. there's either something fundamentally wrong with our code (possible, though a bit unlikely at this point) or something very weird about your system
(0028315)
merryl0   
2023-11-11 14:12   
Generally it works well. The only thing i can think of is the nvidia graphics driver. I have a quadro 400 card and when AVL tries to update the driver (from the original supplied mx linux driver) it always fails and reverts back to the first one.
(0028316)
merryl0   
2023-11-11 14:44   
Ive just tried updating the driver using apt and it says that both the (nonfree) driver and firmware are the latest version, so I guess there's nothing to be done about that then.
(0028318)
merryl0   
2023-11-11 18:37   
Thinking about what you said, I have run graphics tests and found no problems. Now I have tested the ssd hard drive, ram and gpu and they've all been fine. My computer is (as far as I know) a standard 2017 thinkstation with nvidia graphics (bought used, from a large uk reseller). Can you suggest what part might be wierd, or what i could further test?
Many thanks

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9531 [ardour] bugs block always 2023-11-10 21:40 2023-11-10 21:40
Reporter: musicallyn00best Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Trying to use the ASIO driver of my Roland Quad-Capture USB audio interface crashes Ardoud 8.1 at startup.
Description: Trying to use the ASIO driver of my Roland Quad-Capture USB audio interface crashes Ardoud 8.1 at startup. Using ASIO4ALL as my driver works completely fine, though.
Tags:
Steps To Reproduce: Select Roland Quad-Capture as the ASIO driver in the startup prompt and then try to launch the program.
Additional Information: Program hangs indefinitely so that Windows Task Manager will show the process still running but nothing shows up on screen no matter how long I wait so I have eventually terminate it from the Task Manager. I'm using the latest official version of the Roland Quad-Capture drivers and also using said drivers work fine in FL Studio so I don't think the drivers are faulty.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9226 [ardour] bugs crash always 2023-02-06 05:00 2023-11-10 13:47
Reporter: Eric Crapton Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: immediate OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ardour crashes when exporting to wav
Description: I am a beginner ardour user, trying to export a song with a single track to wav and it crashes. Always at exactly the 80 bars point

I've tried: saving as another session, doing all the clean up operations, removing all other tracks, removing all plugins

It is immediately reproducible on my setup, and I have coredump files available at request but they're too big to attach.

Here is the terminal output:

zsh: correct 'ardour' to 'ardour7' [nyae]? y
Ardour7.2.0 (built using 7.2 and GCC version 12.2.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /etc/ardour7/system_config
Ardour: [INFO]: Loading user configuration file /home/dg/.config/ardour7/config
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
Ardour: [INFO]: Using AVX and FMA optimized routines
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour7/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/dg/.config/ardour7/plugin_metadata/plugin_stats
Ardour: [INFO]: Loading default ui configuration file /etc/ardour7/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/dg/.config/ardour7/ui_config
Ardour: [INFO]: Loading 454 MIDI patches from /usr/share/ardour7/patchfiles
Ardour: [INFO]: Loading color file /usr/share/ardour7/themes/dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file /etc/ardour7/clearlooks.rc
Ardour: [INFO]: Loading bindings from /etc/ardour7/ardour.keys
Loading ui configuration file /etc/ardour7/clearlooks.rc
Found nothing along /home/dg/.config/ardour7/templates:/usr/share/ardour7/templates
Set cursor set to default
/usr/include/c++/12.2.0/bits/stl_vector.h:1123: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = ARDOUR::PeakData; _Alloc = std::allocator<ARDOUR::PeakData>; reference = ARDOUR::PeakData&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
zsh: IOT instruction (core dumped) ardour7


Tags:
Steps To Reproduce: Export the track
Additional Information:
System Description
Attached Files: image.png (57,145 bytes) 2023-02-06 05:03
https://tracker.ardour.org/file_download.php?file_id=4371&type=bug
png
Notes
(0027295)
Eric Crapton   
2023-02-06 05:03   
screenfetch displayed, also im using pipewire
(0027296)
Eric Crapton   
2023-02-06 05:22   
/usr/include/c++/12.2.0/bits/stl_vector.h:1123: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = ARDOUR::PeakData; _Alloc = std::allocator<ARDOUR::PeakData>; reference = ARDOUR::PeakData&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

Thread 47 "audioengine" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffca7fc6c0 (LWP 4070)]
0x00007ffff53dd64c in ?? () from /usr/lib/libc.so.6
(gdb) thread apply all bt

Thread 122 (Thread 0x7fff63fff6c0 (LWP 4149) "WaveViewDrawing"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7f93986 in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
#3 0x00007ffff7f93a8a in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
0000004 0x00007ffff7f9575d in ArdourWaveView::WaveViewThreads::_thread_proc() () at /usr/lib/ardour7/libwaveview.so.0
0000005 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
#6 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#7 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 121 (Thread 0x7fff84ff96c0 (LWP 4148) "WaveViewDrawing"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7f93986 in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
#3 0x00007ffff7f93a8a in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
--Type <RET> for more, q to quit, c to continue without paging--
/usr/lib/ardour7/libwaveview.so.0
0000005 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
#6 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#7 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 120 (Thread 0x7fff857fa6c0 (LWP 4147) "WaveViewDrawing"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7f93986 in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
#3 0x00007ffff7f93a8a in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
0000004 0x00007ffff7f9575d in ArdourWaveView::WaveViewThreads::_thread_proc() () at /usr/lib/ardour7/libwaveview.so.0
0000005 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
#6 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#7 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 119 (Thread 0x7fff85ffb6c0 (LWP 4146) "WaveViewDrawing"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7f93986 in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
#3 0x00007ffff7f93a8a in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
0000004 0x00007ffff7f9575d in ArdourWaveView::WaveViewThreads::_thread_proc() () at /usr/lib/ardour7/libwaveview.so.0
0000005 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
#6 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#7 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 118 (Thread 0x7fff867fc6c0 (LWP 4145) "WaveViewDrawing"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7f93986 in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
#3 0x00007ffff7f93a8a in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
0000004 0x00007ffff7f9575d in ArdourWaveView::WaveViewThreads::_thread_proc() () at /usr/lib/ardour7/libwaveview.so.0
0000005 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
#6 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#7 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 117 (Thread 0x7fff86ffd6c0 (LWP 4144) "WaveViewDrawing"):
--Type <RET> for more, q to quit, c to continue without paging--
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7f93986 in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
#3 0x00007ffff7f93a8a in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
0000004 0x00007ffff7f9575d in ArdourWaveView::WaveViewThreads::_thread_proc() () at /usr/lib/ardour7/libwaveview.so.0
0000005 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
#6 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#7 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 116 (Thread 0x7fffa8c636c0 (LWP 4143) "WaveViewDrawing"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7f93986 in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
#3 0x00007ffff7f93a8a in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at /usr/lib/ardour7/libwaveview.so.0
0000004 0x00007ffff7f9575d in ArdourWaveView::WaveViewThreads::_thread_proc() () at /usr/lib/ardour7/libwaveview.so.0
0000005 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
#6 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#7 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 101 (Thread 0x7fff877fe6c0 (LWP 4128) "AutomationWatch"):
#0 0x00007ffff5422825 in clock_nanosleep () at /usr/lib/libc.so.6
0000001 0x00007ffff5427337 in nanosleep () at /usr/lib/libc.so.6
#2 0x00007ffff6bbd491 in g_usleep () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff73ed6b6 in ARDOUR::AutomationWatch::thread() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 100 (Thread 0x7fff9affd6c0 (LWP 4127) "autoconnect"):
#0 0x00007ffff53d84b6 in () at /usr/lib/libc.so.6
0000001 0x00007ffff53dacd0 in pthread_cond_wait () at /usr/lib/libc.so.6
#2 0x00007ffff77ce47b in ARDOUR::Session::auto_connect_thread_run() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff77ce8ae in ARDOUR::Session::auto_connect_thread(void*) () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
0000005 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

--Type <RET> for more, q to quit, c to continue without paging--
Thread 99 (Thread 0x7fff99ffb6c0 (LWP 4126) "SessionSignals"):
#0 0x00007ffff53d84b6 in () at /usr/lib/libc.so.6
0000001 0x00007ffff53dacd0 in pthread_cond_wait () at /usr/lib/libc.so.6
#2 0x00007ffff7809435 in ARDOUR::Session::emit_thread_run() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff780946e in ARDOUR::Session::emit_thread(void*) () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
0000005 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 98 (Thread 0x7fff9a7fc6c0 (LWP 4125) "midiUI"):
#0 0x00007ffff545037f in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff6be9c2f in () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff6b91d8f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
0000005 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 97 (Thread 0x7fffc9c526c0 (LWP 4124) "butler"):
#0 0x00007ffff545037f in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff6de178d in CrossThreadChannel::poll_for_request() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff6de1813 in CrossThreadChannel::receive(char&, bool) () at /usr/lib/ardour7/libpbd.so.4
#3 0x00007ffff73efbb2 in ARDOUR::Butler::thread_work() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007ffff6df4ffa in () at /usr/lib/ardour7/libpbd.so.4
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 88 (Thread 0x7fff9bfff6c0 (LWP 4115) "RT-6-(nil)"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6df6deb in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff748d30e in ARDOUR::Graph::run_one() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff7493f41 in ARDOUR::Graph::helper_thread() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007fffe8ad7ee2 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) () at /usr/lib/ardour7/backends/libjack_audiobackend.so
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 87 (Thread 0x7fffa9c656c0 (LWP 4114) "RT-5-(nil)"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
--Type <RET> for more, q to quit, c to continue without paging--
0000001 0x00007ffff6df6deb in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff748d30e in ARDOUR::Graph::run_one() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff7493f41 in ARDOUR::Graph::helper_thread() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007fffe8ad7ee2 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) () at /usr/lib/ardour7/backends/libjack_audiobackend.so
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 86 (Thread 0x7fffaa4666c0 (LWP 4113) "RT-4-(nil)"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6df6deb in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff748d30e in ARDOUR::Graph::run_one() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff7493f41 in ARDOUR::Graph::helper_thread() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007fffe8ad7ee2 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) () at /usr/lib/ardour7/backends/libjack_audiobackend.so
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 85 (Thread 0x7fffc8f416c0 (LWP 4112) "RT-3-(nil)"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6df6deb in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff748d30e in ARDOUR::Graph::run_one() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff7493f41 in ARDOUR::Graph::helper_thread() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007fffe8ad7ee2 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) () at /usr/lib/ardour7/backends/libjack_audiobackend.so
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 84 (Thread 0x7fffab4686c0 (LWP 4111) "RT-2-(nil)"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6df6deb in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff748d30e in ARDOUR::Graph::run_one() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff7493f41 in ARDOUR::Graph::helper_thread() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007fffe8ad7ee2 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) () at /usr/lib/ardour7/backends/libjack_audiobackend.so
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 83 (Thread 0x7fff9b7fe6c0 (LWP 4110) "RT-1-(nil)"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
--Type <RET> for more, q to quit, c to continue without paging--
0000001 0x00007ffff6df6deb in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff748d30e in ARDOUR::Graph::run_one() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff7493f41 in ARDOUR::Graph::helper_thread() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007fffe8ad7ee2 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) () at /usr/lib/ardour7/backends/libjack_audiobackend.so
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 82 (Thread 0x7fffa94646c0 (LWP 4109) "RT-main-(nil)"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6df6deb in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff7490c18 in ARDOUR::Graph::reached_terminal_node() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff7493dd9 in ARDOUR::Graph::main_thread() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007fffe8ad7ee2 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) () at /usr/lib/ardour7/backends/libjack_audiobackend.so
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 47 (Thread 0x7fffca7fc6c0 (LWP 4070) "audioengine"):
#0 0x00007ffff53dd64c in () at /usr/lib/libc.so.6
0000001 0x00007ffff538d938 in raise () at /usr/lib/libc.so.6
#2 0x00007ffff537753d in abort () at /usr/lib/libc.so.6
#3 0x00007ffff58110a2 in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:60
0000004 0x00007ffff7e951d8 in AudioGrapher::Analyser::process(AudioGrapher::ProcessContext<float> const&) () at /usr/lib/ardour7/libaudiographer.so.0
0000005 0x00007ffff737f7ad in () at /usr/lib/ardour7/libardour.so.3
#6 0x00007ffff7e98afc in AudioGrapher::Limiter::process(AudioGrapher::ProcessContext<float> const&) () at /usr/lib/ardour7/libaudiographer.so.0
#7 0x00007ffff7e98c4d in AudioGrapher::Normalizer::process(AudioGrapher::ProcessContext<float> const&) () at /usr/lib/ardour7/libaudiographer.so.0
0000008 0x00007ffff7e991e5 in AudioGrapher::SampleRateConverter::process(AudioGrapher::ProcessContext<float> const&) () at /usr/lib/ardour7/libaudiographer.so.0
0000009 0x00007ffff7466cfd in () at /usr/lib/ardour7/libardour.so.3
0000010 0x00007ffff737f7ad in () at /usr/lib/ardour7/libardour.so.3
0000011 0x00007ffff737f53f in () at /usr/lib/ardour7/libardour.so.3
0000012 0x00007ffff745848d in ARDOUR::ExportGraphBuilder::process(long, bool) () at /usr/lib/ardour7/libardour.so.3
0000013 0x00007ffff7472008 in ARDOUR::ExportHandler::process_timespan(long) () at /usr/lib/ardour7/libardour.so.3
0000014 0x00007ffff74721ce in ARDOUR::ExportHandler::process(long) () at /usr/lib/ardour7/libardour.so.3
#15 0x00007ffff77ed9ae in () at /usr/lib/ardour7/libardour.so.3
0000016 0x00007ffff77f1bfe in ARDOUR::Session::process_export(unsigned int) () at /usr/lib/ardour7/libardour.so.3
#17 0x00007ffff77f4412 in ARDOUR::Session::process_export_fw(unsigned int) () at /usr/lib/ardour7/libardour.so.3
--Type <RET> for more, q to quit, c to continue without paging--
0000018 0x00007ffff73ad990 in () at /usr/lib/ardour7/libardour.so.3
0000019 0x00007ffff73a5217 in ARDOUR::AudioEngine::process_callback(unsigned int) () at /usr/lib/ardour7/libardour.so.3
0000020 0x00007fffe8ade4c5 in ARDOUR::JACKAudioBackend::process_thread() () at /usr/lib/ardour7/backends/libjack_audiobackend.so
0000021 0x00007ffff7e42b27 in () at /usr/lib/spa-0.2/support/libspa-support.so
0000022 0x00007ffff3500047 in () at /usr/lib/libpipewire-0.3.so.0
0000023 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#24 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 46 (Thread 0x7fffcaffd6c0 (LWP 4069) "pw-ardour"):
#0 0x00007ffff545d356 in epoll_wait () at /usr/lib/libc.so.6
0000001 0x00007ffff7e518e9 in () at /usr/lib/spa-0.2/support/libspa-support.so
#2 0x00007ffff7e429db in () at /usr/lib/spa-0.2/support/libspa-support.so
#3 0x00007ffff354010a in () at /usr/lib/libpipewire-0.3.so.0
0000004 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
0000005 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 15 (Thread 0x7fffcbfff6c0 (LWP 4036) "gdbus"):
#0 0x00007ffff545037f in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff6be9c2f in () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff6b91d8f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff4950aec in () at /usr/lib/libgio-2.0.so.0
0000004 0x00007ffff6bbfdb5 in () at /usr/lib/libglib-2.0.so.0
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 14 (Thread 0x7fffcb7fe6c0 (LWP 4035) "gmain"):
#0 0x00007ffff545037f in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff6be9c2f in () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff6b910e2 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff6b91132 in () at /usr/lib/libglib-2.0.so.0
0000004 0x00007ffff6bbfdb5 in () at /usr/lib/libglib-2.0.so.0
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 9 (Thread 0x7fffe93d26c0 (LWP 4024) "DeviceList"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
--Type <RET> for more, q to quit, c to continue without paging--
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff73a584c in ARDOUR::AudioEngine::do_devicelist_update() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
0000005 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 8 (Thread 0x7fffe9ffb6c0 (LWP 4023) "EngineWatchdog"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff73a6bd1 in ARDOUR::AudioEngine::do_reset_backend() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
0000005 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 6 (Thread 0x7fffea7fc6c0 (LWP 4021) "Analyzer"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff73849d9 in ARDOUR::Analyser::work() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
0000005 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 5 (Thread 0x7fffeaffd6c0 (LWP 4020) "PeakFileBuilder"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7858f9c in () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
0000005 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 4 (Thread 0x7fffeb7fe6c0 (LWP 4019) "PeakFileBuilder"):
#0 0x00007ffff5455abd in syscall () at /usr/lib/libc.so.6
0000001 0x00007ffff6be2e55 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff7858f9c in () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff6df50aa in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
--Type <RET> for more, q to quit, c to continue without paging--
0000005 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 3 (Thread 0x7fffebfff6c0 (LWP 4018) "LXVSTEventLoop"):
#0 0x00007ffff5422825 in clock_nanosleep () at /usr/lib/libc.so.6
0000001 0x00007ffff5427337 in nanosleep () at /usr/lib/libc.so.6
#2 0x00007ffff6bbd491 in g_usleep () at /usr/lib/libglib-2.0.so.0
#3 0x00005555561d2327 in ()
0000004 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
0000005 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 2 (Thread 0x7ffff05f36c0 (LWP 4017) "Trigger Worker"):
#0 0x00007ffff545037f in poll () at /usr/lib/libc.so.6
0000001 0x00007ffff6de178d in CrossThreadChannel::poll_for_request() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff6de1813 in CrossThreadChannel::receive(char&, bool) () at /usr/lib/ardour7/libpbd.so.4
#3 0x00007ffff7898b42 in ARDOUR::TriggerBoxThread::thread_work() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007ffff6df4ffa in () at /usr/lib/ardour7/libpbd.so.4
0000005 0x00007ffff53db8fd in () at /usr/lib/libc.so.6
#6 0x00007ffff545dd20 in () at /usr/lib/libc.so.6

Thread 1 (Thread 0x7ffff0ad3fc0 (LWP 4014) "ArdourGUI"):
#0 0x00007ffff5422825 in clock_nanosleep () at /usr/lib/libc.so.6
0000001 0x00007ffff5427337 in nanosleep () at /usr/lib/libc.so.6
#2 0x00007ffff6bbd491 in g_usleep () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff783f3ef in ARDOUR::SimpleExport::run_export() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00005555560e8ee7 in ()
0000005 0x00007ffff6d388cd in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () at /usr/lib/libglibmm-2.4.so.1
#6 0x00007ffff6c90210 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#7 0x00007ffff6cbe186 in () at /usr/lib/libgobject-2.0.so.0
0000008 0x00007ffff6cadf85 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000009 0x00007ffff6cae214 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
0000010 0x00007ffff6769596 in () at /usr/lib/libgtk-x11-2.0.so.0
0000011 0x00007ffff6c90210 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
0000012 0x00007ffff6cbdb57 in () at /usr/lib/libgobject-2.0.so.0
0000013 0x00007ffff6cadf85 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000014 0x00007ffff6cae214 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#15 0x00007ffff676846a in () at /usr/lib/libgtk-x11-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
0000016 0x00007ffff68170a8 in () at /usr/lib/libgtk-x11-2.0.so.0
#17 0x00007ffff6c90146 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
0000018 0x00007ffff6cbdfe7 in () at /usr/lib/libgobject-2.0.so.0
0000019 0x00007ffff6cad990 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000020 0x00007ffff6cae214 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
0000021 0x00007ffff693c275 in () at /usr/lib/libgtk-x11-2.0.so.0
0000022 0x00007ffff68156d6 in gtk_propagate_event () at /usr/lib/libgtk-x11-2.0.so.0
0000023 0x00007ffff6815b4b in gtk_main_do_event () at /usr/lib/libgtk-x11-2.0.so.0
#24 0x00007ffff66843be in () at /usr/lib/libgdk-x11-2.0.so.0
0000025 0x00007ffff6b9282b in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
0000026 0x00007ffff6be9cc9 in () at /usr/lib/libglib-2.0.so.0
0000027 0x00007ffff6b91d8f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
0000028 0x00007ffff679876b in gtk_dialog_run () at /usr/lib/libgtk-x11-2.0.so.0
0000029 0x0000555555bf38f0 in ()
0000030 0x00007ffff6d388cd in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () at /usr/lib/libglibmm-2.4.so.1
0000031 0x00007ffff6c90210 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
0000032 0x00007ffff6cbe186 in () at /usr/lib/libgobject-2.0.so.0
0000033 0x00007ffff6cadf85 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000034 0x00007ffff6cae214 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
0000035 0x00007ffff674f5c5 in () at /usr/lib/libgtk-x11-2.0.so.0
0000036 0x00007ffff6c90210 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
0000037 0x00007ffff6cbdb57 in () at /usr/lib/libgobject-2.0.so.0
0000038 0x00007ffff6cadf85 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000039 0x00007ffff6cae214 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
0000040 0x00007ffff693afb5 in gtk_widget_activate () at /usr/lib/libgtk-x11-2.0.so.0
0000041 0x00007ffff6829df1 in gtk_menu_shell_activate_item () at /usr/lib/libgtk-x11-2.0.so.0
0000042 0x00007ffff682a10f in () at /usr/lib/libgtk-x11-2.0.so.0
0000043 0x00007ffff68170a8 in () at /usr/lib/libgtk-x11-2.0.so.0
0000044 0x00007ffff6c90210 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
0000045 0x00007ffff6cbdfe7 in () at /usr/lib/libgobject-2.0.so.0
0000046 0x00007ffff6cad990 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
0000047 0x00007ffff6cae214 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
0000048 0x00007ffff693c275 in () at /usr/lib/libgtk-x11-2.0.so.0
0000049 0x00007ffff68156d6 in gtk_propagate_event () at /usr/lib/libgtk-x11-2.0.so.0
0000050 0x00007ffff6815b4b in gtk_main_do_event () at /usr/lib/libgtk-x11-2.0.so.0
0000051 0x00007ffff66843be in () at /usr/lib/libgdk-x11-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
0000052 0x00007ffff6b9282b in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
0000053 0x00007ffff6be9cc9 in () at /usr/lib/libglib-2.0.so.0
0000054 0x00007ffff6b91d8f in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
0000055 0x00007ffff68149fe in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0
0000056 0x00007ffff6e85d29 in Gtkmm2ext::UI::run(Receiver&) () at /usr/lib/ardour7/libgtkmm2ext.so.0
0000057 0x00005555559dd666 in main ()
(0027297)
x42   
2023-02-06 05:37   
This should already be fixed since 7.2-46-g140b373cac

It happens if you use GUI scaling other than 100% (Preferences > Apperance > Size and scale)
Resetting the scale to 100% should work around this, or you can try a nightly build https://nightly.ardour.org/

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9175 [ardour] bugs crash have not tried 2022-12-19 09:24 2023-11-10 13:47
Reporter: musew Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when creating new MIDI track
Description: Just what it says; this is a midi-only session with a few tracks; created a new one and it crashed as soon as I hit add in the dialog box.

Here's the backtrace:

(gdb) thread apply all bt

Thread 550 (Thread 0x7fffca6e3a40 (LWP 36259) "RT-main-(nil)"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff7061e8b in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff781a9cb in ARDOUR::Graph::main_thread() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007fffe8cb24f2 in ARDOUR::AlsaAudioBackend::alsa_process_thread(void*) () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 549 (Thread 0x7fffa37fe6c0 (LWP 36258) "ALSA-MIDI-LIST"):
#0 0x00007ffff565a0bf in __GI___poll (fds=0x7fffb42d86a0, nfds=1, timeout=200) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007fffe8cb6281 in ARDOUR::AlsaAudioBackend::midi_device_thread() () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
#2 0x00007fffe8cb635e in ARDOUR::AlsaAudioBackend::_midi_device_thread(void*) () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
#3 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000004 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 548 (Thread 0x7fffc8f91a40 (LWP 36257) "audioengine"):
#0 0x00007fffa182fd13 in non-virtual thunk to calf_plugins::wavetable_audio_module::make_snapshot(int) () at /usr/lib/lv2/calf.lv2/calf.so
0000001 0x00007fffa182f7a5 in calf_plugins::wavetable_audio_module::process(unsigned int, unsigned int, unsigned int, unsigned int) () at /usr/lib/lv2/calf.lv2/calf.so
#2 0x00007fffa182f19a in non-virtual thunk to calf_plugins::audio_module<calf_plugins::wavetable_metadata>::process_slice(unsigned int, unsigned int) () at /usr/lib/lv2/calf.lv2/calf.so
#3 0x00007fffa1756450 in calf_plugins::lv2_instance::run(unsigned int, bool) () at /usr/lib/lv2/calf.lv2/calf.so
0000004 0x00007ffff7c40a29 in ARDOUR::LV2Plugin::run(unsigned int, bool) () at /usr/lib/ardour7/libardour.so.3
0000005 0x00007ffff7c45b95 in ARDOUR::LV2Plugin::connect_and_run(ARDOUR::BufferSet&, long, long, double, ARDOUR::ChanMapping const&, ARDOUR::ChanMapping const&, unsigned int, long) () at /usr/lib/ardour7/libardour.so.3
#6 0x00007ffff7a70a67 in ARDOUR::PluginInsert::connect_and_run(ARDOUR::BufferSet&, long, long, double, unsigned int, long, bool) () at /usr/lib/ardour7/libardour.so.3
#7 0x00007ffff7a72e98 in ARDOUR::PluginInsert::run(ARDOUR::BufferSet&, long, long, double, unsigned int, bool) () at /usr/lib/ardour7/libardour.so.3
0000008 0x00007ffff7af16cd in ARDOUR::Route::process_output_buffers(ARDOUR::BufferSet&, long, long, unsigned int, bool, bool) () at /usr/lib/ardour7/libardo--Type <RET> for more, q to quit, c to continue without paging--c
ur.so.3
0000009 0x00007ffff7af25c4 in ARDOUR::Route::run_route(long, long, unsigned int, bool, bool) () at /usr/lib/ardour7/libardour.so.3
0000010 0x00007ffff7b0359e in ARDOUR::Route::no_roll_unlocked(unsigned int, long, long, bool) () at /usr/lib/ardour7/libardour.so.3
0000011 0x00007ffff7a04829 in ARDOUR::MidiTrack::no_roll_unlocked(unsigned int, long, long, bool) () at /usr/lib/ardour7/libardour.so.3
0000012 0x00007ffff7afbcec in ARDOUR::Route::no_roll(unsigned int, long, long, bool) () at /usr/lib/ardour7/libardour.so.3
0000013 0x00007ffff7b8b4e9 in ARDOUR::Session::no_roll(unsigned int) () at /usr/lib/ardour7/libardour.so.3
0000014 0x00007ffff7b8c66d in ARDOUR::Session::process_without_events(unsigned int) () at /usr/lib/ardour7/libardour.so.3
#15 0x00007ffff7b8d085 in ARDOUR::Session::process_with_events(unsigned int) () at /usr/lib/ardour7/libardour.so.3
0000016 0x00007ffff7b8f603 in ARDOUR::Session::process(unsigned int) () at /usr/lib/ardour7/libardour.so.3
#17 0x00007ffff772f0b9 in ARDOUR::AudioEngine::process_callback(unsigned int) () at /usr/lib/ardour7/libardour.so.3
0000018 0x00007fffe8cc263c in ARDOUR::AlsaAudioBackend::main_process_thread() () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
0000019 0x00007fffe8cb66a0 in () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
0000020 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000021 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 547 (Thread 0x7fffc985fa40 (LWP 36256) "AlsaMidiIO"):
#0 0x00007ffff565a0bf in __GI___poll (fds=0x55556473ccb0, nfds=1, timeout=100) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007fffe8cd2bd7 in ARDOUR::AlsaRawMidiIn::main_process_thread() () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
#2 0x00007fffe8cbc4be in () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
#3 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000004 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 546 (Thread 0x7fffc8ee5a40 (LWP 36255) "AlsaMidiIO"):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55556519eee8) at futex-internal.c:57
0000001 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x55556519eee8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2 0x00007ffff55e251f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x55556519eee8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3 0x00007ffff55e4cd0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55556519ee98, cond=0x55556519eec0) at pthread_cond_wait.c:503
0000004 ___pthread_cond_wait (cond=0x55556519eec0, mutex=0x55556519ee98) at pthread_cond_wait.c:618
0000005 0x00007fffe8ccb054 in ARDOUR::AlsaRawMidiOut::main_process_thread() () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
#6 0x00007fffe8cbc4be in () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
#7 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000008 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 545 (Thread 0x7fffc8ed9a40 (LWP 36254) "AlsaMidiIO"):
#0 0x00007ffff565a0bf in __GI___poll (fds=0x555563a5df30, nfds=1, timeout=100) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007fffe8cd2bd7 in ARDOUR::AlsaRawMidiIn::main_process_thread() () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
#2 0x00007fffe8cbc4be in () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
#3 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000004 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 544 (Thread 0x7fffc8ecda40 (LWP 36253) "AlsaMidiIO"):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x5555617dbbb8) at futex-internal.c:57
0000001 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x5555617dbbb8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2 0x00007ffff55e251f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x5555617dbbb8, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3 0x00007ffff55e4cd0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5555617dbb68, cond=0x5555617dbb90) at pthread_cond_wait.c:503
0000004 ___pthread_cond_wait (cond=0x5555617dbb90, mutex=0x5555617dbb68) at pthread_cond_wait.c:618
0000005 0x00007fffe8ccb054 in ARDOUR::AlsaRawMidiOut::main_process_thread() () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
#6 0x00007fffe8cbc4be in () at /usr/lib/ardour7/backends/libalsa_audiobackend.so
#7 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000008 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 543 (Thread 0x7fffa3fff6c0 (LWP 36252) "ExecStdOut"):
#0 0x00007ffff565a0bf in __GI___poll (fds=0x7fffa3ffcad0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff706ce69 in PBD::SystemExec::output_interposer() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff70704ae in () at /usr/lib/ardour7/libpbd.so.4
#3 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000004 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 445 (Thread 0x7fffaaffd6c0 (LWP 34888) "LV2Worker"):
#0 futex_wait (val=8, addr=0x7fffb017e1a4) at /usr/src/debug/gcc/libgomp/config/linux/x86/futex.h:97
0000001 do_wait (val=8, addr=0x7fffb017e1a4) at /usr/src/debug/gcc/libgomp/config/linux/wait.h:67
#2 gomp_barrier_wait_end (bar=0x7fffb017e1a0, state=8) at /usr/src/debug/gcc/libgomp/config/linux/bar.c:48
#3 0x00007ffff3a563e0 in gomp_simple_barrier_wait (bar=0x7fffb017e1a0) at /usr/src/debug/gcc/libgomp/config/posix/simple-bar.h:60
0000004 gomp_thread_start (xdata=<optimized out>) at /usr/src/debug/gcc/libgomp/team.c:133
0000005 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#6 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 444 (Thread 0x7fffaa7fc6c0 (LWP 34889) "LV2Worker"):
#0 futex_wait (val=8, addr=0x7fffa4364794) at /usr/src/debug/gcc/libgomp/config/linux/x86/futex.h:97
0000001 do_wait (val=8, addr=0x7fffa4364794) at /usr/src/debug/gcc/libgomp/config/linux/wait.h:67
#2 gomp_barrier_wait_end (bar=0x7fffa4364790, state=8) at /usr/src/debug/gcc/libgomp/config/linux/bar.c:48
#3 0x00007ffff3a563e0 in gomp_simple_barrier_wait (bar=0x7fffa4364790) at /usr/src/debug/gcc/libgomp/config/posix/simple-bar.h:60
0000004 gomp_thread_start (xdata=<optimized out>) at /usr/src/debug/gcc/libgomp/team.c:133
0000005 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#6 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 443 (Thread 0x7fffabfff6c0 (LWP 34887) "LV2Worker"):
#0 futex_wait (val=8, addr=0x7fffc4009894) at /usr/src/debug/gcc/libgomp/config/linux/x86/futex.h:97
0000001 do_wait (val=8, addr=0x7fffc4009894) at /usr/src/debug/gcc/libgomp/config/linux/wait.h:67
#2 gomp_barrier_wait_end (bar=0x7fffc4009890, state=8) at /usr/src/debug/gcc/libgomp/config/linux/bar.c:48
#3 0x00007ffff3a563e0 in gomp_simple_barrier_wait (bar=0x7fffc4009890) at /usr/src/debug/gcc/libgomp/config/posix/simple-bar.h:60
0000004 gomp_thread_start (xdata=<optimized out>) at /usr/src/debug/gcc/libgomp/team.c:133
0000005 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#6 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 442 (Thread 0x7fffb8d666c0 (LWP 34886) "LV2Worker"):
#0 futex_wait (val=8, addr=0x7fffb4015fc4) at /usr/src/debug/gcc/libgomp/config/linux/x86/futex.h:97
0000001 do_wait (val=8, addr=0x7fffb4015fc4) at /usr/src/debug/gcc/libgomp/config/linux/wait.h:67
#2 gomp_barrier_wait_end (bar=0x7fffb4015fc0, state=8) at /usr/src/debug/gcc/libgomp/config/linux/bar.c:48
#3 0x00007ffff3a563e0 in gomp_simple_barrier_wait (bar=0x7fffb4015fc0) at /usr/src/debug/gcc/libgomp/config/posix/simple-bar.h:60
0000004 gomp_thread_start (xdata=<optimized out>) at /usr/src/debug/gcc/libgomp/team.c:133
0000005 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#6 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 441 (Thread 0x7fffb95676c0 (LWP 34885) "AutomationWatch"):
#0 0x00007ffff562c7c5 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffb9566b40, rem=rem@entry=0x7fffb9566b30) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
0000001 0x00007ffff56312d7 in __GI___nanosleep (req=req@entry=0x7fffb9566b40, rem=rem@entry=0x7fffb9566b30) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2 0x00007ffff6def4e1 in g_usleep (microseconds=<optimized out>) at ../glib/glib/gtimer.c:279
#3 0x00007ffff7776d26 in ARDOUR::AutomationWatch::thread() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000005 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#6 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 440 (Thread 0x7fffb9d686c0 (LWP 34884) "autoconnect"):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55555d2c3a38) at futex-internal.c:57
0000001 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x55555d2c3a38, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2 0x00007ffff55e251f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x55555d2c3a38, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3 0x00007ffff55e4cd0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55555d2c39e8, cond=0x55555d2c3a10) at pthread_cond_wait.c:503
0000004 ___pthread_cond_wait (cond=0x55555d2c3a10, mutex=0x55555d2c39e8) at pthread_cond_wait.c:618
0000005 0x00007ffff7b54b7b in ARDOUR::Session::auto_connect_thread_run() () at /usr/lib/ardour7/libardour.so.3
#6 0x00007ffff7b54fae in ARDOUR::Session::auto_connect_thread(void*) () at /usr/lib/ardour7/libardour.so.3
#7 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000008 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 439 (Thread 0x7fffba5696c0 (LWP 34883) "SessionSignals"):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55555d2c39cc) at futex-internal.c:57
0000001 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x55555d2c39cc, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2 0x00007ffff55e251f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x55555d2c39cc, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3 0x00007ffff55e4cd0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55555d2c3978, cond=0x55555d2c39a0) at pthread_cond_wait.c:503
0000004 ___pthread_cond_wait (cond=0x55555d2c39a0, mutex=0x55555d2c3978) at pthread_cond_wait.c:618
0000005 0x00007ffff7b8fad5 in ARDOUR::Session::emit_thread_run() () at /usr/lib/ardour7/libardour.so.3
#6 0x00007ffff7b8fb0e in ARDOUR::Session::emit_thread(void*) () at /usr/lib/ardour7/libardour.so.3
#7 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000008 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 425 (Thread 0x7fffbad6a6c0 (LWP 34869) "LV2Worker"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff7061e8b in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff7c277f6 in ARDOUR::Worker::run() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 411 (Thread 0x7fffab7fe6c0 (LWP 34855) "LV2Worker"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff7061e8b in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff7c277f6 in ARDOUR::Worker::run() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 397 (Thread 0x7fffbbd6c6c0 (LWP 34841) "LV2Worker"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff7061e8b in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff7c277f6 in ARDOUR::Worker::run() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 383 (Thread 0x7fffbb56b6c0 (LWP 34826) "LV2Worker"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff7061e8b in PBD::Semaphore::wait() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff7c277f6 in ARDOUR::Worker::run() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 382 (Thread 0x7fffa9ffb6c0 (LWP 34825) "midiUI"):
#0 0x00007ffff565a0bf in __GI___poll (fds=0x7fffc0041900, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff6e1b1ff in g_main_context_poll (priority=<optimized out>, n_fds=4, fds=0x7fffc0041900, timeout=<optimized out>, context=0x555559895e90) at ../glib/glib/gmain.c:4543
#2 g_main_context_iterate.constprop.0 (context=0x555559895e90, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4233
#3 0x00007ffff6dc3ddf in g_main_loop_run (loop=0x55555e11b7e0) at ../glib/glib/gmain.c:4438
0000004 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000005 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#6 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 381 (Thread 0x7fffc8d416c0 (LWP 34824) "butler"):
#0 0x00007ffff565a0bf in __GI___poll (fds=0x7fffc8d405b0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff704c80d in CrossThreadChannel::poll_for_request() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff704c893 in CrossThreadChannel::receive(char&, bool) () at /usr/lib/ardour7/libpbd.so.4
#3 0x00007ffff7779212 in ARDOUR::Butler::thread_work() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007ffff706006a in () at /usr/lib/ardour7/libpbd.so.4
0000005 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#6 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 32 (Thread 0x7fffcbfff6c0 (LWP 34178) "gdbus"):
#0 0x00007ffff565a0bf in __GI___poll (fds=0x555556b82af0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff6e1b1ff in g_main_context_poll (priority=<optimized out>, n_fds=2, fds=0x555556b82af0, timeout=<optimized out>, context=0x555556b81630) at ../glib/glib/gmain.c:4543
#2 g_main_context_iterate.constprop.0 (context=0x555556b81630, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4233
#3 0x00007ffff6dc3ddf in g_main_loop_run (loop=0x555556b81720) at ../glib/glib/gmain.c:4438
0000004 0x00007ffff4b6237c in gdbus_shared_thread_func (user_data=0x555556b81600) at ../glib/gio/gdbusprivate.c:284
0000005 0x00007ffff6df1e05 in g_thread_proxy (data=0x555556b7cd20) at ../glib/glib/gthread.c:831
#6 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#7 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 31 (Thread 0x7fffcb7fe6c0 (LWP 34177) "gmain"):
#0 0x00007ffff565a0bf in __GI___poll (fds=0x555556b6bad0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff6e1b1ff in g_main_context_poll (priority=<optimized out>, n_fds=2, fds=0x555556b6bad0, timeout=<optimized out>, context=0x555556b6ba10) at ../glib/glib/gmain.c:4543
#2 g_main_context_iterate.constprop.0 (context=0x555556b6ba10, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4233
#3 0x00007ffff6dc3132 in g_main_context_iteration (context=0x555556b6ba10, may_block=may_block@entry=1) at ../glib/glib/gmain.c:4303
0000004 0x00007ffff6dc3182 in glib_worker_main (data=<optimized out>) at ../glib/glib/gmain.c:6414
0000005 0x00007ffff6df1e05 in g_thread_proxy (data=0x555556b7a6a0) at ../glib/glib/gthread.c:831
#6 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#7 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 9 (Thread 0x7fffe95496c0 (LWP 34141) "DeviceList"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6e14695 in g_cond_wait (cond=0x555556772de8, mutex=0x555556772df8) at ../glib/glib/gthread-posix.c:1590
#2 0x00007ffff772f6dc in ARDOUR::AudioEngine::do_devicelist_update() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 8 (Thread 0x7fffe9ffb6c0 (LWP 34140) "EngineWatchdog"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6e14695 in g_cond_wait (cond=0x555556772db8, mutex=0x555556772dc8) at ../glib/glib/gthread-posix.c:1590
#2 0x00007ffff7730a61 in ARDOUR::AudioEngine::do_reset_backend() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 6 (Thread 0x7fffea7fc6c0 (LWP 34115) "Analyzer"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6e14695 in g_cond_wait (cond=0x7ffff7f7e400 <ARDOUR::Analyser::SourcesToAnalyse>, mutex=0x7ffff7f7e3f8 <ARDOUR::Analyser::analysis_queue_lock>) at ../glib/glib/gthread-posix.c:1590
#2 0x00007ffff770e899 in ARDOUR::Analyser::work() () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 5 (Thread 0x7fffeaffd6c0 (LWP 34114) "PeakFileBuilder"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6e14695 in g_cond_wait (cond=0x7ffff7f808c0 <ARDOUR::SourceFactory::PeaksToBuild>, mutex=0x7ffff7f808d8 <ARDOUR::SourceFactory::peak_building_lock>) at ../glib/glib/gthread-posix.c:1590
#2 0x00007ffff7bdf8ec in () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 4 (Thread 0x7fffeb7fe6c0 (LWP 34113) "PeakFileBuilder"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff6e14695 in g_cond_wait (cond=0x7ffff7f808c0 <ARDOUR::SourceFactory::PeaksToBuild>, mutex=0x7ffff7f808d8 <ARDOUR::SourceFactory::peak_building_lock>) at ../glib/glib/gthread-posix.c:1590
#2 0x00007ffff7bdf8ec in () at /usr/lib/ardour7/libardour.so.3
#3 0x00007ffff706011a in PBD::Thread::_run(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x7fffebfff6c0 (LWP 34112) "LXVSTEventLoop"):
#0 0x00007ffff562c7c5 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffebffe9b0, rem=rem@entry=0x7fffebffe9a0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
0000001 0x00007ffff56312d7 in __GI___nanosleep (req=req@entry=0x7fffebffe9b0, rem=rem@entry=0x7fffebffe9a0) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2 0x00007ffff6def4e1 in g_usleep (microseconds=<optimized out>) at ../glib/glib/gtimer.c:279
#3 0x00005555561cdb27 in ()
0000004 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x7ffff075c6c0 (LWP 34111) "Trigger Worker"):
#0 0x00007ffff565a0bf in __GI___poll (fds=0x7ffff075bad0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff704c80d in CrossThreadChannel::poll_for_request() () at /usr/lib/ardour7/libpbd.so.4
#2 0x00007ffff704c893 in CrossThreadChannel::receive(char&, bool) () at /usr/lib/ardour7/libpbd.so.4
#3 0x00007ffff7c1e922 in ARDOUR::TriggerBoxThread::thread_work() () at /usr/lib/ardour7/libardour.so.3
0000004 0x00007ffff706006a in () at /usr/lib/ardour7/libpbd.so.4
0000005 0x00007ffff55e58fd in start_thread (arg=<optimized out>) at pthread_create.c:442
#6 0x00007ffff5667a60 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 1 (Thread 0x7ffff0bf5a40 (LWP 33958) "ArdourGUI"):
#0 0x0000555555a14c9e in ()
0000001 0x0000555555a1568a in ()
#2 0x00007ffff706dc5a in PBD::StandardTimer::on_elapsed() () at /usr/lib/ardour7/libpbd.so.4
#3 0x00007ffff706df3e in PBD::Timer::_timeout_handler(void*) () at /usr/lib/ardour7/libpbd.so.4
0000004 0x00007ffff6dc50a2 in g_timeout_dispatch (source=0x55555e9188c0, callback=<optimized out>, user_data=<optimized out>) at ../glib/glib/gmain.c:5007
0000005 0x00007ffff6dc487b in g_main_dispatch (context=0x55555676a260) at ../glib/glib/gmain.c:3444
#6 g_main_context_dispatch (context=0x55555676a260) at ../glib/glib/gmain.c:4162
#7 0x00007ffff6e1b299 in g_main_context_iterate.constprop.0 (context=0x55555676a260, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4238
0000008 0x00007ffff6dc3ddf in g_main_loop_run (loop=0x5555574dd770) at ../glib/glib/gmain.c:4438
0000009 0x00007ffff6a3d9fe in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0
0000010 0x00007ffff70f0cd9 in Gtkmm2ext::UI::run(Receiver&) () at /usr/lib/ardour7/libgtkmm2ext.so.0
0000011 0x00005555559d7f96 in main ()
Tags:
Steps To Reproduce: have not tried
Additional Information:
System Description
Attached Files:
Notes
(0027120)
paul   
2022-12-19 19:12   
Looks like a crash in a CALF plugin. Run in safe mode or try removing/disabling the CALF plugin.

We do not endorse/encourage the use of these plugins.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9529 [ardour] bugs minor always 2023-11-10 08:33 2023-11-10 13:27
Reporter: garyd Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: LuaSignalS fires 10 times per second
Description: LuaSignalS should fire once per second according to the documentation. Instead it's firing 10 times per second, thus no different to LuaSignalDS.
Tags:
Steps To Reproduce: Add the attached script as an Action Hook.

View > Log

There are 10 lines added every second. Should be only 1 per second.
Additional Information: Nothing critical for me personally. Just thought I'd mention it.
System Description
Attached Files: LuaTimerS_Test.lua (448 bytes) 2023-11-10 08:33
https://tracker.ardour.org/file_download.php?file_id=4707&type=bug
Notes
(0028311)
x42   
2023-11-10 13:27   
Oh dear, indeed. fixed in Ardour 8.1-82

Thanks!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9528 [ardour] other trivial always 2023-11-10 00:12 2023-11-10 00:12
Reporter: Schmitty2005 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: low OS Version: 10  
Status: new Product Version: Mixbus 9.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Weblinks in Help->About and Help->Website need update
Description: Weblinks in Help->About and Help->Website need update. They point to old weblinks that redirect to https://www.harrisonaudio.com/, not the specific Mixbus Page which would likely be : https://store.harrisonaudio.com/all-products/mixbus32c

Tags:
Steps To Reproduce: Click weblinks in Help-> About and Help->Website.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9526 [ardour] bugs minor always 2023-11-06 10:57 2023-11-07 15:13
Reporter: prokoudine Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Step entry does not create start/end markers
Description: 1. Create a new session
2. Add a MIDI track
3. Do step entry
4. Close the step entry dialog

Content is added, but no start/end markers are created. You can't play what you entered.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028300)
paul   
2023-11-07 15:13   
fixed as of e658056cd7 (also 9e4a6956894 was significant)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9525 [ardour] bugs crash sometimes 2023-11-04 23:27 2023-11-04 23:27
Reporter: Francisco Platform: Microsoft  
Assigned To: OS: Windows  
Priority: high OS Version: 11  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes
Description: Ardour crashes and the program it close suddenly while you are editting. The work you were doing it dissapears and Ardour it's uncapable of recovering the last session.
Tags:
Steps To Reproduce: The fail appeared while I were cutting a large audio track.
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9524 [ardour] bugs crash always 2023-11-04 18:13 2023-11-04 18:13
Reporter: skygge Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when inserting the "Collective" VST3 plugin.
Description: I purchased recently the "Collective" synthesizer/sampler plugin from Tracktion: https://www.tracktion.com/products/collective
It's a very good sounding plugin with a huge bank of presets/samples.

Unfortunately Ardour crashes if I insert this plugin into a MIDI track. Even more: Ardour crashes only if the presets archive is unpacked into plugin preset directory.
Without presets uploaded the plugin opens and runs OK.

If you guys can look into attached trace file to see why the plugin doesn't work with Ardour... Maybe this is easy to fix... I don't know.
It works (under Linux) in Tracktion 12.5 (it's obvious) an Bitwig Studio. It crashes in Reaper and Qtractor and Ardour.
Thanks!
Tags:
Steps To Reproduce: Add MIDI track. Insert Collective plugin with banks/presets uploaded in ~/Traction/Collective/(Instruments|Samples)
Additional Information:
System Description
Attached Files: trace_collective_vst3_plugin.log (57,498 bytes) 2023-11-04 18:13
https://tracker.ardour.org/file_download.php?file_id=4701&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9428 [ardour] bugs minor always 2023-08-01 07:03 2023-11-03 23:37
Reporter: psmith Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cue Learn Midi does not work
Description: I cannot get midi input to trigger clip playback from the cue.

I have tried using Virtual MIDI keyboard and Akai MPKMini. Using either of these keyboards I can play to synthesizer tracks. I can also map midi controls to faders, and then I can control faders from midi keyboard. But trying to get "midi learn" function to work from the Cue view never works.

In MIDI connection manager I have connected the keyboard to "Cue Control In". In MIDI tracer I can see the midi keyboard inputs displayed in the "Cue Control In".

The documentation https://manual.ardour.org/cue/setting-up-cues/playing-back-the-cues/ says that this should work. Have I mis-configured or missed a step? Or is it broken?

Thanks
Tags:
Steps To Reproduce: Launch Ardour with new session and empty template.
Open the following Windows: MIDI Tracer, MIDI Connections, Virtual Keyboard.
Go to Cue view by clicking "Cue" at top right.
Drag Click-120bpm.flac from the clips list and drop in the cue so it is imported into cue A slot1
Check the clip plays when the Play arrow is clicked with the mouse.
In the MIDI connections window, connect the Virtual Keyboard source to the "Cue Control In" Ardour destination
In the MIDI Tracer pick the "Cue Control In" dropdown.
Check that note presses on the virtual keyboard show up in MIDI tracer.

Right click on the clip slot in A1 and pick "MIDI Learn" from the dropdown. The dropdown disappears, there is no prompt for any further action.
Press a note on the virtual keyboard, the keypress information shows up in MIDI tracer.
Press the note on the virtual keyboard again. I expect the clip to play, but nothing happens.
Additional Information: forum message refers https://discourse.ardour.org/t/learning-midi-key-to-play-a-cue-clip/109015.

Ardour version :Ardour 7.5.0~ds "Neroli"
(rev 7.5.0~ds-1~bpo22.04.1~ppa1)
Intel 64-bit

Running on Ubuntu Studio
System Description
Attached Files: Screenshot_20230731_091614.png (174,571 bytes) 2023-08-01 07:03
https://tracker.ardour.org/file_download.php?file_id=4612&type=bug
png
Notes
(0027929)
paul   
2023-08-01 14:22   
Working fine here. Please test with a nightly build from ardour.org
(0027930)
psmith   
2023-08-01 15:46   
Interesting... I installed https://nightly.ardour.org/d/A_Linux_x86_64_FREE-gcc5abi/Ardour-7.5.240-demo-x86_64.run from https://nightly.ardour.org/list.php

and that works, exactly as it should.

downloaded and ran the packaged version from Ardour website Ardour 7.5.0 from https://community.ardour.org/download-paid?platform=linux&architecture=x86_64 and it does not work
"Neroli"
(rev 7.5)

downloaded and ran full paid nightly version https://nightly.ardour.org/d/A_Linux_x86_64-gcc5abi/Ardour-7.5.240-x86_64.run and it does not work.
Ardour 7.5.240
"Neroli"
(rev 7.5-240-g1d31ace29d)
Intel 64-bit

Reinstalled and ran the nightly demo build again, and it works again.

So i cannot get any full version to learn midi in the cue view but the nightly demo works perfectly.
(0027934)
psmith   
2023-08-02 11:26   
This is very weird.
Tried the latest nightly demo (.243) this morning and it didn't work.
Reverted to yesterdays nightly demo (.240), which worked yesterday, it no longer works.

So it looks like there is some config variable or file that has been overwritten or deleted....

The binary that worked yesterday does not work today... so that implies it is a config issue... I think.
(0027939)
psmith   
2023-08-02 15:29   
Might be getting somewhere now ... I have got it working properly on last night's full build!
Ardour 7.5.243
"Neroli"
(rev 7.5-243-g9f4a0b444e)
Intel 64-bit

I think it only works if I drop a midi clip into the cue view and do a "midi learn" on that slot first. I can then import an audio clip onto the cues and "midi learn" works on that slot.

If I don't import a midi clip, or import the midi clip second then it doesn't work.

My hypothesis is that importing the MIDI clip to a cue slot is "fixing" the config option that I have missed, or is setting up some pre-requisite that I cannot get at from the GUI.

Needs more testing as I am a bit baffled and have made many config changes at this point....
(0027981)
zettberlin   
2023-08-18 08:24   
I have the same issue with a build from git I made about 1h ago.
Ardour 7.5.321
"Neroli"
(rev 7.5-321-gb354f41fc2)

My Behringer UMX shows up in the midi tracer window and delivers control messages as expected there.
But neither Midi learn for cue slots nor via middleclick does anything.
(0027997)
psmith   
2023-08-27 08:18   
Windows nightly build does not learn midi cue inputs either. control inputs eg fader mappings work fine.
(0028000)
psmith   
2023-08-29 06:32   
Update: I just renamed the User Appdata\Ardour7\config file and restarted Ardour on Windows and started a New empty session...
then dragged a midi clip onto the cue view
checked that I could hear the cue and also hear notes played on the virtual MIDI keyboard
opened MIDI connections and clicked the box to connect virtual keyboard to cue control in

 and this time cue learn with the virtual midi keyboard worked.

So it looks to me that it is the same behaviour on Windows and Linux. It works if the cue learn on the midi track is the first thing you do with a default config file... but if you do something different first then the config gets messed up and cue learn never works again.
(0028226)
FelixHeppner   
2023-10-18 16:45   
I face the exact same problem with Ardour 8.0 on Linux.
Midi learn for cues works on a fresh session when a midi cue is added first. But it is easy to somehow break it and I did not manage to learn midi triggers for cues in a variety of existing sessions.
(0028298)
ocyssau   
2023-11-03 23:37   
Same problem with Ardour 8.1 on Linux.
Midi learn for cues works on a fresh session when a midi cue is added first.
Get around by adding direclty in the xml of session the section to define bindings.
Example for a launchpad S 8x8 matrix pads :
  <TriggerBindings>
    <Binding col="0" row="0" msg="0x90 0x0 "/>
    <Binding col="1" row="0" msg="0x90 0x1 "/>
    <Binding col="2" row="0" msg="0x90 0x2 "/>
    <Binding col="3" row="0" msg="0x90 0x3 "/>
    <Binding col="4" row="0" msg="0x90 0x4 "/>
    <Binding col="5" row="0" msg="0x90 0x5 "/>
    <Binding col="6" row="0" msg="0x90 0x6 "/>
    <Binding col="7" row="0" msg="0x90 0x7 "/>
    <Binding col="8" row="0" msg="0x90 0x8 "/>
    <Binding col="0" row="1" msg="0x90 0x10 "/>
    <Binding col="1" row="1" msg="0x90 0x11 "/>
    <Binding col="2" row="1" msg="0x90 0x12 "/>
    <Binding col="3" row="1" msg="0x90 0x13 "/>
    <Binding col="4" row="1" msg="0x90 0x14 "/>
    <Binding col="5" row="1" msg="0x90 0x15 "/>
    <Binding col="6" row="1" msg="0x90 0x16 "/>
    <Binding col="7" row="1" msg="0x90 0x17 "/>
    <Binding col="8" row="1" msg="0x90 0x18 "/>
    <Binding col="0" row="2" msg="0x90 0x20 "/>
    <Binding col="1" row="2" msg="0x90 0x21 "/>
    <Binding col="2" row="2" msg="0x90 0x22 "/>
    <Binding col="3" row="2" msg="0x90 0x23 "/>
    <Binding col="4" row="2" msg="0x90 0x24 "/>
    <Binding col="5" row="2" msg="0x90 0x25 "/>
    <Binding col="6" row="2" msg="0x90 0x26 "/>
    <Binding col="7" row="2" msg="0x90 0x27 "/>
    <Binding col="8" row="2" msg="0x90 0x28 "/>
    <Binding col="0" row="3" msg="0x90 0x30 "/>
    <Binding col="1" row="3" msg="0x90 0x31 "/>
    <Binding col="2" row="3" msg="0x90 0x32 "/>
    <Binding col="3" row="3" msg="0x90 0x33 "/>
    <Binding col="4" row="3" msg="0x90 0x34 "/>
    <Binding col="5" row="3" msg="0x90 0x35 "/>
    <Binding col="6" row="3" msg="0x90 0x36 "/>
    <Binding col="7" row="3" msg="0x90 0x37 "/>
    <Binding col="8" row="3" msg="0x90 0x38 "/>
    <Binding col="0" row="4" msg="0x90 0x40 "/>
    <Binding col="1" row="4" msg="0x90 0x41 "/>
    <Binding col="2" row="4" msg="0x90 0x42 "/>
    <Binding col="3" row="4" msg="0x90 0x43 "/>
    <Binding col="4" row="4" msg="0x90 0x44 "/>
    <Binding col="5" row="4" msg="0x90 0x45 "/>
    <Binding col="6" row="4" msg="0x90 0x46 "/>
    <Binding col="7" row="4" msg="0x90 0x47 "/>
    <Binding col="8" row="4" msg="0x90 0x48 "/>
    <Binding col="0" row="5" msg="0x90 0x50 "/>
    <Binding col="1" row="5" msg="0x90 0x51 "/>
    <Binding col="2" row="5" msg="0x90 0x52 "/>
    <Binding col="3" row="5" msg="0x90 0x53 "/>
    <Binding col="4" row="5" msg="0x90 0x54 "/>
    <Binding col="5" row="5" msg="0x90 0x55 "/>
    <Binding col="6" row="5" msg="0x90 0x56 "/>
    <Binding col="7" row="5" msg="0x90 0x57 "/>
    <Binding col="8" row="5" msg="0x90 0x58 "/>
    <Binding col="0" row="6" msg="0x90 0x60 "/>
    <Binding col="1" row="6" msg="0x90 0x61 "/>
    <Binding col="2" row="6" msg="0x90 0x62 "/>
    <Binding col="3" row="6" msg="0x90 0x63 "/>
    <Binding col="4" row="6" msg="0x90 0x64 "/>
    <Binding col="5" row="6" msg="0x90 0x65 "/>
    <Binding col="6" row="6" msg="0x90 0x66 "/>
    <Binding col="7" row="6" msg="0x90 0x67 "/>
    <Binding col="8" row="6" msg="0x90 0x68 "/>
    <Binding col="0" row="7" msg="0x90 0x70 "/>
    <Binding col="1" row="7" msg="0x90 0x71 "/>
    <Binding col="2" row="7" msg="0x90 0x72 "/>
    <Binding col="3" row="7" msg="0x90 0x73 "/>
    <Binding col="4" row="7" msg="0x90 0x74 "/>
    <Binding col="5" row="7" msg="0x90 0x75 "/>
    <Binding col="6" row="7" msg="0x90 0x76 "/>
    <Binding col="7" row="7" msg="0x90 0x77 "/>
    <Binding col="8" row="7" msg="0x90 0x78 "/>
    <Binding col="0" row="8" msg="0x90 0x80 "/>
    <Binding col="1" row="8" msg="0x90 0x81 "/>
    <Binding col="2" row="8" msg="0x90 0x82 "/>
    <Binding col="3" row="8" msg="0x90 0x83 "/>
    <Binding col="4" row="8" msg="0x90 0x84 "/>
    <Binding col="5" row="8" msg="0x90 0x85 "/>
    <Binding col="6" row="8" msg="0x90 0x86 "/>
    <Binding col="7" row="8" msg="0x90 0x87 "/>
    <Binding col="8" row="8" msg="0x90 0x88 "/>
  </TriggerBindings>

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8653 [ardour] bugs minor always 2021-04-05 13:30 2023-11-02 13:26
Reporter: Headwar Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [Papercut] View > Zoom > Zoom to selection and Zoom to selection (horizontal) looses the selection
Description: When one or more region is selected, using the menu Zoom > Zoom to selection or Zoom to selection (horizontal) deselects the tracks, which is probably not what the user wants nor expects.
Tags: Papercut
Steps To Reproduce: See Description
Additional Information:
System Description
Attached Files:
Notes
(0028297)
Headwar   
2023-11-02 13:26   
As stated in the code, it looks to be intentional. I'd argue otherwise because :
1) keeping the selection "anchors" the regions in the user's mind, i.e. he knows where he is
2) maybe he intended to subsequently do something with his selection (merge audio regions...)
3) maybe it is a complex selection with e.g. a few regions selected amongst many, and the user is zooming to see if he had everything selected as intended
Anyway, unselecting everything is really easy and enforcing the deselection (thus guessing the user's intention) doesn't seem to be the right choice here.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9422 [ardour] bugs crash always 2023-07-25 01:52 2023-11-01 23:42
Reporter: Schmitty2005 Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 10  
Status: assigned Product Version: 7.5  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Using MIDI-DeInterlace causes fatal crash to desktop in WIN10 and Linux GDB Log attached Ardour 7.5.199-dbg_x86_64
Description: When trying to De-Interlace a MIDI file, Ardour shows a 'Fatal Error' message and crashes. The backtrace from Ubuntu 22.04 GDB is attached.

Version Ardour 7.5.199-dbg_x86_64 nightly from 7-21-23 was used
Tags: De-interlace, Midi, region
Steps To Reproduce: 1. Start new session
2. Create MIDI track with General MIDI Instrument
3. Record Notes using virtual Keyboard on Channel 1
4. Record notes using keyboard on channel 2, 3, or more.
5. Region -> MIDI -> Deinterlace into Layers.
6. View crash message
Additional Information: Fails similarly on Ubuntu 22.04 LTS using Jack and Windows 10 using ASIO drivers
System Description
Attached Files: Ardour7.199-dbg-x86_64_MIDI_DEINTERLACE (118,393 bytes) 2023-07-25 01:52
https://tracker.ardour.org/file_download.php?file_id=4602&type=bug
image.png (5,921 bytes) 2023-07-25 01:56
https://tracker.ardour.org/file_download.php?file_id=4603&type=bug
png

Bee Gees - You Should Be Dancin'.mid (60,000 bytes) 2023-10-27 01:31
https://tracker.ardour.org/file_download.php?file_id=4685&type=bug
image-2.png (162,979 bytes) 2023-10-27 01:35
https://tracker.ardour.org/file_download.php?file_id=4686&type=bug
png

Ardour-debug.log (76,691 bytes) 2023-11-01 23:42
https://tracker.ardour.org/file_download.php?file_id=4699&type=bug
Notes
(0027911)
Schmitty2005   
2023-07-25 01:56   
Win10 Error Message. Linux is similar except the menu title was 'Programming Error'
(0027990)
x42   
2023-08-22 17:17   
Thanks for the report, and good recipe how to reproduce this.

Fixed in Ardour 7.5-328-ge3297a6a84
(0028259)
Schmitty2005   
2023-10-27 01:29   
Win10 De-Interlace works on simple MIDI created within Ardour. De-Interlace does not work on Win10 Ardour 8.1 Downloaded from here with more complex MIDI files. Here is a link to a MIDI file that will not de-interlace in Win10, but will de-interlace just fine in Ubuntu 22.04 LTS.

https://bitmidi.com/uploads/16637.mid

(0028260)
Schmitty2005   
2023-10-27 01:31   
Uploading MIDI file for convenience.
(0028261)
Schmitty2005   
2023-10-27 01:35   
Ardour gets hung up and never responds after trying to de-interlace.
(0028283)
x42   
2023-11-01 04:02   
Does this also happen when you split channels directly when importing the file?

In the import dialog, Mapping: One track per channel
(0028292)
Schmitty2005   
2023-11-01 23:37   
Import Mapping One Track per channel works fine.
(0028293)
Schmitty2005   
2023-11-01 23:42   
Adding gdb backtrace from Nightly 8.1.50

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8549 [ardour] bugs minor always 2021-01-23 20:02 2023-11-01 14:10
Reporter: bachstudies Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST3 plugin is given mono pin connection instead of stereo
Description: https://steinbergmedia.github.io/vst3_doc/vstinterfaces/structSteinberg_1_1Vst_1_1BusInfo.html#ab22e24964d55652336d526a41e5a2309

As per the spec, IAudioProcessor::setBusArrangements() should be called once to query and anothe time to set.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025452)
bachstudies   
2021-01-23 20:27   
Demo version of Seventh Heaven iLok code: 3267-6374-6049-4539-6744-9222-7327-88
https://www.liquidsonics.com/software/seventh-heaven/
(0025453)
bachstudies   
2021-01-23 21:36   
Email from Matt @ Liquidsonics 01/23/21:

"It’s down to a combination of using an old channel declaration format in Juce, the order of the channel declaration (from memory it indicates mono to stereo first, stereo to stereo first would have been better, and how the host then uses this information for the default as the first in the list). Only Seventh Heaven uses this approach as its older, hence is the only affected plugin. I have a candidate fix, but a lot of testing is going to be needed to check it doesn’t break recall in some hosts. As it’s host dependent, it was certainly work putting that request into Ardour, I’m on the fence about whether the responsibility lies my end or the host end, but nevertheless, it’s on the radar for 2021."
(0025467)
x42   
2021-01-25 01:10   
Could you try if the `vst3rio` git branch fixes this?

git fetch
git checkout -b vst3rio origin/vst3rio
./waf
gtk2_ardour/ardev


(and later back: `git checkout master; ./waf`)
(0025469)
bachstudies   
2021-01-25 02:34   
This doesn't fix it, I'm afraid.
(0027793)
x42   
2023-06-17 21:28   
Fixed since Ardour 7.3 (with further improvements in 7.4)
(0028288)
DeeKay789   
2023-11-01 14:10   
Hi, if fixed in 7.4 I'm afraid it appears broken again in v8.1.0

launching LX480 v4 on a Stereo bus results in mono inputs only.

Do you need screenshots?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9521 [ardour] bugs feature always 2023-10-31 19:53 2023-10-31 19:54
Reporter: thekoala2 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tempos keep defaulting back to constant even if specifically set as ramped.
Description: Tempos keep defaulting back to constant even if specifically set as ramped.

eg. If I say "ok tempo here begins at 141", create another tempo change, move it, then the tempo that I had set to 141 could now be...anything, usually will default to same tempo as the new marker.
Tags:
Steps To Reproduce: Create tempo mark.
Create second tempo mark.
Set them as ramped.
Move right hand tempo.
Left hand tempo goes back to constant.
Additional Information: No amount of reselecting ramped, modifier keys or incantations seem to change the behaviour. I even tried to change the default in the code, which works visually but not as a setting...the problem is obviously a little deeper than my code-monkey abilities can deal with.

When I have managed to maintain a ramp, sometimes it has decided to do weird stuff like a reverse-ramp (ie, the tempo at the beginning gets higher than the target tempo, which could be useful in some situations, but is a bit counterintuitive).

As a side-note, It is also not clear if the ramped/constant setting applies:
1. from the mark onwards
2. up to the mark
3. in and out of the mark
System Description
Attached Files: Screenshot_addtempo1-left.png (37,513 bytes) 2023-10-31 19:54
https://tracker.ardour.org/file_download.php?file_id=4693&type=bug
png

Screenshot_addtempo2-right.png (37,374 bytes) 2023-10-31 19:54
https://tracker.ardour.org/file_download.php?file_id=4694&type=bug
png

Screenshot_addtempo3-result after moving.png (10,253 bytes) 2023-10-31 19:54
https://tracker.ardour.org/file_download.php?file_id=4695&type=bug
png
Notes
(0028278)
thekoala2   
2023-10-31 19:54   

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9508 [ardour] bugs crash always 2023-10-27 02:44 2023-10-31 18:10
Reporter: krystalcode Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes on session load
Description: After starting Ardour, I select the session to load, and it crashes either during loading or just after it. I need to try 2, 3, or 4 times until it finally loads and I am able to playback or operate on the session. When it loads, it seems stable after that i.e. no crashes. It's just at the beginning.

This happens 100% of the times.

I am aware of the instructions in the following link: https://ardour.org/debugging_ardour

I currently with the pre-built, paid version, which I understand does not come with the debug symbols enabled. For me to build Ardour with debugging enabled, or to install a nightly build, it will take me some time. So, I'm posting the issue in advance in case there is some advice already, and I will follow up when I'm able to test with a nightly build.
Tags: crash
Steps To Reproduce:
Additional Information: I have not been able to find any valuable logs in Ardour. I have noted the following though from Jack log messages as found in the QJackCtl messages UI component.

Cannot write socket fd = 35 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = ardour notification = 10 val1 = 146 val2 = 0
21:29:40.969 JACK connection change.
21:29:42.178 XRUN callback (4 skipped).
System Description
Attached Files:
Notes
(0028262)
x42   
2023-10-27 03:14   
Can you load the session when you select

[x] Safe Mode: disable all plugins

in the Recent Session dialog?
(0028263)
krystalcode   
2023-10-27 03:46   
I understand your point is to test if this is caused by a plugin rather than Ardour.

By coincidence, just after I posted this bug I removed and readded the Decent Sampler plugin. After this it stopped happening i.e. restarted the computer 2-3 times, loaded the session, no problem. Let me test this a bit more over the next couple of days, and if the issue is gone I will assume it was this plugin.

Two questions however:
- Is there a way to understand which plugin is causing an issue? If this happens again, I hope I won't have to remove/readd/reconfigure all plugins one-by-one, restarting the computer in-between, until I find the culprit ... even though I have a candidate now.
- If this plugin was the issue, how could I find the actual cause? I know that might not be a question for Ardour developers to answer, but why would the same plugin fail to load initially, and then on 2nd or 3rd load ok with the exact same configuration, or removing and readding it and it works?
(0028276)
paul   
2023-10-31 18:10   
Software bugs are not always deterministic. Sometimes they are caused by code that always behaves in the wrong way, but other times they are caused by code that only misbehaves after a sequence of other stuff has happened.

So there can be a plugin (or some chunk of code in Ardour itself) which is fine 2 out of 3 times that you test it, but not in the one test case where you add in the (bad) magic conditions that lead to the crash.

And yes, sadly, there's no way without using the debugger and a stack trace to find the bad plugin. With a debugger, it is often relatively obvious.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9520 [ardour] bugs minor always 2023-10-31 11:06 2023-10-31 11:10
Reporter: garyd Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 9.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OSC "extra select only feedback" crashes Mixbus
Description: Entering the following in a terminal...
oscsend osc.udp://localhost:3819 /set_surface iii 1 256 8192
...crashes Mixbus every time for me. If a strip is not currently selected then it does not crash, but then does as soon as a strip is selected.

Seems to work fine in Ardour (8.1) and earlier Mixbus (v7 and v8).
Mixbus32C v9.2.105, also v9.1.324.
Happens on two PCs (both Debian), every session I've tried, with or without plugins on the selected strip.

Tags:
Steps To Reproduce: Turn on OSC control surface.
In terminal type: oscsend osc.udp://localhost:3819 /set_surface iii 1 256 8192
If a strip is already selected then Mixbus32C crashes, otherwise it crashes as soon as a strip is selected.
Additional Information: osc_dump reports that quite a few feedback messages are received before the crash. "/select/comp_mode_name" is the last reported message every time.

Various values in the "/set_surface" call have been tried. It seems to only fail when feedback 8192 is used, be it just 8192 or that combined with other values, e.g. 8195.

I'm new to OSC, so maybe I'm doing something wrong. I suspect not though, given that Ardour and earlier Mixbus works as I expected them to.
System Description
Attached Files:
Notes
(0028275)
garyd   
2023-10-31 11:10   
RE: "/select/comp_mode_name" is the last reported message every time.
I mean, I suspect that whatever parameter comes next is the culprit. The compressor "speed" one I think but not sure.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9515 [ardour] bugs minor always 2023-10-29 12:56 2023-10-29 12:56
Reporter: fwcd Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Dropdown menus have a too short "hold time", i.e. often close immediately upon clicking
Description: Clicking a dropdown menu often causes it to close almost immediately, unless it is tapped extremely quickly. This is unfortunately a bit of a usability issue since it makes especially large dropdown menus hard to navigate.

While it seems to be an established convention that clicking and holding on a dropdown menu causes it to close upon release, this "hold time" should be longer. In other words, performing a "normal click" should keep the menu open after releasing the mouse button, like native dropdown menus in other apps.
Tags:
Steps To Reproduce: - Click any dropdown menu (and keep the mouse button pressed for a very short amount of time)
Additional Information: I'm testing this on a 2021 MacBook Pro (with 120 Hz display) on macOS 14.0 (arm64). See the attached screen recording for a short video demo.
System Description
Attached Files: dropdown-issue.mp4 (151,225 bytes) 2023-10-29 12:56
https://tracker.ardour.org/file_download.php?file_id=4688&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9514 [ardour] features minor have not tried 2023-10-29 02:10 2023-10-29 02:10
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: show send in pin connection section
Description: Hi
I want to route output of (one band of a) crossover to it then send to hell
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9511 [ardour] bugs major have not tried 2023-10-28 12:14 2023-10-28 22:24
Reporter: novalix Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Build fails due to missing use of gtkmm
Description: Hi,
i am test building here just for the fun of it.

Since commit 'a5aff68' to libs/surfaces/console1/wscript the build fails due to the missing gtkmm/box.h which is first in the list of several gtkmm includes in libs/surfaces/console1/c1_gui.h.

It builds just fine when i readd 'GTKMM' to the obj.uselib list.

Tell me if you need more info in case this one is not reproducible for you.
Tags: control surface
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028268)
x42   
2023-10-28 22:24   
Fixed in 8.1-43-g03e3546422

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9512 [ardour] translation text always 2023-10-28 12:15 2023-10-28 12:47
Reporter: martin.vlk Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 8.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Separate out the "In" and "Out" text in context of "Punch|In" and "Punch|Out"
Description: Hi, I am an Ardour translator, and I have come across an issue translating the "In" string, in the context of "Punch In".

The problem is that the "In" string is used in many contexts in Ardour and in most places it means "Input", but in the context of "Punch In" the meaning, and translation to other languages is sometimes different.

Could the "In" string for "Punch In" be separated as "Punch|In" so that we can vary the translations?
The same would be good to do for Punch|Out.
Tags: translations
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0028265)
x42   
2023-10-28 12:47   
Done in 8.1-42-g828d45c6fa
I hope I got all of them

https://github.com/Ardour/ardour/commit/e22415f0ce5de78591cce40fcde601f0c0202aca
https://github.com/Ardour/ardour/commit/828d45c6fa82d01dc03689fda943e8df234af7eb

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9510 [ardour] features minor have not tried 2023-10-28 01:41 2023-10-28 01:41
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unique : Midi comping
Description: unique one between DAWs
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9509 [ardour] features minor have not tried 2023-10-28 01:39 2023-10-28 01:39
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: audio comping inside tracks
Description: Due to the Ardour option to view audio track in layer mode; it is possible very easy than comping between tracks like other guys
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9503 [ardour] bugs major always 2023-10-23 21:52 2023-10-27 08:02
Reporter: skygge Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Enabling loop playback disables punch recording, but disabling loop doesn't bring it back.
Description: As in summary. Loop is transport mode. If you turn loop on, the punch in/out icons are greyed out, so punch recording is unavailable (by the way: why? This would be useful...).
But if you switch loop mode off, the punch recording is still grayed out :( but it shouldn't be, I think. The only way to bring it back is restart Ardour. Maybe reloading session would help but I not tried this.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Peek 2023-10-24 00-29.gif (69,304 bytes) 2023-10-23 22:31
https://tracker.ardour.org/file_download.php?file_id=4682&type=bug
gif
Notes
(0028245)
skygge   
2023-10-23 22:31   
(0028246)
skygge   
2023-10-23 22:34   
NOTE: the punch recording can be re-enabled by start/stop playback.
(0028264)
skygge   
2023-10-27 08:02   
Just another comment on disabling punch recording in loop mode.

ardour.org/features.html, section "Flexible Recording":
Quote: "Punch in/out points can be set in a multitude of ways, and can be combined with loop playback".
So I guess this functionality once existed. So why it does not exist anymore? Please bring it back or remove this statement from your site.... cause this is not true (anymore).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9506 [ardour] bugs major always 2023-10-24 12:14 2023-10-24 21:08
Reporter: batinste Platform: PC  
Assigned To: x42 OS: Linux 6.2.0-35-generic #35~22.04  
Priority: normal OS Version: Mint 21.2  
Status: resolved Product Version: 8.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when switching to another existing session with websockets interface activated
Description: Ardour crashes when switching to another existing session with websockets interface activated
Tags: control surface, crash, websockets
Steps To Reproduce: Open any session
Activate websockets interface
Open another session via Session/Recent OR switch to another Session via Session/Open OR switch to another snapshot of the current session
>Ardour crashes with :
Got SIGTERM, quitting.
[2023/10/24 14:06:51:7695] N: -- [wsi|0|pipe] (1) 8.872s
[2023/10/24 14:06:51:7695] N: -- [vh|1|default||3818] (1) 8.872s
[2023/10/24 14:06:51:7695] N: -- [wsi|1|listen|default||3818] (0) 8.872s
[2023/10/24 14:06:51:7695] N: -- [vh|0|netlink] (0) 8.872s
Erreur de segmentation (core dumped)
Additional Information:
System Description
Attached Files:
Notes
(0028255)
x42   
2023-10-24 21:08   
Fixed in Ardour 8.1-20-g1dbc3305fa

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9504 [ardour] bugs major always 2023-10-23 22:59 2023-10-24 19:16
Reporter: skygge Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Clicking on one track stacked layer selects all of them.
Description: If you record some layers (e.g. for comping vocals) and want to select one of them in stacked view by clicking on it - all layers (or multiple layers) are selected instead of this one clicked. To select only one you have to drag a selection box over this layer. An animated gif attached. Regards!
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Peek 2023-10-24 00-53.gif (416,202 bytes) 2023-10-23 22:59
https://tracker.ardour.org/file_download.php?file_id=4683&type=bug
Notes
(0028249)
x42   
2023-10-24 01:35   
There are various explanations that can explain this:

* Preferences > Editor > "Regions in edit groups are edited together" ... "if they have identical length, position and origin"

Since Ardour 8: Explicit Region Groups:
* Regions recorded at the same time are grouped by default so they can be edited together (use shift+ctrl+g to ungroup, ctrl+g to group).
(0028253)
skygge   
2023-10-24 19:16   
:( How to switch off this "feature"? This was a bad idea imo... It's really confusuing. I want to group regions only if really I want to. This will causing more bug reports and forum topics from confused users like me. At least give an option for turning this off...

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9505 [ardour] features minor have not tried 2023-10-24 08:25 2023-10-24 09:55
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: feature request for Midi note
Description: 1- show note name or midnam inside notes
2- chop note to gird size (select note and e.g press shift + s to chop it to grid size)
3- Split Notes to Separate MIDI track (track per pitch) use ful for midi drumers
https://www.protoolstraining.com/blog-help/pro-tools-blog/tips-and-tricks/477-split-notes-to-separate-midi-drum-sequencing-pro-tools-tutorial.html
4- Scale indicator (yes i am noob in music theory and dont have midi controler :D )
5- pan lollipops
6- make lollipops without stick like ableton this help to see different vol note or make option to show or hide stick
7- make lollipops small
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028251)
dsfdsf   
2023-10-24 09:27   
Part 2
8- convert draw tool to brush tool by hold e.g shift
9- duplicate note in range e.g put a note on 3th beat of bar1 then duplicate it note copy to 3th beat or bar2
not only after selected note
or make range tool usable to select range of note and duplicate range of them

10- duplicate note up/down in pitch e.g hold ctrl + shift + up arrow to duplicate note to one semitone up
(0028252)
dsfdsf   
2023-10-24 09:55   
part 3
destructive midi editing i.e when you duplicate / paste note over another note
new one replaced with old one this is better than note overlapping

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9494 [ardour] features feature sometimes 2023-10-20 07:14 2023-10-24 08:11
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Filter / Crossover inside send
Description: Hi to All
1-signal first get filtered inside "send" then filtered signal goes to desire place
2-signal filtering have option for high/low/band pass + slope option and etc
3-filter can cut signal How ?? e.g low freq of signal goes normal way but High freq of it are cut from main signal and send to new bus

signal before send
main signal = 20-20k
low of it = 20-500
high of it = 500-20k also cut from main and send to new bus

signal after send
just low maintained = 20-500
high are cut and send to new bus

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028227)
x42   
2023-10-20 14:19   
Ardour will not do any DSP. All signal processing is done by a plugin. There are also various filter types so it is even preferable to leave this to 3rd party.

I suggest you use a Bus for this, aux-send to the bus and then add your desired Filter plugin there.
(0028239)
novalix   
2023-10-22 09:08   
Hi,

it would still be useful to associate a filter plugin to a single send and not to the receiving bus, which might collect sends from other sources that one does not want to be filtered the same way.
(0028250)
dsfdsf   
2023-10-24 08:11   
@x42
okey about dsp and etc
give me ability to connect filter plugin to sends in pin connection
in simple word make sends visible in pin connection section
i want to make crazy routing :D

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9447 [ardour] bugs crash always 2023-09-14 22:06 2023-10-23 23:12
Reporter: skygge Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Audio stuttering/crackling and Ardour crash when adjusting system volume
Description: If Ardour is run from command line, there is a lot of "Sending key 'state' to UI failed, out of space" printed out every second. But this is not that annoying...
If you adjust system global volume the audio starts to stutter/crackle unpleasantly. If you're adjusting volume long enough - Ardour crashes.
The more tracks Ardour session has the worse effect you get. If you have one or two tracks, you probably won't notice the problem at all.

Example video: https://youtu.be/l-GYdu2_RpU

Thanks! :*
Tags:
Steps To Reproduce: Open Ardour (7.5 or current master, it doesn't matter) under Pipewire-Jack, load heavy session and try to play with system volume.
Additional Information: If you consider this as Pipewire bug let me know. But you have to know that no other application behaves like this, I have also Tracktion Waveform 12 pro and Bitwig Studio (demo),
and audio runs smoothly (with PW-Jack, of course). The only program causing problems is Ardour.

Backtrace attached. Pipewire 0.3.80 (just built from current master) but the version doesn't matter, tbh.
System Description
Attached Files: trace_volume_updown_crash.txt (139,023 bytes) 2023-09-14 22:06
https://tracker.ardour.org/file_download.php?file_id=4633&type=bug
image.png (10,072 bytes) 2023-09-15 05:36
https://tracker.ardour.org/file_download.php?file_id=4634&type=bug
png

image-2.png (21,252 bytes) 2023-09-15 13:47
https://tracker.ardour.org/file_download.php?file_id=4635&type=bug
png
Notes
(0028041)
x42   
2023-09-14 22:45   
Did you not report this to be fixed?
https://discourse.ardour.org/t/ardour-pipewire-sound-stuttering-crackling-popping-when-adjusting-system-volume/109054/10
(0028042)
x42   
2023-09-14 22:47   
Unlike the other DAWs you mention Ardour uses JACK for all audio routing (and uses jack's blocking-process API).

Could you do a quick check: in Ardour, Menu > Window > Audio/MIDI Setup, use Audio System: ALSA and directly interface with the soundcard (bypassing pipewire)
does the issue persist?
(0028043)
skygge   
2023-09-15 05:34   
Unable to check.
If I switch backend to ALSA, my audio device disappears from the system and I cannot adjust volume because "there is no output device"... :(
(0028044)
skygge   
2023-09-15 05:36   
(0028045)
skygge   
2023-09-15 05:39   
Yeah, I told it was fixed, but it was not, I was wrong.
(0028046)
x42   
2023-09-15 13:13   
With ALSA, you change the volume using `alsamixer`. -- In any case this is likely an issue with pipewire :(
(0028047)
x42   
2023-09-15 13:14   
In your video Ardour's DSP load is only at around 30% and no xruns are reported. -- which is rather strong hint that the issue is pipewire.
(0028048)
skygge   
2023-09-15 13:47   
Alsamixer says: This sound device does not have any controls (see attachment).
Pulseaudio backend (Pipewire-pulse) works OK.
My HW:
- CPU: Ryzen 7 5700X,
- 32GB RAM,
- 2TB NVME disk
No performance issues noticed ever.
(0028051)
paul   
2023-09-15 21:17   
It is not possible to say which thread crashed from your first trace.txt file (it is missing that info from gdb).

But it is noticeable that thread 1 (the GUI) is blocked on a mutex that only exists in the Pipewire JACK implementation:

#0 futex_wait (private=0, expected=2, futex_word=0x555557be49a8) at ../sysdeps/nptl/futex-internal.h:146
0000001 __GI___lll_lock_wait (futex=futex@entry=0x555557be49a8, private=0) at ./nptl/lowlevellock.c:49
#2 0x00007ffff3092572 in lll_mutex_lock_optimized (mutex=0x555557be49a8) at ./nptl/pthread_mutex_lock.c:48
#3 ___pthread_mutex_lock (mutex=0x555557be49a8) at ./nptl/pthread_mutex_lock.c:93
0000004 0x00007fffd6bdf12e in jack_port_get_all_connections () at /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0
(0028052)
paul   
2023-09-15 21:18   
The GUI thread is also making a JACK call (jack_port_get_all_connections()) that it is very unlikely other DAWs, even the ones that are JACK capable, would use.
(0028053)
paul   
2023-09-15 21:19   
All that said, I did add some changes two days ago that may improve this situation, so if you check a nightly build, that would be great!
(0028056)
skygge   
2023-09-15 21:33   
I'm on 7.5-567 right now, the same situation. I sync sources and compile fresh Ardour several times a day.
I know you guys don't like PipeWire. I'm also uncomfortable with all this. I appreciate your hard work and admire your progress in developing this program which becomes better and better every day. :)
But, you know, there are some issues wort eliminating for the good of all. I reported these problems on the PW bugtracker as well. We'll see what happens.
(0028058)
x42   
2023-09-16 16:59   
> I know you guys don't like PipeWire.

Quite the opposite. I was also involved with the design of it. Just keep in mind that it is still under heavy development.
(0028135)
skygge   
2023-10-03 20:58   
There is a way to omit JACK and use ALSA without muting every other application. If you run Ardour this way:

ARDOUR_ALSA_DEVICE=pipewire /path/to/ardour7

you can use Pipewire Alsa device which is inaccessible otherwise. If Ardour is started this way - everything is ok, no sound problems at all. This is workaround, not a proper solution.
(0028136)
x42   
2023-10-03 21:03   
Also note that when using the ALSA backend, Ardour will directly use MIDI devices asynchronously (and not expose MIDI ports to pipewire).
(0028247)
skygge   
2023-10-23 23:12   
After a long testing it seems to be KDE Plasma issue. This behaviour is not observed by me neither in XFCE nor in Gnome.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9502 [ardour] bugs crash always 2023-10-23 21:24 2023-10-23 21:24
Reporter: OConnorStP Platform: Linode virtual server  
Assigned To: OS: Debian  
Priority: normal OS Version: 12  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash (find a trout) on second-run of Ardour on a Debian12 virtual machine using Jack/Dummy audio
Description: Please refer to this thread for details and historical config file downloads

https://discourse.ardour.org/t/ardour8-still-chasing-find-a-trout-in-debian12-logging-stereo-channels-unattended-install/109312/23

Summary -- Ardour runs correctly if Jack is already running. It also runs correctly on the first run of a freshly built workstation. In that case, Ardour crashes on the second run. It can be restored to normal (first-run) operation by deleting the config file.
Tags:
Steps To Reproduce: I can provide you access to a virtual machine that is dedicated to the debugging effort. It's freshly created on top of the standard Debian12 Linode machine by adding Ardour and Jack with apt and setting permissions for Jack to run properly. That will pretty much assure that the following steps will reproduce the problem.

If it turns out that debugging reveals a problem with my workstation configuration I will donate $1000 to Ardour (or more, depending on how much of your time you waste debugging a problem that I created).

Steps to reproduce:

- VNC into the Debian12 workstation (credentials provided offlist)

- Launch Ardour (command-line, launch-icon on the desktop or through the program menu)

- Configure Jack (and do other things if desired)

- Close and reopen Ardour -- it will crash on open.

 
Additional Information: Config files and term-sessions have been uploaded to the Discourse thread -- I can add them here, but thought they might just be confusing.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9501 [ardour] bugs minor always 2023-10-23 11:30 2023-10-23 11:30
Reporter: skygge Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Loop playback - jump to prev/next mark doesn't work, playback starts always from loop beginning instead of playhead position
Description: Jump to next and previous mark doesn't work in loop transport mode.
Playback always starts from the beginning of loop range instead of current playhead position.
Tags:
Steps To Reproduce: The description is self-explained.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9472 [ardour] bugs major always 2023-10-08 16:44 2023-10-23 10:40
Reporter: fredo.faure Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: CC Midi messages are transmitted from one track to another but not recorded on midi tracks
Description: I have two Midi tracks: Track0 with plugin0 and Track1 with plugin1.
The two tracks are Midi connected: Track0->Track1.
 
In the loop processBlock, the plugin0 creates some midi messages and print them.
the plugin1 receive the messages and print them.
At the same time i ask the track1 to record the midi messages and i export this in a file.mid.
Concerning the printed messages everything is ok, all messages are transmitted.
But in the file some messages are missing. I repeated many times and this is reproducible.
But i don't understand the exact rule, but observe that the missing messages in my example are (but sometimes they are here):
b0,e,*,
b0,17,*,
b0,18,*,
b0,35,*,
b0,36,*,
b0,37,*,
b0,38,*,

I give below 3 files:

  log1.txt :that contains the printed midi messages (with their time measured from the start of the loop), from plugin0 (output) and plugin1 (input).
         From this file we can check that the messages are all transmited correctly.

 log2.txt: that contains the printed midi messages from plugin1 (input) when we read the recorded file on track1.
     From this we can compare with log1.txt and observe that some CC messages are missing.

   Precisely this is for the sequences of 5 messages:
b0,7,17, 97.9692
b0,15,7d, 97.9693
b0,16,2, 97.9693
e0,20,41, 97.9693
90,3e,7f, 97.9693
----------------------

   where we expect instead the 12 messages:
b0,e,3, 84.5669
b0,15,7d, 84.5669
b0,16,2, 84.567
b0,17,0, 84.567
b0,18,0, 84.567
b0,35,0, 84.567
b0,36,0, 84.567
b0,37,0, 84.567
b0,38,0, 84.567
b0,7,17, 84.567
e0,20,41, 84.567
90,3e,7f, 84.5671
----------------------

  file.mid that contains the recorded midi file. Looking carefuly we see that it corresponds to log1.txt.
    So some midi messages are missing.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: file.mid (365 bytes) 2023-10-08 16:44
https://tracker.ardour.org/file_download.php?file_id=4660&type=bug
log2.txt (2,039 bytes) 2023-10-08 16:44
https://tracker.ardour.org/file_download.php?file_id=4661&type=bug
log1.txt (4,521 bytes) 2023-10-08 16:44
https://tracker.ardour.org/file_download.php?file_id=4662&type=bug
MIDI-CC.mid (1,161 bytes) 2023-10-08 21:14
https://tracker.ardour.org/file_download.php?file_id=4663&type=bug
Notes
(0028156)
fredo.faure   
2023-10-08 16:50   
I can add the following information:
This Ardour 7.5.0 "Neroli" (rev 7.5) Intel 64 bits On Ubuntu, but i observed the same with Ardour 7.5 on MacOs.
My Plugins are VST3 made with JUCE 7.
(0028157)
paul   
2023-10-08 17:01   
Can you retest this with a setup where track 1 has no MIDI plugin at all?

I would do it myself, but (a) busy with the release process for Ardour 8 (b) i can't compare it quickly with the plugin you are using
(0028158)
x42   
2023-10-08 19:12   
perhaps this is a VST3 issue? CCs are mapped to plugin control input parameters, and not sent as MIDI messages.
(0028159)
fredo.faure   
2023-10-08 20:32   
I am sur to understand very weel, but i removed the plugin on track 1, recorded and see the same problem.
(0028160)
x42   
2023-10-08 21:14   
(Last edited: 2023-10-08 21:30)
I just checked . I created a MIDI file with CCs 1..127 on channel one with midicomp (https://github.com/markc/midicomp/) a MIDI to/form text tool:
MFile 0 1 19200
MTrk
0 Par ch=1 c=1 v=127
4800 Par ch=1 c=1 v=0
4800 Par ch=1 c=2 v=127
9600 Par ch=1 c=2 v=0
9600 Par ch=1 c=3 v=127
14400 Par ch=1 c=3 v=0
14400 Par ch=1 c=4 v=127
19200 Par ch=1 c=4 v=0
# ... SNIP ...
604800 Par ch=1 c=126 v=0
604800 Par ch=1 c=127 v=127
609600 Par ch=1 c=127 v=0
609600 Meta TrkEnd
TrkEnd



Imported it to Ardour on a track without synth. Then created a 2nd MIDI track, and connected its input to the output of the track with the sequence.
For good measure I have added "ACE MDI Monitor" plugin (comes with Ardour) to both tracks.
Rec-arm, record. save, quit and then used MIDIcomp again to check the recorded midi file (from the session's interchange/*/midifiles/ folder).
All CCs were correctly recorded.

So either there is an issue with Ardour's VST3 implementation not passing all MIDI events on, or something specific to your JUCE plugin.

Older versions of JUCE default generates 127 * 16 VST3 hidden control ports. One for each MIDI CC and channel. I don't know if that is still the case for JUCE7.
While generating MIDI still uses an event based API.

1. Can you try if you receive all MIDI events if you play the attached file into your plugin?

2. Can you check with ACE MIDI Monitor added after your plugin on the same track if all events are correctly generated?
(0028243)
fredo.faure   
2023-10-23 10:26   
I did the test, thank you, it works. I see no problem using this file.
So i have to find the problem with my situation.
(0028244)
fredo.faure   
2023-10-23 10:40   
But i am not sure that the problem comes from my plugin, because, i checked that the midi messages are well transmited if i put an intermediary midi track (without recording).
 The problem is when i record. May be too many CC messages at the same time?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9496 [ardour] bugs crash sometimes 2023-10-21 10:26 2023-10-22 20:06
Reporter: benald Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Saving 'Snapshot and keep working on current version' regularly crashes.
Description: I noticed this after I put in several patch changes in my tracks. I am using the new arpeggiator plugins and a Cardinal FX bus. The project can be saved reliably using the straight 'Save' option.
I was going to upload my project but is now too large, even compressed into a zip file. The size of the project is, I think, down to the output of one track with an arpeggiator being fed into a bus. The bus also has an arpeggiator in it. This might be a terrible idea as far as the software goes but I like the sound it produces - and so is probably a good contender for the cause of the crashing.
I had some idea that the crashes were to do with an inconsistency with how the software adds patch changes - which I flagged earlier.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files: CrashLog.zip (109,214 bytes) 2023-10-22 11:08
https://tracker.ardour.org/file_download.php?file_id=4679&type=bug
Ardour-8.1.0-crash-1697985563.txt (11,575 bytes) 2023-10-22 14:46
https://tracker.ardour.org/file_download.php?file_id=4680&type=bug
Notes
(0028233)
x42   
2023-10-21 14:56   
Is there anything in %localappdata%\Ardour8\CrashLog\ ?

Does this only happen when there are any MIDI tracks in the session?
(0028234)
benald   
2023-10-21 15:00   
All tracks are midi apart from the fx bus
(0028235)
x42   
2023-10-21 15:46   
I just checked and with Ardour 8.1 on Windows 7 and with a simple session a MIDI track, general MIDI synth and a MIDI region it work fine.

To track things down..

Does it also happen in a new session?
Does it happen if there are only audio tracks?
Does it happen in every session that has at least 1 MIDI track?

It could also be caused to [synth] plugins?!

Do you have a session where snapshot & keep working crashes reliably? Can you share/upload that session?
(0028237)
benald   
2023-10-21 19:34   
I did have a lot of patch changes in single tracks and I was suspicious that that was causing a problem. I have deleted all of the patch changes and put the different instruments in different tracks instead. I think that this has fixed the problem for me. I am happy to send a copy of the project with the problem. It is about 15 mbytes compressed so it won't upload here.
(0028240)
benald   
2023-10-22 11:08   
I think I have got around this issue (as described in my last reply) but going through the replies I saw the request for a crash log. I'm sorry I haven't sent this before. Here are all of my crashlogs for this project. Thanks for your help.
(0028241)
benald   
2023-10-22 14:46   
I've started to get the snapshot crashes again. This is the latest crash report.
(0028242)
benald   
2023-10-22 20:06   
I managed to copy this from the log before a snapshot crash just now....
2023-10-22T20:39:03 [ERROR]: BackendPort::connect (): wrong port-type trying to connect ardour:Arpeggio rec fr track1/audio_out 1 and ardour:1 bright grand/midi_in 1
2023-10-22T20:39:03 [ERROR]: BackendPort::connect (): wrong port-type trying to connect ardour:Arpeggio rec fr track1/audio_out 1 and ardour:1 dulcimer/midi_in 1
2023-10-22T20:39:03 [ERROR]: BackendPort::connect (): wrong port-type trying to connect ardour:Arpeggio rec fr track1/audio_out 2 and ardour:Arpeggio rec fr track1/midi_in 1
2023-10-22T20:39:03 [INFO]: Loading user ui scripts file C:\Users\bj\AppData\Local\Ardour8\ui_scripts
2023-10-22T20:39:03 [INFO]: Loading plugin order file C:\Users\bj\AppData\Local\Ardour8\plugin_metadata\plugin_order
2023-10-22T20:39:04 [INFO]: Loading history from C:\Users\bj\Dropbox\Ardour\Ardour 8 arpeggios\Ardour 8 arpeggios.history
2023-10-22T20:46:41 [ERROR]: Exception while writing C:\Users\bj\Dropbox\Ardour\Ardour 8 arpeggios\interchange\Ardour 8 arpeggios\midifiles\Take31_Arpeggio rec fr track1-320.mid, file may be corrupt/unusable
2023-10-22T20:53:58 [ERROR]: ardour::connect: Invalid Source port: (system:midi_capture_LPK25)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9499 [ardour] bugs minor always 2023-10-21 19:31 2023-10-21 21:27
Reporter: consint Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Grid disappears
Description: In Ardour 8 and 8.1 the grid disappear at certain project lengths, certain zoom levels and certain scroll positions. In the video I opened a new project and inserted an audio file without plugins or similar. I tried it with different Ardour graphics options and raster resolutions.
Tags:
Steps To Reproduce: Zoom and scroll
Additional Information:
System Description
Attached Files: ardour8_grid_disappears_3.png (117,683 bytes) 2023-10-21 21:27
https://tracker.ardour.org/file_download.php?file_id=4676&type=bug
png

ardour8_grid_disappears_2.png (115,619 bytes) 2023-10-21 21:27
https://tracker.ardour.org/file_download.php?file_id=4677&type=bug
png

ardour8_grid_disappears_1.png (108,678 bytes) 2023-10-21 21:27
https://tracker.ardour.org/file_download.php?file_id=4678&type=bug
png
Notes
(0028236)
consint   
2023-10-21 19:33   
Unfortunately I could not upload the video although it is only 1.6 MB in size.
(0028238)
consint   
2023-10-21 21:27   
Here are at least a few screenshots. On screenshot 1 I imported an audio file and then zoomed in on the whole project. When scrolling vertically, the grid only appears when I scroll to the beginning of the project (screenshot 2). When I scroll beyond the end of the project, the grid appears only sometimes. The grid also reappears when I zoom in further (screenshot 3).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9495 [ardour] bugs minor always 2023-10-21 02:31 2023-10-21 14:47
Reporter: tseaver Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.1  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: “Transport | Playhead | Jump to next mark” starts transport
Description: Under Ardour 8.x, using either the `Transport` menu items or the keyboard shortcuts (`W` and `Q`) to move to a mark causes the transport to start.

It didn't used to do this under 7.x or previously.
Tags:
Steps To Reproduce: 1. Set multiple markers in a project with existing audio on a track.
2. Move the playahead to a spot between markers.
3. Select `Transport | Playahead | Jump to next mark` (or press `W` or `Q` keys).
4. Listen to your audio playing, when all you wanted to do was move the playahead.
Additional Information: See screencap video attached.
System Description
Attached Files:
Notes
(0028228)
tseaver   
2023-10-21 02:37   
Screencap I meant to attach earlier.
(0028229)
paul   
2023-10-21 03:06   
Still no attachment.

Also, I cannot replicate this. I suspect you may have accidentally enabled auto-play. Does Ardour play when you locate anywhere at all?
(0028230)
tseaver   
2023-10-21 03:37   
> Still no attachment.

Yup. I dragged the 1.6 Mb screencap to the window, let it sit for about 5 minutes with the green "barber pole" spinning, and finally hit the "Add Note" button (I've just tried again, with the same result, and expect not to see the attachment).

> Also, I cannot replicate this. I suspect you may have accidentally enabled auto-play. Does Ardour play when you locate anywhere at all?

In fact, Ardour does play when I click in the timeline. Is the "auto-play" preference set in the "Preferences" dialog?

I wouldn't knowingly have set it -- does it maybe have a new-ish keyboard shortcut which I might've triggered by default?
(0028231)
tseaver   
2023-10-21 03:39   
Yup, no attachment upload.

Looking at the "Transport" menu, I see that it *is* checked, and shows a keyboard shortcut of `Ctrl-7`. I can however see no other visual indication of that setting: am I missing anything?

At any rate, my own issue is closed: I will likely always be able to remember to look for the option on the `Transport` menu.

It might still be an issue for others, particularly that there is no "visible by default" indicator of that status on the editor view (without opening the menu).
(0028232)
x42   
2023-10-21 14:47   
We used to have an "auto play" button in the main toolbar, but it was too prominent for a rarely used feature.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9491 [ardour] features minor N/A 2023-10-17 21:34 2023-10-18 14:27
Reporter: finotti Platform: Linux  
Assigned To: OS: Debian  
Priority: normal OS Version: Unstable  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [Feature Request] Lollipop drawing on Selection
Description: It would be nice if it was possible to draw the velocity lollipops only for selected notes.

For instance, when programming drums, often hihats and snares (or kicks) are at the same position. One could select only one (say the kicks, by right clicking on the correct note in the piano roll) and then draw the velocity only for the kick, not affecting the hihats, cymbals, etc., that are on the same position.

This is an option in MuseSequencer and is quite useful.
Tags: feature request, lollipops, Midi, velocity
Steps To Reproduce: N/A
Additional Information:
System Description Using also KXStudio repositories.
Attached Files:
Notes
(0028220)
paul   
2023-10-18 02:27   
if you have selected a hihat note, it's lollipop will be on top already ....
(0028223)
finotti   
2023-10-18 10:14   
But I can not freehand draw the heights (velocities) just for the selected lollipops without affecting the other lollipops. The idea was to isolate only one drum instrument (in a MIDI track with the whole drum set) to adjust the velocities by freehand drawing.

Maybe a modifier (say Shift+Left Click and hold) to affect only selected notes?
(0028225)
paul   
2023-10-18 14:27   
implemented in d88b9d36ca

lollis remain visible but if any notes are selected the freehand draw only affects them

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9492 [ardour] bugs feature have not tried 2023-10-18 02:05 2023-10-18 12:50
Reporter: forsland Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.0  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 8 ready-to-run program didn't find some midi plugins, like mda-ePiano and mda-Piano
Description: Ardour, fresh install, ready-to-run, couldn't find my favorite midi plugin MDA-ePiano. Tried some woodoo with PATHs whithout success. I learned about the plugin manager. It said error about several plugins, and stale about a whole lot of plugins.

I didn't keep 7.5.0 so i downloaded a tar.xz. During compile Ardour 8 source fetched and then compiled. Both versions can find MDA-ePiano. The plugin manager in both versions is saying error about 2 or 3 plugins and a whole lot are stale.

I guess there is some dependency issue during the config comile process.
Tags: Ardour 8.0
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9493 [ardour] bugs feature have not tried 2023-10-18 02:08 2023-10-18 12:49
Reporter: forsland Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 8 ready-to-run program didn't find some midi plugins, like mda-ePiano and mda-Piano
Description: Ardour, fresh install, ready-to-run, couldn't find my favorite midi plugin MDA-ePiano. Tried some woodoo with PATHs whithout success. I learned about the plugin manager. It said error about several plugins, and stale about a whole lot of plugins.

I didn't keep 7.5.0 so i downloaded a tar.xz. During compile Ardour 8 source fetched and then compiled. Both versions can find MDA-ePiano. The plugin manager in both versions is saying error about 2 or 3 plugins and a whole lot are stale.

I guess there is some dependency issue during the config comile process.
Tags: Ardour 8.0, Plugins not found, Plugins stale
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028221)
x42   
2023-10-18 02:39   
Debian 12 no longer follows the LV2 FHS. So for the time being it works if you use debian's liblilv

see also https://discourse.ardour.org/t/best-way-to-set-lv2-path/109345/7
(0028224)
x42   
2023-10-18 12:49   
Ardour builds since 8.0-46-gedc0e636e2 now also search $(DEB_HOST_MULTIARCH)/lv2

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9490 [ardour] features minor N/A 2023-10-17 21:30 2023-10-18 10:11
Reporter: finotti Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [Feature Request] Send selected tracks to same bus
Description: It would be nice if, together with other "quick group" actions, it was possible to set the outputs of all selected tracks to a single bus (or track). (E.g., select "snare top" and "snare bottom" and send to "snare" bus.)
Tags: feature request, quick groups
Steps To Reproduce: N/A
Additional Information:
System Description
Attached Files:
Notes
(0028219)
x42   
2023-10-18 00:41   
.. except you really should use aux-sends to Busses, rather than direct connections..
(0028222)
finotti   
2023-10-18 10:11   
Maybe I am using it wrong... (I can't say I am very experienced.) I do use aux sends for delay and reverb buses, but not for something like a drum bus. And it is an option for an actual group ("Add new subgroup bus").

The problem with groups, in my case, is that I would have a drum bus, but I also would have also snare bus (for top and bottom), a kick bus (for in and out, maybe a sample), a tom bus, etc, so I can process them together, all of them sent to the drum bus. I cannot do that with groups, but I could with "quick groups".

I can continue to do it by hand, so it is not a big deal, especially if it is not something others would use. Thanks for considering it!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9478 [ardour] bugs minor always 2023-10-11 12:05 2023-10-17 21:22
Reporter: finotti Platform: Linux  
Assigned To: OS: Debian  
Priority: normal OS Version: Unstable  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Ignore Y-axis when adding new automation points" randomly ignored
Description: With "Ignore Y-axis when adding new automation points" selected in Preferences -> Editor, often (but not always) adding new automation points are added at the pointers y-value.
Tags: automation, draw, editing
Steps To Reproduce: * Create new audio track.
* Add ACE Amplifier plugin.
* Add automation lane for ACE Amplifier's Gain.
* Start adding automation points.
Additional Information:
System Description Using also KXStudio repositories.
Attached Files:
Notes
(0028178)
x42   
2023-10-11 14:20   
This expect is due to the new "freehand automation drawing" feature:

A single click adds a point on the line.
Mouse-press, mouse-move, starts freewhand drawing and adds a point at the mouse-position.
(0028179)
finotti   
2023-10-11 14:57   
So, the problem is that I am holding the mouse button for too long? I was really just trying to left click to add points.

Is the difference between the amount of time for mouse "click" and "hold" coming from Ardour or the OS? It would be nice if I could change that.
(0028180)
x42   
2023-10-11 15:09   
It is not time-based. The condition is "does a movement of more than N pixels happen while the mouse button is pressed". It is not done by the OS, but Ardour.

I don't recall how large N is, it is zoom-level dependent though.
(0028218)
finotti   
2023-10-17 21:22   
I've tested it some more and it seems that any small movement makes it go into "freehand mode". Maybe increase the minimum amount a little would be good?

On the other hand, I figured that in EDIT mode I can also add nodes, and these are always on the same y-axis value (no freehand), so it solves the issue for me. Feel free to mark it solved, and thanks for the support!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9487 [ardour] bugs major unable to reproduce 2023-10-17 09:57 2023-10-17 09:57
Reporter: rastin Platform: Arch  
Assigned To: OS: Linux  
Priority: none OS Version: (any)  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unsaved grid changes permanently affect MIDI recordings
Description: When applying mid-twists using the new Grid Tool (Y), it appears that changes to the grid underlying MIDI regions result in permanent changes to those MIDI regions. I was playing around with the new tool and applied a number of mid-twists to see the grid move around. Closed the project without saving. Was surprised on reopening that the notes in the MIDI regions looked very different from how they ever had. It looks as though the altered grid gets baked into the MIDI regions even though the grid alterations were never saved.

The steps outlined in the Steps to Reproduce don't actually work to reproduce this issue... Apologies, I haven't been able to pin down how to make it happen, though I ran into the issue a couple times in different save files. The steps below are approximately what I had performed when I encountered the bug. (I triggered this bug when trying to get a screenshot of bug 0009486. Maybe they're linked?)
Tags:
Steps To Reproduce: 1. Create a midi track
2. Create a region on that track
3. Add some midi notes to the region, preferably on the grid so that the bug can easily be seen in later steps.
3b. Maybe also add an automation lane with some points.
4. Using the Grid Tool (Y), pin a location before the region and a location after the region.
5. SAVE the project
6. Using the Grid Tool, apply a few mid-twists to the grid between the location created in 4.
7. Close Ardour, DO NOT SAVE
8. Reopen the project
9. Notice that the notes created in 3 now have different durations and positions.
Additional Information: Attached are two screenshots. The first is from just before closing Ardour (after step 6), and the second is after reloading the project (step 8).

Also attached is the archive of the session which has the twisted notes.
System Description
Attached Files: Screenshot_20231017_035006.png (169,912 bytes) 2023-10-17 09:57
https://tracker.ardour.org/file_download.php?file_id=4673&type=bug
png

Screenshot_20231017_035706.png (153,738 bytes) 2023-10-17 09:57
https://tracker.ardour.org/file_download.php?file_id=4674&type=bug
png

2023_10_17_tempo_mapping_7_2023-10-17_044910.ardour-session-archive (5,561 bytes) 2023-10-17 09:57
https://tracker.ardour.org/file_download.php?file_id=4675&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9485 [ardour] bugs minor always 2023-10-17 09:13 2023-10-17 09:13
Reporter: rastin Platform: Arch  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Display of midi automation remains after automation points deleted
Description: After deleting all automation points in a midi region, changing zoom or moving the canvas shows visually the points that were just deleted as if they had not been deleted. The issue seems to be graphical only, as the automation lane's value does not change when playing through the region.

Note that this happens only when deleting all points. Deleting a single point does not have this issue.
Tags:
Steps To Reproduce: 1. Create a blank MIDI region in a MIDI track. Something four bars long is sufficient.
2. Add an automation lane to it (such as Pitch Bender or Controller).
3. Add some automation points using the Draw Tool (D)
4. Using the Edit Tool (E), click on the automation lane that contains the newly-created points.
5. Press Ctrl+A to select all automation points in that lane.
6. Press Delete to delete all points.
7. Zoom in or zoom out to see the ghostly remains of the automation points that were just deleted.
Additional Information: The attached screenshot shows the result of deleting all of the automation points and then zooming out one tick on the mouse scroll wheel. The automation points that existed in the previous zoom level are displayed beyond the boundaries of the region at the current zoom level. (There should not be any points at all, since they were deleted.)

Unsure if this is an issue on my system only. So, here are my system specs just in case the issue is indeed unique to me.
Ardour is compiled from source and run using ./ardev
./ardev --version reports the following
Ardour8.0.44 (built using 8.0-44-g44a2ef9098 and GCC version 13.2.1 20230801)

inxi -F
System:
  Host: lunchbox Kernel: 6.1.55-1-MANJARO arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.27.8 Distro: Manjaro Linux
Machine:
  Type: Desktop System: ASUS product: All Series v: N/A
    serial: <superuser required>
  Mobo: ASUSTeK model: Z97I-PLUS v: Rev X.0x serial: <superuser required>
    UEFI: American Megatrends v: 2302 date: 11/04/2014
CPU:
  Info: quad core model: Intel Core i7-4790K bits: 64 type: MT MCP cache:
    L2: 1024 KiB
  Speed (MHz): avg: 2374 min/max: 800/4000 cores: 1: 3885 2: 3998 3: 3910
    4: 800 5: 800 6: 800 7: 4000 8: 800
Graphics:
  Device-1: NVIDIA GM204 [GeForce GTX 980] driver: nvidia v: 535.113.01
  Display: x11 server: X.Org v: 21.1.8 with: Xwayland v: 23.2.1 driver: X:
    loaded: nvidia gpu: nvidia resolution: 1920x1080~60Hz
  API: EGL Message: No EGL data available.
  API: OpenGL v: 4.6.0 vendor: nvidia v: 535.113.01 renderer: NVIDIA
    GeForce GTX 980/PCIe/SSE2
  API: Vulkan v: 1.3.264 drivers: nvidia surfaces: xcb,xlib
System Description
Attached Files: Screenshot_20231017_034606.png (162,366 bytes) 2023-10-17 09:13
https://tracker.ardour.org/file_download.php?file_id=4671&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9481 [ardour] bugs major always 2023-10-14 10:28 2023-10-17 04:13
Reporter: doojonio Platform: Redhat  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI event duplicates on midi buses during session exports when using ALSA
Description: If you use ALSA as a backend for Ardour:
1) MIDI events from midi track to midi bus duplicate during session exports.
2) They don't duplicate in realtime, but duplicate during export.
3) This bug causes increasing volume on the bus during the export, because midi bus instrument will play twice. So volume balance in exported session will be ruined
Tags: alsa, bus, export, Midi
Steps To Reproduce: 1) Create new session with ALSA backend
2) Add a midi track without instrument and a midi bus with somo instrument (lsp sampler for example). Set MIDI track output to the MIDI bus
4) Add ACE MIDI Monitors before MIDI bus instrument
3) Draw some notes on the midi track and play them in realtime. Ensure that midi events do not duplicate
4) Export (in realtime) session. During the playback, ensure that midi events duplicate on the midi bus before the instrument. And it plays with more volume.

Additional Information: I uploaded the video. In first part I play session in realtime. In second part I export session. You can see that MIDI bus plays louder during the export and there are duplicates of the midi events (double "On C2" notes)
System Description
Attached Files: midi event duplicates_2023-10-14_200258.ardour-session-archive (10,324 bytes) 2023-10-14 15:04
https://tracker.ardour.org/file_download.php?file_id=4668&type=bug
Notes
(0028199)
paul   
2023-10-14 13:38   
Could you attach your test session as a session archive please? (Use the top level menu .. Session > Archive)
(0028200)
doojonio   
2023-10-14 15:04   
(0028201)
doojonio   
2023-10-14 15:07   
You can easily test it by using realtime export. Export > Time Span (at top) > RT checkbox. When you will export my attached session, piano will clipping, but when you play it in ardour without exporting, it wont
(0028215)
x42   
2023-10-16 20:57   
Also happens during normal export (realtime export is not required)
(0028216)
x42   
2023-10-17 04:04   
Fixed in 8.0-44-g44a2ef9098

I am however curious which synth produces louder output after receiving a duplicate Note-On (same timestamp).
(0028217)
doojonio   
2023-10-17 04:13   
I use LSP Sampler to add drum samples. It is produces louder sample output after receiving a duplicate Note-On

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9482 [ardour] bugs minor always 2023-10-15 12:41 2023-10-16 09:46
Reporter: benald Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can only insert patch change in first region of midi track
Description: I have one midi track and one midi bus both connected to the excellent General Midi Synth. I have Dr Graf's excellent Raptor arpeggiator on the midi track and I have recorded the arpeggiated midi into the midi bus. I thought it would be nice to hear the midi on both tracks through changing, different instruments. I started by splitting the tracks where I wanted a new instrument but found I couldn't add a patch change in the new region. I then found I could add a patch change in the first region of the track and split that region at the patch change. This works but the tracks are long and it would very hard work to recombine all of the regions every time I want to add a patch change.
Tags:
Steps To Reproduce:
Additional Information: I am running Ardour nightly 8.0.19
System Description Windows 11
Attached Files: Ardour 8 arpeggios.zip (761,743 bytes) 2023-10-15 12:41
https://tracker.ardour.org/file_download.php?file_id=4669&type=bug
Notes
(0028206)
benald   
2023-10-15 15:43   
I thought I had thought up a workaround by creating an empty track to drag regions down to (where they would become the first region) - change the patch there and then drag them back to the original position. When I dragged a patch down to the empty track - the patch changes in previous regions from the source track appeared in the destination track over empty space and any subsequent action crashed Ardour.
(0028207)
x42   
2023-10-15 15:46   
I cannot reproduce this. I can add patch-changes just fine in MIDI regions.

Perhaps the issue is "edit point" and you try to add a patch-change somewhere outside the region. e.g. if edit-point is set to "playhead" and that is not above the region.
(0028208)
benald   
2023-10-15 15:57   
Thanks, x42. I was on 'playhead' and changed to 'marker'. This was no better. Then I changed to 'mouse' and I can now insert multiple patch changes in subsequent regions. Result!
(0028209)
x42   
2023-10-15 16:11   
It still seem an issue that one can add patch-changes outside of a region, and that can cause crashes later.
(0028210)
benald   
2023-10-15 16:17   
Yes - it looks like a copied/moved region can have patch changes outside of its begin and end. I imagine that could be a problem.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9350 [ardour] bugs crash have not tried 2023-05-24 22:51 2023-10-16 09:02
Reporter: middlewalker Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: unknown crashing problem involving timecnt
Description: For some reason, when attempting to load a specific project, ardour fails and gives me the errors:

> Cannot initialize session/engine: Audio/MIDI Engine is not running or sample-rate mismatches.
and
> ---ERROR: Unexpected exception during session setup: negative distance in timecnt constructor
Tags: crash, Linux
Steps To Reproduce: here's my project folder, if that helps.
https://drive.proton.me/urls/VV2F3GPA5M#SyPrLV5t28VG
Additional Information: Project was made using pipewire. have not tested on pulseaudio or jack. changing audio engines has not solved this problem, restarting pipewire has not solved this problem, updating and rebooting my system has not solved this problem, deleting files in a backup of the folder has not solved this problem. Thus, I believe it stems from something in the main .ardour file. Tested with both the Arch Linux ardour package and with the AUR ardour-git package.
System Description
Attached Files:
Notes
(0027971)
middlewalker   
2023-08-11 07:13   
I've been able to gain access to these files by commenting out the lines 78-80 in libs/temporal/timeline.cc on the main branch on the github mirror. I don't imagine this is a great solution, but it seems to work fine without it. I'm not sure what the lines are meant to prevent, though now I can access the files.
(0027972)
middlewalker   
2023-08-11 07:21   
on further note the plugins look to be unusuable, but that can at least be redone. definitely better than being unable to access it at all.
(0027973)
middlewalker   
2023-08-11 07:49   
this is not the case, those plugins will reset every time. however that is a separate problem. for now i'm going to leave this here unless I find a better solution
(0028211)
truls   
2023-10-16 09:02   
I encountered this problem and by commenting out parts of the ardour-file I managed to track it to a region definition in the xml. This region had a problem:
    <Region name="Take139_Test-1.2" muted="0" opaque="1" locked="0" video-locked="0" automatic="0" whole-file="0" import="0" external="0" sync-marked="0" left-of-split="0" right-of-split="0" hidden="0" position-locked="0" valid-transients="0" start="a752640000" length="a4611685970258427903@a48168960000" sync-position="a752640000" ancestral-start="a359068080" ancestral-length="a774584160@a359068080" stretch="0.97166240215301514" shift="1" layering-index="5" tags="" contents="0" rgroup="5712" envelope-active="0" default-fade-in="0" default-fade-out="0" fade-in-active="1" fade-out-active="1" scale-amplitude="2.8850500583648682" id="38873" type="audio" first-edit="nothing" source-0="38474" master-source-0="38020" channels="1"/>

The length seemed strange compared to other ones, so I removed some numbers from the part before the @, and then I could load the file without the error; working version:
    <Region name="Take139_Test-1.2" muted="0" opaque="1" locked="0" video-locked="0" automatic="0" whole-file="0" import="0" external="0" sync-marked="0" left-of-split="0" right-of-split="0" hidden="0" position-locked="0" valid-transients="0" start="a752640000" length="a46116859@a48168960000" sync-position="a752640000" ancestral-start="a359068080" ancestral-length="a774584160@a359068080" stretch="0.97166240215301514" shift="1" layering-index="5" tags="" contents="0" rgroup="5712" envelope-active="0" default-fade-in="0" default-fade-out="0" fade-in-active="1" fade-out-active="1" scale-amplitude="2.8850500583648682" id="38873" type="audio" first-edit="nothing" source-0="38474" master-source-0="38020" channels="1"/>

Hope it helps someone!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9484 [ardour] bugs minor always 2023-10-15 18:01 2023-10-15 18:01
Reporter: Schmitty2005 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: Mixbus 9.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When editing lower layers on MIDI with ‘layers’ view, notes cannot be moved correctly
Description: When trying to edit the second layer in a MIDI track, using ‘E’ Edit mode, I am unable to properly move an existing note. The note that is being edited seems to have its boundary attached to the first MIDI Layer.

Example this C2 Note in the pic below, select “E” for Edit mode, then select the note, trying to move any direction, and it bumps it up to an possibly random note, it was A3 one time, F4 another, and the note can only be dragged up higher into the first layer, eventually hitting MIDI note 127. As a side-note, the boundary seems to be tied to the first layer, if that makes sense, and going no further. When the mouse is released, the note will drop into the proper layer but a note on the second layer can never be moved below where it moves when selected with the ‘E’ tool.

Tags: Edit, Layers, Midi
Steps To Reproduce: To recreate issue:

    1. Create New MIDI track
    2. Draw two new regions, add a few notes.
    3. Drag one MIDI region over the other
    4. Switch to layer view
    5. Select a note in the second layer with ‘E’ tool.
    6. Try to move note vertically or horizontally.
    7. Notice what happens (selected note moves up in pitch) and continue to drag the note up as high as you can. and then as low as you can. And note that the limits seem tied to the first layer.
Additional Information: Affects Mixbus 9.2.105 . Also affects Ardour 8.0 Release downloaded from Ardour.org.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9483 [ardour] bugs minor always 2023-10-15 13:25 2023-10-15 14:36
Reporter: colinf Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Only left channel of stereo regions is heard for a while after region trim
Description: After modifying a stereo region, playback of that region will only play the left channel of the region through both outputs of the track, for an amount of time that seems to be equal to the “Edit | Preferences | Performance | Disk I/O | Buffering | Playback” setting.

See https://discourse.ardour.org/t/first-10-seconds-of-modified-stereo-region-goes-mono-output/109322
Tags:
Steps To Reproduce: * modify a stereo region. I've done this by trimming the left-hand end
* start playback of that region

That's it - only the left channel will be heard for a few seconds.
Additional Information: Bisected to 295dbd8e: “Make RCU reader return a const pointer (omnibus commit)”. Bisect log attached in case I messed it up for any reason.
System Description
Attached Files: git-bisect-7.3-7.4-log (3,615 bytes) 2023-10-15 13:25
https://tracker.ardour.org/file_download.php?file_id=4670&type=bug
Notes
(0028205)
x42   
2023-10-15 14:35   
outstanding detective work tracking this down. Thanks!

Fixed in 8.0-24-gfd3f475b3f

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9477 [ardour] bugs minor always 2023-10-10 18:14 2023-10-14 13:06
Reporter: cyr123 Platform: PC  
Assigned To: OS: Pop!_OS  
Priority: normal OS Version: 22.04  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unable to open native file dialogs from VST plugins
Description: When I select an option in a plugin GUI that is supposed to open a file / directory dialog in the OS (e.g. "load preset", "open preset directory" or "load license file") nothing happens. This is specific to Ardour, it works as expected in Carla.

I've seen this in a number of plugins, I expect it applies to all VST3 plugins at least.
Examples: Dexed, TAL-U-NO-LX, AudioThings "Things" plugins.
Tags:
Steps To Reproduce: 1) Open custom GUI in Dexed
2) Click on CART
3) Click on LOAD, SAVE or SHOW DIR

Nothing happens (a file dialog is expected)
Additional Information: Just as I was posting this bug report I decided to run Ardour from a terminal and look for any hints, and I found some. It looks like some kind of confusion regarding MIME types, followed to an attempt to run every web browser under the sun. I hope this makes sense to someone...

xdg-mime: mimetype argument missing
Try 'xdg-mime --help' for more information.
Warning: unknown mime-type for "/home/cyrano/.local/share/DigitalSuburban/Dexed/Cartridges" -- using "application/octet-stream"
Error: no "view" mailcap rules found for type "application/octet-stream"
Use of uninitialized value $file in open at /usr/share/perl5/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value $file in open at /usr/share/perl5/File/MimeInfo/Applications.pm line 140.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 105.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 105.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 105.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 105.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 105.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 105.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 105.
Use of uninitialized value in subroutine entry at /usr/share/perl5/File/BaseDir.pm line 105.
Opening "/home/cyrano/.local/share/DigitalSuburban/Dexed/Cartridges" with Visual Studio Code (inode/directory)
/usr/bin/flatpak: symbol lookup error: /lib/x86_64-linux-gnu/libsoup-2.4.so.1: undefined symbol: g_file_info_get_modification_date_time
/usr/bin/xdg-open: 882: x-www-browser: not found
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0: undefined symbol: atk_component_scroll_to
Couldn't load XPCOM.
/usr/bin/xdg-open: 882: iceweasel: not found
/usr/bin/xdg-open: 882: seamonkey: not found
/usr/bin/xdg-open: 882: mozilla: not found
/usr/bin/xdg-open: 882: epiphany: not found
/usr/bin/xdg-open: 882: konqueror: not found
/usr/bin/xdg-open: 882: chromium: not found
/usr/bin/xdg-open: 882: chromium-browser: not found
/usr/bin/xdg-open: 882: google-chrome: not found
/usr/bin/xdg-open: 882: www-browser: not found
/usr/bin/xdg-open: 882: links2: not found
/usr/bin/xdg-open: 882: elinks: not found
/usr/bin/xdg-open: 882: links: not found
/usr/bin/xdg-open: 882: lynx: not found
/usr/bin/xdg-open: 882: w3m: not found
xdg-open: no method available for opening '/home/cyrano/.local/share/DigitalSuburban/Dexed/Cartridges'
/bin/sh: 1: /etc/alternatives/x-www-browser: not found
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0: undefined symbol: atk_component_scroll_to
Couldn't load XPCOM.
/bin/sh: 1: mozilla: not found
/bin/sh: 1: google-chrome: not found
/bin/sh: 1: chromium-browser: not found
/bin/sh: 1: opera: not found
/bin/sh: 1: konqueror: not found
System Description
Attached Files:
Notes
(0028181)
cyr123   
2023-10-11 15:27   
I have tried to debug this further, looking more closely at the log I see that xdg-open tries (but fails) to launch VS Code, which might be related to this issue: https://github.com/microsoft/vscode/issues/41037 (though I have had no such problems outside Ardour)

If I uninstall VS Code, xdg-open now correctly tries to open the file manager (Nautilus), but that then fails because of:

"/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0: undefined symbol: atk_component_scroll_to"

Something quite similar reported here: https://gitlab.gnome.org/GNOME/zenity/-/issues/18 turned out to be caused by LD_LIBRARY_PATH and conflicting library versions, I strongly suspect this is the issue here as well.
I see that the launch script for Ardour sets LD_LIBRARY_PATH to that Ardour can use the bundled libraries, but shouldn't this be cleared from the environment when an external application is launched from within Ardour?
(0028182)
cyr123   
2023-10-11 16:05   
I think I confirmed and partially fixed the issue using the following wrapper script:

$ cat /opt/Ardour-8.0.0/bin/xdg-open
#!/bin/sh

unset LD_LIBRARY_PATH
/usr/bin/xdg-open "$@"

This fixed the "show directory" function, however it is still no possible to open a file dialog to load or save a file (and I see no log output to diagnose this).
(0028193)
x42   
2023-10-13 00:35   
If they'd use the official VST3 GUI that would not be an issue. LD_LIBRARY_PATH is unset there:

https://github.com/steinbergmedia/vstgui/blame/65c353fcad783dd6baa34a2b9dbe23bb9f88d035/vstgui/lib/platform/linux/x11fileselector.cpp#L189

Please suggest that to the plugin vendor
(0028194)
cyr123   
2023-10-13 05:25   
Do you happen to know any plugins that do this correctly I could check?

Is there any reason Ardour couldn't, or shouldn't, unset LD_LIBRARY_PATH before loading any plugins? Or could the way it's built and packaged be changed to not rely on this var?

Meanwhile, I've installed a flatpak version of Ardour8 and it doesn't have this issue. I suppose that's a solution, but I'd rather use the officially supported version.
(0028196)
x42   
2023-10-13 20:00   
Ardour cannot unset it. It is the plugin that copies the environment after calling fork (which is another thing a plugin should not do since it causes dropouts).
surge is an example of a plugin that gets it right (and they also use vfork).
(0028197)
cyr123   
2023-10-14 07:22   
What I mean was essentially https://linux.die.net/man/3/unsetenv in main()
But maybe that would break bundled plugins or some other dynamically loaded part of Ardour ?

SurgeXT (LV2 and VST3 version) seems to have the same problem as the other plugins I've tried.

I've fixed the problem using the brute force method of removing every .so file from /opt/Ardour-8.0.0/lib that isn't needed to allow Ardour to launch without errors.
This is what I'm going to use for now, the flatpak has the problem of not seeing plugins installed using OS packages because of the sandboxing.
(0028198)
x42   
2023-10-14 13:06   
(Last edited: 2023-10-14 13:06)
> What I mean was essentially https://linux.die.net/man/3/unsetenv in main()

That will not work since Ardour dynamically loads modules after that. All engine backends are dynamically linked, as are control surfaces and panners.

> SurgeXT (LV2 and VST3 version) seems to have the same problem as the other plugins I've tried.

Surge solved this a few years ago:
https://github.com/surge-synthesizer/surge/issues/3790
https://github.com/surge-synthesizer/surge/issues/657

Anyway it is really bad practice for plugins to rely on external resources. (libraries or applications), and as the surge discussion explains using fork to launch an external app is even worse since it can cause dropouts.
On other platforms (macOS, Windows) plugins are all statically linked, and pro-audio distros (e.g. KXStudio) do this as well.

I'd rather prefer a baldly written or badly packaged plugin to not work than causing audio dropouts. YMMV.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9419 [ardour] bugs minor always 2023-07-21 06:28 2023-10-12 15:09
Reporter: sollapse Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Varispeed loses midi sync when pitching up in 7.5.198
Description: In the 7.5.198 build, it seems using varispeed with midi tends to lose sync periodically when pitching up 1+ semitones. For the midi track in question, I'm using a VST step sequencer controlling a synth drum kit. This issue does not appear in 7.5.0.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0028192)
x42   
2023-10-12 15:09   
Sorry for the delay, I just started looking into this.

Do I understand correctly that you use a VST plugin to generate MIDI events and then send MIDI data to an external hardware synth?

I have created a MIDI track without instrument, then created a MIDI region with equally spaced 8th notes. (Session is 48kHz, default 120 BPM).
I send those MIDI events out, and when I check on another machine these MIDI events arrive equally spaced, even when vari-speeding.

So it seems the issue might be caused by VST3/tempo and not playback vari-speed mapping of events on the output.

I do not have a VST3 sequencer, so could you try the following: Record the MIDI data output of the VST3 sequencer on another MIDI track in Ardour.

Create a MIDI track and connect its input to the output of the MIDI track with the Sequencer. rec-arm, record, vari-speed.
Does the recording show artifacts you describe?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9474 [ardour] features feature N/A 2023-10-10 07:57 2023-10-12 06:53
Reporter: slartibartfast Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Automatic levels at -23 LUFS for imported audio
Description: I know this is a long-shot, but one cool feature I miss in Ardour when mixing podcasts, is the automatic levels - where on import, it would be possible to check a box so levels of an imported track are set to consistently hit a target of -23 LUFS. Like a sort of intelligent normalization/intelligent gain envelope.

Having this as an option would make Ardour even more powerfull as a podcast editing tool and speed up the process when editing audio stories even more.
Tags: loudness, podcasting, request
Steps To Reproduce:
Additional Information: The reason for the suggested target of -23 LUFS, is because this is near the recommended loudness level for mixing (pre normalization export to any platform-specific targets, such as Apples or Spotifys -16).
Sources: https://transom.org/2021/the-audio-producers-guide-to-loudness/ and https://training.npr.org/2018/10/31/mixing/
System Description
Attached Files:
Notes
(0028173)
x42   
2023-10-10 11:44   
Ardour offers this on export. An EBU-R128 preset has been available since over 10 years now.

I'm curious though, why you want this on import though.
Cutting, editing and mixing changes the loudness . One has to normalize the final result to meet broadcast specs.

For individual regions you can use Region > Gain > Normalize, which offers a LUFS target value.
(0028174)
slartibartfast   
2023-10-10 12:39   
I know it has this on export. The reason I want a similar function on import is because of how long it takes to fiddle with the basic loudness of my tracks to begin editing a podcast.
I saw this option in another DAW named after an infamous airship (link here: https://loudfunk.dk/watch?v=ODvM0GZMqq8), and thought it would be quite cool to have in Ardour as well to speed up the editing process for audio stories/podcasts etc.
(0028183)
Dan Easley   
2023-10-12 00:55   
Having worked in public radio and television for twenty years, I have to agree that, while I would never use this feature in music production, I think I would find it really useful for podcast/broadcast production.
(0028184)
x42   
2023-10-12 01:06   
Would this only happen once on input?
Or do you expect regions to automatically adjust the gain when you split or trim them later?

The former would be relatively easy and be identical to manually normalize the region just after import.
(0028185)
Dan Easley   
2023-10-12 01:27   
I don't want to hijack slartibartfast's request, but I was imagining an option in the Import window.
(0028191)
slartibartfast   
2023-10-12 06:53   
No worries, Dan.
This was also how I imagined it. Like a checkbox in the import window, similar to those that lets one choose to import files as new tracks or directly to sources list.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9479 [ardour] bugs crash always 2023-10-12 02:01 2023-10-12 04:40
Reporter: ayerkblei Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: adding zynaddsubfx lv2 to a track crashes ardour
Description: this is using the pipewire jack emulation.. What's surprising is that when I loaded a saved session that already had a zyn plugin on a track.. It worked fine! (including the gui) I tried loading other lv2s and they worked fine.. so perhaps I should be querying at the zyn forums, if so sorry about that. tnx
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028186)
x42   
2023-10-12 02:24   
Just zyn, or any other synth?

There was a pipewire bug that prevented creating MIDI tracks with synths in new sessions (meanwhile fixed in recent pipewire).
Can you try to change the audio-engine (Ardour Menu > Window > Audio/MIDI Setup) to ALSA or pulseaudio and see if you can add zyn then?
(0028187)
ayerkblei   
2023-10-12 03:00   
looks like under (pipewire) jack, generalMidiSynth and ReasonableSynth, as well as Zyn VST version all crash Ardour.. When engine is changed to either PulseAudio or Alsa, Zyn loads (including GUI).. Would prefer to use the Pipewire since it's so easy to route audio from other apps like firefox, but maybe that's not going to happen.. Any guesses where the problem might lie?
(0028188)
ayerkblei   
2023-10-12 03:03   
tried to check my version of pipewire, but not so easy, pipewire -v in the CLI gets error, presumably because the running pipewire blocks it.
(0028189)
x42   
2023-10-12 03:34   
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3183
(0028190)
ayerkblei   
2023-10-12 04:40   
interesting reading! I see now my pipewire is 0.3.65, so I'll just use the workaround of changing the Ardour audio engine til Ubuntu adds the latest pipewire with your patches.. tnx so much!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9367 [ardour] bugs crash always 2023-06-10 05:02 2023-10-12 03:34
Reporter: gaybe Platform: GNU  
Assigned To: x42 OS: OpenSUSE  
Priority: urgent OS Version: tumbleweed  
Status: resolved Product Version: 7.4  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes trying to create a new MIDI track.
Description: I was trying to start and learn how to use this software, but I just can't do it. If I try to run it in ALSA, any sound device starts to not being detected by the system, I can't here Ardour not even other app. If I try to run it in JACK, as I pretended at start, it just crashes everytime I try to create a MIDI Track.
Tags:
Steps To Reproduce: Open a new session with JACK.
Right click on the track area.
It will open a window to create a new track, select the MIDI Track one.
Click in the button to create it.
Additional Information:
System Description
Attached Files:
Notes
(0027733)
x42   
2023-06-10 13:25   
Are you perhaps using pipewire as JACK server?

If so, please see
https://discourse.ardour.org/t/ardour-crashes-when-trying-to-load-synth-with-jack/108700
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3183

> If I try to run it in ALSA, any sound device starts to not being detected by the system,

Perhaps the device is in use? Ardour requires exclusive access to the soundcard, This usually works fine (Ardour requests the device from pipewire or pulseaudio).
(0027895)
kmarty   
2023-07-14 18:24   
I have the same issue. When JACK (pipewire-jack) is used, Ardour freezes immediately after add midi track is attempted.
Ardour is 7.5.0.
Pipewire is latest possible (commit 0a13d37e5, Jul 14 2023).

Doesn't happen when Reaper (instead of Ardour) is used.
(0027896)
x42   
2023-07-14 18:38   
If this does not happen with JACK (no pipewire) or Ardour/ALSA (no pipewire) then this is a pipewire bug.

I cannot reproduce this with pipewire/git. If you can could you get a bactrace?

PS. are you certain Ardour actually use latest pipewire on your system (see comment https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3183#note_1922014)
PPS. Reaper internally works significantly different.
(0027897)
kmarty   
2023-07-14 20:43   
> PS. are you certain Ardour actually use latest pipewire on your system (see comment https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3183#note_1922014)
Oops, damn. You're right.
Ardour was loading the old libraries :-(

with correct LD_LIBRARY_PATH, PIPEWIRE_CONFIG_DIR and PIPEWIRE_MODULE_DIR (all pointing to the new pipewire tree) Ardour works.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9476 [ardour] features feature N/A 2023-10-10 16:27 2023-10-10 20:02
Reporter: slartibartfast Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Use range-marker do define gain-envelopes, to dip audio.
Description: it would be cool if ranges marked with "range-finder" activated four points in a gain envelope that spanned the marking. This would make sound-beds/music dips under i.e. speaks much faster. Image from another DAW attached to show what I mean since I'm not currently on a machine with Ardour on it.

As it works now in Ardour, one has to manually make each point for the gain envelope.

Having the feature requested here not as a replacement, but as an addition would be really cool.
Tags: editing, mixing, podcast, radio
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Webklip_10-10-2023_18443_i.ytimg.com.jpeg (28,047 bytes) 2023-10-10 16:27
https://tracker.ardour.org/file_download.php?file_id=4667&type=bug
jpeg
Notes
(0028175)
x42   
2023-10-10 17:15   
> As it works now in Ardour, one has to manually make each point for the gain envelope.

You can use the range tool to select a range, then switch to the draw tool (press 'd') and lower that range (which creates 4 points).
switch back to the range tool (press 'r') and repeat.

It is not identical to the image you posted since there is no ramp, but otherwise that workflow is available in Ardour.

Here a video showing this in Mixbus - the editor is identical to Ardour though: https://youtu.be/DjlBbao5gMQ?feature=shared&t=135
(0028176)
slartibartfast   
2023-10-10 19:05   
Awesome! Thanks for clarifying :)
Ardour keeps being stellar!
(0028177)
slartibartfast   
2023-10-10 20:02   
The ramp would be nice to have as an option, though. To smoothen out ducks.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9475 [ardour] bugs minor always 2023-10-10 14:27 2023-10-10 14:27
Reporter: sollapse Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 8.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi scroomer and piano roll scaling
Description: It seems on a HiDPI display (only display in use by me), the piano roll notes fail to properly scale as shown in the screenshot.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files: midi_keyboard.jpg (9,912 bytes) 2023-10-10 14:27
https://tracker.ardour.org/file_download.php?file_id=4666&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9473 [ardour] bugs major always 2023-10-09 18:41 2023-10-09 19:16
Reporter: ardourwlk Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 8.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Hanging on start - splash says "setup editor"
Description: Starting fresh while passing some arguments:
/opt/Ardour-8.0.0/bin/ardour8 -N $(date +%Y%m%d\.%H%M) -T 3WayToneLib01

First time (was first time with 8), it said it had to set up my profile, and I would need to restart. Now, everytime I start like this (although I have not tried any other way yet), it hangs on the "Setup Editor" splash screen, and I can see a process running at 100%

Ah, removed the -T argument, and it started. So it doesn't seem to like the template (which I use all the time on 7.5.0).
Tags:
Steps To Reproduce: As noted in description.
Additional Information: I'll try to get you a debug!
System Description
Attached Files: 3WayToneLib01.template (44,619 bytes) 2023-10-09 18:45
https://tracker.ardour.org/file_download.php?file_id=4664&type=bug
3WayToneLib01-2.template (44,619 bytes) 2023-10-09 18:46
https://tracker.ardour.org/file_download.php?file_id=4665&type=bug
Notes
(0028164)
ardourwlk   
2023-10-09 18:45   
This is the "ardour8" template
(0028165)
ardourwlk   
2023-10-09 18:46   
This is the "ardour7" template, so you can see what may have changed, if anything. These are copied from my ~/.config/ directories under the appropriate versions.
(0028166)
ardourwlk   
2023-10-09 18:47   
Just a note to clarify that if I remove the template argument, Ardour starts. If I add the template argument back in, it hangs.
(0028167)
ardourwlk   
2023-10-09 18:51   
And what this template does is create 3 (maybe 4?) tracks, for re-amping, so I have one interface input on track 1, another interface input on track 2, and then a third track receiving input from standalone ToneLib GLX.
(0028168)
x42   
2023-10-09 18:52   
OK. It works here if I start Ardour normally, and then pick the template from the sidebar of the New session dialog.

When using `-N $(date +%Y%m%d\.%H%M) -T 3WayToneLib01` a debug build assert()s
ardour-8.0.0: ../libs/temporal/timeline.cc:569: Temporal::Beats Temporal::timepos_t::_beats() const: Assertion `time_domain() == AudioTime' failed.

Thanks, we will look into a fix for this.
(0028169)
ardourwlk   
2023-10-09 18:57   
Hmmm... I tried to start with gdb with the template option, and it gave me the new session menu... Is there not a way to do that? And when I started the session in this case, selecting the applicable template from the menu, it started.
(0028170)
x42   
2023-10-09 19:03   
Perhaps you passed the option to gdb rather than Ardour?
Are you using official debug version (from nightly.ardour.org) if so, run Ardour7 --gdb -N ... -T ...
or local builds, from source ./gtk2_ardour/ardbg -N .. -T ...

got me:
Setting time domain
ardour-8.0.0: ../libs/temporal/timeline.cc:569: Temporal::Beats Temporal::timepos_t::_beats() const: Assertion `time_domain() == AudioTime' failed.

Thread 1 "ArdourGUI" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
0000001  0x00007ffff0f0a537 in __GI_abort () at abort.c:79
#2  0x00007ffff0f0a40f in __assert_fail_base
    (fmt=0x7ffff1081688 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff36fd860 "time_domain() == AudioTime", file=0x7ffff36fcdc0 "../libs/temporal/timeline.cc", line=569, function=<optimized out>) at assert.c:92
#3  0x00007ffff0f19662 in __GI___assert_fail
    (assertion=0x7ffff36fd860 "time_domain() == AudioTime", file=0x7ffff36fcdc0 "../libs/temporal/timeline.cc", line=569, function=0x7ffff36fd800 "Temporal::Beats Temporal::timepos_t::_beats() const") at assert.c:101
0000004  0x00007ffff37e2cd5 in Temporal::timepos_t::_beats() const (this=0x61a000182260) at ../libs/temporal/timeline.cc:569
0000005  0x00007ffff37e2241 in Temporal::timepos_t::set_time_domain(Temporal::TimeDomain) (this=0x61a000182260, td=(unknown: 0xbebebebe)) at ../libs/temporal/timeline.cc:504
#6  0x00007ffff5a89b79 in ARDOUR::Location::set_position_time_domain(Temporal::TimeDomain) (this=0x61a000181e80, domain=(unknown: 0xbebebebe)) at ../libs/ardour/location.cc:249
#7  0x00007ffff5a89bb6 in ARDOUR::Location::set_time_domain(Temporal::TimeDomain) (this=0x61a000181e80, domain=(unknown: 0xbebebebe)) at ../libs/ardour/location.cc:258
0000008  0x00007ffff5aa0a73 in ARDOUR::Locations::time_domain_changed() (this=0x618000177080) at ../libs/ardour/location.cc:2053
0000009  0x00007ffff55fd223 in boost::_mfi::mf0<void, Temporal::TimeDomainProvider>::operator()(Temporal::TimeDomainProvider*) const (this=0x6070025dc7a8, p=0x618000177180)
    at /usr/include/boost/bind/mem_fn_template.hpp:49
0000010 0x00007ffff55faacd in boost::_bi::list1<boost::_bi::value<Temporal::TimeDomainProvider*> >::operator()<boost::_mfi::mf0<void, Temporal::TimeDomainProvider>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, Temporal::TimeDomainProvider>&, boost::_bi::list0&, int) (this=0x6070025dc7b8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000011 0x00007ffff55f8590 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, Temporal::TimeDomainProvider>, boost::_bi::list1<boost::_bi::value<Temporal::TimeDomainProvider*> > >::operator()()
    (this=0x6070025dc7a8) at /usr/include/boost/bind/bind.hpp:1294
0000012 0x00007ffff55f5926 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, Temporal::TimeDomainProvider>, boost::_bi::list1<boost::_bi::value<Temporal::TimeDomainProvider*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000013 0x0000555557c34d11 in boost::function0<void>::operator()() const (this=0x6070025dc7a0) at /usr/include/boost/function/function_template.hpp:763
0000014 0x0000555557c343dd in PBD::Signal0<void, PBD::OptionalLastValue<void> >::operator()() (this=0x6260000d8290) at libs/pbd/pbd/signals_generated.h:340
#15 0x0000555558041626 in Temporal::TimeDomainProvider::time_domain_changed() (this=0x6260000d8288) at ../libs/temporal/temporal/domain_provider.h:83
0000016 0x00007ffff6437a6c in ARDOUR::Session::time_domain_changed() (this=0x6260000d8100) at ../libs/ardour/session_time.cc:335
#17 0x000055555984f865 in Temporal::TimeDomainProvider::set_time_domain(Temporal::TimeDomain) (this=0x6260000d8288, td=(unknown: 0xbebebebe))
    at ../libs/temporal/temporal/domain_provider.h:63
0000018 0x00007ffff6395bb4 in ARDOUR::Session::config_changed(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool)
    (this=0x6260000d8100, p="default-time-domain", ours=true) at ../libs/ardour/session_state.cc:4590
0000019 0x00007ffff6252af2 in boost::_mfi::mf2<void, ARDOUR::Session, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool>::operator()(ARDOUR::Session*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) const (this=0x6030052595e0, p=0x6260000d8100, a1="default-time-domain", a2=true)
    at /usr/include/boost/bind/mem_fn_template.hpp:280
0000020 0x00007ffff6243d3b in boost::_bi::list3<boost::_bi::value<ARDOUR::Session*>, boost::arg<1>, boost::_bi::value<bool> >::operator()<boost::_mfi::mf2<void, ARDOUR::Session, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool>, boost::_bi::rrlist1<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >(boost::_bi::type<void>, boost::_mfi::mf2<void, ARDOUR::Session, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool>&, boost::_bi::rrlist1<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, int) (this=0x6030052595f0, f=..., a=...) at /usr/include/boost/bind/bind.hpp:398
0000021 0x00007ffff623514d in boost::_bi::bind_t<void, boost::_mfi::mf2<void, ARDOUR::Session, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool>, boost::_bi::list3<boost::_bi::value<ARDOUR::Session*>, boost::arg<1>, boost::_bi::value<bool> > >::operator()<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) (this=0x6030052595e0, a1=...) at /usr/include/boost/bind/bind.hpp:1306
0000022 0x00007ffff6226104 in boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf2<void, ARDOUR::Session, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool>, boost::_bi::list3<boost::_bi::value<ARDOUR::Session*>, boost::arg<1>, boost::_bi::value<bool> > >, void, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::invoke(boost::detail::function::function_buffer&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)
    (function_obj_ptr=..., a0="") at /usr/include/boost/function/function_template.hpp:158
0000023 0x0000555557c8b33a in boost::function1<void, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) const (this=0x6070025dc880, a0="") at /usr/include/boost/function/function_template.hpp:763
#24 0x0000555557d1a40e in PBD::Signal1<void, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, PBD::OptionalLastValue<void> >::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) (this=0x6260000d9058, a1="default-time-domain") at libs/pbd/pbd/signals_generated.h:738
0000025 0x0000555557de5804 in ARDOUR::SessionConfiguration::set_default_time_domain(Temporal::TimeDomain) (this=0x6260000d8f88, val=(unknown: 0xbebebebe))
    at ../libs/ardour/ardour/session_configuration_vars.h:98
0000026 0x0000555557dd7edd in ARDOUR_UI::build_session_stage_two(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, ARDOUR::BusProfile const&, bool, Temporal::TimeDomain)
--Type <RET> for more, q to quit, c to continue without paging--
    (this=
    0x62f00000e400, path="/home/rgareus/Documents/ArdourSessions/20231009.2100", snap_name="20231009", session_template="/home/rgareus/.config/ardour8/templates/3WayToneLib01", bus_profile=..., unnamed=false, domain=(unknown: 0xbebebebe)) at ../gtk2_ardour/ardour_ui_session.cc:779
0000027 0x0000555557dd6bbd in ARDOUR_UI::build_session(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, ARDOUR::BusProfile const&, bool, bool, Temporal::TimeDomain)
    (this=0x62f00000e400, path="/home/rgareus/Documents/ArdourSessions/20231009.2100", snap_name="20231009", session_template="/home/rgareus/.config/ardour8/templates/3WayToneLib01", bus_profile=..., from_startup_fsm=true, unnamed=false, domain=(unknown: 0xbebebebe)) at ../gtk2_ardour/ardour_ui_session.cc:628
0000028 0x0000555557dfec3c in ARDOUR_UI::load_session_from_startup_fsm() (this=0x62f00000e400) at ../gtk2_ardour/ardour_ui_startup.cc:692
0000029 0x0000555557dfc034 in ARDOUR_UI::sfsm_response(StartupFSM::Result) (this=0x62f00000e400, r=StartupFSM::LoadSession) at ../gtk2_ardour/ardour_ui_startup.cc:551
0000030 0x0000555557e0844a in sigc::bound_mem_functor1<void, ARDOUR_UI, StartupFSM::Result>::operator()(StartupFSM::Result const&) const
    (this=0x6080006c1dd8, _A_a1=@0x7fffffffaa50: StartupFSM::LoadSession) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:2066
0000031 0x0000555557e07c11 in sigc::adaptor_functor<sigc::bound_mem_functor1<void, ARDOUR_UI, StartupFSM::Result> >::operator()<StartupFSM::Result const&>(StartupFSM::Result const&) const
    (this=0x6080006c1dd0, _A_arg1=@0x7fffffffaa50: StartupFSM::LoadSession) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:89
0000032 0x0000555557e06a28 in sigc::internal::slot_call<sigc::bound_mem_functor1<void, ARDOUR_UI, StartupFSM::Result>, void, StartupFSM::Result>::call_it(sigc::internal::slot_rep*, StartupFSM::Result const&) (rep=0x6080006c1da0, a_#0=@0x7fffffffaa50: StartupFSM::LoadSession) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:451
0000033 0x0000555559aaa81f in sigc::internal::signal_emit1<void, StartupFSM::Result, sigc::nil>::emit(sigc::internal::signal_impl*, StartupFSM::Result const&)
    (impl=0x6030009d4380, _A_a1=@0x7fffffffaa50: StartupFSM::LoadSession) at /usr/include/sigc++-2.0/sigc++/signal.h:1045
0000034 0x0000555559aa8f6e in sigc::signal1<void, StartupFSM::Result, sigc::nil>::emit(StartupFSM::Result const&) const (this=0x613000082b08, _A_a1=@0x7fffffffaa50: StartupFSM::LoadSession)
    at /usr/include/sigc++-2.0/sigc++/signal.h:2955
0000035 0x0000555559aa7e45 in sigc::signal1<void, StartupFSM::Result, sigc::nil>::operator()(StartupFSM::Result const&) const
    (this=0x613000082b08, _A_a1=@0x7fffffffaa50: StartupFSM::LoadSession) at /usr/include/sigc++-2.0/sigc++/signal.h:2971
0000036 0x0000555559a9b639 in StartupFSM::dialog_response_handler(int, StartupFSM::DialogID) (this=0x6130000829c0, response=-5, dialog_id=StartupFSM::PluginDialog)
    at ../gtk2_ardour/startup_fsm.cc:327
0000037 0x0000555559aadd0f in sigc::bound_mem_functor2<void, StartupFSM, int, StartupFSM::DialogID>::operator()(int const&, StartupFSM::DialogID const&) const
    (this=0x60b0000d72d0, _A_a1=@0x7fffffffae0c: -5, _A_a2=@0x60b0000d72f0: StartupFSM::PluginDialog) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:2143
0000038 0x0000555559aad071 in sigc::adaptor_functor<sigc::bound_mem_functor2<void, StartupFSM, int, StartupFSM::DialogID> >::operator()<int const&, StartupFSM::DialogID&>(int const&, StartupFSM::DialogID&) const (this=0x60b0000d72c8, _A_arg1=@0x7fffffffae0c: -5, _A_arg2=@0x60b0000d72f0: StartupFSM::PluginDialog) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:108
0000039 0x0000555559aac469 in sigc::bind_functor<-1, sigc::bound_mem_functor2<void, StartupFSM, int, StartupFSM::DialogID>, StartupFSM::DialogID, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::operator()<int const&>(int const&) (this=0x60b0000d72c0, _A_arg1=@0x7fffffffae0c: -5) at /usr/include/sigc++-2.0/sigc++/adaptors/bind.h:1136
0000040 0x0000555559aac0af in sigc::internal::slot_call1<sigc::bind_functor<-1, sigc::bound_mem_functor2<void, StartupFSM, int, StartupFSM::DialogID>, StartupFSM::DialogID, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, void, int>::call_it(sigc::internal::slot_rep*, int const&) (rep=0x60b0000d7290, a_1=@0x7fffffffae0c: -5)
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h:170
0000041 0x00007ffff1885f27 in  () at /lib/x86_64-linux-gnu/libgtkmm-2.4.so.1
0000042 0x00007ffff72d70a2 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000043 0x00007ffff72e9602 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000044 0x00007ffff72ef6cf in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000045 0x00007ffff72efc3f in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000046 0x0000555559a9f38a in StartupFSM::engine_running() (this=0x6130000829c0) at ../gtk2_ardour/startup_fsm.cc:557
0000047 0x0000555559a9b4fd in StartupFSM::dialog_response_handler(int, StartupFSM::DialogID) (this=0x6130000829c0, response=-5, dialog_id=StartupFSM::AudioMIDISetup)
    at ../gtk2_ardour/startup_fsm.cc:305
0000048 0x0000555559aadd0f in sigc::bound_mem_functor2<void, StartupFSM, int, StartupFSM::DialogID>::operator()(int const&, StartupFSM::DialogID const&) const
    (this=0x60b0000827c0, _A_a1=@0x7fffffffb7ec: -5, _A_a2=@0x60b0000827e0: StartupFSM::AudioMIDISetup) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:2143
0000049 0x0000555559aad071 in sigc::adaptor_functor<sigc::bound_mem_functor2<void, StartupFSM, int, StartupFSM::DialogID> >::operator()<int const&, StartupFSM::DialogID&>(int const&, StartupFSM::DialogID&) const (this=0x60b0000827b8, _A_arg1=@0x7fffffffb7ec: -5, _A_arg2=@0x60b0000827e0: StartupFSM::AudioMIDISetup) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:108
0000050 0x0000555559aac469 in sigc::bind_functor<-1, sigc::bound_mem_functor2<void, StartupFSM, int, StartupFSM::DialogID>, StartupFSM::DialogID, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::operator()<int const&>(int const&) (this=0x60b0000827b0, _A_arg1=@0x7fffffffb7ec: -5) at /usr/include/sigc++-2.0/sigc++/adaptors/bind.h:1136
0000051 0x0000555559aac0af in sigc::internal::slot_call1<sigc::bind_functor<-1, sigc::bound_mem_functor2<void, StartupFSM, int, StartupFSM::DialogID>, StartupFSM::DialogID, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, void, int>::call_it(sigc::internal::slot_rep*, int const&) (rep=0x60b000082780, a_1=@0x7fffffffb7ec: -5)
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h:170
0000052 0x00007ffff1885f27 in  () at /lib/x86_64-linux-gnu/libgtkmm-2.4.so.1
0000053 0x00007ffff72d70a2 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
0000054 0x00007ffff72e9602 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000055 0x00007ffff72ef6cf in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000056 0x00007ffff72efc3f in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000057 0x00005555585f1203 in EngineControl::start_stop_button_clicked() (this=0x625000223900) at ../gtk2_ardour/engine_dialog.cc:2734
0000058 0x0000555558617694 in sigc::bound_mem_functor0<void, EngineControl>::operator()() const (this=0x6080006be0d8) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
0000059 0x0000555558612506 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, EngineControl> >::operator()() const (this=0x6080006be0d0)
    at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000060 0x000055555860c08d in sigc::internal::slot_call<sigc::bound_mem_functor0<void, EngineControl>, void>::call_it(sigc::internal::slot_rep*) (rep=0x6080006be0a0)
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h:483
0000061 0x0000555557c7210b in sigc::internal::signal_emit0<void, sigc::nil>::emit(sigc::internal::signal_impl*) (impl=0x6030009462a0) at /usr/include/sigc++-2.0/sigc++/signal.h:798
0000062 0x0000555557c8b787 in sigc::signal0<void, sigc::nil>::emit() const (this=0x625000224bb8) at /usr/include/sigc++-2.0/sigc++/signal.h:2804
0000063 0x0000555557c7a37c in sigc::signal0<void, sigc::nil>::operator()() const (this=0x625000224bb8) at /usr/include/sigc++-2.0/sigc++/signal.h:2820
0000064 0x00007ffff2bc0f8e in ArdourWidgets::ArdourButton::on_button_release_event(_GdkEventButton*) (this=0x625000224ac0, ev=0x61d000327e60) at ../libs/widgets/ardour_button.cc:994
0000065 0x00007ffff1900cb4 in Gtk::Widget_Class::button_release_event_callback(_GtkWidget*, _GdkEventButton*) () at /lib/x86_64-linux-gnu/libgtkmm-2.4.so.1
0000066 0x00007ffff1d391ab in  () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000067 0x00007ffff72d70a2 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000068 0x00007ffff72e8e6e in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000069 0x00007ffff72ef259 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000070 0x00007ffff72efc3f in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000071 0x00007ffff1e58fe4 in  () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000072 0x00007ffff1d377d4 in gtk_propagate_event () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000073 0x00007ffff1d37c4b in gtk_main_do_event () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000074 0x00007ffff2da3afc in  () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
0000075 0x00007ffff30e3e6b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#76 0x00007ffff30e4118 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000077 0x00007ffff30e440b in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
0000078 0x00007ffff1d36b2a in gtk_main () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000079 0x00007ffff27e07d3 in Gtkmm2ext::UI::run(Receiver&) (this=0x62f00000e400, old_receiver=...) at ../libs/gtkmm2ext/gtk_ui.cc:305
0000080 0x0000555558be6869 in main(int, char**) (argc=5, argv=0x7fffffffcd58) at ../gtk2_ardour/main.cc:471
(0028171)
x42   
2023-10-09 19:07   
When using the GUI, the new session-dialog now has a "Default Time Domain" dropdown.
It seems that it is not correctly applied when skipping that dialog.
(0028172)
x42   
2023-10-09 19:16   
Should be fixed since 8.0-5-g1b0f248e68
Please test!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9072 [ardour] features feature have not tried 2022-11-06 07:44 2023-10-09 03:02
Reporter: ksawerytreningowski Platform:  
Assigned To: paul OS:  
Priority: immediate OS Version:  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi Velocity Lanes
Description: Non destrictive or destructive edition - Midi Velocity Lanes.
One or many velocity lanes for a midi region or track (versions)
Tags: Midi velocity lanes
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0028162)
paul   
2023-10-09 03:02   
implemented for version 8.0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8486 [ardour] features minor sometimes 2020-12-07 10:51 2023-10-09 03:02
Reporter: dgdgddgd Platform:  
Assigned To: paul OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.5  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: add event editor to piano roll
Description: hello guys
please add event editor to ardour piano roll for fast adjust midi volume not midi track audio out
thanks
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 2020-12-07-103807_1366x768_scrot.png (33,168 bytes) 2020-12-07 10:51
https://tracker.ardour.org/file_download.php?file_id=3874&type=bug
png
Notes
(0025290)
dgdgddgd   
2020-12-07 10:55   
edit : midi note volume
(0025298)
ksawerytreningowski   
2020-12-09 23:05   
we have to choices:

1. use what we have - lines colors in te notes what is a very good solution
drawing on or near notes
or additional editor

2. we can use clasical pianoroll editor known from many programs for example cubase
- new lane
(0028161)
paul   
2023-10-09 03:02   
implemented for version 8.0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9471 [ardour] bugs crash always 2023-10-07 10:59 2023-10-07 14:26
Reporter: krischan941 Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 8 nightly "crash"
Description: Hey there, currently playing around with new Ardour nightly and discovered a simple to trigger crash when you double click on a tempo marker. The Ardour opens a diaologue with something like "programming error: mouse grid clicks are handled by _canvas_grid_zone!"
Many thanks
Tags:
Steps To Reproduce: Double click a (also newly created) tempo marker
Additional Information: Ardour 8.0.rc3.39
Attached Files:
Notes
(0028155)
x42   
2023-10-07 14:26   
Fixed in 8.0-rc3-41-g5426bbfd57

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9470 [ardour] bugs crash always 2023-10-06 21:52 2023-10-06 23:37
Reporter: skygge Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Using "Grid mode" ("Y" shortcut) crashes Ardour
Description: Well... The new tempo edit tool (grid mode) crashes Ardour (current master).
Tags:
Steps To Reproduce: Open session,
Press Y or click "Grid mode" button,
Move the grid.
CRASH!
Additional Information: The same session file as the 0009464. You got the link.
System Description
Attached Files:
Notes
(0028154)
paul   
2023-10-06 23:37   
believed resolved by 26eed327adaa

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9465 [ardour] bugs major have not tried 2023-10-03 15:02 2023-10-06 19:32
Reporter: axra Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 8.0-rc3 can't find avldrums and calf lv2 plugins
Description: Though the plugins are listed in plugin manager (Status OK) Ardour cant't load them.
Seems Ardour scans wrong directory.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Bildschirmfoto zu 2023-10-03 15-43-01.png (208,526 bytes) 2023-10-03 15:02
https://tracker.ardour.org/file_download.php?file_id=4653&type=bug
png

Bildschirmfoto vom 2023-10-05 12-00-52.png (227,700 bytes) 2023-10-05 10:03
https://tracker.ardour.org/file_download.php?file_id=4655&type=bug
png

Screenshot_20231006_010235.png (24,955 bytes) 2023-10-05 23:04
https://tracker.ardour.org/file_download.php?file_id=4658&type=bug
png

ardour8.png (270,720 bytes) 2023-10-06 07:47
https://tracker.ardour.org/file_download.php?file_id=4659&type=bug
Notes
(0028137)
axra   
2023-10-04 08:38   
Still the same issue with Ardour-8.0.-rc3.9
(0028140)
axra   
2023-10-05 10:03   
not solved yet, Ardour 8.0.rc3.27
(0028142)
x42   
2023-10-05 19:09   
Is there any additional information on stdout/stderr?

Failed to instantiate is often casued by an arch mismatch (64 bit ardour, 32bit plugin) or missing symbols of dynamically linked plugins. If that is the case there might be some additional information from liblilv on stderr.

Where did you get Ardour from? Where the plugin(s)?

Nothing has changed on Ardour's LV2 side of things, and liblilv loads LV2 plugins, incl. avldrums, just fine with the official binary.
(0028145)
axra   
2023-10-05 21:57   
I just checked with latest Linux Mint Debian Edition Live Stick. avldrums and calf lv2 plugins loading there.
On the Ardour forum someone confirmed the same issue with calf plugins on open suse TW, but avldrums working.
I got ardour 8.0.rc3 from nightly.ardour.org and Calf (0.90.3.6) and avldrums (0.7.2-1) Plugins from Manjaro Package Manager.
Installed Ardour to /opt directory.
(All working in Ardour 7.5-1)
(0028146)
x42   
2023-10-05 22:27   
(Last edited: 2023-10-05 22:28)
When you start Ardour from a terminal "Ardour8 <press enter>" is any information printed to stdout/stderr when you load the plugins?
(0028148)
axra   
2023-10-05 23:04   
Here is the error message in terminal when loading the plugins:
(0028149)
x42   
2023-10-05 23:46   
OK that explains it. Your distro not only dynamically links plugins (they ought to be self-contained and not depend on external resources), but also uses an incompatible library version (which does no work with glib that Ardour comes with).

avldrums does not even depend on libinstapatch. That is very strange.
I suggest to file a bug with Arch Linux and meanwhile get the official binary which does not have this issue: https://x42-plugins.com/x42/x42-avldrums
(0028150)
axra   
2023-10-06 07:47   
When starting Ardour8 I also get:
(0028151)
axra   
2023-10-06 07:48   
Gtk-Message: 09:47:52.211: Failed to load module "canberra-gtk-module"
(0028152)
axra   
2023-10-06 07:54   
But avldrums and calf plugins loading in Ardour 7.5.
So maybe the issue is related to /opt install path of Ardour8?
(0028153)
x42   
2023-10-06 19:32   
The problem is that the plugins require a NEWER version of glib (which provides g_string_free_and_steal).
The official 7.5 binary does have the same version as 8.0. Perhaps you're using Ardour 7.5 from Arch, or have removed libglib from opt/Ardour-7.5/lib/ ?

I expect a distro version of Ardour (using distro libs) works, until Arch sorts out dynamic linking of plugins and instead links them statically.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9468 [ardour] bugs major always 2023-10-05 08:12 2023-10-05 22:42
Reporter: merryl0 Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ardour 8.0.rc3.9 wont install due to missing syntax
Description: I downloaded the latest nightly and tried to install but it stopped. I tried again and got the same result, heres the output from the installer

 AV Linux MX Edition
mel@mx:~/Downloads
$ sh Ardour-8.0.rc3.9-dbg-x86_64.run
Verifying archive integrity... 100% All good.
Uncompressing Ardour 100%

Welcome to the Ardour installer

Ardour will be installed for user mel in /opt

[sudo] password for mel:
Thu 5 Oct 09:07:11 BST 2023
Architecture is x86_64
Checking for required disk space
/tmp/selfgz4152/.stage2.run: 321: arithmetic expression: expecting primary: " + "
mel@mx:~/Downloads
$
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9467 [ardour] bugs minor always 2023-10-05 01:14 2023-10-05 22:42
Reporter: tseaver Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour-8.0.rc3.9-dbg-x86_64.run file contains empty '.size' file
Description: The `.Ardour_x86_64-8.0.rc3.9-dbg.size` file created in the temporary directory is empty, leading to an error message in the `.stage2.run` script:

```
Checking for required disk space
/.../.stage2.run: 321: arithmetic expression: expecting primary: " + "
```
Tags: 8.0.rc3.9 debug
Steps To Reproduce: From my download directory:

```
$ sh Ardour-8.0.rc3.9-dbg-x86_64.run --keep --target ../tmp/
Creating directory ../tmp/
Verifying archive integrity... 100% All good.
Uncompressing Ardour 100%

Welcome to the Ardour installer

Ardour will be installed for user tseaver in /opt

[sudo] password for tseaver:
Wed 04 Oct 2023 09:10:35 PM EDT
Architecture is x86_64
Checking for required disk space
/.../.stage2.run: 321: arithmetic expression: expecting primary: " + "
$ ls -laF ../tmp
total 580096
drwxr-xr-x 2 tseaver tseaver 4096 Oct 4 04:54 ./
drwxr-xr-x 33 tseaver tseaver 4096 Oct 4 20:55 ../
-rw-r--r-- 1 tseaver tseaver 0 Oct 4 04:54 .Ardour_x86_64-8.0.rc3.9-dbg.size
-rw-r--r-- 1 tseaver tseaver 593977344 Oct 4 04:54 Ardour_x86_64-8.0.rc3.9-dbg.tar
-rwxr-xr-x 1 tseaver tseaver 812 Oct 4 04:54 install.sh*
-rw-r--r-- 1 tseaver tseaver 975 Oct 4 04:54 README
-rwxr-xr-x 1 tseaver tseaver 20235 Oct 4 04:54 .stage2.run*

```
Additional Information:
System Description
Attached Files: Screenshot_2023-10-05_18-30-16.png (279,583 bytes) 2023-10-05 22:31
https://tracker.ardour.org/file_download.php?file_id=4657&type=bug
Notes
(0028139)
tseaver   
2023-10-05 01:14   
The corresponding non-debug build installs cleanly.
(0028141)
x42   
2023-10-05 14:51   
I was too late to try it with yesterday's build. Looks like it was a temporary issue (we had a disk-full).

Is this still an issue with today's Ardour-8.0.rc3.27-x86_64.run? That works here.
(0028147)
tseaver   
2023-10-05 22:31   
Thanks! I can report that the `Ardour-8.0.rc3.27-dbg-x86_64.run` version installs fine for me. Feel free to close the issue!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9463 [ardour] bugs trivial always 2023-09-30 20:59 2023-10-05 21:48
Reporter: skygge Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI clips are colored even if "Region color follows track color" is off.
Description: "Region color follows track color" option works only for audio clips. The MIDI clips have colors even if you switch this option off in Preferences (Appearance -> Editor).
To "uncolor" the MIDI clips you have to select and deselect them or switch to "Range mode" for example.
Tags:
Steps To Reproduce: Ucheck "Region color follows track color" in Preferences. Open a session with MIDI clips on a MIDI track. You can see that the MIDI regions still follow track color. If the session contains also audio tracks, you can notice that audio clips have no background color (which is correct). Change mode from Grab to Range - the MIDI clips become correctly rendered now.
Additional Information: Also applies to 8.0.rcX (current master).
System Description
Attached Files: fix_9463.diff (1,655 bytes) 2023-10-05 21:48
https://tracker.ardour.org/file_download.php?file_id=4656&type=bug
Notes
(0028144)
x42   
2023-10-05 21:48   
This requires show-name-highlight to be enabled (which is off by default).

Some tech details for devs..

Resolving this cleanly will take some refactoring. Right now the color is changed a few times already. There are 5 (!) calls to MidiRegionView::get_fill_color() for a single MIDI region at session load. The attached patch would add 4 more.

The problem at hand is that,

1. TAV's c'tor () sets high_enough_for_name =1 and height to 1px
2. MidiStreamView::create_region_view creates a MRV, which calls MidiRegionView::init
2a. MRV::initi calls RegionView::region_muted() which calls RV::region_renamed() -> TAVI:::set_name_text() -> TAVI::manage_name_highlight
2b. The region height is still 1px, so high_enough_for_name = 0
3. MidiRegionView::get_fill_color()
    (!UIConfiguration::instance().get_show_name_highlight() || high_enough_for_name) is false, and the region uses the track's color

Only after the RV is added later in MidiStreamView::add_region_view_internal by calling MidiStreamView::display_region the correct height is available
and high_enough_for_name is set to true again.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9461 [ardour] bugs minor always 2023-09-30 19:08 2023-10-05 19:13
Reporter: songo Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: feedback_alert_button: missing "_" preventing translation
Description: Another typo which prevented the string "Feedback" from being translated (unless lit).
Tags: feedback, gettext, translations
Steps To Reproduce: In the Editor window the „Feedback” alert buton isn't translated (unless lit) in any foreign language enabled version of Ardour.
Additional Information: The PR fixing this issue is here:
https://github.com/Ardour/ardour/pull/828
System Description
Attached Files:
Notes
(0028143)
x42   
2023-10-05 19:13   
Fixed in 8.0-rc3-33-ge9bde1c638 Thanks

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9466 [ardour] bugs minor always 2023-10-04 02:37 2023-10-04 13:18
Reporter: Schmitty2005 Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour RC3 Nightly Split MIDI regions wont COMBINE properly
Description: Using Ardour Nightly RC3

When I dragged a MIDI chord, I split it into 4 sections, deleted the last 3. I copied and pasted the first section to fill the measure. When I select all 4 sections and right click>selected regions>edit>combine, they dissappear. They do not play either.
Tags:
Steps To Reproduce: 1. New Session.
2. Drag Chord onto edit window
3. Cut Chord into 4 sections using ruler guide and 'S'
4. Remove last 3 sections
5. Copy and paste 1section 3 times to fill bar
6. Select all sections. right click>selected regions>edit>combine
7. MIDI disappears
Additional Information: Example session attached. Hit UNDO to see if needed.
System Description
Attached Files: Bug Report_2023-10-03_193504.ardour-session-archive (6,357 bytes) 2023-10-04 02:37
https://tracker.ardour.org/file_download.php?file_id=4654&type=bug
Notes
(0028138)
x42   
2023-10-04 13:18   
Thanks for this good bug report! Fixed in 8.0-rc3-12-gc7745ffd43

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9458 [ardour] bugs minor always 2023-09-26 01:45 2023-10-02 20:27
Reporter: dom2 Platform: GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Monitoring a tracks input causes loop while playing to unset
Description: This bug can be viewed by the following steps:

1. Create a new session
2. Add a new audio track
3. Turn on "Monitor input" for that audio track
4. Set a loop range
5. Start playing the session
6. Click on the loop button

I would expect that this would activate the loop range and start looping playback, but instead it flashes the loop range briefly and then continues without the loop.

This seems to be occurring when the butler thread handles a PostTransportStop multiple times on the loop triggering, resulting in the "loop_changing" flag being unset and then unsetting the loop. I have a patch that fixes it for me by moving the unsetting of the "loop_changing" flag latter into the processing, but I'm not familiar enough with the event/threading architecture to be sure this is a safe solution.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: loop_fix.patch (850 bytes) 2023-09-26 01:45
https://tracker.ardour.org/file_download.php?file_id=4648&type=bug
Notes
(0028122)
paul   
2023-09-28 23:44   
Excellent detective work! Thanks very much. Committed as 243f40e10daa
(0028131)
paul   
2023-10-02 20:15   
hey @dom2 ... let me know the name you'd like me to include in the contributors list.
(0028132)
dom2   
2023-10-02 20:27   
name is Dominik Martinez, also got the patch for 0009452 :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9464 [ardour] bugs major always 2023-10-01 23:07 2023-10-02 01:15
Reporter: skygge Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: v8.0-rc2 - Arranger - undo move section makes a mess
Description: According to discourse.ardour.org topic "New Arranger in Ardour 8 is awesome!":
Move section and then "undo" makes the session messed up.
Tags:
Steps To Reproduce: Session has 3 arrangement sections.
Step 1: Move second, accoustic section "Akustycznie" (Accoustic) to the last position.
Step 2: Make undo.
Additional Information: Link to the session sent to Robin via mail. Please don't make it public, it's for debugging purposes only. Thanks.
List of plugins used in this session:

CNT | TYPE | NAME
  1 * LV2 LSP Impulse Responses Stereo (by LSP LV2)
  1 * VST2 ToneLib-GFX (by ToneLib)
  1 * LV2 Dragonfly Hall Reverb (by Michael Willis and Rob vd Berg)
  7 * LV2 Calf Limiter (by Calf Studio Gear)
  3 * LV2 Dragonfly Plate Reverb (by Michael Willis)
  9 * LV2 x42-eq - Parametric Equalizer Mono (by Robin Gareus)
  2 * LV2 Calf Haas Stereo Enhancer (by Calf Studio Gear)
  1 * LV2 LSP Spectrum Analyzer x1 (by LSP LV2)
  2 * LV2 ZynAddSubFX (by ZynAddSubFX Team)
  2 * VST2 #TLimiter (by Tracktion)
  5 * LADSPA Barry's Satan Maximiser (by Steve Harris)
  1 * LV2 Calf Saturator (by Calf Studio Gear)
  1 * LV2 GxZita_rev1-Stereo (by Guitarix team)
  1 * LV2 Calf Vintage Delay (by Calf Studio Gear)
  1 * LV2 LSP Impulse Responses Mono (by LSP LV2)
  1 * VST3 MT-PowerDrumKit (by MANDA AUDIO)
  3 * VST2 #TEqualiser (by Tracktion)
  1 * VST2 Tonelib-BassDrive (by Tonelib)
  3 * LV2 Calf Compressor (by Calf Studio Gear)
  1 * LV2 LSP Compressor Mono (by LSP LV2)
  3 * Lua ACE Inline Spectrogram (by Ardour Community)
  1 * LV2 LSP Limiter Stereo (by LSP LV2)
  2 * LV2 Neural Amp Modeler (by Mike Oliphant)
  3 * Lua ACE Inline Scope (by Ardour Community)

I don't want to export this session to stems - this would be a drastic chage of the the environment.
It works exactly the same in safe mode with all plugins disabled.
System Description
Attached Files:
Notes
(0028129)
x42   
2023-10-01 23:33   
Thanks I got the session, and issue reproduced.
(0028130)
x42   
2023-10-02 01:15   
Fixed in Ardour 8.0-rc2-23-gdfd44c2ebf

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9459 [ardour] bugs minor always 2023-09-27 07:21 2023-09-30 03:48
Reporter: dspasic Platform: Apple Macintosh  
Assigned To: OS: Ventura  
Priority: normal OS Version: 13.4.2  
Status: new Product Version: Mixbus 9.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Routing metronome to audio track causes negative delay (only while using loopback audio drivers)
Description: Hi,
the idea is to use loopback audio drivers (blackhole or rogue amoeba loopback) to record from many DAWs to Mixbus
this works well (i suppose, i haven't tried challenging latency at that path, or - i'm not sure how ito approach at this point)

when i route metronome to any audio track (and disconnect from hardware output) and record to track - it always records with negative delay.

note: i do not have any hardware ins/outs except headphones plugged into laptop

Please let me know how i can further help debugging
Tags:
Steps To Reproduce: 1. Open ardour7/8/Mixbus32c9
2. Use any loopback driver (tested with blackhole and rogue amoeba loopback)
3. create audio track and route metronome to it (while disconnecting metronome from hardware output - to avoid 'no align' indicator)
4. record metronome to audio track
5. it is recorded with negative delay

and to confirm the difference: repeat all steps but choose external headphones as audio out this time.
6. now the metronome recording is perfect on the grid
Additional Information: ~/Library/Preferences/Ardour7/stdout.log
and
~/Library/Preferences/Ardour8/stdout.log
do not contain/indicate any timing/delay values



please check this topic for initial discussion:
https://discourse.ardour.org/t/negative-delay-when-using-audio-loopback-devices/109233/6
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9432 [ardour] bugs block always 2023-08-10 13:56 2023-09-30 03:46
Reporter: cauldron Platform: Apple Macintosh  
Assigned To: paul OS: MacOS  
Priority: high OS Version: 10.12 or later  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Eventide plugins AU/VST2 don't load and VST3 crashes Ardor
Description: Eventide plugins Physion-2.8.15-osx-installer.dmg and SplitEQ-1.0.18-osx-installer.dmg work with Reaper v6.81/macOS-arm64 on Mac mini M2 and iLok License Manager Version Number 5.8.1 GM (b4991, d40534ab) : AU, VST2 and VST3!

With Ardor 7.5.0 (arm64 and intel) the following problem occurs with Physion and SplitEQ Eventide plugins:
AU plugin:
[ERROR]: AudioUnit: Could not convert CAComponent to CAAudioUnit
VST2 plugin:
[ERROR]: ** ERROR ** VSTFX : /Library/Audio/Plug-Ins/VST/Eventide/Physion.vst could not be instantiated :(
VST3 plugin:
ARDOUR CRASH!


By disconnecting the iLok usb key and loading the AU or VST2 plugin the iLok authorization mask appears but inserting the iLok usb license the problem remains as indicated by the Ardor logs above.
Tags:
Steps To Reproduce: This is likely to be a problem with Eventide plugins that require an iLok license. All details indicated in the description
Additional Information:
System Description
Attached Files:
Notes
(0027976)
cauldron   
2023-08-13 11:58   
Experiencing the same issue with other Eventide plugins:
 Precision-Time-Align-3.8.2-osx-installer.dmg
 ShimmerVerb-1.0.15-osx-installer.dmg
 Blackhole-3.8.17-osx-installer.dmg

Note that the Newflanged Audio plugins distributed by Eventide do not exhibit this problem and work correctly:
 Newfangled-Elevate-Bundle-1.12.7-osx-installer.dmg
 Invigorate-1.2.6-osx-installer.dmg
(0027980)
cauldron   
2023-08-13 20:29   
The same Eventide plugins that don't work with Ardour_7.5.0 (amr64 AND x86_64) WORK with Ardour_6.9.0_Intel_x86_64 (with the same Mac Mini M2)!!!
It is evident that there is something wrong with Ardour 7.5.0 for Eventide plugins.
(0028121)
cauldron   
2023-09-27 22:08   
good news, Ardour 8.0rc1.30 (Intel and arm) work perfectly with AU/VST2/VST3 Eventide plugins
(0028124)
paul   
2023-09-30 03:46   
see final note from reporter.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9460 [ardour] bugs major always 2023-09-27 12:32 2023-09-27 14:47
Reporter: merryl0 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Recording playhead not moving - is session corrupted?
Description: The session was created in 7.5.xxx-dbg and worked well until today
Today I tried to record some midi into the session. On pressing record the track runs and plays existing content, but the playhead doesn't move at all. On stopping the record the clocks and playhead update and track shows recorded data.
Recording audio produces the same behaviour
Downloaded new nightly 8.0.1.30. Same issue with this session.
New sessions record properly and don't give this problem.
I have uploaded the session archive: https://mega.nz/folder/NQ1WFSIR#Txl9zD1e_Bb9dIDGba-svQ
Many thanks
Tags:
Steps To Reproduce: Open session linked above
try to record
Additional Information:
System Description
Attached Files:
Notes
(0028120)
merryl0   
2023-09-27 14:47   
The problem has now disappeared - very strange

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9445 [ardour] bugs major always 2023-09-14 15:59 2023-09-26 19:04
Reporter: dspasic Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: Mixbus 9.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: First note is skipped while feeding midi data to VSTi on audio track
Description: I noticed strange behaviour (bug?) when having following setup:

IDEA:
Midi track feeding midi data into VSTi on another audio track

SETUP:
1. Midi track sends midi data (recorded midi region) to VSTi on track 2
2. Audio track receives midi data for VSTi

THE ISSUE:
First midi note on the grid will be skipped if varispeed value is not +12 -12 or 0 in semitones
- shown in 2nd video

- I’ve tried turning on and off the lookahead - no improvement

Please take a look at videos:
https://www.youtube.com/watch?v=AUkxCfTCXVk (Renoise Redux)
https://www.youtube.com/watch?v=BcgkR28v57g (Modartt Pianoteq)


Let me know if i can help further. Thanks
Tags:
Steps To Reproduce: SETUP:

1. create Midi track which will send recorded midi data to VSTi on track 2 (midi region should have midi note at the very beginning of midi region)
2. create Audio track, add VSTi which will receive midi data from recorded midi region on track 1
3. Play content and try changing varispeed value in semitones and cents
4. First midi note on the grid will be skipped if varispeed value is not +12 -12 or 0 in semitones
Additional Information:
System Description
Attached Files: Ardour8 nightly project import crash.log (139,981 bytes) 2023-09-26 16:27
https://tracker.ardour.org/file_download.php?file_id=4649&type=bug
Ardour8 nightly project import v2 crash (140,171 bytes) 2023-09-26 16:27
https://tracker.ardour.org/file_download.php?file_id=4650&type=bug
debug first note.zip (454,934 bytes) 2023-09-26 16:27
https://tracker.ardour.org/file_download.php?file_id=4651&type=bug
debug first note_2023-09-26_195825.ardour-session-archive (39,179 bytes) 2023-09-26 18:01
https://tracker.ardour.org/file_download.php?file_id=4652&type=bug
Notes
(0028111)
paul   
2023-09-26 15:58   
Please try this in a nightly build of Ardour. I fixed two buglets that sound related to this.
(0028112)
dspasic   
2023-09-26 16:27   
Hi Paul,
thanks for the input, but unfortunately it is not fixed.
Please refer to this video i just made:
https://youtu.be/iYp5l7eAfxQ

offtopic crash:
also i've tried importing project dedicated to this issue from Mixbus32cv9 to Ardour8 - and it crashes every time.
here is the log (and the project file i'm trying to import:

Let me know how can i help further. Thanks!
(0028113)
dspasic   
2023-09-26 16:28   
forgot to mention that importing same project in Ardour7.5 works without issues (does not provoke a crash)
(0028114)
paul   
2023-09-26 17:53   
Sadly those crash reports contain nothing of any value at all.

BTW: Session > Archive inside of ardour produces a slightly-easier-to-use session archive.
(0028115)
paul   
2023-09-26 17:55   
I can load that session into current Ardour without issues on Linux, but I'm also missing many plugins used by the session.

I would recommend checking it in "safe" mode - there's a checkbox at the bottom of the session selection dialog
(0028116)
dspasic   
2023-09-26 18:01   
Here is the 'archive' version


session uses only pianoteq (the missing plugins thing is probabbly everything tied to internal Mixbus32c DSP)
(0028117)
x42   
2023-09-26 18:41   
It loads just fine here on with Ardour 8.0-rc1 (Linux and macOS) and with Mixbus 9.1.x

I do have missing plugins though.
(0028118)
dspasic   
2023-09-26 19:04   
it seems that the method of how you open the project causes crash:

the following works:
1. open ardour8(nightly)
2. open project - select
3. works

the following does not
1. right click on .ardour project - open with ardour8
2. crash

see here: https://youtu.be/KjA4jUmVb_4

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9451 [ardour] bugs minor always 2023-09-21 01:32 2023-09-25 13:53
Reporter: Schmitty2005 Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI velocity 'lollipops' are not drawn on initial track creation when dragging from MIDI CLIPS
Description: When dragging a MIDI clip from Ardour Beats or Chords and creating a new midi track by dragging clip to empty edit field, the velocity lollipops are not visible after selecting 'A'utomation and velocity.

When the clip is slightly moved, the velocity lollipops will reappear.

This was using the nightly build of Ardour-7.5.614-x86_64.run.

I was able to reproduce it with each new track created by dragging clip.
Tags: CLIPS, lollipops, Midi, velocity
Steps To Reproduce: 1. New session
2. Select MIDI Clip , beat or chord, or otherwise. I assume it would work with all MIDI that is dragged.
3. Drag clip onto empty EDIT field, not an existing track.
4. Open Automation / velocity for newly created track.
5. Note that there are no velocity lollipops.
6. slightly move MIDI clip and velocity appears.

It may have also had the same result (no lollipops) when dragging a clip to existing MIDI track that was empty. If the MIDI track was already populated (and lollipops shown) and a new clip was dragged, the lollipops may have been shown.
Additional Information:
System Description
Attached Files:
Notes
(0028110)
paul   
2023-09-25 00:46   
Should be fixed by commit 1f13b311fdfdcb

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9457 [ardour] bugs minor always 2023-09-24 01:01 2023-09-24 15:24
Reporter: joachim Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: confirmed Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI List Editor unexpected behaviour, can cause crash.
Description: When I started to learn Ardour, I simply used it as a "tape recorder" and effects processor for my guitar.
"Convalescence - Part 3" became the first track I made this way, and also my very first FOSS production.

Now I'm craving music production of a more structured nature, so I've started to learn MIDI editing with Ardour.
While exploring the functionality of Ardour, I discovered the MIDI List Editor.
So, I tried changing some note values and I discovered that the List Editor is not behaving right.
Tags: crash, Keyboard, MIDI List Editor, mousewheel
Steps To Reproduce: 1. Create a MIDI track (instrument optional)
2. Create a MIDI-region, about 8 bars long (you decide).
3. Draw a half note (1/2) at or near the beginning of the region.
5. Hit "G" (grab mode).
6. Right-click the region, go to MIDI - List Editor.
7. Left-click the text describing how long the note is.
8. Left-click a different note length from the list.
9. Try changing note values with the mouse wheel.

Expected behaviour, when changing note length (left-click in list):
All available note length in the list should affect the note length when clicked.

Actual behaviour, when changing note length (left-click in list):
Only "Half", "Quarter", and "Whole" affects the note length.

Expected behaviour, when changing note length (mouse wheel):
Mouse wheel should switch between note lengths in the list:

Actual behaviour, when changing length (mouse wheel):
Mouse wheel up, switching beyond a "Whole" note length gives numerical values.
Mouse wheel down, swithing to a note length shorter than "Quarter" gives a note length of "1" tick.

Expected behaviour, when changing note start (mouse wheel):
Mouse wheeling up/down over the note start value should move the note forwards and backwards in time.

Actual behaviour, when changing note start (mouse wheel):
Mouse wheeling up/down always moves the note forwards in time, regardless of scroll direction.
Additional Information: This behaviour is seen in rev 7.5-636-g0633254820, pulled from git a few hours ago.
 
There is no visual feedback on which column is selected when navigating with the Left/Right arrow keys. I tried a different color theme, but that turned out is not the issue.

Changing the note start values via keyboard entry does not have any effect.

Ardour can crash with an "Address boundary error" (as reported by fish, in my case [https://fishshell.com/]) when attempting to change values with the keyboard. If I discover a procedure to reproduce, I will add a comment to describe it.

The manual does not state anything about using the mouse wheel or changing note lengths from a drop down list.
https://manual.ardour.org/midi/midi-editing/midi-list-editor/
System Description
Attached Files: Screenshot_20230924_161941.png (22,035 bytes) 2023-09-24 15:03
https://tracker.ardour.org/file_download.php?file_id=4646&type=bug
png

Screenshot_20230924_162005.png (14,459 bytes) 2023-09-24 15:03
https://tracker.ardour.org/file_download.php?file_id=4647&type=bug
png
Notes
(0028105)
x42   
2023-09-24 12:32   
With 7.5-671-g32efd92360 most of these have been addressed
 * All entries in Note length dropdown work
 * Mouse wheel increments by 1 beat (fine -grained modifier1/64 beat). -- this is intentionally not using the dropdown
 * Mouse wheel on note-position now works in both directions
 * Note-position text edit is now disabled

Pressing "Insert" to create a new note on an empty region no longer crashes
(0028108)
joachim   
2023-09-24 15:03   
The Note Length dropdown in the List Editor is different from the Grid Mode dropdown (highlighted in Yellow)
The List Editor uses only words to describe note length while the Grid Mode dropdown uses fractions and words.

Could it be the an idea to make have the same entries, for consistency?
Perhaps the List Editor could include Triplets, Quintuplets and Septuplets (highlighted in Cyan), just like the Grid Mode dropdown does?

A bit curious why these are not the same. It feels like these functions does not reference the same code?

Consistency is the point of this comment. Other than that, I'm not sure.
(0028109)
x42   
2023-09-24 15:24   
The editor grid is not directly related to region or note length property.
I suppose for 1/4 notes and shorter we could use numerics. However using "Bar" for "whole" note duration seems wrong.

In any case it will have to wait until after Ardour 8.0 - There is currently a string-freeze with translations trickling in.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9450 [ardour] bugs minor N/A 2023-09-19 20:45 2023-09-24 14:08
Reporter: sixro Platform: Microsoft  
Assigned To: OS: Windows  
Priority: low OS Version: 10  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unable to "bounce with processing" just one region of a MIDI Track...
Description: Hi, I have a MIDI track (here a screenshot: https://imgur.com/a/YXSuWAW) and I am using the bounce option to create the audio of all the regions.
It worked perfectly with all the other regions in the same track, but it doesn’t work with the last region selected: with that region, when I press “bounce (with processing)”, the created wav has no audio inside.
I tried again with one of the previous region in the same track in order to understand if the app was stuck, but it worked perfectly.
I tried to move the region, but without success. That track had an automation, but the volume didn't go to 0 by the way, but I press “Clear” and indeed if I play that MIDI region, I can hear the sound perfectly.
Thanks
Tags: bouncing with processing, MIDI region
Steps To Reproduce: Actually I don't know how to reproduce.
I create just 2 sessions since I downloaded Ardour and this is the first time I see this situation.
Additional Information: Ardour 7.5 has been download by ardour.org from the "Ready-to-Run program" page.
System Description
Attached Files: Screenshot 2023-09-19 222701.png (47,759 bytes) 2023-09-19 20:45
https://tracker.ardour.org/file_download.php?file_id=4640&type=bug
png
Notes
(0028072)
paul   
2023-09-20 00:15   
Are you bouncing each region one-by-one?
(0028074)
sixro   
2023-09-20 06:53   
Yes
Is it better to combine and bounce just once?
Thanks
Regards
(0028079)
sixro   
2023-09-21 16:35   
Sorry just to add that in my opinion this issue is very low priority.
The reason is that I had just to create another region on the same MIDI track, copy&paste the notes from the other one and bouncing it with success.
So with this workaround, this is not really an impacting issue.
Regards
(0028107)
paul   
2023-09-24 14:08   
I cannot reproduce this behavior with the current nightly build.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9449 [ardour] bugs crash always 2023-09-19 02:34 2023-09-24 14:06
Reporter: NotGabe Platform: Redhat  
Assigned To: OS: Fedora Linux  
Priority: high OS Version: 38  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when loading Vital GUI
Description: When I try to open the Vital synthesizer GUI, Ardour crashes.
It happens with both the VST2 and VST3 versions of the plugin.
Tags: crash, GUI, instrument, Linux, plugin, vital, VST3
Steps To Reproduce: Open an Ardour project. It doesn't matter if it's a new or existing project.
Add a MIDI track with Vital as the instrument.
Double-click Vital on the left, or right-click > Edit.
Ardour should crash at that point.
Additional Information: Vital, in my case, is stored in ~/.vst3.
I'm on X11.
Other VST3 plugins load fine.
Ardour is installed from flathub.
I have attached the core_backtrace portion of the crash report from Fedora's Problem Reporting app.
Let me know if any other parts of it would be useful.
System Description
Attached Files: core_backtrace.txt (33,996 bytes) 2023-09-19 02:34
https://tracker.ardour.org/file_download.php?file_id=4639&type=bug
Notes
(0028070)
NotGabe   
2023-09-19 02:36   
Vital is version 1.5.5
(0028106)
paul   
2023-09-24 14:04   
(Last edited: 2023-09-24 14:06)
That is not actually a crash backtrace at all (not sure what Fedora is thinking there ..).

Please read https://ardour.org/debugging_ardour for info on how to get useful backtraces.

Also, we cannot provide support for distro-built versions of Ardour. I encourage you to test out the currently nightly build of Ardour at https://nightly.ardour.org/ (you can install it in parallel with your distro version, and there are free/demo versions available). See if it has the same issue, and if not, you know who to reach out to.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9435 [ardour] bugs crash always 2023-08-14 14:29 2023-09-24 14:01
Reporter: Emanuele Pigozzo Platform: Xubuntu  
Assigned To: paul OS: Ubuntu 22.04.3 LTS  
Priority: high OS Version: real time  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When I send a string for OSC ,Ardor 7.5 it crach Same thing with 6.9
Description: Xubuntu with real time kernel, jackd1, when send sting for OpenSaundControl Ardour crash.
Idem with 6.9
Tags: control surface, jack1, osc
Steps To Reproduce: Enable OSC and send control string
Additional Information: 5.15.0-79-lowlatency
System Description
Attached Files: error7_5_osc.txt (109,333 bytes) 2023-09-21 19:26
https://tracker.ardour.org/file_download.php?file_id=4642&type=bug
error7_5_639_osc.txt (148,472 bytes) 2023-09-22 13:16
https://tracker.ardour.org/file_download.php?file_id=4644&type=bug
Notes
(0027983)
Emanuele Pigozzo   
2023-08-20 10:41   
As in ardur.org/debugging_ardour, i create a core dump (1GB) bat with gdb i dont can produce the backtrace

core dump is

/var/lib/apport/coredump/core._usr_lib_ardour7_ardour-7_5_0~ds.1000.d0189266-cfee-4d07-8bc3-4eefa7732753.4195.344714.

with gdb , core-file /var/lib/apport/coredump/core._usr_lib_ardour7_ardour-7_5_0~ds.1000.d0189266-cfee-4d07-8bc3-4eefa7732753.4195.344714

and thread apply all bt .....how can i generate the file to send?
(0027991)
paul   
2023-08-22 17:34   
Not sure what the question is? Are you asking how to get the output from gdb into a file?
(0027992)
x42   
2023-08-22 17:59   
What control string do you send?

Can you try some simple ones? (oscsend some with the liblo-tools package on debian based distros)
oscsend osc.udp://localhost:3819 /transport_stop
oscsend osc.udp://localhost:3819 /access_action/Common/Save
(0027993)
Emanuele Pigozzo   
2023-08-24 22:00   
Good morning.
Thank you for the help you are giving me.
I did some tests.
Installed Ubuntu Studio Version 22.04.3 LTS Jammy Jellyfish.
UMC1820 external sound card (perfectly recognized and working).
Started Ardor 6.9 and created a small simple one track project.
Enabled OSC from settings.
Used
oscsend osc.udp://localhost:3819 /transport_stop
and
oscsend osc.udp://localhost:3819 /access_action/Common/Save.
Apparently it works.

Uploaded an important project,

(36 stereo tracks for 2 hours and 30 minutes duration.
Audio tracks only, no plugins and no midi)
 used many times, created with Ardor 5.10.
Regularly imported.
Everything works but the above commands

oscsend osc.udp://localhost:3819 /transport_stop

and

oscsend osc.udp://localhost:3819 /access_action/Common/Save

 lead to the crash of Ardor.


How can I get the output of gdb to a file?

Grazie.
(0027994)
x42   
2023-08-24 22:20   
Note that the OSC API changed between Ardour 5 and Ardour 6

Are you using 5.12 still?

As for getting a backtrace. The easiest is likely to get a debug version from https://nightly.ardour.org/ (demo is fine, can be installed in parallel to distro builds).
Then run `Ardour7 --gdb` and when Ardour crashes, on the gdb commandline run "thread apply all bt"
see also https://ardour.org/debugging_ardour
(0028002)
Emanuele Pigozzo   
2023-08-29 20:40   
... Still using 5.12 ...

I would like to upgrade to Ardour 6.x or Ardour 7.x if possible
especially to be able to use strings in OSC

/transport_stop
/transport_play
/markers markers
/next_marker
/prev_marker


It is important to be able to use (convert) existing projects made with Ardour 5.12 .

(We use Ardour for multi track audio and xjaneo in 6-10 pc for video, synced via jack1)
(0028003)
Emanuele Pigozzo   
2023-08-29 21:29   
Sorry for my bad english (i use google translate).
with a small project it doesn't crash.
With big project imported by Ardor 5.12 crashes.

62,8 GiB (67.432.156.693)
2.379 file, 11 sottocartelle

Next is running Ardor on gdb

pippo@pippo-lifebooke756:~$ ardour --gdb

GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/ardour6/ardour-6.9.0~ds0...
(No debugging symbols found in /usr/lib/ardour6/ardour-6.9.0~ds0)

(gdb) handle SIG32 noprint nostop
Signal Stop Print Pass to program Description
SIG32 No No Yes Real-time event 32

(gdb) run

Starting program: /usr/lib/ardour6/ardour-6.9.0~ds0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Ardour6.9.0~ds0 (compilato usando 6.9.0~ds0-1build1 e la versione di GCC 11.2.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 1048576 open files
Ardour: [INFO]: Caricamento del file di configurazione del sistema /etc/ardour6/system_config
Ardour: [INFO]: Caricamento del file di configurazione utente /home/pippo/.config/ardour6/config
[New Thread 0x7ffff03ff640 (LWP 3976)]
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
Ardour: [INFO]: Using AVX and FMA optimized routines
[New Thread 0x7fffefbfe640 (LWP 3977)]
[New Thread 0x7fffef3fd640 (LWP 3978)]
[New Thread 0x7fffeebfc640 (LWP 3979)]
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour6/plugin_metadata/plugin_tags
[New Thread 0x7fffee07b640 (LWP 3980)]
[Thread 0x7fffee07b640 (LWP 3980) exited]
[New Thread 0x7fffee07b640 (LWP 3981)]
[New Thread 0x7fffed38d640 (LWP 3982)]
[New Thread 0x7fffeca9a640 (LWP 3983)]
Ardour: [INFO]: Caricamento file di configurazione interfaccia predefinito /etc/ardour6/default_ui_config
Ardour: [INFO]: Caricamento file di configurazione interfaccia /home/pippo/.config/ardour6/ui_config
Ardour: [INFO]: Loading 452 MIDI patches from /usr/share/ardour6/patchfiles

.........

(ardour-6.9.0~ds0:3973): Gtk-WARNING **: 22:57:25.973: Unable to locate theme engine in module_path: "adwaita",

Thread 83 "Open Sound Cont" received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0x7fffcdffb640 (LWP 4068)]
0x00007fffed668b51 in ArdourSurface::OSC::_strip_select2(boost::shared_ptr<ARDOUR::Stripable>, ArdourSurface::OSC::OSCSurface*, void*) () from /usr/lib/ardour6/surfaces/libardour_osc.so
(gdb) thread apply all bt

Thread 99 (Thread 0x7fffa919f640 (LWP 4084) "WaveViewDrawing"):
Couldn't get registers: No such process.
(gdb)
(0028025)
paul   
2023-09-14 15:39   
We cannot respond to bugs reported for Ardour 6.9 at this time unless they are shown to occur with the nightly builds of Ardour 7.5 (soon to be Ardour 8.0)
(0028080)
Emanuele Pigozzo   
2023-09-21 19:26   
I'm sorry.
The error also appears identical with version 7.5

with "open sound control" enabled,
 transport started,
 and command "oscsend osc.udp://localhost:3819 /transport_stop"

.... Thread 34 "Open Sound Cont" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff87fff640 (LWP 39482)]
0x00007fffcb463608 in ArdourSurface::OSC::_strip_select2(std::shared_ptr<ARDOUR::Stripable>, ArdourSurface::OSC::OSCSurface*, void*) () from /opt/Ardour-7.5.0/lib/surfaces/libardour_osc.so
(gdb)

With a small project everything works fine but with a much larger project (originally built in Ardor 5.12) this error appears.

I apologize for my bad english (I use google translate).
I ask you to be patient with me and give me precise instructions on how to proceed to be of help
(0028082)
paul   
2023-09-21 19:47   
Please download a debug nightly build from https://nightly.ardour.org/

Repeat the process that gave you the gdb output above, and paste the output here. There will be more detail that we can use.
(0028089)
Emanuele Pigozzo   
2023-09-22 13:16   
....

4767 ../libs/surfaces/osc/osc.cc
Thread 34 "Open Sound Cont" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff999a0640 (LWP 8114)]
0x00007fffc59eff5a in ArdourSurface::OSC::_strip_select2 (this=0x55555d378750, s=std::shared_ptr<ARDOUR::Stripable> (empty) = {...}, sur=0x7fff7c05d5d0, addr=0x7fff7c05c680) at ../libs/surfaces/osc/osc.cc:4767
: No such file or directory.

(gdb) thread apply all bt

Hi
Here is what was requested. (I hope!)
the complete report in the attached file.

-- I don't understand the intervention of "adelinasmith97" in relation to the problem in question. --

Grazie da pigozzo emanuele
(0028090)
paul   
2023-09-22 13:29   
that's the correct info, thanks.

the note above yours was typical spam, nothing more.
(0028091)
x42   
2023-09-22 13:30   
This crash will go way by checking if Stripable is NULL.
I do however not understand the fallback logic "we got a null strip check that old strips are valid" that should prevent this in the first place

diff --git a/libs/surfaces/osc/osc.cc b/libs/surfaces/osc/osc.cc
index 824c4312aa..d4f23b4cb3 100644
--- a/libs/surfaces/osc/osc.cc
+++ b/libs/surfaces/osc/osc.cc
@@ -4760,6 +4760,9 @@ OSC::_strip_select2 (std::shared_ptr<Stripable> s, OSCSurface *sur, lo_address a
        if (s != old_sel) {
                sur->select = s;
        }
+       if (!s) {
+               return 0;
+       }
        bool sends;
        uint32_t nsends  = 0;
        do {
(0028092)
paul   
2023-09-22 13:32   
Does the session that crashes like this have a master bus?
(0028093)
Emanuele Pigozzo   
2023-09-22 14:13   
No, the section does not have any Master Bus
(0028094)
paul   
2023-09-22 14:20   
OK, I just pushed the fix for this. You'll need v8 or a nightly build (unless you self build Ardour).
(0028095)
Emanuele Pigozzo   
2023-09-22 14:30   
I added a Bus, and now it doesn't crash.
I'll have to test it more carefully.
(0028096)
Emanuele Pigozzo   
2023-09-22 14:54   
Thank you for your support and patience.

While waiting for version 8,
In the meantime (as an exercise) I will try to compile Ardor ... To find the source with the fix where should I look?

What problems can I encounter using the "nightly build"?
What numbering will the one have with the correction?
...but this is not the right place for this question!

Grazie!
(0028097)
Emanuele Pigozzo   
2023-09-22 14:56   
I suppose I should close by marking it as solved?
(0028098)
paul   
2023-09-22 15:14   
If you do close it, please mark it as "closed". We reserve "resolved" for developers indicating "I believe this is fixed".

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9446 [ardour] bugs major sometimes 2023-09-14 19:39 2023-09-24 01:29
Reporter: SadKo Platform: GNU  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Track plays as mono after import while it is stereo
Description: Seems that problem start to be reproducible after adding and removing many track.
I have some test project where the typical workflow is the following:
1. Import some audio files to new tracks.
2. Send the output of some imported track to the master bus.
3. Listen the result.
4. Remove just imported tracks.

After several repetitions, the imported track starts to sound mono and only after some time it 'opens' to stereo.

Here's the example of the behaviour:
https://youtu.be/nYV0rZuye3c

As you see on the video, the imported track sounds as mono (and meters confirm that).
But after a while, the track starts to sound stereo (as should be from the beginning).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0028039)
SadKo   
2023-09-14 20:08   
Here's the link to the session which allows me to reproduce the problem: https://drive.google.com/file/d/1tSEkRGRoYzXBPEaIpnJgVHajIQeIiAbx/view?usp=sharing

The files that I try to import on the video are placed into TEST_FILES subfolder.
(0028076)
rassiereSpammer   
2023-09-20 13:40   
If you want to flip to the back camera so you can use https://spacebarclicker.co
(0028103)
joachim   
2023-09-24 01:28   
Similar behaviour can be heard when toggling loop mode on/off.
(0028104)
joachim   
2023-09-24 01:29   
Try this with Robin's Stereo Phase Scope!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9442 [ardour] bugs major always 2023-09-11 22:36 2023-09-23 16:50
Reporter: L_Pro Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: scrolling horizontally makes the grid to dissapear
Description: When I open a session, I start srolling horizontally and the grid turns off and then on.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Captura desde 2023-09-11 19-34-20.png (196,122 bytes) 2023-09-11 22:36
https://tracker.ardour.org/file_download.php?file_id=4629&type=bug
png

Captura desde 2023-09-11 19-34-36.png (191,903 bytes) 2023-09-11 22:36
https://tracker.ardour.org/file_download.php?file_id=4630&type=bug
png

ardour_scroll_bug.mp4 (164,403 bytes) 2023-09-14 16:00
https://tracker.ardour.org/file_download.php?file_id=4631&type=bug
ardour_grid_bug_tst.zip (9,558 bytes) 2023-09-14 16:13
https://tracker.ardour.org/file_download.php?file_id=4632&type=bug
Bug_report_2023-09-16_213609.ardour-session-archive (4,252 bytes) 2023-09-17 01:05
https://tracker.ardour.org/file_download.php?file_id=4637&type=bug
bug_grid.mp4 (527,582 bytes) 2023-09-17 01:05
https://tracker.ardour.org/file_download.php?file_id=4638&type=bug
Notes
(0028012)
L_Pro   
2023-09-11 22:37   
I've also tried in Ubuntu 22.04 and the same thing happened
(0028013)
L_Pro   
2023-09-11 22:49   
I figured out that only happen when the grid is set to "Bar".
(0028015)
AndresMGA   
2023-09-12 18:09   
line 383 of editor_tempodisplay.cc

tmap->get_grid (grid, max (tmap->superclock_at (lower_beat), (superclock_t) 0), samples_to_superclock (rightmost, sr), 1);

last argument should be 0 instead of 1

that solves the issue
(0028016)
L_Pro   
2023-09-12 20:53   
Thank Andres... however I'm not sure how to implement this solution because it's my first bug report ever.
Should I close this issue?
(0028017)
AndresMGA   
2023-09-12 20:56   
no, don't close it please....

I am no expert, and i am not even sure that it is a proper solution.

Developers will sort it, i guess
(0028018)
L_Pro   
2023-09-12 21:10   
Excellent... so I'll wait and see.
(0028023)
paul   
2023-09-14 15:33   
Does this happen in nightly builds? I cannot reproduce it ...
(0028026)
AndresMGA   
2023-09-14 15:40   
7.5-532-gc625e13a6f

happens only when grid is set to Bar, as L_Pro said
(0028027)
paul   
2023-09-14 15:47   
not happening here with 7.5-55X and above.
(0028030)
L_Pro   
2023-09-14 15:50   
Exactly, in nightly builds. Sorry for not detail it before.
(0028031)
paul   
2023-09-14 15:52   
if you can still make it happen with the current nightlies, please create a minimal session that demonstrates this behavior and attach it here as a session archive.
(0028032)
AndresMGA   
2023-09-14 16:00   
yes, i just downloaded and installed 7.5.555 nightly build and it happens in my system too

(Ubuntu Studio 22.04)

attached a short screen record video
(0028034)
L_Pro   
2023-09-14 16:12   
Hi, I can't record a video right now but after upgrading to Ardour 7.5-552-g31f45a488a in windows 10, this behaviour happen when PLAYHEAD is selected in the grid menu.
(0028035)
AndresMGA   
2023-09-14 16:13   
here is an empty session, created on nightly build, that does the grid disappearing error
(0028037)
paul   
2023-09-14 18:19   
OK, the "playhead" option is not supposed to be present any more.

We are working on fixing this today.
(0028040)
skygge   
2023-09-14 22:27   
Still not fixed in 7.5.561: https://youtu.be/61XihQcwm_4
(0028049)
paul   
2023-09-15 17:43   
appreciate the feedback, but still need a simple/sample session to debug, since i am unable to reproduce this.
(0028050)
AndresMGA   
2023-09-15 17:58   
i sent a session yesterday.... on 7.5.555... that was doing it (see note 0028035)

but now I can't reproduce it anymore (on 7.5.561)

sorry, not sure if this note is too helpful
(0028063)
L_Pro   
2023-09-17 01:05   
Hello, I've just downloaded Ardour 7.5.579 "Neroli" (rev 7.5-579-gf11a5880af) for testing and unfortunately this bug isn't fixed except for me. I'm uploading a session archive but it's as simple as an empty session.
(0028064)
paul   
2023-09-17 01:15   
reproduced locally! thanks very much, i should be able to get this fixed now.
(0028065)
L_Pro   
2023-09-17 02:01   
No, no Paul... thank you and your team. I'm glad I can help with such a small contribution.
(0028067)
paul   
2023-09-18 03:24   
should be fixed by commit 75e12993c627
(0028071)
L_Pro   
2023-09-19 22:59   
Hi Paul. I've just downloaded Ardour 7.5.609 (rev 7.5-609-g6edbc21929) and tested it. As you said before, it's fixed.
Thank you very much for your terrific work on this and I really appreciate the support from AndresMGA and skygge.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9427 [ardour] other tweak always 2023-07-31 13:23 2023-09-23 12:34
Reporter: edrickblade Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: An Ardour7 shortcut to load it with Pipewire-ALSA support and connectable in pwqraph
Description: This is my grain of sand for the Ardour community.
Just put this .desktop file in .local/share/applications folder and it'll appear in your applications menu, in Ardour's Windows>Connections menu select ALSA and the connections will be PIPEWIRE-ALSA.
Tags:
Steps To Reproduce: Below is the .desktop file.
Additional Information:
System Description
Attached Files: ardour-pipewire-alsa.desktop.tar.gz (371 bytes) 2023-07-31 13:23
https://tracker.ardour.org/file_download.php?file_id=4611&type=bug
Notes
(0027928)
edrickblade   
2023-07-31 15:05   
It's a good tool for those users having the distortion on sound problem with Pipewire-Jack
(0027933)
x42   
2023-08-02 02:00   
Is there a pipewire bug report for the distortion issue with pipewire-jack?
(0027935)
edrickblade   
2023-08-02 12:06   
Yes Rob, but it was in Endevour OS and Majaro forums
(0027936)
edrickblade   
2023-08-02 12:30   
x42, here are the links about that bug, I think it could be a compatibility problem between Ardour and Pipewire-Jack, mainly the distorted audio in Ardour problem is with Pipewire in Arch Linux, not an Ardour bug, thats why I'm using this .desktop script to use Ardour with the Pipewire flexibility to work without sound issues, and shared it for those users willing to use Ardour with ALSA and Pipewire, is like the best of two worlds, LOL!

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2257
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3030
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2889
https://www.reddit.com/r/linuxaudio/comments/ztrjtr/tons_of_bugs_with_ardour_and_pipewire/
(0027937)
x42   
2023-08-02 13:23   
Thanks.

Reading these issue reports, if you are still having this problem with pipewire 0.3.76, you should not be using pipewire for pro-audio.

2889 is unrelated (a soundcard/driver issue), 2257 seems to be caused by pipewire syncing different soundcards, it would also be present when using pipewire's ALSA emulation.
The issue you describe, which is only present with pipewire-jack is likely 3030, which was fixed.
(0027938)
edrickblade   
2023-08-02 13:28   
Thanks x42 for that advice, by the way, this .desktop script solve my problem if later I have a problem with Pipewire-ALSA I'll take your advice.
(0028102)
x42   
2023-09-23 12:34   
It is not a solution, just a workaround.

In particular if you use MIDI, Ardour/ALSA <-> pipewire is significantly inferior to Ardour/JACK <-> pipewire

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9438 [ardour] bugs minor sometimes 2023-08-25 04:31 2023-09-23 12:21
Reporter: ergen Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: low OS Version: 10.12 or later  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: update ardour-build-tools/build-stack
Description: - change zlib source to github
- run curl without -k if it fails initially
- build harfbuzz before freetype to prevent undefined HB_SCRIPT_ADLAM/HB_SCRIPT_OSAGE error
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 0001-change-zlib-source-to-github-try-curl-without-k-buil.patch (4,111 bytes) 2023-08-25 04:31
https://tracker.ardour.org/file_download.php?file_id=4627&type=bug
Notes
(0027995)
x42   
2023-08-25 04:53   
can you elaborate on why you swapped harfbuzz and freetype?

Also did you mean
curl -L -o $1 $2 || curl -L -k -o $1 $2  


IIRC insecure was for old OSX builders, which did not have updated certs. So we can probably get rid of that, too.
(0028099)
ergen   
2023-09-22 20:01   
I was getting error 'undefined "HB_SCRIPT_ADLAM"/"HB_SCRIPT_OSAGE"' when building freetype. I believe the issue is that freetype is expecting those symbols, which are defined by harfbuzz, which in the original build script is built after freetype. When I built harfbuzz before freetype the error went away.

after I did this i read that freetype is not actually even used on macos https://ardour.org/current_dependencies.html -- if this is true should freetype just be removed from the build stack for macos? maybe harfbuzz too?

your suggestion regarding curl definitely seems better practice than mine, i was mainly just trying to introduce the least amount of change in behavior. i'll try building fresh without inseucre and update the patch accordingly.
(0028101)
x42   
2023-09-23 12:21   
I have applied the curl change. I'm still curious about the freetype issue. There is circular dependency: freetype can use harfbuzz and harfbuzz can use freetype. In our case this is a non-issue since freetype is not directly used and text rendering happens via pango/cairo -> harfbuzz -> freetype/CoreFont.

The build script runs regularly and on different systems for nightly and local builds on High Siearra (Intel), Mojave (Intel) , BigSur (Intel and M1) and Venuta (M2).

So it's curious that you ran into those issues, while it works otherwis

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9456 [ardour] bugs minor always 2023-09-23 10:18 2023-09-23 12:13
Reporter: songo Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: port_group.cc: missing "_" in "Tracks"
Description: There is a small typo in the port_group.cc preventing noun "Tracks" from being
translated in the routing grid.
Tags: gettext, ports, track, translations
Steps To Reproduce: Just open the "Routing grid" in any foreign language enabled version of Ardour and check if the "Tracks" noun is correctly translated.
Additional Information: You can find a patch fixing this issue in the attachment.
System Description
Attached Files: 0001-PortGroup-fix-missing-_-in-Tracks.patch (1,082 bytes) 2023-09-23 10:18
https://tracker.ardour.org/file_download.php?file_id=4645&type=bug
Notes
(0028100)
x42   
2023-09-23 12:12   
Applied in 7.5-662-g82d03607b8 Thanks!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9441 [ardour] bugs trivial always 2023-09-08 21:07 2023-09-22 02:04
Reporter: dspasic Platform: Mac  
Assigned To: paul OS: Ventura  
Priority: normal OS Version: 13.4.1  
Status: resolved Product Version: 7.5  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: grid 'Stretch MIDI' does not stretch midi content
Description: Hi, for demonstration i've recorded screen:
https://youtu.be/6_mSlO49ot8?si=Izf4SQgQ9w9RRm7J

let me know if i can help more or i did misunderstand the new feature. Thanks
Tags: grid
Steps To Reproduce: 1. open new session
2. create midi instrument (and midi content)
3. add grid markers
4. move them (with checkbox 'Stretch MIDI' enabled)
5. midi content (notes do not move/change - and there is visible change of midi clip duration)
Additional Information:
System Description
Attached Files:
Notes
(0028010)
dspasic   
2023-09-08 21:19   
Hi again,
here is visual bug (if new ticket is needed, i will create it)
1. when moving region, changes are not visible while dragging, but are visible when you let go of region (after moving it)
2. when doing slip edit - the changes are instantly visible
https://youtu.be/So08dmvlb3Y

can we have visual update when moving region (like slip edit does)?
Thanks!
(0028011)
BenLoftis   
2023-09-09 12:12   
I'm sorry, this button was only provided for prototyping/conceptual design. The underlying functionality does not yet exist.

I've removed the checkbox for now.

In the future, we will likely have checkboxes for 'move markers', 'move midi', 'move audio' or maybe 'move selected tracks', when the Grid Tool is engaged.

-Ben at Harrison
(0028014)
dspasic   
2023-09-12 06:55   
Hi Ben, thanks for clarification.
What about my note regarding visual aspect?
Thanks
(0028024)
paul   
2023-09-14 15:37   
There's significant confusion here.

The grid tool is currently used ONLY for an operation we call "tempo mapping", which adjusts the tempo map to fit a (probably) human performance.

It is absolutely intentional that existing material (MIDI or audio) does not move or respond to the changes: the purpose is to change ONLY the tempo map so that it fits the material.
(0028028)
dspasic   
2023-09-14 15:47   
Paul, if i understood correctly - grid tool will not change existing material position/lenght/etc to fit the newly drawn tempo markers?
and; is there a plan to support this, or this is already defined as 'no'?
Thanks
(0028029)
paul   
2023-09-14 15:49   
The grid tool, as i explained, is to make the *grid* fit the material. That is its only purpose.

Changing the grid to fit *some* material while then adjusting *other* material to follow the grid is something we might do in the future, but it is absolutely not the intended purpose of the grid tool.
(0028033)
dspasic   
2023-09-14 16:02   
Ok, it makes perfect sense. Thanks for clearing up completely
The problem was that i was having too many expectations (i assumed it will work like that due to the checkbox which i mentioned earlier in the issue).
(0028054)
paul   
2023-09-15 21:19   
see notes.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9452 [ardour] bugs crash always 2023-09-21 18:46 2023-09-21 22:56
Reporter: dom2 Platform: GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes after adding many midi notes to a small region
Description: Ardour crashes when adding a midi track and adding notes using the Draw Mode tool to first draw a midi region then adding notes. It seems that adding around 15 notes quickly in a smaller region causes the crash, although I have no specific measurement of the exact parameters causes it.
Tags:
Steps To Reproduce: - start new project
- add new midi track
- use the draw mode tool to add a small midi region (about a measure)
- use the draw mode tool to randomly add notes to the region

After around 15 midi note additions, it crashes.
Additional Information:
System Description
Attached Files: ardour_backtrace.txt (87,212 bytes) 2023-09-21 18:46
https://tracker.ardour.org/file_download.php?file_id=4641&type=bug
crash.patch (1,100 bytes) 2023-09-21 19:28
https://tracker.ardour.org/file_download.php?file_id=4643&type=bug
Notes
(0028081)
dom2   
2023-09-21 19:28   
This patch seems to fix it on my machine. I'm not a strong C++ developer nor am i very familiar with Ardour's codebase, so this was an intelligent guess based on the assumption that an insertion into the events' map would be invalidating the optimization iterator, resulting in the crash when incrementing the iterator. Someone else should confirm that this is a sensible assumption/change.
(0028083)
paul   
2023-09-21 22:17   
Excellent detective work. Any chance we can get a "real name" to add the contributor list?
(0028084)
dom2   
2023-09-21 22:45   
Sure, name is Dominik Martinez.
(0028085)
paul   
2023-09-21 22:55   
Thanks again. It will be in 8.0, to be released in a <single-digit number> of days, we hope.
(0028086)
paul   
2023-09-21 22:56   
fixed by reporter. yay!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9448 [ardour] bugs crash always 2023-09-16 17:25 2023-09-20 13:39
Reporter: ccaudle Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: crash when attempting to create new session
Description: I was attempting to create a session to duplicate a situation questioned in a forum post.
I used qjackctl to start jackd (1.9.22) on a Focusrite interface running at 192k sample rate, 1024/3 buffer size.
I started Ardour 7.5 (ardour.org build) and picked the project directory, selected the default recording template, picked JACK backend from the audio setup dialog, and clicked the OK.
The Ardour editor view was displayed, but then crashed before creating the session file. The project directory structure was created, but the initial session file was not saved.

I restarted from CLI and these messages were displayed after the usual messages about audio device or resource is busy while waiting for me to select jack backend:
BDB1539 Build signature doesn't match environment
Cannot open DB environment: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch
BDB1539 Build signature doesn't match environment
Cannot open DB environment: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch
BDB1539 Build signature doesn't match environment
BDB1539 Build signature doesn't match environment
BDB1539 Build signature doesn't match environment
Set cursor set to default
BDB1539 Build signature doesn't match environment
BDB1539 Build signature doesn't match environment
[...many repetitions...]
DB1539 Build signature doesn't match environment
BDB0594 database environment not yet opened
BDB1572 replication requires transaction support
BDB1539 Build signature doesn't match environment
Segmentation fault (core dumped)

Even though it prints "core dumped" I do not see a file with "core" in the name, so not sure if that message was accurate.
Tags:
Steps To Reproduce:
Additional Information: Will attempt to dupliate in gdb later, just wanted to get this information in while it was still fresh, in case the messages about build signature indicate something semi-obvious.
System Description
Attached Files: ardour_7.5_backtrace.txt (29,133 bytes) 2023-09-16 21:05
https://tracker.ardour.org/file_download.php?file_id=4636&type=bug
Notes
(0028059)
ccaudle   
2023-09-16 18:46   
did not crash when using the ALSA backend
(0028060)
ccaudle   
2023-09-16 18:53   
After starting with the ALSA backend and verifying that record and playback worked correctly, I stopped the audio backend, re-started jackd, and selected JACK as the audio backend. Ardour crashed again either while starting or just after starting the JACK backend.
(0028061)
ccaudle   
2023-09-16 21:05   
Attached backtrace from 7.5 (ardour.org build).
Will next attempt to get backtrace from recent non-stripped local build.
(0028062)
ccaudle   
2023-09-16 21:12   
My locally built ardour did not crash when using the JACK backend.

Ardour7.5.461 (built using 7.5-579-gf11a5880af and GCC version 13.2.1 20230728 (Red Hat 13.2.1-1))
(0028068)
paul   
2023-09-18 03:27   
THere were some changes last week to the JACK backend (specifically, serializing all JACK API calls that involve a round-trip to the JACK server) that may fix whatever issue you were having.
(0028069)
ccaudle   
2023-09-18 15:33   
Makes sense, I saw the commit messages about adding serialization locks to the JACK backend. Since I confirmed the problem does not exist in a recent git pull this can be marked as complete as far as I am concerned, I just wanted to get it documented before I forgot when I hit the problem on 7.5.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9340 [ardour] features minor have not tried 2023-05-20 03:58 2023-09-17 05:59
Reporter: garyd Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Store the Lua Binding Class Reference JSON files
Description: Here...
https://discourse.ardour.org/t/ardour-lua-api-code-completion-extension-for-vs-code/106862/2
...Robin is saying that two JSON files are generated which in turn are used to generate the Lua Binding Class Reference HTML page.

Would it be possible to store those JSON files in the repository somewhere? I can't find them so I'm guessing they're not currently held onto.

I did look into generating them myself, via Robin's link in that post, but it's beyond me. Even if I could figure it out it would be much quicker/easier to get the already-generated files.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027669)
x42   
2023-05-22 15:27   
> Would it be possible to store those JSON files in the repository somewhere?

i do not like to commit generated files in the git repo. Redundant information is best avoided.
Besides, those files would have to be updated with every commit that changes the API.
(0027672)
x42   
2023-05-22 23:30   
current files Ardour 7.4:
http://robin.linuxaudio.org/tmp/ardourapi.json.gz
http://robin.linuxaudio.org/tmp/luadoc.json.gz
(0028066)
garyd   
2023-09-17 05:59   
Okay no worries. Thanks anyway.

Sorry for the delayed response. I thought I had already replied.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9404 [ardour] bugs major have not tried 2023-06-28 00:40 2023-09-16 01:23
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Piano roll and midi bug in 7.5 official build
Description: Piano roll lines color doesn't match with key color
after adding new note previous note/s maintained selected
pay attention to screenshots
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: bug1.png (16,163 bytes) 2023-06-28 00:40
https://tracker.ardour.org/file_download.php?file_id=4583&type=bug
png

bug2.png (13,375 bytes) 2023-06-28 00:40
https://tracker.ardour.org/file_download.php?file_id=4584&type=bug
png

bug3.png (35,832 bytes) 2023-06-28 00:40
https://tracker.ardour.org/file_download.php?file_id=4585&type=bug
png
Notes
(0027948)
dking952012   
2023-08-07 20:32   
The same is true for automation points. When added, selection usually includes previously selected or added notes/points. Have to manually deselect.
(0028055)
paul   
2023-09-15 21:21   
Lines: this was fixed a month or two ago

Selection: this is deliberate. If you don't like it, press Escape at some point.
(0028057)
dking952012   
2023-09-16 01:23   
Thanks for the clarification! Could this be disabled in preferences in a future release? It makes working/scoring with midi in the DAW piano role pretty annoying, as I'd have to press escape between every midi note entered in order to correct any misplacement/resize intention.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9431 [ardour] bugs crash always 2023-08-09 12:03 2023-09-14 18:28
Reporter: chaybutler Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Windows 11 - Demo version crashes on start
Description: Just trying Ardour for the first time. Installed via Ardour-7.5.0-w64-Setup.exe. I cannot get it to open without crashing. I did attempt to remove and reinstall.

There are two events in the Event Viewer, an Application Error, and a Windows Error Report

############################################
Application Error:
Faulting application name: Ardour.exe, version: 0.0.0.0, time stamp: 0x649514c6
Faulting module name: msvcrt.dll, version: 7.0.22621.608, time stamp: 0xc4d8152c
Exception code: 0xc0000005
Fault offset: 0x0000000000061e80
Faulting process id: 0x0x4560
Faulting application start time: 0x0x1D9CAB77300C2E0
Faulting application path: C:\Program Files\Ardour7\bin\Ardour.exe
Faulting module path: C:\WINDOWS\System32\msvcrt.dll
Report Id: 556155c5-10ca-4673-a007-42dbb15da3f2
Faulting package full name:
Faulting package-relative application ID:


############################################
Windows Error Report:
Fault bucket 1367579723242479094, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: Ardour.exe
P2: 0.0.0.0
P3: 649514c6
P4: msvcrt.dll
P5: 7.0.22621.608
P6: c4d8152c
P7: c0000005
P8: 0000000000061e80
P9:
P10:

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.8c07c353-1ce6-45e2-a57c-43137899b61e.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.18fe9803-032a-4d51-81c7-13d9356258b3.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.37099769-128a-4c03-9b5a-9809527c9d43.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.5398bf97-91c0-45ab-9ad7-3a06df3c4de2.tmp.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.633bec34-438d-4734-ab58-e76066daec32.tmp.xml

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Ardour.exe_6d2cbff79f742ff6126a20422a77a52ecf12e36_16f7c005_764e003f-8a45-4127-b052-4cb1774e1f8e

Analysis symbol:
Rechecking for solution: 0
Report Id: 556155c5-10ca-4673-a007-42dbb15da3f2
Report Status: 268435456
Hashed bucket: c72c4b6b82b584a972fa9e8335e51df6
Cab Guid: 0
Tags:
Steps To Reproduce: Click on the Ardour7 Icon
Additional Information:
System Description Windows 11
Attached Files: ArdourEventLogs.evtx (69,632 bytes) 2023-08-09 12:03
https://tracker.ardour.org/file_download.php?file_id=4621&type=bug
Ardour-debug.log (16,159 bytes) 2023-08-09 20:58
https://tracker.ardour.org/file_download.php?file_id=4622&type=bug
Ardour-debug-2.log (18,170 bytes) 2023-08-09 21:19
https://tracker.ardour.org/file_download.php?file_id=4623&type=bug
Notes
(0027955)
x42   
2023-08-09 15:02   
(Last edited: 2023-08-09 15:03)
This is very mysterious.
Ardour is not compiled with MSVC and should not be using msvcrt.dll in the first place. The .evtx is not useful for that reason.

Perhaps some soundcard-driver causes this when Ardour probes for soundcards.

--

Would you mind trying to help investigate this issue?

First delete the Ardour preferences (if any), remove the folder %localappdata%\Ardour7\
Download and install a debug build from nightly.ardour.org ; and start <b<Ardour (GDB).

 - A command-terminal comes up -- don't panic :) Ardour starts normally
 - When Ardour crashes: Do not press the "Close application, ..report to Microsoft" button.
 - Go to the command window.
 - Type thread apply all bt and press "enter"
 - Type quit and press "enter"

In your user's home folder ("My Documents") there is now a file ardour-debug.log.

Hopefully that will tell us more about the issue.
(0027964)
chaybutler   
2023-08-09 20:58   
There is no window or anything to click on. Just a flicker of the mouse cursor and that's about it.

That notwithstanding, I followed the rest of your steps and the resulting log is attached.

Thanks for the assist!
(0027968)
x42   
2023-08-09 21:07   
Aha, some text formatting issue. It is entirely obvious, why or where..

Is the main language of your system not English? Does it help to create an (empty) file: %localappdata%\Ardour7\.translate

https://discourse.ardour.org/t/unable-to-run-on-windows-11/108698/4
(0027969)
chaybutler   
2023-08-09 21:19   
This machine has only ever had English installed as a language.
Nevertheless, I created the .translate file as prescribed, and it did not appear to make a difference.
New logs attached.
(0027982)
chaybutler   
2023-08-18 18:10   
Been a couple of weeks. Any new feedback or assistance would be appreciated
(0027984)
chaybutler   
2023-08-21 11:57   
Flying blind over here. Help would be great. Just trying to start the app. Anyone able to offer anything?

I thought to check the Windows event viewer. Found two logs, an info & an error:

---Info---
Fault bucket 1367579723242479094, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: Ardour.exe
P2: 0.0.0.0
P3: 649514c6
P4: msvcrt.dll
P5: 7.0.22621.608
P6: c4d8152c
P7: c0000005
P8: 0000000000061e80
P9:
P10:

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.9dd46b5a-d183-46ab-9ea3-f6bfee9ffdd9.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.40a6631e-b7e3-42e1-a735-e4c1df80d15d.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.71b6c9f1-02af-426a-bef1-679675da49da.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.60380ed7-f16c-4887-ab82-f92d09d43bc9.tmp.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.6e9bce16-545c-470b-abfb-8b00d231e784.tmp.xml

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Ardour.exe_6d2cbff79f742ff6126a20422a77a52ecf12e36_16f7c005_2d3404d0-0920-4d71-bf8c-b5720ce3b8a7

Analysis symbol:
Rechecking for solution: 0
Report Id: fd460870-3093-49f4-aa47-230980dcacbc
Report Status: 268435456
Hashed bucket: c72c4b6b82b584a972fa9e8335e51df6
Cab Guid: 0

---Error---
Faulting application name: Ardour.exe, version: 0.0.0.0, time stamp: 0x649514c6
Faulting module name: msvcrt.dll, version: 7.0.22621.608, time stamp: 0xc4d8152c
Exception code: 0xc0000005
Fault offset: 0x0000000000061e80
Faulting process id: 0x0x1084
Faulting application start time: 0x0x1D9D425DAB2D0AD
Faulting application path: C:\Program Files\Ardour7\bin\Ardour.exe
Faulting module path: C:\WINDOWS\System32\msvcrt.dll
Report Id: fd460870-3093-49f4-aa47-230980dcacbc
Faulting package full name:
Faulting package-relative application ID:
(0027985)
chaybutler   
2023-08-21 12:48   
I've run DISM & SFC, both of which claimed to make repairs. No improvement. Then I tried another reboot, which also did not help. Still cannot get Ardor to open at all. When you execute the EXE, the mouse flashes a few times, and then the above logs appear in the event viewer. That is it. No crash report or anything.
(0028038)
paul   
2023-09-14 18:28   
Some problems - the ones that only occur on a specific Windows system - are essentially impossible for us to diagnose or fix. It would be great to get a better understanding of why Ardour is crashing on your system, but I'm not sure that will be possible.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9439 [ardour] bugs minor always 2023-08-30 15:58 2023-09-14 18:15
Reporter: sk-os Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: FaderPort Classic - Transport LED not working
Description: The LED-Feedback in the transport area (play pause, loop, punch, etc) are not lighting up wenn they are active in ardour.
They do work regarding their function, only the led feedback indicator is missing. play should light up wenn pressed and a track is playing, but the track start playing, but the play button is not lighted.

the per-channel LEDs are working as expected
Tags:
Steps To Reproduce: press play, rewing, loop a.so.
Additional Information:
System Description
Attached Files:
Notes
(0028036)
paul   
2023-09-14 18:15   
fixed in commit 7a0d80b62a

Thanks for noticing and reporting this! We made some changes a while back to try to share more source code between different MIDI control surfaces, and this introduced some breakage for the faderport classic that wasn't fixed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9444 [ardour] features minor N/A 2023-09-14 15:34 2023-09-14 15:34
Reporter: wargreen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Import track / playlist from a session / snapshot
Description: In lot of situations, we need to import some tracks or playlist from a session / snapshot to another session / playlist.

It avoid to redo a work, edit or recording.
Import audio file or consolidated track can work but we can't edit it further.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9443 [ardour] bugs minor always 2023-09-14 11:01 2023-09-14 14:07
Reporter: DopplerNyquist Platform: GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Drawn and recorded MIDI regions have different transparency
Description: In previous versions Ardour usually increase the transparency of MIDI regions when we use the Draw or Edit modes, but now the recorded regions do not follow this behavior.

Youtube video showing the problem: https://www.youtube.com/watch?v=Y5xFXeyFMjg
(Using the nightly 7.5.555 version in this video, but the 7.5 also have this issue)
Tags:
Steps To Reproduce: Create a MIDI track.
Record the notes.
Use the Edit mode.
Additional Information:
System Description
Attached Files:
Notes
(0028020)
AndresMGA   
2023-09-14 13:02   
you could add

r->set_opaque(false);

in the first constructor of midi_region_view.cc (lines 134 to 142)

as it gets called both after recording and after drawing.

NOTE: I am not an Ardour developer.... and only recently started reading/learning Ardour's code hopping to be able to contribute in the future.... the proposed solution is only a suggestion
(0028022)
paul   
2023-09-14 14:07   
There's a Session option (Session > Properties) to control the opacity of drawn regions (we consider it distinct from recorded regions). If recording is using layered mode (opaque regions) setting this option to true will cause both "types" of regions to have the same visual (and acoustic) opacity.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9434 [ardour] bugs major always 2023-08-13 14:39 2023-09-14 13:49
Reporter: doojonio Platform: GNU  
Assigned To: paul OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Undo after creating new playlist destroys all plugins
Description: After creating new playlist, it is very dangerous to press undo, because it will destroy all your plugins on track/tracks.

If you create new playlist for all tracks, it will destroy all your plugins on session without a chance to restore
Tags: playlists, PLugins
Steps To Reproduce: - Record audio or midi
- Create new playlist on track
- Press "Undo" (Ctrl + Z by default)
- All plugins on the track have destroyed
Additional Information:
System Description
Attached Files:
Notes
(0027977)
doojonio   
2023-08-13 14:40   
It is not necessary to record audio. It is reproduces even on empty tracks
(0028021)
paul   
2023-09-14 13:49   
fixed by commit 73d559056e

thanks for noticing and reporting this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7182 [ardour] features minor have not tried 2016-12-19 17:41 2023-09-07 18:21
Reporter: cooltehno_bugs Platform: Linux  
Assigned To: paul OS: KXStudio  
Priority: normal OS Version: 14.04  
Status: acknowledged Product Version: 5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: To limit or switch off sound, when few MIDI notes are selected
Description:  Ardour has a useful possibility to sound selected MIDI notes. This mode can be activated here:

 Preferences>MIDI>MIDI Preferences>

"Sound MIDI notes as they are selected in the editor".

 This mode works fine with single notes, but when we select several notes - they sound together (volume level summary!). If, for example, we have about 20 notes in a region and press Ctrl+A (to select all of them) - it produces an impermissible level of sound.
 The proposal is:
-to make a level limitation for several notes sounding;
-or to switch off the sounding of the selected group of notes at all;
-or to sound the first note of the selected note group.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: bundle_selection_sound_overload.gif (466,147 bytes) 2022-10-31 20:04
https://tracker.ardour.org/file_download.php?file_id=4267&type=bug
Notes
(0019535)
cooltehno_bugs   
2017-03-20 05:17   
One extra thought:
-to sound the note which we pick during dragging the group.
(0026791)
cooltehno_bugs   
2022-10-31 20:04   
added gif example
(0027844)
x42   
2023-07-03 15:20   
This was addressed in Ardour 6.3 (August 2020)
    Special case MIDI note selection auditioning - 0008358
    
    This adds a few exceptions to the general preference
    "Sound MIDI notes as they are being selected in the editor".
    
    * Select all no longer plays _all_ notes.
    * Remain silent when selection is inverted or a range is selected
    * Play no sound when a saved selection is restored on session load.
(0027845)
x42   
2023-07-03 15:24   
A "level limitation for several notes sounding" would have to happen by the synth. unconditionally adding a Limiter is not an option either.
"or to sound the first note of the selected note group." This seems wrong when selecting chords.
(0028009)
paul   
2023-09-07 18:21   
I intend to put a 12 note limit in place. It might not be the 12 notes you intend, but that's life.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9440 [ardour] bugs minor always 2023-09-04 17:30 2023-09-04 17:42
Reporter: mario1313 Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI keyboard lines are misaligned
Description: It looks like the MIDI keyboard lines are misaligned.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: MIDI keyboard lines are misaligned.png (13,290 bytes) 2023-09-04 17:30
https://tracker.ardour.org/file_download.php?file_id=4628&type=bug
png
Notes
(0028008)
x42   
2023-09-04 17:42   
This should already be fixed since Ardour 7.5.186

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9349 [ardour] bugs major always 2023-05-23 17:40 2023-09-02 08:19
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: assigned Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: same session present two time in session setup recent section
Description: please note to screenshot
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 2023-05-23_20-38.png (37,455 bytes) 2023-05-23 17:40
https://tracker.ardour.org/file_download.php?file_id=4543&type=bug
png

recent (294 bytes) 2023-05-27 11:18
https://tracker.ardour.org/file_download.php?file_id=4544&type=bug
bug.png (155,596 bytes) 2023-05-28 16:03
https://tracker.ardour.org/file_download.php?file_id=4547&type=bug
png
Notes
(0027686)
x42   
2023-05-27 10:04   
Can you attach the file `~/.config/ardour7/recent` (or paste its content here)?
(0027688)
dsfdsf   
2023-05-27 11:18   
(0027691)
x42   
2023-05-28 01:02   
Looks like you do have this session twice on disk. "On love" and "on love" note the lower-case "o"
I assume both also have the snapshot "Darkium".

Have you manually copied the session (rather than use Menu > Session > Save as) ?
(0027692)
dsfdsf   
2023-05-28 16:03   
(0027703)
dsfdsf   
2023-06-04 06:52   
@42
notice that after create snapshot and rename main snapshot or change project name
this bug happened
(0028004)
kamilner   
2023-09-01 06:54   
I have been getting the same thing recently. In my case it seems to be because I'm storing my Ardour files on a separate, symlinked, mount point.

So, for instance (the below is a simplified version to keep the paths short):
My home folder is /home/keith
I also have a mount on /media/Production
I have soft-linked /media/Production to /home/keith/Production
My default folder for session management is set to /home/keith/Production/Ardour

I create a new Ardour session and save it as "Test". After editing it and saving it a few times, I notice there are two sessions for Test with the following paths:
/home/keith/Production/Ardour/Test
/media/Production/Ardour/Test

When I start Ardour, and open a session in /home/keith/Production/Ardour and save it, it always seem to revert the path name to /Production/Ardour

I'm going to try to set the default session path to /media/Production/Ardour and see what happens

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8973 [ardour] features tweak always 2022-09-27 10:17 2023-08-22 07:50
Reporter: johne53 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Inconsistent Snap options
Description: In Mixbus's Editor window, just above the rulers, there's a button saying 'Snap' and to the right of it there's another button offering the various Grid options. And the Edit menu (Edit->Snap & Grid) also contains a list of Grid options. For the most part, selecting an option in one menu will reflect the same option in the other.

Unfortunately though... the two menus offer different options so sometimes, selecting an option in one menu will leave the other menu showing no selection. Is that intentional or do the two menus need to be brought into sync?

Or maybe one of them isn't needed any more ?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026590)
johne53   
2022-09-29 11:56   
I found this early return in 'gtk2_ardour/editor.cc' which I thought might be causing the problem:-

bool
Editor::grid_type_is_musical(GridType gt) const
{
    switch (gt) {
    case GridTypeBeatDiv32:
    case GridTypeBeatDiv28:
    case GridTypeBeatDiv24:
    case GridTypeBeatDiv20:
    case GridTypeBeatDiv16:
    case GridTypeBeatDiv14:
    case GridTypeBeatDiv12:
    case GridTypeBeatDiv10:
    case GridTypeBeatDiv8:
    case GridTypeBeatDiv7:
    case GridTypeBeatDiv6:
    case GridTypeBeatDiv5:
    case GridTypeBeatDiv4:
    case GridTypeBeatDiv3:
    case GridTypeBeatDiv2:
    case GridTypeBeat:
    case GridTypeBar:
        return true; // <--- returns early !!!
    case GridTypeNone:
    case GridTypeTimecode:
    case GridTypeMinSec:
    case GridTypeCDFrame:
        return false;
    }
    return false;
}

However, I rebuilt with that line commented out but it didn't change anything. I've also discovered that this affects both Mixbus and Ardour but the bit I'm not sure about is whether it's intentional.
(0027987)
Krio   
2023-08-21 20:49   
I just checked this on Ardour 7.5.0 (Linux) and cannot reproduce.

I see the exact same entries in both:
1) the grid option button next to the snap button
2) the edit > snap&grid menu

Maybe somebody else fixed this in the meantime?
(0027989)
johne53   
2023-08-22 07:50   
Well it's nearly a year since I first reported this so maybe it was still a 'work-in-progress' back then? This morning I've tested again (in Mixbus) and yes, it does seem fixed now.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
88 [ardour] features feature N/A 2003-10-24 11:56 2023-08-22 06:40
Reporter: v2 Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Track rulers
Description: It would be a nice to have 'rulers' to provide visual division between "groups" of tracks.

Exmple:

 Main Vocals
 Doubled vocals
 ---- (ruler)
 Chorus I
 Chorus II
 ---- (ruler)
 Guitar I
 etc..

Just to be clear, I'm not talking about the groups as already defined and used in Ardour, but just logical groups that humans tend to categorize things by.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0000085)
taybin   
2003-10-24 19:48   
That would be neat, but I think this should be post-1.0.
(0027986)
Krio   
2023-08-21 20:43   
Twenty years later I guess we can say this one will not be done. At least one alternative solution is groups with specific colors.

Better close this ticket no?
(0027988)
v2   
2023-08-22 06:40   
Heh, definitely time to close this one!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9420 [ardour] bugs crash always 2023-07-21 12:03 2023-08-13 19:59
Reporter: merryl0 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashing for no apparent reason
Description: Running a session with 1 imported audio file, 2 mono audio tracks and 2 midi tracks (general midi synth)
Dragon reverb, Gx delay, Ace stereo routing, x42 eq
Ardour crashing when i try to edit in the edit window
Was crashing on v 7.5.127-dbg, still the same on 7.5.199-dbg
Tags:
Steps To Reproduce: New session
Import mp3 audio
record 2 tracks audio
record 2 tracks midi
add plugins
edit audio
Additional Information:
System Description
Attached Files: CRash210723.txt (62,688 bytes) 2023-07-21 12:03
https://tracker.ardour.org/file_download.php?file_id=4600&type=bug
Crash250723.txt (145,634 bytes) 2023-07-25 18:47
https://tracker.ardour.org/file_download.php?file_id=4605&type=bug
Crash260723.txt (146,163 bytes) 2023-07-26 13:47
https://tracker.ardour.org/file_download.php?file_id=4606&type=bug
NoTRecoveredLog260723.txt (2,637 bytes) 2023-07-26 13:47
https://tracker.ardour.org/file_download.php?file_id=4607&type=bug
crash060823.txt (91,817 bytes) 2023-08-06 18:25
https://tracker.ardour.org/file_download.php?file_id=4613&type=bug
crash070823.txt (183,238 bytes) 2023-08-07 08:00
https://tracker.ardour.org/file_download.php?file_id=4615&type=bug
crash070823-2.txt (183,203 bytes) 2023-08-07 14:49
https://tracker.ardour.org/file_download.php?file_id=4616&type=bug
Screenshot_2023-08-07_15-37-02.png (820,352 bytes) 2023-08-07 14:49
https://tracker.ardour.org/file_download.php?file_id=4617&type=bug
crash070823-3.txt (148,754 bytes) 2023-08-07 16:42
https://tracker.ardour.org/file_download.php?file_id=4618&type=bug
EIT2.ardour.zip (47,202 bytes) 2023-08-07 22:11
https://tracker.ardour.org/file_download.php?file_id=4619&type=bug
Crash75286.txt (162,484 bytes) 2023-08-08 19:48
https://tracker.ardour.org/file_download.php?file_id=4620&type=bug
crash130823.txt (147,023 bytes) 2023-08-13 19:56
https://tracker.ardour.org/file_download.php?file_id=4625&type=bug
Screenshot_2023-08-13_20-57-39.png (123,551 bytes) 2023-08-13 19:59
https://tracker.ardour.org/file_download.php?file_id=4626&type=bug
png
Notes
(0027901)
paul   
2023-07-21 14:29   
It would be useful to include the info from gdb about which thread crashed, though I'm 99% certain it would have said thread 0

The crash is happening when drawing waveforms. This is not a known bug at this point in time.
(0027902)
merryl0   
2023-07-21 18:21   
Many thanks for your quick help.
I must have missed part of the dbg log when copying, sorry for that
I've been having so much trouble with Ardour, crashing often and have given up on several sessions. As i said to Robin a few months back, I just want to get a stable system I can use when working with other people, particularly.
Have you got any advice you could offer?
Is ALSA good enough without jack, or could it be anything to do with graphics? I have a nvidia graphics card and I'm using the driver from mxlinux repository (AVL default).
(0027903)
paul   
2023-07-21 19:29   
ALSA is fine, and we recommend it for most users.

This has nothing (that we know of) to do with your video interface.

Please do report on whether the bug occurs in safe mode, as seablade asked about on the forums.
(0027905)
merryl0   
2023-07-22 15:08   
So far today, Ardour has not crashed in safe mode, or with plugins active, when using the edit window. I will send another report when a problem occurs
Many thanks
(0027913)
merryl0   
2023-07-25 18:47   
Today it crashed running from launcher, then in safe mode from launcher, 3rd time this log from gdb, Ardour in safe mode.
Actions:
Edited some audio regions (whilst stopped)
Crashed when playing
File attached, I think i got it all
(0027914)
paul   
2023-07-25 18:59   
That's actually an outright bug but it won't be solvable unless this is repeatable behavior. Is it?
(0027915)
darless   
2023-07-25 19:24   
From looking at the crash file this is in Thread 40, crashes on an assert in Range::subtract -> case: OverlapEnd.

AlsaMidiBuffer: it's too late for this event. 255 > 0
Dragging region(s) from 2 different track(s), max dist: 1
locate to 347586 took 20897 usecs for 18 tracks = 1161 per track
Dragging region(s) from 2 different track(s), max dist: 1
ardour-7.5.199: ../libs/temporal/range.cc:86: Temporal::RangeList Temporal::Range::subtract(Temporal::RangeList&) const: Assertion `j->start() < i->start()' failed.
--Type <RET> for more, q to quit, c to continue without paging--<RET>

Thread 40 "butler" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffef5ff700 (LWP 9890)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

----
The associated thread 40 backtrack

Thread 40 (Thread 0x7fffef5ff700 (LWP 9890) "butler"):
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
0000001 0x00007ffff364e537 in __GI_abort () at abort.c:79
#2 0x00007ffff364e40f in __assert_fail_base (fmt=0x7ffff37c5688 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff44a02b1 "j->start() < i->start()", file=0x7ffff44a0297 "../libs/temporal/range.cc", line=86, function=<optimized out>) at assert.c:92
#3 0x00007ffff365d662 in __GI___assert_fail (assertion=0x7ffff44a02b1 "j->start() < i->start()", file=0x7ffff44a0297 "../libs/temporal/range.cc", line=86, function=0x7ffff44a0320 <Temporal::Range::subtract(Temporal::RangeList&) const::__PRETTY_FUNCTION__> "Temporal::RangeList Temporal::Range::subtract(Temporal::RangeList&) const") at assert.c:101
0000004 0x00007ffff4465e18 in Temporal::Range::subtract (this=0x7fffef5fd6d0, sub=...) at ../libs/temporal/range.cc:86
0000005 0x00007ffff62785cf in ARDOUR::AudioPlaylist::read (this=0x55555a905030, buf=0x7fff737ff010, mixdown_buffer=0x7fff72ffe010, gain_buffer=0x7fff727fd010, start=..., cnt=..., chan_n=0) at ../libs/ardour/audio_playlist.cc:243
#6 0x00007ffff6369089 in ARDOUR::DiskReader::audio_read (this=0x55555db685e0, sum_buffer=0x7fff737ff010, mixdown_buffer=0x7fff72ffe010, gain_buffer=0x7fff727fd010, start=@0x7fffef5fde78: 5049795, cnt=262144, rci=0x55555af754c0, channel=0, reversed=false) at ../libs/ardour/disk_reader.cc:1042
#7 0x00007ffff636a253 in ARDOUR::DiskReader::refill_audio (this=0x55555db685e0, sum_buffer=0x7fff737ff010, mixdown_buffer=0x7fff72ffe010, gain_buffer=0x7fff727fd010, fill_level=0, reversed=false) at ../libs/ardour/disk_reader.cc:1300
0000008 0x00007ffff636962f in ARDOUR::DiskReader::refill (this=0x55555db685e0, sum_buffer=0x7fff737ff010, mixdown_buffer=0x7fff72ffe010, gain_buffer=0x7fff727fd010, fill_level=0, reversed=false) at ../libs/ardour/disk_reader.cc:1123
0000009 0x00007ffff636949d in ARDOUR::DiskReader::do_refill (this=0x55555db685e0) at ../libs/ardour/disk_reader.cc:1097
--Type <RET> for more, q to quit, c to continue without paging--
_reader.cc:1097
--Type <RET> for more, q to quit, c to continue without paging-- <RET>
0000010 0x00007ffff6926bac in ARDOUR::Track::do_refill (this=0x55555b325aa0) at ../libs/ardour/track.cc:540
0000011 0x00007ffff6329171 in ARDOUR::Butler::thread_work (this=0x555558dcc000) at ../libs/ardour/butler.cc:271
0000012 0x00007ffff63282e1 in ARDOUR::Butler::_thread_work (arg=0x555558dcc000) at ../libs/ardour/butler.cc:170
0000013 0x00007ffff2b30547 in fake_thread_start (arg=0x55555cf92000) at ../libs/pbd/pthread_utils.cc:101
0000014 0x00007ffff7f79ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#15 0x00007ffff3727a2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(0027916)
paul   
2023-07-25 19:32   
yes, i know how to read gdb backtraces ... :)
(0027917)
merryl0   
2023-07-25 20:40   
It happens on about half the sessions Paul. I think all the bad sessions have midi
(0027918)
merryl0   
2023-07-25 20:41   
I will keep posting
(0027919)
paul   
2023-07-25 20:52   
repeatable not across all sessions, but repeatable in a given session. is this the case?
(0027922)
merryl0   
2023-07-26 11:07   
Yes, would you like me to upload a crashing session? if yes where to?
Many thanks Paul
(0027923)
paul   
2023-07-26 12:44   
I can't do anything unless it's repeatable (lets say, more than 50% of the time). If it is, then yes, please upload it anywhere I can download it.
(0027924)
merryl0   
2023-07-26 13:47   
Ok. Today it crashed in safe mode a few seconds after pressing play for the first time. Second time I did it in dbg and the same thing happened. Ive attached the dbg file below [Crash260723.txt].
I restarted the computer and ran Ardour, loaded the same session but this time did not choose recover crash data and it ran ok. I repeated the process and save a couple of audio region edits. Still fine. The third time like this, its still ok. The red light for the log was flashing so Ive also saved that and attached it [NoTRecoveredLog260723.txt].
Its running ok with plugins enabled so far now
I'm uploading the project folder to mega and will send the link as soon as its complete (going slowly at the mo).
(0027925)
merryl0   
2023-07-26 14:06   
Heres the link to the project folder
https://mega.nz/folder/BQtTDYiB#t2Tc0JevM417cW8DkRfu_Q
(0027926)
paul   
2023-07-26 16:32   
That crash had an entirely different cause. This suggests memory corruption, which is often (though not always) caused by plugins.
(0027927)
merryl0   
2023-07-27 07:51   
Thanks Paul. Ardour was in safe mode when crashing, I thought this disabled the plugins.
Anyway, now after many years, I've found that not trying to recover the crash data seems to work and give me trouble free sessions.
(0027940)
merryl0   
2023-08-04 14:15   
Hi Paul
My latest update.
I was working on a session with 7 mono audio tracks, 3 GM synth and 1 AVL drum tracks, No fx plugins. Song is under 2 mins long.
It had been ok until today. I did a section copy, pressed play and after a few seconds it displayed the disk too slow msg, then crashed.
I had run memtester 2048 5 without any errors, so I don't think there's a hardware memory problem.
(0027941)
merryl0   
2023-08-06 18:25   
Crashing today when i edit audio regions, then on launch
dbg attached.
This sessions has only audio, 4xgmsynth and avl drums, no eq or fx
It seems that trouble starts once i use midi instruments, Ive done mixing sessions with just audio and plugins and not had problems. It could be coincidence but i sense a pattern
(0027942)
paul   
2023-08-06 18:39   
To make the debug output useful, you need type

   thread apply all bt

at the gdb) prompt and include the output

If this crash is repeateable, please attach the session as an archive if you can (along with a recipe for causing the crash)
(0027943)
merryl0   
2023-08-07 08:00   
This morning I renamed the config file
Started Ardour, new session started ok.
Opened previous troubled session (see previous post), crashed on loading
Ran debug in normal and safe mode
Crashed both times
Safe mode loads a blank edit Window
Cannot open session at all, this is a recurrent problem for me.
dbg below
Session folder: https://mega.nz/folder/gJkTXKxL#rEnKQmG8ZCxFbJkdwPkmtw
(0027945)
merryl0   
2023-08-07 14:49   
Hi Paul I typed thread apply all as you said but it doesn't seem to give much more output. Please see the dbg file
The crash occurs before the session actually loads (see screenshot below), so I cant provide an archive.
There's a link to a copy of the session in the post above
how to proceed?
(0027946)
paul   
2023-08-07 14:55   
When gdb says:

    --Type <RET> for more, q to quit, c to continue without paging--thread apply all bt

it means press the key on your computer keyboard labelled Return or Enter
(0027947)
merryl0   
2023-08-07 16:42   
Thanks Paul
I guess I took it too literally before!
Here's the dbg for the same project
Hope its more useful this time
(0027949)
paul   
2023-08-07 22:11   
Your session is failing to load because of a known (and already fixed) issue. You've been editing with the grid enabled, and this converted some audio regions position & length parameters into music time (instead of audio time).

I've attached a fixed version of EIT2.ardour which ought to load fine. It contains many other subtle changes, but nothing that should impact the session in any meaningful way.

In the current code base, we do not allow regions to have the "wrong" time domain used. Alas, avoiding this in 7.5 is a challenge for most users who ever enable a musical grid.
(0027950)
merryl0   
2023-08-08 05:47   
Many thanks for fixing the session.
Does this mean that I should turn off the grid before moving, trimming, copying etc. regions?
Or, is it that once I've ever used the grid in a session its too late to edit regions in those ways?
Will this continue in V7.6?
(0027952)
merryl0   
2023-08-08 15:57   
I downloaded and installed the latest nightly [.286}. Some tests on new sessions reveal the problem is still present when performing grid based editing on audio, though seemingly not on midi, eg I could quantize without causing a crash.
Would you be able to give any idea of how long until normal operation will be working again?
(0027953)
paul   
2023-08-08 16:11   
Please provide more details.
(0027954)
merryl0   
2023-08-08 19:48   
Process:
In gdb: Ardour>New session 1
create 2 midi tracks, draw notes then quantise. Copy regions
Create 2 audio tracks,
record audio
Strip silence
Snap to grid
Edit region lengths, move regions
No Problems
--------------------------------Tea break (computer set to never sleep etc)
New session2
Create midi track, draw notes, copy region
Create audio track and record
Strip silence
Snap to grid
Removing unwanted leftover slithers of regions whilst playing caused crash
gdb below
(0027970)
paul   
2023-08-11 00:01   
That's a related crash, but not quite the same thing.

I would really appreciate it if you could again attach a session that shows this behavior (the second case).
(0027974)
merryl0   
2023-08-11 16:44   
Certainly Paul, will do.
Do you want me to upload a project folder, or a session archive?
Many thanks
(0027975)
paul   
2023-08-11 22:10   
either will do.
(0027978)
merryl0   
2023-08-13 19:56   
todays crash:
project with
1 midi AVL drum track
4 audio tracks
recorded 3 audio tracks
strip silence from gvox anmd remove unwanted slithers ok
Strip silence from bv2, removing unwanted slithers {rec arm still enabled) crash
gdb below
project folder: https://mega.nz/folder/kNU0jT6T#3M2s-vALiSBH11hu8u_hVw
(0027979)
merryl0   
2023-08-13 19:59   
Screenshot shows edit window with log error light green for session above

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9433 [ardour] bugs crash N/A 2023-08-10 14:53 2023-08-10 14:53
Reporter: Daleweirod Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes / corrupted session
Description: Can't open session, Ardour crashes when drawing the GUI.
There are lots of plugins, it does run in safe mode (-d option)

This I get when running through --gdb

Thread 1 "ArdourGUI" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Backtrace attached
Tags:
Steps To Reproduce:
Additional Information: User-level linux enthusiast.
This is my first bug report ever, let me know if I did alright.
Is it possible to recover this session to the state before the crash?
System Description
Attached Files: ardour_sesscrash_bt.txt (64,534 bytes) 2023-08-10 14:53
https://tracker.ardour.org/file_download.php?file_id=4624&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9429 [ardour] features feature have not tried 2023-08-06 22:32 2023-08-09 21:06
Reporter: Corruptinator Platform: Any Platform  
Assigned To: OS: Any OS  
Priority: normal OS Version: Any Version  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Speaker Output Reposition in the 3D VBAP Panner Window
Description: Playing around with the 10 Channel 3D VBAP Panner, gave me the realization that there is more freedom to move the source of the sound anywhere within the panner limits, problem is that the speaker outputs are already hardcoded/anchored in their respective spots.

Is there any chance the 3D VBAP Panner can be enhanced to allow speakers to be moved anywhere within the 3D Panner for purposes of custom surround sound setups for any sound system (A.K.A Dolby Atmos/ 9.1.4/ DTS)
Tags: 3D VBAP, panner, Speaker, Surround
Steps To Reproduce: Change speaker output to 10 Channels. Allows 3D VBAP Panner setup. Sound output will be hardcoded in place and cannot be changed/repositioned.
Additional Information:
Attached Files: image.png (35,902 bytes) 2023-08-06 22:32
https://tracker.ardour.org/file_download.php?file_id=4614&type=bug
png
Notes
(0027944)
wargreen   
2023-08-07 14:26   
Maybe related, or idea :
Allow custom panners by map strip panner to "standardized" plugin controls.

Eg : I have a custom panner in my strip, i can say to the strip "the panner is this plugin", and the L/R or XYZ Width controls are sent to the plugin.

Ambisonic everywhere ! ;)
(0027962)
x42   
2023-08-09 19:51   
@wargreen that has been the initial idea. Panners in ardour are plugins (dynamically loaded shared libs: https://github.com/Ardour/ardour/tree/master/libs/panners).
Ardour offers five controls available for each panner:

  * Azimuth
  * Elevation
  * Width
  * Front/Back
  * LFE

This would allow for N.m, and also ambisonics.
However so far nobody volunteered to add more panner plugins beyond the basic ones. VBAP is also only half baked (automation is not implemented).
For ambionics however, you can simply use a LV2 or VST3 plugin instead ...
(0027963)
x42   
2023-08-09 20:53   
PS. There is another proposal to only use meta-data for panning, until the signal reaches the graph boundary. This would be required for Atmos.

So far Ardour directly pans the audio signal on each track. This allows to have direct outs, and use JACK for connections.
The alternative would be that the audio output of each track remains unpanned and the pan-information is sent along with it until the final stage where summing and panning happens.
(0027965)
wargreen   
2023-08-09 20:59   
I do use a lv2 for ambisonic :)
But it would be wonderful to use the ardour's UI / OSC control for spat. I've made this lv2 from my faust code but C is really out of my knowledge.
is it imaginable to get a kind of panner "load plugin" ?
(0027966)
Corruptinator   
2023-08-09 21:01   
Interesting...
(0027967)
Corruptinator   
2023-08-09 21:06   
What if Ardour has an option to replace the Default Panner in the mixer with an External Panner Plugin that works across the entire project for multiple audio tracks?

Say you can implement an industry standard panner (Whether its LV2, VST2, or VST3) as an alternative to the default with the features to add multiple speaker outputs and position them and link them through Ardour's Input/Output nodes?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9285 [ardour] bugs minor always 2023-03-21 17:41 2023-08-09 17:00
Reporter: enorrmann Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ubuntu 23.04 Cue view causes ibus daemon to use 100% cpu and system turns unresponsive
Description: Upgrading to Ubuntu 23.04 the version of ardour shipped with ubuntu is 7.3, if I go to cue view and add some clips and start them, ibus service goes to more than 100% cpu usage and the system becomes unresponsive. Closing ardour, ibus goes back to normal.
This happens with ardour shipped with ubuntu 23.04 AND compiling from 7.3 source on ubuntu 23.04
Binaries downloaded from ardour.org doesn't have this issue
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027486)
paul   
2023-03-21 18:07   
Sorry, if this does not occur with our binaries, then it's not a problem we can (or will) investigate. You would need to take it up with the Ubuntu packager(s).
(0027956)
lminiero   
2023-08-09 16:30   
Just thought I'd add it doesn't only happen on Ubuntu. It started happening to me on Fedora 37 as well, and I can confirm it's still happening on Fedora 38 (updated today) with Ardour 7.5.0 and IBus 1.5.28. My experience seems to be a bit different, though, as closing Ardour doesn't seem to bring IBus back to normal, or at least not right away (it takes a bit). Besides, the system doesn't become entirely unresponsive: only keyboard input where you can type stuff is, and after a long time input seems to work again, but incredibly sluggish (I'm typing right now with this effect).

When I check with top (if I opened it before Ardour, otherwise I won't be able to type top in the terminal) I can see both Ardour and ibus-data taking a huge amount of CPU (0000087:0000160 and 0000102:0000120 respectively). Not sure if there's any other info I can provide, or even if this existing post is the right place to provide it.

Besides, not sure if the fault lies in Ardour, ibus, or pipewire, since it may be related to the number of connections that Ardour creates (and I have many in my templates).
(0027957)
lminiero   
2023-08-09 16:31   
Sorry, the amount of CPU seems to have been turned into some Mantis specific code... I meant about 160 and 120 percent respectively.
(0027958)
paul   
2023-08-09 16:33   
about 99.875% certain that this has nothing directly to do with Ardour, but is the fault of ibus and/or pipewire.

you can check this by running ardour with the ALSA audio/MIDI backend as a test, and see if the same thing happens. i'd wager that it does not.
(0027959)
lminiero   
2023-08-09 16:52   
I tried configuring Ardour to use ALSA in the Audio/MIDI setup window, and it looks like it still does it. Maybe less sluggish on the input, but the high CPU on both processes is still there.
(0027960)
paul   
2023-08-09 16:56   
ibus should play zero role if Ardour is using ALSA directly. So something is still wrong, but outside Ardour.

I have no idea who you can ask about this, but it's not something we're likely to investigate. If someone can provide any evidence that we're doing something wrong, we'll fix it, but I really do not believe this is the case,
(0027961)
lminiero   
2023-08-09 17:00   
Thanks for the clarification and the prompt replies!
Just FYI, I see there's a bug open on the ibus repo (which has a link to this issue too) but no activity unfortunately: https://github.com/ibus/ibus/issues/2492
Hopefully someone will give it a look sooner or later.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9430 [ardour] features feature have not tried 2023-08-06 22:42 2023-08-06 22:45
Reporter: Corruptinator Platform: Any Platform  
Assigned To: OS: Any OS  
Priority: normal OS Version: Any Version  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Adding 10+ more channels in the 3D VBAP audio Panner for Custom Surround Sound Setup
Description: This is sort of related to the other feature request post here: https://tracker.ardour.org/view.php?id=9429 (009429)

Having read through the Ardour Manual that 10 channel setup is the only setup that utilizes the experimental 3D VBAP panner setup. I was wondering if it would be possible to allow more speaker outputs to be added in the 3D panner space which can also synergize with the feature request link above to allow speaker outputs to be placed anywhere in the panner surround space?
Tags: 3D VBAP, Feature
Steps To Reproduce: Set channel output on "Master" to 10, will show the 3D VBAP panner setup, add more than 10 will revert it to the normal VBAP panner rotation pan.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9421 [ardour] bugs minor always 2023-07-21 22:55 2023-08-01 20:22
Reporter: Schmitty2005 Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Virtual Keyboard F4-F8 Velocity problem. Going 96 to 128 doesnt work!
Description: When using the Virtual MIDI keyboard and the new feature of using the F-key to change velocity, all of them work except going from 96 velocity to 127.

Tags: f-key, Keyboard, MIID, velocity, Virtual MIDI Keyboard
Steps To Reproduce: Open a new session, add a MIDI track, add MIDI Monitor LUA plugin. Use F4 to F8 for velocity changes, and play some notes. The velocity will change EXCEPT from 96 up to 127! 32 to 127 works, 64 to 127 works, but 96 to 128 does not work as can be seen in the MIDI Monitor plug in.
Additional Information:
System Description
Attached Files:
Notes
(0027909)
Schmitty2005   
2023-07-24 03:31   
Also affects Linux Ardour 7.5 release
(0027920)
darless   
2023-07-25 21:24   
Confirmed the issue on my setup. Although the manual states it's F5-F8. F5 (32), F6 (64), F7 (96), F8 (127). I'll push up a PR for it in github. It's a simple fix. The F7 is tied to 96, but 96 is not one of the options from the drop down which affects the ArdourDropdown::set_active code.
(0027921)
darless   
2023-07-25 21:32   
PR: https://github.com/Ardour/ardour/pull/811
(0027931)
x42   
2023-08-01 20:22   
This was somewhat intentional. You can use the scroll-wheel to get any velocity.

I have merged the PR anyway.
(0027932)
x42   
2023-08-01 20:22   
Resolved in Ardour 7.5-243

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9426 [ardour] features minor have not tried 2023-07-29 20:54 2023-07-29 20:54
Reporter: sollapse Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add an external Window option to plugin GUI.
Description: It would be useful to allow Ardour the option to host plugin GUI as an external process to allow native OS scaling on HiDPI displays. This is for plugins which do not take HiDPI into affect, or allow manual scaling.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9425 [ardour] bugs minor always 2023-07-29 20:51 2023-07-29 20:51
Reporter: sollapse Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Fit content periodically squashes notes to bottom of region.
Description: On some occasions, using the fit content option on MIDI regions to zoom in all the used notes squashes them to the lower part of the region.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files: Screenshot (1).png (31,683 bytes) 2023-07-29 20:51
https://tracker.ardour.org/file_download.php?file_id=4610&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9424 [ardour] bugs major always 2023-07-28 22:37 2023-07-28 22:37
Reporter: merryl0 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Disk too slow error message
Description: I keep getting the disk too slow error message on fairly basic sessions e.g
3 midi instruments
5 mono audio tracks
a few plugins

Changing the buffer size doesn't seem to help

I've attached a screenshot, and the hardware report for my computer.
below is a link to the xsession-errors file
Can you tell me is the disk (SanDisk SD6SB2M5 SSD) really too slow for this kind of work?
Many thanks
Tags:
Steps To Reproduce: Create new session with eg
3 midi instruments
5 audio tracks
12 plugins
Additional Information: xsession-errors link:
https://mega.nz/file/BJdz0YIC#P0_UrkNDxR8j6Z4ygGEFLp2reuP8G6yQWnTDOqmcdyA
System Description
Attached Files: SlowDisksession280723.png (760,465 bytes) 2023-07-28 22:37
https://tracker.ardour.org/file_download.php?file_id=4608&type=bug
hardinfo_report.txt (12,404 bytes) 2023-07-28 22:37
https://tracker.ardour.org/file_download.php?file_id=4609&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8857 [ardour] bugs minor always 2022-01-11 09:02 2023-07-26 12:42
Reporter: wmbm Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Gridlines not visible for 1/16 or smaller without snap on
Description: Unsure whether this is a bug or a feature, but I have noticed that the gridlines are not visible for 1/16 note or smaller (1/32, etc.)

If I am doing some sort of manual timing correction of live recordings this can be somewhat time consuming to go back and forth between snap on / snap off to view the gridlines and then turn them off to be able to adjust the live recording accordingly.
Tags:
Steps To Reproduce: Set gridline mode to 1/16 [or 1/32] without snap on
Additional Information:
System Description
Attached Files:
Notes
(0027884)
Krio   
2023-07-10 07:54   
I have the same issue. Without snap mode activated, setting grid mode to 1/16 note or smaller (1/32, etc.) will not show the vertical grid lines of this granularity. However it's useful to use this granularity if you don't want to snap, but still have visual indication of (sub)beats inside the bar.

Workaround is to:
- first activate snap mode
- then select the 1/16 or smaller gride mode
- then deactivate the snap again
- after some activity these gride lines disappear again (for example after zooming out and in again).

So you need to repeat the workaround all the time, which is quite annoying.
(0027904)
darless   
2023-07-21 21:05   
Created a PR for this: https://github.com/Ardour/ardour/pull/809

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9423 [ardour] features feature N/A 2023-07-25 14:12 2023-07-25 14:12
Reporter: emanuele.454 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIT Licensed Neural Amp Modeler Plugin should be built-in
Description: https://github.com/sdatkinson/NeuralAmpModelerPlugin

Would be useful to build this into Ardour as a custom device and modify it
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9418 [ardour] bugs minor have not tried 2023-07-20 13:15 2023-07-25 12:09
Reporter: sollapse Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST3 - Plugins open as stereo on mono tracks
Description: Starting around Ardour 7.5.198, all VST3 plugins that have mono modes open as stereo on mono tracks. This includes both Pro-Q and any other plugin which operates in this manner.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Waves VST3 on Vox Bus.png (443,902 bytes) 2023-07-25 12:09
https://tracker.ardour.org/file_download.php?file_id=4604&type=bug
Notes
(0027912)
troathscream666   
2023-07-25 12:09   
Hi, using AVlinux MX, latest version.
Maybe connected to this ticket, but trouble with VST3 on stereo tracks/busses
SInce upgrading to Mixbus 9 and Ardour 7 using Waves VST3 stereo plugins on stereo tracks, busses or the Mixbusses only lets through one channel of audio, the Right channel is the correct volume the Left channel is very low in Volume, almost inaudible.
The pinconnections are correctly configured, all of the waves VST3 plugins have this issue.
Other vendors VST3, the few i tried and are not Waves, behave correctly.
I don't have this issue with the latest version of Mixbus 8 and the same waves VST3 plugins.
The VST2 plugins don't show this behavior, and work as expected,
Disabling the plugin, has no effect. I have to remove the plugin to get both channel up again.
I use the latest Yabridge release and Wine TKG staging
Here a picture of Rvox inserted on the highlighted Vox Bus, as you can see, in the plugin it lets you see both channels reacting but after the plugin @the channel VU-meter you can only see the right channel getting signal.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9334 [ardour] features feature always 2023-05-14 07:24 2023-07-24 15:20
Reporter: dsfdsf Platform:  
Assigned To: OS:  
Priority: immediate OS Version:  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: feature for clip browser
Description: add search bar to clip browser / searchable clip browser

browse clips with keys up down right left
[ up / down ] go to previous and next clip - sample
[ right / left ]go to next dirctory and come back to previous

at the moment up / down / right / left control daw functions when mouse placed in clip area of editor list
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027652)
al f   
2023-05-14 07:56   
+1
(0027656)
al f   
2023-05-16 12:47   
Related to this is that when renaming sounds in the Sources list, navigation is still active in the editor.

So if you try to CTRL-V something from the clipboard, expecting your copied piece of text to be pasted, what actually happens is that any audio in Ardour's clipboard is pasted at the current edit point (CTRL-C of course copies at edit point).

This behaviour is so annoying I'd say this should be a bug report, not a feature request.
(0027746)
paul   
2023-06-12 21:35   
The ctrl-v/c/x issues should be fixed now, via commit d742e876d1

Would appreciate feedback on that.
(0027802)
dsfdsf   
2023-06-20 04:58   
@paul
also add option to clip browser section to play along side playback
when audition clip / sample main playback not going stoped
(0027805)
paul   
2023-06-20 13:02   
We're not likely to do that. Our auditioning mechanism explicitly overrides normal playback. Just have a scratch track and drop the clip into a slot. It's not expensive.
(0027806)
dsfdsf   
2023-06-21 03:41   
@paul
My reason to say that it is because with this option user can hear sample in context and decide use it or not
Some DAWs give user this option + match with tempo ( sample never go out of rhythm )
And i think if you decide to optimize Ardour for live performance this option is vital
(0027807)
paul   
2023-06-21 03:52   
That is equivalent to:

* provide a scratch track
* load clip into slot in the scratch track
* trigger clip appropriately

someone can write a Lua script to do this, it doesn't need to be part of the core (though sure, it could be)
(0027910)
darless   
2023-07-24 15:20   
With regard to the UP/DOWN keys to select clips: (Version 7.5)

- If the following Modes are set (Grab, Range, Cut, Audition, Stretch): The up/down changes track
- If the 'Draw' or 'Internal Edit Mode' is used, and you click on a clip, then the up/down arrow keys change which clip is selected.

From the above, in version 7.5 (at least) to change which clip is selected with arrow keys:
- Change mode to 'Draw Mode' or 'Internal Edit Mode'
- Select a clip in the 'Clips' Browser
- Press 'UP key' will select the previous clip
- Press 'DOWN' key will select the next clip

If the auto-play is enabled, then the above actions, will automatically switch which clip is being played.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8260 [ardour] other minor always 2020-06-19 15:11 2023-07-24 01:02
Reporter: dhealey Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Dual delete entries in Keyboard Shortcuts editor
Description: I notice in the Keyboard Shortcuts editor, there are two entries for Editor >> Delete. This is really confusing as there is no clear indication of what the difference is. However I discovered the difference when trying to edit automation points. My original bug report was going to be "Remove automation with delete key only works when using the select tool" as that's how I discovered this quirk.

I think there should either be only one delete action in the menu, or both actions should have the same default key binding, or they should have different names so users know what they do.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: image.png (18,584 bytes) 2023-07-24 01:02
https://tracker.ardour.org/file_download.php?file_id=4601&type=bug
png
Notes
(0027908)
darless   
2023-07-24 01:02   
From looking at the code, the 2nd one is an alternate to delete. In the code the first Delete is called editor-delete, the 2nd is called alternate-editor-delete. It's also stated as the same Delete in the ardour manual - see attached screenshot. I think it makes sense that you'd like to delete via different keys, some are used to backspace, and others are used to the Delete key. Ideally, the shortcuts would allow you to set the action to multiple keys, but that's not the case it seems.

In the code (editor_actions.cc)

```
    reg_sens (editor_actions, "editor-delete", _("Delete"), sigc::mem_fun(*this, &Editor::delete_));
    reg_sens (editor_actions, "alternate-editor-delete", _("Delete"), sigc::mem_fun(*this, &Editor::delete_));
```

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2982 [ardour] bugs block always 2010-01-01 18:44 2023-07-23 21:57
Reporter: realhangman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 2.8.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 3.0  
Summary: performance issue with lots of regions (bad scalability)
Description: Ardour gets painfully slow when the project has lots of regions.
Scenario:
I edit one mono track splitting one .wav file into about 80 regions and move them around, and the gui (e.g. when scrolling horizontally) gets very slow. This happens on an AMD Phenom 4 x 2,5GHz and 4GB Ram.

The behaviour can be improved by reducing the undo history (ah, there I also see that Ardour does not save the number of saved undos between sessioon loads), but this only improves the situation temporarily until you have to handle some more regions.

I would love to see Ardour being more scalable, as I often work with 10+ tracks for drum editing, where I have several hundreds of regions to work with.

Not sure if this is related to report 0002905
http://tracker.ardour.org/view.php?id=2905
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: slow-project.zip (359,277 bytes) 2011-04-12 16:31
https://tracker.ardour.org/file_download.php?file_id=1323&type=bug
Notes
(0008082)
confusion_music   
2010-05-27 20:55   
For what its worth I find this to be quite an issue as well with a similarly specified PC as realhangman.
(0008084)
paul   
2010-05-27 21:30   
this has already been addressed in ardour3. the entire undo/redo mechanism has been reimplemented for everything except automation data, which is much more compact than region state.
(0010549)
realhangman   
2011-04-12 16:20   
Hi, an update: This has nothing to do with undo/redo. True, undo/redo gets very slow in A2 in a big session, this has been adressed in A3.

But my problem is the following scenario:

In a recent project (with A2 rev 9332), I have hundreds of regions and reduced the undo history to 7 and have no saved undo region at all (this gets saved now). Immediately after reopening the project, the gui (zooming, scrolling etc.) is very very slow. On top of that, Ardour crashes often while editing (splitting, trimming).

If I consolidate most of the regions, A2 is fast again, so it really is an issue with lots of (overlapping ?) regions.

I'd like to upload the project, but it's 20 GB big...
(0010550)
realhangman   
2011-04-12 16:30   
Fwiw, I attach a zip file containing two session files.

The first file (2011-04-12T13:21:50.ardour) contains my slow session with hundreds of overlapping regions in the project.
The second (A2mainsession.ardour) contains the session with consolidated regions, i.e. no regions are deleted from the project but most have been removed from the timeline. A2 is quite fast here. This file contains some more data as it contains 2 more recorded songs.

Don't know if this is useful, tell me if you need something more.
(0010554)
realhangman   
2011-04-14 22:03   
Here we go with a video & detailed description how to reproduce this fast.

Link: http://www.septimbears.de/a2-performance.ogv

This is what I do:

1. Open a new project and import a file (this is a .flac file with about 5 minutes length)

--> Zooming and scrolling is fast

2. Split the region and copy one region over the other (Ctrl-left mouse and drag) some times (maybe 10-20) so we end up with quite some regions and crossfades.

--> Zooming and scrolling is already lagging

3. Do it some more

--> In this example, Ardour freezes for some time and is afterwards really slow. I never experienced this freeze and 100% CPU consumption before, but zooming and scrolling is painfully slow now.

4. Delete the regions

--> A2 is performing nicely again.

Conclusion: The undo/redo mechanism seems not to be the problem here. The problem is caused by too many overlapping regions, maybe also the underlying created crossfades. I have the feeling that it's better if you deactivate "create crossfades" beforehand, but it's not really that much better.
I know this is not a real world example, but imaging you have 14 tracks for drums and then cut and overlap some takes etc. You'll reach the limit very soon.
(0010555)
oofus   
2011-04-14 22:31   
maybe this is a flac issue. can you try the same thing with a wav file ?
(0010560)
realhangman   
2011-04-15 07:58   
Thanks for replying. Unfortunately, the behaviour is completely the same with a 16 bit wav file. You can also record a short region and then follow the same procedure as described above.
(0010561)
lincoln   
2011-04-15 12:16   
Have you tried to open this session on A3. I would be interested to see if there is any noticeable difference in performance.
(0010582)
realhangman   
2011-04-18 21:32   
A3 feels very slightly better, but has the same problem.
I realized something else, though: Ardour only slows down as long as it displays the regions. If you are scrolling hoizontally to another part of the project with little or no regions, the gui behaves normal. The vertical zoom level of the track is also important, i.e. the smaller the track height the better the performance.
(0012396)
farbro   
2011-12-12 23:27   
I confirm this issue on latest SVN. I do this kind of songs when I end up with lots and lots of short regions with samples. When reaching a somewhat large number of regions, the GUI starts performing extremely slow, especially copying/moving multiple regions completely locks up the computer and you have to leave it for up to 5 minutes before it's done processing the copying and you can start working again (though still with bad performance in scrolling etc).
(0012542)
lievenmoors   
2012-01-10 23:54   
I would like to confirm this issue as well, at least for the ardour2 series.
Could this be due to the calculation or rendering of the waveforms?
(0012990)
realhangman   
2012-03-20 11:22   
A quick note: I also experience the problem of slow scrolling within Audacity. When I have long file (about 30 Minutes) and zoom to near-sample level, horizontal scrolling becomes sluggish. I don't know if it's related, a shared library comes to my mind, but it also might be a coincidence.
(0013178)
farbro   
2012-04-24 12:58   
I have now been running Ardour SVN on my laptop since January and I must say that I do no longer experience these performance issues. It is still a bit slow but much better than on my stationary computer.

My laptop has an Intel Core i5 2410M and 4GB RAM and is running Ubuntu 11.10. The stationary has an Intel Core 2 Duo E8400 and 4 GB RAM on 11.04.

Any clue of what is causing the problem?
(0013530)
cth103   
2012-06-14 10:15   
Are we thinking that A3 is ok in this regard now?
(0013532)
farbro   
2012-06-14 12:21   
After further testing on both computers, I must now withdraw my last post. I haven't really experienced this problem with my laptop on my new projects, probably because they haven't been that complex. But now when I open up my old sessions on both of the computers, it performs just as bad on both.

This is my procedure to reproduce it:

1. Import a short half beat sample to say 5 tracks.
2. Duplicate them 20 times. Select them all and duplicate them, it goes pretty smooth.
3. Now, undo and duplicate the regions to a length of 100, this takes a moment but not too long.
4. Try duplicating all of them again, this will take a while and my Ubuntu freezes until it's done.

5. Delete all regions except the first ones. Do step 2 again, but this time the duplication will take *much* longer than the first time.

Apparently the bad performance starts when you reach a great amount of regions, and does not go away simply because you delete them.

This is on SVN 12717
(0013563)
realhangman   
2012-06-17 21:06   
A3 rev.12747 is much better than A2 here! It still becomes slower with lots of overlapping regions, but I think it's much better. I still need to do some tests, though. I will report back.
(0013567)
cth103   
2012-06-18 16:58   
Should be quicker in SVN 12753.
(0013569)
farbro   
2012-06-18 17:57   
Can't see any difference here... :/
(0013570)
cth103   
2012-06-18 18:18   
What are you testing? I meant the duplicating regions test.
(0013572)
realhangman   
2012-06-18 19:04   
(Last edited: 2012-06-18 19:05)
The duplications run fine here with A3 12756.

The performance with lots of regions though.. it's better and I don't expect a program to run perfectly smooth when stuffed with thousands of objects, but you can already feel this sluggishness after duplicating 5 regions 20 times, and after duplicating them a hundred times ( =500 regions), you'll see it for sure.

Again, this seems like a high region count, but when recording drums or whole bands with 10-20 tracks at once, you can't have too many takes before things will get slow.

(0013574)
cth103   
2012-06-18 23:06   
Is this sluggishness in moving around the session?
(0013593)
realhangman   
2012-06-19 10:30   
Yes, when moving and zooming. Or when dragging a lot of regions, single regions are fine.
(0016326)
nick_m   
2015-02-06 12:41   
How is this with current git or the nightlies?
Things that have improved scalability since 2012-16:
Canvas rewrite.
Caching of waveviews per source (helps with many regions from one audio source).
Improved waveview drawing speed.
Canvas doesn't update offscreen items.
There are probably many more, but it would be great to get an update on this.
(0016355)
BenLoftis   
2015-02-19 00:17   
Several regions "overlaid" as layers on the same track will slow down rendering of the red playhead dramatically.

Switching to "stacked" layer view will improve rendering (measured by how smooth the playhead moves) ... but it's still much worse than a single region on the track.

This is NOT panning or zooming the canvas ... just passing the playhead across the regions. After the playhead gets past the stacked regions, the playhead speed/smoothness will improve.
(0016356)
paul   
2015-02-19 00:36   
behaviour isolated as slow drawing of waveform lines. fixes to come from two directions:

(1) direct, non-cairo rendering of waveform lines
(2) threaded rendering of image cache for waveviews
(0016421)
realhangman   
2015-03-12 22:13   
I don't understand Paul's response, but in response to nick_m: To my understanding, the cairocanvas branch improves things, but it depends on your hardware and 2d acceleration driver support. Unfortunately I lack the time to test this more atm. I will certainly do some tests with the 4.0 release that's ahead.
Thanks for caring about the issue, Paul & co :)
(0016734)
nick_m   
2015-05-26 15:39   
I've discovered that you can only really get reasonable performance when cairo can render to a gl backend.
By default, my radeon card doesn't do this, so i made a file
/etc/X11/xorg.conf.d/50-radeon.conf

and put this in it:

Section "Module"
    Load "dri2"
    Load "glamoregl"
EndSection

Section "Device"
        Option "AccelMethod" "glamor"
    Identifier "Card0"
    Driver "radeon"
    BusID "PCI:1:0:0"
EndSection

The usual warnings about messing with this stuff appy: you may end up with a garbled display or worse if you try this out without knowing how to get back to your original state

Anyway, with only that in the file, things have sped up dramatically. I've been using it for months now without any problems.

lspci shows it to be:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]
(0016736)
nick_m   
2015-05-27 11:15   
Apparently i've confused some people with that last note.
To be clearer, afaict the only way to get cairo to use hardware acceleration is by choosing an acceleration method which translates X requests into gl primitives.
In the case of Radeon cards, this means to use glamor.
This has nothing to do with the actual libraries used by the application. I am talking hardware acceleration at the video card driver level and nothing else.
(0027734)
slash42   
2023-06-10 14:43   
Hi.

I'm using Ardour 6.9.0 (from KDE neon / Ubuntu 22.04) on an AMD Ryzen 1700 and I also observed this performance issue.
I think the easiest way to reproduce is to do the following:
- start with an empty project
- add two mono wave tracks
- record some silence on one track (or just import an arbitrary wave file, doesn't really matter)
- arbitrarily split up the wave into regions and optionally select + Ctrl-click to copy them in order to get at least 200 regions in total
 
Then, on my system I can observe the following numbers:
- when moving only few regions to the other wave track, the performance is fine
- when moving 100 regions to the other wave track, it takes about 6 seconds. During that time, the UI is kind of frozen and CPU usage goes up.
- when moving 200 regions, it takes over 30 seconds.

So, whatever Ardour does while moving these regions, something happens that obviously doesn't scale up well with the amount of regions.


Thanks and regards.
(0027907)
Krio   
2023-07-23 21:57   
Here's a summary of my findings on this issue. Also discussed this on Unfa #ardour chat channel with Paul and others.

I have been experiencing intermittent GUI freezes (Ardour doesn't respond to keyboard/mouse input) when the number of regions in the session file increase. From a certain moment certain edit operations become slow (5-10 seconds GUI freeze after each split region, move region, ...) and also stopping recording can take up to minutes before the recording is actually stopped. Strangely during the freeze I don't see CPU power go higher than 15%.

Paul says "apparently we still have some cases of O(N^x) where x>2 (N is the number of regions". x42 confirms "so far I have only been able to establish that it is a GUI issue. a headless Lua script splitting regions runs fast."

For me specifically in 2023 on a fairly fast computer this means: fast response time with up to 1000 total number of regions in the session file. When having 2000+ regions in the session the intermittent freeze builds up to around 3-4 seconds. When going to 4000+ regions this freezes for at least several minutes. It doesn't make any difference if the regions are all referring to the same underlying audio file or to different (parts of different) audio files. Also the regions can be on the same or on different tracks.

As a workaround:
- the following do NOT work:
    * muting or deactivating the track containing lots of regions
    * muting the regions (Edit selected regions > Gain > Mute)
- these DO work:
    * Combining lots of regions (Edit selected regions > Edit > Combine)
    * Putting the separate regions on a playlist of the track that is not active/selected
    * Removing the regions from the session (via automatic cleanup or manually)

Combining related regions is the most elegant workaround, since you can easily uncombine afterwards in case you need to do some more edits afterwards.

This ticket is 13 years old, but still an issue.

I propose to close the following two tickets, which I'm quite sure they are duplicates:
https://tracker.ardour.org/view.php?id=2905
https://tracker.ardour.org/view.php?id=7685

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9417 [ardour] features minor N/A 2023-07-18 14:53 2023-07-22 22:03
Reporter: edrickblade Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Edit in a external editor option and CLAP plugin support
Description: Hi, Ardour is the only 99.9% usable DAW in the linux platform, is the only that loads LV2, VST2-3 without many issues, it could be a great feature that Ardour let use an external editor via right click menu, some like Ocenaudio or Audacity to remove noise etc.
A CLAP plugins support could be a great upgrade.
Tags: CLAP, Editor, Upgrade
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027900)
darless   
2023-07-20 14:10   
This should probably be split into 2 different feature requests. One for the external editor and one for the more important one imho - CLAP.
(0027906)
edrickblade   
2023-07-22 22:03   
Thanks darless for your opinion!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8686 [ardour] features minor always 2021-05-05 08:55 2023-07-18 02:48
Reporter: unfa Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Prevent accidental region duplication when holding Ctrl
Description: When selecting multiple regions by holding down Ctrl and clicking on them I often create region duplicates by mistake.

I think a simple solution to this problem is to introduce a minimum drag distance threshold that needs to be crossed in order for drag to be registered.
It seems that these accidental region duplications occur when I hold my mouse button for too long and move my mouse cursor by 1 or 2 pixels while clicking.

Adding a 5-pixel threshold would most likely eliminate this annoying problem and ensure regions are only copied when the user intends to do so, and not during region selection.

What do you think?
Tags: ui, usability
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025802)
x42   
2021-05-08 01:58   
There is currently a 4 sample threshold (for all move drags), so it's only effective when zoomed it. It should perhaps be pixel based.
(0025803)
x42   
2021-05-08 02:37   
Tweaked in 6.6-456-gce1e05fc3d copy-drags now require 6 px horiz movement (move drags 2px)
(0025804)
x42   
2021-05-08 02:37   
Please test

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9411 [ardour] bugs minor always 2023-07-04 05:02 2023-07-11 02:05
Reporter: blakegardner Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Realtime export fails to follow normalization setting
Description: While exporting a region or session with the realtime option enabled, the end result is always normalized, even when normalization is disabled in the export profile.

Disabling the normalization checkbox in the export profile results in an exported file with the loudness and peak settings that would be expected if normalization was enabled.
Tags: export, normalization, realtime, Windows
Steps To Reproduce: 1. In the Time Span dialog, enable the realtime option for the session or range to export.

2. Choose an export profile (I tried with a 48k/32 bit float wav), and disable normalization.

3. Export and check the loudness analysis.

4. Run Loudness Analysis on source material to confirm that the source does not match the export loudness.
Additional Information: I initially thought that this problem was due to an upgrade from 7.4 to 7.5. However, I realized that I had not actually tried a realtime export prior to the upgrade.

At one point in my troubleshooting process, I downgraded to 7.4, and the bug was present; re-upgrading didn't solve the problem.

More screenshots and discussion may be found in this thread:
https://discourse.ardour.org/t/export-issue-after-upgrade-to-7-5-on-windows/108894
System Description Windows 11
Attached Files: export.zip (2,790 bytes) 2023-07-11 02:05
https://tracker.ardour.org/file_download.php?file_id=4599&type=bug
Notes
(0027853)
x42   
2023-07-04 15:10   
I cannot reproduce this here. Perhaps the bug is triggered by some custom export formats.
While Ardour is not running, please remove %localappdata%\ardour7\export\ and after that try the export again.

Just move the folder away, do not delete it. If that solves the problem we can investigate the export specs.
(0027894)
blakegardner   
2023-07-11 02:05   
I'm so sorry for the delay here --- moving the export folder solved the issue. I can export at the expected loudness using both a stock Ardour profile and a modified profile. I've attached a zipped copy of the original export folder.

Thank you for the suggestion, and please let me know if there's anything else I can do to help!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9414 [ardour] bugs crash N/A 2023-07-08 15:56 2023-07-10 19:15
Reporter: merryl0 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Session crashing when plugin values edited whilst playing
Description: This is a mixed session of live instruments, AVL drumkit and general midi synth.
It started crashing as soon as I started adding plugins (x42, and airwindows) to the channels and master.
Originally I was using sfizz, up to 8 instances but I decided to reduce the load, in case this was the cause of the problem, by changing sfizz to genral midi synth for all the instances. I had been constantly getting the disk is too slow message
Still crashing everytime i edit a plugin during playback
buffer size is 2048
dsp load less than 20%
System is AVL 21.3 fully up to date on 2017 Lenovo Thinkstation, SSL drive, 15% used and 32G ram
Tags:
Steps To Reproduce: I made a new session with sfizz and AVL drums, various plugins, but could not reproduce crash
Additional Information:
System Description
Attached Files: 75127Crash.txt (58,308 bytes) 2023-07-08 15:56
https://tracker.ardour.org/file_download.php?file_id=4595&type=bug
Crash100723.txt (58,361 bytes) 2023-07-10 19:05
https://tracker.ardour.org/file_download.php?file_id=4597&type=bug
PlginList.png (80,808 bytes) 2023-07-10 19:05
https://tracker.ardour.org/file_download.php?file_id=4598&type=bug
png
Notes
(0027889)
merryl0   
2023-07-10 19:05   
Now crashing with monotonous regularity. Even editing note lengths with a mouse
As well as the debug, Ive put a screenshot of the plugins used.
Am I expecting too much of this computer? It's a graphics workstation with an ssd as main disk in the raid (and i only use the hdd for archiving), but Ardour keeps telling me the disk is too slow.
It works fine editing videos
(0027890)
merryl0   
2023-07-10 19:15   
Shall I provide an archive of the troubled session?
I tried below but its 11Mb and will not upload here

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9415 [ardour] features minor have not tried 2023-07-10 03:19 2023-07-10 03:19
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: send to insert
Description:
https://discourse.ardour.org/t/send-to-instert-fast-way/108950
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9410 [ardour] bugs major unable to reproduce 2023-07-03 16:05 2023-07-09 20:01
Reporter: edrickblade Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: midi region doesn't sound at the beginning.
Description: Hi, Forum, I have a situation, I don’t know if I’m doing something wrong or is a bug, the situation is Ardour doesn’t play the beginning of midi regions, in the video is the description of the problem.
Thanks anticipated!

https://www.youtube.com/watch?v=D8PZwlVmW2Q
Tags: MIDI region
Steps To Reproduce:
Additional Information: https://www.youtube.com/watch?v=D8PZwlVmW2Q
System Description
Attached Files: test.ardour (223,457 bytes) 2023-07-03 16:05
https://tracker.ardour.org/file_download.php?file_id=4591&type=bug
Complete_Project.zip (128,476 bytes) 2023-07-03 16:11
https://tracker.ardour.org/file_download.php?file_id=4592&type=bug
Notes
(0027846)
edrickblade   
2023-07-03 16:11   
(0027847)
paul   
2023-07-03 17:03   
does not replicate here.

steps for you to take:

1. replace sfizz with General MIDI synth to avoid potential plugin issues
2. insert the ACE MIDI monitor plugin before the GM Synth so you can see MIDI events as they do (or do not) happen
3. try to replicate in an even simpler session

Also, if you have to attach whole projects again, please use Ardour's own built in archiver (Session > Archive in the top menu bar)
(0027848)
edrickblade   
2023-07-03 17:13   
Hi, Paul, I discovered what is the problem, Ardour doesn't play the beginning of the midi region if the track record button is on, when I turned off the record button then plays the complete region, if the track's record button is on Ardour plays the region in the second bar of the region but not the beginning.
(0027865)
edrickblade   
2023-07-08 12:13   
It doesn't play the beginning of a midi region when quantize the region and the track is armed for record, if the track isn't armed it plays the complete region, no matter if is quantized.
(0027866)
axra   
2023-07-08 12:52   
It doesn't even record notes at the beginning entered from midi keyboard while recording!
(0027868)
edrickblade   
2023-07-08 15:16   
axtra, Try to record with pre-roll and let me know.
(0027877)
paul   
2023-07-08 21:26   
 Bug fixed in commit 3b1d4d8fa65
(0027882)
edrickblade   
2023-07-09 20:01   
Great! All united we can do our bit to make Ardour continue to be the best of the best!!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9409 [ardour] bugs minor sometimes 2023-07-03 10:04 2023-07-09 08:40
Reporter: nyxkn Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi quantize to 1/16 quantizes to 1/8 triplets instead
Description: I have a certain midi region that when I try to quantize all notes to 16th notes, it quantizes to 8th notes instead. When set to quantize to main grid, and grid is 16th notes, it works fine.

This only happened on this particular region. Attaching session project containing only the faulty region.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: bug1_2023-07-03_105909.ardour-session-archive (13,098 bytes) 2023-07-03 10:04
https://tracker.ardour.org/file_download.php?file_id=4590&type=bug
Notes
(0027839)
nyxkn   
2023-07-03 10:29   
Edit: meant to type "it quantizes to 8th note *triplets* instead"
(0027880)
Alcorpmasta   
2023-07-09 08:40   
Relates to https://tracker.ardour.org/view.php?id=9211 and https://tracker.ardour.org/view.php?id=9316 ? ( not sure about it )

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9412 [ardour] bugs minor always 2023-07-06 19:56 2023-07-08 22:37
Reporter: aggraef Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Uninitialized Parameter symbol() called" warning
Description: Whenever I run Ardour (7.5-120 at present) for an extended period of time, I can see a large number of these messages in the log window:

2023-07-06T21:31:57 [WARNING]: Uninitialized Parameter symbol() called.

These pop up occasionally, at seemingly random times. The message probably comes from `std::string EventTypeMap::to_symbol(const Evoral::Parameter& param) const` in event_type_map.cc:231 and seems to indicate an unkown automation type.

This happens even with the most basic session, e.g., with a single MIDI track, some notes, not even a synth, nor any automation on it.
Tags:
Steps To Reproduce: Create a new session, add a MIDI track with a MIDI clip on it, and wait. The messages should start popping up. If not, try to hit play and stop.
Additional Information:
System Description
Attached Files:
Notes
(0027860)
x42   
2023-07-08 03:04   
It happens when ardour saves. Either explicitly, or periodic
Thread 1 "ArdourGUI" hit Breakpoint 1, ARDOUR::EventTypeMap::to_symbol[abi:cxx11](Evoral::Parameter const&) const (this=0x6060003eace0, param=...) at ../libs/ardour/event_type_map.cc:297
297			PBD::warning << "Uninitialized Parameter symbol() called." << endmsg;
(gdb) bt
#0  ARDOUR::EventTypeMap::to_symbol[abi:cxx11](Evoral::Parameter const&) const (this=0x6060003eace0, param=...) at ../libs/ardour/event_type_map.cc:297
0000001  0x00007ffff55bf39b in ARDOUR::AutomationList::state(bool, bool) const (this=0x619001705280, save_auto_state=true, need_lock=true) at ../libs/ardour/automation_list.cc:335
#2  0x00007ffff55bf118 in ARDOUR::AutomationList::get_state() const (this=0x619001705280) at ../libs/ardour/automation_list.cc:327
#3  0x00007ffff558f33c in ARDOUR::Automatable::get_automation_xml_state() const (this=0x62500262ca50) at ../libs/ardour/automatable.cc:329
0000004  0x00007ffff601a41a in ARDOUR::Route::state(bool) const (this=0x62500262c900, save_template=false) at ../libs/ardour/route.cc:2609
0000005  0x00007ffff64a9db2 in ARDOUR::Track::state(bool) const (this=0x62500262c900, save_template=false) at ../libs/ardour/track.cc:185
#6  0x00007ffff5c142f8 in ARDOUR::MidiTrack::state(bool) const (this=0x62500262c900, save_template=false) at ../libs/ardour/midi_track.cc:241
#7  0x00007ffff6019345 in ARDOUR::Route::get_state() const (this=0x62500262c900) at ../libs/ardour/route.cc:2538
0000008  0x00007ffff62f960c in ARDOUR::Session::state(bool, ARDOUR::Session::snapshot_t, bool, bool) const (this=
    0x6260000e7100, save_template=false, snapshot_type=ARDOUR::Session::NormalSave, for_archive=false, only_used_assets=false) at ../libs/ardour/session_state.cc:1519
0000009  0x00007ffff62ed2ef in ARDOUR::Session::save_state(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, bool, bool, bool, bool)
...

(gdb) p param
$1 = (const Evoral::Parameter &) @0x6190017053b0: {_type = 31, _id = 0, _channel = 0 '\000'}


Looks like MidiVelocityAutomation is missing
(0027861)
x42   
2023-07-08 03:11   
MIDI Velocity tracks are work in progress (and currently show a fake Automation Control in the track-header, which is what that enum is used for)
(0027879)
paul   
2023-07-08 22:37   
Fixed in commit 1c54f0e4

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9398 [ardour] bugs minor always 2023-06-24 10:54 2023-07-08 21:43
Reporter: merryl0 Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: version7.4 will not play midi notes at beginning of region
Description: Midi Notes which start earlier than 80 ticks after the beginning of a region do not sound
Tags:
Steps To Reproduce: draw a midi region
insert notes at start of region
play region (eg press h, or record another track starting from beginning of region
Seems to have affected all 7.xs so far
Additional Information: Will try with 7.5
System Description
Attached Files: image.png (35,863 bytes) 2023-06-28 13:39
https://tracker.ardour.org/file_download.php?file_id=4587&type=bug
png

1stNoteSilent.ardour-session-archive (4,894 bytes) 2023-07-04 09:48
https://tracker.ardour.org/file_download.php?file_id=4593&type=bug
Notes
(0027812)
merryl0   
2023-06-24 11:04   
Still present in 7.5.0
(0027813)
merryl0   
2023-06-24 11:05   
also applies to notes entered from midi controller keyboard
(0027814)
merryl0   
2023-06-24 11:26   
could it be related to this error message 1st entry in the log?
2023-06-24T11:59:13 [ERROR]: Cannot set sample rate to 0
(0027821)
merryl0   
2023-06-28 13:35   
Today the first note (at 01.01.0) is playing. Still on 7.5.0
(0027822)
merryl0   
2023-06-28 13:39   
though there is some note length time discrepancy. i turned off snap, selected all the semiquaver notes except one in a region with the edit tool and shortened them by dragging. the resulting note lengths are unequal. please see screenshot below
(0027840)
nyxkn   
2023-07-03 10:50   
I get this too. On 7.5.

My workflow for triggering this is:
Start record, play some stuff with the metronome, stop record. Then I'll want to remove the extra empty space at the beginning of the region, so I want to resize the beginning of the region to match where the first midi note is. If the note is earlier than the beat, resizing to the beat will clip the note, so I first have to manually adjust the first note to be exactly on the beat. Then I resize the start of the region to the same beat and all looks nice with the note still showing in the region. But, if I set the playhead on that same beat (start of region) and hit play, the first note will not play.

Now, the first note will not play, *as long as the track is still armed*.
If I disarm the track, and play from the start of the region again, the first note will play correctly!!
(0027841)
merryl0   
2023-07-03 12:22   
Mine is doing this with nothing rec armed.
Just open a session.
put the playhead at the beginning of a midi region with a note at the start (of the region).
the first note does not sound when play is pressed
(0027842)
merryl0   
2023-07-03 12:26   
Five minutes later...
Now the first note is sounding
(0027843)
paul   
2023-07-03 12:45   
Please attach a session archive (via Session > Archive inside Ardour) of a *minimal* session that displays this behavior.
(0027851)
merryl0   
2023-07-04 09:48   
Good morning.
This session is behaving as nyxkn describes above; the first note silent when record is armed for the track, but sounding when record is not enabled.
Many thanks for your great help
(0027852)
merryl0   
2023-07-04 10:13   
I have noticed that the silent first note occurs if recording is enabled for the session (Shift R), or the Track itself.
So the track might not be armed, but the first note is silent if Record is enabled on the transport bar at the top left of the edit window.
(0027862)
edrickblade   
2023-07-08 12:06   
Hi merryl0, I found what is the problem, Ardour doesn't play the beginning of the midi region if the track record button is on, when the the record button is off, it plays the complete region.
(0027863)
edrickblade   
2023-07-08 12:08   
I mean, when the track is armed to record that happens, has nothing to do with the main record button, but the the trackk's.
(0027864)
edrickblade   
2023-07-08 12:10   
Is when you quantize the region and the track is armed for record.
(0027867)
axra   
2023-07-08 12:54   
It doesn't even record notes at the beginning entered from midi keyboard while recording!
(0027869)
edrickblade   
2023-07-08 15:18   
axra, Try to record with Pre-Roll feature and let me know.
(0027873)
paul   
2023-07-08 16:59   
(Last edited: 2023-07-08 17:01)
I am not able to reproduce this behavior using the test session when using the JACK backend.

I can reproduce it using ALSA.
(0027875)
x42   
2023-07-08 20:23   
(Last edited: 2023-07-08 20:25)
Here it plays correctly with Arodur's ALSA backend and Pulseaudio.

PS. I first had to disable Rec-arm. Then it plays correctly both after rewind as well as when looping.
(0027876)
paul   
2023-07-08 21:26   
Bug fixed in commit 3b1d4d8fa65
(0027878)
nyxkn   
2023-07-08 21:43   
Confirming, fixed for me on master!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9400 [ardour] features minor have not tried 2023-06-25 05:08 2023-07-08 16:50
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Brush tool for midi
Description: adding midi with brush like fls
in modern genre like trap ukdrill specially for drum notes
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027816)
dsfdsf   
2023-06-26 04:29   
@paul
also can hold e.g alt key and drag to brush notes as grid mode length
(0027819)
paul   
2023-06-27 13:21   
we offer region brush dragging already (not the same, but arguably more useful)
(0027872)
edrickblade   
2023-07-08 16:50   
It's a great idea, even for any genre of drum patterns, specially for the hihats!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9399 [ardour] features feature sometimes 2023-06-25 02:43 2023-07-08 16:47
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: make button for "sound MIDI note as they are selected in editor"
Description: instead every time going to preferences page for change this option "sound MIDI note as they are selected in editor"
make button for it
pay attention to screenshot
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: button.jpg (80,850 bytes) 2023-06-25 02:43
https://tracker.ardour.org/file_download.php?file_id=4582&type=bug
jpg
Notes
(0027833)
paul   
2023-06-30 19:01   
that toolbar is only visible in "draw" mode, and the button would be more useful in internal edit mode ....
(0027834)
dsfdsf   
2023-07-01 01:31   
@paul
I just create it with gimp - you can move it anywhere
(0027836)
paul   
2023-07-01 03:21   
finding the right "anywhere" is 90.3764218% of the task.
(0027871)
edrickblade   
2023-07-08 16:47   
If you select "sound MIDI note as they are selected in editor" once, you don't need to reselect it, Ardour keeps the configuration in the .config folder, if you are a person who like to try many distros, make a backup of that folder,paste it to your new home/user directory and you will have the same Ardour configuration as before.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2235 [ardour] features minor always 2008-05-05 15:28 2023-07-08 15:30
Reporter: magnanimo Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Warp in ardour
Description: No se ingles, no se hablar ingles pero les reegalo estas direciones donde ustedes pueden ver la herramienta que tendria que tener ardour

Not English, not speak English but I reegalo these addresses where you can see the tool you would have to take ardour

WARP EXPLICATION:
http://www.ableton.com/pages/tips/2004_05
WARP IN ACTION:
http://es.youtube.com/watch?v=7F0Dcs-sias
http://es.youtube.com/watch?v=hNevsn8Pbxo
http://es.youtube.com/watch?v=hvVBnO2FwMc
http://es.youtube.com/watch?v=fI4EAWVruwc

It is a very useful tool




paul
Posts: 676
Joined: 2006-03-16
This is a fascinating idea

This is a fascinating idea but I cannot imagine adding it to Ardour until some time after version 3.0 comes out. Most people don’t know that Live is running a granular resynthesis engine all the time, which makes transformations like this rather easy. They also have a the possibility of a BBT ruler for every track, which ardour currently does not have. This makes certain aspects of the warp marker idea easier to implement. Please file the idea in our bug/feature request track with a link back to this page, and that way it will not be forgotten.
Thanks, Viva Ardour
Tags:
Steps To Reproduce:
Additional Information: http://ardour.org/node/1744
Attached Files: Screenshot at 2023-07-08 11-24-16.png (62,155 bytes) 2023-07-08 15:30
https://tracker.ardour.org/file_download.php?file_id=4594&type=bug
png
Notes
(0017012)
naught101   
2015-08-10 01:28   
For what it's worth, there is at least one open source live warping library available now:

- Soundtouch - http://www.surina.net/soundtouch/
- Rubberband - http://www.breakfastquay.com/rubberband/

Both of those are used in Mixxx for live stretching, and work very well with a ±15% stretch, and reasonably well outside of that (good enough to be useful for many genres, but not all).

There's also Paulstretch, for extreme stretching, but I doubt it's very useful for Ardour.
(0018519)
cyberbeat   
2016-08-30 19:55   
(Last edited: 2016-10-10 15:05)
Here a video how it is done in cubase:

https://www.youtube.com/watch?v=w3qSloN7h2w

I like this way. Also in combination with pitch detection+correction (called "variaudio" in cubase).

The rubberband library would be a good choice as a foundation to implement such a feature.

A typical workflow:
- You record some tracks with musical instruments/voices
- you notice some timing-problems in single tracks
- you drag some waveform-position with wrong timing to their correct position (possibly snap to musical-rasters)

For the implementation there could be different rendering quality-settings or algorithms for live-preview and mixdowns.

Some musicians may say, "simply record the track again without errors". But I say, this software-workflow above is so easy and effective, and gives very good results.

(0018792)
paul   
2016-10-12 21:44   
Ardour already uses Rubberband. We replaced our older use of Soundtouch because the latter had way too many artifacts.

Most/All (?) proprietary DAWs that do this use ZPlane, which is not usable in a GPL context, and is significantly more sophisticated than Rubberband (or Soundtouch). It is a product of nearly 10 years of highly focused development by people who have specialized in this one domain.
(0018796)
cyberbeat   
2016-10-12 21:49   
What are the reasons, you think, that rubberband would not fullfill the needs for such a feature?
(0018799)
paul   
2016-10-12 21:58   
rubberband can provide the API required. the quality of the results is the issue.

anyway, the hard part of this is the GUI, not the backend stretching.
(0018802)
cyberbeat   
2016-10-13 15:54   
Thank you for the explanation. Yes, I believe, that it would be hard to implement a gui for this. But perhaps in the future, someone is motivated enough to do it. It's a killer feature in my opinion.
(0025164)
soundguy30   
2020-10-27 08:41   
I would like to see a open source version of this, is the time stretch feature from rubberband?
(0025169)
paul   
2020-10-27 12:32   
yes, it's time stretch in rubberband, as described above. but "dynamic" time stretch (i.e. from sample N1 to sample N2 stretch by 2% then from N2 to N3 by 2.4% then from N3 to N4 by 8% and so on) rather than the single static stretches that we use it for currently.
(0027870)
edrickblade   
2023-07-08 15:30   
With the new (Stretch audio to the left and right side) you can split region according to the visual transients and stretch or align transients to grid, to do that you must select the "snap rubberband to grid" option as the image below.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9203 [ardour] bugs minor always 2023-01-23 20:04 2023-07-05 07:21
Reporter: Edward Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: General UI slowness on an Intel Mac (compared to Ardour 6.9)
Description: The Ardour UI updating gets excessively slow when the amount of MIDI tracks grows. I noticed this when working on sessions and created a sample session to reproduce it.

In the example there are 45 MIDI tracks with imported MIDI files from previous Ardour sessions. I created the session in Ardour 6.9. When opening the same session in Ardour 7.2. it looks like the frame rate drops roughly to one fourth to what it was in 6.9.

I am running a 4K display (3840x2160). Scaling the display down to Full HD resolution improves the performance but the difference between 6.9 and 7.2 stays roughly the same.
Hiding tracks has an effect to the performance but still with just one track visible the frame rate on 7.2 is roughly on the level it is with all of them in 6.9.

The computer itself is not struggling - Mac Activity Monitor reports CPU usage of 5% - 8% and the memory consumption is also moderate between 400 and 700 MB. Audio / MIDI performance is flawless. Just the UI lags behind. In Ardour performance setting I have "all but one CPU" selected.

To try whether the computer itself is the problem I created the same session in Reaper. It ran considerably smoother there even if the playhead was slightly laggy.
Tags: 7.2, mac, ui
Steps To Reproduce: Test session on Dropbox:
https://www.dropbox.com/s/o8p52xoep1hydd3/Ardour-UI-perf-6-7.zip?dl=0

Video on how the UI looks on Ardour 7.2:
https://www.dropbox.com/s/lv9bywi662lbqnu/Ardour-72-4K.mov?dl=0

Video on how the UI looks on Ardour 6.9:
https://www.dropbox.com/s/ynrbbovm71lyphz/Ardour-69-4K.mov?dl=0
Additional Information: Computer:

MacBook Pro 16" 2019
Intel Core i9 2,4 GHz 8 cores
32GB RAM

macOS Monterey 12.6
System Description
Attached Files:
Notes
(0027223)
Edward   
2023-01-23 20:18   
The external screen I am using is not an Apple one. I tried setting the color correction to "Generic RGB Profile" as suggested in the other Mac performance related issue. It did improve the performance a little.
(0027344)
x42   
2023-02-10 01:00   
(Last edited: 2023-02-10 01:00)
There has been some progress, please see 0009201
(0027854)
Edward   
2023-07-04 18:15   
The same session on Ardour 7.5 runs pretty smoothly. You can see the playhead stutter just slightly. In other words - the performance is massively better now.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9393 [ardour] bugs crash always 2023-06-21 23:47 2023-06-29 22:18
Reporter: ksso Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: when run ardour all sounds are muted
Description: install ardour on xubuntu 23.4
all sounds are muted,
can not record nothing
HP Laptop 15-ef2xxx (612B7LA#ABM) AMD Ryzen 5 5500U with Radeon Graphics
Renoir Radeon High Definition Audio Controller
HD-Audio Generic HDMI/DP,pcm=3
Multimedia controller
Raven/Raven2/FireFlight/Renoir Audio Processor
Tags:
Steps To Reproduce: install ardour and run it
Additional Information:
System Description
Attached Files:
Notes
(0027829)
paul   
2023-06-29 21:42   
run ardour; while it is running, open a terminal and run this command

   cd /tmp && wget https://ardour.org/files/adevices.sh && bash ./adevices.sh

then paste the output of that command here.
(0027830)
ksso   
2023-06-29 21:57   
$ cd /tmp && wget https://ardour.org/files/adevices.sh && bash ./adevices.sh
--2023-06-29 16:55:55-- https://ardour.org/files/adevices.sh
Resolviendo ardour.org (ardour.org)... 54.235.123.47
Conectando con ardour.org (ardour.org)[54.235.123.47]:443... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 2249 (2,2K) [application/octet-stream]
Guardando como: ‘adevices.sh’

adevices.sh 100%[===================>] 2,20K --.-KB/s en 0s

2023-06-29 16:56:04 (248 MB/s) - ‘adevices.sh’ guardado [2249/2249]

========================================
Part I: ALSA
Advanced Linux Sound Architecture Driver Version k6.2.0-24-generic.

Card 0 (Generic):
  * Playback Device 3 (HDMI 0):
    - Subdevice 0 (hw:Generic,3,0):
      closed

Card 1 (Generic_1):
  * Playback Device 0 (ALC236 Analog):
    - Subdevice 0 (hw:Generic_1,0,0):
      used by: ArdourGUI (PID 28858)
      access: MMAP_INTERLEAVED
      format: S32_LE
      subformat: STD
      channels: 2
      rate: 44100 (44100/1)
      period_size: 1024
      buffer_size: 2048

  * Recording Device 0 (ALC236 Analog):
    - Subdevice 0 (hw:Generic_1,0,0):
      used by: ArdourGUI (PID 28858)
      access: MMAP_INTERLEAVED
      format: S32_LE
      subformat: STD
      channels: 2
      rate: 44100 (44100/1)
      period_size: 1024
      buffer_size: 2048

Card 2 (acp):
  * Recording Device 0:
    - Subdevice 0 (hw:acp,0,0):
      closed

========================================
Part II: jack processes
(0027831)
paul   
2023-06-29 22:18   
What device do you expect to hear audio from ardour playing on?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9405 [ardour] bugs minor always 2023-06-28 12:09 2023-06-29 00:52
Reporter: Schmitty2005 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST3 version of Relab LX480 Essentials always opens with mono on stereo tracks. VST2 Version works correctly
Description: Related to issue 8549
https://tracker.ardour.org/view.php?id=8549

https://relabdevelopment.com/lx480-essentials/

VST3 version of Relab LX480 Essentials always opens with mono plug in on stereo tracks. VST2 Version works correctly.

Also affects Mixbus 32C version 9.1.153

VST3 version LX480 works properly in Reaper, Cubase 12, and Bitwig.

Is this a Relab bug or Ardour bug ?

Tags: VST3
Steps To Reproduce: Add VST3 version of LX480 Essentials to any stereo track or buss. Plug in only has 1 input available, two outputs.

VST2 version functions as it should with stereo inputs, and stereo outputs.
Additional Information: Also affects Mixbus 32C version 9.1.153
System Description
Attached Files: image.png (4,458 bytes) 2023-06-28 12:09
https://tracker.ardour.org/file_download.php?file_id=4586&type=bug
png

image-2.png (5,293 bytes) 2023-06-29 00:52
https://tracker.ardour.org/file_download.php?file_id=4588&type=bug
png

image-3.png (7,907 bytes) 2023-06-29 00:52
https://tracker.ardour.org/file_download.php?file_id=4589&type=bug
png
Notes
(0027823)
x42   
2023-06-28 15:24   
Can you configure the plugin to become stereo using pin connections?
(0027824)
Schmitty2005   
2023-06-29 00:52   
I am unable to configure plugin with pin connections.

Plug-in is opened in mono. Only left side is connected. Only 1 input available on plug-in.

Plug-in selector show Audio I/O as 1/2 for VST3 version. VST2 version shows Audio I/O as 2/2.

Pics attached.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9402 [ardour] features minor have not tried 2023-06-26 04:27 2023-06-28 07:07
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: send to insert
Description: like send to bus
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027817)
dsfdsf   
2023-06-27 05:55   
a killer ability to shot signal any where
regular send just can send signal to bus input
but with this option user can route signal to any where of bus / track
before processors pre-fader
after processors pre-fader
before processors post-fader
and etc
(0027820)
dsfdsf   
2023-06-28 07:07   
it can also link send and insert (or maybe return) together
e.g you send signal to an insert in bus-1 then if you not love bus-1 sound drag&drop insert to bus-2 now you route signal easy to bus-2
 signal not disconnected from source because send and insert are linked together

@Paul what is your opinion ?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9403 [ardour] features minor have not tried 2023-06-27 05:59 2023-06-27 05:59
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: for playlists
Description: drag midi/audio to track header to put it on new playlist
scrol with mouse wheel on playlist bottom to go next / previous playlist
 remove playlist from playlist manager
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9401 [ardour] features minor have not tried 2023-06-26 02:39 2023-06-26 02:39
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Drag&Drop rigion
Description: https://discourse.ardour.org/t/drag-drop-rigion-from-region-propertise-to-anywhere/108884
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9056 [ardour] bugs minor always 2022-10-31 12:01 2023-06-25 16:43
Reporter: cooltehno_bugs Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bug: Ardour 6.9-7.0 - "Delete" key is not working for automation control points
Description: "Delete" key is not working for automation control points. Only "Backspace" key can delete the selected control points (may be this is somehow related with double "Delete" action in the Keyboard Shortcuts dialog)
Tags:
Steps To Reproduce: 1. Make few control points in any automation line.
2. Select few control points by rectangle selection with the mouse.
3. Press "Delete" key - this does nothing (Press "Backspace" key to delete these points - to ensure that the control points can be deleted in principle)
Additional Information:
System Description
Attached Files: Delete_control_points.gif (230,207 bytes) 2022-10-31 12:01
https://tracker.ardour.org/file_download.php?file_id=4264&type=bug
gif
Notes
(0026946)
tired_eyes   
2022-11-26 13:17   
Still relevant for 7.1

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9397 [ardour] features minor have not tried 2023-06-24 03:35 2023-06-24 03:35
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: revese midi region / notes
Description: horizontally and vertically
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9396 [ardour] other minor always 2023-06-24 00:07 2023-06-24 00:07
Reporter: beto Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Requirements page is broken
Description: The requirements page (https://ardour.org/requirements.html) is broken. The tabs (Linux, MacOS, Windows, Other) don't do anything, and the page seems to be showing the content for all the tabs at once.
Tags:
Steps To Reproduce: Go to https://ardour.org/requirements.html
Additional Information: Tested both in Firefox and Chrome, Mac OS.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9392 [ardour] features minor have not tried 2023-06-21 03:51 2023-06-22 01:17
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: put monitor gain knob in toolbar
Description: like other guys
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 2023-06-21_07-20.png (32,668 bytes) 2023-06-21 03:51
https://tracker.ardour.org/file_download.php?file_id=4581&type=bug
png
Notes
(0027810)
paul   
2023-06-21 21:47   
FL Studio has a monitor section?
(0027811)
dsfdsf   
2023-06-22 01:17   
@paul

no but have global gain trim knob on toolbar

and about ardour monitor section if you want switch between level need keep open it always
and this takes big space of mixer
e.g i want to mix in mono in a crappy speaker that need different level to give 85 spl
rather than my main speaker
so i always keep monitor section open and it take a space of my mixer view
i suggest it because when you added knob for mono/dim/mute let's add a knob for trim monitor


best

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9394 [ardour] features major always 2023-06-22 01:05 2023-06-22 01:05
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Built-in Crossover maybe plugin
Description: i described it in here
https://discourse.ardour.org/t/built-in-crossover-maybe-plugin/108874
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9391 [ardour] bugs minor always 2023-06-20 07:48 2023-06-20 07:48
Reporter: florijan Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Dragging regions to re-arrange (in stacked layer mode) doesn't behave as expected
Description: When in stacked layer mode one can drag stacked regions to re-arrange them. Two issues can occur:

1. Dragging a region that is currently below (inactive) to the top (visually displayed during dragging) will not result in that region being moved to the top.
2. Dragging a region from one track (let's call it A) to another (call it B) and back (during a single dragging event, so not releasing the mouse button) will result in the region visually positioned (while still dragging) at a position away from the cursor. This is a different position then where the region was when exiting the track (in track A, before entering B).
Tags: drang'n'drop, region, stacked, track
Steps To Reproduce: For problem 1 (see video https://drive.google.com/file/d/1-gMhYoMbWF6e1f7YupxvoFI_niJCz7Gd/view?usp=sharing):
1. Have a track in stacked layer mode.
2. Have 2 overlapping regions.
3. Have more overlapping regions in a different place, in the same track (thus forcing multiple lanes)
4. Drag the lower region just above the upper one (will be displayed visually) and release the mouse
5. Observe the lower region remained below.

For problem 2 (see video https://drive.google.com/file/d/1reXdNKLx5cJNbElRuyWFzTMfhaVk5Pn6/view?usp=sharing):
1. Have a track in stacked layer mode.
2. Have multiple overlapping regions.
3. Drag a lower one upward, exit the current track (while still dragging) and enter the upper track, return to original track (while still dragging)
4. Observe the region will be in a different position.
Additional Information: I tried to upload the videos directly to the bug report. It's 3.5MB total, but I think it's considered too large. Maybe up the limit, if that's more practical.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9389 [ardour] bugs crash have not tried 2023-06-19 14:46 2023-06-19 15:22
Reporter: moi2985 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6.9 : Recording large wav files wrong RIFF header
Description: Last saturday, I was live-recording a show. This show was 7h55 long, and I recorded it in WAV 32 bits float 48kHz.

When I stopped the record, I figured out that the data was effectively written to the disk BUT the WAV header was completely off. The consequence is that my files were showing a length of 1h42 and not 7h55, just because the wrong header was used to write the wav file so the size of the file couldn' fit the 32 bits allocated for that.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027798)
x42   
2023-06-19 15:22   
First the good news, you can recover the files with the commandline tool `sndfile-salvage` (on Ubuntu this is available from the "sndfile-programs" package).

Where did you get Ardour from? Is this the binary downloaded from ardour.org?
This includes a RF64-to-WAV feature (using libsndfile's SFC_RF64_AUTO_DOWNGRADE - I do not know if distros enable this libsndfile feature), but libsdnfile would first write w64 files, and when they do not break the 32bit index downgrade them to wav.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9388 [ardour] features minor have not tried 2023-06-19 01:35 2023-06-19 01:35
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: show pitch inside note
Description:
like this in cubase
https://steinberg.help/cubase_pro/v11/en/cubase_nuendo/trans_picts/midi_editors/key_editor_note_display.png
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: image.png (22,324 bytes) 2023-06-19 01:35
https://tracker.ardour.org/file_download.php?file_id=4580&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9387 [ardour] features minor have not tried 2023-06-18 05:50 2023-06-19 00:51
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: support jsfx plugin
Description: why not ??
support jsfx plugin like zrythm
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027796)
x42   
2023-06-18 14:33   
Or you might just use the VST3 wrapper: https://github.com/jpcima/ysfx
(0027797)
dsfdsf   
2023-06-19 00:51   
@x42
I'm tried it before post this feature in here ; often make crash / some time it cant load scripts properly
I think add a option to Ardour to support this type of plugin with/without bridge is better than it
Maybe make more stability - speed to load and easy manage plugins

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8365 [ardour] bugs minor random 2020-08-17 19:23 2023-06-18 04:13
Reporter: unfa Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Randomly introduced latency
Description: I'm using Ardour 6.2.43 (rev 6.2-43-g15fcb5c782) - I've recently noticed random latency problems on certain tracks. Suddenly my drums or bass synth would start lagging behind the click track by 0000071:0000060 ms.
At first I thought it's a problem with some plug-ins I'm using, I suspected LSP, as I've used them a lot in the affected project.

But then it happened after I added submix bus to a Black Pearl Drumkit (Multi).
The MIDI track was fed into multiple audio buses. These also send signal to 2 Reverb Buses in varying amounts.
When I've created another bus and routed all the individual channel buses to it - the whole drum line started to noticeably lag behind the rest of the track (quite a surreal sound).

Because of that I started suspecting that the problem might be caused by Ardour itself. Also - I'm not really using any plug-ins that I haven't been using in previously and I've never had such random latency introduced.

If I manually set the latency of my instrument plug-ins - it lets me compensate for it, but then the unexpected latency randomly goes away and my tracks start to rush instead of lagging.

After reloading the session - the latency problems seem to be gone, but re-appear randomly at times.

Here's a video I've quickly made to demonstrate the problem:
https://youtu.be/bWOSsuEyW0o

Can anyone reproduce this?
Tags: latency
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025163)
soundguy30   
2020-10-27 08:30   
Does it still happen when using jack or ALSA
(0025178)
x42   
2020-10-28 16:50   
Preferences > Appearance > Toolbar > Display Latency Compensation Info

Does the I/O Latency show "ambiguous latency"?
(0025180)
unfa   
2020-10-28 17:43   
I'm gonna check when I encounter this again.
(0025202)
janisl   
2020-11-06 08:17   
I have this problem all the time now. And from what I have observed it applies to all newly added tracks and buses. And the only solution is to reload the project. And doing it every time I add new track is very anoying.
(0025203)
x42   
2020-11-06 09:59   
@janisl This sounds like an issue with JACK2. Does using Ardour/ALSA (no JACK) help? Is this with Ardout 6.3.0 ?
(0025205)
janisl   
2020-11-06 12:31   
@x42 Yes, with ALSA it works fine. It's 6.3.0.
(0025210)
x42   
2020-11-09 17:14   
> After reloading the session - the latency problems seem to be gone, but re-appear randomly at times.

Could it be that you have changed jack's buffersize while Ardour is running? and from then on there were inconsistencies (existing tracks newly created ones)?
(0025214)
janisl   
2020-11-11 14:53   
I don't change buffer size, and I can reproduce this every time.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8502 [ardour] bugs minor always 2020-12-15 22:54 2023-06-18 04:12
Reporter: rosslagerwall Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.5  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Duplicate tracks are not correctly aligned
Description: If I duplicate a track and copy the playlist, one track plays ahead of the other track. This is most obvious with a drum track.

If I run, "jack_lsp -l", the issue seems to go away.

This seems to be similar to 0008304.
Tags: jack, latency
Steps To Reproduce:
Additional Information: I'm using jack as the audio backend. I compiled Ardour from the 6.5 tag.
System Description
Attached Files:
Notes
(0025945)
x42   
2021-06-12 13:23   
Is this still an issue with Ardour 6.7 ?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8575 [ardour] bugs minor sometimes 2021-02-15 09:32 2023-06-18 04:11
Reporter: unfa Platform: Ryzen PC  
Assigned To: x42 OS: Manjaro  
Priority: normal OS Version: KDE  
Status: resolved Product Version: 6.5  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Newly added audio tracks have unexpected and uncompensated latency
Description: In one session I'm working on, when I add new audio tracks seem to have extra latency (by ear it's like 30-50 ms).

I'm attaching a video demonstrating the problem.

I'm using JACK back-end.
After closing and reloading the session the latency is gone (or is successfully compensated)
Tags: latency
Steps To Reproduce:
Additional Information:
System Description
Attached Files: New track latency.ardour.zip (445,490 bytes) 2021-02-15 09:34
https://tracker.ardour.org/file_download.php?file_id=3941&type=bug
Notes
(0025520)
unfa   
2021-02-15 09:34   
I'm attaching .ardour file of a session I'm experiencing this problem within, maybe it carries something within?
(0025538)
x42   
2021-02-19 23:53   
Fixed in 6.5-264-g4a5b355d3d
(0025583)
unfa   
2021-03-03 10:37   
I've just reproduced this in 6.6.0.
(0025584)
unfa   
2021-03-03 10:38   
Audio tracks that were added in the current session have extra latency until I restart Ardour and reload the project.
Still occurs in 6.6.0.
(0025585)
x42   
2021-03-03 13:28   
Can you reproduce this reliably, or does it only happen sometimes?

Also can you can you confirm that this issue is caused by using jack2, while using jack1 (or any other Ardour backend) is fine?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8304 [ardour] bugs minor random 2020-07-11 16:13 2023-06-18 04:10
Reporter: diegobonilla4 Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Latency compensation failure
Description: When importing tracks, some of them fail in latency compensation and being in the correct position, they sound very out of phase with the other tracks, even without loading plugins on them. It is a random failure and when it has been presented to me I have not found a cause for it to happen.

However, after analyzing many ways to solve it, I found that the error goes away when the entries of the track that presents the fault are left empty.

Español:
Al importar tracks, algunos de ellos fallan en la compensación de latencia y estando en la posición correcta, suenan muy desfasados de los demás tracks, aún sin cargar plugins en ellos. Es un fallo aleatorio y cuando se me ha presentado no he encontrado una causa para que suceda.

Sin embargo, luego de analizar muchas formas para solucionarlo, encontré que el error se va cuando se deja vacío las entradas del track que presenta la falla.
Tags:
Steps To Reproduce: Importing Tracks
Additional Information:
System Description
Attached Files:
Notes
(0024711)
x42   
2020-07-11 18:59   
Are you using JACK?
If so https://discourse.ardour.org/t/duplicating-track-inverting-one-does-not-null-out-both/104396/6
(0024714)
x42   
2020-07-11 22:16   
If you were using JACK, this should be fixed in Ardour 6.2-10-gb5e479dfc3

Please test.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8384 [ardour] bugs minor sometimes 2020-08-30 13:20 2023-06-18 04:09
Reporter: mantis_n1oif Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Frequent segfaults when drawing/dragging midi track automation points
Description: I get frequent segfaults when manipulating midi track automation points. The two I've gotten in the past 15 minutes both had to do with the bender automation of a-Fluid Synth. I don't know if it's specific to this plugin or this plugin's bender automation or not.
Tags:
Steps To Reproduce: 1. Create new session
2. Add midi track
3. Add a-Fluid synth plugin
4. Add automation points to bender
5. Move them, create more, delete some... you should get a segfault in a relatively short amount of time.
Additional Information: (gdb) thread apply all bt

Thread 29 (Thread 0x7f3462101700 (LWP 285621)):
#0 0x00007f34882b7f9b in __GI___select (nfds=1, readfds=0x7f34620fec00, writefds=0x0, exceptfds=0x0, timeout=0x7f34620fec80) at ../sysdeps/unix/sysv/linux/select.c:41
0000001 0x00007f348f80606e in PBD::SystemExec::output_interposer (this=0x55c76e680800) at ../libs/pbd/system_exec.cc:995
#2 0x00007f348f8051ae in interposer_thread (arg=0x55c76e680800) at ../libs/pbd/system_exec.cc:375
#3 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000004 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 28 (Thread 0x7f33f7060700 (LWP 285805)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c7756e9020) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c7756e9020, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c7756e9020, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c7756e9020) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f3492719606 in ARDOUR::Worker::run (this=0x55c7756e9000) at ../libs/ardour/worker.cc:146
0000005 0x00007f349271a5f8 in sigc::bound_mem_functor0<void, ARDOUR::Worker>::operator() (this=0x55c7756e8448) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787
#6 0x00007f349271a540 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ARDOUR::Worker> >::operator() (this=0x55c7756e8440) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007f349271a417 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ARDOUR::Worker>, void>::call_it (rep=0x55c7756e8410) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000009 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000010 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 27 (Thread 0x7f348431ad40 (LWP 285604)):
#0 0x000055c76bad3f6b in boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > >::bind_t(boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > const&) (this=0x7ffc2515d230) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1275
0000001 0x000055c76badde4d in boost::detail::function::basic_vtable0<void>::assign_functor<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >(boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > >, boost::detail::function::function_buffer&, mpl_::bool_<false>) const (this=0x55c76cb29220 <boost::function0<void>::assign_to<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >(boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > >)::stored_vtable>, f=..., functor=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:586
#2 0x000055c76badc93e in boost::detail::function::basic_vtable0<void>::assign_to<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >(boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > >, boost::detail::function::function_buffer&, boost::detail::function::function_obj_tag) const (this=0x55c76cb29220 <boost::function0<void>::assign_to<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >(boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > >)::stored_vtable>, f=..., functor=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:617
#3 0x000055c76badaea3 in boost::detail::function::basic_vtable0<void>::assign_to<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >(boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > >, boost::detail::function::function_buffer&) const (this=0x55c76cb29220 <boost::function0<void>::assign_to<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >(boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > >)::stored_vtable>, f=..., functor=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:498
0000004 0x000055c76bad8adf in boost::function0<void>::assign_to<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >(boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD--Type <RET> for more, q to quit, c to continue without paging--c
::PropertyChange> > >) (this=0x7ffc2515d5e0, f=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:938
0000005 0x000055c76bad6468 in boost::function0<void>::function0<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >(boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > >, boost::enable_if_c<!boost::is_integral<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >::value, int>::type) (this=0x7ffc2515d5e0, f=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:725
#6 0x000055c76bad400d in boost::function<void ()>::function<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >(boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > >, boost::enable_if_c<!boost::is_integral<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, boost::_bi::list2<boost::_bi::value<boost::shared_ptr<ARDOUR::Region> >, boost::_bi::value<PBD::PropertyChange> > > >::value, int>::type) (this=0x7ffc2515d5e0, f=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:1074
#7 0x000055c76bad1ae8 in PBD::Signal2<void, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&, PBD::OptionalLastValue<void> >::compositor(boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, PBD::EventLoop*, PBD::EventLoop::InvalidationRecord*, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&) (f=..., event_loop=0x55c76e9347e0, ir=0x55c76fb24ca0, a1=..., a2=...) at libs/pbd/pbd/signals_generated.h:971
0000008 0x000055c76badcc3d in boost::_bi::list5<boost::_bi::value<boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)> >, boost::_bi::value<PBD::EventLoop*>, boost::_bi::value<PBD::EventLoop::InvalidationRecord*>, boost::arg<1>, boost::arg<2> >::operator()<void (*)(boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, PBD::EventLoop*, PBD::EventLoop::InvalidationRecord*, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&), boost::_bi::rrlist2<boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&> >(boost::_bi::type<void>, void (*&)(boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, PBD::EventLoop*, PBD::EventLoop::InvalidationRecord*, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&), boost::_bi::rrlist2<boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&>&, int) (this=0x55c77822ebf8, f=@0x55c77822ebf0: 0x55c76bad1a2d <PBD::Signal2<void, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&, PBD::OptionalLastValue<void> >::compositor(boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, PBD::EventLoop*, PBD::EventLoop::InvalidationRecord*, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, a=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:531
0000009 0x000055c76badafe8 in boost::_bi::bind_t<void, void (*)(boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, PBD::EventLoop*, PBD::EventLoop::InvalidationRecord*, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&), boost::_bi::list5<boost::_bi::value<boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)> >, boost::_bi::value<PBD::EventLoop*>, boost::_bi::value<PBD::EventLoop::InvalidationRecord*>, boost::arg<1>, boost::arg<2> > >::operator()<boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&>(boost::shared_ptr<ARDOUR::Region>&&, PBD::PropertyChange const&) (this=0x55c77822ebf0, a1=..., a2=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1318
0000010 0x000055c76bad8c68 in boost::detail::function::void_function_obj_invoker2<boost::_bi::bind_t<void, void (*)(boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)>, PBD::EventLoop*, PBD::EventLoop::InvalidationRecord*, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&), boost::_bi::list5<boost::_bi::value<boost::function<void (boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&)> >, boost::_bi::value<PBD::EventLoop*>, boost::_bi::value<PBD::EventLoop::InvalidationRecord*>, boost::arg<1>, boost::arg<2> > >, void, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&>::invoke(boost::detail::function::function_buffer&, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&) (function_obj_ptr=..., a0=..., a1=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:159
0000011 0x000055c76bade67f in boost::function2<void, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&>::operator() (this=0x55c777bbc080, a0=..., a1=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:769
0000012 0x00007f349244f566 in PBD::Signal2<void, boost::shared_ptr<ARDOUR::Region>, PBD::PropertyChange const&, PBD::OptionalLastValue<void> >::operator() (this=0x55c76cc81a40 <ARDOUR::Region::RegionPropertyChanged>, a1=..., a2=...) at libs/pbd/pbd/signals_generated.h:1080
0000013 0x00007f3492518d18 in ARDOUR::Region::send_change (this=0x55c771ba13c0, what_changed=...) at ../libs/ardour/region.cc:1497
0000014 0x00007f34923cafb0 in ARDOUR::MidiRegion::model_contents_changed (this=0x55c771ba13c0) at ../libs/ardour/midi_region.cc:683
#15 0x00007f34923cf667 in boost::_mfi::mf0<void, ARDOUR::MidiRegion>::operator() (this=0x55c777bba9f8, p=0x55c771ba13c0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
0000016 0x00007f34923cecd6 in boost::_bi::list1<boost::_bi::value<ARDOUR::MidiRegion*> >::operator()<boost::_mfi::mf0<void, ARDOUR::MidiRegion>, boost::_bi::list0> (this=0x55c777bbaa08, f=..., a=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:259
#17 0x00007f34923ce0e5 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::MidiRegion>, boost::_bi::list1<boost::_bi::value<ARDOUR::MidiRegion*> > >::operator() (this=0x55c777bba9f8) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1294
0000018 0x00007f34923cd92b in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::MidiRegion>, boost::_bi::list1<boost::_bi::value<ARDOUR::MidiRegion*> > >, void>::invoke (function_obj_ptr=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:159
0000019 0x000055c76b7cb0cc in boost::function0<void>::operator() (this=0x55c777bba9f0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:769
0000020 0x000055c76b7cad6c in PBD::Signal0<void, PBD::OptionalLastValue<void> >::operator() (this=0x55c770870148) at libs/pbd/pbd/signals_generated.h:328
0000021 0x00007f34923a0f88 in ARDOUR::MidiModel::control_list_marked_dirty (this=0x55c77086f7c0) at ../libs/ardour/midi_model.cc:1826
0000022 0x00007f3490a5cf35 in boost::_mfi::mf0<void, Evoral::ControlSet>::operator() (this=0x55c777bbc1a8, p=0x55c770870218) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
0000023 0x00007f3490a5c6a6 in boost::_bi::list1<boost::_bi::value<Evoral::ControlSet*> >::operator()<boost::_mfi::mf0<void, Evoral::ControlSet>, boost::_bi::list0> (this=0x55c777bbc1b8, f=..., a=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:259
#24 0x00007f3490a5bb53 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, Evoral::ControlSet>, boost::_bi::list1<boost::_bi::value<Evoral::ControlSet*> > >::operator() (this=0x55c777bbc1a8) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1294
0000025 0x00007f3490a5b51a in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, Evoral::ControlSet>, boost::_bi::list1<boost::_bi::value<Evoral::ControlSet*> > >, void>::invoke (function_obj_ptr=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:159
0000026 0x000055c76b7cb0cc in boost::function0<void>::operator() (this=0x55c777bbc1a0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:769
0000027 0x000055c76b7cad6c in PBD::Signal0<void, PBD::OptionalLastValue<void> >::operator() (this=0x55c770875b10) at libs/pbd/pbd/signals_generated.h:328
0000028 0x00007f3490a3f272 in Evoral::Control::list_marked_dirty (this=0x55c770875b08) at ../libs/evoral/Control.cc:84
0000029 0x00007f3490a44ebb in boost::_mfi::mf0<void, Evoral::Control>::operator() (this=0x55c777bbaab8, p=0x55c770875b08) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
0000030 0x00007f3490a44c30 in boost::_bi::list1<boost::_bi::value<Evoral::Control*> >::operator()<boost::_mfi::mf0<void, Evoral::Control>, boost::_bi::list0> (this=0x55c777bbaac8, f=..., a=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:259
0000031 0x00007f3490a446bb in boost::_bi::bind_t<void, boost::_mfi::mf0<void, Evoral::Control>, boost::_bi::list1<boost::_bi::value<Evoral::Control*> > >::operator() (this=0x55c777bbaab8) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1294
0000032 0x00007f3490a44321 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, Evoral::Control>, boost::_bi::list1<boost::_bi::value<Evoral::Control*> > >, void>::invoke (function_obj_ptr=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:159
0000033 0x000055c76b7cb0cc in boost::function0<void>::operator() (this=0x55c777bbaab0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:769
0000034 0x000055c76b7cad6c in PBD::Signal0<void, PBD::OptionalLastValue<void> >::operator() (this=0x55c7708753d0) at libs/pbd/pbd/signals_generated.h:328
0000035 0x00007f3490a4c037 in Evoral::ControlList::mark_dirty (this=0x55c770875380) at ../libs/evoral/ControlList.cc:1158
0000036 0x00007f3490a465aa in Evoral::ControlList::maybe_signal_changed (this=0x55c770875380) at ../libs/evoral/ControlList.cc:230
0000037 0x00007f3491fa9ad4 in ARDOUR::AutomationList::maybe_signal_changed (this=0x55c770875380) at ../libs/ardour/automation_list.cc:193
0000038 0x00007f3490a4bbb9 in Evoral::ControlList::modify (this=0x55c770875380, iter=Python Exception <class 'AttributeError'> 'NoneType' object has no attribute 'pointer':
, when=86.701041666666669, val=8724) at ../libs/evoral/ControlList.cc:1082
0000039 0x000055c76b8deab4 in AutomationLine::sync_model_with_view_point (this=0x55c7772c6f70, cp=...) at ../gtk2_ardour/automation_line.cc:798
0000040 0x000055c76b8dc8fa in AutomationLine::sync_model_with_view_points (this=0x55c7772c6f70, cp=Python Exception <class 'AttributeError'> 'NoneType' object has no attribute 'pointer':
std::__cxx11::list) at ../gtk2_ardour/automation_line.cc:345
0000041 0x000055c76b8de617 in AutomationLine::end_drag (this=0x55c7772c6f70, with_push=false, final_index=0) at ../gtk2_ardour/automation_line.cc:744
0000042 0x000055c76ba2d332 in ControlPointDrag::finished (this=0x55c777a68b00, event=0x7ffc2515e8f0, movement_occurred=true) at ../gtk2_ardour/editor_drag.cc:4935
0000043 0x000055c76ba11f47 in Drag::end_grab (this=0x55c777a68b00, event=0x7ffc2515e8f0) at ../gtk2_ardour/editor_drag.cc:338
0000044 0x000055c76ba1178c in DragManager::end_grab (this=0x55c77271d8b0, e=0x7ffc2515e8f0) at ../gtk2_ardour/editor_drag.cc:177
0000045 0x000055c76ba76743 in Editor::button_release_handler (this=0x55c76f8a8770, item=0x55c7772c7dd0, event=0x7ffc2515e8f0, item_type=ControlPointItem) at ../gtk2_ardour/editor_mouse.cc:1487
0000046 0x000055c76ba0acdb in Editor::typed_event (this=0x55c76f8a8770, item=0x55c7772c7dd0, event=0x7ffc2515e8f0, type=ControlPointItem) at ../gtk2_ardour/editor_canvas_events.cc:222
0000047 0x000055c76ba0bc5f in Editor::canvas_control_point_event (this=0x55c76f8a8770, event=0x7ffc2515e8f0, item=0x55c7772c7dd0, cp=0x55c7772c7c30) at ../gtk2_ardour/editor_canvas_events.cc:680
0000048 0x000055c76b931f88 in ControlPoint::event_handler (this=0x55c7772c7c30, event=0x7ffc2515e8f0) at ../gtk2_ardour/control_point.cc:91
0000049 0x000055c76b933cb4 in sigc::bound_mem_functor1<bool, ControlPoint, _GdkEvent*>::operator() (this=0x55c7772c8168, _A_a1=@0x7ffc2515e680: 0x7ffc2515e8f0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/mem_fun.h:1856
0000050 0x000055c76b933a4f in sigc::adaptor_functor<sigc::bound_mem_functor1<bool, ControlPoint, _GdkEvent*> >::operator()<_GdkEvent* const&> (this=0x55c7772c8160, _A_arg1=@0x7ffc2515e680: 0x7ffc2515e8f0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:89
0000051 0x000055c76b9333de in sigc::internal::slot_call1<sigc::bound_mem_functor1<bool, ControlPoint, _GdkEvent*>, bool, _GdkEvent*>::call_it (rep=0x55c7772c8130, a_1=@0x7ffc2515e680: 0x7ffc2515e8f0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:137
0000052 0x00007f34902a1099 in sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::operator() (this=0x7ffc2515e558, _A_slot=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/signal.h:830
0000053 0x00007f34902a0c6b in sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool>::operator* (this=0x7ffc2515e510) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/signal.h:302
0000054 0x00007f34902a04db in ArdourCanvas::Item::EventAccumulator<bool>::operator()<sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool> > (this=0x7ffc2515e57f, first=..., last=...) at ../libs/canvas/canvas/item.h:239
0000055 0x00007f349029f9d9 in sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::emit (impl=0x55c7772c80d0, _A_a1=@0x7ffc2515e680: 0x7ffc2515e8f0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/signal.h:850
0000056 0x00007f349029e4ab in sigc::signal1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::emit (this=0x55c7772c7e40, _A_a1=@0x7ffc2515e680: 0x7ffc2515e8f0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/signal.h:2797
0000057 0x00007f349029cac3 in sigc::signal1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::operator() (this=0x55c7772c7e40, _A_a1=@0x7ffc2515e680: 0x7ffc2515e8f0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/signal.h:2805
0000058 0x00007f3490297b9b in ArdourCanvas::GtkCanvas::deliver_event (this=0x55c76f016d08, event=0x7ffc2515e8f0) at ../libs/canvas/canvas.cc:773
0000059 0x00007f3490299489 in ArdourCanvas::GtkCanvas::on_button_release_event (this=0x55c76f016d08, ev=0x55c775318830) at ../libs/canvas/canvas.cc:1081
0000060 0x00007f348bd50e28 in Gtk::Widget_Class::button_release_event_callback(_GtkWidget*, _GdkEventButton*) () from /opt/Ardour-6.2.21-dbg/lib/libgtkmm-2.4.so.1
0000061 0x00007f348db6ecac in ?? () from /opt/Ardour-6.2.21-dbg/lib/libgtk-x11-2.0.so.0
0000062 0x00007f348e88a945 in g_closure_invoke () from /opt/Ardour-6.2.21-dbg/lib/libgobject-2.0.so.0
0000063 0x00007f348e89c5a0 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libgobject-2.0.so.0
0000064 0x00007f348e8a569b in g_signal_emit_valist () from /opt/Ardour-6.2.21-dbg/lib/libgobject-2.0.so.0
0000065 0x00007f348e8a6082 in g_signal_emit () from /opt/Ardour-6.2.21-dbg/lib/libgobject-2.0.so.0
0000066 0x00007f348dcf364c in ?? () from /opt/Ardour-6.2.21-dbg/lib/libgtk-x11-2.0.so.0
0000067 0x00007f348db6d29d in gtk_propagate_event () from /opt/Ardour-6.2.21-dbg/lib/libgtk-x11-2.0.so.0
0000068 0x00007f348db6d723 in gtk_main_do_event () from /opt/Ardour-6.2.21-dbg/lib/libgtk-x11-2.0.so.0
0000069 0x00007f348d789b5c in ?? () from /opt/Ardour-6.2.21-dbg/lib/libgdk-x11-2.0.so.0
0000070 0x00007f348e57bb67 in g_main_context_dispatch () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000071 0x00007f348e57bdd0 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000072 0x00007f348e57c0f2 in g_main_loop_run () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000073 0x00007f348db6c3e7 in gtk_main () from /opt/Ardour-6.2.21-dbg/lib/libgtk-x11-2.0.so.0
0000074 0x00007f348fb98898 in Gtkmm2ext::UI::run (this=0x55c76e9347e0, old_receiver=...) at ../libs/gtkmm2ext/gtk_ui.cc:293
0000075 0x000055c76bd7c6b0 in main (argc=2, argv=0x7ffc2515f518) at ../gtk2_ardour/main.cc:437

Thread 26 (Thread 0x7f34497fa700 (LWP 285680)):
#0 0x00007f34882b596f in __GI___poll (fds=0x7f341c17a810, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007f348e57bd66 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#2 0x00007f348e57c0f2 in g_main_loop_run () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#3 0x00007f348f7b6876 in BaseUI::main_thread (this=0x55c76f5e0d80) at ../libs/pbd/base_ui.cc:98
0000004 0x00007f348f7ba998 in sigc::bound_mem_functor0<void, BaseUI>::operator() (this=0x55c771040f68) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787
0000005 0x00007f348f7ba5d8 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, BaseUI> >::operator() (this=0x55c771040f60) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#6 0x00007f348f7ba019 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, BaseUI>, void>::call_it (rep=0x55c771040f30) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
#7 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000008 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000009 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000010 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 25 (Thread 0x7f3440ff9700 (LWP 285688)):
#0 0x00007f3488280361 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7f3440ff8bb0, rem=0x7f3440ff8bc0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
0000001 0x00007f3488285eb7 in __GI___nanosleep (requested_time=<optimized out>, remaining=<optimized out>) at nanosleep.c:27
#2 0x00007f348e5aca38 in g_usleep () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#3 0x00007f3491fb2ce2 in ARDOUR::AutomationWatch::thread (this=0x55c76f6f9340) at ../libs/ardour/automation_watch.cc:195
0000004 0x00007f3491fb8525 in boost::_mfi::mf0<void, ARDOUR::AutomationWatch>::operator() (this=0x55c77027e9c0, p=0x55c76f6f9340) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
0000005 0x00007f3491fb816a in boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list0> (this=0x55c77027e9d0, f=..., a=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:259
#6 0x00007f3491fb788b in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> > >::operator() (this=0x55c77027e9c0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1294
#7 0x00007f3491fb780c in sigc::adaptor_functor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> > > >::operator() (this=0x55c77027e9c0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000008 0x00007f3491fb706a in sigc::internal::slot_call0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> > >, void>::call_it (rep=0x55c77027e990) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000009 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000010 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000011 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000012 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 24 (Thread 0x7f344afd8900 (LWP 285649)):
#0 __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:736
0000001 0x00007f34885a731e in __cxxabiv1::__si_class_type_info::__do_dyncast(long, __cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info::__dyncast_result&) const () from /lib/x86_64-linux-gnu/libstdc++.so.6
#2 0x00007f34885a4f38 in __dynamic_cast () from /lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x000055c76c03893f in boost::dynamic_pointer_cast<ARDOUR::PortInsert, ARDOUR::Processor> (r=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/smart_ptr/shared_ptr.hpp:904
0000004 0x00007f349253a5d6 in ARDOUR::Route::flush_processor_buffers_locked (this=0x55c770eca400, nframes=256) at ../libs/ardour/route.cc:3808
0000005 0x00007f349252766b in ARDOUR::Route::run_route (this=0x55c770eca400, start_sample=1664614, end_sample=1664614, nframes=256, gain_automation_ok=false, run_disk_reader=false) at ../libs/ardour/route.cc:706
#6 0x00007f349253ac7e in ARDOUR::Route::no_roll_unlocked (this=0x55c770eca400, nframes=256, start_sample=1664614, end_sample=1664614, session_state_changing=true) at ../libs/ardour/route.cc:3932
#7 0x00007f34923ed4a9 in ARDOUR::MidiTrack::no_roll_unlocked (this=0x55c770eca400, nframes=256, start_sample=1664614, end_sample=1664614, state_changing=true) at ../libs/ardour/midi_track.cc:356
0000008 0x00007f349253ab5b in ARDOUR::Route::no_roll (this=0x55c770eca400, nframes=256, start_sample=1664614, end_sample=1664614, session_state_changing=true) at ../libs/ardour/route.cc:3902
0000009 0x00007f34920e5d56 in ARDOUR::Graph::process_one_route (this=0x55c76f0b8050, route=0x55c770eca400) at ../libs/ardour/graph.cc:670
0000010 0x00007f34920ea854 in ARDOUR::GraphNode::process (this=0x55c770eca8d8) at ../libs/ardour/graphnode.cc:80
0000011 0x00007f34920e5f99 in ARDOUR::GraphNode::run (this=0x55c770eca8d8, chain=0) at ../libs/ardour/ardour/graphnode.h:62
0000012 0x00007f34920e384a in ARDOUR::Graph::run_one (this=0x55c76f0b8050) at ../libs/ardour/graph.cc:442
0000013 0x00007f34920e3b94 in ARDOUR::Graph::helper_thread (this=0x55c76f0b8050) at ../libs/ardour/graph.cc:470
0000014 0x00007f34920ea131 in boost::_mfi::mf0<void, ARDOUR::Graph>::operator() (this=0x7f344afd7ef8, p=0x55c76f0b8050) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
#15 0x00007f34920e98e6 in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0> (this=0x7f344afd7f08, f=..., a=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:259
0000016 0x00007f34920e8d43 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator() (this=0x7f344afd7ef8) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1294
#17 0x00007f34920e85e7 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke (function_obj_ptr=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:159
0000018 0x000055c76b7cb0cc in boost::function0<void>::operator() (this=0x7f344afd7ef0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:769
0000019 0x00007f3463750265 in ARDOUR::AlsaAudioBackend::alsa_process_thread (arg=0x55c76f245440) at ../libs/backends/alsa/alsa_audiobackend.cc:1146
0000020 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000021 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 23 (Thread 0x7f3441ffb700 (LWP 285686)):
#0 futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x55c771409288) at ../sysdeps/nptl/futex-internal.h:183
0000001 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55c771409238, cond=0x55c771409260) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=0x55c771409260, mutex=0x55c771409238) at pthread_cond_wait.c:638
#3 0x00007f34926252f3 in ARDOUR::Session::emit_thread_run (this=0x55c7714074b0) at ../libs/ardour/session_process.cc:1110
0000004 0x00007f3492625290 in ARDOUR::Session::emit_thread (arg=0x55c7714074b0) at ../libs/ardour/session_process.cc:1099
0000005 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 22 (Thread 0x7f34417fa700 (LWP 285687)):
#0 futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x55c7714092f8) at ../sysdeps/nptl/futex-internal.h:183
0000001 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55c7714092a8, cond=0x55c7714092d0) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=0x55c7714092d0, mutex=0x55c7714092a8) at pthread_cond_wait.c:638
#3 0x00007f34925ac3fa in ARDOUR::Session::auto_connect_thread_run (this=0x55c7714074b0) at ../libs/ardour/session.cc:7060
0000004 0x00007f34925ac110 in ARDOUR::Session::auto_connect_thread (arg=0x55c7714074b0) at ../libs/ardour/session.cc:7004
0000005 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 21 (Thread 0x7f346007b900 (LWP 285645)):
#0 0x00007f3448559fba in __rt_text__start () from /usr/local/lib/lv2/gx_amp_stereo.lv2/gx_amp_stereo.so
0000001 0x00007f344853a47b in ?? () from /usr/local/lib/lv2/gx_amp_stereo.lv2/gx_amp_stereo.so
#2 0x00007f349271aad7 in lilv_instance_run (instance=0x55c775422660, sample_count=256) at ../../gtk/inst/include/lilv-0/lilv/lilv.h:1705
#3 0x00007f349272c66e in ARDOUR::LV2Plugin::run (this=0x55c7754547f0, nframes=256, sync_work=false) at ../libs/ardour/lv2_plugin.cc:3231
0000004 0x00007f349272a124 in ARDOUR::LV2Plugin::connect_and_run (this=0x55c7754547f0, bufs=..., start=1665137, end=1665137, speed=0, in_map=..., out_map=..., nframes=256, offset=0) at ../libs/ardour/lv2_plugin.cc:2883
0000005 0x00007f34924768d0 in ARDOUR::PluginInsert::connect_and_run (this=0x55c776c28ea0, bufs=..., start=1665137, end=1665137, speed=0, nframes=256, offset=0, with_auto=true) at ../libs/ardour/plugin_insert.cc:1039
#6 0x00007f3492477e21 in ARDOUR::PluginInsert::run (this=0x55c776c28ea0, bufs=..., start_sample=1665137, end_sample=1665137, speed=0, nframes=256) at ../libs/ardour/plugin_insert.cc:1241
#7 0x00007f34925265fe in ARDOUR::Route::process_output_buffers (this=0x55c771c082b0, bufs=..., start_sample=1665137, end_sample=1665137, nframes=256, gain_automation_ok=false, run_disk_reader=false) at ../libs/ardour/route.cc:519
0000008 0x00007f3492527635 in ARDOUR::Route::run_route (this=0x55c771c082b0, start_sample=1664614, end_sample=1664614, nframes=256, gain_automation_ok=false, run_disk_reader=false) at ../libs/ardour/route.cc:701
0000009 0x00007f349253ac7e in ARDOUR::Route::no_roll_unlocked (this=0x55c771c082b0, nframes=256, start_sample=1664614, end_sample=1664614, session_state_changing=true) at ../libs/ardour/route.cc:3932
0000010 0x00007f349253ab5b in ARDOUR::Route::no_roll (this=0x55c771c082b0, nframes=256, start_sample=1664614, end_sample=1664614, session_state_changing=true) at ../libs/ardour/route.cc:3902
0000011 0x00007f34920e5d56 in ARDOUR::Graph::process_one_route (this=0x55c76f0b8050, route=0x55c771c082b0) at ../libs/ardour/graph.cc:670
0000012 0x00007f34920ea854 in ARDOUR::GraphNode::process (this=0x55c771c08788) at ../libs/ardour/graphnode.cc:80
0000013 0x00007f34920e5f99 in ARDOUR::GraphNode::run (this=0x55c771c08788, chain=0) at ../libs/ardour/ardour/graphnode.h:62
0000014 0x00007f34920e384a in ARDOUR::Graph::run_one (this=0x55c76f0b8050) at ../libs/ardour/graph.cc:442
#15 0x00007f34920e3f76 in ARDOUR::Graph::main_thread (this=0x55c76f0b8050) at ../libs/ardour/graph.cc:523
0000016 0x00007f34920ea131 in boost::_mfi::mf0<void, ARDOUR::Graph>::operator() (this=0x7f346007aef8, p=0x55c76f0b8050) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
#17 0x00007f34920e98e6 in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0> (this=0x7f346007af08, f=..., a=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:259
0000018 0x00007f34920e8d43 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator() (this=0x7f346007aef8) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1294
0000019 0x00007f34920e85e7 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke (function_obj_ptr=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:159
0000020 0x000055c76b7cb0cc in boost::function0<void>::operator() (this=0x7f346007aef0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:769
0000021 0x00007f3463750265 in ARDOUR::AlsaAudioBackend::alsa_process_thread (arg=0x55c771525750) at ../libs/backends/alsa/alsa_audiobackend.cc:1146
0000022 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000023 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 20 (Thread 0x7f34600ab900 (LWP 285643)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c76e7d53e0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c76e7d53e0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c76e7d53e0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c76e7d53e0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f349256f6db in ARDOUR::RTTaskList::run (this=0x55c76e7d53b0) at ../libs/ardour/rt_tasklist.cc:112
0000005 0x00007f349256f4c8 in ARDOUR::RTTaskList::_thread_run (arg=0x55c76e7d53b0) at ../libs/ardour/rt_tasklist.cc:68
#6 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 19 (Thread 0x7f34427fc700 (LWP 285685)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c770f07720) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c770f07720, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c770f07720, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c770f07720) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f3492719606 in ARDOUR::Worker::run (this=0x55c770f07700) at ../libs/ardour/worker.cc:146
0000005 0x00007f349271a5f8 in sigc::bound_mem_functor0<void, ARDOUR::Worker>::operator() (this=0x55c770f1f938) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787
#6 0x00007f349271a540 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ARDOUR::Worker> >::operator() (this=0x55c770f1f930) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007f349271a417 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ARDOUR::Worker>, void>::call_it (rep=0x55c770f1f900) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000009 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000010 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 18 (Thread 0x7f3442ffd700 (LWP 285684)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c77128b280) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c77128b280, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c77128b280, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c77128b280) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f3492719606 in ARDOUR::Worker::run (this=0x55c77128b260) at ../libs/ardour/worker.cc:146
0000005 0x00007f349271a5f8 in sigc::bound_mem_functor0<void, ARDOUR::Worker>::operator() (this=0x55c7712a3498) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787
#6 0x00007f349271a540 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ARDOUR::Worker> >::operator() (this=0x55c7712a3490) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007f349271a417 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ARDOUR::Worker>, void>::call_it (rep=0x55c7712a3460) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000009 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000010 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 17 (Thread 0x7f3460033900 (LWP 285647)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c76f0b8100) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c76f0b8100, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c76f0b8100, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c76f0b8100) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f34920e36dc in ARDOUR::Graph::run_one (this=0x55c76f0b8050) at ../libs/ardour/graph.cc:426
0000005 0x00007f34920e3b94 in ARDOUR::Graph::helper_thread (this=0x55c76f0b8050) at ../libs/ardour/graph.cc:470
#6 0x00007f34920ea131 in boost::_mfi::mf0<void, ARDOUR::Graph>::operator() (this=0x7f3460032ef8, p=0x55c76f0b8050) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
#7 0x00007f34920e98e6 in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0> (this=0x7f3460032f08, f=..., a=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:259
0000008 0x00007f34920e8d43 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator() (this=0x7f3460032ef8) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1294
0000009 0x00007f34920e85e7 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke (function_obj_ptr=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:159
0000010 0x000055c76b7cb0cc in boost::function0<void>::operator() (this=0x7f3460032ef0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/function/function_template.hpp:769
0000011 0x00007f3463750265 in ARDOUR::AlsaAudioBackend::alsa_process_thread (arg=0x55c77101ee50) at ../libs/backends/alsa/alsa_audiobackend.cc:1146
0000012 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000013 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 16 (Thread 0x7f346157d700 (LWP 285624)):
#0 0x00007f34882b596f in __GI___poll (fds=0x7f3450000b60, nfds=1, timeout=200) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007f3463751100 in ARDOUR::AlsaAudioBackend::midi_device_thread (this=0x55c76e9b9880) at ../libs/backends/alsa/alsa_audiobackend.cc:1339
#2 0x00007f3463750f98 in ARDOUR::AlsaAudioBackend::_midi_device_thread (arg=0x55c76e9b9880) at ../libs/backends/alsa/alsa_audiobackend.cc:1302
#3 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000004 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 15 (Thread 0x7f344b7fe700 (LWP 285683)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c7717dd2a0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c7717dd2a0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c7717dd2a0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c7717dd2a0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f3492719606 in ARDOUR::Worker::run (this=0x55c7717dd280) at ../libs/ardour/worker.cc:146
0000005 0x00007f349271a5f8 in sigc::bound_mem_functor0<void, ARDOUR::Worker>::operator() (this=0x55c7717f54b8) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787
#6 0x00007f349271a540 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ARDOUR::Worker> >::operator() (this=0x55c7717f54b0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007f349271a417 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ARDOUR::Worker>, void>::call_it (rep=0x55c7717f5480) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000009 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000010 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 14 (Thread 0x7f344bfff700 (LWP 285804)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c775433d00) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c775433d00, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c775433d00, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c775433d00) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f3492719606 in ARDOUR::Worker::run (this=0x55c775433ce0) at ../libs/ardour/worker.cc:146
0000005 0x00007f349271a5f8 in sigc::bound_mem_functor0<void, ARDOUR::Worker>::operator() (this=0x55c775433dd8) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787
#6 0x00007f349271a540 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ARDOUR::Worker> >::operator() (this=0x55c775433dd0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007f349271a417 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ARDOUR::Worker>, void>::call_it (rep=0x55c775433da0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000009 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000010 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 13 (Thread 0x7f344a7fc700 (LWP 285681)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c7721853f0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c7721853f0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c7721853f0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c7721853f0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f3492719606 in ARDOUR::Worker::run (this=0x55c7721853d0) at ../libs/ardour/worker.cc:146
0000005 0x00007f349271a5f8 in sigc::bound_mem_functor0<void, ARDOUR::Worker>::operator() (this=0x55c77219c858) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787
#6 0x00007f349271a540 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ARDOUR::Worker> >::operator() (this=0x55c77219c850) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007f349271a417 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ARDOUR::Worker>, void>::call_it (rep=0x55c77219c820) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000009 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000010 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 12 (Thread 0x7f3449ffb700 (LWP 285682)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c77041ffe0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c77041ffe0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c77041ffe0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c77041ffe0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f3492719606 in ARDOUR::Worker::run (this=0x55c77041ffc0) at ../libs/ardour/worker.cc:146
0000005 0x00007f349271a5f8 in sigc::bound_mem_functor0<void, ARDOUR::Worker>::operator() (this=0x55c7704381f8) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787
#6 0x00007f349271a540 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ARDOUR::Worker> >::operator() (this=0x55c7704381f0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007f349271a417 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ARDOUR::Worker>, void>::call_it (rep=0x55c7704381c0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000009 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000010 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 11 (Thread 0x7f34600db900 (LWP 285639)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c76e7d53e0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c76e7d53e0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c76e7d53e0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c76e7d53e0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f349256f6db in ARDOUR::RTTaskList::run (this=0x55c76e7d53b0) at ../libs/ardour/rt_tasklist.cc:112
0000005 0x00007f349256f4c8 in ARDOUR::RTTaskList::_thread_run (arg=0x55c76e7d53b0) at ../libs/ardour/rt_tasklist.cc:68
#6 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 10 (Thread 0x7f347096c700 (LWP 285616)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007f348e5cce4c in g_cond_wait () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#2 0x00007f3491f5923b in ARDOUR::AudioEngine::do_devicelist_update (this=0x55c76e8bb7e0) at ../libs/ardour/audioengine.cc:703
#3 0x00007f3491f66371 in boost::_mfi::mf0<void, ARDOUR::AudioEngine>::operator() (this=0x55c76ea492a0, p=0x55c76e8bb7e0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
0000004 0x00007f3491f65da0 in boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list0> (this=0x55c76ea492b0, f=..., a=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:259
0000005 0x00007f3491f654dd in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >::operator() (this=0x55c76ea492a0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1294
#6 0x00007f3491f64cdc in sigc::adaptor_functor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > > >::operator() (this=0x55c76ea492a0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007f3491f63e9a in sigc::internal::slot_call0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >, void>::call_it (rep=0x55c76ea49270) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000009 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000010 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 9 (Thread 0x7f34600c3900 (LWP 285641)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c76e7d53e0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c76e7d53e0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c76e7d53e0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c76e7d53e0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f349256f6db in ARDOUR::RTTaskList::run (this=0x55c76e7d53b0) at ../libs/ardour/rt_tasklist.cc:112
0000005 0x00007f349256f4c8 in ARDOUR::RTTaskList::_thread_run (arg=0x55c76e7d53b0) at ../libs/ardour/rt_tasklist.cc:68
#6 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 8 (Thread 0x7f3460cca700 (LWP 285626)):
#0 0x00007f34882b596f in __GI___poll (fds=0x55c76f1e7280, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007f348e57bd66 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#2 0x00007f348e57be7c in g_main_context_iteration () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#3 0x00007f348e57bec1 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000004 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000005 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7f3480af4700 (LWP 285615)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007f348e5cce4c in g_cond_wait () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#2 0x00007f3491f59002 in ARDOUR::AudioEngine::do_reset_backend (this=0x55c76e8bb7e0) at ../libs/ardour/audioengine.cc:667
#3 0x00007f3491f66371 in boost::_mfi::mf0<void, ARDOUR::AudioEngine>::operator() (this=0x55c76e433cc0, p=0x55c76e8bb7e0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
0000004 0x00007f3491f65da0 in boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list0> (this=0x55c76e433cd0, f=..., a=...) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:259
0000005 0x00007f3491f654dd in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >::operator() (this=0x55c76e433cc0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/bind/bind.hpp:1294
#6 0x00007f3491f64cdc in sigc::adaptor_functor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > > >::operator() (this=0x55c76e433cc0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007f3491f63e9a in sigc::internal::slot_call0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >, void>::call_it (rep=0x55c76e433c90) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000009 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000010 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 6 (Thread 0x7f346188e900 (LWP 285623)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55c76f0b8148) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55c76f0b8148, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007f348a6a14e8 in __new_sem_wait_slow (sem=0x55c76f0b8148, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007f34920e5f40 in PBD::Semaphore::wait (this=0x55c76f0b8148) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007f34920e5a93 in ARDOUR::Graph::routes_no_roll (this=0x55c76f0b8050, nframes=256, start_sample=1664614, end_sample=1664614, non_rt_pending=true) at ../libs/ardour/graph.cc:654
0000005 0x00007f34926211b4 in ARDOUR::Session::no_roll (this=0x55c7714074b0, nframes=256) at ../libs/ardour/session_process.cc:186
#6 0x00007f3492623549 in ARDOUR::Session::process_without_events (this=0x55c7714074b0, nframes=256) at ../libs/ardour/session_process.cc:648
#7 0x00007f34926229f4 in ARDOUR::Session::process_with_events (this=0x55c7714074b0, nframes=256) at ../libs/ardour/session_process.cc:481
0000008 0x00007f3492620a79 in ARDOUR::Session::process (this=0x55c7714074b0, nframes=256) at ../libs/ardour/session_process.cc:97
0000009 0x00007f3491f58707 in ARDOUR::AudioEngine::process_callback (this=0x55c76e8bb7e0, nframes=256) at ../libs/ardour/audioengine.cc:492
0000010 0x00007f346375478c in ARDOUR::AlsaAudioBackend::main_process_thread (this=0x55c76e9b9880) at ../libs/backends/alsa/alsa_audiobackend.cc:1900
0000011 0x00007f346374de6d in pthread_process (arg=0x55c76e9b9880) at ../libs/backends/alsa/alsa_audiobackend.cc:763
0000012 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000013 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 5 (Thread 0x7f348245d700 (LWP 285612)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007f348e5cce4c in g_cond_wait () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#2 0x00007f34926b57b4 in peak_thread_work () at ../libs/ardour/source_factory.cc:74
#3 0x000055c76c04d545 in sigc::pointer_functor0<void>::operator() (this=0x55c76e44a618) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
0000004 0x000055c76c04a678 in sigc::adaptor_functor<sigc::pointer_functor0<void> >::operator() (this=0x55c76e44a610) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000005 0x000055c76c046501 in sigc::internal::slot_call0<sigc::pointer_functor0<void>, void>::call_it (rep=0x55c76e44a5e0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
#6 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
#7 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000008 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000009 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7f348345f700 (LWP 285610)):
#0 0x00007f3488280361 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7f348345ebf0, rem=0x7f348345ec00) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
0000001 0x00007f3488285eb7 in __GI___nanosleep (requested_time=<optimized out>, remaining=<optimized out>) at nanosleep.c:27
#2 0x00007f348e5aca38 in g_usleep () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#3 0x000055c76c3ca5bc in gui_event_loop (ptr=0x0) at ../gtk2_ardour/linux_vst_gui_support.cc:463
0000004 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000005 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7f3482c5e700 (LWP 285611)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007f348e5cce4c in g_cond_wait () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#2 0x00007f34926b57b4 in peak_thread_work () at ../libs/ardour/source_factory.cc:74
#3 0x000055c76c04d545 in sigc::pointer_functor0<void>::operator() (this=0x55c76e44ac88) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
0000004 0x000055c76c04a678 in sigc::adaptor_functor<sigc::pointer_functor0<void> >::operator() (this=0x55c76e44ac80) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000005 0x000055c76c046501 in sigc::internal::slot_call0<sigc::pointer_functor0<void>, void>::call_it (rep=0x55c76e44ac50) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
#6 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
#7 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000008 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000009 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f3481c5c700 (LWP 285613)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007f348e5cce4c in g_cond_wait () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
#2 0x00007f3491f0d124 in ARDOUR::Analyser::work () at ../libs/ardour/analyser.cc:93
#3 0x00007f3491f0cf10 in analyser_work () at ../libs/ardour/analyser.cc:58
0000004 0x000055c76c04d545 in sigc::pointer_functor0<void>::operator() (this=0x55c76e44a428) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
0000005 0x000055c76c04a678 in sigc::adaptor_functor<sigc::pointer_functor0<void> >::operator() (this=0x55c76e44a420) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#6 0x000055c76c046501 in sigc::internal::slot_call0<sigc::pointer_functor0<void>, void>::call_it (rep=0x55c76e44a3f0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
#7 0x00007f348eb15c4d in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglibmm-2.4.so.1
0000008 0x00007f348e5ab1e5 in ?? () from /opt/Ardour-6.2.21-dbg/lib/libglib-2.0.so.0
0000009 0x00007f348a697609 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000010 0x00007f34882c2103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f344af1a700 (LWP 285679)):
#0 0x00007f3490a4de45 in Evoral::ControlList::rt_safe_earliest_event_linear_unlocked (this=0x55c770875380, start=22.827799006255049, x=@0x7f344af17b20: 0, y=@0x7f344af17b18: 0, inclusive=false) at ../libs/evoral/ControlList.cc:1671
0000001 0x00007f3490a719db in Evoral::Sequence<Temporal::Beats>::const_iterator::operator++ (this=0x7f344af189f0) at ../libs/evoral/Sequence.cc:372
#2 0x00007f34923dce96 in ARDOUR::MidiSource::midi_read (this=0x55c77086f220, lm=..., dst=..., source_start=-329130, start=329130, cnt=9760420, loop_range=0x0, cursor=..., tracker=0x7f344af181e0, filter=0x55c7711a1950, filtered=std::set with 0 elements, pos_beats=0, start_beats=15.999390999390997) at ../libs/ardour/midi_source.cc:246
#3 0x00007f34923ca351 in ARDOUR::MidiRegion::render (this=0x55c771bb9690, dst=..., chan_n=0, mode=ARDOUR::Sustained, filter=0x55c7711a1950) at ../libs/ardour/midi_region.cc:549
0000004 0x00007f34923c0b78 in ARDOUR::MidiPlaylist::render (this=0x55c771bb89f0, filter=0x55c7711a1950) at ../libs/ardour/midi_playlist.cc:356
System Description
Attached Files:
Notes
(0024991)
x42   
2020-08-31 05:42   
Potentially fixed in Ardour 6.2-230-gb9cfb31205 - please test.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8601 [ardour] bugs minor random 2021-03-03 12:42 2023-06-18 04:08
Reporter: unfa Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on attempting to slide an audio region with mouse
Description: Ardour 6.6.56 dbg crashed when I attempted to move a region with my mouse after sing timestretch a lot).

I am attaching full gdb backtrace.
Tags: crash
Steps To Reproduce:
Additional Information:
System Description
Attached Files: gdb.log (186,488 bytes) 2021-03-03 12:42
https://tracker.ardour.org/file_download.php?file_id=3962&type=bug
Notes
(0025737)
paul   
2021-04-22 00:18   
If this is reproducible, can you run from the command line with -D audioplayback and attach the output?
(0025865)
x42   
2021-05-18 02:22   
Is this still an issue with 6.6-554-g8cd8d90483
(0025866)
x42   
2021-05-18 02:23   
PS. This was likely fixed in 6.6-491-gdcc0f1cb17

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5100 [ardour] features major have not tried 2012-09-10 15:33 2023-06-18 04:06
Reporter: colinf Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 3.X  
Summary: MIDI regions are always transparent
Description: When two or more MIDI regions overlap, notes from all overlapping regions play, regardless of the opacity of the upper regions.

I think that:
 (a) the opacity of MIDI regions should be choosable
 (b) they should be opaque by default

This would make them behave just like audio regions, which I think would be much less confusing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014081)
paul   
2012-10-17 22:26   
this is a very deep problem.
(0014553)
colinf   
2013-01-22 11:58   
I know this is unlikely to be implemented before 3.0.

However, I'd request that for the moment, MIDI regions be explicitly marked as transparent (and maybe not allowed to be made opaque).

That way, if some future version of A3 does allow opaque MIDI regions, sessions containing overlapping MIDI regions will continue to sound the same when loaded.
(0020615)
colinf   
2019-03-20 23:14   
This still bugs me, six years later...
(0024326)
inFlowiaLab   
2020-05-31 18:17   
The problem is still relevant. Without its solution, working with MIDI takes is very unproductive. You have to mute every take except for the active one. This is slow, and it is completely different from recording takes of ordinary non-MIDI sound.
(0024327)
paul   
2020-05-31 18:45   
I wonder why I said this was so deep.
(0024328)
paul   
2020-05-31 18:52   
Oh, I see why.

The earliest/leftmost boundary of a currently-topmost MIDI region has to act as an "all notes off" for every note currently on.

This is trivial if every region completely covers all the ones below it. But if they are "staggered", then this becomes quite challenging. There is also the question of what happens to notes in a lower region that span the entire length of the upper region.

so yeah, inFlowiaLab, I understand why this is tricky for your workflow. But its quite hard to solve for the general case, and when we don't do that, people will run into those scenarios very often. In your case, since you appear to be completely "covering" one take with another, I would just delete the existing region (it isn't deleted from the session or disk) or switch to a new playlist.
(0024329)
inFlowiaLab   
2020-05-31 19:20   
> "There is also the question of what happens to notes in a lower region that span the entire length of the upper region."

It should sound until the upper region begins. Then she must shut up forever.

> "In your case, since you appear to be completely "covering" one take with another, I would just delete the existing region (it isn't deleted from the session or disk) or switch to a new playlist."

But I do not want to delete the recorded duplicates until I decided which one suits me. I record several takes, listen to them several times, choose the best one and leave it. And while I choose with MIDI clips, I have to drown out all the duplicates except one, listen to it, then drown it out, turn on another, listen to it, drown it out to turn on another and so on. With AUDIO thoughts, everything is simpler - I listen to the upper double, then I select another and raise it up - and it already sounds, I do not need to drown out all the doubles. Just pick the one you want and go up.

I'm not sure if using playlists to record takes is a good idea. Is there really a way to record duplicates in a loop, automatically placing each in its own separate playlist, and then quickly switch between playlists when choosing the best take? (As fast as this can be done with layers of AUDIO clips.)
(0026573)
colinf   
2022-09-09 22:51   
Looks like this is now implemented in edd78000 (& preceding), though I haven't tried it yet...
(0026574)
x42   
2022-09-11 00:01   
As of Ardour 7.0-pre0-3455-g38c5ae4237 layered obscured MIDI regions is now fully implemented.

At the start of an opaque region above a lower region, pitch-bend and CCs values that were modified by a lower regions are either reset or restored to the the prior state (if available).
The main motivation here is to provide an easy way to loop-record and comp with consistency.

Please test.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8153 [ardour] bugs minor always 2020-05-27 11:29 2023-06-18 00:56
Reporter: Dirk Offringa Platform: Windows 10  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: Mixbus 6.x  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi Real Time messages are sent too early (Mixbus AND Ardour)
Description:
I’m using Mixbus 32c V6.à.655 on Win10, 48k, 1024 buffersize, ASIO. I have an issue with the midiclock and/or the start/continue messages. They start/continue messages are always sent too early in relation to the grid, and this offset seems to be related to some latency compensation: if I insert a plugin that needs PDC (even the limiter on the main bus) the start/continue messages are issued even earlier but I did not identify a clear sample-accurate pattern. I spent countless hours checking every possibility I could think of, and reported the issue to Harrison support. as well. On the other hand, audio latency compensation is spot on: I have correctly calibrated the audio hardware and it’s sample accurate.

When using the midi device calibration results, the offset is worse than when leaving them at default 0.

The Real Time start/continue/stop messages should be sent when the actual audio starts to sound, so that synced external sequencers are synced to the recorded audio. This means that all latency compensation should apply to these RT messages too. This seems not to be the case. When a external sequencer receives a start message, and we record its (audio) metronome, the record metronome shoul be perfectly aligned on the grid.

I downloaded Ardour to doublecheck and it has the same behaviour.

Please note this is MidiClock, not MTC.

Tags:
Steps To Reproduce: Make sure audio and midi have been calibrated. Patch midiclock to the midiport a sequencer is connected to. Patch the sequencer's audio click output into a audio interface input, and connect to a Ardour track. Start Ardour and record that click. Check if the click is aligned on the grid.

Even when routing internally, there's an issue:

Patch Ardour click to an audio track input, record metronome. Check if the click is aligned on the grid.
Additional Information:
System Description
Attached Files: ardour midiclock latency.JPG (54,434 bytes) 2020-08-26 12:04
https://tracker.ardour.org/file_download.php?file_id=3811&type=bug
jpg

Ardour sync test.JPG (68,679 bytes) 2020-08-28 09:26
https://tracker.ardour.org/file_download.php?file_id=3814&type=bug
jpg

Ardour Align clicks.JPG (38,015 bytes) 2020-08-28 09:30
https://tracker.ardour.org/file_download.php?file_id=3815&type=bug
jpg

alignment options.JPG (48,075 bytes) 2020-08-28 19:17
https://tracker.ardour.org/file_download.php?file_id=3816&type=bug
jpg

ardour click plus DN click.JPG (23,289 bytes) 2020-08-28 20:10
https://tracker.ardour.org/file_download.php?file_id=3817&type=bug
jpg
Notes
(0024331)
x42   
2020-05-31 22:47   
This should be fixed since Ardour 6.0-44-gef94663d1c

The main problem was that Ardour just sent start/continue message instantly, and not at MIDI Clock downbeats. Nor was the clock every in sync with music-time beats.
In all versions prior to 6.0.44 Ardour just used it to indicate [clock] speed (and state).
(0024961)
Dirk Offringa   
2020-08-26 12:04   
Hi, following up on a thread on the forum: I downloaded the latest version and noticed the change. BUT: now externally synced gear is ONE buffer late. It's an improvement over the earlier situation, where it was always early and randomly so. The current issue is reproductible, not random: one buffer. I experience SOME extra offset, but didn't identify it yet and it might be due to my own hardware.
(0024962)
Dirk Offringa   
2020-08-26 14:04   
I want to add that the I/O latency calibration for the midi ports has no effect whatsoever on the RT messages, IMHO it should be!
(0024963)
x42   
2020-08-26 15:54   
Thanks for the feedback! So we're making progress at least.

> I want to add that the I/O latency calibration for the midi ports has no effect whatsoever on the RT messages.

Odd, It has an effect here. Both Audio and MIDi calibration are in use and port latencies are set correctly.

Ardour's clock is aligned to the master-bus's output (incl. playback latency). The clock (and playhead position) matches "what you hear at the speakers".
The MIDI signal is likewise aligned, and sent early by difference of Audio - MIDI port playback latency.

However we can only measure **round-trip** latency (MIDI out -> MIDI in, Audio out -> Audio in), the absolute alignment of MIDI-out -> Audio in is unknown.



> BUT: now externally synced gear is ONE buffer late.

That is interesting. Could you describe your test setup? It'd be great if I could reproduce it somehow.
Are you perhaps directly feeding Ardour's MIDI clock output back into an Ardour Audio port? That could explain the 1 cycle offset.
 
Can you test this independently?
Play back this Ardour session. Record the audio of the slaved synth and Ardour's master-bus audio output with a different device (or an independent Ardour session) and see if the audio aligns.
I'd also start at a time other than 00:00:00:00 first.

This tests alignment of Audio out vs MIDI out. It'd be interesting if this is exactly half of the buffer-size.. or if it aligns.
(0024964)
Dirk Offringa   
2020-08-26 18:42   
I just spent over an hour typing in a detailed report bu my session expired and all was lost.
(0024970)
Dirk Offringa   
2020-08-28 09:26   
I take some time to redo my lost report (I've a very tight schedule ATM)

In the screenshot below, you see two lanes.

These are recordings of the (stereo) output of a Elektron Analog Keys, that has a Minibrute2S connected to it's external input, so the both synths are mixed to the same output, and thus using the same input on the mixer, and sent over the same direct-out USB channel, so record on the same track.
Audio path: AK+MB2S => Soundcraft mixer with USB/MADI card=> USB out => Ardour. Buffer size set to 1024.

The downward square pulse is the AK click, the other, longer "squirp" sound is the MB2S metronome "click".

LANE ON TOP: both synths are clocked by Ardours midi clock (via a iConnectivity iCM4+ interface/router). The orange line on the left is the playback head position on the beat. Both clocks are 1 buffer late.

LANE ON BOTTOM: AK remains clocked by Ardour midi clock. The MB2S is clocked over it's analog clock input. To do so I use the ERM VST plugin (usually used by their MultiClock) that outputs audio pulses as soon as the sequencer is running (it reads a looping audio file, AFAIK). The audio from that track is patched to a output of the Souncraft desk and then into the MB2S clock input.
This clock is right on the beat as expected, and the AK click didn't move (as expected too)

This illustrates the issue perfectly.
(0024971)
Dirk Offringa   
2020-08-28 09:30   
"Can you test this independently?
Play back this Ardour session. Record the audio of the slaved synth and Ardour's master-bus audio output with a different device (or an independent Ardour session) and see if the audio aligns.
I'd also start at a time other than 00:00:00:00 first.

This tests alignment of Audio out vs MIDI out. It'd be interesting if this is exactly half of the buffer-size.. or if it aligns. "


I recorded the main output of my mixer, with the recorded click playing, and the synced live-click. They (almost) align. (Give or take some jitter). On top: the recorded click, bottom: recorded+live
(0024972)
x42   
2020-08-28 16:46   
Thanks this is good information!

So in summary:

1. When playing, MIDI-clock and audio playback are aligned. (give of take expected MIDI jitter of ~1ms)
2. Absolute alignment with time grid is off by 1 process cycle (buffer-size samples).

I still do not know if the offset happens when recording or during playback.

When you did the AK and MB2S test, have you recorded the result with a separate Ardour instance, or the same Ardour instance that also produced the MIDI clock?
If the latter, you will have to change the track's input to use "Alignment: Align with capture time" (track header context menu), since Ardour cannot deduce the connection.

PS. VST2.x bar/beat timestamps are not latency compensated in Ardour 6, so they will be early by the playback latency, usually 1 cycle early, minus a few samples.
This is usually not an issue for VST2 synths producing audio, but VST MIDI outputs will be offset. (So far only LV2 and AU are correctly aligned to music-time), and in your case you're just lucky that this cancels out.
(0024973)
Dirk Offringa   
2020-08-28 19:10   
"When you did the AK and MB2S test, have you recorded the result with a separate Ardour instance, or the same Ardour instance that also produced the MIDI clock?"
The same instance, Ardour crashes when attempting to launch a second instance, probably a Windows issue , related to the ASIO driver

"VST2.x bar/beat timestamps are not latency compensated in Ardour 6, so they will be early by the playback latency, usually 1 cycle early, minus a few samples."
I don't use any Virtual instruments, just reverbs and delays. I use midi only for the clock sync (but I might need to go for a ERM multiclock if we can't sort this out in a reasonable time window ;-) )

"I still do not know if the offset happens when recording or during playback."

During recording for sure, otherwise it wouldn't show on my screenshots. On playback without recording, I'll try to do the test using another recorder when I manage to free up some time to repatch stuff
(0024974)
Dirk Offringa   
2020-08-28 19:17   
"If the latter, you will have to change the track's input to use "Alignment: Align with capture time" (track header context menu), since Ardour cannot deduce the connection."

If I set alignment to "capture time" the offset becomes ridicoulouly high, if I leave it on "auto" it looks good

TOP LANE: aligned to "capture time"
BOTTOM LANE: aligned auto ("existing material" whatever that means)

Both are AK (DIN MIDI) +MB2S (ANALOG MIDI)

I recorded the main output of my desk with a synth live + it's recording but the result is the same as what I reported above: I don't see how this can be any different. Maybe I do not understand what you want me to do here
(0024975)
Dirk Offringa   
2020-08-28 19:20   
I said "I recorded the main output of my desk with a synth live + it's recording but the result is the same as what I reported above: I don't see how this can be any different. Maybe I do not understand what you want me to do here" but I actually do understand: it doesn't matter if Ardour is recording or only playing back: both the recording and and the live sound remain aligned in both cases.
(0024976)
x42   
2020-08-28 19:21   
Ah yeah, Windows/ASIO mandates exclusive access. So a second soundcard would be needed.

Regarding VST2.x offset, I meant "ERM multiclock" in Ardour.
When doing playback alignment tests, you could also check the output of Ardour's metronome along with alignment audio/midi playback.

If all playback is in sync (give or take some small MIDI jitter), then I'm happy. -- The only clue I currently have is that capture alignment is not correctly set.
I'll investigate, but I cannot provide any ETA when this can be sorted out. I'll likely have to acquire and dust off some equipment to check for myself.
(0024977)
Dirk Offringa   
2020-08-28 19:30   
Ok, let me know If I can some more. I appreciate your implication, thanks for this!
(0024978)
x42   
2020-08-28 19:31   
" it doesn't matter if Ardour is recording or only playing back"

No, I was thinking of the simple most setup using external validation. When you're on stage what matters is what comes out of the speakers. So I was suggesting to test if everything lines up there.

When you play some Audio track, and record it back onto a different track in Ardour it should align. That is usually guaranteed by measuring can calibrating latency.
So I'm surprised that there can be an offset since above you've shown in Ardour Align clicks.JPG that playback is aligned.

Something doesn't add up.
(0024979)
Dirk Offringa   
2020-08-28 20:10   
Here's Ardour's own metronome plus a synth's metronome synced to Ardour over DIN MIDI (the square pulse). The Ardour metronome is spot on.
(0024981)
Dirk Offringa   
2020-08-28 20:46   
Oh, and BTW:
"> I want to add that the I/O latency calibration for the midi ports has no effect whatsoever on the RT messages.

Odd, It has an effect here. Both Audio and MIDi calibration are in use and port latencies are set correctly."

I double/triple checked with both normal and totally insane values and can confirm that Start/Stop messages are not affected at all by these settings. If they were, my current issue would be a no-brainer: I would have set an output latency value and that's it, and I could even do thi on a per-port basis to align synths with slightly different response times!
(0024982)
Dirk Offringa   
2020-08-29 22:51   
Hi Robin, I figured out a way to accurately sync my external gear to Mixbus/Ardour. By "accurate" I mean really accurate: I have 6 sequencers/drum machines running at once, I record each on different tracks and when playing back the recording WHILE leatting the sequencers run alongside in sync there's no phasing and everything is on the grid so I can punch in/out without cutting off the head of a kick . That's what I need. But I used Elektron's Overbridge to do this, via a Digitone synth which puts out the midi clock. By adjusting it's extensive buffer management I managed to precisely glue the beats to the grid (within the limits of each device, they all have some inherent latency of a couple of samples).

 So for now I can get to work again without needing to manually align each take. I guess Overbridge sync is sample-based like the ERM solution, but it talks directly to the Elektron hardware over USB so it bypasses the audio interface altogether. Of course if you need more information I'm OK to do more testing and help a bit if I can. Ardour/mixbus is already pretty good at aligning stuff (I compared briefly to others DAW's I have and they are far worse as far as midi sync goes!), it's actually near-perfect, if you guys could only fix this issue it would be amongst the best out there. (And get the midi-latency compensation to work would be nice too.... )

Cheers, and thanks for the great job you all do here!
(0024990)
x42   
2020-08-30 23:24   
The capture alignment was fixed in 6.2-227-gb326b8e462 (now systemic MIDI latency is correctly offset), and the bug also explain perfectly why the offset was always a multiple of the buffer-size.
In my prior tests I was just lucky that it was zero * buffer-size.
(0024992)
Dirk Offringa   
2020-08-31 06:23   
Hey that's good news! So my findings were correct.... that's reassuring. Thanks!
(0024997)
Dirk Offringa   
2020-09-01 09:19   
Hi Robin, where can I download that build? I downloaded the official release but it is stil 6.2.0 and do you know when there will be a official MixBus build with this fix? (or do I need to talk to Ben at Harrison about it?)

Thanks!
(0024998)
x42   
2020-09-01 10:08   
https://nightly.ardour.org/ -- It will be in upcoming Ardour 6.3.0 when that's released. That will be soon, since for Ardour we roughly aim for 2 months between minor versions.

There are also updated Mixbus nightly builds with this fix, but you do have to ask Ben for for a beta-version (Mixbus 6.1.229 or later).
(0027795)
x42   
2023-06-18 00:56   
OK. I have finally got my hands on a [remote] Windows system that has a dongle to tap-off the outgoing MIDI signal and send it back to an audio-port.

I found various small bugs related to systemic latency configuration for PortAudio/ASIO and WinMME MIDI Ports.
The MIDI Clock generator was also updated to use the new Tempo Map. Since Ardour 7.4.285 (Mixbus 9.1-153) MIDI clock is sent reliably.
On Win 11 with an AudioBox at 48KHz there are about +/- 20 samples jitter.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8287 [ardour] features minor have not tried 2020-07-04 07:26 2023-06-17 21:51
Reporter: foobuntu Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Create support for track templates
Description: As far as I can see all template related functionality only works from the "new session" dialog.
There should be a functionality that allows me to call up a predefined track setup at any time, even in a project that already contains tracks.

So instead of only being able to create a new session with my drum template, I want to call up my drum template in a project that already has tracks.

If that functionality already exists, please point out where to find that and I will open a new ticket on how to make it better accessible, so far I couldn't find it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024603)
x42   
2020-07-04 12:38   
- Existing Track Templates show up in the "Add Track or Bus" dialog.
- They can be import/exported just like Session Templates via Window > Template Manager
- They can be created from the context menu of each mixer-strip in the mixer-window
(0024604)
foobuntu   
2020-07-04 22:44   
No, this only allows me to add ONE predefined track, I want to add a complete track setup, like for drums. A complete setup with kick, snare, hihat, etc. and their respective inputs, group busses, panning. Like a session template but beeing able to add it on the fly in the middle of a project and not only upon session creation.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8203 [ardour] bugs minor always 2020-06-04 16:14 2023-06-17 21:24
Reporter: ngeiswei Platform: Some Other Linux  
Assigned To: x42 OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: resolved Product Version: 6.0  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash after undo and no longer load the song
Description: After undoing some copy/pasting over an automation, Ardour crashes. Then when I try to reload my song Ardour keep crashing, and thus cannot reload it.

Please find the song attached.
Tags:
Steps To Reproduce: Load monstro-1.ardour to ardour, it crashes.
Additional Information: Upon crashing while reloading monstro-1.ardour, Ardour outputs the following

ardour-6.0.573: ../gtk2_ardour/stripable_time_axis.cc:195: boost::shared_ptr<AutomationTimeAxisView> StripableTimeAxisView::automation_child(Evoral::Parameter): Assertion `param.type() != PluginAutomation' failed.

If I comment out this assertion in the code, then Ardour can load the song as if nothing is wrong.
System Description
Attached Files: monstro-1.tar.xz (74,756 bytes) 2020-06-04 16:14
https://tracker.ardour.org/file_download.php?file_id=3720&type=bug
Notes
(0024383)
ngeiswei   
2020-06-04 19:32   
Oops, it's a duplicate of https://tracker.ardour.org/view.php?id=8201

Maybe the ardour file can provide some help though.
(0024385)
x42   
2020-06-04 19:41   
This should be fixed in 6.0-53-g54ffd92fde Please test

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9384 [ardour] bugs crash N/A 2023-06-15 10:57 2023-06-17 21:00
Reporter: merryl0 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash whilst playing a loop
Description: Working on a mix which had proceeded without any problems for about 4 sessions.
Started work today, not running in debug and it crashed twice whilst playing a 2m30s loop
Ran in dbg and it crashed again
Tags:
Steps To Reproduce: Load existing session
turn on loop and play
Additional Information: dbg info attached
System Description
Attached Files: 150623Crash.txt (146,163 bytes) 2023-06-15 10:57
https://tracker.ardour.org/file_download.php?file_id=4572&type=bug
Notes
(0027778)
paul   
2023-06-16 17:49   
Would it possible for you to upload an archive of the session?
(0027780)
merryl0   
2023-06-16 20:17   
Do you mean the whole session folder Paul?
And to where?
Thanks
(0027781)
merryl0   
2023-06-16 20:19   
Another thing, it hasn't crashed again since then. Do you still want the session in this case?
(0027787)
x42   
2023-06-17 16:13   
> Another thing, it hasn't crashed again since then. Do you still want the session in this case?

No.

I suspect the issue happens if the loop-range uses music-time (bar/beats), a small note symbol appears next to the loop marker, and only with a specific range where some rounding issue happens.
(0027792)
merryl0   
2023-06-17 21:00   
OK.
I will let you know if the issue re-occurs anytime soon
Thanks Paul

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8024 [ardour] features minor have not tried 2020-04-19 13:04 2023-06-17 20:46
Reporter: alesprochazka Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.0-pre1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow sends to buses have separate pan
Description: Add possibility to set independent pan to each send of track/bus to another buss.
Same as is for foldback busses.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: ArdourPans.png (201,372 bytes) 2020-04-23 09:30
https://tracker.ardour.org/file_download.php?file_id=3608&type=bug
png
Notes
(0023857)
ovenwerks   
2020-04-22 16:01   
This is already possible. In fact that is the only reason Foldback sends have it. Right click on the send and select the "Send Options" sub menu. Uncheck the "Link panner controls" check box and then when the show sends button is pressed on the aux bus, the panner will control just the send panner and not the main panner. It is perhaps unfortunate that Controls for the send does not include pan as an option but that could be confusing if the send pan is linked to the main pan which is the most likely use (default).
(0023861)
alesprochazka   
2020-04-22 16:44   
Thanks @ovenwerks. I didn't know this option. It's quite hidden. So in that case it would be nice to have possibility to unlink pan of send directly from pan control somehow, when sends of bus are shown :-) But it's task for some UX designer ...
And when it's unlinked, it's missing small pan control right next to send label/panel, similar as is used in foldback bus, and also some visual information, that pan is unlinked ...
Anyhow, I can live with it as is.
(0023864)
x42   
2020-04-22 17:30   
(Last edited: 2020-04-22 17:32)
The panner of the send can be any of the available panner types: mono-to-stereo, stereo-balance, stereo-width, VBAP,..
A single azimuth slider is not sufficient. So it is not displayed inline.
Furthermore stereo-width constrains the azimuth range, and a simple slider or knob cannot represent this.

There's also "Preferences > Mixer > Link panners of Aux and External Sends with main panner by default" (on by default)

(0023872)
alesprochazka   
2020-04-23 09:30   
I've created some sample, how it could be (attached).
And regarding linking/unlinking panner from main panner, there could be command directly on context menu (right click on PANNER), when "Show Sends" of BUS is active.
(0023883)
x42   
2020-04-23 22:57   
You example is nicely constructed to have space to show an icon to the right. This is not usually the case with longer bus names, or with narrow strip mode.
Also I'm not sure if a "Lock" is appropriate. A "Link" symbol perhaps, or rather "Unlinked" could be pre-fixed to the name (so always visible regardless of name-length). or simply changing the color of the send.

So far I've just prefixed a caret (^) to the name (this is similar to the asterisk that is used for replicate processors). When editing unlinked send-panners the panner widget changes color (so far "contrasting alt" foreground, which is orange in the default theme) in 6.0-rc1-73
(0023895)
alesprochazka   
2020-04-24 12:07   
It looks better now :-) Tested on 6.0-rc1-82 (Windows)

Just 2 comments:
- Please, remove space character between caret '^' and first character of buss name to have more space for buss name.
- if it's possible, add command for link/unlink send-panner to/from main-panner into context menu of panner, when "Show Sends" of bus is active. I mean those popup menu, which contains "Bypass", "Reset", "Edit ..." commands.
(0023910)
x42   
2020-04-25 14:37   
I've added it the context menu, so far (due to translation string-freeze) "Link panner controls" (Eventually this should be "Link to route panner") in 6.0-rc1-99-g7751841b78

As for the former, with wide-strip mode there is always a space after any text/symbol indicator flags.
This is also consistent with indicators used with regions in the editor.
(0027791)
x42   
2023-06-17 20:46   
Separate [aux] send panning is available since 6.0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8649 [ardour] features minor have not tried 2021-04-02 20:57 2023-06-17 20:01
Reporter: foobuntu Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make all level metering systems available as default
Description: When right clicking a track or bus (in my case masterbus) I get different/more options for metering systems than in the global settings for setting a default (see attached image).
I want to default my masterbus to 0dbFS, but I can't because that is not available in the global settings. It is however available when I right click on the masterbus. From a users persepective it would make much more sense when these options would be unified.
As I said: I'm mostly concerned about defaulting the masterbus to 0dbFS but this should be fixed for the other defaults as well. For example: Tracks can only default to either +6dbFS or 0dbFS, which again makes no sense because all the other metering systems are available when right clicking on a track, why not in the defaults?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: ardourDbFeature_finished.png (157,911 bytes) 2021-04-02 20:57
https://tracker.ardour.org/file_download.php?file_id=3988&type=bug
png
Notes
(0027790)
x42   
2023-06-17 20:01   
Implemented in 7.4-220-g44a6069694

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8564 [ardour] bugs minor always 2021-02-06 12:27 2023-06-17 19:59
Reporter: erojahn Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.5  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: New track has a short delay.
Description: This occured only in one project so far.
But it keeps repeating.
When i add a track the track is played back with a delay. I have to restart Ardour and the it is in sync.
Happens on both, audio and midi tracks. If i record from another track onto a new one the resulting audiofile is placed a little bit earlyer on the timeline then it should be.
Tags: ardour6
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025498)
x42   
2021-02-08 00:39   
Are you using JACK? if so, this might be a duplicate of 0008472
(0025540)
x42   
2021-02-20 20:24   
Likely a duplicate of 0008472, if so this should be fixed since 6.5-268-g7e196e7559
Please test.
(0025758)
erojahn   
2021-04-22 15:40   
In 6.6 it works! :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8679 [ardour] bugs minor always 2021-04-28 06:36 2023-06-17 19:58
Reporter: DaiKen Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 6.6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes on MackieControlProtocol::master_fader_touch_press
Description: Windows 10 Home
Ardour 6.6.0
Behringer X-Touch One 1.04 & 1.08

After switcihng to MASTER, using the fader crashes Ardour
Tags:
Steps To Reproduce: Switch to MASTER, use the fader
Additional Information:
System Description
Attached Files: Ardour-6.6.0-crash-1619178418.txt (7,932 bytes) 2021-04-28 06:36
https://tracker.ardour.org/file_download.php?file_id=4011&type=bug
Notes
(0025863)
x42   
2021-05-18 02:16   
Might be fixed since 6.6-500-g3a3fcd0d2d (assuming this is a session without master-bus).

Please test https://nightly.ardour.org/
(0025877)
DaiKen   
2021-05-22 06:54   
Partly thanks to <https://tracker.ardour.org/view.php?id=8680> I switched to Reaper as my favourite DAW a few days ago, sorry ;-)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9191 [ardour] bugs major always 2023-01-05 16:43 2023-06-17 19:57
Reporter: mpk Platform: Redhat  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ctrl-drag region in snap mode creates glued copy
Description: Copying a region using ctrl-drag while in snap mode creates a copy which is marked as "Glued to Bars and Beats". Note that the session option "Glue new regions to bars and beats" is not selected.

The new region's length property (in the saved xml) is a mix of both audio time and beat time, e.g.: length="a273568446480@b2818560" with the distance (length) portion expressed in audio time and the position portion expressed in beat time.

Subsequently it is not possible to unglue this region due to the logic in Editor::toggle_region_lock_style and Region::set_position_time_domain.

1. Editor::toggle_region_lock_style checks region->position_time_domain then calls Region::set_position_time_domain if the requested time domain differs. In this case the new region's position is different, so:

2. Region::set_position_time_domain checks _length.val().time_domain(). But in this case the new region's length is already in AudioTime so nothing happens further.
Tags:
Steps To Reproduce: 1. In a new session, import an audio region.
2. Enable snap mode
3. Ctrl-drag the region to copy it.
4. The new region has the musical notes icon denoting "Glued to Bars and Beats".
5. Attempt to unglue the region (Region > Position > Glued to Bars and Beats) - nothing happens.
Additional Information: Note that dragging a region or source from the Editor List in snap mode has the same problem.
System Description
Attached Files: debug-toggle-glue.patch (3,536 bytes) 2023-01-05 18:24
https://tracker.ardour.org/file_download.php?file_id=4340&type=bug
Notes
(0027162)
x42   
2023-01-05 18:04   
Thanks for that. There are various issues with "a...@b..."

It should not be possible to mix time domains, and I wondered how users managed to do this :)
(0027163)
mpk   
2023-01-05 18:24   
I used this patch to fix my session which had a...@b... regions with some brute force. But I don't really understand what's meant to happen here.
(0027170)
x42   
2023-01-10 17:43   
I can also create the inverse. ctrl+drag duplicate a music-locked MIDI region using a timecode grid. This results in "b...@a..."
(0027171)
x42   
2023-01-10 18:18   
The patch you suggested will allow an audio-region to have a duration specified in beats.
This will cause various issues. Beat granularity is coarser than samples. This can lead to the audio disk-reader trying to read more samples than are present.

An Audio region's length must always be given in samples, and (at this time) a MIDI region's duration in Music-time. Only the position's time domain can change.


--
This can change in the future: When Notes inside a MIDI region can use Audio-time, a MIDI region's duration can also be specified in in Audio time.
Likewise an audio region can to have Music Time duration once Arodur supports time-stretching
(0027172)
mpk   
2023-01-10 18:31   
Just to be clear, I didn't intend to suggest that my patch solves the problem! I just used this as a way to recover a session in which some regions had become broken (displayed as "glued", but actually with "a...@b..." lengths).
(0027173)
x42   
2023-01-10 19:09   
This should be fixed in Ardour 7.2-91-gf658a4c0b2 -- please test
(0027174)
x42   
2023-01-10 19:16   
> Just to be clear, I didn't intend to suggest that my patch solves the problem!

It was very helpful to further track down the actual issue. Thanks for that! The `timecnt_t::set_time_domain` part is still somewhat relevant.
I was thinking out loud and leaving a comment in case someone else investigates the issue. -- There are still various edge-cases related to this.
(0027176)
mpk   
2023-01-11 09:28   
Thanks, looks like this is working!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9215 [ardour] bugs minor always 2023-01-30 13:26 2023-06-17 19:56
Reporter: ahellquist Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash recovery session handling
Description: I frequently use my sessions for rehearsal or just goofing around. When playing soft synths, I change patches and sometimes att Tracks an busses that I don't intend to save to my current session.
No to the issue.

If Ardour crashes, I get the usual choice if I want to recover or load the saved state.

If i choose recover, I expect to get the last state of my session so I can keep on goofing or rehearsal.
Then when I quit, I expect Ardour to ask me if I'd like to save my recovered still dirty session of not.

Unfortunately, that is not how Ardour behaves since Ardour apparently commits the recovered session to the Session file as soon as one is recovering a crashed session.

My question is, Am I totally wrong in my reasoning that Ardour should not commit the recovered state to file until the user wants to quit?
Tags: crash, session
Steps To Reproduce: Open a session. Change some stuff. Make Ardour crash.
Select recover when option is presented.
Try quiting the session without commiting the changes to the session file
Additional Information:
System Description
Attached Files:
Notes
(0027260)
ahellquist   
2023-01-30 13:28   
Sorry for the spelling misstakes
(0027269)
x42   
2023-02-03 06:25   
> Unfortunately, that is not how Ardour behaves since Ardour apparently commits the recovered session to the Session file as soon as one is recovering a crashed session.

That is indeed the case. and I think you do have a valid point.

OK. Let me elaborate:

Ardour periodically writes a ".pending" state (usually every 2 mins, and when rec-arming the session).

When loading a session and a .pending state file exist, there is the option to load this state ("recover from crash") instead of the main session file.

The .pending file is removed
1. when a session is closed (at exit, no crash)
2. when the session is saved. This can happen
 2a. manually (ctrl+S)
 2b. automatically after each record-stop
 2c. after a successful load of the .pending file
3. when a snapshot is saved or the session is renamed - both a special cases of (2a)

We can indeed get rid of (2c) and instead add

 2d. when the user chooses to not recover (ignore crash data)

There is still the edgecase of 2b. When your goofing around involves recording data, the session will be saved.
In theory rec-stop could just write to a .pending safe rather than overwriting the session, but I am not [yet] convinced that is is a good approach.

All that being said, why don't you use a snapshot when playing around?
(0027270)
x42   
2023-02-03 06:42   
Amend the above:

2b. automatically after each record-stop, and also after "remove last capture" (so that the session does not end up referring to non-existent sources)
2f. session is also saved after a Session > Cleanup
(0027271)
x42   
2023-02-03 06:58   
I have just made those changes (Ardour 7.2-194-g14606ac655)

https://github.com/Ardour/ardour/commit/054e1c3c123a1cfb0c79c448eae0511ccd2d9178
https://github.com/Ardour/ardour/commit/14606ac655479769ed79bb905725a1217fd073ad

Rec-stop now also only writes a pending (recovery) file. This is somewhat dangerous and I may revert that change pending further discussion.
(0027789)
x42   
2023-06-17 19:56   
You can now recover, goof around, and quit without saving.
On next reload this returns you back to the last explicit save.

There are 2 notable exceptions: removing tracks, and session-cleanup save the session. There is a confirmation dialog "..this operation cannot be undone..", so you can opt out

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9386 [ardour] features major always 2023-06-17 03:02 2023-06-17 03:02
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mixer List
Description: separate mixer list sections to tabs like editor list

with four section on one tab ardour give each section a little space
but with one section on one tab you have maximum space for each one

pay attention to screenshot
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Untitled.jpg (280,125 bytes) 2023-06-17 03:02
https://tracker.ardour.org/file_download.php?file_id=4575&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9381 [ardour] bugs minor always 2023-06-14 05:28 2023-06-16 21:53
Reporter: aggraef Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 7.4  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI clock starts 1 quarter note late
Description: Running the latest git version of Ardour. This will affect all external devices and programs syncing to MIDI clock from Ardour. The synced gear will start playback one quarter note too late.

Looking at the MIDI clock and note output from Ardour in aseqdump and kmidimon, it seems that the MIDI clock indeed starts one quarter note late. The attached log from aseqdump clearly shows this. In fact, the emitted Song Position Pointer message indicates an SPP of 4 (= 4/16 = 1 quarter note), which is consistent with the clock starting one beat late.

Is this by design? Or is there some setting in the preferences which does this? An obvious work-around is to start playback in Ardour 1 quarter note in advance, but this shouldn't be necessary IMHO.
Tags:
Steps To Reproduce: The attached aseqdump log was created using the attached simple session with 4 quarter notes in one bar, using the Play Region option. MIDI clock generation is enabled in the preferences, and sync is set to internal. I captured the MIDI output from the MIDI track along with Ardour's MIDI clock output, to better see what's going on there.
Additional Information:
Attached Files: aseqdump.txt (3,543 bytes) 2023-06-14 05:28
https://tracker.ardour.org/file_download.php?file_id=4567&type=bug
single-bar_2023-06-14_071513.ardour-session-archive (6,173 bytes) 2023-06-14 05:28
https://tracker.ardour.org/file_download.php?file_id=4568&type=bug
jack_lsp.txt (15,104 bytes) 2023-06-14 21:19
https://tracker.ardour.org/file_download.php?file_id=4571&type=bug
Notes
(0027756)
x42   
2023-06-14 16:01   
I cannot reproduce this with Ardour/ALSA. Are you using JACK? Can you provide the output of `jack_lsp -lc` ?

Keep in mind that Ardour applies latency compensation. Ardour sends the Mclk "start" message before starting to roll, so that by the time Ardour starts rolling at 1|1|0, the message is already at the MIDI output.
If that is not possible (e.g. jack-transport), then Ardour will queue up the next possible start location.

I've just tested with with a MIDI loopback cable: delta time is in samples. It is a bit jittery and since it's a USB device (running at 48kHz - clock messages should be sent in 1000 sample intervals).
[....]
+      492816          NoteOn chn  1 3c 40
+          48           Start
+           1           Clock
+         831           Clock
+        1028           Clock
+        1019           Clock
+         993           Clock
+         976           Clock
+        1024           Clock
+         976           Clock
+        1023           Clock
+         976           Clock
+        1025           Clock
+         976           Clock
+        1023           Clock
+         975           Clock
+        1026           Clock
+         975           Clock
+        1025           Clock
+         977           Clock
+        1022           Clock
+        1025           Clock
+         976           Clock
+        1072           Clock
+         880           Clock
+        1074           Clock
+         973         NoteOff chn  1 3c 40
+          47          NoteOn chn  1 3c 40
+          49           Clock
+         897           Clock
+         975           Clock
+        1024           Clock
+         978           Clock
+        1024           Clock
+         972           Clock
+        1027           Clock
+         975           Clock
+        1025           Clock
+         977           Clock
+        1021           Clock
+         980           Clock
+        1023           Clock
+         976           Clock
+        1024           Clock
+         975           Clock
+        1024           Clock
+        1022           Clock
+         981           Clock
+         973           Clock
+        1022           Clock
+        1027           Clock
+         945           Clock
+        1069         NoteOff chn  1 3c 40
+          31          NoteOn chn  1 3c 40
+          50           Clock
+         895           Clock
+         976           Clock
+         978           Clock
+        1021           Clock
+        1025           Clock
+         977           Clock
+         976           Clock
+        1023           Clock
+         976           Clock
+        1025           Clock
+         976           Clock
+        1024           Clock
+         977           Clock
+        1071           Clock
+         976           Clock
+        1025           Clock
+         928           Clock
+        1073           Clock
+         943           Clock
+        1024           Clock
+         976           Clock
+        1026           Clock
+         973           Clock
+        1024         NoteOff chn  1 3c 40
+          47          NoteOn chn  1 3c 40
+          80           Clock
+         849           Clock
+        1025           Clock
+         979           Clock
+        1020           Clock
+         976           Clock
+        1025           Clock
+         974           Clock
+        1026           Clock
+         975           Clock
+        1021           Clock
+        1029           Clock
+         973           Clock
+        1072           Clock
+         930           Clock
+         974           Clock
+         993           Clock
+        1057           Clock
+         944           Clock
+        1022           Clock
+         977           Clock
+        1024           Clock
+         976           Clock
+        1023           Clock
+        1026         NoteOff chn  1 3c 00
+          48           Clock
+         927           Clock
+         988           Clock
+        1013           Clock
+         976           Clock
+        1023           Clock
+         976           Clock
+        1024           Clock
+        1021           Clock
+         981           Clock
+        1022           Clock
+         929           Clock
+        1024           Clock
+        1021           Clock
+         994           Clock
+         977           Clock
+        1024           Clock
+         975           Clock
+        1024           Clock
+         975           Clock
+        1023           Clock
+         977           Clock
+         831            Stop
(0027757)
aggraef   
2023-06-14 17:24   
Yes, I'm running Jack (Jack2 to be precise), and using a2jmidid to hook up Ardour's MIDI clock output port to other apps such as Pd.

I'd try with ALSA, but in that case I have no idea how to send the MIDI clocks from Ardour to another ALSA MIDI app, without having to fiddle around with actual real-world MIDI loopback cables. ;-)

This can't be a latency compensation issue, the MIDI clocks start rolling an entire quarter note late. Unfortunately, aseqdump doesn't print any timestamps, so this isn't obvious from the log I posted. But I can see in kmidimon that the first note plays, then nothing happens for almost a quarter note, then a few ticks before the second note I get the SPP message, and then the MIDI clocks start rolling at the exact same time the note off from the previous note and the note on from the second note. Thus the timing is exactly what I'd expect it to be, it's just that the MIDI clocks start an entire quarter note late. :(

Here's the output of `jack_lsp -lc` (yeah, I have a lot of USB MIDI devices hooked up to this machine, including a mioXM box).

~~~
system:capture_1
   PulseAudio JACK Source:front-left
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 256 256 ] frames
system:capture_2
   PulseAudio JACK Source:front-right
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 256 256 ] frames
system:playback_1
   PulseAudio JACK Sink:front-left
    port playback latency = [ 512 512 ] frames
    port capture latency = [ 0 0 ] frames
system:playback_2
   PulseAudio JACK Sink:front-right
    port playback latency = [ 512 512 ] frames
    port capture latency = [ 0 0 ] frames
PulseAudio JACK Source:front-left
   system:capture_1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 256 256 ] frames
PulseAudio JACK Source:front-right
   system:capture_2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 256 256 ] frames
a2j:Midi Through [14] (capture): Midi Through Port-0
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:Midi Through [14] (playback): Midi Through Port-0
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:APC mini mk2 [24] (capture): APC mini mk2 APC mini mk2 Contr
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:APC mini mk2 [24] (playback): APC mini mk2 APC mini mk2 Contr
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:APC mini mk2 [24] (capture): APC mini mk2 APC mini mk2 Notes
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:APC mini mk2 [24] (playback): APC mini mk2 APC mini mk2 Notes
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:AG06/AG03 [36] (capture): AG06/AG03 MIDI 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:AG06/AG03 [36] (playback): AG06/AG03 MIDI 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:MPK mini Plus [40] (capture): MPK mini Plus MIDI 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:MPK mini Plus [40] (playback): MPK mini Plus MIDI 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:MPK mini Plus [40] (capture): MPK mini Plus MIDI 2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:MPK mini Plus [40] (playback): MPK mini Plus MIDI 2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM DIN 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM DIN 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM DIN 2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM DIN 2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM DIN 3
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM DIN 3
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM DIN 4
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM DIN 4
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM HST 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM HST 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM HST 2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM HST 2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM HST 3
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM HST 3
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM HST 4
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM HST 4
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM HST 5
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM HST 5
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM HST 6
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM HST 6
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM HST 7
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM HST 7
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM HST 8
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM HST 8
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM Preset Selector
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM Preset Selector
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM RSV 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM RSV 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM RSV 2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM RSV 2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (capture): mioXM RSV 3
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:mioXM [44] (playback): mioXM RSV 3
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:STARRYPAD [48] (capture): STARRYPAD MIDI 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:STARRYPAD [48] (playback): STARRYPAD MIDI 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:QmidiNet [128] (capture): port 0
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:QmidiNet [128] (playback): port 0
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:QmidiNet [128] (capture): port 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:QmidiNet [128] (playback): port 1
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:QmidiNet [128] (capture): port 2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:QmidiNet [128] (playback): port 2
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:QmidiNet [128] (capture): port 3
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
a2j:QmidiNet [128] (playback): port 3
    port playback latency = [ 0 0 ] frames
    port capture latency = [ 0 0 ] frames
PulseAudio JACK Sink:front-left
   system:playback_1
    port playback latency = [ 512 512 ] frames
    port capture latency = [ 0 0 ] frames
PulseAudio JACK Sink:front-right
   system:playback_2
    port playback latency = [ 512 512 ] frames
    port capture latency = [ 0 0 ] frames
~~~
(0027758)
aggraef   
2023-06-14 18:15   
It seems that a2jmidid is the culprit. Ardour just doesn't like it, and even says so with a red flashing "No Align" LED.

With jack2 and its built-in seq Jack MIDI driver everything works fine.

Sorry for the false alarm, this ticket can be closed. Case of PEBCAK. :)
(0027759)
x42   
2023-06-14 20:01   
It seems that a2j does not correctly set port-latencies. They are all zero. Physical playback ports should report at least the buffersize.
I don't see any Ardour connections in the list though, so it's hard to determine if there is some additional issue.
(0027760)
aggraef   
2023-06-14 21:19   
Oops, sorry, here's a more complete log.
(0027761)
aggraef   
2023-06-14 21:48   
This is weird. I just tried this again (in the original configuration using a2jmidid), and this time it worked every single time. The flashing red led is gone as well. Looks like the bug isn't that reproducible after all.

Feel free to close the ticket. I don't really understand what's going on there. I didn't even reboot the machine, just switched to Jack's built-in Jack MIDI bridge, and then back again to a2jmidid.

Could be the USB MIDI driver going wonky? I do have an awful lot of USB MIDI devices hooked up to this computer. And I *did* unplug my mioXM box and plugged it in again, maybe that helped. :)
(0027764)
x42   
2023-06-15 15:14   
Your guess is as good as mine.

I expect however that if you disconnect Ardour's master bus the issue returns.

The current implementation expects that worst-case playback latency is not zero (at least one track or bus must have a latency > 0).
Ardour's MidiClockTicker sends "start" only during pre-roll. Buffers are filled so that by the time Ardour starts rolling, data reaches the output.
If worst-case playback latency is zero, that step is skipped. -- Sadly this is not trivial to fix.
(0027765)
x42   
2023-06-15 15:24   
Actually the last sentence I wrote above is wrong. There is already special case for zero latency.
(0027766)
aggraef   
2023-06-15 17:49   
Hmm, can you point me to the code that deals with the zero latency case? So that in case the issue returns, I can have a look myself and fiddle with the code.

Anyway, thanks for taking the time to look into it. It's very unfortunate that I can't reproduce the issue any more. I hate Heisenbugs. :((
(0027767)
x42   
2023-06-15 18:12   
https://github.com/Ardour/ardour/blob/3e27df9040b61d8fd7571bfb413cf59cedb57d64/libs/ardour/ticker.cc#L174-L188

When there is no latency, at transport start <tt>_remaining_latency_preroll = worst_latency_preroll_buffer_size_ceil ();</tt>
In that case<tt>pre_roll</tt> is always 0 when <tt>MidiClockTicker::tick</tt> is called.

In that case "start" is sent later during the first process cycle:

<tt>start_sample = 0; end_sample = n_samples; </tt>

The MIDI Clock port has zero latency: <tt>_mclk_out_latency.max == 0 </tt>

and hence <tt>_beat_pos == 0</tt> and <tt>_next_tick ==0</tt>
which leads to <tt>send_start_event (..)</tt>
(0027782)
aggraef   
2023-06-16 21:53   
Cool, thanks for the pointer!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9313 [ardour] bugs minor always 2023-04-23 04:20 2023-06-16 19:32
Reporter: killermike Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when combining MIDI regions
Description: Ardour crashes when combining two overlapping MIDI regions.

Example files provided (ignore the consolidated.mid) file .
Tags:
Steps To Reproduce: Create first MIDI region (with draw tool) and populate with MIDI notes (with Draw tool). Create second MIDI region and populate with notes. Move region 2 on top of region 1. Use the Range tool to select a range that covers both regions. In context menu, select 'Select All in Range'. In context menu, select 'Selected Regions > Edit > Combine'. Ardour crashes.
Additional Information: Error at terminal:

(ardour-7.3.0:131320): Gtk-CRITICAL **: 05:15:33.471: IA__gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(ardour-7.3.0:131320): Gtk-CRITICAL **: 05:15:54.851: IA__gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(ardour-7.3.0:131320): Gtk-CRITICAL **: 05:16:08.786: IA__gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(ardour-7.3.0:131320): Gtk-CRITICAL **: 05:16:32.914: IA__gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
ardour-7.3.0: ../libs/evoral/Sequence.cc:921: void Evoral::Sequence<T>::append(const Evoral::Event<Time>&, Evoral::event_id_t) [with Time = Temporal::Beats; Evoral::event_id_t = int]: Assertion `_notes.empty() || ev.time() >= (*_notes.rbegin())->time()' failed.
Aborted (core dumped)
killermike@killermike-desktop:~$ ardour-request-device: watched PID no longer exists - releasing device.

System Description
Attached Files: instant.xml (3,120 bytes) 2023-04-23 04:20
https://tracker.ardour.org/file_download.php?file_id=4497&type=bug
Untitled-2023-04-23-05-03-11.ardour.bak (10,612 bytes) 2023-04-23 04:20
https://tracker.ardour.org/file_download.php?file_id=4498&type=bug
crash_test1.ardour.bak (39,583 bytes) 2023-04-23 04:20
https://tracker.ardour.org/file_download.php?file_id=4499&type=bug
crash_test1.ardour (44,182 bytes) 2023-04-23 04:20
https://tracker.ardour.org/file_download.php?file_id=4500&type=bug
crash_test1.history.bak (11,505 bytes) 2023-04-23 04:20
https://tracker.ardour.org/file_download.php?file_id=4501&type=bug
crash_test1.history (11,505 bytes) 2023-04-23 04:20
https://tracker.ardour.org/file_download.php?file_id=4502&type=bug
crash_test1.pending (44,396 bytes) 2023-04-23 04:20
https://tracker.ardour.org/file_download.php?file_id=4503&type=bug
ACE Reasonable Synth-1.mid (26 bytes) 2023-04-23 04:20
https://tracker.ardour.org/file_download.php?file_id=4504&type=bug
Take1_ACE Reasonable Synth-1.mid (26 bytes) 2023-04-23 04:20
https://tracker.ardour.org/file_download.php?file_id=4505&type=bug
Notes
(0027779)
x42   
2023-06-16 19:32   
Fixed in 7.4.278

PS. for future reference Menu > Session > Archive is an easy way to zip up the session (no need to attach individual files).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9382 [ardour] bugs crash sometimes 2023-06-14 08:25 2023-06-16 16:12
Reporter: Benjamin13 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when removing audio regions from the editor
Description: Sometimes, when I select one or more audio regions from the editor and hit delete, Ardour crashes.

It happens in a new session with no plugins loaded. In this session I have 8 tracks recording from the 8 inputs of my audio interface and that's it.

I attach a log of a run that lead to such a crash.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Ardour-debug.log (114,431 bytes) 2023-06-14 08:25
https://tracker.ardour.org/file_download.php?file_id=4569&type=bug
Ardour-debug-2.log (125,017 bytes) 2023-06-14 08:34
https://tracker.ardour.org/file_download.php?file_id=4570&type=bug
Notes
(0027755)
Benjamin13   
2023-06-14 08:34   
The same problem can happen at the end of a recording. I wanted to open a ticket for that initially but couldn't reproduce the issue.

I just got a crash for that scenario with the same session setup described in the initial bug description. After a few seconds of recording I hit stop and the same crash happen (same call stack).

I attach the log as well.
(0027776)
paul   
2023-06-16 16:12   
We need to get an understanding of which thread is exiting when this crash happens. Not sure of the best way to do this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9310 [ardour] bugs feature always 2023-04-21 12:31 2023-06-16 15:51
Reporter: johne53 Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: Mixbus 9.x  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tempo Mapping ruler not working in current code
Description: Just wondering if anyone can make sense of this...

A new ruler bar got added recently (called the Tempo Mapping ruler). But for some strange reason I can't display it here when building with either MSVC or Clang (see the attached screen grab). And it doesn't work in Robin's Mixbus nightly from yesterday - although it was working fine in the last official MB release. The relevant entry gets displayed but with no text assigned - and regardless of whether I check the box or uncheck it, the Tempo Mapping ruler just doesn't get displayed any more. I've built Ardour from last night's code and Ardour shows me the same problem :-(

I can't see any obvious difference in the way this ruler's coded compared to the others so I just wondered if someone can figure out what's changed?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Capture-10.png (26,416 bytes) 2023-04-21 12:31
https://tracker.ardour.org/file_download.php?file_id=4490&type=bug
png
Notes
(0027606)
paul   
2023-04-22 18:09   
(Last edited: 2023-04-22 18:09)
The work is not finished, and it isn't a new ruler any more.
(0027774)
paul   
2023-06-16 15:51   
this refers to an intermediate state of the design

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9385 [ardour] features minor random 2023-06-16 02:44 2023-06-16 02:44
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: spectral analysis
Description: spectral analysis show note number
also allow rename region / reason ? because maybe user find note of region and want change it name to this note name

vertical line for easy find frequency

good luck
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9368 [ardour] features major sometimes 2023-06-11 05:28 2023-06-16 02:37
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Piano roll scale note indicator based on midi file
Description: I described it in here
https://discourse.ardour.org/t/piano-roll-scale-note-indicator-based-on-midi-file/108775
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027737)
dsfdsf   
2023-06-11 05:30   
or drag&drop midi file to midi track header to use midi file as scale reference
(0027753)
paul   
2023-06-13 16:51   
1. It isn't currently clear what objects inside a session should be able to "have a scale" - tracks? regions? time ranges? the session?

2. we would use Scala files to load scales, not MIDI
(0027762)
dsfdsf   
2023-06-15 01:33   
@paul
my reason for this is because midi file are very common and work on this feature ardour can make road to make fold option for piano roll
and some times a scale can be find that is very old and unique and scala format doesn't contain it
also this feature can help to reverse engine midi file melody's and chord easy just select a midi file and put it as reference in piano roll background


and your talk about what section should be have scale is true
i think entire session is best option
(0027763)
paul   
2023-06-15 13:12   
A trivial case where this doesn't work: in quite a bit of contemporary jazz and rock, the bass doesn't technically use the same scale as the main melody or harmonic progression. So a single scale for the session doesn't seem like the right answer.

I challenge you to come up with a scale that doesn't have a Scala file. From the Scale home page:

---------
Recognises more than 3100 musical modes. You can check any scale to see if it approximates an existing mode.

More than 690 note naming systems built in. Notes can be named and shown in a consistent way with microtonal accidentals.

Recognises more than 850 chords. You can check the occurrence of these chords in any scale.

Recognises more than 550 rational intervals.

Recognises more than 5900 regular temperaments. You can check the name by giving a generator and period.

More than 5200 scales available. Download these for free from this website, see the Download page.
-----------

https://www.huygens-fokker.org/scala/
(0027768)
x42   
2023-06-15 18:42   
Assuming 12TET using a MIDi file to indicate which notes are currently in scale is not a bad idea. Particularly since it can also vary over time.
I doubt that it is practical though. A dedicated ruler and list of built-in scales (like for the Push2) seems preferable.
(0027770)
dsfdsf   
2023-06-16 02:37   
@paul
but maybe a user need reverse a melody scale from midi file instead find it between 5k of scales
and this feature can be a start point to build some other feature over the time
like fold option to fold piano roll to midi file or note that appear in piano roll
and note that drums note doesn't use scale and i think fold option is better than adding sequencer in this case

best of two world maybe adding both scala format && midi to scale option


about scala completeness
i don't have time to test it but i'm sure nothing is 100% perfect

good luck

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9383 [ardour] features minor random 2023-06-15 06:05 2023-06-15 06:05
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: knife and glue tool for midi note
Description: knife for chop note
glue for combine note

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9372 [ardour] bugs minor always 2023-06-12 07:21 2023-06-13 20:37
Reporter: aggraef Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Meter and bpm not updated in Jack transport
Description: This happens on both Linux and Mac for me. Ardour is running as Jack time master. Meter and bpm information is set to whatever meter and tempo is set at the beginning of the timeline, but then never changes. Beats *are* counted properly (correct number of beats per bar, at the right pulse rate), it's just the beats_per_bar, beat_type, and beats_per_minute fields in the jack_position_t struct returned by jack_transport_query() that never get updated.
Tags:
Steps To Reproduce: Play back the attached meter-test session created with Ardour 7.4 which has some tempo and meter changes, using Jack transport with Ardour running as Jack time master. In qjackctl you can see that the bpm value never changes, but that the beats are counted properly. Running a little jack transport client program it becomes apparent that the beats_per_bar and beat_type information never changes either. (I have a little pd-lua external which does this for me, see https://github.com/agraef/pd-jacktime.)
Additional Information:
System Description
Attached Files: meter-test_2023-06-12_085804.ardour-session-archive (4,181 bytes) 2023-06-12 07:21
https://tracker.ardour.org/file_download.php?file_id=4560&type=bug
Notes
(0027742)
paul   
2023-06-12 19:13   
Fixed in 12c3daa46b10

Thanks for noticing, and reporting it.
(0027754)
aggraef   
2023-06-13 20:37   
That was quick, many thanks!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9376 [ardour] bugs minor always 2023-06-13 00:48 2023-06-13 16:50
Reporter: gudmunduringimarsson Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unable to move track up or down in editor
Description: I'm unable to move the tracks up or down with "Ctrl-Up/Down" even if i try to remap it.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9356 [ardour] bugs minor random 2023-05-31 10:55 2023-06-13 16:50
Reporter: nyxkn Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Moving a track up/down with ctrl+up/down sometimes doesn't work
Description: Tracks that are armed for recording cannot be moved, and I think that's as intended.
But sometimes, even when the track is unarmed it cannot be moved. But, if I then arm and disarm the track, I'm able to move it as expected.

This also happened on an inactive track. It couldn't be moved. Surprisingly, when then doing the arm+disarm trick on a *different* track (the inactive track cannot be armed), I'm then able to move the inactive track.
Tags:
Steps To Reproduce: Attempt to move a track.
The bug happens only some times, seemingly at random. When it happens, the arm+disarm trick always solves it.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9366 [ardour] bugs minor always 2023-06-10 02:29 2023-06-13 16:49
Reporter: jaykstah Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI tracks don't bounce corectly if there is a tempo change in the project.
Description: I have project files with a tempo change. If I create a midi region in a place after the tempo change happens and bounce it to the Clip Library, when placed onto the timeline the region is smaller than the original and the notes are spaced closer together so that the sequence plays out faster than it should.
Tags: bouncing, clip, Midi, sources
Steps To Reproduce: - Create an empty project
- Add a tempo change (for my example the project starts at 88BPM then changes to 120BPM after 5 bars)
- Create a MIDI region in an area after the tempo change and place some notes
- Open the context menu for the MIDI region, then Bounce (without processing) to the Clip Library
- From the Clip Library (or sources list) drag the bounced clip onto the timeline somewhere after the tempo change
     - The placed region will be smaller than the original and the sequence of notes will be spaced closer together than they should be, therefore playing faster than the original region
- Take that same region that you placed from the Clip Library and drag it to an area prior to the tempo change. The notes will not line up with the tempo markers for the 88BPM section but they will be correctly spaced so that the sequence plays at the expected speed that the original does at 120BPM.
Additional Information:
System Description
Attached Files:
Notes
(0027752)
paul   
2023-06-13 16:49   
This may be fixed in the latest nightly builds. Please check and report ...

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9377 [ardour] bugs crash always 2023-06-13 00:50 2023-06-13 16:45
Reporter: gudmunduringimarsson Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Application crash on New/Open
Description: When i try to either open an existing project or create a new one when an existing project the application crashes and closes. Works fine when opening for the first time.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0027750)
paul   
2023-06-13 16:45   
Please see https://ardour.org/debugging_ardour
(0027751)
paul   
2023-06-13 16:45   
Also, check the latest nightly build(s)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9380 [ardour] bugs minor always 2023-06-13 01:10 2023-06-13 16:44
Reporter: gudmunduringimarsson Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Novation Impulse 25 - Unable to map transport control
Description: I have tried everything to map the transport control of this MIDI controller in Ardour with no luck. Other buttons can be assigned.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0027749)
paul   
2023-06-13 16:44   
Have you determined what messages are sent?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9379 [ardour] features major N/A 2023-06-13 01:03 2023-06-13 03:18
Reporter: gudmunduringimarsson Platform: Microsoft  
Assigned To: OS: Windows  
Priority: high OS Version: 11  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Patch names on MIDI keyboard
Description: This is a major one: In some daws you can see on the DAW MIDI keyboard track the names of the patches. F.x "Kick", "Snare". This is especially important when programing drum patterns and you always have to press the keys to find kick snare etc.
F.x MT-Power-drumkit offers a patch for a few daws (not Ardour) that enables this possibility.
Tags:
Steps To Reproduce:
Additional Information: https://www.powerdrumkit.com/presets_drum-maps.php
System Description Windows 11
Attached Files: image.png (179,523 bytes) 2023-06-13 01:03
https://tracker.ardour.org/file_download.php?file_id=4565&type=bug
png

midnam-cursor.png (26,168 bytes) 2023-06-13 03:18
https://tracker.ardour.org/file_download.php?file_id=4566&type=bug
png
Notes
(0027748)
x42   
2023-06-13 03:18   
Ardour shows it when you draw a note, or hover over it in edit mode.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9378 [ardour] features minor N/A 2023-06-13 00:59 2023-06-13 00:59
Reporter: gudmunduringimarsson Platform: Microsoft  
Assigned To: OS: Windows  
Priority: high OS Version: 11  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Create a folder/group option on open project screen at start
Description: It would boost the productivity to be able to group existing projects into folders or groups. F.x based on different clients e.t.c.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9374 [ardour] bugs minor always 2023-06-12 23:43 2023-06-12 23:43
Reporter: gudmunduringimarsson Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Track templates not working
Description: Track templates do nothing when I select them and press done.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9339 [ardour] bugs minor always 2023-05-18 10:37 2023-06-12 22:46
Reporter: finotti Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot change tempo
Description: I have a session with many signature changes and a few tempo changes. I wanted to increase the tempo. But changing the initial tempo (e.g., from 150 to 155) hides the first bars. The first visible in the time line is marked as bar 103. Pressing HOME does not take to the first bar. MIDI regions at the beginning also disappear.
Tags: tempo change
Steps To Reproduce: Extract the attached session and change the first tempo from 150 to 155.
Additional Information:
System Description
Attached Files: tempo_change_bug.tgz (6,399 bytes) 2023-05-18 10:37
https://tracker.ardour.org/file_download.php?file_id=4528&type=bug
gdb.txt (26,169 bytes) 2023-05-18 11:00
https://tracker.ardour.org/file_download.php?file_id=4529&type=bug
Notes
(0027661)
finotti   
2023-05-18 11:00   
I tried a new session. Left the default 120 tempo, added a new tempo at bar 10, changed it to 130.

When trying to change the first tempo (to 125), Ardour crashes. I could reproduce it many time. Attached the gdb file.
(0027747)
paul   
2023-06-12 22:46   
Should be fixed as of commit bb97ade440

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9373 [ardour] features minor have not tried 2023-06-12 20:39 2023-06-12 21:05
Reporter: skygge Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add possibility to collapse / expand a group (aka "folder track")
Description: Please make a feature in Ardour to enable collapse/expand a tracks group - something like a "folder track" known from other DAWs.
If you have a plugin (eg. virtual drums) that fans out into 16 or more separate tracks, this would be desired to collapse all these tracks and keep edit area organized and clear.
Thanks!
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: group_expanded.png (20,825 bytes) 2023-06-12 20:39
https://tracker.ardour.org/file_download.php?file_id=4562&type=bug
png

group_collapsed.png (5,599 bytes) 2023-06-12 20:39
https://tracker.ardour.org/file_download.php?file_id=4563&type=bug
png
Notes
(0027745)
x42   
2023-06-12 21:05   
You have just created year's work of work in just one sentence :)

Folder tracks are not just a visual show/hide, but involve signal flow upwards to the parent track.
In Arodur's case the parent-track will likely need to become a downstream bus.
Implementing this been on our ToDo list since around 10 years (post 3.5).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9371 [ardour] bugs minor always 2023-06-12 06:11 2023-06-12 20:01
Reporter: merryl0 Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi List editor reports werong note lenght
Description: Note length values drawn in mid region are reported as semibreve in list editor. The length value and start point cannot be changed
Tags:
Steps To Reproduce: Start new session
create midi track
draw a region
draw in 1/4 notes
open list editor for region
attempt changes to length or start point
Additional Information:
System Description
Attached Files: MidiListEd1.png (208,135 bytes) 2023-06-12 06:11
https://tracker.ardour.org/file_download.php?file_id=4558&type=bug
png

MidiListEd-dbg.txt (91,027 bytes) 2023-06-12 06:11
https://tracker.ardour.org/file_download.php?file_id=4559&type=bug
Notes
(0027744)
paul   
2023-06-12 20:01   
Should be fixed by commit 04b728fb38

Please verify.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9354 [ardour] bugs minor N/A 2023-05-27 21:25 2023-06-12 19:52
Reporter: colinf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: No way to remove a single cue marker from a region source
Description: There's no way (at least, as far as I can see) to remove a single cue marker from a region's source. There's "Region > Markers > Clear Region Cue Markers" to delete them all, but removing just one seems impossible.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 0001-fix-shift-right-click-removal-of-region-source-marke.patch (925 bytes) 2023-06-12 19:52
https://tracker.ardour.org/file_download.php?file_id=4561&type=bug
Notes
(0027701)
colinf   
2023-06-03 16:50   
So it appears that ardour's standard <shift>+<right-click> to delete is somehow supposed to be implemented for region cue markers, but in fact provokes an assert() failure in debug builds, thus:

An UNDO transaction was started while a prior command was underway. Aborting command (remove cue marker) and prior (remove region marker)
ardour-7.3.280: ../libs/ardour/session_state.cc:3327: void ARDOUR::Session::begin_reversible_command(GQuark): Assertion `false' failed.
(0027743)
colinf   
2023-06-12 19:52   
The attached at least gets shift+right-click working to remove a single region cue marker. It still doesn't work quite as well as I'd like: it only removes cue markers if their containing region is selected in 'G'rab mode. I feel it ought to work regardless of whether the region is selected, and ideally in 'D'raw & internal 'E'dit modes too - I'll see whether I can find the time to implement that soon. Otherwise I'll just merge this anyway.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9369 [ardour] features minor have not tried 2023-06-11 13:08 2023-06-11 13:49
Reporter: skygge Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Rec Editor: Rename Audio/MIDI Inputs and Outputs
Description: Please make the rename of Inputs permanent (in Ardour configuration), not only for the current session.
And add ability to rename outputs as well.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027738)
x42   
2023-06-11 13:24   
Custom Input Port names are session-independent. They were never saved with the session.
Assuming you are on GNU/Linux, can you check `$HOME/.config/ardour7/port_metadata` for Ardour internal audio-systems.

If you are using JACK, then jackd is responsible for keeping port-meta-data. By default jack's meta-data database is volatile.
you can use `jack_property` to modify the port-names.
(0027739)
skygge   
2023-06-11 13:36   
I don't want to rename inputs for whole system, just as an alias for Ardour....
(0027740)
x42   
2023-06-11 13:49   
If you use JACK, then jackd provides ports (and port-meta-data), and Ardour has no control over this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9370 [ardour] features major have not tried 2023-06-11 13:34 2023-06-11 13:34
Reporter: skygge Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Editor: Enhancements for MIDI to make it more... contemporary.
Description: The MIDI editor in Ardour is very outdated... :(
Please make Ardour more friendly for music creators, not only for "recorders" and enhance MIDI editor functionality, give us at least:

- Display note names on the pianoroll keys (on/off),
- Display instrument names on the pianoroll keys, e.g.: kick, snare, tom1, etc. (configurable),
- Display keys only for selected keys/scales/only used (so it indicates scale selection),
- Add a choice to replace piano keys with a grid,
- Add chord/arpeggio mode to insert chords (optional: for selected scale only), configurable: major/minor/seventh/dminished/augmented, and so on,
- Add a progression/pattern generator to generate own progression or pick from popular chord progressions available,

As you can see not a word about lollipop velocity so far ;)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9363 [ardour] bugs crash random 2023-06-09 11:52 2023-06-10 21:27
Reporter: merryl0 Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on aborting record
Description: Recording a track (audio and midi). pressing control space to abort take crashes ardour. Metronome fails first
Tags:
Steps To Reproduce: Start a session
Start recording a track
Press Ctrl-Space
Additional Information: I think I might have pressed a wrong key while copying the debug data. If so and the file below is useless let me know and I will do it again
System Description
Attached Files: RecCreash090623.txt (43,706 bytes) 2023-06-09 11:52
https://tracker.ardour.org/file_download.php?file_id=4553&type=bug
RecCreash090623-2.txt (58,663 bytes) 2023-06-09 12:01
https://tracker.ardour.org/file_download.php?file_id=4554&type=bug
DrawToolListEditorMismatch.png (214,525 bytes) 2023-06-10 21:18
https://tracker.ardour.org/file_download.php?file_id=4557&type=bug
png
Notes
(0027718)
merryl0   
2023-06-09 12:01   
I think Ive copied the rest of the debug data in this file
(0027722)
x42   
2023-06-09 16:51   
Should be fixed now in 7.4-238-g55afdc2aa4 please test
(0027735)
merryl0   
2023-06-10 21:18   
Re: [ardour 0009363]: Crash on aborting record
Good evening
in Ardour 7.4.250 I have so far not encountered the crash but have found a couple of different problems.
1. When recording with count in, the first midi note at the start point does not sound
2. here is a screen shot which relates to the problem above. I opened the midi list editor to see if i could put the first note on bar|beat|1 instead of bar|beat|0 to try and make it sound. With the snap on or off I cannot change the start point. Also the note length in the list editor (semibreve) is not the length that i drew in with the draw tool (crotchet)
image.png
The log shows no errors or warnings
Many thanks
(0027736)
x42   
2023-06-10 21:27   
This is an entirely different issue, unrelated to recording.

Would you mind opening another issue and provide some details how to reproduce this, and include the error messags? Thanks in advance.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9361 [ardour] bugs crash random 2023-06-08 13:01 2023-06-10 19:49
Reporter: skygge Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stop-and-forget record leads to crash
Description: If you have a really demanding part to record, and you try to record it using "stop and forget" feature (Ctrl+Space) , sooner or later Ardour crashes.
You can record 10 takes, maybe 20 if you're lucky enough... Just repeat "Shift+Space" and "Ctrl+Space" and you can be 100% sure that Ardour window will disappear.
Tags: crash after a take, recording crash
Steps To Reproduce: Use "Stop and Forget" several times in a row: Shift+Space to start record, Ctrl+Space to stop and forget. I bet you can't reach 30 takes.
Additional Information: Logs attached.
System Description
Attached Files: stop_and_forget_crash.log (5,214 bytes) 2023-06-08 13:01
https://tracker.ardour.org/file_download.php?file_id=4549&type=bug
stop_and_forget_crash_backtrace.log (85,172 bytes) 2023-06-09 22:25
https://tracker.ardour.org/file_download.php?file_id=4556&type=bug
Notes
(0027711)
x42   
2023-06-08 22:00   
Which version of Ardour do you use? Is that 7.4.0 ?

Does this still happen with 7.4.220 (or later)?
If so could you get a backtrace (https://ardour.org/debugging_ardour , demo version from https://nightly.ardour.org/ is fine to test. Thanks in advance)
(0027715)
skygge   
2023-06-09 07:52   
Attached logs are from 7.4.220 so - yes. Well... maybe.
Because there's something strange going on. If I run Ardour in debug mode (-D all) it is very unstable. It crashes all the time on 'everything', even adding a track.
I tried now v7.4.233 in normal mode and it seems to be stable, except debug mode, where I've got one crash after the other.

This is an old story, I remember this issue even in v5... I reported this bug long time ago but it was closed with "cannot reproduce" or something.
(0027716)
x42   
2023-06-09 11:41   
Yeah `-Dall` is pretty useless. It can spit out MBs of texts in under a second :)
and yes -Dxxxx can indeed cause crashes because print happens concurrently from different threads. These -D debug flags are not usually useful to track down crashes, they are more of a developer tool to debug specific issues.

Can you try to get a backtrace running Ardour inside gdb (https://ardour.org/debugging_ardour)?

> I reported this bug long time ago but it was closed with "cannot reproduce" or something.

We don't usually do that. - Then again, Ardour's recording infrastructure was completely overhauled since v5.x, so it is unlikely to be the same issue.
(0027717)
x42   
2023-06-09 11:59   
PS.

I do see see where it crashes. it is a failed assert()ion: Ardour reaches a state that should be impossible to reach: A source is removed while it is still in use.
So far we have not been able to find the root cause and have added the assert() in the hope to get a complete backtrace that can lead this.

It is great that you can apparently re-create it with relative ease.
(0027719)
skygge   
2023-06-09 12:23   
[...]
> Ardour reaches a state that should be impossible to reach
[...]
It reminds me another system I administer: Zabbix. If something is wrong, I see something like this in logs: "Something impossible has just happened". :D
[...]
> I do see see where it crashes
[...]
Is that means I don't need to "try to get a backtrace running Ardour inside gdb" anymore? Regards!
(0027720)
x42   
2023-06-09 12:28   
> I do see see where it crashes
> [...]
> Is that means I don't need to "try to get a backtrace running Ardour inside gdb" anymore? Regards!

I still need the "why" and thread context. but meryl was faster: https://tracker.ardour.org/view.php?id=9363

So thanks to them, you don't need to provide a backtrace anymore.
(0027721)
x42   
2023-06-09 16:50   
(Last edited: 2023-06-09 16:51)
OK should be fixed now in 7.4-238. Please test
(0027726)
skygge   
2023-06-09 20:30   
I can definitely see progress. Ardour crashed at 57th take :D
(0027728)
x42   
2023-06-09 21:43   
I'm not sure how to interpret that smiley. Are you still getting crashes?

And if so, can you get a backtrace?
(0027729)
skygge   
2023-06-09 22:25   
Yes, the crashes are still there but not that often.
Backtrace generated. Thank you for your effort!
(0027730)
x42   
2023-06-10 02:03   
Thank you for your patience and the feedback so far.

Can you please give 7.4-250-ga3e64445de another try?
(0027731)
skygge   
2023-06-10 08:53   
100 takes recorded with no crash. I think you fixed this. Thank you very much! :D :D :D

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9292 [ardour] bugs crash always 2023-03-28 16:38 2023-06-10 19:48
Reporter: thomaskuntz Platform: GNU Linux  
Assigned To: x42 OS: Fedora Workstation  
Priority: normal OS Version: 37  
Status: resolved Product Version: 7.3  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when creating new session from an open session
Description: Ardour crashes when I create a new session while another session is already open.
Tags:
Steps To Reproduce: 1. Open or create a session when Ardour starts up
2. Once this first session is open, go to Session > New… to create a new session
3. Choose any template, choose a session name and click “Open”
4. In the “Audio/MIDI Setup” window that pops up, choose either PulseAudio or ALSA as the Audio System
5. Click “Start”
6. Ardour crashes (it won’t crash if you chose JACK as the Audio System)
Additional Information:
Attached Files: gdb_backtrace.txt (49,677 bytes) 2023-04-06 08:56
https://tracker.ardour.org/file_download.php?file_id=4477&type=bug
message.txt (1,161 bytes) 2023-04-06 09:00
https://tracker.ardour.org/file_download.php?file_id=4478&type=bug
Notes
(0027518)
thomaskuntz   
2023-03-28 18:23   
NB: there is no issue when creating a new session at the start of Ardour when no other session is open yet.
(0027537)
x42   
2023-04-05 15:07   
I tried but cannot reproduce this. Does his happen every time on your system with any initial session?

Could you get a backtrace of the crash? https://ardour.org/debugging_ardour
(0027549)
thomaskuntz   
2023-04-06 08:56   
(0027550)
thomaskuntz   
2023-04-06 09:00   
(0027570)
paul   
2023-04-12 13:24   
Are there plugins in the session being opened? This sort of error can be caused by a plugin trying to draw its GUI from teh wrong thread (and it will be a non-deterministic bug if so)
(0027571)
paul   
2023-04-12 13:26   
Your mantis error was caused by taking "too long" to reply in Mantis. It's a long-lived bug in Mantis (at least 10 years), and I have no idea why they do not fix it, since it is very annoying.
(0027588)
thomaskuntz   
2023-04-16 14:45   
No, there are no plugins in the session. The crash occurs even when I create a new empty session when Ardour starts up and then create another new empty session from there, without doing anything else in between.
(0027589)
paul   
2023-04-16 15:43   
Have you tried a free/demo version from https://ardour.org/download ? It can be installed in parallel with what appears to be a distro package version ...
(0027590)
thomaskuntz   
2023-04-16 18:48   
I had tried with the fedora package (Ardour 7.2.0) and with the flathub flatpak package (version 7.3.0). I just tried with the demo version (7.3.0) that I just installed as you suggested, and I get the exact same behavior in all three cases
(0027732)
thomaskuntz   
2023-06-10 08:55   
I can’t reproduce this bug anymore on Ardour 7.4.0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9364 [ardour] bugs crash sometimes 2023-06-09 12:52 2023-06-09 21:22
Reporter: nils Platform: x86_64  
Assigned To: x42 OS: Fedora Linux  
Priority: normal OS Version: 38  
Status: resolved Product Version: 7.4  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Removing tracks with a connected input or disconnecting the input will often crash if _GLIBCXX_ASSERTIONS is defined
Description: On a binary built with the _GLIBCXX_ASSERTIONS macro set (e.g. the Fedora RPM package of 7.4.0, a local build from git with `./waf configure ... --arch="-Wp,-D_GLIBCXX_ASSERTIONS"`), Ardour very often crashes if I remove a track with a connected input, or if I attempt to disconnect the input.
Tags:
Steps To Reproduce: 1. Build Ardour with _GLIBCXX_ASSERTIONS defined
2. Start Ardour with an empty session
3. Add a track and ensure its input is connected (doesn’t matter if Audio or MIDI track, the latter e.g. connected to the virtual keyboard)
4.1. Right click on the track header in the editor and select "Remove", confirm removal, _or_
4.2. Click the input button in the mixer and select "Disconnect"
Additional Information: Running Ardour with --gdb set, I get this when removing a track causes it to crash …:

--- 8< ---

[New Thread 0x7fff5e7fc6c0 (LWP 40511)]
[New Thread 0x7fff5dffb6c0 (LWP 40512)]
[Thread 0x7fff5e7fc6c0 (LWP 40511) exited]
[Thread 0x7fff5dffb6c0 (LWP 40512) exited]
[Thread 0x7fff86ffd6c0 (LWP 40389) exited]
/usr/include/c++/13/bits/stl_vector.h:1208: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::front() [with _Tp = std::__cxx11::basic_string<char>; _Alloc = std::allocator<std::__cxx11::basic_string<char> >; reference = std::__cxx11::basic_string<char>&]: Assertion '!this->empty()' failed.

Thread 1 "ArdourGUI" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6,
    no_tid=no_tid@entry=0) at pthread_kill.c:44
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
Missing separate debuginfos, use: dnf debuginfo-install ladspa-rev-plugins-0.8.1-1.fc38.x86_64
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
0000001 0x00007ffff44b18b3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff4460abe in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff444987f in __GI_abort () at abort.c:79
0000004 0x00007ffff48df1c0 in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>)
    at ../../../../../libstdc++-v3/src/c++11/debug.cc:61
0000005 0x00000000009aa361 in IOButtonBase::set_label(IOButtonBase&, ARDOUR::Session&, std::shared_ptr<ARDOUR::Bundle>&, std::shared_ptr<ARDOUR::IO>) ()
#6 0x00000000009aad78 in IOButton::update() ()
#7 0x000000000094ab0c in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (ARDOUR::IOChange, void*)>, boost::_bi::list2<boost::_bi::value<ARDOUR::IOChange>, boost::_bi::value<void*> > >, void>::invoke(boost::detail::function::function_buffer&) ()
0000008 0x00007ffff6c28dc2 in AbstractUI<Gtkmm2ext::UIRequest>::call_slot(PBD::EventLoop::InvalidationRecord*, boost::function<void ()> const&) () at /home/nils/opt/ardour/lib/ardour7/libgtkmm2ext.so.0
0000009 0x000000000094b174 in PBD::Signal2<void, ARDOUR::IOChange, void*, PBD::OptionalLastValue<void> >::compositor(boost::function<void (ARDOUR::IOChange, void*)>, PBD::EventLoop*, PBD::EventLoop::InvalidationRecord*, ARDOUR::IOChange, void*) ()
0000010 0x000000000094969d in boost::detail::function::void_function_obj_invoker2<boost::_bi::bind_t<void, void (*)(boost::function<void (ARDOUR::IOChange, void*)>, PBD::EventLoop*, PBD::EventLoop::InvalidationRecord*, ARDOUR::IOChange, void*), boost::_bi::list5<boost::_bi::value<boost::function<void (ARDOUR::IOChange, void*)> >, boost::_bi::value<PBD::EventLoop*>, boost::_bi::value<PBD::EventLoop::InvalidationRecord*>, boost::arg<1>, boost::arg<2> > >, void, ARDOUR::IOChange, void*>::invoke(boost::detail::function::function_buffer&, ARDOUR::IOChange, void*) ()
0000011 0x00007ffff747b981 in PBD::Signal2<void, ARDOUR::IOChange, void*, PBD::OptionalLastValue<void> >::operator()(ARDOUR::IOChange, void*) () at /home/nils/opt/ardour/lib/ardour7/libardour.so.3
0000012 0x00007ffff746f8fe in ARDOUR::IO::disconnect(void*) () at /home/nils/opt/ardour/lib/ardour7/libardour.so.3
0000013 0x00007ffff770d985 in ARDOUR::Session::remove_routes(std::shared_ptr<std::__cxx11::list<std::shared_ptr<ARDOUR::Route>, std::allocator<std::shared_ptr<ARDOUR::Route> > > >) ()
    at /home/nils/opt/ardour/lib/ardour7/libardour.so.3
0000014 0x0000000000846137 in Editor::_remove_tracks() ()
#15 0x0000000000846cc1 in Editor::idle_remove_tracks() ()
0000016 0x00007ffff69683b6 in sigc::slot0<bool>::operator()() const (this=0xe767540) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:535
#17 (anonymous namespace)::glibmm_source_callback(void*) (data=data@entry=0xe767540) at ../glib/glibmm/main.cc:243
0000018 0x00007ffff67b539d in g_idle_dispatch (source=0xcd2e500, callback=0x7ffff6968390 <(anonymous namespace)::glibmm_source_callback(void*)>, user_data=0xe767540) at ../glib/gmain.c:6163
0000019 0x00007ffff67b939c in g_main_dispatch (context=0x1d54ec0) at ../glib/gmain.c:3460
0000020 g_main_context_dispatch (context=0x1d54ec0) at ../glib/gmain.c:4200
0000021 0x00007ffff6817438 in g_main_context_iterate.isra.0 (context=0x1d54ec0, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4276
0000022 0x00007ffff67b899f in g_main_loop_run (loop=0x22ab190) at ../glib/gmain.c:4479
0000023 0x00007ffff635b0d1 in IA__gtk_main () at /usr/src/debug/gtk2-2.24.33-13.fc38.x86_64/gtk/gtkmain.c:1270
#24 0x00007ffff6c21ec6 in Gtkmm2ext::UI::run(Receiver&) () at /home/nils/opt/ardour/lib/ardour7/libgtkmm2ext.so.0
0000025 0x00000000005bad83 in main ()
(gdb)
--- >8 ---

… and this when disconnecing the input causes the crash:

--- 8< ---

[New Thread 0x7fff5a7fc6c0 (LWP 43163)]
[New Thread 0x7fff5affd6c0 (LWP 43164)]
[Thread 0x7fff5a7fc6c0 (LWP 43163) exited]
[Thread 0x7fff5affd6c0 (LWP 43164) exited]
[Thread 0x7fff8b7fe6c0 (LWP 43057) exited]
/usr/include/c++/13/bits/stl_vector.h:1208: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::front() [with _Tp = std::__cxx11::basic_string<char>; _Alloc = std::allocator<std::__cxx11::basic_string<char> >; reference = std::__cxx11::basic_string<char>&]: Assertion '!this->empty()' failed.

Thread 1 "ArdourGUI" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
Missing separate debuginfos, use: dnf debuginfo-install ladspa-rev-plugins-0.8.1-1.fc38.x86_64
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
0000001 0x00007ffff44b18b3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff4460abe in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff444987f in __GI_abort () at abort.c:79
0000004 0x00007ffff48df1c0 in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>)
    at ../../../../../libstdc++-v3/src/c++11/debug.cc:61
0000005 0x00000000009aa361 in IOButtonBase::set_label(IOButtonBase&, ARDOUR::Session&, std::shared_ptr<ARDOUR::Bundle>&, std::shared_ptr<ARDOUR::IO>) ()
#6 0x00000000009aad78 in IOButton::update() ()
#7 0x000000000094ab0c in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (ARDOUR::IOChange, void*)>, boost::_bi::list2<boost::_bi::value<ARDOUR::IOChange>, boost::_bi::value<void*> > >, void>::invoke(boost::detail::function::function_buffer&) ()
0000008 0x00007ffff6c28dc2 in AbstractUI<Gtkmm2ext::UIRequest>::call_slot(PBD::EventLoop::InvalidationRecord*, boost::function<void ()> const&) () at /home/nils/opt/ardour/lib/ardour7/libgtkmm2ext.so.0
0000009 0x000000000094b174 in PBD::Signal2<void, ARDOUR::IOChange, void*, PBD::OptionalLastValue<void> >::compositor(boost::function<void (ARDOUR::IOChange, void*)>, PBD::EventLoop*, PBD::EventLoop::InvalidationRecord*, ARDOUR::IOChange, void*) ()
0000010 0x000000000094969d in boost::detail::function::void_function_obj_invoker2<boost::_bi::bind_t<void, void (*)(boost::function<void (ARDOUR::IOChange, void*)>, PBD::EventLoop*, PBD::EventLoop::InvalidationRecord*, ARDOUR::IOChange, void*), boost::_bi::list5<boost::_bi::value<boost::function<void (ARDOUR::IOChange, void*)> >, boost::_bi::value<PBD::EventLoop*>, boost::_bi::value<PBD::EventLoop::InvalidationRecord*>, boost::arg<1>, boost::arg<2> > >, void, ARDOUR::IOChange, void*>::invoke(boost::detail::function::function_buffer&, ARDOUR::IOChange, void*) ()
0000011 0x00007ffff747b981 in PBD::Signal2<void, ARDOUR::IOChange, void*, PBD::OptionalLastValue<void> >::operator()(ARDOUR::IOChange, void*) () at /home/nils/opt/ardour/lib/ardour7/libardour.so.3
0000012 0x00007ffff746f8fe in ARDOUR::IO::disconnect(void*) () at /home/nils/opt/ardour/lib/ardour7/libardour.so.3
0000013 0x00000000009a466a in IOButton::disconnect() ()
0000014 0x00007ffff696d654 in sigc::slot0<void>::operator()() const (this=0xd0a5bc8) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:535
#15 Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) (self=<optimized out>, data=0xd0a5bc0) at ../glib/glibmm/signalproxy.cc:103
0000016 0x00007ffff68ba4ea in g_closure_invoke (closure=0xf9786b0, return_value=0x0, n_param_values=1, param_values=0x7fffffffc320, invocation_hint=0x7fffffffc2a0) at ../gobject/gclosure.c:832
#17 0x00007ffff68e915d in signal_emit_unlocked_R.isra.0
    (node=node@entry=0x1dc7650, detail=detail@entry=0, instance=instance@entry=0xeb54390, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffc320)
    at ../gobject/gsignal.c:3883
0000018 0x00007ffff68d9cbd in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc4c0) at ../gobject/gsignal.c:3565
0000019 0x00007ffff68d9f33 in g_signal_emit (instance=instance@entry=0xeb54390, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3622
0000020 0x00007ffff64a6a3c in IA__gtk_widget_activate (widget=0xeb54390) at /usr/src/debug/gtk2-2.24.33-13.fc38.x86_64/gtk/gtkwidget.c:5048
0000021 0x00007ffff6373cad in IA__gtk_menu_shell_activate_item (menu_shell=0xd867770, menu_item=0xeb54390, force_deactivate=<optimized out>) at /usr/src/debug/gtk2-2.24.33-13.fc38.x86_64/gtk/gtkmenushell.c:1305
0000022 0x00007ffff63763b1 in gtk_menu_shell_button_release (widget=0xd867770, event=<optimized out>) at /usr/src/debug/gtk2-2.24.33-13.fc38.x86_64/gtk/gtkmenushell.c:730
0000023 0x00007ffff635d3ee in _gtk_marshal_BOOLEAN__BOXED
    (closure=0x1db8da0, return_value=0x7fffffffc810, n_param_values=<optimized out>, param_values=0x7fffffffc870, invocation_hint=<optimized out>, marshal_data=<optimized out>)
    at /usr/src/debug/gtk2-2.24.33-13.fc38.x86_64/gtk/gtkmarshalers.c:84
#24 0x00007ffff68ba4ea in g_closure_invoke (closure=0x1db8da0, return_value=0x7fffffffc810, n_param_values=2, param_values=0x7fffffffc870, invocation_hint=0x7fffffffc7f0) at ../gobject/gclosure.c:832
0000025 0x00007ffff68e9315 in signal_emit_unlocked_R.isra.0
    (node=<optimized out>, detail=detail@entry=0, instance=instance@entry=0xd867770, emission_return=emission_return@entry=0x7fffffffc980, instance_and_params=instance_and_params@entry=0x7fffffffc870)
    at ../gobject/gsignal.c:3851
0000026 0x00007ffff68d97e2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffca30) at ../gobject/gsignal.c:3575
0000027 0x00007ffff68d9f33 in g_signal_emit (instance=instance@entry=0xd867770, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3622
0000028 0x00007ffff64a8bf4 in gtk_widget_event_internal (widget=0xd867770, event=0xfbbed20) at /usr/src/debug/gtk2-2.24.33-13.fc38.x86_64/gtk/gtkwidget.c:5017
0000029 0x00007ffff635ffb3 in IA__gtk_propagate_event (widget=0xd867770, event=0xfbbed20) at /usr/src/debug/gtk2-2.24.33-13.fc38.x86_64/gtk/gtkmain.c:2503
0000030 0x00007ffff6361c7b in IA__gtk_main_do_event (event=0xfbbed20) at /usr/src/debug/gtk2-2.24.33-13.fc38.x86_64/gtk/gtkmain.c:1698
0000031 IA__gtk_main_do_event (event=<optimized out>) at /usr/src/debug/gtk2-2.24.33-13.fc38.x86_64/gtk/gtkmain.c:1503
0000032 0x00007ffff61a318e in gdk_event_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at x11/gdkevents-x11.c:2425
0000033 0x00007ffff67b939c in g_main_dispatch (context=0x1d46b90) at ../glib/gmain.c:3460
0000034 g_main_context_dispatch (context=0x1d46b90) at ../glib/gmain.c:4200
0000035 0x00007ffff6817438 in g_main_context_iterate.isra.0 (context=0x1d46b90, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4276
0000036 0x00007ffff67b899f in g_main_loop_run (loop=0x21dea70) at ../glib/gmain.c:4479
0000037 0x00007ffff635b0d1 in IA__gtk_main () at /usr/src/debug/gtk2-2.24.33-13.fc38.x86_64/gtk/gtkmain.c:1270
0000038 0x00007ffff6c21ec6 in Gtkmm2ext::UI::run(Receiver&) () at /home/nils/opt/ardour/lib/ardour7/libgtkmm2ext.so.0
0000039 0x00000000005bad83 in main ()
(gdb)
--- >8 ---
Attached Files:
Notes
(0027723)
x42   
2023-06-09 17:20   
Fixed in 7.4-241-g9486b4e6cb, please test.
(0027727)
nils   
2023-06-09 21:22   
Works for me now. Thanks for the quick fix!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9362 [ardour] features major always 2023-06-09 06:56 2023-06-09 07:05
Reporter: dsfdsf Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Organaize plugin tag in plugin selector
Description: traditionally if you decide to reorder / organize you plugin with tags in ardour you should edit plugin tag one by one
and to organize individual tag you need modify it from plugins are linked to it in text format

why not create button for tag/s and dropdown menu to un/link
like this in bellow screenshot

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: fe.png (194,366 bytes) 2023-06-09 06:56
https://tracker.ardour.org/file_download.php?file_id=4552&type=bug
png
Notes
(0027714)
dsfdsf   
2023-06-09 07:05   
and when you click on tag/s just show linked plugin/s to this tag

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9347 [ardour] bugs minor always 2023-05-23 16:49 2023-06-09 06:38
Reporter: dsfdsf Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: monitor section doesn't save processor box status / it is open or close
Description: when i work on a session add some plugin to monitor section processor box and keep it (processor box) open
but after close session and reopen it monitor section processor box are close
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: b.png (61,839 bytes) 2023-06-09 06:38
https://tracker.ardour.org/file_download.php?file_id=4550&type=bug
png

b2.png (41,180 bytes) 2023-06-09 06:38
https://tracker.ardour.org/file_download.php?file_id=4551&type=bug
png
Notes
(0027713)
dsfdsf   
2023-06-09 06:38   

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9360 [ardour] bugs minor always 2023-06-07 15:04 2023-06-09 01:09
Reporter: Largos Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Play Selected Region behaviour
Description: If you press the "Play Selected Region" shortcut when the transport is running, the transport does not stop at the end of the region. This differs when you play it from the transport stop. I don't see why you would want it to keep running when just telling it to play a selected region.
Tags:
Steps To Reproduce: Press "Play Selected Region" when the transport is running
Additional Information:
System Description
Attached Files:
Notes
(0027709)
x42   
2023-06-08 15:04   
Fixed in Ardour 7.4-221-gcd2d0448a9
(0027710)
x42   
2023-06-08 15:26   
The issue is not entirely resolved:

locating during range-playback does not unset Play-range,
and the Range Stop event is not cleared when reading the end of the range.
(0027712)
x42   
2023-06-09 01:09   
OK, fixed now in 7.4.223

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9341 [ardour] features feature always 2023-05-21 18:04 2023-06-07 23:45
Reporter: dsfdsf Platform:  
Assigned To: x42 OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add K-meter to "Default meter type for tracks"
Description: why tracks don't have option to set default metering as k-meters
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027664)
x42   
2023-05-22 03:17   
> why tracks don't have option to set default metering as k-meters

Because it does not (usually) make sense. When tracking you need to make sure to not clip the signal, and hence needs a digital-peak meter.
Measuring loudness as perceived by humans is useful during mixing after summing on busses or the master-bus.

see also https://manual.ardour.org/meters/
(0027674)
dsfdsf   
2023-05-23 10:07   
as far i understand k-meter is RMS + peak meter but just scaled by k-system
 
if K-meter problem is it doesn't show cliping
it have peak meter and also when you achieve top of this scale (doesn't mater what number you receive) you are get cliped
   k-meter give user a ton of headroom - cliping??
so maybe some user (like me) want mix with k-meter and set it zero as ref in tracks to mix with ton of headroom
then in bus processing go it up near to clip level

i dont think this option be worth to kill
(0027681)
screwtop   
2023-05-25 06:09   
I'd second this feature request. IMO, K-System meters offer great ergonomics for track metering when recording. I typically use K-20 for individual tracks, and K-14 on the master for mixing and mastering, and if the levels are around 0 on the tracks, it usually ends up around 0 on the master. Clipping is very unlikely if you track around 0 on a K-20, and there's extra CPU load, I haven't noticed it!

I think it would be nice to have them (and why not all types?) available as options for the default track meter type.
(0027687)
dsfdsf   
2023-05-27 11:15   
@x42

With 32-bit float processing, you’ll never clip so long as your audio stays in the DAW
(0027693)
dsfdsf   
2023-05-28 17:06   
@x42

I invite you to a duel
Whoever killed that one will decide on this option
:D
(0027706)
x42   
2023-06-07 20:22   
> With 32-bit float processing, you’ll never clip so long as your audio stays in the DAW

sure by tracks are for tracking, and usually have analog inputs.

> I invite you to a duel

OK, my weapon of choice is the banjo :)

Well Ardour already provides sufficient rope to shoot yourself in the foot, and if you want K-meters.. why not. Might as well also offer 0dB Peak meters for busses.
(0027707)
x42   
2023-06-07 20:23   
Added in 7.4.220
(0027708)
screwtop   
2023-06-07 23:45   
Thank you. :) It did occur to me that something like K-20 is well-suited to channel monitoring for live mixing as well. I do agree that avoiding clipping when capturing is one of the most important things (but 24 bits is really a lot of resolution).

And, why not...
https://www.youtube.com/watch?v=sDsn-RRmDXU

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9359 [ardour] bugs crash always 2023-06-06 11:18 2023-06-06 13:40
Reporter: nils Platform: x86_64  
Assigned To: x42 OS: Fedora Linux  
Priority: normal OS Version: 38  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stopping recording MIDI makes Ardour hang (current git)
Description: In a build from current git (7.4-207-g3468ffddbb), recording from a MIDI keyboard into a MIDI track (with ReasonableSynth) makes Ardour "forget" the recently recorded region, then hang, first partly (e.g. playhead can’t be moved) then fully (UI becomes fully unresponsive, then GNOME asks whether to wait or force quit Ardour).
Tags:
Steps To Reproduce: With Auto-Return enabled and a MIDI keyboard connected and hooked up to a MIDI track (using ReasonableSynth),

- Start recording (e.g. Shift-Space, or MMC Record Pause + MMC Play, or MMC Record Strobe)
- Play some notes
- Stop recording (e.g. Space, or MMC Stop)

At this point, the playhead stays where it is, the just recorded MIDI region vanishes and parts of the UI become unresponsive (e.g. the playhead can’t be moved, or any transport control buttons (play, record enable, stop). After a while, the whole UI becomes unresponsive.
Additional Information: This works in Ardour 7.4.0 (sans the MMC commands, see 0009358), either the Fedora RPM package or the binary version from ardour.org: the playhead returns to the beginning of the recorded region, the region doesn’t vanish and Ardour stays operational.
Attached Files:
Notes
(0027705)
x42   
2023-06-06 13:40   
Fixed in 7.4-208-g6865615af8

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8952 [ardour] bugs minor always 2022-08-12 14:08 2023-06-04 14:52
Reporter: FabienB Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: low OS Version: (any)  
Status: resolved Product Version: 6.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Clear all xruns" is not working
Description: In the Ruler, Location Markers, right-click menu proposes "Clear all xruns" option which is not working. "Clear all locations" is working and delete markers and xruns as well.

Tested on Ubuntu 20.04.4 LTS and Ardour 6.9.0 (Official build).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027700)
robertaramar   
2023-06-01 08:09   
Just came across the same issue in 7.4
(0027704)
x42   
2023-06-04 14:52   
Fixed in 7.4-190.

The problem is that the markers were not flagged as being "xrun" markers. So in old sessions you can only remove them my name.
You can do this: Menu > Window > Scripting ... in the dropdown center/right pick "Action > Delete xrun markers" and press "run".

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9358 [ardour] bugs crash always 2023-06-02 16:51 2023-06-03 23:16
Reporter: nils Platform: x86_64  
Assigned To: x42 OS: Fedora Linux  
Priority: normal OS Version: 38  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MMC: record pause or record strobe crashes Ardour
Description: The MMC commands "record pause" or "record strobe" make Ardour crash.
Tags:
Steps To Reproduce: I've configured a MIDI keyboard to send "record pause" or "record strobe" MMC commands and connected it as an input to MMC in in Ardour. When pressing the respective button on the keyboard, Ardour crashes. Other MMC commands (like play, stop) work as expected.
Additional Information: I tried it in Ardour 7.4.0 as packaged in Fedora, the binary downloaded from ardour.org and built on my machine from current git (commit c56313cea058b197aa47b53a47434be0bb1727a5). All three crash as described.
System Description
Attached Files:
Notes
(0027702)
x42   
2023-06-03 23:16   
Fixed in 7.4.182

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9344 [ardour] features feature N/A 2023-05-22 23:45 2023-05-31 23:46
Reporter: wargreen Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Routing by audio device
Description: In the case of a session created with lot of external I/O is open, edited and saved with another device with less I/O, we just lost the routing for the original device.
Example : a live recording session used for a virtual souncheck, we do some edit on the internal soundcard in the train...
Or : a session with many live clips tracks routed to different outputs, we need to mix it better without the big soundcard...

I imagine a workflow as this (but maybe some are better) :
Save the external (to hardware) routing by audio device
If the device is changed AND the current routing will change something to the routing for this device :
  a popup with "The audio device changed, what to do ?" "Load original routing" / "Stay with current routing"

And maybe is it a way to merge the two routings ? Only load the previous routing for a track if the current routing is not to an hardware port ?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027684)
x42   
2023-05-26 22:21   
Since Ardour 7.4-146 external connections are unconditionally remembered per device. So no popup dialog is needed.

One exception is made for the master and monitor output busses. The first time a new device is used, and if Preferences > Signal Flow > Auto-connect main output is enabled, mains-out is connected.
(0027685)
x42   
2023-05-26 22:25   
I think it's preferable to not try to be smart, and not attempt to "merge" existing external connections from different interfaces.
But rather maintain a consistent set of connections for each setup. -- Internal connections are not affected.

Please test and let me know if the issue can be closed.
(0027696)
wargreen   
2023-05-31 22:33   
The external routing by device work perfectly, thank you for this work !

I understand the choice to not touch the internal connection but it leads to an issue :
If a port is connected to an external output with device 1, then we switch to device 2, this port is now auto-connected to the master (or manually to a bus...).
Switch back to the device 1 leads to an unexpected double signal path : external + master (that is connected to external).

I think that should be avoided (think to a live situation with PA), and in this case the signal path is not consistent for each setup.

Maybe somebody have a better idea, but mine :
If a port should be connected to external by switching device _this port_ should be connected as saved, internal connection included.

So, RFC open !
(0027697)
x42   
2023-05-31 23:33   
> If a port is connected to an external output with device 1, then we switch to device 2, this port is now auto-connected to the master (or manually to a bus...).

That is not the case, there are no internal auto-connections made when switching backends. Please check again.
(0027698)
x42   
2023-05-31 23:35   
Internal connections are entirely separate independent from the device used and will remain so.
Hence it is not possible to have it disconnected to master or connected to master depending on the backend in use.
(0027699)
x42   
2023-05-31 23:46   
IIUC you want to toggle between two modes

1. each track has is a pass-trhu in -> no panner -> out
2. each track is connected to master with a panner

My first suggestion would be to simply ignore the additional master-bus connection in case of (1), and simply disconnect the master output (which will be remembered).
But in case of (1) that would also mean removing an extra output for each mono track (assuming a stereo master). You could add external sends (pre-panner) to each track instead.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9329 [ardour] bugs minor always 2023-05-09 09:01 2023-05-31 09:11
Reporter: al f Platform: Arch  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: cannot have two events of type TransportStateChange at the same sample
Description: When playing back recorded / edited audio, if changing playhead position by using arrow keys, the red warning light is lit and messages like these populate the log:

2023-05-09T10:38:49 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone
2023-05-09T10:38:49 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (6049280).
2023-05-09T10:38:49 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone
2023-05-09T10:38:49 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (5977280).
2023-05-09T10:49:22 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone
2023-05-09T10:49:22 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone
2023-05-09T10:49:22 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (7585280).
2023-05-09T10:49:22 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone
2023-05-09T10:49:22 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (7537280).
2023-05-09T10:49:22 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone
2023-05-09T10:49:22 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (7513280).

The playhead skips backwards in jumps as expected, playback is not affected and there seems to be no other unwanted events.
Tags: Editor, playhead
Steps To Reproduce: 1. Import or record audio
2. Play back audio
3. while playing back, press and hold LEFT or RIGHT
4. Observe the small light indicating error logs / warning turn on, red.
Additional Information:
System Description
Attached Files:
Notes
(0027694)
agittins   
2023-05-31 07:55   
I am experiencing what appears to be the same issue.

In Ardour 7.40 and 7.30 I can open a new session, press "Play" and and the transport buttons appear to respond but immediately revert to stopped (sometimes too fast for me to notice, but always "immediately", by which I mean inside of 200ms). On the first press of play, no log output is produced. If I press play again (and any subsequent time) I get output of:

```
2023-05-31T17:14:21 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (2048).
2023-05-31T17:14:26 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (2048).
2023-05-31T17:14:26 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (2048).
```

My pipewire quant is 1024, and the above is if the playhead is at sample 0, I can reposition the playhead, and pressing play the first time outputs no messages (and transport stops "immediately"), and on subsequent presses of play it outputs:

```
2023-05-31T17:18:06 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (866048).
2023-05-31T17:18:12 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (866048).
2023-05-31T17:18:12 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (866048).
2023-05-31T17:18:13 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (866048).
```

The playhead for the output above was at sample 864000, so the sample noted in the output appears to be playheadPosition + 2048, so perhaps playheadPosition+ ( 2 x bufferSize ).

I'm on Debian Sid, running Ardour from the official Ardour builds (not distro packages). I am connecting as a jack client to Pipewire, which I just upgraded to 0.3.71 using packages from Debian's experimental repos - I did that because I was experiencing the lockup when adding a midi track issue from https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3183. Previously I have been experiencing strange issues with routing (both midi and audio ports not connecting properly within Ardour) which I think there were some likely fixes for in my upgrade from 0.3.65.

If I go into "Transport Masters" and set JACK as the master, AND click the External Positional Sync button (so it goes from "Int." to "JACK") the transport will now roll on command, both from within Ardour or by using the `jack-transport` cli utility. Seeking is weird though, if I click in the timeline the playhead jumps to sample 0, but transport will roll from the clicked position when started. If I click twice (in *exactly* the same location) the playhead jumps to 0 on first click, then to the chosen spot. However in this case hitting play doesn't show the transport rolling, but hitting stop relocates the playhead to somewhere forward of that location. Super weird.

If I add an audio clip to a track in the cue window and click the "play" button next to the slot, the transport no longer rolls and I get the same error messages as above in the Log window. The transport won't roll again until I clear the slot, at which point the transport rolls immediately (without hitting play) as if it were blocked waiting on the slot. Could this be an issue related to how the cue feature integrates with the timeline / transport? Just an idea.

FWIW, previous to upgrading pipewire I was having issues with cues being a bit finicky about stopping and starting, if I recall correctly it would do things like a slot wouldn't stop playing, or once I did get it to I couldn't start others etc. I didn't get a handle on exactly what interaction sequences would cause or resolve that, I was creating so just instinctively clicked around until things worked again. It happened frequently enough that it felt like I was possibly not using it correctly.

I'm using wireplumber 0.4.12 (from debian) as the session manager. Kernel is 6.1.27-1. I don't see anything audio/ardour related or coincident in dmesg or journalctl.

In `~/.config/pipewire/pipewire.conf.d/99-ajg-custom.conf` I have:
```
context.properties = {
    ## Properties for the DSP configuration.
    default.clock.rate = 48000
    default.clock.allowed-rates = [ 48000 ]
    default.clock.quantum = 1024
    default.clock.min-quantum = 16
    #default.clock.max-quantum = 2048
    #default.clock.quantum-limit = 8192
    #default.video.width = 640
    #default.video.height = 480
    #default.video.rate.num = 25
    #default.video.rate.denom = 1
    #
    settings.check-quantum = true
    settings.check-rate = true
    #
    # These overrides are only applied when running in a vm.
    vm.overrides = {
        default.clock.min-quantum = 1024
    }

    # AJG - might help ardour midi issues
    alsa.seq.name = "a2j"
}
```

And in `~/.config/pipewire/jack.conf.d/99-ajg-custom.conf` I have:
```
jack.properties = {
     node.latency = 1024/48000
     node.rate = 1/48000
     node.quantum = 1024/48000
     node.lock-quantum = true
     #node.force-quantum = 0
     #jack.show-monitor = true
     #jack.merge-monitor = true
     #jack.short-name = false
     #jack.filter-name = false
     #jack.filter-char = " "
     #
     # allow: Don't restrict self connect requests
     # fail-external: Fail self connect requests to external ports only
     # ignore-external: Ignore self connect requests to external ports only
     # fail-all: Fail all self connect requests
     # ignore-all: Ignore all self connect requests
     #jack.self-connect-mode = allow
     #jack.locked-process = true
     #jack.default-as-system = false
     #jack.fix-midi-events = true
     #jack.global-buffer-size = false


    # <https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-JACK>

    # Enable this to have the default sink and source show as system:capture_2 etc.
    # jack.default-as-system = true

    jack.short-name = true
    # AJG: Stops it from re-writing note-on-velocity-zero messages
    # into note-offs (which breaks the MotorMix ping/echo).
     jack.fix-midi-events = false
}
```
(0027695)
agittins   
2023-05-31 09:11   
Further experimenting (now with 7.4.163 from nightlies) reveals:

- If I have an empty, new session, with the default “Int” sync set, the transport won’t roll.

- If I add a midi track OR an audio track, AND in the cue window add any clip to a slot, the transport will now roll (either just rolling the timeline with no cues triggered, or by hitting the play button next to the slot.

So it seems like the internal transport won’t roll unless there’s a clip loaded into a slot somewhere, regardless of whether that cue is part of playback or not.

Turning off the “Play Cues” button doesn’t alter the behaviour.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9352 [ardour] features feature N/A 2023-05-26 06:39 2023-05-27 13:42
Reporter: whanake Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: low OS Version: (any)  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow renaming of plugin instances in mixer strips
Description: It would be useful for organization purposes if the user were able to rename plugin instances inside each channel's mixer strip, preferably by a 'Rename' option in the right-click context menu for each plugin instance.
Tags: instance, plugin, rename
Steps To Reproduce: N/A
Additional Information: N/A
System Description
Attached Files:
Notes
(0027689)
x42   
2023-05-27 13:42   
Implemented in Ardour 7.4.152

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9343 [ardour] bugs major always 2023-05-22 17:27 2023-05-25 16:31
Reporter: unfa Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Export silence trim applies unwanted noise gating
Description: Noise trimming results in exports being noise-gated, poking holes in the audio.
This can be seen as black bars on the export analysis spectrogram.

Tags: audio, export, silence, Trim
Steps To Reproduce: I'm attaching a test project.

Open it and export the session with silence trimming enabled.
You should see a striped spectrogram - with chunks of the audio missing.

Now disabled silence trimming and try again - the black bars will be gone.
Additional Information:
System Description
Attached Files: Silence trim gating repro_2023-05-22_191755.ardour-session-archive (7,076 bytes) 2023-05-22 17:34
https://tracker.ardour.org/file_download.php?file_id=4536&type=bug
silence-trim-spektrum.png (262,225 bytes) 2023-05-23 00:22
https://tracker.ardour.org/file_download.php?file_id=4537&type=bug
silence-trim-settings.png (90,596 bytes) 2023-05-23 00:22
https://tracker.ardour.org/file_download.php?file_id=4538&type=bug
png

Ardour_LoVseLzisO.png (50,036 bytes) 2023-05-23 11:22
https://tracker.ardour.org/file_download.php?file_id=4539&type=bug
png

Ardour_kK28HfwiZk.png (51,398 bytes) 2023-05-23 11:36
https://tracker.ardour.org/file_download.php?file_id=4540&type=bug
png

Ardour_lu4cFHLfBy.png (259,103 bytes) 2023-05-23 11:36
https://tracker.ardour.org/file_download.php?file_id=4541&type=bug
png

Ardour_vxgJwWUXB7.png (84,980 bytes) 2023-05-23 11:36
https://tracker.ardour.org/file_download.php?file_id=4542&type=bug
png
Notes
(0027670)
unfa   
2023-05-22 17:34   
Minimal reproduction project.
(0027671)
unfa   
2023-05-22 17:34   
I've also reported this to Paul on Discord:
https://discord.com/channels/344542072855986178/727813815454138408/1110258129410723850
(0027673)
x42   
2023-05-23 00:22   
Can you elaborate which settings you use to export?

I have just tested this and cannot reproduces this
(0027675)
unfa   
2023-05-23 11:22   
The only difference I see is that I selected Shaped Noise dither, and you have no dither selected here. I'll try with no dither on my side.
(0027676)
unfa   
2023-05-23 11:27   
I've tested with no dithering and I have the same (gated) result. Could you test on Windows?
Maybe this is caused by some dependency misbehaving on Windows, while working as expected on Linux?

I could provide you with remote access to my Windows machine (via RustDesk) for debugging, if that'd be useful.
(0027677)
unfa   
2023-05-23 11:36   
Here's an export from official 7.4.2.117 Windows 64-bit build with NO dithering:
(0027678)
unfa   
2023-05-23 11:37   
*7.4.117 (I typed some nonsense version number above, sorry)
(0027682)
x42   
2023-05-25 16:02   
I just tested this on Windows 11 (at Harrison), and cannot reproduce this there either.
I also cannot see how silence trim would cut out something in the middle. Can you double-check that disabling that option exports correctly?

BTW, have you edited %localappdata%\Ardour7\config and changed
 Option name="export-silence-threshold" value="-90"
(0027683)
x42   
2023-05-25 16:31   
While the backend should not matter, the data track -> master is still passed via the backend.
I have checked with both Dummy, and Portaudio/ASIO to be certain.
I've also re-imported the exported file and verified the loudness (Region > Loudness Analysis) and checked level with the "internal edit tool" to be within -67 and -57 dBFS.

This is mysterious..

Could you try with a different user (new preferences)?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9351 [ardour] bugs minor always 2023-05-25 08:54 2023-05-25 08:54
Reporter: batinste Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour sends plugin parameter values as doubles instead of floats via OSC
Description: When querying Ardour via OSC for its plugin parameters values, we get doubles when floats would be enough.

Suggestion : add a flag to the osc feedback parameters to select floats instead of doubles for plugin parameters values.
Tags:
Steps To Reproduce: Query Ardour with
/strip/plugin/descriptor ssid pid

Ardour answers with 'd' type-tagged messages.
Additional Information: See the discussion with Robin here : https://discourse.ardour.org/t/osc-type-tag-d-for-plugin-descriptors/108772
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9346 [ardour] bugs crash sometimes 2023-05-23 09:44 2023-05-24 20:47
Reporter: tarball Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when recording
Description: Ardour 7.3
I have a recording session with a couple of tracks and plugins, one of this track gets a mic as input. Ardour crashes each time I hit play when record is loaded.
The terminal displays:
> Segmentation fault (core dumped)

I found the voice track makes the program crash (when I toggle off its REC button, the crash doesn’t happen).
I also found that if I create this track again, the issue disappears. I wasn’t able to find the difference between the new and crashing voice track.
My problem appears to be solved for now, but the bug definitely exists. I will update this issue if it reappears.
Tags: 7.3
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027680)
x42   
2023-05-24 20:47   
This is likely already fixed in Ardour 7.4 (or rather since 7.3-94-g5c69aef56e)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9348 [ardour] features feature have not tried 2023-05-23 16:55 2023-05-23 16:55
Reporter: dsfdsf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Duplicating selected plugin in processor box with ' Ctrl + D ' key
Description: Duplicating selected plugin with ' Ctrl + D ' instead copy and paste
in 7.4
 i dont see shortcut for copy and pasting plugin
just user can select copy and paste option from menu
right ??

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9345 [ardour] bugs minor always 2023-05-23 09:17 2023-05-23 14:28
Reporter: dsfdsf Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Delete key doesnt remove plugin from monitor section processors box
Description: in regular track and bus when select a plugin and press delete key on keyboard plugin/s are removed
but in monitor section processor box delete key doesn't remove selected plugin/s
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027679)
x42   
2023-05-23 14:28   
Fixed since Ardour 7.4.18

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9342 [ardour] bugs minor always 2023-05-21 20:58 2023-05-22 15:15
Reporter: flowz Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Noise shaping doesn't work
Description: The current noise shaping algorithm doesn't work as it doesn't use the error value within the error feedback function, because it always gets overridden by noise before any usage.

I fixed the implementation by looking at Audacitys dither code which is ironically based on Ardours code.

I attached 2 short 8 bit FLAC example exports for illustration, one before and one after the bugfix.
Furthermore I attached a spectrogram for each of the files.

I uploaded the fixed cpp file which I used to generate the "fixed" FLAC.

Furthermore calling gdither_noise() twice gave me the very best results, much better than using the same logic from GDitherTri, but feel free to make you own experiments.
Tags:
Steps To Reproduce: Export a file with noise shaping selected. Export 8 bit PCM for the best test results.
Additional Information:
Attached Files: diffview.png (273,576 bytes) 2023-05-21 20:58
https://tracker.ardour.org/file_download.php?file_id=4530&type=bug
noise_shape_bugged.flac (99,246 bytes) 2023-05-21 20:58
https://tracker.ardour.org/file_download.php?file_id=4531&type=bug
noise_shape_fixed.flac (120,699 bytes) 2023-05-21 20:58
https://tracker.ardour.org/file_download.php?file_id=4532&type=bug
noise_shape_bugged.flac.png (201,002 bytes) 2023-05-21 20:58
https://tracker.ardour.org/file_download.php?file_id=4533&type=bug
png

noise_shape_fixed.flac.png (195,685 bytes) 2023-05-21 20:58
https://tracker.ardour.org/file_download.php?file_id=4534&type=bug
png

gdither.cc (12,572 bytes) 2023-05-21 20:58
https://tracker.ardour.org/file_download.php?file_id=4535&type=bug
Notes
(0027663)
x42   
2023-05-22 01:23   
While this ostensibly fixes the issue, it does not seem to be right. With this change "ideal" is really the error.
The key difference in your patch seems to be to use triangular shaped noise (gdither_noise() + gdither_noise()) * 0.5f;

It has been a while since I've looked into shaped dithering, I'll have to refresh my memory.
(0027668)
x42   
2023-05-22 15:15   
I have applied your patch with minor changes. Thank you for tracking this down!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9242 [ardour] bugs crash always 2023-02-16 11:22 2023-05-18 09:16
Reporter: gonsolo Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when playing and jumping forward/backward with the mouse
Description: Ardour crashes with a SIGSEG while playing and trying to jump around with the mouse.


Tags:
Steps To Reproduce: 1. Open my session
2. Play
3. Jump in the timeline via mouse clicks
4. Crash
Additional Information: Git commit: 31a3c3c6f30dbcc6a9f0b4a3b8c935c6ea428ae4

Stack trace:

#0 0x00007ffff7e85118 in Temporal::TempoMetric::reftime() const (this=this@entry=0x7fffffffb6f0) at ../libs/temporal/tempo.cc:663
0000001 0x00005555562bbd76 in Temporal::TempoMetric::round_to_bar(Temporal::BBT_Time const&) const (bbt=..., this=0x7fffffffb6f0)
    at ../libs/temporal/temporal/tempo.h:502
#2 Temporal::TempoMap::round_to_bar(Temporal::BBT_Argument const&) const (bbt=..., this=0x55555801b950) at ../libs/temporal/temporal/tempo.h:859
#3 MiniTimeline::render(Cairo::RefPtr<Cairo::Context> const&, _cairo_rectangle*) (this=0x5555572794e8, ctx=<optimized out>)
    at ../gtk2_ardour/mini_timeline.cc:609
0000004 0x00007ffff6bf9f68 in CairoWidget::on_expose_event(_GdkEventExpose*) (this=0x5555572794e8, ev=0x7fffffffbe20)
    at ../libs/gtkmm2ext/cairo_widget.cc:207
0000005 0x00007ffff5e61459 in Gtk::Widget_Class::expose_event_callback(_GtkWidget*, _GdkEventExpose*) (self=0x5555573e9ee0, p0=0x7fffffffbe20)
    at /build/gtkmm2.4-uNdZjB/gtkmm2.4-2.24.5/gtk/gtkmm/widget.cc:4479
#6 0x00007ffff63434d7 in _gtk_marshal_BOOLEAN__BOXED
    (closure=0x5555572fea20, return_value=0x7fffffffba20, n_param_values=<optimized out>, param_values=0x7fffffffba80, invocation_hint=<optimized out>, marshal_data=<optimized out>) at /build/gtk+2.0-AJUhhk/gtk+2.0-2.24.33/debian/build/shared/gtk/gtkmarshalers.c:84
#7 0x00007ffff6999f50 in g_closure_invoke
    (closure=0x5555572fea20, return_value=0x7fffffffba20, n_param_values=2, param_values=0x7fffffffba80, invocation_hint=0x7fffffffba00)
    at ../../../gobject/gclosure.c:832
0000008 0x00007ffff69c7e95 in signal_emit_unlocked_R.isra.0
    (node=<optimized out>, detail=detail@entry=0, instance=instance@entry=0x5555573e9ee0, emission_return=emission_return@entry=0x7fffffffbb90, instance_and_params=instance_and_params@entry=0x7fffffffba80) at ../../../gobject/gsignal.c:3835
0000009 0x00007ffff69b7b86 in g_signal_emit_valist
    (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffbc40)
    at ../../../gobject/gsignal.c:3559
0000010 0x00007ffff69b8403 in g_signal_emit (instance=instance@entry=0x5555573e9ee0, signal_id=<optimized out>, detail=detail@entry=0)
    at ../../../gobject/gsignal.c:3606
0000011 0x00007ffff646f024 in gtk_widget_event_internal (widget=0x5555573e9ee0, event=0x7fffffffbe20) at ../../../../gtk/gtkwidget.c:5017
0000012 0x00007ffff63431c3 in IA__gtk_main_do_event (event=0x7fffffffbe20) at ../../../../gtk/gtkmain.c:1637
0000013 IA__gtk_main_do_event (event=<optimized out>) at ../../../../gtk/gtkmain.c:1517
0000014 0x00007ffff67d94c9 in _gdk_window_process_updates_recurse (window=window@entry=0x55557d989000, expose_region=expose_region@entry=0x555576cca300)
    at ../../../../gdk/gdkwindow.c:5479
#15 0x00007ffff67d9449 in _gdk_window_process_updates_recurse (expose_region=0x555576cca300, window=0x55557d989000)
    at ../../../../gdk/gdkregion-generic.c:1545
0000016 _gdk_window_process_updates_recurse (window=window@entry=0x555558dba360, expose_region=expose_region@entry=0x5555837000f0)
    at ../../../../gdk/gdkwindow.c:5452
#17 0x00007ffff67d9449 in _gdk_window_process_updates_recurse (expose_region=0x5555837000f0, window=0x555558dba360)
    at ../../../../gdk/gdkregion-generic.c:1545
0000018 _gdk_window_process_updates_recurse (window=0x5555572a5c60, expose_region=0x555583880990) at ../../../../gdk/gdkwindow.c:5452
0000019 0x00007ffff67cf155 in gdk_window_process_updates_internal (window=0x5555572a5c60) at ../../../../gdk/gdkregion-generic.c:1545
0000020 0x00007ffff67cf8e8 in IA__gdk_window_process_all_updates () at ../../../../gdk/gdkwindow.c:5752
0000021 0x00007ffff67cf98d in gdk_window_update_idle (data=<optimized out>) at ../../../../gdk/gdkwindow.c:5372

Bisected commits (one bad, one skipped because it didn't compile):

commit 2c7bfa9eadf75e9d71e864886bf15ed3fadcbb45 (refs/bisect/bad)
Author: Paul Davis <paul@linuxaudiosystems.com>
Date: Sun Feb 12 12:02:33 2023 -0700

    require use of BBT_Argument as both parameter and return type from most methods (GUI edition)

commit 259499fc5f9a349a9c729947813bdb5231fbdaa9 (refs/bisect/skip-259499fc5f9a349a9c729947813bdb5231fbdaa9)
Author: Paul Davis <paul@linuxaudiosystems.com>
Date: Sun Feb 12 12:02:22 2023 -0700

    require use of BBT_Argument as both parameter and return type from most methods (libs edition)
System Description
Attached Files: 0001-Revert-require-use-of-BBT_Argument-as-both-parameter.patch (25,679 bytes) 2023-02-25 22:37
https://tracker.ardour.org/file_download.php?file_id=4406&type=bug
Notes
(0027391)
gonsolo   
2023-02-17 08:40   
Link to session (that crashes at startup but works with 7.3): https://drive.google.com/file/d/1cJAgviVrdxMPJOKR__kJYVSUeN_cGYkX/view?usp=share_link
(0027411)
gonsolo   
2023-02-25 22:37   
The attached patch make the crash go away (in my private branch, but mostly on top of 3b0a19d30efe12f1cec17b6a02e2b374964faf2b).

The problematic section seems to be in TempoMap::reftime(TempoMetric const &tm) const, and specifically the dynamic_cast:

       if (dynamic_cast<const MusicTimePoint*> (&*pi)) {
(0027660)
gonsolo   
2023-05-18 09:16   
This seems to be fixed with the latest Temporal fixes. Please close.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9337 [ardour] bugs tweak always 2023-05-17 16:17 2023-05-17 20:05
Reporter: aceku Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: filenames with german umlaute
Description: when i import a file with german umlaute (or other UTF-8 characters) in the filename, i get an import error of the ardour file after reopening it in ardour.

 ERROR: XML error: Input is not proper UTF-8, indicate encoding !Bytes: 0xE2 0x80 0x5F 0x39 in /home/alex/Ardour/nina_simone_go_to_hell/nina_simone_go_to_hell.ardour at line 89:37

this wav file: Und_fällt_eine kün_473251317.wav

line 89:
<Source name="Und_fällt_eine_kün_473251317.wav" take-id="" type="audio" flags="" id="85822" natural-position="a0" channel="0" origin="" gain="1"/>
Tags:
Steps To Reproduce: import this wav file: Und_fällt_eine kün_473251317.wav
Additional Information:
System Description
Attached Files:
Notes
(0027658)
x42   
2023-05-17 16:29   
(Last edited: 2023-05-17 16:29)
That looks like your file-system or locale is not using UTF8, but ISO-8859-1

Does it work when you create a track in Ardour using umlauts? - If so then the issue is with the filename of the imported file.

Can you open a terminal window, run
locale

and post the output?
(0027659)
aceku   
2023-05-17 20:05   
locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9317 [ardour] bugs major always 2023-04-25 15:18 2023-05-17 16:30
Reporter: katana1232 Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 11  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour refuses to open projects with the PS-20 VST/VST3 in them
Description: Every time I save a project with the PS-20 VST or VST3 in it the file doesn't show up in the recent sessions menu and if I try too load it from the file browser it gives me these errors

ERROR: Cannot get existing session information from E:\Ardour7\test\test.ardour
ERROR: XML error: PCDATA invalid Char value 16 in file:/E:/Ardour7/test/test.ardour at line 593:52
ERROR: XML error: Couldn't find end of Start Tag Controllable line 593 in file:/E:/Ardour7/test/test.ardour at line 593:52
ERROR: XML error: attributes construct error in file:/E:/Ardour7/test/test.ardour at line 593:52
ERROR: XML error: invalid character in attribute value in file:/E:/Ardour7/test/test.ardour at line 593:52
ERROR: XML error: PCDATA invalid Char value 16 in file:/E:/Ardour7/test/test.ardour at line 592:52
ERROR: XML error: Couldn't find end of Start Tag Controllable line 592 in file:/E:/Ardour7/test/test.ardour at line 592:52
ERROR: XML error: attributes construct error in file:/E:/Ardour7/test/test.ardour at line 592:52
ERROR: XML error: invalid character in attribute value in file:/E:/Ardour7/test/test.ardour at line 592:52
ERROR: XML error: PCDATA invalid Char value 16 in file:/E:/Ardour7/test/test.ardour at line 593:52
...

the name of the save file here was test since I was trying to reproduce the bug. It also gives the same errors inside Ardour if I have a glitched file on my hard drive when I stat a new session.
Tags: 7.3, VST3
Steps To Reproduce: 1. Create a session
2. Add PS-20 VST or VST3
3. Save session
4. Try to reload the saved project
Additional Information:
System Description Windows 11
Attached Files: test.zip (21,961 bytes) 2023-04-25 15:18
https://tracker.ardour.org/file_download.php?file_id=4510&type=bug
invalid-utf8-char.png (34,935 bytes) 2023-04-25 15:27
https://tracker.ardour.org/file_download.php?file_id=4511&type=bug
png
Notes
(0027619)
x42   
2023-04-25 15:24   
(Last edited: 2023-04-25 15:25)
Thanks the .zip was helpful. Issue understood: This is caused by invalid parameter name provided by the plugin

Controllable name="Envelope Generator 1 - Velocity Amount" id="485" flags="" value="0" parameter="106"
(0027620)
x42   
2023-04-25 15:27   
(0027621)
katana1232   
2023-04-25 15:34   
Is there something I can do to fix this? Sorry this is my first time reporting a bug for ardour so I don't know how support works for ardour normally . Thanks for the cause of the issue in any case :)
(0027624)
x42   
2023-04-26 22:03   
On order to load the session, you could edit the the .ardour session file in a text editor and remove any chars that are not UTF-8

> ERROR: XML error: PCDATA invalid Char value 16 in file:/E:/Ardour7/test/test.ardour at line 593:52

here line 593 in the file, char 52 on that line.

Since Ardour 7.4.2 (or later, available from https://nightly.ardour.org/ a few hours from now) ,Ardour does no longer write invalid UTF-8 from plugins.
Sadly the 7.4 release process was already underway, and this fix was a bit too late.

> Is there something I can do to fix this?

Depends, if you can write C++ source code, if so you might have come up with a solution like
https://github.com/Ardour/ardour/commit/4b77ecbe8303cb2102dd77a04b92be0103bd008b
https://github.com/Ardour/ardour/commit/df298c6046d4a3fd4f8b4ba81845d4623804eb46

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9332 [ardour] bugs minor always 2023-05-13 15:14 2023-05-17 13:28
Reporter: merryl0 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: timestretch crashes Ardour
Description: 0000005 0x00007ffff3927a2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7ffff49ff700 (LWP 4286) "Trigger Worker"):
#0 0x00007ffff391b96f in __GI___poll (fds=0x7ffff49febc4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff2d08b30 in CrossThreadChannel::poll_for_request (this=0x555557463320) at ../libs/pbd/crossthread.posix.cc:108
#2 0x00007ffff2d08ba1 in CrossThreadChannel::receive (this=0x555557463320, msg=@0x7ffff49fec2f: 0 '\000', wait=true) at ../libs/pbd/crossthread.posix.cc:133
#3 0x00007ffff6b430a9 in ARDOUR::TriggerBoxThread::thread_work (this=0x5555574632f0) at ../libs/ardour/triggerbox.cc:4853
0000004 0x00007ffff6b4303f in ARDOUR::TriggerBoxThread::_thread_work (arg=0x5555574632f0) at ../libs/ardour/triggerbox.cc:4841
0000005 0x00007ffff2d2cfdb in fake_thread_start (arg=0x555557460fc0) at ../libs/pbd/pthread_utils.cc:101
#6 0x00007ffff7f79ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff3927a2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7ffff7aa2080 (LWP 4273) "ArdourGUI"):
#0 0x00007ffff391b96f in __GI___poll (fds=0x555557db4770, nfds=4, timeout=15) at ../sysdeps/unix/sysv/linux/poll.c:29
--Type <RET> for more, q to quit, c to continue without paging--<RET>
0000001 0x00007ffff1456c76 in ?? () from /opt/Ardour-7.4.72-dbg/lib/libglib-2.0.so.0
#2 0x00007ffff1457002 in g_main_loop_run () from /opt/Ardour-7.4.72-dbg/lib/libglib-2.0.so.0
#3 0x00007ffff05834c7 in gtk_main () from /opt/Ardour-7.4.72-dbg/lib/libgtk-x11-2.0.so.0
0000004 0x00007ffff313f2f4 in Gtkmm2ext::UI::run (this=0x555557b1df50, old_receiver=...) at ../libs/gtkmm2ext/gtk_ui.cc:305
0000005 0x00005555561d9413 in main (argc=1, argv=0x7fffffffd5c8) at ../gtk2_ardour/main.cc:471
(gdb)
Tags:
Steps To Reproduce: launch ardour
select audio region
use timestretch tool to change region length
ardour quits or hangs
Additional Information:
System Description
Attached Files: Ardour_7.4.72_dbg.desktop (253 bytes) 2023-05-13 15:14
https://tracker.ardour.org/file_download.php?file_id=4521&type=bug
timestretchCrashdbg.txt (172,510 bytes) 2023-05-13 15:25
https://tracker.ardour.org/file_download.php?file_id=4522&type=bug
Ardour7.4crash150523.txt (167,908 bytes) 2023-05-15 10:00
https://tracker.ardour.org/file_download.php?file_id=4527&type=bug
Notes
(0027650)
merryl0   
2023-05-13 15:25   
I dont think I got all the file last post so here it is again hopefully complete
(0027653)
merryl0   
2023-05-15 10:00   
(0027654)
merryl0   
2023-05-15 10:01   
This is the latest crash info. The project crashes a few seconds after pressing play
Many thanks
(0027657)
x42   
2023-05-17 13:28   
OK. It seems that in your case time-stretch produces insufficient audio-data. Likely due to rounding of the duration, and the playing the result fails when ardour tried to read the end of the stretched file.

Could it be that you stretch an audio-region to a given bar/beat duration, or have used "glue to bar/beats" for an audio-region?
Do you have a recipe how to produce this problem step by step, starting with a new session; or alternately, can you upload the project that produces this bug (if you cannot share it publicly send to to robin@gareus.org).

Thanks in advance.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9333 [ardour] bugs crash always 2023-05-13 23:57 2023-05-16 00:19
Reporter: ardourwlk Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Session crash when attempting to add certain plugins
Description: I have a session where I can no longer add certain plugins without Ardour wrecking (it just winks out). Other plugins load ok. I had done some pitch-shift, as the only non-normal thing I do. I tried to recreate this in another session, but was unsuccessful, so something is just whack with this session. For example, if I try to add ToneLib GFX (vst2 or 3), it dies. If I add an acmt, it’s fine. Again, in my attempt to recreate in a new session, all works fine.
Tags:
Steps To Reproduce: Start session, select a track, attempt to add a plugin to the track (using plugin selector or from favorites), upon selection Ardour dies. In this case I tried to load ToneLib GFX vst2.
Additional Information:
System Description
Attached Files: ardour_text_dump.txt (151,033 bytes) 2023-05-13 23:57
https://tracker.ardour.org/file_download.php?file_id=4523&type=bug
ardour_text_dump2.txt (105,868 bytes) 2023-05-14 00:13
https://tracker.ardour.org/file_download.php?file_id=4524&type=bug
Notes
(0027651)
ardourwlk   
2023-05-14 00:13   
Just recreated using ToneLib's Tube Warmth plugin, which is free.

Ran a new gdb trace: ardour_text_dump2.txt

https://tonelib.net/tl-tubewarmth.html
(0027655)
x42   
2023-05-16 00:19   
So the crash happens inside ToneLib-TubeWarmth.vst3 when its GUI is shown, but since it happens inside the binary it is not useful to determine the cause.

You can probably add the plugin after disabling Ardour Preferences > Plugins > GUI > Automatically open the plugin GUI
It may or may not still crash when you later open the GUI.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9336 [ardour] bugs major always 2023-05-14 17:00 2023-05-14 17:00
Reporter: dsfdsf Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: why ? Nudge clock affect Nudge Notes / note should move by grid size
Description: Hi
when i set nudge clock value to zero notes move by grid size
otherwise nudge clock value determines note move where and how long go

NG clock should just affect on audio region and midi note move with grid mode (size of note)


best
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9331 [ardour] bugs major always 2023-05-13 09:44 2023-05-13 10:50
Reporter: martin.vlk Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't export the project or perform Loudness analysis, progress indicator stays at zero, never finishes
Description: I tried this on 3 of my existing projects, and on a newly created one (attached) and it behaves the same.
Tags: export, export audio
Steps To Reproduce: Try to export the session or use the Loudness Assistant.
Additional Information:
System Description
Attached Files:
Notes
(0027649)
martin.vlk   
2023-05-13 10:50   
I couldn't attach the sample prpject, so here is a download link:
https://drive.google.com/file/d/1jpr7lbWqSZegvD4XR9Osk8m0f0tYU9ZE/view?usp=sharing

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9321 [ardour] bugs minor have not tried 2023-05-01 06:32 2023-05-12 18:32
Reporter: sollapse Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 7.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST3: Pro-Q3 band solo auditioning fails to work
Description: Soloing a frequency band in Pro-Q3 doesn't work under VST3. The VST2 version works normally, along with using the VST3 within Metaplugin.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: vst3_proq_solo.jpg (933,394 bytes) 2023-05-01 06:35
https://tracker.ardour.org/file_download.php?file_id=4516&type=bug
Notes
(0027634)
sollapse   
2023-05-01 06:35   
To clarify, the UI works, just the audio fails to play of the selected frequency band.
(0027645)
x42   
2023-05-11 00:14   
The Pro-Q3 evaluation period has expired (and i forgot to take a VM snapshot before installing Fabfilter), so I cannot reproduce this here.

Could you please try if Ardour 7.4.67 (or later, should be available 2-3h from now) fixes this?
(0027646)
sollapse   
2023-05-11 03:04   
It's still not functioning on the new build.
(0027647)
x42   
2023-05-12 01:39   
OK, another educated guess: please try 7.4.69

If that also fails I'll have to see if I can get a NFR license from Fabfilter to investigate further.
(0027648)
sollapse   
2023-05-12 06:16   
That fixed it! Thanks for looking into this one.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9330 [ardour] bugs minor have not tried 2023-05-09 15:34 2023-05-09 15:34
Reporter: x42 Platform: Apple  
Assigned To: OS: macOS  
Priority: normal OS Version: Ventura 13.2.1  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Waves Plugins do not work when translations are enabled
Description: https://discourse.ardour.org/t/ardour-7-1-doesnt-work-with-waves-plugins-v14/108432
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9327 [ardour] bugs minor always 2023-05-06 20:04 2023-05-07 22:06
Reporter: nonsequitarian Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Behringer X-Touch often shows wrong track colors
Description: The new support for track colors on the Behringer X-Touch is awesome, but unfortunately the colors displayed often don't match the track colors in Ardour. Even when I add multiple tracks at once as part of a group the new tracks might not all have the same color. For instance, I added 6 tracks at once, all part of a newly created group, which showed up in Ardour as a light blue color. On the X-touch, the first two were white, the next two were blue, the fifth track was green, and then the last was white again.

I'd say the colors are accurate about 50-60% of the time.
Tags:
Steps To Reproduce: Have an X-Touch, connect it to an Ardour session using Mackie Control protocol, the colors showing on the X-Touch might not match the track colors showing in Ardour.
Additional Information: Actually, I just did a bit more testing and saw something interesting and probably useful: I added multiple tracks at once, all part of a new group, to an empty session that I had already connected to my X-Touch. When they showed up on the X-Touch, at first they were all the same correct color. About a half-second later, however, many of them changed to seemingly random other colors. So it looks like it's choosing the right color in the first place, but something is then causing these correct colors to be replaced.
System Description
Attached Files: output.log (158,125 bytes) 2023-05-07 22:06
https://tracker.ardour.org/file_download.php?file_id=4519&type=bug
Notes
(0027641)
nonsequitarian   
2023-05-07 04:12   
I did a bit more experimenting and found something reproducible that I'm guessing will be very helpful in figuring out what's going on. TL;DR: I can set things up such that new tracks are consistently created with the correct color, but the color gets overwritten when you take specific x-touch actions. Here are the detailed steps:

* Hit the "CHANNEL >" button on the x-touch until the last channel in the session is in the x-touch's second track, i.e. until there are 6 empty channels on the x-touch with dark LED screens.
* Choose `Track -> Add Track` in the Ardour menus. In the track adding dialog, under the default `Audio Tracks` option, set `Add:` to 6. Set `Group:` to `New Group...`, click the `New` button on the nested dialog window that comes up, and then click `Add and Close`.
* Verify that all of the new x-touch channels are the same color, accurate to the color Ardour chose. If so then:
* Push any of the x-touch's `FADER BANK` or `CHANNEL` navigation buttons.
* Verify that some or all of the tracks have changed to a different color, and cannot be changed back.
(0027642)
nonsequitarian   
2023-05-07 22:06   
Here's the debug output from a recent Ardour run (built from main branch on 2023-05-06) run with `-D mackiecontrol` setting. I added some output to the `display_colors_on_xtouch` function to show the values that are being passed to that function.

The session starts with 2 active tracks (debug output: `COLORS BEING WRITTEN: 1 1 0 0 0 0 0 0`), then I added 6 new audio tracks all in a new group (`COLORS BEING WRITTEN: 1 1 7 7 7 7 7 7`), then, taking no additional steps, I added one more new audio track, causing incorrect colors to be generated (`COLORS BEING WRITTEN: 1 1 1 7 1 1 1 3`).

Hope this is helpful!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9326 [ardour] features minor always 2023-05-06 17:13 2023-05-06 17:13
Reporter: lorenzosu Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow to only use actual track name for 'by track name' when importing MIDI file
Description: When importing MIDI file there is an option to set 'MIDI Track Names' to ''by track name' in the import dialog.
However the actual track name (in the original MIDI file), is prepended by the file name and other strings are added as well.

It would be useful to be able to use the actual track name used in the original midi file as these are often describing in a concise way the contents of the track either in terms of the instrument ('Piano', 'Strings', etc.) or the drum ('Kick', 'Snare', etc.)
Tags: Midi, midi import
Steps To Reproduce: - Start the Import via File > Import
- Select a MIDI file
- Select 'MIDI Track Names' > 'by track name' [dropdown]
Additional Information: Actually this might even be the expected behaviour from how the functionality is presented although I see the point with adding filename etc. especially with multiple files.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9325 [ardour] features minor sometimes 2023-05-06 03:06 2023-05-06 03:06
Reporter: dsfdsf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: add delete / Remove option to playlist selector
Description: Hi
Why playlist selector or playlist section dont have option to remove playlist/s???
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9322 [ardour] bugs minor always 2023-05-01 14:33 2023-05-01 14:33
Reporter: benald Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Control-Up and Control-Down for repositioning tracks doesn't work for my OS
Description: This looks like it's just waiting to be implemented. It'd be really handy though.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9312 [ardour] bugs minor always 2023-04-22 18:32 2023-04-30 12:00
Reporter: JohnMcChavs Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mute not working
Description: The Gain/mute function just doesn't work. With the right-click dropdown menu, when mute is ON, the track is still perfectly audible. A difference between now and the previous Ardour I wad using : the track becomes grey when muted, but not "transparent" as it was the case before, although the menu shows that the mute is activated.
Tags: 7.3, gain, mute
Steps To Reproduce: Right-click on a track and do Gain/Mute and clic on the mute checkbox.
Additional Information:
System Description Windows 11
Attached Files: Mute Ardour.png (79,768 bytes) 2023-04-22 18:32
https://tracker.ardour.org/file_download.php?file_id=4495&type=bug
png
Notes
(0027609)
JohnMcChavs   
2023-04-23 08:55   
STOP THE PRESS ! The problem is not in the mute function, that works well. The problem is in the CUT MODE, that cuts and creates a replica of the region on the left of the cut ! So, when I applied the mute fucntion, there wad still sound, from the underlying other region....
(0027618)
x42   
2023-04-25 13:41   
So the problem is that an underlying region still produces sound, and that is not visually obvious with "Overlaid" layer mode?

In the track header's context menu (right-click on the left side of track) select Layers > Stacked
Is there a region below the muted one?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7742 [ardour] features minor N/A 2019-03-20 23:33 2023-04-30 12:00
Reporter: colinf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Muted regions should be opaque
Description: I think that the current behaviour of muted regions isn't very helpful. If I mute a region, I want to hear (appropriately cross-faded) silence, not what happens to be underneath the region. If I did want to hear the lower region, unticking the 'Opaque' property of the (muted) upper region I think would be a more reasonable way to do it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020620)
user3660   
2019-03-21 12:06   
....

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9320 [ardour] bugs minor always 2023-04-28 19:17 2023-04-30 11:59
Reporter: domingo Platform: Mac and Linux  
Assigned To: OS: OSx 12 and Arch Linux  
Priority: normal OS Version:  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Jump to Region Boundary (No Track Selection)" works for a limited amount of tracks
Description: The options "Jump to Region Next/Previous Boundary (No Track Selection)" do not respond to regions located after track Nr.12. Meaning, the playhead won't stop at the boundaries of regions located in the last tracks, after aprox. track 12, when these options are triggered via the Transport>Playback menu or keys assigned to that function.

The bug reportedly occurs in OSx and Linux, using ALSA or Jack drivers.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027633)
colinf   
2023-04-30 11:59   
I can reproduce this. Unsetting the `region-boundaries-from-onscreen-tracks` config variable changes the behaviour a bit, but neither the set nor unset behaviours seem quite right. When it's set (the default), some regions outside the editor pane are still taken into account by "Playhead to Next/Previous Region Boundary", and when it's unset, some regions within the editor pane are still ignored by "Playhead to Next/Previous Region Boundary".

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9318 [ardour] features minor always 2023-04-27 18:39 2023-04-29 23:42
Reporter: sollapse Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Manual pin in/out selections for VST3
Description: This was previously discussed in an old bug report regarding multi-bus out support. The request is for implementing a manual selector in the pin connections dialog to choose the correct speaker arrangements for VST3 plugins that aren't easily discerned automatically (ex. ProQ 3's 5.1 mode).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: proq_native.jpg (617,523 bytes) 2023-04-27 23:30
https://tracker.ardour.org/file_download.php?file_id=4512&type=bug
proq_metaplugin.jpg (665,369 bytes) 2023-04-27 23:30
https://tracker.ardour.org/file_download.php?file_id=4513&type=bug
Notes
(0027627)
x42   
2023-04-27 22:21   
To inform a VST3 plugin to configure as 5.1 in Ardour, simply connect the first 6 pins of the plugin.
VST3 defines 5.1 in the following channel order: kSpeakerL | kSpeakerR | kSpeakerC | kSpeakerLfe | kSpeakerLs | kSpeakerRs;


Ardour does not special case any Plugin API, and there is no common abstraction for speaker layout that would apply to Audio Unit, VST2, VST3, LV2, etc. So there no way to expose this directly to the user until we come up with a common abstraction.
(0027628)
sollapse   
2023-04-27 23:30   
The issue is that Ardour creates multiple stereo instances of the plugin when using a 6 channel bus (or track). I've also included an example of using Metaplugin with a forced 5.1 configuration which changes ProQ's interface and pins appropriately.
(0027629)
sollapse   
2023-04-27 23:30   
(0027632)
sollapse   
2023-04-29 23:42   
I can understand the rationale for wanting to have a universal method across all plugin types, however would it still be appropriate to have I/O pins available on the track/bus dynamically dictate the layout of the VST3 plugin if available? Much like the mono/stereo detection works currently.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9216 [ardour] bugs minor always 2023-01-30 17:52 2023-04-29 23:33
Reporter: enorrmann Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes while attempting to change tempo
Description: after trying the CUE view features, adding clips and removing them, the master tempo suddenly changed back to default 120, and any attempt to change that value results in a crash
ardour-7.0.17: ../libs/temporal/tempo.cc:489: Temporal::superclock_t Temporal::TempoPoint::superclock_at(const Temporal::Beats&) const: Assertion `qn >= _quarters' failed.
Aborted (core dumped)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027631)
ragnarok   
2023-04-29 23:33   
I can confirm this issue on 7.4.0 too (debian 11)
my song have 2 tempos
when change the value form the first tempo, then ardour crash.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9319 [ardour] bugs crash always 2023-04-28 14:55 2023-04-28 14:55
Reporter: ilawson Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 7.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on project creation
Description: After getting through the Session Setup and Audio/Midi Setup windows Ardour crashes
Tags:
Steps To Reproduce: 1. Open ardour
2. Create new session w/ empty template
3. Use default settings
4. Program crashes
Additional Information:
System Description
Attached Files: Screen Shot 2023-04-17 at 5.10.05 PM.png (110,525 bytes) 2023-04-28 14:55
https://tracker.ardour.org/file_download.php?file_id=4514&type=bug
png

Ardour7_2023-04-17-161656_Ians-MacBook-Pro-2.crash (104,617 bytes) 2023-04-28 14:55
https://tracker.ardour.org/file_download.php?file_id=4515&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7504 [ardour] features minor have not tried 2017-11-12 16:27 2023-04-27 06:37
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Duplicating selection ignores automation data
Description: I often work with many automation lanes for my synth lines.
When I use Ctrl+D or Sift+D shortuts to duplicate the regions the automation relevant to these regions is not copied along. Even when I have the automation points selected.

The only way to copy the MIDI regions with their relevant automation is by selecting all that, using Edit > Copy, then moving my playhead and Edit > Paste. This however sometimes puts MIDI regions on different tracks - then I need to do it fear each track separately one-by-one.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027626)
nomad   
2023-04-27 06:37   
+1

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7490 [ardour] features feature N/A 2017-10-14 17:21 2023-04-27 06:35
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Automation following MIDI region edits?
Description: There's a great function in Ardour that makes automation follow editing that one performs on relevant audio clips. This is absolutely brilliant and saves me a lot of time.

The problem is - its doesn't work for MIDI regions as well, only for audio regions.
I mostly use complex automation for my synth lines to add motion to them, and duplicating phrases is a bit laborsome , when automation (sometimes I have 4 automation lanes used or more for a single synth) and I need t ocopy or move them manually myself, risking displacement.

Could the wonderful "Move relevant automation data when audio clip is moved" option have a MIDI counterpart?

Also - it could be renamed to "Automation follows revevant region editing operations" or something, becasue duplicating regions works to, so it's not just moving.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: simplescreenrecorder-2021-04-29_14.47.31.webm (386,690 bytes) 2021-04-29 19:01
https://tracker.ardour.org/file_download.php?file_id=4014&type=bug
move_automation.gif (246,370 bytes) 2021-04-29 20:00
https://tracker.ardour.org/file_download.php?file_id=4015&type=bug
gif
Notes
(0025309)
chaot   
2020-12-14 23:59   
I just want to second this feature request. I got really confused today because I just could not find this option and I did not understand why, until I realized that it does not exist yet apparently.
(0025618)
sankey   
2021-03-20 19:55   
I love Ardour, but I would say this issue is my number 1 stress inducer while using it. I'm in constant fear while writing new automation for MIDI tracks because I never know when I might change my mind about the structure of the song and ultimately need to re-write the automation from scratch just to move it over 1 measure. I know there's supposedly a copy+paste workaround, but it still sounds labor intensive and error-prone (not to mention I don't understand the instructions).

* The supposed "workaround" described in: https://discourse.ardour.org/t/problems-with-duplication-and-moving-midi-automation/89012/4
* Another related discussion: https://discourse.ardour.org/t/midi-automation/89429/2
(0025619)
Daniele1971   
2021-03-21 00:15   
Yes please, this features is badly needed !
(0025624)
mikelupe   
2021-03-21 13:46   
I will respectfully double (or quintuple) that.
(0025638)
cooltehno_bugs   
2021-03-23 18:27   
"badly needed"
(0025781)
sankey   
2021-04-29 19:01   
I have a passable workaround that i just discovered on Ardour 6.6 (see attached screen recording):

1. Enable Snap Mode and set the Grid Mode to 1 bar.
2. Enable Internal Edit Mode.
3. Create a dummy automation point on the first beat of any bar and drag it all the way to one extreme value (max or min).
4. Highlight all automation points you wish to move, including the dummy point.
5. Click and hold on the dummy point you just added.
6. Drag left or right by the number of bars you wish to move all the points, while ALSO keeping your dummy automation point fixed at the extreme max or min value.
7. Delete the dummy automation point.

Using this method, you can move automation in time with minimal risk of destroying or damaging it.
(0025800)
cooltehno_bugs   
2021-05-07 19:00   
@sankey IMO this could be good Post in the forum under the category "Hints and Tricks". Yes I had such issue with the dragging automation points, and your advise helps, but how this could resolve the problem with the moving multiple midi regions including automation?
(0027625)
nomad   
2023-04-27 06:35   
highly appreciated!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9315 [ardour] features minor always 2023-04-23 19:57 2023-04-26 03:19
Reporter: sollapse Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add text parameter descriptions for VST3 automation
Description: When using the Kontakt 7 VST3, the host automation parameters do not appear in Ardour as with Kontakt 6 VST2. This helps with labelling for either the automation track or inline controls.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: vst3_ui.gif (844,956 bytes) 2023-04-25 04:04
https://tracker.ardour.org/file_download.php?file_id=4508&type=bug
vst3_ui2.gif (932,161 bytes) 2023-04-25 04:41
https://tracker.ardour.org/file_download.php?file_id=4509&type=bug
Notes
(0027614)
x42   
2023-04-25 00:41   
I do no have a system with Kontakt 7 and sound libraries change any automation parameter names, but I've attempted to fix this blindly.
Could you test with a nightly build https://nightly.ardour.org 7.3.286 or later?
(0027615)
sollapse   
2023-04-25 04:04   
The parameters now appear, although the updates are now lagging significantly. I've posted a GIF showing the issue.
(0027616)
x42   
2023-04-25 04:32   
Thanks for the testing, this is good news. So far I fail to see how this change could have any effect on the GUI updates. I'll sleep over it.

Have the updates been smooth before? Do you still have the 7.3.0 installer?
Hint: In older versions without named parameters, find a given automation lane: Menu > Edit > Show automation lane on touch, then move a knob in the plugin's UI.
(0027617)
sollapse   
2023-04-25 04:41   
Yes, it's smooth without names parameters. This is from 7.3.0.
(0027622)
x42   
2023-04-25 22:25   
Should be fixed in upcoming 7.3-290 (or 7.4.0).
The regression for slow updates was actually a side effect of fixing 0009287
(0027623)
sollapse   
2023-04-26 02:54   
It's working in 7.4.0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9295 [ardour] bugs major always 2023-04-02 11:27 2023-04-23 12:53
Reporter: al f Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cut and paste misalignment, undo failing
Description: Ardour 7.3 on Manjaro KDE, extensively edited session. Edit point = Playhead.

Cutting and pasting regions (tested with 3 regions aligned across 3 different tracks), they are misaligned.

The regions are pasted into the correct tracks, but:

Region 1 from track 1 appears where it should, at Edit Point. Region 2 from track 2 is "mirrored", that is the end boundary is aligned at Edit Point. Region 3 sometimes ends where Region 2 starts, sometimes it's aligned with Region 2.

Also (though that might be a separate bug), CTRL-Z to undo the cut & paste does not restore regions.
Tags: editing, Editor, paste, region, split, undo
Steps To Reproduce: Start new session, make sure Edit Mode > Ripple > All. Import 3 tracks. Split regions, my setting is that Newly created regions before edit point will be auto-selected, thus creating 3 selected regions across the 3 tracks. Cut (CTRL-X) . Paste (CTRL-V).

Optional extra steps: CTRL-Z to undo paste (newly pasted regions disappear), CTRL-Z again to undo cut (end marker and region positions are readjusted, but the cut regions are not pasted restored.
Additional Information:
System Description
Attached Files: Ardour_7-3_01_blank-session.png (138,094 bytes) 2023-04-02 11:27
https://tracker.ardour.org/file_download.php?file_id=4460&type=bug
png

Ardour_7-3_02_after-import.png (204,230 bytes) 2023-04-02 11:27
https://tracker.ardour.org/file_download.php?file_id=4461&type=bug
png

Ardour_7-3_03_after-split.png (222,042 bytes) 2023-04-02 11:27
https://tracker.ardour.org/file_download.php?file_id=4462&type=bug
png

Ardour_7-3_04_before-paste.png (201,350 bytes) 2023-04-02 13:45
https://tracker.ardour.org/file_download.php?file_id=4463&type=bug
png

Ardour_7-3_05_after-paste.png (202,749 bytes) 2023-04-02 13:45
https://tracker.ardour.org/file_download.php?file_id=4464&type=bug
png

Ardour_7-3_06_after-undo-1.png (200,448 bytes) 2023-04-02 13:45
https://tracker.ardour.org/file_download.php?file_id=4465&type=bug
png

Ardour_7-3_07_after-undo-2.png (200,883 bytes) 2023-04-02 13:46
https://tracker.ardour.org/file_download.php?file_id=4466&type=bug
png

Ardour_7-3_After-cut-before-paste.png (73,127 bytes) 2023-04-02 13:46
https://tracker.ardour.org/file_download.php?file_id=4467&type=bug
png

Ardour_7-3_After-paste.png (90,636 bytes) 2023-04-02 13:46
https://tracker.ardour.org/file_download.php?file_id=4468&type=bug
png

ripple-all-multiselect.png (44,078 bytes) 2023-04-06 00:23
https://tracker.ardour.org/file_download.php?file_id=4475&type=bug
png
Notes
(0027531)
al f   
2023-04-02 13:45   
Adding images 4-6
(0027532)
al f   
2023-04-02 13:46   
And images 7-9
(0027544)
x42   
2023-04-06 00:23   
Fixed in 7.3-185-gf57a9d84df

There is however still a bug when **undoing** a cut or delete of multiple discontinuous regions (see attached screenshot)
(0027578)
paul   
2023-04-12 18:03   
This should now fully fixed as of commit 36525a1ada6
(0027611)
al f   
2023-04-23 12:53   
Thank you guys!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9314 [ardour] bugs major always 2023-04-23 10:55 2023-04-23 12:53
Reporter: al f Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Deleting regions across multiple tracks when ripple all is enabled, subsequent regions move wrong distance
Description: Manjaro KDE, Ardour 7.3.

Selecting multiple regions across multiple tracks and then deleting, regions to the right of deletion does not align at the edit point. When working with just a single track, it works as expected.
Tags: delete, editing, Editor, region, split
Steps To Reproduce: 1. Open new session, make sure Edit Mode > Ripple > All is selected
2. Import audio to 2 or more tracks
3. Select regions in at least 2 of the tracks, split at 2 points and delete
4. Observe how remaining regions move the wrong distance
Additional Information:
System Description
Attached Files: 01-Ardour-select-across-tracks.png (217,347 bytes) 2023-04-23 10:55
https://tracker.ardour.org/file_download.php?file_id=4506&type=bug
png

02-Ardour-delete-across-tracks.png (209,266 bytes) 2023-04-23 10:55
https://tracker.ardour.org/file_download.php?file_id=4507&type=bug
png
Notes
(0027610)
al f   
2023-04-23 12:53   
Cannot reproduce this with Ardour 7.3.276 "Nerve Net" (rev 7.3-276-gc16ee928de) Intel 64-bit - debug, so likely fixed when https://tracker.ardour.org/view.php?id=9295 was squashed. Thanks!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8911 [ardour] bugs crash always 2022-05-08 13:27 2023-04-22 20:13
Reporter: robertaramar Platform: Linux  
Assigned To: OS: Fedora  
Priority: normal OS Version: 35  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Session doesn't load (ERROR: Unexpected exception during session setup: tr1::bad_weak_ptr)
Description: When loading the session Narcotic.ardour, Ardour presents a "Loading Error" see "Ardour-Loading-Error.png" for details.
On the console, it says:

Log Messages:
INFO: AlsaAudioBackend: adjusted output channel count to match device.
INFO: AlsaAudioBackend: adjusted input channel count to match device.
WARNING: AlsaMidiIO: Cannot acquire realtime permissions.
WARNING: AlsaMidiIO: Cannot acquire realtime permissions.
WARNING: AlsaMidiIO: Cannot acquire realtime permissions.
WARNING: AlsaMidiIO: Cannot acquire realtime permissions.
WARNING: AlsaMidiIO: Cannot acquire realtime permissions.
WARNING: AlsaMidiIO: Cannot acquire realtime permissions.
ERROR: AlsaSeqMidiIO: Device initialization failed.
WARNING: AlsaMidiOut: failed to open midi device '144:0'.
ERROR: AlsaSeqMidiIO: Device initialization failed.
WARNING: AlsaMidiIn: failed to open midi device '144:0'.
ERROR: AlsaSeqMidiIO: Device initialization failed.
WARNING: AlsaMidiOut: failed to open midi device '145:0'.
ERROR: AlsaSeqMidiIO: Device initialization failed.
WARNING: AlsaMidiIn: failed to open midi device '145:0'.
WARNING: AlsaMidiIO: Cannot acquire realtime permissions.
WARNING: AlsaMidiIO: Cannot acquire realtime permissions.
WARNING: AlsaAudioBackend: cannot acquire realtime permissions.
INFO: harvid version: 803
INFO: Loading menus from /opt/Ardour-6.9.0/etc/ardour.menus
ERROR: Unexpected exception during session setup: tr1::bad_weak_ptr
Tags:
Steps To Reproduce: Launch Ardour, open this session.

After clicking away the Loading-Error, if you try to load any other session that would normally load,
you get an exception:

Thread 1 "ArdourGUI" received signal SIGSEGV, Segmentation fault.
0x00007ffff3da0781 in gtk_radio_action_set_group () from /opt/Ardour-6.9.0/lib/libgtk-x11-2.0.so.0
Additional Information: (gdb) bt
#0 0x00007ffff3da0781 in gtk_radio_action_set_group () from /opt/Ardour-6.9.0/lib/libgtk-x11-2.0.so.0
0000001 0x00007ffff1ef37a7 in Gtk::RadioAction::set_group(Gtk::RadioButtonGroup&) () from /opt/Ardour-6.9.0/lib/libgtkmm-2.4.so.1
#2 0x00007ffff1ef3a67 in Gtk::RadioAction::RadioAction(Gtk::RadioButtonGroup&, Glib::ustring const&, Gtk::StockID const&, Glib::ustring const&, Glib::ustring const&)
    () from /opt/Ardour-6.9.0/lib/libgtkmm-2.4.so.1
#3 0x00007ffff1ef3b42 in Gtk::RadioAction::create(Gtk::RadioButtonGroup&, Glib::ustring const&, Glib::ustring const&, Glib::ustring const&) ()
   from /opt/Ardour-6.9.0/lib/libgtkmm-2.4.so.1
0000004 0x00007ffff5b89b0d in ActionManager::register_radio_action(Glib::RefPtr<Gtk::ActionGroup>, Gtk::RadioButtonGroup&, char const*, char const*, sigc::slot<void, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>) () from /opt/Ardour-6.9.0/lib/libgtkmm2ext.so.0
0000005 0x00005555559a6b7e in ?? ()
#6 0x00005555559bc407 in ?? ()
#7 0x000055555597ed33 in ?? ()
0000008 0x000055555588ff40 in ?? ()
0000009 0x000055555587fed4 in ?? ()
0000010 0x0000555555848f51 in ?? ()
0000011 0x000055555584ad1c in ?? ()
0000012 0x000055555605de94 in ?? ()
0000013 0x000055555606116e in ?? ()
0000014 0x00007ffff1ebe5f5 in ?? () from /opt/Ardour-6.9.0/lib/libgtkmm-2.4.so.1
#15 0x00007ffff4a6c945 in g_closure_invoke () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
0000016 0x00007ffff4a7e01b in ?? () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
#17 0x00007ffff4a87c30 in g_signal_emit_valist () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
0000018 0x00007ffff4a88082 in g_signal_emit () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
0000019 0x00007ffff3cac80c in gtk_dialog_response () from /opt/Ardour-6.9.0/lib/libgtk-x11-2.0.so.0
0000020 0x00007ffff1f37b35 in ?? () from /opt/Ardour-6.9.0/lib/libgtkmm-2.4.so.1
0000021 0x00007ffff4a6c945 in g_closure_invoke () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
0000022 0x00007ffff4a7e01b in ?? () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
0000023 0x00007ffff4a87c30 in g_signal_emit_valist () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
#24 0x00007ffff4a88082 in g_signal_emit () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
0000025 0x00007ffff3eb43c0 in ?? () from /opt/Ardour-6.9.0/lib/libgtk-x11-2.0.so.0
0000026 0x00007ffff3d50cac in ?? () from /opt/Ardour-6.9.0/lib/libgtk-x11-2.0.so.0
0000027 0x00007ffff4a6c945 in g_closure_invoke () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
0000028 0x00007ffff4a7e5a0 in ?? () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
0000029 0x00007ffff4a8769b in g_signal_emit_valist () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
0000030 0x00007ffff4a88082 in g_signal_emit () from /opt/Ardour-6.9.0/lib/libgobject-2.0.so.0
0000031 0x00007ffff3ed564c in ?? () from /opt/Ardour-6.9.0/lib/libgtk-x11-2.0.so.0
0000032 0x00007ffff3d4f29d in gtk_propagate_event () from /opt/Ardour-6.9.0/lib/libgtk-x11-2.0.so.0
0000033 0x00007ffff3d4f723 in gtk_main_do_event () from /opt/Ardour-6.9.0/lib/libgtk-x11-2.0.so.0
0000034 0x00007ffff396bb4c in ?? () from /opt/Ardour-6.9.0/lib/libgdk-x11-2.0.so.0
0000035 0x00007ffff475db67 in g_main_context_dispatch () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000036 0x00007ffff475ddd0 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000037 0x00007ffff475e0f2 in g_main_loop_run () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000038 0x00007ffff3d4e3e7 in gtk_main () from /opt/Ardour-6.9.0/lib/libgtk-x11-2.0.so.0
0000039 0x00007ffff5baaa55 in Gtkmm2ext::UI::run(Receiver&) () from /opt/Ardour-6.9.0/lib/libgtkmm2ext.so.0
0000040 0x000055555580c814 in ?? ()
0000041 0x00007fffee3d9f20 in __libc_start_call_main (main=main@entry=0x55555580c420, argc=argc@entry=1, argv=argv@entry=0x7fffffffd058)
    at ../sysdeps/nptl/libc_start_call_main.h:58
--Type <RET> for more, q to quit, c to continue without paging--
0000042 0x00007fffee3d9fd0 in __libc_start_main_impl (main=0x55555580c420, argc=1, argv=0x7fffffffd058, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffd048) at ../csu/libc-start.c:392
0000043 0x000055555581360a in ?? ()

System Description
Attached Files: Ardour-Loading-Error.png (90,641 bytes) 2022-05-08 13:27
https://tracker.ardour.org/file_download.php?file_id=4181&type=bug
png

Narcotic.ardour (399,027 bytes) 2022-05-08 13:27
https://tracker.ardour.org/file_download.php?file_id=4182&type=bug
Narcotic-2.ardour (398,910 bytes) 2022-05-10 16:06
https://tracker.ardour.org/file_download.php?file_id=4183&type=bug
image.png (32,414 bytes) 2023-04-22 20:13
https://tracker.ardour.org/file_download.php?file_id=4496&type=bug
png
Notes
(0026439)
x42   
2022-05-10 16:06   
The problem relates to MIDI learn, The bound control is not available at session load. deleting line 4738 in the session file makes the session load again
<MIDIControllable id="19405" event="0xb0" channel="0" additional="0x14"/>
(0026440)
robertaramar   
2022-05-10 17:06   
Thanks, good to know. But is this still considered being a bug?
And we're you able to reproduce the exception when, after closing the error dialog, loading a recently used session?
(0027554)
MyLoFy   
2023-04-07 08:09   
Had a similar error on Ardour 7.3 ArchLinux and couldn't open the project. I had MIDI-learned a Faderport2 through QMidiRoute to drive some automation, then closed the project. Reopening without Faderport/QMidiRoute attached.

ERROR: Unexpected exception during session setup: tr1::bad_weak_ptr

I removed the lines
      <Controls>
        <MIDIControllable id="224482" event="0xb0" channel="0" additional="0x0"/>
      </Controls>
from the *.ardour session file and was able to start the project again. The weekend is saved :)
(0027607)
paul   
2023-04-22 18:17   
Can you describe in more detail what you're doing with MIDI learn that ends up with this problem?
(0027608)
MyLoFy   
2023-04-22 20:13   
I have tried to reproduce this on a fresh session with the below steps, but unfortunately without success so far, so I can only describe what lead to the error:

* I routed drum instrument tracks to a drum bus
* I put LSP parametric EQ on that bus with a high shelf activated
* I opened an automation lane for the frequency of that shelf
* To automate that with my faderport2 I connected the faderport in Jack with QMidiRoute to convert Pitchbend events to Controller events (see screenshot)
* I connected the QMidiRoute MIDI output channel via Jack with Ardour's "MIDI Control in" channel
* Then I CTRL+Middle Mouse clicked the automation fader in Ardour's Edit window
* When the MIDI-learn popup appeared ("operate controller now") I moved the fader of the Faderport
* From there I was able to drive the high shelf of the EQ with the fader and record the automation
* Then I closed the project, shut down the PC
* When reopening the project the next day, without Faderport or QMidiRoute activated, the error message appeared

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9304 [ardour] features minor always 2023-04-15 22:04 2023-04-22 18:16
Reporter: automaciej Platform: Apple Macintosh  
Assigned To: paul OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: resolved Product Version: 7.3  
Product Build: Resolution: won't fix  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make it possible to use UI for Calf plugins
Description: Calf Plugins are a suite of excellent multiplatform open source audio plugins from https://calf-studio-gear.org/

There are two github issues related to them and macOS:
Calf plugins for macOS: https://github.com/calf-studio-gear/calf/issues/72
GTK UI for Calf: https://github.com/calf-studio-gear/calf/issues/324

Calf Plugins are available on macOS via brew.

Calf plugins without the graphical interface not very usable. It's possible to adjust parameters by reading text labels, but most of the real time feedback is missing and it's hard to figure out how the plugin is interacting with my audio.

It's not currently possible to enable the graphical UI in Ardour in macOS. It's possible to compile Calf Plugins with GTK support using brew, but when you try to open a plugin, Ardour immediately crashes.

AFAIU, it's because of clashing GTK libraries. One GTK library comes with the official Ardour binary, and the other comes with homebrew. (Disclaimer, I might be wrong about this, I just read it in the github issues linked above.)

Calf / homebrew is just an example of a plugin that happens to contain clashing symbols, and I could imagine other plugins running into the same problem. I'd argue that since Ardour is a binary distribution, it's on Ardour's side to make that binary compatible with plugins using standard toolkit libraries.

Could you see any way of achieving this compatibility? How to have Ardour and Calf compiled with the same version of GTK?
Tags: gtk
Steps To Reproduce: 1. Take a macOS machine.
2. Install Ardour on it.
3. Compile Calf on it using `brew reinstall --with-gtk+ --with-cairo calf`.
4. Create an Ardour project and try to open a Calf plugin.

Ardour will crash.
Additional Information:
System Description
Attached Files:
Notes
(0027586)
x42   
2023-04-15 22:17   
First of all, the calf plugin's DSP is, to put it mildly, far from great. You're well advised to avoid those plugins for pro-audio) [1,2,3,4].

As for the issue at hand. GTK (like QT) is not suitable for plugin GUIs because it requires the host and plugin to have the exact same ABI of the toolkit.
Plugins are supposed to be self-contained and not rely on external libs, with GTK this is not possible. All plugins have moved away from GTK, except CALF.
In order to use calf plugins both ardour and the calf plugins have to be compiled with the exact same version of GTK. -- You might be able to archive this by compiling Ardour via brew.

[1] https://discourse.ardour.org/t/how-to-achieve-multiband-processing/102498/16
[2] https://discourse.ardour.org/t/30-band-calf-eq-plugin-error/99728/12
[3] https://discourse.ardour.org/t/decrease-db-with-automation-for-a-lowshelf/100088/2
[4[ https://github.com/calf-studio-gear/calf/issues/217

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9308 [ardour] bugs major always 2023-04-20 17:36 2023-04-22 18:10
Reporter: M.F. Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Starting Ardour freezes at plugin scan. Only safe mode works
Description: Bundled A7 at AV Linux 21.3 works but after up-grade to 7.3 plugin scan fails.


 ardour-7.3.29:8990): glibmm-CRITICAL **: 23:30:40.305:
unhandled exception (type Glib::Error) in signal handler:
domain: g_convert_error
code : 1
what : Invalid byte sequence in conversion input
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027602)
M.F.   
2023-04-20 19:53   
Solved?
Installing the latest build fixed the issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9307 [ardour] bugs minor always 2023-04-19 21:59 2023-04-22 11:03
Reporter: colinf Platform:  
Assigned To: zamaudio OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ProTools import always creates new tracks
Description: Importing a ProTools session into an ardour session which already has appropriately named tracks places the regions onto the existing tracks, as I'd hope, but it also creates new empty tracks for the tracks in the ProTools session.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027598)
zamaudio   
2023-04-19 23:55   
colinf: Thanks for the report. I hadn't thought anyone would try to import into a non-empty session. I hadn't actually thought through that scenario at all. If the track names are slightly different to protools ones, does it create a new track with the exact name and load the correct regions onto the right tracks? Also, if there are existing tracks with the exact same names does it populate the existing tracks correctly, or does it mess up the regions and put them on wrongly named tracks?
(0027599)
zamaudio   
2023-04-20 05:16   
@colinf the current behaviour is broken, it counts tracks from the first one at the top of the session so all the imported regions are put on unrelated tracks at the beginning of the session. I think the best thing for me to do at this point is to create new tracks for PT import at the end and import the regions only to the new tracks. This will fix the problem for most use cases, except if you wanted to import the regions onto existing tracks. (They can be moved after import, so not too bad).
(0027600)
zamaudio   
2023-04-20 05:51   
Fixed in d2a4e0ac9a
(0027601)
colinf   
2023-04-20 08:45   
Ah, so the previous behaviour wasn't how it was intended to work? That's a shame: it did exactly what I wanted, and the new behaviour is actually worse for me.

I have several PT projects, all with identically-named & ordered tracks. I wanted to import them all into ardour sessions with the same rough mix set up, including plugins, routing, VCAs & so forth. I was very pleased to discover that, having made a template after importing from the first of the PT sessions and setting up the rough mix, I could just make a new session from that template, import the next PT project, and have everything arrive on (apparently) the right tracks without any further messing around. The only wrinkle that appeared to me was that I then had to delete the new empty tracks that PT import created. Now, I have to drag the regions across from the new tracks into the existing ones too.

I haven't tried it, but I'd also hope that importing multiple PT projects with the same tracks into a single ardour session wouldn't end up creating new tracks for each PT import: what'd I'd really like in that case would be for each PT project to be imported to a new playlist on the existing tracks, though that's definitely a feature request!
(0027603)
zamaudio   
2023-04-22 00:18   
@colinf your use case should be fixed in 4620d138ee , it now imports to tracks with the same names and does not create new ones unless they are missing.
(0027605)
colinf   
2023-04-22 11:03   
Brilliant, thank you! That seems like it does exactly what I'd hope & expect now

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9311 [ardour] bugs major always 2023-04-22 08:38 2023-04-22 08:43
Reporter: mexomexo Platform: PC x64  
Assigned To: OS: Windows  
Priority: normal OS Version: 7, 10  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bad waveforms display
Description: If I don't use a high zoom level, the waveforms on all tracks look the same.
The first picture shows a high zoom level, where you can see the differences in the waveforms. The second image shows one step lower zoom level.
If I use the rebuild waveforms function, nothing changes.

At a lower zoom level, short peaks are not visible on the waveform, for example when the cable is disconnected from the guitar.
The third picture shows a high zoom level, where you can see the peak in the waveforms. The fourth image shows one step lower zoom level.

On the MAC, the display of waveforms is fine.
Tags: does not appear correct, waveforms, Windows
Steps To Reproduce: Change the zoom level
Additional Information:
System Description
Attached Files: Ardour zoom b 01.jpg (147,054 bytes) 2023-04-22 08:43
https://tracker.ardour.org/file_download.php?file_id=4491&type=bug
jpg

Ardour zoom b 02.jpg (138,466 bytes) 2023-04-22 08:43
https://tracker.ardour.org/file_download.php?file_id=4492&type=bug
jpg

Ardour zoom b 03.jpg (126,127 bytes) 2023-04-22 08:43
https://tracker.ardour.org/file_download.php?file_id=4493&type=bug
jpg

Ardour zoom b 04.jpg (127,463 bytes) 2023-04-22 08:43
https://tracker.ardour.org/file_download.php?file_id=4494&type=bug
jpg
Notes
(0027604)
mexomexo   
2023-04-22 08:43   

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8582 [ardour] bugs minor always 2021-02-24 18:49 2023-04-19 10:22
Reporter: unius Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: A large lag in the response of the UI in some VST3 plugins
Description: Some VST3 plugins (apparently based on JUCE) plugins have a very large delay on any user actions.
This does not appear on other hosts (for example, Reaper) and in the VST2 version of the same plugins in Ardour.

A similar effect is observed in Harrison AVA plugins on any host starting with beta version from 2020.08.07 (in 2020.07.31 and earlier, everything was fine).
Tags:
Steps To Reproduce: 1 get https://tal-software.com/downloads/plugins/TAL-J-8_64_linux.zip
2 install VST2 and VST3 version
3 create a MIDI Track in Ardour with the VST3 version of this plugin
4 try clicking on any button that brings up a pop-up window/menu (for example SC)
5 after a few seconds, the window/menu may or may not appear
6 try with VST2 version
7 all ok
Additional Information: tested on Ardour Nightly Build 6.6.40
x86_64, Optimized, Demo, gcc5
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9001 [ardour] bugs crash always 2022-10-17 19:08 2023-04-16 19:41
Reporter: martin.vlk Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when I try to add the ZynAddSubFX synth plugin to a MIDI track
Description: It used to work fine in 6.9

For some reason when I start Ardour7 from the console, it doesn't crash in this scenario and works as expected.
Tags:
Steps To Reproduce: Create a new MIDI track and replace the default synth with ZynAddSubFX - the application crashes.
Additional Information:
System Description
Attached Files: ardour-backtrace.txt (32,709 bytes) 2022-11-23 23:12
https://tracker.ardour.org/file_download.php?file_id=4301&type=bug
Notes
(0026629)
martin.vlk   
2022-10-17 19:41   
Further testing shows that the app crashes on trying to show the plugin GUI. When I don't try to show the GUI, the plugin itself works fine.
(0026935)
rcheesley   
2022-11-23 23:12   
I am able to replicate this on Ardour 7.1.0 - as soon as the GUI opens, Ardour crashes. Short screencast here: https://watch.screencastify.com/v/as3AG13drqiNKP4x1Qhf in case that is helpful.

Happy to help with debugging and have attached a backtrace (thanks for the excellent docs, my first time so let me know if there's anything wrong/missing!)
(0026939)
Daniele1971   
2022-11-24 22:59   
Works fine on openSUSE TW.
(0027382)
rcheesley   
2023-02-15 21:00   
I don't know if this is something that was fixed in 7.2 or Ubuntu 22.10 but it's now stopped crashing on my end. I updated both at the same time so I can't tell which fixed this!
(0027459)
martin.vlk   
2023-03-12 11:22   
Still the same problem on Ardour 7.3
(0027489)
paul   
2023-03-21 18:12   
This is a problem with the plugin build process. We can't fix it.
(0027592)
martin.vlk   
2023-04-16 19:41   
I noticed the crash doesn't happen when I use the VST version of the plugin.

But also, testing it now again with Ardour 7.3, it seems to work fine, with both versions of the plugin. So I am not sure what the actual problem is/was.
So this report can be closed, as far as I am concerned.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9187 [ardour] bugs major always 2023-01-01 20:44 2023-04-16 15:09
Reporter: automaciej Platform: Apple Macintosh  
Assigned To: x42 OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour doesn't react to mouse clicks about 50% of the time
Description: Also reported on the forums: https://discourse.ardour.org/t/ardour-7-2-0-sometimes-not-reacting-to-mouse-clicks-in-osx/108111/1
Video showing the problem: https://photos.app.goo.gl/vvsJUacUFYWwHvav6

About half the time Ardour doesn't react to mouse clicks. Sometimes a wrong window is reacting to clicks, not the window where I'm clicking but the window underneath it. Sometimes when I click an element, a small border around the button appears as if the element was selected / the focus shifted to it. But when I release the mouse button, nothing happens. The element just remains selected.

Most of the time I am able to complete tasks by using keyboard shortcuts, mainly keyboard arrows, TAB, SHIFT+TAB, cycling through buttons and confirming with ENTER. But this is very time consuming. Sometimes just mashing keyboard makes Ardour "unblock" and it starts reacting to clicks for a few seconds. Then it stops reacting again.

My Ardour is virtually unusable, every smallest task takes three to five times more time to complete.

I'm running Ardour 7.2.0.
Tags:
Steps To Reproduce: Just install Ardour 7.2.0, create a new session, create a new track, try recording, etc. You'll find that buttons just don't react to clicks and you can't do anything - can't select track input, or can't switch the metronome on off, can't do anything what is behind a button.
Additional Information: My Mac's details:

Model Name: iMac
  Model Identifier: iMac18,3
  Processor Name: Quad-Core Intel Core i7
  Processor Speed: 4.2 GHz
  Number of Processors: 1
  Total Number of Cores: 4
  L2 Cache (per Core): 256 KB
  L3 Cache: 8 MB
  Hyper-Threading Technology: Enabled
  Memory: 40 GB
System Description
Attached Files:
Notes
(0027158)
automaciej   
2023-01-01 21:34   
I discovered one more factor: a USB mouse connected to my iMac. When I try to use Ardour with the original Apple mouse, the session jumps around uncontrollably, possibly because the top of the mouse works like a trackpad, and when I just brush the mouse's top, Ardour starts scrolling vertically or horizontally, or zooms in or out, or makes tracks bigger or smaller, it's really out of control.

So I switched off the Apple mouse and connected a regular PC mouse using a USB cable. Then the problems with the clicks started.

I also noticed one more symptom. When I'm in the mixer view, and I click the track input selection, and then hover over the list of inputs, normally the UI would highlight the item I'm hovering over. But not when I'm using a USB mouse. So the item highlighting and mouse clicks issues are somehow connected.
(0027159)
x42   
2023-01-02 16:44   
Thanks for that info.

I use Ardour on M2 (macbook Air) and do not have this issue. -- but I do not have any external gear and use the touchpad. I'll see if I can find some USB mouse that I can connect to the USB3 ports..
Another clue (GTK3 based) gimp has the same issue: https://www.gimp.org/news/2022/11/18/gimp-2-99-14-released/#pointer-click-bug-with-macos-ventura
(0027160)
x42   
2023-01-03 03:33   
I have started to backport some changes to work around the issue

https://gitlab.gnome.org/GNOME/gtk/-/issues/5305
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5280/diffs

With some luck Ardour 7.2-77 no longer has this issue. -- Please try that when tomorrow's builds are up.

It is still a bit of a mystery. I cannot reproduce the problem here on macOS 13.1, and for some users gimp 2.10 (also uses gtk2, same as ardour) works, too.
Maybe it is indeed related to an external non-apple mouse.
(0027346)
x42   
2023-02-10 02:28   
Can you still reproduce this with the current nightly build?
(0027585)
automaciej   
2023-04-15 17:09   
I don't remember if I tested with the nightly build at the time. In the meantime, I managed to disable the scrolling feature in the Apple mouse, so I could stop using the USB mouse and that worked around the issue. Today I tested it again with the USB mouse with rev 7.3-19-gb6f0e547bb and the problem is gone. Thank you!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9293 [ardour] features feature N/A 2023-03-29 21:43 2023-04-12 16:08
Reporter: Lost_Highway Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mixer view presets
Description: An idea for a feature -- presets for the view of the mixer, which a user could switch between at will.

The preset would store which tracks were currently visible, track heights (in the Editor), mixer strip widths (in the Mixer window). Maybe it would be useful to store the active status of tracks as well and possibly even the track order.

The use case would be, for example, a large session with different sections and very many tracks, with some tracks having content for the full length of the session, others for just small parts. Navigating the session would be a lot easier if you could hide all unnecessary tracks and save that view as a preset, then do the same for a different subset of tracks necessary at a different point and save that as a preset. You could then recall the relevant view preset at different points along the timeline, perhaps recalling the different views with keyboard shortcuts (as can be done with Editor views).
Tags: mixer, preset, shortcuts, view, visible
Steps To Reproduce:
Additional Information:
System Description
Attached Files: [1] Screenshot_2023-04-12_16-29-42.png (517,227 bytes) 2023-04-12 16:08
https://tracker.ardour.org/file_download.php?file_id=4482&type=bug
[2] Screenshot_2023-04-12_16-33-27.png (455,638 bytes) 2023-04-12 16:08
https://tracker.ardour.org/file_download.php?file_id=4483&type=bug
[3] Screenshot_2023-04-12_16-42-12.png (504,562 bytes) 2023-04-12 16:08
https://tracker.ardour.org/file_download.php?file_id=4484&type=bug
Notes
(0027572)
paul   
2023-04-12 13:31   
We actually already have something fairly similar to this.

Press Ctrl-FunctionKeyN to save visual state N (replace N by 1-12, whatever your keyboard provides)

Press FunctionKeyN to revert to that visual state.

Note that it saves *visual state* only, and is not equivalent to mixer views.
(0027574)
Lost_Highway   
2023-04-12 16:07   
I'm aware of the Editor View presets as I came across them in the manual and in fact referenced the functionality in the original description. I can see that those might be useful, recalling combinations of zoom, vertical position amongst the tracks and horizontal position along the timeline.

I still think it would be useful to be able to recall track visibility, track height, mixer track width easily to facilitate working with large track counts, especially as there doesn't seem to be a way of showing/hiding many tracks at once (whilst all tracks in a group can be made active/inactive with one click, that doesn't appear to be the case for visible/hidden).

I've attached three screenshots of a current session, all zoomed to show the full timeline to demonstrate the point. It's two movements of the same piece in the one session (so they can be recorded and mixed consistently with each other).

[1] shows all tracks visible: there are a number of tracks in Part 2 (right-hand side of the session, in yellows and browns near the top, plus others elsewhere) that are not used during Part 1 and vice versa.
[2] has visible all tracks in use in Part 1 (left-hand end of the timeline), tracks only used in Part 2 are hidden.
[3] shows all the tracks in use in Part 2 (right-hand end of the timeline) visible and tracks not in use at that end are hidden.

It would be a useful feature if the user were able to save different views, as in [2] and [3], and switch quickly between them. This would remove the need, for example when working on Part 1 near the beginning of the timeline, to have to scroll vertically past acres of grey (empty tracks) to get to/from the tracks that are in use.

I think perhaps the title I gave this was a bit misleading and the description also, but I wasn't quite sure what to call it. I suppose what I'm suggesting would possibly be an extension of the existing Editor Views functionality to include additional things such as track visibility, height, mixer strip width (in the mixer) etc, if that makes sense. It does relate to the view in the Editor (and the Mixer if mixer strip width were included), but goes beyond just where you're viewing up/down the tracks or horizontally along the timeline and the scale (i.e. zoom), but also changing which tracks are visible/hidden and their height.
(0027575)
Lost_Highway   
2023-04-12 16:08   
(0027576)
Lost_Highway   
2023-04-12 16:08   
(0027577)
Lost_Highway   
2023-04-12 16:08   

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9302 [ardour] features minor N/A 2023-04-11 01:24 2023-04-12 13:32
Reporter: rodsilva Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Time stretch on changing project's tempo
Description: I would simplify a lot the use of time stretch feature if it was available while changing project's tempo. For rexample, after changing the project's tempo from 130 BPM to 135 BPM, Ardour would ask if we want to time stretch all the regions within the project so they would remain synced with the click.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027573)
paul   
2023-04-12 13:32   
Ardour does not currently pretend to have "elastic time" for audio. MIDI will adjust automatically.

When we add this in the future, it likely will not happen via the mechanism used by timestretching (since that cannot accomodate tempo changes and ramps).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9299 [ardour] bugs minor always 2023-04-06 00:21 2023-04-12 13:22
Reporter: enorrmann Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes while attempting to launch cue from cue view
Description: Ardour crashes while attempting to launch cue from cue view
no plugins, only audio tracks
official binary from ardour.org on ubuntu linux 23.04
Ardour 7.3.0
"Nerve Net"
(rev 7.3)
Intel 64-bit
Tags:
Steps To Reproduce: see project here
https://www.dropbox.com/s/w8pj588l7ttb73n/test_crash.zip?dl=1
open project, go to cue, click on C, or on any other cue
ardour crashes
Additional Information:
System Description
Attached Files: Screenshot from 2023-04-05 22-09-32.png (9,072 bytes) 2023-04-06 01:10
https://tracker.ardour.org/file_download.php?file_id=4476&type=bug
png
Notes
(0027545)
enorrmann   
2023-04-06 01:05   
update: using Pulseaudio the project works fine, but with Jack the app crashes trying to launch a cue
(0027546)
enorrmann   
2023-04-06 01:10   
Alsa and pulseaudio works ok, but when I switch to Jack again, a message appears
(0027547)
enorrmann   
2023-04-06 01:28   
I managed to "fix" it by:
1- opening the project
2- press home to go to the begginning
3- press play
4- while playing launch cues A to D, launch some random clips clicking on the play button
5- while playing, save the project

now I can launch any cue letter again

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9301 [ardour] bugs minor always 2023-04-09 17:02 2023-04-09 17:02
Reporter: Mark Knecht Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: The window surrounding a resizable VST does not resize with the VST
Description: Some VSTs allow resizing of the complete GUI to either save space (smaller) or for readability (larger). Mixbus32C-9 & Ardour-7.3.187 don't resize the container window along with the VST. When making Scaler 2 or Dreamsynth smaller the window remains the same size so there's gray space inside the window to the left and bottom of the VST. When resizing larger the VST grows but the bottom and right size are cut off and the resizing button in the VST is gone so you cannot size it back down. Fortunately when you close and reopen the VST window the VST again fills the window as normal.
Tags:
Steps To Reproduce: Load a VST that allows resizing & resize
Additional Information: Screenshots attached
System Description
Attached Files: Normal VST Size.png (226,726 bytes) 2023-04-09 17:02
https://tracker.ardour.org/file_download.php?file_id=4479&type=bug
png

VST sized down.png (216,166 bytes) 2023-04-09 17:02
https://tracker.ardour.org/file_download.php?file_id=4480&type=bug
png

VST sized up.png (139,765 bytes) 2023-04-09 17:02
https://tracker.ardour.org/file_download.php?file_id=4481&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9259 [ardour] bugs minor have not tried 2023-02-25 13:03 2023-04-08 14:03
Reporter: colinf Platform:  
Assigned To: zamaudio OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: PRoTools import doesn't set session start or end markers
Description: Importing a ProTools session into an empty Ardour session doesn't set the start or end marker positions. I don't know whether these are obtainable from the original PT session, but if not, the positions ought to at least be set from the regions imported.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027553)
zamaudio   
2023-04-07 01:47   
Thanks for the feature request. This is currently unimplemented.
(0027569)
x42   
2023-04-08 14:03   
Implemented by @zamaudio in 7.3-192-ga27a88f9f2

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8007 [ardour] bugs minor sometimes 2020-04-11 19:46 2023-04-08 09:35
Reporter: mauritslamers Platform: x86_64  
Assigned To: zamaudio OS: Linux  
Priority: normal OS Version: Ubuntu 18.04  
Status: feedback Product Version: 6.0-pre1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Importing a Protools file makes Ardour get stuck sometimes
Description: When importing a protools session using the (version 7.x in my case) using the "Import PT Session" menu option, a bug causes Ardour to get stuck in the import process, specifically when creating the tracks in the session to put the imported sound files.
I suspect this to be a race condition, as it does not seem to happen when running in gdb mode.
The console reports "Failed to register port "Audio 1/audio_out 2", reason is unknown from here", the application log has a similar message, but tells that it cannot create track Audio 1/audio_out 2, unknown constructor.
Tags:
Steps To Reproduce: 1. Start Ardour
2. Create a new session with the same bitrate and samplerate as the PT session to be imported
3. Import the session through "File > Import PT session"
Additional Information: I have tested this a few times, and originally thought that it happened all the time. It turns out that once in a while it works.
I followed the instructions to get a trace, but I haven't managed to get the problematic behavior reproduced when running ardour with the --gdb option.
What I eventually did get, where crashes at the same point, which I did not get in the beginning.
The stack trace here is:

  PBD::stacktrace(std::ostream&, int)
  ARDOUR::Session::realtime_stop(bool, bool)
  ARDOUR::Session::engine_halted()
  boost::_mfi::mf0<void, ARDOUR::Session>::operator()(ARDOUR::Session*) const
  void boost::_bi::list1<boost::_bi::value<ARDOUR::Session*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Session>, boost::_bi::rrlist1<char const*> >(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Session>&, boost::_bi::rrlist1<char const*>&, int)
  void boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Session>, boost::_bi::list1<boost::_bi::value<ARDOUR::Session*> > >::operator()<char const*>(char const*&&)
  boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Session>, boost::_bi::list1<boost::_bi::value<ARDOUR::Session*> > >, void, char const*>::invoke(boost::detail::function::function_buffer&, char const*)
  boost::function1<void, char const*>::operator()(char const*) const
  PBD::Signal1<void, char const*, PBD::OptionalLastValue<void> >::operator()(char const*)
  ARDOUR::AudioEngine::halted_callback(char const*)
  ARDOUR::JACKAudioBackend::disconnected(char const*)
  boost::_mfi::mf1<void, ARDOUR::JACKAudioBackend, char const*>::operator()(ARDOUR::JACKAudioBackend*, char const*) const
  void boost::_bi::list2<boost::_bi::value<ARDOUR::JACKAudioBackend*>, boost::arg<1> >::operator()<boost::_mfi::mf1<void, ARDOUR::JACKAudioBackend, char const*>, boost::_bi::rrlist1<char const*> >(boost::_bi::type<void>, boost::_mfi::mf1<void, ARDOUR::JACKAudioBackend, char const*>&, boost::_bi::rrlist1<char const*>&, int)
  void boost::_bi::bind_t<void, boost::_mfi::mf1<void, ARDOUR::JACKAudioBackend, char const*>, boost::_bi::list2<boost::_bi::value<ARDOUR::JACKAudioBackend*>, boost::arg<1> > >::operator()<char const*>(char const*&&)
  boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf1<void, ARDOUR::JACKAudioBackend, char const*>, boost::_bi::list2<boost::_bi::value<ARDOUR::JACKAudioBackend*>, boost::arg<1> > >, void, char const*>::invoke(boost::detail::function::function_buffer&, char const*)
  boost::function1<void, char const*>::operator()(char const*) const
  PBD::Signal1<void, char const*, PBD::OptionalLastValue<void> >::operator()(char const*)
  ARDOUR::JackConnection::halted_info_callback(JackStatus, char const*)
actually writing state to /home/maurits/Ardour Sessions/test7/test7.tmp
  /opt/Ardour-6.0.pre1.264-dbg/lib/backends/libjack_audiobackend.so(+0x706cb) [0x7fa1341776cb]
  /usr/lib/x86_64-linux-gnu/libjack.so.0(+0x10581) [0x7fa12b8b5581]
  /usr/lib/x86_64-linux-gnu/libjack.so.0(+0x2f017) [0x7fa12b8d4017]
  /usr/lib/x86_64-linux-gnu/libjack.so.0(+0x2a626) [0x7fa12b8cf626]
  /lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7fa1519596db]
  clone
renaming state to /home/maurits/Ardour Sessions/test7/test7.ardour
ardour-6.0.pre1.264: /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/smart_ptr/shared_ptr.hpp:734: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = ARDOUR::JackPort; typename boost::detail::sp_member_access<T>::type = ARDOUR::JackPort*]: Assertion `px != 0' failed.
saved state in 22.5 ms
Attached Files:
Notes
(0021309)
x42   
2020-04-11 20:07   
Could it be that the session has a lot of tracks, and JACK runs out of ports?

Does it work when using Ardour's ALSA backend instead?
(0021310)
mauritslamers   
2020-04-11 20:17   
I think that it is unlikely that Jack is running out of ports, as the PT sessions I tried to import (one 44KHz 16bit, and one 48KHz 16 bit) each only has two tracks. I have quickly tested one time with each session with alsa as backend and didn't run into issues yet.
(0027568)
zamaudio   
2023-04-08 06:21   
mauritslamers: Can you please retest with version 295dbd8e1e8465fb74d94e4eb0cfa35b09761cfc (current master) or later. Eg tomorrow's nightly would be a good test.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9148 [ardour] bugs minor always 2022-12-06 15:15 2023-04-08 06:06
Reporter: Xansta Platform: Ubuntu  
Assigned To: zamaudio OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Import of Protools session shows track list but no audio content
Description: I tried to import a Protools session back in the March/April 2022 time frame unsuccessfully. The problem was worked on and a fix was incorporated and scheduled for the next release. I was given an opportunity to try the fix myself, but I would need to compile Ardour myself. I made an effort to compile, but was unsuccessful. Now that there's a new release, I tried to import the Protools file again. The import ran to completion. I can see the tracks listed. The tracks seem devoid of any audio content. I picked a couple of the tracks and raise the gain, but that did not do anything either.

I'm running Lubuntu 18.04.6 LTS
Bionic
Tags:
Steps To Reproduce: Launch Ardour
Create a new session by clicking the New Session button in the Session Setup window
Name the session and click the Open button in the Session Setup window
Current settings in the Audio/MIDI Setup:
Audio System: ALSA
Input Device: HDA Intel PCH
Output Device: HDA Intel PCH
Sample rate: 44.1 kHz
Buffer size: 1024 samples (23.2 ms)
Periods: 2
Record monitoring handled by: Audio Hardware
Click the Start button in the Audio/MIDI Setup window
Note: I sometimes connect to a USB input box where the Audio/MIDI settings are different
Session > Import PT session
Navigate to the file on the hard drive (Session 015 - Mar 26, 2022.ptx)
Click the Import button in the Import PT Session window
I see the P...rt window while the import occurs and the dialog box with the message "PT import completed! See log for specifics" where I click the OK button.
Additional Information: Out of curiosity, I looked at the log file. I see these messages:
2022-12-06T09:04:21 [WARNING] PT Import: MISSING `/home/skaraan/Downloads/Fade Files/Drums_01.wav, inserting ref to missing source
[...]
2022-12-06T09:04:21 [WARNING] Failed to load one or more of the audio files for PT import, see above list

There's a line for a fade file for each of the tracks. It looks like I need to go back to the original recorder and ask for those files . I only just now noticed these messages. I appreciate you reading this far. I also appreciate the information in the log file. I should have read that sooner. Sorry about that.
System Description
Attached Files:
Notes
(0027552)
zamaudio   
2023-04-07 01:11   
Xansta: Did you resolve this issue? Can we close out this bug? I think you're just missing the fade files. But they should not block the rest of the files in "Audio Files"/ from importing. If you cant see any audio at all, maybe the fades were across the entire regions?
(0027564)
Xansta   
2023-04-08 01:22   
My apologies, I have not had a chance to retest. Real life has been eating my lunch, breakfast and dinner. Yes, feel free to close this issue. When I return to this issue, I'll let you know what happens.

Thanks
(0027567)
zamaudio   
2023-04-08 06:06   
Resolved for now as a non-issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9263 [ardour] bugs crash always 2023-02-26 19:05 2023-04-08 06:01
Reporter: colinf Platform:  
Assigned To: zamaudio OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on ProTools session import
Description: Importing the attached .ptx file crashes ardour.
Tags:
Steps To Reproduce:
Additional Information: Here's an example of a backtrace of the crashing thread (with dummy audio backend), with 1 CPU in use for DSP:

[Switching to Thread 0x7fffd45c4c40 (LWP 242897)]
0x0000555555e59f9e in ARDOUR::PresentationInfo::flags (this=0x392) at ../libs/ardour/ardour/presentation_info.h:164
164 PresentationInfo::Flag flags() const { return _flags; }
(gdb) bt
#0 0x0000555555e59f9e in ARDOUR::PresentationInfo::flags() const (this=0x392) at ../libs/ardour/ardour/presentation_info.h:164
0000001 0x0000555555ea35c8 in ARDOUR::Stripable::is_auditioner() const (this=0x2a) at ../libs/ardour/ardour/stripable.h:75
#2 0x00007ffff7537868 in ARDOUR::Session::no_roll(unsigned int) (this=0x555559730ce0, nframes=512) at ../libs/ardour/session_process.cc:229
#3 0x00007ffff7539f9b in ARDOUR::Session::process_without_events(unsigned int) (this=0x555559730ce0, nframes=512) at ../libs/ardour/session_process.cc:701
0000004 0x00007ffff753928a in ARDOUR::Session::process_with_events(unsigned int) (this=0x555559730ce0, nframes=512) at ../libs/ardour/session_process.cc:531
0000005 0x00007ffff7536e34 in ARDOUR::Session::process(unsigned int) (this=0x555559730ce0, nframes=512) at ../libs/ardour/session_process.cc:120
#6 0x00007ffff6d6f3df in ARDOUR::AudioEngine::process_callback(unsigned int) (this=0x555557b33cc0, nframes=512) at ../libs/ardour/audioengine.cc:537
#7 0x00007fffd58caef4 in ARDOUR::DummyAudioBackend::main_process_thread() (this=0x5555575980e0) at ../libs/backends/dummy/dummy_audiobackend.cc:953
0000008 0x00007fffd58c8603 in pthread_process(void*) (arg=0x5555575980e0) at ../libs/backends/dummy/dummy_audiobackend.cc:434
0000009 0x00007ffff46c0ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000010 0x00007ffff38d3a2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

It looks like the process callback sees a corrupted value in the Session::routes list, but the routes appear to be good when added in Session::import_pt_rest(). Using multiple CPUs for DSP causes a crash in a different place, but it appears to be from a similar cause.
Attached Files: Copy of SORCERERS.ptx (440,467 bytes) 2023-02-26 19:05
https://tracker.ardour.org/file_download.php?file_id=4409&type=bug
Notes
(0027565)
zamaudio   
2023-04-08 03:44   
Fixed in f3e13848fa, confirmed fixed in 295dbd8e1e. Thanks Robin!
(0027566)
zamaudio   
2023-04-08 06:01   
Fixed in 295dbd8e1e8465fb74d94e4eb0cfa35b09761cfc

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9287 [ardour] bugs major always 2023-03-24 18:51 2023-04-07 15:56
Reporter: Mark Knecht Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour does not correctly restore settings in Halion 7 after save and reload
Description: This problem exists on Ardour 7. Mixbus32C-8 & Mixbus32C-9, all on Windows 10.

I create a new session with 1 MIDI track. Halion 7 is loaded on the track and I load an instrument into the first slot. (Halion will handle many slots but it's not necessary to reproduce this problem) I set the track to MIDI channel 1 and play the instrument. Everything works great.

I save the session, close Ardour and restart. I load the session I just saved. The track and Halion instrument are still there but the sound has changed.

Studying the VST GUI shows the major problem which is the area just above the keyboard. All of the knobs are set to zero. If I reset the knobs by hand the sound seems pretty close to the original.

What might be a related but minor problem is that exploring the GUI, in the FM OSC section and elsewhere the knobs and green rings appear to be the same but the yellow dots have changed. I do not know at this time if that matters.

I am attaching two screenshots - the initial load which shows proper values on the bottom knobs and the reload which shows them all set to 0.

Also, this may just be a Halion thing but reloading the instrument from the right hand Media Bay doesn't work. I have to first load an "FM Lab Init" layer and then I can load the instrument and get the proper sound again.
Tags:
Steps To Reproduce: As documented above, at least with the full version of Halion 7. I don't know if this happens with the demo but I suspect it probably does.
Additional Information:
System Description
Attached Files: Halion 7 - Initial load.png (228,170 bytes) 2023-03-24 18:51
https://tracker.ardour.org/file_download.php?file_id=4448&type=bug
png

Halion 7 - Reload.png (213,274 bytes) 2023-03-24 18:52
https://tracker.ardour.org/file_download.php?file_id=4449&type=bug
png

HALion-reloaded.png (760,595 bytes) 2023-04-05 16:01
https://tracker.ardour.org/file_download.php?file_id=4473&type=bug
Plug-in report.txt (25,749 bytes) 2023-04-05 17:35
https://tracker.ardour.org/file_download.php?file_id=4474&type=bug
Notes
(0027507)
Mark Knecht   
2023-03-24 18:51   
(0027508)
Mark Knecht   
2023-03-24 18:52   
(0027509)
Mark Knecht   
2023-03-25 14:27   
Running the debug version of Ardour I open the session that was already created but didn't set the bottom controls. All output was created upon starting. There was no additional output created by opening Halion.


(c) Microsoft Corporation. All rights reserved.

C:\Users\Titan-R7>"c:\Program Files\Ardour7\bin\Ardour.exe" -DVST3C

C:\Users\Titan-R7>ARDOUR_DATA_PATH not set in environment
bind txt domain [gtk2_ardour7] to c:\Program Files\Ardour7\share\ardour7\locale
Debug flag 'VST3Callbacks' set
Debug flag 'VST3Config' set
Ardour7.3.139 (built using 7.3-139-g70df054d68 and GCC version 8.3-posix 20190406)
Crash Log: C:\Users\Titan-R7\AppData\Local\Ardour7\CrashLog\Ardour-7.3.139-crash-1679754214.txt
Ardour: [INFO]: MMCSS Initialized
Ardour: [INFO]: Your system is configured to limit Ardour to 2048 open files
ARDOUR_CONFIG_PATH not set in environment
Ardour: [INFO]: Loading system configuration file c:\Program Files\Ardour7\share\ardour7\system_config
Ardour: [INFO]: Loading user configuration file C:\Users\Titan-R7\AppData\Local\Ardour7\config
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 9 5950X 16-Core Processor
Ardour: [INFO]: Using AVX and FMA optimized routines
Ardour: [INFO]: Loading plugin meta data file c:\Program Files\Ardour7\share\ardour7\plugin_metadata\plugin_tags
Ardour: [INFO]: Loading plugin statistics file C:\Users\Titan-R7\AppData\Local\Ardour7\plugin_metadata\plugin_stats
Ardour: [INFO]: add_lrdf_data 'C:\Users\Titan-R7\AppData\Local\Ardour7\rdf;c:\Program Files\Ardour7\share\ardour7\rdf'
*** WEAK-JACK: initializing
*** WEAK-JACK: libjack was not found
Ardour: [INFO]: Loading 454 MIDI patches from c:\Program Files\Ardour7\share\ardour7\patchfiles
Ardour: [INFO]: Loading default ui configuration file c:\Program Files\Ardour7\share\ardour7\default_ui_config
Ardour: [INFO]: Loading user ui configuration file C:\Users\Titan-R7\AppData\Local\Ardour7\ui_config
Ardour: [INFO]: Loading color file c:\Program Files\Ardour7\share\ardour7\themes\dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file c:\Program Files\Ardour7\share\ardour7\clearlooks.rc
Ardour: [INFO]: Loading bindings from c:\Program Files\Ardour7\share\ardour7\ardour.keys
Loading ui configuration file c:\Program Files\Ardour7\share\ardour7\clearlooks.rc
pingback: No Error
Found nothing along C:\Users\Titan-R7\AppData\Local\Ardour7\templates;c:\Program Files\Ardour7\share\ardour7\templates
Set cursor set to default
DEBUG::VST3Config: VST3 Loading: C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3
DEBUG::VST3Config: VST3PI create instance 3B63D74130B34AE397AF92A9659137D5
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: EEC8968380DB43369177273E138A763B
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 97E507DAE5594EEAA5AC4042E458F2B4
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: CC0B7716362B4EE589EE5F415458463F
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 29633AEC1D1C47E2BB85B97BD36EAC61
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 6D319DC660C56242B32C951B93BEF4C6
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
DEBUG::VST3Config: VST3 parameter count: 9793
DEBUG::VST3Config: VST3PI::set_event_bus_state: n_bus_in = 4 n_bus_in = 0 enable = 1
DEBUG::VST3Config: VST3 instantiating FUID: 3B63D74130B34AE397AF92A9659137D5
DEBUG::VST3Config: VST3PI::enable_io: ins = 2 == 2 outs = 70 == 70
DEBUG::VST3Config: VST3PI::enable_io: n_bus_in = 1 n_bus_out = 33
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kInput, 0, 1) used-chn: 2 spk-arr: 3
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 0, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 1, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 2, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 3, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 4, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 5, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 6, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 7, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 8, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 9, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 10, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 11, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 12, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 13, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 14, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 15, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 16, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 17, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 18, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 19, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 20, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 21, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 22, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 23, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 24, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 25, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 26, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 27, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 28, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 29, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 30, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 31, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 32, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: setBusArrangements ins = 1 outs = 33 | rv = 0
DEBUG::VST3Config: VST3PI: Input BusArrangements: 0 chan: 2 bits: 3
DEBUG::VST3Config: VST3PI: Output BusArrangements: 0 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 1 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 2 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 3 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 4 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 5 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 6 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 7 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 8 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 9 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 10 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 11 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 12 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 13 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 14 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 15 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 16 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 17 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 18 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 19 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 20 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 21 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 22 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 23 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 24 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 25 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 26 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 27 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 28 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 29 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 30 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 31 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 32 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI::setup_psl_info_handler: (0) (0)
DEBUG::VST3Config: VST3Plugin::set_state: set_program (pgm: 0 plug: HALion 7)
DEBUG::VST3Config: VST3PI::load_state: chunk: 0 off: 48 size: 30572 type: Comp
DEBUG::VST3Config: VST3PI::load_state: chunk: 1 off: 30620 size: 23991 type: Cont
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 29633AEC1D1C47E2BB85B97BD36EAC61
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 6D319DC660C56242B32C951B93BEF4C6
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 29633AEC1D1C47E2BB85B97BD36EAC61
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 6D319DC660C56242B32C951B93BEF4C6
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
DEBUG::VST3Config: VST3PI::setup_psl_info_handler: (0) (0)
DEBUG::VST3Config: VST3PI::queryInterface not supported: 00C9DC5B9D90425491A388C8B4E91B69
DEBUG::VST3Config: VST3PI::notifyProgramListChange: val: 0 (norm: 0)
DEBUG::VST3Callbacks: VST3PI::restartComponent 40
DEBUG::VST3Callbacks: VST3PI::restartComponent 14
DEBUG::VST3Callbacks: VST3PI::restartComponent 14
DEBUG::VST3Config: VST3PI::enable_io: ins = 2 == 2 outs = 70 == 70
DEBUG::VST3Config: VST3PI::enable_io: n_bus_in = 1 n_bus_out = 33
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kInput, 0, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 0, 1) used-chn: 2 spk-arr: 3
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 1, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 2, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 3, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 4, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 5, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 6, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 7, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 8, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 9, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 10, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 11, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 12, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 13, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 14, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 15, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 16, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 17, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 18, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 19, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 20, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 21, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 22, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 23, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 24, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 25, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 26, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 27, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 28, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 29, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 30, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 31, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 32, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: setBusArrangements ins = 1 outs = 33 | rv = 0
DEBUG::VST3Config: VST3PI: Input BusArrangements: 0 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 0 chan: 2 bits: 3
DEBUG::VST3Config: VST3PI: Output BusArrangements: 1 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 2 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 3 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 4 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 5 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 6 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 7 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 8 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 9 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 10 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 11 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 12 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 13 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 14 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 15 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 16 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 17 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 18 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 19 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 20 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 21 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 22 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 23 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 24 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 25 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 26 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 27 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 28 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 29 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 30 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 31 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 32 chan: 0 bits: 0
locate to 0 took 29132 usecs for 2 tracks = 14566 per track
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: EEC8968380DB43369177273E138A763B

(Ardour.exe:8248): Pango-WARNING **: 07:23:50.931: couldn't load font "ArdourMono Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", falling back to "Sans Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", expect ugly output.

(Ardour.exe:8248): Pango-WARNING **: 07:23:50.932: couldn't load font "Sans Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", falling back to "Sans Not-Rotated 5.3994140625", expect ugly output.

(Ardour.exe:8248): Pango-WARNING **: 07:23:50.940: couldn't load font "bold ArdourMono Not-Rotated 7", falling back to "Sans Not-Rotated 7", expect ugly output.

(Ardour.exe:8248): Pango-WARNING **: 07:23:50.946: couldn't load font "ArdourMono Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", falling back to "Sans Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", expect ugly output.

(Ardour.exe:8248): Pango-WARNING **: 07:23:50.947: couldn't load font "Sans Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", falling back to "Sans Not-Rotated 6.2998046875", expect ugly output.
Butler drops pool trash
Graph::drop_threads() sema-counts: 0, 0, 1
PluginWindow deleted for 0x2b1c5cf0
DEBUG::VST3Config: VST3PI::set_event_bus_state: n_bus_in = 4 n_bus_in = 0 enable = 0

C:\Users\Titan-R7>
(0027510)
Mark Knecht   
2023-03-25 14:33   
I create a new Ardour session, add 1 MIDI track with Halion 7, choose stereo as the output format, and add an FM7 instrument to the 1st slot. I play the instrument - it sounds correct - and I save and exit Ardour:

C:\Users\Titan-R7>"c:\Program Files\Ardour7\bin\Ardour.exe" -DVST3C

C:\Users\Titan-R7>ARDOUR_DATA_PATH not set in environment
bind txt domain [gtk2_ardour7] to c:\Program Files\Ardour7\share\ardour7\locale
Debug flag 'VST3Callbacks' set
Debug flag 'VST3Config' set
Ardour7.3.139 (built using 7.3-139-g70df054d68 and GCC version 8.3-posix 20190406)
Crash Log: C:\Users\Titan-R7\AppData\Local\Ardour7\CrashLog\Ardour-7.3.139-crash-1679754536.txt
Ardour: [INFO]: MMCSS Initialized
Ardour: [INFO]: Your system is configured to limit Ardour to 2048 open files
ARDOUR_CONFIG_PATH not set in environment
Ardour: [INFO]: Loading system configuration file c:\Program Files\Ardour7\share\ardour7\system_config
Ardour: [INFO]: Loading user configuration file C:\Users\Titan-R7\AppData\Local\Ardour7\config
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 9 5950X 16-Core Processor
Ardour: [INFO]: Using AVX and FMA optimized routines
Ardour: [INFO]: Loading plugin meta data file c:\Program Files\Ardour7\share\ardour7\plugin_metadata\plugin_tags
Ardour: [INFO]: Loading plugin statistics file C:\Users\Titan-R7\AppData\Local\Ardour7\plugin_metadata\plugin_stats
Ardour: [INFO]: add_lrdf_data 'C:\Users\Titan-R7\AppData\Local\Ardour7\rdf;c:\Program Files\Ardour7\share\ardour7\rdf'
*** WEAK-JACK: initializing
*** WEAK-JACK: libjack was not found
Ardour: [INFO]: Loading 454 MIDI patches from c:\Program Files\Ardour7\share\ardour7\patchfiles
Ardour: [INFO]: Loading default ui configuration file c:\Program Files\Ardour7\share\ardour7\default_ui_config
Ardour: [INFO]: Loading user ui configuration file C:\Users\Titan-R7\AppData\Local\Ardour7\ui_config
Ardour: [INFO]: Loading color file c:\Program Files\Ardour7\share\ardour7\themes\dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file c:\Program Files\Ardour7\share\ardour7\clearlooks.rc
Ardour: [INFO]: Loading bindings from c:\Program Files\Ardour7\share\ardour7\ardour.keys
Loading ui configuration file c:\Program Files\Ardour7\share\ardour7\clearlooks.rc
pingback: No Error
Found nothing along C:\Users\Titan-R7\AppData\Local\Ardour7\templates;c:\Program Files\Ardour7\share\ardour7\templates
Set cursor set to default
locate to 0 took 52 usecs for 1 tracks = 52 per track

(Ardour.exe:12664): Pango-WARNING **: 07:29:52.072: couldn't load font "ArdourMono Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", falling back to "Sans Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", expect ugly output.

(Ardour.exe:12664): Pango-WARNING **: 07:29:52.072: couldn't load font "Sans Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", falling back to "Sans Not-Rotated 5.3994140625", expect ugly output.

(Ardour.exe:12664): Pango-WARNING **: 07:29:52.079: couldn't load font "bold ArdourMono Not-Rotated 7", falling back to "Sans Not-Rotated 7", expect ugly output.
DEBUG::VST3Config: VST3 Loading: C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3
DEBUG::VST3Config: VST3PI create instance 3B63D74130B34AE397AF92A9659137D5
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: EEC8968380DB43369177273E138A763B
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 97E507DAE5594EEAA5AC4042E458F2B4
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: CC0B7716362B4EE589EE5F415458463F
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 29633AEC1D1C47E2BB85B97BD36EAC61
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 6D319DC660C56242B32C951B93BEF4C6
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
DEBUG::VST3Config: VST3 parameter count: 9793
DEBUG::VST3Config: VST3PI::set_event_bus_state: n_bus_in = 4 n_bus_in = 0 enable = 1
DEBUG::VST3Config: VST3 instantiating FUID: 3B63D74130B34AE397AF92A9659137D5
DEBUG::VST3Config: VST3PI::enable_io: ins = 2 == 2 outs = 70 == 70
DEBUG::VST3Config: VST3PI::enable_io: n_bus_in = 1 n_bus_out = 33
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kInput, 0, 1) used-chn: 2 spk-arr: 3
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 0, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 1, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 2, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 3, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 4, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 5, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 6, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 7, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 8, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 9, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 10, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 11, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 12, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 13, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 14, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 15, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 16, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 17, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 18, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 19, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 20, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 21, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 22, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 23, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 24, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 25, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 26, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 27, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 28, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 29, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 30, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 31, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 32, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: setBusArrangements ins = 1 outs = 33 | rv = 0
DEBUG::VST3Config: VST3PI: Input BusArrangements: 0 chan: 2 bits: 3
DEBUG::VST3Config: VST3PI: Output BusArrangements: 0 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 1 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 2 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 3 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 4 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 5 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 6 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 7 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 8 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 9 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 10 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 11 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 12 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 13 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 14 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 15 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 16 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 17 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 18 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 19 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 20 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 21 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 22 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 23 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 24 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 25 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 26 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 27 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 28 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 29 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 30 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 31 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 32 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI::notifyProgramListChange: val: 0 (norm: 0)

(Ardour.exe:12664): Pango-WARNING **: 07:30:20.060: couldn't load font "ArdourMono Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", falling back to "Sans Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", expect ugly output.

(Ardour.exe:12664): Pango-WARNING **: 07:30:20.061: couldn't load font "Sans Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", falling back to "Sans Not-Rotated 6.2998046875", expect ugly output.
DEBUG::VST3Config: VST3PI::setup_psl_info_handler: (0) (0)
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: EEC8968380DB43369177273E138A763B
DEBUG::VST3Config: VST3PI::enable_io: ins = 2 == 2 outs = 70 == 70
DEBUG::VST3Config: VST3PI::enable_io: n_bus_in = 1 n_bus_out = 33
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kInput, 0, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 0, 1) used-chn: 2 spk-arr: 3
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 1, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 2, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 3, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 4, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 5, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 6, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 7, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 8, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 9, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 10, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 11, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 12, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 13, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 14, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 15, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 16, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 17, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 18, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 19, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 20, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 21, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 22, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 23, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 24, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 25, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 26, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 27, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 28, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 29, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 30, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 31, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 32, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: setBusArrangements ins = 1 outs = 33 | rv = 0
DEBUG::VST3Config: VST3PI: Input BusArrangements: 0 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 0 chan: 2 bits: 3
DEBUG::VST3Config: VST3PI: Output BusArrangements: 1 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 2 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 3 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 4 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 5 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 6 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 7 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 8 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 9 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 10 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 11 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 12 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 13 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 14 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 15 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 16 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 17 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 18 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 19 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 20 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 21 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 22 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 23 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 24 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 25 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 26 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 27 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 28 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 29 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 30 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 31 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 32 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI::queryInterface not supported: 00C9DC5B9D90425491A388C8B4E91B69
DEBUG::VST3Callbacks: VST3PI::restartComponent 14
DEBUG::VST3Config: VST3PI::notifyProgramListChange: val: 0 (norm: 0)
DEBUG::VST3Callbacks: VST3PI::restartComponent 40
DEBUG::VST3Config: VST3PI::queryInterface not supported: F89F8CDF699E4BA596AAC9A481452B01
DEBUG::VST3Config: VST3PI::queryInterface not supported: EC23B5FFF97CF14DA41213F033E3E00C
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
Butler drops pool trash
Graph::drop_threads() sema-counts: 0, 0, 1
PluginWindow deleted for 0x2b26ebc0
DEBUG::VST3Config: VST3PI::set_event_bus_state: n_bus_in = 4 n_bus_in = 0 enable = 0
-- List Of Registered Controllables
CTRL: transport rec-enable
CTRL: transport roll
CTRL: transport stop
CTRL: transport auto loop
CTRL: transport play selection
CTRL: transport goto start
CTRL: transport goto end
Total number of registered controllables: 7

C:\Users\Titan-R7>
(0027511)
Mark Knecht   
2023-03-25 14:43   
I create a new session, add Halion as before, wiggle all the knobs that aren't being save and then save the session 3 times just to remember where that save happens in the output file. I exit Ardour.

C:\Users\Titan-R7>"c:\Program Files\Ardour7\bin\Ardour.exe" -DVST3C

C:\Users\Titan-R7>ARDOUR_DATA_PATH not set in environment
bind txt domain [gtk2_ardour7] to c:\Program Files\Ardour7\share\ardour7\locale
Debug flag 'VST3Callbacks' set
Debug flag 'VST3Config' set
Ardour7.3.139 (built using 7.3-139-g70df054d68 and GCC version 8.3-posix 20190406)
Crash Log: C:\Users\Titan-R7\AppData\Local\Ardour7\CrashLog\Ardour-7.3.139-crash-1679755108.txt
Ardour: [INFO]: MMCSS Initialized
Ardour: [INFO]: Your system is configured to limit Ardour to 2048 open files
ARDOUR_CONFIG_PATH not set in environment
Ardour: [INFO]: Loading system configuration file c:\Program Files\Ardour7\share\ardour7\system_config
Ardour: [INFO]: Loading user configuration file C:\Users\Titan-R7\AppData\Local\Ardour7\config
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 9 5950X 16-Core Processor
Ardour: [INFO]: Using AVX and FMA optimized routines
Ardour: [INFO]: Loading plugin meta data file c:\Program Files\Ardour7\share\ardour7\plugin_metadata\plugin_tags
Ardour: [INFO]: Loading plugin statistics file C:\Users\Titan-R7\AppData\Local\Ardour7\plugin_metadata\plugin_stats
Ardour: [INFO]: add_lrdf_data 'C:\Users\Titan-R7\AppData\Local\Ardour7\rdf;c:\Program Files\Ardour7\share\ardour7\rdf'
*** WEAK-JACK: initializing
*** WEAK-JACK: libjack was not found
Ardour: [INFO]: Loading 454 MIDI patches from c:\Program Files\Ardour7\share\ardour7\patchfiles
Ardour: [INFO]: Loading default ui configuration file c:\Program Files\Ardour7\share\ardour7\default_ui_config
Ardour: [INFO]: Loading user ui configuration file C:\Users\Titan-R7\AppData\Local\Ardour7\ui_config
Ardour: [INFO]: Loading color file c:\Program Files\Ardour7\share\ardour7\themes\dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file c:\Program Files\Ardour7\share\ardour7\clearlooks.rc
Ardour: [INFO]: Loading bindings from c:\Program Files\Ardour7\share\ardour7\ardour.keys
Loading ui configuration file c:\Program Files\Ardour7\share\ardour7\clearlooks.rc
pingback: No Error
Found nothing along C:\Users\Titan-R7\AppData\Local\Ardour7\templates;c:\Program Files\Ardour7\share\ardour7\templates
Set cursor set to default
locate to 0 took 45 usecs for 1 tracks = 45 per track
DEBUG::VST3Config: VST3 Loading: C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3
DEBUG::VST3Config: VST3PI create instance 3B63D74130B34AE397AF92A9659137D5
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: EEC8968380DB43369177273E138A763B
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 97E507DAE5594EEAA5AC4042E458F2B4
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: CC0B7716362B4EE589EE5F415458463F
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 29633AEC1D1C47E2BB85B97BD36EAC61
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 6D319DC660C56242B32C951B93BEF4C6
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
DEBUG::VST3Config: VST3 parameter count: 9793
DEBUG::VST3Config: VST3PI::set_event_bus_state: n_bus_in = 4 n_bus_in = 0 enable = 1
DEBUG::VST3Config: VST3 instantiating FUID: 3B63D74130B34AE397AF92A9659137D5
DEBUG::VST3Config: VST3PI::enable_io: ins = 2 == 2 outs = 70 == 70
DEBUG::VST3Config: VST3PI::enable_io: n_bus_in = 1 n_bus_out = 33
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kInput, 0, 1) used-chn: 2 spk-arr: 3
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 0, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 1, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 2, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 3, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 4, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 5, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 6, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 7, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 8, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 9, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 10, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 11, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 12, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 13, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 14, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 15, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 16, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 17, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 18, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 19, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 20, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 21, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 22, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 23, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 24, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 25, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 26, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 27, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 28, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 29, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 30, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 31, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 32, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: setBusArrangements ins = 1 outs = 33 | rv = 0
DEBUG::VST3Config: VST3PI: Input BusArrangements: 0 chan: 2 bits: 3
DEBUG::VST3Config: VST3PI: Output BusArrangements: 0 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 1 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 2 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 3 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 4 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 5 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 6 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 7 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 8 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 9 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 10 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 11 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 12 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 13 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 14 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 15 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 16 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 17 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 18 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 19 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 20 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 21 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 22 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 23 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 24 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 25 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 26 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 27 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 28 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 29 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 30 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 31 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 32 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI::notifyProgramListChange: val: 0 (norm: 0)
DEBUG::VST3Config: VST3PI::setup_psl_info_handler: (0) (0)
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: EEC8968380DB43369177273E138A763B
DEBUG::VST3Config: VST3PI::enable_io: ins = 2 == 2 outs = 70 == 70
DEBUG::VST3Config: VST3PI::enable_io: n_bus_in = 1 n_bus_out = 33
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kInput, 0, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 0, 1) used-chn: 2 spk-arr: 3
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 1, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 2, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 3, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 4, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 5, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 6, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 7, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 8, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 9, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 10, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 11, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 12, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 13, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 14, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 15, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 16, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 17, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 18, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 19, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 20, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 21, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 22, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 23, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 24, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 25, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 26, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 27, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 28, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 29, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 30, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 31, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 32, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: setBusArrangements ins = 1 outs = 33 | rv = 0
DEBUG::VST3Config: VST3PI: Input BusArrangements: 0 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 0 chan: 2 bits: 3
DEBUG::VST3Config: VST3PI: Output BusArrangements: 1 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 2 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 3 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 4 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 5 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 6 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 7 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 8 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 9 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 10 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 11 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 12 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 13 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 14 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 15 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 16 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 17 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 18 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 19 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 20 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 21 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 22 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 23 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 24 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 25 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 26 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 27 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 28 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 29 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 30 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 31 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 32 chan: 0 bits: 0

(Ardour.exe:8640): Pango-WARNING **: 07:39:32.278: couldn't load font "ArdourMono Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", falling back to "Sans Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", expect ugly output.

(Ardour.exe:8640): Pango-WARNING **: 07:39:32.279: couldn't load font "Sans Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", falling back to "Sans Not-Rotated 5.3994140625", expect ugly output.

(Ardour.exe:8640): Pango-WARNING **: 07:39:32.287: couldn't load font "bold ArdourMono Not-Rotated 7", falling back to "Sans Not-Rotated 7", expect ugly output.

(Ardour.exe:8640): Pango-WARNING **: 07:39:32.295: couldn't load font "ArdourMono Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", falling back to "Sans Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", expect ugly output.

(Ardour.exe:8640): Pango-WARNING **: 07:39:32.295: couldn't load font "Sans Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", falling back to "Sans Not-Rotated 6.2998046875", expect ugly output.
DEBUG::VST3Config: VST3PI::queryInterface not supported: 00C9DC5B9D90425491A388C8B4E91B69
DEBUG::VST3Callbacks: VST3PI::restartComponent 14
DEBUG::VST3Config: VST3PI::notifyProgramListChange: val: 0 (norm: 0)
DEBUG::VST3Callbacks: VST3PI::restartComponent 40
DEBUG::VST3Config: VST3PI::queryInterface not supported: F89F8CDF699E4BA596AAC9A481452B01
DEBUG::VST3Config: VST3PI::queryInterface not supported: EC23B5FFF97CF14DA41213F033E3E00C
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
Butler drops pool trash
Graph::drop_threads() sema-counts: 0, 0, 1
PluginWindow deleted for 0x2b7161e0
DEBUG::VST3Config: VST3PI::set_event_bus_state: n_bus_in = 4 n_bus_in = 0 enable = 0
-- List Of Registered Controllables
CTRL: transport goto start
CTRL: transport goto end
CTRL: transport roll
CTRL: transport stop
CTRL: transport rec-enable
CTRL: transport auto loop
CTRL: transport play selection
Total number of registered controllables: 7

C:\Users\Titan-R7>
(0027512)
Mark Knecht   
2023-03-25 14:45   
I reopen the session where I wiggled the knobs. No change. The knobs are still set to 0.


C:\Users\Titan-R7>"c:\Program Files\Ardour7\bin\Ardour.exe" -DVST3C

C:\Users\Titan-R7>ARDOUR_DATA_PATH not set in environment
bind txt domain [gtk2_ardour7] to c:\Program Files\Ardour7\share\ardour7\locale
Debug flag 'VST3Callbacks' set
Debug flag 'VST3Config' set
Ardour7.3.139 (built using 7.3-139-g70df054d68 and GCC version 8.3-posix 20190406)
Crash Log: C:\Users\Titan-R7\AppData\Local\Ardour7\CrashLog\Ardour-7.3.139-crash-1679755441.txt
Ardour: [INFO]: MMCSS Initialized
Ardour: [INFO]: Your system is configured to limit Ardour to 2048 open files
ARDOUR_CONFIG_PATH not set in environment
Ardour: [INFO]: Loading system configuration file c:\Program Files\Ardour7\share\ardour7\system_config
Ardour: [INFO]: Loading user configuration file C:\Users\Titan-R7\AppData\Local\Ardour7\config
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 9 5950X 16-Core Processor
Ardour: [INFO]: Using AVX and FMA optimized routines
Ardour: [INFO]: Loading plugin meta data file c:\Program Files\Ardour7\share\ardour7\plugin_metadata\plugin_tags
Ardour: [INFO]: Loading plugin statistics file C:\Users\Titan-R7\AppData\Local\Ardour7\plugin_metadata\plugin_stats
Ardour: [INFO]: add_lrdf_data 'C:\Users\Titan-R7\AppData\Local\Ardour7\rdf;c:\Program Files\Ardour7\share\ardour7\rdf'
*** WEAK-JACK: initializing
*** WEAK-JACK: libjack was not found
Ardour: [INFO]: Loading 454 MIDI patches from c:\Program Files\Ardour7\share\ardour7\patchfiles
Ardour: [INFO]: Loading default ui configuration file c:\Program Files\Ardour7\share\ardour7\default_ui_config
Ardour: [INFO]: Loading user ui configuration file C:\Users\Titan-R7\AppData\Local\Ardour7\ui_config
Ardour: [INFO]: Loading color file c:\Program Files\Ardour7\share\ardour7\themes\dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file c:\Program Files\Ardour7\share\ardour7\clearlooks.rc
Ardour: [INFO]: Loading bindings from c:\Program Files\Ardour7\share\ardour7\ardour.keys
Loading ui configuration file c:\Program Files\Ardour7\share\ardour7\clearlooks.rc
pingback: No Error
Found nothing along C:\Users\Titan-R7\AppData\Local\Ardour7\templates;c:\Program Files\Ardour7\share\ardour7\templates
Set cursor set to default
DEBUG::VST3Config: VST3 Loading: C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3
DEBUG::VST3Config: VST3PI create instance 3B63D74130B34AE397AF92A9659137D5
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: EEC8968380DB43369177273E138A763B
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 97E507DAE5594EEAA5AC4042E458F2B4
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: CC0B7716362B4EE589EE5F415458463F
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 29633AEC1D1C47E2BB85B97BD36EAC61
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 6D319DC660C56242B32C951B93BEF4C6
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
DEBUG::VST3Config: VST3 parameter count: 9793
DEBUG::VST3Config: VST3PI::set_event_bus_state: n_bus_in = 4 n_bus_in = 0 enable = 1
DEBUG::VST3Config: VST3 instantiating FUID: 3B63D74130B34AE397AF92A9659137D5
DEBUG::VST3Config: VST3PI::enable_io: ins = 2 == 2 outs = 70 == 70
DEBUG::VST3Config: VST3PI::enable_io: n_bus_in = 1 n_bus_out = 33
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kInput, 0, 1) used-chn: 2 spk-arr: 3
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 0, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 1, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 2, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 3, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 4, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 5, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 6, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 7, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 8, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 9, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 10, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 11, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 12, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 13, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 14, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 15, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 16, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 17, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 18, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 19, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 20, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 21, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 22, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 23, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 24, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 25, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 26, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 27, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 28, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 29, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 30, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 31, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 32, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: setBusArrangements ins = 1 outs = 33 | rv = 0
DEBUG::VST3Config: VST3PI: Input BusArrangements: 0 chan: 2 bits: 3
DEBUG::VST3Config: VST3PI: Output BusArrangements: 0 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 1 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 2 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 3 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 4 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 5 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 6 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 7 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 8 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 9 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 10 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 11 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 12 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 13 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 14 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 15 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 16 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 17 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 18 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 19 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 20 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 21 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 22 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 23 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 24 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 25 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 26 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 27 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 28 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 29 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 30 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 31 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 32 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI::setup_psl_info_handler: (0) (0)
DEBUG::VST3Config: VST3Plugin::set_state: set_program (pgm: 0 plug: HALion 7)
DEBUG::VST3Config: VST3PI::load_state: chunk: 0 off: 48 size: 30604 type: Comp
DEBUG::VST3Config: VST3PI::load_state: chunk: 1 off: 30652 size: 23972 type: Cont
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 29633AEC1D1C47E2BB85B97BD36EAC61
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 6D319DC660C56242B32C951B93BEF4C6
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 29633AEC1D1C47E2BB85B97BD36EAC61
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: 6D319DC660C56242B32C951B93BEF4C6
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
DEBUG::VST3Config: VST3PI::setup_psl_info_handler: (0) (0)
DEBUG::VST3Config: VST3PI::queryInterface not supported: 00C9DC5B9D90425491A388C8B4E91B69
DEBUG::VST3Config: VST3PI::notifyProgramListChange: val: 0 (norm: 0)
DEBUG::VST3Callbacks: VST3PI::restartComponent 40
DEBUG::VST3Callbacks: VST3PI::restartComponent 14
DEBUG::VST3Callbacks: VST3PI::restartComponent 14
DEBUG::VST3Config: VST3PI::enable_io: ins = 2 == 2 outs = 70 == 70
DEBUG::VST3Config: VST3PI::enable_io: n_bus_in = 1 n_bus_out = 33
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kInput, 0, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 0, 1) used-chn: 2 spk-arr: 3
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 1, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 2, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 3, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 4, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 5, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 6, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 7, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 8, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 9, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 10, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 11, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 12, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 13, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 14, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 15, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 16, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 17, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 18, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 19, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 20, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 21, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 22, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 23, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 24, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 25, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 26, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 27, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 28, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 29, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 30, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 31, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: activateBus (kAudio, kOutput, 32, 0) used-chn: 0 spk-arr: 0
DEBUG::VST3Config: VST3PI::enable_io: setBusArrangements ins = 1 outs = 33 | rv = 0
DEBUG::VST3Config: VST3PI: Input BusArrangements: 0 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 0 chan: 2 bits: 3
DEBUG::VST3Config: VST3PI: Output BusArrangements: 1 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 2 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 3 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 4 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 5 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 6 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 7 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 8 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 9 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 10 chan: 0 bits: 0
lDEBUG::VST3Config: VST3PI: Output BusArrangements: 11 chan: 0 bits: 0
ocate to DEBUG::VST3Config: VST3PI: Output BusArrangements: 12 chan: 0 bits: 0
0DEBUG::VST3Config: VST3PI: Output BusArrangements: 13 chan: 0 bits: 0
 DEBUG::VST3Config: VST3PI: Output BusArrangements: 14 chan: 0 bits: 0
took DEBUG::VST3Config: VST3PI: Output BusArrangements: 15 chan: 0 bits: 0
2DEBUG::VST3Config: VST3PI: Output BusArrangements: 16 chan: 0 bits: 0
8143DEBUG::VST3Config: VST3PI: Output BusArrangements: 17 chan: 0 bits: 0
 DEBUG::VST3Config: VST3PI: Output BusArrangements: 18 chan: 0 bits: 0
usecs for DEBUG::VST3Config: VST3PI: Output BusArrangements: 19 chan: 0 bits: 0
2DEBUG::VST3Config: VST3PI: Output BusArrangements: 20 chan: 0 bits: 0
 DEBUG::VST3Config: VST3PI: Output BusArrangements: 21 chan: 0 bits: 0
tracks = DEBUG::VST3Config: VST3PI: Output BusArrangements: 22 chan: 0 bits: 0
1DEBUG::VST3Config: VST3PI: Output BusArrangements: 23 chan: 0 bits: 0
4072DEBUG::VST3Config: VST3PI: Output BusArrangements: 24 chan: 0 bits: 0
 DEBUG::VST3Config: VST3PI: Output BusArrangements: 25 chan: 0 bits: 0
per track
DEBUG::VST3Config: VST3PI: Output BusArrangements: 26 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 27 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 28 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 29 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 30 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 31 chan: 0 bits: 0
DEBUG::VST3Config: VST3PI: Output BusArrangements: 32 chan: 0 bits: 0
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: EEC8968380DB43369177273E138A763B

(Ardour.exe:5488): Pango-WARNING **: 07:44:18.294: couldn't load font "ArdourMono Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", falling back to "Sans Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", expect ugly output.

(Ardour.exe:5488): Pango-WARNING **: 07:44:18.295: couldn't load font "Sans Ultra-Light Ultra-Condensed Not-Rotated 5.3994140625", falling back to "Sans Not-Rotated 5.3994140625", expect ugly output.

(Ardour.exe:5488): Pango-WARNING **: 07:44:18.304: couldn't load font "bold ArdourMono Not-Rotated 7", falling back to "Sans Not-Rotated 7", expect ugly output.

(Ardour.exe:5488): Pango-WARNING **: 07:44:18.311: couldn't load font "ArdourMono Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", falling back to "Sans Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", expect ugly output.

(Ardour.exe:5488): Pango-WARNING **: 07:44:18.311: couldn't load font "Sans Ultra-Light Ultra-Condensed Not-Rotated 6.2998046875", falling back to "Sans Not-Rotated 6.2998046875", expect ugly output.
Butler drops pool trash
Graph::drop_threads() sema-counts: 0, 0, 1
PluginWindow deleted for 0x2b4bedc0
DEBUG::VST3Config: VST3PI::set_event_bus_state: n_bus_in = 4 n_bus_in = 0 enable = 0

C:\Users\Titan-R7>
(0027515)
Mark Knecht   
2023-03-26 22:43   
Having messed with a about 30 VST3's this weekend looking at what works and what does I'm fairly convinced right now that your comment about this sort of issue:

DEBUG::VST3Config: VST3PI::queryInterface not supported: F89F8CDF699E4BA596AAC9A481452B01
DEBUG::VST3Config: VST3PI::queryInterface not supported: EC23B5FFF97CF14DA41213F033E3E00C
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44
PBD::DEBUG::VST3Config: HostApplication::queryInterface not supported: A3B8C6C5C0954688B0916F0BB697AA44

is probably the root cause. VST3's that don't have these messages seems to work fine, ones with lots crash more often or don't work in some other way.

If Ardour is behind on Steinberg's VST spec levels then I guess what's next is to look at the newer spec and begin to support it when you can.

There are certain VST3's that I have that only have 1 or 2 of these messages so if it's helpful I can test intermediate debug updates any time, just get in touch. Happy to do it.

For now I'll use Halion as an stand alone app and outboard sound source which is more work for me but appears completely stable on my Win 10 system
(0027516)
Mark Knecht   
2023-03-26 22:44   
what works and what does/doesn't
(0027517)
Mark Knecht   
2023-03-27 16:48   
As an aside I purchased a copy of the least expensive version of Cubase. As should be expected I can load and save all of the Steinberg VST3s as well as those from other VST providers, and can record MIDI and audio.

I stand ready to do any testing needed to help move this bug resolution forward. Just get in touch.
(0027538)
x42   
2023-04-05 16:01   
I cannot reproduce this with Ardour 7.3.182 -- all control settings are properly restored. That includes the orange ones (Vibrato, Chorus, Reverb) as well as the instrument settings (Pitch, Filter, Amp).
(0027539)
Mark Knecht   
2023-04-05 16:11   
That's Halion Sonic, not Halion, but Halion Sonic fails for me at least 50% of the time. Sometimes it does work.

2 things:

1) I'm glad it looks ok. Did you actually listen to and export the audio? Yesterday in Mixbus32C (on my machine, your point taken) it appears to fail visually - the VUs aren't moving and I got no sound - but I was able to export the audio even though the VUs weren't moving. Weird.

2) Do me a favor. In that session delete the MIDI track with Halion Sonic and then re-add a new MIDI track with Halion Sonic on it again. Does it work? For me that fails 100% of the time in Mixbus32C on Win 10 with a message about a Jack MIDI port already existing.
(0027540)
x42   
2023-04-05 16:16   
It works, but note that we do not use JACK.
(0027541)
Mark Knecht   
2023-04-05 17:28   
On my system in Mixbus32C-9 I have a session with only 1 MIDI track with Halion Sonic applied. I right click that track, remove it and now the session is empty. I then attempt to add a new MIDI track with Halion Sonic applied. In the console window at the upper right the light turns red and I see this:

2023-04-05T10:24:10 [INFO]: Loading user ui scripts file C:\Users\Titan-R7\AppData\Local\Mixbus9\ui_scripts
2023-04-05T10:24:10 [INFO]: Loading plugin order file C:\Users\Titan-R7\AppData\Local\Mixbus9\plugin_metadata\plugin_order
2023-04-05T10:24:11 [INFO]: Loading history from C:\Users\Titan-R7\Documents\Nathan 3\Nathan 3.history
2023-04-05T10:24:36 [ERROR]: mixbus32c::register_port: Port already exists: (mixbus32c:HALion Sonic/midi_in 1)
2023-04-05T10:24:36 [ERROR]: No more JACK ports are available. You will need to stop Mixbus32C and restart JACK with more ports if you need this many tracks.
2023-04-05T10:24:36 [ERROR]: could not create 1 new mixed track

The first 3 lines are the end of what's in the console after loading the session. The last 3 lines are the error and Mixbus won't add the track.

Possibly it's a Mixbus32C problem only?
(0027542)
Mark Knecht   
2023-04-05 17:35   
To the extent it helps you at all here is a plugin report generated last week I think by Cubase LE for my Windows environment. Shows info about my computer and all of the plugins.

It's quite a wide file. I have to stretch it out over 2 monitors to read it. It does appear to show which VST3 spec version units are built against.

If there is any specific VST you want me to test in some way let me know.
(0027543)
Mark Knecht   
2023-04-05 17:43   
I tried the same thing in Ardour and it doesn't fail the way Mixbus32C does. Will report to Harrison.
(0027548)
x42   
2023-04-06 04:00   
> but Halion Sonic fails for me at least 50% of the time. Sometimes it does work.

Aha! That gives me an idea.

As for the JACK port issue. Chances are that this is JACK on Windows specific issue? It is unclear why the port is not unregistered properly. but that is a different bug.
(0027551)
x42   
2023-04-07 00:09   
Could you try Ardour 7.3-187 (or later) from https://nightly.ardour.org/ and see if state is correctly restored now?
(0027555)
Mark Knecht   
2023-04-07 13:48   
Good work. Testing version (rev 7.3-187-g979f9876a7), for the first time Ardour did apparently restore a Halion 7 FM Lab preset correctly.

I did 3 tests. In all cases I recorded MIDI, exported audio to an mp3, saved and closed Ardour, reopened Ardour and exported audio again.

1) Halion 7 in Single instrument mode using an FM Lab preset of mine.

2) Halion 7 in Multi Instrument/Rack mode using the same FM Lab preset.

3) Halion 7 in Multi Instrument/Rack mode with 3 instruments on the same MIDI channel mixed to a single stereo out.

There's obviously a lot more I could test but so far this looks very good.
(0027556)
Mark Knecht   
2023-04-07 14:05   
OK, I also tested a simple group output routing - Halion 7 in multi instrument mode, 3 instruments loaded on the same MIDI channel, and then 6 outputs which do apparently show up as 3 stereo pairs. In Halion I routed the instruments to Master, Out2 and Out3 and they showed up on the correct audio tracks in the group. I can solo each audio track in the group and I do hear the correct instrument so that looks good.

Excellent work!
(0027557)
Mark Knecht   
2023-04-07 14:06   
Also - as per a question earlier, I do not use Jack on Windows so that other problem is some other issue, but I don't think it's in Ardour, only in Mixbus. I have reported it to Nathan.
(0027558)
x42   
2023-04-07 14:42   
OK . It sounds like this issue can be closed. Thank you for the valuable feedback and testing!
(0027559)
x42   
2023-04-07 14:42   
Fixed since Ardour 7.3-187
(0027560)
Mark Knecht   
2023-04-07 14:48   
I agree. Closed for now. If I find something else I'll open a new ticket.

For my own education I was wondering if the fix was just building Ardour against a newer VST SDK library from Steinberg or something else? I took a quick look in the Ardour->About area and didn't see info about what SDK version it's using. My thought is that if you can reasonably easily call out the SDK version number somewhere that might be good.
(0027561)
x42   
2023-04-07 15:40   
Ardour is not using Steinberg's VST3 SDK at all. Only the interface.
(0027562)
x42   
2023-04-07 15:56   
As for the issue at hand.

Ardour saves the value of every automatable control-parameter itself (as if every parameter was automated).

When the session is loaded, first the VST3's custom state is restored, and then all control-parameters are set.
Usually the latter is a no-op. The plugin's custom state already has restored the correct information.

Halion has over 3500 parameters and setting them all in one go during the first process call apparently causes issues.
The solution was to only send a parameter-change if the new value does not already match the current one.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9300 [ardour] bugs minor always 2023-04-06 01:23 2023-04-06 01:23
Reporter: bsj Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Audition mode cracking when preview sounds and clips etc
Description: I notice because I had a eq correction Eq enabled on my processor section in ardour and mixbus that there is cracking when Audition mode is being used. When I disabled the eq I notice Audition mode works much better.
Tags: Crackle
Steps To Reproduce: Put a eq on the processor section, I tried with the ace eq but you have to adjust eq bands up and down and it produces the cracking in Audition mode enabled
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9294 [ardour] bugs minor always 2023-04-01 18:17 2023-04-03 14:51
Reporter: thecross Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stem export feature exports one track as silent
Description: When I export two of the session tracks using the "stem export" feature, one output file is OK and the other one is silent.
Tags:
Steps To Reproduce: Session > Export > Export stem
Channels : tick the two channels to export and untick "apply processing".
Period : tick "session".
File format : Flac 24 bit, no analysis nor normalizing.
Finally select "Export".
Two files are produced but one is silent.
Additional Information: See attached pictures :
"1-bug.png" shows that the two channels have audio content within the "begin" and "end" marks, but that one of the output files is empty.
"2-normal.png" shows the result obtained by exporting one channel by one.

Ardour 7.3.0 on GNU/Linux Debian 11.
Intel x86-64.
System Description
Attached Files: 2-normal.png (103,249 bytes) 2023-04-01 18:17
https://tracker.ardour.org/file_download.php?file_id=4457&type=bug
png

1-bug.png (103,164 bytes) 2023-04-01 18:17
https://tracker.ardour.org/file_download.php?file_id=4458&type=bug
png
Notes
(0027526)
x42   
2023-04-01 21:11   
I cannot reproduce this with a simple 2 track session as follows:

* new session
* add 2 mono audio tracks
* record-arm both tracks
* record + roll, record 20 seconds
* Session > Export > Stem Export
 - FLAC 24bit (not normalized, no silence trim/add, no meta-data
 - default session-timespan
 - export both tracks (Audio 1,2) without track/bus processing
 - disable "Analyze Exported Audio
 - disable "Re-Import Exported Audio"
 .. and export

Both files contain sound.

Can you provide a session which causes this issue? Is there anything in Menu > Window > Log
(0027533)
x42   
2023-04-03 14:51   
I managed to track down the issue. It depends on the order in which tracks/channels are enabled for export.
Fixed in Ardour 7.3-174 2c4d1e011c

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9296 [ardour] bugs major unable to reproduce 2023-04-02 18:53 2023-04-02 18:53
Reporter: Lost_Highway Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI notes not moving with changing tempo map & visually and audibly out of sync
Description: I recorded a MIDI region in a session in 7.3. When adding tempo changes on the Tempo ruler, the notes move around to conform to the shorter/longer bar (time) durations. However, when the region is exported to a MIDI file and imported into a different 7.3 session, the notes are static and do not move around to conform to shorter/longer bar durations caused by changing tempos on the Tempo ruler. What's more, whilst the MIDI notes appear in the wrong places (because the region appears to be at a fixed tempo over bars of varying tempos), the notes sound in different places to where they appear -- they more-or-less where they should (i.e. the MIDI output is conforming to the tempo changes).

I tried reproducing this by creating a brand new session in 7.3, recording MIDI, exporting it, then importing the file into another (brand new) 7.3 session but everything worked as expected. The only thing I can think is that the sessions where I experienced this were first created in 7.0 (and I no longer have that installed to try to replicate) but now using 7.3.

Screenshot 1: shows the MIDI notes recorded in the session
Screenshot 2: shows the same session, but with tempo changes added. The notes conform to the changing tempo marks
Screenshot 3: shows an export of the MIDI from screenshot 1, imported into a different session, with tempo changes already on the timeline. The notes do not conform to the changing tempo (even when moving the region) and do not sound where they appear on the timeline. For example, the three hits in quick succession (circled) that should appear as a pick-up to the 7/8 bar (bar 133, see screenshots 1 and 2) appear about a bar early, but sound at almost the correct point (the arrowhead, just before bar 133)
Tags: 7.0, 7.3, Midi, sync, tempo
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 1 Screenshot_2023-04-02_19-38-25.png (32,038 bytes) 2023-04-02 18:53
https://tracker.ardour.org/file_download.php?file_id=4469&type=bug
png

2 Screenshot_2023-04-02_19-40-30.png (33,526 bytes) 2023-04-02 18:53
https://tracker.ardour.org/file_download.php?file_id=4470&type=bug
png

3 Screenshot_2023-04-02_19-46-15.png (51,723 bytes) 2023-04-02 18:53
https://tracker.ardour.org/file_download.php?file_id=4471&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9288 [ardour] bugs minor always 2023-03-25 20:14 2023-04-01 15:22
Reporter: joachim Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Pitch bend automation curves outputs incorrect values.
Description: Hi! I'm new here :-)

I've been making electronic music with synthesizers since 1997.
I've been using Linux as a server platform for many years and I've fallen in love with the four essential freedoms of libre software. Inspired by the work of unfa and his community, I decided to go all in on using FOSS for all my computing needs, including music production.
It is my understanding that MIDI editing is something Ardour can improve on.

I was making Cardinal patches for a MIDI file exported from a Propellerheads Reason project I started a few years ago with the intent of re-creating and finishing the entire project from scratch based on that MIDI file exclusively with libre software. The exported MIDI file has a few lead melody tracks with Pitch Bend automation and I noticed the lead voices sounded detuned whenever a change in pitch bend was played back from the automation lane.

As a sanity check, I set up a simple session with Pitch Bend automation, using two instances of Cardinal and two instances Surge XT set up to generate a simple sawtooth tone at 261,53 Hz. The sawtooth waveform is chosen because it's rich harmonic content makes it very easy to hear any relative offsets and changes in pitch. I set up identical conditions in Cardinal and Surge XT to have two references to compare against incase one of them was behaving differently.

In this test-session, attached below, I learned two things:

1. The Pitch Bend output values does not correspond to the values in the automation curve after they deviate from the default value of 8192. A pitch bend value of zero in the automation lane outputs a value of 273, and the maximum value of 16383 in the automation lane outputs a value of 16110.
When a pitch bend automation control point is to 8192 after a change in value, the actual output value is offset, depending on the previous direction of change. A volt meter fed by the V/Oct output on the Host MIDI module in Cardinal confirmes this.

2. The fader for the Pitch bend updates according to the automation curve on playback for Surge XT, but it remains static for Cardinal.
Tags: automation, connect, MIDI control
Steps To Reproduce: TLDR; Have a look at the attached Ardour session archive. There are comments written in each track that provide additional details on what's happening.

The following steps assumes you already have Cardinal and Surge XT installed and available and ready to go in Ardour's plugin manager.

1.1. Invoke the "Add Track/Bus/VCA" dialog box in Ardour.
1.2. Select MIDI Track as the type, and in the Configuration section, set the number of tracks to "2" and select Cardinal as the instrument.
1.3. Name one track as "Reference" and the other track as "Pitch Bend"
1.4. Open up the GUI for the Cardinal instance in the "Pitch Bend" track.
1.5. Right Click any empty space in Cardinal to bring up the module browser.
1.6. Select "Amalganated Harmonics" in the "Brand" drop-down list and "Visual" in the tags drop-down list and click and hold the left mouse button to select and place the "Polyprobe" module. Release the mouse button somewhere that makes it easy to see the module without having to scroll the viewport for convenience. I suggest you place it to the left of the "Host MIDI" module.
1.7. Right-click the "Host MIDI" module and set the Pitch bend range to "12".
1.8. Right-click the "V/Oct" output port on the right hand side (white background) to create a new patch cable. Choose any color you want, it does not bear any significance in this case. Left-click and drag a new cable to the "A" or "B" input of the Polyprobe module. The Polyprobe module should now read 0,000000 volts.
1.9. Shift your focus over to the "VCO"-module and left-click and drag the patch cable connected to the "SINE"-output over to the "SAW"-output.
1.10. Go to the "ADSR"-module and set "SUS" to 100% and, optionally, set "ATK" and "RES" to taste, or just leave them at their default values if you don't care.
1.11. In the "Host Audio" module and right-click the large knob over the "Level"-label and type in "-12" and hit Enter to set it to -12 dB.

2.1 Now, open the GUI for the "Reference"-instance of Cardinal.
2.2 Remove the patch cable going between the "V/Oct" output on the Host MIDI module and the "V/Oct" input on the VCO module by left clicking and dragging the cable away from one of the patch points. When you release the mouse button away enough from the chosen patch point, the cable will dissapear.
2.3 Go to the "ADSR" module and set "SUS" to 100% and, optionally, change "ATK" and "REL" to taste, or leave them at their default values if you don't care to do so.
2.4 Set the "Level" knob on the Host Audio module to -12 dB, in the same way you did in the "Pitch Bend" instance.
2.5 You can now close the window for this "Reference"-instance of Cardinal.

3.1 Create two MIDI regions, one for each track, make them about 4 bars long.
3.2 Paint a long C#4 note in both regions, make sure the two notes in each of the MIDI regions overlap so that you'll hear both the reference and pitch bend instances of Cardinal play simultaneously.
3.3 Add automation points for the pitch bend of the "Pitch Bend" Cardinal instance.
3.4 Hit play to hear why I'm reporting this as a severe bug.
3.5 (Optional) Change the tempo if desired.
3.6 (Bonus) Open and read the session metadata and the track comments for a bit more information.

In summary, the expected behaviour is:
1. Notes should continue playing while editing automation points.
2. When the Pitch Bend curve is returned to a value of 8192, pitch should also return to a zero offset of the note.
3. The value range of the pitch bend output should extend all the way from 0 to 16383, in accordance with the automation curve values.

But, the actual behaviour is:
1. A note off event is triggered whenever changes to the automation curve is done during playback, which is annoying when doing automation edits on longer notes.
2. Actual Pitch Bend output values does not correspond to the values in the automation curve. A pitch bend value of 0 in the automation lane outputs a value of 273, and the maximum value of 16383 in the automation curve outputs a value of 16110.
3. When the pitch bend automation curve is set to return to 8192, the actual output value is offset, depending on the direction of change for the automation curve.
4. The automation level fader does not update when controlling a Cardinal Synth (tested with LV2 and VST3)
Additional Information: I compiled Ardour from git and ended up with rev 7.3-143-gc771eccd0e to see if this bug has been adressed already, but I saw the same behaviour there as in the current "Nerve Net" (rev 7.3) release

I have not yet checked if this automation curve behaviour is the same for other types of control messages. Incorrect pitch bend behaviour is the most noticable and critical issue for me.

I chose to use the LV2 versions of Cardinal and Surge XT because of the relativly simple nature of this test scenario. I saw no need to test with the VST3 versions as there is only one channel of output needed per track to hear what's going on.
System Description
Attached Files: MIDI Pitch Bend automation bug_2023-03-25_205625.ardour-session-archive (36,529 bytes) 2023-03-25 20:14
https://tracker.ardour.org/file_download.php?file_id=4450&type=bug
Notes
(0027524)
x42   
2023-04-01 15:22   
Fixed in 7.3-170-g4ba1ccc09b

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9291 [ardour] bugs minor always 2023-03-28 09:58 2023-03-28 09:58
Reporter: grammo Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: NSM: ardour only launch succesfull if JACK is running
Description: Ardour seems to quit itself when JACK is not running, while under NSM session management. NSM is not dependent on JACK. So I don't think Ardour should check if JACK is running or not when under NSM. It's the responsibility of the user to check this. The particular NSM session manager GUI can help them with it, but not Ardour. Maybe the user wants to use NSM with ALSA or whatever next generation thing.
Tags: jack, NSM
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9290 [ardour] bugs minor always 2023-03-26 16:56 2023-03-26 16:56
Reporter: alex.cherg Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Scheduled cue slots for playing tracks don't have a frame around
Description: Normally, scheduled cue slots have a white frame indicating that the cue slot is to be played next.
For scheduled cue slots in a track that is currently playing another cue slot, the frame is not there.
Tags: cue
Steps To Reproduce: 1. Setup 2 tracks with 2 cues (A and B).
2. Trigger 1A (track 1 cue A)
3. Trigger cue B
4. 2B has a white frame indicating that this slot is about to be played, but 2A doesn't have such a frame.
Additional Information:
System Description
Attached Files: cue_slot_frame_bug.png (43,819 bytes) 2023-03-26 16:56
https://tracker.ardour.org/file_download.php?file_id=4454&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9283 [ardour] bugs crash always 2023-03-17 20:18 2023-03-24 14:37
Reporter: Dan Easley Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ardour crashes on session load
Description: Hi! The Ardour 7.3.0 official build recently started crashing on this session, and this session only, whether plugins are enabled or not. This was preceded by some crashing happening when zooming in and moving newly-combined regions on five or six tracks at once, and recovering crash data following those crashes. Thanks!
Tags:
Steps To Reproduce: Opening this file.
Additional Information: I've tried to attach a backtrace here. The session file is larger than the upload limit; here's a link to it: https://drive.google.com/file/d/1MZiqd721lBUsWh2u7gwdriIW_3jocSpj/view?usp=sharing
System Description
Attached Files: ardour-crash-on-startup-backtrace.txt (82,689 bytes) 2023-03-17 20:18
https://tracker.ardour.org/file_download.php?file_id=4444&type=bug
The Days of Defamation.ardour.gz (440,211 bytes) 2023-03-22 02:08
https://tracker.ardour.org/file_download.php?file_id=4446&type=bug
Notes
(0027480)
Dan Easley   
2023-03-18 15:03   
When run from the command line, Ardour reports this right before crashing:

ardour-7.3.67: ../libs/ardour/audio_playlist.cc:279: ARDOUR::timecnt_t ARDOUR::AudioPlaylist::read(ARDOUR::Sample*, ARDOUR::Sample*, float*, const timepos_t&, const timecnt_t&, uint32_t): Assertion `start.distance (i->range.start()).samples() + read_cnt <= scnt' failed.
(0027487)
paul   
2023-03-21 18:08   
Can you attach the session (as an archive) ?
(0027492)
Dan Easley   
2023-03-22 02:08   
Somehow didn't think to zip the file. Thanks so much!
(0027493)
paul   
2023-03-22 02:24   
I will need the entire session (Session > Archive), not just the .ardour file ...
(0027494)
Dan Easley   
2023-03-22 02:39   
Oh, I think I see. It's a 1.3GB file, so here's a link to it. If I'm still misunderstanding, please just let me know.

https://drive.google.com/file/d/1yA2olSTEWUVLZ1P8WWz7GHbJNKPqg0w-/view?usp=sharing
(0027505)
paul   
2023-03-23 03:50   
OK fixed. You can get the corrected session file at https://ardour.org/files/defamation.ardour

The error was caused by mixed time domains in the length of many regions in this session. It would be a good idea for us to figure out how this happened, but I'm not sure how easy that might be.

Also, what system do you run this on? It was overloading on my 16 core Ryzen Threadripper ...
(0027506)
Dan Easley   
2023-03-24 14:37   
Paul, thanks so much for this! I can't overstate how well-supported I feel right now. You're the best!

I'm running on a dell tower system with an i7-12700K, 16GB RAM, and and RME Raydat. I think it's the first desktop computer I've ever had that's fairly current in specs. I'd been wanting an RME interface since I first read about them on the LAU list years ago - might be a stretch to say that I could finally afford one, but I did finally buy one. :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9282 [ardour] bugs minor always 2023-03-15 15:51 2023-03-22 18:29
Reporter: SoundsOfKooky Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Updating to 7.3 breaks tracks and busses using IEM plugins
Description: After updating to 7.3 all my projects using IEM plugins for ambisonics had no sound going through the tracks and busses with those plugins. I tried on new projects and the same happened.
Vanilla 4 channel with the default ardour 360° panner works, but as soon as I drop a IEM stereo Encoder, or a IEM binaural decoder somewhere there is no longer any sound coming through. All activity also stops on the meters, as if there were no audio on the track or being routed to the bus.
Note that this is also true when placing the plugins post-fader.

Reverting to 7.2 fixed the issue.
Tags: plugin, VST3
Steps To Reproduce: Requires IEM plugin suite (v1.4.3 in my case)

1. create a 4 channel track
2. record some audio to it, or in a seperate track and drag it into the track
3. play it back: it works fine
4. disable panner: still works fine
5. add a stereo encoder plugin from IEM, set it to 1st order ambisonics (you might have to go into pin connections and manually remove the extra outputs that get automatically created, until you have only 4 outputs).
6. hit play. In 7.3 you'll get the bug: no sound, nothing on the meters

The same will happen on a bus, if you want to send audio from a 4channel ambisonics encoded track into a binaural decoder.
Additional Information:
System Description
Attached Files: IEM-decoder.png (88,414 bytes) 2023-03-21 01:41
https://tracker.ardour.org/file_download.php?file_id=4445&type=bug
png
Notes
(0027483)
x42   
2023-03-21 01:41   
Could you try with a recent nightly build (demo is fine for testing) from https://nightly.ardour.org/ ?

Since those plugins are made with JUCE, a recent change made in Ardour likely addresses the issue:
https://github.com/Ardour/ardour/commit/6cb90471fe3a63f44f452b48b9cc77b330062708

If you wait for tomorrow's build (7.3.76), there is now also a context menu in the plugin-pinout window to allow to "disconnect all" which makes it easier to only connect the required I/O.
That seems to work here and the plugin also auto-detects 1st order when only connecting the first 4 outputs
(0027495)
SoundsOfKooky   
2023-03-22 11:53   
Tried build 7.3.77 :
-audio issue is fixed. Opening a project with IEM plugins works, no audio bug anymore
-disconnect all makes ardour freeze for a couple of seconds and crash, jack server is still running.
(0027496)
x42   
2023-03-22 18:28   
> -disconnect all makes ardour freeze for a couple of seconds and crash

The crash happens inside the plugin. It is fine to either disconnect all inputs or all outputs for as long as there is at least one plugin I/O pin connected.
I have reported this issue: https://git.iem.at/audioplugins/IEMPluginSuite/-/issues/173
(0027497)
x42   
2023-03-22 18:29   
Thanks for testing.

Since "audio issue is fixed. Opening a project with IEM plugins works, no audio bug anymore" -- there is nothing more to do on the Ardour side of things.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9286 [ardour] bugs minor always 2023-03-21 23:28 2023-03-22 00:48
Reporter: enorrmann Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ardour crashes trying to consolidate range
Description: ardour crashes trying to consolidate range
Tags:
Steps To Reproduce: on ubuntu 23.04 official 7.3 biuld from ardour.oorg go to edit mode, region select the audio on the FX audio track,ricght click, consolidate, input a name, accept and crash
sample project
https://www.dropbox.com/s/6tr1psgg8uinzlb/IP_01_LIVE_2.zip?dl=1
Additional Information:
System Description
Attached Files:
Notes
(0027490)
x42   
2023-03-22 00:46   
Thanks due to your session it was easy to reproduce and hence also easy to fix!
Fixed in Ardour 7.3-77-g5453e6f1f7
(0027491)
enorrmann   
2023-03-22 00:48   
great !

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9050 [ardour] bugs major always 2022-10-30 19:00 2023-03-21 18:06
Reporter: levalithan Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi editor snapping offset after tempo marker
Description: Was making a project in 120BPM, added a tempo marker to transpose to 190, Midi editor became unusable. It's hard to describe, but I think it's still snapping notes as if it's 120BPM but allowing me to create notes as if it were 190. For example, i can place a note down, but if i try to resize it, depending on where it is after the tempo marker, the preview will move further ahead, and the length of the note will only correlate to a 120bpm grid.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026776)
paul   
2022-10-31 05:47   
This is almost certainly fixed in git master. Please check a nightly build or wait for 7.1 in a day or two. We have fixed many bugs in this area over the last two weeks.
(0027484)
levalithan   
2023-03-21 17:53   
this still has not been fixed
(0027485)
paul   
2023-03-21 18:06   
Can you provide an example session and a few more detailed instructions to reproduce? Thanks.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9038 [ardour] bugs major always 2022-10-26 09:18 2023-03-18 07:00
Reporter: al f Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Shift+Alt+Left / Right shortcuts not working as expected
Description: In Ardour 7.0.0: After changing Shift+Alt+Left / Right shortcuts to "Playhead to Previous / next region boundary (No track selection)", both shortcuts place playhead at session start (same as Home button).

In Ardour 7.0.105 (rev 7.0-105-g6904a86576): After changing the shortcuts, if the playhead is at a region boundary only Shift+Alt+Right works as expected.
Shift+Alt+Left does nothing until the playhead is moved away from the region boundary. Then it will move the playhead to the previous boundary and get stuck again.
Tags: Editor, region, shortcuts
Steps To Reproduce: In a session with mulitple regions across multiple tracks, change shortcuts and (try to) navigate.
Additional Information:
System Description
Attached Files: ardour.log (4,028 bytes) 2022-10-26 09:18
https://tracker.ardour.org/file_download.php?file_id=4253&type=bug
Notes
(0027156)
al f   
2022-12-29 10:41   
I can not reproduce this in Ardour 7.2
(0027479)
al f   
2023-03-18 07:00   
In Ardour 7.3, if snap is set to "Timecode", "MinSec" or "CD Frames" then navigation with left / right arrows will only move the playhead to the next grid line and get stuck there. No response to left / right arrows.

If snap is changed back to musical time, normal behaviour resumes. I suspect this has been the problem all along.

I started Ardour with a fresh profile to make sure it didn't have to do with any of my settings. Running with official download on Manjaro KDE.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9271 [ardour] bugs minor always 2023-03-06 20:32 2023-03-15 15:03
Reporter: consint Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Time stretching of an audio region via drag and drop results in an audio region that is too small
Description: When I speed up/shorten an audio region with the time stretch tool via drag and drop and drag it to the previous bar, the region is a little bit too small after time stretching. You can hardly see it when zooming in, but when I duplicate the file a few times afterwards, the duplicates end up further and further away from the grid.

This only seems to happen when I speed up an audio region. If I make an audio region slower, duplicates of it remain right in the grid.
Tags: Time Stretch
Steps To Reproduce: Open a new session

Import an audio file

Drag the audio region with the time stretch tool smaller to the previous bar

Click "Stretch/Shrink" in the dialog box

Duplicate the shrinked audio region a few times to see it
Additional Information:
System Description
Attached Files:
Notes
(0027478)
consint   
2023-03-15 15:03   
I must correct myself. When I make an audio region longer/slower the resulting audio region is a bit too long.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9281 [ardour] features minor have not tried 2023-03-15 02:26 2023-03-15 02:26
Reporter: wargreen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cues : Not quantize Stop when Launch is not quantize (or allow to select it)
Description: In the cue launcher, if a cue is not launch quantized, the stop should be same.
Or we need to have the same choice !
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9278 [ardour] bugs minor always 2023-03-13 03:06 2023-03-15 01:49
Reporter: thekoala2 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Information in the selection clock widget is not accurate when set to "samples"
Description: If you do the math on the sample info in the selection clock widget, you will find it is innacurate
End - Length =/= Start

Tags:
Steps To Reproduce: 1 Set selection clock to samples
2 select a range
3 information is not accurate
Additional Information: The number of samples difference is not consistent
Snap or free selection makes no difference
Tempo map or simple bpm makes no difference

A few screen shots provided
System Description
Attached Files: example1.png (2,636 bytes) 2023-03-13 03:06
https://tracker.ardour.org/file_download.php?file_id=4441&type=bug
png

example2.png (2,858 bytes) 2023-03-13 03:06
https://tracker.ardour.org/file_download.php?file_id=4442&type=bug
png

example3.png (2,809 bytes) 2023-03-13 03:06
https://tracker.ardour.org/file_download.php?file_id=4443&type=bug
png
Notes
(0027471)
x42   
2023-03-13 03:15   
When counting frames Length = End - Start +1 (similar to the fencepost problem)

start 00:00:00:00 end 00:00:00:00 references the first frame. The length is 00:00:00:01
An "empty" selection has neither start nor end.

This convention dates back to editing tape and film.
(0027476)
thekoala2   
2023-03-15 01:42   
So is this intentional behaviour? If it is, I will close the report.
(0027477)
x42   
2023-03-15 01:49   
In general yes, except in the first case I'd expect the length to be 97086. There is still some oddity here.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9280 [ardour] bugs minor always 2023-03-13 18:01 2023-03-14 02:48
Reporter: peder Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't add leading silence when exporting
Description: As noted by yvan02 in https://discourse.ardour.org/t/impossible-to-add-a-silence-in-the-export-profile/108462 you can't add leading via the GUI when exporting anymore.
It worked in 7.0-31-gaaddf5f385 but not in 7.2-10-gedd68d8682 or 7.3-29-g93b68fea89

Tags:
Steps To Reproduce: Select an export format
click Edit
check "Add silence to start" , enter a number and hit Enter
click Save
click Edit again and notice that the option is now unchecked
Additional Information:
System Description
Attached Files:
Notes
(0027472)
x42   
2023-03-14 02:48   
Fixed in Ardour 7.3-61-g6ff8fb7c5e

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6752 [ardour] features feature N/A 2016-01-28 07:24 2023-03-13 21:07
Reporter: ohzbees Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Multi-Track Templates
Description: This feature has been requested a number of times in slightly different terms, but I think it amounts to the same thing:

Have the ability to add multiple pre-defined tracks to an existing session.

See here: http://tracker.ardour.org/view.php?id=5456
and here: http://tracker.ardour.org/view.php?id=5691
some more here: http://comments.gmane.org/gmane.comp.audio.ardour.user/10749

There doesn't seem to be much discussion of this I could find beyond the above.

This is *very* useful in the following workflow: We have started building a song with a basic set of tracks (e.g., click, vox, guitar). Sometime later we wish to add more sophisticated accompaniment (drum tracks/buses will probably be the most common).

In general, it would add considerably to the flexibility and efficiency of building up a session.

On the face of it, this seems like it might be a shoo-in given the very cool existing single-track-template/dupe features, i.e., just save a template containing pointers to multiple tracks (selected by the user).

Tags: template, track
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017853)
ohzbees   
2016-01-28 07:33   
SONOR has the proposed feature:

http://forum.cakewalk.com/SOLVED-Export-amp-Import-MultiTrack-Templates-m2920985.aspx

Simply select a bunch of tracks and choose "Save as template...."
(0017856)
mc888   
2016-01-29 23:01   
similar to 0006465
(0018057)
Domino   
2016-03-09 20:46   
It's a 3D app rather than a DAW, but I really like Blender's approach to this. Import lets you open a blend file and select a single or multiple elements from that file to import.

I'd find a similar approach in Ardour to be far more useful than a template system. You could import tracks but not audio, or even a single plugin from existing sessions or ones specifically created as templates.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5691 [ardour] features feature N/A 2013-09-18 15:44 2023-03-13 21:02
Reporter: Leatuspenguin Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 3.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Adding a "group template" facility - idea
Description: Currently, you can save and load track templates and session templates. They are both useful but there is no in between. What if you could do the same for groups, ie. save group templates. Furthermore to the settings that track templates save, group templates could also save all group settings, colours, etc.

Something like this would be useful for drum recordings with different configurations or perhaps you have different bus configurations that you like to use from time to time. Session templates are useful for similar set ups but may sometimes be overkill. They also aren't very useful if you've already started a session and just want one part of what would make up a session template. Group templates would be a flexible in-between option that would allow you to load up these configurations into a session that is already in progress.

Here's an idea of how it would work -

Right clicking on a group will give you the option to "save group template".

In “add tracks or bus”, underneath add tracks, there would be a drop down menu called “templates” or “group templates” with all saved templates saved into a drop down menu. Track templates could perhaps also be consolidated into this menu if it made sense to do so.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Save group template.png (17,644 bytes) 2013-09-18 15:44
https://tracker.ardour.org/file_download.php?file_id=2259&type=bug
png

Add template.png (18,044 bytes) 2013-09-18 15:44
https://tracker.ardour.org/file_download.php?file_id=2260&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9279 [ardour] bugs block have not tried 2023-03-13 17:23 2023-03-13 17:23
Reporter: nomystempar Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 7 crash just after session loading
Description: free(): invalid size
Abandon

This is what I get on 7.3.
I was in 7.2 then I got a segmentation fault, so I decided to update to see if the session loads again.

With -d option or safe mode I'm back with the seg fault.

My other sessions work fine.
Tags:
Steps To Reproduce:
Additional Information: More logs: https://discourse.ardour.org/t/ardour-7-crash-at-session-loading/108447/11

Link to the session: https://drop.chapril.org/download/f29209cdc1a2a4cd/#tN6OGRmwwcizDkVR5CwE6A
I's larger than 4mo.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9277 [ardour] other minor have not tried 2023-03-12 08:02 2023-03-12 08:02
Reporter: dftar Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [ERROR]: Butler read ahead failure on dstream auditioner
Description: I have this error every time i open the session…
[ERROR]: Butler read ahead failure on dstream auditioner
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Butler read ahead.png (130,003 bytes) 2023-03-12 08:02
https://tracker.ardour.org/file_download.php?file_id=4438&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9272 [ardour] bugs minor always 2023-03-06 20:57 2023-03-08 14:40
Reporter: consint Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi quantization does not work
Description: Quantizing midi notes only works as it should when selecting 1/4 note and 1/8 note. When selecting 1/16 note, a large number of notes end up somewhere between 16th notes. When I select 1/32 note, all notes end up at 16th notes and none at 32nd notes. With 1/64 note and 1/128 note, many notes land somewhere in between.

All tests were done with the settings "Snap note start" on, "Snap note end" off, Threshold 0, Strength 100 and Swing off.
Tags: Quantize
Steps To Reproduce: Open a new session

Add a midi track

Add a Midi Rigion with unquantized Midi notes

Select all notes and right-click "Quantize"

Select in the dialog window for example 1/16 note and press "Quantize".
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9270 [ardour] bugs major always 2023-03-05 20:41 2023-03-06 05:18
Reporter: znbm Platform: Ryzen 5 2600  
Assigned To: OS: Manjaro, Kernel 5.14.21-2  
Priority: high OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ALSA I/O halts with Behringer UM2
Description: I use a Behringer UM2 USB audio interface, and when I want to use my Alesis V49 MIDI controller during playback, I use the ALSA backend.
After some arbitrary duration -- usually between several seconds and several minutes --
playback suddenly halts and is replaced by a low-frequency square wave sound playing in the right channel.
After another ten seconds, the audio system stops completely and must be restarted, usually resulting in the same issue.
At this point, "The current operation is not possible because of an error communicating with the audio hardware." errors are common for many operations.
Tags: alsa, hangs, i/o failure, usb
Steps To Reproduce: Create a new Ardour session, using ALSA as the backend and the UM2 as the input and output device.
Create a new MIDI bus with a MIDI-controlled instrument.
Play a loop range with some audio in it.
Play MIDI notes, whether from a MIDI controller, the piano roll, or a MIDI region.
Wait several minutes for playback to halt.
Additional Information: This issue occurs reliably with ALSA, and also with JACK, effectively making these backends unusable.
Notably, it does not occur with Pulseaudio, which works perfectly (but lacks MIDI I/O support).

The issue might occur when MIDI is not involved at all, but I haven't reproduced it.

Changing the "Record Monitoring" does not seem to help.
Changing the MIDI system to "ALSA sequencer" seems to make the error occur faster.
Changing it to "None" does not seem to completely prevent the error -- other MIDI sources can still cause the issue.

No relevant output appears on stdout or stderr.

I assume the square wave sound is caused by the UM2's firmware when it encounters an error.

Personally, I'd prefer if this issue were fixed by adding MIDI I/O support to the Pulseaudio backend.
High-latency Pulseaudio MIDI input would much better fit my workflow than low-latency ALSA MIDI input,
even if the latter worked reliably.
System Description
Attached Files:
Notes
(0027429)
paul   
2023-03-06 00:43   
What buffer size(s) were you using with each backend?
(0027430)
znbm   
2023-03-06 01:07   
Typically (and most recently) 1024 samples, which I think is the default. Pulseaudio also uses 1024 samples.
For what it's worth, stdout also informs me that all of the MIDI buffers are "of size 8192".

I tested it just now and found some very interesting behavior:

When starting ALSA with 8192 samples, Ardour gives a "Could not configure Audio/MIDI engine with given settings." error popup.
Then it opens the "Starting Audio/MIDI Engine" splash anyway, but at least it doesn't hang.

When starting ALSA with 4096 samples, Ardour crashes with this message on stderr:
```
** (ardour-7.2.0:382037): ERROR **: 16:04:12.547:
unhandled exception (type std::exception) in signal handler:
what: negative distance in timecnt constructor
```

When starting ALSA with 1024 samples, playback runs properly for about five seconds, then halts as described above.

When starting ALSA with 256 samples, the audio instantly halts... but the tone is higher pitch, and it seems to flicker on and off randomly for a while.
The audio engine doesn't actually seem to halt, and I can get snippets of playback to play between the tone.

When starting ALSA with 64 samples, the audio instantly halts, and the tone is even higher pitch. Its waveform seems to waver slightly every second or so.

At this point I don't think the audio I hear is actually a square wave, nor is it probably generated by the UM2. But it's always sounded the same, no matter what audio I'm playing back.
(0027431)
paul   
2023-03-06 01:34   
It is very unlikely that PulseAudio is using 1024 at the hardware level. When using PulseAudio, you should open a terminal window, and run this command:

cat /proc/asound/card0/pcm0p/sub0/hw_params

substituting "card0" with the right cardN value for the device you are using. My guess is that the real problem is that your computer cannot support the buffer sizes you're using; PulseAudio works because under the hood it uses a much larger buffer size.

The exception message is compeltely unrelated to what we're discussing (though it is a bug that should be tracked down.
(0027432)
znbm   
2023-03-06 02:03   
You're right -- `$ cat /proc/asound/CODEC/pcm0p/sub0/hw_params` yields
```access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 44100
buffer_size: 88200
```

On an unrelated note, JACK seems to work much better than ALSA, provided the server is started via QjackCtl.
The issue appears immediately at very small sizes like 64, but at 256 I haven't seen it happen at all.
I recall it also being problematic in the past, but for now it seems like a good workaround.
Thanks for the help.
(0027433)
paul   
2023-03-06 03:20   
to compare the Ardour- and QJackctl- started instances of JACK, start each of them and while one is running, in a terminal window run this command:

ps aux | grep jackd

Compare the two commands yourself or post them here and I can comment.
(0027434)
znbm   
2023-03-06 04:39   
Launching JACK from Ardour's Audio/MIDI Setup window has always yielded a "Could not reconnect to Audio/MIDI engine" error, regardless of "Device", "Driver", "MIDI System", etc.
I always assumed this was an issue with Manjaro's packaging of Ardour, since it prints something like this to stderr:
```
JACK command line will be: /usr/bin/jackd -t 200 -p 2048 -R -T -X alsarawmidi -d alsa -n 2 -r 48000 -p 1024 -d hw:CODEC,0 -X alsarawmidi
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Automatic start of JACK server is disabled at configure time
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
```
Regardless, using a QjackCtl-provided server (`/usr/bin/jackd -dalsa -dhw:CODEC -r48000 -Xseq`) works fine.

On an unrelated note, I remembered out how this error manifests when using JACK.
It doesn't occur randomly; instead, it reliably happens immediately after exporting and normalizing audio.
It also hangs Ardour, although fortunately the exported file is unaffected.
Let me know if I should make a new issue for that behavior.
(0027435)
paul   
2023-03-06 05:18   
The export hang is a semi-known problem, and I believe it does not happen with builds from ardour.org (you could try a demo version at no cost, parallel installed with the Manjaro one).

The only obvious difference with the two JACK commands are that Ardour has been told use the ALSA Raw MIDI API when starting JACK, whereas QJackctl is using the ALSA Sequencer MIDI API. I'd be surprised, however, if that explained the difference. But fundamentally, I'd suspect a packaging/build error, indeed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9269 [ardour] bugs minor always 2023-03-05 17:20 2023-03-05 17:20
Reporter: cieciu Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: stretching tool work on orginal midi region - that restores leading silence
Description: Stretching tool work on original midi region - that restores leading part removed with moving left region border (eg. removed silence). That even may couse all notes to jump out of visiblity beyond right border of region. That may occur even by just clicking on region with stretch tool active - "click" and all your notes disappear.
Tags:
Steps To Reproduce: Remove beginning of region by moving left region border to the right on grab mode.
Activate Stretch mode.
Click on region or stretch it.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9268 [ardour] translation tweak have not tried 2023-03-05 14:28 2023-03-05 15:45
Reporter: oliverruehl Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: low OS Version: (any)  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Confirmation mail says "Paul David" instead of "Paul Davis"
Description: After donating I got an email.
It says "Paul David" instead of "Paul Davis"
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Opera Snapshot_2023-03-05_152551_my.mail.de.png (25,764 bytes) 2023-03-05 14:28
https://tracker.ardour.org/file_download.php?file_id=4434&type=bug
png
Notes
(0027426)
paul   
2023-03-05 15:45   
Thanks for noticing.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9267 [ardour] features minor N/A 2023-03-05 07:53 2023-03-05 07:53
Reporter: williwow Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Adapt button functionality for clip launcher/cue-view so it is better adapted for touch screens
Description: I suggest to change the user interface for the clip launcher aus follows:

The clip launcher has for each slot two functions:
* the small triangle launching the clip
* the area where the name of the clip/wav/midi is visible (which activates also the control panel on the lower part of the screen)

When using a device/laptop with touch screen (which becomes more and more common) the clip launching panel ("cue"-view) could be directly used for launching the clips. However the "triangle"-Buttons are much too small to be used.
Thus I suggest to switch functionality:
* the "large" area where the name of the clip is shown should have the "play" functionality, thus the cue-view could be directly used for live looping on touch devices
* the functionality of the "play" triangle should take over the menu-functionality and showing the control panel

See mockup.

In general clip launching could be optimized to work on touch screens so additional hardware (launchpad) could be avoided.

Thanks!
Tags: ui
Steps To Reproduce:
Additional Information:
System Description
Attached Files: launchpad.jpg (192,041 bytes) 2023-03-05 07:53
https://tracker.ardour.org/file_download.php?file_id=4433&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9194 [ardour] bugs major sometimes 2023-01-07 10:34 2023-03-04 06:03
Reporter: Windsurfer152 Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: high OS Version: (any)  
Status: assigned Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Manually edited MIDI cc messages do not retain position
Description: When entering a value it will sometimes appear to be ignored on playback. In fact the change will take place later than where it was entered. Changing the zoom level shows that the value is no longer where it was placed. Reverting to the initial zoom level confirms this.

It doesn't seem to matter whether snap is on or off, in lock or slide mode, in discrete or linear mode, or what the zoom level is when entering the values.

The issue does NOT occur when values are initially drawn. However once they are moved horizontally the behaviour occurs. This makes accurate use of controllers almost impossible.

Values can be edited using Grab, Draw or Internal Edit mode. The issue seems to be present regardless of which is chosen.
Tags:
Steps To Reproduce: Create a MIDI region. Make a controller visible and set to "play". Draw in some values. Edit their horizontal position. Note where those values are in relation to the timecode. Zoom in/out. Check position of value events. Behaviour is more obvious when discrete mode is used.
Additional Information: While working out how to reproduce the issue I note that when snap is enabled it sometimes seems impossible to actually snap to the grid. Possibly related?

Examples attached. Inputted values are 25, 8, 73, 95
System Description
Attached Files: Screenshot_2023-01-07_08-20-37.png (127,360 bytes) 2023-01-07 10:34
https://tracker.ardour.org/file_download.php?file_id=4341&type=bug
png

Screenshot_2023-01-07_08-22-51.png (128,631 bytes) 2023-01-07 10:34
https://tracker.ardour.org/file_download.php?file_id=4342&type=bug
png

Screenshot_2023-01-07_08-23-14.png (129,421 bytes) 2023-01-07 10:34
https://tracker.ardour.org/file_download.php?file_id=4343&type=bug
png

Screenshot_2023-01-07_08-23-47.png (129,115 bytes) 2023-01-07 10:34
https://tracker.ardour.org/file_download.php?file_id=4344&type=bug
png

Screenshot_2023-01-07_08-24-23.png (129,387 bytes) 2023-01-07 10:34
https://tracker.ardour.org/file_download.php?file_id=4345&type=bug
png

Screenshot_2023-01-07_08-24-53.png (129,271 bytes) 2023-01-07 10:34
https://tracker.ardour.org/file_download.php?file_id=4346&type=bug
png

Screenshot_2023-01-07_08-25-29.png (128,841 bytes) 2023-01-07 10:34
https://tracker.ardour.org/file_download.php?file_id=4347&type=bug
png

Screenshot_2023-01-07_08-26-22.png (121,643 bytes) 2023-01-07 10:34
https://tracker.ardour.org/file_download.php?file_id=4348&type=bug
png

ardour bug 2023-01-14 200143.png (144,313 bytes) 2023-01-14 21:13
https://tracker.ardour.org/file_download.php?file_id=4349&type=bug
png

2023_Folk_MIDI.zip (250,113 bytes) 2023-01-25 06:47
https://tracker.ardour.org/file_download.php?file_id=4353&type=bug
sidechaining.png (678,141 bytes) 2023-02-11 18:21
https://tracker.ardour.org/file_download.php?file_id=4386&type=bug
FX cv data test.zip (567,240 bytes) 2023-02-11 21:06
https://tracker.ardour.org/file_download.php?file_id=4388&type=bug
fix_test_7_2_267.zip (42,396 bytes) 2023-02-12 21:52
https://tracker.ardour.org/file_download.php?file_id=4392&type=bug
fix_test_7_2_267_1.zip (37,490 bytes) 2023-02-12 21:52
https://tracker.ardour.org/file_download.php?file_id=4393&type=bug
Screenshot_2023-02-12_20-43-22.png (117,461 bytes) 2023-02-12 21:52
https://tracker.ardour.org/file_download.php?file_id=4394&type=bug
png

Screenshot_2023-02-12_20-48-56.png (119,032 bytes) 2023-02-12 21:52
https://tracker.ardour.org/file_download.php?file_id=4395&type=bug
png

Screenshot_2023-03-02_15-26-42.png (167,855 bytes) 2023-03-02 16:11
https://tracker.ardour.org/file_download.php?file_id=4419&type=bug
png

Screenshot_2023-03-02_15-27-03.png (167,792 bytes) 2023-03-02 16:11
https://tracker.ardour.org/file_download.php?file_id=4420&type=bug
png

Screenshot_2023-03-02_15-28-08.png (168,055 bytes) 2023-03-02 16:11
https://tracker.ardour.org/file_download.php?file_id=4421&type=bug
png

Screenshot_2023-03-02_15-28-23.png (167,912 bytes) 2023-03-02 16:11
https://tracker.ardour.org/file_download.php?file_id=4422&type=bug
png

Screenshot_2023-03-02_15-28-38.png (168,690 bytes) 2023-03-02 16:11
https://tracker.ardour.org/file_download.php?file_id=4423&type=bug
png

Screenshot_2023-03-02_15-28-59.png (168,786 bytes) 2023-03-02 16:11
https://tracker.ardour.org/file_download.php?file_id=4424&type=bug
png

Screenshot_2023-03-02_15-29-26.png (168,258 bytes) 2023-03-02 16:15
https://tracker.ardour.org/file_download.php?file_id=4425&type=bug
png

Longer1.zip (210,793 bytes) 2023-03-02 17:17
https://tracker.ardour.org/file_download.php?file_id=4426&type=bug
Screenshot_2023-03-02_15-29-41.png (169,022 bytes) 2023-03-02 17:17
https://tracker.ardour.org/file_download.php?file_id=4427&type=bug
png

Screenshot_2023-03-02_15-30-12.png (168,473 bytes) 2023-03-02 17:17
https://tracker.ardour.org/file_download.php?file_id=4428&type=bug
png

Screenshot_2023-03-02_15-30-51.png (167,402 bytes) 2023-03-02 17:17
https://tracker.ardour.org/file_download.php?file_id=4429&type=bug
png

Screenshot_2023-03-02_15-31-30.png (166,979 bytes) 2023-03-02 17:17
https://tracker.ardour.org/file_download.php?file_id=4430&type=bug
png

Clarinet trial.zip (144,872 bytes) 2023-03-04 06:03
https://tracker.ardour.org/file_download.php?file_id=4431&type=bug
Clarinet trial_2023-03-04_055139.ardour-session-archive (26,063 bytes) 2023-03-04 06:03
https://tracker.ardour.org/file_download.php?file_id=4432&type=bug
Notes
(0027185)
benald   
2023-01-14 21:13   
I'm having this issue, too - In Ardour 7.2 on Windows. I'm hoping to find how to find a reasonable workaround until this is fixed. If you look at my screen shot there are two tracks with CC midi controls. In the lower track the repeated section has edited CC data that remains stable during zoom operations. I'm currently working on the track higher up the screen with the single region of CC data. This will currently degrade with almost any operation - including saving the file, closing Ardour and re-opening it. I'm wondering if the bug is at its worst on duplicated tracks. I have (since I started writing this) and I think the problem might be slightly less bad with tracks made from scratch (rather than duplicated) and notes copied and pasted to the new track. Also I cut the region into two at the tempo change. At this point the section after the tempo change behaved itself after I added some CC data and I eventually got he region before the tempo change to behave by editing the CC data the same distance ahead of where it slipped by during a zoom - since at this stage it was only seeming to slip once. Hopefully there is something useful here to either people wanting to make their CC data behave and/or coders trying to fix the problem.
(0027227)
paul   
2023-01-24 17:37   
was not able to trivially reproduce this.
(0027228)
paul   
2023-01-24 17:41   
if you could attach a session that demonstrates this behavior, that would be helpful.
(0027231)
benald   
2023-01-24 18:07   
I have just been able to replicate the problem by editing the control data on the track 'Siren Synth' then zooming in and out again in the time domain.
I'm sorry if this upload fails - I'm on holiday in a rural area (hence having more time to spend on Ardour) - which is very nice but the internet is terrible. I'll keep trying.
(0027232)
benald   
2023-01-24 18:22   
I haven't been able to upload the file because of internet problems. The first track in my project was an imported audio file. I deleted that track to upload my problem project and then had another look at the problem control data. The problem seems to have gone away. I recorded some audio to recreate the presence of an audio track and the problem is still absent. I'll try and get the original file to you as soon as I can, though.
(0027234)
benald   
2023-01-24 21:51   
'storm bass to upload' provides the root folder of my project and some sub folders
'storm bass root files' are files to be extracted into the project root folder
'cardinal patches' is a sub folder of root
'interchange' is a sub folder of root
(0027235)
paul   
2023-01-24 22:04   
I don't see the link .... am I just missing it?
(0027236)
benald   
2023-01-24 22:22   
I'm having trouble with Mantis, Paul. I have sent an email to the address on the credits page. That's you isn't it?
(0027237)
Windsurfer152   
2023-01-25 06:47   
Apologies for being late to the party with this.

Attached is the session from which I took the screenshots in the original post.

It uses SFZ and DecentSampler instruments which obviously aren't in the attachment and which may be a problem.

However I've added a track using General MIDI Synth which shows the same behaviour. I attempted to add some some CC1 data on the 2nd 16th note of each beat. All seemed ok until I adjusted the values (not the horizontal position). I saved the session without zooming in the hope you might see the mismatch.

I notice a previous bug report 0009142 also related to MIDI automation and involving tempo changes. I do have tempo changes in this session so perhaps the 2 are connected.
(0027239)
benald   
2023-01-25 11:09   
Re: tempo changes. My project also has at least one tempo change in it.
(0027306)
paul   
2023-02-07 04:32   
Thanks to Windsurfer152, this issue is now (mostly) fixed. Certainly the most significant breakage is now fixed, but there were a couple of other details along the way that I noticed that need careful attention and probably tweaks to change the behavior.
(0027309)
Windsurfer152   
2023-02-07 18:51   
Many thanks Paul. It's really nothing to do with me; I just reported the bug. Anyway I'll download a nightly build and test.
(0027324)
benald   
2023-02-08 09:39   
Thanks Paul. I am having a much better experience writing control data to my tracks now.
(0027348)
paul   
2023-02-10 18:26   
Glad to hear that. Turned out that code still had some very deep thinkos in it that prevent snapping to grid correctly. This has now (just) been fixed in commit f1d784afbb0e and you can now drag multiple points with a tempo change in the middle and if they were all on-grid before, they will stay on grid (if they were off-grid, only the point you actually grab will snap)

I would appreciate some testing of this in deliberately weird (and normal!) scenarios, so that I be confident about marking this all as resolved.
(0027358)
benald   
2023-02-11 18:21   
Paul, I have noticed that my recorded control data going into my Cardinal FX channels via sidechains and the Cardinal Host Midi CC module no longer work. This could well be down to something I have done and my level of expertise with this sort of software would indicates that what I am doing could be any distance away from either sensible or practical. I think I would be sending this data directly via a bus track in Ardour but the bus tracks, I think, don't have facilities for recording and sending CC data. So I have done it using sidechaining from other midi channels, and, I'm pretty sure I had it working a week or two ago. If I am wrong or this was never meant to be possible in the first place then fair enough. I will request recording CC data in Bus channels. That, I think, would be the sensible solution to all of this. Sorry to have unloaded all of this on you. I was happy with my little workaround there while it worked but, as I say, having the feature in the Bus tracks would be better anyway. I think
(0027359)
paul   
2023-02-11 19:26   
@benald: plese clarify what *used to work* and what does not work now. Images generally don't convey a lot (except when they do).
(0027361)
benald   
2023-02-11 21:06   
I have been playing around a bit more. I have made a simple project to upload and found that of the two control parameters I have set up in the midi track, parameter 1 gets sent to and is available in the FX in the audio bus but not parameter 2. Having one parameter work is better than I thought and the other one not working is probably something I’m doing but a week or so ago I was running five or six parameters each to two FX buses without a problem.
(0027362)
benald   
2023-02-11 21:52   
I have been playing around a bit more. I have made a simple project to upload and found that of the two control parameters I have set up in the midi track, parameter 1 gets sent to and is available in the FX in the audio bus but not parameter 2. Having one parameter work is better than I thought and the other one not working is probably something I’m doing but a week or so ago I was running five or six parameters each to two FX buses without a problem.
(0027363)
benald   
2023-02-11 22:02   
Sorry Paul. Everything I have said about a way of sending CV from midi tracks to Audio busses via a sidechain that used to work in Ardour before your fix which don't work now I have fixed by correcting the routing of the CV in my cardinal patches. It was entirely my bad.
(0027365)
Windsurfer152   
2023-02-12 11:27   
I've spent a bit of time testing. I included tempo changes, ramped tempo changes, cc data added before I'd set the changes of tempo, edited some of that data after adding the tempo changes, added some new cc data... It's a massive improvement - thank you.

I came across 3 minor issues, 1 of which may be entirely an installation error on my part so I'll leave that till last.

Snap now works! For cc data, particularly in linear mode, it works in a slightly unexpected fashion. So it allows you to draw or move points to positions between snap values, but the nearer you get to the snap points the more it tends to snap. I really like this as it avoids the need to change the snap value or turn snap off to make small adjustments. But that feeling may not be universal. I didn't find instances of that behaviour in discrete mode but maybe I didn't look hard enough...

All the cc data I added after adding tempo changes worked perfectly. Likewise any existing cc data I edited after adding tempo changes. The only thing that wasn't quite right is some of the existing (linear) data lagged slightly on playback. So what I saw in the slider panel and heard didn't tally with what I had drawn and was seeing in the controller lane. Unlike previous behaviour toggling the zoom setting didn't redraw the values.
On editing the misbehaving points with the pencil tool - just dragging a few pixels vertically and then replacing - the behaviour corrected itself. Not a big deal; I can absolutely work with the behaviour I was experiencing.

The final issue is that while carrying out these tests I got dozens of "ardour: get_connections: Invalid Port" error messages. I only had 2 midi tracks and it didn't seem to matter how many times I disabled and then re-enabled the port I was using. Even with MIDI input disabled on both tracks just switching focus between the tracks was enough to throw the error. Whatever the cause of the error message is it didn't seem to affect the behaviour in the session, but my mechanic has warned me before about the dangers of ignoring flashing red lights. If there's no obvious explanation, and if you'd prefer, I'm happy to report this as a separate issue.
(0027372)
paul   
2023-02-12 18:08   
1. the first issue is entirely by design. Years ago, Ardour used to have two kinds of snap - absolute snap where things could only be placed "on the grid", and "elastic snap" (I think it had a better name), which is the behavior you see. Somewhere around v5, we dropped absolute snap everywhere.

2. If you could possibly try to create either a small test session or a precise recipe to replicate this, it would be much appreciated.

3. I'll check into this. I would imagine you have "MIDI input follows selection" enabled?
(0027376)
Windsurfer152   
2023-02-12 21:52   
Please bear with me; this is a little complicated.

I have 2 midi tracks. In one the cc lane uses linear mode while the other uses discrete. In both cases the cc data was created before programming tempo changes. In both cases the cc events are placed at regular intervals.

The region that involves the discrete lane is duplicated. Initially the regions overlapped so I edited the start point and first cc event of each region to ensure they would play. That's why the values at the start of each region are slightly different.

With no tempo changes everything played as expected. See first screenshot.

After adding tempo changes it appears that both discrete and linear events have NOT moved to take account of the tempo changes. So they no longer align with the grid in the same way as previously. I didn't screenshot this.

When I zoom in and then back out the linear events appear to have corrected themselves. The discrete events still appear out of alignment. See second screenshot.

When I play the session the slider for the linear events does not move as the display would suggest it should, and the audio confirms this. This was partly expected based on previous experience.

I've attached session files, both before and after tempo changes.

Having saved the relevant information I thought I'd try manually correcting the data. When the vertical position of the linear data points (showing in the correct place but playing late) was edited even minutely it seemed to reset the horizontal position and it played back accurately. Again this confirms what I mentioned in my previous post.

But the discrete data was less co-operative. With snap disabled I could move the points to where they should be and playback was in line with this. But with snap enabled I was unable to drag them to their regular positions - snap was offset in the same way as was the case before your fix was implemented.

So the issue is hugely diminished from what it was, but there is clearly still something a bit buggy going on.

An extra positive is that the error messages I detailed in my previous post did not appear this time. I don't think I changed any settings but happy to park that particular issue for now unless other users report the same behaviour.
(0027378)
paul   
2023-02-14 03:34   
so, not a lot of mystery but still a problem to be solved with UI/UX.

the line(s) do not update because these regions have their length & position defined in samples (despite being MIDI). as a result, we do not notify of any changes to the length/position when the tempo map changes. this behavior is correct and as intended.

what is not correct, and what is not clear how to correct, is that it was a trivial matter for you to end up with a MIDI region with these settings, and that's not intended (certainly, it is not intended to be easy to do, let alone a side-effect).
(0027379)
Windsurfer152   
2023-02-14 08:33   
Thank you for the information. I don't completely understand and I'm not clear on why discrete and linear modes behave differently in this respect.

However I have had situations when recording a piano track to midi where, if I increase the tempo after recording, some of the damper pedal changes I'd recorded instinctively are a bit out of whack on playback. I guess this might explain that behaviour.

In any case the big lesson from this for me (other than learning that taking the time to report bugs properly is time well spent) is in terms of workflow - the thing with which I struggle most in Ardour. So recording note data then finalising tempo changes then adding cc data would seem to be a good rule of thumb.
(0027380)
paul   
2023-02-14 15:52   
Since ardour 7, we have two different time "domains": positions and lengths can be in either samples or beats. For the foreseeable future, we expect pretty much all things MIDI to have position and length measured in beats. However, there are clearly some operations that users can carry out (on purpose, or by accident) which changes this so that, for example, a MIDI region ends up with a position and/or length defined in samples.

Your point about the difference between the discreet/interpolated cases is excellent though, and I should go back and make sure that this is explained (at least to me).
(0027418)
Windsurfer152   
2023-03-02 16:09   
Having updated to 7.3 I've unfortunately had another instance of cc messages being ignored or moved.

I was using the Expression controller to emulate a natural diminuendo at the end of a note, so that's the lane to look at in the screenshots. The slider in the lane accurately represents what actually happens.

Everything starts fine but when we get to the 4th "dip" in b 13 and 14 the cc data is just ignored. Then the 5th drop in b16 doesn't happen until b18.

I can't correct it. Unlike previous instances redrawing or moving points doesn't fix the issue.

The session was created from a template. I thought the template may have been created using a previous version so I built it again from scratch and just imported the midi data. Same problem, although that also threw up the slightly odd situation of the default mode for Expression cc11 being discrete rather than linear.

Screenshots and session file attached.
(0027419)
Windsurfer152   
2023-03-02 16:11   
(0027420)
Windsurfer152   
2023-03-02 16:15   
(0027421)
paul   
2023-03-02 17:04   
No sign of the session archive yet ....
(0027422)
Windsurfer152   
2023-03-02 17:17   
I didn't realise the upload limit was 10 items per hour, or per 3600 seconds as Mantis calls it! I set my timer so hopefully here we go...
(0027424)
Windsurfer152   
2023-03-03 19:43   
I don't know if this helps; that session crashed on me repeatedly when I tried to change the initial tempo of 120 to the 104 I wanted.

Then today, working on a different session, everything was working ok in the opening bars at 100 bpm. I then changed to 88 bpm some 20 bars in. I was subsequently unable to position any cc data events with any accuracy regardless of whether snap as on or off.

So it does appear that the further you get from 120 bpm and/or the further into the piece you get the more erratic the behaviour.
(0027425)
Windsurfer152   
2023-03-04 06:03   
I've uploaded the archive of the session I mention above. I used the archive session dialogue for the first time and can't quite believe the result is only 26kB. I've also included a standard archive. Can you please confirm they both contain all relevant data?

On revisiting the session I can see my description was not accurate.; 72bpm rather than 88.

While I presume it is related this problem is actually distinct as it relates to adding new cc data. So the timeline is; create tempo change > create new region after tempo change > add new cc data.

Bar 22 is where the problems start. "Attack," "Offset" and "Expression" lanes in the Clarinet track. Playback is consistent with what is in the lanes. The issue is that the points are not where I placed them.

A point drawn in b22 is placed more than a beat later. By the time you get to entering data in b27 it is placed more than 2 BARS later. This is true whether snap is on or off and whether in Linear or Discrete mode.

It is possible to drag the point to the correct position and snap does work if it is enabled. And, unlike the previous example, data is not skipped on playback. But it's not a sustainable workflow and, so far as I know, there is no list editor or similar I can use as an alternative.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9243 [ardour] bugs trivial always 2023-02-16 15:51 2023-02-28 21:05
Reporter: bsj Platform: Apple Macintosh  
Assigned To: x42 OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Blurry text in overall program ever since the opaque region feature was introduced
Description: Blurry text in ardour and mixbus

Tags: Blurry text
Steps To Reproduce: Just using the program
Additional Information: Seems like the resolution is lower in the text and icons and mixer features.
System Description
Attached Files:
Notes
(0027392)
x42   
2023-02-17 14:58   
Fixed in Ardour 7.3-18-gcba8fd090f
(0027393)
bsj   
2023-02-17 20:28   
is this available in the nightlies, v7.3-16?
(0027395)
x42   
2023-02-18 18:13   
no. v7.3.16 is (was) too old. you need .18 or later.
(0027416)
bsj   
2023-02-26 21:38   
Was this a simple fix, not sure if mixbus was able to fix it on their end, they did mention not knowing why it was using 2 different fonts but then said they are planning on using bigger fonts in the next release of mixbus.

When will the fix be available in ardour website for everyone.
(0027417)
x42   
2023-02-28 21:05   
> When will the fix be available in ardour website for everyone.

When v7.4 is released.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9262 [ardour] bugs crash always 2023-02-26 16:09 2023-02-26 16:09
Reporter: Werner Back Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour panning automation crashes Mixbus
Description: I think this is not very important, but anyway, crashes should never happen:
I tried to load an older Ardour project into Mixbus, but Mixbus crashed immediately. It took me a pretty amount of time to figure out, that a track which had pan automation on it was the cause. The crash (segfault) seems to happen if there is a postfade send involved.
I was way into the mixing process because I had it working by deleting the bus which the postfade send was sending to (I thought the groups were the reason). When I set up a new post fade send the segfault appeared again.
Tags: 8.2, close, crash, MIxbus, open
Steps To Reproduce: Create an Ardour project with one audio track and one bus (aux). Write some pan automation on the audio track (no real audio necessary). Create a post fade send to the bus. Save.
Open Mixbus and try to load the Ardour project -> Segfault.
Project appended.
Additional Information:
System Description
Attached Files: Test Pan Crash.zip (25,560 bytes) 2023-02-26 16:09
https://tracker.ardour.org/file_download.php?file_id=4408&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9261 [ardour] bugs minor always 2023-02-26 13:34 2023-02-26 13:35
Reporter: jslain Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Count-in at a tempo change bar plays the previous tempo
Description: I noticed that in previous versions as well.
I you place the playhead exactly at a bar that has a tempo change, if you enable the count-in before recording, the metronome does not play the new tempo at that bar, but plays the one that were just before that bar.

I don't usually use that feature, I set punch regions, put the playhead before and start playing the previous riff, so i can feel the tempo.
It's not a solution when the tempo changes abruptly.

Everytime it happens, i'm like :
- "It'ld be nice if the metronome could play the tempo just before the recording starts. I'll go search the internet."
- "Oh yeah, that feature exists!"
[trying it out]
- "Ah, and now I remember it doesn't work in my specific case." (which is the only case it'ld be really handy)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 2023-02-26 08_32_48-Window.png (38,705 bytes) 2023-02-26 13:34
https://tracker.ardour.org/file_download.php?file_id=4407&type=bug
png
Notes
(0027414)
jslain   
2023-02-26 13:35   
In the screenshot, when i start recording at bar 62 with count-in, the tempo played by the count-in metronome is 78, not 69.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9260 [ardour] features feature always 2023-02-26 09:41 2023-02-26 09:42
Reporter: AnyThreeWords Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: No horizontal scrol in windows
Description: I have a mouse that has horizontal scrolling capabilities that do not function on windows I've tried both windows 10 and 11 on 2 different machines. Horizontal scroll does work in Ardour when on Ubuntu.

Horizontal scroll does work with other programs on on windows including: Audacity, Reason Studios, Gimp and Inkscape.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9049 [ardour] bugs major always 2022-10-29 16:27 2023-02-25 23:25
Reporter: gonsolo Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when trying to jump and play
Description: A session upgraded to Ardour 7 seems to be seriously confused.
When playing and trying to jump after location marker 8 Ardour crashes.

Stack trace:

```
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
0000001 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff343bc46 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
0000004 0x00007ffff34227fc in __GI_abort () at ./stdlib/abort.c:79
0000005 0x00007ffff58a2d27 in Temporal::TempoMap::get_grid(std::__cxx11::list<Temporal::TempoMapPoint, std::allocator<Temporal::TempoMapPoint> >&, long, long, unsigned int) const
     (this=0x55555793c700, ret=empty std::__cxx11::list, start=282401617680, end=282401617680, bar_mod=0) at ../libs/temporal/tempo.cc:1916
#6 0x00007ffff774b722 in ARDOUR::LV2Plugin::connect_and_run(ARDOUR::BufferSet&, long, long, double, ARDOUR::ChanMapping const&, ARDOUR::ChanMapping const&, unsigned int, long)
     (this=0x55556d9d8e40, bufs=..., start=48027486, end=48027486, speed=0, in_map=..., out_map=..., nframes=1024, offset=0) at ../libs/ardour/lv2_plugin.cc:2668
#7 0x00007ffff73d0e57 in ARDOUR::PluginInsert::connect_and_run(ARDOUR::BufferSet&, long, long, double, unsigned int, long, bool)
     (this=0x55556d9d3d60, bufs=..., start=48027486, end=48027486, speed=0, nframes=1024, offset=0, with_auto=true) at ../libs/ardour/plugin_insert.cc:1107
0000008 0x00007ffff73d2785 in ARDOUR::PluginInsert::run(ARDOUR::BufferSet&, long, long, double, unsigned int, bool)
    (this=0x55556d9d3d60, bufs=..., start_sample=48027486, end_sample=48027486, speed=0, nframes=1024) at ../libs/ardour/plugin_insert.cc:1329
0000009 0x00007ffff74c62a6 in ARDOUR::Route::process_output_buffers(ARDOUR::BufferSet&, long, long, unsigned int, bool, bool)
     (this=0x55556c1bd8d0, bufs=..., start_sample=48027486, end_sample=48027486, nframes=1024, gain_automation_ok=false, run_disk_reader=false) at ../libs/ardour/route.cc:543
0000010 0x00007ffff74c7441 in ARDOUR::Route::run_route(long, long, unsigned int, bool, bool)
    (this=0x55556c1bd8d0, start_sample=48026446, end_sample=48026446, nframes=1024, gain_automation_ok=false, run_disk_reader=false) at ../libs/ardour/route.cc:734
0000011 0x00007ffff74dcd49 in ARDOUR::Route::no_roll_unlocked(unsigned int, long, long, bool)
    (this=0x55556c1bd8d0, nframes=1024, start_sample=48026446, end_sample=48026446, session_state_changing=false) at ../libs/ardour/route.cc:4054
0000012 0x00007ffff731ce15 in ARDOUR::MidiTrack::no_roll_unlocked(unsigned int, long, long, bool)
     (this=0x55556c1bd8d0, nframes=1024, start_sample=48026446, end_sample=48026446, state_changing=false) at ../libs/ardour/midi_track.cc:389
0000013 0x00007ffff74dcbfa in ARDOUR::Route::no_roll(unsigned int, long, long, bool)
    (this=0x55556c1bd8d0, nframes=1024, start_sample=48026446, end_sample=48026446, session_state_changing=false) at ../libs/ardour/route.cc:4024
0000014 0x00007ffff6f3a24e in ARDOUR::Graph::process_one_route(ARDOUR::Route*) (this=0x555558223800, route=0x55556c1bd8d0) at ../libs/ardour/graph.cc:547
#15 0x00007ffff74c7262 in ARDOUR::Route::process() (this=0x55556c1bd8d0) at ../libs/ardour/route.cc:705
0000016 0x00007ffff6f45b45 in ARDOUR::GraphNode::run(ARDOUR::GraphChain const*) (this=0x55556c1bdd20, chain=0x7fffb40826d0) at ../libs/ardour/graphnode.cc:65
#17 0x00007ffff6f38853 in ARDOUR::Graph::run_one() (this=0x555558223800) at ../libs/ardour/graph.cc:346
0000018 0x00007ffff6f38c11 in ARDOUR::Graph::helper_thread() (this=0x555558223800) at ../libs/ardour/graph.cc:374
0000019 0x00007ffff6f44bb1 in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fffa1ffa958, p=0x555558223800) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000020 0x00007ffff6f4413d in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fffa1ffa968, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000021 0x00007ffff6f43090 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fffa1ffa958)
    at /usr/include/boost/bind/bind.hpp:1294
0000022 0x00007ffff6f41601 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000023 0x0000555555cb32d3 in boost::function0<void>::operator()() const (this=0x7fffa1ffa950) at /usr/include/boost/function/function_template.hpp:763
#24 0x00007fffd7fba431 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x555558394410) at ../libs/backends/jack/jack_audiobackend.cc:955
0000025 0x00007ffff3490402 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
0000026 0x00007ffff351f590 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
```
Tags:
Steps To Reproduce: 1. Open the session.
2. Play.
3. Jump via mouse to location marker 8 or a bit later.
4. Crash.
Additional Information: Archive (3MB which is bigger than the allowed 2MB):
https://drive.google.com/file/d/1qI6lSKW8yoTqECEjxAuxoKdlyNQomG0k/view?usp=share_link
System Description
Attached Files: wrong.png (20,368 bytes) 2022-10-30 16:40
https://tracker.ardour.org/file_download.php?file_id=4262&type=bug
png

debug_output.gz (79,887 bytes) 2022-10-31 17:47
https://tracker.ardour.org/file_download.php?file_id=4265&type=bug
debug_output-2.gz (2,826 bytes) 2022-10-31 18:50
https://tracker.ardour.org/file_download.php?file_id=4266&type=bug
bars.png (28,829 bytes) 2022-11-07 10:00
https://tracker.ardour.org/file_download.php?file_id=4280&type=bug
png
Notes
(0026752)
paul   
2022-10-29 17:05   
There are at least 3 other bug reports withthe same backtrace.

Thanks for the session archive, should be useful.
(0026753)
gonsolo   
2022-10-29 17:39   
I find https://tracker.ardour.org/view.php?id=9027 which is marked fixed with 7.0-116-g489c9ace9f which it isn't (I believe).
A search for "TempoMap::get_grid" doesn't reveal any other reports.

And sorry for being a PITA. :)
(0026754)
paul   
2022-10-29 17:43   
Not a pain at all. Please keep reports coming.
(0026756)
gonsolo   
2022-10-30 10:48   
I think the culprit is TempoMetric::bbt_at at tempo.cc:622 because it is confused of the 3/4 in the middle of a bar.
I managed to manually get it to work by moving the 3/4 to the beginning of a bar.

gonsolo start0: 47001057, end: 47001057
 start0 superclock: 276366215160
 end superclock: 276366215160
  sc: 276366215160
  dg.get_beats(): 10
  _meter->note_value(): 4
  note_value_count: 10
  ticks: 1077
  _meter->bbt(): 290|1|0
  bbt_offset: 0|10|1077
  add: 293|2|1077
  bbt: 293|2|1077
  new_start: 276441352257
  sc: 276366215160
  dg.get_beats(): 10
  _meter->note_value(): 4
  note_value_count: 10
  ticks: 1077
  _meter->bbt(): 290|1|0
  bbt_offset: 0|10|1077
  add: 293|2|1077
  sc: 276366215160
  dg.get_beats(): 10
  _meter->note_value(): 4
  note_value_count: 10
  ticks: 1077
  _meter->bbt(): 290|1|0
  bbt_offset: 0|10|1077
  add: 293|2|1077
gonsolo start0: 47001057, end: 47001057
 start0 superclock: 276366215160
 end superclock: 276366215160
  sc: 276366215160
  dg.get_beats(): 10
  _meter->note_value(): 4
  note_value_count: 10
  ticks: 1077
  _meter->bbt(): 290|1|0
  bbt_offset: 0|10|1077
  add: 293|2|1077
  bbt: 293|2|1077
  new_start: 276441352257
  sc: 276366215160
  dg.get_beats(): 10
  _meter->note_value(): 4
  note_value_count: 10
  ticks: 1077
  _meter->bbt(): 290|1|0
  bbt_offset: 0|10|1077
  add: 293|2|1077
(0026757)
paul   
2022-10-30 13:34   
hmm, meter (time signature) changes are supposed to be allowed on bars only. This is part of the conceptual changes that make full compatibility with 6.x hard. Importing a 6.x session that allowed those changes off-bar would definitely cause issues.
(0026758)
paul   
2022-10-30 14:49   
(Last edited: 2022-10-30 14:51)
that said, the .ardour file you attached doesn't seem to show any meter changes off-bar:

      <Meter note-value="4" divisions-per-bar="4" sclock="0" quarters="0:0" bbt="1|1|0"/>
      <Meter note-value="4" divisions-per-bar="3" sclock="112409227592" quarters="400:0" bbt="101|1|0"/>
      <Meter note-value="4" divisions-per-bar="4" sclock="132422609396" quarters="478:0" bbt="127|1|0"/>
      <Meter note-value="4" divisions-per-bar="4" sclock="237611970470" quarters="986:0" bbt="254|1|0"/>
      <Meter note-value="4" divisions-per-bar="3" sclock="274559752262" quarters="1130:0" bbt="290|1|0"/>
      <Meter note-value="4" divisions-per-bar="4" sclock="300066321800" quarters="1154:0" bbt="305|1|0"/>
      <Meter note-value="4" divisions-per-bar="4" sclock="323415267238" quarters="1266:0" bbt="333|1|0"/>

when loading here, the 3/4 meter starts at bar 101

Is that not the case for you?
(0026761)
paul   
2022-10-30 16:23   
OK, I understand the bug now. But it will take a day of putting up tiles in my bathroom to come up with a solution.

The problem is that when we are computing the grid near a sample position, we first determine meter and tempo in effect at that point. Then we compute the number of quarter notes since the tempo change, and then use that to compute the delta in quarter notes between the meter change and the given position.

Problem is, if the meter is before the tempo, then for the interval from the meter to the tempo, the duration of a quarter note is defined by the *previous tempo*, not the one in effect at the time we're interested in. This ends up leading to the "we've gone backwards" error.

To the tiles!
(0026762)
paul   
2022-10-30 16:25   
BTW, I did try just using the *later* of the tempo or meter change for the computation, which initially looked like a simple fix. But this just breaks other stuff.
(0026763)
gonsolo   
2022-10-30 16:40   
```
<Meter note-value="4" divisions-per-bar="3" sclock="112409227592" quarters="400:0" bbt="101|1|0"/>
```
If you're saying that the last number in "bbt="101|1|0" has to be always zero, then yes, my ardour file is sane.
But after opening the meter change is still off-bar as can be seen in the picture.

I see that you now have an understanding of the bug and I expect the fix just after the tiles. (Kidding, as I said, I manually fixed the session, but it's still nice to hear that I can help to make Ardour rock solid again.)
(0026764)
gonsolo   
2022-10-30 17:13   
Since it is related (or the same bug): Dragging the tempo marker at bar 300 around is also crashing.
Stack trace:

#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
0000001 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff343bc46 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
0000004 0x00007ffff34227fc in __GI_abort () at ./stdlib/abort.c:79
0000005 0x00007ffff342271b in __assert_fail_base
    (fmt=0x7fffef6039b5 "%s%s%s:%u: %s%sZusicherung »%s« nicht erfüllt.\n%n", assertion=0x7ffff58d7f1e "qn >= _quarters", file=0x7ffff58d7d47 "../libs/temporal/tempo.cc", line=471, function=<optimized out>) at ./assert/assert.c:92
#6 0x00007ffff3433596 in __GI___assert_fail
    (assertion=0x7ffff58d7f1e "qn >= _quarters", file=0x7ffff58d7d47 "../libs/temporal/tempo.cc", line=471, function=0x7ffff58d7eb0 "Temporal::superclock_t Temporal::TempoPoint::superclock_at(const Temporal::Beats&) const") at ./assert/assert.c:101
#7 0x00007ffff58936cd in Temporal::TempoPoint::superclock_at(Temporal::Beats const&) const (this=0x5555864279f0, qn=...)
    at ../libs/temporal/tempo.cc:471
0000008 0x00007ffff58b7551 in Temporal::TempoMetric::superclock_at(Temporal::Beats const&) const (this=0x7fffffffafa0, qn=...)
    at ../libs/temporal/temporal/tempo.h:480
0000009 0x00007ffff58a3978 in Temporal::TempoMap::get_grid(std::__cxx11::list<Temporal::TempoMapPoint, std::allocator<Temporal::TempoMapPoint> >&, long, long, unsigned int) const (this=0x5555844a6230, ret=std::__cxx11::list = {...}, start=282572606127, end=286108540200, bar_mod=0)
    at ../libs/temporal/tempo.cc:2001
0000010 0x00005555560b5ea2 in Editor::compute_current_bbt_points(std::__cxx11::list<Temporal::TempoMapPoint, std::allocator<Temporal::TempoMapPoint> >&, long, long) (this=0x555558391250, grid=std::__cxx11::list = {...}, leftmost=46659834, rightmost=48657915) at ../gtk2_ardour/editor_tempodisplay.cc:413
0000011 0x0000555556083994 in Editor::metric_get_bbt(std::vector<ArdourCanvas::Ruler::Mark, std::allocator<ArdourCanvas::Ruler::Mark> >&, long, long, int) (this=0x555558391250, marks=std::vector of length 0, capacity 256, lower=46659834, upper=48657915) at ../gtk2_ardour/editor_rulers.cc:1172
0000012 0x00005555560b62af in Editor::maybe_draw_grid_lines() (this=0x555558391250) at ../gtk2_ardour/editor_tempodisplay.cc:462
0000013 0x00005555560b8ab4 in Editor::mid_tempo_change(Editor::MidTempoChanges) (this=0x555558391250, what_changed=Editor::TempoChanged)
    at ../gtk2_ardour/editor_tempodisplay.cc:801
0000014 0x0000555555fa35fb in TempoMarkerDrag::motion(_GdkEvent*, bool) (this=0x5555876af7f0, event=0x7fffffffbc30, first_move=false)
    at ../gtk2_ardour/editor_drag.cc:3320
#15 0x0000555555f90a86 in Drag::motion_handler(_GdkEvent*, bool) (this=0x5555876af7f0, event=0x7fffffffbc30, from_autoscroll=false)
    at ../gtk2_ardour/editor_drag.cc:522
0000016 0x0000555555f8f7fa in DragManager::motion_handler(_GdkEvent*, bool) (this=0x5555583b6650, e=0x7fffffffbc30, from_autoscroll=false)
    at ../gtk2_ardour/editor_drag.cc:231
#17 0x000055555600db0d in Editor::motion_handler(ArdourCanvas::Item*, _GdkEvent*, bool)
    (this=0x555558391250, event=0x7fffffffbc30, from_autoscroll=false) at ../gtk2_ardour/editor_mouse.cc:2300
0000018 0x0000555555f86b57 in Editor::typed_event(ArdourCanvas::Item*, _GdkEvent*, ItemType)
     (this=0x555558391250, item=0x5555776cbbf0, event=0x7fffffffbc30, type=TempoMarkerItem) at ../gtk2_ardour/editor_canvas_events.cc:223
0000019 0x0000555555f89793 in Editor::canvas_tempo_marker_event(_GdkEvent*, ArdourCanvas::Item*, TempoMarker*)
(0026765)
paul   
2022-10-30 18:01   
At present, if you see ::get_grid() in the stacktrace, then more useful output is obtainable via running ardour from the cmdline with -D grid,temporalmap
(0026771)
paul   
2022-10-31 01:36   
should be fixed in git master, 9c2c08973d894

was easier than tiling!
(0026782)
gonsolo   
2022-10-31 17:47   
Not yet:

#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
0000001 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff343bc46 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
0000004 0x00007ffff34227fc in __GI_abort () at ./stdlib/abort.c:79
0000005 0x00007ffff342271b in __assert_fail_base
    (fmt=0x7fffef6029b5 "%s%s%s:%u: %s%sZusicherung »%s« nicht erfüllt.\n%n", assertion=0x7ffff58d7f1e "qn >= _quarters", file=0x7ffff58d7d47 "../libs/temporal/tempo.cc", line=471, function=<optimized out>) at ./assert/assert.c:92
#6 0x00007ffff3433596 in __GI___assert_fail
    (assertion=0x7ffff58d7f1e "qn >= _quarters", file=0x7ffff58d7d47 "../libs/temporal/tempo.cc", line=471, function=0x7ffff58d7eb0 "Temporal::superclock_t Temporal::TempoPoint::superclock_at(const Temporal::Beats&) const") at ./assert/assert.c:101
#7 0x00007ffff589272d in Temporal::TempoPoint::superclock_at(Temporal::Beats const&) const (this=0x555577625950, qn=...)
    at ../libs/temporal/tempo.cc:471
0000008 0x00007ffff5893de8 in Temporal::TempoMetric::superclock_at(Temporal::BBT_Time const&) const (this=0x7fffffffb090, bbt=...)
    at ../libs/temporal/tempo.cc:667
0000009 0x00007ffff58a2be3 in Temporal::TempoMap::get_grid(std::__cxx11::list<Temporal::TempoMapPoint, std::allocator<Temporal::TempoMapPoint> >&, long, long, unsigned int) const (this=0x555588116670, ret=std::__cxx11::list = {...}, start=290064432769, end=345781174612, bar_mod=1)
    at ../libs/temporal/tempo.cc:2027
0000010 0x00007ffff58a57fe in Temporal::TempoMap::count_bars(Temporal::Beats const&, Temporal::Beats const&) const
    (this=0x555588116670, start=..., end=...) at ../libs/temporal/tempo.cc:2182
0000011 0x0000555556083303 in Editor::compute_bbt_ruler_scale(long, long) (this=0x5555583ad640, lower=43142526, upper=58760601)
    at ../gtk2_ardour/editor_rulers.cc:1078
0000012 0x0000555556081b99 in Editor::update_tempo_based_rulers() (this=0x5555583ad640) at ../gtk2_ardour/editor_rulers.cc:754
0000013 0x00005555560b8aa5 in Editor::mid_tempo_change(Editor::MidTempoChanges) (this=0x5555583ad640, what_changed=Editor::TempoChanged)
    at ../gtk2_ardour/editor_tempodisplay.cc:800
0000014 0x0000555555fa351f in TempoMarkerDrag::motion(_GdkEvent*, bool) (this=0x555565786e40, event=0x7fffffffbc10, first_move=true)
    at ../gtk2_ardour/editor_drag.cc:3320
#15 0x0000555555f909aa in Drag::motion_handler(_GdkEvent*, bool) (this=0x555565786e40, event=0x7fffffffbc10, from_autoscroll=false)
    at ../gtk2_ardour/editor_drag.cc:522
0000016 0x0000555555f8f71e in DragManager::motion_handler(_GdkEvent*, bool) (this=0x5555583d1720, e=0x7fffffffbc10, from_autoscroll=false)
    at ../gtk2_ardour/editor_drag.cc:231
#17 0x000055555600dab1 in Editor::motion_handler(ArdourCanvas::Item*, _GdkEvent*, bool)
    (this=0x5555583ad640, event=0x7fffffffbc10, from_autoscroll=false) at ../gtk2_ardour/editor_mouse.cc:2300
0000018 0x0000555555f86a7b in Editor::typed_event(ArdourCanvas::Item*, _GdkEvent*, ItemType)
    (this=0x5555583ad640, item=0x5555777ac030, event=0x7fffffffbc10, type=TempoMarkerItem) at ../gtk2_ardour/editor_canvas_events.cc:223
0000019 0x0000555555f896b7 in Editor::canvas_tempo_marker_event(_GdkEvent*, ArdourCanvas::Item*, TempoMarker*)
    (this=0x5555583ad640, event=0x7fffffffbc10, item=0x5555777ac030, marker=0x5555777ab460) at ../gtk2_ardour/editor_canvas_events.cc:1095

I attached the output of "-D grid,temporalmap"

One tile down.
(0026783)
paul   
2022-10-31 18:09   
Could you repeat that with Edit > Preferences > Performance > processor usage set to 1 processor ? The debug output is unreadable when multithreaded ... thanks

Alternatively, let me know the steps to make this happen (your existing instructions no longer crash for me)
(0026787)
gonsolo   
2022-10-31 18:46   
Output attached (with set to 1 processor).

Session: https://drive.google.com/file/d/1cUZyxJnVvgjXUO5DhSBd15JnknysQJK2/view?usp=sharing

1. Open session
2. Drag the tempo marker at bar 306 around.
(0026788)
gonsolo   
2022-10-31 18:50   
Debug output with setting processors to 1, restarting, and making sure that processor is set to 1.
(0026790)
paul   
2022-10-31 19:07   
and this was generated/triggered how?
(0026794)
gonsolo   
2022-10-31 20:47   
Open the session and drag the tempo marker around.
(0026862)
gonsolo   
2022-11-07 10:00   
Also note how Ardour doesn't respect the 4/4 change at bar 298.
Also the time change is in the middle of bar 306 which should not be the case.
That is still the session above.
(0026863)
gonsolo   
2022-11-07 10:01   
https://tracker.ardour.org/view.php?id=9067 seems to be related as it also crashes at tempo.cc:471.
(0026929)
paul   
2022-11-22 01:26   
archive no longer readable. would like to check if f5887b978d4 fixes this issue
(0026931)
gonsolo   
2022-11-22 07:21   
The session in https://tracker.ardour.org/view.php?id=9049#c26787 is essentially the same (with processor set to 1 for debugging).

I opened the session and dragged said marker around for half an hour now (slightly exaggerating) and couldn't get Ardour to crash so it seems to be fixed.
(0027412)
gonsolo   
2023-02-25 22:39   
Please close this bug report. It's fixed.
(0027413)
paul   
2023-02-25 23:25   
see notes

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8750 [ardour] bugs minor always 2021-06-19 17:00 2023-02-23 20:20
Reporter: ccr5-delta32 Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 10  
Status: feedback Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Transport malfunction when synced to continuous external midi clock
Description: I am experiencing a bug where Ardour will not run properly when synced to external midi clock. Although I am reporting for Win10, the same happens in the Linux(Debian) version.

In my case the incoming midi clock signal is continuous rather than only on after a midi start until a midi stop, something I require for my boxes with internal sequencers. The clock source is an E-RM MIDIclock+ through an simple midi - USB converter, but not a cheap one with all kinds of design compromises. I have made the necessary "MIDI Connections" to route the incoming midi clock.

When Ardour is not running, as soon as I switch Ardour to external sync using the button below the transport buttons Ardour immediately starts to run from some seemingly arbitrary point in the song. Note that this does not require a midi start. I did set up the Transport Master "Active Commands" to accept start/stop. In fact, Ardour does not react to midi start/stop/reset commands at all when synced to my external midi clock.

In Edit>Preferences>Transport>Chase>Transport Masters I notice that the "Sync Position + Delta" is continuously increasing regardless of whether Ardour is running. This value is determining where Ardour will start playback when external sync is activated.

Now, if I press start on the midiclock+ followed by stop, while Ardour was running due to the above, Ardour does not stop. But the "Sync Position + Delta" in the "Transport Masters" resets and starts incrementing from 0 again.

I am not sure if the following is part of the problem because it seems sensible. If the song position pointer is stopped at a timepoint in the track that is greater than the "Sync Position + Delta", Ardour does not immediately start playback as soon as external sync is activated. But when "Sync Position + Delta" catches up to the song position pointer it Ardour will start to run. But in any case midi start and stop commands do nothing.

Only in Linux using Jack and a2jmidid the above behavior is associated with glitches such as tooltip balloons flickering rather than being displayed properly. I have also had crashes to desktop in Linux while experiencing the issue described above but cannot provide more details now.
Tags:
Steps To Reproduce: (1) Connect an external midi clock source that sends continuous midi clock data.
(2) Make the necessary connections in "MIDI Connections"
(3) Setup or verify "Edit>Preferences>Transport>Chase>Transport" to select 'MIDI Clock' from the respective source, and select "Accept start/stop commands" and "Accept locate commands" in "Active Commands".
(4) Note how "Sync Position + Delta" in "Edit>Preferences>Transport>Chase>Transport" is continuously increasing according to the continuous incoming midi clock.
(5) Move the song position pointer to the start of the session.
(6) Select 'M-Clk' by pressing the 'Int.' button near the transport buttons.
(7) Watch Ardour immediately start playback from whatever the value of "Sync Position + Delta" in "Edit>Preferences>Transport>Chase>Transport Masters" was.
(8) Press start/stop/reset on the midi master
(9) See Ardour do nothing while other slaves do start/stop/reset. But the "Sync Position + Delta" in "Edit>Preferences>Transport>Chase>Transport Masters" does reset upon receiving midi stop.
Additional Information:
System Description
Attached Files: 2023-02-20-175139_2940x1649_scrot.png (354,539 bytes) 2023-02-20 16:53
https://tracker.ardour.org/file_download.php?file_id=4401&type=bug
2023-02-20-183318_1192x110_scrot.png (17,521 bytes) 2023-02-20 17:33
https://tracker.ardour.org/file_download.php?file_id=4402&type=bug
png

ar-01.mp4 (284,574 bytes) 2023-02-20 17:50
https://tracker.ardour.org/file_download.php?file_id=4403&type=bug
Notes
(0027394)
TatriX   
2023-02-18 09:03   
I have a similar issue with Squarep Pyramid ;(
(0027398)
x42   
2023-02-20 12:53   
This should be fixed since 7.3-23-g78c89fcbae. Except I no longer have a hardware MIDI Clock source so I cannot test it myself.

It would be great if you could check with a https://nightly.ardour.org build of Ardour 7.3.23 or later.
(0027399)
TatriX   
2023-02-20 14:00   
Lovely, thank you! I'll do the check sometime soon.
(0027400)
TatriX   
2023-02-20 16:53   
I've compiled 78c89fcbae
It doesn't crash, but behaves very weirdly.
After Pyramid sends "START" Ardour does nothing for a few seconds, then transport starts going, and then it get stuck. It's a bit hard to explain.
Are you still on irc or there is something like discord?
(0027401)
TatriX   
2023-02-20 17:33   
(0027402)
TatriX   
2023-02-20 17:50   

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9258 [ardour] features minor always 2023-02-23 02:04 2023-02-23 02:04
Reporter: Arkforest Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Velocity Input Problem
Description: Hi Paul,

There seems to be a bug where every time I create a new MIDI clip to input MIDI notes and change the velocity of the first note (I usually change it to 96 or 127), the second note I input always defaults to the standard 64. This does not happen with the third or subsequent notes inputted into the same MIDI clip. I suspect there either may be a problem with the second note adapting its velocity to the existing first note or that the first note may not have been input properly for the second note to be aware of the first note's velocity. I am aware of the new auto length, channel and velocity parameters available in the toolbar above the editor session. I thought this might be something worth reporting to potentially save a little bit of time down the road.

Cheers in advance,

Arkforest
Tags: Midi, velocity
Steps To Reproduce: 1. Create new MIDI clip
2. Input any one note of any length at any position within MIDI clip
3. Change velocity of initial note to anything other than 64
4. Input a second note anywhere in the MIDI clip
5. The second note will have a velocity of 64
6. Input a third and possibly more subsequent notes
7. These notes will adapt to the velocities of the existing notes in the MIDI clip that the second one failed to do.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9257 [ardour] features tweak always 2023-02-22 22:19 2023-02-22 22:19
Reporter: Kinghand Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Do the same operation to selected tracks
Description: For example. I want mute or solo some selected tracks temporary. But I don't want to group them. Is there any way I can achieve this?

Thanks
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8562 [ardour] bugs minor always 2021-02-04 00:26 2023-02-22 16:13
Reporter: DBA Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI driven knob (VST plugin) moves the displayed value of the knob but not its value
Description: MIDI driven knob (VST plugin) moves the displayed value of the knob but not its value in the plugin while the SAME knob moved with the mouse cursor is actually changing value in the plugin.

Also see https://discourse.ardour.org/t/midi-control-knob-and-switch-of-a-vst-plugin-works-with-mouse-but-when-driven-by-midi-displays-the-action-without-doing-it/105445
Tags: 6.5, MIDI control, plugin, VST3, Windows
Steps To Reproduce: - Setup MIDI, and don't forget to change this fXXXXg "Smooth" parameter to 127 as it should be by default (this used 3 hours of my life)
- Install Helix Native 3.01 VST3 (maybe it works with other VST pluging)
- make a track for your guitar and put an instance of the plugin in the sound path
- in Helix Native, put a Wah and assign "knob1" to the position parameter so knob 1 will control the effect.
- display knob of the VST plugin
- execute MIDI learn and assign it to an expression pedal (in my case Roland FC-200 via a Berhinger UMC 1820)

So here the fun begin.
- move the knob value with the mouse cursor -> the display of the knob (the bar) moves and the sound of the guitar changes
- move the knob value with the expression pedal -> the display of the knob (the bar) moves but the plugin receives no event and the guitar sound is unchanged.
Additional Information:
System Description
Attached Files: MIDI Control.png (16,879 bytes) 2021-02-04 13:12
https://tracker.ardour.org/file_download.php?file_id=3937&type=bug
png
Notes
(0025488)
DBA   
2021-02-04 08:06   
IMPORTANT

I discovered that in fact the knob is active but very weirdly and only with slow motion which is what happen when the Smooth parameter is at a low value. But I put it to a high value!

So my guess is the following: Smoothing parameter is not applied to the actual communication of the plugin, only to some ardour stuff and that's why the parameter in the VST plugin is not tracked correctly.
(0025490)
DBA   
2021-02-04 13:09   
To be very clear about my previous comment (0025488).

The knob jauge, attached to the VST plugin, in the effect loop of the track is moving with the expression pedal (because I set up Smoothing to 127) but inside the plugin, the parameter moves like the Smoothing was still on 10.
(0025491)
DBA   
2021-02-04 13:12   
Here is the knob jauge I talk about.
(0025590)
paul   
2021-03-03 20:24   
"don't forget to change this fXXXXg "Smooth" parameter to 127 as it should be by default (this used 3 hours of my life)"

I believe I explained elsewhere why it should not be 127 by default, and why there is fact no suitable default for this value. The correct value depends on the MIDI hardware in use.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9256 [ardour] bugs minor sometimes 2023-02-21 20:56 2023-02-21 20:56
Reporter: TatriX Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Notes in MIDI region are rendered as solid black rectangles
Description: See attached picture. If you move the region proper rendering is restored.
Copied region have notes rendered black as well.
If I reopen the session, note are black again.
Session attached.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 2023-02-21-215503_3840x2160_scrot.png (472,941 bytes) 2023-02-21 20:56
https://tracker.ardour.org/file_download.php?file_id=4404&type=bug
2023-02-21.zip (27,318 bytes) 2023-02-21 20:56
https://tracker.ardour.org/file_download.php?file_id=4405&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9253 [ardour] bugs minor always 2023-02-20 15:11 2023-02-21 01:04
Reporter: peder Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Commit b3a10378cfdfff8 breaks compiling with clang
Description: Compiling with llvm-16-14949-g6cad2a95fb and llvm-17-init-637-gae1475461 fails on _mm_hint
It works with gcc 7.5.0


[ 179/1179] Compiling libs/ardour/uri_map.cc
../libs/ardour/x86_functions_avx512f.cc:86:59: error: use of undeclared identifier '_mm_hint'
                _mm_prefetch(reinterpret_cast<void const *>(src + 256), _mm_hint(0));


[ 187/1179] Compiling libs/ardour/audiorom.cc
../libs/ardour/x86_functions_avx512f.cc:86:59: error: use of undeclared identifier '_mm_hint'
                _mm_prefetch(reinterpret_cast<void const *>(src + 256), _mm_hint(0));
 
Tags:
Steps To Reproduce: CC=clang CXX=clang++ ./waf configure --prefix=/opt/ardour-`git describe --tags` --ptformat --optimize --denormal-exception --with-backends=jack,dummy,pulseaudio --cxx11 --use-lld && ./waf build
Additional Information: I've compiled and installed llvm/clang myself, so it's possible that I've done something wrong there, but it has worked fine until b3a10378cfdfff8
System Description
Attached Files:
Notes
(0027403)
x42   
2023-02-21 01:04   
Fixed in 7.3-28-g2773199fa3, thanks to Ayan Shafqat

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9255 [ardour] bugs minor always 2023-02-20 16:27 2023-02-20 16:27
Reporter: dftar Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Session Loading Error
Description: I removed the problem IDs, opened the session, of course I lost most of the arrangement.
I worked in the session again, saved and closed. When I opened again, same error.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: a73-MamSuitInDealulClujului.ardour (117,915 bytes) 2023-02-20 16:27
https://tracker.ardour.org/file_download.php?file_id=4400&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9230 [ardour] bugs minor always 2023-02-08 15:27 2023-02-19 22:53
Reporter: lorenzosu Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Import intrprets midi pitch-bend rest position incorrectly as automation lines
Description: Importing a MIDI files Ardour always tries to 'interpolate' (i.e. create a line) between different pitch bend values, including if the value is 8191.

8191 should be considered the 'rest' or 'central' position of a pitch bend (wheel) and therefore a netural value not to be automated towards the next value unless explicitly requested. Some software expose to the user values of -8191 to +8191 and 0 (zero) as the central position which is more similar to how the actual pitch bend wheel works on many keyboards.
The problem is that typically sequencers interpret this value as a rest position and therefore won't automate to the next value, unless a series of controllers is explicitly required.

Overall this poses the more general issue of how to interpret 'automation' in midi, especially when importing and when control or pitch-bend changes are written in the MIDI file and some have a certain interpretation (e.g. CC 64 pedal, or other on/off controllers don't really make sense to be automated continuously).

Attached is a simple 1-track midi file which shows the problem.
Also attached screenshots of how Ardour imports it and how it is interpreted and used in other two MIDI sequencer software

Tags: Midi, midi import, pitch bend
Steps To Reproduce: - Import a MIDI file with pitch bends which include explicit values of 8191 (like the attached)
- Ardour interprets as automation lines changes from the last 8191 to the next different value
Additional Information:
System Description
Attached Files: bend_test.mid (388 bytes) 2023-02-08 15:27
https://tracker.ardour.org/file_download.php?file_id=4379&type=bug
ardour_pitch_bend_automation.png (43,901 bytes) 2023-02-08 15:27
https://tracker.ardour.org/file_download.php?file_id=4380&type=bug
png

qtractor_pitch_bend.png (15,064 bytes) 2023-02-08 15:27
https://tracker.ardour.org/file_download.php?file_id=4381&type=bug
png

rosegarden_pitch_bend.png (9,119 bytes) 2023-02-08 15:27
https://tracker.ardour.org/file_download.php?file_id=4382&type=bug
png
Notes
(0027327)
x42   
2023-02-08 15:35   
Is this still the case? I believe this was already fixed in 7.2-7-g75c9927d75
(0027397)
lorenzosu   
2023-02-19 20:04   
I can confirm that with a freshly built version (rev 7.3-22-gcf0b119b45) this now works as expected and is indeed fixed. Thanks!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9240 [ardour] other minor always 2023-02-16 03:51 2023-02-16 06:39
Reporter: dbolton Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 7.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Download page links to a 404 page
Description: If you visit https://community.ardour.org/download?platform=win&architecture=x86_64&type=compiled it includes a link to https://ardour.org/first_time_win.html (bottom of page in red box).

If you click on the link it says 404 Not Found
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027386)
paul   
2023-02-16 06:39   
Link fixed. Thanks for noticing.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9233 [ardour] bugs major always 2023-02-11 14:30 2023-02-14 16:19
Reporter: peki Platform: Desktop  
Assigned To: OS: Manjaro  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Incorrect MIDI note drawing with snapping to bar
Description: In Ardour 7.2, as it is available via the Arch Packages, with the settings mentioned in the "Steps To Reproduce" section, attempting to draw a note which is one bar long, Ardour will snap the note to ~3/4 of length the length of a bar.

A video showcasing the issue is provided.
Tags: 7.2, draw, editing, Midi
Steps To Reproduce: - Open a project in Ardour 7.2
- Ensure these settings are set:

-- "Snap" is enabled and snaps to Markers, Region Sync Points, Region Starts, Region Ends and the Grid.
-- Set the Grid Mode to Bar
-- Set the Draw Mode settings like so: Len: Auto, Ch: Auto, Vel: Auto

- Create a MIDI track, the choice of instrument doesn't matter
- Create a MIDI pattern of variable length, provided the length is greater than 1 bar
- Draw a note with your cursor starting near the beginning of the pattern and move the cursor to the end of the bar
- Notice the resulting note
Additional Information: Everything works as intended with other Grid Modes (e.g. 1/4 Note, 1/8 Note etc).
System Description
Attached Files: ardour-issue.mp4 (714,013 bytes) 2023-02-11 14:39
https://tracker.ardour.org/file_download.php?file_id=4385&type=bug
Notes
(0027354)
peki   
2023-02-11 14:39   
(0027355)
x42   
2023-02-11 16:10   
This should already be fixed since 7.2.29
(0027356)
x42   
2023-02-11 16:11   
Please test with a https://nightly.ardour.org build
(0027381)
peki   
2023-02-14 16:19   
Tested, all works fine!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9238 [ardour] other minor always 2023-02-13 17:29 2023-02-13 17:29
Reporter: mwotton218 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Export inconsistency with Normalize selection
Description: o Export had a single output file type mp3

o Exports worked as expected, without Normalize as had not been selected

o Added a second output file type flac which had normalize selected by default

o flac files exported with Normalize as selected

o mp3 files invoked Normalize when exporting, it was NOT selected in the file export profile but WAS selected in the profile NOT in use, the flac profile

o After Ardour re-start same result

o After system reboot same result

o After unchecking Normalize in the profile NOT IN USE, Normalize worked as expected
Tags:
Steps To Reproduce: see above
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9225 [ardour] bugs crash always 2023-02-05 17:38 2023-02-12 21:34
Reporter: enorrmann Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes while adding decent sampler VST3 plugin
Description: Ardour crashes while adding decent sampler VST3 plugin on any project
Tags:
Steps To Reproduce: download and copy decent sampler to home / .vst3 folder
new project
add midi track
insert decent sampler vst plugin
Segmentation fault (core dumped)
Additional Information:
System Description
Attached Files: decent-1.7.9.png (184,524 bytes) 2023-02-05 18:26
https://tracker.ardour.org/file_download.php?file_id=4368&type=bug
png

L26vbZVs.txt (88,677 bytes) 2023-02-05 18:45
https://tracker.ardour.org/file_download.php?file_id=4369&type=bug
dump.txt (30,504 bytes) 2023-02-05 22:44
https://tracker.ardour.org/file_download.php?file_id=4370&type=bug
dump-2.txt (31,173 bytes) 2023-02-08 08:42
https://tracker.ardour.org/file_download.php?file_id=4378&type=bug
dump-3.txt (19,095 bytes) 2023-02-09 08:46
https://tracker.ardour.org/file_download.php?file_id=4383&type=bug
dump-4.txt (22,733 bytes) 2023-02-09 08:50
https://tracker.ardour.org/file_download.php?file_id=4384&type=bug
DSLog_65340_2023-02-12_22-01-48.log (712 bytes) 2023-02-12 21:06
https://tracker.ardour.org/file_download.php?file_id=4391&type=bug
Notes
(0027279)
x42   
2023-02-05 18:26   
It works just fine here (with decent-sampler 1.7.9) downloaded just now and Ardour 7.2.226 (current nightly)

Older versions of the plugin crashed as soon as the plugin UI was shown (https://github.com/juce-framework/JUCE/pull/867).

Which version of Ardour are you using? Which version of the plugin? If you can reliably reproduce the crash, can you get a backtrace? https://ardour.org/debugging_ardour
(0027280)
enorrmann   
2023-02-05 18:45   
running
bind txt domain [gtk2_ardour7] to /usr/local/share/ardour7/locale
Ardour7.2.190 (built using 7.2-226-g13562d94f4 and GCC version 12.2.0)

and decent sampler just donwnloaded (179)
attached is the dump
(0027281)
x42   
2023-02-05 18:50   
OK. this seems to be an issue with decentsampler using openssl (libcrytpto) on your distro when the plugin tries to phone home.

Does the standalone version of decentsampler work?
(0027282)
enorrmann   
2023-02-05 18:52   
yes, it works in standalone mode
(0027283)
Miliation   
2023-02-05 22:44   
I'm also encountering this issue on my Arch Linux desktop, running Ardour 7.2 and the plugin works just fine in standalone mode. It's also worth noting that Carla didn't work with this plugin until I enabled "Load Carla backend in global namespace". I'm appending the dump in a file below.
(0027284)
paul   
2023-02-05 22:48   
This issue only occurs during DS account registration. I just downloaded 1.7.9 and loaded it into ardour 7.2 ... no issues. But I was already registered since I've been using DS for several years.

I would recommend (for now, at least) using the Standalone version to register yourself, and then the plugin should work.
(0027285)
enorrmann   
2023-02-06 02:55   
the issua happens on first gui load, I can't even reach account registration
(0027290)
paul   
2023-02-06 03:29   
Yes because the plugin is probably trying use libcrypto as part of an effort to see if you're registered. Please try the standalone version to get registered.

Plugins are supposed to be self-contained static things, and they should not require specific versions of system libraries. I will let the DS developer know about this.
(0027291)
enorrmann   
2023-02-06 03:54   
got it
(0027292)
paul   
2023-02-06 03:59   
One more question: is this the official ardour build from ardour.org or a build obtained from ubuntu?
(0027293)
enorrmann   
2023-02-06 04:01   
this is a nightly version built by me
(0027294)
paul   
2023-02-06 04:04   
please grab a free/demo copy, either the last release (https://ardour.org/download) or the nightly builds (https://nightly.ardour.org/) and test that. Chance are that it will work correctly.
(0027301)
Miliation   
2023-02-06 17:04   
After more investigation, the problem is indeed from the account logging in part. I just built the latest version and I still have the same problem. The problem is that when I login in the standalone version, the VST3 doesn't login. The interesting thing is that when i completely cut off my internet connection, everything starts working fine but when I reconnect. I immediately encounter a crash.
(0027302)
enorrmann   
2023-02-06 21:50   
I tried 2 more versions
latest from https://nightly.ardour.org/ works fine
and 7.2 from ubuntu studio backports, the bug is present
(0027303)
x42   
2023-02-06 23:13   
> but when I reconnect. I immediately encounter a crash.

The plugin GUI starts an insane amount of threads, about one per second performing some some http request.

As for the actual issue. recent JUCE plugins are not statically linked, nor dynamically linked, but dlopen() libcurl at rumtime.
The idea behind this is that it can work with various distros: Some use curl + openSLL, other distros curl + GNUTLS, yet others curl + NSS, etc.

Ardour binaries ship with NSS. -- In any case it seems to be some issue with Ubuntu's curl/openSSL setup.
(0027310)
dhilowitz   
2023-02-07 23:25   
Hi all! This is very interesting! DecentSampler actually contains a statically linked version of LibCURL/OpenSSL. I wonder if it's somehow conflicting with the version that is present within Ardour? Let me try creating a version that isn't statically linked and see if that still results in the same issue.
(0027311)
paul   
2023-02-07 23:34   
Hi Dave - so just to make sure the story is clear: our official builds on ardour.org work OK, but the versions of Ardour from at least some Linux distros do not.
(0027312)
dhilowitz   
2023-02-07 23:37   
Actually, it looks like in the most recent version (1.7.12), I _forgot_ to change the DecentSampler Makefile. In other words, I didn't try to link against static libcurl. I'd be interested in hearing if it fixes the issue for anyone: https://www.decentsamples.com/product/decent-sampler-plugin/
(0027313)
x42   
2023-02-07 23:38   
The backtrace also shows that JUCE uses system-wide /lib/x86_64-linux-gnu/libcrypto.so.3 -- even though the actual crash happens when the plugin tries to parse certs in a different thread.
(0027314)
x42   
2023-02-07 23:41   
PS I referred to the gdb backtrace "L26vbZVs.txt" from above https://tracker.ardour.org/view.php?id=9225#c27280
(0027319)
enorrmann   
2023-02-08 04:01   
I tried DS 1.7.12 and the issue is still present
(0027323)
Miliation   
2023-02-08 08:42   
I have also just tried DS 1.7.12 and this issue still persists. I'm sorry if the last dump wasn't okay. Here is a fresh dump:
(0027331)
dhilowitz   
2023-02-08 22:57   
What version of Ubuntu are y'all running? I've been unable to reproduce the issue with my build machine (Ubuntu 18.04) either using the pre-built Ardour or using one I built myself. I was also unable to reproduce it using the Ardour that ships with AV Linux.
(0027332)
x42   
2023-02-08 23:16   
(Last edited: 2023-02-08 23:16)
I cannot reproduce the issue here (debian 11.6 - current debian/stable), but searching the web for "crash SSL_get_peer_certificate" finds various other cases.

Also note that curl removed it about a year ago in curl 7.81
openssl: remove usage of deprecated `SSL_get_peer_certificate` 

(from https://curl.se/changes.html)

debian/.stable has curl 7.74 - and here by default libcurl4-gnutls is installed (not libcurl-nss nor libcurl4-openssl).

I hazard a guess that affected users are those from Ubuntu 22.10 with ships libcurl 7.85 or 22.04LTS which comes with 7.81
(0027333)
x42   
2023-02-08 23:22   
So the solution would be either

(a) statically link against libcurl+openssl and then either ignore certs
 curl_easy_setopt (c, CURLOPT_SSL_VERIFYPEER, 0);
 curl_easy_setopt (c, CURLOPT_SSL_VERIFYHOST, 0);


or set them up by checking various locations used by distros like:
https://github.com/Ardour/ardour/blob/bb31125c944acffa94068b8c52788964bb3be82c/gtk2_ardour/ardour_http.cc#L70-L106

or

(b) dlopen("libcurl.so") at runtime and use symbols from there.
(0027334)
enorrmann   
2023-02-09 02:09   
I'm running Ubuntu 22.10 indeed
(0027337)
Miliation   
2023-02-09 08:18   
My desktop is running Arch Linux so what I'm guessing is that since it has rolling release packages, it has the latest version of libcurl installed, I will install an older version of it and report back.
(0027338)
Miliation   
2023-02-09 08:25   
Update: installing curl 7.74 completely fixed the problem and plugin works as expected now.
(0027339)
Miliation   
2023-02-09 08:46   
Despite the fact that the plugin works just fine after downgrading, when I try to remove the track, Ardour crashes. However if I deactivate the track and then remove it. It doesn't seem to crash.

This is not the main focus of this thread but it might be worth pointing out:
(0027340)
Miliation   
2023-02-09 08:50   
Sorry about the last note, looks like the "deactivating and deleting" thing I pointed out doesn't seem to stand out in another gdb session:
(0027366)
dhilowitz   
2023-02-12 15:29   
Hi all, I've just uploaded a fresh version of Decent Sampler that links against the latest versions of libcurl and openSSL: https://www.dropbox.com/s/r2htgfvtdprglyb/Decent_Sampler-1.7.13-Linux-x86_64.tar.gz?dl=0.

I'd love to hear if this fixes any issues.
(0027367)
enorrmann   
2023-02-12 16:07   
I'm happy to report that 1.7.13 fixed the issue for me on Ardour 7.2 from ubuntu 22.10
(0027368)
dhilowitz   
2023-02-12 16:25   
Oh, that's great to hear. Here's hoping that I didn't introduce any more bugs by upgrading to the latest versions. ;)
(0027369)
x42   
2023-02-12 16:37   
It also loads fine on debian/stable. This is great news. -- I suppose this issue can be closed then.


PS. The plugin still exposes all of JUCE in the public namespace. Ideally there'd be only the dynamic glibc symbols, and VST entry points (ModuleEntry, ModuleExit)
objdump -T  ~/.vst3/DecentSampler.vst3/Contents/x86_64-linux/DecentSampler.so | c++filt
(0027373)
dhilowitz   
2023-02-12 19:15   
Ah, so glad to hear this. Thanks for trying it out!

PS. I have actually no idea how to prevent JUCE from being exposed. :/
(0027374)
ppelikan   
2023-02-12 21:06   
For me Ardour (7.2.0) + DecentSampler (1.7.13) crash when I try to change the preset or the sample library inside DecentSampler.
For VST only DecentSampler crashes, for VST3 both crash.
(0027375)
x42   
2023-02-12 21:34   
> PS. I have actually no idea how to prevent JUCE from being exposed. :/

Likely by adding`-fvisibility-hidden` to CFLAGS and CXXFLAGS. -- It also used to be the default for JUCE until Jules left.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9236 [ardour] features minor have not tried 2023-02-12 17:19 2023-02-12 17:19
Reporter: cooltehno_bugs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Reduce the "marmalade" effect in the "Gain" region transparency visibility
Description: The proposal is to make the regions color fill unaffected while the "Gain" Opaque change,

and the Grid visibility affected by this options (the area where the grid crosses the regions):

   - if the region "Gain" is transparent - the grid visibility is 80-100%
   - if the region "Gain" is opaque - the grid visibility is 10-20%
Tags:
Steps To Reproduce:
Additional Information: Discussion:
https://discourse.ardour.org/t/regions-transparency-in-7-2/108060
Attached Files: Gain_transparency_proposal.png (835,056 bytes) 2023-02-12 17:19
https://tracker.ardour.org/file_download.php?file_id=4390&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9235 [ardour] features minor have not tried 2023-02-11 18:36 2023-02-11 22:20
Reporter: benald Platform: Microsoft  
Assigned To: OS: Windows  
Priority: low OS Version: 11  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Could we have midi cc editing for Busses please?
Description: I have achieved this in the past in Ardour using sidechaining from midi instrument tracks to control Cardinal FX plugins. I think it would be nice to have CC editing for Busses (with editable names per parameter) so parameters for shared FX can be altered as the song plays without having to come via sidechains. The picture shows how I reckon I have achieved this in the past (pre current nightly version of Ardour I'm using) via sidechaining. I'm thinking it might make sense for the busses to be able to send CC data directly without a sidechain.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files: sidechaining.png (678,141 bytes) 2023-02-11 18:36
https://tracker.ardour.org/file_download.php?file_id=4387&type=bug
Notes
(0027364)
benald   
2023-02-11 22:20   
There is no problem with the current nightly concerning sending CV data to an audio bus FX via a sidechain as I thought there might have been when I wrote this feature request.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9234 [ardour] bugs major always 2023-02-11 16:30 2023-02-11 19:28
Reporter: doojonio Platform: Redhat  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't draw notes in percussive mode
Description: If you record or create new midi region on track with percussive mode enabled and if you crop the beginning of the region then you can't draw notes on this region anymore unless you switch to sustained mode or restore the cropped beginning of the region.
Tags: 7.2, draw, editing, Midi, region
Steps To Reproduce: 1. Create MIDI track
2. Switch to percussive note mode
3. Draw a new region
4. Crop the beginning of created region
5. Try draw notes
Additional Information:
System Description
Attached Files:
Notes
(0027357)
gimp335   
2023-02-11 18:12   
Also have this issue since 7.0. The issue occurs on Arch Linux with Ardour from the arch repos, the official binary, and git builds.
(0027360)
x42   
2023-02-11 19:28   
Fixed in Ardour 7.2-270-gadf1eb34fb

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9206 [ardour] bugs minor always 2023-01-24 15:20 2023-02-11 12:41
Reporter: colin.y Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST3 Plugin "Zebralette" does not recall state correctly when session re-opens
Description: When I re-open a saved session which contains a native Linux VST3 plugin for the Zebralette synth, I have to manually reset the plugin's inbuilt preset.

This did not occur in 6.9 or even 7.2.0.

I first noticed it in 7.2.104 and have since verified it in 7.2.148.

I see the same behaviour when I create a new session containing only one track with this plugin.
Tags: 7.2, Linux, plugin, VST3
Steps To Reproduce: Create a MIDI track in 7.2.148 with Zebralette and select inbuilt plugin preset. Save and close session.

Re-open session and although the preset displays the correct preset name, the plugin's settings are not correct, so I have to manually re-select the preset to obtain the desired sound.
Additional Information: VST3 module-path '/home/colin/.vst3/u-he/Zebra2.vst3/Contents/x86_64-linux/Zebra2.so'
System Description
Attached Files: _PluginTest7_2_171.ardour (166,097 bytes) 2023-01-29 13:55
https://tracker.ardour.org/file_download.php?file_id=4360&type=bug
Notes
(0027253)
colin.y   
2023-01-29 13:55   
I have re-tested using build 7.2.171, with the same results described previously. I also see issues with some other VST3 synth plugins (e.g. OT GENESYN 2).

I do not see the problem when I open the session (created with 7.2.171) with 7.2.0.
(0027353)
x42   
2023-02-11 12:41   
Fixed in 7.2-269-g21d86b264a

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9107 [ardour] bugs major always 2022-11-20 13:35 2023-02-10 20:26
Reporter: Stummer Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot change tempo at a x/8 time signature change mark. Changing TS also causes a crash
Description: i have an Ardour project in 6/8 time. At the start of bar 5 the TS changes to 3/8 for one bar then back to 6/8 at bar 6. The tempo should change from 75 to 92 at bar 6, beat 1 but Ardour will not take a tempo entry at beat 1 (at the same time as a TS change), only beat 2. Making a test by changing the TS to other x/8 values then caused Ardour to crash.
Tags:
Steps To Reproduce: Tempo changes and TS changes work as they should for 4/4 time changing to 2/4 time. And 8/16 time changing to 12/16 time for example. But irregular behaviour seems to happen when the project is set up with x/8 time in the first place. Trying the above actions in a new project and I got further but then it caused problems. Screenshot attached.
Additional Information:
System Description
Attached Files: Ardour TS.png (109,661 bytes) 2022-11-20 13:35
https://tracker.ardour.org/file_download.php?file_id=4297&type=bug
png
Notes
(0027350)
paul   
2023-02-10 20:26   
Testing this with current git master version suggests that this has all been fixed. Could you check with a nightly build from https://nightly.ardour.org/ ?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9204 [ardour] bugs minor sometimes 2023-01-24 10:55 2023-02-10 19:20
Reporter: benald Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash during repeat pasting region from several tracks (including control data)
Description: I have created a select region over several tracks, copied it and pasted it in a clear section after all of my recorded data. When I pressed 'Control-V' a second time the pasted section appeared briefly immediately following the first pasted instance of the data in the timeline. Immediately after this Ardour crashed.
It seems that if I wait for some time between pressing 'Control-V' then crashing will not occur.
The screen grab I am uploading shows the selected data towards the left of the screen and one instance of that selected data successfully pasted towards the right of the screen.
Here is my hardware spec:

Processor AMD Ryzen 7 4700U with Radeon Graphics 2.00 GHz
Installed RAM 8.00 GB (7.37 GB usable)
System type 64-bit operating system, x64-based processor



 
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files: ardour paste crash.png (234,266 bytes) 2023-01-24 10:55
https://tracker.ardour.org/file_download.php?file_id=4352&type=bug
png

Ardour-debug.log (4,180 bytes) 2023-01-28 14:33
https://tracker.ardour.org/file_download.php?file_id=4358&type=bug
ardour hangs here.png (147,132 bytes) 2023-01-28 14:33
https://tracker.ardour.org/file_download.php?file_id=4359&type=bug
png
Notes
(0027243)
paul   
2023-01-26 05:45   
We would need a debug backtrace to be able to work on this. https://ardour.org/debugging_ardour
(0027246)
benald   
2023-01-26 18:02   
I've got this project do what I want by exporting all of the midi and loading it into a new project. I'll look into installing the bug tracking software at the weekend or next week when I'm back home.
(0027249)
benald   
2023-01-27 16:37   
Paul, the debug version web page download button is greyed out for me whether I select free or full download version. I am a subscriber.
(0027250)
benald   
2023-01-27 16:48   
Sorry, ignore that last message. Download is working now I selected '64 bit'.
(0027251)
benald   
2023-01-28 14:33   
Hi Paul. I have got a debug log for you. I had slightly different behaviour with the debugger running. I *could* re-open my compromised project under the debugger (without the debugger Ardour hung at the screen grab shown. I ran the debugger by running the debug.bat in the ardour7 file. Is this right? The instructions in your how to debug page may need updating...
https://ardour.org/debugging_ardour.html
(0027349)
paul   
2023-02-10 19:20   
The debug log shows that you were doing the correct thing, but there was no apparent crash ....

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9228 [ardour] features minor have not tried 2023-02-06 17:36 2023-02-10 17:49
Reporter: cooltehno_bugs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Dublicate Favorite Plugins from the Mixer List into the Editor List TAB
Description: Just an idea (may be it's not too much difficult). If the side panel in the Editor window (Editor List Shift+L) could have the same Favorite Plugins list (as one more TAB) as Mixer List has - this could give the possibility to drug&drop favorite plugins into the Editor mixer strip.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: favorite_plugins_tab_editor_list.png (298,981 bytes) 2023-02-06 17:36
https://tracker.ardour.org/file_download.php?file_id=4373&type=bug
Notes
(0027345)
x42   
2023-02-10 02:26   
It is sadly not an easily reusable widget and keeping order in sync when reordering the favorites will also need some extra work.
Ergonomically it is also odd, one would have to drag the plugin across the entire screen width to reach the editor-mixer and the editor mixer may not even be visible.
(0027347)
cooltehno_bugs   
2023-02-10 17:49   
This feature request is absolutely not so important, it was just my thought! For my personal taste&needs - Ardour is already good featured - just only bugs polishing could make the DAW super-cool for me!
About "reach the editor-mixer" - it is the same as if we want to reach from the mixer favorite plugins list to the Master Bus stripe in the Mixer window..
But you are the master, no problem!)) My deal is to propose..
And also thanks for the response & dialog! Good&creative mode, x42! :))

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9201 [ardour] bugs major always 2023-01-18 11:45 2023-02-10 00:59
Reporter: bsj Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: high OS Version: 10.12 or later  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Slow Editor performance caused by the new opaque regions on Ardour 7.2 & Mixbus 8.2 Release!
Description: The editor section is slow when zooming in and out of audio regions.
Tags: 7.2, 8.2, Ardour, Editor, MIxbus, performance, slow
Steps To Reproduce: this issue is noticeable with a good amount of tracks, however 1 or 2 tracks seem to be ok but in a real mix environment this is not ideal as the slow performance will occur when you are having a real world mix session, if you add lets say 16-30 tracks as a example and then you zoom in and out on all regions its very slow, also you will notice this when you set the Zoom setting to (Fit All Tracks) and when you scroll around/zooming in and out its slow. Prior versions such as 7.1 for Ardour and Mixbus 32c 8.1 did not have any issues with this.
Additional Information: The new opaque regions seems to be causing this. Mixbus 8.1 and Ardour 7.1 do not have this issue, the only way to resolve this and get the same performance zooming in and out etc is to adjust the alpha setting to 0 which causes all audio regions to disappear and thus the perforce is back again but is useless due to the ability not to see your audio regions is gone. This new feature seems to be slowing down Ardour and Mixbus editor performance and should be changed and re-implemented in a way that doesn't create a performance hit.
System Description
Attached Files:
Notes
(0027187)
bsj   
2023-01-18 11:46   
I hope they can fix this issue. really been a drag and having to stay on older versions because of this.
(0027190)
paul   
2023-01-18 14:42   
The problem is that this issue appears to be system-dependent. We have tried to reproduce it on various macs in our possession, and none of them show the issue. It therefore becomes unclear whether this is hardware dependent, or triggered by some 3rd party software, or specific to a very precise version of macOS, or something else.
(0027191)
bsj   
2023-01-18 14:59   
I’m not sure if all m1 users have this issue or if some do and don’t? I tested this on 2 m1 computers and they both have this issue, one of the computers has a more fresh install on Monetary Mac OS. I’m not sure if going to Mac OS Ventura would help, I also don’t know if the latest versions of ardour and mixbus are compiled for the latest Mac OS either.
(0027192)
bsj   
2023-01-18 15:25   
Also were any your tested machines powered by Apple silicon. This may be a apple silicon issue but I don’t know if I read that someone using Linux had the same issue or not.
(0027193)
paul   
2023-01-18 15:39   
Yes, we've tested on 2 Apple Silicon systems.
(0027194)
bsj   
2023-01-18 21:31   
What version of OS was it tested on
(0027195)
bsj   
2023-01-18 21:51   
Also I know the slowness can be subjective to different people if they are not aware of use the program in different ways, example they may have a mouse with a slower mouse scroll speed for example. But on the systems you tested, there was absolutely no speed difference in the scroll speed or response rate of zooming in and out of all regions on screen on a large mix where all or most of the tracks or regions are displayed on the screen at the same time. I wish someone posted a video of their unaffected setup, it’s a bit discouraging since I tested on 2 different machines with same issue. Is this only a Mac OS issue, do people on windows or Linux have this issue at all?
(0027196)
paul   
2023-01-18 22:45   
Nobody has reported this behavior for Linux or Windows.

This is the sort of thing we've (and Reaper) have encountered in the past: https://user.cockos.com/~deadbeef/index.php?article=516
(0027197)
bsj   
2023-01-18 23:32   
Oh ok, sometimes I really dislike Mac OS for when things are just complicated. I guess the only way to fix this is for ardour to reverse the feature that causes this, but I know that’s not likely going to happen since it doesn’t affect all of users.
(0027198)
paul   
2023-01-19 00:49   
We won't reverse it for now, but not because it doesn't affect all users - more because we want to find a system where we can debug whatever is happening, and then fix it.
(0027199)
bsj   
2023-01-19 02:04   
Which operating system was it tested on.
(0027203)
bsj   
2023-01-19 16:59   
This issue seems to be a graphics acceleration issue. When disabled mixbus 8.2 works much smoother. However not sure on any possible cpu performance costs that I may face.
(0027204)
x42   
2023-01-19 22:26   
@bsj Can you elaborate which, and how you "disable graphics acceleration" -- there are various options.

I use Ardour on a M2 macbook air running Ventura 13.1, and do not have and issues. I do not use external screens though.
I could imagine that perhaps using some external displays with color correction, esp non apple hardware, might have an effect.
(0027205)
bsj   
2023-01-20 00:42   
I disabled it via the settings/preferences menu, not via terminal code. Which I do want to try. However I’m not sure why some have this issue and some don't, when I disable the hardware acceleration it does improve and it does improve even more when I reduce my Mac OS resolution scaling.

I’m not sure if I will have my CPU usage when running with disabled hardware acceleration, Does it also stop plugins from using GPU? When using ardour/mixbus I don’t see any GPU usage other than my plugins that use GPU so I don’t know what hardware acceleration is doing.

Also I’m wondering how could this be resolved without disabling.

I also was wondering if ardour can use something other than open GL for rendering, I know apple has their Metal API and I know there’s Vulcan. Not sure if this is just fantasy for a daw like ardour and mixbus to utilize.


Also, have you tried loading up a typical mix session with about 16-30 tracks and set the zoom to fit so all regions fit on screen, then zoom in and out of all regions, are you saying that you don’t have any slow rendering or delayed loading etc.
(0027207)
x42   
2023-01-21 00:12   
Ardour is 2D (not 3D), so neither Vulkan or Metal will help. openGL is used as work-around to bypass color-correction (see paul's post above) on older systems (until Catalina).

I test with a session with 12 tracks visible, zoomed to show 5 seconds. With follow playhead as well as stationary playhead things are smooth using "more space" with the Retina screen.
Quatrz debug reports 30 fps.
(0027209)
bsj   
2023-01-21 00:45   
Oh, so what about plugins that use GPU for GUI, I don’t think most plugins have any 3D elements to them. Also I always thought ardour and mixbus would be benefit from GPU acceleration based on how mixbus mixer GUI looks.

Also what happens when you disable hardware acceleration if it doesn’t use GPU for rendering.
(0027210)
x42   
2023-01-21 00:54   
With Hardware acceleration Ardour renders directly to a NSView.
Without Hardware acceleration Ardour renders to an image-surface in memory and then the result is copied as bitmap to the NSView.
(0027211)
bsj   
2023-01-21 02:00   
Is their like a performance hit that is noticeable, is there a way I can see how it affects CPU?
(0027213)
x42   
2023-01-21 04:03   
Could you try if changing the color profile helps? Set

Apple System Preferences > Displays > Color Profile ... to Generic RGB Profile
(0027214)
bsj   
2023-01-21 04:40   
So I try this before or after I disable hardware acceleration?
(0027216)
x42   
2023-01-21 05:00   
Disable HW acceleration.
(0027217)
bsj   
2023-01-21 06:06   
Well disabling hardware acceleration and changing colour profile didn’t help do bc anything different, when I do disable hardware acceleration it does speed up the editor section.,
(0027222)
bsj   
2023-01-23 12:15   
Text is a bit blurry without hardware acceleration. So I have to keep that in mind also.
(0027261)
bsj   
2023-01-31 04:19   
Is their anything that ardour can do?
(0027262)
paul   
2023-01-31 05:02   
We are continuing to evaluate, research and debug this issue. We do seem to have a system that shows the problem in front of of one of our developers now.
(0027263)
bsj   
2023-01-31 08:29   
Oh ok, this is great news, I hope it can be fixed. Not sure why only some have this issue like me and many others.
(0027273)
bsj   
2023-02-04 18:47   
Mixbus appears to have a version update that resolves this however with Harrison’s implementation it does have lower quality/resolution of the waveform view. I hope there is a way to fix this, it looks less sharp and the Color is dull compared to the default settings.
(0027316)
x42   
2023-02-08 00:07   
There has been some some significant work in Ardour 7.2-250 (https://nightly.ardour.org)

* partial exposure works now properly on macOS/OSX. Previously every redraw always painted the complete editor canvas -- this still happens with stationary playhead though
* Colorspace correction is bypassed for the application - this speeds up bitblt
* alpha-overlay calculation is now performed using dedicated asm code.
* openGL can now upscale to Retina resolution
* ... and if thing render still too slow, setting "region alpha" to 100% is now possible (Prefs > Appearance > Colors > Transparency) -- previously it got stuck at 98.9%.
(0027317)
bsj   
2023-02-08 02:02   
I assume that this is more work under the hood then what mixbus just released. I’ll check this out when I can
(0027318)
x42   
2023-02-08 02:58   
(Last edited: 2023-02-08 02:59)
It is in the Mixbus 8.2.170 hotfix.
(0027325)
bsj   
2023-02-08 10:05   
When I tried the mixbus 32C update fix it didn’t say or have option render for retina scaling l, I assume based on the quality it was only for low quality but was not labeled that. Ardour does have different wordings which I prefer, but strange thing is, on ardour nightlies, I tested it on my apple silicon computer and all the settings, the slow editor performance is somehow gone from my testing with 30 tracks. It was only 5-7 percent slower with the fixes enabled but when I clicked No for the option it was running at regular speed. Lol

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6976 [ardour] bugs minor always 2016-08-22 01:17 2023-02-09 22:36
Reporter: trebmuh-olinuxx Platform:  
Assigned To: paul OS: debian  
Priority: normal OS Version: jessie  
Status: feedback Product Version: 5.0  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ctrl + double-click doesn't open a plugin with the generic UI, but with the plugin provided UI
Description: As the tooltip when overing a plugin in the mixer strip says : double-click is supposed to open the plugin with its UI, and Ctrl + double-click is supposed to open it with the generic UI.

It doesn't work, meaning : Ctrl + double-click is opening the plugin with its self-provided UI.

Tested with various LV2 plugins such as : x42 fil4, IR.lv2, guitarix GxCompressor, ZamDelay, Calf 30 bands EQ.

Note that opening the generic UI from the context menu works as expected.
Tags:
Steps To Reproduce: - open Ardour
- create an audio track
- load a plugin
- Ctrl + double-click on it
Additional Information: Supposed to be working if looking at the tooltip when mouseovering the plugin in the mixer strip, as well as reading at : https://ardour.org/news/3.2.html
Attached Files:
Notes
(0018468)
paul   
2016-08-24 02:48   
Already fixed in git. The tooltip and code did not match; the code now matches what was said in the tooltip. commit ed5091d7ae47
(0018542)
trebmuh-olinuxx   
2016-09-03 18:48   
(Last edited: 2016-09-03 18:48)
Hi Paul,
running a backport on debian Jessie from the debian Sid 5.3 package, it doesn't looks to be here.

The_CLA mentioned on IRC :
<the_CLA_2> olinuxx: It's Alt + Double Click
<the_CLA_2> olinuxx: The tooltip seems to be wrong.
<the_CLA_2> olinuxx: Hm... just reading the bug report... So I guess it was supposed to be changed the other way round. Not sure I would like that, though. Las might be able to tell more when he's back.

So I'm putting this here to keep the momentum.

Let me know if you'd like me to test anything else.

(0023642)
system   
2020-04-19 20:18   
Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.
(0027326)
trebmuh-olinuxx   
2023-02-08 12:08   
Hi there

Running a 7.2 version, this issue is still here but changed a bit.
The tooltip says "alt + double-click" to open the generic interface, but doing this "alt + double-click" results in nothing happening.
Note that right-click on it + "edit with generic interface" works fine.
(0027343)
x42   
2023-02-09 22:36   
Works fine here. Note however that some desktop environments to catch Alt+click and reserve it for various window operations.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9229 [ardour] bugs minor always 2023-02-08 01:37 2023-02-09 17:38
Reporter: sollapse Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST3: Pro-Q 3 UI fails to detect mono track/bus
Description: When using Pro-Q on a mono track or bus the UI continues to provide stereo options. The bx_console_9000 has similar functionality with different UI's for mono and stereo, and works correctly in Ardour. I've included a screenshot using Pro-Q forced to mono within Metaplugin to show the correct interface.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: pro-q.jpg (396,858 bytes) 2023-02-08 01:37
https://tracker.ardour.org/file_download.php?file_id=4376&type=bug
9000_old.jpg (928,575 bytes) 2023-02-08 05:42
https://tracker.ardour.org/file_download.php?file_id=4377&type=bug
Notes
(0027320)
sollapse   
2023-02-08 05:29   
It seems that the bx_console_SSL9000 fails to detect mono as well now. This was working previously. I'm running 7.2.251 currently.
(0027321)
sollapse   
2023-02-08 05:42   
Added screenshot highlighting the new instance on latest version (7.2.251). The plugin which detected mono correctly was added using version 7.2.200.
(0027322)
sollapse   
2023-02-08 07:31   
I was able to trigger the mono mode of the 9000 VST by enabling manual config in the pin connectors dialog. Pro-Q is unaffected however and still remains in stereo.
(0027330)
x42   
2023-02-08 21:58   
Fixed in 7.2-260-g445e5162fd (tested with Pro-Q)
(0027335)
sollapse   
2023-02-09 03:35   
Thanks for this. Will it be possible in the future to allow the pin connector to manually force the correct I/O ports for the plugin? For instance, Pro-Q also offers surround modes. I've been using Metaplugin to choose the correct ports for VST3 plugins as a workaround.
(0027341)
x42   
2023-02-09 16:29   
While there is support for surround (just connect all the pins), it is not currently possible to distinguish the VST3 modes semantically.
Ardour just enumerates connected pins sequentially (L, R, C, LFe, Ls, .. see bitset below)

This caused the current bug: Only pin 1 was connected, so Ardour announced "Left" -- but VST3 distinguishes "only left of a stereo-pair" and "mono".
For whatever reason there is also the ambiguity of connecting the first six pins (L, R, C, Lfe, Ls, Rs) and explicitly choosing "Surround".

So at some point we may have to expose this explicitly and let the user pick

VST3 defines the following bitset:
  const Speaker kSpeakerL    = 1 << 0;    ///< Left (L)
  const Speaker kSpeakerR    = 1 << 1;    ///< Right (R)
  const Speaker kSpeakerC    = 1 << 2;    ///< Center (C)
  const Speaker kSpeakerLfe  = 1 << 3;    ///< Subbass (Lfe)
  const Speaker kSpeakerLs   = 1 << 4;    ///< Left Surround (Ls)
  const Speaker kSpeakerRs   = 1 << 5;    ///< Right Surround (Rs)
  const Speaker kSpeakerLc   = 1 << 6;    ///< Left of Center (Lc) - Front Left Center
  const Speaker kSpeakerRc   = 1 << 7;    ///< Right of Center (Rc) - Front Right Center
  const Speaker kSpeakerS    = 1 << 8;    ///< Surround (S)
  const Speaker kSpeakerCs   = kSpeakerS;   ///< Center of Surround (Cs) - Back Center - Surround (S)
  const Speaker kSpeakerSl   = 1 << 9;    ///< Side Left (Sl)
  const Speaker kSpeakerSr   = 1 << 10;   ///< Side Right (Sr)
  const Speaker kSpeakerTc   = 1 << 11;   ///< Top Center Over-head, Top Middle (Tc)
  const Speaker kSpeakerTfl  = 1 << 12;   ///< Top Front Left (Tfl)
  const Speaker kSpeakerTfc  = 1 << 13;   ///< Top Front Center (Tfc)
  const Speaker kSpeakerTfr  = 1 << 14;   ///< Top Front Right (Tfr)
  const Speaker kSpeakerTrl  = 1 << 15;   ///< Top Rear/Back Left (Trl)
  const Speaker kSpeakerTrc  = 1 << 16;   ///< Top Rear/Back Center (Trc)
  const Speaker kSpeakerTrr  = 1 << 17;   ///< Top Rear/Back Right (Trr)
  const Speaker kSpeakerLfe2 = 1 << 18;   ///< Subbass 2 (Lfe2)
  const Speaker kSpeakerM    = 1 << 19;   ///< Mono (M)
  const Speaker kSpeakerACN0  = (Speaker)1 << 20; ///< Ambisonic ACN 0
  const Speaker kSpeakerACN1  = (Speaker)1 << 21; ///< Ambisonic ACN 1
  const Speaker kSpeakerACN2  = (Speaker)1 << 22; ///< Ambisonic ACN 2
//[...]

  const SpeakerArrangement kEmpty      = 0;          ///< empty arrangement
  const SpeakerArrangement kMono       = kSpeakerM;  ///< M
  const SpeakerArrangement kStereo     = kSpeakerL   | kSpeakerR;    ///< L R
  const SpeakerArrangement kStereoSurround = kSpeakerLs  | kSpeakerRs;   ///< Ls Rs
//[...]
  
(0027342)
sollapse   
2023-02-09 17:38   
I would look forward to that option! Although this leads to another question I have about dynamically configured plugins. I mentioned that the bx_9000 VST at first was able to detect mono channels correctly (7.2.191). Somewhere around 2-3 nightly versions back, this function was broken and now it only triggers it's mono mode when manual config is selected. Does this mean multiple methods are involved (or allowed) for a plugin to determine the channels in use?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9231 [ardour] bugs minor always 2023-02-08 20:28 2023-02-08 20:58
Reporter: GMaq Platform: Linux  
Assigned To: OS: AV Linux  
Priority: normal OS Version: 21.3  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Imported tracks order is scrambled when importing using 'existing tracks' and 'playhead' for import later in timeline.
Description: Hi,

I use a Zoom Livetrak L-20 recorder which can either be used as a class compliant USB interface or records to SD Card. I usually record to SD Card and then import the tracks into Ardour for post-production. As an example with 6 recorded drum tracks if I do an initial Import into Ardour from the Import menu and I 'Add Files as new tracks' at 'Session start' then the tracks are all processed properly and in order of track number off the SD Card, However if I want to add more content later to an Ardour Session and I select the Tracks I want to import to and use 'Add to selected Tracks' with the 6 tracks selected and I use 'Playhead' as the position to be imported to on the timeline then the order of the tracks is scrambled and the imported tracks are not properly mapped to the existing 6 tracks in order. The tracks to be imported are not selected in any random order and are selected from top to bottom in numerical sequence exactly as they are when imported into a fresh session. This bug is annoying because it requires creating a slush track to make room to manually drag the newly imported tracks into their correct order to line up with what is already in the session.
Tags:
Steps To Reproduce: 1. Fresh session
2. Import numbered multiple tracks (observed here with 1-6) into session with Add Files as new tracks and Session start settings
3. move playhead to later in session..
4. Select track headers of tracks to import to.
5. Import same number of tracks with Add to selected tracks and at Playhead set
6. Tracks import at Playhead on selected tracks but the order is scrambled..
Additional Information:
System Description
Attached Files:
Notes
(0027328)
x42   
2023-02-08 20:35   
What "Sort order" do you use in the Import File dialog? "by selection order"?
(0027329)
GMaq   
2023-02-08 20:58   
Hi,

I just use what the default is, I don't make a specific selection in that dropdown box, but my selection order is always 'Shift' from top to bottom, never randomly selected with 'Ctrl'.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9217 [ardour] bugs crash always 2023-01-31 19:32 2023-02-08 00:01
Reporter: slash42 Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Segfault when moving a wave region using the middle mouse button and also clicking/releasing the left mouse button while moving
Description: Hi.

A while ago I reported a similar bug: https://tracker.ardour.org/view.php?id=8529
It is fixed in KDE neon / Ubuntu 22.04 / Ardour 6.9, thanks for that!
However, I found a variant of it which again leads to a reproducible crash.
Tags:
Steps To Reproduce: - open a blank session, no plugins
- add 3 or more wave tracks
- record something into the 1st track
- click and hold middle mouse button on the recorded region
- drag region to the 2nd wave track
- now click and hold also the left mouse button
- drag region further down to the 3rd wave track
- the region starts to jump back to the first and then to the 2nd track, although the mouse pointer is now inside the 3rd.
- release the left mouse button
- release the middle mouse button => crash
Additional Information: The Ardour version I'm using is 1:6.9.0+ds0-1build1

In my recording and cutting process I mostly use the middle mouse button to drag regions around, especially if I want to keep the positions of them. But sometimes, due to sloppiness, it happens to me that my finger slips off the mouse wheel and also presses the left mouse button.
System Description
Attached Files:
Notes
(0027305)
x42   
2023-02-07 01:27   
Confirmed, starting a new action while one is already in progress:

Dragging region(s) from 1 different track(s), max dist: 0
An UNDO transaction was started while a prior command was underway. Aborting command (fixed time region drag) and prior (fixed time region drag)

ardour-7.2.214: ../libs/ardour/session_state.cc:3326: void ARDOUR::Session::begin_reversible_command(GQuark): Assertion `false' failed.
--Type <RET> for more, q to quit, c to continue without paging--

Thread 1 "ArdourGUI" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
0000001  0x00007ffff37f9537 in __GI_abort () at abort.c:79
#2  0x00007ffff37f940f in __assert_fail_base
    (fmt=0x7ffff39716a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff6d3a1bf "false", file=0x7ffff6d38c30 "../libs/ardour/session_state.cc", line=3326, function=<optimized out>) at assert.c:92
#3  0x00007ffff3808662 in __GI___assert_fail
    (assertion=0x7ffff6d3a1bf "false", file=0x7ffff6d38c30 "../libs/ardour/session_state.cc", line=3326, function=0x7ffff6d3a188 "void ARDOUR::Session::begin_reversible_command(GQuark)")
    at assert.c:101
0000004  0x00007ffff7981230 in ARDOUR::Session::begin_reversible_command(unsigned int) (this=0x55555d220800, q=5476) at ../libs/ardour/session_state.cc:3326
0000005  0x00007ffff798114a in ARDOUR::Session::begin_reversible_command(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    (this=0x55555d220800, name="fixed time region drag") at ../libs/ardour/session_state.cc:3309
#6  0x00005555575d4d0a in Editor::begin_reversible_command(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) (this=
    0x55555eb631f0, name="fixed time region drag") at ../gtk2_ardour/editor.cc:3735
#7  0x0000555557688ac3 in RegionMoveDrag::motion(_GdkEvent*, bool) (this=0x5555672ba820, event=0x7fffffffc1d0, first_move=true) at ../gtk2_ardour/editor_drag.cc:1594
0000008  0x00005555576830a2 in Drag::motion_handler(_GdkEvent*, bool) (this=0x5555672ba820, event=0x7fffffffc1d0, from_autoscroll=false) at ../gtk2_ardour/editor_drag.cc:522
0000009  0x0000555557681f6c in DragManager::motion_handler(_GdkEvent*, bool) (this=0x555559b02b10, e=0x7fffffffc1d0, from_autoscroll=false) at ../gtk2_ardour/editor_drag.cc:231
0000010 0x00005555576f5e42 in Editor::motion_handler(ArdourCanvas::Item*, _GdkEvent*, bool) (this=0x55555eb631f0, event=0x7fffffffc1d0, from_autoscroll=false)
    at ../gtk2_ardour/editor_mouse.cc:2299
0000011 0x000055555767b4e4 in Editor::canvas_region_view_event(_GdkEvent*, ArdourCanvas::Item*, RegionView*) (this=0x55555eb631f0, event=0x7fffffffc1d0, item=0x555566f6c420, rv=0x555559cd2040)
    at ../gtk2_ardour/editor_canvas_events.cc:273
0000012 0x0000555557eabe92 in RegionView::canvas_group_event(_GdkEvent*) (this=0x555559cd2040, event=0x7fffffffc1d0) at ../gtk2_ardour/region_view.cc:277
0000013 0x00005555580ac4d5 in sigc::bound_mem_functor1<bool, TimeAxisViewItem, _GdkEvent*>::operator()(_GdkEvent* const&) const (this=0x555564c05e38, _A_a1=@0x7fffffffbf70: 0x7fffffffc1d0)
    at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:2066
0000014 0x00005555580abf85 in sigc::adaptor_functor<sigc::bound_mem_functor1<bool, TimeAxisViewItem, _GdkEvent*> >::operator()<_GdkEvent* const&>(_GdkEvent* const&) const
    (this=0x555564c05e30, _A_arg1=@0x7fffffffbf70: 0x7fffffffc1d0) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:89
#15 0x00005555580ab620 in sigc::internal::slot_call<sigc::bound_mem_functor1<bool, TimeAxisViewItem, _GdkEvent*>, bool, _GdkEvent*>::call_it(sigc::internal::slot_rep*, _GdkEvent* const&)
    (rep=0x555564c05e00, a_#0=@0x7fffffffbf70: 0x7fffffffc1d0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:451
0000016 0x000055555815d56f in sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::operator()(sigc::slot<bool (_GdkEvent*), sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil> const&) const (this=0x7fffffffbe48, _A_slot=...) at /usr/include/sigc++-2.0/sigc++/signal.h:860
#17 0x000055555815cb49 in sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool>::operator*() const
    (this=0x7fffffffbe00) at /usr/include/sigc++-2.0/sigc++/signal.h:319
0000018 0x000055555815be8f in ArdourCanvas::Item::EventAccumulator<bool>::operator()<sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool> >(sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool>, sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >, bool>) (this=0x7fffffffbe6f, first=..., last=...) at ../libs/canvas/canvas/item.h:257
0000019 0x000055555815b0b8 in sigc::internal::signal_emit1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::emit(sigc::internal::signal_impl*, _GdkEvent* const&)
    (impl=0x5555654228d0, _A_a1=@0x7fffffffbf70: 0x7fffffffc1d0) at /usr/include/sigc++-2.0/sigc++/signal.h:879
0000020 0x000055555815a101 in sigc::signal1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::emit(_GdkEvent* const&) const
    (this=0x555566f6c490, _A_a1=@0x7fffffffbf70: 0x7fffffffc1d0) at /usr/include/sigc++-2.0/sigc++/signal.h:2955
0000021 0x0000555558159527 in sigc::signal1<bool, _GdkEvent*, ArdourCanvas::Item::EventAccumulator<bool> >::operator()(_GdkEvent* const&) const
    (this=0x555566f6c490, _A_a1=@0x7fffffffbf70: 0x7fffffffc1d0) at /usr/include/sigc++-2.0/sigc++/signal.h:2971
0000022 0x00007ffff5849c8f in ArdourCanvas::GtkCanvas::deliver_event(_GdkEvent*) (this=0x55555e49fcb8, event=0x7fffffffc1d0) at ../libs/canvas/canvas.cc:866
0000023 0x00007ffff584b915 in ArdourCanvas::GtkCanvas::on_motion_notify_event(_GdkEventMotion*) (this=0x55555e49fcb8, ev=0x55555873fad0) at ../libs/canvas/canvas.cc:1238
#24 0x00007ffff4500df4 in Gtk::Widget_Class::motion_notify_event_callback(_GtkWidget*, _GdkEventMotion*) () at /lib/x86_64-linux-gnu/libgtkmm-2.4.so.1
0000025 0x00007ffff4b391ab in  () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000026 0x00007ffff505f0a2 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000027 0x00007ffff5070e6e in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000028 0x00007ffff5077259 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000029 0x00007ffff5077c3f in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
0000030 0x00007ffff4c58fe4 in  () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000031 0x00007ffff4b377d4 in gtk_propagate_event () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000032 0x00007ffff4b37c4b in gtk_main_do_event () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
(0027315)
x42   
2023-02-08 00:01   
Fixed in 7.2-239-g48efbb4cc5

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9224 [ardour] bugs minor always 2023-02-04 18:30 2023-02-07 05:16
Reporter: SethTanner Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: high OS Version: 10.12 or later  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Way Distorted Audio After Stopping Ardour in the Audio/MIDI Setup to Change from Headphones to Line Out
Description: I had about 13 midi tracks, then tired of listening to my headphones, and stopped Ardour with the "Audio/MIDI Setup" window, changed from my Headphones to another Line Out, and upon doing so, the audio was horrid, way distorted.

I assumed my signal or external speakers (monitor) was incapacitated for playback. I stopped Ardour again, and went back to headphones, but the problem of massively distorted audio persisted.

I found no way around this except by deleting the most recent track I'd added. That solved it. I then swapped back to external speakers and once again, distortion.

I quit Ardour and opened it anew, and then the audio plays just fine directed to the external speakers, or that line out.

So, in a nutshell, my audio signal of my composition goes horrid if I swap my line out back and forth from headphones to external speakers (one Line out to another line out from my Mac Pro, (2010 Model) running 10.12.6 (Sierra).
Tags: audio, Audio Output Device, Audio/MIDI setup, AudioSignalDistortion, distortion, signal
Steps To Reproduce: With this file or composition, all it takes is stopping Ardour with the Audio/MIDI Setup to change my audio output device.
Additional Information: This is running Ardour 7.2.0
Mac Pro, (2010 Model) running 10.12.6 (Sierra).
System Description
Attached Files: Screen Shot 2023-02-06 at 10.10.44 PM.png (66,818 bytes) 2023-02-07 05:12
https://tracker.ardour.org/file_download.php?file_id=4374&type=bug
png

Screen Shot 2023-02-06 at 10.13.37 PM.png (84,649 bytes) 2023-02-07 05:16
https://tracker.ardour.org/file_download.php?file_id=4375&type=bug
png
Notes
(0027277)
x42   
2023-02-05 01:46   
Does it help to stop/restart the engine? Ardour Menu > Window > Audio/MIDI Setup?

In the "output device" dropdown are there both line-out and headphone listed ?

I recall that older macbooks have separate "devices" for headphone and line-out - rather than a single soundcard that has both.
(0027307)
SethTanner   
2023-02-07 05:12   
The problem arises when I do stop the engine, the start it anew after having swapped from Headphones to line out (to listen on speakers rather than headphones).

Attached is a screenshot of the System Preferences listing of "Headphones" which are plugged into the jack in the front of my 2010 Mac Pro.
(0027308)
SethTanner   
2023-02-07 05:16   
In Ardour, it does not list as "headphones" but is the first of the listed in the drop down as shown in this screenshot.

So, if I stop the Ardour engine, to change the output of audio, starting back up, then playing my MIDI, brings forth a horrendous distortion in the MIDI playback. It seems quitting the program and restarting is the solution that seems to work. By preference, unless necessary, I prefer to listen on external monitors, but at times, I'm forced to go to headphones.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9222 [ardour] bugs minor always 2023-02-04 04:26 2023-02-07 01:15
Reporter: rastin Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cursor unresponsive when in editor timeline below all tracks
Description: In the editor view, there is a thin line that follows your cursor (or snaps to nearest grid if grid snap is enabled). This line freezes in place if the mouse cursor goes below the last track in the project. Once in this frozen state, the line does not follow the cursor even when moving the mouse back onto a track. It does, however, unfreeze if the mouse goes onto the main UI at the top or onto the track's fader/mute/solo/automation/group header. See attached animated gif for this behavior.

Related, though possibly a different bug -- when in that frozen state, using the keyboard allows switching between grab mode, range mode, and cut mode, but switching to draw or edit disables the keyboard from choosing grab, range, or cut until unfrozen.
Tags:
Steps To Reproduce: 1) open any project or create a new project
2) go to the editor view
3) move the mouse over any track on the timeline and notice that the thin ruler follows the mouse
4) move the mouse below all other tracks and notice that the ruler no longer follows the mouse
Additional Information: I'm unsure if this is unique to my system/graphics setup, so here's some info just in case.

Ardour7.2.200 (built using 7.2-200-g51e93399ba and GCC version 12.2.1 20230111)
CPU: quad core Intel Core i7-4790K (-MT MCP-)
Kernel: 6.1.7-1-MANJARO x86_64
Graphics:
  Device-1: NVIDIA GM204 [GeForce GTX 980] driver: nvidia v: 525.85.05
  Display: x11 server: X.Org v: 21.1.6 with: Xwayland v: 22.1.7 driver: N/A
    resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6.0 NVIDIA 525.85.05 renderer: NVIDIA GeForce GTX
    980/PCIe/SSE2
System Description
Attached Files: Peek 2023-02-03 22-10.gif (235,704 bytes) 2023-02-04 04:26
https://tracker.ardour.org/file_download.php?file_id=4365&type=bug
gif
Notes
(0027304)
x42   
2023-02-07 01:15   
Fixed in Ardour 7.2-238 2b64c4afe4

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9227 [ardour] features minor have not tried 2023-02-06 17:00 2023-02-06 17:00
Reporter: cooltehno_bugs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: The separete color Item for the LOG Error massage (divide the gtk_bright_indicator)
Description:  In the current situation the color item :"gtk_bright_indicator" is used for the track header outline and for the LOG Error massage together. For the Dark theme - there's no problem - the red color fits to the both targets well.
 But for the Bluererry-Milk, Cubasish and UnaStudia - this makes obstacle. It could be better to alert about the Errors in the LOG window with the red color - but if we change the "gtk_bright_indicator" to the red color - this makes the track header outline also red (that is not appropriate for these themes (of course IMHO)).
 May be (If it is possible) - a separate Item for the LOG Error massage color could resolve the problem.
ThankS!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: LOG_error_massage_red_color.png (414,511 bytes) 2023-02-06 17:00
https://tracker.ardour.org/file_download.php?file_id=4372&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9219 [ardour] bugs crash sometimes 2023-02-02 10:56 2023-02-03 09:28
Reporter: Werner Back Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour / Mixbus open after close crash
Description: After closing a project and trying to open another project, mixbus disappears immediately, ardour does crash sometimes, both without any further message. In my test scenario I did not have any plugins in use.
I couldn't get ardour to crash without plugins or with ACE plugins, I usually use LSP plugins, which leads to crashes sometimes (not always).
Mixbus (8.2.151) crashes even without any plugins in use except the built-in ones.
Tags: 8.2, close, crash, MIxbus, open
Steps To Reproduce: Create 2 projects, I used the factory templates in Mixbus. Open the first project, make some changes, close & save. Choose the other project in the selection (I did via doubleclick) -> crash (mixbus dissapears).
Additional Information:
System Description
Attached Files: Mixbus.tar.gz (200,104 bytes) 2023-02-03 09:28
https://tracker.ardour.org/file_download.php?file_id=4364&type=bug
Notes
(0027266)
x42   
2023-02-03 02:05   
Can you upload the project that causes the issue? zip up the folder and attach it here (or if it is too large use dropbox, onedrive or similar). Thanks.
(0027272)
Werner Back   
2023-02-03 09:28   
Here is the archive, I packed both projects into it (with folders, I hope that's OK).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9212 [ardour] bugs minor always 2023-01-29 17:21 2023-02-03 04:24
Reporter: sollapse Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST3 parameter issue in bx Console SSL 9000
Description: The 'console channel' parameter for the bx console SSL 9000 VST3 cycles between is high range while scrolling through the values. The GUI fails to step through the values properly, and the behavior is seen clearly using the automation track.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: params_sm.gif (865,293 bytes) 2023-01-29 17:24
https://tracker.ardour.org/file_download.php?file_id=4361&type=bug
Notes
(0027254)
sollapse   
2023-01-29 17:24   
(0027258)
sollapse   
2023-01-30 01:29   
Also occurs with Pro-Q 3

<iframe src='https://gfycat.com/ifr/EminentWelcomeGartersnake' frameborder='0' scrolling='no' allowfullscreen width='640' height='470'></iframe>
(0027259)
sollapse   
2023-01-30 01:54   
Posted link instead: https://gfycat.com/ifr/EminentWelcomeGartersnake
(0027268)
x42   
2023-02-03 04:24   
Thanks for bringing this to our attention. Almost unbelievable that this was not reported before!

Those were two separate issues. the " bx Console SSL 9000" relates to integer step controls, and the Pro-Q issue was due to range mismatch: internally all parameters are normalized to 0..1 range.
Ardour informed the UI about the normalized value 0..1 rather than actual frequency value (in Hz).

It seems that most other VST3 plugins always used the range 0..1 both internally and as 'actual' value (like VST2) and hence were not affected by this.

Both issue are now fixed since 7.2-191-gdac8feb98b

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9218 [ardour] bugs crash always 2023-02-01 16:23 2023-02-03 03:47
Reporter: enorrmann Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when adding plugin to a midi track containing a synth
Description: Start a new project, add Surge XT plugin to a midi track, then try to add another midi plugin like midi chord by Robin Gareus, ardour crashes with
ardour-7.0.17: ../libs/ardour/plugin_insert.cc:2071: virtual bool ARDOUR::PluginInsert::configure_io(ARDOUR::ChanCount, ARDOUR::ChanCount): Assertion `get_count () > 1' failed.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027267)
x42   
2023-02-03 03:47   
Thanks!
Fixed in 7.2-189-g830dfdda24

(Note this is not an issue if you directly add the plugin before Surge.)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9220 [ardour] features minor always 2023-02-02 23:27 2023-02-02 23:27
Reporter: Attila S. Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make the "Panner" optional/hideable/minimizable
Description: Please make the "Panner" optional/hideable/minimizable or something like these because it can unnecessarily occupy valuable screen space on smaller monitors/laptops, especially with quad+ config. See on the attached screenshot.

Thank you in advance for considering this.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: panner.png (32,556 bytes) 2023-02-02 23:27
https://tracker.ardour.org/file_download.php?file_id=4363&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9213 [ardour] bugs minor always 2023-01-29 23:06 2023-02-01 01:41
Reporter: Yruama_Lairba Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cue markers are ignored in some occasion
Description: In some occasion, Cue markers are ignored
Tags:
Steps To Reproduce: - start a new empty project
- create a new audio (or midi) track
- got to Cue windows
- in the audio track, load a clip into a cue slot, lets say cue A for the example
- select cue a of the track and set Follow options to again
- go to the editor view
- in cue markers lanes add a "cue A" marker at the beginning, that is Measure 1, Beat 1
- add a "stop all cues" marker at measure 3, Beat 2
- play project from beginning

expected: at end of measure 3 the Cue A should stop to play
result: at end of measure 3, the Cue A continue to play
Additional Information: i'm unable to join a project example
System Description
Attached Files:
Notes
(0027255)
Yruama_Lairba   
2023-01-29 23:17   
sorry, forgot some important things:
- tempo should be set at 180 bpm exactly
- sampling rate is 44,1khz (didn't try other sampling rates)
(0027256)
Yruama_Lairba   
2023-01-29 23:47   
missing another parameter, the problem occur with a buffer size of 256 samples. It doesn't occur with a size of 1024. I didn't yet try another buffer size
(0027257)
Yruama_Lairba   
2023-01-30 00:05   
for some obscure reason, i can't join a file to a message, so here is a onedrive link to a project where the issue occur:
https://1drv.ms/u/s!Ao9-ll0yecywgTDanL-TwjcCluX4?e=2n2dWR
(0027265)
paul   
2023-02-01 01:41   
Fixed in commit df3b8efbb96

Thanks for finding the precise circumstances required to trigger this bug.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6768 [ardour] features minor N/A 2016-02-11 00:37 2023-01-31 19:49
Reporter: timbyr Platform:  
Assigned To: timbyr OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Zoom Editor track area/canvas by clicking and dragging in the ruler
Description: Some other DAW's have the ability to zoom by clicking and dragging in a certain area of the canvas. In Ableton and Cubase this is in the ruler area.

I'm reporting this issue to see if there is any interest in having similar functionality in Ardour.

I prefer to use this functionality to zoom in those applications as it allows me to use the "nipple" on my laptop to zoom without moving my hands out of position.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: ruler-drag-zoom.webm (3,679,162 bytes) 2016-02-11 00:40
https://tracker.ardour.org/file_download.php?file_id=2867&type=bug
Notes
(0017902)
timbyr   
2016-02-11 00:41   
I uploaded a short video to demonstrate what I mean.
(0017904)
timbyr   
2016-02-11 01:00   
(Last edited: 2016-02-11 01:01)
One concern with this sort of functionality is that the performance of the canvas, as with a lot of items it can really slow the zooming operation down to the point of being almost useless.

(0018581)
timbyr   
2016-09-09 12:03   
I have a small series of changes that implements this functionality as an option that is off by default.

If there is no negative feedback I will commit the changes so that the functionality can at least be tested.
(0018893)
cooltehno_bugs   
2016-10-31 15:08   
Great feature! How it would be nice to see it committed)
(0018936)
timbyr   
2016-11-11 04:23   
This feature has been committed to master branch as of revision 5.4-317-gdac2d41 and so can be tested in a nightly >= 5.4.317

It is enabled via Preferences -> Editor -> Use time rulers area to zoom when clicking and dragging vertically

Feedback welcome.
(0018941)
rutsch   
2016-11-12 09:16   
(Last edited: 2016-11-12 09:19)
Excellent! Works great for me. Now add scrolling instead moving the playhead when moving left or right and this is perfect.

Edit: I see, it's scrolling when going to the left and right border.

(0018942)
timbyr   
2016-11-12 11:07   
Yes, it should scroll when moving the mouse to the edge of the track canvas area.

I think there might be a few tweaks to improve it.

One would be if there was a vertical drag threshold that had to be passed in order for zooming to start so that if you just click up in the ruler it doesn't zoom unless you drag the mouse a few pixels.

The other would be to see if only zooming when the mouse moves vertically every two or three pixels instead of every pixel would improve the issue with the delay in redrawing the waveforms.

I'll try to play around with these ideas when I get time. Let me know if you can think of anything else.
(0018943)
rutsch   
2016-11-12 15:15   
Sounds good, nothing to add from me at this time.
(0018954)
cooltehno_bugs   
2016-11-13 21:46   
Thanks for contribution!
After night-build testing I've got two Ideas:

1) It could be very comfortable (from Bitwig using):
- Click+drag vertically - zooms in/out;
- Click+drag horizontally - shifts right/left.

The horizontal shifting by clicking&dragging - could be nice for your Ardour's feature!

2) The playhead goes with clicking in the area of the canvas - it's not comfortable. It would be nice to zoom and shift no effecting the playhead position. Or may be for zooming/shifting - to use a middle mouse button (left m.button - to leave for playhead positioning).
(0018960)
timbyr   
2016-11-14 03:31   
I don't have access to Bitwig but I'm assuming this zoom/scroll operation you are describing has the same behaviour as in Ableton Live.

The way it is implemented currently was based on the behaviour in Cubase.

After using Ableton Live lite for a bit to test, I think I prefer its behaviour (and your suggestion) that it also scroll and that it not manipulate the playhead position. It seems to make navigation much easier and predictable when scrolling than trying to move the cursor to the side of the canvas to scroll.

It will probably be a bit more complicated to implement and I'll wait for some more feedback on the current behaviour before investing any time in changing it.
(0027238)
arpad.jakab@outlook.hu   
2023-01-25 10:38   
Hi! The vertical dragging of the mouse starting in the time ruler is working opposite to what Ableton Live has. I have in my fork reversed the direction. The best explanation why this is better than in the current version is that: (1) one has to drag the mouse up to zoom in, and the screen top sets a limit to the zoom, and one has to repeat the movement for more in-depth zooming. (2) when dragging down the mouse pointer will be exactly where I want it to have it: above the zoomed in tracks.
(0027252)
timbyr   
2023-01-29 09:18   
(Last edited: 2023-01-29 09:18)
The current mouse drag zoom behaviour in Ardour is not the same as when I implemented the feature and the zoom direction was inverted. The current behaviour of dragging up to zoom in is not useful to me.
(0027264)
arpad.jakab@outlook.hu   
2023-01-31 19:49   
Obviously we agree on that this zooming behavour is unwanted and changing it would be good. Since I've just joined the Ardour development, I'll take a little time before I'll als for a pull request, but I'll do it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9214 [ardour] bugs crash always 2023-01-30 11:21 2023-01-30 11:21
Reporter: Hanry Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashing when stopping the recording
Description: I record a few tracks and all of a sudden at the end of a recording it crashes and leaves me without my last take.
It has been an issue with all of the ardour versions I used (since at lease 5).
I am using qjackctl as the jack driver.
also having some vsts like pianoteq and drumgizmo.
Tags: 7.2, Butler drops pool trash, crash, Graph::drop_threads(), recording
Steps To Reproduce: open a new session, start recording (audio or midi doesn't matter) give it a nice 5 min track. open a new track and record till you find the perfect take, then it will crash leaving you without that awesome take you did.
that's pretty much it.
Additional Information: I followed the instructions about getting the debug errors, I hope it helps
System Description
Attached Files: ardour72.txt (137,694 bytes) 2023-01-30 11:21
https://tracker.ardour.org/file_download.php?file_id=4362&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9210 [ardour] features feature have not tried 2023-01-28 17:07 2023-01-28 17:07
Reporter: benald Platform: Microsoft  
Assigned To: OS: Windows  
Priority: low OS Version: 11  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Standard keyboard editing in track comments, plz
Description: Ctrl C,Z and V in Windows. Thanks.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9209 [ardour] features minor have not tried 2023-01-28 14:56 2023-01-28 14:56
Reporter: benald Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Could we have editable names for automation controllers plz?
Description: This would lovely, and, thrice, lovely. XXX
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9207 [ardour] bugs major always 2023-01-24 17:33 2023-01-25 12:38
Reporter: benald Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Splitting more than two midi regions (with control data and at the same playhead position) renders project unrecoverable
Description: I have three midi tracks, each with control data tracks. I found a region I wanted to copy and paste to repeat. I had serious issues doing this (see my bug report from earlier today - 24th January 2023 - link below) so I thought I might be able to achieve what I wanted by splitting each track at the start region point and the end region point. Every time I did this I could copy and paste the region once or twice before the project crashed. If I pasted the copied region just once and saved it, closed Ardour and tried to reopen the project Ardour would hang at the screen grab supplied.
I repeated this process many times and the found the fault to be consistent.
In order to narrow down the failure point I decided I would save the project at each of the six split points, save the project and try and reopen it. I was able to re open the project twice (after the first and second splits). The screen grabs are:-
1) Snip 1 (before project saved and reopened successfully)
2) Pre snip 2
3) Snip 2 (before project saved and reopened successfully)
4) Pre snip 3
4) Snip 3 (before project saved and could no longer be opened)
My bug report from earlier today: https://tracker.ardour.org/view.php?id=9204
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0027230)
benald   
2023-01-24 17:56   
1) Snip 1 (before project saved and reopened successfully)
2) Pre snip 2
3) Snip 2 (before project saved and reopened successfully)
4) Pre snip 3
4) Snip 3 (before project saved and could no longer be opened)
(0027233)
benald   
2023-01-24 18:52   
I'll try again to upload the screen shots. I'm on holiday in a rural area at the moment and the internet isn't great...
(0027240)
benald   
2023-01-25 12:38   
Update: I have successfully split three midi tracks in two places each - containing ten automation tracks between them. The project could then be successfully saved and reloaded. The difference between this case and the case in which saving the project after the total six track splits (or, more likely, I think - any split in a third track), saving the project and the project being unrecoverable appears to be the eight further automation tracks (all of the automation associated with the third midi track) being cleared. This suggests to me that there is a tipping point somewhere between a total of ten and eighteen automation tracks in my setup.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9205 [ardour] bugs minor have not tried 2023-01-24 15:07 2023-01-24 17:44
Reporter: Sinuslabs Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Plugin crashes in Ardour with "X Error of failed request: BadWindow (invalid Window parameter)" on Plugin Scan
Description: Hello Ardour Team,
I am a Plugin Developer who is also releasing on Linux. My Plugin runs fine but I have a customer reporting a issue with Ardour on VOID Linux. This crash is not happening in other DAWs only in Ardour. I am unable to reproduce this issue with my own System and do not know where to start to solve this. The customer is running X11.

The Plugin I am developing is open source and can be found here: https://github.com/Sinuslabs/Reach

VST3 module-path '/home/rutsch/.vst3/Reach.vst3/Contents/x86_64-linux/Reach.so'
[Info]: Scanning: /home/rutsch/.vst3/Reach.vst3
X Error of failed request: BadWindow (invalid Window parameter)
  Major opcode of failed request: 20 (X_GetProperty)
  Resource id in failed request: 0x0
  Serial number of failed request: 54
  Current serial number in output stream: 54
Scan Failed.
Tags: 7.2, VST3, window, x11
Steps To Reproduce: Add Plugin to .vst3 folder
Open Ardour in Void Linux
Scan Pluginins
Fails
Additional Information:
System Description
Attached Files:
Notes
(0027224)
Sinuslabs   
2023-01-24 15:53   
The problem was solved by the customer by installing the xsettingsd package and creating a empty config file. Afterwards Ardour was able to successfully scan the Plugin.
(0027225)
paul   
2023-01-24 16:06   
Those errors typically happen when a thread that is not the main GUI thread attempts to draw.

Most/all applications on Linux use a single-threaded GUI (even when there are multiple other threads), and drawing from other threads will always cause issues.

Can you comment on whether or not this could be the case in your plugin?
(0027226)
Sinuslabs   
2023-01-24 16:09   
No my plugin is using a single thread for the GUI and runs the DSP on the other threads.
(0027229)
paul   
2023-01-24 17:44   
Your plugin works without errors here on my system (Debian 11). The issue would appear to be user-specific.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9061 [ardour] bugs minor always 2022-11-01 08:51 2023-01-24 12:06
Reporter: surfinspots Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Undefined state while midi recording and pressing "arrow left"
Description: When recording MIDI (I've tried it with an audio track and there it works) and pressing arrow-left the playback line stops and it seems that
Ardour is a bit in an undefined state.
The "stop" button doesnt work anymore.
The "ruler" becomes messed (I added a screenshot).
Tags: 7.2, Midi, record
Steps To Reproduce: - MIDI Track on record
- start recording
- pressing left-arrow key

Additional Information:
System Description
Attached Files: ardour-midi-record-arrow-left-bug.png (11,606 bytes) 2022-11-01 08:51
https://tracker.ardour.org/file_download.php?file_id=4271&type=bug
png

ardour-bug-2023-01-21_10.03.07.mp4 (435,868 bytes) 2023-01-21 09:06
https://tracker.ardour.org/file_download.php?file_id=4351&type=bug
Notes
(0027219)
surfinspots   
2023-01-21 09:06   
this seems not be fixed in the actual master. So I maybe I need to provide a video.
In this video I only press the global record button with the mouse and the arrow right button while recording so the play head jumps back. As you may see ... the scale is becoming corrupt and the recorded regions in the midi track have been deleted on pressing arrow back.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9202 [ardour] bugs minor always 2023-01-20 20:23 2023-01-21 00:41
Reporter: rastin Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: missing print() messages in lua dsp processor
Description: When using the print() function from within a lua dsp processor, the printed messages do not reach the log until something else prints a message.
Tags:
Steps To Reproduce: 1) Load any lua dsp processor that calls print() anywhere, such as in dsp_init, dsp_configure, or dsp_run
2) Notice that nothing appears in Ardour's log
3) Load any lua session script that calls print()
4) Notice that all of the print messages from 1) now appear in the log and the first printed message from 3) is missing its time stamp.
Additional Information: Skimming through Ardour's code, I wonder if an endmsg is missing on line 206 of luaproc.cc which reads as follows.
PBD::info << "LuaProc: " << s << "\n";

A similar line in session.cc (line 5249) has endmsg, and lua session scripts have no issue using print().
PBD::info << "LuaSession: " << s << endmsg;

System Description
Attached Files:
Notes
(0027208)
x42   
2023-01-21 00:41   
Thanks. Fixed in 7.2-128-g7e4bb2ff68. Keep in mind that print() is not realtime-safe and should only be used for debugging.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9193 [ardour] bugs major always 2023-01-06 16:22 2023-01-20 16:15
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Errors export to mp3
Description: i exportet a very small project with 5 audio and 2 midi tracks. As mp3 always sound interrupts - as wav it works.
Same on "quick audio export and normal export as mp3.
On every export there are errors in the file - like a corrup mp3.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027164)
x42   
2023-01-06 16:30   
Are you using Ardour 7.2.0 from ardour.org or a nightly version or a distro build?

After export can you view Window > Log. and copy the "Encode command: ..."
(0027165)
stefan-franz   
2023-01-06 16:48   
2023-01-06T17:44:38 [INFO]: Encode command: { /opt/Ardour-7.2.85/bin/ffmpeg_harvid -f f32le -acodec pcm_f32le -ac 2 -ar 44100 -i pipe:0 -f mp3 -acodec mp3 -q:a 2 -metadata comment=Created with Ardour -y /home/stefan/Studio/Ardour Projekte/110 Eigene Songs/Ole - Master/Ole - Stefan Franz-03/export/Ole - Stefan Franz-03.mp3 }

Here is the export 0:44 you hear it
https://nco.stefan-franz.de/index.php/s/JicbMmjY5QZt8D2
(0027186)
x42   
2023-01-17 15:21   
We believe this is fixed in 7.2-112.

I was not able to reproduce this myself, but some macOS users who also experience this issue confirmed a fix. Please test!
(0027202)
stefan-franz   
2023-01-19 07:52   
With 7.2.123 it works. Fixed. Thanks.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9142 [ardour] bugs minor always 2022-12-04 13:46 2023-01-18 13:31
Reporter: noedig Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI automation drawing is offset after tempo change
Description: When drawing in a region's automation lane for a MIDI parameter, when there has been a tempo change prior to that region, the drawing input is offset, i.e. when clicking to add a new automation node, the new node does not appear at the click position.
Tags: automation, draw, Midi, tempo change
Steps To Reproduce: 1. Create a midi track with two midi regions.
2. In-between the regions, create a tempo change marker, so the first region is in 120bpm and the second region is in e.g. 180 bpm.
3. Enable a midi parameter automation lane for the track, e.g. Bender or CC.
4. In draw mode, drawing in the first region's automation area works fine. Drawing in the second region's automation area (after the tempo change) does not work correctly. When clicking to add nodes, they are offset i.e. do not appear where clicked.
Additional Information: Forum post with gif screenshots:
https://discourse.ardour.org/t/midi-bender-automation-drawing-glitches/107986
System Description
Attached Files: Peek 2022-12-04 15-31 Ardour bender automation 2.gif (559,303 bytes) 2022-12-04 13:46
https://tracker.ardour.org/file_download.php?file_id=4317&type=bug
automation_tenpo_change_glitch.gif (292,132 bytes) 2022-12-04 16:45
https://tracker.ardour.org/file_download.php?file_id=4318&type=bug
ardour automation 2022-12-08.gif (316,004 bytes) 2022-12-08 12:08
https://tracker.ardour.org/file_download.php?file_id=4319&type=bug
Notes
(0026979)
paul   
2022-12-04 14:52   
Could you please try a nightly build, because I believe this is already fixed.
(0026980)
cooltehno_bugs   
2022-12-04 16:45   
Ardour 7.1.211 Nightly - can confirm the same bug
(0026981)
noedig   
2022-12-04 17:09   
Confirmed here too, bug is still in nightly v7.1-211 2022-12-04
(0026984)
paul   
2022-12-05 21:55   
fixed in commit 1728b691
(0027000)
noedig   
2022-12-08 12:08   
Drawing nodes in the second region (after the tempo change) works now (nightly Ardour-7.1.239-dbg-w64).
However, there is still this odd behaviour (see attached gif): when moving an existing node, and then inserting a new one, the former node position jumps.
(0027188)
Arello   
2023-01-18 13:06   
I think I still have this same issue on 7.2. (Debian 10)

I followed these steps to reproduce the problem:
1) make automation pattern on some MIDI parameter (like bend),
2) move the MIDI region elsewhere (not sure if relevant),
3) make a tempo change in the project before MIDI region,
4) try to add or edit automation point to different location (you'll see effects when it doesn't align with the snap setting and zooming in/out shows it gets messed up)
(0027189)
Arello   
2023-01-18 13:31   
To clarify my previous comment: It seems that editing the the already drawn points is the bigger issue. They still get misplaced after tempo change. Drawing new points somewhat works for me.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9200 [ardour] bugs crash always 2023-01-13 17:20 2023-01-13 17:21
Reporter: ercling Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Rescan All dialog crash on wayland
Description: When I go to Plugin manager -> Rescan All -> Yes a crash happens. The console output is below:

The program 'ardour-7.2.0' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 53053 error_code 3 request_code 38 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Tags:
Steps To Reproduce: 1. Start an empty session
2. Open Window -> Plugin manager
3. Press Rescan All button inside the plugin manager window
4. Press Yes in Are you sure you want to rescan all plugins? dialog
5. Receive crash immediately
Additional Information: I reproduced the bug on a freshly installed Fedora 37 Workstation with all updates installed. I used the default GNOME session on wayland.

The crash does NOT happen in the GNOME session on X.org

GDB logs:

[Thread 0x7fffb4fff6c0 (LWP 51497) exited]
[New Thread 0x7fffb4fff6c0 (LWP 51521)]
[New Thread 0x7fff9f7fe6c0 (LWP 51522)]
[New Thread 0x7fff9effd6c0 (LWP 51523)]
[New Thread 0x7fff9dffb6c0 (LWP 51524)]
[New Thread 0x7fff9e7fc6c0 (LWP 51525)]
[Detaching after vfork from child process 51526]
[New Thread 0x7fff9d7fa6c0 (LWP 51527)]
[Thread 0x7fff9d7fa6c0 (LWP 51527) exited]
[Detaching after vfork from child process 51528]
[New Thread 0x7fff9d7fa6c0 (LWP 51529)]
[Thread 0x7fff9d7fa6c0 (LWP 51529) exited]
[Thread 0x7fff9f7fe6c0 (LWP 51522) exited]
[Thread 0x7fff9dffb6c0 (LWP 51524) exited]
[Thread 0x7fff9effd6c0 (LWP 51523) exited]
[Thread 0x7fffb4fff6c0 (LWP 51521) exited]
Set cursor set to default
[New Thread 0x7fff9d7fa6c0 (LWP 51530)]
[New Thread 0x7fffb4fff6c0 (LWP 51531)]
[New Thread 0x7ffff0dfe940 (LWP 51532)]
[New Thread 0x7ffff05fe940 (LWP 51533)]
[New Thread 0x7ffff057a940 (LWP 51534)]
[New Thread 0x7ffff01fe940 (LWP 51535)]
[New Thread 0x7ffff017a940 (LWP 51536)]
[New Thread 0x7ffff00f6940 (LWP 51537)]
[New Thread 0x7fffefdfe940 (LWP 51538)]
[New Thread 0x7fffefd7a940 (LWP 51539)]
[New Thread 0x7fffefcf6940 (LWP 51540)]
[New Thread 0x7fffef9fe940 (LWP 51541)]
[New Thread 0x7fffef5fe940 (LWP 51542)]
[New Thread 0x7fffef57a940 (LWP 51543)]
[New Thread 0x7fffef4f6940 (LWP 51544)]
[New Thread 0x7fffeedfe940 (LWP 51545)]
[New Thread 0x7fffeed7a940 (LWP 51546)]
[New Thread 0x7fffea1ff6c0 (LWP 51547)]
[New Thread 0x7fff9dffb6c0 (LWP 51548)]
[New Thread 0x7fff9effd6c0 (LWP 51549)]
[New Thread 0x7fff47fff6c0 (LWP 51550)]
locate to 0 took 246 usecs for 1 tracks = 246 per track
[New Thread 0x7fff4f7fe6c0 (LWP 51551)]
[Thread 0x7fffb4fff6c0 (LWP 51531) exited]
[Thread 0x7fff9d7fa6c0 (LWP 51530) exited]
The program 'ardour-7.2.101' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 25783 error_code 3 request_code 38 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[Thread 0x7fff4f7fe6c0 (LWP 51551) exited]
[Thread 0x7fff47fff6c0 (LWP 51550) exited]
[Thread 0x7fff9effd6c0 (LWP 51549) exited]
[Thread 0x7fff9dffb6c0 (LWP 51548) exited]
[Thread 0x7fffea1ff6c0 (LWP 51547) exited]
[Thread 0x7fffeed7a940 (LWP 51546) exited]
[Thread 0x7fffeedfe940 (LWP 51545) exited]
[Thread 0x7fffef4f6940 (LWP 51544) exited]
[Thread 0x7fffef57a940 (LWP 51543) exited]
[Thread 0x7fffef5fe940 (LWP 51542) exited]
[Thread 0x7fffef9fe940 (LWP 51541) exited]
[Thread 0x7fffefcf6940 (LWP 51540) exited]
[Thread 0x7fffefd7a940 (LWP 51539) exited]
[Thread 0x7fffefdfe940 (LWP 51538) exited]
[Thread 0x7ffff00f6940 (LWP 51537) exited]
[Thread 0x7ffff017a940 (LWP 51536) exited]
[Thread 0x7ffff01fe940 (LWP 51535) exited]
[Thread 0x7ffff057a940 (LWP 51534) exited]
[Thread 0x7ffff05fe940 (LWP 51533) exited]
[Thread 0x7ffff0dfe940 (LWP 51532) exited]
[Thread 0x7fff9e7fc6c0 (LWP 51525) exited]
[Thread 0x7fff9ffff6c0 (LWP 51456) exited]
[Thread 0x7fffb77ff6c0 (LWP 51421) exited]
[Thread 0x7fffbdbff6c0 (LWP 51420) exited]
[Thread 0x7fffce7fc6c0 (LWP 51417) exited]
[Thread 0x7fffceffd6c0 (LWP 51416) exited]
[Thread 0x7fffcf7fe6c0 (LWP 51415) exited]
[Thread 0x7fffcffff6c0 (LWP 51414) exited]
[Thread 0x7ffff47ff6c0 (LWP 51413) exited]
[Thread 0x7ffff4ffcdc0 (LWP 51174) exited]
[Thread 0x7ffff2178940 (LWP 51518) exited]
[New process 51174]
[Inferior 1 (process 51174) exited with code 01]
(gdb) thread apply all bt
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9099 [ardour] bugs minor always 2022-11-17 13:51 2023-01-13 15:28
Reporter: HirokiFutami Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: I cannot use Vital in Ardour 7.1.
Description: Nice to meet you. I would like to report a problem.

I am enjoying Ardour 7.1, but I have a problem.
It is that Vital installed in {.deb} format is not recognized by Ardour7.1.
Ardour 6.9 recognized them properly, but 7.1 does not show them in the plugin list no matter how much I scan.
This is probably a bug and I am reporting it.

I love Ardour, I use it all the time.
Thank you very much.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Ardour6.9_.png (12,130 bytes) 2022-11-20 00:27
https://tracker.ardour.org/file_download.php?file_id=4293&type=bug
png

Ardour7.1_.png (13,983 bytes) 2022-11-20 00:27
https://tracker.ardour.org/file_download.php?file_id=4294&type=bug
png
Notes
(0026897)
x42   
2022-11-17 14:56   
Where is the plugin installed to?
 Is it a LV2 or VST2? If the latter have you configured Ardour to search that location?
(0026902)
HirokiFutami   
2022-11-18 18:24   
Hello.

Yes, I have set up VST2 and VST3 folders to search, and both Ardour version 6.9 and 7.1 have the same search settings, but for some reason 7.1 is the only one that does not recognize Vital.

Of course, the version of Vital is the latest version currently available.
(0026903)
x42   
2022-11-18 20:39   
There should be no difference for VST3 plugins between Ardour 6.9 and 7.1 - so this is a bit of a mystery
Is there any information in Ardour's Plugin Manager when you scan for the plugin?

PS. there should be no need to set a custom VST3 path same for LV2 (only VST2 requires this).
(0026905)
HirokiFutami   
2022-11-20 00:27   
I'm sharing images from my scans with each of Ardour 6.9 and Ardour 7.1!

(I've been using the VST3 version for a long time because I couldn't figure out how to get the LV2 version to work.)
(0026906)
x42   
2022-11-20 00:58   
Select the Vital.vst3 and at the bottom the error message should show
(0026914)
HirokiFutami   
2022-11-20 10:54   
VST3 module-path '/usr/lib/vst3/Vital.vst3/Contents/x86_64-linux/Vital.so'
[Info]: Scanning: /usr/lib/vst3/Vital.vst3
[ERROR]: Could not load VST3 plugin '/usr/lib/vst3/Vital.vst3/Contents/x86_64-linux/Vital.so': /lib/x86_64-linux-gnu/libsecret-1.so.0: undefined symbol: g_task_set_name
Cannot load VST3 module: '/usr/lib/vst3/Vital.vst3/Contents/x86_64-linux/Vital.so'
Scan Failed.


I got the above message.
(0026915)
x42   
2022-11-20 12:51   
That looks like https://forum.vital.audio/t/not-working-on-linux-libraries-are-not-statically-linked/2194/13 is back.
(0026920)
HirokiFutami   
2022-11-21 10:37   
I saw the page you linked to.
Does this mean that the problem is on the Vital side and not Ardour?
Sorry if I am wrong X(
(0026994)
paul   
2022-12-08 00:56   
Yes, it is a problem with Vital not being statically linked. Consequently, it clashes with some hosts, because they both use different versions of the same software libraries. Plugins should always be statistcally linked.
(0027183)
HirokiFutami   
2023-01-13 15:28   
Understood.
Thank you very much for your kind attention!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9199 [ardour] features feature have not tried 2023-01-11 19:11 2023-01-11 19:11
Reporter: DonJaime Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Custom position for signal "out"
Description: Allow a setting custom position in the signal chain for track/bus output, just as there is already for disk I/O.

Use case: I want the dry signal to go to the master bus before I start applying delay and EQ prior to sending it to a reverb bus (with an aux send at the end of the chain).

Currently only doable with extra busses, which create clutter and move part of the control of the sound of an instrument awy from its own track.

Alternatively, allowing an "aux send" to send to master would work, but be less convenient because the track output would then have to be routed to the effect bus.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9190 [ardour] bugs major always 2023-01-04 17:42 2023-01-11 14:53
Reporter: mpk Platform: Redhat  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tempo change snaps incorrectly after n/8 time-signature (n is odd)
Description: It is not possible to place a tempo change on a non-whole quarternote position.
Tags:
Steps To Reproduce: 1. Enter time-signatures as per attached screenshot
2. Try to add a tempo-change at bar 3
Additional Information: May be related to https://tracker.ardour.org/view.php?id=9107
System Description
Attached Files: tempo-map-bug.png (10,392 bytes) 2023-01-04 17:42
https://tracker.ardour.org/file_download.php?file_id=4338&type=bug
png

tempo-map-bug.ardour (21,368 bytes) 2023-01-04 17:42
https://tracker.ardour.org/file_download.php?file_id=4339&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9185 [ardour] features feature always 2022-12-27 17:50 2023-01-10 22:04
Reporter: Blindekinder Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: won't fix  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bus automations should follow regions drag when selected
Description: This should be the case when selecting all, or all after/before edit point, etc.
Tags: automation
Steps To Reproduce: -create a session
-create some tracks
-import some sound, put the regions anywhere
-create a bus, or a group master bus
-create automations on tracks AND bus
-Ctrl+A to select all: all regions and automations are selected
-drag a region: all regions move, all tracks automations move, but not the bus automations
Additional Information:
System Description
Attached Files:
Notes
(0027168)
paul   
2023-01-10 15:03   
Busses do not have regions.Multiple tracks may feed a bus, with their own independent regions. There is no specific relationship between data on a track and anything that happens in a bus. Bus automation should always be thought of as independent of actual data.
(0027175)
Blindekinder   
2023-01-10 22:04   
I agree with that. I just wonder why all selected objects wouldn't move together.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9105 [ardour] bugs major always 2022-11-18 09:26 2023-01-10 21:06
Reporter: ksawerytreningowski Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: immediate OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Dosn't copy one quarter note C3 in a four bar region - several times
Description: After copying a four-bar region with one quarter note C3 several times, the copied regions are shifted one unit to the left

Multi-Duplicate
    Position End
1 001:01:0000 001:04:1919
2 001:04:1919 002:04:1918
3 002:04:1918 003:04:1917
4 003:04:1917 004:04:1916

Fill Track
    Position End
1 001:01:0000 001:04:1919
2 002:01:0000 002:04:1919
3 002:04:1919 003:04:1918
4 003:04:1918 004:04:1917

Same with Copy Paste and Drag&Drop
Tags: copy
Steps To Reproduce: Create a four-bar region with one quarter note C3. Multi duplicate it. or fill track
Additional Information:
System Description
Attached Files: Ardour Copy Regions.png (150,144 bytes) 2022-11-18 09:26
https://tracker.ardour.org/file_download.php?file_id=4292&type=bug
png
Notes
(0027008)
paul   
2022-12-10 17:34   
fixed in commit 4fdd8646b4bff, will be in release 7.2, out tomorrow or the day after. Thanks for noticing this!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9198 [ardour] bugs feature always 2023-01-10 05:12 2023-01-10 05:12
Reporter: P3P3 Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: high OS Version: 10.12 or later  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi Notes disappear from looped recording
Description: This is a continuation of a previous post: Midi Notes disappear from looped recording , where the midi notes disappear when recording in loop mode. They appear while recording, but vanish when I hit “Stop”. The track regions are still there, but they become empty.

This happens when recording an electric drum

Tags:
Steps To Reproduce: I connect an electric drum via USB cable and when I start recording the midi notes appear, but when I stop recording the midi notes disappear
Additional Information: i use ardour 7 en mac M1
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9197 [ardour] features minor always 2023-01-09 16:12 2023-01-09 16:23
Reporter: prokoudine Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: UX improvements for Step Entry dialog
Description: The Step Entry dialog currently has a few UX issues that would be nice to have fixed.

1. The keyboard could do with the same piano keys widget that is used in the Virtual Keyboard dialog where octaves are numbered and keys in C4-C5 are visibly mapped to shortcuts on the physical keyboard. Actually pressing keys works, but there is no visual feedback on the piano keyboard and no hint which key correspond to what shortcuts. So: please mark octaves and keys.

2. Being able to use shortcuts to set note duration would be rather helpful. E.g. Logic Pro uses 1 for 1/1, 2 for 1/2, 3 for 1/4 etc. Ardour could do the same and use 0 for toggling chord input. The hints about that could be displayed in tooltips on hover.

3. It might be useful to enhance tooltips for velocity presets and mention the exact velocity value that corresponds to ppp, mp, fff etc. E.g.: "Set volume to mezzo-forte (velocity 80)".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027167)
x42   
2023-01-09 16:23   
(2) should already be possible. See Window > Keyboard Shortcuts

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9195 [ardour] bugs major always 2023-01-07 16:08 2023-01-07 16:08
Reporter: mpk Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Not possible to drag Time Signature with lock style Audio to non-snapped position
Description: When initiating a drag on a Time Signature change (MeterMarkerDrag), snap is always turned on with grid mode bar, making it impossible to drop the marker freely. Once dropped, the Time Signature lock style has been changed to Music.
Tags:
Steps To Reproduce: 1. Add a time signature change with lock style = Audio
2. With or without snap mode active, drag the time signature marker to a new position
3. Snap mode with a bar grid will be engaged
4. When editing the moved time signature marker, note that its lock style has been changed to Music
Additional Information: This makes editing material which switches between strict tempo time and free time virtually impossible. Snap should not be automatically engaged when dragging Audio locked markers.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9188 [ardour] bugs major always 2023-01-03 14:49 2023-01-07 04:16
Reporter: dking952012 Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 11  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Plugin internal time not synced to Ardour in tempo change
Description: Plugins do not sync rhythmic and meter information to Ardour's general time in the case of tempo/meter changes. For example, a drumkit or LFO will sync with a song's beginning tempo, but will only sync with that tempo even after a new tempo has been entered. This is true even for regions not crossing the tempo change threshold (starting in the new tempo still syncs with the first). The same is true for meter changes. The plugins synced just fine with both things in 6.9. I have tested with two plugins on Windows 11 with Ardour 7.2:

Strike, by Air Music (VST2)

Vital (VST3)
Tags:
Steps To Reproduce: -New Session

-Add new tempo and change it (or time signature for meter issues)

-Create midi track

-Create midi region

-Create midi notes on both sides or one crossing tempo threshold

-Plugins do not recognize the changes
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0027166)
x42   
2023-01-07 04:16   
Fixed in 7.2-87-gebf7afc482

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9192 [ardour] bugs minor always 2023-01-05 17:15 2023-01-05 18:01
Reporter: mpk Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Trailing comma in config variable
Description: Line 165 in rc_configuration_vars.h includes a trailing comma in the variable name.

CONFIG_VARIABLE (bool, recording_resets_xrun_count, "recording-resets-xrun-count,", false)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027161)
x42   
2023-01-05 18:01   
Thanks! Fixed in 7.2.83

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9189 [ardour] bugs minor always 2023-01-04 14:54 2023-01-04 14:54
Reporter: Largos Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when bare midi track interacts with foldback bus
Description: With the assign selected tracks you assign a midi track to foldback bus but if there isn't a plugin with an audio connection it crashes. This also happens when you remove a plugin with an audio connection when the track it's on is connected to a foldback bus.
Tags:
Steps To Reproduce: 1. Create empty midi track
2. Create foldback bus
3. Assign empty midi track to foldback bus

and

1: Create midi track with an instrument plugin
2: Create foldback bus
3: Assign midi track to foldback bus
4: Remove instrument plugin from midi track.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9176 [ardour] features minor always 2022-12-19 23:47 2022-12-31 03:28
Reporter: paul Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: i/o names assigned in rec tab should show up in i/o menus
Description: ... instead of just "in 1" or "in 1+2" etc
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0027157)
Mek   
2022-12-31 03:28   
Mono channels seem to already behave this way for me? https://github.com/Ardour/ardour/pull/770 was my attempt to make stereo bundles also show up using pretty names rather than "in 1+2" (although currently in that PR it only uses pretty names if both channels have a pretty name).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9179 [ardour] bugs minor always 2022-12-21 00:20 2022-12-28 17:20
Reporter: sub26nico Platform: GNU/Linux  
Assigned To: OS: Librazik 4  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes after exporting if ‘Analyse Exported Audio’ in the Export window is selected
Description: Since version 7 (.0,.1 & .2), if ‘Analyse Exported Audio’ in the Export window is selected, Ardour crashes after export is done when clicking on ‘Close’ button in the ‘Export/Report Analysis’ window.
Tags:
Steps To Reproduce: Create a new session, import audio file then export the session, select ‘Analyse Exported Audio’ in the Export window then click on 'Export'. Once export is done, click on ‘Close’ button in the ‘Export/Report Analysis’ window.
Additional Information:
System Description
Attached Files: gdb (5,681 bytes) 2022-12-21 00:20
https://tracker.ardour.org/file_download.php?file_id=4332&type=bug
gdb2 (39,880 bytes) 2022-12-23 17:28
https://tracker.ardour.org/file_download.php?file_id=4335&type=bug
Notes
(0027132)
sub26nico   
2022-12-22 09:32   
Happen also without exporting, just using 'OnlyAnalyse', both with JACK or ALSA backend.
(0027133)
sollapse   
2022-12-22 16:01   
I'm experiencing the same crash after exporting audio as well.
(0027135)
x42   
2022-12-23 16:52   
@sub26nico can you reproduce the crash with a debug version and provide a backtrace?

(there should be function names instead of "??" on each line in the backtrace)
(0027136)
sub26nico   
2022-12-23 16:56   
@x42, i've made the backtrace (1st note) with a debug version (Ardour 7.2.32-dbg).
(0027137)
x42   
2022-12-23 17:05   
(Last edited: 2022-12-23 17:06)
odd. it looks like it was an optimized version (due to "in ?? ()") - sadly that backtrace is useless as-is :(
(0027138)
x42   
2022-12-23 17:08   
I see. you've used a core file without the corresponding source.

if you do not have the source-code, run ardour directly in gdb: `Ardour7 --gdb`
(0027139)
x42   
2022-12-23 17:10   
since I cannot reproduce it here

Does this happen with every session, or only some specific ones?
Does it happen if you disable translations?
(0027140)
sub26nico   
2022-12-23 17:11   
it happen for every session, and i have already disable translations. I re-made the backtrace with "Ardour7 --gdb' command line.
(0027141)
sub26nico   
2022-12-23 17:28   
@x42, new backtrace, i hope this one is good.
(0027142)
x42   
2022-12-23 17:30   
Yes, this is readable. thanks!
(0027146)
sub26nico   
2022-12-26 11:28   
I've tested on my laptop (same OS) and it doesn't happened. the laptop have an Intel cpu, the desktop have an AMD, don't know if it can be a useful information.
(0027149)
Blindekinder   
2022-12-27 17:29   
Issue also happens on Kubuntu 22.04.
(0027150)
x42   
2022-12-27 18:00   
Do you use ui-scaling? If so, Ardour 7.2.46 (or newer) might fix this.
(0027151)
Blindekinder   
2022-12-27 19:03   
indeed, my screen is (unfortunately) a 3840X2160, I changed both Kubuntu resolution and Ardour scaling.
(0027152)
sub26nico   
2022-12-27 20:31   
Yes, I use ui-scaling.
(0027154)
sub26nico   
2022-12-28 14:58   
Bug seems to be gone with ardour 7.2.54 (dbg), no more crash after export, analysis or Loudness Analyser and Normalizer.
Thanks.
(0027155)
sub26nico   
2022-12-28 17:20   
@x42, is that commit who fix the bug ?
https://github.com/Ardour/ardour/commit/140b373cace1c8c1aed26f44098d4f9a41d35174

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9184 [ardour] bugs minor always 2022-12-26 02:16 2022-12-28 12:22
Reporter: garyd Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: Mixbus 8.x  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Temporal" not recognised in Lua session script
Description: Attempting to use Temporal.timepos_t() in a session script fails with error: "attempt to index a nil value (field 'Temporal')"

It works fine in action scripts (Mixbus), also in session scripts in Ardour.
Tags:
Steps To Reproduce: Dummy session script is attached.
Additional Information:
System Description
Attached Files: session_script.lua (316 bytes) 2022-12-26 02:20
https://tracker.ardour.org/file_download.php?file_id=4336&type=bug
Notes
(0027145)
garyd   
2022-12-26 02:20   
Note sure if the attachment attached. Couldn't see it so attaching again.
(0027147)
x42   
2022-12-26 15:52   
Which version of Mixbus is that (Menu > Help > About)

For the new Tempo API to work correctly you need at least 8.1.700 or newer. Upcoming 8.2 should fix this as well.
(0027148)
garyd   
2022-12-27 02:36   
v8.1.378
Glad to hear it's already sorted. Thanks.
(0027153)
garyd   
2022-12-28 08:37   
Confirmed to be working in Mixbus32C v8.2.66. Thanks.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9186 [ardour] other feature N/A 2022-12-28 04:35 2022-12-28 04:35
Reporter: YackBackman Platform: Arch  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi control surface keymap preset for M-audio Oxygen Pro Mini
Description: A midi keymap for M-audio Oxygen Pro Mini that binds everything so the keyboard is usable in Ardour.
Tags:
Steps To Reproduce:
Additional Information: This keymap is made to be used in DAW mode, in the user preset.
System Description
Attached Files: M-audio Oxygen Pro Mini.map (3,048 bytes) 2022-12-28 04:35
https://tracker.ardour.org/file_download.php?file_id=4337&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6657 [ardour] bugs minor always 2015-10-28 01:09 2022-12-24 21:21
Reporter: yfkar Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 4.X git (version in description)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: NanoKONTROL2 does not get feedback from track record control and toggled controls in plugins
Description: Tested on revision 4.4-145-g3e3a5e1 with a nanoKONTROL2 in CC mode.

Issue: Pressing a button on the nanoKONTROL2 sends a CC message. The nanoKONTROL2 expects to receive the new status as a feedback CC message to update the corresponding status LED. This works on solo and mute for tracks but not for the record button. Feedback fails also when a nanoKONTROL2 button is bound to a toggled control in a plugin. However, the feedback is sent correctly if the control is toggled in Ardour instead of the midi device.
Tags:
Steps To Reproduce:
Additional Information: Looking at midicontrollable.cc, the previous control value from/to the midi device is stored in last_value. When writing midi feedback, if the value being sent is the same as last_value, feedback is aborted. What this means that none of the buttons should get feedback since the device expects to receive the same value it sent.

Why do the solo and mute buttons work then?

It turns out that MIDIControllable::midi_sense_controller sets the new value using controllable->set_value() and then uses controllable->get_value() to update last_value. However, Route::SoloControllable::set_value() and Route::MuteControllable::set_value() both put the new value in an asynchronous queue, which is why controllable->get_value() called immediately after set_value() usually returns the unchanged value instead of the new value. Now the current value is different from last_value and Ardour happily sends it as feedback.

Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9181 [ardour] features minor always 2022-12-23 14:31 2022-12-23 14:40
Reporter: finetuned Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: FaderPort V2: map "Solo Clear" and "Mute Clear"
Description: On the FaderPort V2 Control Surface, there are buttons [SOLO] and [MUTE], that have secondary functions when [SHIFT] is held down, namely "Solo Clear" and "Mute Clear". At the moment, these don't work as expected; [SHIFT] + [SOLO] acts the same as pressing [SOLO] without [SHIFT], and the same goes for [MUTE]. [SHIFT] + [ARM] does work as "Arm All", so I think the basic functionaly should be doable. There exist buttons in the Ardour interface for canceling all SOLO and for canceling MUTE, so the functionality is there on the Ardour side as well.

I'd like to contribute a fix for this. I'm looking at the source code for the control surfaces, but I could use some guidance as to how this should be implemented.

I noticed that the source files for the faderport8 get re-used with some IFDEFS for the FaderPort2, FaderPort8 and FaderPort16.

In fp8_controls.cc, I notice these lines:

    NEWSHIFTBUTTON (0x00, BtnArm, BtnArmAll, false);
    NEWBUTTON (0x01, BtnSoloClear, false);
    NEWBUTTON (0x02, BtnMuteClear, false);

By first thought is that there should be entries with NEWSHIFTBUTTON for BtnSoloClear and BtnMuteClear, analogous to the BtnArmAll line above it.

There exists an ENUM that lists all the buttons, and while they do contain BtnSoloClear and BtnMuteClear, they don't contain BtnSolo and BtnMute entries. I'm a little confused as to how this is implemented and how I should go about implementing the SHIFT functions for these buttons.

Any guidance would be appreciated, and if I get it tested and working, I can submit a patch for this.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: faderport2.jpg (85,792 bytes) 2022-12-23 14:31
https://tracker.ardour.org/file_download.php?file_id=4334&type=bug
jpg
Notes
(0027134)
finetuned   
2022-12-23 14:40   
The MIDI codes for these functions, for reference:

Pressing [Solo]
   226301800 NoteOn chn 1 08 7f
   226322080 NoteOff chn 1 08 40

Pressing [Mute]
   227721026 NoteOn chn 1 10 7f
   227745710 NoteOff chn 1 10 40

Pressing [Arm]
   228726544 NoteOn chn 1 00 7f
   228738029 NoteOff chn 1 00 40


Pressing [SHIFT] + [Solo]
   229577727 NoteOn chn 1 46 7f
   229607728 NoteOn chn 1 08 7f
   229615651 NoteOff chn 1 08 40
   229638600 NoteOff chn 1 46 40

Pressing [SHIFT] + [Mute]
   230293959 NoteOn chn 1 46 7f
   230302776 NoteOn chn 1 10 7f
   230309829 NoteOff chn 1 10 40
   230317774 NoteOff chn 1 46 40

Pressing [SHIFT] + [Arm]
   231193641 NoteOn chn 1 46 7f
   231205998 NoteOn chn 1 00 7f
   231212164 NoteOff chn 1 00 40
   231223642 NoteOff chn 1 46 40


It looks like the button values are all the same, with a surrounding SHIFT (0x46) NoteOn and NoteOff events.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9180 [ardour] features minor always 2022-12-21 14:35 2022-12-21 14:35
Reporter: colinf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 'CD Frames' grid foibles
Description: There are a few minor annoyances when grid is set to 'CD Frames':
 * the visible grid lines never indicate CD frames, regardless of the zoom level
 * when zoomed out enough, snap is to the nearest second
 * when zoomed in enough, snap to CD frames is magnetic, allowing (e.g.) CD merkers to be positioned not on a CD frame

It'd be nice if snap to CD markers was always exact, regardless of zoom level, and also lovely if you could see that that's what's happening if you zoom in enough.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9178 [ardour] documentation minor always 2022-12-20 20:29 2022-12-20 21:07
Reporter: Attila S. Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Documentation: include more sites for discovering new plugins for Ardour on Linux
Description: If it is possible please mention additional sites for discovering plugins for Linux in the documentation of Ardour.

Place in the documentation:
https://manual.ardour.org/working-with-plugins/getting-plugins/

Proposed sites for discovering additional plugins:
https://www.kvraudio.com/plugins/the-newest-plugins/linux
http://linux-sound.org/linux-vst-plugins.html
https://www.audiopluginsforfree.com/linux/
https://libreav.org/software
http://linuxsynths.com/
etc ...

(I personally found the first one the most useful and most comprehensive - relatively.)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027128)
x42   
2022-12-20 20:58   
I agree that we should remove that page from ardour's documentation and rather delegate things to KVR and more dedicated sites to the subject
(0027129)
mikelupe   
2022-12-20 21:07   
Additional "aggregators":
- https://linuxmusic.rocks/
- https://lv2plug.in/pages/projects.html
- https://www.ubuntupit.com/top-15-best-linux-synthesizers-for-digital-audio-production/

I still think, it would almost be better to place a new tab "Resources" on the ardour.org page, or to add a group to the "Community" tab. It's maybe easier to manage it - downloaded/generated manuals cold otherways remain out-of-date.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9177 [ardour] bugs minor always 2022-12-20 08:51 2022-12-20 08:51
Reporter: cooltehno_bugs Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bug: The new consolidated MIDI region doesn't match the grid after the consolidation of few MIDI regions
Description: If we consolidate few MIDI layered regions with 750 samples length using the Consolidate the range command - this makes a new region that has 737 length and make additional short regions with 25 samples length
Tags:
Steps To Reproduce: 1. Draw the MIDI region 750 samples (1/128 Note) long.
2. Draw the second MIDI region with the same length as a layer above the previous.
3. Select the full length of the drawn regions by the range selection.
4. Consolidate the range - BOOM - this makes the result consolidated region 737samples (expect 750!!) long and two short regions 25 samples long!
Additional Information:
System Description
Attached Files: range_consilidate_bug.gif (657,413 bytes) 2022-12-20 08:51
https://tracker.ardour.org/file_download.php?file_id=4331&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9164 [ardour] bugs major sometimes 2022-12-14 09:18 2022-12-20 06:28
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour plays wrong
Description: Here i have a video made. Error is still agin.
https://discourse.ardour.org/t/ardour-plays-midi-track-wrong/108016
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Bass Track.jpg (68,384 bytes) 2022-12-14 16:03
https://tracker.ardour.org/file_download.php?file_id=4327&type=bug
jpg

Midi Setting.jpg (52,584 bytes) 2022-12-15 20:15
https://tracker.ardour.org/file_download.php?file_id=4328&type=bug
jpg
Notes
(0027080)
stefan-franz   
2022-12-14 10:03   
Seems Ardour is completely overwhelmed with the midi file - maybe because of pitch bend data
(0027081)
stefan-franz   
2022-12-14 10:04   
Ardour plays sometimes wrong elsewhere
(0027082)
stefan-franz   
2022-12-14 10:38   
mp3 export also wrong - The bass is not playing at the beginning....and then it plays wrong
Here is the mp3 export - https://nco.stefan-franz.de/index.php/s/8JfF7DyGoa2dQBJ
(0027083)
stefan-franz   
2022-12-14 12:04   
I think the problem here are the pitch bend data - because all other projects work.
here is the original midi file - the bass makes the biggest problems.
https://nco.stefan-franz.de/index.php/s/fkptcbsw4PqGaMD
(0027090)
x42   
2022-12-14 15:37   
We do need a lot more information.

Which note(s) are played wrong? At what timestamp?
What do you mean with "plays wrong"? Is the timing off? Is a note missing?

Can you isolate the problem? ideally to a single MIDI region with just a few notes.

Which MIDI Track and Channel has the Bass that is not playing? Perhaps Channel Volume is zero?

Can you check with the plugin "ACE MIDI Monitor" (add it before the synth) if all events are sent to the synth as you expect?
(0027091)
stefan-franz   
2022-12-14 16:03   
After start Ardour it play a few minutes right. But after about 10-15min, some notes were played in the false ranges, as here in the video you see
https://discourse.ardour.org/t/ardour-plays-midi-track-wrong/108016

Not always the same - it's randomly. As the tracks gets corrupt over time.....

The bass track is the 2nd track in the midi file here https://nco.stefan-franz.de/index.php/s/fkptcbsw4PqGaMD
The beginning looks so (screenshot).

Here is a mp3 export from Ardour where you here the error: https://nco.stefan-franz.de/index.php/s/8JfF7DyGoa2dQBJ
The first few bars you hear no bass (but the notes are there) and then some bass notes are played in the wrong note range. The first 7 seconds of the file you hear no bass (but the bass is there) and in second 8-9 you hear a false note range.

Randomly the wrong note range is one of the problems - i think the pitch bend data mess up Ardour.
Now i started Ardour and all is playing good - the problem came today in the morning after i work with the project about 15minutes. I recorded only a audio track, or adjusted the level of tracks or the ACE EQ setting i edited.

I have just re-exported it: At the moment all sounds right. You hear the right sounds and can so hear the difference / error: https://nco.stefan-franz.de/index.php/s/qGf3sBsK5dyBMdP
(0027092)
stefan-franz   
2022-12-14 16:18   
Here you hear and see the error from 5minutes ago - Ardour 7.2.5 https://vimeo.com/781156134/cf54a0930d
(0027093)
x42   
2022-12-14 16:47   
Thank you, the video helps a lot!
(0027094)
stefan-franz   
2022-12-15 15:58   
info to 7.2.10 - now the track 2 or 3 plays wrong too - and sometimes track 2 (or 3) play a note about 1 second i stoped.
And now the wrong playing is nearly alwas reproduceabel. Project needs only 3 times played (only the first 10 bars needed) and then the error comes.
(0027095)
x42   
2022-12-15 19:32   
There has been no change that would explain this.

I still cannot reproduce this. Here the bass track plays just fine repeatedly.

Looking at the vimeo video, the main difference is that I use 48k/1024 (not 44.1/512) and an English system (dot as decimal separator). Neither should make a difference but I'll check.
I also use a debug (not optimized) build.
(0027096)
stefan-franz   
2022-12-15 19:53   
I found now out some things: The new "problem" track caused by Redux - i loaded the sound new to Redux and now it works.
But the Bass was/is played from the General Midi Synth.

After loading the Sound new to Redux, now my project plays right. All tracks.

Are there any Sys-Ex data in the tracks what messes up the Redux or the GM Midi Synth? (i don't know if Ardour has an "old school" list editor with all midi events....)
(0027097)
x42   
2022-12-15 19:58   
https://manual.ardour.org/midi/midi-editing/midi-list-editor/ -- but only shows notes, not all MIDI Events.
(0027098)
x42   
2022-12-15 20:00   
Ardour's GM Synth handles SysEx messages (eg. MTS - MIDI Tuning Standard) .
I do however not see any SysEx messages in the file that you have linked (You can leave your hat on.mid) - Also Arodur would show SysEx on the Editor timeline if there were any
(0027099)
stefan-franz   
2022-12-15 20:15   
New findings: https://vimeo.com/781608543/5dd1a2f75c
If i adjust the monitor volume, redux plays note very long. But, i assigned the Behringer controller only to the Monitor Level and Stop, Play and Record Button in Ardour. Not at any track nor to any function of Redux. In Redux no Macros are active. Neither PitchBend.
(0027100)
stefan-franz   
2022-12-15 20:28   
Here ist my Ardour project: https://nco.stefan-franz.de/index.php/s/jAS9a3AFyfyicfd
(0027101)
stefan-franz   
2022-12-15 21:33   
After some further tests: The controller is the cause for the problem. If i don't touch the controller (the slider which is assigned to the monitor level) then the project is playing ok.

How is in Ardour the setting, that only Ardour self should react/listen to the controller - and only what i assign?
(0027107)
stefan-franz   
2022-12-16 21:00   
Unfortunately i have to say....the conrtoller is not the cause. Without the controller Ardour plays wrong. The bass is after playing the project 3 or 4 times only 20 seconds from start (2.3.0000) wrong in that way
https://vimeo.com/781156134/cf54a0930d
(0027108)
stefan-franz   
2022-12-16 21:18   
The controller messes up Redux - maybe there are 2 problems. BTW also at AV Linux.
(0027109)
stefan-franz   
2022-12-17 08:11   
Wrong pitch of notes bouncing results: https://vimeo.com/782037266/6558f31165
Ardour 7.2.12
(0027111)
stefan-franz   
2022-12-17 13:24   
Deaktivated Bass and the Distortion 1 track which brings Redux in trouble with the controller. (to mix the project i exported the 2 tracks as Wav out of Cubase and imported to Ardour.
Now the project works normal - include Behringer Controller.
The cause are the 2 tracks. I mean the controller / Pitch Bend / Automatism is the reason.....good luck to find the reason. But it's really in 2-3 minutes reproduceable. I testet on LInux Mint 21, AV Linux, and Linux Mint DE5 (Debian version). All the same.
(0027122)
paul   
2022-12-19 19:16   
I would suggest testing with another synth. ACE Reasonable Synth would be a good choice.
(0027123)
stefan-franz   
2022-12-19 20:56   
But that synth is not usable for projects..... i uploaded my whole "problem" project here. I think it saves time for all, you test in my project all what you need. Here is a info from PMB Sound:
https://discourse.ardour.org/t/ardour-plays-midi-track-wrong/108016/6

And Robin maybe had tried out something.
(0027124)
paul   
2022-12-19 21:38   
I wasn't suggesting it was usable. It's a mechanism to differentiate issues with a given plugin versus issues in the host/DAW/Ardour.

Us testing your project is efficient, it is true, except that we have dozens or hundreds of issues to work on, while you have ... less :)
(0027125)
stefan-franz   
2022-12-20 06:28   
Oh - i searched about 2 full days and made here many infos and contributed many information. It's now the work of the devs to find it. ;-)

At the moment i have 5 projects - a mix of Audio tracks, and about 10 midi tracks with Redux, Speedrum and ACE Fluid Synth.
4 projects work fine. Only that "problem" project makes errors. I think Ardour has a big problem with Pitch Bend data, because this is the only project of me, where pitchbend data are used. Details you find above.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9109 [ardour] bugs crash sometimes 2022-11-20 22:33 2022-12-19 19:13
Reporter: beto Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unable to edit MIDI on a ramped BPM
Description: Ardour crashes when I try to add/edit MIDI on a region with ramped BPM
Tags:
Steps To Reproduce: 1. Create new project with BPM 120
2. Add a new tempo of 140 in bar 9
3. Edit the first tempo marker so it's ramped to 140
4. Add a MIDI track
5. Try to add a new MIDI region by dragging slowly (if you do it quickly it works)
6. Ardour crashes

This is with an official 7.1 build on Arch Linux.
Additional Information:
System Description
Attached Files: Ramp bug.ardour (31,492 bytes) 2022-11-20 22:33
https://tracker.ardour.org/file_download.php?file_id=4298&type=bug
Notes
(0026922)
paul   
2022-11-21 18:19   
I am unable to reproduce this bug, either with my own session or with the one attached.

Could you make a screen recording so that I can see in more detail what you are doing when the crash happens?
(0026937)
beto   
2022-11-24 00:52   
I've uploaded the video to https://youtu.be/xIT5dIjMNY0 (HD still processing).

Note that this doesn't happen when I remove the BPM ramp, which is why I think that's the problem here.
(0026993)
paul   
2022-12-08 00:54   
I believe this should be fixed now.
(0027118)
beto   
2022-12-18 02:43   
Just tested in 7.2 and it's now working!
(0027121)
paul   
2022-12-19 19:13   
see notes

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9172 [ardour] bugs major always 2022-12-18 00:25 2022-12-18 00:25
Reporter: MatthaeusHarris Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Regions on measure boundaries act weird after global tempo change
Description: This one is long, sorry. :/

I'm trying to match the tempo between two songs for a mashup. I do this by setting the global tempo to the tempo of one song, lining up the tracks on beat boundaries, then padding each track's region to perfectly align with both 001| 01 | 0000 and a measure boundary after the song ends. Once this is done I can change the global tempo to match the target tempo and use the stretch tool to extend or compress each region so it'll still end on the same measure after the tempo change. This works great for songs that need to be slowed down, but when I try to use the same method to speed songs up, the regions get truncated at the new measure boundary. For example, if I have padded a 121 bpm track with silence to end on measure 114 | 01 | 0000, when I change the tempo to 130 bpm some tracks will get truncated on measure 114 | 01 | 0000 even though the regions should contain audio that reaches past that point. If I use the trim tool to try to extend the regions, only audio that was previously trimmed will appear. If I try to undo the tempo change, Ardour will crash. I have not been able to reproduce the crash using a GDB build, although other weird stuff starts to happen (regions will not show the proper waveform unless zoomed in, and rebuilding peaks will result in the region being represented by a checkerbox instead of a waveform).
Tags:
Steps To Reproduce: https://youtu.be/uO1he0bJMYs shows the steps I took to reproduce this issue. This video shows 7.2 release; I was unable to reproduce the crash with GDB on the nightly build, but the underlying issue of unexpected region truncation remained.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9171 [ardour] bugs crash always 2022-12-17 23:28 2022-12-17 23:28
Reporter: MatthaeusHarris Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Windows crash on import file
Description: Was trying to reproduce a different bug with the nightly debug build, but encountered this in the process. Ardour segfaults when trying to import a sound file into a new project.
Tags:
Steps To Reproduce: 1. Open Ardour7.2.16-gdb
2. Create a new project
3. Import a sound file
4. Ardour has crashed.

Note: the crash does not occur if Ardour is not running with GDB.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9170 [ardour] features minor N/A 2022-12-17 12:32 2022-12-17 12:32
Reporter: x42 Platform: Web infrastructure  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Migrate bug-tracker to gitea
Description: Ideally issue tracking would be migrated to https://git.ardour.org/ and mantisBT retired
mantis has various issues (SPAM, token timeout to comment), the entry form is overly complicated, and it does no integrate with git.

gitea does offer SSO, has a much cleaner simple GUI, supports markdown.

For the migration to happen we
* first need need a SSO provider (main ardour site)
* find a way to map user-accounts
* migrate bug reports to gitea
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9169 [ardour] bugs block always 2022-12-16 17:42 2022-12-17 11:34
Reporter: rigandrix Platform: x86_64  
Assigned To: OS: Linux Fedora  
Priority: normal OS Version: 37  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Edit -> Tempo -> Set Tempo From Edit Range = Bar hangs Ardour -> Set global
Description: Ardour becomes unresposive when using Edit -> Tempo
Tags:
Steps To Reproduce: Option 1:
1. Select a portion of a track (even an empty one)
2. Edit, Tempo, Set Tempo From Edit Range = Bar , Set global tempo
Ardour blocks and a window alerts that the program is unresponsive

Option 2 (maybe more interesting):
1. Select a portion of a track (even an empty one)
2. Edit, Tempo, Set Tempo from Edit Range = Bar , Cancel
3. Edit, Tempo, Set Tempo from Edit Range = Bar
Ardour blocks and a window alerts that the program is unresponsive
Additional Information:
Attached Files:
Notes
(0027110)
rigandrix   
2022-12-17 11:34   
Forgot the stack:

Starting program: /home/rigazilla/git/ardour/build/gtk2_ardour/ardour-7.2.0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
bind txt domain [gtk2_ardour7] to /usr/local/share/ardour7/locale
Ardour7.2.0 (built using 7.2 and GCC version 12.2.1 20221121 (Red Hat 12.2.1-4))
[New Thread 0x7fffef9016c0 (LWP 52953)]
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /home/rigazilla/git/ardour/system_config
Ardour: [INFO]: Loading user configuration file /home/rigazilla/.config/ardour7/config
[New Thread 0x7fffe20f66c0 (LWP 52954)]
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
Ardour: [INFO]: Using AVX and FMA optimized routines
[New Thread 0x7fffe18f56c0 (LWP 52955)]
[New Thread 0x7fffe10f46c0 (LWP 52956)]
[New Thread 0x7fffe08f36c0 (LWP 52957)]
Ardour: [INFO]: Loading plugin meta data file /home/rigazilla/git/ardour/share/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/rigazilla/.config/ardour7/plugin_metadata/plugin_stats
- Zero stats of plugin 'https://community.ardour.org/node/7596' use-count: 1 LRU: 461
[New Thread 0x7fffca4236c0 (LWP 52958)]
[Thread 0x7fffca4236c0 (LWP 52958) exited]
[New Thread 0x7fffca4236c0 (LWP 52959)]
[New Thread 0x7fffc9a7b6c0 (LWP 52960)]
[New Thread 0x7fffc8d8a6c0 (LWP 52961)]
Ardour: [INFO]: Loading 454 MIDI patches from /home/rigazilla/git/ardour/share/patchfiles
Ardour: [INFO]: Loading default ui configuration file /home/rigazilla/git/ardour/build/gtk2_ardour/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/rigazilla/.config/ardour7/ui_config
Gtk-Message: 18:06:10.758: Failed to load module "pk-gtk-module"
[New Thread 0x7fffbbfff6c0 (LWP 52962)]
[Thread 0x7fffbbfff6c0 (LWP 52962) exited]
[New Thread 0x7fffbbfff6c0 (LWP 52963)]
[New Thread 0x7fffbb7fe6c0 (LWP 52964)]
[Thread 0x7fffbbfff6c0 (LWP 52963) exited]
[Thread 0x7fffbb7fe6c0 (LWP 52964) exited]
[New Thread 0x7fffbb7fe6c0 (LWP 52965)]
[New Thread 0x7fffbbfff6c0 (LWP 52966)]
[New Thread 0x7fffbaffd6c0 (LWP 52967)]
[New Thread 0x7fffba7fc6c0 (LWP 52968)]
[New Thread 0x7fffb9ffb6c0 (LWP 52970)]
[New Thread 0x7fffb97fa6c0 (LWP 52971)]
[Thread 0x7fffb9ffb6c0 (LWP 52970) exited]
[Thread 0x7fffb97fa6c0 (LWP 52971) exited]
Ardour: [INFO]: Loading color file /home/rigazilla/git/ardour/gtk2_ardour/themes/dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file /home/rigazilla/git/ardour/build/gtk2_ardour/clearlooks.rc
[New Thread 0x7fffb97fa6c0 (LWP 52972)]
[New Thread 0x7fffb9ffb6c0 (LWP 52973)]
[Thread 0x7fffb97fa6c0 (LWP 52972) exited]
[New Thread 0x7fffb97fa6c0 (LWP 52974)]
[New Thread 0x7fffb8ff96c0 (LWP 52975)]
[Thread 0x7fffb9ffb6c0 (LWP 52973) exited]
[Thread 0x7fffb97fa6c0 (LWP 52974) exited]
[New Thread 0x7fffb97fa6c0 (LWP 52976)]
[Thread 0x7fffb8ff96c0 (LWP 52975) exited]
[New Thread 0x7fffb8ff96c0 (LWP 52977)]
[Thread 0x7fffb97fa6c0 (LWP 52976) exited]
[Thread 0x7fffb8ff96c0 (LWP 52977) exited]
Ardour: [INFO]: Loading bindings from /home/rigazilla/git/ardour/build/gtk2_ardour/ardour.keys
Loading ui configuration file /home/rigazilla/git/ardour/build/gtk2_ardour/clearlooks.rc
[New Thread 0x7fffb8ff96c0 (LWP 52978)]
[New Thread 0x7fffb97fa6c0 (LWP 52979)]
[Thread 0x7fffb8ff96c0 (LWP 52978) exited]
[New Thread 0x7fffb8ff96c0 (LWP 52980)]
[New Thread 0x7fffb9ffb6c0 (LWP 52981)]
[Thread 0x7fffb97fa6c0 (LWP 52979) exited]
[Thread 0x7fffb8ff96c0 (LWP 52980) exited]
[Thread 0x7fffb9ffb6c0 (LWP 52981) exited]
[New Thread 0x7fffb87f86c0 (LWP 52982)]
[New Thread 0x7fffb85fd6c0 (LWP 52983)]
[Thread 0x7fffb85fd6c0 (LWP 52983) exited]
[Thread 0x7fffb87f86c0 (LWP 52982) exited]
[New Thread 0x7fffb87f86c0 (LWP 52984)]
[New Thread 0x7fffb85fd6c0 (LWP 52985)]
[Thread 0x7fffb85fd6c0 (LWP 52985) exited]
[Thread 0x7fffb87f86c0 (LWP 52984) exited]
[New Thread 0x7fffb9ffb6c0 (LWP 52986)]
[New Thread 0x7fffb8ff96c0 (LWP 52987)]
[Thread 0x7fffb9ffb6c0 (LWP 52986) exited]
[Thread 0x7fffb8ff96c0 (LWP 52987) exited]
[New Thread 0x7fffb8ff96c0 (LWP 52988)]
[New Thread 0x7fffb9ffb6c0 (LWP 52989)]
[Thread 0x7fffb8ff96c0 (LWP 52988) exited]
[Thread 0x7fffb9ffb6c0 (LWP 52989) exited]
[New Thread 0x7fffb9ffb6c0 (LWP 52990)]
[New Thread 0x7fffb8ff96c0 (LWP 52991)]
[New Thread 0x7fffb97fa6c0 (LWP 52992)]
Found nothing along /home/rigazilla/.config/ardour7/templates:/home/rigazilla/git/ardour/share/templates:/home/rigazilla/git/ardour/build/templates:/home/rigazilla/git/ardour/gtk2_ardour/templates:/home/rigazilla/git/ardour/build/gtk2_ardour/templates
[New Thread 0x7fff9b3ff6c0 (LWP 52994)]
[New Thread 0x7fff9abfe6c0 (LWP 52995)]
[Thread 0x7fff9b3ff6c0 (LWP 52994) exited]
[Thread 0x7fff9abfe6c0 (LWP 52995) exited]
[Thread 0x7fffb9ffb6c0 (LWP 52990) exited]
[Thread 0x7fffb97fa6c0 (LWP 52992) exited]
[Thread 0x7fffba7fc6c0 (LWP 52968) exited]
[Thread 0x7fffb8ff96c0 (LWP 52991) exited]
[Thread 0x7fffc8d8a6c0 (LWP 52961) exited]
[New Thread 0x7fffb8ff96c0 (LWP 52996)]
[New Thread 0x7fffb97fa6c0 (LWP 52997)]
[New Thread 0x7fffb9ffb6c0 (LWP 52998)]
[Thread 0x7fffb97fa6c0 (LWP 52997) exited]
[Thread 0x7fffb9ffb6c0 (LWP 52998) exited]
[Thread 0x7fffb8ff96c0 (LWP 52996) exited]
[New Thread 0x7fffb8ff96c0 (LWP 52999)]
[New Thread 0x7fffb87f86c0 (LWP 53000)]
[New Thread 0x7fffb82ea6c0 (LWP 53001)]
[New Thread 0x7fff9bf2c6c0 (LWP 53002)]
[New Thread 0x7fffb9ffb6c0 (LWP 53003)]
[New Thread 0x7fffb97fa6c0 (LWP 53004)]
[New Thread 0x7fffba7fc6c0 (LWP 53005)]
[New Thread 0x7fff9ab226c0 (LWP 53006)]
[New Thread 0x7fff9a3216c0 (LWP 53007)]
[Thread 0x7fff9ab226c0 (LWP 53006) exited]
[Thread 0x7fff9a3216c0 (LWP 53007) exited]
Set cursor set to default
[New Thread 0x7fff9a3216c0 (LWP 53008)]
[New Thread 0x7fff9ab226c0 (LWP 53009)]
[Thread 0x7fff9a3216c0 (LWP 53008) exited]
[Thread 0x7fff9ab226c0 (LWP 53009) exited]
[New Thread 0x7fff9ab226c0 (LWP 53010)]
[New Thread 0x7fff9a3216c0 (LWP 53011)]
[Thread 0x7fff9ab226c0 (LWP 53010) exited]
[Thread 0x7fff9a3216c0 (LWP 53011) exited]
[New Thread 0x7fff9a3216c0 (LWP 53012)]
[New Thread 0x7fff9ab226c0 (LWP 53013)]
[Thread 0x7fff9a3216c0 (LWP 53012) exited]
[Thread 0x7fff9ab226c0 (LWP 53013) exited]
[New Thread 0x7fff9ab226c0 (LWP 53014)]
[New Thread 0x7fff9a3216c0 (LWP 53015)]
[Thread 0x7fff9ab226c0 (LWP 53014) exited]
[Thread 0x7fff9a3216c0 (LWP 53015) exited]
[New Thread 0x7fff9a3216c0 (LWP 53016)]
[New Thread 0x7fff9ab226c0 (LWP 53017)]
[Thread 0x7fff9a3216c0 (LWP 53016) exited]
[Thread 0x7fff9ab226c0 (LWP 53017) exited]
[New Thread 0x7fff9ab226c0 (LWP 53018)]
[New Thread 0x7fff9a3216c0 (LWP 53019)]
[Thread 0x7fff9ab226c0 (LWP 53018) exited]
[New Thread 0x7fff9ab226c0 (LWP 53020)]
[New Thread 0x7fff998726c0 (LWP 53021)]
[Thread 0x7fff9a3216c0 (LWP 53019) exited]
[Thread 0x7fff9ab226c0 (LWP 53020) exited]
[Thread 0x7fff998726c0 (LWP 53021) exited]
[New Thread 0x7fff998726c0 (LWP 53022)]
[New Thread 0x7fff9ab226c0 (LWP 53023)]
[Thread 0x7fff998726c0 (LWP 53022) exited]
[Thread 0x7fff9ab226c0 (LWP 53023) exited]
[New Thread 0x7fff9ab226c0 (LWP 53024)]
[New Thread 0x7fff998726c0 (LWP 53025)]
[Thread 0x7fff9ab226c0 (LWP 53024) exited]
[New Thread 0x7fff9ab226c0 (LWP 53026)]
[New Thread 0x7fff9a3216c0 (LWP 53027)]
[Thread 0x7fff998726c0 (LWP 53025) exited]
[Thread 0x7fff9ab226c0 (LWP 53026) exited]
[Thread 0x7fff9a3216c0 (LWP 53027) exited]
[New Thread 0x7fff9a3216c0 (LWP 53028)]
[New Thread 0x7fff9ab226c0 (LWP 53029)]
[Thread 0x7fff9a3216c0 (LWP 53028) exited]
[Thread 0x7fff9ab226c0 (LWP 53029) exited]
[Thread 0x7fffba7fc6c0 (LWP 53005) exited]
[Thread 0x7fffb97fa6c0 (LWP 53004) exited]
[New Thread 0x7fff995716c0 (LWP 53030)]
[New Thread 0x7fff994f06c0 (LWP 53031)]
[New Thread 0x7fff9946f6c0 (LWP 53032)]
[New Thread 0x7fff993ee6c0 (LWP 53033)]
[New Thread 0x7fff9936d6c0 (LWP 53034)]
[New Thread 0x7fff992ec6c0 (LWP 53035)]
[New Thread 0x7fff9926b6c0 (LWP 53036)]
[New Thread 0x7fffba7fc6c0 (LWP 53037)]
[New Thread 0x7fffb97fa6c0 (LWP 53038)]
[Thread 0x7fffba7fc6c0 (LWP 53037) exited]
[New Thread 0x7fffba7fc6c0 (LWP 53039)]
[New Thread 0x7fff9ab226c0 (LWP 53040)]
[Thread 0x7fffba7fc6c0 (LWP 53039) exited]
[Thread 0x7fffb97fa6c0 (LWP 53038) exited]
[Thread 0x7fff9ab226c0 (LWP 53040) exited]
[New Thread 0x7fff9ab226c0 (LWP 53042)]
[New Thread 0x7fffb97fa6c0 (LWP 53043)]
[Thread 0x7fff9ab226c0 (LWP 53042) exited]
[Thread 0x7fffb97fa6c0 (LWP 53043) exited]
[New Thread 0x7fff75e0f6c0 (LWP 53048)]
[New Thread 0x7fffb97fa6c0 (LWP 53049)]
[New Thread 0x7fff9ab226c0 (LWP 53051)]
[New Thread 0x7fffba7fc6c0 (LWP 53052)]
[Thread 0x7fffb8ff96c0 (LWP 52999) exited]
[Thread 0x7fffbaffd6c0 (LWP 52967) exited]
locate to 0 took 217 usecs for 1 tracks = 217 per track
[New Thread 0x7fffb8ff96c0 (LWP 53053)]
[New Thread 0x7fffbaffd6c0 (LWP 53054)]
[New Thread 0x7fff9a3216c0 (LWP 53055)]
[Thread 0x7fffbaffd6c0 (LWP 53054) exited]
[Thread 0x7fff9a3216c0 (LWP 53055) exited]
[New Thread 0x7fff9a3216c0 (LWP 53056)]
[New Thread 0x7fffbaffd6c0 (LWP 53057)]
[Thread 0x7fff9a3216c0 (LWP 53056) exited]
[Thread 0x7fffbaffd6c0 (LWP 53057) exited]
[New Thread 0x7fffbaffd6c0 (LWP 53058)]
[New Thread 0x7fff9a3216c0 (LWP 53059)]
[Thread 0x7fffbaffd6c0 (LWP 53058) exited]
[Thread 0x7fff9a3216c0 (LWP 53059) exited]
[New Thread 0x7fff9a3216c0 (LWP 53060)]
[New Thread 0x7fffbaffd6c0 (LWP 53061)]
[Thread 0x7fff9a3216c0 (LWP 53060) exited]
[Thread 0x7fffbaffd6c0 (LWP 53061) exited]
[New Thread 0x7fffbaffd6c0 (LWP 53062)]
[New Thread 0x7fff9a3216c0 (LWP 53063)]
[Thread 0x7fffbaffd6c0 (LWP 53062) exited]
[New Thread 0x7fffbaffd6c0 (LWP 53064)]
[New Thread 0x7fff5be536c0 (LWP 53065)]
[Thread 0x7fff9a3216c0 (LWP 53063) exited]
[Thread 0x7fffbaffd6c0 (LWP 53064) exited]
[Thread 0x7fff5be536c0 (LWP 53065) exited]
[New Thread 0x7fff5be536c0 (LWP 53066)]
[New Thread 0x7fffbaffd6c0 (LWP 53067)]
[Thread 0x7fff5be536c0 (LWP 53066) exited]
[Thread 0x7fffbaffd6c0 (LWP 53067) exited]
[New Thread 0x7fffbaffd6c0 (LWP 53068)]
[New Thread 0x7fff5be536c0 (LWP 53069)]
[Thread 0x7fffbaffd6c0 (LWP 53068) exited]
[New Thread 0x7fffbaffd6c0 (LWP 53070)]
[New Thread 0x7fff9a3216c0 (LWP 53071)]
[Thread 0x7fff5be536c0 (LWP 53069) exited]
[Thread 0x7fffbaffd6c0 (LWP 53070) exited]
[Thread 0x7fff9a3216c0 (LWP 53071) exited]
[New Thread 0x7fff9a3216c0 (LWP 53072)]
[New Thread 0x7fffbaffd6c0 (LWP 53073)]
[Thread 0x7fff9a3216c0 (LWP 53072) exited]
[Thread 0x7fffbaffd6c0 (LWP 53073) exited]
[New Thread 0x7fffbaffd6c0 (LWP 53075)]
[New Thread 0x7fff9a3216c0 (LWP 53076)]
[Thread 0x7fffbaffd6c0 (LWP 53075) exited]
[New Thread 0x7fffbaffd6c0 (LWP 53077)]
[New Thread 0x7fff5be536c0 (LWP 53078)]
[Thread 0x7fff9a3216c0 (LWP 53076) exited]
[Thread 0x7fffbaffd6c0 (LWP 53077) exited]
[Thread 0x7fff5be536c0 (LWP 53078) exited]
[Thread 0x7fffb9ffb6c0 (LWP 53003) exited]




^C
Thread 1 "ArdourGUI" received signal SIGINT, Interrupt.
syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
Downloading 0.00 MB source file /usr/src/debug/glibc-2.36-8.fc37.x86_64/misc/../sysdeps/unix/sysv/linux/x86_64/syscall.S
38 cmpq $-4095, %rax /* Check %rax for error. */
(gdb) thread apply all bt

Thread 94 (Thread 0x7fffb8ff96c0 (LWP 53053) "AutomationWatch"):
#0 0x00007ffff2c15095 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffb8ff8a80, rem=rem@entry=0x7fffb8ff8a70) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
0000001 0x00007ffff2c19847 in __GI___nanosleep (req=req@entry=0x7fffb8ff8a80, rem=rem@entry=0x7fffb8ff8a70) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2 0x00007ffff4e7b83f in g_usleep (microseconds=<optimized out>) at ../glib/gtimer.c:279
#3 0x00007ffff6dcdd8d in ARDOUR::AutomationWatch::thread() (this=0x46e0c00) at ../libs/ardour/automation_watch.cc:207
0000004 0x00007ffff6dd2ebf in boost::_mfi::mf0<void, ARDOUR::AutomationWatch>::operator()(ARDOUR::AutomationWatch*) const (this=0x47048a0, p=0x46e0c00) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000005 0x00007ffff6dd2a53 in boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>&, boost::_bi::list0&, int) (this=0x47048b0, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
#6 0x00007ffff6dd23c7 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> > >::operator()() (this=0x47048a0) at /usr/include/boost/bind/bind.hpp:1273
#7 0x00007ffff6dd1ec2 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000008 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x4704898) at /usr/include/boost/function/function_template.hpp:763
0000009 0x00007ffff51d1787 in PBD::Thread::_run(void*) (arg=0x4704870) at ../libs/pbd/pthread_utils.cc:488
0000010 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000011 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
--Type <RET> for more, q to quit, c to continue without paging--c

Thread 93 (Thread 0x7fffba7fc6c0 (LWP 53052) "autoconnect"):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x3e6b1f0) at futex-internal.c:57
0000001 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x3e6b1f0, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2 0x00007ffff2bcad9f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x3e6b1f0, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3 0x00007ffff2bcd530 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x3e6b1a0, cond=0x3e6b1c8) at pthread_cond_wait.c:503
0000004 ___pthread_cond_wait (cond=0x3e6b1c8, mutex=0x3e6b1a0) at pthread_cond_wait.c:618
0000005 0x00007ffff74c6e12 in ARDOUR::Session::auto_connect_thread_run() (this=0x3e69130) at ../libs/ardour/session.cc:7444
#6 0x00007ffff74c691f in ARDOUR::Session::auto_connect_thread(void*) (arg=0x3e69130) at ../libs/ardour/session.cc:7375
#7 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000008 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 92 (Thread 0x7fff9ab226c0 (LWP 53051) "SessionSignals"):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x3e6b180) at futex-internal.c:57
0000001 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x3e6b180, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2 0x00007ffff2bcad9f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x3e6b180, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3 0x00007ffff2bcd530 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x3e6b130, cond=0x3e6b158) at pthread_cond_wait.c:503
0000004 ___pthread_cond_wait (cond=0x3e6b158, mutex=0x3e6b130) at pthread_cond_wait.c:618
0000005 0x00007ffff754bbd6 in ARDOUR::Session::emit_thread_run() (this=0x3e69130) at ../libs/ardour/session_process.cc:1232
#6 0x00007ffff754bb7f in ARDOUR::Session::emit_thread(void*) (arg=0x3e69130) at ../libs/ardour/session_process.cc:1221
#7 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000008 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 91 (Thread 0x7fffb97fa6c0 (LWP 53049) "midiUI"):
#0 0x00007ffff2c4205f in __GI___poll (fds=0x7fff68021ad0, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff4ea950d in g_main_context_poll (priority=<optimized out>, n_fds=4, fds=0x7fff68021ad0, timeout=<optimized out>, context=0x45c9b00) at ../glib/gmain.c:4543
#2 g_main_context_iterate.constprop.0 (context=0x45c9b00, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4233
#3 0x00007ffff4e5328f in g_main_loop_run (loop=0x45c9c20) at ../glib/gmain.c:4438
0000004 0x00007ffff51922bf in BaseUI::main_thread() (this=0x45c95d0) at ../libs/pbd/base_ui.cc:102
0000005 0x00007ffff5196c8b in boost::_mfi::mf0<void, BaseUI>::operator()(BaseUI*) const (this=0x45c9d50, p=0x45c95d0) at /usr/include/boost/bind/mem_fn_template.hpp:49
#6 0x00007ffff5196955 in boost::_bi::list1<boost::_bi::value<BaseUI*> >::operator()<boost::_mfi::mf0<void, BaseUI>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, BaseUI>&, boost::_bi::list0&, int) (this=0x45c9d60, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
#7 0x00007ffff51965a3 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, BaseUI>, boost::_bi::list1<boost::_bi::value<BaseUI*> > >::operator()() (this=0x45c9d50) at /usr/include/boost/bind/bind.hpp:1273
0000008 0x00007ffff5196075 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, BaseUI>, boost::_bi::list1<boost::_bi::value<BaseUI*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000009 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x45c9d48) at /usr/include/boost/function/function_template.hpp:763
0000010 0x00007ffff51d1787 in PBD::Thread::_run(void*) (arg=0x45c9d20) at ../libs/pbd/pthread_utils.cc:488
0000011 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000012 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 90 (Thread 0x7fff75e0f6c0 (LWP 53048) "butler"):
#0 0x00007ffff2c4205f in __GI___poll (fds=0x7fff75e0e204, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff51a9ac6 in CrossThreadChannel::poll_for_request() (this=0x3b546d0) at ../libs/pbd/crossthread.posix.cc:108
#2 0x00007ffff51a9b35 in CrossThreadChannel::receive(char&, bool) (this=0x3b546d0, msg=@0x7fff75e0e2bf: 0 '\000', wait=true) at ../libs/pbd/crossthread.posix.cc:133
#3 0x00007ffff6de307a in ARDOUR::Butler::thread_work() (this=0x3b54630) at ../libs/ardour/butler.cc:188
0000004 0x00007ffff6de2df3 in ARDOUR::Butler::_thread_work(void*) (arg=0x3b54630) at ../libs/ardour/butler.cc:170
0000005 0x00007ffff51d0c44 in fake_thread_start(void*) (arg=0x45b3c90) at ../libs/pbd/pthread_utils.cc:101
#6 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
#7 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 83 (Thread 0x7fff9926b6c0 (LWP 53036) "RT-6-0x7fff9926"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff51d79be in PBD::Semaphore::wait() (this=0x3b5c764) at ../libs/pbd/semutils.cc:120
#2 0x00007ffff6f1ed6d in ARDOUR::Graph::run_one() (this=0x3b5c630) at ../libs/ardour/graph.cc:322
#3 0x00007ffff6f1f279 in ARDOUR::Graph::helper_thread() (this=0x3b5c630) at ../libs/ardour/graph.cc:374
0000004 0x00007ffff6f2a07f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fff9926abd8, p=0x3b5c630) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000005 0x00007ffff6f2971d in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fff9926abe8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
#6 0x00007ffff6f2872f in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fff9926abd8) at /usr/include/boost/bind/bind.hpp:1273
#7 0x00007ffff6f2713f in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000008 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x7fff9926abd0) at /usr/include/boost/function/function_template.hpp:763
0000009 0x00007fffc923809c in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x3e615f0) at ../libs/backends/jack/jack_audiobackend.cc:955
0000010 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000011 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 82 (Thread 0x7fff992ec6c0 (LWP 53035) "RT-5-0x7fff992e"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff51d79be in PBD::Semaphore::wait() (this=0x3b5c764) at ../libs/pbd/semutils.cc:120
#2 0x00007ffff6f1ed6d in ARDOUR::Graph::run_one() (this=0x3b5c630) at ../libs/ardour/graph.cc:322
#3 0x00007ffff6f1f279 in ARDOUR::Graph::helper_thread() (this=0x3b5c630) at ../libs/ardour/graph.cc:374
0000004 0x00007ffff6f2a07f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fff992ebbd8, p=0x3b5c630) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000005 0x00007ffff6f2971d in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fff992ebbe8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
#6 0x00007ffff6f2872f in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fff992ebbd8) at /usr/include/boost/bind/bind.hpp:1273
#7 0x00007ffff6f2713f in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000008 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x7fff992ebbd0) at /usr/include/boost/function/function_template.hpp:763
0000009 0x00007fffc923809c in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x2298590) at ../libs/backends/jack/jack_audiobackend.cc:955
0000010 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000011 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 81 (Thread 0x7fff9936d6c0 (LWP 53034) "RT-4-0x7fff9936"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff51d79be in PBD::Semaphore::wait() (this=0x3b5c764) at ../libs/pbd/semutils.cc:120
#2 0x00007ffff6f1ed6d in ARDOUR::Graph::run_one() (this=0x3b5c630) at ../libs/ardour/graph.cc:322
#3 0x00007ffff6f1f279 in ARDOUR::Graph::helper_thread() (this=0x3b5c630) at ../libs/ardour/graph.cc:374
0000004 0x00007ffff6f2a07f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fff9936cbd8, p=0x3b5c630) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000005 0x00007ffff6f2971d in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fff9936cbe8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
#6 0x00007ffff6f2872f in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fff9936cbd8) at /usr/include/boost/bind/bind.hpp:1273
#7 0x00007ffff6f2713f in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000008 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x7fff9936cbd0) at /usr/include/boost/function/function_template.hpp:763
0000009 0x00007fffc923809c in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x228d690) at ../libs/backends/jack/jack_audiobackend.cc:955
0000010 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000011 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 80 (Thread 0x7fff993ee6c0 (LWP 53033) "RT-3-0x7fff993e"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff51d79be in PBD::Semaphore::wait() (this=0x3b5c764) at ../libs/pbd/semutils.cc:120
#2 0x00007ffff6f1ed6d in ARDOUR::Graph::run_one() (this=0x3b5c630) at ../libs/ardour/graph.cc:322
#3 0x00007ffff6f1f279 in ARDOUR::Graph::helper_thread() (this=0x3b5c630) at ../libs/ardour/graph.cc:374
0000004 0x00007ffff6f2a07f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fff993edbd8, p=0x3b5c630) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000005 0x00007ffff6f2971d in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fff993edbe8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
#6 0x00007ffff6f2872f in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fff993edbd8) at /usr/include/boost/bind/bind.hpp:1273
#7 0x00007ffff6f2713f in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000008 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x7fff993edbd0) at /usr/include/boost/function/function_template.hpp:763
0000009 0x00007fffc923809c in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x22d6d80) at ../libs/backends/jack/jack_audiobackend.cc:955
0000010 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000011 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 79 (Thread 0x7fff9946f6c0 (LWP 53032) "RT-2-0x7fff9946"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff51d79be in PBD::Semaphore::wait() (this=0x3b5c764) at ../libs/pbd/semutils.cc:120
#2 0x00007ffff6f1ed6d in ARDOUR::Graph::run_one() (this=0x3b5c630) at ../libs/ardour/graph.cc:322
#3 0x00007ffff6f1f279 in ARDOUR::Graph::helper_thread() (this=0x3b5c630) at ../libs/ardour/graph.cc:374
0000004 0x00007ffff6f2a07f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fff9946ebd8, p=0x3b5c630) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000005 0x00007ffff6f2971d in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fff9946ebe8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
#6 0x00007ffff6f2872f in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fff9946ebd8) at /usr/include/boost/bind/bind.hpp:1273
#7 0x00007ffff6f2713f in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000008 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x7fff9946ebd0) at /usr/include/boost/function/function_template.hpp:763
0000009 0x00007fffc923809c in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x2a19850) at ../libs/backends/jack/jack_audiobackend.cc:955
0000010 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000011 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 78 (Thread 0x7fff994f06c0 (LWP 53031) "RT-1-0x7fff994f"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff51d79be in PBD::Semaphore::wait() (this=0x3b5c764) at ../libs/pbd/semutils.cc:120
#2 0x00007ffff6f1ed6d in ARDOUR::Graph::run_one() (this=0x3b5c630) at ../libs/ardour/graph.cc:322
#3 0x00007ffff6f1f279 in ARDOUR::Graph::helper_thread() (this=0x3b5c630) at ../libs/ardour/graph.cc:374
0000004 0x00007ffff6f2a07f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fff994efbd8, p=0x3b5c630) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000005 0x00007ffff6f2971d in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fff994efbe8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
#6 0x00007ffff6f2872f in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fff994efbd8) at /usr/include/boost/bind/bind.hpp:1273
#7 0x00007ffff6f2713f in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000008 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x7fff994efbd0) at /usr/include/boost/function/function_template.hpp:763
0000009 0x00007fffc923809c in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x3d07ac0) at ../libs/backends/jack/jack_audiobackend.cc:955
0000010 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000011 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 77 (Thread 0x7fff995716c0 (LWP 53030) "RT-main-0x7fff9"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff51d79be in PBD::Semaphore::wait() (this=0x3b5c770) at ../libs/pbd/semutils.cc:120
#2 0x00007ffff6f1e856 in ARDOUR::Graph::reached_terminal_node() (this=0x3b5c630) at ../libs/ardour/graph.cc:269
#3 0x00007ffff6f2af47 in ARDOUR::GraphNode::finish(ARDOUR::GraphChain const*) (this=0x4463be0, chain=0x7fffa801f850) at ../libs/ardour/graphnode.cc:99
0000004 0x00007ffff6f2ae24 in ARDOUR::GraphNode::run(ARDOUR::GraphChain const*) (this=0x4463be0, chain=0x7fffa801f850) at ../libs/ardour/graphnode.cc:66
0000005 0x00007ffff6f1ef23 in ARDOUR::Graph::run_one() (this=0x3b5c630) at ../libs/ardour/graph.cc:346
#6 0x00007ffff6f1f6b8 in ARDOUR::Graph::main_thread() (this=0x3b5c630) at ../libs/ardour/graph.cc:427
#7 0x00007ffff6f2a07f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fff99570bd8, p=0x3b5c630) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000008 0x00007ffff6f2971d in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fff99570be8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
0000009 0x00007ffff6f2872f in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fff99570bd8) at /usr/include/boost/bind/bind.hpp:1273
0000010 0x00007ffff6f2713f in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000011 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x7fff99570bd0) at /usr/include/boost/function/function_template.hpp:763
0000012 0x00007fffc923809c in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x3e0ff10) at ../libs/backends/jack/jack_audiobackend.cc:955
0000013 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000014 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 49 (Thread 0x7fff9bf2c6c0 (LWP 53002) "audioengine"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007fffcab0aacb in Jack::JackLinuxFutex::Wait() (this=0x2b8a368) at ../linux/JackLinuxFutex.cpp:104
#2 0x00007fffcab0abdd in Jack::JackLinuxFutex::TimedWait(long) (this=<optimized out>, usec=usec@entry=9223372036854775807) at ../linux/JackLinuxFutex.cpp:113
#3 0x00007fffcaaecdaa in Jack::JackConnectionManager::SuspendRefNum(Jack::JackClientControl*, Jack::JackLinuxFutex*, Jack::JackClientTiming*, long) (this=<optimized out>, control=0x7fffcbf46000, table=table@entry=0x2b8a020, timing=timing@entry=0x7fff87df721c, time_out_usec=time_out_usec@entry=9223372036854775807) at ../common/JackConnectionManager.cpp:241
0000004 0x00007fffcaaef639 in Jack::JackGraphManager::SuspendRefNum(Jack::JackClientControl*, Jack::JackLinuxFutex*, long) (this=this@entry=0x7fff859a1000, control=<optimized out>, table=table@entry=0x2b8a020, usec=usec@entry=9223372036854775807) at ../common/JackGraphManager.cpp:130
0000005 0x00007fffcaaeadb0 in Jack::JackClient::WaitSync() (this=<optimized out>) at ../common/JackClient.cpp:640
#6 Jack::JackClient::CycleWaitAux() (this=<optimized out>) at ../common/JackClient.cpp:604
#7 Jack::JackClient::CycleWait() (this=0x275f800) at ../common/JackClient.cpp:624
0000008 0x00007fffc923815f in ARDOUR::JACKAudioBackend::process_thread() (this=0x1f14460) at ../libs/backends/jack/jack_audiobackend.cc:984
0000009 0x00007fffc92380ea in ARDOUR::JACKAudioBackend::_process_thread(void*) (arg=0x1f14460) at ../libs/backends/jack/jack_audiobackend.cc:963
0000010 0x00007fffcaaeb234 in non-virtual thunk to Jack::JackClient::Execute() () at ../common/JackClient.h:220
0000011 0x00007fffcab08cf0 in Jack::JackPosixThread::ThreadHandler(void*) (arg=0x275fa48) at ../posix/JackPosixThread.cpp:63
0000012 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000013 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 48 (Thread 0x7fffb82ea6c0 (LWP 53001) "audioengine"):
#0 __GI___libc_read (nbytes=4, buf=0x7fffb82e9a70, fd=22) at ../sysdeps/unix/sysv/linux/read.c:26
0000001 __GI___libc_read (fd=22, buf=0x7fffb82e9a70, nbytes=nbytes@entry=4) at ../sysdeps/unix/sysv/linux/read.c:24
#2 0x00007fffcab09f59 in read (__nbytes=4, __buf=<optimized out>, __fd=<optimized out>) at /usr/include/bits/unistd.h:38
#3 Jack::JackClientSocket::Read(void*, int) (this=0x7fffa80211a0, data=<optimized out>, len=4) at ../posix/JackSocket.cpp:196
0000004 0x00007fffcab0ed71 in Jack::JackClientNotification::Read(Jack::detail::JackChannelTransactionInterface*) (this=this@entry=0x7fffb82e9a70, trans=0x7fffa80211a0) at ../common/JackRequest.h:1711
0000005 0x00007fffcab0eba7 in Jack::JackSocketClientChannel::Execute() (this=0x21c3a90) at ../posix/JackSocketClientChannel.cpp:138
#6 0x00007fffcab08cf0 in Jack::JackPosixThread::ThreadHandler(void*) (arg=0x21c3bc0) at ../posix/JackPosixThread.cpp:63
#7 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000008 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 47 (Thread 0x7fffb87f86c0 (LWP 53000) "audioengine"):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x2ba3b48) at futex-internal.c:57
0000001 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x2ba3b48, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2 0x00007ffff2bcad9f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x2ba3b48, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3 0x00007ffff2bcd530 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x2ba3af0, cond=0x2ba3b20) at pthread_cond_wait.c:503
0000004 ___pthread_cond_wait (cond=0x2ba3b20, mutex=0x2ba3af0) at pthread_cond_wait.c:618
0000005 0x00007fffcab097c4 in Jack::JackPosixProcessSync::Wait() (this=0x2ba3ae8) at ../posix/JackPosixProcessSync.cpp:81
#6 0x00007fffcaafdc9d in Jack::JackMessageBuffer::Execute() (this=0x2b9b8b0) at ../common/JackMessageBuffer.cpp:107
#7 0x00007fffcab08cf0 in Jack::JackPosixThread::ThreadHandler(void*) (arg=0x2ba3ac8) at ../posix/JackPosixThread.cpp:63
0000008 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000009 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 15 (Thread 0x7fffbbfff6c0 (LWP 52966) "gdbus"):
#0 0x00007ffff2c4205f in __GI___poll (fds=0x25c9b20, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff4ea950d in g_main_context_poll (priority=<optimized out>, n_fds=3, fds=0x25c9b20, timeout=<optimized out>, context=0x25c87b0) at ../glib/gmain.c:4543
#2 g_main_context_iterate.constprop.0 (context=0x25c87b0, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4233
#3 0x00007ffff4e5328f in g_main_loop_run (loop=0x25c88a0) at ../glib/gmain.c:4438
0000004 0x00007ffff461488a in gdbus_shared_thread_func (user_data=0x25c8780) at ../gio/gdbusprivate.c:284
0000005 0x00007ffff4e7d9c2 in g_thread_proxy (data=0x25c4240) at ../glib/gthread.c:831
#6 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
#7 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 14 (Thread 0x7fffbb7fe6c0 (LWP 52965) "gmain"):
#0 0x00007ffff2c4205f in __GI___poll (fds=0x25c0390, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff4ea950d in g_main_context_poll (priority=<optimized out>, n_fds=2, fds=0x25c0390, timeout=<optimized out>, context=0x25be290) at ../glib/gmain.c:4543
#2 g_main_context_iterate.constprop.0 (context=0x25be290, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4233
#3 0x00007ffff4e50f40 in g_main_context_iteration (context=0x25be290, may_block=may_block@entry=1) at ../glib/gmain.c:4303
0000004 0x00007ffff4e52bd1 in glib_worker_main (data=<optimized out>) at ../glib/gmain.c:6414
0000005 0x00007ffff4e7d9c2 in g_thread_proxy (data=0x256c980) at ../glib/gthread.c:831
#6 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
#7 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 9 (Thread 0x7fffc9a7b6c0 (LWP 52960) "DeviceList"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff4ea4e83 in g_cond_wait (cond=0x1ed0028, mutex=0x1ed0038) at ../glib/gthread-posix.c:1590
#2 0x00007ffff6d6432f in ARDOUR::AudioEngine::do_devicelist_update() (this=0x1ecf670) at ../libs/ardour/audioengine.cc:747
#3 0x00007ffff6d72067 in boost::_mfi::mf0<void, ARDOUR::AudioEngine>::operator()(ARDOUR::AudioEngine*) const (this=0x1f16ec0, p=0x1ecf670) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000004 0x00007ffff6d7172f in boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::AudioEngine>&, boost::_bi::list0&, int) (this=0x1f16ed0, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
0000005 0x00007ffff6d70cab in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >::operator()() (this=0x1f16ec0) at /usr/include/boost/bind/bind.hpp:1273
#6 0x00007ffff6d70121 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
#7 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x1f16eb8) at /usr/include/boost/function/function_template.hpp:763
0000008 0x00007ffff51d1787 in PBD::Thread::_run(void*) (arg=0x1f16e90) at ../libs/pbd/pthread_utils.cc:488
0000009 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000010 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 8 (Thread 0x7fffca4236c0 (LWP 52959) "EngineWatchdog"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff4ea4e83 in g_cond_wait (cond=0x1ecfff8, mutex=0x1ed0008) at ../glib/gthread-posix.c:1590
#2 0x00007ffff6d640dd in ARDOUR::AudioEngine::do_reset_backend() (this=0x1ecf670) at ../libs/ardour/audioengine.cc:711
#3 0x00007ffff6d72067 in boost::_mfi::mf0<void, ARDOUR::AudioEngine>::operator()(ARDOUR::AudioEngine*) const (this=0x1f16b80, p=0x1ecf670) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000004 0x00007ffff6d7172f in boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::AudioEngine>&, boost::_bi::list0&, int) (this=0x1f16b90, f=..., a=...) at /usr/include/boost/bind/bind.hpp:238
0000005 0x00007ffff6d70cab in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >::operator()() (this=0x1f16b80) at /usr/include/boost/bind/bind.hpp:1273
#6 0x00007ffff6d70121 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
#7 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x1f16b78) at /usr/include/boost/function/function_template.hpp:763
0000008 0x00007ffff51d1787 in PBD::Thread::_run(void*) (arg=0x1f16b50) at ../libs/pbd/pthread_utils.cc:488
0000009 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000010 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 6 (Thread 0x7fffe08f36c0 (LWP 52957) "Analyzer"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff4ea4e83 in g_cond_wait (cond=0x7ffff7d4fee0 <ARDOUR::Analyser::SourcesToAnalyse>, mutex=0x7ffff7d4fed8 <ARDOUR::Analyser::analysis_queue_lock>) at ../glib/gthread-posix.c:1590
#2 0x00007ffff6d133d5 in ARDOUR::Analyser::work() () at ../libs/ardour/analyser.cc:95
#3 0x00000000010c2e05 in sigc::pointer_functor0<void>::operator()() const (this=0x1ea52d0) at /usr/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
0000004 0x00007ffff6d165a9 in boost::detail::function::void_function_obj_invoker0<sigc::pointer_functor0<void>, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000005 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x1ea52c8) at /usr/include/boost/function/function_template.hpp:763
#6 0x00007ffff51d1787 in PBD::Thread::_run(void*) (arg=0x1ea52a0) at ../libs/pbd/pthread_utils.cc:488
#7 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000008 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 5 (Thread 0x7fffe10f46c0 (LWP 52956) "PeakFileBuilder"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff4ea4e83 in g_cond_wait (cond=0x7ffff7d52e90 <ARDOUR::SourceFactory::PeaksToBuild>, mutex=0x7ffff7d52ea0 <ARDOUR::SourceFactory::peak_building_lock>) at ../glib/gthread-posix.c:1590
#2 0x00007ffff75f09ae in peak_thread_work() () at ../libs/ardour/source_factory.cc:75
#3 0x00007ffff7f29f9e in boost::detail::function::void_function_invoker0<void (*)(), void>::invoke(boost::detail::function::function_buffer&) (function_ptr=...) at /usr/include/boost/function/function_template.hpp:117
0000004 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x1ea56b8) at /usr/include/boost/function/function_template.hpp:763
0000005 0x00007ffff51d1787 in PBD::Thread::_run(void*) (arg=0x1ea5690) at ../libs/pbd/pthread_utils.cc:488
#6 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
#7 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 4 (Thread 0x7fffe18f56c0 (LWP 52955) "PeakFileBuilder"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff4ea4e83 in g_cond_wait (cond=0x7ffff7d52e90 <ARDOUR::SourceFactory::PeaksToBuild>, mutex=0x7ffff7d52ea0 <ARDOUR::SourceFactory::peak_building_lock>) at ../glib/gthread-posix.c:1590
#2 0x00007ffff75f09ae in peak_thread_work() () at ../libs/ardour/source_factory.cc:75
#3 0x00007ffff7f29f9e in boost::detail::function::void_function_invoker0<void (*)(), void>::invoke(boost::detail::function::function_buffer&) (function_ptr=...) at /usr/include/boost/function/function_template.hpp:117
0000004 0x000000000076d15e in boost::function0<void>::operator()() const (this=0x1ea5b58) at /usr/include/boost/function/function_template.hpp:763
0000005 0x00007ffff51d1787 in PBD::Thread::_run(void*) (arg=0x1ea5b30) at ../libs/pbd/pthread_utils.cc:488
#6 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
#7 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x7fffe20f66c0 (LWP 52954) "LXVSTEventLoop"):
#0 0x00007ffff2c15095 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffe20f5ad0, rem=rem@entry=0x7fffe20f5ac0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
0000001 0x00007ffff2c19847 in __GI___nanosleep (req=req@entry=0x7fffe20f5ad0, rem=rem@entry=0x7fffe20f5ac0) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2 0x00007ffff4e7b83f in g_usleep (microseconds=<optimized out>) at ../glib/gtimer.c:279
#3 0x000000000156be0a in gui_event_loop(void*) (ptr=0x0) at ../gtk2_ardour/linux_vst_gui_support.cc:468
0000004 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
0000005 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x7fffef9016c0 (LWP 52953) "Trigger Worker"):
#0 0x00007ffff2c4205f in __GI___poll (fds=0x7fffef900aa4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff51a9ac6 in CrossThreadChannel::poll_for_request() (this=0x1e4e2e8) at ../libs/pbd/crossthread.posix.cc:108
#2 0x00007ffff51a9b35 in CrossThreadChannel::receive(char&, bool) (this=0x1e4e2e8, msg=@0x7fffef900b0f: -1 '\377', wait=true) at ../libs/pbd/crossthread.posix.cc:133
#3 0x00007ffff7651a5a in ARDOUR::TriggerBoxThread::thread_work() (this=0x1e4e2c0) at ../libs/ardour/triggerbox.cc:4841
0000004 0x00007ffff76519ef in ARDOUR::TriggerBoxThread::_thread_work(void*) (arg=0x1e4e2c0) at ../libs/ardour/triggerbox.cc:4829
0000005 0x00007ffff51d0c44 in fake_thread_start(void*) (arg=0x1de8b60) at ../libs/pbd/pthread_utils.cc:101
#6 0x00007ffff2bce14d in start_thread (arg=<optimized out>) at pthread_create.c:442
#7 0x00007ffff2c4fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81


Thread 1 (Thread 0x7ffff1730a00 (LWP 52952) "ArdourGUI"):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff4ea4dfc in g_mutex_lock_slowpath (mutex=0x1d637d8 <Temporal::TempoMap::_map_mgr+24>) at ../glib/gthread-posix.c:1503
#2 0x00007ffff59fb0a9 in SerializedRCUManager<Temporal::TempoMap>::write_copy() (this=0x1d637c0 <Temporal::TempoMap::_map_mgr>) at ../libs/pbd/pbd/rcu.h:162
#3 0x00007ffff59e74e2 in Temporal::TempoMap::write_copy() () at ../libs/temporal/tempo.cc:3367
0000004 0x0000000000b0a831 in Temporal::TempoMap::fetch_writable() () at ../libs/temporal/temporal/tempo.h:709
0000005 0x0000000000b09e59 in Editor::begin_tempo_map_edit() (this=0x2d5f850) at ../gtk2_ardour/editor_tempodisplay.cc:758
#6 0x00000000013fe7c3 in TempoMapChange::begin() (this=0x7fffffffb150) at ../gtk2_ardour/tempo_map_change.cc:50
#7 0x00000000013fe5dd in TempoMapChange::TempoMapChange(PublicEditor&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool) (this=0x7fffffffb150, e=..., str="set tempo from region", uoc=true, begin_now=true) at ../gtk2_ardour/tempo_map_change.cc:31
0000008 0x0000000000a9cf5d in Editor::define_one_bar(Temporal::timepos_t const&, Temporal::timepos_t const&) (this=0x2d5f850, start=..., end=...) at ../gtk2_ardour/editor_ops.cc:7485
0000009 0x0000000000a9cac4 in Editor::use_range_as_bar() (this=0x2d5f850) at ../gtk2_ardour/editor_ops.cc:7408
0000010 0x0000000000985f72 in sigc::bound_mem_functor0<void, Editor>::operator()() const (this=0x2ed6fd8) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
0000011 0x000000000097dada in sigc::adaptor_functor<sigc::bound_mem_functor0<void, Editor> >::operator()() const (this=0x2ed6fd0) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000012 0x000000000097db01 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, Editor>, void>::call_it(sigc::internal::slot_rep*) (rep=0x2ed6fa0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000013 0x00007ffff4fa0fac in sigc::slot0<void>::operator()() const (this=0x2ef81d8) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:535
0000014 Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) (self=<optimized out>, data=0x2ef81d0) at ../glib/glibmm/signalproxy.cc:103
#15 0x00007ffff5642fc0 in g_closure_invoke (closure=0x2efae90, return_value=0x0, n_param_values=1, param_values=0x7fffffffb650, invocation_hint=0x7fffffffb5d0) at ../gobject/gclosure.c:832
0000016 0x00007ffff5671054 in signal_emit_unlocked_R.isra.0 (node=node@entry=0x24f2f80, detail=detail@entry=0, instance=instance@entry=0x2ef7b70, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffb650) at ../gobject/gsignal.c:3867
#17 0x00007ffff566041a in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffb7f0) at ../gobject/gsignal.c:3549
0000018 0x00007ffff5660633 in g_signal_emit (instance=instance@entry=0x2ef7b70, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3606
0000019 0x00007ffff487c7ae in _gtk_action_emit_activate (action=0x2ef7b70) at /usr/src/debug/gtk2-2.24.33-10.fc37.x86_64/gtk/gtkaction.c:795
0000020 0x00007ffff5642fc0 in g_closure_invoke (closure=0x25097f0, return_value=0x0, n_param_values=1, param_values=0x7fffffffba80, invocation_hint=0x7fffffffba00) at ../gobject/gclosure.c:832
0000021 0x00007ffff5670a35 in signal_emit_unlocked_R.isra.0 (node=node@entry=0x2509850, detail=detail@entry=0, instance=instance@entry=0x3bb4940, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffba80) at ../gobject/gsignal.c:3726
0000022 0x00007ffff566041a in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffbc20) at ../gobject/gsignal.c:3549
0000023 0x00007ffff5660633 in g_signal_emit (instance=instance@entry=0x3bb4940, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3606
#24 0x00007ffff4a94b6c in IA__gtk_widget_activate (widget=0x3bb4940) at /usr/src/debug/gtk2-2.24.33-10.fc37.x86_64/gtk/gtkwidget.c:5048
0000025 0x00007ffff496b195 in IA__gtk_menu_shell_activate_item (menu_shell=0x3bb0450, menu_item=0x3bb4940, force_deactivate=<optimized out>) at /usr/src/debug/gtk2-2.24.33-10.fc37.x86_64/gtk/gtkmenushell.c:1305
0000026 0x00007ffff496d769 in gtk_menu_shell_button_release (widget=0x3bb0450, event=<optimized out>) at /usr/src/debug/gtk2-2.24.33-10.fc37.x86_64/gtk/gtkmenushell.c:730
0000027 0x00007ffff49551e9 in _gtk_marshal_BOOLEAN__BOXED (closure=0x25050f0, return_value=0x7fffffffbf50, n_param_values=<optimized out>, param_values=0x7fffffffbfb0, invocation_hint=<optimized out>, marshal_data=<optimized out>) at /usr/src/debug/gtk2-2.24.33-10.fc37.x86_64/gtk/gtkmarshalers.c:84
0000028 0x00007ffff5642fc0 in g_closure_invoke (closure=0x25050f0, return_value=0x7fffffffbf50, n_param_values=2, param_values=0x7fffffffbfb0, invocation_hint=0x7fffffffbf30) at ../gobject/gclosure.c:832
0000029 0x00007ffff5670eb5 in signal_emit_unlocked_R.isra.0 (node=<optimized out>, detail=detail@entry=0, instance=instance@entry=0x3bb0450, emission_return=emission_return@entry=0x7fffffffc0c0, instance_and_params=instance_and_params@entry=0x7fffffffbfb0) at ../gobject/gsignal.c:3835
0000030 0x00007ffff565fe16 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc170) at ../gobject/gsignal.c:3559
0000031 0x00007ffff5660633 in g_signal_emit (instance=instance@entry=0x3bb0450, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3606
0000032 0x00007ffff4a96b44 in gtk_widget_event_internal (widget=0x3bb0450, event=0x2396520) at /usr/src/debug/gtk2-2.24.33-10.fc37.x86_64/gtk/gtkwidget.c:5017
0000033 0x00007ffff4957c74 in IA__gtk_propagate_event (widget=0x3bb0450, event=0x2396520) at /usr/src/debug/gtk2-2.24.33-10.fc37.x86_64/gtk/gtkmain.c:2503
0000034 0x00007ffff4959883 in IA__gtk_main_do_event (event=0x2396520) at /usr/src/debug/gtk2-2.24.33-10.fc37.x86_64/gtk/gtkmain.c:1698
0000035 IA__gtk_main_do_event (event=<optimized out>) at /usr/src/debug/gtk2-2.24.33-10.fc37.x86_64/gtk/gtkmain.c:1503
0000036 0x00007ffff4d98c33 in gdk_event_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at x11/gdkevents-x11.c:2425
0000037 0x00007ffff4e53cbf in g_main_dispatch (context=0x1eee420) at ../glib/gmain.c:3444
0000038 g_main_context_dispatch (context=0x1eee420) at ../glib/gmain.c:4162
0000039 0x00007ffff4ea9598 in g_main_context_iterate.constprop.0 (context=0x1eee420, block=1, dispatch=1, self=<optimized out>) at ../glib/gmain.c:4238
0000040 0x00007ffff4e5328f in g_main_loop_run (loop=0x2d254e0) at ../glib/gmain.c:4438
0000041 0x00007ffff4952fdf in IA__gtk_main () at /usr/src/debug/gtk2-2.24.33-10.fc37.x86_64/gtk/gtkmain.c:1270
0000042 0x00007ffff5389be5 in Gtkmm2ext::UI::run(Receiver&) (this=0x2486d50, old_receiver=...) at ../libs/gtkmm2ext/gtk_ui.cc:309
0000043 0x0000000000db15c4 in main(int, char**) (argc=1, argv=0x7fffffffcac8) at ../gtk2_ardour/main.cc:456
Warning: the current language does not match this frame.
(gdb)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9168 [ardour] features minor have not tried 2022-12-16 12:47 2022-12-16 16:47
Reporter: Pat Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Editor view, also remember edit list and edit mixer
Description: Hello

In the Editor views one can store the track states. However also : edit list and edit mixer and which track is hidden could be stored.

Why
 
One use for Editor view is a fast way to view better tracks. Since the other also helps much to view better tracks, could they be included.

Mbr Patrik
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027104)
x42   
2022-12-16 13:21   
(Last edited: 2022-12-16 13:22)
That should already be the case.

Can you check the file instant.xml - which saves the GUI state - in your session folder?
there should be the following information saved (and later restored)
show-editor-mixer="1" show-editor-list="1" editor-list-page="6"

(0027105)
Pat   
2022-12-16 14:25   
Hello, I checked, that the edit mixer and the edit list states could not be restored. (track zoom state works). I've attached here the file you requested:
<?xml version="1.0" encoding="UTF-8"?>
<instant>
  <LocationUI clock-mode="BBT"/>
  <Main x="0" y="0" w="1366" h="813" current-tab="editor"/>
  <Mixer mixer-rhs-pane1-pos="0.60000002384185791" mixer-rhs_pane2-pos="0.69999998807907104" mixer-list-hpane-pos="0.20000000298023224" mixer-inner-pane-pos="0.80000001192092896" narrow-strips="0" show-mixer="0" maximised="0" show-mixer-list="0" monitor-section-visible="0" foldback-strip-visible="1" show-vca-pane="1">
    <Window name="Mixer" visible="0" x-off="-1" y-off="-1" x-size="-1" y-size="-1" tabbed="1"/>
  </Mixer>
  <Preferences>
    <Window name="Preferences" visible="1" x-off="0" y-off="0" x-size="841" y-size="735" tabbed="0"/>
  </Preferences>
  <Meterbridge show-meterbridge="0">
    <geometry x-size="163" y-size="387" x-pos="3" y-pos="29"/>
  </Meterbridge>
  <Recorder recorder-vpane-pos="0.75">
    <Window name="Recorder" visible="0" x-off="-1" y-off="-1" x-size="-1" y-size="-1" tabbed="1"/>
  </Recorder>
  <TriggerPage triggerpage-hpane-pos="0.23154363036155701" triggerpage-sidebar-page="0">
    <Window name="Cues" visible="0" x-off="506" y-off="27" x-size="856" y-size="711" tabbed="1"/>
  </TriggerPage>
  <ClockModes>
    <Clock name="primary" mode="BBT" on="1"/>
    <Clock name="secondary" mode="Timecode" on="1"/>
    <Clock name="bigclock" mode="Timecode" on="1"/>
    <Clock name="nudge" mode="Timecode" on="1"/>
    <Clock name="EditorTimeInfo-selection-start" mode="Timecode" on="0"/>
    <Clock name="EditorTimeInfo-selection-end" mode="Timecode" on="0"/>
    <Clock name="EditorTimeInfo-selection-length" mode="Timecode" on="0"/>
    <Clock name="EditorTimeInfo-punch-start" mode="Timecode" on="0"/>
    <Clock name="EditorTimeInfo-punch-end" mode="Timecode" on="0"/>
    <Clock name="ToolbarTimeInfo-selection-start" mode="Timecode" on="0"/>
    <Clock name="ToolbarTimeInfo-selection-end" mode="Timecode" on="0"/>
    <Clock name="ToolbarTimeInfo-selection-length" mode="Timecode" on="0"/>
  </ClockModes>
  <LastUsedSnapshot name="pat second"/>
  <Editor id="49" edit-horizontal-pane-pos="0.86783438920974731" notebook-shrunk="0" edit-vertical-pane-pos="0.90518516302108765" mixer-width="Wide" zoom-focus="ZoomFocusPlayhead" zoom="172" grid-type="GridTypeBeat" snap-mode="SnapMagnetic" internal-grid-type="GridTypeBeat" internal-snap-mode="SnapOff" pre-internal-grid-type="GridTypeBeat" pre-internal-snap-mode="SnapMagnetic" edit-point="EditAtMouse" visible-track-count="-1" draw-length="GridTypeNone" draw-velocity="-1" draw-channel="-1" playhead="0" left-frame="176302" y-origin="0" maximised="1" follow-playhead="1" stationary-playhead="0" mouse-mode="MouseDraw" join-object-range="1" show-editor-mixer="1" show-editor-list="1" editor-list-page="0" show-marker-lines="0" show-touched-automation="0" nudge-clock-value="a1411200000@a0">
    <Window name="Editor" visible="0" x-off="-1" y-off="-1" x-size="-1" y-size="-1" tabbed="1"/>
    <Buttons>
      <Press/>
      <Release/>
    </Buttons>
    <Selection/>
    <EditorLocations clock-mode="BBT"/>
  </Editor>
</instant>
(0027106)
Pat   
2022-12-16 16:47   
your wrote it should read as xml as following
show-editor-mixer="1" show-editor-list="1" editor-list-page="6"

My session file was different
show-editor-mixer="1" show-editor-list="1" editor-list-page="0" show-marker-lines="0" show-touched-automation="0" nudge-clock-value="a1411200000@a0">

I did try several time to save with edit list with above elements disabled and the enabled them again. Finally i loaded the saved edit, but it did not affect the elements, only track zoom state.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9078 [ardour] bugs crash always 2022-11-07 19:37 2022-12-16 10:29
Reporter: Jxs Platform: Linux  
Assigned To: OS: Mageia  
Priority: normal OS Version: 8  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when trying to delete first tempo marker
Description: as in summary
Tags: 7.1, crash, Linux, Windows
Steps To Reproduce: 1. Open new empty project
2. select the first tempo marker
3. press Del key
4. crash

Additional Information: One of the messages in the console says: Floating point exception (core dumped)
Attached Files:
Notes
(0026866)
Jxs   
2022-11-07 19:52   
I was actually trying to follow instructions from https://manual.ardour.org/arranging/time-tempo-and-time-signature/techniques-for-working-with-tempo-and-time-signature/
While playing around with tempo changes I experienced weird behaviour and several crashes. Most of them not so easy to reproduce. This bug report is about the simplest case of the problems I had. I will try to see if I can cook up some easy steps to reproduce the others
(0026966)
krischan941   
2022-11-30 15:34   
Confirmed, with Shift-Right-Click on first tempo marker.
(0027102)
Jxs   
2022-12-16 08:33   
Fixed in 7.2, commit https://github.com/Ardour/ardour/commit/db3e87a7e4576cfa8e999adc26d956150e3d9fa9

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9096 [ardour] bugs minor always 2022-11-16 10:54 2022-12-16 08:53
Reporter: cooltehno_bugs Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: urgent OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bug: Set Range to Selected Regions - doesn't match the grid for 25 samples
Description: If you create a MIDI region 750 samples long (1/128 Note) - and then use the operation "Set Range to Selected Regions" (Edit > Select > Set Range to Selected Regions) - this makes range 25 samples shorter than the selection.
Tags:
Steps To Reproduce: 1. Make a new MIDI track.
2. Set the Grid Mode to "1/128 Note" and activate Snap.
3. Draw a new region 750 samples long (1/128 Note).
4. Maximize zoom to the drawn region.
5. Set the mouse to the Grab Mode and select the region.
6. Do the operation: Edit > Select > Set Range to Selected Regions - Ups!! - this makes the range 25 samples shorter than the selection.

(7. Check the length of the rest area of the region - just cut (Ctrl+X) the formed range and look into the properties of the rest part of the region)
Additional Information: A gif is attached
System Description
Attached Files: Set_Range_Selected_Region_bug.gif (514,112 bytes) 2022-11-16 10:54
https://tracker.ardour.org/file_download.php?file_id=4288&type=bug
Nothing_Set_Range_Selected_Region_bug.gif (78,174 bytes) 2022-11-16 11:02
https://tracker.ardour.org/file_download.php?file_id=4289&type=bug
gif

bbt-mismatch.png (54,292 bytes) 2022-11-23 23:14
https://tracker.ardour.org/file_download.php?file_id=4302&type=bug
png

range_consilidate_bug.gif (657,413 bytes) 2022-12-16 08:53
https://tracker.ardour.org/file_download.php?file_id=4329&type=bug
Notes
(0026895)
cooltehno_bugs   
2022-11-16 11:02   
May be this can help somehow: if we select the rest piece of the region and then repeat the "Set Range to Selected Regions" - this does not range anything!! Look at the next gif:
(0026936)
x42   
2022-11-23 23:14   
Further relevant info 48kHz sample-rate 120BPM (48000*120/60/128 = 750)

The "End" is 1 tick before the 128th note, and Length is also reported incorrectly (changing Edit > Position > NOT glue to bar/beats works around this).
The selection uses `selection->set (selection->regions.start_time(), selection->regions.end_time());` and hence from 1|1|0 to 1|1|59 (rather than 1|1|60)
(0027103)
cooltehno_bugs   
2022-12-16 08:53   

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9167 [ardour] bugs major always 2022-12-16 06:30 2022-12-16 06:30
Reporter: musew Platform: Arch  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 7.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Multiple MIDI issues, difficult to separate
Description: This is Manjaro, with ardour 7.1-1.

Multiple issues relating to MIDI, plugins, cues:

1) Plugin interface does not work, especially in the "clips" sidebar - I swtich to ACE Fluidsynth so the drum based clips make sense - then I try and load an sf2 file, but the plugin interface (clicking the button right next to the plugin selector) is either:
    a) stuck on the previous plugin, ACE reasonable synth;
    b) not showing up at all; or
    c) showing the ACE Fluid Synth interface, but then when I load an sf2 file, the "program" slots do not populate with any patches in the dropdown menus; basically I'm stuck using the defaults because it's not showing the proper things to change.
    d) the ACE Fluid Synth programs finally populate but it's random and then if I want to load a new sf2 file, they may or may not decide to update.

     Right now I'm stuck with it not showing up at all.

     The same thing happens sometimes in the ACE Fluid Synth plugin on some of the regular tracks too. I'll load an sf2 and then the interface will not refresh to give me all the patches in the channels (it will be showing the previous sf2 file's patches, and I don't know how to get it to refresh). This was not an issue in Ardour 6.9.

2) I don't know if this is a plugin issue or a MIDI issue, but after drawing a couple of regions (notes only, no program changes or anything), and dragging things around a bit, it seems that there is something in one of the regions that causes the ACE Fluid Synth plugin to revert back to the default patch on the channel I was using. I did not draw any program changes, I don't even know how to do that, and I don't even know if that would effect the patch selection in the Channels in the plugin interface.

3) Cues and Tracks.
    Does a Cue existing in a certain track and then being in that cue's area in the timeline cause that track's actual content to be silent?

4) Inconsistent cue stopping.
    If I am in the "cue" view and I start a region/clip playing, how do I stop it? Do I click on the "play" button again? It seems to have worked once and only once.
    Is the proper way then to click on the "stop" square next to one of the empty cues? What to do then if all the cues are filled up?

Sorry to lump all this together, it all seems related somehow and it's a little hard to tell where one problem stops and the next begins, especially related to the plugins/MIDI.
Tags:
Steps To Reproduce: New session.
Create some MIDI tracks. Assign ACE Fluidsynth to the tracks.
Load an sf2 file in a couple of the tracks, and if you can get the interface to work, assign a patch to the first channel.
Make a couple of regions with MIDI data in them.
Drag the regions around a bit.
(at some point, the Fluidsynth reverts the first channel's patch to the default. Unclear if this is because of something in the MIDI data in the track getting corrupted, or if it's completely independent of that.)

Go to the "cue" view. In the Clips sidebar, choose ACE Fluid Synth. Click the button to the right of the Plugin selector dropdown. Either nothing will show up, or you will get the interface of the previous plugin (ACE Reasonable Synth) which just shows a message about how it is basic and has no options, or you will get ACE Fluid Synth interface, but then the patches won't update in the Channel menus so you won't be able to select anything.
Additional Information: I have videos of some of this happening, can provide them if helpful.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9130 [ardour] bugs crash always 2022-11-29 23:17 2022-12-13 18:57
Reporter: MatthaeusHarris Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Windows crash on zoom
Description: warning: HEAP[Ardour.exe]:

warning: Heap block at 00000000395FF7B0 modified at 00000000396037C0 past requested size of 4000


Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 19496.0x5e4]
0x00007ffaee40a773 in ntdll!RtlRegisterSecureMemoryCacheCallback () from C:\WINDOWS\SYSTEM32\ntdll.dll
Tags: 7.1, crash, Windows
Steps To Reproduce: Zoom in past a certain level in the editor window with a certain region in view. Project file can be provided on request.
Additional Information:
System Description
Attached Files: Ardour-debug.log (107,934 bytes) 2022-11-29 23:17
https://tracker.ardour.org/file_download.php?file_id=4311&type=bug
Notes
(0026963)
x42   
2022-11-30 00:04   
The crash apparently happens when rendering the text for the ruler (Timecore, Bar/Beat, Tempo ...).

Since you say "Zoom in past a certain level in the editor window with a certain region in view."
Can you tell us what the time position is? Perhaps a screenshot of the top of the editor window (clocks, and visible rulers) before you zoom in?
(0027058)
MatthaeusHarris   
2022-12-13 18:57   
Removing the region from my project fixed the issue. If you still think it is the time position that's at fault, I can recreate the project and send a video of the crash, but from what you said it sounds like Ardour crashed trying to render a more detailed view of that region.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9118 [ardour] bugs minor always 2022-11-26 16:17 2022-12-12 07:57
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Copy and Paste midi notes brings only the note visible - but not playable
Description: Linux Mint 21 Cinamon

If i copy in the midi editor a midi note and paste it to the destination, the destination created note is only visible, but is not playing and can't not modify

2nd wish/bug: In overlaping notes.
https://manual.ardour.org/working-with-midi/handle-overlapping-notes/

My setting: replace both overlapping notes with a single note
1. Undo is not working, if 2 notes were combined
2. It works only, if i pull the 2nd note from right to left. If make the left note longer and pull it over the right, no combining. If i only move the left note to the right, no combining, but the right is cut to the duration of the first note.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027031)
paul   
2022-12-12 00:27   
I cannot reproduce the first issue here.
(0027032)
stefan-franz   
2022-12-12 07:57   
Maybe it's solved now.
That problem is solved also - project plays right now.
https://discourse.ardour.org/t/ardour-plays-midi-track-wrong/108016

I make next time a video if it comes again.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9147 [ardour] other feature always 2022-12-06 14:24 2022-12-11 22:39
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Performance is going down or crashes if i load a SF2 file with more than 500GB in the ACE Fluid Synth
Description: If i load a SF2 File with more than about 500 GB Ardour crashes very fast. My device has 16 GB RAM - so Ardour could use it.
An i have a good machine, i7 processor.....in the year 2018 a very fast machine for that time.
System runs on a SSD - the data (Sound files and Sounds, Ardour Project, recording wavs etc) are on a harddrive.
Governor switched to "Performance" mode in Linux Mint 21 Cinnamon
Tags:
Steps To Reproduce: Load huge SF2
Additional Information:
System Description
Attached Files:
Notes
(0027004)
stefan-franz   
2022-12-09 05:50   
Additional Info about performance:
My system: Linux Mint 21 Cinnamon - with the CPUPower GUI i switch always before starting to "Performance"! (default is Powersafe).
My machine: i7 with 16 GB Ram. Linux is on the SSD, the project and used SF2 sounds, Samples for Speedrum Drum Sampler and Sounds for Redux are on a HDD. Same setup as in Cubase.

I have a small project running with about 10 instrument tracks (ACE Fluid Synth and Redux in midi tracks) and Speedrum. At the moment no Audio / Wav tracks. if i let my project playing an click on the tracks e.g. to adjust the level the gui and sometimes the sound runs not fluent.

I'm not a programmer - startet my work with Ardour to contribute the development as i do with Mixxx (DJ Software) -. i'm there a reporter for testing and finding bugs - and let me here write some thoughts - maybe it helps you to improve someting.
First: Comparing Virtual DJ /Win 10 - Mixxx Linux: Mixxx on Linux runs stable and more fluent as Virtual DJ in Win10. Neither my nextcloud client nor the browser brings Mixxx out of step. Virtual DJ had dropouts. So Linux Mint 21 works for me more stable and nearly double fast as Win10. 10 years old machines work now fluent.
So i think Ardour can also run as stable as Cubase or or even with more performance.

Some thoughts: I saw that Ardour is not using the full 16 GB Ram - maybe you can here make something, that Ardour uses the RAM.
The VST integration is not at the moment optimal - maybe that is the reason for performance problems.
Maybe you find a way, that ardour does not let itself be put out of step, if i click through the tracks in the edit mode.

Thanks for your work - after repairing some issues, i post Ardour on social media and make advertise to get more users. I want support linux - and help people to switch from the corrupt Apple or Microsoft group to Linux.
(0027016)
paul   
2022-12-11 05:30   
Fluidsynth is not Ardour, it is a plugin. It does not suprise me that loading a 500GB soundfont into Fluidsynth causes issues, but these are not issues that the Ardour team is likely to be able to address. Did you really mean 500GB or did you mean 500MB?

Please read https://ardour.org/debugging ardour for information about how to get useful backtraces when Ardour crashes.
(0027019)
stefan-franz   
2022-12-11 08:55   
Oh, my fault. I meant 500MB of course. A GM/GS font with about 300 single SF2's in one big SF2.
No i splited up this big files - was my workaround.

Your debugging site is not found.....
(0027020)
groudsquirrel   
2022-12-11 11:17   
I think the debugging page actually is https://ardour.org/debugging_ardour
(0027029)
paul   
2022-12-11 15:23   
Yeah, even with 500MB, the issue is with Fluidsynth, not with Ardour, so it's not something we're likely to be involved in fixing.
(0027030)
x42   
2022-12-11 22:39   
The CrisisGeneralMidi301.sf2 (1.6GB) works reliably here.
Note however that fluidsynth loads the complete file into RAM. For that to work reliably memory-locking needs to be set up.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9156 [ardour] bugs minor always 2022-12-10 17:38 2022-12-11 15:22
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: urgent OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Controller can since 7.1.244 not assigned to the top left buttons (rec, play, stop etc....)
Description: Since 7.1.244 i'm not able to assign the controller to the buttons of the top. Only a few buttons can assigned in the monitor section.
Strg+ middle mouse brings no function alert. The monitor volume works.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027009)
stefan-franz   
2022-12-10 18:24   
Works correct after restart - something was crashed.
(0027010)
stefan-franz   
2022-12-10 18:28   
The error comes only, if i close a open project and opens another. No controller function at the whole top area (play, stop, rec.....)
(0027014)
paul   
2022-12-11 01:11   
MIDI learn control surface bindings are per-session. If you close a session and open another, they will not persist. This is intentional.

If you want persistent control, you should create a binding map and use that.
(0027025)
stefan-franz   
2022-12-11 12:42   
Hmmm.....in all my projects i had assigned my controller for Monitor Leve, and play, stop, rec (not more at the moment).

So if i close a project and load another project (in which the controller is assigned) i would expect as user, that it works. Do you mean that this is not working?
And the monitor level assign works. But not the complete buttons / functions at the toolbar on the top.

About creating a map as you mentioned here:
https://tracker.ardour.org/view.php?id=9144#c27015

It's looks very complicated....let me wish an improvement, that i can create a map with your great learning method:
1. learn the conrtoller to Ardour
2. Export the controller learnings as map
3. Offer the possiblity to manage the map setting and the installation with user friendly menu's

At the end a solution, that the controller settings not deleted, if a project is startet without a controller.
(0027028)
paul   
2022-12-11 15:22   
To repeat: MIDI Learn is a per-session thing, it does not persist across sessions.

As for the binding maps, lots of people have successfully created a binding map for their device. I agree that it would be nice to do MIDI Learn + Export binding map, but this is merely one more nice thing of many thousands of nice things that we haven't had time to do yet.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9157 [ardour] features tweak always 2022-12-11 13:16 2022-12-11 14:48
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Spartanic Gui of the ACE EQ
Description: Since the 7.1.269 the ACE EQ Gui as a spartanical GUI.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Spartanic Gui now for the EQ.jpg (54,522 bytes) 2022-12-11 13:16
https://tracker.ardour.org/file_download.php?file_id=4321&type=bug
jpg
Notes
(0027026)
x42   
2022-12-11 14:15   
Do you use the official binary? Those custom ACE* GUIs are proprietary (provided by Harrison).

Does the following file exist: /opt/Ardour-7.1.269/lib/LV2/Harrison.lv2/a-EQ_gui.so
(0027027)
stefan-franz   
2022-12-11 14:32   
My fault - i download every day the actual nightly build - and today i didn't say yes for "install harrison plugins"
Now all works.
Issue is fixed by user....;-)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9159 [ardour] bugs minor have not tried 2022-12-11 14:37 2022-12-11 14:38
Reporter: HarryR Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Fitting to the Editor Window adds tracks
Description: Situation:

There are several tracks.

I want to fit them to the Editor Window.

After fitting the last track is increased.

In my example I have seven tracks (including master).
After fiting the last track exits seven times

Maybe it's justan "optical" thing, I didn't test this.
Tags:
Steps To Reproduce: Look above
Additional Information:
System Description
Attached Files: Before-Fitting.png (30,353 bytes) 2022-12-11 14:37
https://tracker.ardour.org/file_download.php?file_id=4322&type=bug
png

After fitting.png (34,033 bytes) 2022-12-11 14:37
https://tracker.ardour.org/file_download.php?file_id=4323&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9158 [ardour] features minor have not tried 2022-12-11 14:30 2022-12-11 14:30
Reporter: gunterkoenigsmann Platform: GNU  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ability to set the default template
Description: I don't make music so I have no use for the time signature and tempo meter, but perhaps for the "samples" one. I can even create a template with these settings - but there currently is no way to make ardour use that template automatically by default => a low-prio feature request.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8344 [ardour] bugs minor always 2020-07-31 10:44 2022-12-11 14:21
Reporter: apoorv569 Platform: Arch Linux  
Assigned To: paul OS: GNU/Linux  
Priority: normal OS Version: Arch Linux  
Status: resolved Product Version: 6.2  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unable to launch Ardour.
Description: I was working on a project a day before yesterday, and everything was fine, but today when I tried to open Ardour, nothing opened, tried a couple of more time and nothing showed up. So I tried opening from a terminal to if it outputs some error, it gave some warning about gtk murrine engine not found, so I installed it, and then I tried again and it gets stuck here
```
[apoorv@Apoorv-PC ~]$ ardour6
Ardour6.2.0 (built using 6.2 and GCC version 10.1.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /etc/ardour6/system_config
Ardour: [INFO]: Loading user configuration file /home/apoorv/.config/ardour6/config
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
Ardour: [INFO]: Using SSE optimized routines
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour6/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading default ui configuration file /etc/ardour6/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/apoorv/.config/ardour6/ui_config
Ardour: [INFO]: Loading 449 MIDI patches from /usr/share/ardour6/patchfiles
Ardour: [INFO]: Loading color file /usr/share/ardour6/themes/caineville-ardour.colors
```
I tried waiting for about 15-20 mins nothing happens. I tried removing Ardour and reinstalling again, no luck. After a long time trying to fix it, I gave up and formatted my drive and reinstalled my Arch Installation, after finishing installation, I installed Ardour and tried running it ran fine, but after installing all the other packages that I use on my PC, I rebooted and tried running Ardour, again nothing happens, tried running through terminal still stuck on the same output as I posted above.

One thing if I try to run it as root, it does open.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0024872)
x42   
2020-07-31 12:27   
That smells like a duplicate of https://tracker.ardour.org/view.php?id=5605#c18109 (your user's desktop theme defines colors and conflicts)

try
   export GTK2_RC_FILES=/usr/share/themes/Adwaita/gtk-2.0/gtkrc
or maybe
   export GTK2_RC_FILES=/nonexistent
before starting Ardour
(0024873)
apoorv569   
2020-07-31 12:44   
@x42 I tried running both commands, no luck. Still stays stuck there in the terminal.
(0024876)
apoorv569   
2020-07-31 13:53   
@x42 Well, I tried changing my GTK theme to Adwaita, its opening now. Does it means I won't be able use the theme I want?
(0027013)
paul   
2022-12-11 01:10   
Ardour doesn't really use your system theme anyway.
(0027021)
groudsquirrel   
2022-12-11 11:21   
I posted another duplicate of this in the forum: https://discourse.ardour.org/t/ardour-7-gui-does-not-show-up-with-kde-plasma-breeze-theme/108025
Maybe my workaround helps you.
(0027022)
groudsquirrel   
2022-12-11 11:30   
Ah, GTK2_RC_FILES=/nonexistent works as well. It's probably the better workaround.
(0027023)
groudsquirrel   
2022-12-11 11:39   
One can also put the workaround in ardour's .desktop file:
`Exec=ardour7` -> `Exec=bash -c 'export GTK2_RC_FILES=/nonexistent && ardour7'`

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9155 [ardour] other tweak sometimes 2022-12-09 13:06 2022-12-11 12:29
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Erorr messages - only to look if something is important
Description: Hello, at the top right, there is in Ardour an error signal - opening the window brings that in red.
Ardour works very well - i thought it helps the dev's

2022-12-09T13:36:37 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T13:36:43 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T13:37:12 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T13:37:18 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T13:37:42 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T13:38:05 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T13:39:17 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T13:39:20 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T13:59:56 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T13:59:58 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T14:00:02 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T14:00:05 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T14:00:07 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T14:00:09 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
2022-12-09T14:02:40 [ERROR]: g_log: gtk_box_pack: assertion 'child->parent == NULL' failed
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027017)
paul   
2022-12-11 05:31   
(Last edited: 2022-12-11 05:31)
In order to do anything about those messages, We would need to know what you were doing when those messages were generated.
(0027024)
stefan-franz   
2022-12-11 12:29   
I startet now the 7.1.269 and now i have such log: (Linux Mint 21 Cinnamon)

2022-12-11T13:22:23 [INFO]: AlsaAudioBackend: adjusted output channel count to match device.
2022-12-11T13:22:23 [INFO]: AlsaAudioBackend: adjusted input channel count to match device.
2022-12-11T13:22:23 [INFO]: Scanning folders for bundled LV2s: /opt/Ardour-7.1.269-dbg/lib/LV2
2022-12-11T13:22:25 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:26 [INFO]: harvid version: 900
2022-12-11T13:22:26 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:26 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:26 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:26 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:26 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:26 [INFO]: Lade Menüs von /opt/Ardour-7.1.269-dbg/etc/ardour.menus
2022-12-11T13:22:27 [INFO]: LV2: update midnam for plugin 'General MIDI Synth'
2022-12-11T13:22:28 [WARNING]: Ignored automation data for non-automatable parameter
Ignored automation data for non-automatable parameter
Ignored automation data for non-automatable parameter
Ignored automation data for non-automatable parameter
Ignored automation data for non-automatable parameter
Ignored automation data for non-automatable parameter
.....
-- 100 of same lines as above or below --
..........
Ignored automation data for non-automatable parameter
Ignored automation data for non-automatable parameter
Aux-Send ID 2 ist offenbar schon in Gebrauch
2022-12-11T13:22:28 [WARNING]: Aux-Send ID 2 ist offenbar schon in Gebrauch
2022-12-11T13:22:28 [WARNING]: Aux-Send ID 2 ist offenbar schon in Gebrauch
2022-12-11T13:22:30 [INFO]: LV2: update midnam for plugin 'ACE Fluid Synth'
2022-12-11T13:22:34 [INFO]: LV2: update midnam for plugin 'ACE Fluid Synth'
2022-12-11T13:22:34 [INFO]: LV2: update midnam for plugin 'ACE Fluid Synth'
2022-12-11T13:22:34 [ERROR]: ardour::connect: ungültiger Quellport (ardour:)
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [ERROR]: AudioClock::sample_duration_from_bbt_string() called with BBT mode but without session!
2022-12-11T13:22:35 [INFO]: Lade Benutzer-UI-Skriptdatei /home/stefan/.config/ardour7/ui_scripts
2022-12-11T13:22:35 [INFO]: Entferne MIDI-Patch-Datei custom:urn:ardour:a-fluidsynth:0x557af72b1130
2022-12-11T13:22:35 [INFO]: LV2: update midnam for plugin 'ACE Fluid Synth'
2022-12-11T13:22:35 [INFO]: Entferne MIDI-Patch-Datei custom:urn:ardour:a-fluidsynth:0x557ad4d85070
2022-12-11T13:22:36 [INFO]: LV2: update midnam for plugin 'ACE Fluid Synth'
2022-12-11T13:22:36 [INFO]: Entferne MIDI-Patch-Datei custom:urn:ardour:a-fluidsynth:0x557af80859e0
2022-12-11T13:22:36 [INFO]: LV2: update midnam for plugin 'ACE Fluid Synth'
2022-12-11T13:22:36 [INFO]: Lade Plugin-Reihenfolge-Datei /home/stefan/.config/ardour7/plugin_metadata/plugin_order
2022-12-11T13:22:40 [INFO]: Loading history from /home/stefan/WinD/15-Ardour/Ardour-Projekte/100 Party-DJ-Stefan/Aber bitte mit Sahne - Master/Aber bitte mit Sahne 05/Aber bitte mit Sahne 05.history
2022-12-11T13:24:08 [WARNING]: g_log: Input method gtk-im-context-simple should not use GTK's translation domain gtk20

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9138 [ardour] bugs major always 2022-12-03 16:56 2022-12-11 05:33
Reporter: plehal Platform: Redhat  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: tempo for tracks created using cue window changes when exporting the sound file, but plays fine during the session
Description: Any clips used in track with cue window do not retain their tempo (adjusted using clip Stretch options) when exporting the final sound file. Track plays just fine in the session though. This defeats the purpose of stretch functionality.
Tags:
Steps To Reproduce: Use a clip with a different bpm than the track and use stretch function to adjust the tempo of clip. Record the played sound and export the sound file. The recorded file will be different tempo than exported file.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9136 [ardour] bugs minor always 2022-12-03 14:05 2022-12-11 05:32
Reporter: Pat Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi track directed to bus with synth dont play notes
Description: Hello,

The bus track contains fluidsynth with a gm bank connected.
In the midi track, I can hear notes clicking on the pianoroll ( editor view) and I can draw notes.
But when i start playback i cannot here the notes on the midi track.

Mbr Pat
Tags:
Steps To Reproduce: 1. Create a Midi bus track. insert fluidsynth and a gm bank as plugin on the midi bus track.
2. Add a midi track and direct it to the midi bus. Connect to the same play group.
3. Add some notes on the midi track
4. Try playback.
Additional Information:
System Description
Attached Files:
Notes
(0026971)
Pat   
2022-12-03 17:15   
Hi,

Noticed that the input monitor was activated on the midi track, which did cause this behavior.
If i disabled the input monitor in the editor mixer, the notes playback started to work on the midi track.

So this was not a bug, sorry and can be removed.
(0027018)
paul   
2022-12-11 05:32   
see notes

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9144 [ardour] bugs minor always 2022-12-05 05:28 2022-12-11 01:13
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Controller Setup deleted after starting a project one times without controller (Behringer X-Touch Mini)
Description: Linux Mint 21 Cinnamon
After starting a project (which worked before fine with the controller) without a connected Controller -and restart with connected controller - the project deleted the controller setting.
I had to reconnect manually in the global options, and the complete programming now i must do again.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0027015)
paul   
2022-12-11 01:13   
you should be creating a binding map that persists on disk and can be re-used, edited, copied etc.

https://manual.ardour.org/using-control-surfaces/generic-midi/midi-binding-maps/

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8883 [ardour] bugs minor random 2022-02-25 21:21 2022-12-11 01:09
Reporter: Arkforest Platform: GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour destroys individual MIDI files upon closing and reopening of projects.
Description: I am using Ardour 6.7.0 (rev 6.7) on Bandshed Records' AV Linux (my current OS is based on the outdated MX Linux 19), but this problem also occurred when I used to use Obarun Linux (based on Arch Linux, but with S6 instead of systemd) last year as well, so it's not OS exclusive. There is a small chance (small, but significant) that whenever I close and reopen a project, Ardour destroys a few MIDI files in my music projects. This became particularly problematic with me recently, as I had been manually tuning my vocal takes with x42 autotune and MIDI, and it was those autotune clips I lost, which I struggle to remember the notes for since they're not used the normal way. I have also tried to find it among the interchange and dead folders, but that failed, since the specific files I needed came from another project (I saved this project from another one to reuse the same mix template, and it seems I didn't clear the dead MIDI from the previous project). This bug is one of those ones which is infrequent enough for people to underreport it, and I know the famous musician and YouTuber unfa also has this problem and I, also a somewhat popular musician and YouTuber, am now speaking about this problem too. I would like to be able to find a solution to this problem that can allow it to be patched somehow.
Tags: 6.7, Midi, MIDI region, missing source, overwrite
Steps To Reproduce: It usually happens when I save a project, close a project and then reopen it again. There is a low chance of reproduction with this bug and will potentially need extensive testing.
Additional Information:
System Description
Attached Files: ardourbug1.png (86,829 bytes) 2022-02-25 21:21
https://tracker.ardour.org/file_download.php?file_id=4158&type=bug
png

ardourbug2.png (156,858 bytes) 2022-02-25 21:21
https://tracker.ardour.org/file_download.php?file_id=4159&type=bug
png

ardourbug3.png (168,086 bytes) 2022-02-25 21:21
https://tracker.ardour.org/file_download.php?file_id=4160&type=bug
png

ardourbug4.png (114,309 bytes) 2022-02-25 21:21
https://tracker.ardour.org/file_download.php?file_id=4161&type=bug
png

Screenshot_20220326_085305.png (33,355 bytes) 2022-03-26 06:56
https://tracker.ardour.org/file_download.php?file_id=4172&type=bug
png
Notes
(0026336)
unfa   
2022-02-25 21:35   
I see Ardour 6.9 silently deleting data from MIDI files all the time.
I save a project, I load in the next day or next 15 minutes and some regions are just empty.
Recently I also had a few instances of Ardour refusing to load the entire session because some MIDI file was made empty (0 bytes).
I had to delete that file or remove a reference to in in the .ardour session file.
I don't know if it's the same issue we see here, but I think they all must have a common cause.

Ardour is eating MIDI files on a regular basis and that's just horrible.
PLEASE - FIX THIS!
(0026359)
Bugzey   
2022-03-26 06:56   
I can confirm I encountered this issue too today. After finishing up a project, some midi files were gone with the above described error message the next morning.

The only thing different for me is that I had duplicated a previously existing session using Session -> Save as, and then I continued working on the new session. This new session was affected by the bug, but only midi files added after the duplication disappeared. Midi files that existed in the old session are still there in the new session.

I ran a quick text search, and I'm finding instances of the old session's path still being referenced. I renamed "fiddling" to "fatal piano", and searching for fiddling showed the following:

$ grep fatal\ piano/ -Eire fiddling
fatal piano/fatal piano.ardour: <Option name="audio-search-path" value="/run/media/radi/Archives/Dropbox/Documents/Ardour/fiddling/interchange/fiddling/audiofiles"/>
fatal piano/fatal piano.ardour.bak: <Option name="audio-search-path" value="/run/media/radi/Archives/Dropbox/Documents/Ardour/fiddling/interchange/fiddling/audiofiles"/>

System: Linux 5.15.28-1-MANJARO 0000001 SMP PREEMPT Fri Mar 11 14:12:57 UTC 2022 x86_64 GNU/Linux
(0026388)
paul   
2022-04-16 00:36   
Please describe a precise step-by-step recipe that replicates this behaviour predictably, and I will be happy to take a look.
(0027012)
paul   
2022-12-11 01:09   
I believe that this has already been fixed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9111 [ardour] bugs minor always 2022-11-21 15:03 2022-12-09 16:28
Reporter: Pat Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Menu Edit / Analyze always greyed out
Description: But I can activate Analyze Loudness and Analys Spectral using Right click on an audio file.

I tried this with the imageapp version 7.1. for Mx-Linux and with the demo binary version 7.1 for Windows.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026942)
x42   
2022-11-25 02:11   
Those edit menu actions applies to selected Range (not Region).
(0026944)
Pat   
2022-11-25 09:44   
Ok x42,

Then this is not a bug, but from a usability point of view its not the best solution either.
In my opinion, it would be more intuitive if you have a generic submenu Analysis, which applies to both (greyed out when it doesn't apply).

Mbr Patrik
(0026992)
paul   
2022-12-08 00:53   
We don't have a region-based analysis action at present, so making this change now would not make sense.
(0026999)
Pat   
2022-12-08 08:13   
Hello,

Then let me explain better

In 7.1 i can select an audio object and then from the region menu one can select directly loudness analysis and spectral analysis which is then wrong. But from a usability point of view they could be in edit / analysis sub menu in addition to the case of an active range.

Then it would not need to be not duplicated to the region menu which is the case now.

Also since the analysis has a submenu which can be greyed out in the situations it do not apply.

mbr Patrik
(0027005)
Pat   
2022-12-09 13:15   
Even simpler explanation on a really minor thing

1. Today audio objects work for loudness analysis and spectral analysis
2. But from usability point I suggest they are only in edit / analysis submenu and not in region menu (as you write that they do not work)
3. And in edit / analysis submenu can we se for audio objects and range which work
4. Edit / Analysis has a submenu which can be greyed out in the situations when it don't work

My best regards

- Patrik
(0027006)
x42   
2022-12-09 16:28   
I do agree that it is confusing to have

 * Region > Loudness Analysis...
 * Region > Spectral Analysis...

and for Ranges:
 * Edit > Analyze > Spectral Analysis
 * Edit > Analyze > Loudness Analysis
 * Edit > Analyze > Loudness Assistant

They are however different operations.
I think we may have to add a "Range" menu at some point.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9115 [ardour] bugs minor always 2022-11-26 03:41 2022-12-08 17:54
Reporter: whanake Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Colour of new tracks do not follow stripable-color-palette
Description: Every time a new track in Ardour is created, it gets assigned a random colour. This colour is supposed to be chosen from the 'stripable-color-palette' line in '~/.config/ardour7/ui_config'. However, changing the palette in ui_config does nothing and the colour assigned to new tracks is seemingly random.
Tags:
Steps To Reproduce: Open any existing Ardour session, or create a new one, then start adding tracks.
Additional Information: The colours seem to be assigned in the same order across sessions, but there is no repeating pattern upon initial investigation.
System Description
Attached Files:
Notes
(0026995)
paul   
2022-12-08 01:05   
"This colour is supposed to be chosen from the 'stripable-color-palette' line" ... looking into this, but can find no evidence that this was ever true. Do you have any?
(0026996)
paul   
2022-12-08 04:28   
there is a fix for this (of a sort) now in ardour master branch (git) Would appreciate feedback on how this works for you
(0026997)
whanake   
2022-12-08 04:52   
No, I don't have any evidence, but x42 said he thought this used to be the case in the IRC channel. Either way, would be nice to have the option to set default colours. I'll try compiling from master now and give feedback in a few hours.
(0026998)
whanake   
2022-12-08 07:53   
I have tried the master branch, and I appreciate the colour addition, thank you. Although I wish the colours were added in a sequential order rather than each track randomly selecting a colour from the palette. It looks like they have slight brightness variations too, which is especially prominent when all palette colours are set to the same value. Some more consistency would be nice :)
(0027001)
paul   
2022-12-08 17:54   
the colors are not used more than once, which is why you see the luminance differences after one cycle through the palette

sequential ordering now in place.

finally, we need some way to edit the palette :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9120 [ardour] bugs minor always 2022-11-27 12:07 2022-12-07 05:54
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ranges - 1st not displayed - and not deleteable
Description: I made 2 Ranges, but the 1st is not displayed. And i saw, it's not deleteable.
Tags:
Steps To Reproduce:
Additional Information: 2 improvement-Ideas in Ranges:
If the regions were continuous and colors could be assigned, I would like it very much.

The manual time entry in the list of regions is very cumbersome - a direct click on the respective number you want to change would be great.
System Description
Attached Files: Bereiche.jpg (99,057 bytes) 2022-11-27 12:07
https://tracker.ardour.org/file_download.php?file_id=4306&type=bug
jpg
Notes
(0026982)
stefan-franz   
2022-12-05 14:13   
Sorry, my fault. It's the full Project Range an not deleteable. No Bug.
(0026989)
paul   
2022-12-07 05:54   
see notes

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9143 [ardour] features feature always 2022-12-04 22:03 2022-12-06 23:31
Reporter: nonsequitarian Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Attach description / notes to session snapshots
Description: Over the course of creating a song, I like to use snapshots to capture the state at various points of the process. I also often create a snapshot thread to explore a particular idea that may or may not come to fruition. Right now the only metadata a snapshot has is its name, which usually isn't high fidelity enough for the context I want to include. It'd be delightful to be able to attach a text note to a snapshot so I can more easily keep track of which snapshot is which, especially when returning to a track after a few weeks or more of not working on it.
Tags: snapshots
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026988)
x42   
2022-12-06 23:31   
You could use Ardour Menu > Session > Metadata > Description

The main downside is that it is only visible there (not in the recent session dialog, nor the snapshot list in the editor's sidebar).
The description is also inhered by new snapshots (which may be fine).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9150 [ardour] bugs major always 2022-12-06 19:27 2022-12-06 19:27
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: After adding Redux no further Midi Tracks can added
Description: After making a new midi track with Redux https://www.renoise.com/products/redux Output: Strict I/O - next Window "Automatic" (because i want only in Stereo Mode)
i can't add a further Midi track. The dialogue opens, but i can not select an Instrument - the selection button is greyed out.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9149 [ardour] bugs major always 2022-12-06 17:17 2022-12-06 17:17
Reporter: Pat Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Comment editor content gets deleted.
Description: Ardour can store comments per track. ( I use it to store instrumental information, but sometimes also lyrics for the singer.)

When switching focus to another track, the content is invisible, but when focusing on the original track it does not re-appear.

The information should be shown again when refocusing on that track.

Mbr Patrik

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9140 [ardour] bugs crash always 2022-12-04 10:34 2022-12-05 21:57
Reporter: Hanry Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: immediate OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: after finishing recording ardour crashes, happens with mic recordings and MIDI
Description: every time I'm recording at one point it crashes right after finishing a take. if it doesn't I save it for when it will. sometimes I get an error like "BOOST : terminate called after throwing an instance of 'boost::wrapexcept<std::out_of_range>"
most of the times it gives an error like this ""Thread 61 "butler" received signal SIGABRT, Aborted"" it always happens right as I press stop or space bar after recording a take. doesn't matter if its MIDI or Mic or a direct instrument.
Tags: 7.1, butler, crash after a take
Steps To Reproduce: open ardour, record a few takes longer than 3-4 min. it will crash at some point. sometimes on the first or second sometimes on the 8th take.
Additional Information: I compiled it myself from source
System Description
Attached Files: ardour71_errorlog (2,667 bytes) 2022-12-04 10:34
https://tracker.ardour.org/file_download.php?file_id=4316&type=bug
Notes
(0026986)
paul   
2022-12-05 21:57   
https://ardour.org/debugging_ardour

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9135 [ardour] bugs crash have not tried 2022-12-02 13:37 2022-12-04 14:13
Reporter: Login4Jay Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: urgent OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour Session contains 140 MB of automation data and crashes
Description: i There,

I used fader automation and the whole session is not working anymore, because it got really slow and crashes all the time. I first thought it is the same bug as @tired_eyes reported here https://tracker.ardour.org/view.php?id=9117 ("Automation: combining two [midi] regions create an excessive amount of automation points"). But i have the problem with audio regions and they are not combined. Just huge amount of automation data.

When i load the Session, it takes about one minute which is very long in comparison to other projects i worked on. While loading i see all my 8 GB RAM filling up and also the Swap going up and my system is showing me the note, that ardour is not responding. Once i see the editor view, the session is behaving very slow and playback starts with a delay of about 5 seconds. Sometimes i got notified that my storage (SSD) isn’t quick enough for playing back simple Audio tracks (about 10 Tracks with Flac files).

I realized, that the .ardour file is about 140MB huge. Once i deleted the Track with the Fader-Automation, the session is only 1MB. That means, there was is a ton of automation data in there. That surprises me, because the fader automation (that i recorded) is only for a region of about one minute.
What i find strange, that in the session folder, there is no .history file, but a .history.bak file of 400MB (which you can see in the screenshot). That .history.bak file is from the point of the screenshot on only automation data. I never deleted my .history file (or can it go away with a new snapshot?) and i wonder where it’s gone.
I can’t even show my fader automation data, because ardour is struggling to zoom in.

Besides ot that: Thank you guys for the wonderful DAW that Ardour is. I’m using it for years now and never wanna change!
Tags: 7.1, fader automation, track freeze
Steps To Reproduce:
Additional Information: Ubuntu 22.04.01 LTS
Lenovo ThinkPad T450s
Intel® Core™ i7-5600U CPU @ 2.60GHz × 4
8GB RAM
System Description
Attached Files: inside_the_history.bak-file.png (247,172 bytes) 2022-12-02 13:37
https://tracker.ardour.org/file_download.php?file_id=4314&type=bug
png
Notes
(0026975)
x42   
2022-12-04 10:39   
How did you create that automation-data? have you recorded this fader automation with a control surface?
There was a bug in Ardour7: automation thinning did not work correctly. Usually Ardour removes dense automation points at the end of each write pass. Fixed now in 7.1-207.

If that session is important to you, there are a few ways to recover it:

Either just delete the Automation in the .ardour session file using a text editor.

If it is fader automation, you can use a Lua script that comes with Ardour to remove dense events: Open Window > Scripting . Load script "Snippets > Thin Fader Automation", select the track(s) that have fader automation, press "Run" (in versions prior to 7.1-207. change line 30 from al:thin (50) to al:thin(128000).

You can also safely remove the .history file (that is undo/redo data).
(0026978)
Login4Jay   
2022-12-04 14:13   
Thanks for the response!
I have recorded the fader automation just with ardour by hand with the write mode. Control surface? I didn’t use any extra software or hardware (fader) to do this. So nothing special.

Thanks for the recovery tipps. Luckily i could restore from backup but good to know for the (hopefully not) next time. I’ll try to open my "corrupted" session with Ardour 7.2 when it’s out. In the moment i unfortunately don’t have time to learn how to use lua scripts or to install nightly builds of ardour.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9141 [ardour] bugs minor random 2022-12-04 13:16 2022-12-04 13:19
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Track move by strg+up doesn't work sometimes
Description: I made new tracks and then the shortcut combination "strg+up" doesn't work anymore. It works over the menu "track / selected tracks move up"
Tags:
Steps To Reproduce: Adding new tracks - can't reproduce it...
Additional Information:
System Description
Attached Files:
Notes
(0026977)
stefan-franz   
2022-12-04 13:19   
Found out: Adding a e.g. ACE Eq in any track bringts the shortcut function back

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9139 [ardour] features feature N/A 2022-12-03 19:42 2022-12-03 19:42
Reporter: al f Platform: all  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: Clip preview: loop part of the session, then test clips in sync with the loop
Description: The clip launcher works well when starting with clips and building from there, but sometimes I'd like to do it the other way 'round: starting with existing material and searching for fitting clips.

In that scenario, it would be awesome to be able to loop some part of the session and when browsing clips have them play back in sync with the loop. The start of the clip should start to play when the loop starts from the beginning.

The corresponding text in the manual now is "When playing a clip, Ardour will automatically pause the transport and resume playback when the clip playback is done".

If this feature is implemented it could change to something like "When pre-viewing clips, if Ardour is already playing a loop, the clip playback will be syncronised with the loop".

Tags: cue, loop
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9137 [ardour] bugs minor always 2022-12-03 14:15 2022-12-03 18:39
Reporter: Pat Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Lua script ( at least for voice activation) lacks needed information
Description: The headers which is needed for saving the Lua script is not available, at least not for voice activation Lua plugin.
Information is also needed on where to put ( paste) the script in Ardour.
So the information should be

Mbr Patrik
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026970)
x42   
2022-12-03 16:04   
Can you elaborate? I have just tested and works here.
https://github.com/Ardour/ardour/blob/master/share/scripts/voice_activate.lua
(0026972)
Pat   
2022-12-03 17:20   
Hello,

Yes.

I copied that script to Ardour Window menu / Scripting.
It does run ( says OK)
But when i try to save I get the following:
Missing script header.
The script requires an '{ardour}' info table and a 'factory' function.
(0026973)
x42   
2022-12-03 17:27   
There should be no need to copy it, Ardour comes with that script.
Here it is in C:\Program FIles\Ardour7\share\ardour7\scripts\

> I copied that script to Ardour Window menu / Scripting.

AHA. That console is for GUI script (EditorAction). It is not meant for DSP scripts with run in realtime-context in the mixer.

You load the voice-activate script like a normal plugin in the Mixer Window.
(0026974)
Pat   
2022-12-03 18:39   
Hello,

Ok that clear. I did actually look in the Plugin manager, where it is not, therefore it went wrong.

This plugin is indeed visible only from the mixer. Could it show up also in the Plugin manager?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9133 [ardour] bugs minor always 2022-12-01 17:15 2022-12-01 17:15
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ACE Fluid Synth can't load other SF2 files if LibreArp is used
Description: Linux Mint 21 Cinnamon
If i use libre Arp https://librearp.gitlab.io/ - the ACE Fluid Synth doesn't load new loaded SF2 Files. I can load, but played is always the song before using ACE Fluid used.

Error in LibreArp: The VST3 version (lv2 didn't run) is not able to load or save pattern (no file requester opens). And if i adjust a pattern, the plugin does often not recognize, that something has changed and the save button for save a the preset is not usable.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Bildschirmfoto vom 2022-12-01 18-08-56.jpg (4,675 bytes) 2022-12-01 17:15
https://tracker.ardour.org/file_download.php?file_id=4313&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9132 [ardour] bugs minor always 2022-11-30 22:45 2022-12-01 13:29
Reporter: domingo Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Jack Transport: LUA script for snapping region to playhead behaves bizarre
Description: OS: Linux Manjaro Gnome 43
Ardour 7.1

A LUA script for Ardour 7.1 moves a region to the playhead (included on 'Additional Information'). It works fine when timecode is set to INT, but using JACK as timecode master produces a strange effect. After running the script the selected region will move a few frames after the playhead, instead of the playhead itself. ie., If the playhead is at 00:10:00:00, the region will fall on 00:10:00:02.

Jack Transport is interfaced by QJackCtl 0.9.8, JACK version 1.9.21.
I noticed the failure in sync with Blender, but it also occurs when Ardour is the only Jack client.

A related discussion of the issue here: https://discourse.ardour.org/t/snap-audio-region-to-playhead-ardour-7/107972/6


Tags: jack, Lua, playhead, script, sync, timecode, transport
Steps To Reproduce:
Additional Information: =====================
LUA Script
=====================

ardour {
  ["type"] = "EditorAction",
  name = "Move Regions to Playhead",
  license = "MIT",
  author = "Ardour Team",
  description = "Move selected regions to playhead position"
}

function factory () return function ()

  local sel = Editor:get_selection () -- get current selection
  local sel_regions = sel.regions:regionlist() -- get selected regions

  local playhead = Session:transport_sample () -- get playhead position

  -- prepare undo operation
  Session:begin_reversible_command ("Move Regions to Playhead")

  -- iterate over selected regions
  for region in sel.regions:regionlist ():iter () do
      -- prepare for undo operation
      region:to_stateful ():clear_changes ()

      -- move region to playhead position
      region:set_position (Temporal.timepos_t (playhead))

      -- collect undo/redo diff
      Session:add_stateful_diff_command (region:to_statefuldestructible ())
  end

  -- all done, commit the combined Undo Operation (if any)
  if not Session:abort_empty_reversible_command () then
    Session:commit_reversible_command (nil)
  end

end end
System Description
Attached Files: Screenshot from 2022-11-30 19-20-58.png (66,355 bytes) 2022-11-30 22:45
https://tracker.ardour.org/file_download.php?file_id=4312&type=bug
png
Notes
(0026967)
x42   
2022-11-30 23:22   
can you add a

  print (Session:transport_sample ())

and run the script in Window > Scripting (so that the output is visible)
Assuming a sample-rate of 48kHz, the result at 00:10:00:00 should be 48000 * 10 * 60 = 2880000
(0026968)
domingo   
2022-12-01 13:29   
Running the script with JACK timecode prints: 28804096
With INT timecode: 28800000

Playhead at 00:10:00:00

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9131 [ardour] bugs crash have not tried 2022-11-30 10:11 2022-11-30 10:11
Reporter: Pat Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour refuses to reopen project.
Description: I am not certain what caused this, but i did change browser (from Brave to Firefox). I also before this installed pipwire, but Ardour successfully opened the project after that. Also this is the only project i have, so It is not possible that a cleanup from another project has caused it. Re-installing Brave did not help either.

I have added the error description i get when i try to open the project.

Session "/home/pat/pat first (snapshot pat first)" did not load successfully:
Cannot initialize session/engine: Invalid or corrupt session state.

---ERROR: Could not set session state from XML
ERROR: Session: cannot create Playlist from XML description.
ERROR: Playlist: cannot create region from XML
ERROR: Session: XMLNode describing a AudioRegion references an unknown source id =159856
ERROR: Session: cannot create Region from XML description. Can not load state for region 'Take35_Audio 2-1'
ERROR: Session: XMLNode describing a AudioRegion references an unknown source id =159856
...
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9128 [ardour] features minor have not tried 2022-11-29 19:10 2022-11-30 07:06
Reporter: Pat Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Voice/Level Activate plugin location?
Description: Voice activated recording was possible using a plugin called Voice/Level Activate according to the Tutorial.

It is however not among the plugin that came with Ardour 7.1.

So can you advise on where to find it?

My best reagrds Patrik

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026958)
x42   
2022-11-29 19:28   
It is a Lua DSP plugin: https://github.com/Ardour/ardour/blob/master/share/scripts/voice_activate.lua

I've just checked it is available in Ardour 7.0 and 7.1 from ardour.org/download
Where did you get ardour from?
(0026964)
Pat   
2022-11-30 07:06   
Hello

My version 7.1. As a customer I downloaded it after buying from you as download.

If it is a Lua script inside Ardour, please describe where.

Or I can also download the script from your link and run it, and get the header syntax from other Lua scripts
But then i need to know which category of Lua scripts it should be in. There are 3 different ones.

 Mbr Patrik

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9129 [ardour] features feature have not tried 2022-11-29 22:13 2022-11-29 22:13
Reporter: johnmayqwerty Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Git friendliness
Description: Built-in integration with Git would be awesome. Like, point at a repo, commit, push, with appropriate ignore settings. You could go crazy with this, but maybe just enough built-in functions to make musicians happy.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9126 [ardour] bugs minor always 2022-11-29 16:41 2022-11-29 20:13
Reporter: hyph3n Platform: Fedora  
Assigned To: OS: Linux  
Priority: normal OS Version: 37  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: System Screensaver Mode has no Effect in Fedora 37
Description: By default, Ardour is configured to inhibit the system screensaver while recording, and it also offers the option to inhibit the screensaver while Ardour is open. Regardless of the setting used, Fedora 37's screensaver starts after its configured idle period, apparently causing xruns in the process.

This occurs on a clean installation (not an upgrade) of Fedora Workstation 37.
Tags:
Steps To Reproduce: 1) In Preferences>Appearance>System Screensaver mode, configure Ardour to either "Inhibit while Recording" or "Inhibit while Ardour is running"

2) Leave the machine idle for an appropriate amount of time (ie. if screensaver is configured to start after 5 minutes, leave the computer idle for 5+ minutes)

Expected result: Ardour prevents the screensaver from starting.
Actual result: Screensaver starts.
Additional Information:
System Description
Attached Files:
Notes
(0026956)
x42   
2022-11-29 16:48   
Are you using Wayland instead of X11/Xorg?
(0026959)
hyph3n   
2022-11-29 19:44   
Yes, correct. Wayland is the default for Fedora Workstation and I believe for Ubuntu now as well.
(0026960)
x42   
2022-11-29 20:01   
Not sure what we can do about this, perhaps with Ubuntu moving to Wayland will raise more attention. Ardour is not alone here:
https://bugs.freedesktop.org/show_bug.cgi?id=89440
https://gitlab.freedesktop.org/xorg/xserver/-/issues/675
(0026961)
hyph3n   
2022-11-29 20:12   
One simple workaround is to lengthen the "Blank Screen Delay" setting in the OS. However, the longest option offered by default is 15 minutes. If you need to delay the screensaver for longer than that, I believe this command will create new options in the list:

gsettings set org.gnome.desktop.session idle-delay 1800

Where 1800 represents the number of seconds you want the idle timeout to be (1800/60 = 30minutes). I haven't tested this on Fedora specifically, but I used it successfully on an Ubuntu 20.04 machine in the past.
(0026962)
hyph3n   
2022-11-29 20:13   
Ah, I stand corrected--there is also a "Never" option in Fedora. If you want something between 15 minutes and never, the above command should apply. :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9127 [ardour] features feature sometimes 2022-11-29 18:45 2022-11-29 18:45
Reporter: eqeqeqweqeq Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: master fader not follow track color
Description: watch Attach file
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot.png (337,941 bytes) 2022-11-29 18:45
https://tracker.ardour.org/file_download.php?file_id=4310&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9124 [ardour] bugs minor always 2022-11-27 17:31 2022-11-29 16:57
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Save as new project error, if (unused) sounds not found
Description: In my project i tested some SF2 Files with the ACE Flud Synth. Some then i deleted or moved to another directory on my harddisk.

Not after saving as new project this comes:

Save As failed:
copying "/home/stefan/WinD/15-Ardour/Ardour-Projekte/110 Eigene Songs/Ole - Master/Ole/Ole - Stefan Franz/externals/Laidbass.sf2" failed !

In the project this sound is not used neither the ACE Flud Synth is used.....
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026957)
Daniele1971   
2022-11-29 16:57   
it happened to me too in the past with Ardour 6.9.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9125 [ardour] bugs minor always 2022-11-29 06:13 2022-11-29 06:13
Reporter: hyph3n Platform: Fedora  
Assigned To: OS: Linux  
Priority: normal OS Version: 37  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 7 Can't Autostart ALSA Backend
Description: The “Autostart” option in the Audio/MIDI setup dialog (or Preferences>General>Try to auto-launch audio/midi engine) has no effect on a fresh install of Ardour 7.1.0 when using the ALSA backend. When I had Ardour configured to use pipewire’s JACK, it started up without displaying the Audio/MIDI setup dialog. When configured to use ALSA, it shows the Audio/MIDI setup dialog every time, even when autostart is enabled.

I'm using a single audio device for both input and output, and have confirmed that a recent .ardour session file lists the correct input-device and output-device.

Original forum post here: https://discourse.ardour.org/t/ardour-7-cant-autostart-alsa-backend/107960
Tags:
Steps To Reproduce: 1) On a fresh Fedora 37 install (using pipewire) configure Ardour to use ALSA backend.

2) Ensure "Autostart" is selected in the Audio/Midi Setup dialog (or Preferences>General>Try to auto-launch audio/midi engine).

3) Start Ardour.

Expected result: Ardour starts the audio engine automatically.
Actual result: Ardour prompts the user to start the audio engine manually.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9122 [ardour] bugs minor always 2022-11-27 13:23 2022-11-27 23:40
Reporter: lorenzosu Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour generates un-open-able session (XML) when archiving a session which has stero wav files as sources
Description: Archiving a session via File > Archive which had stereo files as sources. In turn these were encoded into mono FLAC but their channels retained in the <Sources> as 0 an 1 (see attached)

Changing the destination session by hand in a text editor and setting all the sources' channel attribute to 0 (i.e. channel="0") fixes the session and Ardour can successfully open it.
Tags: 7.1, archive, unable to load
Steps To Reproduce: - Have a session which has stereo wav file(s) as source(s)
- File > Archive
- Make sure some FLAC compression is selected
- Archive
- When done, uncompress the archive and try opening the session
- Ardour gives an error simlar to the following
In a dialog:
Session "/home/lo/ardour_sessions/Valentina_prova_2017_07_15_2022-11-27_134626 (snapshot Valentina_prova_2017_07_15_2022-11-27_134626)" did not load successfully:
Cannot initialize session/engine: Invalid or corrupt session state.

---ERROR: Could not set session state from XML
ERROR: Session: cannot create Playlist from XML description.
ERROR: Playlist: cannot create region from XML
ERROR: Session: XMLNode describing a AudioRegion references an unknown source id =336
ERROR: Session: cannot create Source from XML description.
ERROR: Found a sound file that cannot be used by Ardour. Talk to the programmers.
...

On the terminal:
ERROR: SndFileSource: file only contains 1 channels; 1 is invalid as a channel number
ERROR: Found a sound file that cannot be used by Ardour. Talk to the programmers.
ERROR: Session: cannot create Source from XML description.
ERROR: SndFileSource: file only contains 1 channels; 1 is invalid as a channel number
ERROR: Found a sound file that cannot be used by Ardour. Talk to the programmers.
ERROR: Session: cannot create Source from XML description.
ERROR: SndFileSource: file only contains 1 channels; 1 is invalid as a channel number
ERROR: Found a sound file that cannot be used by Ardour. Talk to the programmers.
ERROR: Session: cannot create Source from XML description.
ERROR: SndFileSource: file only contains 1 channels; 1 is invalid as a channel number
ERROR: Found a sound file that cannot be used by Ardour. Talk to the programmers.
ERROR: Session: cannot create Source from XML description.
ERROR: Session: XMLNode describing a AudioRegion references an unknown source id =336
ERROR: Playlist: cannot create region from XML
ERROR: Session: cannot create Playlist from XML description.
ERROR: Could not set session state from XML
Additional Information:
System Description
Attached Files: ORIGINAL_Session.ardour (118,575 bytes) 2022-11-27 13:23
https://tracker.ardour.org/file_download.php?file_id=4307&type=bug
BROKEN_session.ardour (118,695 bytes) 2022-11-27 13:23
https://tracker.ardour.org/file_download.php?file_id=4308&type=bug
Notes
(0026955)
x42   
2022-11-27 23:40   
Fixed in Ardour 7.1-177-g842f4517de

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9123 [ardour] bugs major always 2022-11-27 14:19 2022-11-27 19:16
Reporter: 71bpm Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bars & Timecode Ruler do their own thing ;-)
Description: Ahh, the Bars:Beats and the Timecode ruler move, yes, they dis-align with respect to the editor grid -- please refer to the operational steps to reproduce this bug as described below.

This problem happens consistently, however there is at least one inconsistency that I wasn't able to isolate so far: In the project where I first noticed this bug starting playback would realign the Bars:Beats ruler to the grid. On the other hand, in the test file (attached) the ruler remains dis-aligned and closing/reopening the session is needed to fix it.
Tags:
Steps To Reproduce: 1. Create a new session, 48kH
2. Create a mono audio track
3. Record anything at least a few bars long at 120 bpm (I recorded 6 bars)
4. Position playhead at bar 3 (or anywhere left of bar 2, even beyond session end) with the shortcut P
5. Move playhead to the left with the cursor key
6. Snap is on, when I reach bar no. 2 the bar & timecode ruler move to right and do not match the bar grid of the editor anymore. They stop moving after a "width of approximately 1.5 bars left of 00:00:00:00" (sorry, I cannot express this any better).

Sidenotes:
- The ruler seems to make bigger steps to the right when Snap is set to Bar, whereas the steps are smaller with Snap set to 1/16 or 1/128.
- Nothing happens when moving the playhead to the right and before reaching bar no. 2 when moving left.
Additional Information: Please find the Ardour file that I used to explore this strange behavior attached.

I use AV Linux, please ask if you need more specifications.
System Description
Attached Files: TestBuggyBarsDisplay.ardour (43,358 bytes) 2022-11-27 14:19
https://tracker.ardour.org/file_download.php?file_id=4309&type=bug
Notes
(0026954)
71bpm   
2022-11-27 19:16   
Edit: "width of approximately 1.5 bars left of 00:00:00:00" is not accurate, it seems to depend on the zoom level but in fact I am not sure about this, also what I said about "bar no. 2" is crap, in another project it is not bar 2 but anyway the problem persists across diverse sessions.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9071 [ardour] bugs major always 2022-11-05 20:30 2022-11-27 16:43
Reporter: krischan941 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Editor List doesn't really work on Windows
Description: Ardour on Windows 11. I can't really interact with "Tracks & Bus"-Tab in Editor List. I can not check or uncheck f.e. visibility state or active state. I also cannot rename tracks und busses. Click or double click to call/do these actions does nothing. The same in Sources and Regions Tab. F.e. double click "Tags" does nothing. Only "Track & Bus Groups" Tab works as expected.

I discovered this issue as I wanted a track in the Editor view to add to Cue page afterwards. I think a possibility to do so via right click a track and a option below "Active" or so would be nice as well.
Tags:
Steps To Reproduce:
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0026885)
Napadator   
2022-11-12 22:58   
You need to hold Alt key and left click to check or uncheck or to rename.
(0026887)
krischan941   
2022-11-13 06:21   
Indeed. It should work without holding Alt key (like on Linux).
(0026888)
Napadator   
2022-11-13 10:20   
Yeah, I don't see any reason why it shouldn't.
(0026952)
NickyP   
2022-11-27 16:36   
In Ardour 7, Windows 11 it worked fine without having to hold the ALT key.
(0026953)
NickyP   
2022-11-27 16:43   
Sorry, I meant in Ardour 6.9.0 it worked fine

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9121 [ardour] features feature N/A 2022-11-27 12:48 2022-11-27 12:48
Reporter: lorenzosu Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow to preserve original time/date when archiving
Description: The Archive functionality is rather useful in particular to archive older projects, e.g. using audio compression (e.g. FLAC). However the new file and compressed Ardour session are created with the current time and date. For archival purposes it would be useful to have an option to preserve the original time/date so that in the future one can track when the session was last saved. AFAIK the original session creation and save timestamps are not preserved anywhere.
Tags: 7.1, archive
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9119 [ardour] bugs major always 2022-11-26 16:56 2022-11-26 17:44
Reporter: Pat Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: urgent OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: for mono recordings, normalize nor gain work
Description: I recorded in mono, and the editor mixer readings are Out left/Out right, fader is on 2.0 and fader automation mode is active (button P)
Neither normalize nor boost gain works.
Selecting Properties I can however select region gain (tried up to 21 dB) which works.

I have not tested stereo recording so it might be there too.

Tags:
Steps To Reproduce: 1. Create mono audio track and record
2. Activate the recorded audio, and select Normalize or Boost gain from right mouse mouse.


Additional Information:
System Description
Attached Files:
Notes
(0026949)
Pat   
2022-11-26 17:44   
Hello,

I recorded once more, but with a higher volume, and this time Normalized worked ( on the same track, same track parameters).
The difference to the first one was that the volume was really low (needed to ampify it 21dB) and that it was the first audio recording in a new project.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9116 [ardour] bugs minor have not tried 2022-11-26 13:26 2022-11-26 13:29
Reporter: tired_eyes Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Automation: unable to select the rightmost point
Description: It's impossible to select the rightmost automation point if automation line spans it's entire region. Please see the attached screenshot
Tags: 7.1, automation
Steps To Reproduce:
Additional Information:
System Description
Attached Files: automation.png (117,964 bytes) 2022-11-26 13:26
https://tracker.ardour.org/file_download.php?file_id=4303&type=bug
png
Notes
(0026947)
tired_eyes   
2022-11-26 13:29   
It's still possible to edit the rightmost point by temporary expanding the region to the right

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9083 [ardour] bugs crash always 2022-11-08 16:49 2022-11-25 13:25
Reporter: Daniele1971 Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: segfault in libardour opening a session made with 6.9
Description: I've a session made with Ardour-6.9 (openSUSE build), official 7.1 crash on loading::
RT-7-(nil)[4038]: segfault at 0 ip 00007f88a1579b4a sp 00007f889b17d8d0 error 4 in libardour.so.3[7f88a0e00000+d54000]

Does not crash with 7.1 openSUSE build (tested by a friend, we're both on TW)

Session its an unfinished project, so it's small without strange things..

I'd like to attach the session archive but there' s an error: "413 Request Entity too large". The archive is 1,7mb
(https://discourse.ardour.org/t/bugtracker-upload-size/107847)

If may help, loading the session with official 6.9, Ardour warns about a missing plugin (samplv1) untrue it's selectable from plugin window and no issue with the openSUSE build.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026870)
Daniele1971   
2022-11-08 18:29   
Sorry, some corrections: with the openSUSE builds:
7.0 -> ok
7.1 -> crash

official package:
6.9 -> ok *
7.0 -> ok *
7.1 -> crash

(*) missing samplv1 plugin
(0026941)
x42   
2022-11-25 01:54   
Could it be that the session has a track that has a MIDI output, but no MIDI input?

If so that should meanwhile be fixed in ardour/git.
(0026945)
Daniele1971   
2022-11-25 10:40   
Tested Ardour-7.1.168 and it's ok.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9114 [ardour] bugs major always 2022-11-22 13:28 2022-11-24 03:42
Reporter: Pat Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Vsti dont work after saving and restarting with fluidsynth disabled
Description: I have fluidsynth connected to gm soundband.

Original state : fluidsynth is playing drums ok
de-activated fluidsynth and restarted ardour
Now after re-activate fluidsynth no sound (could not enable it )
After one more Ardour restart, fluidsynth now only plays the last two notes ive insterted
After re-selecting fluidsynth patch, and channel 10 (drums) i got it working normally again.

It seems that the fluidsynth configuration is not save successfully.

Tags:
Steps To Reproduce: 1. Disable fluidsynth
2. Save and restart Arduor
3. Activate fluidsynth
4. Try playback again, note that its not ok
5. Restart Ardour
6. Try playback, note only newest notes play.
Additional Information:
System Description
Attached Files:
Notes
(0026934)
x42   
2022-11-23 19:31   
The patch/progam state is not saved as part of the plugin, but Ardour's MIDI track (this way it also works with external synths).
When re-loading a session Ardour replays bank/patch changes, but i the plugin is disabled it will not process those events.

So this is more or less expected behavior.

A more reliable solution is to add the bank/patch changes to the MIDI region, so that they are sent to the synth whenever you play though them (not just at session load).
(0026938)
Pat   
2022-11-24 03:42   
Hello x42

I like to add some more related issues which you might take into account
- When Ardour restarted it was in a state where it could not play fluidsynth sounds at all ( tested that audio played so no sound card issues)
- When selecting drums in fluidsynth using GUI i also select Midi channel 10. But Ardour does not read the channel right from the GUI so i have to set the channel to play only on channel 10 from Ardour track right mouse menu.
- The plugin state should be saved as above (with channel info and VSTI activation status) also if the midi track is deleted and recreated.
- And the information should also be in patch changes in the Midi.

So i assume based on above that :
. Ardour need to save also the Midi channel from GUI configuration, and it should also have a default channel if no channel has been set
- The Vsti state need to be saved with on/off status. It should be read "on the fly" ( not written in the midi file) in the beginning of midi track playback. so that any previous patch changes in the midi track need to partially or fully override that information.

Mbr Patrik

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9113 [ardour] bugs minor always 2022-11-22 11:40 2022-11-22 11:40
Reporter: nicbeu Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Display of paths in the project settings dialog
Description: Although you can make the project settings window larger, the paths are not fully displayed.
Tags: 7.1
Steps To Reproduce: Open project settings dialog, go to Locations and take a look at the sessions folder paths.
Additional Information:
System Description
Attached Files: Bildschirmfoto 2022-11-22 um 12.17.34.png (107,795 bytes) 2022-11-22 11:40
https://tracker.ardour.org/file_download.php?file_id=4300&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9112 [ardour] bugs minor always 2022-11-22 09:53 2022-11-22 10:07
Reporter: DavidB Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Current Preferences GUI and Font scaling value isn't obvious if not 100%
Description: Seen on both Linux and Windows 10.

Preferences > Appearance > Size and Scale > GUI and Font scaling

The currently selected scaling value isn't obvious if it's not 100%. There's only one value above the slider, i.e. 100%.

Possible suggestions:
* Put other static values above the slider, although they probably won't all fit.
* Have the currently selected value displayed (and it dynamically changes as the slider is moved).
* Remove the slider and just allow the user to type in the value or select from a list of values.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: gui-and-font-scaling.png (21,271 bytes) 2022-11-22 09:53
https://tracker.ardour.org/file_download.php?file_id=4299&type=bug
png
Notes
(0026932)
DavidB   
2022-11-22 10:07   
Putting static 50% and 200% values above the slider would be helpful, and presumably would be a quick fix.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9110 [ardour] features minor N/A 2022-11-21 11:01 2022-11-22 04:51
Reporter: Pat Platform:  
Assigned To: paul OS:  
Priority: high OS Version:  
Status: resolved Product Version: 7.1  
Product Build: Resolution: won't fix  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Need for compressed audio format
Description: Hello,

Ardour 7.1 is a inspiring Daw, thanks to you!

I suggest that you add Ogg compression to the existing media formats in the Session properties. My actual target is that a 3 minutes stereo track would consume less that 10 Mb. I think this need is generic for both linux and windows.

Motivation
i record songs with 4-8 audio tracks, and I noticed that I can easily consume 0.3 - 0.5 Gb per song, even using the flak compression, which is too much. I have a netbook running Linux ( MX linux) with a 32 Gb disk.

I also would add out that several other daws (like Reaper) has support for Ogg (and indeed Mp3) for similar reasons..

Thank you
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026921)
paul   
2022-11-21 18:15   
We will not add lossy compression formats to the native format list for Ardour. FLAC is available (lossless compression). Disk space is cheap, data lost by compressing to vorbis or mp3 is not. You can export to any of these formats, but they are not appropriate as the internal data format for a professional tool.
(0026925)
paul   
2022-11-21 21:53   
(Last edited: 2022-11-21 21:54)
Memory is not used by DAW-created audio files, only disk space. I haven't seen a laptop in some time that has less than a *huge* amount of space, and the ones that do not will accept external USB3 drives, which are cheap and fast enough.

FLAC will still save you a significant amount of space compared to WAV/AIFF, and has no quality issues.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9067 [ardour] bugs crash always 2022-11-04 17:42 2022-11-22 01:24
Reporter: prokoudine Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when playing back a tempo ramp and a TS change
Description: 1. Open the attached session (archived)
2. Place a 6/8 time signature at bar 3 (right in the middle of a tempo ramp)
3. Start playback
4. BOOM

This is an optimized 64-bit of v7.1 for Linux, running on Ubuntu 22.04.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: markers-2022-11-04-12-20-23_2022-11-04_203831.ardour-session-archive (6,383 bytes) 2022-11-04 17:42
https://tracker.ardour.org/file_download.php?file_id=4276&type=bug
Notes
(0026852)
x42   
2022-11-04 17:49   
libs/temporal/tempo.cc:471: Temporal::superclock_t Temporal::TempoPoint::superclock_at(const Temporal::Beats&) const: Assertion `qn >= _quarters' failed.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
0000001  0x00007fe7147f9537 in __GI_abort () at abort.c:79
#2  0x00007fe7147f940f in __assert_fail_base
    (fmt=0x7fe7149716a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fe7169c9c6e "qn >= _quarters", file=0x7fe7169c9a97 "../libs/temporal/tempo.cc", line=471, function=<optimized out>) at assert.c:92
#3  0x00007fe714808662 in __GI___assert_fail
    (assertion=0x7fe7169c9c6e "qn >= _quarters", file=0x7fe7169c9a97 "../libs/temporal/tempo.cc", line=471, function=0x7fe7169c9c00 "Temporal::superclock_t Temporal::TempoPoint::superclock_at(const Temporal::Beats&) const") at assert.c:101
0000004  0x00007fe7169f051b in Temporal::TempoPoint::superclock_at(Temporal::Beats const&) const (this=0x55b1870ee5f0, qn=...) at ../libs/temporal/tempo.cc:471
0000005  0x00007fe7169f1b12 in Temporal::TempoMetric::superclock_at(Temporal::BBT_Time const&) const (this=0x7fe6d5fb58a0, bbt=...) at ../libs/temporal/tempo.cc:667
#6  0x00007fe7169ff89f in Temporal::TempoMap::get_grid(std::__cxx11::list<Temporal::TempoMapPoint, std::allocator<Temporal::TempoMapPoint> >&, long, long, unsigned int) const (this=
    0x55b180e47c10, ret=Python Exception <class 'AttributeError'> 'NoneType' object has no attribute 'pointer': 
empty std::__cxx11::list, start=379258824, end=380463048, bar_mod=0) at ../libs/temporal/tempo.cc:1925
#7  0x00007fe718a638c0 in ARDOUR::LV2Plugin::connect_and_run(ARDOUR::BufferSet&, long, long, double, ARDOUR::ChanMapping const&, ARDOUR::ChanMapping const&, unsigned int, long) (this=
    0x55b1865a8ee0, bufs=..., start=322499, end=323523, speed=1, in_map=..., out_map=..., nframes=1024, offset=0) at ../libs/ardour/lv2_plugin.cc:2668
0000008  0x00007fe71873be31 in ARDOUR::PluginInsert::connect_and_run(ARDOUR::BufferSet&, long, long, double, unsigned int, long, bool) (this=
    0x55b18659b010, bufs=..., start=322499, end=323523, speed=1, nframes=1024, offset=0, with_auto=true) at ../libs/ardour/plugin_insert.cc:1109
0000009  0x00007fe71873d88a in ARDOUR::PluginInsert::automate_and_run(ARDOUR::BufferSet&, long, long, double, unsigned int)
    (this=0x55b18659b010, bufs=..., start=322499, end=323523, speed=1, nframes=1024) at ../libs/ardour/plugin_insert.cc:1377
0000010 0x00007fe71873d4b8 in ARDOUR::PluginInsert::run(ARDOUR::BufferSet&, long, long, double, unsigned int, bool)
    (this=0x55b18659b010, bufs=..., start_sample=322499, end_sample=323523, speed=1, nframes=1024) at ../libs/ardour/plugin_insert.cc:1328
0000011 0x00007fe71881c955 in ARDOUR::Route::process_output_buffers(ARDOUR::BufferSet&, long, long, unsigned int, bool, bool) (this=
    0x55b182750600, bufs=..., start_sample=322499, end_sample=323523, nframes=1024, gain_automation_ok=true, run_disk_reader=true) at ../libs/ardour/route.cc:543
0000012 0x00007fe71881da80 in ARDOUR::Route::run_route(long, long, unsigned int, bool, bool)
    (this=0x55b182750600, start_sample=321459, end_sample=322483, nframes=1024, gain_automation_ok=true, run_disk_reader=true) at ../libs/ardour/route.cc:734
0000013 0x00007fe718832332 in ARDOUR::Route::roll(unsigned int, long, long, bool&) (this=0x55b182750600, nframes=1024, start_sample=321459, end_sample=322483, need_butler=@0x7fe6d5fbb95f: false)
    at ../libs/ardour/route.cc:4007
0000014 0x00007fe7183211eb in ARDOUR::Graph::process_one_route(ARDOUR::Route*) (this=0x55b182db4f70, route=0x55b182750600) at ../libs/ardour/graph.cc:544
#15 0x00007fe71881d8b8 in ARDOUR::Route::process() (this=0x55b182750600) at ../libs/ardour/route.cc:705
0000016 0x00007fe71832ae55 in ARDOUR::GraphNode::run(ARDOUR::GraphChain const*) (this=0x55b182750a50, chain=0x7fe6c80038e0) at ../libs/ardour/graphnode.cc:65
#17 0x00007fe71831f9b8 in ARDOUR::Graph::run_one() (this=0x55b182db4f70) at ../libs/ardour/graph.cc:346
0000018 0x00007fe71832011e in ARDOUR::Graph::main_thread() (this=0x55b182db4f70) at ../libs/ardour/graph.cc:427
0000019 0x00007fe71832a579 in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fe6d5fbbef8, p=0x55b182db4f70) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000020 0x00007fe718329c4d in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fe6d5fbbf08, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000021 0x00007fe718328dd9 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fe6d5fbbef8)
    at /usr/include/boost/bind/bind.hpp:1294
0000022 0x00007fe7183277ae in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000023 0x000055b17f817ce4 in boost::function0<void>::operator()() const (this=0x7fe6d5fbbef0) at /usr/include/boost/function/function_template.hpp:763
#24 0x00007fe6fa9fb541 in ARDOUR::PulseAudioBackend::pulse_process_thread(void*) (arg=0x55b1834f8fc0) at ../libs/backends/pulseaudio/pulseaudio_backend.cc:732
0000025 0x00007fe715725ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000026 0x00007fe7148d3a2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(0026864)
gonsolo   
2022-11-07 10:02   
https://tracker.ardour.org/view.php?id=9049 also crashes at tempo.cc:471.
(0026928)
paul   
2022-11-22 01:24   
should be fixed (crashed here before, now works) with commit f5887b978d4

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8041 [ardour] features minor have not tried 2020-04-22 08:51 2022-11-21 18:40
Reporter: unfa Platform: PC  
Assigned To: x42 OS: Linux  
Priority: normal OS Version:  
Status: resolved Product Version: 5.12  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Switch to Dummy back-end when exporting in non-realtime using JACK
Description: When i export files from Ardour 5.12 on Windows (using PortAudio driver) - the OS sounds still work fine.

When I do the same on Linux using JACK back-end - Ardour switches JACK to freewheel mode for export (unless realtime export is used).

This causes all other sound to be muted, and fro example playing a video in the browser will play at much higher speed and without sound.

It's nice to be able to watch a video while waiting for the export to complete, but regardless of reasons - I see this as a flaw.

I've managed to work this around by switching to a Dummy backend before exporting.

If Ardour would switch to Dummy whenever exporting in non-realtime mode, the export would work as usual, but the user could still use their JACK server normally, play some music or watch a video while waiting for Ardour to finish.

Not to mention if I'm on a VoIP call with a co-worker and I need to export a sound effect for them, my sound will cut off and that's bad.

The Dummy back-end seems like a simple solution. I could do this manually, but it'd be fantastic if Ardour could do it on it's own.

I see that this might be a bit OS-specific, but this would be a huge life quality improvement for me, and (I guess) other people using Ardour as their daily driver for sound work under Linux. It's not an issue on Windows, and I have no idea how it behaves on Mac.

What do you think?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20200423_131352-1.png (62,685 bytes) 2020-04-23 11:18
https://tracker.ardour.org/file_download.php?file_id=3609&type=bug
png
Notes
(0023854)
x42   
2020-04-22 13:38   
The whole point of Ardour/JACK is to allow using external applications in an Ardour Session. Those also need to be included in the export, and switching to Dummy backend would exclude those.

If you don't need this feature, don't use JACK. Like on Windows with PortAudio, prefer Ardour/ALSA (which is also a tad more efficient) or Ardour6/Pulseaudio (if you don't need to record).
Alternatively export using the commandline util /opt/Ardour-5.12.0/bin/ardour5-export (that does use the dummy backend).
(0023859)
unfa   
2020-04-22 16:21   
Oh - I see. I have always kept my Ardour sessions self-contained. Even in the old times of Ardour 2 whenever I used Hydrogen for drums, I would record Hydrogen's output into an audio track first before exporting my Ardour session. I never thought I could route in external software and keep it working. I have heard about using outboard gear (hence the Real-time option), but it never occurred to me I could also use external software.

I use JACK over ALSA, because I often use multiple programs at once, and also I need to use FreeSound very often or reference videos online - if I were to use ALSA, I'd not be able to share my audio I/F with any other program.

I'll see if I can export with the command line utility, though I'll miss the export analysis and summary features. Though maybe I'll create PNG files if I configure that? I doubt that, since these seem to be screenshots of the UI.

Thanks!
(0023860)
paul   
2020-04-22 16:37   
As x42 noted, if you don't need to record, A6 has a PulseAudio backend that does just playback, and allows you to share the interface with other Pulse-using applications.
(0023869)
unfa   
2020-04-22 20:31   
Oh! I missed that! That's interesting - I think it can simplify the work a lot of many people who only sequence and edit, not record!
So far I haven't switched all my work to Ardour6, as there's some bugs I'm waiting to see fixed.

PulseAudio support is mighty neat though! I wonder why doesn't it support capture though?
(0023870)
x42   
2020-04-22 20:55   
Pulseaudio cannot offer reliable capture latency, nor any accurate latency information. So recording overdubs is not possible.

It's also not really suitable for any kind of reliable pro-audio work. The main motivation for this was to offer bluetooth support for guys mixing while traveling.
(0023873)
unfa   
2020-04-23 11:18   
I see. That's gonna be pretty neat.

I wouldn't mind even flawed PulseAudio capture possibility, as for example when I'm doing sound design I record various elements and then edit everything, so timing of my capture is not important.
Though It'd be important that the captured audio is 24-bit (I am not sure if PulseAudio supports more than 16-bit samples?)

Also -I wonder if with the commandline export I can export only selected timeline ranges?

When iterating over sound effects I very often have dozens of CD ranges in my session and I usually export a few at a time to update them.
If I save my session with chosen export ranges, will the commandline utility export only those?
(0023874)
unfa   
2020-04-23 11:37   
I've just tried exporting this session with ardour5-export, but it ended up in a SegFault, so I need to resort to the regular export.
I can try and get a backtrace, but I don't know how to run it in gdb with approperiate commandline arguments.
(0023875)
unfa   
2020-04-23 11:39   
Oh, ok seems like Calf plug-ins can't live in the headless version of Ardour:

ardour5-export[174528]: segfault at 7f7cb00010d8 ip 00007f7c8154c16f sp 00007f7cb00010e0 error 6 in calf.so[7f7c81505000+e6000]

I wonder why is that, but well - that's not Ardour's fault.
(0023876)
unfa   
2020-04-23 11:44   
I've reported the problem to Calf:
https://github.com/calf-studio-gear/calf/issues/249
(0023880)
x42   
2020-04-23 16:55   
Re: "as for example when I'm doing sound design I record various elements and then edit everything, so timing of my capture is not important."

I'm wary of opening Pandora's box. Once that would be possible users will expect it to work. Nobody reads the small print "only use for XXX". Pulse also re-samples when using multiple devices, and all capture settings including volume, are outside or Ardour's control. It is really not suitable to be used in a DAW context.

With some luck pipewire will eventually solve this. PW also supports MIDI (Pulse doesn't).
(0026923)
x42   
2022-11-21 18:40   
The original idea "Switch to Dummy back-end when exporting in non-realtime using JACK" excludes other JACK apps from being exported.
And using external 3rd party apps is the main reason why JACK exists, so this is counterproductive.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8960 [ardour] bugs crash always 2022-09-11 18:59 2022-11-20 18:40
Reporter: secke Platform: x86_64  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 20.04  
Status: acknowledged Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour-6.9 with Presonus Faderport V2 segfaults on Section->Next
Description: Using a Presonus Faderport V2, when I'm in "Section" mode and hit "Next", Ardour reliably crashes.

Also happens in other circumstances, but this is easiest way to reproduce.

It seems that the "Next" button or turning the dial right is part of the misbehaviour in most cases.

Also note that in "Channel" mode (after hitting the button "Channel", when it is lit) the "Prev" button works as expected (selecting the previous track) while "Next" has no discernable effect.

Most other controls seem to work as expected.
Tags: control surface, crash
Steps To Reproduce: * Start Ardour
> bin/ardour6 -n
* Create new session
* Choose "Empty Template"
* Audio setup:
    - Audio System: ALSA
    - MIDI System: ALSA raw devices
* Start
* Configure control surface:
    - Edit -> Preferences -> Control Surfaces -> PreSonus FaderPort2
    - -> Show Protocol Setting: select Faderport MIDI connectors (Faderport device reacts)
* Close dialogs
* On the Fadeport device:
    - Hit "Master"
    - Hit "Section"
    - Hit "Next"

After a few moments, Ardour crashes.

Instead of the crash, I'd expect Ardour to do-the-right-thing™ (e.g. select next region), show an error dialog ("you can't do that here") or do nothing except writing a log entry.
Additional Information: On Ubuntu 20.04 (kernel: Linux 5.4.0-125-generic 0000141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64)
Presonus Faderport V2 attached via USB
Focusrite Scarlett 2i2 soundcard attached via USB (crash also happens with other soundcards)

Ardour version:
> secke@Dobrindt:~$ /opt/Ardour-6.9.0/bin/ardour6 --version
> Ardour6.9.0 (built using 6.9 and GCC version 6.3.0 20170516)

Attached files:
* ardour-log_2022-09-11_003 -> contents of the Ardour log until BEFORE the crash
* ardour-out_2022-09-11_003.txt -> shell output of the Ardour process
* _opt_Ardour-6.9.0_bin_ardour-6.9.0.1000.crash.head -> first part of created crash file, without actual core dump (too big to upload)
* Faderport-Test.tar.gz -> tarball of created session, saved just before triggering the crash

----

MIDI events

In Ardour's MIDI tracer, pressing "Next" in "Channel" mode is reported like this:
> 39566314 NoteOn chn 1 19 7f
> 39566314 NoteOn chn 1 19 00

(Note that in "Channel" mode pressing "Next" does NOT cause a crash, but merely does nothing.)

Using an external MIDI tracer, I see that in "Section" mode, "Prev" and "Next" generate the following MIDI events:
> Controller, Channel 1 | Controller: 60 - Control 28 LSB, Value: 65 # "Section"/"Prev"
> Controller, Channel 1 | Controller: 60 - Control 28 LSB, Value: 1 # "Section"/"Next" (causing the crash)

For comparison, these are "Prev" and "Next" in "Channel" mode:
> Note On, Channel 1 | Note: 46 (A#2), Velocity: 127 # "Channel"/"Prev" (selects previous channel)
> Note Off, Channel 1 | Note: 46 (A#2), Velocity: 64
> Note On, Channel 1 | Note: 25 (C#1), Velocity: 127 # "Channel"/"Next" (does nothing in Ardour)
> Note Off, Channel 1 | Note: 25 (C#1), Velocity: 64
System Description
Attached Files: ardour-log_2022-09-11_003 (2,326 bytes) 2022-09-11 18:59
https://tracker.ardour.org/file_download.php?file_id=4214&type=bug
ardour-out_2022-09-11_003.txt (2,122 bytes) 2022-09-11 18:59
https://tracker.ardour.org/file_download.php?file_id=4215&type=bug
_opt_Ardour-6.9.0_bin_ardour-6.9.0.1000.crash.head (101,788 bytes) 2022-09-11 18:59
https://tracker.ardour.org/file_download.php?file_id=4216&type=bug
Faderport-Test.tar.gz (3,550 bytes) 2022-09-11 18:59
https://tracker.ardour.org/file_download.php?file_id=4217&type=bug
Notes
(0026889)
secke   
2022-11-13 17:16   
Problem persists in Ardour-7.1
(0026898)
secke   
2022-11-17 18:00   
Update: Crash doesn't happen when the Faderport is in "Studio One" operation mode.
As that mode is the one that's to be used with Ardour, the cause for the crash is much more esoteric than I thought at first.
(0026899)
x42   
2022-11-17 18:16   
Great to hear that you have figured this out. I would not have thought of that.

I suppose it still is a bug that ardour crashes when the Faderport is not used in Studio One mode.
Ardour should not crash, and yet still somehow inform the user to change the FP to use S1 mode.
(0026918)
secke   
2022-11-20 18:40   
Additional info on how to reproduce:
The device needs to be in "Cubase / Nuendo (MCU)" mode. (Power off, press and hold Next while powering back on, hit Bypass.)

Then activate control surface PreSonus FaderPort2 in Ardour.

Hit Master > Section > Next.

The crash doesn't occur in other modes. (At least not with this sequence of button presses.)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9108 [ardour] bugs minor always 2022-11-20 18:22 2022-11-20 18:22
Reporter: sollapse Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Changing audio engine state by script fails to update Audio/MIDI menu.
Description: When stopping and starting the audio engine with Lua, the status bar and Audio/MIDI menu still retains is last setting (stopped, when started in the script). The engine however works as expected.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9106 [ardour] bugs crash always 2022-11-20 11:32 2022-11-20 14:07
Reporter: coenplanetc Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Session-conversion from 6 to 7 crashes with segmentation fault
Description: Session is called RAGE
When trying to convert the version-6-session to Ardour 7 it crashes with a Segmentation fault (core dumped)

Base was a session with lots of busses, tracks and plugins but I've cleaned it all up to a stage where there is only one Masterbus, no plugins, no files.
Tags:
Steps To Reproduce: Extract the zip files and open the RAGE.ardour file
Or open the archive-file from within Ardour 7.1.0
In both cases Ardour makes an -6000.ardour backupfile and crashes with the Segmentation fault
Additional Information: Ardour 6.9.0~ds0 (distribution version)
Ardour 7.1.0 (downloaded binary)
Ubuntu Studio 22.04.1 LTS / xfce 4.16
I use Jack 0.9.6 most of the times but I tried it also with Alsa, makes no difference
System Description
Attached Files: RAGE_2022-11-20_111218.ardour-session-archive (3,939 bytes) 2022-11-20 11:32
https://tracker.ardour.org/file_download.php?file_id=4295&type=bug
RAGE_NoConversionTo7Possible.zip (9,683 bytes) 2022-11-20 11:32
https://tracker.ardour.org/file_download.php?file_id=4296&type=bug
Notes
(0026916)
x42   
2022-11-20 13:28   
The issue here is that session's master bus has no MIDI input but a MIDI output.

I'll look into a solution.
(0026917)
x42   
2022-11-20 14:07   
Fixed in 7.1-154-g82512422a7

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9098 [ardour] bugs minor always 2022-11-16 19:25 2022-11-20 04:34
Reporter: gonsolo Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Compile error because glib.h could not be found.
Description: A fix for waf is at:

https://github.com/Ardour/ardour/pull/757
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026896)
gonsolo   
2022-11-16 19:27   
I'm not sure about the minimum version so I just picked the one on my distribution.
(0026909)
x42   
2022-11-20 04:34   
Should be fixed since 7.1-108

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8403 [ardour] bugs minor random 2020-09-13 13:31 2022-11-20 01:17
Reporter: unfa Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Export silence trim is very hard to get working reliably
Description: I'm using export silence trim function in Ardour to export sounds effects for game engines.

I've always had issues with that feature, as it seems to be very pick about input signals.

Example from a job I'm doing currently:

At first trimming wouldn't work unless I disabled Ardour's export dithering - checking the exported files shown dithering noise was present and it stopped trimming from happening - solution: dither after trimming? (EDIT: I've found this to not be true in all cases - read more later).

I've disabled the dither and used NotJustAnotherDither by AirWindows instead, after a Master Limiter and before an LSP noise gate that applied 72 dB of gain reduction if signal was dropping below -60 dB (to make sure the dither noise is not going to trip up the trimming). This worked for a while, but then it stopped and I have no idea why.

Disabling the NotJustAnotherDither plug-in didn't fix it.
Also duplicating the LSP Gate 2 times for a total of 216 dB of gain reduction didn't help either.

I think silence trim needs some work - it's a very good idea, and I'd love to have this working reliably, as it's extremely helpful for working with audio for video games.

Sound effects or music loops are much easier to get working properly in a game engine with this feature, as it's much less error prone than manually aligning export markers.
Because of various issues the only real workaround is to bounce the master bus output to another track and truncate it manually there - which is laborious and error-prone.

---

I've checked my master bus with x42 Bit Meter plug-in - the average level was around - 400 dB, yet trim still was tripped by that.
I've added a Hard Gate plug-in set to 0.0001 threshold (the lowest possible value) and it seems to work now.

I suspect some reverb tail is producing these extremely low level sounds.

Interestingly after I've added this Hard Gate, Ardour's Shaped dither doesn't break the Trim function any more.

Could the export trim function have a customizable threshold and attack/release maybe?
I'm not sure how to get this to work reliably without using a bunch of plug-ins in the master bus and risking quality degradation (the hard gate doesn't seem like a great option, but I don't hear issues, and it fixed the trimming for me).
Tags: export, silence trim
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026907)
x42   
2022-11-20 01:16   
Since Ardour 6.7 the default is -90 dBFS.
Silence trimming is performed before decimation on the float signal, and the given value is more than a factor of two above the max S/N of undithered 16bit audio.
Overall dithering noise (eg. Harrison's channel dithering) is also well below that level.

GIven that it is common to loudness normalize to -23 LUFS (EBU-R 128), this allows for 60dB S/N which is reasonable. Cases that require a steeper cut-off should likely use a expander/gate.
(0026908)
x42   
2022-11-20 01:17   
Ardour v7 will have pushed a config-change to set the value to -90

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9104 [ardour] features feature N/A 2022-11-18 08:56 2022-11-18 08:56
Reporter: thebutant Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: MIDI note info when moving with arrow keys
Description: In Internal Edit Mode (E-mode), when hovering the mouse over a MIDI note, the note info is displayed.
"B4 0000071 etc"

It would be really neat if this info was also displayed when editing with your arrow keys.
The arrow keys are great for moving MIDI notes up and down without losing their positioning, but you have to keep your head pretty straight to remember if 6 steps down gets you to an F or an E.

Really no big issue, but I guess it wouldn't be the most difficult to implement either. And it would be really handy.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9103 [ardour] other trivial always 2022-11-17 23:29 2022-11-17 23:29
Reporter: prokoudine Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Marker discrepancies
Description: ## Creating single markers

All new markers can be added via right-click menu. However, modifier + click/double-click combination doesn't work the same way between different rulers with single markers.

- BBT markers: a new BBT marker can only be added via right-click menu, there is no modifier + click combo.

- Time signature: Ctrl + single click opens a dialog to specify settings, a marker with some default value is not created at that point.

- Tempo: Ctrl + single click places a marker on the ruler, where value is copied from the closest marker to the left of it. Ctrl + double-click creates a marker and opens a dialog to specify settings

- CD Markers: Ctrl + single click places a marker on the ruler and automatically names it. Ctrl + double-click additionally opens a dialog to specify settings

- Location markers: Shift/Ctrl + single click places a marker on the ruler and automatically names it. Shift/Ctrl + double-click additionally opens a dialog to specify settings

- Cue markers: Ctrl + single click places a marker on the ruler and automatically names it. Ctrl + double-click additionally opens a dialog to specify a different name for the marker, however this information is only visible in the Ranges & Marks sidebar.

To reiterate, Ardour seems to gravitate towards the workflow where:

- Ctrl + click places a marker with some default values
- Ctrl + double-click places a marker with some default values and opens the dialog to edit settings

However, not every ruler with markers has that behavior. Moreover, BBT markers don't even respond to modifier + click/double-click.

## Creating paired markers / Range markers

Range markers (as well as loop/punch ranges) can be created directly on the ruler by pressing a modifier, then clicking and dragging.

Range Markers: both Shift and Ctrl work as that modifier. With Ctrl, markers are named using the 'unnamedN' pattern, with Shift, they are 'skipN' (where N is an integer that starts at 1 and is incremented by 1).

Loop/Punch ranges: only Ctrl works as that modifier

CD markers: only Ctrl works as modifier for creating range markers, while Ctrl + Click creates single markers

## Selecting markers

Ardour uses two different ways to tell that a marker is selected: 1) recoloring the background of a marker, 2) rendering the vertical line.

All marker types except one (cue markers) only render the vertical line and recolor a marker's background on hover only. Cue markers do it both ways: selected marker retains the "selected" background color _and_ renders a vertical line.

On top of that, TS and Tempo markers have the color of selected location/cue markers. Which means there is not much visual confirmation for selecting a TS or a tempo marker. They always look selected.

Selecting multiple markers with shift+click affects all rulers except for BBT, TS, and tempo. This doesn't seem to be an expected behavior, while both use cases (moving a range of markers in one ruler or all rulers) have a place. So there should be a way for the user to select a range of consecutive markers on just one ruler or all rulers.

## Moving Markers

"If you happen to drag exactly where the red vertical line of a marker is, then it will drag that marker. A microscopic, 1-pixel-wide interaction area in a UI [is not usable], therefore, it shouldn't be an interactable UI element..."

## Right-click options

All types of markers can be hidden and/or locked. Some types of markers expose this option in the right-click menu and some don't.

Hiding not available in:

- Time signature
- Tempo
- Loop/Punch ranges
- Cue markers

Locking not available in:

- Time signature
- Tempo
- Range markers
- Loop/Punch ranges
- Cue markers

Additionally, the same command (Hide) is called differently. It's _Hide range_ for range markers yet just _Hide_ for CD markers.

## Unexpected behavior

Ctrl + Shift + click creates a copy of the selected location maker and hides the original.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9101 [ardour] bugs minor always 2022-11-17 21:22 2022-11-17 21:24
Reporter: cooltehno_bugs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bug (not able to improve) Blueberry theme: unable to resolve text visibility in the clip launch section
Description: We have almost invisible light text on the light area in the clip launching window in Blueberry Milk theme.

We have two ways to resolve a problem:
1. Make the text -> dark - that is impossible! - There are no items & aliases in the theme file. I've made "one color palette" - it has no result - the text stays the same.

2. Make the area -> dark - that is possible through the changing pallete color: Color name="theme:bg", BUT this involve almost all main items of the light theme.

I've made a list of Aliases, where the "theme:bg" has a place:
    <ColorAlias name="arrange base" alias="theme:bg"/>
    <ColorAlias name="audio automation track fill" alias="theme:bg"/>
    <ColorAlias name="gtk_background" alias="theme:bg"/>
    <ColorAlias name="inactive group tab" alias="theme:bg"/>
    <ColorAlias name="meterbridge label: fill" alias="theme:bg"/>
    <ColorAlias name="midi device: fill active" alias="theme:bg"/>
    <ColorAlias name="monitor section processors toggle: fill" alias="theme:bg"/>
    <ColorAlias name="monitor section processors toggle: fill active" alias="theme:bg"/>
    <ColorAlias name="monitor section solo model: fill active" alias="theme:bg"/>
    <ColorAlias name="monitor section solo option: fill active" alias="theme:bg"/>
    <ColorAlias name="processor control knob" alias="theme:bg"/>
    <ColorAlias name="stereo panner rule" alias="theme:bg"/>
    <ColorAlias name="tracknumber label: fill" alias="theme:bg"/>

 - no one of them can control mentioned clip area.

That mean we need a new SEPARATE Item for clip launching area.
Tags:
Steps To Reproduce:
Additional Information: "One color palette" with unchanged text and desired "dark (violet)" clip launching area pictures - are attached.
Attached Files: palette_independent_text.png (72,805 bytes) 2022-11-17 21:22
https://tracker.ardour.org/file_download.php?file_id=4290&type=bug
png

propose_separate_item.png (191,274 bytes) 2022-11-17 21:22
https://tracker.ardour.org/file_download.php?file_id=4291&type=bug
png
Notes
(0026900)
cooltehno_bugs   
2022-11-17 21:24   
"That mean we need a new SEPARATE Item for clip launching area."

OR - we need a new SEPARATE Item for the clip text (to make it dark)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9097 [ardour] features feature N/A 2022-11-16 14:38 2022-11-16 14:43
Reporter: Attila S. Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make “Plugin analysis” a standalone thing, to be able to use it with graphic plugin ui
Description: In my view it would a be good thing to be able to use the “Plugin analysis” tool independent of the “Edit with generic controls” window.

It would be a good thing to launch it from the right lick menu like the “Edit with generic controls”, or from the plugin window’s toolbar with a button, or something like this, and it would open in a standalone own window.

(Thank You in advance for considering this.)
Tags:
Steps To Reproduce:
Additional Information: Probably, problem 0009074 could be solved with this.
https://tracker.ardour.org/view.php?id=9074
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9074 [ardour] bugs minor always 2022-11-06 15:22 2022-11-16 14:43
Reporter: Attila S. Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Not enough space for the “Plugin analysis” section
Description: For the plugins in the “Edit with generic controls” window the plugin controls often listed in a way that for the additional “Plugin analysis” section not enough space left on the screen/windows. See the attached screenshot.

Probably the controls section should be resizable and scrollable.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: not-enough-space-for-plugin-analysis.png (248,634 bytes) 2022-11-06 15:22
https://tracker.ardour.org/file_download.php?file_id=4277&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9095 [ardour] bugs minor always 2022-11-16 06:46 2022-11-16 06:47
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Eventeditor - On edition a value with the mouse wheel, the list jumps up or down if the rotation direction is chenged
Description: It the event editor is a great feature, that e.g i can chose more events and with the mouse wheel the value (e.g. velocity) for all selected can edited.

But if i change the rotation direction, the list is moved ant some other events were edited.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026894)
stefan-franz   
2022-11-16 06:47   
I meant the Midi Event Editor of course.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9033 [ardour] bugs crash always 2022-10-24 10:15 2022-11-16 03:33
Reporter: Thomas Krocker Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: immediate OS Version: 10  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 7.0 crashes and freezes Windows 10 when deleting a preset in Midi Chord.
Description: By clicking on the delete icon in Midi Chord, Ardor 7.0 crashes and freezes Windows 10.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Ardour 7 Absturz Midi Chord.jpg (170,856 bytes) 2022-10-24 10:15
https://tracker.ardour.org/file_download.php?file_id=4246&type=bug
jpg
Notes
(0026687)
x42   
2022-10-24 12:07   
Confirmed. Those "factory presets" cannot be deleted, and trying do to so currently causes crashes in libserd/sord.
(0026893)
x42   
2022-11-16 03:33   
Fixed since Ardour 7.1-86-g6c3a1d98fe

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9090 [ardour] bugs minor always 2022-11-10 23:41 2022-11-15 23:46
Reporter: Attila S. Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Window > Meterbridge in VU mode has a bad red background
Description: Window > Meterbridge in VU mode has a bad red background
See on the attached screenshot.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: meterbridge-red-vu.png (41,759 bytes) 2022-11-10 23:41
https://tracker.ardour.org/file_download.php?file_id=4285&type=bug
png
Notes
(0026892)
x42   
2022-11-15 23:46   
Fixed in 7.1-90-g16ce8b3331 (back to yellow)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9082 [ardour] bugs minor random 2022-11-08 14:50 2022-11-15 05:06
Reporter: JP_Bennett Platform: Fedora  
Assigned To: OS: Linux  
Priority: normal OS Version: 36  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Playhead occasionally jumps when seeking with a Midi shuttle wheel
Description: Editing a large project (6 tracks, a couple hours of audio), when using a Behringer X-touch One to scroll though the timeline, the playhead will occasionally jump to a previous location. This usually happens after stopping playback, then shuttling, then the playhead will pop back to where playback stopped. Note that Auto Return is disabled.
Tags:
Steps To Reproduce: Large project, Interview Ripple mode, make multiple cuts throughout the project. Then play and shuttle with a shuttle wheel in Mackie Control mode. Not every time, but often enough to be annoying, the playhead will jump.
Additional Information: Next time I'm editing one of these sessions, I'll try to use a screen recorder to capture the exact behavior.
System Description
Attached Files:
Notes
(0026891)
JP_Bennett   
2022-11-15 05:06   
Managed to catch a few instances of this while editing. Most obvious one at 12:25 https://youtu.be/hJFUf0FCM3M?t=745

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9094 [ardour] bugs major always 2022-11-14 19:00 2022-11-14 19:10
Reporter: stefan-franz Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Plugin Selector empty on new start - First need the Plugin Manager, Discover new/Updated Button
Description: Mint 21 Cinnamon

On every new start of Ardour, the plugin selector is empty. After running the Plugin Manager, Discover new/Updated Button, there is list as normal.
Tags: plugin
Steps To Reproduce: Close Ardour, restart.
Additional Information:
System Description
Attached Files:
Notes
(0026890)
stefan-franz   
2022-11-14 19:10   
New insight: It depends on the project. One makes no problem. Other have it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9093 [ardour] bugs minor always 2022-11-12 13:21 2022-11-14 14:05
Reporter: finotti Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Follow playhead does not work when starting from start
Description: If I go to the start of the sessions (like, pressing "home"), the playhead is not followed. If I move it away from the start, it works normally.

I noticed that it works in a new session, until I create a track.
Tags:
Steps To Reproduce: 1) Create a new session.
2) Make sure "Follow Playhead" is selected.
3) Add an audio track.
4) Press "home" or move to start and press play. It does *not* follow the playhead.
4) Put the playhead anywhere else and press play. It does follow the playhead.
Additional Information: This has happened with many past versions. (I think since Ardour5, at least.)
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9088 [ardour] features tweak always 2022-11-09 22:51 2022-11-14 13:56
Reporter: Attila S. Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unifying plugin bypass/on-off function and feedback light
Description: Currently if a plugin is enabled it will have a turned on green light on the mixer view. But if the plugin is opened in its window it will have a turned off red light. If the plugin is disabled/bypassed then on the mixer view the green light will turn off and the red light will turn on in the plugin window.

Now, in my opinion it would be a good idea to unify the behavior of the bypass functions and feedback lights.

So the turned on plugins would be green everywhere and the turned off/bypassed plugins would be red everywhere. Or something like this.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: fig-bypass.png (65,114 bytes) 2022-11-09 22:51
https://tracker.ardour.org/file_download.php?file_id=4284&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9089 [ardour] bugs major always 2022-11-09 23:58 2022-11-12 03:40
Reporter: exxelxior22 Platform: Debian GNU/Linux  
Assigned To: OS: Debian 11  
Priority: urgent OS Version: Bullseye  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When recording with Count-in in MIDI tracks the first beat is not recorded after count-in
Description: When recording a MIDI track and counting in (using "Record with Count-in: in the Transport menu), recording starts after a two-bar count-in, notes played are showed in the track but the first beat is not recorded when stop. This does not happen with Audio tracks.
My Ardour version is
Ardour 6.5.0~ds0
"Old Land"
(rev 6.5.0~ds0-1)
Intel 64-bit

This bug is the same reported in 0007314 dated in 2017. Is there a solution that I've not found?
Thanks in advance.
Tags: 6.5, count-in, Midi, recording
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026878)
x42   
2022-11-10 21:48   
Works here with Ardour 7.1 - however if you play a bit early (just before the last click of the count-in), the note will indeed be ignored.
(0026879)
x42   
2022-11-10 21:48   
Could you test with Ardour 7.1?
(0026882)
exxelxior22   
2022-11-12 03:40   
I've not tested with 7.1 because I'm using the Debian stable version which is 6.5.0+ds0-1

As an aside:
When is recording the first whole beat is in the screen, but when I push stop it disappears entirely and the rest of the beats position at the beginning of the record. In other words: the first beat desappears and the rest of the beats take its place from the second beat.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7314 [ardour] bugs major always 2017-04-11 10:32 2022-11-10 21:45
Reporter: bramilo Platform: Ubuntu Studio  
Assigned To: OS: Ubuntu 16.04  
Priority: high OS Version: Maverick  
Status: new Product Version: 5.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When using Count-in with MIDI tracks, the first beat is not recorded after count-in
Description: When recording a MIDI track and counting in (using "Record with Count-in: in the Transport menu), recording starts after a two-bar count-in, but the first beat is not recorded. This does not happen with Audio tracks.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9087 [ardour] bugs minor always 2022-11-09 22:23 2022-11-10 18:19
Reporter: Attila S. Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: h-he Satin plugin’s dropdown menus stopped working
Description: The dropdown menus stopped working.
For example try setting the Compander's Encoder or Decoder.
Beforehand clicking on the downwards arrow a menu showed up.

Works in Mixbus 8.1 and Reaper.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026876)
Attila S.   
2022-11-09 22:25   
"h-he Satin" correctly is "u-he Satin"
(0026877)
Attila S.   
2022-11-10 18:19   
This problem seems to be restricted to the official builds and/or to the current OpenSUSE Tumbleweed distribution.
Because Satin works correctly with Ardour v7.1 build provided by the Geekos DAW Tumbleweed repo.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9086 [ardour] bugs minor always 2022-11-08 20:56 2022-11-08 20:56
Reporter: Jxs Platform: Linux  
Assigned To: OS: Mageia  
Priority: normal OS Version: 8  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: no screen refresh after tempo change by ctrl-dragging
Description: as in the title

ps: the documentation mentions "constraint modifier" which is shift by default. This appears to set the tempo left of the marker. But the documentation doesn't seem to mention ctrl-dragging
Tags:
Steps To Reproduce: 1. create a new tempo
2. ctrl drag the tempo. A text appears with the value of the new tempo
3. release the mouse button. Screen is not refreshed
4. zooming, shift dragging or right click + edit + ok updates the screen
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9085 [ardour] bugs major always 2022-11-08 20:23 2022-11-08 20:23
Reporter: Jxs Platform: Linux  
Assigned To: OS: Mageia  
Priority: normal OS Version: 8  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Edit tempo with a BBT creates a second tempo
Description: As in the title
Tags:
Steps To Reproduce: 1. create a new tempo at bar 6
2. create a new BBT with Bars:Beates 1:1 at bar 8
3. right click + edit the tempo at bar 6. Immediately click apply (no properties need to change)
4. in addition to our tempo, we have now a second tempo at bar 6 inside the BBT
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9052 [ardour] translation trivial always 2022-10-30 19:10 2022-11-08 17:06
Reporter: ufocia Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Misspelled name of patch/instrument
Description: Accordion misspelled as "Accordian" in the Patch Selector for standard MIDI patches Channel 1, Patch Bank 0
Tags:
Steps To Reproduce: Open Patch Selector for Channel 1, Patch Bank 0
Additional Information:
Attached Files:
Notes
(0026770)
x42   
2022-10-30 19:20   
This is odd, It was fixed about a year ago (for Ardour 6.9):
https://github.com/Ardour/ardour/commit/dd0c543943e5526fe9a161fd5dbf15f734363240

Are you using a synth plugin that provides those names? General MIDI synth? or ACE Fluidsynth with a .sf2 that provides those names?
(0026845)
x42   
2022-11-02 19:06   
Fixed in general-midi synth plugin.
(0026869)
trombet   
2022-11-08 17:06   
Good afternoon, the validation of the correction is carried out in version 7.0 for windows desktop.Thank you so much

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9079 [ardour] bugs minor always 2022-11-07 21:55 2022-11-07 21:55
Reporter: Jxs Platform: Linux  
Assigned To: OS: Mageia  
Priority: normal OS Version: 8  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Erratic behaviour of time signature markers + crash
Description: 1. jumpy, erratic behaviour when left dragging time signatures
2. with a BBT the real crazyness begins
3. a crash can also be seen when manipulating both time signature and BBT
Tags:
Steps To Reproduce: 1. create a new time signature marker
2. left drag it to the right and watch it jump immediately to the next bar
3. continue dragging, this time to the left. It will jump immediately to the previous bar

Looks like moving to a next or previous bar is coupled to the mouse direction. This behaviour makes it very difficult to manipulate. Note that dragging the tempo marker has more stable behaviour.


With a BBT:

1. create new time signature marker, at bar 4 for example
2. create new BBT marker with bars:beats 1:1, just after bar 8
3. left drag the time signature marker to the right of the BBT marker
4. watch it jump to BBT+8
5. draggin the time signature is now confined within the BBT marker (unless steps 8-10 are executed)
6. drag the time signature back to the left of the BBT marker
7. watch it jump again to BBT+8

8. move it back to the right of the BBT marker, more specifically to bar 2 within the BBT marker
9. move it a tiny amount to the left and watch the Bars:Beats ruler reset itself as if there was no BBT at all. The time signature is at bar 9
10. move it further to the left and observe that it has indeed left the BBT. The Bars:Beats ruler again shows the BBT marks
11. note that this effect cannot be obtained by dragging the time signature marker in one go from right to left. In that case the time signature marker will stay inside the BBT and jump wildly each time you cross the BBT marker

A crash can also be observed:

1. create new BBT marker with bars:beats 1:1, at bar 8 for example
2. create new time signature marker to the left of the BBT
3. watch it jump immediately to the right of the BBT ! That's already weird.
4. left drag the BBT marker to the right of the time signature marker
5. watch how a bunch of vertical guide lines disappear to the left of the BBT marker
6. scroll mouse wheel up
7. crash...
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9077 [ardour] bugs minor always 2022-11-07 12:02 2022-11-07 13:27
Reporter: supernovajm Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Gain envelope being duplicated on delete/split
Description: If you delete or split a region, the gain envelope from the original region gets replicated on both halves of the split track.
Tags:
Steps To Reproduce: add a track
manipulate the gain envelope
split or delete the track at a point after the envelope, the gain envelope settings will be duplicated on both halves of the split track.

video example: https://www.youtube.com/watch?v=CL0y4k75AuM
Additional Information:
System Description
Attached Files:
Notes
(0026865)
x42   
2022-11-07 13:27   
Fixed in 7.1-1-g7b86ef8eff

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8976 [ardour] translation trivial always 2022-10-04 16:52 2022-11-07 13:08
Reporter: ufocia Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 6.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Misspelled name of patch/instrument
Description: Accordion misspelled as "Accordian" in the Patch Selector for standard MIDI patches Channel 1, Patch Bank 0
Tags:
Steps To Reproduce: Open Patch Selector for Channel 1, Patch Bank 0
Additional Information:
System Description
Attached Files: image.png (69,891 bytes) 2022-10-04 16:52
https://tracker.ardour.org/file_download.php?file_id=4220&type=bug
png

image-2.png (68,494 bytes) 2022-10-04 18:04
https://tracker.ardour.org/file_download.php?file_id=4221&type=bug
png
Notes
(0026601)
ufocia   
2022-10-04 18:04   
Similar mistake in Patch Bank 8 for Italian Accordion misspelled as "Italian Accordian".
(0026844)
x42   
2022-11-02 19:06   
OK this seems to have been a bug in general MIDI synth (or rather the general user soundfont https://github.com/x42/gmsynth.lv2/tree/master/sf2).
Fixed now.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9076 [ardour] bugs minor always 2022-11-06 21:59 2022-11-07 05:18
Reporter: cooltehno_bugs Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bug: snap issue - a summary gap between copied midi regions
Description: While the copying snapped to time line MIDI regions - there's some accumulated error in the length of copies. For example, if we copy x50 times the region 4bars length - this make a gap 612 samples long between the end boundary of the last (50-th) region & grid.
Tags:
Steps To Reproduce: 1. Create a new MIDI track
2. Draw 4 bars length MIDI region in Snap state activated.
3. Duplicate the created region 50 times through the Alt+D command.
4. Zoom to the end boundary of the last 50-th region - you'll see the GAP the end boundary of the last 50-th region and grid.
5. Draw the new region between the end boundary of the 50-th region and the grid - this must be 612 samples long - which must not be.
Additional Information:
Attached Files: midi_copy_accumulated_error_gap.gif (600,665 bytes) 2022-11-06 22:03
https://tracker.ardour.org/file_download.php?file_id=4278&type=bug
midi_copy_accumulated_error_gap-2.gif (636,166 bytes) 2022-11-07 05:18
https://tracker.ardour.org/file_download.php?file_id=4279&type=bug
Notes
(0026860)
cooltehno_bugs   
2022-11-06 22:03   
(0026861)
cooltehno_bugs   
2022-11-07 05:18   
better quality gif

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9069 [ardour] bugs minor always 2022-11-04 21:42 2022-11-06 19:28
Reporter: CraigPid Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot select inputs in the connection matrix after opening a video and extracting the audio
Description: After opening a video and choosing to extract audio only, when another audio track is added I cannot select any inputs in the connection matrix.
The workaround is to save and close Ardour. After restarting Ardour and opening the project I am able to select inputs. I have reproduced this in
an up to date version of Mint with the 6.9 bundle from ardour.org and also in Arch with the 7.1 version from the Arch repo. Both systems are using pipewire.
When attempting to select an input, a green dot appears when hovering but when clicked, does not make the connection.
Tags:
Steps To Reproduce: 1. Create new project
2. Open video and extract audio to a new track
3. Create new audio track
4. Open the grid and attempt to select an input
Additional Information: Both systems are running pipewire-jack at 44.1 khz.
The video I imported was 48k and resampled by Ardour when importing.
System Description
Attached Files:
Notes
(0026853)
CraigPid   
2022-11-05 15:55   
Seems that it's not dependent on importing audio from a video but just importing audio in general. Or maybe random. I've noticed that when I click the square on the input, the green dot does not appear but I actually am getting input from the mic, even though it says it's not armed. There doesn't seem to be a way of disconnecting it though.
(0026855)
kiilerix   
2022-11-05 22:29   
Can you reproduce if using the ALSA or PulseAudio backend?
(0026856)
CraigPid   
2022-11-05 23:24   
When Ardour starts I don't have an option of choosing a backend. Do I need to disable Jack?
(0026857)
kiilerix   
2022-11-06 01:13   
You can always open the backend dialog in Window -> Audio/MIDI Setup. "Close" the old backend and "start" the new one. (The ALSA backend should connect directly to the device after telling PipeWire to back off.)

(My hypothesis is that this could be a JACK/PipeWire issue that I also have seen, apparently related to timing issues between creating JACK "channels" in PipeWire and being able to use them for signal routing.)
(0026859)
CraigPid   
2022-11-06 19:28   
I tried it with the Alsa backend and was not able to reproduce.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9073 [ardour] features feature have not tried 2022-11-06 07:50 2022-11-06 07:50
Reporter: ksawerytreningowski Platform:  
Assigned To: OS:  
Priority: immediate OS Version:  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mute midi notes
Description: Mute selected notes in Editor.
Absolutely essential function absolutely necessary
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9066 [ardour] bugs minor always 2022-11-03 15:50 2022-11-05 22:31
Reporter: paul Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: bbt ruler is incorrect when using non-quarter note time signatures
Description: as in summary
Tags:
Steps To Reproduce: use 11/8 time

lines/points appear to be quarter notes, which seems wrong.
Additional Information:
Attached Files: badtime.png (20,821 bytes) 2022-11-03 15:50
https://tracker.ardour.org/file_download.php?file_id=4275&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9068 [ardour] bugs minor always 2022-11-04 18:14 2022-11-05 22:29
Reporter: prokoudine Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Range markers not rendered properly when CD mode is toggled
Description: Range markers are not rendered properly when CD mode is toggled in the Ranges & Marks list.
Tags:
Steps To Reproduce: 1. Create a custom pair of range markers
2. Tick its "CD" checkbox in the Ranges & Marks list
3. The markers disappear from the "Range Markers" ruler, but do not appear on the CD Markers ruler until the canvas/timeline is somehow updated, e.g. by scrolling it left/right or hovering the mouse over the ruler
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9006 [ardour] bugs minor always 2022-10-18 19:01 2022-11-05 19:48
Reporter: Attila S. Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Plugin analysis goes astray
Description: I observed that the “Edit with generic controls” window’s “Plugin analysis” goes astray with the ACMT ACM-2SA and ACM-5SA vst3 plugins, if I set values on the standard plugin UI and then I open the plugin with “Edit with generic controls” and here I open the plugin analysis. It will not show the changes that I made.

BUT if I’m using from start only the generic controls then the analysis seems to work correctly.

I also contacted the plugin’s developer and he said the problem is not on the plugins side.

I attached a screenshot.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: plugin-analysis-acm-2sa.png (226,325 bytes) 2022-10-18 19:01
https://tracker.ardour.org/file_download.php?file_id=4232&type=bug
png
Notes
(0026851)
x42   
2022-11-04 17:03   
Fixed in 7.1-18-g0aad0ae464
(0026854)
Attila S.   
2022-11-05 19:48   
Thank You!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9062 [ardour] bugs minor always 2022-11-01 17:58 2022-11-02 18:37
Reporter: sollapse Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 11  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Motorized fade setting not saved with session.
Description: I've noticed that I have to re-enable the Motorized option on opening a session. This causes assignment to be lost for automation controllers.
Tags:
Steps To Reproduce: Open a session, add a Generic MIDI controller and select Motorized. Assign parameters with any MIDI control. Save the session then reopen. Motorized will be disabled.
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0026815)
sollapse   
2022-11-01 18:00   
*Meant to say motorized option instead of fade.
(0026837)
x42   
2022-11-02 16:22   
Are you perhaps using an AKAI_MPKmini preset (or a custom preset that explicitly sets motorized = false?
(0026840)
x42   
2022-11-02 16:48   
Fixed in Ardour 7.0-200-g6813884857
(0026843)
sollapse   
2022-11-02 18:37   
It's a custom MPK225 mapping file. I now see there is a setting for motorized under bank in the MPKmini map.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9065 [ardour] features minor have not tried 2022-11-02 09:00 2022-11-02 16:40
Reporter: cooltehno_bugs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Proposal: to add 'write' and 'touch' functions to CC MIDI
Description: It could be so comfortable to modify CC while playback MIDI regions using 'write' and 'touch' functions to CC MIDI - analogically to plugin of fader automation.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026835)
paul   
2022-11-02 13:57   
There's a reason we don't do this. Right now I can remember what it is. It might be a bad reason.
(0026838)
cooltehno_bugs   
2022-11-02 16:40   
Thanks for response, Paul! It's absolutely not a critical feature! Good luck in current stage polishing! :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7186 [ardour] bugs major random 2016-12-25 21:49 2022-11-02 09:44
Reporter: unfa Platform: PC/ Linux  
Assigned To: OS: Linux Mint  
Priority: normal OS Version: 18 KDE5 64-bit  
Status: feedback Product Version: 5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ZynAddSubFX patches are not saved
Description: After saving and reloading my session, all of my ZynAddSubFX patches are replaced with default sine-wave patch.

I tried this with two Ardour 5.x versions. Looks like it affects only ceritan sessions.

I have made 2 sessions with the same ZynAddSubFX LV2 plugin - one seems to never load (or even save) the Zyn patches - the other loads them fine.

I loaded my flawed session to realize my sounds are gone, I remade some of them, saved the session, reloaded and they are gone again.

I tried loading that session with many different Arodur 5 versions - none loaded the Zyn patches. Looks like patches the haven't been saved in the project.
Tags:
Steps To Reproduce:
Additional Information: I'm attaching my session.
Attached Files: What is JACK 2.ardour (478,334 bytes) 2016-12-25 21:49
https://tracker.ardour.org/file_download.php?file_id=3151&type=bug
What is JACK.tar.bz2 (350,443 bytes) 2016-12-26 18:27
https://tracker.ardour.org/file_download.php?file_id=3152&type=bug
Notes
(0019217)
x42   
2016-12-25 23:43   
LV2 preset save/load is between the plugin and liblilv. Ardour takes no part in presets. LV2 presets are usually saved to ~/.lv2/ and available to all lv2 hosts. Can you try with jalv?

Are you using Ardour binaries from ardour.org (with liblilv-0.22.1). If not, which version of liblilv did you compile and run Ardour with?

LV2 *state* (current settings) are saved with the session, in SESSION-DIR/plugins/ID/ and not part of the session file.

You also seem to be using an old version of zyn in what looks Carla as wrapper (the plugin URI is the session file is http://kxstudio.sf.net/carla/plugins/zynaddsubfx). Can you try with zyn-fusion (proper LV2 plugin, not a wrapped carla instance) http://zynaddsubfx.sourceforge.net ?
(0019218)
unfa   
2016-12-26 18:35   
I'm using only Ardour binaries form ardour.org - usually nightlies to check for new bugfixes.

I mean plugin states, not presets.

I have attached a bz2'ed copy of the whole session directory without the audio files in interchange (because they are big).

In a subfolder "Zyn patches" I have manually saved XMZ files from the ZynAddSubFX instruments to have a backup in case Ardour won't recall the plugin states.

I the "plugins" subfolder I saw there are some plugin states saved but I have no idea if they contain what I manually saved in "Zyn patches" - even if so, Ardour doesn't load this data.

Could you please take a look?
(0019221)
x42   
2016-12-28 00:04   
What is the absolute path to the session on your disk? Is the file-system using UTF-8 charset (default on gnu/linux for fs) or some non-standard codepage?

The state-manifest files have some very strange reference:

   rdfs:seeAlso <#07/What\u0020is\u0020JACK/plugins/1097/state8/state.ttl>

that should be just

   rdfs:seeAlso <state.ttl>

It looks like lilv/serd fail to detect the the common ancestor of the state directory, but I haven't found a way to reproduce this nor find an obvious code-bug that results in this, yet.
(0019222)
x42   
2016-12-28 01:12   
PS. can you also include the output of `locale` on your system?
(0019224)
unfa   
2016-12-28 14:22   
IIRC the absolute path for the session is:

"/unfa/Projects/YouTube/Vlog/Episodes/UV#07/What is JACK/What is JACK 2.ardour"

Maybe the "#" character in the path is problematic?

The "/unfa" dir is mounted using fstab from a separate partition than the system one.
I'll provide more details later.
(0019227)
x42   
2016-12-28 15:36   
Yep, the hash (#) is the issue.
(0019231)
x42   
2016-12-28 23:39   
forwarded upstream: http://dev.drobilla.net/ticket/1150
(0019234)
unfa   
2016-12-29 17:39   
(Last edited: 2017-01-01 18:51)
Here's the requested detail about my system:

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_UM.UTF-8
LANGUAGE=
LC_CTYPE="en_UM.UTF-8"
LC_NUMERIC=pl_PL.UTF-8
LC_TIME="en_UM.UTF-8"
LC_COLLATE="en_UM.UTF-8"
LC_MONETARY=pl_PL.UTF-8
LC_MESSAGES="en_UM.UTF-8"
LC_PAPER=pl_PL.UTF-8
LC_NAME=pl_PL.UTF-8
LC_ADDRESS=pl_PL.UTF-8
LC_TELEPHONE=pl_PL.UTF-8
LC_MEASUREMENT=pl_PL.UTF-8
LC_IDENTIFICATION=pl_PL.UTF-8
LC_ALL=


The filesystem is an EXT4 - I have no idea how to check if it's using UTF-8. I didn't mess with it so I guess it is.

x42: thank you for proposing a fix!

PS:

I tried changing the absolute path to remove the "#" charactetr, but the plugins states are not loaded correctly. Is there anything I can do to fix the session?

(0019260)
x42   
2017-01-03 19:51   
Since the problem happens during "save", it's too late.

You can however manually edit the files in plugin/NNN/stateMMM/manifest.ttl and change the "rdfs:seeAlso <...>" to "rdfs:seeAlso <state.ttl>"
and remove the invalid \u0020 in both .ttl files


something like (make a backup first)

----- BASH -----
for file in plugins/*/*/manifest.ttl; do
  sed -i'' 's/rdfs:seeAlso.*$/rdfs:seeAlso<state.ttl> ./' $file
done
for file in plugins/*/*/*.ttl; do
sed -i'' 's/\\u0020//g' $file
done
----------------

I can't test this with your session, the only plugin from your session that I also have installed is "Autotune".
(0019265)
unfa   
2017-01-04 09:56   
(Last edited: 2017-01-04 18:57)
Thank you, I'll try fixing the session - good that I saved an external backup of the patches in XMZ files.

EDIT: The bash script didn't fix my session, but after reloading the backed-up ZynAddSubFX patches into the tracks and saving the session in a new location ("Save as...") I was able to get it running well again.

I wonder if there are any more special characters that can break ZynAddSubFX when put in the session's path.

(0019292)
x42   
2017-01-21 02:39   
Can you confirm that the issue is no longer present when using a recent nightly build (or update liblilv to v0.24.2)?

Old sessions still won't restore the (wrongly saved) preset, but when saving a new session that issue should no longer be present.
(0021216)
x42   
2020-04-06 18:48   
Is this still an issue with Ardour 6.0-pre1?
(0026827)
willbradley   
2022-11-02 09:44   
I still experience this issue under Ardour 6.9/Ubuntu 22.04/latest Zyn, but I've found a reliable workaround and I'm describing it here in case it may help with troubleshooting.

What works, I have no idea why, is to disable (just switch off, not remove) every affected instance of Zyn before you save the project and switch them back on after reload. And then, at least for me, the patches are still there.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9064 [ardour] bugs minor always 2022-11-01 19:56 2022-11-01 19:56
Reporter: lootre Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Jump to next/previous mark stuck between 2 marks
Description: When using the keyboard shortcuts W or Q to jump to the next or previous location mark and if there are more than 2 location mark, the playhead only jumps between the 2 same marks, it doesn't go to the next or the previous.

Example: In a session with 4 location marks, I set the playhead between mark 2 and 3. Using the keyboard shortcuts (Q/W) I can only jump to mark 2 or 3, but not to 1 (as a previous of 2) or to 4 (as the next of 3).

In a session with several location marks, the behavior is not consistent with this example. Sometimes it's only possible to jump to previous, sometimes only to next.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8313 [ardour] features minor N/A 2020-07-15 17:41 2022-11-01 13:23
Reporter: Oliver Platform: x86_64  
Assigned To: x42 OS: Xubuntu  
Priority: normal OS Version: 18.04LTS  
Status: resolved Product Version: 6.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Preference window needs scrollbars
Description: On my 1024x768 screen, I need to detach the preferences to see all of the editor and mixer when in
full screen mode (Maximise Editor Space).

The detached preference window is still too large and I need to move the window around to see all entries,
sometimes awkwardly so if the interesting part is on the bottom (selecting first 'Move' from the window
manager menu, then place it with the mouse). There is no way to resize the preference window.

The usual remedy for this, I believe, are scrollbars.
Tags:
Steps To Reproduce:
Additional Information:
System Description Pentium Dual-Core E5200 (2.50GHz)
Attached Files: Ardour Mixer maximised attached.png (77,668 bytes) 2020-11-08 09:08
https://tracker.ardour.org/file_download.php?file_id=3862&type=bug
png

Ardour Mixer maximised detached.png (57,519 bytes) 2020-11-08 09:08
https://tracker.ardour.org/file_download.php?file_id=3863&type=bug
png
Notes
(0025177)
Oliver   
2020-10-28 09:59   
Another window that is too large on my screen is the 'Edit Export Format Profile' window.

Couldn't all secondary windows have scrollbars if exceeding the screen size?
(0025187)
x42   
2020-11-01 21:48   
Try Preferences > Appearance > GUI and font scaling and make Ardour smaller. Scaling is relative to the default desktop font-size and a scaling of 0000088:0000085% - 90% is usually required for small screens <= 1024x768.

Full widow scrollbars are tricky to add in a way that does not otherwise interfere with native min. window sizes, and it's hard to justify spending time on this in 2020 where most screens are 4k or 8k.
(0025188)
Oliver   
2020-11-01 22:00   
I do use GUI scaling already, indeed in the suggested range, as otherwise the main window overflows. Some secondary windows are still way larger than my screen.

I was hoping (apparently in vain) that it would just be a few lines of code to add scrollbars (also hiding automatically when not need), as in other GUI tool kits (e.g. Qt).

I agree that this screen size is less common, on the other hand it was always a strength of Linux versus windows to not make working hardware obsolete so quickly. It is possible to work around this with window manager functions, but it is awkward.
(0025189)
x42   
2020-11-01 22:19   
Same problem with QT. It would enable resizing regardless of screen-size.
(0025190)
x42   
2020-11-01 22:35   
Which dialogs are affected?

The export-profile dialog could be fixed with some re-layout. make it wider less tall.
(0025191)
Oliver   
2020-11-01 23:00   
Quickly scanning through the available windows:

'Preferences' - too wide after selecting the 'Transport' category
'Edit Export Format Profile' - too high
'Transport Masters' - too wide

The Preferences initially fit on the screen (after program start), but by selecting the 'Transport' category they expand horizontally. Then, even if selecting another category, they do not revert to the previous width anymore.
(0025209)
al f   
2020-11-08 09:08   
I have the same or a very similar problem on Ardour (version 5.12 up to 6.3) on (X)Ubuntu Studio 18.04. Toshiba laptop with 1366x768 screen resolution.

GUI scaling is not really an option for me as I would struggle to read the text if smaller than default.

Opening Ardour first time, the main window is too high. Selecting 'Maximise Editor Space' fixes this, deselecting reverts. The titlebar button to maximise does nothing.

Most of the windows accessible from the Window menu fit on the screen, but not these:

'Preferences' - too high (from first opening, can't resize it - the arrow changes to a moving hand as soon as I click it)
'Edit Export Format Profile' - too high (can't see nor reach the buttons cancel / save).
'Mixer' - if detached OK, if attached the main frame OK but some of the contents a little too big. See screenshots
(0025238)
x42   
2020-11-18 18:39   
The Export Profile Dialog layout was updated, and it should now fit on smaller screens.
(0025262)
Oliver   
2020-11-24 10:07   
Thanks, this dialog is good now with ardour 6.5. Would be nice if also Preferences/Transport and Transport Masters could be updated if scrollbars are out of the question.
(0025263)
x42   
2020-11-24 13:39   
Yes, that's the idea.
The Transport master window will be next, since that's also used in preferences.
(0025287)
al f   
2020-12-04 10:55   
Ardour 6.5 fixed these, thank you very much!

- Size of main window now good, regardless of 'Maximise Editor Space' being selected or not. The titlebar buttons now works as expected.
- 'Edit Export Format Profile' - good size, accesible controls.

These issues remain (minor, as they do not lose access to any controls):

- 'Mixer' - if detached OK, if attached the main frame OK but some of the contents a little too big.
- Preferences dialog still overflowing (but all options accessible)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9039 [ardour] bugs crash always 2022-10-26 14:39 2022-11-01 09:30
Reporter: al f Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: immediate OS Version: 10  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Looping audio causes Ardour 7 to crash
Description: Tested with Ardour 7.0.0 and Ardour 7.0.105 (rev 7.0-105-g6904a86576)

Creating a loop and starting it with the shortcut L, the loop plays once and then stalls with a high pitched noise. Subsequently Ardour hangs or crashes with lots of xruns reported by QJackctl. Right-clicking on a region and chosing "Loop region" = same result.
Tags: crash, Editor, loop, range marker
Steps To Reproduce: Create and start a loop.
Additional Information: Manjaro KDE, PulseAudio and Jack2. Everything up to date except glib2 which is temporarily held at 2.74.0-2 because the newer versions causes Timeshift crashing.
System Description
Attached Files: Ardour.log (47,038 bytes) 2022-10-26 14:39
https://tracker.ardour.org/file_download.php?file_id=4254&type=bug
Notes
(0026702)
al f   
2022-10-26 17:06   
There's an error in my report, the crash does NOT happen with Ardour 7.0.0 but only with Ardour 7.0.105.

Also, I'm on Manjaro KDE, don't know how I messed it up to look like I'm on Windows. Apologies!
(0026704)
paul   
2022-10-26 19:05   
fixed in git master 489c9ace9f87b5

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9060 [ardour] bugs minor always 2022-11-01 08:15 2022-11-01 08:15
Reporter: krischan941 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make "Open Clip library button" stay visible
Description: Like in this thread:
https://discourse.ardour.org/t/location-of-installed-samplepacks/107744/3

In the clip list editor, wehn you have some sample packs installed via Library Downloader and you click an arrow to expand a libraries content, the "Open Clip library button" vanishes, which is confusing.
When double click to enter the libraries content an then double click on the two dotts (..) to access root directory again, the button remains. Would be good if it also remains when using arrows to navigate samples/samplepacks.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9059 [ardour] bugs tweak always 2022-11-01 08:04 2022-11-01 08:04
Reporter: surfinspots Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Painting "long" notes when MIDI record is paused and started while playing
Description: If the recording of a MIDI track is paused and restarted the played notes are rendered very long while the notes are actually played short.
Tags:
Steps To Reproduce: I added a screencast.
1. record a midi track
2. turn off the recording for the track while recording
3. end the note you are playing
4. turn recording on again
5. play the note again
Additional Information:
System Description
Attached Files: ardour-screen-paint-error-2022-11-01_09.03.10.mp4 (916,232 bytes) 2022-11-01 08:04
https://tracker.ardour.org/file_download.php?file_id=4270&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9017 [ardour] bugs major always 2022-10-20 19:12 2022-10-31 23:08
Reporter: paul Platform:  
Assigned To: paul OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: when zoomed out, bars/beats ruler is insanely crowded
Description: what the summary says and the screenshot shows
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: bnb.png (22,586 bytes) 2022-10-20 19:12
https://tracker.ardour.org/file_download.php?file_id=4236&type=bug
png
Notes
(0026796)
paul   
2022-10-31 23:08   
fixed via several commits ending with 6d1e4207de524

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7605 [ardour] features minor always 2018-04-23 18:41 2022-10-31 20:27
Reporter: cooltehno_bugs Platform: Linux  
Assigned To: OS: KX Studio  
Priority: normal OS Version: 14.04  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 5.12 & 6.0 focusing issue when to select the header of midi/audio track during many automation tracks are opened
Description: If to open few automation tracks and make them vertically sized out of ardour's window, and than to select (click left mouse button) the header of this track - the view focuses (jumps) to the center of all (the track itself + all the automation tracks) tracks vertically. Such jumping is a bit annoying during editing automations in complex sessions.
Tags:
Steps To Reproduce: 1. Open few automation tracks in any midi/audio track.
2. Make the size of the automation tracks such wide vertically, so they can't fit to the ardour's window.
3. Select the track header.(it provokes focusing to center of all the opened automation tracks)
Additional Information: Some help video is uploaded
Attached Files: vertical_focusing_issure.mkv (1,953,706 bytes) 2018-04-23 18:41
https://tracker.ardour.org/file_download.php?file_id=3381&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9053 [ardour] bugs minor always 2022-10-30 19:16 2022-10-31 19:22
Reporter: ufocia Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: normal OS Version: 10  
Status: assigned Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Play from playhead" button remains active and does not switch to "Stop playback" upon "Go to start of session"
Description: The transport stops automatically on "Go to start of session", but the "Play from playhead" button remains active and does not switch to "Stop playback". Subsequent clicking on "Stop playback" button does not reset the "Play from playhead" button state.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026769)
ufocia   
2022-10-30 19:17   
Probably related to bug 0008521 fix in the 6.x versions.
(0026773)
paul   
2022-10-31 05:42   
What is the "play from playhead" button?
(0026789)
ufocia   
2022-10-31 19:04   
This doc page explains what "play from playhead is : https://manual.ardour.org/ardours-interface/the-transport-bar/

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8930 [ardour] features minor always 2022-06-19 15:18 2022-10-31 18:37
Reporter: Alkukoira Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: In Blueberry Milk "color theme" the grid is off kilter (+ color tuning)
Description: In Blueberry Milk (which I love)-- thanks for the light layout-- the grid emphasizes off beats (in basic quarter note division). The grid lines for 1.5, 2.5, 3.5 are thicker than, say, 1.2.0, 1.3.0, 1.4.0.

It's a very feminine approach to emphasize the off-beats (reggae springs to mind), and as a custom setup such a grid division can be usable, however, is it intentional (or intuitive (to Ardour's largely male user-base)?

Also, using, say ACE Delay in Blueberry Milk, the sync button (among others) gets swallowed up in the color setup, so finetuning the color themes with this mind, and also the purity of colours, would be a great advance for Ardour and its users.

Thanks, and namaste.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026767)
cooltehno_bugs   
2022-10-30 18:54   
Hi, @Alkukoira!
I've made a PR with your remarks here (if Paul or Robin will implement my changes - your request will be satisfied):
https://github.com/Ardour/ardour/pull/747

Big thanks for your advises!! Really good! :)
(0026774)
paul   
2022-10-31 05:44   
PR was merged.
(0026785)
cooltehno_bugs   
2022-10-31 18:33   
Thanks again, Paul! As the nightly test is perfect - I suppose this feature could be marked resolved (I can't change status of this feature request by myself, sorry).
(0026786)
paul   
2022-10-31 18:37   
see notes

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9055 [ardour] bugs minor always 2022-10-30 19:38 2022-10-31 18:27
Reporter: cooltehno_bugs Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bug: Alt+D with several selected MIDI regions - makes copies superimposed to one position
Description: When in "G-mode" we select two or more MIDI regions and use Alt+D function to copy - this makes all copied regions well - but puts them to one start position (all copied regions are placed in one time position like layers).
Tags:
Steps To Reproduce: 1. Make two or more MIDI regions in one track an put them touched to each other.
2. Select these regions by the rectangle selection with the mouse.
3. Press Alt+D combination - this action makes copies of the selected regions superimposed to each other (puts them at the and of the selection).
Additional Information:
System Description
Attached Files: Alt_D_copying_regions_bug.gif (650,813 bytes) 2022-10-30 19:38
https://tracker.ardour.org/file_download.php?file_id=4263&type=bug
Notes
(0026772)
paul   
2022-10-31 05:41   
fixed in git master 21e8885e00261
(0026784)
cooltehno_bugs   
2022-10-31 18:27   
Paul - great thanks! Tested in nightly 7.0.158!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9005 [ardour] bugs minor always 2022-10-18 16:14 2022-10-31 12:35
Reporter: lfont Platform: PC  
Assigned To: x42 OS: Fedora Linux  
Priority: normal OS Version: 36  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Session > Import > Search Freesound does not work because of an SSL CA cert error
Description: Hello,

On Ardour 7.0.0 (rev 7.0) official build, it is currently not possible to use the "Search Freesound" feature (at least on Fedora Linux 36).

The Ardour log window contains this error:
2022-10-18T17:48:25 [ERROR]: curl error 77 (Problem with the SSL CA cert (path? access rights?))
2022-10-18T17:48:25 [ERROR]: no root XML node!
Tags:
Steps To Reproduce: Open the import window: "Session > Import"
Go to the third tab "Search Freesound"
Type something in the "Tags" field
Click on the "Search" button

> The Ardour log indicator at the top right will blink in red.
The window will contains the following error:
... [ERROR]: curl error 77 (Problem with the SSL CA cert (path? access rights?))
... [ERROR]: no root XML node!
Additional Information:
System Description
Attached Files:
Notes
(0026641)
x42   
2022-10-18 16:52   
Where does Fedora keep its SSL Certs these days?

is there still /etc/pki/tls/certs/ca-bundle.crt on your system, or is it newer than https://bugzilla.redhat.com/show_bug.cgi?id=1053882 ?
(0026643)
x42   
2022-10-18 17:38   
A potential workaround is now in Ardour 7.0-45-g073d6f5e80
(0026645)
lfont   
2022-10-18 20:19   
/etc/pki/tls/certs/ca-bundle.crt is still there and looking at the README provided by the ca-certificates package (https://src.fedoraproject.org/rpms/ca-certificates/blob/f36/f/README.etcssl) it seems that (/etc/ssl) should be compatible with Debian like distro.

So I'm not sure that this https://github.com/Ardour/ardour/blob/master/gtk2_ardour/ardour_http.cc#L106 is still required.

7.0-45-g073d6f5e80 is not yet available to download, I will test it but I'm not sure about the fix as ca_info should not be empty.
(0026646)
lfont   
2022-10-19 13:13   
I've try to run the latest nightly build (rev 7.0-46-g22829e96b1) and I still get the same error message:
strace output:
stat("/etc/pki/tls/certs/ca-bundle.crt", {st_mode=S_IFREG|0444, st_size=214712, ...}) = 0
openat(AT_FDCWD, "/etc/pki/tls/certs/ca-bundle.crt", O_RDONLY) = 65
stat("/nonexistent_path", 0x7ffd799d8b50) = -1 ENOENT (No such file or directory)

I've build Ardour (rev 7.0) on my system and I was not able to reproduce the issue:
strace output:
openat(AT_FDCWD, "/etc/crypto-policies/back-ends/openssl.config", O_RDONLY) = 62
openat(AT_FDCWD, "/etc/pki/tls/certs/ca-bundle.crt", O_RDONLY) = 62

In the second case there is not attempt to open (/nonexistent_path).
I don't know if this is relevant or not, I can provide more output if needed.
(0026647)
x42   
2022-10-19 14:42   
> So I'm not sure that this https://github.com/Ardour/ardour/blob/master/gtk2_ardour/ardour_http.cc#L106 is still required.

Apparently it is a trap. Red Hat tries to provide a debian compatible but fails at that (see the linked bug report).
I just realized that the check is incorrect. It should check for Glib::FILE_TEST_EXISTS|Glib::FILE_TEST_IS_REGULAR


>I've build Ardour (rev 7.0) on my system and I was not able to reproduce the issue:
The issue is only relevant for binaries from Ardour that bundle libcurl. In this case curl has to be informed where to search for SSL certs.

If you compile Ardour locally and use libcurl from your GNU/Linux distro, your distro has already configured libcurl correctly.
(0026648)
lfont   
2022-10-19 15:16   
> Apparently it is a trap. Red Hat tries to provide a debian compatible but fails at that (see the linked bug report).
Hmm, I don´t know if this has been fixed or not. Some part of the discussion seems to say yes.

> If you compile Ardour locally and use libcurl from your GNU/Linux distro, your distro has already configured libcurl correctly.
Sorry but I'm not familiar will all of this and I don't know how to reproduce exactly the same bundle configuration.

> I just realized that the check is incorrect. It should check for Glib::FILE_TEST_EXISTS|Glib::FILE_TEST_IS_REGULAR
Yes, but the result will be the same. ca_path will end up with the (/nonexistent_path) value which seems to be a problem.
As Glib::file_test ("/etc/pki/tls/certs/ca-bundle.crt", Glib::FILE_TEST_EXISTS|Glib::FILE_TEST_IS_DIR) check is wrong and that (/etc/ssl/certs) exists we should not currently have (/nonexistent_path) in strace. On fedora, (/etc/ssl/certs) is a symlink to (/etc/pki/ca-trust/extracted/pem/directory-hash).
(0026649)
krischan941   
2022-10-19 15:30   
Hi, I don't know whether there is a connection to this but I had a similar problem using the new Download-Library-Manager of Ardour on Linux. It first didn't work and I got some SSL CA cert errors. I closed Ardour and deleted the Ardour config in ~/.config/ and after starting Ardour again it worked. Before official Ardour release, I had a Nihgtly version installed, maybe that config got corrupted or something simlar. Perhaps it helps
(0026651)
lfont   
2022-10-19 20:56   
Thanks for the suggestion, but this is not a configuration problem.
I've run different builds and do not reproduce the issue with all of them.
It seems that the issue is due to the configuration of the bundled libcurl.
(0026661)
paul   
2022-10-21 04:47   
I forgot to mention in the release announcement that if you had used a build of Ardour during the 7.0 development process, you should almost certainly delete or rename your ardour preferences/configuration folder.
(0026671)
kiilerix   
2022-10-21 23:22   
(I am a Fedora developer/packager (but not the owner of the Ardour package). I say that to claim a bit of relevant credibility in this area.)

I can confirm the problem with Ardour binaries as reported.

The problem is however not in /etc/pki/tls/certs/ca-bundle.crt . And Fedora didn't change it in any relevant way.

The problem is /nonexistent_path . The invalid path makes the Ardour curl / openssl choke. Assuming it worked before, the change most be on the Ardour side. Perhaps the version on the build host (which is bundled with the binary builds) got upgraded to something more strict than before?

As a workaround and evidence of the culprit, try creating an empty directory at /nonexistent_path . That makes freesound search work for me.

I don't understand the comment '''don't try "/etc/ssl/certs" in case it's curl's default'''. Even though /etc/ssl/certs doesn't contain hashed certs on Fedora and thus doesn't work as openssl CA path, it still works as well as an empty directory. Evidence: it also works with "ln -s /etc/ssl/certs /nonexistent_path". I thus suggest unconditionally using ca_path = "/etc/ssl/certs".

I also suggest reverting b75be7f97 and 073d6f5e. These changes doesn't seem to go in the right direction. And the introduction of the unsafe default of silently not verifying certificates seems very unfortunate.
(0026672)
kiilerix   
2022-10-22 19:13   
I proposed https://github.com/Ardour/ardour/pull/743 which has some related discussion.
(0026739)
kiilerix   
2022-10-28 23:09   
The PR proposed above has landed.

I verified that Ardour-7.0.141-dbg-x86_64-gcc5.run now works smoothly when searching freesound. Both out of the box, where Fedora now has hashes in /etc/ssl/certs to be compatible with Debian, and it also works if making /etc/ssl/certs an empty directory (as it more or less has been in the past).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9032 [ardour] features minor always 2022-10-24 09:56 2022-10-31 09:56
Reporter: DonJaime Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Remove unused peak and state files
Description: TL;DR:
When regions and plugins are removed, the peak and state files associated with them remain on disk, wasting space.

Full story:
To create a slimmed-down session for a bug report, I removed all of the tracks, regions and sources except one from an ardour session, and all of the plugins. But there were still hundreds of files/folders in the peaks and plugins directories, which were also copied over when I saved as...
The files are mainly not very big, but it all adds up. And there were multiple copies of soundfonts in some state folders (is that a bug?), which add up quite quickly.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026755)
Daniele1971   
2022-10-30 10:45   
Yes please, hundreds of useless files...
(0026766)
Napadator   
2022-10-30 18:19   
What's the problem, search entire drive or location for *.peak files and delete them. Ardor will rebuild the necessary peak files.
(0026779)
Daniele1971   
2022-10-31 09:56   
For me the problems are plugins state file more then peak.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9054 [ardour] features feature N/A 2022-10-30 19:18 2022-10-30 19:18
Reporter: Napadator Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add the detachable Editor List
Description: Due to the fact that the best way to navigate between multiple tracks in an extended session is to use the Editor List, it must be kept open which limits the space of the main Editor. Since I have a multi monitor setup, it would be more convenient to detach the Editor List and put it on another monitor
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9051 [ardour] features minor have not tried 2022-10-30 19:09 2022-10-30 19:11
Reporter: cooltehno_bugs Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Propose: "F1, F2, F3... saved views" - to store in the SESSION file
Description: Propose to store the saved views (Ctrl+F1, F2, F3....) in the session file, to have a possibility to continue the habitual view arrangement after reloading the session.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6145 [ardour] features minor N/A 2015-01-21 22:48 2022-10-30 19:11
Reporter: x42 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Save/restore of visual state is not implemented
Description: Views (visual state) only saves/restore horizontal scroll+zoom.
Tags:
Steps To Reproduce:
Additional Information: some half baked prototype:
https://github.com/Ardour/ardour/commit/0c9d094870b3c9e
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9009 [ardour] bugs major always 2022-10-19 08:37 2022-10-30 19:09
Reporter: thebutant Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: high OS Version: (any)  
Status: assigned Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: After tempo change in the tempo bar, midi regions are offset and behaves unexpectedly.
Description: When changing tempo with the tempo marker during a project, the midi regions recorded after the tempo change behave unexpectedly and are very difficult to work with.
Modwheel automation is offset, editing midi notes is offset and responds rather wildly.
Tags:
Steps To Reproduce: 1/ New project.
2/ Record a midi region with several notes and modwheel automation. This one will work as expected, it's simply there as a reference.
3/ After this region, change tempo in the tempo bar (for instance so that the first part of the project has its default 120 bpm, and the second part has 92 bpm (doesn't matter, but just to make a tempo change).
4/ Record a midi region in this second part, the one with the different tempo. Record the region with several notes and modwheel automation.
5/ You will now see that the modwheel automation for this new midi region is offset, it comes before the notes it relates to. Playback will nevertheless play it correcty, you can see that the modwheel fader to the left (sorry, I'm not sure what it's called) won't correspond with the nodes under the midi region. The modwheel fader to the left acts correctly.
6/ Try to edit several modwheel automation nodes, select by dragging the cursor over. I'm not able to select the ones I wish to select, I only get to select nodes that are placed earlier in the region.
7/ Try to select several midi notes in the region the same way, these are also offset. You'll get to select notes that come earlier in the region, but not the ones you try to select.
8/ Try to select 1 note. You're able to. Try to make it longer or shorter. I will probably be a rather frustating task, as it behaves unexpectedly.
9/ Split the midi region. Drag the two regions apart a little. Mark them with the range tool, right click and "Consolidate." My oh my, what a mess. ):O
Additional Information:
System Description
Attached Files: midi_rec_region_fix.diff (3,414 bytes) 2022-10-24 02:11
https://tracker.ardour.org/file_download.php?file_id=4244&type=bug
Notes
(0026667)
paul   
2022-10-21 16:42   
Thanks for the excellent bug report. Will try to get to this ASAP.
(0026681)
x42   
2022-10-24 02:11   
(Last edited: 2022-10-24 02:16)
(7) and (8) should be fixed since Ardour 7.0-82-g63c78ebced

The rec-region not showing notes while recording is understood, I attach a patch which explains the issue, however the actual fix will need further work.
Ardour::Region needs an API for `source->natural_position().distance (abspos)`.

--

PS. While recording region->source()->natural_position () is using BeatTime - while region->source_position() is using AudioTime - the value of the latter is not valid until after rec-stop
(0026682)
x42   
2022-10-24 02:33   
PPS. step-entry works nicely across tempo-changes, at Region::region_beats_to_region_time() works correctly in that context
(0026738)
paul   
2022-10-28 22:43   
note visibility during capture now fixed in git master. also enhanced with new color for notes during capture.

I believe all items in this report are now fixed, but will wait for confirmation before marking "Resolved"

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9044 [ardour] bugs crash always 2022-10-28 10:36 2022-10-29 17:04
Reporter: gonsolo Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when trying to disconnect from jack.
Description: I start ardbg at commit 7.0-141-gefdc47bc74 and load my session on Ubuntu Kinetic with "pw-jack ./ardbg".
When I try to switch from jack to something else Ardour crashes.
Here is the stack trace:

#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
0000001 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff343bc46 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
0000004 0x00007ffff34227fc in __GI_abort () at ./stdlib/abort.c:79
0000005 0x00007ffff342271b in __assert_fail_base
    (fmt=0x7fffef6039b5 <error: Cannot access memory at address 0x7fffef6039b5>, assertion=0x7fffd7fe1614 <error: Cannot access memory at address 0x7fffd7fe1614>, file=0x7fffd7fe15e8 <error: Cannot access memory at address 0x7fffd7fe15e8>, line=728, function=<optimized out>) at ./assert/assert.c:92
#6 0x00007ffff3433596 in __GI___assert_fail
    (assertion=0x7fffd7fe1614 <error: Cannot access memory at address 0x7fffd7fe1614>, file=0x7fffd7fe15e8 <error: Cannot access memory at address 0x7fffd7fe15e8>, line=728, function=0x7fffd7fe1620 <error: Cannot access memory at address 0x7fffd7fe1620>) at ./assert/assert.c:101
#7 0x00007fffd7fd34fc in boost::shared_ptr<ARDOUR::JackPort>::operator->() const (this=0x7fffffffb3d0) at /usr/include/boost/smart_ptr/shared_ptr.hpp:728
0000008 0x00007fffd7fd0883 in ARDOUR::JACKAudioBackend::get_port_name[abi:cxx11](boost::shared_ptr<ARDOUR::ProtoPort> const&) const (this=0x5555575dd1e0, port=...) at ../libs/backends/jack/jack_portengine.cc:125
0000009 0x00007ffff744b2a4 in ARDOUR::PortManager::get_port_by_name(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
    (this=0x5555575e1d60, portname=<Fehler beim Lesen der Variable: Cannot access memory at address 0x55555ed0b6a8>) at ../libs/ardour/port_manager.cc:507
0000010 0x00007ffff6dd9fc3 in ARDOUR::Bundle::connected_to(boost::shared_ptr<ARDOUR::Bundle>, ARDOUR::AudioEngine&, ARDOUR::DataType, bool)
    (this=0x55555ec15f00, other=<Fehler beim Lesen der Variable: Cannot access memory at address 0x7fffffffb4f0>, engine=..., type=..., exclusive=true) at ../libs/ardour/bundle.cc:483
0000011 0x000055555627a9af in IOButtonBase::set_label(IOButtonBase&, ARDOUR::Session&, boost::shared_ptr<ARDOUR::Bundle>&, boost::shared_ptr<ARDOUR::IO>)
    (self=..., session=..., bndl=..., io=<Fehler beim Lesen der Variable: Cannot access memory at address 0x7fffffffb5b0>) at ../gtk2_ardour/io_button.cc:258
0000012 0x00005555562801b3 in IOButton::update() (this=0x5555775de540) at ../gtk2_ardour/io_button.cc:703
0000013 0x000055555628c369 in boost::_mfi::mf0<void, IOButton>::operator()(IOButton*) const (this=0x7fffb401cf58, p=0x5555775de540) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000014 0x000055555628aa47 in boost::_bi::list1<boost::_bi::value<IOButton*> >::operator()<boost::_mfi::mf0<void, IOButton>, boost::_bi::rrlist2<ARDOUR::IOChange, void*> >(boost::_bi::type<void>, boost::_mfi::mf0<void, IOButton>&, boost::_bi::rrlist2<ARDOUR::IOChange, void*>&, int) (this=0x7fffb401cf68, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
#15 0x0000555556288e85 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, IOButton>, boost::_bi::list1<boost::_bi::value<IOButton*> > >::operator()<ARDOUR::IOChange, void*>(ARDOUR::IOChange&&, void*&&)
    (this=0x7fffb401cf58, a1=..., a2=<Fehler beim Lesen der Variable: Cannot access memory at address 0x7fffffffbdc0>) at /usr/include/boost/bind/bind.hpp:1318
0000016 0x00005555562871a4 in boost::detail::function::void_function_obj_invoker2<boost::_bi::bind_t<void, boost::_mfi::mf0<void, IOButton>, boost::_bi::list1<boost::_bi::value<IOButton*> > >, void, ARDOUR::IOChange, void*>::invoke(boost::detail::function::function_buffer&, ARDOUR::IOChange, void*) (function_obj_ptr=..., a0=..., a1=0x555557bf6830) at /usr/include/boost/function/function_template.hpp:158
#17 0x00005555561e76db in boost::function2<void, ARDOUR::IOChange, void*>::operator()(ARDOUR::IOChange, void*) const (this=0x7fffb401cf50, a0=..., a1=0x555557bf6830)
    at /usr/include/boost/function/function_template.hpp:763
0000018 0x00005555561e678a in boost::_bi::list2<boost::_bi::value<ARDOUR::IOChange>, boost::_bi::value<void*> >::operator()<boost::function<void (ARDOUR::IOChange, void*)>, boost::_bi::list0>(boost::_bi::type<void>, boost::function<void (ARDOUR::IOChange, void*)>&, boost::_bi::list0&, int) (this=0x7fffb401cf70, f=..., a=...) at /usr/include/boost/bind/bind.hpp:319
0000019 0x00005555561e4f86 in boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (ARDOUR::IOChange, void*)>, boost::_bi::list2<boost::_bi::value<ARDOUR::IOChange>, boost::_bi::value<void*> > >::operator()() (this=0x7fffb401cf50) at /usr/include/boost/bind/bind.hpp:1294
0000020 0x00005555561e2d36 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<boost::_bi::unspecified, boost::function<void (ARDOUR::IOChange, void*)>, boost::_bi::list2<boost::_bi::value<ARDOUR::IOChange>, boost::_bi::value<void*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000021 0x0000555555cb32d3 in boost::function0<void>::operator()() const (this=0x7fffb4069570) at /usr/include/boost/function/function_template.hpp:763
0000022 0x00007ffff559bd9d in Gtkmm2ext::UI::do_request(Gtkmm2ext::UIRequest*) (this=0x5555575a5a20, req=0x7fffb4069560) at ../libs/gtkmm2ext/gtk_ui.cc:499
0000023 0x00007ffff55a1561 in AbstractUI<Gtkmm2ext::UIRequest>::handle_ui_requests() (this=0x5555575a5a20) at ../libs/pbd/pbd/abstract_ui.cc:365
#24 0x00007ffff513e2d0 in BaseUI::request_handler(Glib::IOCondition) (this=0x5555575a5a20, ioc=Glib::IO_IN) at ../libs/pbd/base_ui.cc:153
0000025 0x00007ffff5142d0e in sigc::bound_mem_functor1<bool, BaseUI, Glib::IOCondition>::operator()(Glib::IOCondition const&) const
    (this=0x5555575a3f08, _A_a1=<Fehler beim Lesen der Variable: Cannot access memory at address 0x7fffffffc24c>) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:2066
0000026 0x00007ffff514285d in sigc::adaptor_functor<sigc::bound_mem_functor1<bool, BaseUI, Glib::IOCondition> >::operator()<Glib::IOCondition const&>(Glib::IOCondition const&) const
    (this=0x5555575a3f00, _A_arg1=<Fehler beim Lesen der Variable: Cannot access memory at address 0x7fffffffc24c>) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:89
0000027 0x00007ffff51421a9 in sigc::internal::slot_call1<sigc::bound_mem_functor1<bool, BaseUI, Glib::IOCondition>, bool, Glib::IOCondition>::call_it(sigc::internal::slot_rep*, Glib::IOCondition const&)
    (rep=0x5555575a3ed0, a_1=<Fehler beim Lesen der Variable: Cannot access memory at address 0x7fffffffc24c>) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:170
0000028 0x00007ffff5158c20 in sigc::slot1<bool, Glib::IOCondition>::operator()(Glib::IOCondition const&) const
    (this=0x5555575a5ab8, _A_a1=<Fehler beim Lesen der Variable: Cannot access memory at address 0x7fffffffc24c>) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:665
0000029 0x00007ffff51588e8 in cross_thread_channel_call_receive_slot(_GIOChannel*, GIOCondition, void*) (condition=G_IO_IN, data=0x5555575a5aa8) at ../libs/pbd/crossthread.cc:52
0000030 0x00007ffff4dfb3cf in g_main_dispatch (context=<Fehler beim Lesen der Variable: Cannot access memory at address 0x7fffffffc178>) at ../../../glib/gmain.c:3444
0000031 g_main_context_dispatch (context=<Fehler beim Lesen der Variable: Cannot access memory at address 0x7fffffffc178>) at ../../../glib/gmain.c:4162

I'm happy to provide further details.
Tags:
Steps To Reproduce: 1. Get Ubuntu Kinetic
2. Compile ardour
3. Start with "pw-jack ./ardbg"
4. Load session: https://drive.google.com/file/d/1yAc12rxdwuMNrcdr2gV_lpkL0vPSrNcY/view?usp=sharing
5. Try to disconnect from jack: crash.
Additional Information:
System Description
Attached Files: log.xz (122,212 bytes) 2022-10-29 15:29
https://tracker.ardour.org/file_download.php?file_id=4260&type=bug
0001-Fix-crash-when-stop-jack-server-under-pipewire.patch (846 bytes) 2022-10-29 15:55
https://tracker.ardour.org/file_download.php?file_id=4261&type=bug
Notes
(0026733)
kiilerix   
2022-10-28 17:30   
I can confirm that I also periodically have had problems around JACK / pipewire get_port_name.
(0026734)
gonsolo   
2022-10-28 18:06   
If it helps, I can also file a bug at pipewire.
(0026735)
paul   
2022-10-28 19:48   
A more usefl but also more difficult test would be to try a "real" version of JACK
(0026742)
gonsolo   
2022-10-29 10:07   
I filed a bug at pipewire.org: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2796
(0026745)
gonsolo   
2022-10-29 15:29   
Wim Taymans from pipewire suggested to run through valgrind.
This is the tail of the log:

```
Graph::engine_stopped. n_thread: 23
==9936== Thread 1 ArdourGUI:
==9936== Syscall param futex(futex) points to uninitialised byte(s)
==9936== at 0x8FF6C4D: syscall (syscall.S:38)
==9936== by 0x7740023: PBD::Semaphore::signal() (semutils.cc:108)
==9936== by 0x5C7DC55: ARDOUR::Graph::drop_threads() (graph.cc:171)
==9936== by 0x5C7D77F: ARDOUR::Graph::engine_stopped() (graph.cc:101)
==9936== by 0x5C8ABC8: boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (mem_fn_template.hpp:49)
==9936== by 0x5C8A154: void boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (bind.hpp:259)
==9936== by 0x5C890A7: boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (bind.hpp:1294)
==9936== by 0x5C87618: boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_template.hpp:158)
==9936== by 0x8672D2: boost::function0<void>::operator()() const (function_template.hpp:763)
==9936== by 0x866D22: PBD::Signal0<void, PBD::OptionalLastValue<void> >::operator()() (signals_generated.h:340)
==9936== by 0x5A9C66B: ARDOUR::AudioEngine::stop(bool) (audioengine.cc:1147)
==9936== by 0xC847CC: EngineControl::stop_engine(bool) (engine_dialog.cc:517)
==9936== Address 0x118920e4 is 308 bytes inside a block of size 448 alloc'd
==9936== at 0x4845013: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==9936== by 0x62772B9: ARDOUR::Session::immediately_post_engine() (session.cc:569)
==9936== by 0x62732C6: ARDOUR::Session::Session(ARDOUR::AudioEngine&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, ARDOUR::BusProfile const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) (session.cc:372)
==9936== by 0x928CB7: ARDOUR_UI::build_session_stage_two(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, ARDOUR::BusProfile const&, bool) (ardour_ui_session.cc:683)
==9936== by 0x9286C3: ARDOUR_UI::build_session(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, ARDOUR::BusProfile const&, bool, bool) (ardour_ui_session.cc:626)
==9936== by 0x93AEB5: ARDOUR_UI::load_session_from_startup_fsm() (ardour_ui_startup.cc:670)
==9936== by 0x939DD7: ARDOUR_UI::sfsm_response(StartupFSM::Result) (ardour_ui_startup.cc:533)
==9936== by 0x93F47B: sigc::bound_mem_functor1<void, ARDOUR_UI, StartupFSM::Result>::operator()(StartupFSM::Result const&) const (mem_fun.h:2066)
==9936== by 0x93F016: sigc::adaptor_functor<sigc::bound_mem_functor1<void, ARDOUR_UI, StartupFSM::Result> >::deduce_result_type<StartupFSM::Result const&, void, void, void, void, void, void>::type sigc::adaptor_functor<sigc::bound_mem_functor1<void, ARDOUR_UI, StartupFSM::Result> >::operator()<StartupFSM::Result const&>(StartupFSM::Result const&) const (adaptor_trait.h:89)
==9936== by 0x93E770: sigc::internal::slot_call<sigc::bound_mem_functor1<void, ARDOUR_UI, StartupFSM::Result>, void, StartupFSM::Result>::call_it(sigc::internal::slot_rep*, StartupFSM::Result const&) (slot.h:451)
==9936== by 0x15EC896: sigc::internal::signal_emit1<void, StartupFSM::Result, sigc::nil>::emit(sigc::internal::signal_impl*, StartupFSM::Result const&) (signal.h:1045)
==9936== by 0x15EBD56: sigc::signal1<void, StartupFSM::Result, sigc::nil>::emit(StartupFSM::Result const&) const (signal.h:2955)
==9936==
Graph::drop_threads() sema-counts: 0, 0, 1
ardour-7.0.141: /usr/include/boost/smart_ptr/shared_ptr.hpp:728: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = ARDOUR::JackPort; typename boost::detail::sp_member_access<T>::type = ARDOUR::JackPort*]: Zusicherung »px != 0« nicht erfüllt.
==9936==
==9936== Process terminating with default action of signal 6 (SIGABRT)
==9936== at 0x8F7226B: __pthread_kill_implementation (pthread_kill.c:44)
==9936== by 0x8F7226B: __pthread_kill_internal (pthread_kill.c:78)
==9936== by 0x8F7226B: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89)
==9936== by 0x8F1BC45: raise (raise.c:26)
==9936== by 0x8F027FB: abort (abort.c:79)
==9936== by 0x8F0271A: __assert_fail_base.cold (assert.c:92)
==9936== by 0x8F13595: __assert_fail (assert.c:101)
==9936== by 0x150D14FB: boost::shared_ptr<ARDOUR::JackPort>::operator->() const (shared_ptr.hpp:728)
==9936== by 0x150CE882: ARDOUR::JACKAudioBackend::get_port_name[abi:cxx11](boost::shared_ptr<ARDOUR::ProtoPort> const&) const (jack_portengine.cc:125)
==9936== by 0x61912A3: ARDOUR::PortManager::get_port_by_name(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (port_manager.cc:507)
==9936== by 0x5B1FFC2: ARDOUR::Bundle::connected_to(boost::shared_ptr<ARDOUR::Bundle>, ARDOUR::AudioEngine&, ARDOUR::DataType, bool) (bundle.cc:483)
==9936== by 0xE2E9AE: IOButtonBase::set_label(IOButtonBase&, ARDOUR::Session&, boost::shared_ptr<ARDOUR::Bundle>&, boost::shared_ptr<ARDOUR::IO>) (io_button.cc:258)
==9936== by 0xE341B2: IOButton::update() (io_button.cc:703)
==9936== by 0xE31DBE: IOButton::port_connected_or_disconnected(boost::weak_ptr<ARDOUR::Port>, boost::weak_ptr<ARDOUR::Port>) (io_button.cc:487)
```

Can it be that ardour was stopping the engine and then trying to grab a port?
(0026746)
paul   
2022-10-29 15:37   
(Last edited: 2022-10-29 15:38)
I've just pushed 1eaaf4303b which might address this. Let me know.
(0026747)
paul   
2022-10-29 15:48   
BTW, gdb produces more useful backtraces than valgrind, but the valgrind output is still sometimes useful.
(0026748)
gonsolo   
2022-10-29 15:55   
The following patch fixes the issue. I'm not sure who is the guilty one (ardour or pipewire), but I thought I just let you both know.

After applying the fix I can stop and start (pipewire-)jack without any crash.
(0026749)
gonsolo   
2022-10-29 15:59   
I also sent the fix to pipewire: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2796#note_1613565
(0026750)
gonsolo   
2022-10-29 16:01   
Ah, now I've read the message about commit 1eaaf4303b. Trying it out...
(0026751)
gonsolo   
2022-10-29 16:12   
Ok. 1eaaf4303b fixes my issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8328 [ardour] bugs minor always 2020-07-22 20:04 2022-10-29 14:16
Reporter: mc888 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: group shared gain will not disable
Description: Group shared gain is still active when 1) group is deselected, and even when 2) shared gain is specifically deselected in group settings.
Tags: group gain
Steps To Reproduce: creat a group, move a fader
Additional Information:
System Description
Attached Files:
Notes
(0026737)
mc888   
2022-10-28 22:43   
Bug still present in 7.0. Let me give clearer steps to reproduce:

1. Create a group, deselect shared gain.
2. Pull back a fader in the group. Only one fader moves, as expected.
3. Shift-Click to zero that fader. All group faders will move.

The inverse is also true -

1. Select shared gain for the group.
2. Move a fader, all faders move as expected.
3. Shift-Click will only zero the fader for that single track.
(0026744)
paul   
2022-10-29 14:16   
It's a problem of modifier overloading.

Shift-click is used in ardour to "reset to default"

But "shift" is also the "override group setting" modifier.

We've had some discussions in the past about how to deal with this, but they have not gotten very far.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9040 [ardour] bugs minor always 2022-10-27 10:50 2022-10-28 20:35
Reporter: MyLoFy Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Alt + D copies are not on grid
Description: The key shortcut Alt + D produces imprecise placement of copies. Official binaries used for testing.

Tags: 7.0
Steps To Reproduce: Steps to reproduce:
-Create MIDI region
-Switch to grab mode
-Select MIDI region
-Press Alt + D
-Resulting copy is a small amount before the expected grid line and overlapping with the previous region
Repeated use of Alt + D produces accumulated shift of regions
Additional Information: Screencast:
https://mark.nl.tab.digital/s/dMmsLd5XK9NAKbj
System Description
Attached Files:
Notes
(0026736)
paul   
2022-10-28 20:35   
fixed in git master c58d052a8e

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9037 [ardour] bugs crash always 2022-10-25 13:17 2022-10-28 17:34
Reporter: MichaelP Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 7 crashes when saving a converted session the first time
Description: When loading an old session, it get's automatically converted, and a message box informs the user about that.
Changing anything in the session, so it is marked dirty and saving it, crashes Ardour every time.
When starting Ardour with that session again, everything works normal, even the previous changes are there and now saving does not crash Ardour again.
Tags: 7.0, crash, save, session
Steps To Reproduce: Load an Ardour 6.9 session, change something and hit Ctrl+s
Additional Information:
System Description
Attached Files: Ardour-7.0.0-crash-1666702733.txt (10,539 bytes) 2022-10-25 13:17
https://tracker.ardour.org/file_download.php?file_id=4250&type=bug
Ardour-7.0.0-crash-1666702628.txt (10,539 bytes) 2022-10-25 13:17
https://tracker.ardour.org/file_download.php?file_id=4251&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9025 [ardour] bugs minor always 2022-10-22 22:42 2022-10-28 00:43
Reporter: mc888 Platform: Debian GNU  
Assigned To: OS: bullseye/KDE  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mixer Strip width random changes
Description: Ardour 7.0 Mixer strips randomly change width. Changes to width are not saved with session. Changes in Mixer window are not replicated to Editor window.

This occurs on session load AND during session.
Tags: mixer strips
Steps To Reproduce: Use any number of tracks. In Editor window, select any track and change width. Select a different track, then re-select the changed track and the width reverts to previous width.
Additional Information: This is minor, but hugely annoying. It was always present in Ardour 6.x but has grown worse in Ardour 7.0.
System Description
Attached Files: width.webm (931,122 bytes) 2022-10-27 23:22
https://tracker.ardour.org/file_download.php?file_id=4255&type=bug
narrow-MIDI.png (124,776 bytes) 2022-10-27 23:38
https://tracker.ardour.org/file_download.php?file_id=4256&type=bug
png

wide-MIDI.png (133,125 bytes) 2022-10-27 23:38
https://tracker.ardour.org/file_download.php?file_id=4257&type=bug
png
Notes
(0026706)
paul   
2022-10-26 23:05   
Nobody else has ever noticed/reported this behavior.
(0026714)
mc888   
2022-10-27 19:54   
This morning I tested with a clean config (renamed directory) and a new session with Ardour 7.0.0, And was unable to reproduce the problem.

Renamed the ardour7 directory to get the original back (which was copied from 6.9 on first run), and still was not able to reproduce the problem.

Went back to a session I was working on in 6.9 before the 7.0 release. Before loading, I confirmed in the session file it was created in 6.2 and modified in 7.0. Yes, there's a big gap because I've been using Mixbus32C. But the random strip width again greeted me at startup.

It seems the issues I'm running into are always when loading a session from a previous version into 7.0.
(0026722)
mc888   
2022-10-27 22:53   
Ok, I did reproduce some of it it in a limited way. This is in the clean 7.0 session.

First, when changing any strip width in the Editor window, all strips change as if Ctrl-Shift-Click was pressed. Is this by design?

Once that happens, they cannot decouple. So i get doublewide trailer strips on the MIDI tracks, or gobbledygook strips on the audio tracks.

The Mixer seems to have it's own width setting apart from the Editor window. Changing strip width there has no effect on the Editor strips.

Unfortunately, wide Editor width will propagate to MIDI tracks in the Mixer window after an exit and restart. When I save & exit from the Mixer window with narrow MIDI, but wide in Editor, on session reload the Mixer MIDI track becomes wide.
(0026723)
paul   
2022-10-27 23:17   
ctrl-shift-<X> is the general modifier combo in ardour for "do this to everything"

but i am confused " changing any strip width in the editor window" ... there's only one strip in the editor window ... clcking on its width button seems to have no irregular effect. Did you mixer window?

Even so, the behavior there (in the mixer window) is essentially just what I would expect.

And yes, the editor strip is totally independent. It is not "owned" by any track, but shows the current first-selected track/bus etc.

Some screenshots or even a screencast would help.
(0026724)
paul   
2022-10-27 23:22   
here's my screencast of just the editor window. i can't see any misbehavipr here:
(0026726)
mc888   
2022-10-27 23:38   
Maybe I'm the one who's confused. I didn't realize the Editor window treats the mixer strips as all one strip.

Your synths look fine. Here's what a 16 channel track looks like.

As long as I *never* touch the width in the Editor window, I can keep the narrow MIDI and wide Audio default. But as soon as I touch it once, it's game over. I can never get back that combination.
(0026727)
paul   
2022-10-27 23:44   
ah, ok, now i understand.

Yeah, understanding that the editor mixer strip is one strip with "ever changing content" is important here. When you make it narrow, that isn't an operation somehow tied to the currently displayed track, it's a purely visual thing for the editor mixer strip. It will continue to be that way regardless of the content shown.

In the mixer view/tab/window, the strips are "bound" to show just "their" track/bus. So when you change width there it *appears* to be a persistent setting for the track/bus. But again, it's just a visual thing, not a setting of the track/bus. You don't see this because the strip <-> track/bus mapping never changes.
(0026728)
mc888   
2022-10-28 00:02   
Ok. But that doesn't explain the width change in the Mixer window on exit & restart.

This is just the small piece I could reproduce on a pure 7.0 session. I'm still mystified by the random width shuffling in the Mixer window in 6.x. And I mean random. It will be like 2 or 3 adjacent audio tracks/busses in a larger group. Sometimes it's less random, and only narrows the last track all the way to the right.

If it's part of the display subsystem, anyplace I can tweak it ? Try a different theme or something?

Thanks
(0026731)
paul   
2022-10-28 00:43   
absolutely nothing to do with themeing.

from a quick scan of the code, the mixer width strip is only saved if it was set individually for that strip. any time you set it via the mixe (e.g. Ctrl-Shift-click) or or a menu item, we will not save that setting. That may explain part of what you are seeing.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9043 [ardour] bugs block always 2022-10-27 21:16 2022-10-28 00:35
Reporter: mrbillrodgers Platform: Apple Macintosh  
Assigned To: paul OS: MacOS  
Priority: high OS Version: 10.12 or later  
Status: resolved Product Version: 7.0  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Downloaded Program Will Not Install
Description: My brand new download won't run on my new macbook pro. I verified that my download from the web site was the ARM version. After installing, I get the message:

“Ardour7” is damaged and can’t be opened. You should move it to the Trash.

I downloaded the file at 4:50pm US Eastern time.

In looking at the file I downloaded, it has the name:

Ardour-7.0.0-arm64.dmg

Given that the Mac is such a popular platform for music people, I'm really surprised it's not working for me. Maybe I've done something really stupid.

On my macbook, if I enter the command "uname -a" in the command window, I get:

Darwin Williams-MacBook-Pro.local 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:19:52 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T6000 arm64
williamrodgers@Williams-MacBook-Pro ~ %
Tags:
Steps To Reproduce: Download from web site.
Do "install" drag and drop thing
Attempt to start Ardor.
Additional Information:
System Description
Attached Files:
Notes
(0026721)
paul   
2022-10-27 22:46   
This is covered in the document we asked you to read after download:

https://ardour.org/first_time_macos.html
(0026729)
mrbillrodgers   
2022-10-28 00:23   
Your fix worked. However, since people read from top to bottom, the important message should be placed above the download button the page, not below it. I would still consider this a bug, not in the Ardour program itself, but in the design of the download page.
(0026730)
paul   
2022-10-28 00:35   
Changed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9030 [ardour] bugs major always 2022-10-24 08:32 2022-10-27 21:04
Reporter: fhomann Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: First time signature position lost when importing a 6.x session into Ardour 7
Description: If you have a 6.x session where the first time signature has been moved to the first beat in a recording as described in [1] the position of that first time signature will be lost after importing that session into Ardour 7.

In effect all position markers, bars etc. will be off, and the session will be hard to work with again.

[1] https://manual.ardour.org/arranging/time-tempo-and-time-signature/techniques-for-working-with-tempo-and-time-signature/
Tags:
Steps To Reproduce: Create a new session with Ardour 6.x . Drag the first time signature to a position that is not '0'. Maybe create some position markers, too. Save that session and open it with Ardour 7.
Additional Information: Tested with Ardour-7.0.80-dbg-x86_64-gcc5 and a session created with Debian's Ardour 6.9.0.
System Description
Attached Files:
Notes
(0026705)
paul   
2022-10-26 23:02   
This was sort of a deliberate decision. The structure of the tempo map in 7.0 is radically different, and for now we opted to not correctly support 6.x sessions with the first tempo marker at 0.

However, we may be able to fix this at some point.

You should use 6.9 to continue working on such sessions.
(0026716)
mc888   
2022-10-27 20:25   
Not to hijack the thread, but is there any workaround for this? i.e. a conversion process. Perhaps doing as Save As to create a session copy with the new format? Or maybe a Lua script session patch that can just rewrite the tempo markers from a previous version?
(0026719)
paul   
2022-10-27 21:04   
This is now "fixed" in the sense that we do the best we can:

* put a time signature marker at zero with the same time signature as the initial one in the 6.x version
* put a BBT marker at the position of the 6.x initial marker to reset the BBT time appropriately

7.x will not allow you to not have a time signature at zero, so this is the "best" we can do.

BTW, it was a very simple typo that stopped this from working already.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9026 [ardour] bugs major always 2022-10-22 22:49 2022-10-27 20:07
Reporter: mc888 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: bullseye/KDE  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: waveforms not visible during recording
Description: Waveforms do not appear in Editor window while recording, until transport is stopped.

In previous version the waveform display would be delayed, but would appear.

Righ now I'm tracking 6 channels and just get a big red block until I press stop to see if it's working.

Tested with both Clear Current and New playlists.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026674)
mc888   
2022-10-23 00:31   
Just as a sanity check, I deselected "Show waveforms while recording". Exit and restarted. Checked the box again to enable it, exit and restart. No change. Always acts as if this box is deselected.

The problem does not occur in 6.9.
(0026684)
paul   
2022-10-24 03:20   
Working just fine here. I would recommend that you start by renaming ~/.config/ardour7 (the directory) and see if that helps fix it.
(0026688)
mc888   
2022-10-24 13:38   
Ok. Renamed the directory and this time I did not copy config from Ardour 6 when prompted at startup.

Verified "Show waveforms while recording" is selected by default. Created new playlists for testing (recording output from a MIDI instrument).

Rolled it for 8 bars and waveforms still did not appear until I stopped transport.

Before reporting it yesterday, I already tried creating a new session in Ardour 7 so there would be no leftover Ardour 6 data in the session. But I did create a template in Ardour 6 and used it for the new Ardour 7 session. That should be clean, yes?

If it's not the config and not the session, I don't know where else to look.
(0026689)
paul   
2022-10-24 14:09   
An obvious test would be to create a new session without the template ....
(0026690)
mc888   
2022-10-24 14:42   
That worked.

What could possibly be stored in a routing template that could impact this? I have a lot of templates accumulated since Ardour 4...
(0026691)
paul   
2022-10-24 14:48   
attach the template and I'll take a look.
(0026693)
mc888   
2022-10-24 16:43   
I want to test a few more to see if I can reproduce it consistently from older templates. And narrow the scope for fault isolation.

If I can do that, I'll post one for you to look at.
(0026715)
mc888   
2022-10-27 20:07   
I've had limited time for testing. As it turns out, I was mistaken about still having templates from Ardour 4. i still have templates from Ardour 3.

Since I've been primarily using Mixbus32C with Store Mixer Settings, I only had 3 templates from Ardour 6.2. All 3 loaded and worked fine without the waveform problem.

The two sessions showing this problem were created in 6.9. One of the two (a test copy of the same session) was modified in Ardour 7.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9008 [ardour] bugs major have not tried 2022-10-18 20:54 2022-10-27 16:16
Reporter: Lost_Highway Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tempo and location markers in wrong place in Ardour 6 session imported to Ardour 7
Description: I’ve opened an A6 session in A7. It has lots of time signature and tempo markers.

A lot of the location markers are not in quite the right place and the same with many of the tempo markers and many of the tempo ramps haven’t been honoured, all of which has thrown the MIDI track out relative to the audio material.

Also, in A6, at a certain zoom level the ruler should show the bar number of every bar. In A7 it does this for some sections, but other sections it is only showing the bar numbers for alternate bars. It also only shows odd-numbered beats in some bars, but even-numbered beats in the following bar. When zooming in further, instead of the previously-unlabelled beats becoming numbered, each showed 960 (I think, the font is tiny). Tempo markers can only be moved to every other beat, so 1, 3, 5, 7 in one bar and 2, 4, 6 of the following bar.

Link to session archive: https://www.dropbox.com/s/3b2v54m0zgyylk0/So%20Disdained%20%28intro%20%26%20extra%29%20WRITING_2022-10-18_202950.ardour-session-archive?dl=0
Tags: bcf2000, Import, marker, ruler, tempo
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026712)
Lost_Highway   
2022-10-27 16:10   
I can confirm that this issue isn't isolated to sessions created in Ardour 6, which are subsequently opened in Ardour 7. I have created a session in Ardour 7 and I can only move tempo markers to beats 1, 3, 5 and 7 of a bar of 7/8 or beats 2, 4, 6 of the subsequent bar. It seems to be only letting me move markers to every other 8th note, ignoring the ones in-between.

The Snap was turned on and even when set to 16th notes, I could only move markers to every other 8th note. However, I've just discovered that with the Snap turned off, I can move tempo markers to any beat. The tempo markers all show as whatever bpm/4 -- with Snap on, is it limiting the range of movement to quarter notes somehow (every other 8th note)?
(0026713)
Lost_Highway   
2022-10-27 16:16   
Sorry, scratch the second half of the previous note, I don't know what was going on.

The first half still stands: this behaviour happens in sessions created in A7 as well as ones imported into it. In all cases tempo change markers can only be moved to every other 8th note.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9041 [ardour] bugs minor always 2022-10-27 10:58 2022-10-27 14:32
Reporter: MyLoFy Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Percussive Mode: Notes do not snap to grid when cursor is placed before grid line
Description: Notes are placed incorrectly when using percussive mode.
Tags: 7.0
Steps To Reproduce: -Create MIDI region
-Switch to percussive mode
-enable snap
-place mouse before the desired grid line. The Ardour cursor snaps to grid.
-left click: Note is placed where the mouse is located and not as expected on the grid line/Ardour cursor location
Additional Information: -happens only in percussive mode
-if mouse is placed after the desired grid line the note is placed as expected.
Screencast:
https://mark.nl.tab.digital/s/A9n9EryJnkqzGox
System Description
Attached Files:
Notes
(0026711)
paul   
2022-10-27 14:32   
fixed in git master a3d3fb9c14ea

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9016 [ardour] features minor have not tried 2022-10-20 14:49 2022-10-27 04:40
Reporter: LAM Platform:  
Assigned To: paul OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow users define keybindings for additional Actions on track/bus/plugin parameters
Description: Currently is not possibile for the user to define keyboard shortcuts for track/bus/plugin parameters. It is possible to access some of these controls only with MIDI/OSC mappings or Lua scripting.

Having additional Actions for track/bus/plugin parameters, and possibly other UI controls, would allow the user to define, for example, keyboard shortcuts to:
enable/disable/bypass plugins
toggle a plugin parameter between two values
Tags: hotkey, shortcuts
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026710)
paul   
2022-10-27 04:40   
Actions are closures, which mean they accept no arguments (i.e. can be invoked without providing any context or information)

Addressing specific parameters of specific plugins is therefore almost impossible to do efficiently with this mechanism. The closest you could get is "the 2nd automtable parameter of the 1st plugin on the 1st selected track". This does not seem useful to me.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9031 [ardour] bugs major always 2022-10-24 09:41 2022-10-27 02:39
Reporter: DonJaime Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Pan automation not working
Description: I have an Ardour 6 session with pan automation on a mono track. When I open it in Ardour 7, the GUI shows the panner moving, but the sound stays centered.
Tags:
Steps To Reproduce: Open the enclosed session and play. The guitarist hangs around in the middle of the stage instead of wandering in from the left.
Additional Information:
System Description
Attached Files: Pan bug_2022-10-24_113022.ardour-session-archive (247,175 bytes) 2022-10-24 09:41
https://tracker.ardour.org/file_download.php?file_id=4245&type=bug
Notes
(0026708)
paul   
2022-10-27 02:39   
fixed in git master fa858a0386ce

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9027 [ardour] bugs major always 2022-10-23 06:42 2022-10-26 23:14
Reporter: gonsolo Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 7 crashes
Description: 0009011 fixed a bug where Midi notes were lost. Now Ardour is crashing (when I'm looping through a region after the first run):

ardour-7.0.78: ../libs/ardour/plugin_insert.cc:1382: void ARDOUR::PluginInsert::automate_and_run(ARDOUR::BufferSet&, ARDOUR::samplepos_t, ARDOUR::samplepos_t, double, ARDOUR::pframes_t): Zusicherung »cnt > 0« nicht erfüllt.

It seems it is this problematic "distance" again:

    samplecnt_t cnt = min (timepos_t (start).distance (next_event.when).samples(), (samplecnt_t) nframes);

The archived project can be found here (since I couldn't upload it because it is 2.5MB):
https://drive.google.com/file/d/1yAc12rxdwuMNrcdr2gV_lpkL0vPSrNcY/view?usp=sharing

I'm trying to loop through bars 40 to 48.
Tags:
Steps To Reproduce: Open the project.
Try to loop from bar 40 to bar 48.
Bang.
Additional Information:
System Description
Attached Files: 0001-Negative-cnt-crashes-ardour-at-the-end-of-a-loop.patch (878 bytes) 2022-10-25 15:40
https://tracker.ardour.org/file_download.php?file_id=4252&type=bug
Notes
(0026677)
gonsolo   
2022-10-23 07:15   
I'm also getting a crash when trying to play from bar 290:

#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
0000001 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007fffe7a3bc46 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
0000004 0x00007fffe7a227fc in __GI_abort () at ./stdlib/abort.c:79
0000005 0x00007ffff4870707 in Temporal::TempoMap::get_grid (this=0x55555ecca830, ret=empty std::__cxx11::list, start=275076360720, end=275082381840,
    bar_mod=0) at ../libs/temporal/tempo.cc:1906
#6 0x00007ffff6e75fa2 in ARDOUR::LV2Plugin::connect_and_run (this=0x55556e442560, bufs=..., start=46781694, end=46782718, speed=1, in_map=...,
    out_map=..., nframes=1024, offset=0) at ../libs/ardour/lv2_plugin.cc:2670
#7 0x00007ffff6b4c418 in ARDOUR::PluginInsert::connect_and_run (this=0x55556e43cbc0, bufs=..., start=46781694, end=46782718, speed=1,
    nframes=1024, offset=0, with_auto=true) at ../libs/ardour/plugin_insert.cc:1107
0000008 0x00007ffff6b4de7c in ARDOUR::PluginInsert::automate_and_run (this=0x55556e43cbc0, bufs=..., start=46781694, end=46782718, speed=1,
    nframes=1024) at ../libs/ardour/plugin_insert.cc:1375
0000009 0x00007ffff6b4da74 in ARDOUR::PluginInsert::run (this=0x55556e43cbc0, bufs=..., start_sample=46781694, end_sample=46782718, speed=1,
    nframes=1024) at ../libs/ardour/plugin_insert.cc:1326
0000010 0x00007ffff6c2a55e in ARDOUR::Route::process_output_buffers (this=0x55556cec9c60, bufs=..., start_sample=46781694, end_sample=46782718,
    nframes=1024, gain_automation_ok=true, run_disk_reader=true) at ../libs/ardour/route.cc:543
(0026683)
paul   
2022-10-24 03:13   
This should already be fixed in git master.
(0026686)
gonsolo   
2022-10-24 08:33   
I just compiled 7.0-104-g72846814ba and it's still there:

ardour-7.0.104: ../libs/ardour/plugin_insert.cc:1382: void ARDOUR::PluginInsert::automate_and_run(ARDOUR::BufferSet&, ARDOUR::samplepos_t, ARDOUR::samplepos_t, double, ARDOUR::pframes_t): Zusicherung »cnt > 0« nicht erfüllt.
Abgebrochen (Speicherabzug geschrieben)
(0026695)
gonsolo   
2022-10-25 15:23   
Printing cnt shows this at the end of the loop:
cnt: 822
cnt: -8469942
(0026696)
gonsolo   
2022-10-25 15:40   
This (preliminary) patch prevents the crash.
(0026697)
gonsolo   
2022-10-25 16:13   
The next crash is here:

0000001 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff343bc46 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
0000004 0x00007ffff34227fc in __GI_abort () at ./stdlib/abort.c:79
0000005 0x00007ffff58a2d0b in Temporal::TempoMap::get_grid(std::__cxx11::list<Temporal::TempoMapPoint, std::allocator<Temporal::TempoMapPoint> >&, long, long, unsigned int) const (this=0x555557b30000, ret=empty std::__cxx11::list, start=280890775200, end=280896796320, bar_mod=0)
    at ../libs/temporal/tempo.cc:1906
#6 0x00007ffff774b7d6 in ARDOUR::LV2Plugin::connect_and_run(ARDOUR::BufferSet&, long, long, double, ARDOUR::ChanMapping const&, ARDOUR::ChanMapping const&, unsigned int, long) (this=0x55556bb1b790, bufs=..., start=47770540, end=47771564, speed=1, in_map=..., out_map=..., nframes=1024, offset=0)
    at ../libs/ardour/lv2_plugin.cc:2668
#7 0x00007ffff73d12b9 in ARDOUR::PluginInsert::connect_and_run(ARDOUR::BufferSet&, long, long, double, unsigned int, long, bool)
     (this=0x55556bb16680, bufs=..., start=47770540, end=47771564, speed=1, nframes=1024, offset=0, with_auto=true) at ../libs/ardour/plugin_insert.cc:1107
0000008 0x00007ffff73d2f5b in ARDOUR::PluginInsert::automate_and_run(ARDOUR::BufferSet&, long, long, double, unsigned int)
    (this=0x55556bb16680, bufs=..., start=47770540, end=47771564, speed=1, nframes=1024) at ../libs/ardour/plugin_insert.cc:1375
0000009 0x00007ffff73d2b67 in ARDOUR::PluginInsert::run(ARDOUR::BufferSet&, long, long, double, unsigned int, bool)
    (this=0x55556bb16680, bufs=..., start_sample=47770540, end_sample=47771564, speed=1, nframes=1024) at ../libs/ardour/plugin_insert.cc:1326
0000010 0x00007ffff74c66c4 in ARDOUR::Route::process_output_buffers(ARDOUR::BufferSet&, long, long, unsigned int, bool, bool)
     (this=0x55556a3fa3b0, bufs=..., start_sample=47770540, end_sample=47771564, nframes=1024, gain_automation_ok=true, run_disk_reader=true)
    at ../libs/ardour/route.cc:543
(0026698)
paul   
2022-10-25 16:21   
That's the same crash as in one of your previous notes.
(0026699)
gonsolo   
2022-10-25 16:29   
Ahhh, yes. Sorry. I meant it's still there after the fix above.
(0026707)
x42   
2022-10-26 23:14   
Fixed in 7.0-116-g489c9ace9f

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9035 [ardour] bugs crash always 2022-10-24 21:07 2022-10-26 19:05
Reporter: imstre Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: high OS Version: 10  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ardour 7 crashes
Description: Hi,
it crashes when you turn on the loop shortcut "L"
it plays until the end and stops, it doesn't to play from the beginning
I tried in several tests
everything is the same
win 10, ram 8, cpu quad q9550
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026703)
paul   
2022-10-26 19:05   
fixed in git master 489c9ace9f87b5

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9036 [ardour] bugs minor always 2022-10-25 12:03 2022-10-26 00:27
Reporter: MichaelP Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Insert Time always prefilled with same values and mixes the values
Description: In Ardour 6.9 this worked as expected.
When using Insert Time with Bars:Beats, the input fields are always prefilled with
001|01|0000
regardless of where the playhead is.
See attached screenshot.

When overwriting the position, and leaving that input field, the 1's reappear, unless at the positions of those 1's a value other than 0 was used.
But when inserting the time, it actually uses the new/correct position.

The second input field, for the amount, has a different behavior.
When leaving that field, the prefilled values of 001|01|0000 are added to the input values.
When applying, the sum of those values is inserted, so 001|01|0000 is the smallest possible amount to insert and hast be subtracted from the actual amount wanted.

When using Timecode, the correct amount is inserted.
But when switching between Timecode and Bars:Beats, after inserting even one number, the input field becomes blank and won't accept anything. The dialogue has to be reopened.
Tags: 7.0, insert, time, track
Steps To Reproduce: Select at least one trackt, choose menu "Track" -> "Insert Time" and try to insert a specific amount, as mentioned before.
Additional Information:
System Description
Attached Files: InsertTime.png (15,468 bytes) 2022-10-25 12:03
https://tracker.ardour.org/file_download.php?file_id=4249&type=bug
png
Notes
(0026701)
paul   
2022-10-26 00:27   
fixed in 29daf3ca4b

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8292 [ardour] bugs minor sometimes 2020-07-09 08:47 2022-10-25 21:38
Reporter: unfa Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Some MIDI regions become empty after reloading a session
Description: This is a very old bug that I've probably reported before, but even I can't find that report.
So here we go again!

After closing and reloading an Ardour session, some MIDI regions become empty - user has to manually recreate them or copy from other places.
If the region was unique - user is out of luck :(

This is one of the worse types of MIDI-related bugs because it introduces data loss and corrupts user work.
Tags: Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20200709_104305.png (46,331 bytes) 2020-07-09 08:47
https://tracker.ardour.org/file_download.php?file_id=3759&type=bug
png
Notes
(0024659)
mhartzel   
2020-07-09 10:01   
If I understand it correctly the user "thekoala" suggested in a forum post that this is a graphical glitch and there is data in the empty regions. He says that resizing the midi track makes midi data reappear.

https://discourse.ardour.org/t/my-ardour-midi-rant/104367/34

Is this true with the issue you are seeing ?
(0024661)
muzikermammoth   
2020-07-09 10:30   
Just had this one happen. Copy a range of a midi clip and paste into another track. All the notes disappear because the region displayed in the new clip on the new track is calculated from the start of the midi clip and not the range start of the selected midi clip.
(0024662)
unfa   
2020-07-09 10:57   
mhartzel:

I don't think so. If it'd be a purely visual issue the notes would still play. I can resize or edit an effected MIDI region and it'll not get the notes back.

muzikermammoth:

I think it's a different issue -what I'm reporting happens strictly when you save and close your session, and open it again. Yes, the regions were duplicates before, but the breakage only occurs after reloading the session.
(0024687)
paul   
2020-07-11 03:28   
need a recipe for this. never had it happen during any of the testing i've done working on MIDI ....
(0026700)
paul   
2022-10-25 21:38   
fixed in b0c162879d484

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9010 [ardour] bugs minor always 2022-10-19 16:26 2022-10-24 16:41
Reporter: Daniele1971 Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: JACK: Cannot callback the server in notification thread!
Description: Since Ardour-7 (official binary)
I see:

[ERROR]: JACK: Cannot callback the server in notification thread!

repeated few times in the log. Everything seems to work normally.

openSUSE TW with Jack (not pipewire).
Tags: jack
Steps To Reproduce: Open an existing session, not sure if happens with new session..
Additional Information:
System Description
Attached Files: log_window.jpg (250,821 bytes) 2022-10-24 16:41
https://tracker.ardour.org/file_download.php?file_id=4248&type=bug
jpg
Notes
(0026658)
paul   
2022-10-20 19:14   
I use Ardour with JACK all day everyday. I have never seen this message. Will pay more attention. ANy idea of a step that might trigger it?
(0026692)
Daniele1971   
2022-10-24 16:41   
It seems that it happens only with sessions created with ardour-6.9, often but not always. I have never seen this error before.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9034 [ardour] features feature N/A 2022-10-24 10:29 2022-10-24 10:29
Reporter: Thomas Krocker Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 7.0 "Midi Chord" integrate chord recording.
Description: The chords that can be heard via "Midi Chord" could be fully edited in the note editor after a chord recording by the user.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Midi Chord Akkord Aufnahme.jpg (330,675 bytes) 2022-10-24 10:29
https://tracker.ardour.org/file_download.php?file_id=4247&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9029 [ardour] bugs major always 2022-10-23 20:33 2022-10-24 04:26
Reporter: unfa Platform: Intel 64-bit  
Assigned To: paul OS: Arch Linux  
Priority: normal OS Version: KDE X11  
Status: resolved Product Version: Mixbus 8.x  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Duplicating a sequence of regions does not work as expected
Description: In Ardour 6.9 if I select multiple regions on a track and hit Alt+D to duplicate them, the relative spacing and order of the selected regions is preserved, an the duplicate of the entire selected group is placed right after the last selected region ends. That's great.

In Ardour 7.0 however, doing the same will not preserve the structure of the selected group of regions, but instead duplicate each region "separately" and put all of them on top of each other, which is not the expected result of the operation.

I attach two screenshots to illustrate this.
One before hitting Alt+D (source regions are selected) and after hitting Alt+D (duplicates are selected).

Tags: Editor
Steps To Reproduce: 1. Create at least 2 regions on a track that are separated on the timeline
2. Select both in the Grab mode
3. Hit Alt+D to duplicate
4. Note how the duplicated regions are placed one on top of another, unlike the source regions
Additional Information:
System Description
Attached Files: Screenshot_20221023_213105.png (46,005 bytes) 2022-10-23 20:53
https://tracker.ardour.org/file_download.php?file_id=4243&type=bug
png
Notes
(0026680)
unfa   
2022-10-23 20:53   
It seems I have posted the issue by mistake and Mantis didn't include my attachements.

Here's the second screenshot. The unselected regions (4 regions in sequence on each track) are the source ones. The selected stack of regions to the right is the result of hitting Alt+D. As you can see the structure of the selected region group was not maintained.
(0026685)
paul   
2022-10-24 04:26   
Fixed in git master, commit 7337ba42f5e0e

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9011 [ardour] bugs major always 2022-10-19 18:36 2022-10-23 06:43
Reporter: gonsolo Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 7 looses MIDI notes
Description: As you can see from the two images, Ardour 7 looses all midi notes from the tuba. This was immediately after opening a project done with Ardour 6.9 with the new version.
Tags: 7.0
Steps To Reproduce: Open the project with Ardour 7: No tuba notes at bar 40.
Additional Information: The archived project can be found here (since I couldn't upload it because it is 2.5MB):
https://drive.google.com/file/d/1yAc12rxdwuMNrcdr2gV_lpkL0vPSrNcY/view?usp=sharing
System Description
Attached Files: Ardour-6.9.png (129,684 bytes) 2022-10-19 18:36
https://tracker.ardour.org/file_download.php?file_id=4233&type=bug
png

Ardour-7.png (108,183 bytes) 2022-10-19 18:36
https://tracker.ardour.org/file_download.php?file_id=4234&type=bug
png
Notes
(0026673)
paul   
2022-10-22 20:34   
Fixed in 7.0-78-gcc30495ba0
(0026675)
gonsolo   
2022-10-23 06:38   
Cool. Thanks.

But now Ardour crashes at (when I'm looping through a region after the first run):

ardour-7.0.78: ../libs/ardour/plugin_insert.cc:1382: void ARDOUR::PluginInsert::automate_and_run(ARDOUR::BufferSet&, ARDOUR::samplepos_t, ARDOUR::samplepos_t, double, ARDOUR::pframes_t): Zusicherung »cnt > 0« nicht erfüllt.

It seems it is this problematic "distance" again:

    samplecnt_t cnt = min (timepos_t (start).distance (next_event.when).samples(), (samplecnt_t) nframes);
(0026676)
gonsolo   
2022-10-23 06:43   
I filed a new bug in 0009027.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8227 [ardour] bugs minor always 2020-06-11 18:27 2022-10-22 18:48
Reporter: derwok Platform: Thinkpad T460s  
Assigned To: OS: Ubuntu Linux  
Priority: normal OS Version: 20.04 LTS  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6.0.0 crashes on session load
Description: Using Ardour 6.0.0 on Ubuntu 20.04 LTS. With ALSA drivers (No Jack).
Worked on this session for several days. It survived multiple opens/closes.
Neither Sound nor MIDI setup changed in theses days.

Now loading my session gives me a loading error (see screenshot) with Ardour crash after pressing OK.
Tags: crash load bad_weak_ptr
Steps To Reproduce: Load the attached session file (sorry only XML, no audio / midi)
Additional Information: I tried:

    Check other sessions. OK: All my other stored project’s sessions load great without a hic-up. Some more complex, some less complex as this one…
    I rebooted. No help
    I unpluged all devices. Then replugged all devices. At no avail…
    I tried to load the session “Safe Mode: Disable all plugins”
    I tried to create a new session: OK, works

Console log follows:

wok@thinkpad:~$ Ardour6
Ardour6.0.0 (built using 6.0 and GCC version 6.3.0 20170516)
Ardour: [INFO]: Your system is configured to limit Ardour to 1048576 open files
Ardour: [INFO]: Loading system configuration file /opt/Ardour-6.0.0/etc/system_config
Ardour: [INFO]: Loading user configuration file /home/wok/.config/ardour6/config
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
Ardour: [INFO]: Using SSE optimized routines
Ardour: [INFO]: Loading plugin meta data file /opt/Ardour-6.0.0/share/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin meta data file /home/wok/.config/ardour6/plugin_metadata/plugin_tags
Cannot xinstall SIGPIPE error handler
Ardour: [INFO]: Loading default ui configuration file /opt/Ardour-6.0.0/etc/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/wok/.config/ardour6/ui_config
Ardour: [INFO]: Loading 449 MIDI patches from /opt/Ardour-6.0.0/share/patchfiles
Gtk-Message: Failed to load module "canberra-gtk-module"
Ardour: [INFO]: Loading color file /opt/Ardour-6.0.0/share/themes/dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file /opt/Ardour-6.0.0/etc/clearlooks.rc
Ardour: [INFO]: Loading bindings from /home/wok/.config/ardour6/ardour.keys
Loading ui configuration file /opt/Ardour-6.0.0/etc/clearlooks.rc
Found nothing along /home/wok/.config/ardour6/templates:/opt/Ardour-6.0.0/share/templates
Scanning folders for bundled LV2s: /opt/Ardour-6.0.0/lib/LV2
Set cursor set to default
 loading from ... templ is_new 0 bp 0
Butler drops pool trash
Log Messages:
INFO: AlsaAudioBackend: adjusted output channel count to match device.
INFO: AlsaAudioBackend: adjusted input channel count to match device.
INFO: harvid version: 803
INFO: Loading menus from /opt/Ardour-6.0.0/etc/ardour.menus
ERROR: Unexpected exception during session setup: tr1::bad_weak_ptr

Attached Files: load-error.png (35,124 bytes) 2020-06-11 18:27
https://tracker.ardour.org/file_download.php?file_id=3732&type=bug
png

Happy Birthday.ardour (269,237 bytes) 2020-06-11 18:27
https://tracker.ardour.org/file_download.php?file_id=3733&type=bug
Happy Birthday-2.ardour (269,237 bytes) 2020-06-11 18:55
https://tracker.ardour.org/file_download.php?file_id=3734&type=bug
2020-06-11_21-36 Ardour Screenshot.png (389,423 bytes) 2020-06-11 19:42
https://tracker.ardour.org/file_download.php?file_id=3735&type=bug
Notes
(0024452)
x42   
2020-06-11 18:55   
(Last edited: 2020-06-11 19:30)
The attached file allows to load the session again. Replace the "Happy Birthday.ardour" file in your session folder with the file.
The fix is to change line 3075 and disable <code>Protocol name="Generic MIDI" ... active="0"</code>

The bug is caused since you've apparently used MIDI-learn and the Control that was assigned is no longer available (a pitch-bend?). We'll need to address this in a future release.

(0024453)
derwok   
2020-06-11 19:42   
There it is in all its beauty!!
You're my hero!! Big thanx!
(And thanks to the XML format that makes patching so easy) :-)
Never would have thought of this root cause.

But I need to say: yes: I tried to learn the pitch bend. But it did not work out while the session was open. Anyhow it got saved?!
The pitch bend had no effect on the setBfree organ. When I tried to load the (then crashing) session , the MIDI keyboard was all available with the same hardware pitch bend.
So it might be, that the problem is not during loading (the hardware was available and connected!), but that the problem occured even more early during assigning and saving bad information?

Anyway: thanks again! Just out of sheer happiness a photo of Ardour with my session loading again.
(0024455)
x42   
2020-06-11 19:57   
Well, organs have no pitch-bend, so it may have been "working", but setBfree does not respond since a Hammond B3 has not pitch-wheel.

Anyway, I'll leave this issue open. The root cause remains to be fixed and that session of yours will come in handy for this.
(0024742)
consint   
2020-07-15 16:29   
I just wanted to inform you that I had the same problem with a project today. Setting "Generic MIDI" to active="0" also worked for me. Thanks a lot!
(0025373)
kevinw   
2021-01-03 16:31   
I had the same "tr1::bad_weak_ptr" exception on startup. I had used midi learning and not changed any hardware.

Removing this block made it run again:

$ diff "Pirate#0.ardour.orig" "Pirate#0.ardour.patchfixed"
2112,2126d2111
< <Protocol name="Generic MIDI" feedback="1" feedback-interval="10000" threshold="15" motorized="0" binding="Korg nanoKONTROL Studio" active="1">
< <Input>
< <Port name="MIDI Control In" direction="input">
< <Connection other="system:midi_capture_nanoKONTROL Studio"/>
< </Port>
< </Input>
< <Output>
< <Port name="MIDI Control Out" direction="output">
< <Connection other="system:midi_playback_nanoKONTROL Studio"/>
< </Port>
< </Output>
< <Controls>
< <MIDIControllable id="23059" event="0xb0" channel="0" additional="0xc"/>
< </Controls>
< </Protocol>


Actually if I just remove:
< <Controls>
< <MIDIControllable id="23059" event="0xb0" channel="0" additional="0xc"/>
< </Controls>

...Ardour will load the session. I'm up and running again thanks to finding this bug report.
(0026214)
MyLoFy   
2021-11-11 18:15   
Phew! This just saved me from a huge headache and the loss of two days work, thanks guys!
Had a setBFree track and assigned my Faderport via QMidiRoute to the rotary speed (which works). Setting <code>Protocol name="Generic MIDI" ... active="0"</code> solved it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9024 [ardour] bugs crash always 2022-10-21 18:28 2022-10-21 18:49
Reporter: Thomas Krocker Platform: Microsoft  
Assigned To: OS: Windows  
Priority: immediate OS Version: 10  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 7 - Windows 10 crash after calling context menu in Ardour time display
Description: https://tracker.ardour.org/view.php?id=8989

Ich habe in der ui_config von Ardour 7 den Parameter clock-display-limit auf Null gesetzt, weil die Zeitanzeige in neuen 96-kHz-Projekten nicht funktionierte. Danach hat es funktioniert. Heute starte ich wie gewohnt Ardour um zu prüfen ob die Zeitanzeige noch funktioniert. Es funktionierte noch. Aber!!! Sobald ich mit der rechten Maustaste auf die Zeitanzeige geklickt habe, fror Windows ein und stürzte danach komplett ab. Ich habe die ui_config wiederhergestellt. Danach gab es keinen Absturz mehr.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9023 [ardour] features feature N/A 2022-10-21 18:20 2022-10-21 18:46
Reporter: Thomas Krocker Platform:  
Assigned To: paul OS:  
Priority: high OS Version:  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 7.0 Delete all CUE markers at once
Description: Ardour 7.0 Delete all CUE markers at once.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: cuemarkers.jpg (398,538 bytes) 2022-10-21 18:20
https://tracker.ardour.org/file_download.php?file_id=4241&type=bug
Notes
(0026670)
paul   
2022-10-21 18:46   
already implemented in git master

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9022 [ardour] bugs crash always 2022-10-21 18:16 2022-10-21 18:42
Reporter: Thomas Krocker Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: urgent OS Version: 10  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 7.0 crash after “Remove SUB Group Bus” click
Description: subgruppenbus1.jpg: If I just remove the SUB group bus, Ardour doesn’t crash yet.

subgruppenbus2.jpg: The SUB group bus has been removed. But!!! If I now call up the context menu of the mono group, the “Remove SUB group bus” button is still available in the context menu, although the SUB group bus has long since been deleted. Now when I click the “Remove SUB Group Bus” button, Ardour 7.0 crashes.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: subgruppenbus1.jpg (266,402 bytes) 2022-10-21 18:16
https://tracker.ardour.org/file_download.php?file_id=4239&type=bug
subgruppenbus2.jpg (264,362 bytes) 2022-10-21 18:16
https://tracker.ardour.org/file_download.php?file_id=4240&type=bug
Notes
(0026669)
x42   
2022-10-21 18:42   
Fixed in Ardour 7.0-75-ge9bafde628

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9020 [ardour] features minor have not tried 2022-10-21 12:05 2022-10-21 16:41
Reporter: krischan941 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Possibility to deinstall Sample Packs which are installed via Library Download Manager
Description: It would be good, if you can deinstall installed Sample Packs via the Library Download Manager.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026666)
paul   
2022-10-21 16:41   
For now, we assume that you will use your platform's file management tools for that. The problem, of course, is finding them, particularly on Linux, where the dir we're using is logical but invisible to almost all users (~/.local/share/sounds/clips)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9021 [ardour] features feature have not tried 2022-10-21 12:26 2022-10-21 12:26
Reporter: krischan941 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: In cue page preview regions and sources (like clips)
Description: Especially in Cue page it would be cool if previewing regions and sources is possible like you can preview/audition clips.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9019 [ardour] bugs major always 2022-10-21 06:52 2022-10-21 10:41
Reporter: flirora Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ACE High/Low Pass Filter plugin hangs when changing
Description: When changing the Low Pass Cutoff parameter in a certain way, the ACE High/Low Pass Filter causes Ardour to hang.
Tags: 7.0, ACEplugins, hangs
Steps To Reproduce: Open the attached session and press Play.
Additional Information:
System Description
Attached Files: backtrace-ace.txt (35,249 bytes) 2022-10-21 06:52
https://tracker.ardour.org/file_download.php?file_id=4237&type=bug
test2_2022-10-21_024910.ardour-session-archive (24,504 bytes) 2022-10-21 06:52
https://tracker.ardour.org/file_download.php?file_id=4238&type=bug
Notes
(0026663)
x42   
2022-10-21 09:57   
Reproduced with a debug build:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
0000001  0x00007ffff37f9537 in __GI_abort () at abort.c:79
#2  0x00007ffff37f940f in __assert_fail_base
    (fmt=0x7ffff39716a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff6ce0c85 "cnt > 0", file=0x7ffff6ce07b0 "../libs/ardour/plugin_insert.cc", line=1382, function=<optimized out>) at assert.c:92
#3  0x00007ffff3808662 in __GI___assert_fail
    (assertion=0x7ffff6ce0c85 "cnt > 0", file=0x7ffff6ce07b0 "../libs/ardour/plugin_insert.cc", line=1382, function=0x7ffff6ce0c00 "void ARDOUR::PluginInsert::automate_and_run(ARDOUR::BufferSet&, ARDOUR::samplepos_t, ARDOUR::samplepos_t, double, ARDOUR::pframes_t)") at assert.c:101
0000004  0x00007ffff772d97b in ARDOUR::PluginInsert::automate_and_run(ARDOUR::BufferSet&, long, long, double, unsigned int) (this=
    0x55555b5304d0, bufs=..., start=113642, end=113664, speed=1, nframes=22) at ../libs/ardour/plugin_insert.cc:1382
0000005  0x00007ffff772d4f8 in ARDOUR::PluginInsert::run(ARDOUR::BufferSet&, long, long, double, unsigned int, bool)
    (this=0x55555b5304d0, bufs=..., start_sample=112640, end_sample=113664, speed=1, nframes=1024) at ../libs/ardour/plugin_insert.cc:1326
#6  0x00007ffff780bc81 in ARDOUR::Route::process_output_buffers(ARDOUR::BufferSet&, long, long, unsigned int, bool, bool) (this=
    0x55555b515230, bufs=..., start_sample=112640, end_sample=113664, nframes=1024, gain_automation_ok=true, run_disk_reader=true) at ../libs/ardour/route.cc:543
#7  0x00007ffff780cdac in ARDOUR::Route::run_route(long, long, unsigned int, bool, bool)
    (this=0x55555b515230, start_sample=112640, end_sample=113664, nframes=1024, gain_automation_ok=true, run_disk_reader=true) at ../libs/ardour/route.cc:734
0000008  0x00007ffff782165e in ARDOUR::Route::roll(unsigned int, long, long, bool&) (this=0x55555b515230, nframes=1024, start_sample=112640, end_sample=113664, need_butler=@0x7fffc47f694f: false)
    at ../libs/ardour/route.cc:4007
0000009  0x00007ffff7311edb in ARDOUR::Graph::process_one_route(ARDOUR::Route*) (this=0x555559e4e580, route=0x55555b515230) at ../libs/ardour/graph.cc:544

(gdb) frame 4
4  0x00007ffff772d97b in ARDOUR::PluginInsert::automate_and_run (this=0x55555b5304d0, bufs=..., start=113642, end=113664, speed=1, nframes=22) at ../libs/ardour/plugin_insert.cc:1382
1382			assert (cnt > 0);
(gdb) p start
$1 = 113642
(gdb) p next_event.when
$2 = {<int62_t> = {v = {<std::__atomic_base<long>> = {_M_i = 4611686018427401238}, <No data fields>}}, <No data fields>}
(gdb) p cnt
$3 = 0
(gdb) p next_event
$4 = {when = {<int62_t> = {v = {<std::__atomic_base<long>> = {_M_i = 4611686018427401238}, <No data fields>}}, <No data fields>}, value = 0, coeff = 0x0}
(0026664)
x42   
2022-10-21 10:28   
Further notes: The automation here in using Music-time (for a MIDI region)

<events>
b13334 20000
b13649 4197.08447265625
b55875 20000
</events>

start: 112640 next_event.when: b13334 -> dist a5892029@a662323200 in dist.samples: 1002
start: 113642 next_event.when: b13334 -> dist a269@a668214960 dist.samples: 0

Due to reduced time resolution of music-time, find_next_event() returns the same event again, resulting in an endless loop
A similar issue as 2de84c97d0a2ab
(0026665)
x42   
2022-10-21 10:41   
Fixed in Ardour 7.0-64-g6a55146fdc

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9018 [ardour] features minor N/A 2022-10-20 19:30 2022-10-21 04:45
Reporter: mrMute Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow mixer scenes to be MIDI controllable
Description: The buttons to recall mixer scenes are currently not MIDI mappable.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026660)
paul   
2022-10-21 04:45   
I suggest an action to use each of the 0..n mixer scenes. Then it can be setup from a binding map.

MIDI learn isn't as sensible for this, I would claim.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9014 [ardour] features minor N/A 2022-10-20 10:08 2022-10-20 18:53
Reporter: thebutant Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: MIDI Note Chase
Description: A feature to improve MIDI editing by a mile, would be what's called MIDI Note Chase in Bitwig.
This feature makes it possible to listen to MIDI regions without having to start from the beginning.
Let's say you have a 4 minute long drone with a melody playing on top. When editing this long piece or soundscape, we now have to start from the beginning every time to hear what it sounds like. Or export/import along the way, but both these methods are really time consuming.
And Bitwig, maybe others aswell – I've only just heard of this feature, has made a solution where you can start in the middle of a MIDI note and listen to it from there.
Like this: https://youtu.be/4YgAttybw9Y?t=89

This would be such a great improvement for MIDI editing.
Tags:
Steps To Reproduce:
Additional Information: This pretty much shows the point: https://youtu.be/4YgAttybw9Y?t=89
System Description
Attached Files:
Notes
(0026655)
paul   
2022-10-20 14:07   
We plan to implement this in the near future. However, it is worth noting that there are some mildly tricky design judgements that need to be made. Some sounds have a very different attack than their sustain sound, and having the note literally start up in "the middle" will give different sonic effects than if it had actually been playing for a while.
(0026657)
thebutant   
2022-10-20 18:53   
Thanks for pointing out the trickyness and inaccuracy of it. And nevertheless: After reading your reply, I think I do love you just a little.
Thank you so much!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9013 [ardour] features feature N/A 2022-10-20 02:49 2022-10-20 18:15
Reporter: redd Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: BWF export with user-selected timecode
Description: BWF maintains timecode information. Sometimes the timecode desired should track to the ardour transport timecode at export. But sometimes what is needed is for the timecode to match some other real-world value (e.g., the timecode found in a recorded LTC track for instance).

I have been able to accomplish this by moving all of my tracks way WAAAY out in the ardour editor to the desired timecode. This works, but is annoying to work in as now there is all that space, and it's a little touchy having to get multiple regions sync'd to that.

It would be better if we could define that the ardour transport, at its left-most position, corresponded to a particular user-named timecode (and then for the LTC generator to start at this value, and for BWF exports to use that value for the first recorded sample/frame, etc.

Failing that, it may remain valuable to have an LTC timecode offset in preferences as currently is implemeted, but to also have an export offset. I consider this less useful as all times reported in clocks, the transport, etc., won't read to match those "real-world" external values.

This would be handiest if I could also select an track containing LTC and have the first timecode frame value reported. Or alternatively an option to set the transport timecode offset from an LTC track (THIS!)
Tags: 6.0
Steps To Reproduce: N/A
Additional Information: N/A
System Description
Attached Files:
Notes
(0026656)
paul   
2022-10-20 18:15   
> . Or alternatively an option to set the transport timecode offset from an LTC track

Session > Properties > Timecode

Let me know if this works for you.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8992 [ardour] features feature always 2022-10-16 17:24 2022-10-20 12:27
Reporter: krischan941 Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ability to change column size (name) in Editor List
Description: I haven't used Ardour and audio stuff for a longer time. I am a bit positively suprised that I can change the column width in sources tab in the Editor List (as a simple "Quality of Life" improvement). But why not in other Lists? Tracks and Busses List and Regions List? That seems odd to me. I can also do change Column width in the Import dialogue (which is good). It would be practical (as a simple QoL improvement) being able to change the width of name columns in Editor Lists and also as a matter of consistency.
For the "Tags" column in Region List it also makes sense to me.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026625)
paul   
2022-10-17 17:15   
Fixed in git master 43d9dda31c

Because of the way GTK works, making the tag column resizable itself makes no real difference - you can only drag the right side of a column, and since the tag column is on the right-hand-size, it is not directly changeable. However, being able to resize the name column effectively lets you resize the tag column too.
(0026638)
krischan941   
2022-10-18 10:08   
Thanks but it is not present in the latest Nightly (7.0-44-g54a98cd320). Is this correct?
(0026650)
paul   
2022-10-19 15:52   
My mistake, I did it in the wrong branch of the code. It will be in master today, and thus the nightly tomrorow. Sorry about that.
(0026653)
krischan941   
2022-10-20 12:27   
Ok works now, thanks!
For Tracks and Busses List it would be nice to have too. (In larger sessions) I tend to use it as vertical canvas navigation. To see full Track names (or bigger part of them) I currently have to expand/enlarge the list until all other track options are visible. Only then the name column gets bigger. Therefore it would be nice to be able to change Track&Busses name collumn size too.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9007 [ardour] bugs minor always 2022-10-18 20:06 2022-10-18 20:06
Reporter: TechieDamien Platform: Arch  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Attempting to download some of the packages from the clip library fails with invalid url.
Description: One example is Lenox BeatMaker Acoustic Guitar. When attempting to download, the install button briefly flashes to installing and the following error can be found in the log: 2022-10-18T20:54:55 [ERROR]: Download failed, error code URL using bad/illegal format or missing URL ().
Tags: clip, cue
Steps To Reproduce: * Switch to Cue View
* Open the download manager from the clip library
* Click Install for Lenox BeatMaker Acoustic Guitar
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8995 [ardour] bugs minor always 2022-10-17 10:09 2022-10-18 17:40
Reporter: leochras Platform: Arch  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't scroll in overflowing menus if mouse isn't moving
Description: When I try to scroll in the Menu "New Plugin" -> "By Tags", I can't scroll through the list without moving the mouse. This issue probably applies to all "overflowing" menus in Ardour.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: grafik.png (145,310 bytes) 2022-10-17 10:09
https://tracker.ardour.org/file_download.php?file_id=4230&type=bug
png
Notes
(0026622)
paul   
2022-10-17 16:49   
Could you explain a little more about what you mean? I have no issues using these "overflowing" menus ....
(0026635)
leochras   
2022-10-18 05:35   
Okay that's weird, I tried a Windows VM as well and had the same problem there. Also, installing the Flatpak or "from source" doesn't make a difference.
It's probably because if I don't move the mouse, a submenu opens, for example "compressors" and then I can't scroll in the "by tag" menu. This may be subjective, but for me it's kind of annoying.
(0026636)
leochras   
2022-10-18 05:52   
I think that's it, because when you scroll in the side of the menu (not ON the menu items) it works.

You can close this if you want.
(0026644)
x42   
2022-10-18 17:40   
marked as resolved as per OP's request

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8998 [ardour] features minor N/A 2022-10-17 11:13 2022-10-18 17:08
Reporter: magnetophon Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: Mixer Scenes as a sound design tool and automation helper
Description: As is, Mixer scenes are immensely useful for comparing mixes.
They could turn into a great sound-design tool as well with (some of) these additions:

- Add a horizontal cross-fade slider with a drop-down menus on either side to select a scene.
- Add a smoothing time parameter to the crossfade
- Allow the above 4 controls to be automateable
- Add quantize options to these automations, like the ones in the Cue window.

I realize that implementing all of the above would need some non trivial architecture and design decisions and would be a lot of work in general.
A way to get 80% of the utility for 2% of the work would be to add a smoothing time parameter that affects any automation caused by Mixer Scenes.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026619)
x42   
2022-10-17 15:06   
Long term the idea is to place recall markers on the timeline, or associate a given range on the timeline with a scene.
cross-fades are already prepared, there is no architectural change needed. The problem is, as usual, policy and GUI.

but rather than automatable VCA like meta-controls for the fade, we envisage a console like integration.
(0026628)
x42   
2022-10-17 17:47   
The hard part here is "how to interpolate" when cross-fading. e.g. Mute (or any boolean automation) cannot be interpolated.
For gain it could be an equal amplitude or equal power fade. EQ frequency log or linear.. etc
(0026642)
magnetophon   
2022-10-18 17:08   
Great to hear that you are thinking in a similar direction!

> The hard part here is "how to interpolate" when cross-fading

I guess the only thing a DAW can do is look if a parameter has metadata that says it is log or bool or something and assume lin interpolation otherwise, right?
At least some plugin formats *do* expose this metadata, right?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9002 [ardour] bugs crash always 2022-10-17 20:31 2022-10-18 16:26
Reporter: merejo Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: high OS Version: 10  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Extremly high CPU usage
Description: DSP over 100% or more when using Kontakt. Rendering the Daw useless for recording with vst2
Tags:
Steps To Reproduce:  Keep reloading just to have the same thing over again.
Additional Information: High CPU even in Idle mode.
System Description
Attached Files:
Notes
(0026630)
x42   
2022-10-17 20:47   
What buffersize do you use? Menu > Window > Audio/MIDI Setup?

High DSP load is usually associated with small buffers.
(0026640)
paul   
2022-10-18 16:26   
see note by reporter.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8507 [ardour] features minor always 2020-12-17 04:45 2022-10-18 07:28
Reporter: dgdgddgd Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stretch Markers in Ardour
Description: Hi
1-add stretch markers where you want (like this in reaper https://youtu.be/rid4NpN8mqY?t=71)
2-add markers for bypass ardour stretch tool effect (this is not a stretch markers just is a mark a region for bypass some effect)

best
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026637)
leochras   
2022-10-18 07:28   
this would be awesome.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9004 [ardour] bugs minor always 2022-10-18 01:29 2022-10-18 01:29
Reporter: paul Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: GUI design issues from HN comment by SeanLuke (https://news.ycombinator.com/item?id=33225937)
Description: I think UI design is all about being consistent across modes, being tolerant, making common things easy to do and easy to discover while still making the less common things possible. I think it's a pretty well understood field at this point. I do not think it's about prettiness or visual consistency, but visual consistency is certainly a signal that tells us that the other elements in the UI design may be lacking a designer's touch. So let's look at that.

Let's take this image for example:

https://ardour.org/images/retina_no_plugs2.png

I count no less than eight different fonts and font sizes on this screen. Use of whitespace throughout is terrible: for example, look at the placement of the red light snugged up right next to the "Lock" button rather than the Iso button. Speaking which, I presume Iso means "Isolate" while "Grp" means, well, let's assume it doesn't refer to the Grp A4 Synthesizer. Why do you shorten in some ways by removing vowels, and in others by brute truncation?

You also have literally dozens of different button heights. Consider just your faders. Put aside the giant red button. The R/L pans are 32 pixels tall. The In button is 38 pixels tall. The Lock button is 36 pixels tall. The Solo button is 42 pixels tall. The buttons at the bottom are 32 pixels tall. For no reason at all it seems.

You also seem to have tons of different widget widths. Let's consider the VU meters. The Meterbridge meters are 28 pixels wide: the Mixer meters are 24 pixels wide, and its stereo channels are 14 pixels wide (and with completely different dB markings as well) The per-instrument meters at the far left are 16 pixels wide The stereo meters above them are for some reason 10 pixels wide, and together they're 22 pixels wide and so don't line up with the mono meters below them. And finally the global stereo meters up top are 28 pixels wide. What?...

Text styling, justification and clipping is just kooky. Look above the second fader. Vocal, 2, and 0 (which looks like the null set, not a zero, due to weird width) are all centered. Then Fader and AuDynamicsPro are left-justified (And AuDynamicsPro is cut off because it's not getting resized). THEN all the parameters underneath (compression threshold -- again cut off in an ugly way, headroom, expansion ratio, etc.) are all centered again. And they are for no good reason lower-case only. So you have both capitalized case, lower-case-only, and upper-case-only strewn throughout your layout.

To the left of the fader you have "Strips" and "Show". The Show checkboxes are almost invisible thanks to the dark-charcoal-on-black color scheme. Also thanks to your nearly invisible charcoal-on-charcoal scrollbar, you can't read the strips. What's "Claps F"? Why is the "+" so gigantic,and why is it gradiated when no other icons are? I presume the divider can be expanded, but again it's nearly impossible to tell due the charcoal-on-charcoal.

Why are your In, Out, Solo, Audition, and Feedback buttons different colors from the other ones? Why are some of your icons antialised, but others (like the thing to the left of the scissors, or the thing to the left of "No Grid") not? Why are the console buttons (play/record/etc.) smashed together horizontally into thin strips, rather than giving them the standard width afforded to buttons of this importance? At least you could make them square to match their icons. Why is your Tempo and Meter in an incomprehensibly small font? Why do you have two different green colors for fonts?

I am not a big fan of Ableton (say). But its interface is more consistent, much less busy, and much more approachable than Ardour. This is the hallmark of open source software: it tends to lack a hegemon who will sit down and (1) remove features to simplify the interface and (2) force a consistency in design and modality on the software. I will say that what I don't like about Ableton is that it tends to have a lot of mystery-meat interface widgets which don't explain their purpose. But at least they're consistent. :-)

Now Ardour is FAR better than the interface nightmare that is Reaper, a veritable explosion of every single interface style, coupled with a seeming lack of understanding regarding how menus work best. Reaper's interface is objectively bad, full stop. Now there might be people who love it, but I'd wager that's primarily because those people have ego investiture in the product, and ego investiture comes with blinkers. We get heavily involved or invested in a product and it becomes our identity. This should never be an excuse for making a poor product. And compared to practically everyone else out there, Reaper's interface is really, really bad.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8996 [ardour] bugs minor always 2022-10-17 10:10 2022-10-18 00:53
Reporter: garyd Platform: Debian GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Lua fails to show/hide VCAs (Mixbusses too)
Description: The script below (Steps to Reproduce) works in Ardour v6 and Mixbus v7 - it successfully hides/shows a VCA strip in the Editor (and Mixer). A similar script can hide/show a Mixbus strip in the Editor.

In Ardour v7 and Mixbus v8 it doesn't work for VCAs or Mixbusses. Other kinds of routes still work fine: tracks, busses, Master.

I reported this to Nathan @ Mixbus as I noticed it in Mixbus32C v8. Haven't heard back and I see it's affecting Ardour v7 too.
Tags:
Steps To Reproduce: Run this script in the Script window...

local vca = Session:vca_manager():vca_by_number(1)
local stav = Editor:get_stripable_time_axis_by_id(vca:to_stateful():id())
Editor:hide_track_in_display(stav, false)
--Editor:show_track_in_display(stav, false)

That 'should' hide VCA 1 in the Editor (and Mixer). Likewise, the last line should show it instead, if it's currently hidden. At least, that's what it does in earlier versions, hence the "should" in quotes.

For a track named "Audio 1" and for Mixbus 1 (or is that 2? ... whatever) that are currently visible in the Editor, the following script should hide both. It only hides the track.

local track = Session:route_by_name("Audio 1")
local mb = Session:get_mixbus(1)
--hide track in Editor
Editor:hide_track_in_display(Editor:rtav_from_route(track):to_timeaxisview(), false)
--hide mb in Editor
Editor:hide_track_in_display(Editor:rtav_from_route(mb):to_timeaxisview(), false)
Additional Information:
System Description
Attached Files:
Notes
(0026614)
garyd   
2022-10-17 10:36   
Forgot to mention...

It doesn't throw an error or anything. It just silently doesn't work.
(0026632)
x42   
2022-10-18 00:26   
Fixed in Ardour 7.0-41-g7c6c6290ee
The underlying function indeed silently ignored VCAs. In the past it also only applied to Tracks (not Busses), hence the somewhat inconsistent name.

Mixbus will need further specialization, since editor and mixer visibility of those are separated.
(0026634)
x42   
2022-10-18 00:53   
Now also fixed in Mixbus 8.1-891

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9003 [ardour] features minor always 2022-10-18 00:22 2022-10-18 00:42
Reporter: paul Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: various GUI pixel pushing issues (from HN comment by kuramitropolis https://news.ycombinator.com/item?id=33234481)
Description: What I'd like to ask is whether you consider important the issues that I've pointed out on this screenshot (from 6.9):

https://imgur.com/a/yk60rNc

1. IMHO, the grid lines being Too Damn Bright is hands down the most jarring thing for any newcomer to Ardour. Basically, there's too much contrast on the very thing that delineates/delimits empty, user-editable space, relative to the contrast in screen areas that contain fixed UI controls. It just creates the impression of a barrier in the wrong place. Changing the line color from 100% white to 100% black would be at least a 200% improvement in terms of more betterness; a slider from 100% black to 100% white would bump that up to 300%.

The rest is mostly 1px misalignments that just sort of add up:

2. Top row of pixels in the menu bar is not active. So in full screen if you move the mouse all the way to the top edge of the screen the menus don't work. You can see this when opening a menu - GNOME didn't let me take a screenshot with a menu open lol

3. The 4px gradient border causes the "transport" and "editing" toolbars to look very misaligned.

4. The above border ends a few pixels above the "scrollbar/overview". Apparently there's a dragging handle there - but no hint that it's there.

5. These are the only toolbar buttons that don't have a border. If this is meant to signify that the button is inactive (why does "solo" behave differently from the others?), it would benefit from also making the text a tad dimmer.

6. Icon noclips out of the button.

7. Why the monospace here? It's not aligned to anything.

8. Separators would benefit from either being more prominent, or just being blank spaces. All separators except the one that the arrow points to have N pixels to one side and N+1 pixels to the other. Button text is also 1 pixel below the center of the button (and below the baseline of neighboring labels).

These things are noticeable, and annoying, on a 24" 1440p monitor at 150% zoom. Is this due to the scaling or something else? It simply looks slightly unappealing and "broken-ish", which does not do justice to the underlying engineering effort.

I think this problem plagues virtually all native GUI apps based on FOSS toolkits, and hampers migration away from proprietary solutions, to a degree that is often underestimated. I have some experience trying to get people to migrate to FOSS solutions, and I realize that it's an uphill struggle against BigCos that have whole design departments and can afford to condition people as to "what things should look like".

Computers are scary enough beasts as it is - it's too easy to present either too much or too little information to users, who just expect things to be "intuitive" (i.e. learned helplessness). People who have looked proprietary apps all their lives are prone to viscerally rejecting a solid FOSS product that might even be a better fit for their workflow, just because of superficial glitches like the ones I listed above.

One funny effect of this: users might even identify the problem at the wrong level. They may object to the semantics of the interface ("I don't understand it"), while the problem actually is on the level of ergonomics ("it doesn't feel right"). Maybe they don't want to seem petty.

I know my way around Ardour and the general Linux audio ecosystem well enough to get things done with it, but the reason I don't bring Ardour with me everywhere is ... basically the grid lines and alignment! Please tell me there's a dotfile for that, or that a fix is on the roadmap? :-)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 8JPTBSC.png (125,288 bytes) 2022-10-18 00:42
https://tracker.ardour.org/file_download.php?file_id=4231&type=bug
png
Notes
(0026633)
x42   
2022-10-18 00:42   
Attached image from https://imgur.com/a/yk60rNc

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8999 [ardour] bugs minor have not tried 2022-10-17 13:33 2022-10-17 17:17
Reporter: umlaeute Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: bashism in launch script
Description: the script generated by 'gtk2_ardour/ardour.sh.in' contains a call to 'ulimit' which is a bash-builtin (and not mandated by POSIX sh).
however, the generated scripts uses '#!/bin/sh' as a shebang, indicating that this is a POSIX-compliant script.

Tags:
Steps To Reproduce: ```sh
$ checkbashisms gtk2_ardour/ardour.sh.in
possible bashism in gtk2_ardour/ardour.sh.in line 14 (ulimit):
MLOCK_LIMIT=$(ulimit -l)

$ shellcheck gtk2_ardour/ardour.sh.in
In gtk2_ardour/ardour.sh.in line 14:
MLOCK_LIMIT=$(ulimit -l)
                     ^-- SC3045 (warning): In POSIX sh, ulimit -l is undefined.
```
Additional Information:
System Description
Attached Files:
Notes
(0026618)
x42   
2022-10-17 14:08   
Can we rely on bash being present? dash can also handle it just fine.

I think it is fine if the check fails when `ulimit` is not available. perhaps the proper solution is to add a 2>/dev/null or fall back to prlimit if that is available
(0026621)
paul   
2022-10-17 16:47   
ulimit is a part of POSIX 1-2017 Section 12.2, Utility Syntax Guidelines.

What you actually mean is that the -l argument to ulimit is not defined by POSIX
(0026626)
umlaeute   
2022-10-17 17:16   
yes.
(0026627)
umlaeute   
2022-10-17 17:17   
"yes" as in: "the -l argument to ulimit is not defined by POSIX".

(rather than: "yes, just ignore 'ulimit' not working")

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8990 [ardour] features minor always 2022-10-16 09:02 2022-10-17 16:58
Reporter: eudoxos Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Combining regions removes their region cue marks
Description: When I select two (adjacent, in this case) regions and go Selected regions > Edit > Combine, any cue marks on the regions will disappear. I would expect them to be transferred to the resulting combined region.
Tags:
Steps To Reproduce: Combine regions with some cue marks on them, resulting region will not have any cue marks.
Additional Information:
System Description
Attached Files: image.png (93,235 bytes) 2022-10-16 09:02
https://tracker.ardour.org/file_download.php?file_id=4225&type=bug
png

image-2.png (4,758 bytes) 2022-10-16 09:02
https://tracker.ardour.org/file_download.php?file_id=4226&type=bug
png
Notes
(0026609)
eudoxos   
2022-10-16 09:07   
please, someone with proper permissions, fix combing -> combining in the summary; sorry
(0026616)
x42   
2022-10-17 13:17   
There is only a single sync-position per region. So it is somewhat ill defined what should happen.
Presumably the compound should inherit the earliest marker.
(0026620)
paul   
2022-10-17 16:44   
This is not about sync positions, but region cue markers. These markers are actually associated with the underlying source (file) and yes, they ought to be transferred. However, the whole magic of "Combine" is that it does not actually create a new file at all. Some thought will be required to see how hard it might be to add the markers to a source type that is not actually a file.
(0026624)
x42   
2022-10-17 16:58   
I see, looking at the screenshot, those marks look like sync-points. I though they're yellow because of some theme option. my bad.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9000 [ardour] other text have not tried 2022-10-17 13:40 2022-10-17 14:46
Reporter: umlaeute Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: XP  
Status: resolved Product Version: 7.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: minor spelling mistakes
Description: there's a few minor spelling mistakes, such as
- "Licence" -> "License"
- "exising" -> "existing"
- "allows to" -> "allows one to"
- "signficantly" -> "significantly"
- "occured" _> "occurred"
Tags:
Steps To Reproduce:
Additional Information: discovered automatically with spellintian.

a patch (named '0200-spelling.patch' or so) that fixes the spelling mistakes can be found at https://salsa.debian.org/multimedia-team/ardour/-/tree/master/debian/patches
System Description
Attached Files:
Notes
(0026617)
x42   
2022-10-17 14:04   
Thanks! Some of those were already fixed, I've applied the missing ones.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8997 [ardour] features minor N/A 2022-10-17 10:55 2022-10-17 10:55
Reporter: magnetophon Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: Mixer Scenes: show current scene, show changes
Description: Thanks a lot for this wonderful feature!
When I asked for an "A/B compare function for plugins" 12 years ago, I didn't realize this is what I actually wanted!
https://tracker.ardour.org/view.php?id=3030

Two possible improvements:
- Highlight the current scene (or the last one saved or selected)
- Show if the current settings are different from the ones in the current scene.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8994 [ardour] bugs crash always 2022-10-16 19:41 2022-10-16 21:45
Reporter: martibs Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: none OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Freeze on track input or monitor select
Description: Opening an empty project in safe mode. Using ALSA with pretty low demand settings (48K, 1024 buffer). After adding an track, when enabling monitor input, or sometimes changing track input, the system freezes. Does not seem to happen at all when ALSA MIDI is disabled (set to None).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: gdb-221016-2.txt (56,208 bytes) 2022-10-16 19:41
https://tracker.ardour.org/file_download.php?file_id=4228&type=bug
gdb-221016-3.txt (60,974 bytes) 2022-10-16 19:41
https://tracker.ardour.org/file_download.php?file_id=4229&type=bug
Notes
(0026612)
x42   
2022-10-16 21:13   
I have not been able to reproduce this with 7.0

Lock (this=0x7fffffffbe10, mutex=...) looks like memory corruption. This will be hard to debug.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8993 [ardour] bugs crash always 2022-10-16 19:15 2022-10-16 21:45
Reporter: martibs Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: none OS Version: (any)  
Status: new Product Version: 7.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Adding track on empty project in safe mode crashes
Description: Opening an empty project in safe mode. Using ALSA with pretty low demand settings (48K, 1024 buffer). When trying to add a track, the GUI freezes. Doesn't actually crash, so the GBD doesn't automatically create a crash report or give a prompt. I have to manually stop GDB using ctrl+c, and then write the backtrace.
Tags:
Steps To Reproduce:
Additional Information: Performed using an older build, as I don't have access to the latest build.
System Description
Attached Files: gdb-221016-1.txt (57,508 bytes) 2022-10-16 19:15
https://tracker.ardour.org/file_download.php?file_id=4227&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8654 [ardour] bugs minor always 2021-04-05 19:59 2022-10-09 06:29
Reporter: n3klid Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 6.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Use translation Tickle box does not work
Description: Even I unchecked Use translation Tickle box, Ardour always starts with translated interface.

I need run Ardour with English interface regardless Ubuntu system setting.

This bug appears in Xfce, Gnome, KDE.
Tags: translations
Steps To Reproduce: Set main Ubuntu language English , units and collating in Czech - >Ardour starts with Czech interface

Set main Ubuntu language English, units and collating English -> Ardour starts with English interface

In both cases "Use translates" check box in Ardour settings is UNCHECKED (I do not want to use translations).
Additional Information: pedro@studio:~$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:cs
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.UTF-8
LC_TIME=cs_CZ.UTF-8
LC_COLLATE=cs_CZ.UTF-8
LC_MONETARY=cs_CZ.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=cs_CZ.UTF-8
LC_NAME=cs_CZ.UTF-8
LC_ADDRESS=cs_CZ.UTF-8
LC_TELEPHONE=cs_CZ.UTF-8
LC_MEASUREMENT=cs_CZ.UTF-8
LC_IDENTIFICATION=cs_CZ.UTF-8

Ardour starts in English but during load switch to Czech:
pedro@studio:~$ ardour
WARNING: Could not check your glib-2.0 for mutex locking atomic operations.

Ardour6.3.0~ds0 (built using 6.3.0~ds0-1 and GCC version 10.2.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 1048576 open files
Ardour: [INFO]: Loading system configuration file /etc/ardour6/system_config
Ardour: [INFO]: Loading user configuration file /home/pedro/.config/ardour6/config
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
Ardour: [INFO]: Using AVX optimized routines
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour6/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/pedro/.config/ardour6/plugin_metadata/plugin_stats
Ardour: [INFO]: Loading default ui configuration file /etc/ardour6/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/pedro/.config/ardour6/ui_config
Ardour: [INFO]: Loading 449 MIDI patches from /usr/share/ardour6/patchfiles
Ardour: [INFO]: Nahrává se soubor s barvou '/usr/share/ardour6/themes/dark-ardour.colors
Ardour: [INFO]: Nahrává se soubor s nastavením rozhraní /etc/ardour6/clearlooks.rc
Ardour: [INFO]: Loading bindings from /etc/ardour6/ardour.keys
Nahrává se soubor s nastavením rozhraní /etc/ardour6/clearlooks.rc


System Description
Attached Files: 2021-04-05_21-28.png (188,347 bytes) 2021-04-05 19:59
https://tracker.ardour.org/file_download.php?file_id=3990&type=bug
png

2021-04-05_21-37.png (16,875 bytes) 2021-04-05 19:59
https://tracker.ardour.org/file_download.php?file_id=3991&type=bug
png

image.png (122,850 bytes) 2022-10-04 06:33
https://tracker.ardour.org/file_download.php?file_id=4219&type=bug
png
Notes
(0025743)
paul   
2021-04-22 00:35   
You put the version down as "Mixbus", but the screenshots show ardour.

Where did you get this version of Ardour from?
(0025746)
paul   
2021-04-22 00:40   
Also, does this still happen with Ardour 6.6 ?
(0026596)
eudoxos   
2022-10-04 06:14   
I am confirming this with Ardour 6.9.0~ds0-1build1 (Ubuntu package) - the UI follows locale settings regardsless of this option being unchecked (the workaround is to run `LC_ALL=C ardour`),
(0026597)
eudoxos   
2022-10-04 06:33   
Without having time for a proper PR ATM, a cursory analysis of main.cc (lines 256 and below) and my hypothesis:

A. (main.cc:258) force-sets LC_MESSAGES to the first nonempty of LC_ALL, LC_MESSAGES, LANG) (as per man 3 gettext).

B. (main.cc:278) bindtextdomain will bind text domain unconditionally

Calls to gettext(...) consume LC_MESSAGES env var (as per man 3 gettext), which was either set by (A) but it could be also part of the process environment already - that is the case for @n3klid (see his output from locale above).
(0026598)
paul   
2022-10-04 13:36   
1. the option in preferences will control whether or not ARDOUR::translations_are_enabled() returns true. Does the file ~/.config/ardour6/.translate exist on your system (note the leading dot before the word translate)

2. bindtextdomain() has no consequences if the locale is not set inside the application

3. We cannot provide support for distribution builds, where we do not/cannot control the build process. If you test this again, please use a nightly build from nightly.ardour.org
(0026602)
eudoxos   
2022-10-09 06:29   
I can reproduce this with local build from git & created a PR at github (https://github.com/Ardour/ardour/pull/733).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8977 [ardour] features feature always 2022-10-08 23:43 2022-10-08 23:43
Reporter: JCS Platform: Microsoft  
Assigned To: OS: Windows  
Priority: low OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Windows installer: add checkbox to create a desktop shortcut
Description: A minor but quality-of-life improvement for WIndows users would be to include a checkbox with the option to create a desktop shortcut within the installation exe.

Existing functionality:
Run the Windows installer to completion, locate Ardour.exe within the install path, right-click the file and "send to desktop as shortcut"

Desired functionality:
Run the windows installer, verify that the checkbox is selected to create a desktop shortcut, run the installer to completion, verify that a shortcut exists on the desktop
Tags: install
Steps To Reproduce: Run the installer to completion and verify that a desktop shortcut was produced.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8521 [ardour] bugs minor always 2020-12-24 18:34 2022-10-04 17:07
Reporter: iur.n Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't stop playing after pressing "Got to start of session"
Description: Can't stop playing after pressing "Got to start of session". On both sound backends Jack or ALSA.
Tags:
Steps To Reproduce: 1. Press Play
2. Press "Got to start of session"
3. Press Stop
Result: Playing is not stopped, also, the vertical line continues to move.
Additional Information: I have made a little inverstigation, and I don't know if ti will help.

// Play

Log: Event type: 7
Log: Event type: 3
Log: TransportFSM::transition : 1

// Got to start of session

Log: Event type: 5
Log: TransportFSM::transition : 4
Log: Event type: 1
Log: locate to 0 took 1119 usecs for 3 tracks = 373 per track
Log: Event type: 6
Log: should_not_roll_after_locatestop
Log: TransportFSM::transition : 0
Log: Event type: 0

// Stop

Log: Event type: 7
Log: Event type: 4

When pressing stop I come here and _motion_state = 0, thus, stop_playback (ev); is not called.

    case StopTransport:
                
                switch (_motion_state) {
                        std::cout << "MYLOG" << "stop playback " << std::endl;
                case Rolling:
                        std::cout << "MYLOG: " << "stop playback[1] " << std::endl;
                        transition (DeclickToStop);
                        stop_playback (ev);
                        break;
                case Stopped:
System Description
Attached Files:
Notes
(0025434)
paul   
2021-01-18 19:19   
if you can easily generate this error, please use a debug build and run with -D tfsm,transport then paste the output here.
(0025516)
ardourwlk   
2021-02-12 17:09   
Just wondering if same thing as: https://tracker.ardour.org/view.php?id=8490
(0025517)
iur.n   
2021-02-12 17:14   
I no more can reproduce.
(0026599)
ufocia   
2022-10-04 16:44   
Seems to be fixed in 6.9. The transport stops automatically on "Go to start of session", but the "Play from playhead" button remains active and does not switch to "Stop playback". Whatever was the solution, additional work remains.
(0026600)
paul   
2022-10-04 17:07   
the only testing that matters at this point are the nightly builds. Ardour 7.0 is about to be released.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8759 [ardour] bugs minor always 2021-06-23 07:36 2022-10-04 00:17
Reporter: CTS Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI learn does not have any effect
Description: When using the MIDI learn (ctrl-middle click) feature, parameters appear to acknowledge incoming MIDI when mapping but the controller fails to have any effect on the parameter value itself.

I noticed this when I was testing issue 0008756, in an earlier commit there was usually at least "some" sporadic movement of the parameter in response to the controller movements. In the most recent commit I tested (8ad1405cf5e83a31017d88ee6706c819b484a37c) parameters appear entirely unresponsive.
Tags:
Steps To Reproduce: 1. Start Ardour
2. Enable Generic MIDI under preferences -> control surfaces. Select your controller for Incoming MIDI.
3. Create an audio track
4. Ctrl - middle click on a fader, see pop-up "operate controller now"
5. Move a control knob or something on your controller, see that the MIDI control message is acknowledged as the popup disappears
6. Continue moving your controller and observe that the mapped parameter does not respond to the incoming messages (i.e. nothin happens!)
Additional Information:
System Description
Attached Files:
Notes
(0026395)
paul   
2022-04-16 00:52   
There are several possibilties.

One is that your controller is using encoders and not "real knobs". These send just "+1" and "-1" messages, and cannot be used with MIDI learn.

Another is that you may need to sweep the knob through the whole range in order to "engage" with the parameter under control.
(0026558)
paul   
2022-08-12 13:29   
status?
(0026562)
CTS   
2022-08-12 16:44   
Hey Paul, it looks to be largely fixed in Ardour7 (commit b03e9b4). Still broken in Ardour6.9. I am just testing by trying to map one of the virtual dials on the virtual keyboard to a track fader. Thank you!
(0026594)
paul   
2022-10-04 00:17   
see notes.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8975 [ardour] bugs minor always 2022-10-03 12:05 2022-10-03 12:07
Reporter: wmbm Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Combining selected regions doesn't always take top regions
Description: Say I have overlapping regions (e.g. vocals) with multiple takes, and I want to combine all final "top" regions into a single one. Sometimes regions "underneath" are brought forward into the final combined region. Perhaps this is a feature, but I cannot quite understand what is going on.

Tags:
Steps To Reproduce: e.g. something like this

A - B - C ---> "combine regions" ----> A - (A) - C

where A is underlying B
Additional Information:
System Description
Attached Files:
Notes
(0026593)
wmbm   
2022-10-03 12:07   
My current solution around this is to combine selected regions 2 at a time to ensure I avoid this effect

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8903 [ardour] features minor N/A 2022-04-22 15:40 2022-10-02 21:51
Reporter: colinf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow creation of source markers in regions currently being recorded
Description: I quite often want to place markers whilst recording to note something or other - it'd be nice if those markers could be source markers for the regions currently being recorded.

Unfortunately, the regions currently being recorded don't actually exist as regions until recording is stopped, so implementing this requires special-casing source marker creation while recording to add the marker location & name to a list that can be applied to the newly-created regions after recording ends.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 0002-gtk2_ardour-set-region-marks-into-currently-recordin.patch (1,670 bytes) 2022-07-11 21:41
https://tracker.ardour.org/file_download.php?file_id=4196&type=bug
0001-libs-ardour-allow-creating-region-source-markers-whi.patch (3,301 bytes) 2022-07-11 21:41
https://tracker.ardour.org/file_download.php?file_id=4197&type=bug
Notes
(0026501)
colinf   
2022-07-11 21:41   
Patches attached.
(0026592)
colinf   
2022-10-02 21:51   
Looks like this has now been merged - thanks!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8974 [ardour] bugs major sometimes 2022-10-02 09:44 2022-10-02 09:46
Reporter: s2030081 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: high OS Version: 11  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't open Ardour 6.9 after install. "USB Audio.msi" was missing
Description: I am using Ardour 6.9 for the first time. After installing Ardour 6.9 on my windows 11 PC and trying to run it, a window pop up and said "please wait while windows configures USB Audio". Quickly, another dialog window prompted and said "the feature you are trying to use is on a network resource that is unavailable". It is asking for the location of "USB Audio.msi". I tried to google this "USB Audio.msi" but it is no where to be found.
Tags:
Steps To Reproduce: 1. install Ardour 6.9
2. Run Ardour from start menu.
Additional Information:
System Description Windows 11
Attached Files:
Notes
(0026591)
s2030081   
2022-10-02 09:46   
I then click on cancel for a few times. The dialog was gone and nothing was opened after that.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8964 [ardour] bugs minor always 2022-09-19 21:37 2022-09-26 08:38
Reporter: Mitsch Platform: Ubuntu Studio  
Assigned To: OS: Linux  
Priority: normal OS Version: 04.22  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Aux Send reaction on mouse scrolling is slow
Description: There is principally a good mechanism in ardour using the scroll wheel on faders:
* Just scroll wheel: fast
* Scroll wheel with Ctrl pressed: slow
* Scroll wheel with Ctrl+Alt pressed: very slow

There is an exception of this rule. When using the scroll wheel on auxiliary sends, it goes:
* Just scroll wheel: slow
* Scroll wheel with Ctrl pressed: very slow
* Scroll wheel with Ctrl+Alt pressed: slightly before "no move at all"

I wonder if this is intended. If not, I'd love to see this behavior changed to one I experienced on other faders.
Tags:
Steps To Reproduce: Use a channel strip with an auxiliary send, set the pointer over it and scroll.
Additional Information:
System Description
Attached Files:
Notes
(0026581)
x42   
2022-09-19 22:41   
This is mysterious. There should be no difference and scroll-wheel works exactly the same (also the small inline fader).

Do you have a mouse with a latching (clicking) scroll-wheel, or do you use a touch-pad (or middle-click scroll emulation)?
I'm asking because the inline fader reacts to both horizontal and vertical scroll, with a touch-pad, a diagonal scroll can cancel out any changes.

I cannot reproduce the issue here (nor can other users I've just asked on IRC).
(0026582)
Mitsch   
2022-09-20 21:08   
Yes, I do have a latching scroll wheel. My preferred input device is a wired "Logitech Track Man Wheel" trackball. But I have mice with which I had the same result.
To be more precise I show you the dB change I'm getting delivered.

Faders (edit window or main fader of mixer window), count from 0.0 dB:
* Scroll wheel only: -5.7 dB / (+)4.7 dB for 5 scroll events from latch to latch.
* with CTRL: -0.1 dB / (+)0.1 dB for each scroll event.
* with CTRL and Alt, you need 10 events to scroll +/-0.1dB

This is totally okay for me. A very good experience.

Auxiliary Sends, count from 0.0 dB:
* Scroll wheel only: -5.69 dB / (+)4.71 dB for 5 scroll events. (Seems to be identical with the faders behavior. My fault! I had this wrong in my mind when writing the bug report!)
* with CTRL, I need between 3 and 5 scroll events to get +/-0.01 dB (I mean 0.01, not 0.1!)
* with CTRL and Alt, you need 45 scroll events to get +/-0.01 dB

Just in case, you're still getting other results: I'm using german locales. In rare cases, some programs can't deal with this or showing strange behaviors like this… But of course, it can also relate to Ubuntu's build options…
(0026589)
Mitsch   
2022-09-26 08:38   
Can this behavior be reproduced?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8972 [ardour] bugs major always 2022-09-24 22:46 2022-09-25 00:23
Reporter: yurivict Platform: GNU  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Splash screen never disappears with the "Indexing Plugins ..." message
Description: I have several packages of LV2 plugins installed installed:
gxplugins-lv2-0.9 Set of LV2 plugins from the guitarix project
infamous-plugins-lv2-0.3.0.7 LV2 plugins for various sound effects
invada-studio-plugins-lv2-1.2.0 Set of LV2 audio effect plugins, ported from VST
lv2-1.18.4 Open standard for audio plugins (successor to LADSPA)
x42-plugins-lv2-20220714 Collection of LV2 plugins (submodules)

The Ardour splash screen never disappears.



clang-14
FreeBSD 13.1
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026586)
x42   
2022-09-24 23:12   
Which desktop environment do you use?

Some (like KDE) do not follow freedesktop.org specs, in Ardour you can work around this via Preferences > Appearance > Quirks > Show/hide splash screen instead of setting z-axis order.

You can launch Ardour with --no-splash option as well.
(0026587)
x42   
2022-09-24 23:13   
Then again this may be a different issue, related to LV2 scanning (not a splash screen issue after all. Does `lv2ls` work and list all plugins?
(0026588)
yurivict   
2022-09-25 00:23   
I use xfce4 DE.

lv2ls lists all LV2 plugins instantly.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8971 [ardour] bugs major always 2022-09-23 11:16 2022-09-24 20:29
Reporter: thebutant Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: Mixbus 8.x  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Opaque/transparent audio regions destroys other regions when placed on top
Description: When placing an opaque region on top of some other audio region, anything that's under the opaque region is destroyed.
Tags:
Steps To Reproduce: Have 2 audio regions.
Make one of them opaque / transparent.
Place the opaque one on top of the other region.
In my case, this destroys whatever's under the opaque region.
Additional Information:
System Description
Attached Files:
Notes
(0026583)
paul   
2022-09-23 20:55   
What does "destroy" actually mean here?
(0026584)
thebutant   
2022-09-24 05:19   
In my case, placing the opaque region over another region makes this other region disappear completely in the range of the opaque region.
That's what "destroys" means.

I cannot stack regions, because the one underneath is completely eaten og digested by the opaque region.
(0026585)
paul   
2022-09-24 20:29   
This was a bug introduced during recent-ish development. Thanks for noticing. It has been fixed in the Ardour codebase, and the fix will appear in a future Mixbus minor release.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8965 [ardour] features minor always 2022-09-19 22:13 2022-09-19 22:13
Reporter: Mitsch Platform: Ubuntu Studio  
Assigned To: OS: Linux  
Priority: normal OS Version: 04.22  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: automation mode "touch" blocks direct value editing and editing via scrolling
Description: I'd prefer to directly write values with the keyboard or using the scroll wheel to edit automation, but unfortunately, in the edit window both seem to be blocked in "touch" mode. You can only edit if you click and hold the fader and move it.

This could be intended, but I can't see the point.
Tags:
Steps To Reproduce: In the edit window, start f.e. a "Trim"-automation with "write" mode in a channel strip. Stop transport, so automation automatically switches to "touch". Go ahead with transport and stop it again, after some time. Double click on the fader, it changes to an input dialog where you can change the value to a desired one and hit enter: Nothing changes. It should have switched to the desired value and set a new automation point.

In the edit window, start f.e. a "Trim"-automation with "write" mode in a channel strip. Stop transport, so automation automatically switches to "touch". Go ahead with transport and stop it again, after some time. Hold shift and use the scroll wheel over the fader that should be changed: Nothing happens. But it should like using the fader in "manual" mode and set a new automation point.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8962 [ardour] bugs crash always 2022-09-19 04:23 2022-09-19 04:23
Reporter: Revelations11 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: high OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Problema Rejilla y plugins
Description: Saludos equipo de Ardour.

Mi problema es que cuando intento configurar la rejilla a 1/16 no realiza nada, solamente funciona hasta 1/8 note, pero de 1/16 en adelante no sirve, tampoco veo para configurarla a 1/2 note, por otro lado, inserto un plugin llamado Total EQ de Hornet Plugins y esta en formato VST 3 y no funciona, no hace nada, instale su VST 2 y este sale como error, abro otro DAW y funciona el plugin, pero en Ardour no funciona, no hace nada, espero me puedan brindar y dar una solucion a estos problemas. Agradezco de antemano la pronta respuesta y solucion muchas gracias.
Tags: grid, plugin
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8961 [ardour] bugs major always 2022-09-14 00:19 2022-09-14 01:25
Reporter: graymon Platform: Microsoft  
Assigned To: x42 OS: Windows  
Priority: normal OS Version: 10  
Status: resolved Product Version: 6.9  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ACE Fluid Synth Cannot Play SF2 Soundfonts in Windows
Description: ACE Fluid Synth Cannot Play SF2 Soundfonts in Windows.

Tags:
Steps To Reproduce: Create Midi Track using ACE Fluid Synth
Apply sf2 sound font by browsing file system
Attempt to play virtual keyboard notes.

Successful:
Install sforzando from https://www.plogue.com/products/sforzando.html
Reload plugins
Create Midi Track using sforzando
Apply sf2 sound font by browsing file system
Attempt to play virtual keyboard works as expected.
Additional Information: Downloaded Bass soundfonts from here:
https://www.producerfeed.com/files/soundfonts/21-bass-sf.rar


The project was created in Linux and the filesystem copies over to Windows, but it failed when using a brand new session.
System Description
Attached Files:
Notes
(0026578)
x42   
2022-09-14 00:39   
Which .sf2 file are you using?

After unpacking the rar there are 22 files. I have tested`Bass/1276-FReTLeZzz.sf2` `Bass/336-ACBass.sf2` and `Bass/336-Squierbass.sf2` and they work just fine with a quick test.
(0026579)
graymon   
2022-09-14 01:21   
I turned off Ardour - started another new project and all the sound fonts are working now. I guess that's good news, but I feel stupid. I even loaded up the apps that were started in Linux, and now adding a new midi track with the Fluid Synth works also. I can no longer duplicate the problem. Please close this one out. If it happens again, I'll try to figure out what is different in my setup. Thanks for checking this for me, and sorry for the misreporting.
(0026580)
x42   
2022-09-14 01:25   
No problem. I thought perhaps you have loaded the .rar file directly.. but if you can reproduce it again, please let us know. perhaps there's a detail we have missed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8926 [ardour] features feature always 2022-06-15 18:48 2022-09-13 17:25
Reporter: mrmrrs Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI learn without middle mouse button (using a trackball)
Description: Hello. :)

Is there a way to assign a different mouse button for mapping a parameter to a MIDI controller?

As Ardour awaits a middle mouse click on a parameter, to map it to a MIDI controller and I use a trackball ("Kensington Orbit"), that has no middle mouse button, it would absolutely make sense to be able to specify other buttons for MIDI mapping. I know, that many people use trackballs in studios, as they are more practical in terms of space requirement on a mixing desk. However, the Kensington Orbit has buttons for left click, right click and a scroll wheel (non-clickable). The ball is also non-clickable.

The most practical way would be a right click (on any parameter), while pressing the left "ALT" key on the keyboard, as this combination has no particular function in this context.

Have I overlooked an option or is this really not a feature? If the latter is true, please, add this. :))
I don't want to produce e-waste, by just buying a three-button mouse. As the trackball is fully working.
It is also more ergonomical and less likely to cause carpal tunnel syndrome.

Thank you in advance. Namaste.
Best regards,
Philip
Tags: Accessibility, automation, control, feature request, feature-request midi, features, GUI, hotkey, improvements
Steps To Reproduce: Using a two-button mouse or trackball and trying to use the third button. :D
Additional Information:
System Description
Attached Files:
Notes
(0026482)
x42   
2022-06-15 19:26   
This is currently not configurable (but may become so in future versions).

On Linux/X11 a common solution to use "Evdev Middle Button Emulation" press left+right mouse button emulates a middle-mouse button press.
(0026577)
mrmrrs   
2022-09-13 17:21   
Thanks! I am absolutely looking forward to it. :)

In the meanwhile I have successfully set up the emulation.
Somehow it seems to work everywhere else but within Ardour.

For example:
Firefox acknowledges such a button press and reacts accordingly by opening an URL as a new tab or closing a tab etc..
Nautilus also reacts, as expected, by opening a folder as a new tab.
Ardour either does nothing or only acknowledges one of the two buttons.

And I have tried to exactly time the simulatneous press of these buttons.
But as all other applications correctly recognize the emulation as a third button press,
I presume Ardour ignores the time window set for the press or the whole emulation itself.

Is there a need to modify the file "/home/"username"/.config/ardour6/ui_scripts"?
And if so, could you please share a piece of code to be put in there to enable Ardour to recognize the evdev emulation?

If you need some log file or screenshot in this regard, please, let me know.

Thanks in advance. Namaste.

Best regards,
Philip

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8777 [ardour] features minor have not tried 2021-07-18 15:43 2022-09-12 12:51
Reporter: unfa Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: LUFS normalisation for audio regions
Description: Right now the audio region normalization can be done based on Peak and Peak RMS measurements.
What is missing is LUFS Integrated.

The only sensible way to perform LUFS normalization at this moment is to perform loudness analysis, write down the LUFS value, do math in your head and apply gain manually.
Since the Analysis dialog is blocking access to the rest of Ardour, this is extra tedious to do, especially if you need to normalize multiple regions (like for example: mastering an album and doing quick loudness normalization after importing your mixes to get in the ballpark before doing manual loudness matching.

Another way would be to import regions, then mark them all with ranges on the timeline and export them using loudness normalization, then import them again.
As you can imagine, neither of these solutions is optimal.

Since LUFS normalization is already present in the export process in Ardour, I hope it shouldn't be too hard to add in here as well.
What do you think?
Tags: audio, loudness, LUFS, normalisation
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026057)
x42   
2021-07-18 16:12   
(Last edited: 2021-07-18 16:12)
When is this useful?

Can you think of any workflow that should encourage normalizing to perceived loudness when you later mix or master the the result, which significantly changes the perceived loudness?

(0026058)
unfa   
2021-07-18 18:32   
As I've written above - a rough level matching for album mastering is the main use-case for me but I believe I also needed this when working with sound effects, can't remember what it was though. Since EBU-R128 is the best perceived loudness model we have, it makes sense for me to use that instead of peak RMS which is in my mind an inferior solution for the same problem (unlike peak or true peak - these ensure no clipping).
(0026063)
x42   
2021-07-20 02:57   
implemented in Ardour 6.8-186-gf457225d08 -- feedback is welcome.
(0026064)
unfa   
2021-07-20 07:59   
Awesome, thank you! I will test it and give feedback.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5579 [ardour] bugs text always 2013-07-12 05:31 2022-09-11 00:03
Reporter: dbolton Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 3.0  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Disable "Opaque" option in MIDI regions context menu
Description: Currently all MIDI regions act "transparently" when stacked/overlaid. However context menu shows a checkmark next to "[region name] > Edit > Opaque".

Expected behavior: The "Opaque" menu option should not have a checkmark (since the region acts transparently). Additionally the menu item should be grayed out to indicate that Ardour doesn't support opaque MIDI regions.

Discussion: According to las on IRC, opaque MIDI regions would "present some very, very difficult logic to implement. We would have to synthesize note on and note off events". Since the feature is unlikely to be implemented, the UI should to be updated to reflect this fact.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026575)
x42   
2022-09-11 00:03   
9 years later.. and this has just been implemented.

I'm closing this, please provide feedback at 0005100

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8947 [ardour] other minor always 2022-07-26 14:46 2022-09-05 10:30
Reporter: johne53 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: File size creepage even though nothing's changed
Description: I've discovered this in Mixbus though I'm not sure if it's intentional or a bug... basically, each session file contains a GUIObjectState section looking like this:-

      <GUIObjectState>
        <Object id="rtav 7" height="68" visible="1"/>
        <Object id="automation 68" height="68" visible="0"/>
        <Object id="automation 70" height="68" visible="0"/>
        <Object id="automation 7 12/0/0" height="68" visible="0"/>
        <Object id="automation 83" height="68" visible="0"/>
        <Object id="automation 87" height="68" visible="0"/>
        <Object id="rtav 19" height="68" visible="1"/>
        <Object id="automation 106" height="68" visible="0"/>
        <Object id="automation 108" height="68" visible="0"/>
        <Object id="automation 19 12/0/0" height="68" visible="0"/>
        <Object id="automation 121" height="68" visible="0"/>
        <Object id="automation 125" height="68" visible="0"/>
        <Object id="strip 7" visible="1" strip-width="Wide">
          <Object id="processor 94"/>
        </Object>
        <Object id="strip 19" visible="1">
          <Object id="processor 132"/>
        </Object>

       // rest of the object

        <Object id="automation 10108" height="98" visible="0"/>
        <Object id="automation 10110" height="98" visible="0"/>
      </GUIObjectState>

Near the 'rtav' objects, each number after the word 'automation' corresponds to an object id somewhere else in the file (typically an automation control / pan control / trim control or whatever). But towards the end of GUIObjectState there's usually a long list of orphaned objects whose 'automation' value doesn't correspond to any value elsewhere in the file. And each time the user presses 'Session->Save' another of these objects gets created and stored. So the file size creeps gradually upwards, even if nothing changed between this save and the last save. Is this behaviour intentional or a bug?
Tags:
Steps To Reproduce: Simply press Session->save with an existing session (without changing anything else)
Additional Information:  It seems to be present in files having ver 6000 or ver 7000 but I don't see it in earlier files.
System Description
Attached Files:
Notes
(0026567)
johne53   
2022-08-16 07:55   
This is still present here in both Ardour and Mixbus - though in Ardour's case it doesn't seem to affect every session. Maybe someone could try it on Linux or Mac?
(0026572)
johne53   
2022-09-05 10:30   
I'm still not sure if I've found a bug or if this gradual 'creepage' is intentional... but FWIW I booted into Linux this morning and I'm seeing exactly the same effect here in Linux.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8958 [ardour] bugs minor have not tried 2022-09-01 18:15 2022-09-01 18:15
Reporter: danx64 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Plugins LV2 failed
Description: Plugins LV2 fallan al ser cargados y no se muestra su GUI respectivamente generan clicks en el audio
Tags: Ardour, audio, GUI, PLugins
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8957 [ardour] bugs minor sometimes 2022-08-29 08:57 2022-08-30 18:50
Reporter: raoul86 Platform: Arch  
Assigned To: OS: Linux  
Priority: low OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Problem with Ardour plugin GUIs
Description: problem with some pluggins (drumgizmo, setbfree, x42eq...) impossible to edit with double click...
it seem to be this issue which work :

"I found suil 0.10.16-2 has a different issue where plugins can only open once in Ardour, best solution is to downgrade back to suil 0.10.12-1.

sudo pacman -U https://archive.archlinux.org/packages/s/suil/suil-0.10.12-2-x86_64.pkg.tar.zst"
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8956 [ardour] bugs major always 2022-08-27 11:15 2022-08-27 20:57
Reporter: lucienkacrofts Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: urgent OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Scrubber audittion function not working
Description: Selected the quick edit Scrubber option for listening to a section of a waveform (cursor changes to a small speaker symbol) then hold left mouse button and scan back and forward over wave form. This should produce audio at whatever speed / direction you move the mouse. On left click the speaker symbol disappears, the play head marker jumps to the position of the cursor but does not move, the counter does not move and no audio is produced. After many attempts i got an error message saying 'memory pool full recompile with larger amounts'. This audition function worked in Ardour 5.12 from the ubuntu 20.04 repo but no longer works in Ardour 6 +.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026571)
lucienkacrofts   
2022-08-27 20:57   
Just installed Ardour 6.9 on Windows 10 64bit and the same problem as with the Linux version.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8907 [ardour] bugs major always 2022-04-24 02:34 2022-08-25 19:50
Reporter: johnthebard Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Click in audio at 41 bars audible with various distortion plugins.
Description: There's a click at 41 bars which is inaudible without distortion but consistent with distortion. The click stays regardless of where the audio lines up with 41 bars.
Tags:
Steps To Reproduce: Enable either ZynDistortion or GxAmplifier-Stereo-X one at a time, and play the audio so that the playhead passes 41 bars.

Moving the audio around has no effect on the click happening at 41 bars.
Additional Information: Project file was sent via email to paul
System Description
Attached Files:
Notes
(0026557)
paul   
2022-08-12 13:29   
I think I fixed this? Do you recall?
(0026570)
johnthebard   
2022-08-25 19:50   
Yes, it turns out it was an issue with plugins and I just so happened to use several plugins in a row to test that have that issue. The 41 bar location was where a loop marker was which was (if I remember correctly) causing some kind of buffer reset the plugins responded poorly to.

We talked about it in IRC and I forgot to mention here/close this when we figured it out.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8955 [ardour] bugs block always 2022-08-23 12:48 2022-08-23 13:54
Reporter: Kilgharrah Platform: Microsoft  
Assigned To: OS: Windows  
Priority: low OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST Gui not opening (6.9 demo)
Description: After adding a Vst3 instrument(produced with st4 and synister) to a project, the gui does not open.
Tags: GUI, VST
Steps To Reproduce: Attempting to load a vst plugin in the demo 6.9 ardour(windows 10) with
"edit->references->plugins->Automatically open the plugin gui when adding a new plugin" enabled.
and "edit->preferences->plugins->Don't automatically open the plugin GUI when the plugin has an inline display mode" DISABLED.
Additional Information: Trying to demo ardour to determing if its right for me. since my vsts arent configurable(which they have to be) i cannot do that, and i dont event think the retail version of ardour will support it.

I want to enjoy and use ardour, i really do.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8848 [ardour] features minor N/A 2022-01-02 20:02 2022-08-18 15:28
Reporter: colinf Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Improve MIDI region unlinking behaviour
Description: Presently, there's no way to unlink multiple linked regions but have them remain linked to each other.

It might be useful in some cases, when unlinking multiple selected regions all at once, to preserve the links within the region selection rather than creating a new source for every region.

E.g.: if we have a set of linked MIDI regions A, A, A, A, it could be useful to be able to select (say) the last two and unlink them, and end up with A, A, A', A', where the regions A' are still linked.
Tags:
Steps To Reproduce:  
Additional Information:
System Description
Attached Files: 0001-gtk2_ardour-implement-Unlink-from-unselected-for-MID.patch (10,231 bytes) 2022-07-11 21:36
https://tracker.ardour.org/file_download.php?file_id=4195&type=bug
Notes
(0026500)
colinf   
2022-07-11 21:36   
Path attached: plenty of room for improvement, but it Works for Me.
(0026569)
paul   
2022-08-18 15:28   
applied and pushed, thanks!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8953 [ardour] bugs major random 2022-08-12 14:24 2022-08-15 21:50
Reporter: FabienB Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour is randomly crashing with Jack server (segmentation fault)
Description: When used with Jack server, Ardour is randomly crashing whatever the complexity of the current session (can happen with a simple audio track). It can happen a few seconds after the opening of a session or half an hour later during playback without a particular interaction. Run in a terminal, I have a "Segmentation fault" output for each crash. Here is a gdb backtrace (a part of, I can add the full BT if needed):

--Type <RET> for more, q to quit, c to continue without paging--

Thread 26 "audioengine" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcc19f700 (LWP 3050)]
0x00007ffff7454e1b in ARDOUR::PortManager::run_input_meters(unsigned int, long)
    () from /opt/Ardour-6.9.0/lib/libardour.so.3
(gdb) thread apply all bt

[…]

Thread 26 (Thread 0x7fffcc19f700 (LWP 3050)):
#0 0x00007ffff7454e1b in ARDOUR::PortManager::run_input_meters(unsigned int, long) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000001 0x00007ffff745762b in ARDOUR::PortManager::cycle_start(unsigned int, ARDOUR::Session*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
#2 0x00007ffff7057722 in ARDOUR::AudioEngine::process_callback(unsigned int) () from /opt/Ardour-6.9.0/lib/libardour.so.3
#3 0x00007fffcf4592fb in ARDOUR::JACKAudioBackend::process_thread() () from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
0000004 0x00007fffd80491f2 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000005 0x00007fffd8062280 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#6 0x00007ffff0892609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007fffee48b133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[…]

Tested on Ubuntu 20.04.4 LTS and Ardour 6.9.0 (Official build), Jack is provided by KXStudio repository (jackd version 1.9.12).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026561)
x42   
2022-08-12 14:42   
This could have a number of causes. The backtrace is from an optimized version of Ardour (without line-numbers) so we cannot tell. A few that come to mind:

* If you have any MIDI devices and hotplug them after starting Ardour, this is a known issue and fixed for upcoming Ardour 7.0. Meanwhile connect them before starting Ardour
* you have manually disabled `work-around-jack-no-copy-optimization` in the config
* an issue with jack 1.9.12 which is from 2017 is rather old at this point and has some known bugs that can also cause this

PS. Unless you have a specific need for JACK, prefer Ardour's ALSA backend
(0026566)
FabienB   
2022-08-15 21:50   
Thank you for your answers. I have checked the two first points and still have the problem. I do use ALSA backend for "in-the-box" projects but need sometimes Jack for bridging VCV Rack for example (VCV VST plugin does not work yet in Ardour). I will try with Ardour 7 and an updated Jack server.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8939 [ardour] bugs major always 2022-07-09 20:27 2022-08-12 19:14
Reporter: Nonlinear Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Some VST3 plugins produce no output - ALL VST3 plugins show I/O error in plugin manager
Description: Every VST3 plugin I have checked in Ardour's plugin manager shows the following errors:

[Info]: VST3: \ error getting busInfo for bus: 0 rv: 0, got type: kMain
[Info]: VST3: \ error getting busInfo for bus: 0 rv: 0, got type: kMain

Some VST3 plugins work properly while others receive input but produce no output back to the DAW - like they are perpetually bypassed. They LOOK like they are working (their meters move, etc.) but the processed sound is not returned to the DAW.

VST2 versions of the same plugins work properly.
Tags:
Steps To Reproduce: 0000001) Scan plugin in plugin manager and view report. (All VST3 plugins report I/O bus errors.)
#2) Insert VST3 plugin in any track or bus and listen for output change when turning knobs, etc. (Some plugins work, some don't.)
Additional Information:
System Description
Attached Files: Ardour VST3 errors.png (165,978 bytes) 2022-08-12 19:14
https://tracker.ardour.org/file_download.php?file_id=4212&type=bug
png
Notes
(0026499)
Nonlinear   
2022-07-09 20:34   
There appears to be no way to edit my post so I will add info here. This issue is with regard to 3rd party VST3 plugins - of all brands. Some work some don't but ALL report the I/O error. The reason I marked this "major" is because a user can inadvertently think the plugin is working when it is in fact not affecting the audio at all.
(0026559)
x42   
2022-08-12 13:45   
At this point it time Ardour's VST3 host supports only "one main bus, and one aux-bus. Also an optional aux-bus by itself is currently N/A.
(0026560)
x42   
2022-08-12 13:47   
Which plugin(s) are affected by this?
(0026563)
Nonlinear   
2022-08-12 17:50   
>>At this point it time Ardour's VST3 host supports only "one main bus, and one aux-bus. Also an optional aux-bus by itself is currently N/A
The error I am reporting here is shown for all VST3 plugins including 2in/2out plugins. Every VST3 plugin I have checked in plugin scan shows this error "[Info]: VST3: \ error getting busInfo for bus: 0 rv: 0, got type: kMain". Some VST3 plugins produce audio output while others simply pass the signal thru unaffected.

>>Which plugin(s) are affected by this?
It's not specific to any particular plugin brand or plugin title - and those plugins that don't work in Ardour work fine in all other DAWs. Therefore, there appears to be a VST3 interface issue in Ardour.

If others users have noticed this issue they probably blame it on the plugin(s) and move along. Please do some checking on your own and don't take my word for it!
(0026564)
x42   
2022-08-12 17:58   
Yes, as I said above it is not a plugin issue, but missing support for specific VST3 configurations in Ardour

I am curious if you have a VST3 that has more than one output bus or announces an output bus as main out, and hence does not currently work correctly in Ardour.
So far the only one I know is Addictive Drums in multi-out mode.
(0026565)
Nonlinear   
2022-08-12 19:14   
To be clear, there are two problems here:

1) EVERY VST3 plugin shows up in the Plugin Manager as having I/O bus errors - including major brands like Fabfilter, Izotope and Waves. Please see attached screenshots. This is not due to a "specific VST3 configuration".

2) Some plugins, even those with only stereo I/O (no aux buses) - do not process the audio and pass it through unaffected. AFAIK, all plugins announce their main I/O bus as "Main". That is the Steinberg VST3 default labeling for main pins regardless of any aux pins. I cannot explain why some plugins work and others don't.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8855 [ardour] bugs minor always 2022-01-08 20:41 2022-08-12 13:44
Reporter: magnetophon Platform: Linux  
Assigned To: OS: NixOS  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: No audio inputs for Surge VST3
Description: The VST3 version of both 1.9 and XT don't have audio inputs when used in Ardour.
According to baconpaul it's not a Surge issu but an ardour one: ihttps://github.com/surge-synthesizer/surge/issues/5743#issuecomment-1008144854
The LV2 and standalone work fine.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026292)
x42   
2022-01-08 21:13   
Yes, it's not just surge, but applies to other VST3s as well.
At this point it time Ardour's VST3 host supports only "one main bus, and one aux-bus. Also an optional aux-bus by itself is currently N/A.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8920 [ardour] features minor have not tried 2022-06-01 11:34 2022-08-12 13:44
Reporter: johne53 Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST plugin issue with multi-output plugins
Description: Sorry if I'm duplicating an entry here. AFAICT it isn't possible to search the entries using text. You need to search for a specific bug ID number (is that just me misunderstanding something..?) Anyway...

Over on the Mixbus forum there've been reports about VST3 plugins not working if they offer multiple outputs (more than 2 presumably...) The older VST2 plugins support multiple outputs okay apparently.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026478)
x42   
2022-06-02 01:15   
Probably not a duplicate, but currently expected behavior, which is also documented in the manual.

Ardour only supports one optional bus for VST3 plugins (usually side-chain input), and does not support variable I/o for VST3 plugins. Addressing this is on the long-term ToDo list.

(VST2 does not support variable I/O, an instrument with multi-channel output will always have all those outputs)
(0026479)
x42   
2022-06-02 01:18   
This is not a Windows specific issue, but Ardour/VST3 related.

Conceptually VST3 bussing is at odds with how Ardour internally handles variable-i/o (which is heavily inspired by audio unit). Solving this will require a major internal overhaul.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8951 [ardour] bugs major always 2022-08-10 13:04 2022-08-11 21:29
Reporter: thebutant Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: high OS Version: (any)  
Status: acknowledged Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unable to copy and paste modwheel automation
Description: When editing modwheel automation, I'm mostly unable to copy and edit nodes from one place to another.
Sometimes I can actually copy and paste, but then they appear in random places and not where I asked to.
Tags:
Steps To Reproduce: Make a midi region with modwheel automation.
Try to copy and paste automation nodes. See it the appear where you'd think they should, or if they appear somewhere at all.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8022 [ardour] features minor always 2020-04-19 10:16 2022-08-11 20:00
Reporter: sonnie Platform: Some Other Linux  
Assigned To: paul OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: feedback Product Version: 6.0-pre1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tint background color of Mixer- and Editor-Channel (Header)
Description: I love to have a fast overview. For years other DAWs can optinally tint background color of the mixer strips for faster overview. I'd love to see this in Ardour.
Tags: color, mixer
Steps To Reproduce: -
Additional Information: -
System Description
Attached Files: ardour editor.jpg (89,762 bytes) 2020-04-21 07:39
https://tracker.ardour.org/file_download.php?file_id=3597&type=bug
jpg

reaper editor mixer.jpg (212,734 bytes) 2020-04-21 07:39
https://tracker.ardour.org/file_download.php?file_id=3598&type=bug
jpg

ardour mixer.jpg (266,377 bytes) 2020-04-21 07:39
https://tracker.ardour.org/file_download.php?file_id=3599&type=bug
ardour mixer track color.jpg (538,888 bytes) 2020-04-22 17:11
https://tracker.ardour.org/file_download.php?file_id=3605&type=bug
ardour mixer track color-2.jpg (538,888 bytes) 2020-04-22 17:11
https://tracker.ardour.org/file_download.php?file_id=3606&type=bug
ProotoolsMixer.jpg (322,299 bytes) 2020-04-22 17:45
https://tracker.ardour.org/file_download.php?file_id=3607&type=bug
ardour-mixer-colored.png (222,630 bytes) 2022-07-19 18:11
https://tracker.ardour.org/file_download.php?file_id=4200&type=bug
png

colored_mixer.png (115,964 bytes) 2022-08-10 01:27
https://tracker.ardour.org/file_download.php?file_id=4205&type=bug
png

aug10.png (167,158 bytes) 2022-08-11 04:19
https://tracker.ardour.org/file_download.php?file_id=4206&type=bug
png

grafik.png (26,633 bytes) 2022-08-11 05:56
https://tracker.ardour.org/file_download.php?file_id=4207&type=bug
png

aug10-2.png (173,815 bytes) 2022-08-11 06:28
https://tracker.ardour.org/file_download.php?file_id=4208&type=bug
png

aug-11-m.png (167,571 bytes) 2022-08-11 14:47
https://tracker.ardour.org/file_download.php?file_id=4209&type=bug
png

aug-11-e.png (163,956 bytes) 2022-08-11 14:47
https://tracker.ardour.org/file_download.php?file_id=4210&type=bug
png

grafik-2.png (14,374 bytes) 2022-08-11 19:49
https://tracker.ardour.org/file_download.php?file_id=4211&type=bug
png
Notes
(0021397)
paul   
2020-04-19 13:47   
Please explain more clearly what you mean by this. Do you mean "use the track color as the background of the mixer strip for that track" ?
(0023838)
sonnie   
2020-04-21 07:16   
use the track color as the background of the mixer strip for that track. I use pretty big screens and its hard go get an overview without the "coloured backgrounds" in mixer (or editor in track headers - where solo/mute and volume is located) just with the group bars above.

Maybe its more reasonable with some pics.
(0023848)
ahellquist   
2020-04-21 23:34   
This is really a much needed feature IMHO. I tend to scroll in larger project while trying to read the labels of the tracks.. If there are 19 vocal tracks in a row it is hard to find what I am looking for. It really doesn't help to use a small screen for that matter.. Having Colors like above would make things quite convenient.

Or in a shorter form:
+1
(0023862)
paul   
2020-04-22 16:45   
@sonnie: those are not track colors at all, but group colors.
(0023863)
sonnie   
2020-04-22 17:11   
@paul: Yes. Is there a different way to color the tracks (not the audio/MIDI items). These are way better for my eyes for a fast overview than these small track color bubbles. (see pic attached)
I run sessions with 50-100 tracks+ and its very, very hard to see fast, what track is what type.
(0023866)
ahellquist   
2020-04-22 17:45   
Plain old Protools has this appearance which is quite handy if you are looking for one of the two dark green tracks and are in a hurry.
(0023867)
itsmonika   
2020-04-22 18:22   
Ok this make some sence
(0023868)
paul   
2020-04-22 19:48   
I should be clear here: I welcome an option to color mixer strip backgrounds.

But there's a lot of language appearing here about "track colors", whereas what is shown in the screenshots from other DAWs are not individual track colors, but group colors.
(0023871)
sonnie   
2020-04-23 07:22   
"whereas what is shown in the screenshots from other DAWs are not individual track colors, but group colors. "

No, in Reaper and Pro Tools it's called "Track Colors". But nevermind, we now know, what I initially meant. Thanks for your help. :)
(0026176)
sonnie   
2021-10-06 09:18   
Will this be a feature of Ardour 7? :)
(0026517)
tanjeffmoos   
2022-07-19 18:11   
I also vote for this feature.

In Ardour, each track in the mixer has a little color bubble on the top. It would be great if that color was more appearent on the whole mixer strip. I gimped an example of how it might look like :)

I'm well aware that implementing this is harder than using Gimp.
(0026539)
paul   
2022-08-09 22:20   
Now in git master via commit bfedf7168e
(0026543)
x42   
2022-08-10 01:27   
I do like at @tanjeffmoos mockup, but the current state of coloring the whole strip incl faceplace of the fader and meter is not helpful and introduces visual clutter in my opinion.
Also the master-bus be exempt but VCAs should also have an outline (like tracks). The faders should not default to blue but the fader/meter area get colored depending on track type (again).

For those who cannot compile from git, the current state looks like :
(0026544)
tanjeffmoos   
2022-08-10 06:00   
I agree with x42 that the current version looks distracting, because there is too much color in the fader/meter area. Or maybe it is just too much contrast between the bright background color and the dark fader/meter.

Coloring the fader and meter (as x42 proposed) would reduce contrast. But I think that recoloring the meter is non-trivial, because it uses multiple colors (white and red ticks, green/yellow/red bars) which need to work with any background color the user chooses. Also, there are other meters with other tick colors (e.g. K20).

I suppose that you mainly colored the background of the strip. Are fader and meter grouped using a box widget? If so, it might help to change the background of that box back to gray (this would look more like my mockup). It might be simpler to implement.
(0026545)
x42   
2022-08-10 12:15   
> Coloring the fader and meter (as x42 proposed) would reduce contrast.

I proposed to revert that that area to how it was before. The box with the fader and meter should just be boring gray (for busses), boring blue-gray (for Audio tracks), and green-gray (for MIDI tracks), like it is when not using track-color. Like in your screenshot above (https://tracker.ardour.org/view.php?id=8022#c26517)

More nitpicking: Currently the brightness of the track color is increased. IMHO, that is also not the correct approach. The color should be used as is.
If this is an issue with the "flat & boxy" theme (the track header button is not distinguishable), increasing saturation would be my choice. Alternatively make it darker with a dark theme and brighter with a bright theme.

--

PS. Harrison Mixbus has an entirely different approach to this: the mixer-strip itself is not colored, the background remains unchanged, only the Fader itself is colored.
(0026546)
paul   
2022-08-11 04:19   
new approach underway. feedback welcomed.
(0026547)
tanjeffmoos   
2022-08-11 05:56   
I like the approach, it looks very clean.

But there is a corner case: It a fader is all the way down, almost no color will be visible. My suggestions are:
- Colorize the "comment" button. Its color does not indicate any status, hence a new color won't do any harm.
- Add a colored horizontal ruler below the fader/meter and above the "group" button, just do indicate the strips color.
- Colorize the fader background with a darker (or brighter?) version of the strip color.

Here are two examples of how a ruler could look like.
(0026548)
paul   
2022-08-11 06:27   
the name button at the *top* is already colored
(0026549)
paul   
2022-08-11 06:28   
here's a corresponding view of the editor view
(0026550)
paul   
2022-08-11 14:47   
OK, here are two screenshots of the current state of play (similar to above but master bus is uncolored, and fader bgs are correct)

Again, any feedback is welcome
(0026551)
tanjeffmoos   
2022-08-11 18:53   
> the name button at the *top* is already colored
Yes, but it is far away from the bottom :-)

The current approach looks professional. Even the 0,0-markers are colored, I love such details!
(0026552)
paul   
2022-08-11 19:26   
"0,0-markers" ??
(0026554)
tanjeffmoos   
2022-08-11 19:49   
This line. How it is named correctly?
(0026555)
x42   
2022-08-11 20:00   
I think "unity position marker" -- although in different contexts (faders for plugin automation) it's the "default value marker"

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8950 [ardour] bugs major always 2022-08-10 12:52 2022-08-11 19:39
Reporter: thebutant Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: Mixbus 8.x  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Modwheel nodes become unavailable/difficult to edit after splitting a midi region.
Description: When recording a miditrack with modwheel, it's useful to edit the modwheel automation afterwards (if something was a bit off).
In Mixbus 8.1 this is still possible, but not after dividing/splitting the recorded miditrack.
I can still edit the modwheel nodes as usual in the first, original midi region, but not in the new part, the one that was split off. In this new region I cannot select more nodes than one at the time (or if I press ctrl, I can pick one and one and one and one).
If I undo and the region is one whole again, I can select several modwheel nodes and edit them as I wish, but as soon as the region is split, this new region (the second one) will not let me select more than one modwheel node at the time.
Tags:
Steps To Reproduce: Record a midi region with modwheel automation.
Divide the midi region.
Try to select several automation nodes in the second region (in edit mode).
At least for me I can not drag my mouse and select them anymore, I have to pick one at the time (but I can select several if I press ctrl and pick one at the time, however this is rather time consuming).
Undo, so the region becomes one whole again, and you can drag your mouse and select multiple nodes.
Additional Information:
System Description
Attached Files:
Notes
(0026553)
paul   
2022-08-11 19:39   
This is now fixed in git master and will be in the 7.0 release of Ardour. It may or may not be in the next release of Mixbus, due to release schedules.

BTW, the bug applied to any MIDI automation at all, not just modwheel or bender.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8232 [ardour] features minor have not tried 2020-06-14 12:42 2022-08-09 23:56
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: We really need a vertical scroll bar
Description: If you'd rather listen to me talking about this and show you what I mean, here's a quickly made video:
https://youtu.be/8Lmq9TRblXw

If you prefer to read, here goes:

My Ardour sessions tend to have a lot of tracks.

I scroll the sessios a lot trying to find the stuff I need.

And I realized there's a very simple, but missing component in Ardour.

A scroll bar.

Why?

A scroll bar clearly shows the user how much stuff there is , and what portion of the stuff they are currently looking at.
It may also allow to quickly jump to a different place, if the user knows what he's looking for.

I can't tell you how much time I'm wasting simply scrolling up and down trying to find that one track. The lack of a scroll bar makes it very hard for me to create a mental image of the vertical space in my session. And even if I had one, I can't immediately jump to that part.

A very basic scroll bar (like the horizontal one in the Mixer view) would do, but Ardour could go a step further and make the scroll bar actually represent the session contents to make the navigation easier.

What if the scroll bar shown colored horizontal bars representing the tracks buses and VCAs? What about vertical lines showing groups?
This could make the vertical navigation of the session so much better. it is terribly inefficient right now.

Unless there's some secret techniques I haven't discovered yet.

Yes, there's the Tracks & Busses side bar. I probably should start using that more. The problem is - for this to be useful I need to give it at least 200 pixels in width, which takes away from the precious editor space. And if I give it less space it's gonna be very easy to misclick and disable a track. It's a sharp tool, so I need to be careful not to cut myself.

What I'm thinking of would not need more than 32 pixels of width, and it would be used *only* to navigate - no data entry allowed (so you can't screw anything up).

The horizontal session navigation is very good - the "Overview" allows me to clearly see what is there, and what part of it I am looking at as well as allowing me to jump places quickly.
But there is no such thing for vertical navigation.

I think once in the past the "summary" on the bottom served for vertical navigation as well, but not any more. Even when it did - the amount of pixels vertically was just not enough to make it useful. A vertical scroll bar needs to be tall.

What do you think?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Mockup.png (159,460 bytes) 2020-07-03 10:04
https://tracker.ardour.org/file_download.php?file_id=3750&type=bug
png

MeterBridge.png (32,909 bytes) 2020-07-03 10:56
https://tracker.ardour.org/file_download.php?file_id=3752&type=bug
png

Screenshot_20200703_140046.png (105,320 bytes) 2020-07-03 12:01
https://tracker.ardour.org/file_download.php?file_id=3753&type=bug
png

Screenshot_20220810_004558-1.png (79,102 bytes) 2022-08-09 23:00
https://tracker.ardour.org/file_download.php?file_id=4204&type=bug
png
Notes
(0024465)
muzikermammoth   
2020-06-15 04:15   
What i do is, i open the panel on the right, and select the tracks and busses tab. In that tab, there is a list of all the tracks and the various switches such as record, mute, active, viewable. Clicking on the names gets ardour to focus on the track in the editor panel. I can even select multiple tracks on this list and ardour will display those. The hot key 'z' will also maximise and focus ardour on selected tracks. Used in conjunction with 'shift - z', which undoes this view, I can zoom focus on one view, and undo to return back to a previous view.

Hope that helps
(0024466)
mhartzel   
2020-06-15 05:06   
I agree that a vertical scrollbar is a simple but valuable tool and I really miss it. It may be easy enough to navigate without it when you have 10 tracks, but not anymore when you have 50. Also as unfa mentioned it also lets you see your vertical position in the track list and the size of the scroll bar shows your vertical "zoom" level also. This helps you create a mental image of your position when you move around. So when we lost the scroll bar we lost three functionalities.
(0024467)
muzikermammoth   
2020-06-15 05:57   
The workflow which i described really comes into its own when trying to align clips within multiple tracks. By selecting tracks to focus on, and pressing 'z', only these tracks are displayed by ardour. In this way the editor view with the tracks becomes a fluid changing interface. Though i do see why the lack of a scrollbar to be a strange omission in any widget that displays content as a list.
(0024473)
mhartzel   
2020-06-15 15:43   
I tried the workaround and I agree this is helpful. You can fit 35 - 40 track names there and focus on single or multiple tracks. I didn't know this feature existed :)
(0024539)
paul   
2020-07-01 16:14   
"The horizontal session navigation is very good - the "Overview" allows me to clearly see what is there, and what part of it I am looking at as well as allowing me to jump places quickly.
But there is no such thing for vertical navigation."

It shows the whole session vertically also.
(0024550)
unfa   
2020-07-01 16:33   
Paul - that's not enough though. You can't see much with 60 pixels of height in the summary panel. You also can't scroll vertically using it.

Have you read my report or watched the video?
(0024551)
paul   
2020-07-01 16:48   
Sorry, my mistake. It once allowed for vertical scrolling.
(0024552)
paul   
2020-07-01 16:49   
(side note: the summary panel can be resized).
(0024556)
unfa   
2020-07-01 18:58   
Yes, vertical scrolling was possible at some time, but even then it was quite limited due to the vertical space available.

(no problem)

Right now the summary panel doesn't visualize what vertical part of the session the user is currently looking at - so it's not helping to build a mental image of the session contents in that dimension. I honestly liked that function, but it wasn't still ideal, as to have any decent precision in vertical scrolling, one had to make the pane quite large, stealing precious space from the track contents themselves.

I think a narrow vertical scroll bar could do a great job with a relatively small pixel cost.

The summary can be resized, true - but for sessions with 50+ tracks, it'd need to be quite big to be of any use (IMO), and it'd use up a lot of pixels for that, while a narrow vertical bar could be much more efficient with it.

I could try and prepare a mock-up to show you what I imagine it could look like if you're interested.
(0024566)
x42   
2020-07-02 20:03   
"...And even if I had one, I can't immediately jump to that part..."
As you mentioned yourself, click on the track in the editor's sidebar, that moves the track into view and selects it.

There are various issues with a vertical scrollbar. Firstly there is no good place to put it. Left of the editor's sidebar is no good place, it's hard to hit it with the mouse.
The bar in the scroller changes its size every time a track's height is resized (which is very common when using "F" and visual-undo), it also snaps in intervals that are not even (due to different track heights and automation lanes). The scrollbar was removed a few versions back because it was pretty much useless due to those issues (and more).
(0024594)
unfa   
2020-07-03 09:14   
x42:

> As you mentioned yourself, click on the track in the editor's sidebar, that moves the track into view and selects it.

That is true, though because there's a bunch of active controls and the track names are very small it's really hard to do.
I think that it could be modified or extended with a different mode to facilitate the problems I'm having with the current design.

> There are various issues with a vertical scrollbar. Firstly there is no good place to put it. Left of the editor's sidebar is no good place, it's hard to hit it with the mouse.

Well, I'm not sure what you mean - a default place virtually all software use is the right edge of the container the scoll bar affects. I think it would make sense between the timeline and an extra panel opened.

> The bar in the scroller changes its size every time a track's height is resized (which is very common when using "F" and visual-undo), it also snaps in intervals that are not even (due to different track heights and automation lanes).

I didn't think about this - but I think it could be solved. The scroll bar should represent a scaled down version of the track, bus, lane and VCA layout and reflect the size of these elements (to help the user connect that with what he sees in the timeline canvas to build a mental image of the session. I think that the snapping shouldn't be that much of a problem.

> The scrollbar was removed a few versions back because it was pretty much useless due to those issues (and more).

Ah I see. I don't remember when I last saw it, but I think I used it, and suddenly I realized I'm missing something.

Maybe then the Tracklist tab could be extended to ease vertical navigation?
I think it'd need three things:

- Give an option to hide the toggles so users can't disable or hide track by misclicking
- Hilight tracks currently visible on the screen to show the user what he's looking at.
- Add a search box so user can quickly filter the tracks and jump to a place of his interest

However I'd still want to give a mini-map scroll bar a try - I'll make a mockup. It would be very useful even if it was non-interactive and only provided visual feedback. However I don't think allowing the user to click and drag to scroll or jump should be that big of a problem once the basics are there. What do you think?
(0024595)
unfa   
2020-07-03 09:38   
Maybe I'll show you one of the session I'm currently working on:

https://unfa.xyz/random/big_ardour_session.png

This session has all sound effects for a small video game.
Being able to have them all in one session is very convenient and allows me to make corrections quickly.

But the session is large so navigating it becomes clunky. But I believe a few simple tools in Ardour could greatly aid with that, because there's not muhc otehr problems with such large sessions (maybe high RAM and CPU usage even when no sound is being produced).

Open the file, set the scale to 100% and scroll. I've joined screenshots from Ardour to make this.

During the process I had no idea how much work is left, because there is simply no visual indication of what part of my session (vertically) am I currently looking at.
Even something like hilighting currently visible tracks in the Summary panel would help - I'd have at least a very rough indication of where am I.

But what would be excellent IMO would be a 24-pixel wide vertical mini-map showing only headers, track types, states and groups. I can't manually prepare a complete mockup, but I'll draw a basic one to show you what I mean.
(0024596)
unfa   
2020-07-03 10:04   
Here's a mockup of a minimap-scrollbar I have in mind.

As you can see this shows:

Master Bus, Tracks, Buses, VCAs (I forgot to add one), automation lanes - all in scale to the "real world" session size.

Groups with their colors and if they're active or not

Record / Mute / Solo status on each track.

Hilights the currently visible area.

It's a little bit ugly, but I hope you get the idea.

Because everything is a simple square, this should scale up pretty well.

I believe if I had this kind of a navigational aid, I could spend much less time scrollign back and forth never finding what I want.

What do you think?
(0024598)
unfa   
2020-07-03 10:44   
Also: if we could integrate a simple level indicator ( a bar changing color from black to green to clipping red) to each track and bus - that'd be absolutely insane In such big sessions I'm spending a lot of time trying to find which tracks produce sound in any given part of the timeline. I haven't added that in the mockup, but that'd be like extra 2-3 pixels vertically to the right of the Rec / Mute / Solo indicators.

What do you think?
(0024599)
mhartzel   
2020-07-03 10:56   
Just for the record, the MeterBridge is far more handy for hunting down what channels are playing. Just open it with: alt + b and drag it open as it might only show a couple of tracks at first. Then you can just open and close it when needed with alt + b. In the screenshot below only channel 7 is outputting audio in a 50 channel session. Pretty easy to spot it, isn't it.
(0024600)
unfa   
2020-07-03 12:01   
mhartzel:

Thanks! Though without a scroll bar or an option to search tracks y name this really doesn't help if I have a really large session - have you seen the stiched screenshot I linked before?
https://unfa.xyz/random/big_ardour_session.png

Here's how the meterbridge looks here:
(0024601)
unfa   
2020-07-03 12:03   
If the meterbridge allowed to jump the editor to a selected track/bus - it'd be at least somewhat helpful, but it doesn't :D
(0026485)
Alkukoira   
2022-06-19 16:02   
I've been missing this feature as well. What's the status? No dice?

I use the up and down keys to scroll between tracks vertically (sometimes the keys work for this, other times they seem to be "occupied" - still unsure what contributes to the keys' different behaviors). 'Page up' and 'page down' can obviously speed up vertical scrolling as well, yet a more robust way to vertically scroll would be of benefit. If there's still an issue with placing the scroll bar, Unfa's suggestion is still good, and an invisible scroll bar could work, too. "Invisible...": say; clicking and dragging on a track (In EDITOR: under its name) would scroll vertically.
(0026536)
paul   
2022-08-09 19:55   
1. scroll bars require mouse motion to place the pointer in the scroll bar. This is almost always a time-waster and is generally considered non-ergonomic.

2. Do none of you have mice with a scrollwheel?

3. @unfa I do not understand your mockup image at all. Can you explain it?
(0026540)
unfa   
2022-08-09 23:00   
@paul

1. Scroll bars provide a clear immediate visual indication of "you are here" and "this is how much stuff is out there".
With very large Ardour sessions (dozens and dozens of tracks many with half a dozen automation lanes open) I often find myself lost scrolling tracks up and down endlessly, trying to find that one track. Having a scroll bar would give me some more spatial awareness about where am I currently.

2. My issue is not about not being able to scroll up and down, it;s about how hard it is to find yourself. The "scroll bar" could not even be a scroll bar, just a visual indicator of which tracks are currently visible on my screen and how many tracks are above and below what I'm currently looking at.

3. I think my mockup is not that great. Let me use a working example instead. I am attaching a screenshot fro a popular text editor Kate.
   1. This is the editing area - it's what the timeline is in Ardour
   2. This is the "mini map" which also functions as a scroll bar.
   3. This is a highlighted part of the mini-map that represents what portion of the edited document is currently visible on screen.

When you have a huge Ardour project with a hunderd tracks - it's as if you'd be editing a source file so large you cannot remember everything that is in it (say 50 various functions), while having no scroll bar, no mini-map, no line numbers, no method list, no code block folding and no search function. That's how it feels to me when I have 100+ tracks in Ardour in a project I've been working on for months.

In software development one can (and probably should) break a huge source file up into smaller ones, making things easier to manage - in Ardour that's not possible. Surely a tiny part of Ardour's userbase is going to be making projects this big, but even smaller ones would greatly benefit from navigational improvements.

Did I explain the problem better?
(0026541)
paul   
2022-08-09 23:09   
OK, so I understand the issue, but the mini-map idea is dead on arrival, at least for me. In the text editing case, generating this is relatively trivial (its the same contents, with "automatically" scaled down text. There's no trival way of doing this for region/track displays. In addition, the start of tracks (which is all you would likely see (as in Kate, where only the start of lines is visible), unlike some text, will not do much to identify where you are.

You might like the track-color-as-bg-color commit that I just pushed recently., (see 0008022) It doesn't really address things in the way a scroll bar would, but could offer you visual guidance via color.
(0026542)
unfa   
2022-08-09 23:56   
@paul In Kate the mini-map works in 2 dimensions - it shows each line of text with it's start and end. That's not what I'd imagine for this feature, as it would be too complex and also hard to read visually if the minimap represented track clips. What I imagine is having full-width horizontal rectangles representing track/bus/automation lanes. Their color would indicate type (track, bus, automation lane, VCA) or a custom color if provided. So we don't care at all about regions on tracks or data on automation lanes, just tracks and lanes themselves. An important part is showing a rectangle that highlights what is currently seen on screen.
I am not sure if using proportional track height in the mini-map (or scrollbar preview? vertical preview?) would be a good idea - on one end it'd help users visually correlate the timeline and the scrollbar preview, but it could also make things a but more cluttered. It could be helpful though. Otherwise the "visible window" highlight would also need to change size.

One important function would be to scroll the timeline vertically immediately to chosen position after clicking on the scrollbar/minimap - this is how it works in Kate, and I think that's great..

That track-color-as-bg-color seems like a step in the right direction - and having such custom track colors be reflected on the minimap / scrollbar preview would greatly help users orient themselves in a huge session.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8940 [ardour] bugs crash always 2022-07-15 23:30 2022-08-09 20:09
Reporter: rw_bowman Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.9  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: crash using pipewire jack
Description:  ardour crashes with latest pipewire update, when trying to use jack on ubuntu 22.04
Tags:
Steps To Reproduce: open ardour, choose jack on selection screen. or jack is preselected from previous session. GUI for ardour will load and crash a few seconds in, choosing alsa or pulseaudio seems to work fine. timeshifted back before last pipewire update and works fine. no other installs other than pipewire update., adjusting jack parameters, quantum, etc to no avail.
Additional Information:
System Description
Attached Files: Text File.txt (53,575 bytes) 2022-07-15 23:30
https://tracker.ardour.org/file_download.php?file_id=4199&type=bug
Notes
(0026506)
x42   
2022-07-17 15:33   
The crash happens in `pipewire-0.3/jack/libjack.so.0` -- nothing we can do about here on our side.

Pipewire is still under heavy development. I suggest to use Ardour's ALSA backend, or jackd.
(0026507)
rw_bowman   
2022-07-18 08:42   
Yep, reported issue to the pipewire git, and timeshifted back to working version of pipewire so all good for now.
(0026538)
paul   
2022-08-09 20:09   
pipewire issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8088 [ardour] bugs minor always 2020-05-05 00:19 2022-08-09 20:07
Reporter: serdeman Platform: Intel i3 laptop  
Assigned To: paul OS: Linux  
Priority: normal OS Version: Mint 19 Cinnamon  
Status: resolved Product Version: 6.0-pre1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6rc1.176 - Exporting does not work correctly
Description: When exporting a mixdown to an audio file, I notice that trying to export a WAV 44.1, 32but (non-float) file does not work correctly. When creating a new export profile, hitting SAVE populates the log with this kind of line:

2020-04-28T23:27:30 [ERROR]: XML error: failed to load external entity "/home/steve/.config/ardour6/export/BWAV 32float Export (copy).format"

Continuing on with setting up the export settings, the popup box does some weird things in the section regarding dither type. (ref. the two screen captures please). After first selected 32bit, all the dither types seem to be available (in white text). But if you click to 16bit, then back to 32bit, all the dither types, except NONE, turn RED.

The resulting export more often than not turns out to be 32bit float. I have not figured out how to, with confidence, make a non-float 32bit file.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Ardour 6rc1.176 gdb output (77,397 bytes) 2020-05-05 00:19
https://tracker.ardour.org/file_download.php?file_id=3660&type=bug
Export_Box_After.png (147,446 bytes) 2020-05-05 00:19
https://tracker.ardour.org/file_download.php?file_id=3661&type=bug
png

Export_Box_Before.png (145,642 bytes) 2020-05-05 00:19
https://tracker.ardour.org/file_download.php?file_id=3662&type=bug
png
Notes
(0024068)
serdeman   
2020-05-05 00:24   
I forgot to mention, during the export, most of the time I end up with two files. One, with all the naming conventions I chose, and an identical file, with a generic name and the tag I placed for the export settings. For example, "session_WAV_441_32bit".
(0026537)
paul   
2022-08-09 20:07   
6.0 is more than 2 years and 8 versions old at this point. Not believed to be an issue in the most recent 6.x release nor in 7.0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8943 [ardour] bugs major always 2022-07-21 06:31 2022-08-09 19:50
Reporter: johne53 Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: urgent OS Version: 10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Strange pointer usage in 'libs'ardour'triggerbox.cc'
Description: I'm repeatedly seeing crashes here when using the Cue Marker lane (in the Edit window). These translate to assertions if I make a Debug build here (with MSVC). I haven't tracked down all the problems but at least part of it is coming from code like this inside 'TriggerBox::fast_forward ()' :-

    CueEvents::const_iterator nxt_cue = c; ++nxt_cue;

    // Then statements like this (further down)
    c = nxt_cue;
    pos = c->time;

As you can see, there's no check to validate the 'c' object. It can easily be pointing to cues.end()
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026518)
johne53   
2022-07-21 06:40   
Sorry - one other thing... it's likely just something I'm not understanding but what's the significance of tests like this

    if (c->cue == INT32_MAX)

AFAICT we never set it to INT32_MAX so what would cause it to be set like that?
(0026535)
paul   
2022-08-09 19:50   
INT32_MAX == CueRecord::stop_all

code has been changed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8827 [ardour] bugs minor always 2021-11-26 07:59 2022-08-09 19:50
Reporter: bobbus Platform: Redhat  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6.6.9 crashes on Fedora 35
Description: Description of problem:
Ardour6.6.9 is broken in Fedora 35. I upgraded from 34 and Ardour is no longer working properly.
Installed a clean Fedora Jam 35 in a VM to replicate the issue, and it's exactly the same.

I'm very aware this might be a Fedora packaging issue, but since Fedora 35 pulled in a lot of the most recent libraries, this might be related.

Actions taken:
Started ardour6 from CLI
Opened existing project or started new project
Do anything in the GUI, like starting a playback, clicking in the timeline, ...
Ardour freezes.

When starting a project or opening an existing project, a ton of error messages are dropped on the CLI (see attached).


Version-Release number of selected component (if applicable):
6.6.9

How reproducible:
Always
Tags:
Steps To Reproduce: Steps to Reproduce:
1.Start Ardour6 on Fedora 35
2.open new or existing project
3.check STDOUT output

Actual results:
Ardour hangs
Additional Information:
System Description
Attached Files: ardour-error-log.txt (21,218 bytes) 2021-11-26 07:59
https://tracker.ardour.org/file_download.php?file_id=4141&type=bug
Notes
(0026247)
bobbus   
2021-11-26 08:13   
removed lv2-klaviatur, klaviatur_gtk and lv2-newtonator and functionally Ardour is now OK.
All the funky lilv_plugin errors in the output remain however!
For completeness: Jack backend emulated by pipewire.
(0026248)
bobbus   
2021-11-26 09:10   
ignore previous comment - Ardour not working despite the removal of broken plugins.
(0026250)
x42   
2021-11-26 14:26   
Does it work if you don't use pipewire? Can you test with Ardour's ALSA backend (no JACK, no PW)?
(0026251)
rohanlean   
2021-11-28 09:43   
Not exactly the answer to Robin's question, but the flatpak from flathub works with pipewire via JACK on Fedora 35 without freezing in the way described.
(0026252)
bobbus   
2021-11-28 12:45   
Switched to jack without PW, but that gave issues starting jack (resources likely claimed by PW).
So I switched to ALSA backend for Ardour6. Doesn't freeze as before, but playback is not consistent and then hangs.

Not the same behavior as with pipewire-jack but also problematic and unusable.
Tried the Fedora 35 live CD and starting Ardour6 from CLI throws the same errors as on my pc.

Flatpaks... I rather don't.
(0026534)
paul   
2022-08-09 19:50   
is this still happening? It is almost certainly a pipewire issue. Will mark resolved in 1 week if no response.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8945 [ardour] bugs crash always 2022-07-23 23:20 2022-08-09 19:17
Reporter: levalithan Platform: Arch  
Assigned To: paul OS: Linux  
Priority: high OS Version: (any)  
Status: resolved Product Version: 6.9  
Product Build: Resolution: unable to reproduce  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Immediate crashing when trying to export
Description: Title. I've finished a track, i go to export and, no matter where i export it, how i export it, or in what format i export it, it doesn't work and will crash immediately with no dialogues or anything. Just an immediate close
Tags:
Steps To Reproduce: Open ardour project, try to export audio
Additional Information: i've attached a file with logs that the "debugging ardour" asked me to grab, if that helps
System Description
Attached Files: ardourcrashlog.txt (65,041 bytes) 2022-07-23 23:20
https://tracker.ardour.org/file_download.php?file_id=4203&type=bug
Notes
(0026520)
levalithan   
2022-07-23 23:27   
nevermind, did it first thing after a reboot with no other programs open, and it worked, i think something with discord and ardour broke as discord didn't have any audio after the initial crash
(0026533)
paul   
2022-08-09 19:17   
Not actionable as-is.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8900 [ardour] bugs minor always 2022-04-14 11:26 2022-08-09 19:14
Reporter: johne53 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crashing bug with RubberBandStretcher
Description: I've been following up a bug report on the MB forum. It's a very reproducible crash on Windows (both for my MSVC build and also Robin's gcc build) but I haven't had a chance yet to try it with Ardour. Also, it probably needs testing with the other platforms.
Tags:
Steps To Reproduce: 1) In the Cues page, select any clip and enable its 'Stretch' mode.
2) Press its "/2" button more than twice.
3) Attempting to replay the clip now causes Mixbus to crash.
Additional Information: I tracked the crash down to some code in librubberband. Intentionally or otherwise, it seems like RubberBandStretcher must have a limit on how much a clip can be speeded up. Double speed works okay and x4 works okay but x8 will crash MB in about 80% of cases.
System Description
Attached Files:
Notes
(0026426)
johne53   
2022-05-02 06:57   
Steps to reproduce:
1) In the Cues page, select any clip and enable its 'Stretch' mode.
2) Press its "/2" button more than twice.
3) Attempting to replay the clip now causes Mixbus to crash.

Additional Information:
it seems like RubberBandStretcher must have a limit on how much a clip can be speeded up.

If this can't be fixed, maybe there could be an upper limit on the maximum speed? (i.e. an upper limit on the number of '/2' presses...)
(0026437)
johne53   
2022-05-07 11:37   
FWIW I can reproduce the same crash in Linux but with a couple of minor differences... on Linux, the speeded-up clip will attempt to play for a second or so (apparently at the last known working speed) and then I see the same crash. And so far in Linux, the crash rate is 100%.
(0026486)
johne53   
2022-06-20 09:56   
Does anyone know this got fixed? I haven't tried Linux yet but I can't reproduce it in Mixbus Windows any more...
(0026487)
lerni   
2022-06-21 05:58   
Dunno but just happen to stumble over https://github.com/Ardour/ardour/commit/fcbe6aab494bf4e13b9ad3d4d5e0ff60ce65626c recently and it sounds related enough.
(0026488)
johne53   
2022-06-21 11:01   
Something's definitely improved this because it used to crash with any clip - but now, I can only find one clip that crashes, namely:-

Under Goldbaby Audio Loops->Loops->PercAndDrums

and it's the clip called "HandsAndFeet1.flac"
(0026532)
paul   
2022-08-09 19:14   
This no longer seems to be reproduceable (here, at least).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8946 [ardour] bugs minor always 2022-07-24 19:31 2022-08-09 19:11
Reporter: oml65 Platform: Arch  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.9  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6.9.0 hangs when closing with JACK setup (not with RtAudio setup or jackd not started)
Description: When closing ardour6 it hangs when is setup with JACK.

Ardour 6.9.0
"After Bach"
(rev 6.9)
Intel 64-bit
Tags: closing, hangs, jack
Steps To Reproduce: Open gnome-terminal and run ardour6.
Close ardour.
Hangs and does not return to login prompt. I need to press CTRL+C.
Additional Information: Config:

Build documentation: False
Debuggable build: False
Export all symbols (backtrace): False
Install prefix: /usr
Strict compiler flags: []
Internal Shared Libraries: True
Use External Libraries: True
Library exports hidden: True
Free/Demo copy: False

ALSA DBus Reservation: True
Architecture flags: None
ARM NEON support: False
Aubio: True
AudioUnits: False
Build target: x86_64
Canvas Test UI: False
Beatbox test app: False
CoreAudio: False
CoreAudio 10.5 compat: False
Debug RT allocations: False
Debug Symbols: False
Denormal exceptions: False
Dr. Mingw: False
FLAC: True
FPU optimization: True
FPU AVX/FMA support: True
Freedesktop files: True
Libjack linking: link
Libjack metadata: True
Lua Binding Doc: False
Lua Commandline Tool: True
LV2 UI embedding: True
LV2 support: True
LV2 extensions: True
LXVST support: True
Mac VST support: False
NI-Maschine: False
OGG: True
Phone home: False
Process thread timing: False
Program name: Ardour
Samplerate: True
PT format: True
PTW32 Semaphore: False
Threaded WaveViews: True
Translation: True
Unit tests: False
Use LLD linker: False
VST3 support: True
Windows VST support: False
Wiimote support: False
Windows key: Mod4><Super

PortAudio Backend: False
CoreAudio/Midi Backend: False
ALSA Backend: True
Dummy backend: True
JACK Backend: True
Pulseaudio Backend: True

Buildstack: -system-
Mac i386 Architecture: False
Mac ppc Architecture: False
Mac arm64 Architecture: False

C compiler flags: ['-I/build/ardour/src/ardour', '-march=x86-64', '-mtune=generic', '-O2', '-pipe', '-fno-plt', '-fexceptions', '-Wp,-D_FORTIFY_SOURCE=2', '-Wformat', '-Werror=format-security', '-fstack-clash-protection', '-fcf-protection', '-g', '-fvar-tracking-assignments', '-fdebug-prefix-map=/build/ardour/src=/usr/src/debug', '-flto', '-DHAVE_RF64_RIFF', '-DWAF_BUILD', '-DNDEBUG', '-fshow-column', '-O3', '-fomit-frame-pointer', '-ffast-math', '-fstrength-reduce', '-pipe', '-DARCH_X86', '-mmmx', '-msse', '-mfpmath=sse', '-DUSE_XMMINTRIN', '-DBUILD_SSE_OPTIMIZATIONS', '-DLXVST_64BIT', '-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', '-DBOOST_SYSTEM_NO_DEPRECATED', '-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="6"', '-Wstrict-prototypes', '-Wmissing-prototypes']
C++ compiler flags: ['-I/build/ardour/src/ardour', '-march=x86-64', '-mtune=generic', '-O2', '-pipe', '-fno-plt', '-fexceptions', '-Wp,-D_FORTIFY_SOURCE=2', '-Wformat', '-Werror=format-security', '-fstack-clash-protection', '-fcf-protection', '-Wp,-D_GLIBCXX_ASSERTIONS', '-g', '-fvar-tracking-assignments', '-fdebug-prefix-map=/build/ardour/src=/usr/src/debug', '-flto', '-DHAVE_RF64_RIFF', '-DWAF_BUILD', '-DNDEBUG', '-fshow-column', '-O3', '-fomit-frame-pointer', '-ffast-math', '-fstrength-reduce', '-pipe', '-DARCH_X86', '-mmmx', '-msse', '-mfpmath=sse', '-DUSE_XMMINTRIN', '-DBUILD_SSE_OPTIMIZATIONS', '-DLXVST_64BIT', '-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', '-DBOOST_SYSTEM_NO_DEPRECATED', '-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="6"', '-std=c++11', '-DBOOST_NO_AUTO_PTR', '-DBOOST_BIND_GLOBAL_PLACEHOLDERS', '-Woverloaded-virtual', '-Wno-unused-local-typedefs', '-D__STDC_LIMIT_MACROS', '-D__STDC_FORMAT_MACROS', '-DCANVAS_COMPATIBILITY', '-DCANVAS_DEBUG', '-DBOOST_ERROR_CODE_HEADER_ONLY']
Linker flags: ['-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now', '-flto']

$ LC_ALL=C ardour6 --gdb
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/ardour6/ardour-6.9.0...
(No debugging symbols found in /usr/lib/ardour6/ardour-6.9.0)
(gdb) run
Starting program: /usr/lib/ardour6/ardour-6.9.0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Ardour6.9.0 (built using 6.9 and GCC version 11.2.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /etc/ardour6/system_config
Ardour: [INFO]: Loading user configuration file /home/user/.config/ardour6/config
[New Thread 0x7ffff0de6640 (LWP 9742)]
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 9 5900X 12-Core Processor
Ardour: [INFO]: Using AVX and FMA optimized routines
[New Thread 0x7fffebfff640 (LWP 9743)]
[New Thread 0x7fffe3fff640 (LWP 9744)]
[New Thread 0x7fffeb7fe640 (LWP 9745)]
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour6/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/user/.config/ardour6/plugin_metadata/plugin_stats
[New Thread 0x7fffeaffd640 (LWP 9746)]
[Thread 0x7fffeaffd640 (LWP 9746) exited]
[New Thread 0x7fffeaffd640 (LWP 9747)]
[New Thread 0x7fffea572640 (LWP 9748)]
[New Thread 0x7fffe9c48640 (LWP 9749)]
Ardour: [INFO]: Loading default ui configuration file /etc/ardour6/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/user/.config/ardour6/ui_config
Ardour: [INFO]: Loading 452 MIDI patches from /usr/share/ardour6/patchfiles
[New Thread 0x7fffe93ce640 (LWP 9750)]
[Thread 0x7fffe93ce640 (LWP 9750) exited]
[New Thread 0x7fffe93ce640 (LWP 9751)]
[New Thread 0x7fffe8bcd640 (LWP 9752)]
[Thread 0x7fffe93ce640 (LWP 9751) exited]
[New Thread 0x7fffe93ce640 (LWP 9753)]
[New Thread 0x7fffe37fe640 (LWP 9754)]
[Thread 0x7fffe8bcd640 (LWP 9752) exited]
[Thread 0x7fffe93ce640 (LWP 9753) exited]
[Thread 0x7fffe37fe640 (LWP 9754) exited]
[New Thread 0x7fffe37fe640 (LWP 9755)]
[New Thread 0x7fffe93ce640 (LWP 9756)]
[Thread 0x7fffe37fe640 (LWP 9755) exited]
[Thread 0x7fffe93ce640 (LWP 9756) exited]
Ardour: [INFO]: Loading color file /usr/share/ardour6/themes/dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file /etc/ardour6/clearlooks.rc
[New Thread 0x7fffe93ce640 (LWP 9757)]
[New Thread 0x7fffe37fe640 (LWP 9758)]
[Thread 0x7fffe93ce640 (LWP 9757) exited]
[New Thread 0x7fffe93ce640 (LWP 9759)]
[New Thread 0x7fffe8bcd640 (LWP 9760)]
[Thread 0x7fffe37fe640 (LWP 9758) exited]
[Thread 0x7fffe93ce640 (LWP 9759) exited]
[New Thread 0x7fffe93ce640 (LWP 9761)]
[New Thread 0x7fffe37fe640 (LWP 9762)]
[Thread 0x7fffe8bcd640 (LWP 9760) exited]
[Thread 0x7fffe93ce640 (LWP 9761) exited]
[New Thread 0x7fffe93ce640 (LWP 9763)]
[New Thread 0x7fffe8bcd640 (LWP 9764)]
[Thread 0x7fffe37fe640 (LWP 9762) exited]
[Thread 0x7fffe93ce640 (LWP 9763) exited]
[Thread 0x7fffe8bcd640 (LWP 9764) exited]
Ardour: [INFO]: Loading bindings from /etc/ardour6/ardour.keys
Loading ui configuration file /etc/ardour6/clearlooks.rc
[New Thread 0x7fffe8bcd640 (LWP 9765)]
[New Thread 0x7fffe93ce640 (LWP 9766)]
[Thread 0x7fffe8bcd640 (LWP 9765) exited]
[New Thread 0x7fffe8bcd640 (LWP 9767)]
[New Thread 0x7fffe37fe640 (LWP 9768)]
[Thread 0x7fffe8bcd640 (LWP 9767) exited]
[Thread 0x7fffe93ce640 (LWP 9766) exited]
[Thread 0x7fffe37fe640 (LWP 9768) exited]
[New Thread 0x7fffe37fe640 (LWP 9769)]
[New Thread 0x7fffe93ce640 (LWP 9770)]
[Thread 0x7fffe37fe640 (LWP 9769) exited]
[Thread 0x7fffe93ce640 (LWP 9770) exited]
[New Thread 0x7fffe8238640 (LWP 9771)]
[New Thread 0x7fffe2ffd640 (LWP 9772)]
[Thread 0x7fffe2ffd640 (LWP 9772) exited]
[Thread 0x7fffe8238640 (LWP 9771) exited]
[New Thread 0x7fffe8238640 (LWP 9773)]
[New Thread 0x7fffe2ffd640 (LWP 9774)]
[Thread 0x7fffe2ffd640 (LWP 9774) exited]
[Thread 0x7fffe8238640 (LWP 9773) exited]
[New Thread 0x7fffe93ce640 (LWP 9775)]
[New Thread 0x7fffe37fe640 (LWP 9776)]
[Thread 0x7fffe93ce640 (LWP 9775) exited]
[New Thread 0x7fffe93ce640 (LWP 9777)]
[New Thread 0x7fffe8bcd640 (LWP 9778)]
[Thread 0x7fffe37fe640 (LWP 9776) exited]
[Thread 0x7fffe93ce640 (LWP 9777) exited]
[Thread 0x7fffe8bcd640 (LWP 9778) exited]
[New Thread 0x7fffe8bcd640 (LWP 9779)]
[New Thread 0x7fffe93ce640 (LWP 9780)]
[Thread 0x7fffe8bcd640 (LWP 9779) exited]
[New Thread 0x7fffe8bcd640 (LWP 9781)]
[Thread 0x7fffe93ce640 (LWP 9780) exited]
[New Thread 0x7fffe93ce640 (LWP 9782)]
[Thread 0x7fffe8bcd640 (LWP 9781) exited]
[Thread 0x7fffe93ce640 (LWP 9782) exited]
[New Thread 0x7fffe93ce640 (LWP 9783)]
[New Thread 0x7fffe8bcd640 (LWP 9784)]
[New Thread 0x7fffe37fe640 (LWP 9785)]
[New Thread 0x7fffe2eda640 (LWP 9786)]
[New Thread 0x7fffe26d9640 (LWP 9787)]
[New Thread 0x7fffe1ed8640 (LWP 9788)]
[New Thread 0x7fffe16d7640 (LWP 9789)]
[New Thread 0x7fffe0ed6640 (LWP 9790)]
[New Thread 0x7fffabfff640 (LWP 9791)]
[New Thread 0x7fffab7fe640 (LWP 9792)]
Found nothing along /home/user/.config/ardour6/templates:/usr/share/ardour6/templates
[New Thread 0x7fffaaffd640 (LWP 9793)]
[New Thread 0x7fffaa7fc640 (LWP 9794)]
[Thread 0x7fffaaffd640 (LWP 9793) exited]
[Thread 0x7fffaa7fc640 (LWP 9794) exited]
[New Thread 0x7fffaa7fc640 (LWP 9795)]
[New Thread 0x7fffaaffd640 (LWP 9796)]
[Thread 0x7fffaa7fc640 (LWP 9795) exited]
[Thread 0x7fffaaffd640 (LWP 9796) exited]
[New Thread 0x7fffaaffd640 (LWP 9797)]
[Thread 0x7fffe9c48640 (LWP 9749) exited]
[Thread 0x7fffe0ed6640 (LWP 9790) exited]
[Thread 0x7fffe1ed8640 (LWP 9788) exited]
[Thread 0x7fffe26d9640 (LWP 9787) exited]
[Thread 0x7fffabfff640 (LWP 9791) exited]
[Thread 0x7fffe37fe640 (LWP 9785) exited]
[Thread 0x7fffab7fe640 (LWP 9792) exited]
[Thread 0x7fffe16d7640 (LWP 9789) exited]
[New Thread 0x7fffe16d7640 (LWP 9798)]
[New Thread 0x7fffe8238640 (LWP 9799)]
[New Thread 0x7fffe2573640 (LWP 9800)]
[New Thread 0x7fffe2235640 (LWP 9801)]
[Thread 0x7fffe2eda640 (LWP 9786) exited]
Scanning folders for bundled LV2s: /usr/lib/ardour6/LV2
[New Thread 0x7fffe2eda640 (LWP 9802)]
[New Thread 0x7fffab7fe640 (LWP 9803)]
[New Thread 0x7fffe37fe640 (LWP 9804)]
[New Thread 0x7fffabfff640 (LWP 9805)]
[New Thread 0x7fffe0ed6640 (LWP 9806)]
[New Thread 0x7fffaa7fc640 (LWP 9807)]
[New Thread 0x7fffa9ffb640 (LWP 9808)]
[New Thread 0x7fffa97fa640 (LWP 9809)]
[New Thread 0x7fffa8ff9640 (LWP 9810)]
[New Thread 0x7fff819a0640 (LWP 9811)]
[New Thread 0x7fff8119f640 (LWP 9812)]
[Thread 0x7fff819a0640 (LWP 9811) exited]
[Thread 0x7fff8119f640 (LWP 9812) exited]
Set cursor set to default
[New Thread 0x7fff8119f640 (LWP 9813)]
[New Thread 0x7fff819a0640 (LWP 9814)]
[Thread 0x7fff8119f640 (LWP 9813) exited]
[New Thread 0x7fff8119f640 (LWP 9815)]
[New Thread 0x7fff8099e640 (LWP 9816)]
[Thread 0x7fff819a0640 (LWP 9814) exited]
[Thread 0x7fff8119f640 (LWP 9815) exited]
[Thread 0x7fff8099e640 (LWP 9816) exited]
[New Thread 0x7fff8099e640 (LWP 9817)]
[New Thread 0x7fff8119f640 (LWP 9818)]
[Thread 0x7fff8099e640 (LWP 9817) exited]
[Thread 0x7fff8119f640 (LWP 9818) exited]
[New Thread 0x7fff8119f640 (LWP 9819)]
[New Thread 0x7fff8099e640 (LWP 9820)]
[Thread 0x7fff8119f640 (LWP 9819) exited]
[New Thread 0x7fff8119f640 (LWP 9821)]
[New Thread 0x7fff819a0640 (LWP 9822)]
[Thread 0x7fff8119f640 (LWP 9821) exited]
[Thread 0x7fff8099e640 (LWP 9820) exited]
[Thread 0x7fff819a0640 (LWP 9822) exited]
[New Thread 0x7fff819a0640 (LWP 9823)]
[New Thread 0x7fff8099e640 (LWP 9824)]
[Thread 0x7fff819a0640 (LWP 9823) exited]
[New Thread 0x7fff819a0640 (LWP 9825)]
[New Thread 0x7fff8119f640 (LWP 9826)]
[Thread 0x7fff8099e640 (LWP 9824) exited]
[Thread 0x7fff819a0640 (LWP 9825) exited]
[Thread 0x7fff8119f640 (LWP 9826) exited]
[New Thread 0x7fff8119f640 (LWP 9827)]
[New Thread 0x7fff819a0640 (LWP 9828)]
[Thread 0x7fff8119f640 (LWP 9827) exited]
[Thread 0x7fff819a0640 (LWP 9828) exited]
[New Thread 0x7fff819a0640 (LWP 9829)]
[New Thread 0x7fff8119f640 (LWP 9830)]
[Thread 0x7fff819a0640 (LWP 9829) exited]
[Thread 0x7fff8119f640 (LWP 9830) exited]
[New Thread 0x7fffe179fa00 (LWP 9831)]
[New Thread 0x7fffe1793a00 (LWP 9832)]
[New Thread 0x7fffe1787a00 (LWP 9833)]
[New Thread 0x7fffe177ba00 (LWP 9834)]
[New Thread 0x7fffe176fa00 (LWP 9835)]
[New Thread 0x7fffe1763a00 (LWP 9836)]
[New Thread 0x7fffe1757a00 (LWP 9837)]
[New Thread 0x7fffe174ba00 (LWP 9838)]
[New Thread 0x7fffe173fa00 (LWP 9839)]
[New Thread 0x7fffe1733a00 (LWP 9840)]
[New Thread 0x7fffe1727a00 (LWP 9841)]
[New Thread 0x7fffe171ba00 (LWP 9842)]
[New Thread 0x7fffe170fa00 (LWP 9843)]
[New Thread 0x7fffe1703a00 (LWP 9844)]
[New Thread 0x7fffe16f7a00 (LWP 9845)]
[New Thread 0x7fffe16eba00 (LWP 9846)]
[New Thread 0x7fffe066aa00 (LWP 9847)]
[New Thread 0x7fffe065ea00 (LWP 9848)]
[New Thread 0x7fffe0652a00 (LWP 9849)]
[New Thread 0x7fffe0646a00 (LWP 9850)]
[New Thread 0x7fffe063aa00 (LWP 9851)]
[New Thread 0x7fffe062ea00 (LWP 9852)]
[New Thread 0x7fffe0622a00 (LWP 9853)]
[New Thread 0x7fffe0617640 (LWP 9854)]
[New Thread 0x7fffe0596640 (LWP 9855)]
[New Thread 0x7fffe0515640 (LWP 9856)]
[New Thread 0x7fffe0494640 (LWP 9857)]
[New Thread 0x7fffe0413640 (LWP 9858)]
[New Thread 0x7fffe0392640 (LWP 9859)]
[New Thread 0x7fffe0311640 (LWP 9860)]
[New Thread 0x7fffe0290640 (LWP 9861)]
[New Thread 0x7fffe020f640 (LWP 9862)]
[New Thread 0x7fffe018e640 (LWP 9863)]
[New Thread 0x7fffe010d640 (LWP 9864)]
[New Thread 0x7fffe008c640 (LWP 9865)]
[New Thread 0x7fffa87f8640 (LWP 9866)]
[New Thread 0x7fffa8777640 (LWP 9867)]
[New Thread 0x7fffa86f6640 (LWP 9868)]
[New Thread 0x7fffa8675640 (LWP 9869)]
[New Thread 0x7fffa85f4640 (LWP 9870)]
[New Thread 0x7fffa8573640 (LWP 9871)]
[New Thread 0x7fffa84f2640 (LWP 9872)]
[New Thread 0x7fffa8471640 (LWP 9873)]
[New Thread 0x7fffa83f0640 (LWP 9874)]
[New Thread 0x7fffa836f640 (LWP 9875)]
[New Thread 0x7fffa82ee640 (LWP 9876)]
[New Thread 0x7fff8119f640 (LWP 9877)]
[New Thread 0x7fff819a0640 (LWP 9878)]
[Thread 0x7fff8119f640 (LWP 9877) exited]
[New Thread 0x7fff8119f640 (LWP 9879)]
[New Thread 0x7fff8099e640 (LWP 9880)]
[Thread 0x7fff8119f640 (LWP 9879) exited]
[Thread 0x7fff819a0640 (LWP 9878) exited]
[Thread 0x7fff8099e640 (LWP 9880) exited]
[New Thread 0x7fff8099e640 (LWP 9881)]
[New Thread 0x7fff819a0640 (LWP 9882)]
[Thread 0x7fff8099e640 (LWP 9881) exited]
[Thread 0x7fff819a0640 (LWP 9882) exited]
[New Thread 0x7fff819a0640 (LWP 9883)]
[New Thread 0x7fff8099e640 (LWP 9884)]
[Thread 0x7fff819a0640 (LWP 9883) exited]
[Thread 0x7fff8099e640 (LWP 9884) exited]
[New Thread 0x7fffa80df640 (LWP 9885)]
[New Thread 0x7fff8099e640 (LWP 9886)]
[Thread 0x7fffa8ff9640 (LWP 9810) exited]
[Thread 0x7fffe0ed6640 (LWP 9806) exited]
[Thread 0x7fffa9ffb640 (LWP 9808) exited]
[Thread 0x7fffe2eda640 (LWP 9802) exited]
[Thread 0x7fffe37fe640 (LWP 9804) exited]
[Thread 0x7fffaa7fc640 (LWP 9807) exited]
[Thread 0x7fffabfff640 (LWP 9805) exited]
[Thread 0x7fffab7fe640 (LWP 9803) exited]
[Thread 0x7fffe16d7640 (LWP 9798) exited]
[New Thread 0x7fffe16d7640 (LWP 9887)]
[New Thread 0x7fffab7fe640 (LWP 9888)]
[New Thread 0x7fffabfff640 (LWP 9889)]
[New Thread 0x7fffaa7fc640 (LWP 9890)]
[New Thread 0x7fffe2eda640 (LWP 9891)]
[Thread 0x7fffaa7fc640 (LWP 9890) exited]
[Thread 0x7fffe2eda640 (LWP 9891) exited]
[New Thread 0x7fffe2eda640 (LWP 9892)]
[New Thread 0x7fffaa7fc640 (LWP 9893)]
[Thread 0x7fffe2eda640 (LWP 9892) exited]
[Thread 0x7fffaa7fc640 (LWP 9893) exited]
[New Thread 0x7fffaa7fc640 (LWP 9894)]
[New Thread 0x7fffe2eda640 (LWP 9895)]
[Thread 0x7fffaa7fc640 (LWP 9894) exited]
[Thread 0x7fffe2eda640 (LWP 9895) exited]
[New Thread 0x7fffe2eda640 (LWP 9896)]
[New Thread 0x7fffaa7fc640 (LWP 9897)]
[Thread 0x7fffe2eda640 (LWP 9896) exited]
[New Thread 0x7fffe2eda640 (LWP 9898)]
[New Thread 0x7fffe0ed6640 (LWP 9899)]
[Thread 0x7fffe2eda640 (LWP 9898) exited]
[Thread 0x7fffaa7fc640 (LWP 9897) exited]
[Thread 0x7fffe0ed6640 (LWP 9899) exited]
[New Thread 0x7fffe0ed6640 (LWP 9900)]
[New Thread 0x7fffaa7fc640 (LWP 9901)]
[Thread 0x7fffe0ed6640 (LWP 9900) exited]
[Thread 0x7fffaa7fc640 (LWP 9901) exited]
[New Thread 0x7fffaa7fc640 (LWP 9902)]
[New Thread 0x7fffe0ed6640 (LWP 9903)]
[Thread 0x7fffaa7fc640 (LWP 9902) exited]
[New Thread 0x7fffaa7fc640 (LWP 9904)]
[New Thread 0x7fffe2eda640 (LWP 9905)]
[Thread 0x7fffe0ed6640 (LWP 9903) exited]
[Thread 0x7fffaa7fc640 (LWP 9904) exited]
[Thread 0x7fffe2eda640 (LWP 9905) exited]
[New Thread 0x7fffe2eda640 (LWP 9906)]
[New Thread 0x7fffaa7fc640 (LWP 9907)]
[New Thread 0x7fffe0ed6640 (LWP 9908)]
[New Thread 0x7fffa8ff9640 (LWP 9909)]
[New Thread 0x7fff819a0640 (LWP 9910)]
[New Thread 0x7fff8119f640 (LWP 9911)]
[New Thread 0x7ffeb27fc640 (LWP 9912)]
[New Thread 0x7ffeb1ffb640 (LWP 9913)]
[Thread 0x7fffab7fe640 (LWP 9888) exited]
Butler drops pool trash
[Thread 0x7fffa80df640 (LWP 9885) exited]
[Thread 0x7ffeb1ffb640 (LWP 9913) exited]
[Thread 0x7ffeb27fc640 (LWP 9912) exited]
[Thread 0x7fff8119f640 (LWP 9911) exited]
[Thread 0x7fff819a0640 (LWP 9910) exited]
[Thread 0x7fffa8ff9640 (LWP 9909) exited]
[Thread 0x7fffe0ed6640 (LWP 9908) exited]
[Thread 0x7fffaa7fc640 (LWP 9907) exited]
[Thread 0x7fffe2eda640 (LWP 9906) exited]
[Thread 0x7fffa82ee640 (LWP 9876) exited]
[Thread 0x7fffa836f640 (LWP 9875) exited]
[Thread 0x7fffa83f0640 (LWP 9874) exited]
[Thread 0x7fffa8471640 (LWP 9873) exited]
[Thread 0x7fffa84f2640 (LWP 9872) exited]
[Thread 0x7fffa8573640 (LWP 9871) exited]
[Thread 0x7fffa85f4640 (LWP 9870) exited]
[Thread 0x7fffa8675640 (LWP 9869) exited]
[Thread 0x7fffa86f6640 (LWP 9868) exited]
[Thread 0x7fffa8777640 (LWP 9867) exited]
[Thread 0x7fffa87f8640 (LWP 9866) exited]
[Thread 0x7fffe008c640 (LWP 9865) exited]
[Thread 0x7fffe010d640 (LWP 9864) exited]
[Thread 0x7fffe018e640 (LWP 9863) exited]
[Thread 0x7fffe020f640 (LWP 9862) exited]
[Thread 0x7fffe0290640 (LWP 9861) exited]
[Thread 0x7fffe0311640 (LWP 9860) exited]
[Thread 0x7fffe0392640 (LWP 9859) exited]
[Thread 0x7fffe0413640 (LWP 9858) exited]
[Thread 0x7fffe0494640 (LWP 9857) exited]
[Thread 0x7fffe0515640 (LWP 9856) exited]
[Thread 0x7fffe0596640 (LWP 9855) exited]
[Thread 0x7fffe0617640 (LWP 9854) exited]
[Thread 0x7fffabfff640 (LWP 9889) exited]
[Thread 0x7fffe16d7640 (LWP 9887) exited]
[Thread 0x7fff8099e640 (LWP 9886) exited]
[Thread 0x7fffe170fa00 (LWP 9843) exited]
[Thread 0x7fffe16f7a00 (LWP 9845) exited]
[Thread 0x7fffe0622a00 (LWP 9853) exited]
[Thread 0x7fffe062ea00 (LWP 9852) exited]
[Thread 0x7fffe063aa00 (LWP 9851) exited]
[Thread 0x7fffe0646a00 (LWP 9850) exited]
[Thread 0x7fffe0652a00 (LWP 9849) exited]
[Thread 0x7fffe065ea00 (LWP 9848) exited]
[Thread 0x7fffe066aa00 (LWP 9847) exited]
[Thread 0x7fffe16eba00 (LWP 9846) exited]
[Thread 0x7fffe1703a00 (LWP 9844) exited]
[Thread 0x7fffe171ba00 (LWP 9842) exited]
[Thread 0x7fffe1727a00 (LWP 9841) exited]
[Thread 0x7fffe1733a00 (LWP 9840) exited]
[Thread 0x7fffe173fa00 (LWP 9839) exited]
[Thread 0x7fffe174ba00 (LWP 9838) exited]
[Thread 0x7fffe1757a00 (LWP 9837) exited]
[Thread 0x7fffe1763a00 (LWP 9836) exited]
[Thread 0x7fffe176fa00 (LWP 9835) exited]
[Thread 0x7fffe177ba00 (LWP 9834) exited]
[Thread 0x7fffe1787a00 (LWP 9833) exited]
[Thread 0x7fffe1793a00 (LWP 9832) exited]
[Thread 0x7fffe179fa00 (LWP 9831) exited]
[Thread 0x7fffa97fa640 (LWP 9809) exited]
^C
Thread 1 "ArdourGUI" received signal SIGINT, Interrupt.
0x00007ffff5689119 in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff5689119 in () at /usr/lib/libc.so.6
0000001 0x00007ffff568e113 in () at /usr/lib/libc.so.6
#2 0x00007ffff3f2b326 in () at /usr/lib/libjack.so.0
#3 0x00007ffff3f0b23c in () at /usr/lib/libjack.so.0
0000004 0x00007ffff3f0a149 in () at /usr/lib/libjack.so.0
0000005 0x00007ffff3f2ed75 in jack_client_close () at /usr/lib/libjack.so.0
#6 0x00007fffe9cabe70 in ARDOUR::JackConnection::close() () at /usr/lib/ardour6/backends/libjack_audiobackend.so
#7 0x00007fffe9cac23b in ARDOUR::JACKAudioBackend::stop() () at /usr/lib/ardour6/backends/libjack_audiobackend.so
0000008 0x00007ffff77264ee in ARDOUR::AudioEngine::stop(bool) () at /usr/lib/ardour6/libardour.so.3
0000009 0x00005555559b87f7 in ()
0000010 0x00005555559ee138 in ()
0000011 0x00007ffff70c59e6 in () at /usr/lib/libglibmm-2.4.so.1
0000012 0x00007ffff6f27c6b in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
0000013 0x00007ffff6f7e001 in () at /usr/lib/libglib-2.0.so.0
0000014 0x00007ffff6f271cf in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#15 0x00007ffff6b339fe in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0
0000016 0x00007ffff7241d5d in Gtkmm2ext::UI::run(Receiver&) () at /usr/lib/ardour6/libgtkmm2ext.so.0
#17 0x000055555597b8f3 in main ()
(gdb) exit
A debugging session is active.

        Inferior 1 [process 9739] will be killed.

Quit anyway? (y or n) y
$
System Description
Attached Files:
Notes
(0026521)
oml65   
2022-07-24 19:32   
$ uname -a
Linux my_pc 5.18.13-arch1-1 0000001 SMP PREEMPT_DYNAMIC Fri, 22 Jul 2022 13:05:04 +0000 x86_64 GNU/Linux
$
(0026522)
oml65   
2022-07-24 20:44   
Neither Wafeform12 nor Waveform11 nor reaper have this issue.
(0026523)
x42   
2022-07-25 13:36   
This is likely the same issue as https://discourse.ardour.org/t/ardour-hanging-at-shutdown/107260/22?u=x42

Ardour delegates background processing to JACK, and those those threads cannot be stopped due to a recent bug in glibc that arch ships.
It s already fixed upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=29214#c6

meanwhile you could downgrade glibc (as mentioned in the forum thread).
(0026531)
paul   
2022-08-09 19:11   
glibc bug.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8942 [ardour] bugs major always 2022-07-18 10:03 2022-07-18 13:50
Reporter: KottV Platform: GNU  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour LV2 host doesn't provide boundedBlockLength in features array
Description: Hi,

Information is from here https://forum.juce.com/t/juce7-technical-preview-branch/50866/87

For the Ardour issue: JUCE plugins need to know their maximum processing block size, so JUCE LV2 plugins declare bufs:boundedBlockSize as an lv2:requiredFeature. If a plugin requires features that cannot be supplied by the host, the host should not attempt to instantiate the plugin. If the host does supply the feature, then it should include the feature in the array of features passed to the plugin during instantiation. For that assertion to fire, one of the following must be true:

   *The host cannot supply the boundedBlockLength feature, but attempts to instantiate the plugin anyway. The host should not attempt to instantiate the plugin in this case.
    *The host can supply the boundedBlockLength feature, but does not include it in the features data array. In this case, the host should be updated to include boundedBlockLength in its features array.
Tags:
Steps To Reproduce: Compile any JUCE plugin with LV2 support.
Install plugin in LV2 path.
Scan for the new plugins in Ardour.
Add new plugin.
Additional Information:
System Description
Attached Files:
Notes
(0026508)
x42   
2022-07-18 12:52   
It's a feature that plugins can require (lv2:requiredFeature), and the host in turn implements and provides
http://lv2plug.in/ns/ext/buf-size#minBlockLength
http://lv2plug.in/ns/ext/buf-size#maxBlockLength

In case of Ardour both are set, minBlockLength is 1 and maxBlockLength 8192. This has been implemented since 2015.

Compare to other plugins that use it (ZynAddSubFX.lv2, KlangFalter.lv2, Pianoteq 6.lv2, moony.lv2 etc)
(0026509)
KottV   
2022-07-18 13:03   
thnx, forwarded to juce forum
(0026510)
KottV   
2022-07-18 13:16   
BTW I haven't such issue in the jalv, Muse, Reaper, Carla
(0026511)
x42   
2022-07-18 13:20   
Odd the same person who wrote jalv (and the LV2 spec) also wrote Ardour's implementation.
(0026512)
KottV   
2022-07-18 13:23   
I know :)
Could you take a look at JUCE implementation, please? Or give a point?
(0026513)
x42   
2022-07-18 13:24   
Reading the source, it looks like the feature is indeed not explicitly announced to the plugin, but the min/max options are set.
(0026514)
reuk   
2022-07-18 13:32   
When a host supports an `lv2:requiredFeature`, the host MUST pass the feature's URI and any additional data to the plugin in LV2_Descriptor::instantiate(), and the plugin MUST fail to instantiate if a required feature is not supported by the host. (See http://lv2plug.in/ns/lv2core#requiredFeature).

I believe that the JUCE implementation is adhering to the spec by failing to instantiate, given that the host is not reporting boundedBlockLength as supported. Plugins that declare boundedBlockLength as a requiredFeature, but which don't check that the host provides this feature, do not adhere to the spec.

If there's some provision in the spec that means 'data-only' features don't need to be included in the LV2_Feature array, please provide a link to this provision so that I can reference it in a change to JUCE.

If there's no such provision, then I believe the wording in the spec is unambiguous, and Ardour must add boundedBlockLength to its array of supported features in order to declare support.
(0026515)
x42   
2022-07-18 13:46   
It is redundant, so it seems plugins just read the options (if present), regardless of the host announcing the feature.
It makes lot more sense the other way around. A host that does not provide the options should refuse plugins that require the feature.

Anyway fixed now in Ardour 7.0-pre0-3175-g79f8606b2d -- Thanks for the heads up.
(0026516)
reuk   
2022-07-18 13:50   
Great, thanks!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8941 [ardour] bugs crash always 2022-07-16 00:01 2022-07-16 00:01
Reporter: tc69 Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes if you try to remove ZynReverb plugin from a midi track.
Description: The plugin itself works fine while it's added to the midi track.
The crash happens with all other synths I've tested it, except for when it's used with ZynAddSubFX.
Tags:
Steps To Reproduce: 1. Create a midi track
2. Add ZynReverb
3. Remove ZynReverb from the track
Additional Information: Ardour terminal output when crash happens:

GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument. Aborting.
Aborted (core dumped)
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8823 [ardour] bugs minor always 2021-11-19 17:59 2022-07-14 02:12
Reporter: rohanlean Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI automation causes repeated messages to be sent for constant values
Description: While trying out the Salamander Grand Piano with sfizz I noticed that if the sustain pedal (CC64) is automated, then if the pedal is fully disengaged or fully engaged, the pedal sound is triggered all the time. Presumably Ardour sends control messages all the time. I have submitted a pull request for the Salamander piano that changes the pedal noise values to trigger just before the endpoints instead of at them, but I am not sure if that is the right approach. Even with that fix, the pedal noise triggers multiple times instead of just once if the pedal is moved slowly.

I think it might be best if Ardour did not send repeat messages if the previous value is unchanged.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: MIDI-CC-playback.png (17,406 bytes) 2021-11-20 11:41
https://tracker.ardour.org/file_download.php?file_id=4136&type=bug
png

sustain_pedal-2021-11-22.zip (33,203 bytes) 2021-11-22 19:48
https://tracker.ardour.org/file_download.php?file_id=4139&type=bug
no_mode.png (5,963 bytes) 2021-11-22 19:48
https://tracker.ardour.org/file_download.php?file_id=4140&type=bug
png
Notes
(0026219)
x42   
2021-11-20 11:41   
Could you provide an Arodur session or .mid file that causes this?

I cannot explain this, nor reproduce it. CC parameter changes are only sent when there is a value change (see ACE MIDI Monitor)
(0026220)
rohanlean   
2021-11-20 13:13   
My setup is as follows:

Ardour 6.9 (flathub, commit 0bdbac43f4bfcdacb69bc5f61d8dbd0ffa01e4ef893553be676877b00147351f),
sfizz 1.1.1 (flathub, runtime 21.08, commit a7bc503d34572af978b163d9f6f6fb04c95790622936f06a2fa9b0884e6a1d83),
Salamander Grand Piano ( https://github.com/sfzinstruments/SalamanderGrandPiano , commit f974189f4d12c99f4f214aadfb4538faf7e7f54f)

New Ardour session, new MIDI track with sfizz, Salamander loaded in sfizz; add an automation lane for controller 64.

Simply witching the automation lane from Manual to Play (no need to start playback) causes
the track to emit constant low level noise, and for sfizz to show 32-37 voices playing at once.

Increasing the the trigger level for the pedal noise from 0 to 1, as here: https://github.com/sfzinstruments/SalamanderGrandPiano/pull/3/files
resolves this.

Oddly enough for me the ACE MIDI Monitor shows no MIDI messages from the automation lane at all. I am probably using it wrong.
(0026224)
paul   
2021-11-22 18:06   
could you check what the mode selection for the CC lane (right click on the CC track header) ?
(0026225)
rohanlean   
2021-11-22 18:47   
On the previous automation track, which I had added through

  Automation > Processor automation > sfizz > Parameters 65-96 > Controller 64

I see no mode selection. But I have now noticed that there is also

  Automation > Controllers > 64: Sus Pedal > Channel 1

which shows discrete mode, only has states Off and Play, and **does not have this problem**.

Does that mean this is a bug in sfizz?
(0026226)
paul   
2021-11-22 19:08   
Right click on automation track header. A menu will appear that has "Mode" at the bottom.
(0026227)
x42   
2021-11-22 19:32   
> Does that mean this is a bug in sfizz?
We have too little information, and also some imprecise info on the subject.

Could you create a session that produces the problem. save and .zip it up and share it? That would be helpful.

Does anyone else also have this issue? Have sfizz authors been able to reduce it?
(0026228)
rohanlean   
2021-11-22 19:48   
I thought that after my last post the instructions for reproduction were unambiguous, but I have attached a project per your request;
also a screenshot which shows that no "Mode" entry appears in the menu for me.
(0026229)
paul   
2021-11-22 21:21   
I have now debugged this with sfizz and salamander from current git, and I'm extremely certain that it's a bug in sfizz. Ardour does not send repeat messages, and sfizz' behavior is not replicated by other synths that are sustain-pedal aware (e.g. Pianoteq with a piano model that has a loud pedal noise).
(0026230)
paul   
2021-11-22 21:24   
I also just tested this using an actual sustain pedal. If the pedal is held down, the pedal "noise" (i used an amplifier to hear it more clearly) plays continuously until I release the pedal.
(0026231)
rohanlean   
2021-11-22 22:03   
Thank you. I will raise the issue with the sfizz developers.

Just to help my understanding, if such questions are appropriate here:

The Automation > Controllers lane is part of the MIDI data and generates messages in a standardised way,
whereas the Automation > Processor automation lane is separate and sends floating point numbers to
sfizz via some plugin interface, generating the floating point numbers by linearly interpolating (time, value)
pairs and sending an update to sfizz every frame (?) where the floating point value compares unequal to the last one?
(0026232)
paul   
2021-11-22 23:41   
(Last edited: 2021-11-22 23:42)
When the CC lane is in Mode > Discrete there is zero interpolation at all. Ardour simply sends individual CC events, the same ones displayed as control points in the lane display. It sends no data that was not recorded or explicitly drawn for the CC track.

When the CC lane is in Mode > Linear, Ardour will interpolate between the points (linear interpolation) and sends a new (potentially interpolated) value periodically. It will not resend the same value, ever.

In both cses, no floating point numbers are involved. The CC track display/represents actual CC messages, and Ardour delivers CC messages to the plugin as MIDI data. This is quite different from generalized plugin automation (which is not CC data, and is presented as floating point).

I do not know why your version of Ardour does not show the Mode option in that context menu. My impression is that it's not an official Ardour build, which makes it harder to offer support for issues like that.

(0026233)
x42   
2021-11-23 15:52   
@paul : the label is "sfizz Controller 064" which is a plugin parameter (and hence float). Also note the automation label "Manual"

MIDI CC lanes show "Damper Pedal" (depending on MIDNAM) but neither track or plugin label. That also explains why there is "Manual" (and not "Off").
(0026234)
x42   
2021-11-23 15:54   
One explanation would be an internal conflict in sfizz. Plugin-parameter (Controller 064) vs. MIDI data CC64.
A plugin must only ever expose one, otherwise there can be ambiguities.
(0026235)
paulfd   
2021-11-24 13:22   
So this is a plugin parameter automation track and not a MIDI one is that it? In this case, does Ardour send the current parameter value in each block for example? Does the same thing happen if you actually automate the CC64 track?

The underlying behavior is that you can have a voice play when receiving a CC message with value in a certain range. This is typically used by piano libraries for sustain pedal noises.

Robin is probably onto something however. Since sfizz allows user-defined parameters beyond the actual number of CCs in the midi spec, and with higher-than-7-bit resolution, these are advertised as plugins parameters, and the first 127 are bound to midi in the VST3 plugin, and (should be) marked with `midi:binding` in the LV2 spec. However the latter has proven problematic because if the host doesn't support the `midi:binding` annotation, you have the terrible UX of having your sustain pedal basically do nothing until you manually bind "plugin parameter 64" to "input midi CC 64". If this is the issue, I'll just remove the first 127 parameters from the LV2 until the binding is more common.
(0026236)
paul   
2021-11-24 16:05   
I've described what happens with the "actual" MIDI CC 64 controller, both via automation in ardour and also when using a physical sustain pedal.

When I get a chance, I'll check the sfizz "exported" Controller064 parameter.
(0026237)
x42   
2021-11-25 18:59   
> In this case, does Ardour send the current parameter value in each block for example?

In case of VST3 automation playback: Yes, implicit curve points at the end of each cycle are always queued explicitly.

This applied to the dashed circles in the diagram:
https://developer.steinberg.help/display/VST/Parameters+and+Automation#ParametersandAutomation-AutomationPlayback

This is something on our long list of VST3 things to tweak. Since one can do arbitrary locations or change the loop-point while looping, the only sane way
to determine if implicit points have to be transmitted is compare the value with a the most recently sent value (and unset it if automation playback mode changed).
Since a plugin will have to do this anyway internally in order to dezipper control parameters, I opted to not implement the discrimination logic in the host, assuming no harm is done my making the curve explicit.
(0026238)
rohanlean   
2021-11-25 20:45   
A somewhat off topic observation here is that Ardour seems to continually pass arguments even while playback is paused. In general I have noticed that Ardour uses more resources than necessary while "idle". I understand that things could happen even then, and that because Ardour does not know what plugins are up to it may be difficult to determine just when nothing is happening. So maybe this issue cannot be solved completely, but any improvements would be nice. Then one does not have to worry so much about leaving Ardour running in the background, especially on a mobile device.

One example I noticed is that simply adding some MIDI tracks without any plugins seems to increase idle resource usage significantly, and I see absolutely no reason for that.

I can open a new issue about idle resource usage if you want.
(0026239)
x42   
2021-11-25 21:00   
> One example I noticed is that simply adding some MIDI tracks without any plugins seems to increase idle resource usage significantly, and I see absolutely no reason for that.

That should not be the case, at least there should not be any significant DSP load increase after the first track.
But yes, by design Ardour's mixer is never idle and constantly processes, like a hardware mixer would. One benefit of that is that the load is constant.

> A somewhat off topic observation here is that Ardour seems to continually pass arguments even while playback is paused.

Not arguments, only port parameters.
The MIDI event-list is sparse and those are discrete events. The plugin should really use MIDI CCs and not expose a control port for those.
I know VST3 makes this complicated and many plugin-devs despise Steinberg's implementation, but at least conceptually it's sound.
(0026240)
paulfd   
2021-11-25 21:22   
> I opted to not implement the discrimination logic in the host, assuming no harm is done my making the curve explicit

Another fix would be for sfizz to disregard controller events that match the current controller state. I'll check if this is indeed what happens in other SFZ implementations and do so if necessary.

> The plugin should really use MIDI CCs and not expose a control port for those.

Technically it's an LV2 parameter :)

> I know VST3 makes this complicated and many plugin-devs despise Steinberg's implementation, but at least conceptually it's sound.

I've come to like it because it avoid such headaches to be honest. If anything, I'd like to be able to capture all channels at once for a given controller.
Anyway I think we can agree the fixes are probably more on sfizz's side so I'll get back to you guys if needed, thanks for your time!
(0026241)
rohanlean   
2021-11-25 21:27   
> One benefit of that is that the load is constant.

That may be true for Ardour itself, but for some popular plugins at least it appears to be false. So I do not think one can reliably judge if the hardware can handle a particular setup just by looking at idle usage, in which case I see only two direct user-facing benefits to any significant idle usage at all: potentially better latency and less overhead under load. Of course users may indirectly benefit from a simpler implementation in other ways.
(0026242)
x42   
2021-11-25 21:32   
> Technically it's an LV2 parameter :)

In this case Ardour will *not* repeat the parameter change.
This is only done for VST3, because the spec demands the value to be sent at the end of each cycle so a plugin can internally interpolate.
(0026243)
x42   
2021-11-25 21:49   
> but for some popular plugins at least it appears to be false.

sadly, yes. This is where pro-audio plugin vendors go to great length to make difference. When live on stage, for FOH mixes, or during a recording-session with a client reliability is key.

> I see only two direct user-facing benefits to any significant idle usage at all: potentially better latency and less overhead under load.

Latency is not affected by this at all. -- Well, if the load is lower, you could use a smaller block-size. But as soon as the system is not idle anymore that is no longer an option.

In case of Ardour, the "overhead" is only to do metering and apply gain (trim and fader). There is dedicated asm code for both of those operations, and one can easily use 1000 tracks without significant DSP load (unless you use the debug version, not an optimized build, which might explain what you're seeing).

Anyway, this is not something that can be changed. This was an early design decision that is deeply ingrained in Ardour's processing engine.
(0026249)
rohanlean   
2021-11-26 12:13   
> unless you use the debug version, not an optimized build, which might explain what you're seeing

I have just checked. The relevant flags that I could see in the Waf output were `-O3 -g -DNDEBUG`, so I am using an optimised build. The DSP load as reported by Ardour indeed does not increase, but adding 8 MIDI tracks to an empty project roughly doubles the CPU use of Ardour reported by `top` (the value is fluctuating in both cases), independently of whether the Ardour windows are visible or not.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8885 [ardour] bugs minor always 2022-02-27 22:49 2022-07-08 16:22
Reporter: mtemmerm Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: AKAI MPK249 midi map not working as expected (new maps included)
Description: There are some issues with the current midi map (e.g. switches need to be pressed twice to toggle solo on/off). I made new ones, one that uses the switches to toggle solo on/off, one that toggles mute on/off (my preference).
Tags: control surface
Steps To Reproduce: When using the current AKAI MPK249 midi map, press a switch twice to toggle solo on/off, this is not as it should be.
Additional Information: Changed clt to ctl-toggle in the midi map, and also set the Master fader to the Modwheel on the controller instead of the last fader in bank C. It's a bit of a hack, but I find it better this way.
System Description
Attached Files: AKAI_MPK249-mute.map (4,975 bytes) 2022-02-27 22:49
https://tracker.ardour.org/file_download.php?file_id=4163&type=bug
AKAI_MPK249-solo.map (4,975 bytes) 2022-02-27 22:49
https://tracker.ardour.org/file_download.php?file_id=4164&type=bug
AKAI_MPK249-mute-2.map (5,068 bytes) 2022-02-28 15:08
https://tracker.ardour.org/file_download.php?file_id=4165&type=bug
AKAI_MPK249-solo-2.map (5,068 bytes) 2022-02-28 15:08
https://tracker.ardour.org/file_download.php?file_id=4166&type=bug
Notes
(0026338)
mtemmerm   
2022-02-28 15:08   
Updated the midi maps: these have strip 8 on bank C as the master control strip, using the modwheel for volume will conflict and was dumb of me.
(0026497)
x42   
2022-07-08 11:50   
The solo-2.map seem to be identical to the the existing map, but changes "ctl" to "ctl-toggle" for the solo toggles.
Does it supersede the existing AKAI_MPK249.map ?
(0026498)
mtemmerm   
2022-07-08 16:22   
Hi x42! I set it to ctl-toggle so I don't have to press it twice, that was mostly what it did 'wrong' IMO. I'm afraid I don't know quite how to answer your question though... it supersedes it on my computer, as I overwrote the file, but I'm not a dev, just a Linux-using musician :).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7768 [ardour] features minor N/A 2019-06-22 02:10 2022-07-04 04:22
Reporter: jeffbrown Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI warp: linearly stretch the timing of MIDI events in a region
Description: # Linear MIDI warping

In Ableton Live you can "warp" audio -- you might take a 2 second clip of sound, and stretch it so that what used to be the first half of the clip occupies the first 90%, and what used to be the second half occupies the remaining 10%.

Doing that with audio seems hard, and I'm not asking for it. But similarly warping MIDI is dead simple, at least mathematically (see below). And surprisingly, Ableton do not offer it.

This feature would let the user add "warp marks" to a point in the MIDI timeline, and then drag them around. Dragging a warp mark causes a linear stretching of the events around it, while keeping the other warp marks fixed.


## One reason you might want to do this

Suppose you record without a metronome, and your left hand always slams down a particular chord X at the start of the beat. If you stuck a warp mark at the start of each X, you could then drag those marks around to change the tempo of what you played locally, while preserving the rhythm.

Among other possibilities, this lets you add a click track after you've recorded without one. That's valuable because many players find it easier to be more creative without a click track.


## The math

Suppose the user has drawn three warp marks, at times `a`, `b0` and `c`, where `a < b0 < c`. Suppose the user then drags the middle marker from the old time `b0` to the new time `b1`.

No MIDI events before `a` or after `c` will be affected by the move. (For warp purposes, the start and end of a note are treated as two separate MIDI events.)

Consider a MIDI event which, before `b0` is warped to `b1`, occurs at time `t0`, where `a < t0 < b0`. After warping, this event will occur at time `t1`, where
```
t1 = (t0 - a) * (b1 - a) / (b0 - a) + a
```

Similarly, if `b0 < t0 < c`, then after `b0` is warped to `b1`, an event which used to occur at time `t0` will now occur at time `t1`, where
```
t1 = c - (c - t0) * (c - b1) / (c - b0)
```

Those formulas work regardless of whether the middle marker is dragged forward or backward.
Tags: Midi
Steps To Reproduce:
Additional Information: If my description is not clear, I could try making some animations and upload them to Youtube.
System Description
Attached Files:
Notes
(0020806)
x42   
2019-11-01 01:16   
Thanks for the elaborate suggestion. The description is clear, but it's not something that can be implemented in the near future.

The problem here is at a different level: "t" in your case is just some abstract continuous time unit.

Ardour's engine handles currently uses a ratio for audio time (when events actually are played to the soundcard): N / sample-rate.
While music-time (bar/beat/ticks) and a tempo-map is currently use double-precision floating point value (mainly for the benefit of exponential tempo-ramps).
GUI Edits can happen at independent music-time units (e.g. move one bar forward, and backwards) and should be lossless.

The problem is that there is no bijective map between the different time-domains, mainly due to rounding issues.

There are some plans to move to a common high-precision time-base ratio ("superclock") to return to some sane state of linear algebra. There are also some thoughts how to represent music-time: https://ardour.org/timing.html but this is a deep change and will likely not happen before Ardour7.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8932 [ardour] bugs minor always 2022-06-29 16:49 2022-06-29 16:58
Reporter: afranke Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: midnam Values not taken into account for automation ranges
Description: On a MIDI track, I set it to Novation A Station and add an automation on controller 3 (Arp Pattern). I then get a slider that goes from 0 to 127.

Looking at the matching MIDNAM file (shipped with Ardour), I see that the values are supposed to be between 0 and 5. Ardour ignores that range.

The 6 values also have names in a ValueNameList, but those aren’t displayed anywhere, as far I can see. Is this also ignored?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026491)
x42   
2022-06-29 16:58   
Ardour only uses Midnam for annotation, not to constrain parameter-ranges.
Looking at the source-code, the value-names should be displayed in the verbose cursor (when hovering over an automation point).

I agree that the value-names should ideally also be displayed on the Fader-Control itself.

I am unsure about constraining the range (and showing it as dropdown). One can change the name-document on the fly and CCs range is not really constrained.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8931 [ardour] features feature N/A 2022-06-24 17:23 2022-06-28 06:09
Reporter: tmu Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Lock Position of everything Audio
Description: Would it be possible to lock the position of audio (and MIDI) but have anything else (region boundaries, automation, ...) movable?

I could imagine a second Lock Mode ("Lock Audio"?) or some checkboxes somewhere to select which items to lock in Lock Mode.
Tags: editing, lock
Steps To Reproduce:
Additional Information: My usual work with Ardour/Mixbus is editing live recordings. So there’s no Grid and none of the Audio should ever move, once it is in place. A lot of the editing is deleting the parts where the instrument on the specific channel doesn't play: Noone needs to hear the drumset over the Backing Vocals SM58 all the time. This means a lot of selecting, splitting and moving the region boundaries.

But often the regions move a tiny bit when I only want to select them. Of course, that doesn’t happen in Lock Mode, but then I cannot move anything.
System Description
Attached Files:
Notes
(0026489)
chance_favre   
2022-06-26 11:36   
I agree, for the same reasons -- editing live recordings. Thanks.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8893 [ardour] bugs minor always 2022-03-26 14:03 2022-06-18 12:40
Reporter: johne53 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cue page crash when monitoring changes
Description: Mixbus v8 can be made to crash quite easily in the new Cues page...
Tags:
Steps To Reproduce: - Select a clip in the new Cues page (preferably one that's 20 secs length or more)
- Click on "/2" to change its BPM
- Click on the icon to start playback
- Pressing the "Master" button a few times will cause MB to crash (disappear from the screen)

If the crash doesn't happen, press "x2" or "/2" again. It'll usually happen very soon.
Additional Information: Has only been found on Windows so far.
System Description
Attached Files: Mixbus32C-8.0.17-crash-1648312824.txt (7,180 bytes) 2022-03-26 16:53
https://tracker.ardour.org/file_download.php?file_id=4173&type=bug
Notes
(0026361)
x42   
2022-03-26 16:27   
Is there a file in %localappdata%\Mixbus8\CrashLog\ ?
(0026362)
johne53   
2022-03-26 16:53   
I just recreated the crash here and yes, it generated a crash log (attached). It looks like the problem is in 'RubberBand::RingBuffer<float>::write<float>'

Possibly a problem with buffer size or alignment? It doesn't happen if I don't keep assigning and unassigning 'Mstr'.

BTW - the issue was initially reported by user PBuryk over on the Mixbus forum.
(0026484)
johne53   
2022-06-18 12:40   
Am I right in thinking this got fixed (I can't reproduce it now...)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8927 [ardour] other minor always 2022-06-15 22:47 2022-06-15 22:47
Reporter: prokoudine Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI markers and region markers have different look and function
Description: MIDI markers and region markers serve pretty much the same purpose. However, they differ in their location, rendering style, and ability to be edited. It could be worth revisiting them to see if all that needs a unification of sorts, in both form and function.

Also, since audio files can have built-in markers too, the checkbox in the importing dialog should probably named in a more general way?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8924 [ardour] documentation text always 2022-06-12 14:29 2022-06-15 13:33
Reporter: jkbd Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: low OS Version: (any)  
Status: resolved Product Version: 6.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Print Bindings (to you webbrowser)" contains wrong bindings
Description: The HTML contains for example:

```
{ --------------------------Set Punch from Selection
{ --------------------------Set Loop from Selection
```

which mismatches the true bindings:

```
[ --------------------------Set Punch from Selection
] --------------------------Set Loop from Selection
```

I have not checked all the other bindings.
Tags:
Steps To Reproduce: Hit Alt-K. Click on the "Print Bindings" button and look into the Editor Window section.
Additional Information: This is independent from the local language. I tried English and German.
System Description
Attached Files:
Notes
(0026481)
x42   
2022-06-15 13:33   
Fixed in 7.0-pre0-2973-g047296060f

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8832 [ardour] bugs minor always 2021-12-02 17:58 2022-06-09 16:36
Reporter: rohanlean Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when percussive MIDI note is placed at end of region
Description: Selecting "Note Mode > Percussive" on a MIDI track and then placing a note at the very end of a region (using grid snapping) crashes Ardour.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: ardour_midi_backtrace.txt (6,416 bytes) 2022-06-09 16:36
https://tracker.ardour.org/file_download.php?file_id=4194&type=bug
Notes
(0026389)
paul   
2022-04-16 00:39   
Please read http://ardour.org/debugging_ardour and try to provide a backtrace for this crash.
(0026480)
rohanlean   
2022-06-09 16:36   
Apologies for the belated response. I have attached a backtrace.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8922 [ardour] bugs major always 2022-06-07 14:15 2022-06-07 14:15
Reporter: xav Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Beginning of the recording is missing when using Jack transport
Description: When recording a Hydrogen stereo drums track using Jack transport, the recording start is delayed by 55ms (see picture).
Tags: jack, recording
Steps To Reproduce: Create a stereo "Drums" track
Connect this track with the stereo output of Hydrogen
Enable JACK transport in Ardour.
Set Ardour as JACK master.
Enable JACK transport in Hydrogen ("J. TRANS" icon).
In Ardour, set the timeline to the beginning.
Make the recording.
Additional Information: Jack 1.9.20
Hydrogen 1.1.1
System Description
Attached Files: ardour_bug.png (80,525 bytes) 2022-06-07 14:15
https://tracker.ardour.org/file_download.php?file_id=4193&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8916 [ardour] bugs major always 2022-05-29 17:31 2022-05-31 19:13
Reporter: rpatros Platform: Arch  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.9  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6.9 not able to close when closing the program
Description: Unable to close Ardour 6.9 when closing the program. It just hangs and does not close and then after some time, I get a warning message saying:

This window might be busy and is not responding. Do you want to terminate the application?

Ardour 6.9 not able to close when closing the program.
Tags: GUI, unable to close ardour
Steps To Reproduce: Running Arch linux running Kernel 5.15.41-1-lts

1. I have a project that I have 2 audio tracks, 1 midi track and 2 buses.
2. My problem is that when trying to close Ardour program, it just hangs and does not close and then after some time, I get a warning message saying:

This window might be busy and is not responding. Do you want to terminate the application?

3. Started jack without Realtime and then started ardour in gdb using the following command:

ardour6 --gdb
Additional Information: gdb output when the project was opened and after attempting to close the application:

[rpatros@patros-pc tmp]$ ardour6 --gdb
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/ardour6/ardour-6.9.0...
(No debugging symbols found in /usr/lib/ardour6/ardour-6.9.0)
(gdb)
(gdb) run
Starting program: /usr/lib/ardour6/ardour-6.9.0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Ardour6.9.0 (built using 6.9 and GCC version 11.2.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /etc/ardour6/system_config
Ardour: [INFO]: Loading user configuration file /home/rpatros/.config/ardour6/config
[New Thread 0x7ffff0afe640 (LWP 111540)]
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
Ardour: [INFO]: Using AVX optimized routines
[New Thread 0x7fffebfff640 (LWP 111541)]
[New Thread 0x7fffe3fff640 (LWP 111542)]
[New Thread 0x7fffeb7fe640 (LWP 111543)]
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour6/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/rpatros/.config/ardour6/plugin_metadata/plugin_stats
[New Thread 0x7fffeaffd640 (LWP 111544)]
[Thread 0x7fffeaffd640 (LWP 111544) exited]
[New Thread 0x7fffeaffd640 (LWP 111545)]
[New Thread 0x7fffea2a9640 (LWP 111546)]
[New Thread 0x7fffe9993640 (LWP 111547)]
Ardour: [INFO]: Loading default ui configuration file /etc/ardour6/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/rpatros/.config/ardour6/ui_config
Ardour: [INFO]: Loading 452 MIDI patches from /usr/share/ardour6/patchfiles
[New Thread 0x7fffe9121640 (LWP 111548)]
[Thread 0x7fffe9121640 (LWP 111548) exited]
[New Thread 0x7fffe9121640 (LWP 111549)]
[New Thread 0x7fffe8920640 (LWP 111550)]
[Thread 0x7fffe9121640 (LWP 111549) exited]
[New Thread 0x7fffe9121640 (LWP 111551)]
[New Thread 0x7fffe36f6640 (LWP 111552)]
[Thread 0x7fffe36f6640 (LWP 111552) exited]
[Thread 0x7fffe9121640 (LWP 111551) exited]
[Thread 0x7fffe8920640 (LWP 111550) exited]
[New Thread 0x7fffe8920640 (LWP 111553)]
[New Thread 0x7fffe36f6640 (LWP 111554)]
[New Thread 0x7fffe9121640 (LWP 111555)]
[New Thread 0x7fffe2ef5640 (LWP 111556)]
[Thread 0x7fffe2ef5640 (LWP 111556) exited]
[New Thread 0x7fffe2ef5640 (LWP 111557)]
Ardour: [INFO]: Loading color file /usr/share/ardour6/themes/dark-ardour.colors
[Thread 0x7fffe2ef5640 (LWP 111557) exited]
Ardour: [INFO]: Loading ui configuration file /etc/ardour6/clearlooks.rc
[New Thread 0x7fffe2ef5640 (LWP 111558)]
[New Thread 0x7fffe2647640 (LWP 111559)]
[Thread 0x7fffe2ef5640 (LWP 111558) exited]
[New Thread 0x7fffe2ef5640 (LWP 111560)]
[New Thread 0x7fffe1e46640 (LWP 111561)]
[Thread 0x7fffe2ef5640 (LWP 111560) exited]
[New Thread 0x7fffe2ef5640 (LWP 111562)]
[New Thread 0x7fffe1645640 (LWP 111563)]
[Thread 0x7fffe2647640 (LWP 111559) exited]
[New Thread 0x7fffe2647640 (LWP 111564)]
[Thread 0x7fffe2ef5640 (LWP 111562) exited]
[New Thread 0x7fffe2ef5640 (LWP 111565)]
[Thread 0x7fffe1e46640 (LWP 111561) exited]
Ardour: [INFO]: Loading bindings from /etc/ardour6/ardour.keys
Loading ui configuration file /etc/ardour6/clearlooks.rc
[Thread 0x7fffe1645640 (LWP 111563) exited]
[Thread 0x7fffe2647640 (LWP 111564) exited]
[Thread 0x7fffe2ef5640 (LWP 111565) exited]
[New Thread 0x7fffe2ef5640 (LWP 111566)]
[New Thread 0x7fffe2647640 (LWP 111567)]
[Thread 0x7fffe2ef5640 (LWP 111566) exited]
[New Thread 0x7fffe2ef5640 (LWP 111568)]
[New Thread 0x7fffe1645640 (LWP 111569)]
[Thread 0x7fffe2ef5640 (LWP 111568) exited]
[New Thread 0x7fffe2ef5640 (LWP 111570)]
[New Thread 0x7fffe1e46640 (LWP 111571)]
[Thread 0x7fffe2ef5640 (LWP 111570) exited]
[Thread 0x7fffe2647640 (LWP 111567) exited]
[Thread 0x7fffe1645640 (LWP 111569) exited]
[New Thread 0x7fffe0e44640 (LWP 111572)]
[New Thread 0x7fffe0c45640 (LWP 111573)]
[Thread 0x7fffe1e46640 (LWP 111571) exited]
[Thread 0x7fffe0c45640 (LWP 111573) exited]
[Thread 0x7fffe0e44640 (LWP 111572) exited]
[New Thread 0x7fffe0e44640 (LWP 111574)]
[New Thread 0x7fffe0c45640 (LWP 111575)]
[Thread 0x7fffe0c45640 (LWP 111575) exited]
[Thread 0x7fffe0e44640 (LWP 111574) exited]
[New Thread 0x7fffe1e46640 (LWP 111576)]
[New Thread 0x7fffe1645640 (LWP 111577)]
[Thread 0x7fffe1e46640 (LWP 111576) exited]
[New Thread 0x7fffe1e46640 (LWP 111578)]
[Thread 0x7fffe1e46640 (LWP 111578) exited]
[Thread 0x7fffe1645640 (LWP 111577) exited]
[New Thread 0x7fffe1645640 (LWP 111579)]
[New Thread 0x7fffe1e46640 (LWP 111580)]
[Thread 0x7fffe1645640 (LWP 111579) exited]
[Thread 0x7fffe1e46640 (LWP 111580) exited]
[New Thread 0x7fffe1e46640 (LWP 111581)]
[New Thread 0x7fffe1645640 (LWP 111582)]
[New Thread 0x7fffe2ef5640 (LWP 111583)]
[Thread 0x7fffe1645640 (LWP 111582) exited]
[Thread 0x7fffe1e46640 (LWP 111581) exited]
[Thread 0x7fffe2ef5640 (LWP 111583) exited]
[New Thread 0x7fffe2ef5640 (LWP 111584)]
[New Thread 0x7fffe1e46640 (LWP 111585)]
[New Thread 0x7fffe1645640 (LWP 111586)]
[New Thread 0x7fffe2647640 (LWP 111587)]
[Thread 0x7fffe1645640 (LWP 111586) exited]
[New Thread 0x7fffe1645640 (LWP 111588)]
[New Thread 0x7fffb3fff640 (LWP 111589)]
[Thread 0x7fffe1645640 (LWP 111588) exited]
[Thread 0x7fffe2647640 (LWP 111587) exited]
[Thread 0x7fffb3fff640 (LWP 111589) exited]
[Thread 0x7fffe9121640 (LWP 111555) exited]
[Thread 0x7fffe2ef5640 (LWP 111584) exited]
[Thread 0x7fffe9993640 (LWP 111547) exited]
[New Thread 0x7fffe1645640 (LWP 111590)]
[New Thread 0x7fffe1446640 (LWP 111591)]
[New Thread 0x7fffe13c5640 (LWP 111592)]
Scanning folders for bundled LV2s: /usr/lib/ardour6/LV2
[New Thread 0x7fffe2ef5640 (LWP 111593)]
[New Thread 0x7fffe9121640 (LWP 111594)]
[New Thread 0x7fffb3fff640 (LWP 111595)]
[Thread 0x7fffe9121640 (LWP 111594) exited]
[Thread 0x7fffb3fff640 (LWP 111595) exited]
Set cursor set to default
[New Thread 0x7fffb3fff640 (LWP 111596)]
[New Thread 0x7fffe9121640 (LWP 111597)]
[Thread 0x7fffb3fff640 (LWP 111596) exited]
[New Thread 0x7fffb3fff640 (LWP 111598)]
[New Thread 0x7fffe2647640 (LWP 111599)]
[Thread 0x7fffb3fff640 (LWP 111598) exited]
[Thread 0x7fffe9121640 (LWP 111597) exited]
[Thread 0x7fffe2647640 (LWP 111599) exited]
[New Thread 0x7fffe2647640 (LWP 111600)]
[New Thread 0x7fffe9121640 (LWP 111601)]
[Thread 0x7fffe2647640 (LWP 111600) exited]
[Thread 0x7fffe9121640 (LWP 111601) exited]
[New Thread 0x7fffe9121640 (LWP 111602)]
[New Thread 0x7fffe2647640 (LWP 111603)]
[Thread 0x7fffe9121640 (LWP 111602) exited]
[New Thread 0x7fffe9121640 (LWP 111604)]
[New Thread 0x7fffb3fff640 (LWP 111605)]
[Thread 0x7fffe9121640 (LWP 111604) exited]
[Thread 0x7fffe2647640 (LWP 111603) exited]
[Thread 0x7fffb3fff640 (LWP 111605) exited]
[Thread 0x7fffe2ef5640 (LWP 111593) exited]
[New Thread 0x7fffe2ef5640 (LWP 111606)]
[New Thread 0x7fffb3fff640 (LWP 111607)]
[Thread 0x7fffe2ef5640 (LWP 111606) exited]
[New Thread 0x7fffe2ef5640 (LWP 111608)]
[New Thread 0x7fffe9121640 (LWP 111609)]
[Thread 0x7fffb3fff640 (LWP 111607) exited]
[Thread 0x7fffe2ef5640 (LWP 111608) exited]
[Thread 0x7fffe9121640 (LWP 111609) exited]
[New Thread 0x7fffe9121640 (LWP 111610)]
[New Thread 0x7fffe2ef5640 (LWP 111611)]
[Thread 0x7fffe9121640 (LWP 111610) exited]
[Thread 0x7fffe2ef5640 (LWP 111611) exited]
[New Thread 0x7fffe2ef5640 (LWP 111612)]
[New Thread 0x7fffe9121640 (LWP 111613)]
[Thread 0x7fffe2ef5640 (LWP 111612) exited]
[Thread 0x7fffe9121640 (LWP 111613) exited]
[New Thread 0x7fffe0f85a00 (LWP 111614)]
[New Thread 0x7fffe0f79a00 (LWP 111615)]
[New Thread 0x7fffe0f6da00 (LWP 111616)]
[New Thread 0x7fffe0f62640 (LWP 111617)]
[New Thread 0x7fffe0ee1640 (LWP 111618)]
[New Thread 0x7fffe0e60640 (LWP 111619)]
[New Thread 0x7fffe9121640 (LWP 111620)]
[New Thread 0x7fffe2ef5640 (LWP 111621)]
[Thread 0x7fffe9121640 (LWP 111620) exited]
[New Thread 0x7fffe9121640 (LWP 111622)]
[New Thread 0x7fffb3fff640 (LWP 111623)]
[Thread 0x7fffe2ef5640 (LWP 111621) exited]
[Thread 0x7fffe9121640 (LWP 111622) exited]
[New Thread 0x7fffe9121640 (LWP 111624)]
[New Thread 0x7fffe2ef5640 (LWP 111625)]
[Thread 0x7fffb3fff640 (LWP 111623) exited]
[Thread 0x7fffe9121640 (LWP 111624) exited]
[New Thread 0x7fffe9121640 (LWP 111626)]
[New Thread 0x7fffb3fff640 (LWP 111627)]
[Thread 0x7fffe2ef5640 (LWP 111625) exited]
[Thread 0x7fffe9121640 (LWP 111626) exited]
[Thread 0x7fffb3fff640 (LWP 111627) exited]
[New Thread 0x7fffb2c74640 (LWP 111628)]
[New Thread 0x7fffb3fff640 (LWP 111629)]
[New Thread 0x7fffe9121640 (LWP 111630)]
ALSA lib pcm_dsnoop.c:601:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
[New Thread 0x7fffa559f640 (LWP 111631)]
[New Thread 0x7fffa551e640 (LWP 111632)]
[Thread 0x7fffa551e640 (LWP 111632) exited]
[Thread 0x7fffa559f640 (LWP 111631) exited]
ALSA lib pcm_dsnoop.c:601:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
[New Thread 0x7fffa559f640 (LWP 111633)]
[New Thread 0x7fffa551e640 (LWP 111634)]
[Thread 0x7fffa551e640 (LWP 111634) exited]
[Thread 0x7fffa559f640 (LWP 111633) exited]
Creating a blank synth
ALSA lib pcm_dsnoop.c:601:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
[New Thread 0x7fffa559f640 (LWP 111635)]
[New Thread 0x7fffa551e640 (LWP 111636)]
[Thread 0x7fffa551e640 (LWP 111636) exited]
[Thread 0x7fffa559f640 (LWP 111635) exited]
Calling configure on soundfont
Loading /home/rpatros/Music/SoundFonts2/SF2/25-piano-sf/25 Piano Soundfonts/Motif ES6 Concert Piano.SF2
ALSA lib pcm_dsnoop.c:601:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
[New Thread 0x7fffa559f640 (LWP 111637)]
[New Thread 0x7fffa551e640 (LWP 111638)]
[Thread 0x7fffa551e640 (LWP 111638) exited]
[Thread 0x7fffa559f640 (LWP 111637) exited]
[New Thread 0x7fffe2ef5640 (LWP 111639)]
[New Thread 0x7fffe2647640 (LWP 111640)]
[New Thread 0x7fff87fff640 (LWP 111641)]
fluidsynth: warning: No preset found on channel 9 [bank=128 prog=0]
sid=1
Calling configure on preset_key_set
Calling configure on preset_key_set2
Calling configure on preset_key_set3
Calling configure on preset_key_set4
Calling configure on preset_key_set5
Calling configure on preset_key_set6
Calling configure on preset_key_set7
Calling configure on preset_key_set8
Calling configure on preset_key_set9
Calling configure on preset_key_set10
Calling configure on preset_key_set11
Calling configure on preset_key_set12
Calling configure on preset_key_set13
Calling configure on preset_key_set14
Calling configure on preset_key_set15
Calling configure on preset_key_set16
[New Thread 0x7fff85105640 (LWP 111642)]
[New Thread 0x7fff84904640 (LWP 111643)]
fluidsynth: warning: Instrument not found on channel 0 [bank=0 prog=14], substituted [bank=0 prog=0]
[New Thread 0x7fff73fff640 (LWP 111644)]
[New Thread 0x7fff73745640 (LWP 111645)]
[New Thread 0x7fff72f44640 (LWP 111646)]
[Thread 0x7fff73745640 (LWP 111645) exited]
[Thread 0x7fff72f44640 (LWP 111646) exited]
Reading player:ACE Fluid Synth took 5006 microseconds, final size = 9662
[New Thread 0x7fff72f44640 (LWP 111647)]
[New Thread 0x7fff73745640 (LWP 111648)]
[Thread 0x7fff72f44640 (LWP 111647) exited]
[Thread 0x7fff73745640 (LWP 111648) exited]
[New Thread 0x7fff73745640 (LWP 111649)]
[New Thread 0x7fff72f44640 (LWP 111650)]
[Thread 0x7fff73745640 (LWP 111649) exited]
[New Thread 0x7fff73745640 (LWP 111651)]
[New Thread 0x7fff72743640 (LWP 111652)]
[Thread 0x7fff72f44640 (LWP 111650) exited]
[Thread 0x7fff73745640 (LWP 111651) exited]
[New Thread 0x7fff73745640 (LWP 111653)]
[Thread 0x7fff72743640 (LWP 111652) exited]
[New Thread 0x7fff72743640 (LWP 111654)]
[Thread 0x7fff73745640 (LWP 111653) exited]
[New Thread 0x7fff73745640 (LWP 111655)]
[New Thread 0x7fff72f44640 (LWP 111656)]
[Thread 0x7fff73745640 (LWP 111655) exited]
[Thread 0x7fff72743640 (LWP 111654) exited]
[Thread 0x7fff72f44640 (LWP 111656) exited]
[New Thread 0x7fff72f44640 (LWP 111657)]
[New Thread 0x7fff72743640 (LWP 111658)]
[Thread 0x7fff72f44640 (LWP 111657) exited]
[New Thread 0x7fff72f44640 (LWP 111659)]
[New Thread 0x7fff73745640 (LWP 111660)]
[Thread 0x7fff72f44640 (LWP 111659) exited]
[Thread 0x7fff72743640 (LWP 111658) exited]
[Thread 0x7fff73745640 (LWP 111660) exited]
[New Thread 0x7fff73745640 (LWP 111661)]
[New Thread 0x7fff72743640 (LWP 111662)]
[New Thread 0x7fff72f44640 (LWP 111663)]
[Thread 0x7fffe1e46640 (LWP 111585) exited]
CALF DEBUG: instance 0x55555c3f3610 data 0x55555bc56ef8
CALF DEBUG: calf 0x7fffb12e6630 cpi 0x7fffb0aebd60
CALF DEBUG: instance 0x55555b73d400 data 0x55555905db58
CALF DEBUG: calf 0x7fffb12e6630 cpi 0x7fffb0aebd60
CALF DEBUG: instance 0x5555595d8320 data 0x555558eac428
CALF DEBUG: calf 0x7fffb12e6690 cpi 0x7fffb0aebbb0
[New Thread 0x7fffe1e46640 (LWP 111685)]
[New Thread 0x7fff71a8a640 (LWP 111686)]
[Thread 0x7fffe1e46640 (LWP 111685) exited]
[New Thread 0x7fffe1e46640 (LWP 111687)]
[New Thread 0x7fff71289640 (LWP 111688)]
[Thread 0x7fff71a8a640 (LWP 111686) exited]
[Thread 0x7fffe1e46640 (LWP 111687) exited]
[New Thread 0x7fffe1e46640 (LWP 111689)]
[New Thread 0x7fff71a8a640 (LWP 111690)]
[Thread 0x7fff71289640 (LWP 111688) exited]
[Thread 0x7fffe1e46640 (LWP 111689) exited]
[New Thread 0x7fffe1e46640 (LWP 111691)]
[New Thread 0x7fff71289640 (LWP 111692)]
[Thread 0x7fff71a8a640 (LWP 111690) exited]
[Thread 0x7fffe1e46640 (LWP 111691) exited]
[New Thread 0x7fffe1e46640 (LWP 111693)]
[New Thread 0x7fff71a8a640 (LWP 111694)]
[Thread 0x7fffe1e46640 (LWP 111693) exited]
[Thread 0x7fff71289640 (LWP 111692) exited]
[Thread 0x7fff71a8a640 (LWP 111694) exited]
[New Thread 0x7fff71a8a640 (LWP 111695)]
[New Thread 0x7fffe1e46640 (LWP 111696)]
[New Thread 0x7fff71289640 (LWP 111697)]
[New Thread 0x7fff4f430640 (LWP 111698)]
[Thread 0x7fff71289640 (LWP 111697) exited]
[New Thread 0x7fff71289640 (LWP 111699)]
[New Thread 0x7fff4ec2f640 (LWP 111700)]
[Thread 0x7fff4f430640 (LWP 111698) exited]
[Thread 0x7fff71289640 (LWP 111699) exited]
[Thread 0x7fff4ec2f640 (LWP 111700) exited]
[New Thread 0x7fff4ec2f640 (LWP 111701)]
[New Thread 0x7fff71289640 (LWP 111702)]
[Thread 0x7fff4ec2f640 (LWP 111701) exited]
[Thread 0x7fff71289640 (LWP 111702) exited]
[Thread 0x7fffe1e46640 (LWP 111696) exited]
[Thread 0x7fff71a8a640 (LWP 111695) exited]
[New Thread 0x7fff71a8a640 (LWP 111712)]
[New Thread 0x7fffe1e46640 (LWP 111713)]
[Thread 0x7fff71a8a640 (LWP 111712) exited]
[New Thread 0x7fff71a8a640 (LWP 111714)]
[New Thread 0x7fff71289640 (LWP 111715)]
[Thread 0x7fffe1e46640 (LWP 111713) exited]
[Thread 0x7fff71a8a640 (LWP 111714) exited]
[Thread 0x7fff71289640 (LWP 111715) exited]
[Thread 0x7fff84904640 (LWP 111643) exited]
Butler drops pool trash
[Thread 0x7fffb2c74640 (LWP 111628) exited]
[Thread 0x7fffe0e60640 (LWP 111619) exited]
[Thread 0x7fffe0ee1640 (LWP 111618) exited]
[Thread 0x7fffe0f62640 (LWP 111617) exited]
[Thread 0x7fff72f44640 (LWP 111663) exited]
[Thread 0x7fff72743640 (LWP 111662) exited]
[Thread 0x7fff73745640 (LWP 111661) exited]
[Thread 0x7fff73fff640 (LWP 111644) exited]
[Thread 0x7fff85105640 (LWP 111642) exited]
[Thread 0x7fffb3fff640 (LWP 111629) exited]
[Thread 0x7fffe0f6da00 (LWP 111616) exited]
[Thread 0x7fffe0f79a00 (LWP 111615) exited]
[Thread 0x7fffe0f85a00 (LWP 111614) exited]
[Thread 0x7fffe9121640 (LWP 111630) exited]
[Thread 0x7fff87fff640 (LWP 111641) exited]
[Thread 0x7fffe2647640 (LWP 111640) exited]
[Thread 0x7fffe13c5640 (LWP 111592) exited]
[Thread 0x7fffe1446640 (LWP 111591) exited]
[Thread 0x7fffe1645640 (LWP 111590) exited]
[Thread 0x7fffe36f6640 (LWP 111554) exited]
[Thread 0x7fffe8920640 (LWP 111553) exited]
[Thread 0x7fffea2a9640 (LWP 111546) exited]
[Thread 0x7fffe2ef5640 (LWP 111639) exited]
[Thread 0x7fffeaffd640 (LWP 111545) exited]
[Thread 0x7fffeb7fe640 (LWP 111543) exited]
[Thread 0x7fffe3fff640 (LWP 111542) exited]
[Thread 0x7fffebfff640 (LWP 111541) exited]
[Thread 0x7ffff106ea00 (LWP 111537) exited]
[Thread 0x7ffff0afe640 (LWP 111540) exited]
[New process 111537]

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb)
System Description
Attached Files: ardour_error.png (182,535 bytes) 2022-05-29 17:34
https://tracker.ardour.org/file_download.php?file_id=4191&type=bug
png

gdb.zip (4,159 bytes) 2022-05-30 15:28
https://tracker.ardour.org/file_download.php?file_id=4192&type=bug
Notes
(0026463)
rpatros   
2022-05-29 17:34   
Here is the error received
(0026464)
x42   
2022-05-29 17:39   
```
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb)
```

How was this killed?

Can you instead get a backtrace from when Ardour hangs, as described at https://discourse.ardour.org/t/ardour-hanging-at-shutdown/107260/11
Thanks
(0026465)
rpatros   
2022-05-29 18:08   
Hello x42,

Thank you for the quick reply, here is the bt:


[rpatros@patros-pc tmp]$ ardour6 --gdb
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/ardour6/ardour-6.9.0...
(No debugging symbols found in /usr/lib/ardour6/ardour-6.9.0)
(gdb) run
Starting program: /usr/lib/ardour6/ardour-6.9.0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Ardour6.9.0 (built using 6.9 and GCC version 11.2.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /etc/ardour6/system_config
Ardour: [INFO]: Loading user configuration file /home/rpatros/.config/ardour6/config
[New Thread 0x7ffff0afe640 (LWP 119202)]
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
Ardour: [INFO]: Using AVX optimized routines
[New Thread 0x7fffebfff640 (LWP 119203)]
[New Thread 0x7fffeb7fe640 (LWP 119204)]
[New Thread 0x7fffeaffd640 (LWP 119205)]
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour6/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/rpatros/.config/ardour6/plugin_metadata/plugin_stats
[New Thread 0x7fffea7fc640 (LWP 119206)]
[Thread 0x7fffea7fc640 (LWP 119206) exited]
[New Thread 0x7fffea7fc640 (LWP 119207)]
[New Thread 0x7fffe9aa8640 (LWP 119208)]
[New Thread 0x7fffe9192640 (LWP 119209)]
Ardour: [INFO]: Loading default ui configuration file /etc/ardour6/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/rpatros/.config/ardour6/ui_config
Ardour: [INFO]: Loading 452 MIDI patches from /usr/share/ardour6/patchfiles
[New Thread 0x7fffe8920640 (LWP 119210)]
[Thread 0x7fffe8920640 (LWP 119210) exited]
[New Thread 0x7fffe8920640 (LWP 119211)]
[New Thread 0x7fffcbfff640 (LWP 119212)]
[Thread 0x7fffe8920640 (LWP 119211) exited]
[New Thread 0x7fffe8920640 (LWP 119213)]
[New Thread 0x7fffcb6f6640 (LWP 119214)]
[Thread 0x7fffe8920640 (LWP 119213) exited]
[Thread 0x7fffcb6f6640 (LWP 119214) exited]
[Thread 0x7fffcbfff640 (LWP 119212) exited]
[New Thread 0x7fffcbfff640 (LWP 119215)]
[New Thread 0x7fffcb6f6640 (LWP 119216)]
[New Thread 0x7fffe8920640 (LWP 119217)]
[New Thread 0x7fffcadd2640 (LWP 119218)]
[Thread 0x7fffcadd2640 (LWP 119218) exited]
[New Thread 0x7fffcadd2640 (LWP 119219)]
Ardour: [INFO]: Loading color file /usr/share/ardour6/themes/dark-ardour.colors
[Thread 0x7fffcadd2640 (LWP 119219) exited]
Ardour: [INFO]: Loading ui configuration file /etc/ardour6/clearlooks.rc
[New Thread 0x7fffcadd2640 (LWP 119220)]
[New Thread 0x7fffca5d1640 (LWP 119221)]
[Thread 0x7fffcadd2640 (LWP 119220) exited]
[New Thread 0x7fffcadd2640 (LWP 119222)]
[New Thread 0x7fffc9dd0640 (LWP 119223)]
[Thread 0x7fffcadd2640 (LWP 119222) exited]
[New Thread 0x7fffcadd2640 (LWP 119224)]
[New Thread 0x7fffc95cf640 (LWP 119225)]
[Thread 0x7fffca5d1640 (LWP 119221) exited]
[Thread 0x7fffcadd2640 (LWP 119224) exited]
[New Thread 0x7fffcadd2640 (LWP 119226)]
[New Thread 0x7fffca5d1640 (LWP 119227)]
[Thread 0x7fffc9dd0640 (LWP 119223) exited]
[Thread 0x7fffcadd2640 (LWP 119226) exited]
Ardour: [INFO]: Loading bindings from /etc/ardour6/ardour.keys
Loading ui configuration file /etc/ardour6/clearlooks.rc
[Thread 0x7fffc95cf640 (LWP 119225) exited]
[New Thread 0x7fffc95cf640 (LWP 119228)]
[New Thread 0x7fffcadd2640 (LWP 119229)]
[Thread 0x7fffca5d1640 (LWP 119227) exited]
[Thread 0x7fffc95cf640 (LWP 119228) exited]
[New Thread 0x7fffc95cf640 (LWP 119230)]
[New Thread 0x7fffca5d1640 (LWP 119231)]
[Thread 0x7fffcadd2640 (LWP 119229) exited]
[Thread 0x7fffc95cf640 (LWP 119230) exited]
[New Thread 0x7fffc95cf640 (LWP 119232)]
[New Thread 0x7fffcadd2640 (LWP 119233)]
[Thread 0x7fffca5d1640 (LWP 119231) exited]
[Thread 0x7fffc95cf640 (LWP 119232) exited]
[Thread 0x7fffcadd2640 (LWP 119233) exited]
[New Thread 0x7fffc8dce640 (LWP 119234)]
[New Thread 0x7fffc8c09640 (LWP 119235)]
[Thread 0x7fffc8c09640 (LWP 119235) exited]
[Thread 0x7fffc8dce640 (LWP 119234) exited]
[New Thread 0x7fffc8dce640 (LWP 119236)]
[New Thread 0x7fffc8c09640 (LWP 119237)]
[Thread 0x7fffc8c09640 (LWP 119237) exited]
[Thread 0x7fffc8dce640 (LWP 119236) exited]
[New Thread 0x7fffcadd2640 (LWP 119238)]
[New Thread 0x7fffc95cf640 (LWP 119239)]
[Thread 0x7fffcadd2640 (LWP 119238) exited]
[New Thread 0x7fffcadd2640 (LWP 119240)]
[New Thread 0x7fffca5d1640 (LWP 119241)]
[Thread 0x7fffcadd2640 (LWP 119240) exited]
[Thread 0x7fffc95cf640 (LWP 119239) exited]
[New Thread 0x7fffc95cf640 (LWP 119242)]
[New Thread 0x7fffcadd2640 (LWP 119243)]
[Thread 0x7fffca5d1640 (LWP 119241) exited]
[Thread 0x7fffc95cf640 (LWP 119242) exited]
[New Thread 0x7fffc95cf640 (LWP 119244)]
[New Thread 0x7fffca5d1640 (LWP 119245)]
[Thread 0x7fffc95cf640 (LWP 119244) exited]
[Thread 0x7fffcadd2640 (LWP 119243) exited]
[Thread 0x7fffca5d1640 (LWP 119245) exited]
[New Thread 0x7fffca5d1640 (LWP 119246)]
[New Thread 0x7fffcadd2640 (LWP 119247)]
[New Thread 0x7fffc95cf640 (LWP 119248)]
[New Thread 0x7fffc9dd0640 (LWP 119249)]
[Thread 0x7fffc95cf640 (LWP 119248) exited]
[New Thread 0x7fffc95cf640 (LWP 119250)]
[New Thread 0x7fffb3fff640 (LWP 119251)]
[Thread 0x7fffc95cf640 (LWP 119250) exited]
[Thread 0x7fffc9dd0640 (LWP 119249) exited]
[Thread 0x7fffb3fff640 (LWP 119251) exited]
[Thread 0x7fffe8920640 (LWP 119217) exited]
[Thread 0x7fffca5d1640 (LWP 119246) exited]
[Thread 0x7fffe9192640 (LWP 119209) exited]
[New Thread 0x7fffc95cf640 (LWP 119252)]
[New Thread 0x7fffc93d0640 (LWP 119253)]
[New Thread 0x7fffc934f640 (LWP 119254)]
Scanning folders for bundled LV2s: /usr/lib/ardour6/LV2
[New Thread 0x7fffca5d1640 (LWP 119255)]
[New Thread 0x7fffe8920640 (LWP 119256)]
[New Thread 0x7fffb3fff640 (LWP 119257)]
[Thread 0x7fffe8920640 (LWP 119256) exited]
[Thread 0x7fffb3fff640 (LWP 119257) exited]
Set cursor set to default
[New Thread 0x7fffb3fff640 (LWP 119258)]
[New Thread 0x7fffe8920640 (LWP 119259)]
[Thread 0x7fffb3fff640 (LWP 119258) exited]
[New Thread 0x7fffb3fff640 (LWP 119260)]
[New Thread 0x7fffc9dd0640 (LWP 119261)]
[Thread 0x7fffb3fff640 (LWP 119260) exited]
[Thread 0x7fffe8920640 (LWP 119259) exited]
[Thread 0x7fffc9dd0640 (LWP 119261) exited]
[New Thread 0x7fffc9dd0640 (LWP 119262)]
[New Thread 0x7fffe8920640 (LWP 119263)]
[Thread 0x7fffc9dd0640 (LWP 119262) exited]
[Thread 0x7fffe8920640 (LWP 119263) exited]
[New Thread 0x7fffe8920640 (LWP 119264)]
[New Thread 0x7fffc9dd0640 (LWP 119265)]
[Thread 0x7fffe8920640 (LWP 119264) exited]
[New Thread 0x7fffe8920640 (LWP 119266)]
[New Thread 0x7fffb3fff640 (LWP 119267)]
[Thread 0x7fffc9dd0640 (LWP 119265) exited]
[Thread 0x7fffe8920640 (LWP 119266) exited]
[Thread 0x7fffb3fff640 (LWP 119267) exited]
[Thread 0x7fffcadd2640 (LWP 119247) exited]
[New Thread 0x7fffcadd2640 (LWP 119268)]
[New Thread 0x7fffb3fff640 (LWP 119269)]
[Thread 0x7fffcadd2640 (LWP 119268) exited]
[New Thread 0x7fffcadd2640 (LWP 119270)]
[New Thread 0x7fffe8920640 (LWP 119271)]
[Thread 0x7fffcadd2640 (LWP 119270) exited]
[Thread 0x7fffb3fff640 (LWP 119269) exited]
[New Thread 0x7fffb3fff640 (LWP 119272)]
[New Thread 0x7fffcadd2640 (LWP 119273)]
[Thread 0x7fffe8920640 (LWP 119271) exited]
[Thread 0x7fffb3fff640 (LWP 119272) exited]
[Thread 0x7fffcadd2640 (LWP 119273) exited]
[New Thread 0x7fffcadd2640 (LWP 119274)]
[New Thread 0x7fffb3fff640 (LWP 119275)]
[Thread 0x7fffcadd2640 (LWP 119274) exited]
[Thread 0x7fffb3fff640 (LWP 119275) exited]
[New Thread 0x7fffc8f2ca00 (LWP 119276)]
[New Thread 0x7fffc8f20a00 (LWP 119277)]
[New Thread 0x7fffc8f14a00 (LWP 119278)]
[New Thread 0x7fffc8f09640 (LWP 119279)]
[New Thread 0x7fffc8e88640 (LWP 119280)]
[New Thread 0x7fffc8e07640 (LWP 119281)]
[New Thread 0x7fffb3fff640 (LWP 119282)]
[New Thread 0x7fffcadd2640 (LWP 119283)]
[Thread 0x7fffb3fff640 (LWP 119282) exited]
[New Thread 0x7fffb3fff640 (LWP 119284)]
[New Thread 0x7fffe8920640 (LWP 119285)]
[Thread 0x7fffcadd2640 (LWP 119283) exited]
[New Thread 0x7fffb3fff640 (LWP 119286)]
[Thread 0x7fffb3fff640 (LWP 119284) exited]
[New Thread 0x7fffcadd2640 (LWP 119287)]
[Thread 0x7fffe8920640 (LWP 119285) exited]
[Thread 0x7fffb3fff640 (LWP 119286) exited]
[New Thread 0x7fffb3fff640 (LWP 119288)]
[New Thread 0x7fffe8920640 (LWP 119289)]
[Thread 0x7fffcadd2640 (LWP 119287) exited]
[Thread 0x7fffb3fff640 (LWP 119288) exited]
[Thread 0x7fffe8920640 (LWP 119289) exited]
[New Thread 0x7fffb2d75640 (LWP 119290)]
[New Thread 0x7fffe8920640 (LWP 119291)]
[WRN] Found standard VST 2.x chunk header (bank)
[New Thread 0x7fffb3fff640 (LWP 119292)]
ALSA lib pcm_dsnoop.c:601:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
[New Thread 0x7fffa1040640 (LWP 119293)]
[New Thread 0x7fffa0fbf640 (LWP 119294)]
[Thread 0x7fffa0fbf640 (LWP 119294) exited]
[Thread 0x7fffa1040640 (LWP 119293) exited]
ALSA lib pcm_dsnoop.c:601:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
[New Thread 0x7fffa1040640 (LWP 119295)]
[New Thread 0x7fffa0fbf640 (LWP 119296)]
[Thread 0x7fffa0fbf640 (LWP 119296) exited]
[Thread 0x7fffa1040640 (LWP 119295) exited]
Creating a blank synth
ALSA lib pcm_dsnoop.c:601:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
[New Thread 0x7fffa1040640 (LWP 119297)]
[New Thread 0x7fffa0fbf640 (LWP 119298)]
[Thread 0x7fffa0fbf640 (LWP 119298) exited]
[Thread 0x7fffa1040640 (LWP 119297) exited]
Calling configure on soundfont
Loading /home/rpatros/Music/SoundFonts2/SF2/25-piano-sf/25 Piano Soundfonts/Motif ES6 Concert Piano.SF2
ALSA lib pcm_dsnoop.c:601:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM hdmi
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline:CARD=0,DEV=0
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib confmisc.c:1369:(snd_func_refer) Unable to find definition 'cards.0.pcm.modem.0:CARD=0'
ALSA lib conf.c:5178:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5701:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2664:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib pcm_dmix.c:1032:(snd_pcm_dmix_open) unable to open slave
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pulse.so (/usr/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
[New Thread 0x7fffa1040640 (LWP 119299)]
[New Thread 0x7fffa0fbf640 (LWP 119300)]
[Thread 0x7fffa0fbf640 (LWP 119300) exited]
[Thread 0x7fffa1040640 (LWP 119299) exited]
[New Thread 0x7fffcadd2640 (LWP 119301)]
[New Thread 0x7fffc9dd0640 (LWP 119302)]
[New Thread 0x7fff83fff640 (LWP 119303)]
fluidsynth: warning: No preset found on channel 9 [bank=128 prog=0]
sid=1
Calling configure on preset_key_set
Calling configure on preset_key_set2
Calling configure on preset_key_set3
Calling configure on preset_key_set4
Calling configure on preset_key_set5
Calling configure on preset_key_set6
Calling configure on preset_key_set7
Calling configure on preset_key_set8
Calling configure on preset_key_set9
Calling configure on preset_key_set10
Calling configure on preset_key_set11
Calling configure on preset_key_set12
Calling configure on preset_key_set13
Calling configure on preset_key_set14
Calling configure on preset_key_set15
Calling configure on preset_key_set16
[New Thread 0x7fff837fe640 (LWP 119304)]
[New Thread 0x7fff82ffd640 (LWP 119305)]
[New Thread 0x7fff827fc640 (LWP 119306)]
[New Thread 0x7fff81ffb640 (LWP 119307)]
[New Thread 0x7fff817fa640 (LWP 119308)]
fluidsynth: warning: Instrument not found on channel 0 [bank=0 prog=14], substituted [bank=0 prog=0]
[Thread 0x7fff81ffb640 (LWP 119307) exited]
restarting Session::update_latency. # of send changes: 8 iteration: 1
[Thread 0x7fff817fa640 (LWP 119308) exited]
Reading player:ACE Fluid Synth took 5869 microseconds, final size = 9662
[New Thread 0x7fff817fa640 (LWP 119309)]
[New Thread 0x7fff81ffb640 (LWP 119310)]
[Thread 0x7fff817fa640 (LWP 119309) exited]
[Thread 0x7fff81ffb640 (LWP 119310) exited]
[New Thread 0x7fff81ffb640 (LWP 119311)]
[New Thread 0x7fff817fa640 (LWP 119312)]
[Thread 0x7fff81ffb640 (LWP 119311) exited]
[New Thread 0x7fff81ffb640 (LWP 119313)]
[New Thread 0x7fff80ff9640 (LWP 119314)]
[Thread 0x7fff81ffb640 (LWP 119313) exited]
[Thread 0x7fff817fa640 (LWP 119312) exited]
[New Thread 0x7fff817fa640 (LWP 119315)]
[New Thread 0x7fff81ffb640 (LWP 119316)]
[Thread 0x7fff817fa640 (LWP 119315) exited]
[Thread 0x7fff80ff9640 (LWP 119314) exited]
[New Thread 0x7fff80ff9640 (LWP 119317)]
[New Thread 0x7fff817fa640 (LWP 119318)]
[Thread 0x7fff80ff9640 (LWP 119317) exited]
[Thread 0x7fff81ffb640 (LWP 119316) exited]
[Thread 0x7fff817fa640 (LWP 119318) exited]
[New Thread 0x7fff817fa640 (LWP 119319)]
[New Thread 0x7fff81ffb640 (LWP 119320)]
[Thread 0x7fff817fa640 (LWP 119319) exited]
[New Thread 0x7fff817fa640 (LWP 119321)]
[New Thread 0x7fff80ff9640 (LWP 119322)]
[Thread 0x7fff81ffb640 (LWP 119320) exited]
[Thread 0x7fff817fa640 (LWP 119321) exited]
[Thread 0x7fff80ff9640 (LWP 119322) exited]
[New Thread 0x7fff80ff9640 (LWP 119323)]
[New Thread 0x7fff817fa640 (LWP 119324)]
[New Thread 0x7fff81ffb640 (LWP 119325)]
[New Thread 0x7fff63fff640 (LWP 119327)]
[New Thread 0x7fff637fe640 (LWP 119328)]
[Thread 0x7fff63fff640 (LWP 119327) exited]
[New Thread 0x7fff63fff640 (LWP 119329)]
[New Thread 0x7fff62ffd640 (LWP 119330)]
[Thread 0x7fff637fe640 (LWP 119328) exited]
[Thread 0x7fff63fff640 (LWP 119329) exited]
[Thread 0x7fff62ffd640 (LWP 119330) exited]
[Thread 0x7fffca5d1640 (LWP 119255) exited]
[Thread 0x7fff82ffd640 (LWP 119305) exited]
Butler drops pool trash
[Thread 0x7fffb2d75640 (LWP 119290) exited]
[Thread 0x7fff827fc640 (LWP 119306) exited]
[Thread 0x7fffc8e07640 (LWP 119281) exited]
[Thread 0x7fffc8e88640 (LWP 119280) exited]
[Thread 0x7fffc8f09640 (LWP 119279) exited]
[Thread 0x7fff81ffb640 (LWP 119325) exited]
[Thread 0x7fff817fa640 (LWP 119324) exited]
[Thread 0x7fff80ff9640 (LWP 119323) exited]
[Thread 0x7fff837fe640 (LWP 119304) exited]
[Thread 0x7fffe8920640 (LWP 119291) exited]
[Thread 0x7fffc8f14a00 (LWP 119278) exited]
[Thread 0x7fffc8f20a00 (LWP 119277) exited]
[Thread 0x7fffc8f2ca00 (LWP 119276) exited]
[Thread 0x7fffb3fff640 (LWP 119292) exited]
^C
Thread 1 "ArdourGUI" received signal SIGINT, Interrupt.
0x00007ffff571a119 in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff571a119 in () at /usr/lib/libc.so.6
0000001 0x00007ffff571f113 in () at /usr/lib/libc.so.6
#2 0x00007ffff3d18326 in () at /usr/lib/libjack.so.0
#3 0x00007ffff3cf823c in () at /usr/lib/libjack.so.0
0000004 0x00007ffff3cf7149 in () at /usr/lib/libjack.so.0
0000005 0x00007ffff3d1bd75 in jack_client_close () at /usr/lib/libjack.so.0
#6 0x00007fffe91a8e70 in ARDOUR::JackConnection::close() () at /usr/lib/ardour6/backends/libjack_audiobackend.so
#7 0x00007fffe91a923b in ARDOUR::JACKAudioBackend::stop() () at /usr/lib/ardour6/backends/libjack_audiobackend.so
0000008 0x00007ffff77e64ee in ARDOUR::AudioEngine::stop(bool) () at /usr/lib/ardour6/libardour.so.3
0000009 0x00005555559b87f7 in ()
0000010 0x00005555559ee138 in ()
0000011 0x00007ffff70d59e6 in () at /usr/lib/libglibmm-2.4.so.1
0000012 0x00007ffff6f37163 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
0000013 0x00007ffff6f8d9e9 in () at /usr/lib/libglib-2.0.so.0
0000014 0x00007ffff6f366a3 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#15 0x00007ffff6bb09fe in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0
0000016 0x00007ffff7251d5d in Gtkmm2ext::UI::run(Receiver&) () at /usr/lib/ardour6/libgtkmm2ext.so.0
#17 0x000055555597b8f3 in main ()
(gdb)
(0026466)
rpatros   
2022-05-29 18:45   
I also want to share that when using ALSA as the backend engine for Ardour, the application can be closed without any issues but with Jack as the backend, I encounter the issue. I am hoping that the backtrace gathered is helpful enough to identify the root cause.
(0026467)
x42   
2022-05-30 13:22   
Thank you. It seems to be an issue with jack. The application hangs calling jack_client_close().

Which version of jack are you using?
(0026468)
x42   
2022-05-30 13:42   
Also do you start jackd before starting Ardour, or does Ardour start jackd for you?
(0026469)
x42   
2022-05-30 14:00   
Since the hang is effectively in libc.so.6 it could also be indirectly caused by a glibc update. Which libc version do you have installed?
(0026470)
Daniele1971   
2022-05-30 15:28   
Here openSUSE TW, glibc-2.35
gdb output generated with ardour-7.pre0.2870-debug, attacched.

Duet to some connection issue, did not dowload the debuinfo packages. Let me know if I have to do it again with debuginfo packages installed.
(0026471)
rpatros   
2022-05-30 15:53   
x42, to answer the questions:

1. Version of Jack is jack2:

[rpatros@patros-pc ~]$ jackd --version
jackdmp version 1.9.21 tmpdir /dev/shm protocol 9

2. Yes I do start jack before starting ardour.

3. The glibc version that I am running is 2.35-5

[rpatros@patros-pc ~]$ sudo pacman -Q | grep glibc
glibc 2.35-5
lib32-glibc 2.35-5

Hope this helps.
(0026472)
rpatros   
2022-05-30 16:12   
x42,

Here is a simple screen sharing that I took yesterday, where you can see that first I started ardour using ALSA and it was able to close the app, then I switch to jack, then attempted to close the app and it hangs:

https://odysee.com/@rpatros:4/Ardour69_bug_upon_closure:d
(0026474)
thomastommySpammer   
2022-05-31 07:18   
good
(0026475)
paul   
2022-05-31 14:21   
confirmed as caused by changes in glibc.
(0026476)
x42   
2022-05-31 18:14   
upstream bug https://sourceware.org/bugzilla/show_bug.cgi?id=29214
libjack is affected by this -- Ardour itself is not.
The glibc release 2.35.0 is not affected, but current git 2.35.xx as currently shipped by some bleeding edge distros has this issue.
(0026477)
x42   
2022-05-31 19:13   
Fix is available upstream at glibc.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5846 [ardour] features feature N/A 2014-01-30 18:09 2022-05-26 21:55
Reporter: bruno Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 3.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Filter freesound search results by license
Description: The idea is to be able to filter search results in the Freesound tab by type of license (for example, "show me Public Domain files only", "show me CC-BY only", etc).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026462)
colinf   
2022-05-26 21:55   
I've had a go at implementing this in eae1673f: scope for improvement still, but at least it's a start...

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7449 [ardour] bugs minor always 2017-08-16 14:11 2022-05-23 14:14
Reporter: magnetophon Platform: linux  
Assigned To: OS: NixOS  
Priority: normal OS Version: 17.09pre  
Status: new Product Version: 5.10  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: shift click fader in group reverses link behavior
Description: When I shift click on a fader to reset its gain to 0dB, it messes up:
if the group is enabled, the other faders in the group stay where they are, if the group is disabled the gains are linked.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6493 [ardour] bugs major always 2015-07-31 10:41 2022-05-21 21:03
Reporter: dlp Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 4.X git (version in description)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Freesound import broken
Description: Common search terms - e.g. drums, loop. techno, etc - return nothing in the Freesound import dialog. Verified on repetition.
Tags:
Steps To Reproduce:
Additional Information: Ardour4.1.446 (built using 4.1-465-g67c75c5 and GCC version 4.8.3 20140911 (Red Hat 4.8.3-7))
Attached Files:
Notes
(0026449)
colinf   
2022-05-20 13:44   
Freesound APIv2 implemented in 9fe0a4f4

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6197 [ardour] features minor N/A 2015-03-10 00:11 2022-05-20 22:25
Reporter: x42 Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: freesound import needs to be updated to new FS API
Description: just a TODO reminder.. see summary.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 0001-New-DebugBit-for-Freesound.patch (1,277 bytes) 2016-01-19 12:04
https://tracker.ardour.org/file_download.php?file_id=2851&type=bug
0002-Update-to-Freesound-API-v2-search-only.patch (11,131 bytes) 2016-01-19 12:05
https://tracker.ardour.org/file_download.php?file_id=2852&type=bug
0003-Freesound-abuse-previews-to-get-some-kind-of-downloa.patch (6,032 bytes) 2016-01-19 12:05
https://tracker.ardour.org/file_download.php?file_id=2853&type=bug
0004-Freesound-s-api_key-token-g.patch (3,110 bytes) 2016-01-19 12:05
https://tracker.ardour.org/file_download.php?file_id=2854&type=bug
Notes
(0017809)
colinf   
2016-01-19 01:10   
I have the search part of this nearly working already, but the Freesound APIv2 now requires OAuth in order to download sound files, so we're going to have to provide a means for users to log into their own Freesound accounts in Ardour if they want to download anything.

Not necessarily a big deal, but it is a bit more hassle than I hoped for. On the bright side, once I understand OAuth I can maybe make Soundcloud upload use it as well. Hopefully I'll have time to carry on looking at this soon.
(0017810)
colinf   
2016-01-19 12:02   
For the moment now, I've hacked it to download the high-quality OGG preview when clicking on an item in the search results. That's not ideal, but I reckon is (marginally) better than nothing for the moment
(0017929)
colinf   
2016-02-13 23:14   
Utterly hacky but basically working implementation now pushed to freesound-apiv2 branch.

The concept may well be too ugly to live; even if it's not deemed totally unacceptable there's a lot of tidying still to be done there, but I hope it's at least a starting point.
(0017937)
timbyr   
2016-02-15 12:55   
I pulled and tested the freesound-apiv2 branch and it seems to work OK.

I haven't got any comments about code as yet but one small detail would be to set the focus on the "OK" button in the CredentialsDialog(or whatever you called it) and also that authorization occasionally seems to take some time(I noticed perhaps 15 seconds) so it may be worth having a progress bar.

Perhaps a progress bar could be added to the credentials dialog if that doesn't look too weird as that will also allow access to the Cancel button.

If I input the incorrect username and password there is no indication of failure and it appears that it will just play the last file that successfully downloaded.
(0017942)
colinf   
2016-02-15 13:52   
(Last edited: 2016-02-15 18:10)
timbyr: thanks for testing!

Yes, the CredentialsDialog (can you think of a better name? I almost called it LoginDialog) really ought to have the <Enter> key act as 'OK'. I shall make it so. [EDIT] Done.

A progress bar is a nice idea. I'm not sure that it should be part of the credentials dialogue: I have a feeling it might be a bit weird that 'OK' doesn't dismiss the dialogue immediately, but I suppose if it gave you the chance to re-enter a mistyped user name or password it might make some sense.

And yes, it really ought to report login failures somehow. I'm not sure what the best way to proceed in that case would be either: I had an idea that we could just download the .OGG preview file if the user doesn't provide valid freesound login details, but I'd like to know what others think of that.

(0017943)
timbyr   
2016-02-15 21:21   
(Last edited: 2016-02-15 22:38)
Yes, I agree about the progress bar, it doesn't seem appropriate. Some sort of indication like setting the wait cursor would be good eventually but considering there are other long operations in Ardour that don't do this it probably isn't much of a concern at this point.

(0017976)
colinf   
2016-02-20 13:58   
Login progress now appears (as text) in the file download progress bar: this also allows the user to cancel the login.
(0018003)
timbyr   
2016-02-24 02:18   
I just re-tested the latest changes.

I think the login status in progress bar works well but I still think some sort of dialog or something is needed on failure.

The other main issue I noticed is that double clicking on a file will start it downloading, but it will also play the previously downloaded file immediately which is quite confusing.

How hard would it be to have a "use low quality preview" option? As I think it may provide a faster workflow with the reduced download time. I find myself previewing many files but only importing a few of them into the session.

I'm not sure how that would tie into "only download preview on login failure" but personally I don't think it is a good idea to allow importing of low quality preview files.
(0018009)
colinf   
2016-02-24 14:23   
I agree that we need better login failure reporting: I'm not sure a dialogue is the right thing, because it's quite possible to click 'OK' in the credentials dialogue and then carry on with something else while waiting for the login to complete, so popping up an error dialogue might interrupt that, or alternatively be missed. Would putting an error into the 'Log' window be too obscure?

Good point about the double-click, too: I guess it needs to be handled differently in the freesound list view from the other file lists, since in the other tabs the clicked file is available immediately for preview.

I like the idea of just downloading the preview on clicking the file, and only downloading the original full-quality file on request. The best way I can think of at the moment for this would be be an extra column in the file list with a tick box to mark which files are to be downloaded, and then either to download them on clicking 'Import', or via a new 'Download chosen files now' button.
(0019104)
turion   
2016-12-02 20:16   
Is there anything besides C++/C-coding that I can do to make this issue progress further? (Right now I'm basically stalled on my music project because there is no freesound.org import.) I'd be happy to test or debug or give/discuss UI ideas.
(0026448)
colinf   
2022-05-20 13:43   
Done in 9fe0a4f4.
(0026452)
x42   
2022-05-20 22:25   
Implemented in 7.0-pre0-2782-g9fe0a4f4dd Thanks to @colinf

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5847 [ardour] features feature N/A 2014-01-30 18:13 2022-05-20 18:13
Reporter: bruno Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 3.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Display and/or collect attribution info from CC-licensed files from Freesound.org
Description: To facilitate and encourage the user to attribute the source when importing Creative Commons licensed sounds from Freesound.org, Ardour could display attribution info for the selected sound file somewhere in the import window. In addition (or alternatively), it could collect and save a text file with attribution info for all CC-licensed files that were imported into a session from Freesound.org.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6311 [ardour] features tweak always 2015-05-08 21:53 2022-05-20 18:12
Reporter: gremlink Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 4.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Freesound CC license authors
Description: The Freesound import should list authors in some fashion so that appropriate CC licensing credit can be given in works using Freesound material.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3072 [ardour] bugs minor always 2010-04-17 23:01 2022-05-20 13:48
Reporter: kernel_geek Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: SVN/2.0-ongoing  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Freesound password not hidden
Description: When you input password on freesound screen, its not stared out.

Seems a pretty basic thing, for a program.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026451)
colinf   
2022-05-20 13:48   
Pretty sure this was fixed years ago, but it's not even relevant now that Freesound import doesn't log directly into freesound.org any more.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5943 [ardour] bugs major always 2014-06-25 09:09 2022-05-20 13:44
Reporter: ahellquist Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Freesound browser unable to cope with / in the clip name
Description: Searching Freesound sometimes results in clips named for instance:

175586 Dubstep/Wobble Effect 1

That and probably all other tracks will not be playable or possible to import. Nor will the meta information window display tags or audio clip information.

This maybe could be fixed with some regression magic ?

And no: I have no interest in dubstep :-) this i only an academic case
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026450)
colinf   
2022-05-20 13:44   
Probable fix in 40f8dc69

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8909 [ardour] features minor N/A 2022-04-27 16:00 2022-05-15 14:16
Reporter: DopplerNyquist Platform: GNU  
Assigned To: OS: Linux  
Priority: high OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI region decrease saturation when disabled
Description: Sometimes when rearranging a track we need to disable some audio or MIDI regions, and Ardour today only shows a slight different color in the waveform and a simple "!" sign in the MIDI region name.
It would be interesting to have a more pronounced visual feedback of the status of the regions to speed up the work.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20220427_124356.png (223,731 bytes) 2022-04-27 16:02
https://tracker.ardour.org/file_download.php?file_id=4180&type=bug
png
Notes
(0026422)
DopplerNyquist   
2022-04-27 16:02   
Sometimes we have Audio and Midi regions disabled in the same view, but it is difficult to distinguish them.
(0026445)
x42   
2022-05-15 14:16   
Ardour uses transparency to indicate audibly transparent regions (hear data on layers underneath). Also the default track/region-colors are already rather desaturated to be easier on the eye when working long hours.

However thanks to https://github.com/Ardour/ardour/pull/706 the exclamation mark has been replaced with a large "mute" icon which already helps significantly.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8264 [ardour] features minor have not tried 2020-06-22 19:45 2022-05-15 01:20
Reporter: consint Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: More automation modes
Description: It would be very nice if there were other automation modes besides drawing lines.

1. the possibility to draw curves (especially for a faster workflow)
2. an LFO with different shapes
3. a random generator with range adjustment
4. a step sequencer

These tools would be especially useful for music producers and could expand the creative possibilities many times over.
Tags: automation
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024548)
paul   
2020-07-01 16:32   
(4) is under development.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8559 [ardour] features minor N/A 2021-02-01 19:33 2022-05-15 01:19
Reporter: thebutant Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 6.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: Non-linear options for automation lines
Description: I really wish for automation lines that aren't linear, but have curves in some way(s).
Either different modes (preferably), like the modes when fading an audio region in or out, or the possibility to drag automation lines into curves.
My experience from other daws is that curvy automation lines tend to sound more musical and lively than the static linear ones.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025483)
x42   
2021-02-01 19:58   
Keep in mind that the Y-axis may not be linear, but can be logarithmic or exponential, depending on the control.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8910 [ardour] features minor always 2022-05-03 09:10 2022-05-04 13:47
Reporter: johne53 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Strange inverted behaviour with track groups
Description: This was first reported by a Mixbus user but I couldn't reproduce it in Mixbus - however it seems very reproducible in Ardour. Although it refers to tracks, it's easier to see in the Edit window.
Tags:
Steps To Reproduce: 1) Select two Editor tracks and click 'Group->New Group' to add them to a group.
2) Moving one fader will now (correctly) move them both.
3) 'Shift+Move' will (correctly) move only the selected fader.
4) Now select 'Group->Edit Group' and mark the group as inactive.
5) Each fader can now (correctly) be moved independently - i.e. as if they weren't grouped.
6) BUT - 'Shift+Move' now moves both faders.
Additional Information: The Mixbus user found it in MB for Linux (not sure which Linux)
System Description
Attached Files:
Notes
(0026427)
x42   
2022-05-03 18:18   
That is intentional. Shift "inverts" the group behavior.
(0026428)
johne53   
2022-05-04 11:17   
In that case there seems to be an inconsistency between Ardour and Mixbus - namely:-

1) Select two Editor tracks and click 'Group->New Group' to add them to a group.
2) Moving one fader will now (correctly) move them both.
3) 'Shift+Move' will (correctly) move only the selected fader.
4) Now select 'Group->Edit Group' and mark the group as inactive.
5) Each fader can now (correctly) be moved independently - i.e. as if they weren't grouped.
6) And in Ardour - 'Shift+Move' now moves both faders.
7) But in Mixbus - 'Shift+Move' still only moves the selected fader.
(0026429)
johne53   
2022-05-04 11:23   
Sorry, I should have added that items 6) and 7) refer to adjustments made in the Mixer window (adjustments made in the Edit window seem okay)
(0026430)
x42   
2022-05-04 13:47   
(6) Ardour -- is what I expect to happen. Shift + action inverts the group setting: deactivated groups (group-settings) are enabled, and vice versa.

But yes, Mixbus changes various hardcoded modifiers in Route-UI for their mixer-strips. e.g. shift+click does not reset the Mixbus-Faders to default (double-click does).
Mute/Solo buttons group-override is ctrl+click in Ardour, but shift+click for Mixbus. and Solo-isolated toggle is also different ctrl+click in Mixbus...

It is inconsistent since the Ardour widgets retain their original behaviour.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8901 [ardour] bugs minor always 2022-04-16 07:06 2022-04-29 13:09
Reporter: johne53 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Failed to find action: [ClipEditing/zoom-in]
Description: When I launch the latest Mixbus (from a terminal window) and then I load a session, a message appears in the terminal:-

Failed to find action: [ClipEditing/zoom-in]

If I subsequently attempt to zoom the Edit window, MB will usually crash. Or if it doesn't crash immediately, zooming the Edit window and then clicking in the Summary window will usually crash it.
Tags:
Steps To Reproduce:
Additional Information: This was first reported by a Mixbus user although I guess it'll also affect Ardour:-

https://forum.harrisonconsoles.com/thread-10662.html

There are reports that it affects Windows and Linux but not Mac.

And here's where it gets weird... if I copy text to the clipboard from some totally unrelated window (i.e. not even a Mixbus window) my MSVC build displays this text in Mixbus's terminal window:-

Gdk-CRITICAL **: inner_clipboard_window_procedure: assertion 'success' failed
System Description
Attached Files: Waveform-corrupted.png (23,159 bytes) 2022-04-17 08:49
https://tracker.ardour.org/file_download.php?file_id=4175&type=bug
png

Waveform-normal.png (15,672 bytes) 2022-04-17 08:49
https://tracker.ardour.org/file_download.php?file_id=4176&type=bug
png

read_fpp_crash_mac_m1.txt (146,301 bytes) 2022-04-25 15:11
https://tracker.ardour.org/file_download.php?file_id=4177&type=bug
Notes
(0026403)
johne53   
2022-04-16 08:04   
It just occurred to me that the Gdk-CRITICAL error is probably unrelated to the zooming crash.
(0026404)
johne53   
2022-04-17 08:49   
My MSVC build doesn't seem to crash but I've noticed something which might be connected. With some zoom factors, clips are getting drawn normally and with others, they look corrupted.
(0026408)
johne53   
2022-04-18 15:20   
This problem seems to have come sometime between the first MB32C release (8.0.17) and the second release (8.0.106). And given that I'm seeing some waveform issues here I decided to look at the 'waveview' branch and see if anything changed between those releases. I could only see 1 x change (on 28th Feb) which involved 2 x commits to change from using Glib::Threads to PBD::Thread (commits 24bbf403b9 and 50abcc74b5). So this morning I decided to revert those 2 commits and see if it'd fix the waveform problem - which it doesn't.

So it's looking like someone will need to track down the actual crash somehow in gcc
(0026412)
johne53   
2022-04-22 10:54   
An idea occurred to me this morning. As well as building with MSVC, Visual Studio now also supports building with Clang. So I rebuilt this morning and sure enough, Clang crashes in exactly the same way as gcc. What's weird is that each crash is always at a different place in the code but the thing they all have in common is that each crash happens immediately after 'WaveView::process_draw_request()' returns. AFAICT each waveform gets drawn in its own thread so maybe the threads are interfering with each other somehow? Or maybe a draw request is getting deleted before it's been fully processed?

I mentioned earlier that Glib::Threads got changed recently to PBD::Thread - but reverting that change didn't solve the problem. But maybe that one change isn't enough? Perhaps something else would need to get reverted too? I'm just flagging it up here in case it jogs someone's memory...
(0026414)
paul   
2022-04-22 18:13   
We are not using new mutex objects, so the Thread change is not relevant. Also, this crash happens on gcc builds, so it has nothing specifically to do with MSVC.

The warning about a missing action during startup is also a red herring.
(0026418)
BenLoftis   
2022-04-25 15:11   
a zoom+scale crash report from Mac M1 ARM; largely the same as other platforms
(0026425)
johne53   
2022-04-29 13:09   
This got fixed in commit #6f5d3d8dd9, from Apr 26th 2022. It looks like it was just a mis-type when converting from Mutex to RWLock.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8198 [ardour] bugs minor always 2020-06-04 07:11 2022-04-27 14:37
Reporter: Tremeschin Platform: Linux  
Assigned To: paul OS: Arch Linux  
Priority: normal OS Version: Rolling  
Status: resolved Product Version: 6.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Duplicating MIDI notes selection in internal edit does not select all the cloned notes but one
Description: Looks like while Ctrl + clicking + dragging a MIDI note selection to duplicate it, only the bottom-most right-most note is selected after cloning while leaving the other duped notes deselected.
Tags: editing, Midi, notes, select
Steps To Reproduce: 1. Create MIDI region
2. Write two or more notes in it
3. Enter internal edit mode
4. Select two or more notes
5. Ctrl + click + drag to duplicate the notes
6. Drag these duplicated notes to a empty space within the region for better visibility

Now only one note will be selected out of the ones that were duplicated
Additional Information: This is annoying when writing plucks / chords progressions as more often than not you want the notes to be playing repeatedly and not always selecting everything and duplicating fill in all the spots or fits them right.

Ardour compiled locally, commit 378a0af

waf configure -j 6 -p --optimize --cxx11

waf build -j 4 -p

Backed up ~/.config/ardour6.dev and ~/.config/ardour6, deleted and run a blank profile, issue still there.

Issue is present on current ardour 6.0-2 package on my Linux distro (compiled from the community as official releases are paid?)
System Description
Attached Files:
Notes
(0026421)
paul   
2022-04-27 14:37   
fixed in 9e77d8923ac (will be in v7.0)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8422 [ardour] features minor have not tried 2020-09-25 23:50 2022-04-27 08:15
Reporter: wargreen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Live clip launch mechanism
Description: Allow to launch one or many clips (audio or midi) while playing the timeline would be nice.
When a clip launched in single play or loop, the audio (or midi) data would take the place of the data of the timeline in the input of the track and remain in sync with the master beat (or not if defined in the clip). Have a parameter for the behavior at the end of the clip would be an advantage for creative use.

This would allow a live usage of Ardour without use trick in the main timeline.

It's a real mess in the FLOSS world, the only alternative in the "pro" live show world are Live or Qlab.
We are Linux Show Player of SuperBoucle (each with it benefices) but no one come with a full featured mixer, timeline, MIDI clips and OSC interface.
Tags: audio, live, loop, Midi
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026402)
paul   
2022-04-16 02:44   
coming up in ardour 7.0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8908 [ardour] bugs crash sometimes 2022-04-26 19:31 2022-04-26 19:31
Reporter: dannyb Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crashes when exporting to audio file.
Description: 1. So far it happens when exporting the project to an audio file--flac format in these cases.
2. I create a mono project from a template with all LV2 plugins (EQ, Gate, FastLookahead Limiter, Expander, Compressor)
3. I drag and drop one flac file into the template track, reduce the whole region gain by 1 or 2dB, then export it to flack.
4. Usually I do NOT do any editing of the region except the gain. If I do more editing, it seems more likely to crash.
Tags: crash, export audio, mutex
Steps To Reproduce: I cannot directly reproduce the crash, but it tends to happen only while exporting to audio.
Additional Information: OS Info:
Operating System: Fedora Linux 35
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Kernel Version: 5.17.4-200.fc35.x86_64 (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor
Memory: 31.4 GiB of RAM
Graphics Processor: NVIDIA GeForce GT 710/PCIe/SSE2 (proprietary driver installed)
====

Console error message when run from the prompt: (occurs every time it crashes)
Attempt to unlock mutex that was not locked
Aborted (core dumped)
====

I wanted to run a debug version of Ardour, but was not able to just download one. I have the Linux know how to do it, but could not find a "simple" way to do it.
====
System Description
Attached Files: Ardour 6.9 - crash on file export (LWP 71654 gdb backtrace).txt (76,311 bytes) 2022-04-26 19:31
https://tracker.ardour.org/file_download.php?file_id=4178&type=bug
Ardour 6.9 - crash on file export (LWP 97375 gdb backtrace).txt (67,995 bytes) 2022-04-26 19:31
https://tracker.ardour.org/file_download.php?file_id=4179&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8906 [ardour] bugs minor always 2022-04-23 12:41 2022-04-23 18:20
Reporter: teodrolli Platform: Linux  
Assigned To: OS: Arch Linux  
Priority: low OS Version:  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Always switches to newly-saved version
Description: If you "Save AS" current session and uncheck "Switch to newly-saved version" Ardour switches to new version anyway.
Tags:
Steps To Reproduce: Go to Session > Save As...
Uncheck "Switch to newly-saved version"
Click "OK"
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8904 [ardour] bugs crash always 2022-04-22 16:23 2022-04-23 10:54
Reporter: robertaramar Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes after some time
Description: Running Ardour on JACK.
No matter whether buffers are big 512 or small 64.
After some time, I get an exception and Ardour crashes.
I do not get this when running Ardour on ALSA.
As I ususally use ALSA, but did have to use JACK in this particular case, this bug is not really important to me.
I just thought, Ardour shouldn't crash for anything like that.
Tags:
Steps To Reproduce: No particular steps to be taken.
I don't even have to play anything, just launching Ardour with a project and leave it, will crash shortly after one minute (01:09, 01:15).
You have to open a project, having the project selection box open, does not count into that minute.
Additional Information: [Thread 0x7fffaffff640 (LWP 104142) exited]

Thread 25 "audioengine" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc4367640 (LWP 104179)]
0x00007ffff744ce1b in ARDOUR::PortManager::run_input_meters(unsigned int, long) () from /opt/Ardour-6.9.0/lib/libardour.so.3


(gdb) bt
#0 0x00007ffff744ce1b in ARDOUR::PortManager::run_input_meters(unsigned int, long) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000001 0x00007ffff744f62b in ARDOUR::PortManager::cycle_start(unsigned int, ARDOUR::Session*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
#2 0x00007ffff704f722 in ARDOUR::AudioEngine::process_callback(unsigned int) () from /opt/Ardour-6.9.0/lib/libardour.so.3
#3 0x00007fffc71c12fb in ARDOUR::JACKAudioBackend::process_thread() () from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
0000004 0x00007fffdc015414 in non-virtual thunk to Jack::JackClient::Execute() () at ../common/JackClient.cpp:583
0000005 0x00007fffdc0330b0 in Jack::JackPosixThread::ThreadHandler (arg=0x555556a99f98) at ../posix/JackPosixThread.cpp:63
#6 0x00007fffee422b1a in start_thread (arg=<optimized out>) at pthread_create.c:443
#7 0x00007fffee4a7660 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
System Description
Attached Files:
Notes
(0026413)
paul   
2022-04-22 18:11   
Almost certainly caused by JACK "zombifying" Ardour for taking too long when processing audio OR by JACK itself going away.

Will hopefully be fixed in 7.0, but it is actually remarkably difficult for JACK clients as complex as Ardour to respond safely to either of those two conditions.
(0026417)
robertaramar   
2022-04-23 10:54   
Would you think that is something introduced by JACK lately. Because I'm using Ardour 6.9.0 since it came out, I was using it solely on JACK until I switch to using ALSA - roughly - six months ago. And I never had issues with JACK before.
If I can be of help further analyzing that, please let me know.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8890 [ardour] bugs minor always 2022-03-23 18:45 2022-04-21 11:25
Reporter: bmuxbeats Platform: Desktop  
Assigned To: paul OS: Manjaro Linux  
Priority: normal OS Version: 21.2.5  
Status: assigned Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Generic MIDI Binding Maps / bind sysex messages not working
Description: I'm currently creating a new generic MIDI binding map for an AKAI MPK261 MIDI controller.
First of all I want to re-map my transport controlling keys.

According to the dedicated documentation (https://manual.ardour.org/using-control-surfaces/generic-midi/midi-binding-maps/) I've tried the following command:

...
Binding sysex="f0 7f 7f 06 06 f7" action="Transport/RecordCountIn"/> <!-- Record w/Count-In -->
...

This definition will not be recognized fro Ardour.

As I tryed out the following definition:
...
Binding msg="f0 7f 7f 06 06 f7" action="Transport/RecordCountIn"/> <!-- Record w/Count-In -->
...
This worked without any problems.
Tags:
Steps To Reproduce: I've created a brand new file named AKAI_MPK261.map file in the folder /usr/share/ardour6/midi_maps/

I've attached the file to this post.
If you open up the file, you can see some lines with "...sysex=". They won't be recognized by Ardour.
The lines with the "...msg=" are recognized and they do their job.
Additional Information:
System Description
Attached Files: AKAI_MPK261.map (979 bytes) 2022-03-23 18:45
https://tracker.ardour.org/file_download.php?file_id=4171&type=bug
Notes
(0026394)
paul   
2022-04-16 00:49   
I think this is fairly simple. All sysex messages start with 0xf0 and end with 0xf7. If you define a message as "sysex", the definition should only contain the *contents* of the sysex message, not the start (0xf0) or the end (0xf7). Let me know if that works for you.
(0026410)
bmuxbeats   
2022-04-21 11:24   
@paul
Nope - it doesn' work.
(0026411)
bmuxbeats   
2022-04-21 11:25   
BTW:
The documentation shows the following lines:

 You can also bind sysex messages:
<Binding sysex="f0 0 0 e 9 0 5b f7" ….
<Binding sysex="f0 7f 0 6 7 f7" ….

The string after the sysex= part is the sequence of MIDI bytes, as hexadecimal values, that make up the sysex message.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8899 [ardour] bugs minor always 2022-04-13 20:37 2022-04-20 19:19
Reporter: mrMute Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Selected MIDI notes in regions stay selected when creating a selection in another region
Description: Creating a new selection in a region deselects the notes of the previous selection in that region.

But when you select midi notes in a region and make a new selection in a second region, the notes in the first region stay selected.

This selection can be expanded over multiple regions.

Edits like resizing and deleting notes are applied to all the notes you selected this way.

This can lead to unexpected data loss.

Tags:
Steps To Reproduce: Switch to edit mode.

Select some notes in a region.

Select some notes in another region.
Additional Information: This seems related to:
https://discourse.ardour.org/t/ardour-6-8-destroyed-my-midi-regions/106251
https://mantis.ardour.org/view.php?id=8729
System Description
Attached Files: selection.png (65,473 bytes) 2022-04-13 20:37
https://tracker.ardour.org/file_download.php?file_id=4174&type=bug
png
Notes
(0026406)
paul   
2022-04-18 05:01   
this should either be dramatically improved or totally fixed in git master (nightly builds) as of commit #a0d08232ad9

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8902 [ardour] features minor always 2022-04-18 20:47 2022-04-18 20:47
Reporter: unsafelyhotboots Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: Humanization
Description: Most DAWS have some kind of right click context option, or a device that creates 'jitter' in MIDI velocity values and adjusts notes to be slightly off beat. I use this function after quantization and note correction to add human groove into my programmed MIDI clips.

It would be nice if the context menu had the following:
Velocity range: This is the +/- range that it would add jitter - so if the range was 10, it would add +/- 10 to velocity.
Velocity: This would set the centerpoint for the range value, so it would need to be set
Timing: This needs to be set up to rush or drag, ideally on a slider, and would set the centerpoint for any sample movement
Timing range: This is the +/- range that it would add jitter - so if the range was 10, it would add +/- 10 to timing. With this, if notes are set to subtly drag, but the range is set to be wide enough, it would need to cap it so that notes would land on the beat instead of being rushed. For example, if the timing is set to drag by 3 samples, but the range is set to 10, it would drag by up to 10 samples but rush by 3 (landing it on the beat instead of rushing it).
Tags: feature-request midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8721 [ardour] features minor N/A 2021-05-24 09:05 2022-04-18 05:23
Reporter: whitewolfmusic Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI workflow improvements for Ardour v7
Description: Original topic with explanations:
https://discourse.ardour.org/t/suggestions-to-improve-midi-workflow-in-ardour-v7/105979

Summary of requested changes:

==============
Add track dialog:
==============
- remember the last selected track type
and / or
- allow rearranging track types / making MIDI track the default selection

====================
Create new MIDI region:
====================
- double clicking inside a MIDI track creates a new 4-bar MIDI region, starting with the bar that has been double-clicked

==================
Editing a MIDI region:
==================

After double-clicking a MIDI region to zoom into it:

- if the region is empty, automatically switch to drawing mode

- if the region contains note data, automatically switch to internal edit mode; but in the settings:
- add an option to choose between internal edit mode and drawing mode for this

- default note velocity should be 127.

- when scrolling with mousewheel to change velocity before drawing a new note, keep this new velocity value for drawing further notes

===================================
Something that drives me crazy right now:
===================================

When drawing notes within a zoomed region, I want to scroll up and down the octaves. NOT the tracks. To do that, I currently have to move the cursor over this super thin strip of octave selector, which slows me down, is not intuitive and requires too much precision to keep the cursor in that slim region. So:

- When zoomed into a MIDI region, make scrolling the mouse wheel scroll up and down ovtaves instead of the track list, while the cursor is over an empty area and no notes are selected.

======================================================
Allow to exit the zoom to MIDI region the same way as entering it:
======================================================

- double-click with the grabbing tool inside a zoomed-in MIDI region goes back to the zoom level before
Tags: Ardour, editing, feature request, MIDI region, usability
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025886)
x42   
2021-05-24 17:20   
Thanks, that is a nice list of good suggestions!

A few comments:

> - remember the last selected track type
> and / or
> - allow rearranging track types / making MIDI track the default selection

The latter is not great since GUI should be consistent. However The former has been near the bottom of my ToDo list for at least 10 years.
It is low priority since compared to hours and hours of recording, editing and mixing, adding tracks is a non-issue. Preselection shaves off a few seconds.
I keep it on a list for someone new to the coding who may want to start contributing to the project.


> - when scrolling with mousewheel to change velocity before drawing a new note, keep this new velocity value for drawing further notes

Currently Ardour uses velocity of the previous note when you append to a region, and otherwise the average of previous/next note.
This should perhaps be more explicit, and this ties in with https://tracker.ardour.org/view.php?id=5608


> - double-click with the grabbing tool inside a zoomed-in MIDI region goes back to the zoom level before

We need to be careful to not overload what double-click does. I don't like the double-click to zoom. That was added only as experiment and somehow remained.
Double-click usually it activates an action that operates on the current selection (e.g. create regions on selected track).

There are some edge-cases with your suggestion. e.g. what happens if you manually resize the track or window after maximizing? Does double-click fill again?
explicit "fill" (F) and "visual undo" (Ctrl+shift+Z) operations are preferable.


PS. Ardour 7 is mainly about fixing a fundamental issue how ardour represents time internally, major version change is needed since the session format changes.
Your suggestions are mostly incremental small changes that can happen later during the 7.x or 8.x minor releases. They're workflow specific and not session-format related.
(0025887)
Daniele1971   
2021-05-24 17:37   
I would add panning note inside pianoroll.
(0025890)
whitewolfmusic   
2021-05-25 03:08   
> - allow rearranging track types / making MIDI track the default selection

@x42: "The latter is not great since GUI should be consistent."

That is correct, in hindsight, I would prefer a simple "make default" button or an option in the settings.

-----------------------------------------

@x42: "what happens if you manually resize the track or window after maximizing? Does double-click fill again?
explicit "fill" (F) and "visual undo" (Ctrl+shift+Z) operations are preferable."

Good point. However, I see an urgent need for improvement in this area. Since Ardour does not apply to the typical way of MIDI editing, having a separate window or screen area, my personal experience is that navigating tracks and navigating the piano roll get in each other's way. When I zoom into a MIDI event, I commit to edit only the note content of that event. I want to navigate only the information surrounding this task. That means to me, if I scroll, I want to scroll the octaves, not the tracks. Fully zooming in to a MIDI event equals opening a separate editor window in my mind, so double-clicking to zoom should lock this zoom state until manually exiting it. Zooming into a MIDI region should prevent scrolling tracks and instead scroll octaves inside the piano roll, that would be the best and most logical compromise to me, for not having a separate editing area.
(0026407)
paul   
2022-04-18 05:23   
as of commit b725b7ddb4, the scrolling behavior has been implemented as follows:

- scroll in a MIDI region with no notes selected with adjust the visible note range
- with no modifier, it moves by single notes
- with the tertiary modifier (shift) it moves by octaves (matches transpose behavior)
- with the primary (ctrl on linux/win, cmd on macOS) modifier, it modifies expands the note range rather than scrolling. scroll up will increase the uppermost visible note, scroll down will decrease the lowermost visible note

Remember that scroll if there are notes selected is used to adjust note velocity.

Thanks for this suggestion.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8729 [ardour] bugs minor sometimes 2021-05-28 15:46 2022-04-18 05:01
Reporter: unfa Platform: PC  
Assigned To: paul OS: Manjaro Linux  
Priority: normal OS Version: KDE  
Status: feedback Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Impossible to deselects regions for multi-region MIDI editing - resulting in unwanted note alteration on multiple tracks
Description: When editing MIDI in a large project I've realized some of my notes are way longer than the y should be, and that I remember making them.

I've inspected the issue and realized when I enter the Edit Mode, there's a lot of MIDI regions selected, with all of the notes inside of them selected as well.
As a result when I try to change length of a single note in one region - dozens of other MIDI notes get altered as well in other regions on other tracks against my intention.

I have tried going in and out of Edit Mode or selecting notes, using Region > Select > Deselect all - to no avail.
it seems the only way for me to alter length of a note without messing up my project in unknown capacity is to delete a note I want to alter and add it again with a different length.

Any attempt at changing the note length will further mess up my project.

This has happened before in the 6.0 branch, but never to such a degree.
Tags: Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026098)
unfa   
2021-08-08 18:36   
This bug strikes again in 6.8:
https://discourse.ardour.org/t/ardour-6-8-destroyed-my-midi-regions/106251
(0026405)
paul   
2022-04-18 05:00   
this should either be dramatically improved or totally fixed as of commit #a0d08232ad9

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8824 [ardour] bugs minor always 2021-11-22 01:57 2022-04-16 00:44
Reporter: ragnarok Platform: amd64  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: 10.11  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: the selected external midi device is not saved when ardour is closed
Description: the selected external midi device is not saved when ardour is closed and is back to the default value Generic / General Midi
Tags: Midi
Steps To Reproduce: create session
add midi track
select external midi device ex: Line -> POD
save and close the session

open session again
the device midi go back to Generic / General MIDI


Additional Information: I use (ardev) a build from 6.9.0 sources.
System Description
Attached Files: 2021-11-21_22-58.png (36,610 bytes) 2021-11-22 01:59
https://tracker.ardour.org/file_download.php?file_id=4137&type=bug
png
Notes
(0026222)
ragnarok   
2021-11-22 01:59   
capture
(0026390)
paul   
2022-04-16 00:44   
What you have shown is not a "selected MIDI device". Those controls related to the use of a MIDNAM file, which is an industry standard (albeit, under-utilized) for providing the names of patches/programs in a synth. They do not control the external device connected to the track, nor the synth inside the track. It is merely used for naming patches/programs.

In addition, I cannot reproduce that here with the official 6.9 build. What synth are you using within the track, if any?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8898 [ardour] features minor N/A 2022-04-07 12:31 2022-04-07 12:31
Reporter: rdz Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow to de/activate tracks with OSC commands
Description: In dynamic setups where only a subset of tracks is used at any given time, this could help reduce DSP usage. Also, it seems natural to have the ability to disable tracks since you can already hide, rename, mute, solo (etc.) them.

This could look like this:
 
/strip/active 15 1 <-- activate strip 15
/strip/active 15 0 <-- deactivate strip 15
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8782 [ardour] bugs minor always 2021-07-27 09:54 2022-04-06 23:24
Reporter: MyLoFy Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Export to audio file creates silent file with pipewire
Description: I'm testing pipewire in an audio production environment:
-pipewire 1:0.3.32-1 from arch repos
-Ardour 6.8
-Monitor section activated
-Ardour set to Jack backend
Tags:
Steps To Reproduce: -Activate Monitor section
-Master is routed to monitor
-Export project to audio => audio file is silent
-Connect Master to system output => audio file as expected
Additional Information:
System Description
Attached Files:
Notes
(0026376)
spixi   
2022-04-06 23:24   
Gentoo user here. Please switch to another PipeWire version. I switched from PipeWire 0.3.30 to 0.3.49 and WAV export works now with Ardour 6.9 and LibSndfile 1.1.0.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8887 [ardour] bugs minor always 2022-03-05 09:44 2022-04-04 07:29
Reporter: coenplanetc Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Consolidation of midi range(s) after a tempo-change unexpected effects length and timing of notes and region
Description: Occurs after a tempo change (for example 120 to 140):
Cconsolidation of one midi range or two midi ranges (bouncing) does something unexpected to the length and placement of the midi notes inside the range.
The range length is also affected. What you expect is that the new range is the same length as the selected region, bit it's not.
Tags:
Steps To Reproduce: Create one miditrack.
Create a tempo change after a couple of bars (for example, start tempo is 120, create a tempo change 140).
Create two regions after the tempo change and put some snapped notes in it, all tied to the grid.
Select the two midi region is one range and consolidate.

Even simpeler: if only one region is selected as a range and consolidate the same happens but a bit less noticable.
Additional Information: Ardour 6.9.0 ds-01
Ubuntu Studio 21.10
System Description
Attached Files: ResultOneRegion.jpg (152,981 bytes) 2022-03-05 09:44
https://tracker.ardour.org/file_download.php?file_id=4167&type=bug
jpg

ResultTwoRegions.jpg (142,993 bytes) 2022-03-05 09:44
https://tracker.ardour.org/file_download.php?file_id=4168&type=bug
jpg

Step1.jpg (150,198 bytes) 2022-03-05 09:44
https://tracker.ardour.org/file_download.php?file_id=4169&type=bug
jpg

Step2.jpg (144,392 bytes) 2022-03-05 09:44
https://tracker.ardour.org/file_download.php?file_id=4170&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8581 [ardour] bugs minor always 2021-02-19 00:13 2022-03-31 07:26
Reporter: SadKo Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Snap to grid behaves very strange
Description: When the zoom allows snapping to grid, Ardour doesn't allow to snap.
Even if 1/16 line is seen, Ardour doesn't allow to snap to it. The same for 1/32 and 1/64.
1/8 behaves OK.
Tags:
Steps To Reproduce: Example video showing the problem
https://youtu.be/hzGkFTCaEhk
Additional Information:
System Description
Attached Files: a.png (6,187 bytes) 2021-02-22 07:31
https://tracker.ardour.org/file_download.php?file_id=3945&type=bug
png

b.png (8,101 bytes) 2021-02-22 07:31
https://tracker.ardour.org/file_download.php?file_id=3946&type=bug
png

scrot20210223212221.png (20,378 bytes) 2021-02-23 20:36
https://tracker.ardour.org/file_download.php?file_id=3947&type=bug
png

scrot20210223212257.png (20,412 bytes) 2021-02-23 20:36
https://tracker.ardour.org/file_download.php?file_id=3948&type=bug
png
Notes
(0025533)
SadKo   
2021-02-19 00:28   
Here's an example of how region dragging works

https://youtu.be/2TeLi_yHCmc
(0025534)
SadKo   
2021-02-19 00:41   
Ardour 5.12 works as expected: the playhead is snapping to grid lines (and even more)

https://www.youtube.com/watch?v=YIf8Z6p12Vg
(0025543)
sciurius   
2021-02-22 07:31   
I've been informed that Ardour6 changed the behaviour to snap only to visible grid lines, to avoid abiguity. This may have been a wise decision.

However, the algorithm for deciding when to show grid lines behaves a bit weird. It tends to place grid lines much farther apart than necessary for convenient snapping. See exhibit a, where the lines are very wide (approx 80px) and there is no way to snap at a resolution finer than a measure (even though the grid is configured for 8th notes).
Exhibit b shows how far a measure must be zoomed to get the grid lines for 8th notes, and even then the spacing between the lines (approx 45px) is excessive.

There is a preference for 'Snap' which is 25px default and can be lowered but no less than 10px. I haven't noticed any difference in grid behaviour when changing this value.
(0025544)
SadKo   
2021-02-22 14:16   
Paul and Ben at Harrison made some recent changes to Ardour code and confirmed that the problem existed.

The build 6.5.268 behaves much better now. But there are still some problems with 1/64 and 1/128 grid.
(0025545)
sciurius   
2021-02-22 17:04   
Much, much better! Fantastic!

I'll play a bit bit the snap settings to find out what their settings do.
(0025547)
sciurius   
2021-02-23 07:24   
navonwolf's message is either a mistake, or maligne. Take care.
(0025548)
sciurius   
2021-02-23 20:36   
With Ardour6.6 I get the following.
Picture 1: Grid with 1/4 note lines.
Picture 2: Same, slightly smaller, shows measure lines. I would have expected 1/2 note lines grid first, and later

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7590 [ardour] bugs major always 2018-03-28 13:34 2022-03-31 02:15
Reporter: martinbangens Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: Maverick  
Status: new Product Version: 5.X git (version in description)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: There is a glitch In the metronomes click when looping
Description: so when we want to use loop functionally with the metronome the click that is the first one when the loop go back to the start position again is clipped or glitched
Tags:
Steps To Reproduce: turn on the metronome, set a loop and then listen to the last click that is also the first(at the point where the loop go back to start location) that metronome click is glitched or clipped.
Additional Information:
System Description
Attached Files:
Notes
(0020247)
unfa   
2018-04-08 18:31   
(Last edited: 2018-04-08 18:33)
I also experience this, seems like the last beat is played and after a short delay - the first one is played too, so it plays 2 clicks one only one should be played.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8895 [ardour] bugs minor always 2022-03-28 09:40 2022-03-30 21:56
Reporter: thebutant Platform: Ubuntu  
Assigned To: x42 OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: Mixbus 8.x  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Automation disappears when region is edited
Description: Editing a region (audio or midi) destroys automation curves belonging to that region.
Tags:
Steps To Reproduce: Draw automation under a region (could be volume or anything).
Change the region by moving it, resizing or other ways.
Automation is removed.
Additional Information:
System Description
Attached Files:
Notes
(0026371)
x42   
2022-03-30 21:56   
Fixed since https://github.com/ardour/ardour/commit/d841b13673a5ef2b4458accb53120047e5d458a1
will be in any upcoming Mixbus release or nightly Mixbus 8.0.29 or later

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4981 [ardour] features tweak sometimes 2012-07-03 08:10 2022-03-30 15:27
Reporter: BenSpector Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 3.0  
Summary: Punch in and out produces an unpleasant click
Description: Mostly depending on the audio type present on the track, but most of the times, when punching in and out from recording, there will be a loud click.
Checked the same audio on PT, no click.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026370)
dannyb   
2022-03-30 15:27   
This issue still exists for me and it sounds just like an xrun. It's annoying, as I don't know whether it's in the recording or not. I always have to look for the punch in marker.

I can reproduce it all the time by playing past the punch in marker with punch in enabled, produceing a static like click. Disable punch in and there is no click.

Ardour 6.9.0
"After Bach"
(rev 6.9)
Intel 64-bit

Operating System: Fedora Linux 35
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Kernel Version: 5.16.17-200.fc35.x86_64 (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce GT 710/PCIe/SSE2

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8897 [ardour] bugs minor always 2022-03-29 20:11 2022-03-29 20:11
Reporter: gedobbles Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes, when jack transport is stopped when recording midi track
Description: Ardour crashes, when jack transport is stopped when recording midi track
Tags: crash, jack, Midi, transport
Steps To Reproduce: New project
add midi track
record on midi track
start recording
stop recording (strange yellow box continues to expand in midi track)
stop jack transport
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7585 [ardour] bugs minor always 2018-03-11 12:34 2022-03-29 20:06
Reporter: jihema Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 17.10  
Status: new Product Version: 5.X git (version in description)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Jack transport crash with midi track
Description: Version 6.0.pre.0.599 (98d6fe9c9113a88766340b99a164cbec0b39217f)

Assertion failing when turning on Jack transport on a midi track.

ardour-6.0.pre0.599: ../libs/ardour/midi_buffer.cc:157: virtual void ARDOUR::MidiBuffer::merge_from(const ARDOUR::Buffer&, ARDOUR::samplecnt_t, ARDOUR::sampleoffset_t, ARDOUR::sampleoffset_t): Assertion `mbuf != this' failed.
Aborted (core dumped)
Tags:
Steps To Reproduce: New empty session, add a midi track, turn on Jack transport ("enable external positional sync").
Additional Information:
Attached Files:
Notes
(0026369)
gedobbles   
2022-03-29 20:06   
This still seems to be an issue in 6.9

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8896 [ardour] bugs minor always 2022-03-28 09:42 2022-03-28 09:42
Reporter: thebutant Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 8.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mixer list resizes at every startup of MB32C
Description: Mixer list (the panel on the left in the mixer, the panel that shows/hides when pressing Shift+L) resizes every time MB32C v8 opens.
Tags:
Steps To Reproduce: Change the layout of the mixer panel (drag down Groups, Strips).
Reopen MB32C v8.
They are resized to default and you have to drag them into your preferred position again.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8286 [ardour] bugs minor always 2020-07-03 22:34 2022-03-27 19:40
Reporter: jeythekey Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Column widths are not adjustable in editor list and plugin manager, leaving some text unreadable
Description: Currently, one can resize the view of the editor list and of the plugin manager, but the columns are fixed. Sometimes, part of the texts are unreadable this way.

Suggestion:
Allow to adjust the widths of columns by grabbing the separators in the header, especially for columns with free text. The width of columns with fixed content could be allowed to be decreased/collapsed to save space. Empty columns should be set to minimal width (e.g. as much as the header needs) and also be allowed to be collapsed.
Additionally, the automatic adjustment of column widths when increasing the view could be made more intelligent, i.e. content-aware in a priority sequence, so that the most important (e.g. the first) column becomes totally readable first and others (e.g. the path-column) afterwards etc. by further increasing the view.

Reason:
While in the regions tab of the editor list, increasing the view further increases the `Region` column, in the sources tab, it increases the (last) path-column, often leaving the text in the first (`Sources`) column unreadable. Moreover, empty columns (e.g. take ID or tags) always take a fixed amount of space, which is a waste.

Discussion here: https://discourse.ardour.org/t/import-multiple-takes/103997/32
Tags: column width, editor list, plugin manager
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026366)
jeythekey   
2022-03-27 19:40   
I think this one is still open. Is anything done in this direction already?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8283 [ardour] features minor always 2020-07-03 18:13 2022-03-27 19:31
Reporter: jeythekey Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Polyphonic import part II: Import several takes/files at once in sequence, one track per channel
Description: Currently, several (polyphonic) files can only be imported as sequence to a single (polyphonic) track.

Suggestion:
Allow to import several polyphonic files at once in sequence to several tracks, one track per channel.
This should optionally be possible to selected existing tracks or by generating new tracks as needed (see part 1: 0008281).

Reason:
Importing several takes of a polyphonic recording session (stereo or more channels) e.g. from a mobile/field recorder should be a straightforward task, as it is a routine step for every Ardour session with material recorded/created outside of Ardour. Polyphonic tracks are not suitable for mixing etc. but currently, it is not possible to split a polyphonic track to mono-tracks, e.g. after import. Otherwise, the latter could be a workaround for this feature.

Discussion here: https://discourse.ardour.org/t/import-multiple-takes/103997/24

As a bonus, import could be made more flexible later on, e.g. by:
- allowing to select the channels to import from a polyphonic file (e.g. to omit auto-mix channels),
- allowing for custom mapping of channels to tracks, e.g. the tracks from the stereo pair to a polyphonic stereo track and all other takes to mono tracks etc. Further suggestions here: https://discourse.ardour.org/t/import-multiple-takes/103997/21
- drag-and-drop import from the import window into tracks with nice feedback of channel-track mapping or even quick'n-dirty from a normal file browser.
Tags: 6.0, Import, polyphonic, stereo
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026364)
jeythekey   
2022-03-27 19:27   
Is there anything done in this regard already? I still think being able to seamlessly import several files/takes at once as a sequence to several (selected) mono tracks, or one after another to selected tracks (i.e. without creating new tracks for every file/import) is utterly important whenever you record on an external recorder and not directly into Ardour.

Also, one addendum: I just noted, that, unlike stated in the original report, the option to import to selected tracks also appears when selecting several files in the import window and selecting "as sequence" also for stereo-files and irrespective of how many tracks are selected. However, it always only imports one (the left?) track per file, to the track selected first, which is totally unexpected behavior and therefore likely a BUG. (I.e. this option should not occur under these circumstances until properly supporting the feature to import polyphonic/stereo files to selected tracks, IMO.)
(Corss-posting here: https://tracker.ardour.org/view.php?id=8281 because also relevant to this issue.)
(0026365)
jeythekey   
2022-03-27 19:31   
Also linking to this issue, as it might be an alternative solution/workaround: https://tracker.ardour.org/view.php?id=8284

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8281 [ardour] features minor always 2020-07-03 16:22 2022-03-27 19:26
Reporter: jeythekey Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Polyphonic (and stereo) import 0000001: Import to selected tracks
Description: Currently, the option to import to selected tracks is only available for (several) mono-files. It appears as soon as the number of selected files matches the number of currently selected tracks.

Suggestion: Make this option also available for polyphonic (stereo or more) files, as soon as the number of channels in a file matches the number of selected tracks.
As an additional (independent) suggestion: Leave the option to import to selected tracks selected as long as the import window stays open (as it is the case with all other options); at least it should become selected again once the number of selected tracks matches (again) the number of selected files/channels in a selected file.

Reason: Currently, importing polyphonic files (e.g. from a mobile/field recorder) creates new tracks on every import. Importing e.g. multiple takes of a recording session therefore is tedious and requires several manual steps (moving up the regions and deleting the created tracks for every imported file/take).

There are two further workarounds, but one does not gain much in convenience:
A) Polyphonic files can first be split to mono-files, either using sox on the command line or by first importing to regions. But having many (6, 16, or even 32) mono files for every take is very prone to errors when manually selecting the files belonging to a take to import.
B) Polyphonic files can be added to (existing) polyphonic takes. However, polyphonic takes can currently not be converted to mono tracks. (It only creates mono-regions/sources in the list view, that later could be imported one by one from the sources list and then aligned.)

As discussed here: https://discourse.ardour.org/t/import-multiple-takes/103997/24?u=jeythekey
Tags: 6.0, Import, polyphonic, stereo
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026363)
jeythekey   
2022-03-27 19:26   
Is there anything done in this regard already? I still think being able to seamlessly import several files/takes at once as a sequence to several (selected) mono tracks, or one after another to selected tracks (i.e. without creating new tracks for every file/import) is utterly important whenever you record on an external recorder and not directly into Ardour.
See also: https://tracker.ardour.org/view.php?id=8283

Also, one addendum: I just noted, that, unlike stated in the original report, the option to import to selected tracks also appears when selecting several files in the import window and selecting "as sequence" also for stereo-files and irrespective of how many tracks are selected. However, it always only imports one (the left?) track per file, to the track selected first, which is totally unexpected behavior and therefore likely a BUG. (I.e. this option should not occur under these circumstances until properly supporting the feature to import polyphonic/stereo files to selected tracks, IMO.)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8892 [ardour] bugs minor always 2022-03-24 20:44 2022-03-24 20:44
Reporter: wargreen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When multiple clip are selected via tracks grouping, double click alway open the properties window of the clip on the last track
Description: With tracks grouped and the option "selection" activated, if multiple clips is selected via this group, a double-click on a selected clip in a track alway open the properties window of the clip on the last track.
Tags: Editor
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8891 [ardour] documentation minor always 2022-03-24 17:27 2022-03-24 17:27
Reporter: bmuxbeats Platform: Desktop  
Assigned To: OS: Manjaro Linux  
Priority: normal OS Version: 21.2.5  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Function 'toggle-rec-enable' in documentation Home/Control Surfaces/Generic MIDI/Generic MIDI Binding Maps not specified
Description: The function 'toggle-rec-enable' is not specified in the listing under the header "Bindings to Ardour "functions" ", but fortunately it's still available and it does what it is supposed to.
(please refer to https://manual.ardour.org/using-control-surfaces/generic-midi/midi-binding-maps/)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8533 [ardour] features minor have not tried 2021-01-07 22:17 2022-03-10 13:59
Reporter: DonJaime Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make it possible to edit the metronome click pattern when editing the meter
Description: One reason for bothering to set the meter is to get a metronome. As things stand the metronome click is inflexible and of variable utility: if I switch on the metronome in 3/4, 4/4 or 5/4 time, I get a reasonable, usable beat. If I switch it on in 7/8 time, I get too many clicks to follow easily unless the tempo is very relaxed. In 13/16 I just get lost.

It would be useful to be able to choose on which beats the metronome clicks.

A sensible place to make the choice would be in the "Edit Meter" dialog.
Underneath the "Lock style:" menu there could be a "Click pattern" section, with an interface similar to that of a drum machine like Hydrogen, with togglable dots on the beats that should click.

Allowing for clicks on subdivisions of beats would be useful, too, or allowing for division into arbitrary tuplets. (Yesterday I wanted to record a simple little song using the metronome, and it turned out to be mostly in 7/8 time with a quadruplet spanning the first three beats, so I ended up having to roll my own MIDI metronome with clicks on beats 1, 2.5, 4, and 6. And some bars turned out to be a quadruplet over 5/4...)
When changing meter the initial pattern should be the most recent one in the track for the meter chosen.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026345)
al f   
2022-03-10 09:48   
Would also like to see this feature +1
(0026346)
ragnarok   
2022-03-10 13:59   
+1 I like too!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8884 [ardour] bugs minor always 2022-02-27 19:05 2022-02-27 19:05
Reporter: graymon Platform: Intel(R) Core(TM) i7-5557U CPU  
Assigned To: OS: 5.16.10-200.fc35.x86_64  
Priority: normal OS Version: Fedora 35  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: continuous stream of recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
Description: My system locks up regularly.


When I run strace /opt/Ardour-6.9.0/bin/ardour6

There is a constant stream of:
poll([{fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=0}, {fd=5, events=POLLIN|POLLPRI}], 4, 14) = 0 (Timeout)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=0}, {fd=5, events=POLLIN|POLLPRI}], 4, 2) = 0 (Timeout)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=0}, {fd=5, events=POLLIN|POLLPRI}], 4, 23) = 0 (Timeout)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=0}, {fd=5, events=POLLIN|POLLPRI}], 4, 14) = 0 (Timeout)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=0}, {fd=5, events=POLLIN|POLLPRI}], 4, 22^C) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
strace: Process 4677 detached
Tags:
Steps To Reproduce: run ardour from command line
Additional Information: I am running pipewire in F35 with everything updated.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8882 [ardour] bugs minor always 2022-02-25 19:21 2022-02-25 19:21
Reporter: MelissaRankin Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crashes at same point in playback and when exporting audio
Description: I'm new so this software and have been working on the same session for about a week now. After having a break for a few hours, all of a sudden ardour crashes at the same point every time I playback or try to export audio.

I have used and both ACE plug-ins and meld productions.
Tags: audio, crash, editing, export, playback, plugin manager
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8879 [ardour] bugs minor always 2022-02-23 15:09 2022-02-23 15:09
Reporter: Alessandro Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot export mp3
Description: Export in Flac, Wav.. ok.
When i try to export session in mp3 formar the result is:
2022-02-23T16:06:23 [ERROR]: Export ended unexpectedly: Exception thrown by AudioGrapher::CmdPipeWriter<float>: Could not write data to output file
2022-02-23T16:06:23 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (0).
2022-02-23T16:06:23 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (3072).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8878 [ardour] bugs minor always 2022-02-23 15:03 2022-02-23 15:03
Reporter: Alessandro Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot access outside Home Volume
Description: I do have 4 partition / Volume in my drive. 1) Media=NTFS(Fuse),2)Buffer=NTFS(Fuse),3) Home(Msdos), 4)BioMarta(USB-Msdos)
Under Ardour 6.9 - the only partition/volume that i can see and then access is Home.
Under Ardour 5.1 - is possible see and access any partition/volume.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8877 [ardour] bugs minor always 2022-02-20 13:20 2022-02-20 13:20
Reporter: daniels115 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: uri for /bus/gain Master is case sensitive
Description: I wrote a midi map file for a Nektar LX25+ midi keyboard (enclosed). I have found that it was necessary to capitalize the /bus/gain uri in order to map the main slider on the keyboard to the master bus fader. The final LX25+ map file is enclosed. The issue is not specific to the Nektar LX25+ but would affect any midi map that maps a control to the master bus fader.
Tags: CC, midi_map, surface
Steps To Reproduce: This line does not work (no mapping to control):

<Binding channel="16" ctl="20" uri="/bus/gain master"/>

This line works properly:

<Binding channel="16" ctl="20" uri="/bus/gain Master"/>

Additional Information: If this is a verified bug, it will affect many of the supplied midi maps as they all appear to use the lower case identification. I'm using the latest Debian release of Ardour which is 6.5.
System Description
Attached Files: nektar_lx25.map (1,995 bytes) 2022-02-20 13:20
https://tracker.ardour.org/file_download.php?file_id=4157&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8873 [ardour] bugs minor have not tried 2022-02-07 17:29 2022-02-18 19:38
Reporter: priya2312 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 502 bad gateway
Description: A 502 Bad Gateway error means that the web server you connected to is acting as a proxy to relay information from another server, but received a bad response from that other server. https://www.thoughtsmag.com/502-bad-gateway/
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8875 [ardour] features minor N/A 2022-02-18 03:06 2022-02-18 03:06
Reporter: Thovthe Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add tooltip for xrun markers.
Description: Just starting to use ardour today. I had this strange black arrow pointing at my track, went on the IRC chat to find out what is was. After a few hours and a user (Ias) asking some more informed others (but getting it not quite right) and me testing some settings they put me near. I find out it's an xrun marker. This might only be a couple lines to add a tool tip on hover that says "xrun", "xrun marker" or "xrun recording error".
Tags:
Steps To Reproduce:
Additional Information: I like the software, and appreciate what you do. It's pretty nice once you watch unfa's 30 min quick start video.
System Description
Attached Files: Screenshot_2022-02-17_23-14-41.png (3,892 bytes) 2022-02-18 03:06
https://tracker.ardour.org/file_download.php?file_id=4156&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8814 [ardour] bugs minor always 2021-10-21 21:27 2022-02-15 07:35
Reporter: OaaH Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour Crashes with ToneLib-GFX's impulse response
Description: While using ToneLib-GFX amp simulator inside Ardour (LXVST or VST3 version), Ardour constantly crashes every time I try the plugin's built-in impulse response effects (cabinet simulators).
trying to run this plugin on Carla worked fine. The ToneLib standalone version works fine either. I have checked it under Ardour at several sampling rates (thinking that this might be a sample rate conversion issue) but it crashed on both 44.1Khz, 48Khz and 96Khz.

I also tried to load Carla as an Ardour plugin, and loading ToneLib inside Carla, but again it crashed as soon as I uploaded the cabinet simulator. It seems to crash every time it somehow goes through Ardour, and it works fine otherwise.
Tags: crash, impulse response, ToneLib, VST
Steps To Reproduce: 1) Run Ardour
2) Load ToneLib-GFX plugin (either LXVST or VST3)
3) inside ToneLib, add the plugin "guitar IRs Cab" or "IR processer"
Additional Information:
System Description
Attached Files: ardour debug (186,247 bytes) 2021-10-21 21:27
https://tracker.ardour.org/file_download.php?file_id=4119&type=bug
Notes
(0026331)
ospi   
2022-02-15 07:35   
This was a Tonelib GFX bug as version 4.7-5 released on 2022-02-14 fixes the issue with IRs.
Tonelib version 4.7-3 crashed both Ardour and Qtractor when using IRs.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8795 [ardour] features minor N/A 2021-09-10 20:14 2022-02-12 22:11
Reporter: DavidLC11 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Implement support for ARA Audio Random Access
Description: ARA is an extension to the VST3 and AU APIs. It was as developed by Celemony, and is used by plugins such as Melodyne. The SDK is available under the Apache License, Version 2. Now that Ardour is planning to move to C++11 with the development of Ardour 7, it can be used to add support for ARA to Ardour. The ARA SDK is available on GitHub at https://github.com/Celemony/ARA_SDK
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026137)
x42   
2021-09-10 22:07   
Yes, it is already on our ToDo list. It is amazingly well documented as well.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8850 [ardour] features minor N/A 2022-01-04 16:12 2022-02-12 12:59
Reporter: timetre Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Alesis Q49 MKII MIDI Control Surface binding file
Description: Just got this master keyboard in my setup.
The 8 control buttons can work in Mackie, HUI or MIDI mode.
Since I'm already using a Mackie control surface, I've configured my keyboard in MIDI mode and built the binding file.
Attached to this ticket
Tags: MIDI control, midi_map
Steps To Reproduce:
Additional Information:
Attached Files: Alesis_Q49v2.map (701 bytes) 2022-01-04 16:12
https://tracker.ardour.org/file_download.php?file_id=4149&type=bug
Alesis_Q49v2-2.map (733 bytes) 2022-01-06 09:00
https://tracker.ardour.org/file_download.php?file_id=4150&type=bug
Notes
(0026290)
timetre   
2022-01-06 09:00   
Actually, after using the keyboard, I ended up making some changes to the previously submitted map.
1. The Record button now starts the recording (instead of just toggling global record)
2. The button at the center of the cross is mapped to stop-and-forget-capture which I use much more when recording keyboard than toggling loop :-D
(0026317)
timetre   
2022-01-29 11:42   
Created a pull request
https://github.com/Ardour/ardour/pull/665
(0026318)
timetre   
2022-01-29 13:07   
Sorry I had messed up my git fork ...
Pull request is : https://github.com/Ardour/ardour/pull/666

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7645 [ardour] other feature always 2018-07-07 17:47 2022-02-11 15:32
Reporter: mrnuke Platform: hax86-64  
Assigned To: OS: Fedora 28  
Priority: normal OS Version:  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour fonts icons and buttons are too small to be usable on high density screens
Description: On displays with high pixel density the text, buttons, icons and controls of Ardour are too small to be easily readable. Even when the desktop environment is configured correctly, where other applications display controls at the cprrect size, Ardour displays these elements in a size that is too small to be seen. On high enough pixel densities (200+ DPI), the controls become unreadable to a normal human eye.

Learnability: Almost impossible to understand what the knobs do when the user can't see them.
Efficiency: -100dB -- User puts in 100 dB of work to get something done, gets out 0 dB.
Memorability: N/A
Safety: N/A
Satisfaction: The user experience is horrible (-inf dB) when knobs can't be seen.
Tags:
Steps To Reproduce: For KDE5, open System Settings -> Fonts -> [x] Force fonts DPI: 300
Log out and log back in.
Launch Ardour.
I suspect other DEs have similar knobs if they don't automatically adjust scaling based on EDID.
Additional Information: ## Expected results

On old-school screens (100-120DPI), I'd expect the buttons and knobs in Ardour to scale up in size.


## Actual results

Ardour controls stay the same size. On a 163 DPI screen, this becomes quite hard to read. On a 330 DPI screen (as shown in screenshots), this is completely unreadable.


## Additional information

The screenshots were taken on a 330DPI screen. An on-screen magnifier (x3) is included for comparison to what a normal font should look like.S
Attached Files: ardour_magnified_x3.png (147,961 bytes) 2018-07-07 17:47
https://tracker.ardour.org/file_download.php?file_id=3407&type=bug
png

ardour_magnified_x3_info_screen.png (82,337 bytes) 2018-07-07 17:48
https://tracker.ardour.org/file_download.php?file_id=3408&type=bug
png

ardour-high-res.png (73,046 bytes) 2019-01-09 11:04
https://tracker.ardour.org/file_download.php?file_id=3438&type=bug
png

ardour-high-res-2.png (682,852 bytes) 2019-01-09 11:04
https://tracker.ardour.org/file_download.php?file_id=3439&type=bug
Notes
(0020347)
x42   
2018-07-07 17:58   
Did you try to increase:
Ardour Preferences > Appearance > GUI and font-scaling?
(0020348)
mrnuke   
2018-07-07 18:13   
Hi x42, I did (eventually) find that setting, and there are two issue with it:

1) It's damn near impossible to read the text and navigate the menus leading to the option (remember, the fonts are unreadable on some screens)
2) It doesn't go far right enough. It becomes readable on my laptop (330 DPI), but still too small for comfort. I still get eye squints and pushing head closer to screen.

My main issue, from a UX perspective, is that the scaling should just work (TM). There's nothing wrong to allowing the user to customize the scaling. That being said, being greeted by an ant colony is poor UX.

I do however revise my "Satisfaction" estimate from -inf dB to -80 dB.
(0020568)
jo-so   
2019-01-09 11:04   
Me having the same problem. I've installed the Debian package of Ardour (5.12) and started Ardour the first time. All dialogues are utterly small on my high-resolution display (280dpi) and the worst thing is, I can't open the preferences dialogue without going through the first initialization and opening a project and all this with an unreadable screen.

Why don't you respect the setting of GDK_DPI_SCALE and GDK_SCALE?
(0020666)
teejaydub   
2019-05-25 02:27   
I see this as well, on a DELL XPS 13 with Ubuntu 18.04, screen resolution 3840 x 2160. Ardour is unusable. Tried the Ubuntu package first, then the installer downloaded from the web site; no difference. Surprising that even going to 400% screen scaling doesn't seem to affect Ardour at all.
(0026279)
x42   
2021-12-21 04:26   
Since Ardour 6, when Ardour is first started (without existing preferences) an initial scaling factor is guessed depending on the screen resolution and the first step in the "new user wizard" allows to configure the scaling factor (which can later be changed in the usual place in the preferences).

This should resolve this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8602 [ardour] bugs minor always 2021-03-03 23:50 2022-02-11 07:57
Reporter: felipeemos Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Weird imported MIDI behavior
Description: I recorded a small video of the bug so you can follow up. Here's the link: https://youtu.be/goPcgEXKW7E

THE BUG
It's impossible to modify attributes from the MIDI region without unlinking them from the original file.

BUG WORKAROUND
As soon as you import the region: "Unlink region from other copies"

EXPECTED BEHAVIOR:
Any modifications that WON'T take place without first unlinking the region should:
1. Ideally not be allowed
2. Warn the user to first unlink the region to see the effects taking place

MY EXPLANATION
Imported MIDI files are linked to the original file, ok, that's good. So Ardour "thinks", perfect, I don't even have to look at what is represented in the region, I'll just use the original file at "such" and "such" timestamp...
Well, if I edit the MIDI region and Ardour keeps looking at the source file, then it simply doesn't care about my edits... and that's a BUG.

That is perfectly acceptable behavior when dealing with sound waves, because in a non-destructive editor there won't be changes in the wave form and we won't be surprised by anything. I'm almost sure this approach comes from an optimization perspective and I'm not suggesting Imported MIDI files should be unlinked from the source by default. But the way Ardour behaves right now is just confusing.
MIDI regions are expected to have this granular modification freedom, so we either allow it or explicitly tell it's not possible in the current configuration because of "Y" and "Z".

SUGGESTED FIX
Linked MIDI regions don't have any visual queue about the link ... I know it's not easy to come up with good stuff (especially about UI ), but this really could be a great start! I would be 70% less confused with this behavior if a "chain link" or something appeared in this region I had just imported.

Although this situation is similar to 2 or more MIDI regions linked together inside the project, really I think there's something so different we should give it a different name. I'd say this is a HARD LINK, because in the previous everybody who's linked together change seamlessly on any change to any of the peers, but on this imported MIDI file, the situation is hard, static, because it's impossible to change the source file!

Good, I like this concept! We just have to make editing such regions HARD too. My approach would be:

1. Every MIDI region that is linked will signal a small "linking chain" icon. Right-clicking on it maybe can even show useful information about all the regions linked together, the file they are sharing (similar to the already existing "Properties / Source" menu) and show if they are HARD or not (in other words: EDITABLE or not)

2. Every HARD LINKED MIDI region won't be editable and instead of having a default grey background will have a continuous "stripe like" texture. (Similar to those "black and yellow" stripes Police Officers use to close the bounds of a crime scene. But not "yellow", let's respect our eyes, just simple variations of the intensity of the tone of "grey" already present in the default background)

The texture and the "chain link" are good ways of signalizing the user there's something different about the region. Once the user tries to make modifications and sees they are not allowed, then it should be enough for him/her to figure it out by himself/herself that the behavior is related to the property / visual queue of such MIDI files.

Tags: editing, Import, MIDI region, UX
Steps To Reproduce: https://youtu.be/goPcgEXKW7E

Import MIDI
Edit notes or change instruments
Changes are allowed and ignored by Ardour
"Unlink region from other copies" and Ardour stops ignoring the changes and works as expected
Additional Information: This is my first bug report, I'm super opened to feedback :)
System Description
Attached Files:
Notes
(0026326)
pjd   
2022-02-10 22:12   
I'm also experiencing this with Ardour 6.9, I'm able to import midi files and play them back but any changes to the midi are shown but will not play back. The workaround I found was to save and restart ardour, my changes will then be included in playback.

Ardour 6.9 (self compiled) on Ubuntu Studio 20.04

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8869 [ardour] bugs minor have not tried 2022-02-02 22:29 2022-02-02 22:29
Reporter: rob mullender-ross Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Track randomly applies VBAP Panner
Description: created a new stereo track which had VBAP panning. Can't find a way to change this to standard stereo panning (doesn't seem to be in the manual) and the track goes silent if you tray to alter the automation.
Tags: panner
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8868 [ardour] bugs minor always 2022-02-01 18:45 2022-02-01 18:45
Reporter: Maut Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 11  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi
Description: Hi there,

I am pretty happy about having EZdrummer 2 working with Ardour on Windows!

Problem: As I open EZDrummer 2 as stand-alone or Plug-In: when I draw Midi Drum Sequences into Ardour, everything is fine…but the little moments (parts of a second) at the beginning and the end of the midi sequence are cut away, so that e.g. a 17 bar drum sequence is 16, 75 bars, and the following part begins to early and of of course without the little delay between sequence 1 and sequence 2…


Tanks for your help!

Dan
Tags:
Steps To Reproduce: Copy EZDrummer Midi Tracks to Ardour
Additional Information:
System Description Windows 11
Attached Files: ec01d8778e52af89cdf9be4a897d7244fc3de233.png (51,041 bytes) 2022-02-01 18:45
https://tracker.ardour.org/file_download.php?file_id=4155&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8867 [ardour] bugs minor always 2022-01-31 22:19 2022-01-31 22:19
Reporter: kgorelov Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 7.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Deadlock while adding VCA Master track
Description: Ardour deadlocks while trying to add a "VCA Masters" track.
The GUI stops responding.

Here's a backtrace obtained in GDB:

#2 0x0000555555c52ff0 in Glib::Threads::Mutex::Lock::Lock(Glib::Threads::Mutex&) (this=0x7fffffffbb10, mutex=...)
    at /usr/include/glibmm-2.4/glibmm/threads.h:687
#3 0x00007ffff6dfc53c in ARDOUR::VCAManager::vcas[abi:cxx11]() const (this=0x555558a73000) at ../libs/ardour/vca_manager.cc:77
0000004 0x00007ffff6c4ad05 in ARDOUR::Session::get_stripables(std::__cxx11::list<boost::shared_ptr<ARDOUR::Stripable>, std::allocator<boost::shared_ptr<ARDOUR::Stripable> > >&, ARDOUR::PresentationInfo::Flag) const (this=0x555558eb8800, sl=
    std::__cxx11::list = {...}, fl=127) at ../libs/ardour/session.cc:3932
0000005 0x00007ffff6c400f8 in ARDOUR::Session::ensure_stripable_sort_order() (this=0x555558eb8800) at ../libs/ardour/session.cc:2617
#6 0x00007ffff6c5b41f in ARDOUR::Session::notify_presentation_info_change(PBD::PropertyChange const&) (this=0x555558eb8800, what_changed=...) at ../libs/ardour/session.cc:6997
...
Tags:
Steps To Reproduce: 1. From the top menu choose:
Track -> Add

2. Choose "VCA Masters" track type

3. Click the "Add and Close" button
Additional Information: [~] $ uname -r
5.4.0-91-lowlatency
[~] $ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.6 LTS"

Ardour configuration:
./waf configure --with-backends=jack,alsa,pulseaudio,dummy

System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8866 [ardour] features minor N/A 2022-01-29 10:18 2022-01-29 10:23
Reporter: timetre Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Visualize the names of the tracks currently managed by Control Surface bank
Description: As discussed in this thread on the forum https://discourse.ardour.org/t/control-surface-banks-not-visually-recognisable/87918/5

Would it be an idea to offer the option to replace or add below the Editor Summary a simple view of the names of the n tracks currently controlled by the Control Surface ?

Mock for my CS that has 8 channels attached

Note that instead of being in the Editor, it could be at the bottom of the Mixer if it makes more sense.

I can imagine that if one has several CS, you might need to configure which CS banking is being shown.
Tags: control surface, mackie, Mackie control, MIDI control
Steps To Reproduce:
Additional Information:
Attached Files: cd4489eb2693077e5defd28fe87499c2e5436f59.jpeg (506,792 bytes) 2022-01-29 10:18
https://tracker.ardour.org/file_download.php?file_id=4153&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6898 [ardour] bugs block have not tried 2016-06-18 08:14 2022-01-28 17:08
Reporter: aeLiXihr Platform: KX studio  
Assigned To: OS: GNU/Linux  
Priority: normal OS Version: KXStudio 14.04.2  
Status: confirmed Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ardour freezes during clean-up
Description: KXStudio 14.04.2 LTS - Release amd64

Dear all,
i have had a problem with Clean-up for a while:
If i go to Session>Clean-up>Clean-up Unused Sources...>Clean-up nothing happens. The popup below does not appear http://robin.linuxaudio.org/tmp/cleanup.png
Ardour freezes and if i try to close Ardour it takes a while and an "Ardour is not responding"screen pops up.

I ran in gdb and that is here: http://pastebin.com/7zETEQGS
If you tell me how i would attach my session file as well.

I found out: if i try to uncombine the first compounds from Droomvlucht-solo(@ 07:13:21:08, tracks: "gitaar-room" and "gitaar" ) they are deleted.

(i have the original session file(without -3001) too but it cannot be attached?, pressing browse nothing happens)
nb: i hope i filled in everything correctly: any questions, just ask please :)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: rommelen-3001.ardour (3,988,339 bytes) 2016-06-18 08:14
https://tracker.ardour.org/file_download.php?file_id=2969&type=bug
rommelen.ardour (3,988,339 bytes) 2016-06-18 09:47
https://tracker.ardour.org/file_download.php?file_id=2970&type=bug
Ardour-5.12.bug6898.trace.tar.xz (3,346,648 bytes) 2018-01-13 13:00
https://tracker.ardour.org/file_download.php?file_id=3357&type=bug
Winter_ARD_REC_007.rar (140,412 bytes) 2020-07-29 08:31
https://tracker.ardour.org/file_download.php?file_id=3791&type=bug
Notes
(0020109)
aeLiXihr   
2017-12-22 12:37   
the issue persists in Ardour 5.12
(0020114)
timbyr   
2018-01-11 13:07   
I can reproduce the freezing issue with cleanup sources and the Session you have attached with 5.12

Based on the gdb backtrace you have referenced and the comment in SessionPlaylist::source_use_count () there may be circular references between compound regions and this is causing an infinite loop/freeze.

Thanks for taking the time to report this and attaching a Session that can be used to reproduce the issue.
(0020115)
timbyr   
2018-01-13 13:00   
I've attached a trace that can be loaded in chrome://tracing that shows the function calls occurring with this session when calling Session::cleanup(At least the first few seconds before I have to interrupt the process so as to not write too large a trace file).

It indicates that the amount of deep nesting (8-9 levels at least) of compound regions in combination with the number of sources in this session may be causing the freezing as in the trace it is still processing the first source out of 0000109:0000400 after 4 seconds.

I'm unsure that the freeze is actually infinite at this point and how there can be circular references.

It does definitely indicate that another method of processing the sources to determine which ones can be "cleaned up" is perhaps needed.

It seems like a method in which each snapshot is loaded and then determining unused sources based on the reference count of the source would much quicker, or possibly just something like storing the Source reference count in a property of the Source on save and using that instead.
(0024848)
Hans Flikkema   
2020-07-29 08:05   
Hi, I want to add that freezing when trying to clean up still happens using Ardour 6.2. It always happens after a longer cut and paste session on for instance 5 recorded Vocals tracks or setting a bass drum track on time.
After that I consolidate those tracks and then I want to clean up and then is when it all goes wrong. When it freezes while cleaning up (selecting clean up unused sources). The project still can be re-opened again but only increases in size. So after this happening the session gets useless. Exporting track is the only options and you loose all mixing, bussing, and track plugin settings.

I did some research and found out it has nothing to do with which audio files are in the audio folder or even which tracks are in the project. Even after deleting all tracks in that pariticular project, is still freezes after clicking remove all unused sources. So it must be some corruption in the "projectname.ardour" file.

I still have a spare copy of one of these crashed projects. If someone wants to examine it i can load it up.
(0024849)
Hans Flikkema   
2020-07-29 08:14   
Crashing when try to clean up unused sources
Platform W10 Home 2004
Ardour 6.2
(0024850)
Hans Flikkema   
2020-07-29 08:16   
Refering to 0024848
Crashing when try to clean up unused sources
Platform W10 Home 2004
Ardour 6.2
Projectfile without audio tracks
(0024851)
Hans Flikkema   
2020-07-29 08:31   
Refering to 0024848 (excusing for repeating this but the file won't load up)
Is there a work around to recover from this project. Deleting all PEAK files didn't solve the problem either?
Is the a way to prevent this happening. would it help if I clean up more frequently?
(0026316)
chance_favre   
2022-01-28 17:08   
Crashing when try to clean up unused sources
Platform Windows 10
Ardour 6.9

Also, clean up of regions or writing to the session file may be involved? With simple projects, after I clean up regions, the number of <Region name=...> XML nodes matches the number of regions displayed in the Editor List. However, in one recent project that has a number of edits in it, the Editor List shows 24 regions after cleanup, but the session file has 2100+ <Region name=...> XML nodes. Maybe that is relevant.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8864 [ardour] bugs minor always 2022-01-21 20:35 2022-01-21 22:47
Reporter: SanbornFan Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: macOS VST2 plugin wrapper offsets gui by few pixels in both x and y directions so right side and bottom edge are chopped off
Description: macOS VST2 plugin wrapper offsets gui by few pixels in both x and y directions. Since the wrapper is sized exactly to fit the plugin then the right side and bottom edge are truncated.

This is not consistent with VST3 and AU plugin wrappers where gui is positioned correctly at 0,0
Windows and Linux versions are also correct. It is only macOS VST2 wrapper that has the problem.

Call to gtk_widget_translate_coordinates appears to be offsetting 8 units(pixels?) in x direction and 6 in y direction
file: mac_vst_plugin_ui.mm line: 212
void
MacVSTPluginUI::lower_box_size_allocate (Gtk::Allocation& allocation)
{
    gint xx, yy;
    gtk_widget_translate_coordinates(
            GTK_WIDGET(low_box.gobj()),
            GTK_WIDGET(low_box.get_parent()->gobj()),
            8, 6, &xx, &yy);
    [_ns_view setFrame:NSMakeRect (xx, yy, allocation.get_width (), allocation.get_height ())];
    NSArray* subviews = [_ns_view subviews];
    for (unsigned long i = 0; i < [subviews count]; ++i) {
        NSView* subview = [subviews objectAtIndex:i];
        [subview setFrame:NSMakeRect (0, 0, allocation.get_width (), allocation.get_height ())];
        break; /* only resize first subview */
    }
}
Tags:
Steps To Reproduce: Open a VST2 plugin such as LennarDigital Sylenth1. Drag the right side and bottom edge of the wrapper window to reveal missing pixels.
Additional Information:
System Description
Attached Files:
Notes
(0026310)
x42   
2022-01-21 22:47   
This dates back to https://github.com/Ardour/ardour/commit/5b28e0bc6fa036464a3f4cf13300819f805d39d4
spacing corresponds to the container (box) spacing. Chances are that those have changed since...

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8390 [ardour] other minor always 2020-08-31 20:10 2022-01-20 20:21
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 6.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour comes bundled with proprietary software and plug-in demo versions
Description: I've talked about this before, but I guess it got lost, so I'm bringing it up again.

1. Ardour for Linux comes bundled with proprietary Harrison GUIs for some of the stock Ardour plug-ins.

I think the GUIs are nice and all, but I run Ardour *specifically* because it's free software, and I just don't want to have it served with proprietary binary code that I have no idea what is doing.

I'd be most happy to see the Harrison GUIs be open-sourced as contribution to Ardour, but I don't expect that.

Since that's the case, I want to be able to have Ardour install without any proprietary plug-ins or plug-in GUIs.
And since Ardour's big selling point is the open-source nature of the project, I'd rather have these as opt-in than opt-out.
I guess the unofficial builds available in various Linux distributions will come without them, but I'd like to not be forced to use these to get a 100% free-software package.

2. Ardour for Windows comes bundled with demo versions of proprietary Harrison plug-ins.
I guess Windows users aren't complaining about it, but honestly this is nothing more than an annoying advertisement for Harrison software - these plug-in are near useless unless the user purchases a license. The Harrison plug-in GUIs are at least fully functional. I think it'd be best to get rid of this stuff, or at least provide an opt-out during installation. Or better: an opt-in.

3. There's also useless demo versions of paid x42 plug-ins bundled, which at least are free software, but still this is shovelware, becasue they are useless unless the user purchases a license.

I have nothing against paid FOSS plug-ins, and I think the x42 plug-ins are of great quality, but I'd highly prefer if Ardour bundled only fully functional plug-ins, not placeholders asking for a license.

---

One of the first things I do on any fresh Ardour installation on Windows is to mark all the useless demo plug-ins as hidden. This doesn't create a good user experience where 90% of the stock plug-ins turn out to be just cardboard cut-outs asking for more money (the user has already paid *something* to get the Windows build of Ardour).

I know this is done to help fund Ardour's development and support it's creators (x42 plug-ins etc.) and you probably have a deal with Harrison to bundle their demo versions, but it's not looking good for the users, especially those who are sensitive to software freedom.

Please provide users with a choice to *not* install proprietary GUIs or demo versions of plug-ins with Ardour.
Instead - please consider bundling fully functional plug-ins like x42 MIDI Filters, x42 DPL, x42 Tuna and x42 Autotune - these would greatly compliment Ardour's stock plug-in set and give users a better experience.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024994)
x42   
2020-08-31 21:10   
> And since Ardour's big selling point is the open-source nature of the project

https://discourse.ardour.org/t/is-open-source-a-diversion-from-what-users-really-want/102665

> and you probably have a deal with Harrison to bundle their demo versions

Only an agreement that we can legally do so. We're glad that Harrison allows those to be bundled.
The main benefit here is that you can load sessions of other using the plugins -- the limitation is only the custom plugin GUI. The DSP is excellent, generally better than free software alternatives and you get it gratis. Even the generic UI works and they're even using a libre standard (LV2), I wish more plugin vendors would follow their lead.

No DRM. No hardware keys, no demo noise. -- I honesty think we should promote this and get more companies to ship cross-platform plugins in similar fashion if they cannot release the software under a free/libre license.

The only reason to not want them is a purism, and I found that best approach is to let those guys weed out files not matching their ideology themselves. Really, they should not trust us in the first place even if we add an opt in/out. :)
(0024995)
x42   
2020-08-31 21:12   
> I know this is done to help fund Ardour's development and support it's creators

Actually that's not the reason.
The plugins were added for user's convenience, because users asked if we we can include the plugins that are bundled with Mixbus also with Ardour.
(0024996)
unfa   
2020-08-31 22:35   
Thanks for clearing this up. I'm gonna read up on Paul's post later as it's quite a lengthy read.

It seems my assumption that the main drive for these plug-ins / GUIs to be included was upselling or product cross-promotion was wrong. And I am glad to be proven wrong there.

I know most users will not complain about it, or even notice - but for people like me who have decided on principle to run as little proprietary software as possible - this is a bummer.
Yes, we can dig files up, ask around and delete what we don't want after the installation, or just depend on unofficial builds where package maintainers have stripped this out for us.
Yet - it's not convenient and it's creating a suboptimal experience for a certain group of Ardour users if they choose to use official Ardour binaries.
I'd expect these should give the best possible experience to all users, shouldn't they?

It's not far away to say "if you don't like that just make your own build" - and it's not reasonable to expect regular users to be able to jump such hoops. And digging into program files to weed out proprietary plug-in binaries is far beyond the reach of an average non-savvy user. Should these people be forced to use proprietary software when they download Ardour (and open a-EQ), when it's advertised as a free/libre program? It's a bit misleading and I am surprised nobody has raised this issue before me.

I understand that it wasn't done viciously, but I think a clear information and a checkbox or two in the installer would go a long way here.

[ x ] Install additional open-source x42 plug-in demo versions
[ x ] Install additional proprietary Harrison plug-in demo versions

What do you think?
(0025022)
jumase   
2020-09-09 19:44   
I started using Ardour mainly as a political/ethical reason -political in an general/wide/'ancient' sense: politike techne, how we (want to) treat each other on a community. I was taught audio processing on an institution using proprietary software, but I wanted to prove (myself) I could be able to perform similar tasks with a more politically committed software.

And I see it's a difficult topic what Paul posted. I couldn't contribute as a developer as I don't know any program language. As far as I can get is reporting bugs, supporting as I can, spreading among my contacts, learning how to use the software and using it. I think that we all are influenced by conservative ideas (we are born in between them) so there are great chances that we get more "advices" to do it the way it is supposed to (as many users would ask too, mainly in DAW stuff). I know you know that, otherwise you wouldn't keep working on the projects and wouldn't have written all those post stating your point of view.

On the other hand, what you call "gratis" (in term of money), is not in other aspects. For example, the company is getting advertising as an exchange (the logo is there and I guess you could not remove it). Is it necessary to apply the proprietary GUI on Ardour's native plugins? I don't understand how is that allowing to load sessions that use Mixbus plugins; or I got it wrong?

We do put trust in many projects, not only Ardour. A community is based on trust, any relation is based on trust. And one obviously get some clues, judge, pre-judge, based on what others do... Think about food: there's a long chain that's imposible to be verified by 'external' people.

I agree that there would be fair not to include proprietary software by default, and a good approach could be what unfa proposes about extra demo plugins. And what about native plugins (a-EQ, a-Compressor, a-Delay)? Why do they have to use Mixbus GUI?
(0025023)
jumase   
2020-09-09 23:52   
>best approach is to let those guys weed out files

Sorry, never thought you were being literal :)
(0025024)
x42   
2020-09-10 00:01   
just delete the LV2/Harrison.lv2 folder
(0025025)
x42   
2020-09-10 00:03   
> And what about native plugins (a-EQ, a-Compressor, a-Delay)? Why do they have to use Mixbus GUI?

The LV2 plugin standard allows separate 3rd party GUIs for any plugin. In the last 3 years nobody stepped up and provided commercial-quality cross-platform UIs.
Ben at Harrison eventually volunteered to make some (a-eq is done, the others are functional but still being worked on).

If someone creates a better GUI, we'll happily ship that instead.

The goal of the Ardour bundles from ardour.org/download is to create a good out-of-the-box experience for typical users.
(0025026)
jumase   
2020-09-10 17:51   
I see the point, thanks for clarifying.
(0025082)
x42   
2020-09-29 18:34   
I forgot to follow up, but since Sep/10 the windows installer allows to opt-out of installing the Harrison plugins.
I hope this concludes this issue.
(0025083)
x42   
2020-09-29 18:34   
Addressed in 6.3-8-gf61ecae4b2
(0025084)
unfa   
2020-09-29 23:32   
Thanks! What about the Linux installers? Do they provide a choice too?
(0025085)
x42   
2020-09-30 01:04   
For GNU/Linux, 6.3 installers already offer to opt-out (that was changed in 6.2-201-g81fb723561; August/21).

macOS does not have an installer, so we cannot change this there.
(0025087)
unfa   
2020-09-30 09:22   
Thanks! I'll check this out and let known if I see any issues.

I guess for MacOS a solution could be to provide two packages - one with and one without the proprietary components?
(0025099)
unfa   
2020-10-02 11:18   
I've just got a development build and intalled it - it didn't ask about the proprietary plug-ins, and just installed them as usual:

$ pwd
/opt/Ardour-6.3.123/lib/LV2
[unfa@unfa-desktop LV2]$ ls
a-comp.lv2 a-delay.lv2 a-eq.lv2 a-exp.lv2 a-fluidsynth.lv2 a-reverb.lv2 gmsynth.lv2 Harrison.lv2 reasonablesynth.lv2

Here's the installer output:

$ ./Ardour-6.3.123-x86_64-gcc5.run
Verifying archive integrity... 100% All good.
Uncompressing Ardour 100%

Welcome to the Ardour installer

Ardour will be installed for user unfa in /opt

[sudo] password for unfa:
Fri Oct 2 01:13:54 PM CEST 2020
Architecture is x86_64
Checking for required disk space
Bundle is on tmpfs filesystem
Unpacking bundle for x86_64
Bundle unpacked

Checking system libs to see if they are compatible with Ardour.


Found existing Ardour installation.
Do you want to run the uninstaller /opt/Ardour-5.12.0.uninstall.sh ? [y/n]: n

Found existing Ardour installation.
Do you want to run the uninstaller /opt/Ardour-6.3.0.uninstall.sh ? [y/n]: n

Found existing Ardour installation.
Do you want to run the uninstaller /opt/Ardour-6.3.55.uninstall.sh ? [y/n]: n

Installing Ardour 6.3.123 in /opt

Adding Ardour to the applications menu

Creating a desktop link for Ardour in /home/unfa/Desktop

Copying uninstall script to /opt


Creating link Ardour6 in /usr/local/bin


Checking to see if Jack is installed

Jack already present

Jack Version Check OK (jackdmp version 1.9.14 tmpdir /dev/shm protocol 8)

which: no qjackctl in (/home/unfa/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/var/lib/flatpak/exports/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)

The program QjackCtl is missing from this system.
QjackCtl is an extremely useful tool for any system that runs JACK applications like Ardour.
We recommend that you install it.

Install QjackCtl using system software repository? [y/n]: n

Cleaning up

!!! Install Complete !!!

Press ENTER to exit installer:
(0025100)
x42   
2020-10-02 11:59   
Oh dear, I've screwed up the path (missing `lib/`), thanks for catching that.

Fixed in https://github.com/Ardour/ardour/commit/e2639a1a588b8f75b101eb48bb717b78dabee7e3
(0025128)
unfa   
2020-10-18 15:08   
Allright, I've tested this and the proprietary plug-in opt-out works - thanks!

I haven't tested a Windows build and the x42 demo versions - what about these?

What do you think about bundling the free x42 plug-ins instead?
These would provide great value to users, and do not require any payment.
I think they'd greatly compliment Ardour's stock plug-in set.
(0025129)
x42   
2020-10-18 15:13   
While they're free-software the ready-to-run x42 binaries are commercial. Probably not what you'd expect either.
(0025131)
unfa   
2020-10-18 19:39   
Yes, but there's a bunch of "free" (no cost) ones as well listed here:
https://x42-plugins.com/x42/
Digital Peak Limiter, Autotune, setBfree and more - what about these?
(0025132)
x42   
2020-10-18 20:39   
I prefer not to tie release cycles of those plugins with Ardour releases.
5.12 -> 6.0 was 2 1/2 years without an ardour release, while at the same time there have been 16 x42-plugins releases.

And where would we stop? Bundle LSP, or DPF plugins?

Ardour's philosophy is to remain as neutral as reasonable and leave coloring DSP out (as opposed to Mixbus which focuses on a given sound character).
One thing I would be interested in is adding a few more a-*/ACE-* plugins that have tight integration in a matter that plugins otherwise cannot provide.
e.g. build-in noise-repellant, right-click on a region -> analyze and remove noise faster than realtime.
(0025147)
soundguy30   
2020-10-24 07:35   
Ardour should maybe have a build version that is just free open source version no other plugins from 3rd parties.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8128 [ardour] bugs minor always 2020-05-20 06:40 2022-01-20 14:55
Reporter: CTS Platform: Apple Macintosh  
Assigned To: OS: macOS  
Priority: normal OS Version: 10.15.4  
Status: new Product Version: 6.0-pre1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: First note of MIDI clip not visible in UI
Description: Seems like MIDI notes can disappear from the UI when the leading edge of the MIDI region is adjusted to touch note onsets. The notes do still sound however, so they are still there and audio is behaving correctly.
Tags: Midi
Steps To Reproduce: 1. Create empty MIDI region
2. Draw some notes on the grid
3. Adjust start of MIDI region until it touches the beginning of a MIDI note (both region edge & note onset snapped to the grid)
Additional Information: Version is 6.0.rc1.371
Attached Files:
Notes
(0024212)
CTS   
2020-05-20 06:45   
Update. In some instances the note no longer sounds after it disappears in the UI. I am seeing both behaviors - sometimes notes DO sound and are invisible and sometimes they neither sound nor are visible.
(0024263)
CTS   
2020-05-24 23:02   
After a bit more examination and looking at other issues, I think this is just another symptom of issue 7947. Looks like sometimes MIDI notes get microshifted forwards and backwards in various scenarios and quantization/snapping only moves notes to some offset compared to the grid.

In my case, it seems like MIDI notes that had been shifted forwards slightly were being removed when the region start snapped to the grid, which is expected since the note onset occurs before the snap point.
(0026282)
bartart3d   
2021-12-27 19:44   
In my case here, I imported a midi file, created with Musescore, I split the region with the cut tool.
Consistently all notes at the starting edge of split regions disappear.

Running Ardour 6.9, rev 6.9~ds0-1 on Ubuntustudio 21.10
(0026305)
hoadao3493   
2022-01-20 14:55   
Your article is very good and useful, thank you for sharing, https://mig8.asia hopes that next time you will have more good articles to send to all readers.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8861 [ardour] bugs minor always 2022-01-15 15:00 2022-01-15 15:00
Reporter: 12strings2hands Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: “No Align” warning initiated in error
Description: The “No Align” warning will appear by connecting the output of a track to a buss and also connect the track output to a hardware output (keep it all either L or R to reproduce).
Example:
 mono Track 1 left side goes to left side of mono buss 1.
“No Align” will blink on if you also attempt to send Track 1 left side to any hardware output left side.
I don’t think this should raise an error but it does.
Tags: feedback, workflow
Steps To Reproduce: The “No Align” warning will appear by connecting the output of a track to a buss and also connect the track output to a hardware output (keep it all either L or R to reproduce).
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8860 [ardour] bugs minor have not tried 2022-01-14 17:24 2022-01-14 19:55
Reporter: imstre Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 7  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ardour 7 does not start
Description: does not start(
Tags:
Steps To Reproduce: open ardour7
Additional Information:
System Description
Attached Files: Ardour.png (131,241 bytes) 2022-01-14 17:24
https://tracker.ardour.org/file_download.php?file_id=4151&type=bug
png
Notes
(0026297)
x42   
2022-01-14 17:42   
That "Microsoft Visual C++" error is weird.
Ardour does not use MSVC, nor require or involved anything from "Microsoft Visual C++".

I have no explanation what could lead to this.
Perhaps some [VST] plugin, or maybe some Antivirus tool?
(0026298)
x42   
2022-01-14 17:59   
Those icon warnings are also a mystery.

Have you installed Ardour to the C:\ drive?
(0026299)
imstre   
2022-01-14 19:44   
"Have you installed Ardour to the C:\ drive?" - Yes in C:\Program Files\Ardour7
With 5 or 6 any version has never had tha.

"Perhaps some [VST] plugin, or maybe some Antivirus tool?" no, heavily and newly installed.
with version 7 I always get this error
I thought maybe you'll fix it
but I see no
(0026300)
imstre   
2022-01-14 19:46   
mistake because I don't have that much chanel input..
version 6.9 great works
(0026301)
imstre   
2022-01-14 19:47   
i don't use antivirus
(0026302)
x42   
2022-01-14 19:48   
There is not version 7, yet. Latest release is 6.9, and that is known to work on Windows.
Also current pre-alpha release runs on windows, albeit with many other issues e.g, https://tracker.ardour.org/view.php?id=8859
(0026303)
imstre   
2022-01-14 19:53   
I about that it as a new version (7.0-pre0) - 263.76 MiB v7.0-pre0-1764 2022-01-14
Sha1: 1a425ea5c4514bf802f928cc519ec5ba8b2f919a
6.9 works great for my
(0026304)
imstre   
2022-01-14 19:55   
I realized I wasn’t reporting :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8856 [ardour] bugs minor always 2022-01-09 22:06 2022-01-09 22:44
Reporter: remi.thebault@gmail.com Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Websockets roll off relocates to previous position
Description: When stopping transport with the websocket API, the transport always relocates to where it was before roll start.

The bug is hit:
 - if starting transport from websocket and stopping transport from websockets.
 - if starting transport from Ardour UI and stopping transport from websockets.

The bug is not hit when stopping transport from Ardour UI, even if it was started from the websockets.
Tags: websockets
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026293)
remi.thebault@gmail.com   
2022-01-09 22:44   
https://github.com/Ardour/ardour/pull/660

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8852 [ardour] bugs minor always 2022-01-04 20:17 2022-01-06 09:05
Reporter: JonnyMako Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash using Pipewire/Jack and playing audio at 2x
Description: With Ardour running via Pipewire Jack, when I play youtube at 2x on my Firefox browser, after a certain amount of time, Ardour crashes.
Tags:
Steps To Reproduce: 1. Run Ardour using Pipewire Jack
2. Open Firefox and let any Youtube video run at 2x
3. After some time (sometimes in minutes sometimes upto an hour), Ardour crashes
Additional Information: #0 0x00007f85b0ce8cbb in () at /usr/lib/pipewire-0.3/jack/libjack.so.0
0000001 0x00007f85b268e535 in msort_with_tmp.part () at /usr/lib/libc.so.6
#2 0x00007f85b268e4c2 in msort_with_tmp.part () at /usr/lib/libc.so.6
#3 0x00007f85b268e4c2 in msort_with_tmp.part () at /usr/lib/libc.so.6
0000004 0x00007f85b268e4c2 in msort_with_tmp.part () at /usr/lib/libc.so.6
0000005 0x00007f85b268e4c2 in msort_with_tmp.part () at /usr/lib/libc.so.6
#6 0x00007f85b268e4c2 in msort_with_tmp.part () at /usr/lib/libc.so.6
#7 0x00007f85b268e88a in qsort_r () at /usr/lib/libc.so.6
0000008 0x00007f85b0cef4c2 in jack_get_ports () at /usr/lib/pipewire-0.3/jack/libjack.so.0
0000009 0x00007f85a5cc5fb8 in ARDOUR::JACKAudioBackend::get_ports(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, ARDOUR::DataType, ARDOUR::PortFlags, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) const ()
    at /usr/lib/ardour6/backends/libjack_audiobackend.so
0000010 0x000055d6c263fa75 in ()
0000011 0x000055d6c235c115 in ()
0000012 0x000055d6c264f36b in ()
0000013 0x00007f85b4179798 in AbstractUI<Gtkmm2ext::UIRequest>::handle_ui_requests() () at /usr/lib/ardour6/libgtkmm2ext.so.0
0000014 0x00007f85b409ec1f in BaseUI::request_handler(Glib::IOCondition) () at /usr/lib/ardour6/libpbd.so.4
#15 0x00007f85b40aa557 in cross_thread_channel_call_receive_slot(_GIOChannel*, GIOCondition, void*) () at /usr/lib/ardour6/libpbd.so.4
0000016 0x00007f85b3e35435 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#17 0x00007f85b3e897b9 in () at /usr/lib/libglib-2.0.so.0
0000018 0x00007f85b3e34ab3 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
0000019 0x00007f85b3aaf9fe in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0
0000020 0x00007f85b4171649 in Gtkmm2ext::UI::run(Receiver&) () at /usr/lib/ardour6/libgtkmm2ext.so.0
0000021 0x000055d6c1f7a1ba in main ()
System Description
Attached Files:
Notes
(0026291)
x42   
2022-01-06 09:05   
Rule#1: If it does not crash when using JACK (not Pipewire's emulation thereof), then it is a Pipewire bug.

This particular issue (jack_get_ports) should already fixed in pipewire/git

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8851 [ardour] bugs minor have not tried 2022-01-04 18:21 2022-01-05 17:17
Reporter: Jimno Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: changing the buffer size affect my automations position!
Description: I started a project, recorded the full song at 48kHz 256 buffsize everything went well, I closed that project. the next day I opend qjackctl changed the buffer size to 512 (AND SAME SAMPLE RATE) to mix it with less DSP load and used some automations. One day after I needed more buffer size so that it can handle all the plugins I used last time so switched to 1024 (AND SAME SAMPLE RATE) and here begins the weird part, I noticed that my automations have moved! thought that was only on my output though when I exported that, the automation process felt delayed and bad...
Tags:
Steps To Reproduce:
Additional Information: someone told me to re-open the session on the same amount of buffer size when I first created those automations and it felt okay
(no delay) the real problem is: I tried to live with that but DSP load was high when I created the automations, now I must mix the song on 512 with high DSP and its hard!
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8854 [ardour] bugs minor always 2022-01-05 17:13 2022-01-05 17:13
Reporter: Jimno Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: changing the buffer size affects my automations position!
Description: I started a project, recorded the full song at 48kHz 256 buffsize everything went well, I closed that project. the next day I opend qjackctl changed the buffer size to 512 (AND SAME SAMPLE RATE) to mix it with less DSP load and used some automations. One day after I needed more buffer size so that it can handle all the plugins I used last time so switched to 1024 (AND SAME SAMPLE RATE) and here begins the weird part, I noticed that my automations have moved! thought that was only on my output though when I exported that, the automation process felt delayed and bad...
Tags: automation
Steps To Reproduce: I just open ardour at a specific buffersize using qjackctl (example: 256)
make some automations (very accurate ones)
save the project.
open qjackctl again change the buffer size (example 2048)
open the project on ardour again and listen
the automation lines will feel late (sonically speaking)
Additional Information: someone told me to re-open the session on the same amount of buffer size when I first created those automations and it felt okay
(no delay) the real problem is: I tried to live with that but DSP load was high when I created the automations, now I must mix the song on 512 with high DSP and its hard!
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8853 [ardour] features minor have not tried 2022-01-05 15:53 2022-01-05 15:53
Reporter: victorvianna Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [feature request] Porting to the web with WebAssembly
Description: Photoshop got recently ported to the web via a joint effort of Google and Adobe.
https://web.dev/ps-on-the-web/
It would be awesome if we could do the same for Ardour.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8790 [ardour] bugs minor always 2021-08-31 02:03 2022-01-05 11:11
Reporter: dean48 Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: normal OS Version: 10  
Status: confirmed Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Using automation with arturia pigments changes pitch
Description: When I use Pigments 3 synth and use the sequencer, If I assign automation to a parameter or macro such as the decay envelope the notes unpredictably shift key/pitch when using automation. The sequence also plays when a note isn’t being played.
Tags: 6.8
Steps To Reproduce: 1. Open ardour
2. Open pigments 3 synth
3. Use a sequencer preset on pigments
4. Enter a single long note into ardour
5. Use automation to change macros in pigments 3
6. Notes become unpredictable and don't follow the sequence set up in pigments 3
Additional Information: Pigments 3 has free demo available here https://www.arturia.com/products/analog-classics/pigments/overview#en

This link shows the issue: https://youtu.be/L7zuFijfVPw
System Description
Attached Files:
Notes
(0026128)
paul   
2021-08-31 02:48   
confirmed fixed in 6.9 by reporter via forums. https://discourse.ardour.org/t/using-automation-with-arturia-pigments-changes-pitch/106334/10
(0026205)
anonymous   
2021-10-30 02:04   
Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8849 [ardour] features minor N/A 2022-01-04 08:23 2022-01-04 14:23
Reporter: timetre Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow more than 32 Editor Action Scripts
Description: Today, 32 Editor Action Scripts can be registered to allow triggering LUA scripts.
While this is more than reasonable when these actions are triggered via the UI/keyboard, the fact that these actions can also be triggered via OSC offers HUGE possibilities to optimize one's workflow and I find myself having reached that 32 limit already.

If this is an arbitrary limitation, could it be increased to something like 64 or 128 to allow for headroom ?
Of course their OSC exposition counterpart should also be ensured.
Tags: Lua, osc, script
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026288)
timetre   
2022-01-04 08:40   
Note that this limitation could be less of an issue if Editor Actions could receive parameters, say an int or float
Could be that when invoked via button or keyboard the parameter is not passed but invoking via OSC, the parameter could be passed. This would allow to use a single script/EditorAction for multiple things.

Sounds more complicated, not aligned with the philosophy of EditorActions etc ...; so probably a stupid idea but I thought I'd mention it anyway ;-)
(0026289)
x42   
2022-01-04 14:23   
Yes, it is mostly arbitrary. Since actions which are usually bound to keyboard shortcuts, 32 seemed plenty.

If you compile Ardour from source, you can increase it already:

#define MAX_LUA_ACTION_SCRIPTS 32

in gtk2_ardour/ardour_ui.h
https://github.com/Ardour/ardour/blob/547465e1fa1498b1ecd656b35bd2edcea6cc3bbe/gtk2_ardour/ardour_ui.h#L193-L194

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8846 [ardour] features minor N/A 2021-12-30 17:42 2021-12-30 18:25
Reporter: timetre Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Move toggle-exclusive-solo action from Monitor Section code to main Mixer code
Description: As discussed in this thread in the forum, it would be nice if the toggle-exclusive-solo action were defined in the main mixer code instead of the Monitor Section code as it can legitimately be used even if not using the Monitor Section

https://discourse.ardour.org/t/osc-and-toggle-exclusive-solo/106733
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026286)
x42   
2021-12-30 18:25   
It is really a preference, and only for convenience also shown on the monitor section

Ardour > Preferences > Monitoring > Exclusive solo

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8841 [ardour] bugs minor always 2021-12-21 14:56 2021-12-29 14:54
Reporter: mrseiter Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Sever X server memory leak
Description: While Ardour is running, xorg memory allocation grows by about 500kb/s. This eventually exhausts system memory and forces reset. Leak is not associated with any process in xrestop.
Tags: x11
Steps To Reproduce: Run Ardour
Additional Information: This is likely due to the drivers for the Intel Iris graphics processor and may not be correctable in Ardour's code.
System Description
Attached Files: sysinfo.text (15,813 bytes) 2021-12-21 14:56
https://tracker.ardour.org/file_download.php?file_id=4146&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8845 [ardour] bugs minor always 2021-12-29 11:33 2021-12-29 12:27
Reporter: johne53 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Foldback bus / Show Sends can't be deselected if there are no selections
Description: Create a Foldback bus and add a couple of selected tracks, then press 'Show Sends'. As expected, the track display gets switched to show only the assigned tracks.

Now remove the tracks. Firstly, removing a track doesn't remove it from the displayed assignments. Secondly, if you remove ALL the assigned tracks, the 'Show Sends' button becomes inactive (i.e. you can't return the track display to normal any more). You need to assign another track, then hit 'Show Sends' and then remove the newly assigned track. Surely it'd make more sense if removing all he assigned tracks would simultaneously de-select 'Show Sends' if it happens to be activated?
Tags:
Steps To Reproduce:
Additional Information: And to me at least, it'd make more sense if removing an assignment would also remove it from the displayed tracks (i.e. whenever 'Show Sends' is active)
System Description
Attached Files:
Notes
(0026285)
johne53   
2021-12-29 12:27   
I forgot to add that there's an extra problem in Mixbus whereby (when 'Show Sends' is active) the displayed track(s) stop displaying their track name - so it can be difficult to tell which one's which. However, that seems to be okay in Ardour.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8844 [ardour] features minor N/A 2021-12-28 21:09 2021-12-28 21:09
Reporter: Lindisfarne Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Clip list to help navigate big audio projects
Description: As a podcaster, I'd really like to have a clip list.

It could be this:
A side panel that can be toggled into view from the "view"-menu in the menu-bar.
The panel (clip list) would then appear to the left, onto which I'd be able to drag any clips or selections made in a track.
 In this clip list, I could then rename the clip - a great quote, for instance, that I'd like to use later - accordingly, so It'd be easy to find and drag it back in to my project. Maybe even leaving a copy of the clip behind in the list (but with a paler-coloured font), so for instance ambient sounds or music bits could be reused multiple times in one project.
Tags: montage, podcasting, radio
Steps To Reproduce:
Additional Information: I know that both Pro Tools and Hindenburg has this feature, but I have no idea how hard it is to build.
System Description
Attached Files: hindenburg-470x250.jpg (16,517 bytes) 2021-12-28 21:09
https://tracker.ardour.org/file_download.php?file_id=4148&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8843 [ardour] features minor have not tried 2021-12-26 11:27 2021-12-28 15:30
Reporter: erojahn Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature Request: optional Dry/Wet controll for Plugins in channel strip.
Description: I would like to be able to mix my processed Signal with the original inside the channelstrip. There is a lot of plugins that dont support that in their controls. I would like to add an dry/wet control to these Plugins inside the channelstrip. It is not too often it is needed so it could be also a hidden controll.
Thank you for reading! :)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0026284)
x42   
2021-12-28 15:30   
We have considered this before but so far chose to not implement it for the following reasons:

The problem is that the host does not know the correct way to do this without introducing artifacts.
Proper Dry/Wet control depends on the DSP (as does properly bypassing a plugin). EQs are a prime example for this.

Additionally this would introduce overhead, even though it is minute, it can become significant if the session scales up.
Ideally dry/wet is only added in place where it is needed, on demand.

For your case there are 3 options currently:
 * Use Aux Sends to a separate bus to duplicate the steam
 * Duplicate the track with a shared playlist, use different set of plugins on both
 * Use Pin-connections to pass the signal around the plugin. Then Mix the result using a cross-fade or A/B plugin e.g. https://i2.paste.pics/de459e12bdc271e1844372ed68292f68.png

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8842 [ardour] features minor N/A 2021-12-26 11:22 2021-12-26 11:22
Reporter: erojahn Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature Request: More delaytime setttings in ace-delay
Description: I would love the Ardour community plugin to be able to set more complex delaytimes. For example every third quarter.
I like the Calf approach to setting the delaytimes.
Thanks for reading :)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Calf - Vintage Delay.jpg (93,575 bytes) 2021-12-26 11:22
https://tracker.ardour.org/file_download.php?file_id=4147&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8839 [ardour] features minor have not tried 2021-12-17 11:22 2021-12-17 11:58
Reporter: snuggle Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: File Extensions
Description: Dear Ardour-Team,

Files have the extension filename.ardour. When using a new version, the old file is changed to filename-3002.ardour. If the originally used version is even older, filename-3002-3002.ardour is created.

It would be nice if Ardour would directly use as extension .ardour5 for version 5 and ardour6 for version 6. Then you could see directly with which version the song was originally recorded.
Best of all it would be nice if there was the possibility to leave in a newer version with "save as ardour5" etc in the old format.

Thank you
Regards
Reiner
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026277)
x42   
2021-12-17 11:35   
The file-extension does not necessarily change with major versions.
e.g. Ardour3.x has 3 different revisions (3000 -3002), and then the file-format remained unchanged until Ardour 5.12 -> 6.0 transition.
 
Back-compatibility is important, but forward-compatibility is essentially impossible.
(0026278)
snuggle   
2021-12-17 11:58   
Thank you for this information.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7714 [ardour] bugs minor always 2018-12-26 21:29 2021-12-15 11:34
Reporter: unfa Platform: PC  
Assigned To: OS: Linux Mint  
Priority: normal OS Version: 18.3 KDE5  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ripple Edit Mode doesn't consider track groups
Description: I'd expect the Ripple Edit Mode to shift around all regions on all tracks together, or at least do so with respect to the Track Groups - unfortunately that's not the case.

It'll work great, but only in the scope of a single track - so as soon I have regions on multiple tracks - any editing done in the Ripple Edit Mode will break their relative sync, so it's not making anything easier, like I'd hoped it would.

Or maybe I'm just missing something?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025349)
bachstudies   
2020-12-23 19:25   
I think grouped ripple editing only works if the starts of regions are exactly aligned i.e. immediately after import or after making a cut. I would really appreciate a multi-track ripple edit mode as in Samplitude and Reaper with any markers automatically moved along with the regions.
(0026275)
Blindekinder   
2021-12-15 11:34   
It could be critical for some use. For example:
Editing a piece with >30 people speaking, one track for each. We are working with hundredths of regions since the interventions are all mixed. When we want to insert a region, we have to Select All after edit point (ctrl+shft+E), and move all together. If by accident one moves a fade or resize a region without unselecting, ALL regions will be affected.

Moving all region in all tracks after edit point in ripple mode edit is more secure and no need to make selection before moving.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8837 [ardour] features minor N/A 2021-12-12 17:05 2021-12-12 17:05
Reporter: finite_time Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature Request: plugin bypass automation
Description: It would be beneficial to be able to bypass a given plugin in a given track with automation.
Tags: automation, bypass, plugin
Steps To Reproduce:
Additional Information: This could be implemented as a bypass option near Fader, Mute, Pan options (see fig_1) with a drop-down menu to chose the existing plugin to bypass. A particular form of this request is implemented in the Calf plugins through an existing Active or Bypass function (see fig_2), but most plugin don't offer this option.
System Description
Attached Files: fig_1.png (22,650 bytes) 2021-12-12 17:05
https://tracker.ardour.org/file_download.php?file_id=4144&type=bug
png

fig_2.png (38,271 bytes) 2021-12-12 17:05
https://tracker.ardour.org/file_download.php?file_id=4145&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8836 [ardour] bugs minor always 2021-12-09 12:05 2021-12-09 12:06
Reporter: szszoke Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour does not start up when Elektron Digitone is connected via USB in Overbridge mode
Description: Whenever I have my Digitone (FW 1.31) connected via USB in Overbridge mode to my computer, Ardour refuses to start up. I tried running Ardour from the console to see if something useful is printed but there is nothing.
Here is the output:

C:\Program Files\Ardour6\bin>Ardour.exe -P -O -d

C:\Program Files\Ardour6\bin>Ardour6.9.0 (built using 6.9 and GCC version 4.9.1)
Crash Log: C:\Users\szszo\AppData\Local\Ardour6\CrashLog\Ardour-6.9.0-crash-1639051252.txt
Ardour: [INFO]: MMCSS Initialized
Ardour: [INFO]: Your system is configured to limit Ardour to 2048 open files
ARDOUR_CONFIG_PATH not set in environment
Ardour: [INFO]: Loading system configuration file C:\Program Files\Ardour6\share\ardour6\system_config
Ardour: [INFO]: Loading user configuration file C:\Users\szszo\AppData\Local\Ardour6\config
Ardour: [INFO]: No H/W specific optimizations in use
Ardour: [INFO]: Loading plugin meta data file C:\Program Files\Ardour6\share\ardour6\plugin_metadata\plugin_tags
Ardour: [INFO]: Loading plugin statistics file C:\Users\szszo\AppData\Local\Ardour6\plugin_metadata\plugin_stats
Ardour: [INFO]: Loading default ui configuration file C:\Program Files\Ardour6\share\ardour6\default_ui_config
Ardour: [INFO]: Loading user ui configuration file C:\Users\szszo\AppData\Local\Ardour6\ui_config
Ardour: [INFO]: Loading 452 MIDI patches from C:\Program Files\Ardour6\share\ardour6\patchfiles
Ardour: [INFO]: Loading color file C:\Program Files\Ardour6\share\ardour6\themes\dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file C:\Program Files\Ardour6\share\ardour6\clearlooks.rc
Ardour: [INFO]: Loading bindings from C:\Program Files\Ardour6\share\ardour6\ardour.keys
Loading ui configuration file C:\Program Files\Ardour6\share\ardour6\clearlooks.rc
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 9 5950X 16-Core Processor
Tags: digitone, elektron, overbridge
Steps To Reproduce: 1. Set USB CONFIG on Digitone to OVERBRIDGE
2. Connect Digitone to computer
3. Launch Ardour
Additional Information: There is an "Overbridge Engine" application that implements Overbridge mode as far as I know. Having this application running or not doesn't make a difference.

If I start up Ardour with the Digitone disconnected and then connect it, I can select it as an ASIO device within Ardour and I can see activity on the Recorder tab for all the input tracks.

If I set the USB CONFIG on the Digitone to USB AUDIO/MIDI then Ardour will start up as expected.

Is there a way to get more verbose logs out of Ardour?
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8661 [ardour] features minor have not tried 2021-04-11 09:16 2021-12-07 12:19
Reporter: DonJaime Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Gracefully ignore unknown plugin port types
Description: Some plugins have CV signal ports, which Ardour can't handle, but still provide useful signals on other ports. For example, the midimsg plugins (https://github.com/blablack/midimsg-lv2) can turn incoming MIDI messages into other MIDI messages (useful) and/or CV signals (no use in Ardour). Ardour refuses to insert these plugins.

It would be useful if Ardour would insert the plugin and let me use the usable ports. It could either completely ignore the unusable ports or (for forward compatibility) show them in the GUI but not allow connections. MIDI and audio ports are already shown in different colours and can't be connected to each other; unusable ports could be a sad dead grey, for example.
Tags:
Steps To Reproduce: Try to insert one of these plugins in Ardour. Dialog:

The plugin "...." could not be loaded
See the Log window for more details (maybe)

And in the Log window:
[ERROR]: LV2: "...." port 4 has no known data type
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7886 [ardour] features minor have not tried 2020-01-27 02:25 2021-12-07 12:19
Reporter: milk Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Support for the recording/editing CV signal?
Description: CV signal essentially being the same as audio signal but often DC and thus (by default) unsuitable for direction to speakers (without some mechanism of intention required to be setup by the user).

Such signal could come from JACK client CV ports or LV2 plugin CV ports. Further possibilities include recording automation from modular synth hardware or applications such as VCV Rack.

More information is available on https://linuxmusicians.com/viewtopic.php?f=1&t=20701
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020933)
x42   
2020-01-27 03:00   
I appreciate your enthusiasm to push every project to support CV, but I think in case of Ardour (and some others) it's misguided and we'd be much better off with more widespread use LV2:Atom sequences, or VST3 sample-automation.

sparse events require significantly less CPU power to process and are equivalent for all purposes.
also keep in mind that many LV2 plugins with CV ports don't even process CV signals sample accurately for that very reason.

That being said It would be great to have a LV2 plugin that takes parameter automation (port or Atom Sequence) and turns it into a CV data-stream. That plugin could be integrated or included with Ardour.
(0025681)
DonJaime   
2021-04-08 12:38   
It would be useful if Ardour could at least gracefully ignore CV ports on plugins. If I want to play/record MIDI while using one of the midimsg plugins, for example, (https://github.com/blablack/midimsg-lv2), I have to use Jack, load the plugin in Carla, and fiddle around with the connections. If I try to insert the plugin in Ardour I get:

The plugin "Midi AfterTouch (Channel Pressure)" could not be loaded
See the Log window for more details (maybe)

And in the Log window:
[ERROR]: LV2: "Midi AfterTouch (Channel Pressure)" port 4 has no known data type

Is there some deep technical reason why Ardour can't just ignore ports it can't do anything with?
(0025689)
x42   
2021-04-09 18:41   
> Is there some deep technical reason why Ardour can't just ignore ports it can't do anything with?

None that I can think of just now. perhaps compatibility once CV support gets added.
Yet generally plugins with CV I/O won't work properly until Ardour supports CV for control and allows patching CV networks.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8696 [ardour] bugs minor always 2021-05-08 15:41 2021-12-06 22:43
Reporter: marrs Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Waves plugins do not render correctly
Description: The skin of waves plugins does not render correctly. The background image appears to be rotated through 180 degrees. The particular plug-in shown is the Waves C6 Multiband Compressor and I've seen the same behaviour with the Linear Phase Multiband Compressor as well.

The issue exists for both VST and AU plugins.
Tags: Waves
Steps To Reproduce: Insert the plugin into a channel
Additional Information:
System Description
Attached Files: Screenshot 2021-05-08 at 16.24.14.png (201,198 bytes) 2021-05-08 15:41
https://tracker.ardour.org/file_download.php?file_id=4025&type=bug
png
Notes
(0026271)
hpfmn   
2021-12-06 22:43   
As proposed in 0008510 I compiled ardour on macos 11.6 with 11.1 SDK. Now the plugins are rendered correctly but I cannot interact with UI. It doesn't respond to clicks or anything. But maybe also there is something wrong with my build since also CMD+Q for example doesn't work. Do you provide a Version of ardour with a newer SDK for acounts that sponser you?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8835 [ardour] bugs minor always 2021-12-05 19:56 2021-12-05 19:56
Reporter: mixdoctor888 Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Initial Setup: list of available drives not refreshed after a disk becomes available
Description: After plugging in a external hard drive, it does not show up in the list of available drives during the initial setup process.
Tags:
Steps To Reproduce: 1. Start Ardour after a fresh install
2. Have an external hard drive that you want to store your sessions to unplugged
3. Plug it in and wait for it to mount. The drive never shows up even after going backward and forward.
4. The drive appears in the list when you restart Ardour

Desired behavior:

Listen for device changes and update the view when a new drive is attached. At minimum, I believe this should be done when the view loads and not when the program starts.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8834 [ardour] bugs minor always 2021-12-03 16:11 2021-12-03 16:11
Reporter: sweptotter Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 6.8&6.9 crash when trying to add point to CC 'curves'
Description: Had this problem several months ago. Now returned.
Had been editing as above fine then repeated crashes when using pencil to add.
Have had to resort to dragging extraneous existing points (created by external ctller in rec)
Tags:
Steps To Reproduce: can upload project folder sans Audio files if you wish
Additional Information: have some 13 automation tracks. 1st 5 edit fine. All others I've tried crash repeatedly (you get bored after a bit)
Trying Hide All then showing one of the problem track(65) made no difference
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8833 [ardour] bugs minor random 2021-12-02 19:49 2021-12-03 04:09
Reporter: merejo Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Win 10 64BIT, ARDOUR CRASHES AND DROPOUTS.
Description: System: Asus M5 A97 R2.0
AMD FX 8 Core.
16 G Mem.

The system has crashed when 3 or more plugins have been enabled.
 Plugins are Ik Multimedia, sound effects and instruments.
Kontak player 6.
Dropouts while recording and playback. I suspect buffering issues.
Tags:
Steps To Reproduce: RE-load all again, or try saving all after loading the plugins.
The dropouts are harder to reproduce due to its inconsistency.
Additional Information: I believe it's s system specific problem.
I'm slowly configuring win 10 for audio, looking to reduce the issues
System Description
Attached Files:
Notes
(0026270)
x42   
2021-12-03 04:09   
In Menu > Window > Audio/MIDI Setup what buffersize do you use? Also also soundcard are you using?

Can you try to isolate the issue a bit further? e.g. create a couple of MIDI tracks with only Kontakt and no other plugins.

Are those VST2 or VST3 plugins?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8831 [ardour] bugs minor always 2021-12-01 09:58 2021-12-02 00:31
Reporter: rohanlean Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Inconsistent MIDI messages generated by playhead repositioning depending on Aux Send vs port connection
Description: When repositioning the playhead, a MIDI track sends Damper Pedal Off (0x4000) and All Notes Off (0x7B00) on all channels when connected via port (i.e. Window ? MIDI Connections), but not when connected by Aux Send.

These same messages are sent on both connections when the track is being muted.

Incidentally this causes unwanted damper pedal noise from at least one virtual piano, so I would also like to enquire whether sending the messages is even correct and if so, how the piano should deal with them.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026269)
x42   
2021-12-02 00:31   
I also noticed that recently.

MIDI panic messages injected and directly sent to synth-plugins on tracks and output ports (which usually feed external synths).
They are not produced at the input and passed though, because there may be multiple plugins and some "eat" MIDI messages, or a track may not monitor input (but play from disk) so it would be lost.

But it seems there is some inconsistency here with MIDI busses with this out-of-band data. The goal is to not collect the panic message from multiple aux-sources (so you get N times the panic message), but re-inject it directly to the synth on the Bus, or the Bus' output.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8830 [ardour] bugs minor sometimes 2021-12-01 01:46 2021-12-01 01:46
Reporter: pq2 Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: Mixbus 7.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI notes are misplaced after reopening the file
Description: I have a MIDI track where I am placing MIDI notes as cues for other software and sending them out through BOME network MIDI interface. I place the notes in a specific place in time where other tracks are playing music and sound effects. After re-opening the file the midi files are misplaced, they are still in order, but not in the right place. I've fixed it a couple of times, but, as the file gets bigger, it is becoming annoying.

I am attaching the MIDI file converted to text.
Tags: Midi
Steps To Reproduce: Setup a MIDI track, add MIDI notes on a single MIDI space. Save, close and re-open, the files are not in the same place. No tempo changes.
Additional Information:
System Description
Attached Files: m2.txt (3,482 bytes) 2021-12-01 01:46
https://tracker.ardour.org/file_download.php?file_id=4142&type=bug
MIDI Signals-2.mid (576 bytes) 2021-12-01 01:46
https://tracker.ardour.org/file_download.php?file_id=4143&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8829 [ardour] bugs minor always 2021-11-30 20:08 2021-11-30 20:08
Reporter: rohanlean Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Drop down menus cover other windows and do not stick to their workspace
Description: Using Mutter 41.1 (Wayland);

Drop down menus cover other windows that are stacked over the Ardour window. They also do not stick to their original workspace and instead move to the active one, at which point they are impossible to get rid of other than by switching back to Ardour's workspace.

For reference, GTK and QT drop down menus disappear when their parent windows loses focus.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8584 [ardour] bugs minor have not tried 2021-02-25 16:51 2021-11-26 06:58
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when activating tracks
Description: Ardour 6.6 crashed when I activated a bunch of disabled tracks.
Here's the backtrace:

Thread 133 "autoconnect" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffe99a67640 (LWP 502483)]
0x00007fffee7fd75f in __cxxabiv1::__dynamic_cast (src_ptr=0x3f0000003f000000, src_type=0x555556659a38 <typeinfo for ARDOUR::Processor>, dst_type=0x7ffff7af65a8 <typeinfo for ARDOUR::LatentSend>, src2dst=-2)
    at /build/gcc/src/gcc/libstdc++-v3/libsupc++/dyncast.cc:50
50 /build/gcc/src/gcc/libstdc++-v3/libsupc++/dyncast.cc: No such file or directory.
(gdb)
(gdb) bt thread apply all
A syntax error in expression, near `apply all'.
(gdb) bt
#0 0x00007fffee7fd75f in __cxxabiv1::__dynamic_cast (src_ptr=0x3f0000003f000000, src_type=0x555556659a38 <typeinfo for ARDOUR::Processor>, dst_type=0x7ffff7af65a8 <typeinfo for ARDOUR::LatentSend>, src2dst=-2)
    at /build/gcc/src/gcc/libstdc++-v3/libsupc++/dyncast.cc:50
0000001 0x00007ffff74d50ec in ARDOUR::Route::update_signal_latency(bool, bool*) () from /opt/Ardour-6.6.0/lib/libardour.so.3
#2 0x00007ffff751a457 in ARDOUR::Session::update_route_latency(bool, bool, bool*) () from /opt/Ardour-6.6.0/lib/libardour.so.3
#3 0x00007ffff751a6f6 in ARDOUR::Session::update_latency_compensation(bool, bool) () from /opt/Ardour-6.6.0/lib/libardour.so.3
0000004 0x00007ffff751aa3c in ARDOUR::Session::auto_connect_thread_run() () from /opt/Ardour-6.6.0/lib/libardour.so.3
0000005 0x00007ffff751ad98 in ARDOUR::Session::auto_connect_thread(void*) () from /opt/Ardour-6.6.0/lib/libardour.so.3
#6 0x00007ffff08f9299 in start_thread () from /usr/lib/libpthread.so.0
#7 0x00007fffee501153 in clone () from /usr/lib/libc.so.6
Tags: crash
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025560)
x42   
2021-02-26 11:59   
Does this also happen if you open the session in safe-mode, without plugins?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8825 [ardour] other minor have not tried 2021-11-22 02:42 2021-11-22 17:47
Reporter: EnderKing101rs Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: windows detected as virus
Description: when I tried to get the demo install going windows defender detected ardour as a virus which I found ironic as I just read that it didn't get flagged. I'm not mad, found it kinda funny actually.
Tags: install, Windows
Steps To Reproduce: try to install the 64x windows demo
Additional Information:
System Description
Attached Files: Screenshot_219.png (28,813 bytes) 2021-11-22 02:42
https://tracker.ardour.org/file_download.php?file_id=4138&type=bug
png
Notes
(0026223)
x42   
2021-11-22 17:47   
"unknown publisher" is expected. The application is not digitally signed by Microsoft. because we (ardour.org) do not pay Microsoft or any other entity for a windows certificate to sign the installer.

Similar issue exists on macOS. We also do not pay the Apple tax.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8826 [ardour] features minor always 2021-11-22 17:07 2021-11-22 17:07
Reporter: PavelAtr Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unable to select the opensles driver in the jack launch settings.
Description: Unable to select the opensles driver in the jack launch settings.

An OpenSLES backend for jackd actually exists and can be used. Now you have to run jackd separately, but I would like to be able to run it using ardor.

Thanks.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7522 [ardour] bugs minor always 2017-12-10 04:23 2021-11-22 01:40
Reporter: ragnarok Platform: 64 Bits  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: 9.x (stretch)  
Status: new Product Version: 5.X git (version in description)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Video glitches on zoomed automation track
Description: I expand size and zoom the automation view from a audio track, i have video glitched when scroll it.

It's do not occur on audio track itself just only on the autimation part.

I upload a video capture that reproduce the issue:

https://www.youtube.com/watch?v=j4HG48d8EBY&feature=youtu.be

Please tell me if you need more info.
Thanks!


Tags:
Steps To Reproduce: resize to grow atomation from audio track. put some points, zoom and scrool it
Additional Information:
System Description
Attached Files:
Notes
(0020287)
agittins   
2018-06-04 10:51   
I'm having a similar issue. For me it only seems to happen in some projects, but when it does I can usually trigger it just by moving nodes. I've not yet been able to replicate it on demand, it seems to be just in certain projects.

I'm on Debian 9.3 using Ardour 5.12.0 built from kxstudio, with amdgpu graphics running kde.
(0020290)
ragnarok   
2018-06-05 01:25   
(Last edited: 2018-06-05 01:25)
Good to know. I also use debian 9.x on Laptop with onboard Intel Ivybridge video card. I can provide my project if can help to debug

(0020302)
lilith   
2018-06-19 11:00   
(Last edited: 2018-06-19 11:01)
I also have these glitches. Ardour 5.12 from the Ardour website with Debian Stretch XFCE and onboard graphic.
My board is a MSI H81M-E34.

(0026221)
ragnarok   
2021-11-22 01:40   
I cannot reproduce on receent version (6.9.0) so i think that this bug was fixed

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8822 [ardour] bugs minor always 2021-11-18 21:49 2021-11-18 21:49
Reporter: ivnamei Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Export distortion
Description: I have a minute voice recorded. It plays fine on Ardour, but every time I export the voice is badly distorted and becomes a much lower voice. It happens with every configuration possible, WAV, FLAC, MP3, Real time or not. When hearing it on Ardour`s windows after the export it sound fine, outside of it it`s distorted on every player and device. Please help!
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8784 [ardour] bugs minor always 2021-08-02 14:09 2021-11-14 10:00
Reporter: Werner Back Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: LUA: Store Mixer Settings has pan wrong
Description: I used the "Store Mixer Settings" Lua script to save a "scene", but when I restore from that file the pans are set wrong. I checked the saved values and it looks as if the way the numbers are stored is wrong. It looks like the following:

...,pan_control=0,5,...
 but should look like
...,pan_control=0.5,0.5,...
(this example is for "center position").

If I correct this manually in the file the pans look alright.
Tags:
Steps To Reproduce: Store + recall mixer settings with LUA script.
Additional Information:
System Description
Attached Files: a_db2b41821.lua (10,885 bytes) 2021-08-05 06:21
https://tracker.ardour.org/file_download.php?file_id=4096&type=bug
mixer_settings_store.lua (10,781 bytes) 2021-11-14 10:00
https://tracker.ardour.org/file_download.php?file_id=4131&type=bug
mixer_settings_recall.lua (14,745 bytes) 2021-11-14 10:00
https://tracker.ardour.org/file_download.php?file_id=4132&type=bug
Simple-fb-duplicated.ardour (150,051 bytes) 2021-11-14 10:00
https://tracker.ardour.org/file_download.php?file_id=4133&type=bug
Simple-fb-triplicated.ardour (151,597 bytes) 2021-11-14 10:00
https://tracker.ardour.org/file_download.php?file_id=4134&type=bug
Simple.ardour (148,509 bytes) 2021-11-14 10:00
https://tracker.ardour.org/file_download.php?file_id=4135&type=bug
Notes
(0026087)
Werner Back   
2021-08-03 10:53   
Oh, just saw that it's a locale problem. LUA replaces the "." with "," in german environments.

Something like that should work:
            if pan ~= false then
                local strPan = tostring(pan)
                pan = strPan:gsub(",", ".")
            end
(0026089)
Werner Back   
2021-08-04 11:26   
Ah, I played a little with LUA (without understanding everything ;)) and it seems that this works:

Replace the following line:
if pan:isnil() then pan = false else pan = pan:get_value() end --sometimes a route doesn't have pan, like the master.

with
if pan:isnil() then pan = false else pan = ARDOUR.LuaAPI.ascii_dtostr(pan:get_value()) end --sometimes a route doesn't have pan, like the master.

Probably there are some more parameters where this problem occurs? I couldn't find out what "send_string" does? Guess that's Mixbus only, right? Since the LUA script's author is "Mixbus Team", is it possible, that this bug doesn't appear in Mixbus?
(0026090)
Werner Back   
2021-08-05 06:21   
This works for me now.
(0026216)
Werner Back   
2021-11-14 10:00   
Further Problems: Storing fails if project name contains blanks. Fixed this.

Still not fixed and beyond my skills: if the Project contains a foldback, recalling a stored setting duplicates all foldback strips again and again. This leads to unusable projects because DSP load increases every time you load.

See the simple attached project files (diff them and you'll see). These were made in mixbus, but in ardour it's the same.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8821 [ardour] bugs minor always 2021-11-09 15:44 2021-11-09 16:07
Reporter: unfa Platform: AMD64, Ryzen 9 (Zen2)  
Assigned To: OS: Ach Linux (formerly Manjaro)  
Priority: normal OS Version: KDE  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Xjadeo is not in sync with Ardour when using Int. sync
Description: On the attached screenshot you can see that Xjadeo is 9 frames behind Ardour.
Ardour is using Internal Sync.

When switching to JACK transport external sync, the video plays fine.
I am using JACK2-dbus as backend.

Also: I have had to manually change the session framerate to 60 FPS (from 30) to have the video at least play at the same speed as the audio plays in Ardour (though there's the 9 or so frames lag).

The video Import dialogue does not automatically set the project framerate, and the option to do so is gone in Ardour 6.9 (I believe it was there in some previous versions.).

Even if the session is set to 30 FPS, the video plays fine when using JACK sync.
I tested that using JACK and PipeWire-JACK-dropin.

So teh out-of-the-box experience when importing a 60FPS vidoe file into Ardour is:
- video plays too slow and needs the project to have changed framerate
- after that it stil lags and needs the sync to be changed to JACK
- it still has bad black frames so the user needs to transcode the vidoe to a different format

And then it works as expected.
Tags: sync, timecode, transport, video, xjadeo
Steps To Reproduce:
Additional Information: All of thse iissues did not exist in older versions of Ardour, as you can see in this video:
https://youtu.be/QGI1QsFcNzU?t=805
(attached screenshot)

I was not using a custom video encoding, did not have to change my session framerate or change to a different sync than Internal and it just worksed in that video (it was recorded more than 8 months ago though).
System Description
Attached Files: Screenshot_20211109_164235.png (434,347 bytes) 2021-11-09 15:44
https://tracker.ardour.org/file_download.php?file_id=4130&type=bug
Notes
(0026213)
x42   
2021-11-09 16:07   
Try without pipwire -- latency compensation and playback alignment is still broken there.

Ideally with Ardour/ALSA (no JACK).
Also Ardour only supports SMPTE framerates. for 60 fps files make sure you have enabled Session > Properties >"Use Video File's FPS Instead of Timecode Value for Timeline and Video Monitor."

PS. Nothing has changed there on our side in the last 8 months. -- really video-timeline has not changed in 4+ years. If this worked in the past it is very likely an issue with your setup.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8820 [ardour] other minor have not tried 2021-11-09 15:39 2021-11-09 15:39
Reporter: unfa Platform: AMD64, Ryzen 9 (Zen2)  
Assigned To: OS: Ach Linux (formerly Manjaro)  
Priority: normal OS Version: KDE  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: AVI/MJPEG produced a lot of dropped frames, ProRes/MOV does not
Description: I've been having issues with video playback via Xjadeo when usign video reference ith Ardour.
In the past it worked ok, but not now.

When using default Ardour MJPEG transcoding, Xjadeo produces a huge amout of dropped frames, resulting on terrible image flicker.

I've tested a different codec and it worked flawlesly (also provided much better visual quality):

My input is a 1080p60 MKV file. I've transcoded it with:

     ffmpeg -i reference.mkv -s 854x480 -pix_fmt yuv420p -c:v prores reference.mov

I do what I can to avoid non-free codecs, but in this case the MJPEG encoding seems to work poorly. I don't know why, as it used to work great.

Please consider testing this and changing the default transcoding settings to make sure other users don't have this same issue.
Tags: video, xjadeo
Steps To Reproduce:
Additional Information: Here's a video demonstration of the issue:

https://youtu.be/KkZ3pzkl_H4
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7221 [ardour] features minor N/A 2017-01-29 11:02 2021-11-07 21:16
Reporter: Lost_Highway Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Editor window track colours
Description: In the Editor window, it would be helpful if each track's colour were displayed somewhere in the track title box at the left hand side.

The reason for suggesting this is that, whilst it's really useful having the regions coloured and the bars in the summary, if you're looking at a section of the timeline where there is no recorded audio you cannot see what colour is selected for the track (and colour-coding tracks is a very useful navigational aid in large sessions).

As there is colour coding of the track title box to differentiatef audio and midi tracks and as track height can vary, perhaps the area around the track name box could be filled with the track colour as this would always be visible, leaving the area around the fader (when visible) and the rec/mute/solo/etc buttons to indicate track type. I guess the background to the actual text would be best left as is so that the text is always legible if really light or dark track colours are selected.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8819 [ardour] bugs minor always 2021-11-04 21:41 2021-11-04 21:41
Reporter: AliMacD Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stretch Mode: various issues
Description: Stretch Mode: relation between stretched result on timeline and source list
auto-naming, (re-naming), re-appearing with different names after re-opening session,
stereo splitting to mono
(and Duration window still doesn't mirror primary clock if it's not bars/beats)
Tags:
Steps To Reproduce: open a new session
create a new stereo audio track
import stereo sound e.g. ‘piano’
drag sound onto track
stretch sound: the name is automatically generated e.g. ‘piano.1@120
bug 1: this *sometimes/usually appears in Source list, but not always*
but assuming Source list has 'piano' and 'piano.1@120' listed for now...

look in Interchange….audiofiles:
in addition to the imported piano%L.wav and %R.wav I now see
piano%L%L.wav and piano%R%R.wav - these appear to be the source files for ‘piano.1@120

save and close session
re-open session

bug 2: Source list now has original ‘piano’ and two mono files: piano%L%L.wav and piano%R%R.wav
and
bug 3: my stereo piano.1@120 is no longer listed in Sources

If I left 'piano.1@120' on the timeline it remains there, and is listed in the Regions list but if I deleted it from the timeline it is gone and
I can’t drag the 2 mono halves of piano%L%L.wav and piano%R%R.wav into a stereo track (is this me or a missing feature?)

drag ‘piano’ in again, repeat
piano_stuff%L-2%L & R
piano_stuff%L-3%L & R etc.
again a mixture of piano.n@nnn sometimes appearing in the source list, sometimes not, but never after re-opening the session, only mono pairs

Also I would dearly like to (re-)name the files myself, not just accept the source+stretch amount even if that were to work
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8815 [ardour] bugs minor always 2021-10-26 17:18 2021-10-26 17:18
Reporter: timkrause Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ACE Inline Spectrogram display becomes choppy after running for a day.
Description: ACE Inline Spectrogram display becomes choppy after running for a day.
Tags: ACEplugins, display
Steps To Reproduce: 1) Open Ardour with a fresh session
2) Add an audio track
3) Add the ACE Inline Spectrogram
4) Route a constant source of sound to the track
5) Let run for a day
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8665 [ardour] bugs minor random 2021-04-16 22:12 2021-10-22 01:23
Reporter: ericfontaine Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: when stop recording, ardour sometimes puts undesired empty region ontop of recorded region
Description: I’m sporadically encountering issue where the last region I recorded shows the waveform fine as it is recording, but then when I press stop, an empty region is placed on top of the recorded region. I don’t hear my recorded region when I playback and it appears as though nothing recording because a blank region is placed ontop of my recorded audio. However the audio did record, and can be found by clicking on the empty region and pressing delete.

See https://discourse.ardour.org/t/ardour-git-sometimes-returns-empty-region-after-stop-recording/105791
Tags:
Steps To Reproduce: Not easily reproducible, and I haven't determined the exact conditions which this happens on my computer, but it seems the more audio regions I record, the more likely I am to encounter this issue.
Additional Information:
System Description
Attached Files: Image1.png (112,313 bytes) 2021-06-22 19:07
https://tracker.ardour.org/file_download.php?file_id=4068&type=bug
png

Image2.png (62,449 bytes) 2021-06-22 19:07
https://tracker.ardour.org/file_download.php?file_id=4069&type=bug
png

Issue.ardour (100,592 bytes) 2021-06-22 19:07
https://tracker.ardour.org/file_download.php?file_id=4070&type=bug
bug-happened.tar.gz (26,391 bytes) 2021-10-22 01:23
https://tracker.ardour.org/file_download.php?file_id=4120&type=bug
Notes
(0025713)
x42   
2021-04-16 22:17   
Just to clarify: there is a correct region with expected audio underneath, and simply deleting the empty region fixes things?
(0025714)
ericfontaine   
2021-04-17 00:03   
yes, there is a correct region underneath the blank region, and simply deleting the empty region fixes things.
(0025991)
jumase   
2021-06-22 19:07   
Hi, I found something similar to this but couldn't reproduce it.

I started up a new project and started recording with Transport -> Follow Playhead and Stationary Playhead activated. These were the only different things I set, so I thought that could be the cause of this issue, but I couldn't reproduce it again by activating those preferences. I mention this here because I got this problem on the first recording. I "fixed" it by editing the region end (I tried to make it larger; of course that would be imposible, but when I released mouse, the waveform was there).

Recently I noticed that region name finishes in .2, indicating it is a "second edit region", but I think I hadn't done any edits when I did the screenshot. What I mean is that maybe the region with the waveform was under the .2 region.

Another difference from what ericfontaine reported is that I actually could hear the recorded audio, though no waveform was shown.

Lastly, I tried to drag and drop region Gtr-1.2 from the Region List but it didn't work. It creates another region, but shows nothing in the track, not even an empty region.

I attach two images. The second one has the track unarmed to show metrics. I also upload the session file as it may help (it has another track and a few edits and automation added).

Version used: 6.7.0 from ardour.org
(0026194)
ericfontaine   
2021-10-22 01:23   
I just experienced this issue again. On a 3-day fresh install of KDE neon user edition (which is based on Ubuntu 20.04-lts and KDE plasma 23.0) using the linux install binary from the Ardour website. My session has 3 tracks: "alto-flute", "06 Conv...Melody", "conveyer...larinet.2". I was recording my first take on alto-flute for the project duration (1 min 20 sec). After recording completed, I see there is a region "Take1_alto-flute-1.2" with no audio which is covering up what I actually recorded (region name "Take1_alto-flute-1.1").

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8813 [ardour] features minor always 2021-10-21 08:37 2021-10-21 08:41
Reporter: gunterkoenigsmann Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: A default template
Description: I make nature recordings => the template I normally use doesn't occupy screen space with tempo and beats.
A low-hanging fruit would be to tell ardour to on creating a new session load the template namend "Default" if I haven't selected a different template to use.
Tags: feature request, start
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8794 [ardour] bugs minor always 2021-09-10 00:57 2021-10-17 17:21
Reporter: domingo Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Hangs when Audio Interface USB is disconnected
Description: This problems bothers me since many versions and finally decided to report it, supposing this is a general problem that can be revised in the future.

Ardour hangs if the audio interface is turned off or unplugged when active.

Interface: Combo Amanero 384 (DAC) under OSX 10.13, using generic drivers.

I wish Ardour would be more agile automatically deactivating and reactivating usb interfaces when they are switched off and on.

Similar problem: When unplugging and replugging a USB sound recorder (Zoom H1), it is not detected automatically by the session in use, the device rather appears duplicated in the list of the Audio/MIDI engine and sometimes not even responding to any both.
Tags:
Steps To Reproduce:
Disconnect and reconnect an active USB interface.
Additional Information:
System Description
Attached Files:
Notes
(0026192)
al f   
2021-10-17 17:21   
Ardour freezes on USB disconnection on my system as well. (K)Ubuntu Studio 20.04, Ardour 6.9. Focusrite Scarlett 2i4.

It seems that sometimes disconections triggers the error message "Session: cannot have two events of type TransportStateChange at the same sample", but I haven' been able to reliably reproduce that.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8787 [ardour] bugs minor always 2021-08-16 16:25 2021-10-12 12:24
Reporter: ardourwlk Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on dragging region to create new track
Description: After several successful iterations of recording 2 regions, then dragging them to create 2 new tracks, I hit a wall where I drag the region down to create the new track, and Ardour exits. On restarting, it does not suggest there was a problem, and I can reproduce this, apparently, ad infinitim with this session... drag, wreck, restart, drag, wreck.
Tags:
Steps To Reproduce: I have a session I am layering some guitars, so I am recording a clean track and a processed track (through guitarix, not plugin) each time. So, recording two tracks at a time (only about 10 seconds), then stop, drag each of those new regions down to create a new track for each, and repeat. I've done 4 iterations so far, and now on the 5th time on dragging the second of the two new regions to create a new track, Ardour exits, and on restarting, it does not suggest that it wrecked, and I can reproduce at will (within this session).
Additional Information: I have not tried with a new session. This is the AMD 64-bit binaries downloaded from the main site.

I don't believe this helps, but from the apport.log (the first incident):
ERROR: apport (pid 6998) Mon Aug 16 12:02:06 2021: called for pid 6791, signal 11, core limit 0, dump mode 1
ERROR: apport (pid 6998) Mon Aug 16 12:02:06 2021: executable: /opt/Ardour-6.9.0/bin/ardour-6.9.0 (command line "/opt/Ardour-6.9.0/bin/ardour-6.9.0 -N /home/aaron1/ArdourSessions/20210816.1144 -T BetterQuickGuitarWithGuitarix")
ERROR: apport (pid 6998) Mon Aug 16 12:02:06 2021: gdbus call error: Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

ERROR: apport (pid 6998) Mon Aug 16 12:02:06 2021: debug: session gdbus call:
ERROR: apport (pid 6998) Mon Aug 16 12:02:25 2021: wrote report /var/crash/_opt_Ardour-6.9.0_bin_ardour-6.9.0.1000.crash
System Description
Attached Files: ard_ouch.txt (31,442 bytes) 2021-08-16 16:34
https://tracker.ardour.org/file_download.php?file_id=4098&type=bug
ardfail_20210817_0934.png (16,421 bytes) 2021-08-17 13:41
https://tracker.ardour.org/file_download.php?file_id=4099&type=bug
png
Notes
(0026106)
ardourwlk   
2021-08-16 16:34   
attached gdb output in ard_ouch.txt file
(0026107)
ardourwlk   
2021-08-16 16:39   
Using Ubuntu Studio 20.04.2 LTS up-to-date on maintenance
(0026108)
ardourwlk   
2021-08-16 22:53   
Recycled jack (and ardour), and was able to successfully create the new track.
(0026110)
ardourwlk   
2021-08-17 13:41   
After having apparently successfully saving the session yesterday, today I tried to open the session and got the message in the screenshot (ardfail_20210817_0934.png), and am unable to open the session.

Then I closed Guitarix, and now the session successfully opens. Some kind of port conflicts within Jack? I've never run into this before.
(0026111)
ardourwlk   
2021-08-17 13:45   
And now, leaving Ardour up, I am no longer able to start Guitarix. And... I stop Ardour, and Guitarix is able to start. Interesting.
(0026114)
ardourwlk   
2021-08-18 16:50   
I boosted the number of ports in jack up to 1024, and am able to work again. Perhaps a tooltip help when giving that "failed constructor" message?
(0026187)
x42   
2021-10-12 12:24   
Glad you figured out the solution.

As for your suggestion: Ardour cannot know why registering a port fails with the server. In case of JACK, jackd reports the error and "port limit reached" is only one possibility.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8462 [ardour] bugs minor always 2020-10-29 00:40 2021-10-12 05:47
Reporter: chance_favre Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Transport Controls Are Broken when using ASIO::ZOOM R16_R24 ASIO Driver
Description: Ardour 6.3
Jack:
Version: 0.3.13.10
Build: Sep 21 2015 20:12:10

ONLY happens when using the ASIO::ZOOM R16_R24 ASIO Driver in Jack. That driver can be found here:
https://zoomcorp.com/en/jp/digital-mixer-multi-track-recorders/multi-track-recorders/r16/r16-support/
Tags: transport
Steps To Reproduce: 1. boot windows
2. connect ZOOM R16 via USB, configure R16 as audio interface (click the enter button 3 times)
3. Launch qjackctl (Qt GUI for Jack), click Setup >> Interface, then select ASIO::ZOOM R16_R24 ASIO Driver
4. Start Jack server
5. Launch Ardour 6.3, make a new recording session
6. Begin recording some audio
7. Try normal transport operations with the mouse, stop, start, record enable.
8. Try to use the spacebar and hotkeys.
9. There seems to be some kind of click/key capture logic indexing issue or something because (although I have not yet found a pattern to the malfunctioning) it SEEMS like it is triggering the wrong events or something.
10. Same problems exist in playback mode (not recording)
Additional Information: I am using a lenovo laptop, and my clicking device is the touchpad, so I also tried a USB mouse -- same problem.

It seems like after the first time you click in the "track window" where the audio waveforms are, then the controls work for one or two events, but after that the space bar no longer toggles playback, and then you click on the gui controls, and maybe that works or the second time it does.

If I use the ASIO::ASIO4ALL v2 driver, the transport functions more predictably.

This one is a doozy.
System Description
Attached Files: transport.PNG (51,698 bytes) 2020-10-29 00:40
https://tracker.ardour.org/file_download.php?file_id=3861&type=bug
png
Notes
(0025201)
chance_favre   
2020-11-05 14:30   
I am happy to help troubleshoot this bug. With a little guidance I'm sure I can get a dev environment up and running so I can test things.
Please let me know what I can do to help! Thanks!
(0025330)
chance_favre   
2020-12-19 21:18   
Bump -- I would love to help in resolving this bug. If anyone has any ideas how I can get started, please let me know.
(0025347)
painltd   
2020-12-23 11:29   
I have similar problems (on Ardour 6.5.0 Intel 64-bit), I click play and then stop and sometimes it continues playing. Space bar does not help but sometimes clicking again it does.

Additionally, I am able to record audio but can't hear it during playback. If I listen to the file in Windows' file explorer it has been properly recorded but can't hear during Ardour playback. Routing is correct as I have the exact same routing settings in my Linux machine and it's working perfectly fine. Do you have this issue @chance_favre ?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8809 [ardour] bugs minor always 2021-10-06 19:21 2021-10-08 19:45
Reporter: eastone Platform: PowerMac G5/G4  
Assigned To: OS: OSX  
Priority: normal OS Version: 10.5.8  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crashes when adding new midi track witht General MIDI synth instrument
Description: Ardour crashes on PowerMacs G5 and G4 when adding a new track only with General MIDI synth instruments.
Crash log attatched.
Tags: ppc
Steps To Reproduce: Steps to reproduce:
1) Open Ardour
2) F.e. double click to add a new midi track, choose General MIDI synth instrument (only this instrument!) The rest of instruments seems to be ok.
3) And pointer changing to beach ball and app crashes.
Additional Information:
Attached Files: Ardour6_2021-10-06-215905_g5s-power-mac-g5.crash (54,284 bytes) 2021-10-06 19:23
https://tracker.ardour.org/file_download.php?file_id=4116&type=bug
Ardour6_2021-10-08-165528_g5s-power-mac-g5.crash (57,682 bytes) 2021-10-08 14:43
https://tracker.ardour.org/file_download.php?file_id=4117&type=bug
Notes
(0026178)
x42   
2021-10-08 11:32   
The problem here seems to be the plugin. does it work when creating a track without synth?
(0026179)
eastone   
2021-10-08 14:43   
No problems with empty track.
BTW, recently, I think I missed a second problematic plugin, SinGen. It crashes in the same way, but at least I can use it by swapping another working plugin in the project (this method does not work for General MIDI plugin)

SinGen crashlog attatched.
(0026180)
x42   
2021-10-08 17:41   
The problem is that 6.9 was the last version with PPC support.
So those reports are a bit too late (https://discourse.ardour.org/t/request-for-help-testing-before-6-7-release/105912 ).

We've meanwhile moved on "modern" C++11 (also 10 years old now), but that requires at last macOS 10.9.
(0026181)
eastone   
2021-10-08 19:45   
I understand.
On my G5 with Debian Bookworm 64bit those problems not occur :)
Btw, thx for you effort.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2627 [ardour] features feature have not tried 2009-04-09 08:53 2021-10-07 12:30
Reporter: tgoose Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 3.X  
Summary: Request: DDP Support
Description: With DDP support in Ardour I could avoid buying an expensive add-on to Pyramix or Sonic PMCD.

Support for DDP versions 1 AND 2 would be preferable, as well as the ability to create a checksum for the image file.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006023)
anrug   
2009-05-21 11:39   
May I ask a couple of questions about that:

* Why do you want DDP 1.00? I would assume, that it's perfectly fine to offer DDP 2.00 export only, being the up-to-date and most complete format. Or have you heard of any manufacturer which only accepts 1.00/1.01?

* The checksum is not part of the DDP format. Can you specify, how you would want the checksum to be added? (Sorry, I have no access to Pyramix and the Sonic products at the moment.)

* Most people nowadays deliver DDP on DVD-R or via FTP. I assume you don't expect export to tape any more?

* How important is it, to be able to listen to the DDP master (Pyramix, the new Sonic products, and Sequoia achive this by importing DDP masters)?

* How important is it, to be able to burn a reference CD straight from the DDP master (none of the above programs offer that, but GearWorks does it iirc).
(0006024)
tgoose   
2009-05-21 14:38   
* DDP 1.00 or 1.01 would be purely "just in case." I don't remember ever having a problem with supplying DDP 2.0 so for my uses I'd probably be fine with just that.

* I'm also without access to any software currently, I'm afraid. If anybody else has access to any of: Pyramix, SADiE or Sequoia then that would be handy—they're the only three I'm aware of that offer checksums (maybe SoundBlade does too but I don't know). I can't remember what form the checksum takes but it's added as an extra file to the DDP folder and I believe it protects only the image.

* Once, about a year ago, a company I worked for was asked to deliver one DDP on Exabyte. So I think that's an option I could do without!

* For the last two points, I would certainly like to be able to do at least one of those two. The latter is preferable since it kills two birds with one stone if I can create a ref and verify the master simultaneously but loadback into Ardour itself would be almost as good. I seem to remember that Pyramix does offer burning direct from DDP via the DiscWrite software (when the DDP option is added, that is).
(0006070)
anrug   
2009-06-10 02:14   
OK, tgoose, DDP export will not make it into 2.x, there basically is a feature freeze. I've prepared an experimental patch for 2.8 that adds DDP export to the normal export dialog, it's not elegant, because it relies on the user specifying the correct format for the audio file, but it works (no CD text though, that's way more complicated to implement, than anything else regarding DDP). I will further test it and maybe upload it somewhere at some point.

In 3.0 there may very well be a dedicated CD export dialog, chances are not too bad that I can help with code for DDP export.

For burning CDs straight from DDP I would suggest creating a cue file along with the other DDP files, this will allow ref CD copies from exactly the same audio file, that's part of the DDP. For proof listening to DDP one could use a media player that supports cue sheets or I'd have to look into implementing a "DDP import" in Ardour - ideally without having to copy the audio (which has always bothered my with Pyramix and Sequoia).
(0009034)
rooker   
2010-09-12 21:20   
Are there any legal problems with DDP-code licensed under GPL?
(0009191)
anrug   
2010-09-29 12:00   
(Last edited: 2010-09-29 12:01)
I whish I could answer that question. The license terms can be found at http://www.dcainc.com/support/documentation/docs/DDPLA1x2x.pdf

It doesn't sound especially restrictive, but I think DCA Inc. expects their specification to only be used in "products", under which they seem to invision closed source compiled software.

I have had email contact with DCA, asking if it is OK to release an open source library for creating DDPs of Audio CDs--I have code in C and Python, that I certainly wouldn't mind sharing). They were concerned about the code being used by their competitors--which would be companies offering glass mastering software for CD/DVD duplication plants--and about the code not adhering to the spec, they wanted the right to "approve" the code. Clearly they had not much of a clue about open source in general. And strangely enough, I think that those concerns are not ensured by their license terms.

So for me this is a somewhat weired situation and I have not released any code yet. But maybe one would be able to convince them.

Another question is of course if one needs their permission at all. I'm not familiar with the US laws, but for people who haven't signed the agreement and have done clean room reverse engineering on the DDP format it might probably be OK to release code under the GPL. Note that in the two projects I know of which have DDP spec related code (dvd2tape and XLD) the source code shows that the authors had probably access to the spec.

(0020215)
sapista   
2018-03-23 16:12   
Hi, this is such an old feature request but I think DDP export/import is still a very valuable feature. I see there are license related issues in order to bring DDP to Ardour. But since DDP is kind of the standard interchange format for CD production, I think it will be very useful for mastering in Ardour.

Do you thing there is any chance to get the DDP export feature in GPL software?
(0026177)
x42   
2021-10-07 12:29   
(Last edited: 2021-10-07 12:30)
Unlikely, that it is possible. There are tools available for GNU/Linux from http://ddp.andreasruge.de/ they are gratis, but not free.

For a GPL implementation someone would have to clean room reverse engineer the format and then there may still be patents.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8808 [ardour] features minor always 2021-10-06 09:28 2021-10-06 09:28
Reporter: sonnie Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Replace Mixer Button Text with SVG Images
Description: Is it possible, to get an option to replace the button text with small icons / pictures?

I made some massivly skilled thumbnails to get the idea.

Pic 1:
Input Monitoring
Output 1
Output 2

Pic 2:
Automation
Playlists
Groups

Pic 3:
Lock
Tags: feature request
Steps To Reproduce:
Additional Information:
Attached Files: signal-2021-10-06-112235.png (155,447 bytes) 2021-10-06 09:28
https://tracker.ardour.org/file_download.php?file_id=4113&type=bug
png

signal-2021-10-06-112413.png (108,744 bytes) 2021-10-06 09:28
https://tracker.ardour.org/file_download.php?file_id=4114&type=bug
png

signal-2021-10-06-112527.png (41,853 bytes) 2021-10-06 09:28
https://tracker.ardour.org/file_download.php?file_id=4115&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8342 [ardour] other minor always 2020-07-29 17:05 2021-09-29 21:15
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Optimize Ardour's defaults for MIDI editing
Description: There's two things I *always* have to change in a fresh Ardour installation before I can do any work with MIDI:

1. Preferences > "Sound MIDI notes as thy are being selected in the editor"
2. Session > Properties > "MIDI copies are independent"

Please - make these things enabled by default in a new Ardour installation. I don't see a reason to have them off.

1. Editing any MIDI when you can't hear what the notes you touch are is like doing graphic design with your monitor off. Ain't gonna work :D

2. Having all MIDI copies linked by default is in my opinion a trap for new users who make a beat, copy it a few times and then change one of the copies to make a drum fill, and they find that their beat is now all drum fills. The MIDI region linking seems like a nice feature on paper, but in practice it's always getting in my way, rather than help me with anything. I think that if it'd get some proper visual indication (a chainlink icon on linked MIDI region copies, highlighting linked copies when you select one of them etc.) and tools to quickly link/unlink selected regions - it could become very useful, but in the current state it's just a trap for someone who doesn't know there's a feature like that.

I'm proposing these changes as I'm writing a MIDI tutorial for Ardour and these are the two things I'm gonna tell everyone to change right away, I thought we could optimize a new user experience a bit by changing the defaults.

What do you think?
Tags: Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20200730_122100.png (70,534 bytes) 2020-07-30 10:25
https://tracker.ardour.org/file_download.php?file_id=3792&type=bug
png

2021-09-17-184800_399x240_scrot.png (5,093 bytes) 2021-09-17 16:48
https://tracker.ardour.org/file_download.php?file_id=4103&type=bug
png
Notes
(0024853)
mhartzel   
2020-07-29 19:30   
Just my 5 cents.

No 1. This can get annoying in some situations. You can assign this to a keyboard shortcut and turn it on and off when needed. Window / Keyboard Shortcuts / Editor / Sound Selected Midi Notes.

No 2: I've been bitten by this a couple of times. Imho it would be better if regions were individual by default and you got to choose when copying regions if they are individual or not. You may want most of drum patterns to be instances of the same copy but not necessarily regions for other midi instruments. However I have learned to live with the current default, although I sometimes forget and find out later my edit was done on many regions and I need to redo the thing.
(0024854)
x42   
2020-07-30 06:06   
I have no strong opinion about (1). Except when you select a lot of notes simultaneously this can lead to a loud, speaker-blasting noise. and should that happen our current excuse is that "you asked for it".

As for (2). Once regions are independent, they will irreversibly remain so. So this is a sane default.
Users who record live MIDI, don't usually copy regions, and users who make pattern based music or use drum-patterns do want copied to be linked (and only un-link on individual basis). It's not a feature on paper as you suggest, but essential for pattern based music. So this seems a sane default. There is already feature request to indicate linked copies in the tracker, but it's not trivial to implement.
(0024855)
unfa   
2020-07-30 07:52   
1. Maybe the amount of notes played at once could be limited with a preference and a low default setting could be used to prevent the earrape? I guess 6 notes at once should usually suffice even for complex chords.

2. My music is pretty much all pattern-based, but after trying to use linked duplicates as being on by default I've had to disable them due to lack of control and visual feedback.

I was unable to remember which regions are linked, and unlinking them requires a lot of menu-diving, unless the user sets a custom shortcut for himself.

So far I've encountered many new users asking about this, being confused, and so far no one I talked to seemed to be using this feature.

I've created a simple Mastodon poll to hopefully get some numbers:

https://mastodon.social/@unfa/104601674634813433
(0024856)
mhartzel   
2020-07-30 08:33   
Just for the record: linked regions is a nice useful feature. When I'm writing a song recording in Ardour I start with a simple drum pattern that is repeating all through the song. I use linked regions here. When I've finalized the structure of the song and recorded in guitars, bass and vocals I start to tweak the drums here and there adding fills and changing drum patterns in some parts of the song. This is where I need to use unlinked regions. If I now want to make a change to the original drum pattern across the song it's easy as the change gets copied into every linked region.

I can also see unfa's use case and agree that the default is not optimal now. I think the preference is in wrong place, since it's a session preference and you need to change it every time you create a new session. The setting should perhaps be global, since a user probably may prefer not to use linked regions ever. Or maybe the options needs to be remembered by Ardour, so the user would not need to change it every time after creating a session.
(0024857)
x42   
2020-07-30 08:39   
(Last edited: 2020-07-30 08:48)
> I've created a simple Mastodon poll to hopefully get some numbers:

Please don't. Ardour is not a democracy, nor design by committee.

Good arguments and constructive criticism are preferable, and those are, alas, usually only provided by a minority.

(0024858)
x42   
2020-07-30 08:45   
To be clear: Preferences are only used for session independent settings (studio setup, hardware, system specifics, etc). Monitoring is part of the preferences (do you have a control room, or not).

(2) is intentionally **NOT** a preference but a session-property. You may have one session where you extensively use linked regions patterns and another where you don't.
You can however save default session props that are used for new sessions.
(0024859)
mhartzel   
2020-07-30 08:51   
"You can however save default session props that are used for new sessions".

I can't believe I have not noticed the big "Use these settings as default" button on the bottom of the Session Properties window in all these years of using Ardour. The button blends to the background quite effectively, maybe it should be of different color from the background to pop up a little:) Thanks for pointing this out, there is a Session Setting I've been changing every time after creating a new session and now I don't have to :)
(0024860)
unfa   
2020-07-30 09:10   
> Please don't. Ardour is not a democracy, nor design by committee.
Well, so far the poll seems to be pretty uniform. I guess that doesn't matter though.

> Good arguments and constructive criticism are preferable
Here you go:

I think without visual feedback and usability improvements linked duplicates are mighty confusing and are bound to cause data loss when a user forgets a duplicate is linked somewhere and overwrites something in his project only to find out minutes later when it's far gone.

This happened to me a few times - so I've learned to *always disable this feature and save my defaults right away*. Always. And I suspect almost everyone who uses MIDI in Ardour goes through the same experience at some point. As improving the feature is not an easy task, I think it'd benefit the grand majority of users to have linked duplicates off by default.
The feature is simply half-baked right now.
(0024861)
x42   
2020-07-30 10:04   
Here's another idea: The first time setup dialog could offer a choice which defaults to use. The classical setup or some more unfa-like preferences.

Then again, I like your suggestion to tell users to actively disable these settings, when they want a workflow like you prefer. That raises awareness that linked regions exist and they have to acknowledge that be able to use linked pattern regions by actively opting out.
(0024862)
unfa   
2020-07-30 10:25   
x42: I think the first run wizard question could be a nice thing - it'd let users disable this easily if they know they don't want it, or (hopefully) put in their minds that there's something like this and when they experience problems, they may remember to seek some MIDI settings (however I think people mostly search for it in Preferences, not Session Properties - I know I wasn't able to find it at first).

Maybe an information where to find this setting to change it later would be a good idea.

I'll keep the warning about this in my tutorial - maybe I can also include a part about using the feature to help users decide if they want it on.
I don't want to force my workflow on people, though I'm obviously biased towards it.

I've got some feedback on YouTube (attached screenshot).
(0024874)
mhartzel   
2020-07-31 12:49   
I just want to add an idea to the conversation.

A user may want to make a global decision about linked and unlinked regions. But one may also want to duplicate both linked and unlinked regions in the same session.

Imho the global default is only one half of the discussion, region duplication is the other. One should be able to choose between duplicating linked or unliked regions also. Could it be possible to add the possibility to choose between these in the multi - duplicate window ? Imho a single region duplication could just follow the global setting.

Thoughts ?
(0024875)
unfa   
2020-07-31 13:07   
I think it'd be great to have an option to choose linked or non-linked duplicates individually, though I think without visual indication it's not going to be of much use.

More comments on YouTube under my post here:
https://www.youtube.com/post/Ugy4h5cADm9YscUmqER4AaABCQ?lc=UgwCOObliRU8LgIeWpN4AaABAg

The relevant ones so far:

> [ Iurie ] (Geonkick developer)
> 6 hours ago (edited)
> Linked for me creates only problem most of the time. It should be unlinked and an option to select and link if there is a need, copy as linked etc.

> [ DanVideo ]
> 1 day ago
> What is missing is a shortcut for copying clip linked/unlinked and a clear sign of what is linked and what is not.


> [ QuotePilgrim ]
> 22 hours ago (edited)
> You shouldn't be asking if people are using the feature, that's not going to answer your real question, which is if they think it should be enabled by default.
>
> The way you phrased your question, people who use the feature but don't think it should be enabled by default are forced to answer yes. If there are many such people, you'll come to the conclusion that the feature should be enabled by default, even though that wouldn't be the case.


> [ Tim Hawthorn ] (an Ardour beginner)
> 22 hours ago
> That threw me to start with and I'm still getting used to it. For the way I work I'd prefer it disabled by default.

> [ PastelComGini ]
> 20 hours ago
> It shouldn't be enabled by default.
(0024877)
adam   
2020-07-31 18:27   
How about a check box in the duplicate dialogue? "Linked copies? [ ]" Maybe add a little chain icon to linked regions and it lists the links when you hover over it?
(0026099)
Madmardigan   
2021-08-10 09:37   
When I'm writing a song recording in Ardour I start with a simple drum pattern that is repeating all through the song. I use linked regions here. When I've finalized the structure of the song and recorded in guitars, bass and vocals I start to tweak the drums here and there adding fills and changing drum patterns in some parts of the song. See here: https://www.google.com ? www.google.com
(0026115)
Daniele1971   
2021-08-18 21:41   
My regions are linked.. I'd say 70-80% of the time. Ardour should be able to create (un)linked regions. 2 shortcut Ctrl+d -> linked, ctrl+xx ->unlinked. There should be a marker on the linked regions, like a small anchor..
(0026141)
viktorsmari   
2021-09-17 16:48   
I agree with unfa's default recommendations.

I installed Ardour yesterday and I made a bass track with midi. Then I copied that track to a drum track and started editing the drums.
Moments later I found out I was editing both tracks at the same time, because the MIDI regions were linked.

As many have said here and on the forum, I believe that the default should be unlinked.

If you copy a region to a new track, you should be expecting a copy, not the same region.
(0026142)
viktorsmari   
2021-09-17 16:59   
Sorry I published my previous note too soon and did not figure out how to edit the note.
I added a screenshot from Bitwig, showing how the cursor indicates if you are making a looped region.

Might be useful instead of copy pasting a region on the same track, when the goal is to use a linked region.
(0026171)
xs   
2021-09-29 21:15   
I have no preferences for N.1. Personally I find it's fine as it is, even if I always enable it.

I got trapped for N.2. I didn't used linked copies for now.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8805 [ardour] bugs minor always 2021-09-29 16:26 2021-09-29 16:26
Reporter: medicineman25 Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 7.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mixbus AND Ardour steal Alsa and do not return on close
Description: This occurs on Arch Linux, the main outputs are used by Ardour/Mixbus and then not returned on close. Tested across hdmi and 3.5 audio.
Tags: alsa, alsa-resore, alsa-state, audio, main out
Steps To Reproduce: Open Ardour/Mixbus, select Alsa as sound backbone. Close and play audio without success.
Additional Information: If you are using the alsa-restore systemd unit file, restarting this service after close will restore audio to main outputs.

Have not tested with systems opting for the alsa-state systemd unit file.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8265 [ardour] bugs minor always 2020-06-24 09:35 2021-09-29 10:10
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: feedback Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Referenced audio files seem to be silently cached somewhere and not updated on file change
Description: When mastering music I always import my mixes without copying them, so that if I re-export them form my individual sessions, they'll automatically update in the master session.

However in Ardour 6 this workflow seems to be broken.

Importing a file without copying it seems to work initially, but subsequent changes to the source files are somehow ignored, as if Ardour cached the file somewhere and refused to reload it.

Even if I delete the original region, and re-import the new version Ardour sill somehow uses the old version of the file.
I don't know how is this possible, other than system RAM cache, because Ardour is not storing a copy in interchange, or external.

This issue means every time I correct the mix, I will not only have to re-export it, but also manually delete it from the master session, clear unused regions, restart Ardour and hope that when I import new version in it'll actually use it, instead of some cached old one.

I would like Ardour to reference the external (non-copied) files and maybe update the waveforms if it detects a change in the file (file modification date and MD5 sum verification?).

Working with referenced files is a very useful tool, and I'm really sad to see it not working right now in Ardour 6.
I had some issues with it in Ardour 5 before, but right now it doesn't seem to work at all.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024627)
alexmitchellmus   
2020-07-07 14:30   
I have noticed this issue as well. It is very important, especially if one is using modifying the audio files in another software.
(0024628)
paul   
2020-07-07 17:31   
" Even if I delete the original region, and re-import the new version Ardour sill somehow uses the old version of the file."

How are you determining this? Listening, or looking?
(0024629)
unfa   
2020-07-07 18:45   
By listening - I know that the waveforms are cached, so I would try to clear the waveform cache , but it doesn't update the source files.
I wonder if this could be caused by Linux disk read cache?
(0024632)
x42   
2020-07-08 00:35   
How are you embedding the file? Menu > Session > Import ? and disabling "Copy files to session"?
Can you check the .ardour session file that the session indeed references an external file with absolute path?

If you're using Drag/Drop. in Ardour6 you have to disable "Preferences > General > Session > Drag and drop import always copies files to session"
(0024634)
unfa   
2020-07-08 07:31   
I think I've been using both Import dialog with "Copy files to session" disabled, and simply dragging the files into the session timeline.

I haven't tested this yet in Ardour 6.
(0024635)
paul   
2020-07-08 13:51   
Drag-n-drop has no options associated with it, and does not follow the settings in the dialog (which you could argue is a bug or usability problem; you might be right although it's not 100% clear). Drag-n-drop will always copy the files into the session (at this time).
(0024639)
alexmitchellmus   
2020-07-08 16:49   
DnD should either:

* Follow the set preference
Or
* Present the user with a dialogue: copy or link. (For all the files associated with the DnD action)
(0024641)
paul   
2020-07-08 17:03   
There will never be a dialog for DnD. It's too cumbersome. If you want control over how import/embed happens, use Ctrl-i (the import dialog)
(0024642)
alexmitchellmus   
2020-07-08 17:05   
Ok, well I think DnD should follow the setting then at very least. As currently it's confusing.
(0024643)
alexmitchellmus   
2020-07-08 17:07   
Wait... Robin stated DnD follows the settings? Is that correct?
(0024644)
alexmitchellmus   
2020-07-08 17:07   
Wait... Robin stated DnD follows the settings? Is that correct?
(0024646)
paul   
2020-07-08 17:15   
Robin is correct and I am wrong. Nothing new there :(
(0024647)
paul   
2020-07-08 17:16   
Ah, no, we are both right :)

There is a global option found ONLY in the preferences editor. DnD follows that.

This is not the same as the control found in the import dialog.
(0024648)
alexmitchellmus   
2020-07-08 17:22   
I feel that it can still be a source of confusion.

Without a popup dialogue for DnD possibly DnD should only ever copy.

Linking is an advanced use case, as projects could easily be damaged if moved around and a user forgot what the DnD setting was.
(0024649)
paul   
2020-07-08 17:55   
"possibly DnD should only ever copy."

which is why there's an option called "only ever copy imported files". Because "possibly" isn't the same as "definitely"
(0024650)
alexmitchellmus   
2020-07-08 18:02   
Sorry, I mean:

Possibly (as in possibly it should be locked), DnD should definitely only ever copy.
(0024651)
alexmitchellmus   
2020-07-08 18:04   
Unless there was a dialogue. So it was clear to the user.
(0024652)
x42   
2020-07-08 18:33   
(Last edited: 2020-07-08 18:34)
When the preference is *disabled*, and embedding is allowed. Embedding/linking is the default drop action. This is indicated by a small link-icon.
Like in any file-browser, holding ctrl will copy the file instead (shown by a small plus icon).

Note that this is only relevant when importing audio (drag/drop of files from a file-browser or desktop). DnD from Ardour's source-list (editor sidebar, previously imported to recorded files) is unrelated.
Also note that some files must be imported. mp3s or files where the sample-rate mismatches. Those are converted or resampled.

The preference "Drag and drop import always copies files to session" was off by default in Ardour5, in Ardour6 it's on by default.

@unfa is this the issue? Was the file accidentally copied instead of linked, or is the issue deeper?
Could you attach the .ardour session file (or check yourself if the file was copied into the session, and is not referenced by absolute path in the .ardour file). Thanks.

(0024653)
alexmitchellmus   
2020-07-08 18:45   
Thanks Robin and Paul.

One question. Currently is there an indication of the media on the timeline that is linked/internal?

I think this would be less confusing if it was clear what the relationship the session had with its media.

@x42 you mentioned an icon? Is that on the timeline media?
(0026129)
kiilerix   
2021-09-01 12:34   
Using Ardour 6.8, I see the same problem as unfa seemed to report:
"Importing a file without copying it seems to work initially, but subsequent changes to the source files are somehow ignored, as if Ardour cached the file somewhere and refused to reload it."

It seems like the discussion digressed into defaults for "Copy files to session", but the original report was clear that it was "without copying", and "Ardour is not storing a copy in interchange, or external".

Could there be other reasons that changes to imported files don't show up? Are there some other caches or copies in memory?

What behaviour should we expect when an imported file is changed? Should the file change be detected immediately, or after a restart of Ardour?
(0026130)
paul   
2021-09-01 14:11   
It would not be detected immediately - Ardour does not run a file monitor on the files used in a session. But it should be noticed on restart/reload of the session.
(0026131)
alexmitchellmus   
2021-09-01 16:26   
Could a wait timer check the files referenced for new modified timestamp?
At say 1 second intervals?
(0026134)
kiilerix   
2021-09-01 21:49   
Paul, thanks for clarifying the expected behaviour. I think I already tried restart without success, but I will take a closer look.

Alex: FWIW, I don't like the idea of polling every second. The better and "perfect" solution would be to subscribe to file system events whenever one of the source files change. But that would still inherently be "undefined behaviour" if it happened during playback/export, so it is perhaps not worth it.

A couple of change ideas that would have worked smoothly for me:

1. It seems like it currently is a silent no-op to import a source file that already exist. A "sorry dave, I can't let you do that" error message would be slightly better. But the ideal for me would be if it re-imported the file.

2. "Rebuild Peak Files" seems to be a solution to a very similar problem/use case. I tried it, but it didn't solve my problem. It could perhaps be generalized to "Reload Source Files" - with the obvious side effect that it rebuilt these "peak files". (It seems like "peak files" is an optimization implementation detail that rather shouldn't be exposed in the UI.)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8804 [ardour] bugs minor always 2021-09-28 12:10 2021-09-28 14:24
Reporter: medicineman25 Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Select all volume control does not work
Description: The controls for dragging down the volume on multiple selected tracks does not work.

"drag" is two finger drag on a track-pad, which should be synonymous with a mouse scroll (tested and confirmed on other system programs).

The following combinations have been tried after selecting multiple tracks in the mix window:

click+drag
Shift+Ctrl+click+drag
Shift+click+drag
Ctrl+click+drag
Shift+Win+click+drag
Win+click+drag
Shift+Alt+click+drag
Alt+click+drag
Ctrl+Alt+click+drag
Ctrl+Win+Alt+click+drag
Win+click drag
etc...

I have also tried with the fn key in all of the above combinations and also using the right-side keys instead of the left-side keys.

This may or may not be relevant, but I am using the i3 window manager and have the Alt key set as modifier.
Tags: broken, control points
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0026169)
medicineman25   
2021-09-28 14:24   
This should be changed from bug to feature request, as I've discovered that unfortunately it is intentional behaviour.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8803 [ardour] features minor N/A 2021-09-28 11:59 2021-09-28 11:59
Reporter: medicineman25 Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Setting for pre/post fader plugins/sends by default
Description: I can't remember the last time I added a plugin as post-fader. Post-fader is the exception to the rule and should be reflected in the default gui behaviour.

There should be a setting available to toggle between default pre/post fader when adding a plugin or a send, it should be set to pre-fader from factory.

The location of the "fader" widget in the black space should also be either at the top or the bottom depending on the setting. At the bottom for pre default, the top for post default.
Tags: aux send, control points, Defaults, improvements, send
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8792 [ardour] bugs minor always 2021-09-01 21:24 2021-09-27 11:21
Reporter: hal2k Platform: Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Audio Defaults to Output Device And Can't be Changed
Description: Audio output will default to one USB output device, and can't be changed. If you start a new session, and choose a different audio output device, it will ignore that choice and use the same audio output device. I have a Focusrite Scarlett, a generic USB audio output device, and built-in audio. Despite settings when creating a new session, Ardour 6.9 will always use the Scarlett device. If I unplug the Scarlett, and create a new session, I can then choose and use one of the other two audio output devices.
Tags:
Steps To Reproduce: Create a new session. Choose Focusrite USB audio interface for input and output. Everything works. Close and start a new session. Choose another audio device for output. While another output device can be selected when creating the session, it will be ignored and the Focusrite will still be used when the session is started.
Additional Information: I have gone around and around on this. I am using an out of the box configuration and routing for Ardour, with the "Recording" session default. I thought it was my inexperience, but was able to immediately record and play back a session on my Macbook Pro, so I know it's nothing I am doing wrong.
System Description
Attached Files:
Notes
(0026165)
KellyP   
2021-09-27 11:21   
Hoping to see another update on this matter.
https://www.lynnlaw.com/

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7392 [ardour] bugs major always 2017-06-09 17:44 2021-09-24 06:42
Reporter: unfa Platform: PC / Linux  
Assigned To: OS: Linux Mint 18.1  
Priority: normal OS Version: KDE5  
Status: feedback Product Version: 5.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Reordering tracks in the editor view doesn't work
Description: Neither dragging or using Ctrl + ? / Ctrl + ? works.

In Ardour 5.8 track reordering works as expected, in 5.9 it seems to be locked down completely.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019779)
x42   
2017-06-09 18:03   
Try the editor-[right]sidebar or mixer-[left]sidebar.

If this is an older session, re-ordering them once there, should fix the issue.
(0019780)
mhartzel   
2017-06-10 12:54   
I had this happen on a newly created Ardour 5.9 session. When I manually disabled visibility of all tracks in the "Editor List" window and enabled it again for all tracks it resolved the problem.
(0019795)
unfa   
2017-06-16 08:56   
I can confirm that in projects created in 5.9 from scratch this problem doesn't occur.
(0019796)
mhartzel   
2017-06-16 14:16   
My problem (above) happened with a session created from scratch with 5.9 and no template was used. So the bug exists in 5.9 code also.
(0019797)
x42   
2017-06-17 17:26   
(Last edited: 2017-06-17 20:17)
Can you test if the problem is still present in 5.10-21-g506b478fe

(0021215)
x42   
2020-04-06 18:47   
Is this still an issue with Ardour 6.0-pre1?
(0026155)
viktorsmari   
2021-09-23 06:40   
Should dragging tracks in the editor view be working now or not?
It does not work on 6.9

I would really like this feature.
I always have to google how to reorder tracks if I have not been using Ardour for a while.
(0026156)
x42   
2021-09-23 13:03   
> Should dragging tracks in the editor view be working now or not?

Drag/Drop was never used to move tracks. In the editor: Select tracks, then ctrl + arrow up/down


> I always have to google how to reorder tracks if I have not been using Ardour for a while.

Have a look a Ardour's Menu > Track > Move Selected Tracks ... That shows the keyboard shortcuts.
(0026157)
viktorsmari   
2021-09-23 13:32   
After using other track based software (in my personal experience) I would say dragging tracks is very common.
I think most new users need to Google how to drag tracks in Ardour, I know I have had to a few times.

> Drag/Drop was never used to move tracks. In the editor: Select tracks, then ctrl + arrow up/down
Could it be considered to move tracks?

Is there a logic or reasoning written somewhere on why it's not possible to drag and drop tracks?
(0026158)
x42   
2021-09-24 05:57   
> Is there a logic or reasoning written somewhere on why it's not possible to drag and drop tracks?

Simply because it is very hard and time-consuming to implement, nobody has yet volunteered to do it.

You can drag/drop using the Track list in the Editor and MIxer sidebars though.
(0026159)
viktorsmari   
2021-09-24 06:42   
> Simply because it is very hard and time-consuming to implement, nobody has yet volunteered to do it.

Thanks, valid point!

Let's hope this gets attention in the future.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8799 [ardour] bugs minor always 2021-09-19 09:37 2021-09-19 09:37
Reporter: viktorsmari Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mouse Scrolling over a unselected MIDI track should NOT change the velocity 'accidentally'
Description: When scrolling over a few MIDI tracks with notes on them, Ardour stops scrolling and instead changes the velocity on the last 'remembered' notes.

When scrolling down from track 1 to track 4, I expect Ardour to keep scrolling down, and not stopping mid way to change the velocity of some notes on track 2 or 3.

---- Possible changes ----
Only change the note with scrollwheel if the track is selected?
Only change the note with scrollwheel if DIRECTLY over that note AND / OR track is selected?
Tags: usability
Steps To Reproduce: - Be in Smart mode, and Draw Mode.
- Create 4 MIDI tracks with some notes on them
- Draw a note on Track 3
- Select Track 4
- Scroll all the way up
- Have the cursor centered horizontally
- Use mouse scroll wheel to scroll down to track 4

It should stop over track 3 and start changing the last drawn notes velocity
Additional Information: Added a screenshot when scrolling down.
System Description
Attached Files: 2021-09-19-111239_1116x504_scrot.png (45,369 bytes) 2021-09-19 09:37
https://tracker.ardour.org/file_download.php?file_id=4106&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8793 [ardour] other minor have not tried 2021-09-02 14:31 2021-09-02 14:31
Reporter: alastA4204 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour doesnt remember setting of control surface
Description: The setting motorised faders seems to not be saved . I have only noticed this in 6.9
Tags:
Steps To Reproduce: Tired saving and exiting , Ardour forgets this every time
Additional Information: See Picture
System Description
Attached Files: Screenshot_2021-09-02_10-20-48.png (85,779 bytes) 2021-09-02 14:31
https://tracker.ardour.org/file_download.php?file_id=4101&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8791 [ardour] bugs minor sometimes 2021-09-01 16:31 2021-09-01 16:41
Reporter: Arello Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Segmentation fault crashes Ardour during playing keyboards(?)
Description: Backtrace after one of the crashes:

Thread 24 "audioengine" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd0154700 (LWP 5450)]
0x00007ffff745be1b in ARDOUR::PortManager::run_input_meters(unsigned int, long) () from /opt/Ardour-6.9.0/lib/libardour.so.3
(gdb) thread apply all bt

Thread 63 (Thread 0x7fff2affd700 (LWP 5491)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff7ba068d in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
#3 0x00007ffff7ba0743 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000004 0x00007ffff7ba09eb in ArdourWaveView::WaveViewThreads::_thread_proc() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000005 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
#6 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#7 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
0000008 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 62 (Thread 0x7fff2b7fe700 (LWP 5490)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff7ba068d in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
#3 0x00007ffff7ba0743 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000004 0x00007ffff7ba09eb in ArdourWaveView::WaveViewThreads::_thread_proc() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000005 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
#6 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#7 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
0000008 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 61 (Thread 0x7fff2bfff700 (LWP 5489)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff7ba068d in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
#3 0x00007ffff7ba0743 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000004 0x00007ffff7ba09eb in ArdourWaveView::WaveViewThreads::_thread_proc() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000005 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
#6 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#7 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
0000008 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 60 (Thread 0x7fff4492a700 (LWP 5488)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
--Type <RET> for more, q to quit, c to continue without paging--
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff7ba068d in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
#3 0x00007ffff7ba0743 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000004 0x00007ffff7ba09eb in ArdourWaveView::WaveViewThreads::_thread_proc() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000005 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
#6 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#7 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
0000008 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 59 (Thread 0x7fff4512b700 (LWP 5487)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff7ba068d in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
#3 0x00007ffff7ba0743 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000004 0x00007ffff7ba09eb in ArdourWaveView::WaveViewThreads::_thread_proc() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000005 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
#6 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#7 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
0000008 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 58 (Thread 0x7fff4592c700 (LWP 5486)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff7ba068d in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
#3 0x00007ffff7ba0743 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000004 0x00007ffff7ba09eb in ArdourWaveView::WaveViewThreads::_thread_proc() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000005 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
#6 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#7 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
0000008 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 57 (Thread 0x7fff4612d700 (LWP 5485)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff7ba068d in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
#3 0x00007ffff7ba0743 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
--Type <RET> for more, q to quit, c to continue without paging--
0000004 0x00007ffff7ba09eb in ArdourWaveView::WaveViewThreads::_thread_proc() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000005 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
#6 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#7 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
0000008 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 56 (Thread 0x7fff4692e700 (LWP 5484)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff7ba068d in ArdourWaveView::WaveViewThreads::_dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
#3 0x00007ffff7ba0743 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000004 0x00007ffff7ba09eb in ArdourWaveView::WaveViewThreads::_thread_proc() () from /opt/Ardour-6.9.0/lib/libwaveview.so.0
0000005 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
#6 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#7 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
0000008 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 55 (Thread 0x7fffbbfff700 (LWP 5483)):
#0 0x00007ffff0889bf0 in __GI___nanosleep (requested_time=0x7fffbbffecc0, remaining=0x7fffbbffecd0)
    at ../sysdeps/unix/sysv/linux/nanosleep.c:28
0000001 0x00007ffff479da38 in g_usleep () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff70a3a00 in ARDOUR::AutomationWatch::thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
#3 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
0000004 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 54 (Thread 0x7fffbb7fe700 (LWP 5482)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x555556e2d258) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
0000001 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556e2d208, cond=0x555556e2d230) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556e2d230, mutex=0x555556e2d208) at pthread_cond_wait.c:655
#3 0x00007ffff7500243 in ARDOUR::Session::auto_connect_thread_run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7500418 in ARDOUR::Session::auto_connect_thread(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

--Type <RET> for more, q to quit, c to continue without paging--
Thread 53 (Thread 0x7fffd1902700 (LWP 5481)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x555556e2d1e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
0000001 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556e2d198, cond=0x555556e2d1c0) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556e2d1c0, mutex=0x555556e2d198) at pthread_cond_wait.c:655
#3 0x00007ffff75763d3 in ARDOUR::Session::emit_thread_run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7576408 in ARDOUR::Session::emit_thread(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 52 (Thread 0x7fffba7fc700 (LWP 5480)):
#0 0x00007fffee4a0819 in __GI___poll (fds=0x7fff401427d0, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff476cd66 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff476d0f2 in g_main_loop_run () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#3 0x00007ffff58e9b32 in BaseUI::main_thread() () from /opt/Ardour-6.9.0/lib/libpbd.so.4
0000004 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
0000005 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 51 (Thread 0x7fff51cdf700 (LWP 5479)):
#0 0x00007fffee4a0819 in __GI___poll (fds=0x7fff51cdeae8, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff58f3ff7 in CrossThreadChannel::poll_for_request() () from /opt/Ardour-6.9.0/lib/libpbd.so.4
#2 0x00007ffff58f4056 in CrossThreadChannel::receive(char&, bool) () from /opt/Ardour-6.9.0/lib/libpbd.so.4
#3 0x00007ffff70b08d6 in ARDOUR::Butler::thread_work() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff70b1a82 in ARDOUR::Butler::_thread_work(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff591c9b6 in ?? () from /opt/Ardour-6.9.0/lib/libpbd.so.4
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 50 (Thread 0x7fffb8f86700 (LWP 5478)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03c8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186d64 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186fd8 in ARDOUR::Graph::helper_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
--Type <RET> for more, q to quit, c to continue without paging--
0000005 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 49 (Thread 0x7fffb9007700 (LWP 5477)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03c8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186d64 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186fd8 in ARDOUR::Graph::helper_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 48 (Thread 0x7fffb9088700 (LWP 5476)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03c8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186d64 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186fd8 in ARDOUR::Graph::helper_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 47 (Thread 0x7fffb9109700 (LWP 5475)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03c8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186d64 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186fd8 in ARDOUR::Graph::helper_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
--Type <RET> for more, q to quit, c to continue without paging--
0000005 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 46 (Thread 0x7fffb918a700 (LWP 5474)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03c8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186d64 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186fd8 in ARDOUR::Graph::helper_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 45 (Thread 0x7fffb920b700 (LWP 5473)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03c8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186d64 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186fd8 in ARDOUR::Graph::helper_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 44 (Thread 0x7fffb928c700 (LWP 5472)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03c8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186d64 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186fd8 in ARDOUR::Graph::helper_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
--Type <RET> for more, q to quit, c to continue without paging--
0000005 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 43 (Thread 0x7fffb930d700 (LWP 5471)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03c8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186d64 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186fd8 in ARDOUR::Graph::helper_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 42 (Thread 0x7fffb938e700 (LWP 5470)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03c8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186d64 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186fd8 in ARDOUR::Graph::helper_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 41 (Thread 0x7fffb940f700 (LWP 5469)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03c8)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03c8, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186d64 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186fd8 in ARDOUR::Graph::helper_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
--Type <RET> for more, q to quit, c to continue without paging--
0000005 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 40 (Thread 0x7fffb9490700 (LWP 5468)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555557cf03f0)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555557cf03f0, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555557cf03f0, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff7186ba6 in ARDOUR::Graph::reached_terminal_node() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff7186d18 in ARDOUR::Graph::run_one() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff71872c0 in ARDOUR::Graph::main_thread() () from /opt/Ardour-6.9.0/lib/libardour.so.3
#6 0x00007fffd272cd81 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) ()
   from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
#7 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
0000008 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 39 (Thread 0x7fffb949b900 (LWP 5467)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 38 (Thread 0x7fffb94a7900 (LWP 5466)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
--Type <RET> for more, q to quit, c to continue without paging--
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 37 (Thread 0x7fffb94b3900 (LWP 5465)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 36 (Thread 0x7fffb94bf900 (LWP 5464)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 35 (Thread 0x7fffb94cb900 (LWP 5463)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 34 (Thread 0x7fffb94d7900 (LWP 5462)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
--Type <RET> for more, q to quit, c to continue without paging--
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 33 (Thread 0x7fffb94e3900 (LWP 5461)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 32 (Thread 0x7fffb94ef900 (LWP 5460)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 31 (Thread 0x7fffb94fb900 (LWP 5459)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

--Type <RET> for more, q to quit, c to continue without paging--
Thread 30 (Thread 0x7fffb9507900 (LWP 5458)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 29 (Thread 0x7fffd000e900 (LWP 5457)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x555556e11f30)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
0000001 do_futex_wait (sem=sem@entry=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:111
#2 0x00007ffff0888988 in __new_sem_wait_slow (sem=0x555556e11f30, abstime=0x0) at sem_waitcommon.c:181
#3 0x00007ffff74e6869 in ARDOUR::RTTaskList::run() () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000004 0x00007ffff74e6c88 in ARDOUR::RTTaskList::_thread_run(void*) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 24 (Thread 0x7fffd0154700 (LWP 5450)):
#0 0x00007ffff745be1b in ARDOUR::PortManager::run_input_meters(unsigned int, long) () from /opt/Ardour-6.9.0/lib/libardour.so.3
0000001 0x00007ffff745e62b in ARDOUR::PortManager::cycle_start(unsigned int, ARDOUR::Session*) ()
   from /opt/Ardour-6.9.0/lib/libardour.so.3
#2 0x00007ffff705e722 in ARDOUR::AudioEngine::process_callback(unsigned int) () from /opt/Ardour-6.9.0/lib/libardour.so.3
#3 0x00007fffd272c2fb in ARDOUR::JACKAudioBackend::process_thread() () from /opt/Ardour-6.9.0/lib/backends/libjack_audiobackend.so
0000004 0x00007fffd24d882a in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000005 0x00007fffd24f0756 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 23 (Thread 0x7fffd0e7c700 (LWP 5449)):
#0 __libc_read (nbytes=4, buf=0x7fffd0e7bb80, fd=12) at ../sysdeps/unix/sysv/linux/read.c:26
0000001 __libc_read (fd=12, buf=0x7fffd0e7bb80, nbytes=4) at ../sysdeps/unix/sysv/linux/read.c:24
#2 0x00007fffd24f19be in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#3 0x00007fffd24f4fc1 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
--Type <RET> for more, q to quit, c to continue without paging--
0000004 0x00007fffd24f0756 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 22 (Thread 0x7fffd1101700 (LWP 5448)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x555556f03678) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
0000001 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556f03620, cond=0x555556f03650) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556f03650, mutex=0x555556f03620) at pthread_cond_wait.c:655
#3 0x00007fffd24f111c in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000004 0x00007fffd24e8d95 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000005 0x00007fffd24f0756 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#6 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 16 (Thread 0x7fffd0cee700 (LWP 5441)):
#0 0x00007fffee4a0819 in __GI___poll (fds=0x555556bddce0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff476cd66 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff476ce7c in g_main_context_iteration () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#3 0x00007ffff476cec1 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000004 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 8 (Thread 0x7fffd3fff700 (LWP 5433)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff705d9c3 in ARDOUR::AudioEngine::do_devicelist_update() () from /opt/Ardour-6.9.0/lib/libardour.so.3
#3 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
0000004 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7fffe2727700 (LWP 5432)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff705fb1d in ARDOUR::AudioEngine::do_reset_backend() () from /opt/Ardour-6.9.0/lib/libardour.so.3
--Type <RET> for more, q to quit, c to continue without paging--
#3 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
0000004 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 5 (Thread 0x7fffe3fff700 (LWP 5430)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff701eab7 in ARDOUR::Analyser::work() () from /opt/Ardour-6.9.0/lib/libardour.so.3
#3 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
0000004 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7fffe8dbf700 (LWP 5429)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff75eac87 in ?? () from /opt/Ardour-6.9.0/lib/libardour.so.3
#3 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
0000004 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fffe95c0700 (LWP 5428)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff47bde4c in g_cond_wait () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff75eac87 in ?? () from /opt/Ardour-6.9.0/lib/libardour.so.3
#3 0x00007ffff4d06c4d in ?? () from /opt/Ardour-6.9.0/lib/libglibmm-2.4.so.1
0000004 0x00007ffff479c1e5 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
0000005 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7fffe9dc1700 (LWP 5427)):
#0 0x00007ffff0889bf0 in __GI___nanosleep (requested_time=0x7fffe9dc0b40, remaining=0x7fffe9dc0b50)
    at ../sysdeps/unix/sysv/linux/nanosleep.c:28
0000001 0x00007ffff479da38 in g_usleep () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
#2 0x00005555562dfab4 in ?? ()
#3 0x00007ffff087ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
0000004 0x00007fffee4ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7fffea194900 (LWP 5423)):
#0 0x00007fffee4a0819 in __GI___poll (fds=0x5555570c1b10, nfds=4, timeout=28) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff476cd66 in ?? () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#2 0x00007ffff476d0f2 in g_main_loop_run () from /opt/Ardour-6.9.0/lib/libglib-2.0.so.0
#3 0x00007ffff3d5d3e7 in gtk_main () from /opt/Ardour-6.9.0/lib/libgtk-x11-2.0.so.0
0000004 0x00007ffff5bb9a55 in Gtkmm2ext::UI::run(Receiver&) () from /opt/Ardour-6.9.0/lib/libgtkmm2ext.so.0
0000005 0x0000555555960814 in ?? ()
#6 0x00007fffee3d609b in __libc_start_main (main=0x555555960420, argc=1, argv=0x7fffffffd628, init=<optimized out>,
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd618) at ../csu/libc-start.c:308
#7 0x000055555596760a in ?? ()
Tags: crash
Steps To Reproduce: Not sure how this would be reproduce-able on different setups than mine. Every time when crashing happened I was usually just playing my MIDI connected keyboards while my certain project was open. Segmentation fault often occurred during playback but not always. I had some other software open too but none of them had issues during Ardour's crash.
Additional Information:
System Description
Attached Files:
Notes
(0026132)
x42   
2021-09-01 16:39   
See also https://discourse.ardour.org/t/ardour-crashing-when-feeding-to-obs/106312/12

That backtrace there is from a debug-build with line numbers.
(0026133)
x42   
2021-09-01 16:41   
Copied by from https://discourse.ardour.org/t/ardour-crashing-when-feeding-to-obs/106312/12
Thread 26 (Thread 0x7fffcb5d4700 (LWP 180156)):
#0  0x00007ffff6f8e92a in ARDOUR::PortManager::run_input_meters (this=0x1f7a500, n_samples=512, rate=48000) at ../libs/ardour/port_manager.cc:1848
0000001  0x00007ffff6f89f84 in ARDOUR::PortManager::cycle_start (this=0x1f7a500, nframes=512, s=0x3c26810) at ../libs/ardour/port_manager.cc:1092
#2  0x00007ffff6951588 in ARDOUR::AudioEngine::process_callback (this=0x1f7a500, nframes=512) at ../libs/ardour/audioengine.cc:495
#3  0x00007fffd17df3ba in ARDOUR::JACKAudioBackend::process_thread (this=0x2823470) at ../libs/backends/jack/jack_audiobackend.cc:986
0000004  0x00007fffd17df30a in ARDOUR::JACKAudioBackend::_process_thread (arg=0x2823470) at ../libs/backends/jack/jack_audiobackend.cc:961
0000005  0x00007fffe008b1f2 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#6  0x00007fffe00a4280 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#7  0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
0000008  0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 25 (Thread 0x7fffd038d700 (LWP 180155)):
#0  __libc_read (nbytes=4, buf=0x7fffd038cb80, fd=10) at ../sysdeps/unix/sysv/linux/read.c:26
0000001  __libc_read (fd=10, buf=0x7fffd038cb80, nbytes=4) at ../sysdeps/unix/sysv/linux/read.c:24
#2  0x00007fffe00a54c2 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#3  0x00007fffe00a891d in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000004  0x00007fffe00a4280 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000005  0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
#6  0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 24 (Thread 0x7fffd040e700 (LWP 180154)):
#0  futex_wait_cancelable (private=<optimised out>, expected=0, futex_word=0x24ec548) at ../sysdeps/nptl/futex-internal.h:183
0000001  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x24ec4f0, cond=0x24ec520) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x24ec520, mutex=0x24ec4f0) at pthread_cond_wait.c:638
#3  0x00007fffe00a4d32 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000004  0x00007fffe009c83d in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
0000005  0x00007fffe00a4280 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#6  0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
#7  0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 19 (Thread 0x7fffc97fa700 (LWP 180149)):
#0  futex_abstimed_wait_cancelable (private=<optimised out>, abstime=0x7fffc97f9c60, clockid=<optimised out>, expected=0, futex_word=0x25a1268) at ../sysdeps/nptl/futex-internal.h:320
0000001  __pthread_cond_wait_common (abstime=0x7fffc97f9c60, clockid=<optimised out>, mutex=0x2416990, cond=0x25a1240) at pthread_cond_wait.c:520
#2  __pthread_cond_timedwait (cond=0x25a1240, mutex=0x2416990, abstime=0x7fffc97f9c60) at pthread_cond_wait.c:656
#3  0x00007ffff32e8465 in g_cond_wait_until () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000004  0x00007ffff326cb63 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000005  0x00007ffff326cd8a in g_async_queue_timeout_pop () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
#6  0x00007ffff32c84a8 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
#7  0x00007ffff32c7825 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000008  0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
0000009  0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 16 (Thread 0x7fffcaffd700 (LWP 180146)):
#0  0x00007fffed073aff in __GI___poll (fds=0x264aeb0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001  0x00007ffff329cad5 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
#2  0x00007ffff329ccf7 in g_main_context_iteration () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
#3  0x00007ffff329cd49 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000004  0x00007ffff32c7825 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000005  0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
#6  0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 8 (Thread 0x7fffcbfff700 (LWP 180138)):
#0  futex_wait_cancelable (private=<optimised out>, expected=0, futex_word=0x2828c78) at ../sysdeps/nptl/futex-internal.h:183
0000001  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x2828c90, cond=0x2828c50) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x2828c50, mutex=0x2828c90) at pthread_cond_wait.c:638
#3  0x00007ffff32e8554 in g_cond_wait () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000004  0x00007ffff69522fd in ARDOUR::AudioEngine::do_devicelist_update (this=0x1f7a500) at ../libs/ardour/audioengine.cc:720
0000005  0x00007ffff6962b71 in boost::_mfi::mf0<void, ARDOUR::AudioEngine>::operator() (this=0x2829040, p=0x1f7a500) at /home/ardour/linux-x86_64/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
#6  0x00007ffff6962790 in boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list0> (this=0x2829050, f=..., a=...) at /home/ardour/linux-x86_64/gtk/inst/include/boost/bind/bind.hpp:259
#7  0x00007ffff6962159 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >::operator() (this=0x2829040) at /home/ardour/linux-x86_64/gtk/inst/include/boost/bind/bind_template.hpp:20
0000008  0x00007ffff6961a5c in sigc::adaptor_functor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > > >::operator() (this=0x2829040) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000009  0x00007ffff6960cd8 in sigc::internal::slot_call0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >, void>::call_it (rep=0x2829010) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000010 0x00007ffff3826b72 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglibmm-2.4.so.1
0000011 0x00007ffff32c7825 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000012 0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
0000013 0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7fffe15be700 (LWP 180137)):
#0  futex_wait_cancelable (private=<optimised out>, expected=0, futex_word=0x28297a8) at ../sysdeps/nptl/futex-internal.h:183
0000001  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x2829180, cond=0x2829780) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x2829780, mutex=0x2829180) at pthread_cond_wait.c:638
#3  0x00007ffff32e8554 in g_cond_wait () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000004  0x00007ffff695209f in ARDOUR::AudioEngine::do_reset_backend (this=0x1f7a500) at ../libs/ardour/audioengine.cc:684
0000005  0x00007ffff6962b71 in boost::_mfi::mf0<void, ARDOUR::AudioEngine>::operator() (this=0x2829340, p=0x1f7a500) at /home/ardour/linux-x86_64/gtk/inst/include/boost/bind/mem_fn_template.hpp:49
#6  0x00007ffff6962790 in boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list0> (this=0x2829350, f=..., a=...) at /home/ardour/linux-x86_64/gtk/inst/include/boost/bind/bind.hpp:259
#7  0x00007ffff6962159 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >::operator() (this=0x2829340) at /home/ardour/linux-x86_64/gtk/inst/include/boost/bind/bind_template.hpp:20
0000008  0x00007ffff6961a5c in sigc::adaptor_functor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > > >::operator() (this=0x2829340) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000009  0x00007ffff6960cd8 in sigc::internal::slot_call0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >, void>::call_it (rep=0x2829310) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000010 0x00007ffff3826b72 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglibmm-2.4.so.1
0000011 0x00007ffff32c7825 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000012 0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
0000013 0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 5 (Thread 0x7fffe2ffd700 (LWP 180135)):
#0  futex_wait_cancelable (private=<optimised out>, expected=0, futex_word=0x1e6c4d8) at ../sysdeps/nptl/futex-internal.h:183
0000001  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x1e6c480, cond=0x1e6c4b0) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x1e6c4b0, mutex=0x1e6c480) at pthread_cond_wait.c:638
#3  0x00007ffff32e8554 in g_cond_wait () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000004  0x00007ffff68fda5b in ARDOUR::Analyser::work () at ../libs/ardour/analyser.cc:93
0000005  0x00007ffff68fd7f1 in analyser_work () at ../libs/ardour/analyser.cc:58
#6  0x0000000001056d4d in sigc::pointer_functor0<void>::operator() (this=0x1f3a3c8) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
#7  0x0000000001053e04 in sigc::adaptor_functor<sigc::pointer_functor0<void> >::operator() (this=0x1f3a3c0) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000008  0x000000000104fa4f in sigc::internal::slot_call0<sigc::pointer_functor0<void>, void>::call_it (rep=0x1f3a390) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000009  0x00007ffff3826b72 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglibmm-2.4.so.1
0000010 0x00007ffff32c7825 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000011 0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
0000012 0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7fffe37fe700 (LWP 180134)):
#0  futex_wait_cancelable (private=<optimised out>, expected=0, futex_word=0x1e7adf8) at ../sysdeps/nptl/futex-internal.h:183
0000001  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x1e7ae10, cond=0x1e7add0) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x1e7add0, mutex=0x1e7ae10) at pthread_cond_wait.c:638
#3  0x00007ffff32e8554 in g_cond_wait () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000004  0x00007ffff71cd831 in peak_thread_work () at ../libs/ardour/source_factory.cc:74
0000005  0x0000000001056d4d in sigc::pointer_functor0<void>::operator() (this=0x1f38bb8) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
#6  0x0000000001053e04 in sigc::adaptor_functor<sigc::pointer_functor0<void> >::operator() (this=0x1f38bb0) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7  0x000000000104fa4f in sigc::internal::slot_call0<sigc::pointer_functor0<void>, void>::call_it (rep=0x1f38b80) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008  0x00007ffff3826b72 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglibmm-2.4.so.1
0000009  0x00007ffff32c7825 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000010 0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
0000011 0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fffe3fff700 (LWP 180133)):
#0  futex_wait_cancelable (private=<optimised out>, expected=0, futex_word=0x1e7adf8) at ../sysdeps/nptl/futex-internal.h:183
0000001  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x1e7ae10, cond=0x1e7add0) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x1e7add0, mutex=0x1e7ae10) at pthread_cond_wait.c:638
#3  0x00007ffff32e8554 in g_cond_wait () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000004  0x00007ffff71cd831 in peak_thread_work () at ../libs/ardour/source_factory.cc:74
0000005  0x0000000001056d4d in sigc::pointer_functor0<void>::operator() (this=0x1f38c48) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
#6  0x0000000001053e04 in sigc::adaptor_functor<sigc::pointer_functor0<void> >::operator() (this=0x1f38c40) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7  0x000000000104fa4f in sigc::internal::slot_call0<sigc::pointer_functor0<void>, void>::call_it (rep=0x1f38c10) at /home/ardour/linux-x86_64/gtk/inst/include/sigc++-2.0/sigc++/functors/slot.h:103
0000008  0x00007ffff3826b72 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglibmm-2.4.so.1
0000009  0x00007ffff32c7825 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
0000010 0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
0000011 0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7fffe8ac1700 (LWP 180132)):
#0  0x00007fffed03e3bf in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7fffe8ac0bd0, rem=0x7fffe8ac0bc0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
0000001  0x00007fffed044047 in __GI___nanosleep (requested_time=<optimised out>, remaining=<optimised out>) at nanosleep.c:27
#2  0x00007ffff32c92c8 in g_usleep () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
#3  0x00000000014bd6cf in gui_event_loop (ptr=0x0) at ../gtk2_ardour/linux_vst_gui_support.cc:468
0000004  0x00007fffef430609 in start_thread (arg=<optimised out>) at pthread_create.c:477
0000005  0x00007fffed080293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7fffe93b0540 (LWP 180128)):
#0  0x00007fffed073aff in __GI___poll (fds=0x25783f0, nfds=4, timeout=7) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001  0x00007ffff329cad5 in ?? () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
#2  0x00007ffff329cbe5 in g_main_loop_run () from /opt/Ardour-6.9.0-dbg/lib/libglib-2.0.so.0
#3  0x00007ffff28d1657 in gtk_main () from /opt/Ardour-6.9.0-dbg/lib/libgtk-x11-2.0.so.0
0000004  0x00007ffff481a0f1 in Gtkmm2ext::UI::run (this=0x20378d0, old_receiver=...) at ../libs/gtkmm2ext/gtk_ui.cc:310
0000005  0x0000000000d1eeea in main (argc=1, argv=0x7fffffffd258) at ../gtk2_ardour/main.cc:422

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5554 [ardour] features feature N/A 2013-06-27 16:42 2021-08-31 20:35
Reporter: joshjaysalazar Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 3.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Split MIDI by Pitch
Description: A fantastic feature to add for MIDI functionality would be the ability to split any MIDI region by note pitch. Specifically, this would be incredibly useful for MIDI drum sequences that were programmed onto one track (not an uncommon thing to do, especially when it's being programmed in real time via an electronic drum kit). When it comes time to mix, it would be extremely handy to simply split the track by pitch so that each different drum/crash/etc. would end up on its own track. Logic is the DAW that comes to mind that has this feature, and after using said feature once, I must admit it saves a TON of time when working with electronic drums. You can see how it works in the Logic Pro 9 manual: http://help.apple.com/logicpro/mac/9.1.6/en/logicpro/usermanual/index.html#chapter=13%26section=23%26tasks=true
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015060)
Leatuspenguin   
2013-06-27 20:55   
(Last edited: 2013-09-19 14:20)
+ 1 on this. Especially with plugins like DrumGizmo showing real promise, this would be a hugely useful feature.

Pro Tools has a similar feature aswell called MIDI Event Split that might also be helpful for inspiration.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8320 [ardour] bugs minor always 2020-07-19 04:45 2021-08-25 00:44
Reporter: don3 Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: A6 no longer remembers user-selected ruler fields
Description: Ardour version: 6.2.33-dbg

Under previous versions, Ardour remembered the user's choice of fields to display in the ruler section. I believe it was stored in the session, and also inherited from templates.

In Ardour 6, every time I open a session, it reverts to a fixed list of fields -- everything except Samples and Video. Is there a way to get the previous behaviour? If not, this seems to be a regression.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0024770)
x42   
2020-07-19 15:41   
Ardour6 currently automatically shows rulers when a corresponding grid is used.

That does however indeed have some issues associated with it, and ruler visibility is indeed not correctly remembered
(0024821)
don3   
2020-07-27 11:54   
Ah, I didn't realize there was anything automatic going on there. That sounds like a nice feature -- although I just tried some different grid settings and I didn't see the rulers change.

For me, since I use Ardour mostly for live recording and (non-musical) editing, I don't usually care about the musical rulers (Bars:Beats, Meter, Tempo), and I don't usually need Timecode either. Removing the rulers I don't need frees up a little vertical space on the screen. Not a huge deal, it's just a new little speed bump in the workflow. Unfortunately, as crashy as A6 has been for me, it's something I've been having to do rather more often.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8700 [ardour] bugs minor always 2021-05-12 05:57 2021-08-23 03:22
Reporter: CTS Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on selecting "None" for both Audio setup inputs & outputs
Description: Ardour crashes/quits immediately if I select None under both inputs and outputs and attempt to start the Audio engine.
Tags:
Steps To Reproduce: 1. Open Ardour & open a session with audio engine with defaults, Macbook Pro Microphone as input and Speakers as output
2. Open the audio setup dialog again and stop the engine
3. Select None for input device & None for output device
4. Click "Start" to start the audio engine
Crash!
Additional Information: Obviously straying from the happy path with this one, but it's very easy to accidentally select the wrong thing and crash your session so would be nice if it was handled gracefully.

Version 6.6.479
System Description
Attached Files: none.png (180,508 bytes) 2021-05-12 05:57
https://tracker.ardour.org/file_download.php?file_id=4029&type=bug
png
Notes
(0025816)
CTS   
2021-05-12 07:31   
This also happens on Linux, version 6.6.489:29267. Looks like an unhandled exception according to the debug output:

```caught signal - shutting down.
Process is still running! trying SIGKILL
  PBD::stacktrace(std::ostream&, int)
  ARDOUR::Session::realtime_stop(bool, bool)
  ARDOUR::Session::engine_halted()
  ARDOUR::AudioEngine::stop(bool)
  /.../ardour/build/gtk2_ardour/ardour-6.6.489(+0xa5eb54) [0x556485499b54]
  /.../ardour/build/gtk2_ardour/ardour-6.6.489(+0xa6fadf) [0x5564854aaadf]
  /.../ardour/build/gtk2_ardour/ardour-6.6.489(+0xa6d982) [0x5564854a8982]
  /.../ardour/build/gtk2_ardour/ardour-6.6.489(+0xa6a9a8) [0x5564854a59a8]
  sigc::internal::signal_emit0<void, sigc::nil>::emit(sigc::internal::signal_impl*)
  sigc::signal0<void, sigc::nil>::emit() const
  sigc::signal0<void, sigc::nil>::operator()() const
  ArdourWidgets::ArdourButton::on_button_release_event(_GdkEventButton*)
  Gtk::Widget_Class::button_release_event_callback(_GtkWidget*, _GdkEventButton*)
  /usr/lib/libgtk-x11-2.0.so.0(+0x1360a8) [0x7f81a69c40a8]
  g_closure_invoke
  /usr/lib/libgobject-2.0.so.0(+0x3b9cb) [0x7f81a6e689cb]
  g_signal_emit_valist
  g_signal_emit
  /usr/lib/libgtk-x11-2.0.so.0(+0x25b275) [0x7f81a6ae9275]
  gtk_propagate_event
  gtk_main_do_event
  /usr/lib/libgdk-x11-2.0.so.0(+0x5e3be) [0x7f81a682f3be]
  g_main_context_dispatch
  /usr/lib/libglib-2.0.so.0(+0xa7b59) [0x7f81a6d9fb59]
  g_main_loop_run
  gtk_main
  Gtkmm2ext::UI::run(Receiver&)
  /.../ardour/build/gtk2_ardour/ardour-6.6.489(+0xcc2b35) [0x5564856fdb35]
  __libc_start_main
  /.../ardour/build/gtk2_ardour/ardour-6.6.489(+0x664b1e) [0x55648509fb1e]
Graph::engine_stopped. n_thread: 11
Graph::drop_threads() sema-counts: 0, 0, 1
Find a trout and repeatedly slap the nearest C++ who throws exceptions without catching them.
Ardour will likely crash now, giving you time to get the trout.

** (ardour-6.6.489:29267): ERROR **: 00:26:53.215:
unhandled exception (type std::exception) in signal handler:
what: std::exception

[1] 29267 trace trap (core dumped) ./gtk2_ardour/ardev
```
(0026121)
RobertJamesSpammer   
2021-08-23 03:21   
What does this mean for when the fix will be available - https://www.google.com will there be a 6.9 release or should I wait for 7.0?
(0026122)
RobertJamesSpammer   
2021-08-23 03:22   
google.com

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8531 [ardour] other minor always 2021-01-06 10:59 2021-08-18 03:57
Reporter: Carla Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Scaling for hdpi screen does not work
Description: This app is barely usable on my Ultra HD screen without applying a workaround for screen scaling
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025385)
x42   
2021-01-06 13:34   
What setting do you use in Preferences > Appearance > GUI and Font scaling?

What is your screen's geometry, dpi and your view angle?
(0025394)
Carla   
2021-01-08 10:16   
Thank you for the quick answer!
The problem is only the default scaling when using Ultra HD screen.
As it was very small it was hard to find the appearance settings when using your program the first time. Changing the scale works fine. Sorry for the misleading comment.
But it would be nice if it was readable by default.
I am using Ubuntu 20.04.1 LTS
and the screen resolution is 3840:2160 with 15.6-inch display.
(0026109)
matty0ung   
2021-08-17 10:07   
I'd second the call for automatic detection of HDPI displays. Although you can change preferences after you've got everything set up, when you first run the program, all the intro wizard screens are extremely hard to read on an HDPI display.
(0026112)
x42   
2021-08-18 00:37   
(Last edited: 2021-08-18 00:39)
When you first start Ardour, the new-user wizard dialog does suggest a scaling depending on screen-size (and also scaled up already).
It is the very first step since Ardour 6.0.

For a display 3840 x 2160px, the default is a scaling is 200%.

(0026113)
matty0ung   
2021-08-18 03:57   
Ah, OK, thanks. That's good. I have Ardour 5, so I didn't get any of that. Will try the more recent version.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8788 [ardour] bugs minor N/A 2021-08-18 02:17 2021-08-18 02:17
Reporter: ema87 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Save Ruler preference
Description: when you start ardour is shown by default all the rulers. tempo, cd mark, time, etc... and it fill the space in a small screen. So I take it out the most rulers. And when I save the session, it don't save with rulers changes
Tags: ruler
Steps To Reproduce:
Additional Information:
System Description
Attached Files: ard.jpg (375,341 bytes) 2021-08-18 02:17
https://tracker.ardour.org/file_download.php?file_id=4100&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8785 [ardour] bugs minor always 2021-08-06 18:10 2021-08-06 19:51
Reporter: autumncheney Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: unable to export/use loudness assistant
Description: whenever i try to export or use the loudness assistant, the process works for a second or two and then stops. i have to cancel it to regain control of ardour
Tags: 6.8, export, freeze, loudness assistant
Steps To Reproduce: try to export something or use the loudness assistant
Additional Information: i'm using ubuntu studio 20.10 with jackd2 1.9.19 built from source
System Description
Attached Files:
Notes
(0026092)
x42   
2021-08-06 19:23   
Does it work if you don't use JACK?
(0026093)
autumncheney   
2021-08-06 19:42   
ah, yes it does work if i use alsa

i thought it was a jack problem, though i can't find any solution for what's happening

my jack output keeps saying "ERROR: JackFreewheelDriver::Process: SuspendRefNum error" whenever i try to do this
(0026094)
x42   
2021-08-06 19:51   
> ERROR: JackFreewheelDriver::Process: SuspendRefNum error

That is a good clue. Thanks for checking.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8783 [ardour] bugs minor always 2021-07-28 10:44 2021-07-30 08:48
Reporter: klask Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: AU plugin settings are not saved(Slate VMR)
Description: Slate Digital "Virtual Mix Rack" plugin has its own GIU
After saving and loading the project, it launches the standard preset.
I think that the problem is related to the fact that data is not updated in "EplChunk".
( it locates in Session.Routes.Route.__numberOfRoute__.Processor.__numberOfPlugin.audiounit.plist.data )
In the case of VST3, the chunk is updated and there are no problems with saving.
Tags: Audio Unit, audiounit, saving, session
Steps To Reproduce: Add Slate VMR plugin AU
Change something
Save project
Close project
Open project
Additional Information: Perhaps you know how to decompile EplChunk Data values in audiounit?
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8478 [ardour] bugs minor always 2020-11-27 15:38 2021-07-20 11:19
Reporter: mpk Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Regular disk read errors
Description: Since using Ardour 6.5 I have started getting disk read errors in a large-ish editing project. I've never had any of these errors before (on any hardware). The error is:

"The disk system on your computer was not able to keep up with Ardour. Specifically, it failed to read data from disk quickly enough to keep up with playback."

I've git bisected this to find that commit 8b048bb35155e992ddead37cfd00aedc94ec71b5 is the first bad commit.
Tags:
Steps To Reproduce: The error seems to most often happen when adjusting the start point of a region backwards as the playhead is approaching. i.e. while playing or looping:

__________P_______<--pull back[-----REGION------]__________
Additional Information: Fairly certain this is not a hardware issue as:

1. I've never had this error before
2. It doesn't happen with builds before commit 8b048bb
3. I've got the error with the session files copied to 3 different disks including an NVMe SSD

System Description
Attached Files:
Notes
(0025271)
Hans Flikkema   
2020-11-27 16:42   
I have the same experience as mkp.
(0025791)
marrs   
2021-05-06 12:02   
I'm experiencing the same behaviour on macOS when playback returns to the beginning of a loop in 6.6-359.

Looking at the patch the original reporter referenced, all it really does is improve error reporting, so it's revealing an issue that was already present rather than causing it.
(0026065)
mpk   
2021-07-20 11:19   
I'm still getting this error with 6.8.0. It makes Ardour unusable when doing detailed editing with loop playback.

For the past 6 months I've been building from git and reverting commit 8b048bb, however this no longer works as too much has changed in session_transport.cc.

I'd love to help fix this and am available to assist in debugging.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8779 [ardour] features minor have not tried 2021-07-19 20:16 2021-07-19 20:16
Reporter: cooltehno_bugs Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Select all existing automation tracks whith "Ctrl+T" besides of selection of all tracks
Description: Ardour has a good function to select all tracks through the "Ctrl+T" snapshot. All works good until we have big number of automation tracks. When we press "Ctrl+T" - we just select all tracks except automation, so we need to select them manually. That's very time consuming when we want to copy/cut some range (in the "R"-mouse mode) of the session.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8776 [ardour] bugs minor always 2021-07-15 21:15 2021-07-17 13:32
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Branching internal track routing with a send falsely triggers the "Feedback Loop" detection
Description: My use case:

IN
  ?
SEND ? ?
  ? ?
PLUGIN ?
  ? ?
SISCO ? ?
  ?
OUT

I am branching out to send a "clean" signal along wiht the processed one to SiSco.lv2 for comparison.
It works great, but Ardour thinks this is a dangerous feedback loop and makes my session silent on load until I remove my sidechain send routing.

Could this be fixed?
Tags: feedback, routing
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20210717_153052.png (20,898 bytes) 2021-07-17 13:32
https://tracker.ardour.org/file_download.php?file_id=4084&type=bug
png
Notes
(0026056)
unfa   
2021-07-17 13:32   
My ASCII art flow diagram didn't work, so here's a drawn version:

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8775 [ardour] bugs minor always 2021-07-10 16:57 2021-07-10 16:57
Reporter: huik Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 8  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Recording MIDI with Count-in
Description: After Recording MIDI with Count-in, MIDI is moved two bars earlier.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8774 [ardour] other minor always 2021-07-09 19:10 2021-07-09 19:10
Reporter: rrt Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Signup for Mantis account always gives error if email address was already used
Description: I tried to sign up for an account just now. I had forgotten I already had an account. The error I got was "error 0008200" or similar, which said something had gone wrong with a cookie.

As far as I can tell the actual issue was that my email address had already been used for signup (unless signup is simply broken at present?).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8772 [ardour] bugs minor always 2021-07-09 00:46 2021-07-09 01:35
Reporter: tjm3803 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Reloading midi hardour based project not reloaded as it was saved.
Description: Possible Bugs:
Ardour 6.7-6.8

My set-up requires the Ardour output to be sent to Midi hardware. I do not use any of the audio capability that Ardour provides. I don’t need to. Yes, my laptop will have an easy life.

When I save a project, I expect all the outputs for the various midi tracks that I have created to be saved according to my systems requirements. Unfortunately this is not the case. When I reload any of my projects, every one of those midi outputs has been erroneously changed from “Hardware” to “Ardour Busses”. In other words Ardour is not delivering the project back to me in the configuration that I saved it. I find myself needing to reconfigure each and every track back to “hardware”, before all my various instruments wake up. More: When I pull the USB plug out of the laptop, the need to remain connected to “hardware” is forgotten and the preferred (!?) connection lapses to “Ardour Busses”. And once again all the tracks must be adjusted to output to “hardware”.

Spurious Performance Patch Change Message:
A characteristic which I have only recently noticed, is the tendency for Ardour to send a performance patch change out through midi when I open it. The message changes the patch in my performance Studio Set. Very odd, and not constructive. But at this stage I don’t know if it is me, or the Ardour to blame!

My Rig Configuration
I use a Roland FA-08 to play midi info into the USB port of my laptop.
The midi out port of the FA-08 is configured to be a midi thru port, so that midi info from my laptop will go to my Roland 2080 via the FA-08 out (thru) port.
Yes, I have the potential for many more connections – but I’m keeping it simple at the moment.

In Conclusion
I get the unsettled feeling that this aspect of Ardour’s operation has not been fully tested, such is the gravity of this particular bug. therefore expect to come across other bugs, as I work my way through Ardour and its complexities.

Tim Morland
9 July 2021
Tags:
Steps To Reproduce: Save project, reload - check outputs. They will have changed from hardware to Ardour busses
Additional Information: I think I 've covered it pretty well.
System Description
Attached Files:
Notes
(0026043)
x42   
2021-07-09 01:35   
Would you mind elaborating on the following:

> When I reload any of my projects, every one of those midi outputs has been erroneously changed from “Hardware” to “Ardour Busses”

Could you post a screenshot of the mixer window perhaps? What busses are there that receive data from MIDI track?

I cannot reproduce this Ardour retains connections as-is when the session is re-loaded, including direct MIDI outputs of MIDI tracks without synths (using Ardour/ALSA, no jack)

What backend do you use (Ardour Menu > Window > Audio/MIDI Setup)?

> When I pull the USB plug out of the laptop, the need to remain connected to “hardware” is forgotten

This is correct, tracks ouputs should be disconnected, and remain so.

--

PS. MIDI *inputs* however may be directly connected depending on selection. See Preferences > MIDI > MIDI Port config.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8771 [ardour] bugs minor always 2021-07-07 17:09 2021-07-07 17:44
Reporter: filiptw Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot install Ardour 6.8 if the ardour website is open due to fonts being in use
Description: I was just trying to download and install Ardour 6.8, but the installer was hitting an issue writing the new version of ArdourSans and ArdourMono fonts. When I tried to delete them manually, Windows indicated that Firefox has a lock on those files. I suspect the fonts got added to the system path somehow and Firefox used them preferentially over any webfont definitions you have in the website's CSS, but I haven't investigated that far.
Tags:
Steps To Reproduce: Try to install Ardour 6.8 over a previous version of Ardour 6 while having the community.ardour.org website open in Firefox at the same time
Additional Information:
System Description
Attached Files: Screenshot 2021-07-07 180437.png (339,938 bytes) 2021-07-07 17:09
https://tracker.ardour.org/file_download.php?file_id=4083&type=bug
Notes
(0026039)
x42   
2021-07-07 17:36   
(Last edited: 2021-07-07 17:36)
This can happen if Ardour has crashed in the past. The solution is to reboot and then re-install Ardour.

(0026040)
filiptw   
2021-07-07 17:44   
afaict Ardour exited normally after I closed the initial dialog with the prompt to upgrade (though I wasn't running a debug build previously either and so cannot confirm this). what I find odd is that after examining the styles on the download page again I can't find references to ArdourSans and ArdourMono (unless these are renamed ttf files for other fonts) - intriguing...

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8769 [ardour] bugs minor always 2021-07-03 20:00 2021-07-05 16:28
Reporter: mrMute Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI notes drop out when vst automation points are snapped to the same start point.
Description: This happens when using VST3 synths:

When MIDI notes and processor automation are snapped to the same grid lines notes can drop out.

I tested this with U-he Diva and Tal-software synths.

When i try the VST2 versions of the plugin's the notes play as they should.
Tags: Midi, VST3
Steps To Reproduce: Create a MIDI region.

Add a VST3 instrument.

Draw notes.

Draw processor automation and snap the point to the same grid lines.

(see attached screenshot)
Additional Information:
System Description
Attached Files: automation.png (25,966 bytes) 2021-07-03 20:00
https://tracker.ardour.org/file_download.php?file_id=4078&type=bug
png

automation_test_2021-07-05_170220.ardour-session-archive (15,102 bytes) 2021-07-05 15:09
https://tracker.ardour.org/file_download.php?file_id=4079&type=bug
automation-test-tal_2021-07-05_171503.ardour-session-archive (8,170 bytes) 2021-07-05 15:19
https://tracker.ardour.org/file_download.php?file_id=4080&type=bug
Notes
(0026027)
x42   
2021-07-04 22:03   
I just tested that with Diva (1.4.3), automating the "output" volume, and cannot reproduce the issue.

Could you share the .ardour session file? perhaps there is something else that is key here, maybe related to BPM/samplerate (rounding issues)?
(0026028)
mrMute   
2021-07-05 15:09   
Thanks for looking into this.

I didn't keep the previous test session, i was using the new vst3 version of TAL Noisemaker in that one.

I created a new one using Diva and automation for the output parameter. i get stuck notes this time.

I attached an archive of the test session.
(0026029)
mrMute   
2021-07-05 15:19   
Here is a test session using the vst3 version of TAL Noisemaker: https://tal-software.com/products/tal-noisemaker.

In this case notes are dropped. The same thing happens for the other TAL plugins.
(0026030)
x42   
2021-07-05 16:28   
I've mitigated the issue in Ardour 6.8-68-g13f5fb3dee, but the underlying issue cannot be fixed before Ardour 7.0
There are rounding errors when converting music-time (bar/beat) to sample-time which leads to stuck notes, among other issues.

In this case the rounding error coincided with splitting the process cycle to send automation-data to VST3 plugin (process n samples, update parameter, process remaining samples).
VST2 plugins were not affected since VST2-instruments are always called with a fixed buffer-size.

PS. using a sample-rate of 48000 instead of 44100 greatly reduces the likelihood of those rounding errors. which is why I was not able to reproduce this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8767 [ardour] bugs minor always 2021-07-03 03:39 2021-07-03 04:29
Reporter: vivantart Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: The GUI from stack of tracks bugs last track after press the "Z" shortcut
Description: After press Z on a selected track the last one will "ghost" on GUI when scrolling vertically the timeline.
I did test and this occurs in any project.
Tags: ardour6, GUI, shortcuts, timeline, track
Steps To Reproduce: 1) Select a track
2) Press "Z" (Zoom for Selection) shortcut
3) Scroll Ardour vertically
4) Shrink, Expand or reset track height and the bug will disappear
Additional Information: Screen resolution: 1920x1080
Window manager: Kwin
Graphics: Mesa Intel UHD 630
System Description
Attached Files: ardour_00216.png (278,520 bytes) 2021-07-03 04:29
https://tracker.ardour.org/file_download.php?file_id=4074&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8766 [ardour] bugs minor always 2021-07-02 20:28 2021-07-02 20:29
Reporter: gaurangarora Platform: any  
Assigned To: OS: any  
Priority: normal OS Version: any  
Status: new Product Version: 6.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Keyboard shortcuts for Forward/Rewind increase by semitones instead of 50% points in all modes (Fast/Slow/Normal)
Description: In versions prior to 6.7, each press of the transport forward/rewind key shortcuts would change playback speed by 50%.
But in versions, 6.7 and now, 6.8, each press only speeds up by 1 semitone(5.9% on first press, 12.2% on 2nd press and so on), irrespective of whether shortcut is set to use normal, fast or slow actions from Keybindings Window.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: fast or slow rew-fwd.png (52,624 bytes) 2021-07-02 20:28
https://tracker.ardour.org/file_download.php?file_id=4073&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8765 [ardour] bugs minor always 2021-06-30 23:32 2021-07-01 22:48
Reporter: ema87 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 2-screen startup
Description: when you start, the logo appear divided into 2 screens
Tags: 2 screen
Steps To Reproduce: start with 2 screen
Additional Information:
System Description
Attached Files:
Notes
(0026019)
x42   
2021-07-01 02:45   
Which desktop environment do you use? Do you perhaps map 2 screens using xinerama or a seamless option, so an app cannot tell that there are two distinct screens?

PS. Here (debian/buster Xorg/mate) the splash-screen is centered on the screen that the mouse was last on. I regularly use 2 or 3 screens w/o issues.
(0026020)
ema87   
2021-07-01 22:48   
Hi, thanks for your answer.
I just use ubuntu 20.04 and can't resolve it yet

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8551 [ardour] features minor N/A 2021-01-24 13:16 2021-07-01 16:12
Reporter: ekkof Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi overdub/ merge feature
Description: When recording a midi loop it would be very useful to (have the option to) record 'on top' of the midi file; as it is now, a new take/ midi file is generated each time the loop starts over. I'm used to the 'over dub' workflow from cubase and I think it works good in a production/ composing workflow where you want to try out some ideas through 'jamming'. Hope this makes sense.

Best wishes from Denmark - I appreciate Ardour and all the work that went into creating and refining it, and only want to help making it even better ?

Tags: Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8764 [ardour] bugs minor always 2021-06-28 21:30 2021-06-28 23:11
Reporter: mike-overtonedsp Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST3 Plug-In GUIs cannot be resized smaller than the size at the most recent project save
Description: Ardour assumes that the size of a VST3 plug-in GUI window when a project is saved, is the 'default' size e.g. the normal or smallest size the GUI is intended or permitted to be. This means that if you save a project with a VST3 plug-in GUI open, you can never resize the GUI smaller than the last saved size. This is compounded by the fact that Ardour 'hides' rather than closes a UI window when the *close* button is clicked, meaning that even if you 'close' the plug-in GUI, and then resave the session, on next loading and opening the plug-in GUI, the window will still default to the wrong size and it will not be possible to size it smaller.
Tags:
Steps To Reproduce: 1. Open a VST3 plug-in with a resizable UI.
2. Increase the size
3. Save the project / session
4 Re-open the session
5. Try to shrink the UI back to its minimum size.
Additional Information:
System Description
Attached Files:
Notes
(0026017)
x42   
2021-06-28 22:38   
It is plugin and also OS specific. Steinberg's VST Host Checker is not affected by the issue you describe on Linux.
but yes, Ardour's handling of resizable VST3 plugins is incomplete. there is no checkSizeConstraint() support yet.

Until the issue is fixed, you can work-around by using "Edit with generic controls" (processor box context menu) or Alt+double-click. This destroys the custom plugin UI.
(0026018)
mike-overtonedsp   
2021-06-28 23:11   
checkSizeConstrain() is what you need - that should always limit the (requested) UI dimensions to 'safe' minimum or maximum values. The underlying issue might not be a VST3 specific one, though it is Ardour specific.
it appears that VST2 plug-in GUIs also have the same behaviour in Ardour, its just that because of the way live UI sizing is a non-standard VST2 plug-in hack, its possible for the user to override Ardour's behaviour and 'force' the window smaller. It seems as if its actually the size of the window when its first *opened* which Ardour assumes to be the default size. Unfortunately, when a session is saved with the GUI open, the next time it's loaded, Ardour opens the GUI with the saved size, and then this new 'first opened' size becomes the (new) default minimum size etc.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8763 [ardour] bugs minor always 2021-06-27 02:17 2021-06-27 02:17
Reporter: Guillermo Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stretch and crash
Description: When I select a region, stretch it, the program crashes. By the way, thanks for making and sustaining a great piece of software!.
Tags: 6.7
Steps To Reproduce: I am using a laptop HP EliteBook 8470p with 8Gb of ram, i5 processor.
My operating system is Kundor (Ethertics), on Devuan.

I am working on a radio program with more or less 10 tracks, using OGG and WAV sources. There is a piece of music where I want to stretch a chord to twice the duration. So here are my steps:

I cut the moment the chord begins
Select the region to be stretched
Put the mouse on "Stretch" mode
Drag the clip to make the stretch options window appear
With the keyboard, make the stretch value exactly 200%
Push the "stretch/shrink" button
and.... CRASH.
The whole application shuts down.

I tried changing the "contents" selector. Same thing happens
Additional Information: Thank you!
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8681 [ardour] bugs minor random 2021-04-28 14:49 2021-06-26 13:33
Reporter: Mark Richard Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Random frequent crashes when using PulseAudio
Description: A few months ago, I started using PulseAudio as the backend option in Ardour on my system, since it allows me to do some other audio work outside Ardour while editing. Since then, I get frequent crashes (about once every 10-15 minutes). The crash just freezes everything for a half second then closes the editing window, sometimes resulting in lost work if I forgot to save. Prior to this, when using ALSA (and not being able to use any audio outside Ardour) I had never had these same crashes that I can remember.

These crashes seem to be mitigated a bit if I save after every edit made, but that didn't work this most recent time and the crashes came more frequently. After switching back to ALSA backend to complete the most recent edit, I didn't get any crashes (although it was only about 10 more minutes of work.) I attached the information received by following the "gdb" debugging options found on the Ardour website, and searching through that and seeing "pulseaudio" in a lot of places led me to believe that might be the culprit.

For the record, I only use Ardour to do relatively basic editing of podcasts. I have 2-3 tracks between 1 hour and 2 hours long. I mute sections, do some splitting/moving around, and that's about it.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: gdb_ardour-6-6-0-crashoutput.txt (28,663 bytes) 2021-04-28 14:49
https://tracker.ardour.org/file_download.php?file_id=4012&type=bug
ardour.core.info (5,827 bytes) 2021-06-26 13:33
https://tracker.ardour.org/file_download.php?file_id=4072&type=bug
Notes
(0025776)
x42   
2021-04-28 15:10   
This is unrelated to the backend.

It looks like a known bug where ardour fails to create an undo-action when two things happen at the same time.
e.g. you press the mouse to initiate an action, while also pressing some keyboard-shortcut at the same time.

The crash-reports shows keyboard-shorcut -> ... -> try save undo -> crash -- but it is from an optimized builds so the details as to why or where this happens are lost.
(0025778)
Mark Richard   
2021-04-28 21:53   
Ah interesting. So is the "solution" for now to just be careful with how I'm editing? I do have a lot of quick single-key keyboard shortcuts I use while also mousing around a lot.
(0025779)
x42   
2021-04-28 23:45   
perhaps. yes.

The "classic crash" was to start a region-drag and then press "s" - split while dragging some region. That one has been special-cased.
It might be useful if you could catch this crash with a debug-build, or maybe even narrow down and provide a recipe.
(0025780)
Mark Richard   
2021-04-29 15:57   
I'm happy to give it a shot if you can guide me to how to get/run a debug build.
(0026009)
Bruno Unna   
2021-06-26 13:33   
Hi.

I've experienced this problem for a long time, but recently (I think that starting with 6.7) the frequency of it happening has increased substantially, almost to the point of rendering Ardour useless. However, I never thought of associating it with PulseAudio. Will try disabling it.

In my system Ardour crashes dumping a core, which I would attach here if it was not so large (1.6 GB). I can, however, paste the info about the file.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8762 [ardour] features minor N/A 2021-06-25 03:44 2021-06-25 03:46
Reporter: unsafelyhotboots Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mass MIDI note editing via automation lanes
Description: How to implement quick velocity editing in MIDI tracks has been a very heated topic on the forums, and I've come around to the limits of lollipop graphs, as @paul and @x42 have both come out against. So why not instead make a velocity curve lane for MIDI tracks that automatically edits the velocity to the curve. This has several advantages to the lollipop approach:

- You can "write" the function and bind the fader to a knob/fader on a MIDI controller, play through the song, and edit all the velocities in one playthrough of the entire song - potentially for every midi track all at once (therefor creating a "groove"). There is currently no way to bind a MIDI controller in any program that has lollipops type vertical graphs.
- You can use the "touch" function after editing the notes in aggregate to edit individual notes in chords, single notes that you want to fall outside the curve, and then "play" to avoid accidentally touching the velocities of notes.

This approach can be expanded to dragging and rushing notes ahead of/behind the beat, as well as other MIDI properties.
Tags: Editor, features, Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8707 [ardour] features minor N/A 2021-05-17 12:00 2021-06-23 15:45
Reporter: colinf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Implement ripple mode for markers
Description: It could be handy if, when ripple mode is active, moving a marker could move all the following markers too.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8706 [ardour] features minor N/A 2021-05-17 11:59 2021-06-23 15:45
Reporter: colinf Platform:  
Assigned To: paul OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow simultaneous drag of selected markers & regions
Description: It's already possible to select multiple markers (via the usual <Ctrl>+click/<Shift>+click actions), and all the selected markers can be moved together. Moreover, it's possible to select both markers and regions simultaneously. However, dragging a selected marker or region when the selection contains both types of objects doesn't move all the selected objects, but only those of the same type as the one being dragged.

It could be useful if dragging a region or marker when both types of objects are selected moved all the selected objects.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025923)
paul   
2021-06-03 15:40   
There's a bigger issue here, which is how to select and move "everything" in a given section of the timeline (markers, tempo, meter, automation, audio, MIDI) ... we don't have a clear, solid idea on the best approach to this so far.
(0025924)
colinf   
2021-06-03 22:38   
A "move everything" would be a marvellous thing, but even without that, I think a "move all selected things, whether regions or markers" could be useful.

There's definitely a question about what should happen when moving a selection containing a mixture of items whose position is specified in samples and ones whose position is in musical time when there are tempo or meter changes, but that would apply equally to "move everything" and "move selection", unless the selection is only ever allowed to contain items with one or other type of position.
(0025998)
paul   
2021-06-22 21:56   
region+marker drag in Ripple All edit mode is now implemented in the new-ripple-arch branch.
(0026002)
colinf   
2021-06-23 15:45   
I haven't tried the new-ripple-arch branch yet, so maybe it works like I hoped already, but the idea was really orthogonal to slide/ripple/ripple all edit modes. What I envisaged was that regardless of the edit mode, if there were both markers and regions selected, that moving a selected marker by dragging it would also move the selected regions by the same amount (and/or vice versa).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8693 [ardour] other minor always 2021-05-07 07:23 2021-06-22 21:55
Reporter: Micaguay Platform: Linunx  
Assigned To: OS: UbuntuStudio  
Priority: normal OS Version: 20.04.1 TLS  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: USABILITY - LOW PRIORITY (Master "Track or Strip" in Editor disappear when you scroll down)
Description: When you are in EDITORs mode, if you scroll down a lot, you don't have access to Master Strip anymore.
Tags:
Steps To Reproduce: Create a lot of track
Scroll down
Master Strip goes out of the sight, you are obliged to scroll up a lot, or go to Mixer to access Master.
Additional Information:
System Description
Attached Files: master-strip-goes-away-sticky-it.png (96,088 bytes) 2021-05-07 07:23
https://tracker.ardour.org/file_download.php?file_id=4020&type=bug
png
Notes
(0025997)
paul   
2021-06-22 21:55   
The master is typically not of much importance in the Editor window, since it rarely has any data (automation) to be edited). Just use Alt-m to switch to the mixer view, adjust, then Alt-m to switch back.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8752 [ardour] bugs minor always 2021-06-19 18:25 2021-06-22 21:50
Reporter: jumase Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: In fullscreen mode, renaming tracks cause Editor window to hide under other windows.
Description: When working in fullscreen Editor, editing track(s) name(s) cause other open windows (another program) to "pop up" and the rename box is displayed above such window. It's not actually pop up, but it feels like that, because you want to see the rename box in place over the Editor, not over another application. I attach a screenshot of a track name box in top of the file manager.

(using version from ardour.org)
Tags:
Steps To Reproduce: 1. You must have another window open (not iconified); let's say a file manager (or it could also be the Ardour mixer detached).
2. In Editor fullscreen view, rename any track.
3. It will display only the text box above the window opened in step 1.
4. Problem arises when wanting to rename several tracks by pressing tab, as you loose focus on Ardour and tab has effect on the current window (in the example I used: the file manager).
Additional Information: I don't know if this is a window manager issue. I tried checking and unchecking the quirks preferences in Ardour but no combination succeded. I also tried changing relevant XFCE settings but the issue is still there.

Could one possible solution be setting the "renaming box window" the same type as, for example, the plugin window? Because plugin windows behave well in this context.

xprop output from a plugin GUI

_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY

xprop output from rename box

_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK
_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_POPUP_MENU
System Description
Attached Files: screenshot.png (6,588 bytes) 2021-06-19 18:25
https://tracker.ardour.org/file_download.php?file_id=4067&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8599 [ardour] bugs minor always 2021-03-02 09:22 2021-06-22 16:56
Reporter: aggraef Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Push 2 not working properly in Ardour
Description: First, congrats for the new release, Ardour has really come a long way! I'm having a few issues with the Push 2 support, though. This is using a fairly new Push 2, updated to the latest firmware, working fine in both Ableton Live on Windows and Bitwig Studio on Linux.

- All or some of the buttons (i.e., the ones that are supposed to light up because they are supported in Ardour, like Mix, Master, Scale, Play, Record, etc.) refuse to light up in a freshly created minimal Ardour session with just a single MIDI track. The buttons appear to work as described, it's just very hard to find them when they're not lit. ;-)

- This is a minor niggle, but once the buttons do light up, they aren't turned off again when Ardour exits.

I'm also having some issues specifically with the Scale feature. I can select scale and root all right in the Scale menu, but:

- The Scale menu looks garbled at the bottom (it looks like the last row of the mode menu spills over into the bottom row of root keys, see pic 1). (Sorry for the bad picture quality, I just couldn't get my camera to focus properly.)

- The pads don't light up properly (seemingly at random, or not at all, see pic. 2).

- Once the pads are pushed, they often go dark. At times (chromatic mode?), it's just the pad being pushed, other times (in key mode?) other pads go dark as well, apparently at octave distances -- it's as if Ardour tries to mimic Ableton's and Bitwig's behavior of lighting up the same note in different octaves, but the pads just go dark instead.

- When switching away to master or another track and coming back to the MIDI track, sometimes the entire grid remains dark.
Tags: control, surface
Steps To Reproduce: Most of this stuff happens seemingly at random, but I see at least some of it most of the time.

- Create a new Ardour session with just one MIDI track in it and make sure that the Push 2 is enabled as a control surface and connected.

- Do all the buttons supported by Ardour light up?

- Switch to the scale menu. Do you notice the display glitches?

- Select a scale and root. Does the grid light up?

- Start pushing a few pads. Do they go dark?

- Switch to master and then back to the MIDI track. Is the grid still lit up properly?
Additional Information:
System Description
Attached Files: Ardour-Push2-ScaleMenu.png (494,810 bytes) 2021-03-02 09:22
https://tracker.ardour.org/file_download.php?file_id=3959&type=bug
Ardour-Push2.png (381,145 bytes) 2021-03-02 09:22
https://tracker.ardour.org/file_download.php?file_id=3960&type=bug
Notes
(0025577)
aggraef   
2021-03-02 09:45   
One more thing that I forgot: dB meters are sometimes missing on audio tracks (both in global and track mix view).
(0025968)
paul   
2021-06-18 22:51   
Sorry for missing this when you reported it.

I just tried here with current Ardour (note: the code to support the Push2 has not changed in a long time), and it works fine.

I'm wondering if there was some firmware revision and you have a newer Push2 (effectively). I've had mine since right after they came out.
(0025971)
drobilla   
2021-06-19 17:00   
I have seen some sporadic sketchiness, but not very often. I suspect it's some kind of deeper USB/IPC/etc thing. Which backend are you using?

The scale menu thing is just a straightforward rendering bug and unrelated to the more general sketchiness, I've already fixed it (in a branch).
(0025980)
aggraef   
2021-06-21 05:02   
Paul, this is quite likely. I was running the latest firmware (at least at the time I reported the issue).

Dave, I'm not sure what you mean by backend, but I was running this on a Manjaro (Arch-based) system, fully updated.

FWIW, the same device (with the new firmware) works fine OOTB with Bitwig, as well as Reaper, using Moßgraber's scripts (http://www.mossgrabers.de/Software/Reaper/Reaper.html).

I can try on a different system (Ubuntu MATE 21.04, and even Windows), and see whether that helps. But in the light of Paul's remarks I suspect that it might be an issue with the firmware version.
(0025981)
aggraef   
2021-06-21 05:05   
Correction: Works fine on Bitwig with Moßgraber's scripts (http://www.mossgrabers.de/Software/Bitwig/Bitwig.html), I don't think that I tested with Reaper yet.
(0025990)
drobilla   
2021-06-22 16:56   
I meant "backend" for Ardour, i.e. Jack or Alsa. Only tangentially related, but I feel (if in the vaguest possible way) like I've seen different wonkiness depending.

My Push is also updated to the latest firmware. Also on Manjaro as it happens. I'd wager it's extremely unlikely that there's anything wrong with the device.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8758 [ardour] bugs minor always 2021-06-22 10:27 2021-06-22 10:27
Reporter: krischan941 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Loop Bug
Description: When having Preferences/Transport/Play_loop_is_a_transport_mode enabled and you loop there are some issues.
If the playhead is placed after the loop range and you first click play and then then click L to loop, it plays back the content from playhead position and the loop range simultaneously.

Ardour 6.7.200
Tags:
Steps To Reproduce: 1. set Preferences/Transport/Play_loop_is_a_transport_mode
2. create a loop range
3. place playhead after the loop range
4. press space to play
5. press L to loop
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4634 [ardour] bugs major have not tried 2012-01-15 12:34 2021-06-16 21:54
Reporter: geraldm Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 3.X  
Summary: In splice mode: recorded Midi region gets shifted to playhead position after recording operation
Description: Scenario: Project with one midi track and no regions.
Procedure:
-Playhead (PH) is at time t1
-Arm Midi track (MT)
-Press record and record a tune (Midi Keyboard->a2j->ardour3 MT)
-Notes get recorded, midi region is in place
-Press stop, PH stops rolling, beginning of midi region on MT get immediatly shifted to PH position.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012654)
cth103   
2012-01-25 01:52   
I believe we established that this is because you were in Splice edit mode. Is that right?
(0012656)
geraldm   
2012-01-25 11:14   
Yes. That's right. It works in slide mode.
(0013589)
paul   
2012-06-19 01:54   
splice mode is known to be non-functional under many simple situations as well as more complex ones. removing it from the GUI entirely has been considered.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8746 [ardour] bugs minor sometimes 2021-06-15 21:30 2021-06-16 21:51
Reporter: bluebones Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Transient detection can be fuzzy sometimes
Description: Long story short whenever I press ctrl+arrow keys I cannot be completely sure the program is correctly detecting the transient. I usually check visually and most times it makes sense with the waveform and with the audio, but then I find situations like the pic attached, a transient "detected" clearly way past the right spot, this is an extreme case that got me to report here, but I often find situations in between, a transient that is detected just a little bit before or after what could appear and sound as the right place... and then I get stressed out about the whole track having been cut wrong x (

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: transient pic.png (34,491 bytes) 2021-06-15 21:30
https://tracker.ardour.org/file_download.php?file_id=4066&type=bug
png
Notes
(0025962)
x42   
2021-06-16 04:05   
> a transient that is detected just a little bit before

That is intentional. The default is to find the transient and the rewind 64 samples (or whatever the default fade shape is set to).

When splitting regions at transients it is preferable to retain a bit of context (and then x-fade).
(0025965)
bluebones   
2021-06-16 21:51   
Thanks for the reply, yes I understand that, but I mean a bit that is more than what it is context for the fade, and I say so by the comparison with other detections that are just fine. Anyhow from my experience detection just seems unconsistent, sometimes is here sometimes is there... while visual representation on the contrary seems to be representing the waves right from what I can hear.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8463 [ardour] bugs minor always 2020-10-30 08:49 2021-06-16 21:35
Reporter: rozea Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi recordings from external midi keyboard gets lost when JACK Transport is the time master
Description: Midi recordings from external midi keyboard gets lost when JACK Transport is the time master

Everything looks normal until you hit stop recording, then all the recorded midi notes are gone and are not played.

I didn't have this issue when JACK Transport wasn't the time master

(Ardour version in Debian (6.3) and git version of 2 days ago)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8748 [ardour] bugs minor random 2021-06-16 15:18 2021-06-16 17:25
Reporter: M.F. Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when switching snapshots
Description: Crash when switching between snapshots

message: SessionName did not load succesfully. Port registration failed.
- error: unable to create port 'LTC in' : failed constructor.

Jack used, when using plain Alsa problem disappeared
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025963)
x42   
2021-06-16 15:37   
Does this always happen, or only with a specific session or snapshot?

1. Create a new session
2. Snapshot (& keep working on current version)
3. Load new snapshot (via Editor's right sidebar)
4. Reload previous snapshot

works fine here. Had to dust off JACK for the test, tried with jackdmp 1.9.17.

If only a specific snapshot causes it, could you attach the .ardour session file?
(0025964)
M.F.   
2021-06-16 17:25   
Had it happen in two different sessions but now I'm not having any crashes at all. I tried those sessions as well created some for test purposes but no issues. Weird.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8732 [ardour] bugs minor always 2021-05-30 13:24 2021-06-15 18:36
Reporter: derwok Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Categorized "Print Bindings" (HTML to Browser) of Keyboard Shortcut is not categorized
Description: The "Categorized" column of generated HTML of Print Bindings is not categorized at all (anymore?).
This makes it identical to the "Alphabetical" column in the HTML
see attached HTML.
This is confusing for users as everything is doubled and wastes a lot of space on print-out.
Tags: shortcuts
Steps To Reproduce: Menu > Window > Keyboard Shortcuts (Alt+K)
then press button "Print Bindings (to your web browser)"
Check generated HTML in browser
Additional Information:
System Description
Attached Files: Ardour_Keybindings.html (120,229 bytes) 2021-05-30 13:24
https://tracker.ardour.org/file_download.php?file_id=4055&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8735 [ardour] bugs minor always 2021-06-07 00:52 2021-06-15 17:28
Reporter: jayache80 Platform: GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Track disk audio delayed after toggling "In" monitoring during loop playback
Description: During loop playback, toggling input monitoring (the "In" button on a track) On and then Off will cause the track's disk audio to be delayed. This delay is compounding; the more "in" button toggles that are performed, the more the disk audio will be delayed.

This occurs only during loop playback. This does not occur during regular playback. Also, the delay will remain only during the loop playback and will immediately go away once the loop playback is stopped.
Tags:
Steps To Reproduce: 1. Have a session with at least one audio track with audio already recorded to disk on that track
2. Create a loop range
3. Start loop playback (by pressing the lowercase "L" keyboard shortcut by default) and leave it playing for the duration of this bug reproduction
4. On the track, monitor the input by pressing the "In" monitoring button On (highlighted yellow) and then Off (no longer highlighted yellow). Do this repeatedly.
5. With the Input monitoring toggled off, observe that the disk audio is now severely delayed during playback
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8744 [ardour] features minor N/A 2021-06-14 12:23 2021-06-14 12:23
Reporter: DonJaime Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Flexible fader size
Description: The fader/meter takes up quite a lot of room in the mixer strip. More and more plugins provide an inline display, so you can end up with a scroll bar in the plugin area without using an excessive number. Allowing the fader to be shrunk would make dragging less accurate, but apart from that the fader would be just as usable.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8724 [ardour] bugs minor random 2021-05-26 04:43 2021-06-14 08:29
Reporter: imstre Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crashed project
Description: yesterday I worked on the project save and closed.
i can't open today, so safe mode.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 2021-05-26_07-42-59.png (26,395 bytes) 2021-05-26 04:43
https://tracker.ardour.org/file_download.php?file_id=4041&type=bug
png

Ardour-6.7.12-crash-1621929473.txt (12,524 bytes) 2021-05-27 06:12
https://tracker.ardour.org/file_download.php?file_id=4042&type=bug
Ardour-6.7.18-crash-1621945453.txt (13,999 bytes) 2021-05-27 06:12
https://tracker.ardour.org/file_download.php?file_id=4043&type=bug
2021-05-29_08-07-49.png (49,848 bytes) 2021-05-29 05:08
https://tracker.ardour.org/file_download.php?file_id=4053&type=bug
png
Notes
(0025893)
x42   
2021-05-26 18:52   
Is there a backtrace in %localappdata%\Ardour6\CrashLog\ ?

Does it happen with new sessions or only the existing one ?
(0025896)
imstre   
2021-05-27 06:12   
this is not a new project but I opened and worked normally.
I closed and then crashed.
whether an error can be corrected?
(0025908)
x42   
2021-05-28 23:49   
Does now always happen, even when you create a new empty project?
(0025909)
x42   
2021-05-28 23:50   
Can you try to delete the file "instant.xml" in the session folder (that saves GUI settings and window sizes), and if that doesn't help remove %localappdata%\Ardour6\instant.xml
(0025910)
imstre   
2021-05-29 05:05   
"Does now always happen, even when you create a new empty project?" - with empty everything is fine.
I delete "instant.xml" there and there but the same mistake, thanks)
(0025916)
x42   
2021-05-30 21:24   
Too bad, I suspected the editor-sidebar, if that is too narrow it could trigger such an exception.

So it seems to be session-specific. Can you upload the session (just the .ardour file)?
(0025961)
imstre   
2021-06-14 08:29   
Ok

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4102 [ardour] features feature N/A 2011-06-09 10:34 2021-06-12 14:06
Reporter: deva Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 3.X  
Summary: Spectrogram view for clips.
Description: A feature I have been considering for a while now is the possibility to view a clip in the frequency domain using a spectrogram view.
It could be configured using the view-mode menu (currently linear/logarithmic).
This would be a great help when performing cutting at the beginning of eg. guitar chord strums, which can be quite hard to see in the time domain.
Also it could be useful when performing manual de-essing.
I imagine the clip looking a bit like this: http://en.wikipedia.org/wiki/File:Spectrogram-19thC.png
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010841)
deva   
2011-06-10 09:04   
It seems others have gotten the same idea as well: http://forum.cockos.com/showthread.php?p=728536
(0018036)
lpirl   
2016-03-03 06:16   
+1 for this one.

It feels like now, that a spectrogram is implemented for the export, the editor supports multiple visualizations already, it can't be too hard to add a spectrogram as well (but maybe it is still very hard and a lot of work :)).

IMHO, this very information-dense view can help editors more easily spot tones, glitches, noises, etc.
Just think of a heavily gained guitar where your waveform basically looks like a plank…
(0018039)
x42   
2016-03-05 14:52   
The spectrogram itself is the easy part (already done in a git branch a while ago: https://github.com/ardour/ardour/tree/spectrowave - hard replaces waveform display)

As usual, GUI integration is the vast majority of work:
- allow to switch wave/spectrum or overlay them
- cache precaluated the spectrum (in memory and on disk)
- calculate display in the background
- maintain a image and spectrum cache - not unlike peak-files
..and all sorts of details and edge cases.

I don't expect this to become part of Ardour anytime soon, but who knows.
(0020047)
UnixMan   
2017-09-28 17:11   
Spectrograms can be very useful. Even more so if also combined with spectral editing, like in e.g. Izotope RX.

A somewhat similar and very nice feature have been recently added to Reaper. Have a look here:

https://www.youtube.com/watch?v=vSBO_VC9q3E

Something like this would be a really, really GREAT feature! ;-)
(0025941)
unfa   
2021-06-12 12:52   
This would be a great aid in editing - some content has waveforms that don't tell you much.
I'm making a tutorial about looping sound effects and some cases really require a spectrogram to let the user make cuts in the right spots.
This is why for some looping work Audacity may actually have an upper hand, even though in most cases I prefer Ardour.
(0025943)
x42   
2021-06-12 13:07   
some references and prototypes:
https://github.com/Ardour/ardour/tree/spectrowave
https://github.com/Ardour/ardour/pull/570
(0025944)
x42   
2021-06-12 13:13   
> This is why for some looping work Audacity may actually have an upper hand

Interesting. Could you explain how it is useful to you when looping?
The more bins a spectrum view has, the more undefined the time-axis becomes, you cannot make precise cuts at all.

What are you looking for in the spectrum to base your decision on? Could that information also displayed or made available otherwise?
(0025946)
unfa   
2021-06-12 13:41   
x42: Let me record a quick video for you about this.
(0025947)
unfa   
2021-06-12 14:06   
Here it is: https://youtu.be/Xh3f6wXy9b8

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7786 [ardour] bugs minor always 2019-08-13 11:50 2021-06-12 13:22
Reporter: tomade Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Duplicate Region - Fill Track" does not align exactly at beat raster
Description: Hi

when using the duplicate region -> fill track tool and the region has an exact length of a beat, the fill track tool leads to an error in position of the duplicates (see picture). The duplicated regions are not aligned to the beat raster anymore. This error is accumulative. The longer the track the bigger the error.

Kind regards!
tom
Tags: fill track
Steps To Reproduce: see description
Additional Information:
System Description
Attached Files: Bildschirmfoto von 2019-08-13 13-49-34.png (197,088 bytes) 2019-08-13 11:50
https://tracker.ardour.org/file_download.php?file_id=3461&type=bug
png

ardour_midi_not_in_grid.png (146,047 bytes) 2020-09-23 14:08
https://tracker.ardour.org/file_download.php?file_id=3839&type=bug
png
Notes
(0020736)
x42   
2019-08-24 02:42   
NIce example!

This depends on BPM and sample-rate.

Audio-region duration is counted in audio-samples and currently limited to that unit.

One beat at 44.1kHz, 127 BPM is 44100 [samples/sec] * 60 [sec/min] / 127 [beats/min] = 20834.64 [samples/beat].
There are no fractional audio-samples, so Ardour rounds this down. Hence every time the region is duplicated, 0.64 samples are lost compared to the beat-grid.

Fixing this requires various parts that are planned for Ardour 7 (some preparations are in the nutempo git branch). e.g. the region duration needs to be set in music time -- exactly to 1 beat (not 20834 samples).
(0025052)
consint   
2020-09-23 14:08   
I have the same error with midi regions in Ardour 6.3.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8739 [ardour] features minor always 2021-06-09 20:54 2021-06-09 21:59
Reporter: unsafelyhotboots Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature: Make selected MIDI notes more clearly visible
Description: This was brought up here
https://discourse.ardour.org/t/selected-midi-notes-outline-thickness/106055/6
In general, especially on larger, high resolution displays, the outline on MIDI notes is not very significant - a color change to indicate selection, or a thicker outline would make it clearer that these notes are being selected.
Tags: Editor, features, Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025939)
mikelupe   
2021-06-09 21:59   
Yes please.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8688 [ardour] bugs minor have not tried 2021-05-05 11:08 2021-06-06 23:07
Reporter: unfa Platform:  
Assigned To: x42 OS:  
Priority: normal OS Version:  
Status: feedback Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ripple edit: Disappearing edits, invisible regions
Description: I'm using 6.6.410.

When recording and editing voice recordings I uses Ripple mode for some time.
After a while I've noticed strange behaviour and finally a region that was played back in empty space but draw in another place.
After restarting Ardour the region was visible where I've previously hear it's audio (even though the track was empty on that part of timeline).

The problems persisted even when I switched back to Slide mode.

I yet again have to go back to 6.5, because 6.6 is rendering my work way harder than it needs to be.
Tags: editing
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025793)
x42   
2021-05-07 04:36   
does the problem still exist in 6.6-436 was it also present in 6.6?

if so, do you have a recipe how to reproduce it?
(0025797)
PatienceAllergy   
2021-05-07 15:28   
Just wanted to mention I've been having this issue too. Using 6.6-410 on Windows 10, I'll upgrade to 436 and see what happens.
(0025799)
PatienceAllergy   
2021-05-07 18:09   
yep, still happens in 6.6-436 on Windows 10
(0025801)
x42   
2021-05-08 00:09   
How can you reproduce this issue?
Can you provide step by step instructions starting with a new session?
(0025807)
PatienceAllergy   
2021-05-08 10:35   
v6.6.456 has not fixed this. I can't determine an exact recipe to reproduce the issue, however, editing region lengths then zooming out has triggered it several times for me.
(0025817)
unfa   
2021-05-12 11:30   
Here's a video demonstrating the problem:
https://youtu.be/JbosJaO4rKc

For me the problem started after I've used Ripple Edit for a while to cut out parts of regions and slide them around.

After that something has been broken in my session ever since and whenever I open it in Ardour 6.6 - some regions have an offset between where they play sound on the timeline, and where they are drawn on the timeline.
When I load the session again in Ardour 6.5 it's fine.
(0025818)
unfa   
2021-05-12 11:31   
Let me add: the region shown the video has actually been recorded way after I stopped using Ripple edit, but it's affected by this problem.
(0025820)
unfa   
2021-05-12 11:42   
Since Ardour 6.6 crashed on exporting this session I'm back to 6.5 and I can confirm that the region is visually located where it is played sound in Ardour 6.6.
So the only thing out of place is visual position of the region in Ardour 6.6.
oh, and the exprot crashing:

saved state in 1260.8 ms
  PBD::stacktrace(std::ostream&, int)
  ARDOUR::Session::realtime_stop(bool, bool)
  ARDOUR::Session::pre_export()
  ARDOUR::Session::start_audio_export(long, bool, bool)
  ARDOUR::ExportHandler::start_timespan()
  ARDOUR::ExportHandler::do_export()
  /opt/Ardour-6.6.479-dbg/bin/ardour-6.6.479(+0xa7b086) [0x555555e7b086]
  /opt/Ardour-6.6.479-dbg/bin/ardour-6.6.479(+0xa826fc) [0x555555e826fc]
  /opt/Ardour-6.6.479-dbg/bin/ardour-6.6.479(+0xa81b0c) [0x555555e81b0c]
  /opt/Ardour-6.6.479-dbg/bin/ardour-6.6.479(+0xa8125f) [0x555555e8125f]
  Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*)
  g_closure_invoke
  /opt/Ardour-6.6.479-dbg/lib/libgobject-2.0.so.0(+0x2101b) [0x7ffff324201b]
  g_signal_emit_valist
  g_signal_emit
  /opt/Ardour-6.6.479-dbg/lib/libgtk-x11-2.0.so.0(+0x9ed82) [0x7ffff242dd82]
  /opt/Ardour-6.6.479-dbg/lib/libgobject-2.0.so.0(+0xfb74) [0x7ffff3230b74]
  g_signal_emit_valist
  g_signal_emit
  gtk_button_released
  /opt/Ardour-6.6.479-dbg/lib/libgtk-x11-2.0.so.0(+0x9d059) [0x7ffff242c059]
  /opt/Ardour-6.6.479-dbg/lib/libgtk-x11-2.0.so.0(+0x185cac) [0x7ffff2514cac]
  g_closure_invoke
  /opt/Ardour-6.6.479-dbg/lib/libgobject-2.0.so.0(+0x215a0) [0x7ffff32425a0]
  g_signal_emit_valist
  g_signal_emit
  /opt/Ardour-6.6.479-dbg/lib/libgtk-x11-2.0.so.0(+0x30a64c) [0x7ffff269964c]
  gtk_propagate_event
  gtk_main_do_event
  /opt/Ardour-6.6.479-dbg/lib/libgdk-x11-2.0.so.0(+0x6fb4c) [0x7ffff212fb4c]
[New Thread 0x7fffc9b27640 (LWP 29801)]
ardour-6.6.479: ../libs/ardour/session_transport.cc:1810: void ARDOUR::Session::xrun_recovery(): Assertion `realtime_export ()' failed.
--Type <RET> for more, q to quit, c to continue without paging--
Thread 36 "audioengine" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffca1bc640 (LWP 16995)]
0x00007fffecb96ef5 in raise () from /usr/lib/libc.so.6
(gdb) quit
(0025821)
x42   
2021-05-12 14:26   
> void ARDOUR::Session::xrun_recovery(): Assertion `realtime_export ()' failed.


An x-run occurred while running as freewheel. That should be impossible. Are you using JACK?
It is only however only an assertion. Optimized builds will ignore this.
(0025822)
x42   
2021-05-12 14:27   
> So the only thing out of place is visual position of the region in Ardour 6.6.

I have not been able to reproduce this. Can you send a session where the region position differs when its is loaded in v6.5.0 vs v6.6.489? Thanks.
(0025823)
x42   
2021-05-12 14:40   
> Here's a video demonstrating the problem: https://youtu.be/JbosJaO4rKc

What happens at 0:25 are you using undo?
(0025824)
x42   
2021-05-12 17:28   
Another shot in the dark, could you try if the issue is still present in 6.6.492?

That fixes an potential issue when a 2nd ripple edit is started while Ardour is still busy updating buffers for the prior ripple edit.
This can happen with slow disks or with many regions
(0025851)
krabador   
2021-05-14 19:41   
it seems isn't present on 6.6-504-g4d269729b1
(0025926)
paul   
2021-06-06 23:07   
just sending this as a check on modified mantis email function

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8095 [ardour] bugs minor always 2020-05-08 10:08 2021-06-06 10:06
Reporter: rozea Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 6.0-pre1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour doesn't change tempo via ableton-link / jack_link
Description: Ardour doesn't change tempo via ableton-link / jack_link

Ardour is set to JACK Transport and all three of the 'active commands' are enabled (allow change tempo etc.)

Supercollider does change tempo set by jack_link
Tags: ableton link, jack, transport
Steps To Reproduce: Ardour is set to JACK Transport and all three of the 'active commands' are enabled (allow change tempo etc.)


Use jack_link: https://github.com/rncbc/jack_link

start

tempo 100

tempo 120

etc.
Additional Information:
System Description
Attached Files:
Notes
(0024098)
x42   
2020-05-08 12:31   
Abelton Link is not really applicable, since Ardour has a tempo-map on a global timeline.

Link defines a current tempo, regardless of the position. It may be useful for clip-launching, but it's conceptually at odds with Ardours timeline approach.
(0024101)
rozea   
2020-05-08 13:04   
It may not be the perfect world combination, but it was really easy to sync ardour with supercollider using jack_link. Supercollider doesn't support jack transport, but via ableton-/jack_link it is possible now.

I think it could be useful to combine the Ardours timeline approach way of composing and syncing with supercollider for instance, with all its random and what not possibilities.

It would be nice if tempo changes could work too, but it seems Ardour6 doesn't respond to jack_transport time changes either.
(0024105)
x42   
2020-05-08 14:33   
Correct. Ardour has an internal tempo-map. A fixed score with tempo and time-signature markings for a given time.

It is not a performance tool (like supercollider) that receives such information, but rather a conductor that provides it. Ardour can be jack timebase-master: Convert a given timecode (min|sec) into music-time (bar beat). but not the other way around.

Instant values would only make sense when Ardour adds support for clip-launching independently of the timeline.
(0025925)
rozea   
2021-06-06 10:06   
fyi ProTools has Link support now:
https://cdm.link/2021/06/all-versions-of-pro-tools-now-support-ableton-link/

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8734 [ardour] bugs minor random 2021-06-01 19:51 2021-06-01 19:51
Reporter: DonJaime Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Editing tempo map cumbersome and unpredictable
Description: Often changing a tempo changes the preceding tempo, even when the tempo does not continue.
Locking a tempo to audio changes the end tempo of the preceding tempo to the starting tempo of the new one.
Setting a tempo to continuous and editing it by grabbing the grid makes it ramp. It's quite likely to change the final tempo of the previous tempo, too.
Tags:
Steps To Reproduce: Try to make a tempo map based on recorded audio.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8733 [ardour] bugs minor always 2021-05-31 18:16 2021-05-31 23:28
Reporter: fosskers Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Video encoding fails / is incomplete if video is offset
Description: I have recorded myself in Ardour and taken a video via my phone, then synced the two within Ardour. Playback within Ardour and usage of the video monitor work flawlessly. However, when I try to export video, the bar never gets to the end, and when playing the file in an external player (mplayer) the video freezes near the end and warns:

"Possibly bad interleaving detected."

Through testing I've noticed:

1. If I extend END, the video freezing point extends a bit too.
2. If I extend END past the end of the Video Timeline, video export completely fails.
3. It doesn't seem to matter which output format I use.
4. If I open Ardour via the command line and tell the exporter to show me ffmpeg's output, nothing looks amiss there.
5. I don't think I'm having any resource exhaustion problems.

I've attached some images to show how my tracks are set up.

Thanks for any help you can offer.
Tags:
Steps To Reproduce: 1. Open a new Session with the Recording template.
2. Add an audio track.
3. Import a video file with the default settings.
4. Set START somewhere after the beginning of the video.
5. Set END somewhere before the end of the video.
6. Export the Video using the mp4 preset and default settings.
7. Notice the "Exporting Video" bar doesn't make it to the end.
8. Verify in an external player that the video freezes before the end.
Additional Information:
System Description
Attached Files: start.png (116,698 bytes) 2021-05-31 18:16
https://tracker.ardour.org/file_download.php?file_id=4056&type=bug
png

end.png (84,785 bytes) 2021-05-31 18:16
https://tracker.ardour.org/file_download.php?file_id=4057&type=bug
png
Notes
(0025918)
fosskers   
2021-05-31 18:20   
The part of the issue title that says "if video is offset" was my first pass at the issue. I took too long to write it out and the tracker booted me out. Either way, after more testing, the offsetting of the video doesn't seem to affect the result. The main symptom is the video encoding failing a fixed distance from the END marker. Extending it extends the failure point, but not past the end of the video, since in that case the export fails entirely.
(0025919)
x42   
2021-05-31 18:27   
Is this Ardour from ardour.org with the video-tools from ardour (ffmpeg 3.4.5)?

There have recently been similar reports from distro users that use ffmpeg 4.x. The new ffmpeg changed command-line arguments in incompatible ways and offsets are ignored.
In this case best export audio only and use some other software to mux it with the original video.
(0025920)
fosskers   
2021-05-31 19:07   
I'm on ffmpeg 4.4, yeah. Okay, I'll try what you suggest.
(0025921)
fosskers   
2021-05-31 23:28   
Given that 3.4.5 was released two years ago, is upgrading to 4.x on the Ardour roadmap?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8332 [ardour] features minor N/A 2020-07-25 15:29 2021-05-31 14:11
Reporter: DopplerNyquist Platform: Linux  
Assigned To: OS: LMDE - Linux Mint Debian Edition  
Priority: normal OS Version: 4  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Extend the "Draw 'flat' buttons" option to dialog windows.
Description: I'm using Ardour 6.2 official build in LMDE that uses the Cinnamon desktop. It run and looks almost perfect in this environment. I just miss the option to make all the windows use the option "Draw 'flat' buttons" - I mean, the Export dialog window or the Preferences window. If it is possible to do, please, implement this.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot from 2020-07-25 12-21-33.png (169,528 bytes) 2020-07-25 15:29
https://tracker.ardour.org/file_download.php?file_id=3785&type=bug
png

Screenshot from 2020-07-25 12-23-38.png (157,848 bytes) 2020-07-25 15:29
https://tracker.ardour.org/file_download.php?file_id=3786&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8730 [ardour] bugs minor always 2021-05-29 06:45 2021-05-30 04:11
Reporter: garyd Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 7.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Fatal Error when selecting routes via Lua
Description: Mixbus32c v7.0 and Ardour v6.7

Using the script in Steps below causes a Fatal Error crash saying "programming error: unknown selectable type passed to Selection:add()".

According to the manual’s Lua class reference, RouteTimeAxisView is a RouteUI which is a Selectable which is what set_selection() requires. So this error was unexpected.

Robin Gareus commented that the script looks correct, which suggests that this is a bug in Ardour.

I also tried with the "ArdourUI.SelectionOp.Add" parameter value which had the same result, only this time the error message said "Add()" instead of "add()".
Tags:
Steps To Reproduce: In the Lua script window...

local r = Session:route_by_name(“route name here”)
local rtav = Editort:rtav_from_route(r)
local sl = ArdourUI.SelectionList()
sl:push_back(rtav)
Editor:set_selection(sl, ArdourUI.SelectionOp.Set)
Additional Information:
System Description
Attached Files:
Notes
(0025912)
garyd   
2021-05-30 04:11   
A further comment from Robin in the discourse topic...

"I just realized that Editor:set_selection is exclusively for items that are only visible on the editor-timeline.
Track/Bus selection is synced with the Mixer and control-surfaces.
It is not currently possible to select track from Lua scripts, and there are some technical issues with exposing that API."

So, not a bug after all by the sounds of it.

P.S. The script has a typo - "Editort" - here and in the discourse topic. It was not the cause of the problem.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8608 [ardour] bugs minor always 2021-03-06 15:04 2021-05-29 11:34
Reporter: surfinspots Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Looping and overdubbing ? section isnt playable until it's been made smaller
Description: When overdubbing while playing a loop and stacking the recordings the last top layer of recordings dont play. The recoded area has to be made smaller in order to play correctly
Tags: 6.5, loop, record
Steps To Reproduce: How to reproduce:
- choose region to loop (5s for example)
- record from audio interface into this section and let overdub (or layering the recordings)
- use the top one and remove the underlaying
- it's not possible to play through the recording or play it in loop (you will hear chunks of the content)
- then use the grab tool and try to grab the end of the recording. The recording section now jumps back a few pixels. The recording section is now
smaller than the original one.
- now it should play through
Additional Information:
System Description
Attached Files: ardour-bug.png (7,802 bytes) 2021-03-06 15:04
https://tracker.ardour.org/file_download.php?file_id=3966&type=bug
png

ardur-bug-full-recording-section.png (8,784 bytes) 2021-03-06 15:08
https://tracker.ardour.org/file_download.php?file_id=3967&type=bug
png
Notes
(0025593)
surfinspots   
2021-03-06 15:05   
The screenshot shows the already small recording which is now playable. You also see the looping section markers at the top
(0025594)
surfinspots   
2021-03-06 15:08   
So looks the unaltered recording section

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8728 [ardour] bugs minor always 2021-05-28 10:09 2021-05-28 10:20
Reporter: saltedcoffee Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Region color follows track color" doesn't work properly in one specific scenario
Description: When "Region color follows track color" is disabled and at the same time "Use name highlight bars in region displays" (both settings are in Preferences > Appearance > Editor) is enabled, region color still follows track color upon e.g. opening a session. The setting is only correctly respected after selecting and deselecting all regions at least once.
Tags:
Steps To Reproduce: 1. Make sure Preferences > Appearance > Editor > Region color follows track color is unticked.
2. Make sure Preferences > Appearance > Editor > Use name highlight bars in region displays (requires a restart) is ticked.
3. Open a session.
4. Watch region color still following track color despite the option being disabled.
5. Go to Edit > Select > Select All Objects.
6. Go to Edit > Select > Deselect All.
7. Watch region color not following track color anymore (and thus being displayed correctly).
Additional Information: This is not a new bug in Ardour 6.7. I just didn't have the time to report this earlier (and granted, it wasn't that important to me). It's hard to remember, but I think I first saw this in Ardour 6.0, This version introduced some kind of new color rendering resulting in very poor contrast between the region waveform and the region background, a problem that I reported here: https://discourse.ardour.org/t/waveform-color-in-ardour-6/103695. Ever since this UI change where the waveforms would get tinted despite their color being set to plain white in the theme settings, I use Ardour with "Region color follows track color" disabled because this basically fixed the problem. The name highlight bars are actually very useful because with these, the region name never covers up the waveform. But, as described above, it results in the odd behavior of region color suddely reappearing before selecting anything. I don't know whether this bug is macOS exclusive or whether it can be reproduced under Windows and/or Linux as well.
System Description
Attached Files:
Notes
(0025904)
saltedcoffee   
2021-05-28 10:20   
As an additional observation: You don't have to select all regions at once to make the region color disappear. You can also select and deselect individual regions. In this case, only the regions that got selected at least once are correctly rendered whereas the other ones don't.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8488 [ardour] features minor always 2020-12-07 11:25 2021-05-28 09:19
Reporter: gnzg Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Region Transparency
Description: (using i3wm)

When moving or dragging a region on top of another, there is a "transparency" effect which allows you to see whatever region's underneath

This is a great feature to simplify editing !

I think it could be expanded a little further by activating this feature when editing a region's fade-in/out, this would make crossfading two regions on the same track much more easy
(a relatively simple workaround is to drag the region on a track just below to set the crossfade and then you can just put the region back into its original track, but this isn't as practical or intuitive imo)

Alternatively, Ableton, Reapers and others have a thing where dragging a fade from one object/region to another automatically turns it into a common crossfade for both objects, which is really neat but probably more complex to implement)

Tags: fades, region, transparency
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025292)
jumase   
2020-12-07 18:31   
Nice feature request, I think it can be useful when working with "overlaid layers" just to adjust/correct something.

I just would like to add two comments:

Have you tried the "stacked layers" view for those edits?
See https://manual.ardour.org/working-with-tracks/controlling-track-appearance/layering-display/

Also have in mind that "region fades are crossfades" so you don't need to adjust the two fades, just the one of the topmost region. (https://manual.ardour.org/editing-and-arranging/create-region-fades-and-crossfades/)

Hope this helps and I think the original request is still valid.
(0025293)
mpk   
2020-12-08 13:55   
You can achieve this by adjusting the transparency of "opaque region base" in Preferences > Appearance > Colors > Transparency.
(0025903)
saltedcoffee   
2021-05-28 09:19   
+1 for automatic transparency when editing region fades

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8726 [ardour] bugs minor always 2021-05-27 13:44 2021-05-27 17:09
Reporter: spoontex Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: x42 comp x42 eq crash
Description: Sometimes when I try to insert de x42 comp or x42 eq plugin ardour crashes. I attach a bug report.

Tags:
Steps To Reproduce: Open Ardour.

- Insert x42 Instrument Tuner
- Insert x42 comp, open and crash
Additional Information:
System Description
Attached Files: dump.txt (6,150 bytes) 2021-05-27 13:44
https://tracker.ardour.org/file_download.php?file_id=4046&type=bug
dump2.txt (37,874 bytes) 2021-05-27 13:48
https://tracker.ardour.org/file_download.php?file_id=4047&type=bug
dump3.txt (29,950 bytes) 2021-05-27 16:53
https://tracker.ardour.org/file_download.php?file_id=4048&type=bug
Notes
(0025897)
x42   
2021-05-27 14:27   
Looks like an issue with your openGL system setup issue on your system:

The first crash report is caused in /usr/lib/x86_64-linux-gnu/dri/amdgpu_dri.so (distro provided), while the second one references amdgpu-pro in a different location:

```
0000001 0x00007fff6822b0b3 in () at /opt/amdgpu-pro/lib/x86_64-linux-gnu/libGL.so.1
#2 0x00007fff6822b958 in AGER_Reloc2ICD () at /opt/amdgpu-pro/lib/x86_64-linux-gnu/libGL.so.1
#3 0x00007fff6825ca39 in glXMakeCurrentReadSGI () at /opt/amdgpu-pro/lib/x86_64-linux-gnu/libGL.so.1
```

--

There is a related know issue: Crashes when one opens multiple plugin windows using nvidia graphics cards and the free-software nouveau driver. That driver limits every app to have at one most openGL window.
The solution there is to use the nvidia binary driver (or only use one plugin UI at a time).

I'm not sure if this is related to your issue but it may be something to investigate.
(0025898)
spoontex   
2021-05-27 16:48   
But my graphics card is an AMD with AMD drivers, not nvidia. And only happens sometimes...
(0025899)
spoontex   
2021-05-27 16:53   
Just now crashed without loading any plugin, only a new and fresh project...
(0025900)
x42   
2021-05-27 17:09   
> But my graphics card is an AMD with AMD drivers, not nvidia

This is why I said it is a **related** issue.

Still`glXMakeCurrent` is also where things go wrong with nouveau as soon as two different windows request the GL context. They optimized for single window games (and never supported multi-window applications).
Maybe AMD followed them..?

PS. dump3.txt looks like a complete unrelated issue. Some Region Drag/Drop?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8719 [ardour] bugs minor always 2021-05-22 20:02 2021-05-26 18:50
Reporter: cellofellow Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: FaderPort v2 Encoder Knob Inconsistent and Crash
Description: I just got a PreSonus Faderport v2. Updated it to firmware version 3.44. Generally the encoder knob is very buggy, selecting modes (Pan, Channel, Scroll) usually only works once and then the knob either works for a few seconds or, in the case of Scroll (NavPan), Ardour crashes entirely. The FaderPort will often get into a bad state where even basic controls like the transport buttons stop working.

Observed behavior on versions 6.6 and 6.7 @ d703079f10. Removing a call to abort() in the faderport8 actions code stopped the crashing but it is otherwise still broken.
Tags:
Steps To Reproduce: * Connect FaderPort v2
* Make sure the FaderPort is actually working at all, may require restarting and reconnecting it a couple of times.
* Select [Scroll] mode for the rotary encoder.
* Turn the encoder.
* [Crash]

Also observe other modes of the encoder don't work consistently. Pan might work for a split second, enough to move the pan to 51L49R and be done. Channel might work once.
Additional Information: rgareus on IRC helped me get the stack trace and patch the abort() call out
System Description
Attached Files: ardour6.7-stacktrace-2021-05-21T20:25:00-06:00.txt (52,915 bytes) 2021-05-22 20:02
https://tracker.ardour.org/file_download.php?file_id=4039&type=bug
0001-remove-abort-in-navknob-handler.patch (647 bytes) 2021-05-22 20:02
https://tracker.ardour.org/file_download.php?file_id=4040&type=bug
Notes
(0025889)
cellofellow   
2021-05-25 03:04   
I forgot to mention that the FaderPort would refuse to work at all while using Ardour with straight ALSA backend, and with real JACK. It would sort of kinda work with Pipewire (0.3.28), having the LD_LIBRARY_PATH pointing to the Pipewire jack-compat libraries.
(0025892)
cellofellow   
2021-05-26 18:50   
As an update, and I apologize for this, I've returned my FaderPort to Sweetwater for a Behringer X-Touch One. So, I won't be able to help further debug and test on this. I decided I wanted a unit that I was pretty sure would work. And the Behringer is a bit cheaper anyway, and has displays. If the team needs help getting a FaderPort for further development, I might be able to pitch in.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8722 [ardour] features minor have not tried 2021-05-24 16:51 2021-05-24 16:51
Reporter: unsafelyhotboots Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Adding hotkeys to the mouse-over tooltips
Description: This one feature would speed up the learning curve for first-time users to have the keybinding visible in the mouse-over tooltips.
Tags: UX, workflow
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8720 [ardour] bugs minor always 2021-05-22 21:21 2021-05-22 21:21
Reporter: marrs Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Disabling a track does not disable its external plugins
Description: My external DSP card (a UAD Apollo) has a setting to disable its plugins when it detects that they are disabled in the DAW. This allows a user to free up resources on the Apollo that aren't actually being used. I use this feature to get more mileage out of the Apollo by mixing down a track that I've finished processing and then disabling the track. It seems to me that disabling the track ought to disable its plugins but apparently it doesn't. I have to manually disable or bypass the track's plugins individually, *then* they will be freed by the Apollo.

I'm filing this as a bug report, rather than a feature request, as it seems to me self evident that the effect of "disabling" a track should be that its constituent components will also be "disabled".
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8716 [ardour] bugs minor always 2021-05-22 07:37 2021-05-22 15:50
Reporter: imstre Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crashes when i want
Description: Crashes when i want to Gui and Font scaling
Crashes when i want to freeze audio track
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 2021-05-22_10-44-14.png (63,782 bytes) 2021-05-22 07:45
https://tracker.ardour.org/file_download.php?file_id=4034&type=bug
png

A6-Scaling.jpg (86,814 bytes) 2021-05-22 14:49
https://tracker.ardour.org/file_download.php?file_id=4035&type=bug
jpg
Notes
(0025879)
x42   
2021-05-22 14:49   
can you check if setting windows to scale helps (see also https://discourse.ardour.org/t/the-initial-font-size-to-small-on-the-daw/105939/5 )
(0025882)
imstre   
2021-05-22 15:50   
for my not worked

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8713 [ardour] bugs minor always 2021-05-18 19:56 2021-05-22 15:37
Reporter: L3br4nd Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when trying to delete a freshly recorded region directly after stopping the recording
Description: After stopping the recording, when ardour is calculating the .peak files (or whatever it does shortly after hitting the stop-button), it is possible to make ardour crash by trying to delete a region which already seems to have been processed (region is displayed and marked red) while other regions are still being processed.
Tags: 6.2, 6.6, 6.6.489, crash
Steps To Reproduce: Preconditions: unsure, more likely to occur in projects with sample rates >=88.2 kHz and >= 24 bit depth with multiple recorded tracks
1. Start a Multi-Track recording (e.g. 9 Tracks in parallel).
2. Hit the Stop button.
3. Click at the first region which is being displayed after recording and hit <DEL> while other tracks are still being processed.
Additional Information: Project contained 48 tracks of which 9 were used for recording (drums).
Samplerate: 96 kHz
Bit depth: 24 Bit
Defect was reproducible with ardour 6.6, 6.6.489(? unsure, nightly from 16.05.2021 CEST), 6.2 and 5.12 under windows 10.

Hardware:
AMD FX-8350
32 GB RAM
Project stored on a SSD
RME Digiface USB connected to Yamaha 01V96 via ADAT used to record 9 tracks @96kHz/24bit in parallel

Unfortunately it was not possible to get the logs although I followed your instructions regarding the gdb-console. I simply was not able to find the logs on my machine although I searched every possible documents folder on the PC. I tried to raise the waveform image cache hoping to speed up the process but it still takes several seconds at which the crash can be provoked.

Also seen with Ardour 6.6 under Linux in a 16 track project with 44.1 kHz samplerate and 32 Bit float bit depth but it is necessary to act very fast to provoke this since the time frame the system needs to process the regions is very small (Xubuntu 20.10, AMD FX-7500, 8GB RAM, RME Babyface in Class Compliant mode)
System Description
Attached Files: CrashLog.zip (18,607 bytes) 2021-05-19 19:09
https://tracker.ardour.org/file_download.php?file_id=4032&type=bug
Bildschirmfoto_2021-05-22_17-09-07.png (94,545 bytes) 2021-05-22 15:13
https://tracker.ardour.org/file_download.php?file_id=4036&type=bug
png

Ardour-debug.log (63,484 bytes) 2021-05-22 15:37
https://tracker.ardour.org/file_download.php?file_id=4038&type=bug
Notes
(0025873)
x42   
2021-05-18 21:00   
Is there a file in %localappdata%\Ardour6\CrashLog\ ?
(0025875)
L3br4nd   
2021-05-19 19:09   
Yes, there are :-)
(0025876)
x42   
2021-05-19 21:34   
Thanks.

The original issue should be fixed since 6.6-491, but there were a few follow up issues. Ardour 6.6-570 should no longer crash when deleting the region. Please test.

There's another issue in the crash-log that's seemingly unrelated (registering actions, crash directly at startup) that I don't yet have an explanation for.
(0025880)
L3br4nd   
2021-05-22 15:13   
The crash is still reproducible with Version 6.7.4.
I tried to generate gdb-logs under linux, but the gdb console gets flooded with JackAudioDriver::ProcessGraphAsyncMaster: Process error
(see screenshots)
(0025881)
L3br4nd   
2021-05-22 15:37   
I got a debug log under Windows...

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8714 [ardour] features minor N/A 2021-05-20 10:35 2021-05-20 10:35
Reporter: erojahn Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Edit pin connections on aux sends
Description: Not sure if this is the right place for feature suggestions.
I would like to be able to edit the pin connections on aux sends. So when i want to split a signal in one track and then process one version to send it to a bus and bypass the send with the unprocessed version.
This seems not possible to me at this time.
Tags: feature request, send, split
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8711 [ardour] bugs minor always 2021-05-18 09:45 2021-05-18 20:55
Reporter: andrzejwawer Platform: Intel I7 64  
Assigned To: OS: AV Linux  
Priority: normal OS Version: 2019.4.10  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Copy more tracks doesn'ty work correctly
Description: When I try copy more tracks - it doesn't work correctly.
Sometimes Ardour adds new tracks, sometimes it uses
transpose, sometimes it moves to different places.
Tags:
Steps To Reproduce: Record audio midi(ues the keyboard) tracks in different places
 and try to copy them somewhere
Additional Information: This problem occurs in all versions of Ardour. The same was in Mixbus 5.3
System Description
Attached Files: Ardour Copy Bug - Screenshot_2021-05-18_03-27-47 - 2.png (168,463 bytes) 2021-05-18 09:45
https://tracker.ardour.org/file_download.php?file_id=4031&type=bug
png
Notes
(0025871)
x42   
2021-05-18 20:55   
I assume this is a region selection and you've used copy/paste via ctrl+c and ctrl+v.
You have to explicitly select the MIDI track(s) to paste to before pasting. They can even be different tracks.
As for the "transpose", I assume you mean they're shifted in time (not MIDI transposed). if so, that is expected behavior when pasting multiple times.

In your case it would be easier to use ctrl+drag/drop to copy. That retains track relationships.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8671 [ardour] bugs minor always 2021-04-22 15:39 2021-05-18 07:33
Reporter: erojahn Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't create Snapshots in big Projects
Description: I have two bigger projects. In both of them when i try to create a snapshot ardour will freeze.
Tags: freeze, saving, snapshots
Steps To Reproduce:
Additional Information:
System Description
Attached Files: snapshotbug.png (8,393 bytes) 2021-05-18 07:33
https://tracker.ardour.org/file_download.php?file_id=4030&type=bug
png
Notes
(0025759)
erojahn   
2021-04-22 18:13   
update: i just exported all the stems to put them inside a new project and it still is not working. So it seems not to be too many automations or plugin related. Its still 110 channels going to the Master and a few plugins.
(0025864)
x42   
2021-05-18 02:18   
How does it fail?

Creating a snapshot is no different from just saving the project. with many channels that is a bit slower but should not be an issue.
(0025869)
erojahn   
2021-05-18 07:33   
It just freezes after i press the "Save" button.
I can wait a multiple of the time it would usually take to save the project and i have to kill ardour to move on.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8710 [ardour] other minor have not tried 2021-05-17 19:27 2021-05-17 19:27
Reporter: krischan941 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: unconsistent "piano roll click-drag behaviour"
Description: A little minor thing.
When previewing a midi instrument I tend to click and drag the piano roll. When doing this and I drag outside the keyboard below or above it behaves different. Dragging outside the bottom I can listen to the lower notes (which are not visible). Dragging outside above I can listen to the last visible key.
I think it would be good to align the behavior. Although I'm not sure which behavior would be the "better" one.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6327 [ardour] bugs crash always 2015-05-14 16:18 2021-05-16 17:27
Reporter: jasonkjellberg Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 4.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Changing height of MIDI track causes crash
Description: When I create a MIDI track and change the height of the track by dragging it will force close Ardour before I release the mouse. If I use the right click menu to change the height Ardour will force close if I choose "Larger" or "Largest."

First bug report in this forum so let me know what other info you need.
Tags:
Steps To Reproduce:
Additional Information: Ubuntu Studio 15.04 Intel i3 550, 12GB DDR3, SSD, file system GPT, formatted BTRFS, fglrx video driver.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2358 [ardour] features feature N/A 2008-07-25 15:25 2021-05-15 15:31
Reporter: bennyp Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: official SAE/Intel  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Please add in a "notes" tab to the notebook
Description: Hello,
I often jot down project notes in a text file that I keep in the project directory. It would be great to have access to my notes without leaving the editor window. To that end, please add in a notes tab to the notebook, which would contain a textarea that I can write in.

Another feature it could have would be a list of all tracks with comments at the bottom of the notebook 'page', which could expand to show the comments (similar to the way the region list is now)

Thanks!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018882)
Lost_Highway   
2016-10-30 15:26   
Just come across this feature request -- I think a global/session comment field would be an excellent idea.

The track comment fields are very useful, but somewhere to store notes relating to the project as a whole (such as a to-do list, or mixing notes) would be really helpful.

Now with the tabbed interface in the Editor window, maybe a button on the editor window would work, which when pressed turned the Editor window screen estate into a giant text box (in a similar way to how the Preferences button uses the screen estate to show the preference options).
(0025854)
mikelupe   
2021-05-15 15:31   
I also would find a global session comment section really nice, even if using the master bus' comment section works as well.

There's a similar feature request over here: https://forum.harrisonconsoles.com/thread-10162.html

Would this rather be a thing for A7?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8702 [ardour] bugs minor always 2021-05-13 08:23 2021-05-14 05:13
Reporter: erojahn Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: confirmed Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Septoles grid does not distribute evenly
Description: In reported this once already a long time ago, now ill try and give it another shot.
When i change the grid to any septoles resolution the grid won't display/divide properly.
It seems, that the septoles are calculated too short, so every bar i have a double line where there should be only one, the one introducing the new bar.
Doesnt happen with quintuplets or triplets.
This bug is in every version i have tested so far and it quite frequently messes up my projects as the snap to grid function creates chaotic behavior with this double line.



Tags: grid
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025849)
x42   
2021-05-14 05:13   
Confirmed.

Ardour uses 1920 ticks/beat 1920 can be evenly divided by 3 and 5 (and 2^7 =128) but not by 7. This leads to rounding issues.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8705 [ardour] bugs minor always 2021-05-13 22:21 2021-05-13 22:21
Reporter: user4336 Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6.6.0 randomly dropping MIDI off notes / sustaining MIDI notes.
Description: Ardour 6.6.0 randomly doesn't turn a MIDI note off / sustains it indefinitely, while playing with live MIDI input (Axiom Pro Keyboard).

Using realtime Linux MAO kernel (5.11.4-rt11.fc34.x86_64 0000001 SMP PREEMPT_RT x86_64) with fresh, fully updated Fedora 34 install.
This also happens using latest non-realtime / vanilla kernel.

Using Pipewire with 512 buffer size - no xruns occurring.

It happens while playing live on two different midi keyboard inputs and using USB input and MIDI port input.

Ardour loaded with default.sf2 soundfont using both Calf fluidsynth and ACE Fluid Synth.

Musescore
Tags: Midi
Steps To Reproduce: Open Ardour
Create MIDI track or bus
Set input to MIDI keyboard
Load Calf Fluidsynth
Load /usr/share/soundfonts/default.sf2 -> FluidR3_GM.sf2
Play live keyboard for about 2-3 minutes.
Additional Information: Operating System: Fedora 34
KDE Frameworks Version: 5.81.0
Qt Version: 5.15.2
Kernel Version: 5.11.4-rt11.fc34.x86_64
OS Type: 64-bit
Graphics Platform: X11
Processors: 4 × Intel® Core™ i5-4460 CPU @ 3.20GHz
Memory: 3.7 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4600
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8677 [ardour] features minor always 2021-04-26 10:34 2021-05-13 09:18
Reporter: unfa Platform: PC  
Assigned To: OS: Manajro Linux  
Priority: normal OS Version: KDE  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Working in sessions with over 100 range markers is a pain - no timeline search function
Description: I'm currently working in game development as an SFX artist.

I often work in extremely large Ardour sessions, with hundreds of sound effects being exported from a single timeline. I think this use case exposes many shortcomings of Ardour's navigation capabilities and performance.

For example: because Ardour has no search function I've opened my .ardour file and searched for marker names to find their location on the timeline. I got it, but it's in audio samples, so not something I can easily understand right away.

Searching manually by scrolling the timeline and reading marker names won't work - the markers are too cluttered and names are not visible, plus there's just too many. Using the Locations panel is futile, as the session is too large. Also opening the Locations panel or window takes forever with as many range markers as this session has (over 150).

I tried copying and pasting this value into my main clock widget to move my playhead there, but it's not reacting to Ctrl+V shortcut.

I'm gonna move my playhead and compare the sample values between the playhead position and my found marker location to find it on the timeline.
Needless to say - it's quite a suboptimal workflow.

I wonder what could be done to improve Ardour for working with such large SFX-centered sessions.
I'd love to be able to hit Ctrl+F like in a text editor, type in a name and search my timeline.
Tags: performance, ui, usability
Steps To Reproduce:
Additional Information: I attach screenshots to show the extent of the sessions I'm working with.
Attached Files:
Notes
(0025831)
unfa   
2021-05-13 09:18   
I have found that the best way to edit Range names is to use a text editor like Kate with the Block selection mode enabled:
https://youtu.be/PYu5SwP8z4s
In larger sessions even attempting to open the locations panel or window pretty much freezes Ardour forever, and even if it'd work, it's not as fast as this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8699 [ardour] bugs minor sometimes 2021-05-12 05:47 2021-05-12 05:47
Reporter: CTS Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Audio setup input/output devices mislabelled/duplicates
Description: Using the CoreAudio backend, after stopping/starting the audio engine the inputs and outputs list can get messed up. "MacBook Pro Microphone" is listed twice, but sometimes only one or neither option works (selecting and monitoring on that input produces silence). Also, "MacBook Pro Speakers" are listed twice as well alongside "External Headphones" but it seems the External Headphones option produces silence and maybe one of the MacBook Pro Speakers options instead works as the External Headphones output.
Tags:
Steps To Reproduce: Nothing precise but I can pretty quickly reproduce it by roughly doing something like:

- Start Ardour with headphones NOT plugged in, select CoreAudio backend and MacBook mic input + Macbook speakers output & start session
- Plug your headphones in
- Open the Audio Setup and stop the audio engine
- Click the input/output selector dropdown and view the list. The mic is probably listed twice alongside another option "ArdourDuplex" which doesn't seem to do much if you choose it. The speakers are also listed twice, along with External Headphones and ArdourDuplex. See screenshots attached.
Additional Information: Ardour version 6.6.479
System Description
Attached Files: inputs.png (187,036 bytes) 2021-05-12 05:47
https://tracker.ardour.org/file_download.php?file_id=4027&type=bug
png

outputs.png (202,071 bytes) 2021-05-12 05:47
https://tracker.ardour.org/file_download.php?file_id=4028&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8687 [ardour] bugs minor always 2021-05-05 08:58 2021-05-07 15:22
Reporter: erojahn Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Copying midiregions creates automationpoints where there should not be any
Description: This happens when i copy and paste a few regions in a track which has automations somewhere in the Project but not at the point the regions are i try to copy (no automation line at that place). When i copy the regions to another place suddenly automationpoints are set at the copied regions and that changes the sound completely.
Tags: copy
Steps To Reproduce:
Additional Information:
System Description
Attached Files: rangetocopy.png (380,564 bytes) 2021-05-07 15:22
https://tracker.ardour.org/file_download.php?file_id=4021&type=bug
now range is pasted.png (401,011 bytes) 2021-05-07 15:22
https://tracker.ardour.org/file_download.php?file_id=4022&type=bug
random points.png (399,573 bytes) 2021-05-07 15:22
https://tracker.ardour.org/file_download.php?file_id=4023&type=bug
Notes
(0025794)
x42   
2021-05-07 04:52   
is this about processor/plugin automation, or MIDI CC?

Are you perhaps using Ripple edit mode? If so that should be fixed in recent git (try a https://nightly.ardour.org/ build).

Otherwise a recipe how to reproduce this would help. Thanks.
(0025796)
erojahn   
2021-05-07 15:21   
It is about processor/plugin automation.
I am not using Ripple mode. This happens when i am in slide mode. Also happens in Ripple mode though.
It does not matter if i copy a region or a range without automation. When i paste it there will be automation.
Not sure how to write a recipe for this. I can share some screenshots.
Sorry about the double screenshots but i think it is visible.
The first pic shows the range to copy. The second the pasted range. Here are automationpoints and as seen in the last picture, the values are sometimes not even appearing in the whole automation lane. Is there anything else i can send to help? :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8694 [ardour] bugs minor always 2021-05-07 08:55 2021-05-07 08:55
Reporter: Micaguay Platform: Linux  
Assigned To: OS: UbuntuStudio  
Priority: normal OS Version: 20.04.1 TLS  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Opaque sound like LPF when recording or importing voice audio on Ardour6.6 (not analog not warm, like opaque)
Description: I have the exact feeling of recording in Ardour5, and feeling that the recorded audio was faithfull. Fidelity

The first take on Ardour6, was like recording with a piece of cloth in front of the mic, or with some kind of Low Pass Filter

Then i imported audio file of just voice recorder with Ardour5.12 in Ardour6.6, and the problem seems to be the PlayBack Machine, or sound.

Some Frequencies are totally cut in the high frequency, you know, what we call the High Quality Mic sound, or the Air, that was present in Ardour ever since we use it, or at minimum in Ardour5, and is gone.

Could this be part of Ardour6 config that could be changed?

I don't understand why there is no reports on this, maybe there is something i'm missing, but playback is like opaque, LPF kind of, when you compare with Ardour5.12, is there anything that could be changed to avoid this?

Sound SEEMS to be more "warm" but in fact is not, what is happening is that high frequencies are being cut, offering a much more opaque experience, that makes me feel bad, like voice was recorded with cloth in front.

Equipment:
AKG Perception 100
UMC 202HD (Behringer)
UbuntuStudio 20.04.1 TLS
Ardour6.6
qt5ct: using qt5ct plugin
Qt: 5.12.8
QjackCtl: 0.5.0


Tags:
Steps To Reproduce: Record voice and import voice audio in Ardour 5.12 then the same in Ardour6.6
Try at the same time audio over Audacity in both cases.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8692 [ardour] other minor always 2021-05-07 07:16 2021-05-07 07:16
Reporter: Micaguay Platform: Linunx  
Assigned To: OS: UbuntuStudio  
Priority: normal OS Version: 20.04.1 TLS  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: New Session should start at Editor (despite you last place when logout)
Description: Today i have started a New Session, and thought the program was loading, but i was already at the Mixer without anything that would let me know i was there, because it was very similar as when the program is loading and doesn't show things, and i was not able to see the EDITOR MIXER buttons, so i though it was loading, for newbies this is bad experience and not comfortable for New Session.
Tags:
Steps To Reproduce: Close your last session being in the Mixer, then enter in New Session, the Mixer is loaded without anything that would let you understand you are there (and if the Mixer button is out of the window you don't know you are there too).
Additional Information: New Session should always start at EDITOR place
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8690 [ardour] features minor always 2021-05-06 17:01 2021-05-06 17:01
Reporter: mikelupe Platform: any  
Assigned To: OS: any  
Priority: normal OS Version: any  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: FR: When dragging automation points, use the same behavior when dragging point or line, if all points are selected
Description: If all automation points are selected, moving the line should do the same as moving a point.


Tags: automation
Steps To Reproduce: Select all automation points of an automation track and vertically drag a line.
Additional Information: (Maybe this behavior could be adopted even for the case in which more than two points are selected.)
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8689 [ardour] features minor have not tried 2021-05-06 06:10 2021-05-06 06:10
Reporter: comgang Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Export/Import of Markers, Time Signatures and Tempo-Markers
Description: I often have projects, which I need twice.
For example I use one project for recording with a minimum amount of plugins and then I use another project for mixing. I always have to copy every single marker etc. one by one. It would be much faster and easier to export on the first project and import on the other one.

By the way, thank you all for the awesome work. I use Ardour for 2 years now and it keeps getting better and better :)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8684 [ardour] features minor always 2021-05-01 12:01 2021-05-01 12:02
Reporter: Micaguay Platform: Linux  
Assigned To: OS: UbuntuStudio  
Priority: normal OS Version: 20.04.1 TLS  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Fader Automation, Gain Automation, Consolidate and Bouncing inside Ardour workflow.
Description: Objective: Trying to bounce or consolidate a region with processing, without affecting the actual stage.
Discovered problems and need to improve workflow if possible and considered relevant.

I understand the steps to reproduce the problem goes below, but in this case i'm saying what i did first, so you can understand after that the need or possible need of the solutions suggested. (The issue that affects Bouncing with Processing will be sent appart with details, but it's mentioned here to explain i don't know yet how that feature performs sd it's not working).

STEPS

1) I create a copy of a track without the content
2) I copy a complete region and paste it below in the new track
3) I make changes to the Fader Automation, in play mode affecting the places where there is a wave.
4) I make a new copy of the region in the PlayList(P), the new copy is there, with the same automation below, and i come back to the first one.
5) I make a Bouncing with processing (but nothing happens, this issue is something appart, i will fill a bug case appart with details)
6) I make a Consolidating with processing, and the first region is changed with the processing, in this case fader automation.
7) The fader automation below the region is still there, i don't need it for this region anymore, so as suggested in documentation or forums i clean it.
8) I go to the Copy of this region, and THE AUTOMATION IS GONE, the automation was not part of the region, but something appart, in no place we understand that,
and when cleaning the automation doesn't say something like "If you delete this automation, other copies of this region will not have this automation, as is not attached to regions but to tracks"
9) Then you have the track with processing but you lost your automation and you don't have it in the backup or New Copy of the region.
Leaving the automation would lead to problems as affects the region that already has the processing,

Considerations: Bouncing with processing is not working in my UbuntuStudio 20.04 with [Ardour 5.12.0 "Working Backwards" (rev 1:5.12.0-3ubuntu4) Intel 64-bit]

Because of this, i can't know exactly how it works, so if i repeat something that already works the same way, please forgive me.
Anyway the Copy Fader Automation to Gain Automation i think is good to have it.

The solutions or new features i think could be good (with permission, respect and gratitude to dev team, it's understood) would be:

FIRST POSSIBLE SOLUTION (not the best one -as the best would be having all automation in a per playlist item basis- but good as new feature, would be...)

(Described below as if already exists, as if you read the text from the future docs, i'm not english speaker so forgive my english, i speak italian and spanish native...)

***************************************
************************

Fader Automation to Gain (Copy Fader Automation to Gain Automation)
When you make a "Fader Automation to Gain", the fader automation below the selected region will be copied to the Gain Automation above, you can select "Internal Edit Mode" and see the changes on your gain automation inside the region.
Be sure to clean the fader automation below the region if you don't need it anymore, as it will continue to affect the region itself.

************************
***************************************

(I think the best way to do this would be affecting the selected regions and not the range as it would be harder to do it i think, and confusion for the user,
puting the option inside the Gain menu below Reset Envelope option "Fader Automation to Gain" would be great i think.)

The solution described DOESN'T SOLVE the problem of trying to bounce or consolidate regions with processing, that is having problems.



----------
SECOND POSSIBLE SOLUTION (together with the first one would be great new feature i think)

Allow the user to select if changes on Fader Automation, will affect Gain Automation above, Fader Automation itself or both.
Two little buttons on the left of the Automation State with G and F, being G for Gain Automation and F to Fader Automation.



***************************************
************************
Fader Automation Buttons (F and G)
This buttons tells to the DAW, that actions made on the Fader Automation, should affect only the F(Fader Automation), G(Gain Automation), or both.
When no option is selected, actions will affect only Fader Automation itself.
************************
****************************************



With this two solutions, and if Bouncing with Process works as i think (sending bounce to new track created after the original track)

You have this solutions (speaking to the user always)

1) If you want to have the track bounced with processing in a new track, you have it.
2) If you want to make Fader changes (like in vocal riding and other examples using the actual changes while playing tools) and attach that to Gain Automation (you can do it on the go, or after that with the Fader to Gain Automation copy)
3) If you want to make Fader and Gain automation changes at the same time (you can do it too, with both buttons pressed)
4) If you want to make a New Copy of regions in the PlayList you should make a "Fader to Gain Automation" first, and then the NewCopy to Playlist if you plan to delete or change fader automation in other PlayList items, as they share all track automation.

** CONSOLIDATE WITH PROCESSING **
This should be discouraged as it works now and suggest the Bouncing with or without Processing, except if you can copy all automation with each NewCopy on the PlayList,
and allow "Unlink Automation" to make changes to automation without affecting other automations on other copies of that playlist.
Until that happens or if it's not possible, Consolidate with Processing should be discouraged and suggested the Bouncing with or without processing.


hope this help in the discussion on this topic, and if you let me know of topics related that i couldn't find, or you want me to expand on any feature
or participate in the discussion i will be glad, i have some tech skills, to at less understand the complexity some things could suposse.

Finally thanks for your time, your effort and this marvelous piece of love to our world.

thanks again and as soon as i receive the message i will ASAP send answer if needed, in any other case, i will be here at your command.

Micaguay
Tags: bounce ardour, bouncing, bouncing ardour, bouncing with processing, consolidate, fader automation, freeze track, gain automation, New Copy Play List
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8676 [ardour] other minor always 2021-04-25 20:37 2021-04-28 07:23
Reporter: Prisca Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: can't open a session message: ERROR: ardour::connect: Invalid Source port: (ardour:Bus Master/audio_out 1)
Description: I've got this message error when I want to open a session and so I can't open the session:
ERROR: ardour::connect: Invalid Source port: (ardour:Bus Master/audio_out 1)
could you help me please ...
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 01-beauté.ardour (157,592 bytes) 2021-04-26 16:14
https://tracker.ardour.org/file_download.php?file_id=4009&type=bug
01-beauté-2.ardour (157,514 bytes) 2021-04-26 21:24
https://tracker.ardour.org/file_download.php?file_id=4010&type=bug
Notes
(0025769)
x42   
2021-04-25 21:31   
Could you attach the .ardour session-file, or upload it somewhere?
(0025770)
Prisca   
2021-04-26 16:14   
I don't understand (I'm french ;) ) you want me to send the file, ok ? see file attached
I also try to export the wave files in a new session but i've got the same pb
(0025772)
x42   
2021-04-26 21:24   
Yes, I wanted the "01-beauté.ardour file. Thanks.

However, this session loads just fine here. So either there is something specific translation or the issue is that master-out is connected to Ardour's LTC input.

I've removed the port-connection, new file attached. DOwnload and replace it with 01-beauté.ardour on your PC.
 
If that does not fix it, can you try to start Ardour, create a new session. then in Preferences > General > Translations : disable translations (Ardour will be in english then, je suis désolée)
(0025775)
Prisca   
2021-04-28 07:23   
It seems to be ok...
Merci beaucoup ;)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8680 [ardour] bugs minor always 2021-04-28 06:38 2021-04-28 06:38
Reporter: DaiKen Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Behringer X-Touch One missing functionality after update firmware
Description: Windows 10 Home
Ardour 6.6.0
Behringer X-Touch One 1.04 & 1.08

I was getting myself acquainted with the Behringer X-Touch One (and Ardour itself) when I noticed the Touch One was running on firmware 1.04. I updated that to latest available version (1.08), restarted the lot, and found a few ‘things’ not working anymore (at least as they did in 1.04).

Just a few:

The light around the turning knob;
Turning that knob performed a left-right pan on the actiev channel;
My channels used to show in the scribble, not anymore now;
The fader seems to have come to a stop;\
The signal leds are ‘dead’;
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8678 [ardour] bugs minor always 2021-04-27 20:02 2021-04-27 20:02
Reporter: rugubara Platform: x86_64  
Assigned To: OS: Gentoo Linux  
Priority: normal OS Version: rolling  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: The session cannot be opened
Description: The session stopped to open. I tried to isolate the .ardour file in the new directory and open from there - still no luck. Ardour6 just quits. there is no message about core dump.
 
Tags:
Steps To Reproduce: 1. open the attached session file.
Additional Information: anton@PF16W6Y2 ~ $ pw-jack ardour6
Ardour6.6.0 (built using 6.6 and GCC version 10.3.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /etc/ardour6/system_config
Ardour: [INFO]: Loading user configuration file /home/anton/.config/ardour6/config
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
Ardour: [INFO]: Using AVX and FMA optimized routines
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour6/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/anton/.config/ardour6/plugin_metadata/plugin_stats
Ardour: [INFO]: Loading default ui configuration file /etc/ardour6/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/anton/.config/ardour6/ui_config
Ardour: [INFO]: Loading 451 MIDI patches from /usr/share/ardour6/patchfiles

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.669: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.669: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.669: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.670: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.670: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.671: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.671: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.672: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.672: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.672: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.672: Unable to locate theme engine in module_path: "murrine",
Ardour: [INFO]: Loading color file /usr/share/ardour6/themes/dark-ardour.colors

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.695: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.696: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.696: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.696: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.697: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.697: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.697: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.697: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.697: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.698: Unable to locate theme engine in module_path: "murrine",

(ardour-6.6.0:3093874): Gtk-WARNING **: 22:57:46.698: Unable to locate theme engine in module_path: "murrine",
Ardour: [INFO]: Loading ui configuration file /etc/ardour6/clearlooks.rc
Ardour: [INFO]: Loading bindings from /etc/ardour6/ardour.keys
Loading ui configuration file /etc/ardour6/clearlooks.rc
Found nothing along /home/anton/.config/ardour6/templates:/usr/share/ardour6/templates
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8643 [ardour] other minor have not tried 2021-03-29 12:28 2021-04-25 13:20
Reporter: inFlowiaLab Platform: Linux  
Assigned To: OS: Ubuntu Studio  
Priority: normal OS Version: 19.10 x64  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Snapshots can severely degrade performance
Description: My project has grown to 5 GB. There were only 12 snapshots in it. I had big problems with recording on one track, because before the recording started, there was a delay of about 3-6 seconds all the time, and after the end of the recording, there was also a delay of about 5-15 seconds. There was also a delay before switching the playlist of 5-10 seconds.
I tried cleaning up unused sources and it only cleared 300MB. This did not help to increase productivity (and the cleaning process took more than 2 hours). But when I deleted all 12 snapshots and repeated the cleaning, it cleared more than 3GB and after that the delays before and after recording were reduced to 1-2 seconds and the delay before switching the playlist disappeared.
Tags: performance, snapshot, snapshots
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025744)
paul   
2021-04-22 00:37   
Snapshots can have no impact at all on performance. A given instance of Ardour has no idea how many snapshots exist. It only loads (or even looks at) the one you specify. The only times it looks for snapshots are:

1) when presenting an expandible list of snapshots to open
2) during session cleanup

This is not to say that your problems are not happening, but they are not caused by snapshots.
(0025760)
inFlowiaLab   
2021-04-23 06:55   
Problems are most likely caused by a large number of unused sources that slow down saving, and snapshots prevent these sources from being cleaned up.
(0025763)
paul   
2021-04-23 14:20   
Sources don't slow down saving (saving the session only saves metadata about the source files, not the files). But lots and lots of regions will slow things down (this is a long term problem that we're slowly making progress on.
(0025768)
inFlowiaLab   
2021-04-25 13:20   
OK, thank you for the information. The next time the save slows down a lot again, I'll try cleaning up unused regions (not sources). If it works, then I will no longer be afraid to use snapshots.
 No, though. After that: https://tracker.ardour.org/view.php?id=8552 I'll never stop being afraid of snapshots.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8675 [ardour] bugs minor always 2021-04-25 12:45 2021-04-25 12:45
Reporter: Hans Flikkema Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Names of tracks don't appear in windows Tracks and Buses and in Window Audio connections
Description: As the formal 6.6 W10 version missed Bus connections in the mixer Window it also had the problem that when making new project save it and reopen it, then the names of the tracks in the window Track and Busses and in the windows of Audio Connections stay gray. You can see that there are a lot of tracks and the green dots are the, but no track names.
In nightly build version 6.6.346 The problem of missing direct bus names in the mixer per track is solved but the missing names in the windows I mentioned.
Fortunately using right mouse button per individual track in the mixer still allows me to connect buses etc. But using the connection windows work a lot faster (my vocal recording sessions mostly have 50 or more tracks. And It worked before (6.5.3 was without any bugs in my experience) so.....

Second thing I noticed , when creating project in Advanced mode, the Master bus is missing and all new tracks are not connected at all, was that normal before?
Tags: Bug 6.6 6.6-346 Audio connections
Steps To Reproduce: Create a new recording project wit some recording track. Create a view audio buses and start connecting using the WIndows, no problem, you cab read the names of all tracks. Then save and close the project.
Then re-open the project and check the connection wIndows again and you'll see the track names are all greyed/blanked out. The green connection mark are visable, see attachment
Additional Information:
System Description
Attached Files: Missing Track names ARD6_6 connection windows.JPG (52,306 bytes) 2021-04-25 12:45
https://tracker.ardour.org/file_download.php?file_id=4008&type=bug
jpg
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8674 [ardour] bugs minor always 2021-04-24 22:39 2021-04-24 22:39
Reporter: DBA Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Exports hangs when more than one instance of Komplete Kontrol is used
Description: I use several instance of Native Instruments Komplete Kontrol. When During editing everything works fine. But when I try to export the file, the exports just never starts. I can only choose to stop the export. The file is created with a size of 0. If I have only one instance, the export is made.
Tags: export, instrument
Steps To Reproduce: Create any track with Komplete Kontrol and any instrument in it. Export: it works. Make another track with Komplete Kontrol. Control that both are working well in the edit mode. Try to export: doesn't work.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8644 [ardour] bugs minor always 2021-03-30 08:54 2021-04-23 13:51
Reporter: Werner Back Platform: Microsoft  
Assigned To: paul OS: Windows  
Priority: normal OS Version: 10  
Status: assigned Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Region/Edit/Change Pitch looses timing
Description: I had a track with some relatively short bass parts followed by a slightly longer part. I wanted to pitch the track one octave higher. After doing so the timing was completely lost in the short parts, the long part was nearly OK till near the end, then it was off timing again. I attached an example with the left channel containing the original and the right channel containing the pitched version.
Tags:
Steps To Reproduce: 1. Import audio (new track), should be not too short
2. Duplicate the track
3. Pitch the track
Additional Information:
System Description
Attached Files: PitchError_Schleife.mp3 (813,588 bytes) 2021-03-30 08:54
https://tracker.ardour.org/file_download.php?file_id=3982&type=bug
Screenshot_after.png (77,669 bytes) 2021-04-23 07:46
https://tracker.ardour.org/file_download.php?file_id=4003&type=bug
png

Screenshot_before.png (53,459 bytes) 2021-04-23 07:46
https://tracker.ardour.org/file_download.php?file_id=4004&type=bug
png

Screenshot_start.png (9,123 bytes) 2021-04-23 13:51
https://tracker.ardour.org/file_download.php?file_id=4005&type=bug
png
Notes
(0025730)
paul   
2021-04-22 00:09   
Could you attach a screenshot of what this looks like after the pitch shift?
(0025761)
Werner Back   
2021-04-23 07:46   
I duplicated Track "Git 2" to "Git 2 1" and did a 1 octave pitch. This time I tried the Linux version but the result is the same. Attached screenshots before and after pitch.
(0025762)
Werner Back   
2021-04-23 13:51   
Region start hasn't moved.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8666 [ardour] bugs minor always 2021-04-17 15:51 2021-04-22 12:13
Reporter: TechieDamien Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Opening project with video in timeline crashes Ardour and freezes JACK applications.
Description: When opening a project that has a video timeline enabled. Ardour opens up xjadeo and about half a second later spawns a pop-up that says it is waiting for the video playback to start, despite it already being open. Any attempt to interact with ardour, or after waiting a moment, the graphical interface for ardour closes, but the process is still running in the background. Any attempt to start ardour causes it to open in the background, but never spawn a graphical interface. All other applications that interact with JACK (eg Carla, Cadence) will freeze upon trying to interact with JACK. After logging out and logging back in, starting ardour again, xjadeo spawns in, no pop-up appears and everything works.
Tags: video, video timeline
Steps To Reproduce: 1. Create a project using video.
2. Save the project.
3. Reboot.
4. Open the project.
Additional Information:
System Description
Attached Files:
Notes
(0025741)
paul   
2021-04-22 00:29   
This appears to be specific to (a) the video in question and/or (b) your system. It works without issues here on two test videos I imported. I use JACK1.
(0025757)
TechieDamien   
2021-04-22 12:13   
I use JACK2, so that may be the difference.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8668 [ardour] bugs minor N/A 2021-04-18 17:56 2021-04-22 06:30
Reporter: Rummidge Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour randomly saves many duplicated automation points (2048 identical transitions)
Description: While working on a project (editing tracks, cutting, overlapping), Ardour became sluggish, unresponsive. Anyhow my work had been recently saved.

When tried to reopen the session, Ardour showed a message like "Wait for the UI to load" and after some minutes it didn't respond at all and eventually broke. I could open other projects without any problem.

I analyzed the project file *.ardour and found that Ardour had saved many duped event transitions on some of the automatizations I was using. Some automations had several 2048 repetitions of the same event:

[...]
 <events>0 1
[...]
151419857 1
153124248 1
153124248 0
155287305 1
155584055 1
155584055 0
155584055 1
155584055 0
155584055 1
155584055 0
155584055 1
[...]

And there is exactly 2048 "0"s and 2048 "1"s events. This happens many (up to 24) times on several automations that I have defined: 4 automations of Calf Equalizer Mono. The timestamps differ on each of the 24

I have manually removed 19 of those repetitions (still 5 remain) and my Ardour session works again, but still saves those excessive event transitions.

Of course I have not created them manually :-)


After saving a project, iI was working on

I am editing a podcast and I have a single track to which I apply different equalizations. While I was manually editing have assigned
Tags: automation, save, session
Steps To Reproduce: I really don't believe iI can reproduce it but I do know what I was doing when this happened.

I am editing a two hour long podcast recorded on a single track. Some different speakers demand different equalization so I have several Calf Equalizers (one for each "offending" voice) which remain disabled until they are required. Each activation status is stored on one automation "channel". It's worked perfectly for more than 10 sessions already.

Yesterday I had finished equalizing the session and was trimming some isolated peaks on the audio track by cutting/pasting, saving the session each time I did another trimming.

After one of the "save", Ardour became slow and started playing (was it after my action?) the track sloooowly. After which I had to stop it with the described results.
Additional Information: I have preserved the *.ardour file just in case.
System Description
Attached Files:
Notes
(0025727)
paul   
2021-04-21 23:54   
How as the automation data generated?
(0025755)
Rummidge   
2021-04-22 06:30   
It is originated on a MIDI control surface (M-Audio Oxygen25), routed via JACK and then assigned to the different activation channels of the Calf Equalizers.

Please keep in mind that all these 2048 events are signed exactly with the same timestamp.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8632 [ardour] bugs minor always 2021-03-21 18:13 2021-04-22 04:24
Reporter: tailor@seamlyne.com Platform: Debian Linux  
Assigned To: paul OS: Kubuntu  
Priority: normal OS Version: 18.04  
Status: assigned Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: start screen behind logo
Description: On startup, when I select an existing project from "Session Setup", the "Audio/MIDI setup" screen comes up behind the logo.
Tags: start
Steps To Reproduce: Open Ardour. Select a previous project.
Additional Information:
System Description
Attached Files: ardour - screenshot.png (97,711 bytes) 2021-03-21 18:13
https://tracker.ardour.org/file_download.php?file_id=3976&type=bug
png
Notes
(0025732)
paul   
2021-04-22 00:11   
Do you use KDE as a desktop environment?
(0025748)
tailor@seamlyne.com   
2021-04-22 01:14   
KDE yes.
(0025751)
paul   
2021-04-22 02:49   
KDE frequently fails to follow Freedesktop.org guidelines on window management.

There are some settings in Edit > Preferences > Appearance > Quirks which might help with this issue, notably "All floating windows are dialogs"

We don't consider this to be an Ardour bug. It works correctly in almost all non-KDE window managers (and the ones it is broken in also do not follow Freedesktop.org guidelines)
(0025753)
tailor@seamlyne.com   
2021-04-22 04:24   
> Freedesktop.org guidelines on window management

Never knew there was such a thing. So I learned something new, cool! I don't suppose you know of a site somewhere that lists different DE's compliance?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8622 [ardour] features minor have not tried 2021-03-16 17:52 2021-04-22 03:22
Reporter: D213 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mixer button(points) size.
Description: Hello, Paul.
Is it possibly to increase mouse-click-area on butons in mixer(fader, plugins)? Sometimes it's so hard hit it...
I add picture in attach to show what i mean.
Thank you.
Pavel.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Ardour_plugin_button.png (11,304 bytes) 2021-03-16 17:52
https://tracker.ardour.org/file_download.php?file_id=3968&type=bug
png
Notes
(0025640)
x42   
2021-03-24 20:28   
meanwhile, you can middle-click anywhere on the processor to toggle it.
(0025642)
D213   
2021-03-25 02:41   
I use mouse with a broken scroll button and did not know about this feature...
Now there will be a reason to fix it:))))
Thank you!
Pacvel.
(0025740)
paul   
2021-04-22 00:25   
Also, your mockup doesn't actually increase the area much at all. The entire LED area, not just the colored part, is active for button press events. Making it a rectangle does increase it a little bit, but it also makes the "button" much more visually intrusive.
(0025749)
D213   
2021-04-22 02:40   
It looks, active area uncentered, and moved to right...
Pavel.
(0025750)
paul   
2021-04-22 02:47   
Nope. The active area is actually a rectangle, despite what is drawn on the screen. When I test it, I can click on any pixel in the rectangle touched by the outer circle's outer edge, and the click is active.
(0025752)
D213   
2021-04-22 03:22   
I re-check it at evening. Inattention sometimes lets me down:(

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8623 [ardour] features minor N/A 2021-03-17 12:17 2021-04-22 00:50
Reporter: mmasanga Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: Mixer next page binding
Description: Next page midi midibinding for mixer strips. Can it be automatically triggered with next-bank/prev-bank functions?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025733)
paul   
2021-04-22 00:12   
It's not clear whether you're asking to control Ardour's own GUI, or the behavior via some control surface?
(0025747)
mmasanga   
2021-04-22 00:50   
Hi Paul, is it possible to have the mixer strips move in relation to "next bank" and "prev bank" actions?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8612 [ardour] bugs minor always 2021-03-09 12:25 2021-04-22 00:20
Reporter: WanderingFeral Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Can't play MIIDI section
Description: Ardour won't play MIDI notes if the playhead is not placed at the start of the section of MIDI notes. For example, if the playhead it placed in the middle of a section and the play button is pressed, no sound is produced at all. However, if the playhead is placed at the beginning of the section Ardour plays the MIDI and produces a sound.

Possibly related to: https://tracker.ardour.org/view.php?id=8611
Tags: Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025739)
paul   
2021-04-22 00:20   
Can you attach a screenshot showing the situation?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8611 [ardour] bugs minor always 2021-03-09 12:12 2021-04-22 00:19
Reporter: WanderingFeral Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI loop won't play note
Description: Ardour won't play a MIDI note in a loop if the note begins before the start of the loop range.
Tags: Midi
Steps To Reproduce: - Create a MIDI track and record some MIDI notes
- Create a loop section that starts after the start of the MIDI section
Additional Information:
System Description
Attached Files:
Notes
(0025738)
paul   
2021-04-22 00:19   
This is intentional (as of right now).

It took a very well known sequencer that started life as MIDI-only (Cubase) nearly 25 years to add this feature.

We might get there first. But no immediate plans.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8615 [ardour] bugs minor always 2021-03-13 13:59 2021-04-22 00:14
Reporter: Daniele1971 Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: assigned Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: segfault loading Roughrider3 vst: error 6 in libxcb.so.1.1.0
Description: Ardour segfault as soon I add Roughrider3 vst.
It happens with ardour from opensuse repo but also with official ardour 6.6.45.

Plugin: https://www.audiodamage.com/pages/free-downloads

It works fine in reaper and carla.

From the backtrace:

Thread 1 "ArdourGUI" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe91573c0 (LWP 5789)]
0x00007fffeb5eff83 in ?? () from /usr/lib64/libxcb.so.1
#0 0x00007fffeb5eff83 in ?? () from /usr/lib64/libxcb.so.1
0000001 0x00007fffeb5f0a89 in ?? () from /usr/lib64/libxcb.so.1
#2 0x00007fffeb5f0f21 in ?? () from /usr/lib64/libxcb.so.1
#3 0x00007fffeb5f1f02 in xcb_wait_for_reply64 () from /usr/lib64/libxcb.so.1
0000004 0x00007fffed11d3b8 in _XReply () from /usr/lib64/libX11.so.6
0000005 0x00007fffed0fce34 in XGetWindowProperty () from /usr/lib64/libX11.so.6
#6 0x00007fff723dedad in juce::XWindowSystemUtilities::GetXProperty::GetXProperty(unsigned long, unsigned long, long, long, bool, unsigned long) ()
   from /home/dan/.vst3/RoughRider3.vst3/Contents/x86_64-linux/RoughRider3.so
#7 0x00007fff723def66 in juce::XWindowSystem::isMinimised(unsigned long) const () from /home/dan/.vst3/RoughRider3.vst3/Contents/x86_64-linux/RoughRider3.so
0000008 0x00007fff723f7641 in juce::Component::isShowing() const () from /home/dan/.vst3/RoughRider3.vst3/Contents/x86_64-linux/RoughRider3.so
0000009 0x00007fff72401f2f in juce::Component::setBounds(int, int, int, int) () from /home/dan/.vst3/RoughRider3.vst3/Contents/x86_64-linux/RoughRider3.so
0000010 0x00007fff721da072 in juce::JuceVST3EditController::JuceVST3Editor::ContentWrapperComponent::resized() () from /home/dan/.vst3/RoughRider3.vst3/Contents/x86_64-linux/RoughRider3.so
0000011 0x00007fff723d689c in juce::Component::sendMovedResizedMessages(bool, bool) () from /home/dan/.vst3/RoughRider3.vst3/Contents/x86_64-linux/RoughRider3.so
0000012 0x00007fff72400826 in juce::ComponentPeer::handleMovedOrResized() () from /home/dan/.vst3/RoughRider3.vst3/Contents/x86_64-linux/RoughRider3.so
0000013 0x00007fff7248de00 in juce::LinuxComponentPeer<unsigned long>::setBounds(juce::Rectangle<int> const&, bool) () from /home/dan/.vst3/RoughRider3.vst3/Contents/x86_64-linux/RoughRider3.so
0000014 0x00007fff723d2133 in juce::ComponentPeer::updateBounds() () from /home/dan/.vst3/RoughRider3.vst3/Contents/x86_64-linux/RoughRider3.so
#15 0x00007fff72402081 in juce::Component::setBounds(int, int, int, int) () from /home/dan/.vst3/RoughRider3.vst3/Contents/x86_64-linux/RoughRider3.so
Tags: VST3
Steps To Reproduce: Load Roughrider3 vst
Additional Information:
System Description
Attached Files:
Notes
(0025599)
x42   
2021-03-13 16:47   
This is likely fixed by https://github.com/juce-framework/JUCE/commit/d4e802016a (re-compile the plugin with updated JUCE)

and/or Ardour 6.6.103 (https://github.com/Ardour/ardour/commit/c075d3a026 https://github.com/Ardour/ardour/commit/9f3fba6988 )
(0025620)
Daniele1971   
2021-03-21 00:25   
Tested Ardour-6.6.148, no luck. Same segfault.
(0025735)
paul   
2021-04-22 00:14   
Then it likely needs the JUCE fix in the plugin.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8640 [ardour] features minor have not tried 2021-03-25 12:06 2021-04-22 00:11
Reporter: singybeatman Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: List of micromanagement
Description: The piano roll to sound 2 or more notes at the same time when moving them.

Navigate play head left to right in other modes from grab mode.

An option to mute a midi note.

Option to turn off a created region to stop been auto renamed when moved to a different track.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025731)
paul   
2021-04-22 00:11   
muting a MIDI note is a massive change and would/will require a complete redesign of how we handle MIDI.

i don't know if the first item is a request for a new feature or a request to stop doing something.

i don't know what the second item means.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8383 [ardour] bugs minor always 2020-08-27 13:45 2021-04-20 16:55
Reporter: AliMacD Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Stretch mode clock not changing
Description: According to the manual "The Stretch Mode tool is very similar in use to doing a trim in grab mode: the boundary (start or end) is Left-clicked and dragged to its wanted position. Notice a timer appearing, showing the new duration of the region using the same clock mode as in the primary transport clock."
and
"The Time Stretch Audio window is made of:
Duration The target duration of the region, expressed using the primary transport clock's mode"

For me Time Stretch Audio window duration is always bars and beats.
Tags: editing
Steps To Reproduce: Select stretch mode. Click and drag on region. Release mouse: Time Stretch Audio window opens. Duration is in bars |beats format
Additional Information: While dragging, the number on screen correctly shows the primary clock value, but when the Time Stretch Audio window opens it reverts to bars & beats.
Both of my clocks are in minutes/seconds or a combination of things that are not bars & beats (which I never use)
System Description
Attached Files:
Notes
(0025724)
AliMacD   
2021-04-20 16:55   
I hope this is an easy fix - it would be nice to be able to have the primary clock mode (mins & secs for me) shown in the timestretch window in the upcoming version of Ardour

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7791 [ardour] bugs minor sometimes 2019-08-23 17:04 2021-04-19 11:48
Reporter: colinf Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Combine & uncombine messes up region layering
Description: Sometimes, uncombining a combined region seems to mess up the region layering, changing it so that it effectively becomes 'later regions are higher', even if later regions were layered below before combining them.

I haven't been able to reproduce this in a test session by just combining & uncombining regions: there's some other piece of the recipe that I don't know yet, but it has happened to me during some fairly extensive editing in a session with four combined regions of ten or so constituent regions each on three grouped tracks.
Tags:
Steps To Reproduce: I wish I knew...
Additional Information:
Attached Files: combine-bug.gif (372,104 bytes) 2019-08-23 18:25
https://tracker.ardour.org/file_download.php?file_id=3465&type=bug
Notes
(0020732)
x42   
2019-08-23 18:25   
The fundamental issue: uncombine restores the original regions with their properties before combining.
A related issue is duplicated compounds: Uncombine can vanish those.

Overlap two compounds, then uncombine. The original layering of the compound is restored, but since it's overlapped with another compound it becomes inconsistent. It may even be ambiguous what should happen.

Another bug: Also a compound may have some "missing" layers. e.g. at the time you've made the compound you've combined regions of layer 1 + 3. Elsewhere on the track some layer 2 existed. Uncombine later would try to add a 3rd layer and fail (see gif animation). -- That's likely a won't fix.
(0025721)
Blindekinder   
2021-04-19 11:47   
Bug still present in 6.5.0:
Edit some region, with superpositions, change the layering, "combine": the layering reset to default in the xx-compound region.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8667 [ardour] bugs minor always 2021-04-17 15:57 2021-04-17 15:57
Reporter: TechieDamien Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Post-export scripts do not run.
Description: Post-export scripts do not run after export, despite, in the logs, expanding to the correct script. Copying and pasting the script into a terminal running either zsh (my user shell) or dash (my system shell) result in the desired script running, so I know there is no issue in the script itself.
Tags: export, script
Steps To Reproduce: 1. Edit an export profile (I used Ogg Vorbis) to include a post-export script.
2. Export your project.
3. Check the logs to see if Ardour thinks the script has been run.
4. Verify the script has not run.
5. Copy the expanded script from the logs into a terminal to verify that it is valid.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8664 [ardour] features minor always 2021-04-16 14:57 2021-04-16 19:07
Reporter: akik Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Fader automation curve is not redrawn to reflect the session tempo change
Description: description
Tags:
Steps To Reproduce: - Create a MIDI track with an instrument plugin
- Record some notes to it
- Add fader automation
- Draw fader automation for play
- Change the session tempo from 120 bps to 90 bps
- Fader automation curve stays in its original form and doesn't cover the whole range of notes
Additional Information:
System Description
Attached Files:
Notes
(0025709)
akik   
2021-04-16 15:39   
bps should be bpm
(0025710)
x42   
2021-04-16 19:07   
So far all automation uses sample-time. Audio is not time-stretched when you change the BPM, either.

It is planned in future version of Ardour to specify the time-domain (sample-time or music-time) which can allow automation to follow music-time changes.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8662 [ardour] bugs minor always 2021-04-11 17:43 2021-04-11 21:18
Reporter: loplkc Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Vitalium instances are randomly altered when reopening a session
Description: After saving a session with one or more Vitalium instances, closing Ardour, and reopening the session immediately (or later), various parameters will be altered. The most common alteration is the reversion of samples or oscillators to full volume, but sometimes arbritary parameters will be changed, such as spectral warping modes randomly being enabled or envelopes being lengthened. On my system (both in Ardour 6.5 and Ardour 6.6), this happens consistently to every single new session I create. On older sessions, it seems to selectively apply to some instances but not others.
Tags:
Steps To Reproduce: 1. Create a new session in Ardour.
2. Add at least one MIDI track with a Vitalium instance.
3. Set the Vitalium instance to a previously saved patch.
4. Save the session.
5. Close Ardour.
6. Open Ardour.
7. Load the session.
Additional Information:
System Description
Attached Files:
Notes
(0025704)
x42   
2021-04-11 20:13   
Are you using the LV2 or VST3 plugin?
(0025705)
loplkc   
2021-04-11 21:18   
I use the Vitalium LV2 plugin. I do not know if Vitalium is available as a VST3 plugin.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8660 [ardour] bugs minor sometimes 2021-04-10 15:59 2021-04-10 17:36
Reporter: finotti Platform: Linux  
Assigned To: OS: Debian  
Priority: normal OS Version: Unstable  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when editing automation
Description: Using Ardour 6.6.216 (nightly), Ardour has been crashing when trying to edit automation (pitch bend for Vitalium) in my current project.

As suggested by Paul, I tried disabling DrumGizmo, but it still happened. The log 'gdb.txt' is with DrumGizmo, while 'gdb2.txt' is without.
Tags:
Steps To Reproduce: Open the session, try to add automation points (in this current session).
Additional Information:
System Description Using also KXStudio repositories.
Attached Files: gdb2.txt (213,402 bytes) 2021-04-10 15:59
https://tracker.ardour.org/file_download.php?file_id=3995&type=bug
gdb.txt (134,588 bytes) 2021-04-10 15:59
https://tracker.ardour.org/file_download.php?file_id=3996&type=bug
gdb3.txt (288,716 bytes) 2021-04-10 16:36
https://tracker.ardour.org/file_download.php?file_id=3997&type=bug
gdb4.txt (77,009 bytes) 2021-04-10 17:36
https://tracker.ardour.org/file_download.php?file_id=3998&type=bug
Notes
(0025698)
x42   
2021-04-10 16:06   
Both crashes (gdb.txt and gdb2.txt) happen in /usr/lib/lv2/drumgizmo.lv2/drumgizmo.so
(0025699)
finotti   
2021-04-10 16:36   
OK, here is one from a snapshot where the DG plugin was deleted.
(0025702)
finotti   
2021-04-10 17:36   
Here is another file, with no DG.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8641 [ardour] bugs minor always 2021-03-27 17:21 2021-04-06 21:42
Reporter: ardourwlk Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: region producing audio output sporadically
Description: Reproduced using 6.6.203 running on Ubuntu Studio 20.04 AMD 64-bit.
I am loop recording (mono). I'll record, say, 5 passes, which (apparently) works fine. But when I playback (as a loop) the audio for certain of the regions produced, it will produce audio only sporadically. I.e. some of the regions will work/sound as expected, but some (no pattern yet) will only produce sound (and mostly incomplete) intermittently. For example, it will only produce audio on the 4th time through the loop. I looked at the wav files in question, and they look intact (at least regarding the size).

In addition, I move the problem region later in the track, and playing it, I get no sound. The visual element suggests there is a nice big waveform there.

thanks!
Tags:
Steps To Reproduce: Perform loop recording. some of the resultant regions will have this issue.
Additional Information:
System Description
Attached Files: Screenshot_01.png (117,637 bytes) 2021-03-27 17:57
https://tracker.ardour.org/file_download.php?file_id=3979&type=bug
png

Screenshot_02.png (113,892 bytes) 2021-03-27 17:57
https://tracker.ardour.org/file_download.php?file_id=3980&type=bug
png

Screenshot_03_while_resize_drag.png (114,047 bytes) 2021-03-27 17:57
https://tracker.ardour.org/file_download.php?file_id=3981&type=bug
png

Audio_LoopRec_Test_2021-04-06_233231.ardour-session-archive (646,185 bytes) 2021-04-06 21:42
https://tracker.ardour.org/file_download.php?file_id=3993&type=bug
Notes
(0025644)
ardourwlk   
2021-03-27 17:25   
noted that altering the length of the region allows it to sound. And when I resized it (dragging on the end), it snapped to some interior point. I do not have snapping enabled.
(0025645)
ardourwlk   
2021-03-27 17:39   
And... If I choose one of the loop-recorded regions which seem ok, I can actually extend that region (dragging on the right extremity of the region) to uncover a significant fraction of the "next" loop recording
(0025646)
mikelupe   
2021-03-27 17:57   
I could reproduce this in 6.6.204.

Ectract of IRC chat:
"<MikeLupe> happyau: when I resize at the end, no matter in what direction (there's only one btw, to the front), it snaps the region to the _visual_ end of the amplitude."

I.e. the last (4th) region of the recorded loop shows missing visual amplitude, and that empty visual part what is being "removed" when resizing this region.

See the third attached Screenshot_03_while_resize_drag.png , this is while resizing/draging with mouse, it snaps back to where the audio really ends.
(0025647)
ardourwlk   
2021-03-27 18:17   
Well, for debugging, in 6.6.203, I created a new session, created a mono track, recorded a loop, and was not able to notice the problem. I did a loop of 8, and all sounded fine and seemed to work correctly. I closed up, and created another session, imported 2 wav files as two tracks, created a mono track, recorded a loop of 8 iterations, and it behaved in the undesirable way. I took one of the bad regions, dragged it elsewhere in the track, played it, and it didn't sound. Resized it, and it now it produces audio.

Maybe it's the import that throws things off, maybe you have to import multiple.
(0025648)
ardourwlk   
2021-03-27 18:18   
And if it's important, I'm using Jack, and running at 48k.
(0025668)
mikelupe   
2021-04-02 09:54   
I was able to reproduce it on the other (main) Audio WS. It doesn't matter if using Jack or ALSA btw, so for OBS' recording "simplicity" I used Jack. See the attached screen recording. @x42 were you able to reproduce it? Maybe I could help in some way to narrow it down?

Ardour 6.6.229, Debian bullseye here
(0025669)
mikelupe   
2021-04-02 10:43   
I tried to upload the clip, 1.7MB didn't seem to work, neither did 1.3MB (as .tar.gz). If the clip is relevant, we surely would find another way.

Error on upload here (mouse-focus on the uploading file):
"<head><title>413 Request Entity Too Large</title></head>"
(0025677)
mikelupe   
2021-04-06 21:42   
Here a very short archived example (A6.6.229, onboard notebook mic, ALSA) with a short 3-loop recording. The last, 3rd loop doesn't play unless being resized to snap to the "real" recording lenght of this loop. This happens as well on a "real" recording workstation with Jack and enough buffers set.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8648 [ardour] documentation minor always 2021-04-01 07:49 2021-04-05 14:34
Reporter: sciurius Platform: N/A  
Assigned To: OS: N/A  
Priority: normal OS Version: N/A  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: LV2 plugins documentation errors
Description: Ardour Manual, Appendix, Files and Directories Ardour Knows About.

Plugins > Linux > LV2

> LADSPA plugins should be found in /usr/lib/lv2/, /usr/local/lib/lv2/ or in a directory mentioned in your LV2_PATH environment variable.

This should, of course, be LV2 plugins.

> The most common mistake made by distro packagers, is to use a path like /usr/lib/$ARCH/lv2/ and find that Ardour will not find that by default.

Maybe even more common is to use paths like /usr/lib64/lv2 and /usr/local/lib64/lv2 . It may be worth considering to include these in the standard list as well.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025675)
Headwar   
2021-04-05 14:34   
Correction made, and waiting to be merged. Thanks !

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8651 [ardour] bugs minor always 2021-04-05 08:49 2021-04-05 08:49
Reporter: Headwar Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [Papercut] Edit > Snap & Grid > Previous/Next Quantize Grid Choice not updated
Description: When selecting Edit > Snap & Grid > Next (or Previous) Quantize Grid Choice, all works perfectly fine but the radio select inside the menu itself is not updated.
Tags: Papercut
Steps To Reproduce: See "Description"
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8646 [ardour] bugs minor always 2021-03-31 15:07 2021-03-31 17:35
Reporter: Yruama_Lairba Platform: Librazik 3 (Debian 10 based)  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: confirmed Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: looping can make the time cursor going backward while the sound is played forward
Description: When the speed control have been used to play backward, loop playing make the time cursor going backward from the loop beginning while sounds are played forward in a apparently random speed. The loop playing stop when the cursor reach the project beginning.
Tags: loop
Steps To Reproduce: - open a project with audio track(s)
- place loop markers. beginning of the loop must not be at project beginning and should be placed in a noticeable place ( beginning of an instrument part for example)
- place the time cursor anywhere except at project beginning.
- use the speed control to play backward and release it
- click "play loop" button or press the "L" shortcut. The cursor goes backward while the sound is played forward with a speed that depend on the previously used speed on the speed control
Additional Information: Reproduced in the last official demo version.
I join a project for convenience
System Description
Attached Files: Loop goes backward_2021-03-31_163244.ardour-session-archive (169,045 bytes) 2021-03-31 15:07
https://tracker.ardour.org/file_download.php?file_id=3985&type=bug
session-open-archive.png (10,391 bytes) 2021-03-31 17:35
https://tracker.ardour.org/file_download.php?file_id=3987&type=bug
png
Notes
(0025661)
x42   
2021-03-31 15:25   
An additional step to reproduce this: Play backwards first, with vari-speed dial in "wheel" mode. Ardour remembers the previous speed and resumes playback with the given speed.
However transport-control is backwards, but playback buffers have forward data.

You can work-around this by resetting the speed to 100% (context menu of the vari-speed slider, or shift+click).
(0025664)
Yruama_Lairba   
2021-03-31 15:54   
@x42, i don't need your additional step to make it happen. I mean, i make it happen with vari-speed set in sprung mode. I'm going to test your variant thought, i just experienced a crash few second after have been tryed it once,
(0025665)
x42   
2021-03-31 16:08   
I guess you have previously rolled backwards (ardour remembers this in your local prefs). When you press play (no loop) which direction does the playhead move?
(0025666)
Yruama_Lairba   
2021-03-31 16:47   
when the varispeed is in sprung mode doing:
- open the project (i tried to use my archive but i don't know how to open it)
- set varispeed to a negative speed and release it (playing stop when i release the mouse button)
at this step two possibilities:
one, I "loop play" : the cursor goes backward, sound played forward, and i didn't noticed before, the varispeed goes back to the previous negative speed
two, i do a normal play : the cursor goes forward, sounds are played forward and speed is 100%

i found another bug, probably related and more annoying, i'm going to publish it
(0025667)
x42   
2021-03-31 17:35   
> i tried to use my archive but i don't know how to open it

In Session > Open file-picker dialog you can select session-archives. They are then unzipped to the default session folder.

Alternatively you can use `tar xvJf the-archive-file` - the files are really LZMA compressed tar archives.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8279 [ardour] bugs minor always 2020-06-30 23:22 2021-03-27 22:38
Reporter: TBL Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Duration of exported video with negative video position in timeline wrong
Description: The duration flags given to ffmpeg when exporting a video with negative start position leads to premature end of the video.

The reason seems to be the wrong usage of the -itsoffset <offset> and -t <duration> parameters for ffmpeg: the total duration of the exported video is truncated at <duration> + <offset> (note the sign of <offset>)

Having a negative <offset> value prematurely truncates the resulting video by <offset>.

The ffmpeg command line created by ardour would be:
/usr/bin/ffmpeg_harvid -itsoffset -20 -i input_video.mp4 -i vtl_mysession.wav [...] -t 150 output.mp4

The result would be a output file where the video stream ends at 130s.
Tags: 6.0, export, video
Steps To Reproduce: 1. create project with audio
2. mmport video
3. move video to a negative starting position.
4. export video
Additional Information: This bug happens with Ardour 6.0.0 and ffmpeg 4.2.3
System Description
Attached Files:
Notes
(0025650)
antgel   
2021-03-27 22:38   
Interesting, in 0007312 (Ardour 5.8) I and another user get no video output at all. I wonder if it was (partially) fixed between Andour versions.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7312 [ardour] bugs major always 2017-04-10 00:55 2021-03-27 22:25
Reporter: gostevehoward Platform:  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 16.10  
Status: new Product Version: 5.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Audio export fails with negative -itsoffset for video track -- no video track in output
Description: I have a 0000009:0000010 min recording session in Ardour and a corresponding MP4 video, which starts slightly before the audio session. I import the video and drag the video track backwards to get it to line up with audio. I then only want to export a couple minutes starting about 8 min into the session, so I set the "start" and "end" markers. Everything looks good in Ardour, audio export works perfectly, so I go to video export with the mp4/h264 preset. I check the debug option so it prints the ffmpeg command:

/opt/Ardour-5.8.0/bin/ffmpeg_harvid -itsoffset -471.185 -i <path>.MP4 -i <path>/export/vtl_mysession.wav -acodec aac -strict -2 -t 159.351 -vcodec libx264 -metadata comment="Created with Ardour" -map 0:0 -map 1:0 -y <path>/export/export.mp4

The resulting export.mp4 file has no video track, just audio. I tried replacing the -itsoffset option with -ss (seek), running the following by hand (I manually copied the vtl_mysession.wav intermediate file beforehand):

/opt/Ardour-5.8.0/bin/ffmpeg_harvid -ss 471.185 -i <path>.MP4 -i <path>/export/vtl_mysession2.wav -acodec aac -strict
 -2 -t 159.351 -vcodec libx264 -metadata comment="Created with Ardour" -map 0:0 -map 1:0 -y <path>/export/export2_harvid.mp4

This seems to work perfectly.

Let me know if I can provide more info that will help. It's my first time reporting an Ardour bug so I don't know the ropes. And of course thank you so much for this wonderful wonderful piece of software.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025649)
antgel   
2021-03-27 22:25   
Same here... The `ss` option didn't sync up properly for me, I had to add 3 to get to where I needed to be. I guess from now on, I'll start Ardour recording before I start the video recording, so I don't have to move the video back. It's messy but it should work. Of course, not everyone will have my fairly trivial use case of filming guitar solos at home. Strange though, as negative `-itsoffset` values should be supported.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8639 [ardour] features minor have not tried 2021-03-25 11:53 2021-03-25 11:53
Reporter: singybeatman Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Step Entry free mode
Description: Step entry mode to have a setting where you can create notes to a designated length by holding down for however you held your midi controller for . After creating a note it would have a option to create space for the next note to be made via a key defined by you, whether that's midi learn or the standard keyboard, allowing you to toggle it on and off.

It perhaps could have extra options like quantise after note release. It should keep the ability to set velocity too.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8638 [ardour] bugs minor always 2021-03-24 16:02 2021-03-24 16:36
Reporter: HiddenUser Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OSC sends "/cancel_all_solos" after "/strip/solo 1 1" message
Description: if solo at channel 1 is klicked, OSC sends: "/strip/solo 1 1" and then "/cancel_all_solos".
This cancels the selected solo.
Tags:
Steps To Reproduce: klick at solo button with OSC active. Feedback set to 0x1b
Additional Information: In 6.5.0, 6.6.0 and source from today

solo klicked -> on
>received: /strip/solo 1 1
>received: /cancel_all_solos
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8634 [ardour] bugs minor always 2021-03-23 04:35 2021-03-24 07:13
Reporter: nbadger Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 7  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour hangs at startup, with a box saying "Generic low latency ASIO driver"
Description: Upgraded 6.5 to 6.6, now I get this error every time I start Ardour. The progress bar hangs half way through, saying Focusrite USB, Checking 2 channels, 96000 SPS.
Tags:
Steps To Reproduce: Start Ardour
Additional Information: I'm using a Focusrite Scarlett 2i2, which worked fine with Ardour 6.5.
System Description
Attached Files: ardourstartupbug.jpg (6,346 bytes) 2021-03-23 04:35
https://tracker.ardour.org/file_download.php?file_id=3977&type=bug
jpg
Notes
(0025639)
nbadger   
2021-03-24 07:13   
Re-installed Ardour 6.5 and it now has the same problem! I can't open any projects. Other sound software (Audacity, Reaper) work fine.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8635 [ardour] bugs minor always 2021-03-23 12:32 2021-03-23 12:48
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Opening or resizing region list in a large session makes Ardour unresponsive for a good while
Description: The Locations panel or window are very slow to open up or resize.

Once they do chug through that, they work relatively fine, but using them in a large session (>100 ranges) takes minutes of time to just get the panel or window ready.

I attach a screenshot of a window that was maximized and then took a dozen seconds (or more, not sure) to refresh.
Tags: performance, ui
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20210323_132718.png (144,533 bytes) 2021-03-23 12:32
https://tracker.ardour.org/file_download.php?file_id=3978&type=bug
png
Notes
(0025637)
unfa   
2021-03-23 12:48   
Oh, creating a new Range while the Locations panel or Window are open also takes a good while.
If need be, I can provide a test session file.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8170 [ardour] bugs minor always 2020-05-30 14:49 2021-03-19 17:03
Reporter: inFlowiaLab Platform: Linux  
Assigned To: OS: Ubuntu Studio  
Priority: normal OS Version: 19.10 x64  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Notes drawn on a grid disappear when the clip size is adjusted to the beginning of the note
Description: Video with bug: http://inflowia.ru/tmp/note-snap-disappear.mkv
beat grid and sticking enabled

This behavior was sometimes found in 5.12 but in 6 it seems that this always happens (I tried it in two different projects)

Tags: Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files: screen.png (1,970 bytes) 2021-01-16 14:08
https://tracker.ardour.org/file_download.php?file_id=3933&type=bug
png

screen-2.png (3,395 bytes) 2021-03-19 17:03
https://tracker.ardour.org/file_download.php?file_id=3971&type=bug
png
Notes
(0024319)
inFlowiaLab   
2020-05-31 09:48   
This applies not only to the display of notes. This still creates problems just when playing. For example, if I create a note with stickey to the beat grid at the very beginning of the beat, align its beginning with the snap exactly along the line, and then try to click on the beginning of the beat in the snap mode and play the note, then it will not play. It will not play until I start playing at least a little bit earlier than the start of the beat. It seems that in the stikey to beats mode, all notes are drawn a little earlier than the real beginning of the beats, or the transport starts playing a little later than the real beginning of the beats. As a result, the first notes are constantly skipped. This creates a bunch of problems.
(0025426)
inFlowiaLab   
2021-01-16 13:53   
In version 6.5 this is still not fixed and it still makes the MIDI writing workflow excruciatingly long.
(0025427)
inFlowiaLab   
2021-01-16 14:08   
And I was right about the fact that the notes are drawn a little earlier than the beats. This is how the beginning of a note drawn with sticking to the beginning of measures and beats looks like at MAXIMUM ZOOM.
(0025592)
inFlowiaLab   
2021-03-04 15:04   
After moving to 6.6 it got better, but the bug still happens when drawing notes in the region created by cutting the region with scissors.
That is, if you draw a region through D, then the notes in it are aligned correctly, but if you cut off a piece from this region and draw in it, then everything will be the same.
Video example: http://inflowia.ru/tmp/notes-snap-disapper-cause-scissors.mkv
(0025615)
inFlowiaLab   
2021-03-19 17:03   
Yes. Note beginnings now coincide with the grid (not counting cases from the previous message), however, the length of the notes remained incorrect. They are longer than the selected mesh size. (See screenshot) Because of this, their ends stick out and if you draw several notes in a row one after the other, they will overlap with these extra ends. Such overlapping notes sound only in the place of overlap, that is, they sound very short (practically do not sound). You still have to work separately with each note. Disable snapping mode and shorten them.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8628 [ardour] features minor have not tried 2021-03-18 16:52 2021-03-18 16:52
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make Export > Time Span display amount of selected regions and amount of files that would be overwritten
Description: In large sessions having a an extra bit of information could be useful so the user knows they're not going to export more files by mistake, or not enough files.

I'm attaching a simple mockup on a screenshot from a large SFX session.
Tags: improvements, ui, usability
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20210318_174048-1.png (119,379 bytes) 2021-03-18 16:52
https://tracker.ardour.org/file_download.php?file_id=3969&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8624 [ardour] bugs minor always 2021-03-17 12:24 2021-03-17 12:24
Reporter: mmasanga Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Arbitrary msg binding not working on 6.5
Description: I am having trouble binding this message to a Roland SI-24 jog wheel. The jog wheel sends out "00 0f 01" for clockwise, and "00 0f 7f" for counter-clockwise.

<Binding msg="00 0f 01" action="Common/playhead-forward-to-grid"/>
<Binding msg="00 0f 7f" action="Common/playhead-backward-to-grid"/>

I believe the binding format is correct.

Thank you.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8617 [ardour] bugs minor have not tried 2021-03-15 15:15 2021-03-15 15:20
Reporter: ardourwlk Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour wrecked... perhaps renaming a track
Description: Hi, Ardour 6.6 binaries on Ubuntu Studio 20.04. I was renaming a track, and I may have hit a ctrl-something. Just happened, have not tried to reproduce yet.

in dmesg:
traps: ArdourGUI[4514] trap int3 ip:7f6a6c962278 sp:7ffcecd9a590 error:0 in libglib-2.0.so.0[7f6a6c906000+150000]

in apport.log:
ERROR: apport (pid 4802) Mon Mar 15 10:49:56 2021: called for pid 4514, signal 5, core limit 0, dump mode 1
ERROR: apport (pid 4802) Mon Mar 15 10:49:56 2021: executable: /opt/Ardour-6.6.0/bin/ardour-6.6.0 (command line "/opt/Ardour-6.6.0/bin/ardour-6.6.0")
ERROR: apport (pid 4802) Mon Mar 15 10:49:56 2021: gdbus call error: Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

ERROR: apport (pid 4802) Mon Mar 15 10:49:56 2021: debug: session gdbus call:
ERROR: apport (pid 4802) Mon Mar 15 10:49:56 2021: apport: report /var/crash/_opt_Ardour-6.6.0_bin_ardour-6.6.0.1000.crash already exists and unseen, doing nothing to avoid disk usage DoS


Zipped up crash file above is 72M.... not sure how to parse that out if it's valuable to you.
Tags:
Steps To Reproduce: have yet to try
Additional Information:
System Description
Attached Files:
Notes
(0025602)
ardourwlk   
2021-03-15 15:20   
And... just tried to restart Ardour, and after choosing my desired session, it showed a window which said something along the lines of "...loading visual data..", and it wrecked before I could get a screenshot.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8616 [ardour] bugs minor always 2021-03-14 21:08 2021-03-14 21:08
Reporter: Overmann Platform: Max PPC G5  
Assigned To: OS: OSX  
Priority: normal OS Version: 10.6.8  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6.6.114 crashes every time I try to record
Description: Ardour crashes after recording. Record-enabling a track works, hitting record in the transport works and beginning to record works, but when hitting space (to stop recoring) it crashes.
Tags: ardour6, g5, mac, ppc, record
Steps To Reproduce: Whenever I attempt to record
Additional Information: I have two crash logs from OSX generated from two crashes. They will be separated by:

////////////////////////////////////////////////////////////////////////////////////////////////////////////
*************************************************************************
////////////////////////////////////////////////////////////////////////////////////////////////////////////

{\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf540
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww19600\viewh12860\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural

\f0\fs24 \cf0 Process: Ardour6 [161]\
Path: /Applications/Ardour6.app/Contents/MacOS/Ardour6\
Identifier: org.ardour.Ardour6\
Version: 6.6.114 (6.6.114)\
Code Type: PPC (Native)\
Parent Process: launchd [73]\
\
Interval Since Last Report: 778 sec\
Crashes Since Last Report: 1\
Per-App Interval Since Last Report: 491 sec\
Per-App Crashes Since Last Report: 1\
\
Date/Time: 2021-03-14 20:59:13.609 +0100\
OS Version: Mac OS X 10.5.8 (9L31a)\
Report Version: 6\
Anonymous UUID: A8127075-910C-4DD8-8E6E-E85153ED6D63\
\
Exception Type: EXC_BAD_ACCESS (SIGSEGV)\
Exception Codes: KERN_INVALID_ADDRESS at 0x000000006aaa8000\
Crashed Thread: 0\
\
Thread 0 Crashed:\
0 libSystem.B.dylib 0x908b4a78 tiny_malloc_from_free_list + 296\
1 libSystem.B.dylib 0x908b515c szone_calloc + 228\
2 libSystem.B.dylib 0x908b5024 malloc_zone_calloc + 120\
3 libSystem.B.dylib 0x908b4f7c calloc + 72\
4 com.apple.CoreGraphics 0x900f1c54 CGGStateCreateCopy + 28\
5 com.apple.CoreGraphics 0x900f1c00 CGGStackSave + 48\
6 com.apple.CoreGraphics 0x900f1bb0 CGContextSaveGState + 92\
7 libgdk-quartz-2.0.0.dylib 0x034c6444 gdk_window_impl_quartz_get_context + 132\
8 libgdk-quartz-2.0.0.dylib 0x034b7140 _gdk_windowing_create_cairo_surface + 112\
9 libgdk-quartz-2.0.0.dylib 0x0349c70c gdk_window_ref_cairo_surface + 204\
10 libgdk-quartz-2.0.0.dylib 0x03471c54 gdk_cairo_create + 132\
11 libgdkmm-2.4.1.dylib 0x03d1f0fc Gdk::Drawable::create_cairo_context() + 44\
12 libgtkmm2ext.dylib 0x02a041c8 CairoWidget::on_expose_event(_GdkEventExpose*) + 728\
13 libgtkmm-2.4.1.dylib 0x03a2e1c0 Gtk::Widget_Class::expose_event_callback(_GtkWidget*, _GdkEventExpose*) + 112\
14 libgtk-quartz-2.0.0.dylib 0x030d6610 _gtk_marshal_BOOLEAN__BOXED + 240\
15 libgobject-2.0.0.dylib 0x02d28f30 g_closure_invoke + 432\
16 libgobject-2.0.0.dylib 0x02d3d1dc signal_emit_unlocked_R + 2060\
17 libgobject-2.0.0.dylib 0x02d44b90 g_signal_emit_valist + 3728\
18 libgobject-2.0.0.dylib 0x02d44f2c g_signal_emit + 44\
19 libgtk-quartz-2.0.0.dylib 0x0325862c gtk_widget_event_internal + 908\
20 libgtk-quartz-2.0.0.dylib 0x030d4970 gtk_main_do_event + 1648\
21 libgdk-quartz-2.0.0.dylib 0x034ac410 _gdk_window_process_updates_recurse + 512\
22 libgdk-quartz-2.0.0.dylib 0x034ac350 _gdk_window_process_updates_recurse + 320\
23 libgdk-quartz-2.0.0.dylib 0x034ac350 _gdk_window_process_updates_recurse + 320\
24 libgdk-quartz-2.0.0.dylib 0x034ac350 _gdk_window_process_updates_recurse + 320\
25 libgdk-quartz-2.0.0.dylib 0x034ac350 _gdk_window_process_updates_recurse + 320\
26 libgdk-quartz-2.0.0.dylib 0x034ac350 _gdk_window_process_updates_recurse + 320\
27 libgdk-quartz-2.0.0.dylib 0x034ac350 _gdk_window_process_updates_recurse + 320\
28 libgdk-quartz-2.0.0.dylib 0x034b2514 -[GdkQuartzView drawRect:] + 740\
29 com.apple.AppKit 0x9277cec8 -[NSView _drawRect:clip:] + 3000\
30 com.apple.AppKit 0x9277afd4 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 1424\
31 com.apple.AppKit 0x927774c8 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 2328\
32 libgdk-quartz-2.0.0.dylib 0x034c6a74 _gdk_windowing_after_process_all_updates + 100\
33 libgdk-quartz-2.0.0.dylib 0x0349f35c gdk_window_process_all_updates + 556\
34 libgdk-quartz-2.0.0.dylib 0x0349f3cc gdk_window_update_idle + 12\
35 libgdk-quartz-2.0.0.dylib 0x03470b70 gdk_threads_dispatch + 96\
36 libglib-2.0.0.dylib 0x02db7f80 g_main_dispatch + 976\
37 libglib-2.0.0.dylib 0x02dbb02c g_main_context_iterate + 604\
38 libglib-2.0.0.dylib 0x02dbb210 g_main_loop_run + 400\
39 libgtk-quartz-2.0.0.dylib 0x030d3d7c gtk_main + 220\
40 libgtkmm2ext.dylib 0x02a15a9c Gtkmm2ext::UI::run(Receiver&) + 460\
41 org.ardour.Ardour6 0x0065e358 main + 2200\
42 org.ardour.Ardour6 0x00014c40 start + 64\
43 ??? 0x00000ffc 0 + 4092\
\
Thread 1:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libardour.dylib 0x01f5c578 __ZL16peak_thread_workv + 296\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 2:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libardour.dylib 0x01f5c578 __ZL16peak_thread_workv + 296\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 3:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libardour.dylib 0x016b1c68 ARDOUR::Analyser::work() + 312\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 4:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libardour.dylib 0x016fc318 ARDOUR::AudioEngine::do_reset_backend() + 888\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 5:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libardour.dylib 0x016fa3d8 ARDOUR::AudioEngine::do_devicelist_update() + 376\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 6:\
0 libSystem.B.dylib 0x908ad078 mach_msg_trap + 8\
1 libSystem.B.dylib 0x908b3f9c mach_msg + 56\
2 com.apple.CoreFoundation 0x96dda394 CFRunLoopRunSpecific + 1812\
3 com.apple.audio.CoreAudio 0x931bbfa8 HALRunLoop::OwnThread(void*) + 212\
4 com.apple.audio.CoreAudio 0x931bbde4 CAPThread::Entry(CAPThread*) + 104\
5 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 7:\
0 libSystem.B.dylib 0x908ee7b0 kevent + 12\
1 libgio-2.0.0.dylib 0x0380df98 _kqueue_thread_func + 296\
\
Thread 8:\
0 libSystem.B.dylib 0x90910c14 select$DARWIN_EXTSN + 12\
1 libglib-2.0.0.dylib 0x02dcc954 g_poll + 452\
2 libglib-2.0.0.dylib 0x02dbafac g_main_context_iterate + 476\
3 libglib-2.0.0.dylib 0x02dbb2ec glib_worker_main + 156\
4 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
5 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 9:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libgdk-quartz-2.0.0.dylib 0x034b9854 select_thread_func + 180\
3 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 10:\
0 libSystem.B.dylib 0x908ad0f8 semaphore_timedwait_signal_trap + 8\
1 libSystem.B.dylib 0x908f0214 _pthread_cond_wait + 1320\
2 com.apple.audio.CoreAudio 0x931cd9f0 HP_IOThread::WorkLoop() + 488\
3 com.apple.audio.CoreAudio 0x931cd7f0 HP_IOThread::ThreadEntry(HP_IOThread*) + 12\
4 com.apple.audio.CoreAudio 0x931bbde4 CAPThread::Entry(CAPThread*) + 104\
5 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 11:\
0 libSystem.B.dylib 0x908ad078 mach_msg_trap + 8\
1 libSystem.B.dylib 0x908b3f9c mach_msg + 56\
2 com.apple.audio.midi.CoreMIDI 0x072ddf34 XServerMachPort::ReceiveMessage(int&, void*, int&) + 88\
3 com.apple.audio.midi.CoreMIDI 0x072cfadc MIDIInPortThread::Run() + 68\
4 com.apple.audio.midi.CoreMIDI 0x072d3104 XThread::RunHelper(void*) + 24\
5 com.apple.audio.midi.CoreMIDI 0x072deaa8 CAPThread::Entry(CAPThread*) + 96\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 12:\
0 libSystem.B.dylib 0x908ad0f8 semaphore_timedwait_signal_trap + 8\
1 libSystem.B.dylib 0x908f0214 _pthread_cond_wait + 1320\
2 libcoreaudio_backend.dylib 0x072a2eb0 ARDOUR::CoreAudioBackend::freewheel_thread() + 544\
3 libcoreaudio_backend.dylib 0x072a31ac __ZL17pthread_freewheelPv + 44\
4 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 13:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libardour.dylib 0x01deb054 ARDOUR::RTTaskList::run() + 36\
2 libardour.dylib 0x01deb69c ARDOUR::RTTaskList::_thread_run(void*) + 44\
3 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 14:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libglib-2.0.0.dylib 0x02d7f9d4 g_atomic_pointer_get + 52\
2 libardour.dylib 0x01deb69c ARDOUR::RTTaskList::_thread_run(void*) + 44\
3 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 15:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libglib-2.0.0.dylib 0x02d7f9d4 g_atomic_pointer_get + 52\
2 libardour.dylib 0x01deb69c ARDOUR::RTTaskList::_thread_run(void*) + 44\
3 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 16:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libardour.dylib 0x0189b14c ARDOUR::Graph::run_one() + 316\
2 libardour.dylib 0x0189bb94 ARDOUR::Graph::main_thread() + 580\
3 libcoreaudio_backend.dylib 0x0729dabc ARDOUR::CoreAudioBackend::coreaudio_process_thread(void*) + 1452\
4 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 17:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libardour.dylib 0x0189b528 ARDOUR::Graph::reached_terminal_node() + 88\
2 libardour.dylib 0x0189b218 ARDOUR::Graph::run_one() + 520\
3 libardour.dylib 0x0189bdf4 ARDOUR::Graph::helper_thread() + 532\
4 libcoreaudio_backend.dylib 0x0729dabc ARDOUR::CoreAudioBackend::coreaudio_process_thread(void*) + 1452\
5 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 18:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libardour.dylib 0x0189b14c ARDOUR::Graph::run_one() + 316\
2 libardour.dylib 0x0189bdf4 ARDOUR::Graph::helper_thread() + 532\
3 libcoreaudio_backend.dylib 0x0729dabc ARDOUR::CoreAudioBackend::coreaudio_process_thread(void*) + 1452\
4 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 19:\
0 libSystem.B.dylib 0xffff9350 __bigcopy + 528 (cpu_capabilities.h:242)\
1 libardour.dylib 0x017c4ba8 std::vector<ARDOUR::CaptureInfo*, std::allocator<ARDOUR::CaptureInfo*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<ARDOUR::CaptureInfo**, std::vector<ARDOUR::CaptureInfo*, std::allocator<ARDOUR::CaptureInfo*> > >, ARDOUR::CaptureInfo* const&) + 264\
2 libardour.dylib 0x017b7a38 ARDOUR::DiskWriter::finish_capture(boost::shared_ptr<std::vector<ARDOUR::DiskIOProcessor::ChannelInfo*, std::allocator<ARDOUR::DiskIOProcessor::ChannelInfo*> > >) + 392\
3 libardour.dylib 0x017c12ac ARDOUR::DiskWriter::transport_stopped_wallclock(tm&, long, bool) + 284\
4 libardour.dylib 0x01f26640 ARDOUR::Session::non_realtime_stop(bool, int, bool&) + 912\
5 libardour.dylib 0x01f2809c ARDOUR::Session::butler_transport_work(bool) + 2172\
6 libardour.dylib 0x0177850c ARDOUR::Butler::thread_work() + 396\
7 libardour.dylib 0x01779c00 ARDOUR::Butler::_thread_work(void*) + 240\
8 libpbd.dylib 0x02acb474 __ZL17fake_thread_startPv + 148\
9 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 20:\
0 libSystem.B.dylib 0x90910c14 select$DARWIN_EXTSN + 12\
1 libglib-2.0.0.dylib 0x02dcc954 g_poll + 452\
2 libglib-2.0.0.dylib 0x02dbafac g_main_context_iterate + 476\
3 libglib-2.0.0.dylib 0x02dbb210 g_main_loop_run + 400\
4 libpbd.dylib 0x02a9c4d4 BaseUI::main_thread() + 420\
5 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
6 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
7 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 21:\
0 libSystem.B.dylib 0x908ad0d8 semaphore_wait_signal_trap + 8\
1 libSystem.B.dylib 0x908f0224 _pthread_cond_wait + 1336\
2 libardour.dylib 0x01eb87f0 ARDOUR::Session::emit_thread(void*) + 96\
3 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 22:\
0 libSystem.B.dylib 0x908ad0d8 semaphore_wait_signal_trap + 8\
1 libSystem.B.dylib 0x908f0224 _pthread_cond_wait + 1336\
2 libardour.dylib 0x01e16994 ARDOUR::Session::auto_connect_thread_run() + 2356\
3 libardour.dylib 0x01e16a2c ARDOUR::Session::auto_connect_thread(void*) + 44\
4 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 23:\
0 libSystem.B.dylib 0x908b3a88 __semwait_signal + 8\
1 libSystem.B.dylib 0x908b3870 nanosleep$UNIX2003 + 144\
2 libglib-2.0.0.dylib 0x02df1958 g_usleep + 104\
3 libardour.dylib 0x01765e78 ARDOUR::AutomationWatch::thread() + 216\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 24:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libwaveview.dylib 0x016824ac ArdourWaveView::WaveViewDrawRequestQueue::dequeue(bool) + 108\
4 libwaveview.dylib 0x01682b40 ArdourWaveView::WaveViewDrawingThread::run() + 96\
5 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
6 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
7 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 25:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libwaveview.dylib 0x016824ac ArdourWaveView::WaveViewDrawRequestQueue::dequeue(bool) + 108\
4 libwaveview.dylib 0x01682b40 ArdourWaveView::WaveViewDrawingThread::run() + 96\
5 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
6 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
7 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 26:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libwaveview.dylib 0x016824ac ArdourWaveView::WaveViewDrawRequestQueue::dequeue(bool) + 108\
4 libwaveview.dylib 0x01682b40 ArdourWaveView::WaveViewDrawingThread::run() + 96\
5 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
6 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
7 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 0 crashed with PPC Thread State 32:\
  srr0: 0x908b4a78 srr1: 0x0200f030 dar: 0x6aaa8000 dsisr: 0x02200000\
    r0: 0x00000040 r1: 0xbfffdd50 r2: 0x00000000 r3: 0x04ee8000\
    r4: 0x00000006 r5: 0x00000000 r6: 0xffffffff r7: 0x2155b434\
    r8: 0x02cf0e58 r9: 0x00000001 r10: 0x6aaa8000 r11: 0x00000351\
   r12: 0x908b7730 r13: 0xbfffe5c0 r14: 0xbfffe468 r15: 0x000055db\
   r16: 0xbfffe540 r17: 0x06682030 r18: 0x00000000 r19: 0x02d6c9e4\
   r20: 0x00000000 r21: 0xbfffe484 r22: 0xbfffe540 r23: 0x00000002\
   r24: 0xbfffe468 r25: 0x00000500 r26: 0x21600000 r27: 0x00000006\
   r28: 0x04ee8000 r29: 0x04ee80d8 r30: 0x2161a880 r31: 0x908b4964\
    cr: 0x24422244 xer: 0x00000000 lr: 0x908b4964 ctr: 0x908b7730\
vrsave: 0x80000000\
\
Binary Images:\
    0x1000 - 0xee9ff3 +org.ardour.Ardour6 6.6.114 (6.6.114) <2b40078805a0cfbf7f39559b219e1330> /Applications/Ardour6.app/Contents/MacOS/Ardour6\
 0x1603000 - 0x161eff9 com.apple.audio.CoreAudioKit 1.5 (1.5) <b7e5287b5d5cdda58e147a6ffa19667e> /System/Library/Frameworks/CoreAudioKit.framework/Versions/A/CoreAudioKit\
 0x162f000 - 0x1654fff +libardourcp.dylib ??? (???) <110654e69adccdad08308f77bf168045> /Applications/Ardour6.app/Contents/lib/libardourcp.dylib\
 0x1667000 - 0x168affb +libwaveview.dylib ??? (???) <105e1b3cc6ee77f20af559255af1a657> /Applications/Ardour6.app/Contents/lib/libwaveview.dylib\
 0x1698000 - 0x2246ff3 +libardour.dylib ??? (???) <5ec1554a657769bb72ff73623ead19d7> /Applications/Ardour6.app/Contents/lib/libardour.dylib\
 0x2735000 - 0x2790ff7 +libmidipp.dylib ??? (???) <5b2532f6bd9a1692f4ab57575548d51a> /Applications/Ardour6.app/Contents/lib/libmidipp.dylib\
 0x27b8000 - 0x2804ff3 +libevoral.dylib ??? (???) <3b3b6c5b5c605de4475dfc7194d3b93a> /Applications/Ardour6.app/Contents/lib/libevoral.dylib\
 0x2824000 - 0x284dffb +libaudiographer.dylib ??? (???) <075399552694714f8f2f7efbf10f6c8f> /Applications/Ardour6.app/Contents/lib/libaudiographer.dylib\
 0x2861000 - 0x2871ff7 +libptformat.dylib ??? (???) <f3a46a3139315f873458f5f038c460f4> /Applications/Ardour6.app/Contents/lib/libptformat.dylib\
 0x2876000 - 0x28cbfff +libcanvas.dylib ??? (???) <8d65a9542f3d914f01c8f8d757c15dd4> /Applications/Ardour6.app/Contents/lib/libcanvas.dylib\
 0x28f7000 - 0x296dfff +libwidgets.dylib ??? (???) <7532fef26e9a49ec95db23c082609761> /Applications/Ardour6.app/Contents/lib/libwidgets.dylib\
 0x29e0000 - 0x2a4fff3 +libgtkmm2ext.dylib ??? (???) <742624b5b4a4a39c4029b0ef41a7341c> /Applications/Ardour6.app/Contents/lib/libgtkmm2ext.dylib\
 0x2a94000 - 0x2afeffb +libpbd.dylib ??? (???) <dda6091eba49801e2d92e99bd1f5ca34> /Applications/Ardour6.app/Contents/lib/libpbd.dylib\
 0x2b30000 - 0x2b34fff +libtemporal.dylib ??? (???) <df3bdd770c283a6d6885901bce03ba40> /Applications/Ardour6.app/Contents/lib/libtemporal.dylib\
 0x2b37000 - 0x2b48fff +libappleutility.dylib ??? (???) <683b96763d3371847950730fcf8cf7ec> /Applications/Ardour6.app/Contents/lib/libappleutility.dylib\
 0x2b50000 - 0x2b94fff +libFLAC.8.dylib ??? (???) <9e24c26349a1c0b6a2a9efa3fa9f9479> /Applications/Ardour6.app/Contents/lib/libFLAC.8.dylib\
 0x2b9f000 - 0x2be1fff +libfontconfig.1.dylib ??? (???) <bfd176eeaa696a9939132710c201f37b> /Applications/Ardour6.app/Contents/lib/libfontconfig.1.dylib\
 0x2beb000 - 0x2c8bff7 +libfreetype.6.dylib ??? (???) <8c000e305a14007f5d8f806c615f1f94> /Applications/Ardour6.app/Contents/lib/libfreetype.6.dylib\
 0x2ca1000 - 0x2ce9fff +libglibmm-2.4.1.dylib ??? (???) <1249f17141ce2f079dd70292020982a9> /Applications/Ardour6.app/Contents/lib/libglibmm-2.4.1.dylib\
 0x2d21000 - 0x2d64fff +libgobject-2.0.0.dylib ??? (???) <9adc874cdb4a5bca537fe35f25e8ebe1> /Applications/Ardour6.app/Contents/lib/libgobject-2.0.0.dylib\
 0x2d78000 - 0x2eb3ff7 +libglib-2.0.0.dylib ??? (???) <0e99f3a397c73054cce885d5164c9a7a> /Applications/Ardour6.app/Contents/lib/libglib-2.0.0.dylib\
 0x2edd000 - 0x2fbfff7 +libiconv.2.dylib ??? (???) <6e08b55796ce19a486c8246d27ea2806> /Applications/Ardour6.app/Contents/lib/libiconv.2.dylib\
 0x2fc9000 - 0x2fccff3 +libsigc-2.0.0.dylib ??? (???) <1cab5722f71055c6e7e4ac8bc7a27a8e> /Applications/Ardour6.app/Contents/lib/libsigc-2.0.0.dylib\
 0x2fd0000 - 0x2fd0ff1 +libgthread-2.0.0.dylib ??? (???) <1f0d3fdd00a9f8beed55ac76ac7e2ba5> /Applications/Ardour6.app/Contents/lib/libgthread-2.0.0.dylib\
 0x2fd3000 - 0x33b4ff3 +libgtk-quartz-2.0.0.dylib ??? (???) <a72ad5d114ad16fb2baaf563acef9a2d> /Applications/Ardour6.app/Contents/lib/libgtk-quartz-2.0.0.dylib\
 0x346f000 - 0x34f9ff7 +libgdk-quartz-2.0.0.dylib ??? (???) <db2ffba6ecf200b8713b6ca011fe73b3> /Applications/Ardour6.app/Contents/lib/libgdk-quartz-2.0.0.dylib\
 0x351e000 - 0x352bff7 +libpangocairo-1.0.0.dylib ??? (???) <8564c1b750cc1b136c80f7ea73503b85> /Applications/Ardour6.app/Contents/lib/libpangocairo-1.0.0.dylib\
 0x3535000 - 0x3578ff7 +libpango-1.0.0.dylib ??? (???) <2e4d9cbbd0e649cffcc90bca89174ecf> /Applications/Ardour6.app/Contents/lib/libpango-1.0.0.dylib\
 0x3589000 - 0x35a8ff9 +libatk-1.0.0.dylib ??? (???) <ae73ca851b55b7c587c21f5fc3d7bed0> /Applications/Ardour6.app/Contents/lib/libatk-1.0.0.dylib\
 0x35b6000 - 0x369dff7 +libcairo.2.dylib ??? (???) <0b4f9b600fbdfc11544a12196b1449f7> /Applications/Ardour6.app/Contents/lib/libcairo.2.dylib\
 0x36c2000 - 0x36f9ff7 +libgdk_pixbuf-2.0.0.dylib ??? (???) <c74466e237af0b8b7f4c789278043d5f> /Applications/Ardour6.app/Contents/lib/libgdk_pixbuf-2.0.0.dylib\
 0x3707000 - 0x384effb +libgio-2.0.0.dylib ??? (???) <56232cefd6691ef19b73ae9ef81b9107> /Applications/Ardour6.app/Contents/lib/libgio-2.0.0.dylib\
 0x38b0000 - 0x38b3ff4 +libogg.0.dylib ??? (???) <b2f391854f6820e409580a66d907d5fe> /Applications/Ardour6.app/Contents/lib/libogg.0.dylib\
 0x38b6000 - 0x3921ff7 +libcurl.4.dylib ??? (???) <66ff92fed0e5d47461e62d4cbfb2b2c3> /Applications/Ardour6.app/Contents/lib/libcurl.4.dylib\
 0x3930000 - 0x3ad6ff7 +libgtkmm-2.4.1.dylib ??? (???) <5e9cc9b034dd88130a0141e7681ce24a> /Applications/Ardour6.app/Contents/lib/libgtkmm-2.4.1.dylib\
 0x3cc8000 - 0x3cf4ffb +libatkmm-1.6.1.dylib ??? (???) <9894636e623587e8e29f8cbc19e0de29> /Applications/Ardour6.app/Contents/lib/libatkmm-1.6.1.dylib\
 0x3d15000 - 0x3d3dff1 +libgdkmm-2.4.1.dylib ??? (???) <40840f6ccfc467c75b5643d379655903> /Applications/Ardour6.app/Contents/lib/libgdkmm-2.4.1.dylib\
 0x3d63000 - 0x3e45fff +libgiomm-2.4.1.dylib ??? (???) <8d4a9aed07baacb067ab9487786dda44> /Applications/Ardour6.app/Contents/lib/libgiomm-2.4.1.dylib\
 0x3f02000 - 0x3f16fff +libpangomm-1.4.1.dylib ??? (???) <43742efb71ceb1dd20d12fb48aa9bdb7> /Applications/Ardour6.app/Contents/lib/libpangomm-1.4.1.dylib\
 0x3f2c000 - 0x3f43fff +libcairomm-1.0.1.dylib ??? (???) <3639b202678867b7f786fe7145c093ef> /Applications/Ardour6.app/Contents/lib/libcairomm-1.0.1.dylib\
 0x3f55000 - 0x4019ffb +libfftw3f.3.dylib ??? (???) <e30f22de9ffb5852718241c89795bee5> /Applications/Ardour6.app/Contents/lib/libfftw3f.3.dylib\
 0x402f000 - 0x4032ff7 +libfftw3f_threads.3.dylib ??? (???) <46cee3a904ea870bfa97d1fb4e7fec5c> /Applications/Ardour6.app/Contents/lib/libfftw3f_threads.3.dylib\
 0x4036000 - 0x4043fff +liblo.7.dylib ??? (???) <304fd50c139f0903a7bb873bd3db1ddf> /Applications/Ardour6.app/Contents/lib/liblo.7.dylib\
 0x4048000 - 0x40e4ff7 +libtag.1.dylib ??? (???) <bc5ca0e3d295dd2ff4094b0bfcadb8e1> /Applications/Ardour6.app/Contents/lib/libtag.1.dylib\
 0x4143000 - 0x42c1fff +libxml2.2.dylib ??? (???) <79b4b5942bcf9bcfcce3609d60648305> /Applications/Ardour6.app/Contents/lib/libxml2.2.dylib\
 0x42f2000 - 0x4305ffb +liblilv-0.dylib ??? (???) <75d553801f286ceac0bd9632d326b950> /Applications/Ardour6.app/Contents/lib/liblilv-0.dylib\
 0x430c000 - 0x4314ff9 +libsratom-0.dylib ??? (???) <765c69fc1fdc14e5a6885dadbd4d252b> /Applications/Ardour6.app/Contents/lib/libsratom-0.dylib\
 0x4318000 - 0x4321ffb +libsord-0.dylib ??? (???) <e313d1fc91105fe630bec473a3b4c9d1> /Applications/Ardour6.app/Contents/lib/libsord-0.dylib\
 0x4325000 - 0x433aff7 +libserd-0.dylib ??? (???) <2756b4d21f1c5c13aa2356957be6357c> /Applications/Ardour6.app/Contents/lib/libserd-0.dylib\
 0x433e000 - 0x4368ffb +librubberband.dylib ??? (???) <049d20a31e96d8929fc058dec2ceeb2d> /Applications/Ardour6.app/Contents/lib/librubberband.dylib\
 0x437a000 - 0x4385ff7 +libaubio.2.dylib ??? (???) <e461a7f6f312c45223e342ea95daef55> /Applications/Ardour6.app/Contents/lib/libaubio.2.dylib\
 0x438a000 - 0x438fffa +liblrdf.2.dylib ??? (???) <5ae7e041051de77b0398d6a5b99ec515> /Applications/Ardour6.app/Contents/lib/liblrdf.2.dylib\
 0x439b000 - 0x4445ff7 +libarchive.13.dylib ??? (???) <803090821027c42e4be7530918ec2cc7> /Applications/Ardour6.app/Contents/lib/libarchive.13.dylib\
 0x445b000 - 0x446fff7 +libvamp-sdk.dylib ??? (???) <b32749192d07416f5456cbeaed34f75a> /Applications/Ardour6.app/Contents/lib/libvamp-sdk.dylib\
 0x4478000 - 0x44a7ff7 +libvamp-hostsdk.dylib ??? (???) <14e24b0809685c20b6277ddc714899ca> /Applications/Ardour6.app/Contents/lib/libvamp-hostsdk.dylib\
 0x44bd000 - 0x44bfffa +libsuil-0.dylib ??? (???) <4f913c628faaa2de0a7e53d938452594> /Applications/Ardour6.app/Contents/lib/libsuil-0.dylib\
 0x44c2000 - 0x4529ffb +libstdc++.6.dylib ??? (???) <a4e9b10268b3ffac26d0296499b24e8e> /Applications/Ardour6.app/Contents/lib/libstdc++.6.dylib\
 0x457e000 - 0x45e7ff7 +libsndfile.1.dylib ??? (???) <7d6a9de509cad292a473b410c91cd026> /Applications/Ardour6.app/Contents/lib/libsndfile.1.dylib\
 0x45f9000 - 0x461effb +libvorbis.0.dylib ??? (???) <b92b6edfdba67fbea543c79d35f749e6> /Applications/Ardour6.app/Contents/lib/libvorbis.0.dylib\
 0x4626000 - 0x4696ffb +libvorbisenc.2.dylib ??? (???) <8bcdc019f29e391b28e3656e327aeefb> /Applications/Ardour6.app/Contents/lib/libvorbisenc.2.dylib\
 0x46d5000 - 0x483effb +libsamplerate.0.dylib ??? (???) <deed6abae522909cc4058d20a8524fa7> /Applications/Ardour6.app/Contents/lib/libsamplerate.0.dylib\
 0x4841000 - 0x4842ff3 +libgmodule-2.0.0.dylib ??? (???) <1dced93a72939a1993ad7a042f6ba80a> /Applications/Ardour6.app/Contents/lib/libgmodule-2.0.0.dylib\
 0x4845000 - 0x4849ff3 +libffi.6.dylib ??? (???) <4ede02a89d40bbc14a9b9c5cad52f99e> /Applications/Ardour6.app/Contents/lib/libffi.6.dylib\
 0x484c000 - 0x486affe +libz.1.dylib ??? (???) <b85114989e1aa6662dfb72cbef65666b> /Applications/Ardour6.app/Contents/lib/libz.1.dylib\
 0x486e000 - 0x4891ffb +liblzma.5.dylib ??? (???) <eb72c42c232262750b0f98851d62162e> /Applications/Ardour6.app/Contents/lib/liblzma.5.dylib\
 0x4897000 - 0x4897fff +libcharset.1.dylib ??? (???) <a08a1d2cf0e88dc20b45c58a7f8bfc72> /Applications/Ardour6.app/Contents/lib/libcharset.1.dylib\
 0x489a000 - 0x48dcffb +libssl3.dylib ??? (???) <c510815bfca7076fe76d255f3dc32cad> /Applications/Ardour6.app/Contents/lib/libssl3.dylib\
 0x48ef000 - 0x490dffb +libsmime3.dylib ??? (???) <e404059bd860ba1b97971fe8871b2624> /Applications/Ardour6.app/Contents/lib/libsmime3.dylib\
 0x491b000 - 0x4a10ffb +libnss3.dylib ??? (???) <45f66dd359c0107046729366f52aa608> /Applications/Ardour6.app/Contents/lib/libnss3.dylib\
 0x4a46000 - 0x4a50fff +libplds4.dylib ??? (???) <21fbadeb63ed2fc0d591a2b67b4c0163> /Applications/Ardour6.app/Contents/lib/libplds4.dylib\
 0x4a57000 - 0x4a63fff +libplc4.dylib ??? (???) <a5745b0a7d1ed2250ab97374de425f8e> /Applications/Ardour6.app/Contents/lib/libplc4.dylib\
 0x4a6b000 - 0x4abdff7 +libnspr4.dylib ??? (???) <b87c5a59e73fa0c56804680989f6daf8> /Applications/Ardour6.app/Contents/lib/libnspr4.dylib\
 0x4ae3000 - 0x4afeffb +libnssutil3.dylib ??? (???) <4064ae61ee5df074eb12e235d6b4865a> /Applications/Ardour6.app/Contents/lib/libnssutil3.dylib\
 0x4b0d000 - 0x4bd8fff +libfftw3.3.dylib ??? (???) <3bf45af6e2b54fcf00cd18a1a4316267> /Applications/Ardour6.app/Contents/lib/libfftw3.3.dylib\
 0x4bed000 - 0x4c0eff1 libmx.A.dylib ??? (???) /usr/lib/libmx.A.dylib\
 0x4c16000 - 0x4c60fff +libraptor2.0.dylib ??? (???) <3cbc35ff0a36874e2611453810ec9878> /Applications/Ardour6.app/Contents/lib/libraptor2.0.dylib\
 0x4c76000 - 0x4caafff +libxslt.1.dylib ??? (???) <640274827039c12c886906286004843a> /Applications/Ardour6.app/Contents/lib/libxslt.1.dylib\
 0x4cb4000 - 0x4cc2ffb +libpangoft2-1.0.0.dylib ??? (???) <471adf7c887622c45e8cc7738e71888c> /Applications/Ardour6.app/Contents/lib/libpangoft2-1.0.0.dylib\
 0x4ccb000 - 0x4d5dffe +libharfbuzz.0.dylib ??? (???) <84b6d5d4ac8408bec90b14371f4eb504> /Applications/Ardour6.app/Contents/lib/libharfbuzz.0.dylib\
 0x4d83000 - 0x4de5ff7 +libpixman-1.0.dylib ??? (???) <4e35ace1c5d1bc24ecfa5eb626db2f2c> /Applications/Ardour6.app/Contents/lib/libpixman-1.0.dylib\
 0x4df6000 - 0x4dfffff +libuuid.16.dylib ??? (???) <5f2f65f0728b2c4d143b95055407fdd2> /Applications/Ardour6.app/Contents/lib/libuuid.16.dylib\
 0x4e03000 - 0x4e32ffb +libpng16.16.dylib ??? (???) <5a9465551ac1e717693def3ae6a6c785> /Applications/Ardour6.app/Contents/lib/libpng16.16.dylib\
 0x4e3a000 - 0x4ea0ff7 +libtiff.5.dylib ??? (???) <3c2d439c3eb214c1f9372e9f4edf7167> /Applications/Ardour6.app/Contents/lib/libtiff.5.dylib\
 0x4ead000 - 0x4ee1ff5 +libjpeg.9.dylib ??? (???) <2776b14585512e6b24189735e2ce2a36> /Applications/Ardour6.app/Contents/lib/libjpeg.9.dylib\
 0x5808000 - 0x5865ff3 +libardour_cc121.dylib ??? (???) <30d4f80155ac433d1250aaed02be24f2> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_cc121.dylib\
 0x588e000 - 0x58c2fff +libardour_contourdesign.dylib ??? (???) <62a451e5ae0d91cb54979030e2fd76b9> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_contourdesign.dylib\
 0x58e5000 - 0x58f8ff3 +libusb-1.0.0.dylib ??? (???) <4db06b8242db34a99103dab6948169ee> /Applications/Ardour6.app/Contents/lib/libusb-1.0.0.dylib\
 0x63c6000 - 0x63cffff com.apple.iokit.IOUSBLib 3.4.9 (3.4.9) <d8e92abec3e3d0569d298799e68bfbee> /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle/Contents/MacOS/IOUSBLib\
 0x63d8000 - 0x63e6ff7 +libpan1in2out.dylib ??? (???) <19341b8a3246a1fa254ff17740a55551> /Applications/Ardour6.app/Contents/lib/panners/libpan1in2out.dylib\
 0x6800000 - 0x6860ff3 +libardour_faderport.dylib ??? (???) <da10965271ffe2fa74b8b966c628fbef> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_faderport.dylib\
 0x688c000 - 0x6928ff7 +libardour_faderport16.dylib ??? (???) <241adc82355b742e8b6e020d9fe1a034> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_faderport16.dylib\
 0x6973000 - 0x6a0affb +libardour_faderport2.dylib ??? (???) <e290a59bb20db4d03854059501bb87a9> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_faderport2.dylib\
 0x6a52000 - 0x6aeeffb +libardour_faderport8.dylib ??? (???) <b494f261a06eb0952b08af3af9a1a4ca> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_faderport8.dylib\
 0x6b38000 - 0x6b97fff +libardour_generic_midi.dylib ??? (???) <0621f9f74cafb87d398b6a6e3f81a13f> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_generic_midi.dylib\
 0x6bc8000 - 0x6c3cfff +libardour_launch_control_xl.dylib ??? (???) <6a36c8d311ab0ed67b27f5f05a43365f> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_launch_control_xl.dylib\
 0x6c71000 - 0x6d43ff7 +libardour_mcp.dylib ??? (???) <5d3466094644be8ea68f43fd0d8d98c5> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_mcp.dylib\
 0x6da4000 - 0x6ed4ffb +libardour_osc.dylib ??? (???) <f2d8821c792e1e94c0da6853800426a0> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_osc.dylib\
 0x6f42000 - 0x6ffeff7 +libardour_push2.dylib ??? (???) <b241a31d3836dfe6fb39610f6c02ea87> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_push2.dylib\
 0x7049000 - 0x70e4ff7 +libardour_us2400.dylib ??? (???) <f7dd2e8a9a600718d319bbb0f5a8578d> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_us2400.dylib\
 0x7131000 - 0x718fff3 +libardour_websockets.dylib ??? (???) <d8d6c8de31977cce1ef5318231371ee3> /Applications/Ardour6.app/Contents/lib/surfaces/libardour_websockets.dylib\
 0x71bf000 - 0x71f7ffb +libwebsockets.16.dylib ??? (???) <1dfdac175648a996b80ac60fa377907a> /Applications/Ardour6.app/Contents/lib/libwebsockets.16.dylib\
 0x7203000 - 0x7212fff +libpan2in2out.dylib ??? (???) <6e4f97dc6ba4e40761987555e1607674> /Applications/Ardour6.app/Contents/lib/panners/libpan2in2out.dylib\
 0x7219000 - 0x7227ffb +libpanbalance.dylib ??? (???) <accbd204542daaacecbfe86956b32cc9> /Applications/Ardour6.app/Contents/lib/panners/libpanbalance.dylib\
 0x722e000 - 0x724aff3 +libpanvbap.dylib ??? (???) <22e49f76ebe33ee080949171c0f8b91f> /Applications/Ardour6.app/Contents/lib/panners/libpanvbap.dylib\
 0x728f000 - 0x72b9ff7 +libcoreaudio_backend.dylib ??? (???) <cdec9d117adf286f33afe117fb35198d> /Applications/Ardour6.app/Contents/lib/backends/libcoreaudio_backend.dylib\
 0x72cc000 - 0x72e8ffb com.apple.audio.midi.CoreMIDI 1.6.1 (42) /System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI\
 0x72fe000 - 0x731ffff libexpat.1.dylib ??? (???) <e955fbf7296287c4d40694cf7dffd64f> /usr/lib/libexpat.1.dylib\
 0x7326000 - 0x7351ff7 +libdummy_audiobackend.dylib ??? (???) <bb5cc5a64a0bb9052ca0f24059a641d6> /Applications/Ardour6.app/Contents/lib/backends/libdummy_audiobackend.dylib\
0x1acee000 - 0x1ad17ff7 +libclearlooks.so ??? (???) <8db73caeb8ea9a60f84a57775ecd6a6f> /Applications/Ardour6.app/Contents/lib/gtkengines/engines/libclearlooks.so\
0x1b081000 - 0x1b085fff com.apple.audio.AudioIPCPlugIn 1.0.6 (1.0.6) <ac58ebbd8e1179ff891b7a60b2ba33cc> /System/Library/Extensions/AudioIPCDriver.kext/Contents/Resources/AudioIPCPlugIn.bundle/Contents/MacOS/AudioIPCPlugIn\
0x1b08a000 - 0x1b08cffb com.digidesign.usb.elevenrack.driver.hal-plugin ??? (1.0.1) <5a336d76d12e873253674cfc08c26af5> /System/Library/Extensions/DigidesignElevenRack.kext/Contents/PlugIns/HAL Plugin.bundle/Contents/MacOS/HAL Plugin\
0x1b08f000 - 0x1b090ffd com.apple.aoa.halplugin 2.5.8 (2.5.8f1) <0d6be2c83d2f582060ba48293d283cdd> /System/Library/Extensions/IOAudioFamily.kext/Contents/PlugIns/AOAHALPlugin.bundle/Contents/MacOS/AOAHALPlugin\
0x1b094000 - 0x1b0b7ffb +com.digidesign.digidesign.DigiCoreAudioPlugIn 8.0.1cs2 (8.0.1f515) <2f18474e3707ee8db032545d000a923c> /Library/Audio/Plug-Ins/HAL/Digidesign CoreAudio.plugin/Contents/MacOS/Digidesign CoreAudio\
0x1c6c0000 - 0x1c8a7ff3 com.apple.RawCamera.bundle 2.1.3 (537) <d485a6c33b017f6535c72b77ff4a8a84> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera\
0x1ee63000 - 0x1ee64ffb ATSHI.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/ATSHI.dylib\
0x70000000 - 0x700cdff3 com.apple.audio.units.Components 1.5.2 (1.5.2) /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio\
0x8fe00000 - 0x8fe30c23 dyld 97.1 (???) <89a0055b0e7ea2db881b73c6e63bc774> /usr/lib/dyld\
0x90003000 - 0x900d6fff com.apple.CoreServices.OSServices 228.1 (228.1) <b957e9c8b8ca9c3e03b99d2ad4b31aa2> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices\
0x900d7000 - 0x90653ff3 com.apple.CoreGraphics 1.409.8 (???) <e0bf5ff8fa51b99663fcb860bf44a7ed> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics\
0x907f6000 - 0x90871fff com.apple.SearchKit 1.2.2 (1.2.2) <a9d0033a5e1e55b5e382e52fe578d734> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit\
0x90872000 - 0x908abfff com.apple.SystemConfiguration 1.9.2 (1.9.2) <21dee7ffd93306032f911b5ef3fdbab3> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration\
0x908ac000 - 0x90a4cfe3 libSystem.B.dylib ??? (???) <7dc28e19e1aac16b29cbd7c5d9ce9638> /usr/lib/libSystem.B.dylib\
0x90a4d000 - 0x90a5bff3 com.apple.opengl 1.5.10 (1.5.10) <54bae289e544387ce7997a4a05e70aa9> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL\
0x90a5c000 - 0x90ab9ffb com.apple.HIServices 1.7.1 (???) <a6c5c0bf2d68aeb453dbc493b7d0c8d9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices\
0x90aba000 - 0x90abafff com.apple.Carbon 136 (136) <a85de0e96c9f876edec85e40fb691722> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon\
0x90abb000 - 0x90abbfff com.apple.Accelerate 1.4.2 (Accelerate 1.4.2) /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate\
0x90abc000 - 0x90b23ffb libstdc++.6.dylib ??? (???) <a4e9b10268b3ffac26d0296499b24e8e> /usr/lib/libstdc++.6.dylib\
0x90b24000 - 0x90b59fff com.apple.AE 402.3 (402.3) <75725936d014fd3ca2553d18b784b99b> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE\
0x90b5a000 - 0x90b79fff com.apple.Accelerate.vecLib 3.4.2 (vecLib 3.4.2) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib\
0x90b7a000 - 0x90ea3fe7 libLAPACK.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib\
0x90ea4000 - 0x90f29fff libsqlite3.0.dylib ??? (???) <daf55b073488086ef5b9a3781be53f14> /usr/lib/libsqlite3.0.dylib\
0x90f40000 - 0x91036ffc libiconv.2.dylib ??? (???) <05ae1fcc97404173b2f9caef8f8be797> /usr/lib/libiconv.2.dylib\
0x91037000 - 0x9117fff3 libicucore.A.dylib ??? (???) <bdab570d90979c4f601131d442f84720> /usr/lib/libicucore.A.dylib\
0x91180000 - 0x91180fff com.apple.audio.units.AudioUnit 1.5 (1.5) /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit\
0x91181000 - 0x911abff7 libssl.0.9.7.dylib ??? (???) <2aafe2efc0fb9868cb630ac50b5892b4> /usr/lib/libssl.0.9.7.dylib\
0x911ac000 - 0x911b7ffb libgcc_s.1.dylib ??? (???) <ea47fd375407f162c76d14d64ba246cd> /usr/lib/libgcc_s.1.dylib\
0x921b6000 - 0x92302fff com.apple.ImageIO.framework 2.0.9 (2.0.9) <d12782e17c25bb9679c5d352ac202fcd> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO\
0x92303000 - 0x92303ffb com.apple.installserver.framework 1.0 (8) /System/Library/PrivateFrameworks/InstallServer.framework/Versions/A/InstallServer\
0x9240a000 - 0x92437fff libGL.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib\
0x92510000 - 0x92515ff6 libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib\
0x92516000 - 0x92535fff com.apple.vecLib 3.4.2 (vecLib 3.4.2) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib\
0x92605000 - 0x9262effb com.apple.shortcut 1.0.1 (1.0) <8da20d176ab4cf71cdf4f79b477fe0e7> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut\
0x9268b000 - 0x9268cff8 com.apple.ApplicationServices 34 (34) <6aa5ee485bb2e656531b3505932b845f> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices\
0x9268d000 - 0x92e03fff com.apple.AppKit 6.5.9 (949.54) <687f1742c249d7c9268e2eb57713cef6> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit\
0x92e04000 - 0x92fedffb com.apple.security 5.0.7 (1) <2c8ae7414f8d113a695da92950753ad9> /System/Library/Frameworks/Security.framework/Versions/A/Security\
0x92fee000 - 0x93076fff com.apple.ink.framework 101.3 (86) <66a99ad6bc695390a66dd24789e23dcc> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink\
0x93077000 - 0x93131fff libcrypto.0.9.7.dylib ??? (???) <1d82e65c85d65367f3b6b06355c89c9b> /usr/lib/libcrypto.0.9.7.dylib\
0x93132000 - 0x93151fff libresolv.9.dylib ??? (???) <c5c72e1cf61cb844163156956a1d8407> /usr/lib/libresolv.9.dylib\
0x93152000 - 0x93152ff8 com.apple.Cocoa 6.5 (???) <e9a4f1c636d00893db0494c4040176ba> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa\
0x93192000 - 0x93199ffb com.apple.print.framework.Print 218.0.3 (220.2) <021d2263007c538fd9e6b52e66a2623d> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print\
0x9319a000 - 0x93222ffb com.apple.audio.CoreAudio 3.1.2 (3.1.2) <6fc8a8cb43506b57b951da899a55d3b9> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio\
0x93223000 - 0x93264ffb libTIFF.dylib ??? (???) <6910f0c75ed82f98ea8ebf601136ce47> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib\
0x93265000 - 0x93296fff com.apple.coreui 1.2 (62) /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI\
0x932d9000 - 0x93707ffe libGLProgrammability.dylib ??? (???) <5d52750ec9e438b25d3a4db51361fa2b> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib\
0x93708000 - 0x93a6dffe com.apple.QuartzCore 1.5.8 (1.5.8) <60e54cfb861dc5e66bb4f263a192d558> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore\
0x93a6e000 - 0x93b21ffc com.apple.CFNetwork 438.16 (438.16) <a5b69f31ef4596c8f680772120e3eb08> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork\
0x93b53000 - 0x93b60fff libbz2.1.0.dylib ??? (???) <e25cbe0b7e3f3ff41ace9428e57e304c> /usr/lib/libbz2.1.0.dylib\
0x93b61000 - 0x93b81ff7 libJPEG.dylib ??? (???) <3508b46417ed11d88ae1cea92c7fe756> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib\
0x93cef000 - 0x93cf2fff com.apple.help 1.1 (36) <7106d6e074a3b9835ebf1e6cc6c822ce> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help\
0x93da3000 - 0x93e53fff edu.mit.Kerberos 6.0.15 (6.0.15) <870d4f0c841af131a04737468ba803d6> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos\
0x9524b000 - 0x9529afff libGLImage.dylib ??? (???) <2e1f2a2625064149d209ec19e52d0384> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib\
0x952ac000 - 0x952bffff com.apple.LangAnalysis 1.6.5 (1.6.5) <2a661ad6e432dd62dd831e234904061f> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis\
0x95326000 - 0x95375fff com.apple.Metadata 10.5.8 (398.26) <1a261534027b9d1518327d1fabe1182b> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata\
0x953c5000 - 0x953ccfff com.apple.CommonPanels 1.2.4 (85) <0d1256175c5512c911ede094d767acfe> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels\
0x953cd000 - 0x953f8ff7 libauto.dylib ??? (???) <a64d088b2d17e013b9ee5a08d3a20d33> /usr/lib/libauto.dylib\
0x953f9000 - 0x9550dffa com.apple.vImage 3.0 (3.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage\
0x95525000 - 0x955a7fff com.apple.print.framework.PrintCore 5.5.4 (245.6) <3cde2550ec10348b7162d2b6cb0dfc67> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore\
0x955a8000 - 0x955b0ffb libCGATS.A.dylib ??? (???) <4766ee761032d31b0ad1855ec396e155> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib\
0x955b1000 - 0x955e6ff3 com.apple.LDAPFramework 1.4.5 (110) <0cf1d114abaf598355afb6537b76874e> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP\
0x9577e000 - 0x9584eff7 com.apple.ColorSync 4.5.4 (4.5.4) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync\
0x9584f000 - 0x95858fff com.apple.DiskArbitration 2.2.1 (2.2.1) <682f5c45591e8c4a89c79e384e2c49af> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration\
0x959a8000 - 0x95a0affb com.apple.htmlrendering 68 (1.1.3) <e852db1c007de975fae2f0c2769c88ef> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering\
0x95ac1000 - 0x95b5bff7 com.apple.ApplicationServices.ATS 3.8 (???) <68fbf8a95392317d611f00c709955c8a> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS\
0x95bc2000 - 0x95c23fff com.apple.CoreText 2.0.5 (???) <0a3d84caa94b9d338921e464780dd350> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText\
0x95c2a000 - 0x95d0dfff libobjc.A.dylib ??? (???) <a1d4be2eed463c6799b6a1447fde72ba> /usr/lib/libobjc.A.dylib\
0x95d0e000 - 0x95d12ffe libGIF.dylib ??? (???) <e4f0002b104c2a2cb5b4327e906e544f> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib\
0x95d13000 - 0x95dc3fff com.apple.QD 3.11.57 (???) <e74b370c6f81fc00e8936f5cf7c8ebe0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD\
0x95dc4000 - 0x95e53fff com.apple.DesktopServices 1.4.9 (1.4.9) <07d08e199716420b6df8e23ff91b5d2d> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv\
0x95e54000 - 0x95e7bfff libcups.2.dylib ??? (???) <8b27a8d2477e9b253a664ad72ebc6ae5> /usr/lib/libcups.2.dylib\
0x961aa000 - 0x961f1fff com.apple.NavigationServices 3.5.2 (163) <453fd79dd63debad4908dcc726f9aa04> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices\
0x961f2000 - 0x961fdff9 com.apple.helpdata 1.0.1 (14.2) /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData\
0x961fe000 - 0x96200ffd libRadiance.dylib ??? (???) <50c07ca861b00fa063aec748b5f4d786> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib\
0x96201000 - 0x967bbfff libBLAS.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib\
0x96827000 - 0x9682affb com.apple.securityhi 3.0 (30817) <08b7dd59bdfadfc2e73cd708bb8bdc31> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI\
0x9682b000 - 0x96915fff libxml2.2.dylib ??? (???) <9d05a5451084c8cd78e3f4722e2c2960> /usr/lib/libxml2.2.dylib\
0x96961000 - 0x9696dff3 com.apple.audio.SoundManager 3.9.2 (3.9.2) <79588842bcaf6c747a95b2120304397a> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound\
0x9696e000 - 0x96986ffb com.apple.DictionaryServices 1.0.0 (1.0.0) <fe37191e732eeb66189185cd000a210b> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices\
0x96987000 - 0x96c89ffb com.apple.CoreServices.CarbonCore 786.16 (786.16) <d9a357a3be5a1bf5969e80db6a4b3327> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore\
0x96cd4000 - 0x96d5efff libvMisc.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib\
0x96d71000 - 0x96e96ff3 com.apple.CoreFoundation 6.5.7 (476.19) <dee0f0024f3bf976cfa0a0816e8aa338> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation\
0x96e97000 - 0x96f30fc3 libvDSP.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib\
0x96f31000 - 0x96f4dffb com.apple.openscripting 1.2.8 (???) <01f86cdb8f7347d2f3f13066e954acb6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting\
0x96f4e000 - 0x96f5ffff libsasl2.2.dylib ??? (???) <e4bcc0c9e50ee651e271ff2a8c3f03cd> /usr/lib/libsasl2.2.dylib\
0x96f60000 - 0x971a6ffb com.apple.Foundation 6.5.9 (677.26) <c30e4aea51bbae480d4550cd53abb441> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation\
0x971d9000 - 0x971ecffb com.apple.speech.synthesis.framework 3.7.1 (3.7.1) <050180a659a3905ea38f2acddcdf7b40> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis\
0x971ed000 - 0x97206ffb com.apple.CoreVideo 1.5.1 (1.5.1) <a5c731b2fb74a3cb718500299f6e4a89> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo\
0x97207000 - 0x972cfffb com.apple.CoreData 100.2 (186.2) <be912ff41bd4506438a71d5665e89069> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData\
0x972d0000 - 0x97365ff7 com.apple.framework.IOKit 1.5.2 (???) <ced0a498252f76a2d2ba9f2a0ae02160> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit\
0x973ad000 - 0x973b8fff com.apple.speech.recognition.framework 3.7.24 (3.7.24) <817174777f7b41bfa3e0cc8974fffbdc> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition\
0x973b9000 - 0x97500ffb com.apple.audio.toolbox.AudioToolbox 1.5.3 (1.5.3) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox\
0x97501000 - 0x97501ffa com.apple.CoreServices 32 (32) <42b6dda539f7411606187335d9eae0c5> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices\
0x97502000 - 0x9753ffff libRIP.A.dylib ??? (???) <7f98bbcfc21f87ba692ae1722bc9ecd7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib\
0x97540000 - 0x97596fff libGLU.dylib ??? (???) <3418ce7ca0863162847f553c15d08674> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib\
0x97597000 - 0x97598fff libffi.dylib ??? (???) <11b77dbce4aa0f0b66d40014230abd1d> /usr/lib/libffi.dylib\
0x97599000 - 0x975a1fff libbsm.dylib ??? (???) <c1fca3cbe3b1c21e9b31bc89b920f34c> /usr/lib/libbsm.dylib\
0x975a2000 - 0x975b0fff libz.1.dylib ??? (???) <1a70dd3594a8c5ad39d785af5da23237> /usr/lib/libz.1.dylib\
0x975b1000 - 0x97648fff com.apple.LaunchServices 292 (292) <06cb373fd960fbc2b4a0201f55c7dd6d> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices\
0x97649000 - 0x97664ffb libPng.dylib ??? (???) <7ba22147e900d2ee6837c2f439302f7f> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib\
0x97669000 - 0x979a2ff7 com.apple.HIToolbox 1.5.6 (???) <a3b713a77c16da495c886463985f1e39> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox\
0x979c2000 - 0x979cffff libCSync.A.dylib ??? (???) <02b13948e78cc30bd9f122a024ed9e17> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib\
0x979d0000 - 0x979f8fff libxslt.1.dylib ??? (???) <82421418f81b9b6c63529215a3612ab0> /usr/lib/libxslt.1.dylib\
0x97af7000 - 0x97b0effb com.apple.ImageCapture 5.0.2 (5.0.2) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture\
0xba900000 - 0xba917ffe libJapaneseConverter.dylib ??? (???) <ddbf52237a078e0b4f6b1a408b4f272a> /System/Library/CoreServices/Encodings/libJapaneseConverter.dylib\
0xfffec000 - 0xfffeffff libobjc.A.dylib ??? (???) /usr/lib/libobjc.A.dylib\
0xffff8000 - 0xffff9703 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib\
\
}

////////////////////////////////////////////////////////////////////////////////////////////////////////////
*************************************************************************
////////////////////////////////////////////////////////////////////////////////////////////////////////////

{\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf540
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww9000\viewh8400\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural

\f0\fs24 \cf0 Process: Ardour6 [140]\
Path: /Applications/Ardour6.app/Contents/MacOS/Ardour6\
Identifier: org.ardour.Ardour6\
Version: 6.6.114 (6.6.114)\
Code Type: PPC (Native)\
Parent Process: launchd [73]\
\
Interval Since Last Report: 13085 sec\
Crashes Since Last Report: 1\
Per-App Interval Since Last Report: 3640 sec\
Per-App Crashes Since Last Report: 1\
\
Date/Time: 2021-03-14 20:46:14.304 +0100\
OS Version: Mac OS X 10.5.8 (9L31a)\
Report Version: 6\
Anonymous UUID: A8127075-910C-4DD8-8E6E-E85153ED6D63\
\
Exception Type: EXC_BAD_ACCESS (SIGSEGV)\
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000fffffff0\
Crashed Thread: 19\
\
Thread 0:\
0 libSystem.B.dylib 0x908ad078 mach_msg_trap + 8\
1 libSystem.B.dylib 0x908b3f9c mach_msg + 56\
2 com.apple.CoreGraphics 0x900f7ff8 _CGSSynchronizeWindowBackingStore + 120\
3 com.apple.CoreGraphics 0x900e9f10 _CGSLockWindow + 3616\
4 com.apple.CoreGraphics 0x900f7b20 CGSDeviceLock + 560\
5 libRIP.A.dylib 0x9751eae0 ripd_Lock + 60\
6 libRIP.A.dylib 0x9751dae8 ripl_BltShape + 492\
7 libRIP.A.dylib 0x97506ed8 ripc_Render + 372\
8 libRIP.A.dylib 0x9750eca0 ripc_DrawRects + 636\
9 com.apple.CoreGraphics 0x900f4a08 CGContextFillRects + 160\
10 com.apple.CoreGraphics 0x9012124c CGContextFillRect + 36\
11 libgdk-quartz-2.0.0.dylib 0x034c680c gdk_window_impl_quartz_begin_paint_region + 428\
12 libgdk-quartz-2.0.0.dylib 0x034a188c gdk_window_begin_paint_region + 524\
13 libgtk-quartz-2.0.0.dylib 0x030d4964 gtk_main_do_event + 1636\
14 libgdk-quartz-2.0.0.dylib 0x034ac410 _gdk_window_process_updates_recurse + 512\
15 libgdk-quartz-2.0.0.dylib 0x034ac350 _gdk_window_process_updates_recurse + 320\
16 libgdk-quartz-2.0.0.dylib 0x034ac350 _gdk_window_process_updates_recurse + 320\
17 libgdk-quartz-2.0.0.dylib 0x034ac350 _gdk_window_process_updates_recurse + 320\
18 libgdk-quartz-2.0.0.dylib 0x034b2514 -[GdkQuartzView drawRect:] + 740\
19 com.apple.AppKit 0x9277cec8 -[NSView _drawRect:clip:] + 3000\
20 com.apple.AppKit 0x9277afd4 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 1424\
21 com.apple.AppKit 0x927774c8 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 2328\
22 libgdk-quartz-2.0.0.dylib 0x034c6a74 _gdk_windowing_after_process_all_updates + 100\
23 libgdk-quartz-2.0.0.dylib 0x0349f35c gdk_window_process_all_updates + 556\
24 libgdk-quartz-2.0.0.dylib 0x0349f3cc gdk_window_update_idle + 12\
25 libgdk-quartz-2.0.0.dylib 0x03470b70 gdk_threads_dispatch + 96\
26 libglib-2.0.0.dylib 0x02db7f80 g_main_dispatch + 976\
27 libglib-2.0.0.dylib 0x02dbb02c g_main_context_iterate + 604\
28 libglib-2.0.0.dylib 0x02dbb210 g_main_loop_run + 400\
29 libgtk-quartz-2.0.0.dylib 0x030d3d7c gtk_main + 220\
30 libgtkmm2ext.dylib 0x02a15a9c Gtkmm2ext::UI::run(Receiver&) + 460\
31 org.ardour.Ardour6 0x0065e358 main + 2200\
32 org.ardour.Ardour6 0x00014c40 start + 64\
33 ??? 0x00000ffc 0 + 4092\
\
Thread 1:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libardour.dylib 0x01f5c578 __ZL16peak_thread_workv + 296\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 2:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libardour.dylib 0x01f5c578 __ZL16peak_thread_workv + 296\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 3:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libardour.dylib 0x016b1c68 ARDOUR::Analyser::work() + 312\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 4:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libardour.dylib 0x016fc318 ARDOUR::AudioEngine::do_reset_backend() + 888\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 5:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libglib-2.0.0.dylib 0x02e1b9e4 g_cond_wait + 180\
3 libardour.dylib 0x016fa3d8 ARDOUR::AudioEngine::do_devicelist_update() + 376\
4 libglibmm-2.4.1.dylib 0x02cb24c8 call_thread_entry_slot + 72\
5 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 6:\
0 libSystem.B.dylib 0x908ad078 mach_msg_trap + 8\
1 libSystem.B.dylib 0x908b3f9c mach_msg + 56\
2 com.apple.CoreFoundation 0x96dda394 CFRunLoopRunSpecific + 1812\
3 com.apple.audio.CoreAudio 0x931bbfa8 HALRunLoop::OwnThread(void*) + 212\
4 com.apple.audio.CoreAudio 0x931bbde4 CAPThread::Entry(CAPThread*) + 104\
5 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 7:\
0 libSystem.B.dylib 0x908ee7b0 kevent + 12\
1 libgio-2.0.0.dylib 0x0380df98 _kqueue_thread_func + 296\
\
Thread 8:\
0 libSystem.B.dylib 0x90910c14 select$DARWIN_EXTSN + 12\
1 libglib-2.0.0.dylib 0x02dcc954 g_poll + 452\
2 libglib-2.0.0.dylib 0x02dbafac g_main_context_iterate + 476\
3 libglib-2.0.0.dylib 0x02dbb2ec glib_worker_main + 156\
4 libglib-2.0.0.dylib 0x02defea8 g_thread_proxy + 168\
5 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 9:\
0 libSystem.B.dylib 0x908b3a8c __semwait_signal + 12\
1 libSystem.B.dylib 0x908f0318 _pthread_cond_wait + 1580\
2 libgdk-quartz-2.0.0.dylib 0x034b9854 select_thread_func + 180\
3 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 10:\
0 libSystem.B.dylib 0x908ad0f8 semaphore_timedwait_signal_trap + 8\
1 libSystem.B.dylib 0x908f0214 _pthread_cond_wait + 1320\
2 com.apple.audio.CoreAudio 0x931cd9f0 HP_IOThread::WorkLoop() + 488\
3 com.apple.audio.CoreAudio 0x931cd7f0 HP_IOThread::ThreadEntry(HP_IOThread*) + 12\
4 com.apple.audio.CoreAudio 0x931bbde4 CAPThread::Entry(CAPThread*) + 104\
5 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 11:\
0 libSystem.B.dylib 0x908ad078 mach_msg_trap + 8\
1 libSystem.B.dylib 0x908b3f9c mach_msg + 56\
2 com.apple.audio.midi.CoreMIDI 0x072ddf34 XServerMachPort::ReceiveMessage(int&, void*, int&) + 88\
3 com.apple.audio.midi.CoreMIDI 0x072cfadc MIDIInPortThread::Run() + 68\
4 com.apple.audio.midi.CoreMIDI 0x072d3104 XThread::RunHelper(void*) + 24\
5 com.apple.audio.midi.CoreMIDI 0x072deaa8 CAPThread::Entry(CAPThread*) + 96\
6 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 12:\
0 libSystem.B.dylib 0x908ad0f8 semaphore_timedwait_signal_trap + 8\
1 libSystem.B.dylib 0x908f0214 _pthread_cond_wait + 1320\
2 libcoreaudio_backend.dylib 0x072a2eb0 ARDOUR::CoreAudioBackend::freewheel_thread() + 544\
3 libcoreaudio_backend.dylib 0x072a31ac __ZL17pthread_freewheelPv + 44\
4 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 13:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libardour.dylib 0x01deb054 ARDOUR::RTTaskList::run() + 36\
2 libardour.dylib 0x01deb69c ARDOUR::RTTaskList::_thread_run(void*) + 44\
3 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 14:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libglib-2.0.0.dylib 0x02d7f9d4 g_atomic_pointer_get + 52\
2 libardour.dylib 0x01deb69c ARDOUR::RTTaskList::_thread_run(void*) + 44\
3 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 15:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libglib-2.0.0.dylib 0x02d7f9d4 g_atomic_pointer_get + 52\
2 libardour.dylib 0x01deb69c ARDOUR::RTTaskList::_thread_run(void*) + 44\
3 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 16:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libardour.dylib 0x0189b528 ARDOUR::Graph::reached_terminal_node() + 88\
2 libardour.dylib 0x0189b218 ARDOUR::Graph::run_one() + 520\
3 libardour.dylib 0x0189bb94 ARDOUR::Graph::main_thread() + 580\
4 libcoreaudio_backend.dylib 0x0729dabc ARDOUR::CoreAudioBackend::coreaudio_process_thread(void*) + 1452\
5 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 17:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libardour.dylib 0x0189b14c ARDOUR::Graph::run_one() + 316\
2 libardour.dylib 0x0189bdf4 ARDOUR::Graph::helper_thread() + 532\
3 libcoreaudio_backend.dylib 0x0729dabc ARDOUR::CoreAudioBackend::coreaudio_process_thread(void*) + 1452\
4 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 18:\
0 libSystem.B.dylib 0x9093eddc sem_wait + 12\
1 libardour.dylib 0x0189b14c ARDOUR::Graph::run_one() + 316\
2 libardour.dylib 0x0189bdf4 ARDOUR::Graph::helper_thread() + 532\
3 libcoreaudio_backend.dylib 0x0729dabc ARDOUR::CoreAudioBackend::coreaudio_process_thread(void*) + 1452\
4 libSystem.B.dylib 0x908eef70 _pthread_start + 316\
\
Thread 19 Crashed:\
0 libSystem.B.dylib 0xffff8c00 __memcpy + 1120 (cpu_capabilities.h:237)\
1 libardour.dylib 0x017c4b94 std::vector<ARDOUR::CaptureInfo*, std::allocator<ARDOUR::Capt
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8614 [ardour] bugs minor always 2021-03-10 00:59 2021-03-10 00:59
Reporter: wargreen Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: External send routing window is open behing the mixer window
Description: When an external send is requested from the detached mixer window, the routing window is open behind the mixer.
No problem when open from the mixer strip in the main window.
Tags:
Steps To Reproduce: Detach the mixer window
Put an external send
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8613 [ardour] bugs minor sometimes 2021-03-09 22:32 2021-03-09 22:32
Reporter: metalmyles Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour Freezes When Moving Track in Windows 10
Description: Ardour sometimes freezes while my session is playing audio, after I move a track region to the right in the edit window.

Typically the session will unfreeze after 5 - 15 seconds, but it does delay for this length. I am working on a computer with a dual core system that isn't fast so I am not sure if that is a factor for this bug. When do this same process in Linux on this same computer, I don't seem to have this issue at all.
Tags: Freeze tracks moving Windows 10
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8610 [ardour] bugs minor sometimes 2021-03-08 13:29 2021-03-08 19:46
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when changing JACK buffer size
Description: Ardour often crashes when changing the JACK buffer size.

Doesn't matter if I use the `jack_bufsize` command, or do this from Ardour's UI.

There's like 30% chance that Ardour will just crash.
Tags: bufsize, crash, jack
Steps To Reproduce:
Additional Information: Thread 1 "ArdourGUI" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffea9c8900 (LWP 28821)]
0x00007fffee45ea51 in unlink_chunk.constprop () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007fffee45ea51 in unlink_chunk.constprop () from /usr/lib/libc.so.6
0000001 0x00007fffee45ec75 in malloc_consolidate () from /usr/lib/libc.so.6
#2 0x00007fffee460b03 in _int_malloc () from /usr/lib/libc.so.6
#3 0x00007fffee4627a1 in malloc () from /usr/lib/libc.so.6
0000004 0x00007ffff324208f in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
0000005 0x00007ffff32423f8 in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
#6 0x00007ffff32443b3 in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
#7 0x00007ffff3230458 in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
0000008 0x00007ffff3225fcc in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
0000009 0x00007ffff3230d48 in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
0000010 0x00007ffff32b47b9 in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
0000011 0x00007ffff31f732e in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
0000012 0x00007ffff32a7bcb in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
0000013 0x00007ffff3262ad3 in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
0000014 0x00007ffff320084a in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
#15 0x00007ffff31f9299 in ?? () from /opt/Ardour-6.6.87/lib/libcairo.so.2
0000016 0x00007ffff31f002a in cairo_stroke () from /opt/Ardour-6.6.87/lib/libcairo.so.2
#17 0x00007fffb37bf2c9 in ?? () from /usr/lib/vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
0000018 0x00007fffb372653f in ?? () from /usr/lib/vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
0000019 0x00007fffb384bdbe in ?? () from /usr/lib/vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
0000020 0x00007fffb384d044 in ?? () from /usr/lib/vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
0000021 0x00007fffb37cb2c7 in ?? () from /usr/lib/vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
0000022 0x00007fffb37ca301 in ?? () from /usr/lib/vst3/Surge.vst3/Contents/x86_64-linux/Surge.so
0000023 0x00005555561499da in ?? ()
#24 0x00007ffff47b95a9 in ?? () from /opt/Ardour-6.6.87/lib/libglib-2.0.so.0
0000025 0x00007ffff47b8a2a in g_main_context_dispatch () from /opt/Ardour-6.6.87/lib/libglib-2.0.so.0
0000026 0x00007ffff47b8dd0 in ?? () from /opt/Ardour-6.6.87/lib/libglib-2.0.so.0
0000027 0x00007ffff47b90f2 in g_main_loop_run () from /opt/Ardour-6.6.87/lib/libglib-2.0.so.0
0000028 0x00007ffff3da93e7 in gtk_main () from /opt/Ardour-6.6.87/lib/libgtk-x11-2.0.so.0
0000029 0x00007ffff5c03a45 in Gtkmm2ext::UI::run(Receiver&) () from /opt/Ardour-6.6.87/lib/libgtkmm2ext.so.0
0000030 0x00005555557f658b in ?? ()
0000031 0x00007fffee3feb25 in __libc_start_main () from /usr/lib/libc.so.6
0000032 0x00005555557fd0da in ?? ()
System Description
Attached Files:
Notes
(0025595)
x42   
2021-03-08 19:46   
Does it also crash when you don't use surge VST3? -- The crash happens there. perhaps the plugin cannot handle it?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8609 [ardour] features minor N/A 2021-03-07 18:28 2021-03-07 18:28
Reporter: magnetophon Platform: Linux  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Record midi using fader next to automation lane
Description: When you put a midi track in record mode and wiggle the ardour on screen pitch bend fader, an empty track gets recorded.
It would be handy if you could record automation this way.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8607 [ardour] bugs minor always 2021-03-05 15:14 2021-03-05 15:14
Reporter: nik Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Large Tempo Maps Hang Ardour
Description: User reported (to Mixbus support) that a specific tempo map they exported from Logic crashes when auditioned and/or imported into Mixbus/Ardour

I was able to reporduce the issue reliably using the provided tempo map with a built version of Ardour on Fedora 33
Tags: tempo
Steps To Reproduce:
Additional Information: Built from Ardour master, last commit was e236c2ab0f5c31f2a7de70b8a8336193c43584ef
System Description
Attached Files: Come Thou Fount Tempo Map.mid (473,828 bytes) 2021-03-05 15:14
https://tracker.ardour.org/file_download.php?file_id=3965&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8605 [ardour] bugs minor have not tried 2021-03-04 16:42 2021-03-04 16:42
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Segfault when impatiently drag'n'dropping audio files
Description: 1. Create a session
2. Create an audio track
3. Grab a few large WAV or FLAC files and make sure they are of different sampling rate than your session (so that resampling will be required)
4. Drag and drop one.
5. Before the first one finishes importing drag in another one
6. Watch Ardour crash and burn
Tags: crash, drang'n'drop
Steps To Reproduce:
Additional Information: I guess it's strange that Ardour allows to drag'n'drop files before the import is complete
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8604 [ardour] bugs minor have not tried 2021-03-04 16:29 2021-03-04 16:29
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour fails to load a session previously created by "Save As..."
Description: It seems that Ardour doesn't clean up the new session properly.

My video references were left in the interchange/SESSION1/ older, while the audio and MIDI regions were in interchange/SESSION2/.

When I wanted to load the session again after closing Ardour, it shown me attached error message.
It's not a huge deal ,as it told me what to do and I was able to easily get it working again, but it's created the problem itself.

After moving the video files from interchange/SESSION1/video to interchange/SESSION2/video and deleting interchange/SESSION1, the session loaded fine including video reference.

I think I had the same problem happen before when I used Session>Rename
Tags: rename, save
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20210304_172224.png (11,130 bytes) 2021-03-04 16:29
https://tracker.ardour.org/file_download.php?file_id=3964&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8603 [ardour] bugs minor have not tried 2021-03-04 15:55 2021-03-04 15:55
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour seems to never complete Unused Sources Cleanup in a very large session
Description: Ardour seems to be getting stuck in a loop trying to clean up a large session I've made.

I could deliver the entire session for testing, but only through a secure channel.

I've initiated unused sources cleanup and about an hour later it was still going.
IN GDB I've been watching a never-ending flood of messages looking like the attached one.
I can see the same files being listed over and over.

The session has 39 snapshots, but it doesn't seem it would ever finish this process.


Tags: cleanup, lockup
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8600 [ardour] bugs minor always 2021-03-02 13:41 2021-03-03 22:53
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Show existing automation doesn't show plug-in automation lanes
Description: I haven't tested this in 6.6 yet due to some other issues.
It seems to be a bug introduced in 6.5.

Track > Show Existing Automation seems to ignore plug-in automation, only shows me fader, mute and pan lanes.

Can anyone reproduce this?
Tags: automation, ui
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20210302_142359.png (26,977 bytes) 2021-03-02 13:41
https://tracker.ardour.org/file_download.php?file_id=3961&type=bug
png
Notes
(0025591)
x42   
2021-03-03 22:53   
Could it be that the session was initially created with a version older than 6.2?

In the past there were no unique identifiers for plugin GUI automation lanes (they were identified by plugin parameter), visibility was potentially messed up after re-loading the session.
If so this would be an indirect duplicate of 0008162, and only relevant if there is more than one plugin on a track and you load an old session.

If this is a newly created session, please attach the .ardour session file. Thanks.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8588 [ardour] bugs minor have not tried 2021-02-26 10:04 2021-03-03 16:28
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 6.6 Crash on session load
Description: Ardour while loading a session.
Tags: crash
Steps To Reproduce:
Additional Information: (gdb) bt
#0 std::__detail::_List_node_base::_M_unhook (this=0x5555c06cd420) at /build/gcc/src/gcc/libstdc++-v3/src/c++98/list.cc:142
0000001 0x0000555555a5c3a0 in ?? ()
#2 0x0000555555da620e in ?? ()
#3 0x0000555556131add in ?? ()
0000004 0x0000555555da8e5f in ?? ()
0000005 0x00007ffff7414ea5 in ARDOUR::Playlist::foreach_region(boost::function<void (boost::shared_ptr<ARDOUR::Region>)>) () from /opt/Ardour-6.6.0/lib/libardour.so.3
#6 0x0000555555da57f9 in ?? ()
#7 0x000055555613371d in ?? ()
0000008 0x00005555561340bd in ?? ()
0000009 0x00005555561346d7 in ?? ()
0000010 0x0000555555a6a65d in ?? ()
0000011 0x00005555559c7b8e in ?? ()
0000012 0x00007ffff4d86032 in ?? () from /opt/Ardour-6.6.0/lib/libglibmm-2.4.so.1
0000013 0x00007ffff47e3a2a in g_main_context_dispatch () from /opt/Ardour-6.6.0/lib/libglib-2.0.so.0
0000014 0x00007ffff47e3dd0 in ?? () from /opt/Ardour-6.6.0/lib/libglib-2.0.so.0
#15 0x00007ffff47e3e7c in g_main_context_iteration () from /opt/Ardour-6.6.0/lib/libglib-2.0.so.0
0000016 0x00007ffff3dd4601 in gtk_main_iteration () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
#17 0x00007ffff5c307d5 in Gtkmm2ext::UI::flush_pending(float) () from /opt/Ardour-6.6.0/lib/libgtkmm2ext.so.0
0000018 0x00005555559bddfc in ?? ()
0000019 0x00005555559bedef in ?? ()
0000020 0x00005555559c8ce6 in ?? ()
0000021 0x00005555559caf7e in ?? ()
0000022 0x00005555561081bd in ?? ()
0000023 0x00007ffff1f2a5f5 in ?? () from /opt/Ardour-6.6.0/lib/libgtkmm-2.4.so.1
#24 0x00007ffff4af2945 in g_closure_invoke () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000025 0x00007ffff4b0401b in ?? () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000026 0x00007ffff4b0dc30 in g_signal_emit_valist () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000027 0x00007ffff4b0e082 in g_signal_emit () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000028 0x00007ffff3d3280c in gtk_dialog_response () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000029 0x0000555556107b38 in ?? ()
0000030 0x00007ffff1f2a5f5 in ?? () from /opt/Ardour-6.6.0/lib/libgtkmm-2.4.so.1
0000031 0x00007ffff4af2945 in g_closure_invoke () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000032 0x00007ffff4b0401b in ?? () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000033 0x00007ffff4b0dc30 in g_signal_emit_valist () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000034 0x00007ffff4b0e082 in g_signal_emit () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000035 0x00007ffff3d3280c in gtk_dialog_response () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000036 0x00005555560978e4 in ?? ()
0000037 0x00007ffff1fafa9b in ?? () from /opt/Ardour-6.6.0/lib/libgtkmm-2.4.so.1
0000038 0x00007ffff3dd6cac in ?? () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000039 0x00007ffff4af2945 in g_closure_invoke () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000040 0x00007ffff4b03bf2 in ?? () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000041 0x00007ffff4b0d69b in g_signal_emit_valist () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000042 0x00007ffff4b0e082 in g_signal_emit () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000043 0x00007ffff3f5b64c in ?? () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000044 0x00007ffff3dd529d in gtk_propagate_event () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000045 0x00007ffff3dd5723 in gtk_main_do_event () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000046 0x00007ffff39f1b4c in ?? () from /opt/Ardour-6.6.0/lib/libgdk-x11-2.0.so.0
0000047 0x00007ffff47e3b67 in g_main_context_dispatch () from /opt/Ardour-6.6.0/lib/libglib-2.0.so.0
0000048 0x00007ffff47e3dd0 in ?? () from /opt/Ardour-6.6.0/lib/libglib-2.0.so.0
0000049 0x00007ffff47e40f2 in g_main_loop_run () from /opt/Ardour-6.6.0/lib/libglib-2.0.so.0
0000050 0x00007ffff3dd43e7 in gtk_main () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000051 0x00007ffff5c2ea45 in Gtkmm2ext::UI::run(Receiver&) () from /opt/Ardour-6.6.0/lib/libgtkmm2ext.so.0
0000052 0x00005555559184db in ?? ()
0000053 0x00007fffee429b25 in __libc_start_main () from /usr/lib/libc.so.6
0000054 0x000055555591ec2a in ?? ()
Attached Files: backtrace.log (13,140 bytes) 2021-02-26 13:21
https://tracker.ardour.org/file_download.php?file_id=3954&type=bug
6172577.tar.gz (2,408 bytes) 2021-02-26 13:34
https://tracker.ardour.org/file_download.php?file_id=3955&type=bug
gdb3.log (16,494 bytes) 2021-03-03 15:58
https://tracker.ardour.org/file_download.php?file_id=3963&type=bug
Notes
(0025562)
unfa   
2021-02-26 13:21   
It happened again, this time I have a backtrace from a debug build.
(0025563)
unfa   
2021-02-26 13:25   
Ok, now I can't load the project, it crashes every time.
(0025564)
unfa   
2021-02-26 13:30   
Can reproduce in official 6.6.0, can't reproduce in 6.5.0.
I'm attaching the bare .ardour file of the guilty project.
If you'd need to full thing to fix this, let me know.
(0025565)
unfa   
2021-02-26 13:34   
B.Harvestr plug-in state:
(0025566)
x42   
2021-02-26 13:47   
Cross reference https://github.com/sjaehn/BHarvestr/issues/6
(0025578)
unfa   
2021-03-02 15:45   
I've removed B.Harvestr from my session but Ardour 6.6 still crashes when loading it. Ardour 6.5 is fine:

Thread 34 "ArdourGUI" received signal SIG32, Real-time event 32.
[Switching to Thread 0x7fffca5dd640 (LWP 707824)]
0x00007fffef08087c in read () from /usr/lib/libpthread.so.0
(gdb) bt
#0 0x00007fffef08087c in read () from /usr/lib/libpthread.so.0
0000001 0x00007fffd1baeb2f in ?? () from /usr/lib/libjack.so.0
#2 0x00007fffd1bb373d in ?? () from /usr/lib/libjack.so.0
#3 0x00007fffd1bb3572 in ?? () from /usr/lib/libjack.so.0
0000004 0x00007fffd1bad8ed in ?? () from /usr/lib/libjack.so.0
0000005 0x00007fffef077299 in start_thread () from /usr/lib/libpthread.so.0
#6 0x00007fffeccad053 in clone () from /usr/lib/libc.so.6


Teste with 6.6.56 debug build.
(0025579)
unfa   
2021-03-02 15:49   
I had to remove the plug-in state directory entirely to make Ardour 6.6 load the session.
(0025586)
unfa   
2021-03-03 15:58   
This session has crashed on load again.
(0025587)
unfa   
2021-03-03 16:01   
Maybe Vitalium VST is the reason?
That's a new plug-in I've added.

I also found this in the output.
`JUCE Assertion failure in juce_LookAndFeel.cpp:85
JUCE Assertion failure in juce_LookAndFeel.cpp:85
`

Will try in Ardour 6.5 again.
(0025588)
unfa   
2021-03-03 16:05   
It seems Ardour 6.6 can't handle the plug-ins Ardour 6.5 did, and crashes on session load.
It seems I'll have to go back to 6.5 for production due to this problem.
(0025589)
x42   
2021-03-03 16:28   
> This session has crashed on load again. (gdb3.log)

That is a different issue. same as 0008586, meanwhile fixed in git.

> It seems I'll have to go back to 6.5 for production due to this problem.

Expect different issues. Memory corruption may also just cause audible artifacts, or data-loss, depending on what data is overwritten.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8598 [ardour] features minor have not tried 2021-03-01 09:32 2021-03-01 09:32
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow editing timeline markers along with regions
Description: When working with sound effects, it's common for me to duplicate sounds to create alternate versions.

Since every sound effect has it's own export range (defined by Range Markers), that requires copying these markers as well.
When it's one sound, recreating the maker manually is no problem, but when I'm duplicating a dozen, it starts to add up.

It'd be great if one could shift-select a marker lane just like a track or automation lane to copy/cut/paste/delete markers along with regions in the timeline.

What do you think?
Tags: editing, markers, timeline, usability
Steps To Reproduce:
Additional Information: I'm attaching a screenshot - range markers are used in big amounts when working on SFX.
Attached Files: Screenshot_20210301_102915.png (54,418 bytes) 2021-03-01 09:32
https://tracker.ardour.org/file_download.php?file_id=3958&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8597 [ardour] features minor N/A 2021-02-28 23:54 2021-02-28 23:54
Reporter: Arello Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Sync playhead with the step entry insert position
Description: Hi

In MIDI sequencers like Muse and Rosegarden one can start step recording on any desired position according to the playhead, but on Ardour the position seems to be always separate from playhead which seems counter-intuitive (for me). Insert position can only be navigated with back and rest buttons or by handling regions which can get quite cumbersome in some situations. Step navigation also works only if the step entry window is active which seems confusing (for me).

If the insert position would sync with playhead, you could move it back and forth to replace undone notes faster or start recording MIDI on any position in more flexible manner without scrolling too much between different windows etc.

I might be quite alone with this request, but it would be a lifesaver feature for me to use Ardour's sequencer.
Tags: stepentry
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8595 [ardour] bugs minor always 2021-02-28 17:48 2021-02-28 17:48
Reporter: MichaelWhately Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Program crashed when opening compressor plugins
Description: I can add a compressor plugin, either the ACE Stereo or mono compressor or the XT-MC multiband compressor, but when I double click to open the GUI interface to change the settings, the program crashes.
Tags:
Steps To Reproduce: Open a project.
Add compressor to master.
The GUI will start to open, then the program will crash.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8593 [ardour] bugs minor always 2021-02-27 11:39 2021-02-27 11:39
Reporter: DonJaime Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Scala to MIDI tuning script uses wrong base note frequency when importing .scl file
Description: Scala scales are defined with reference to a base note, which by default is middle C with a frequency of 261.6255653Hz.

The Scala to MIDI tuning script applies scale intervals to successive notes starting at C, which is correct and expected. But it calculates the pitches in such a way as to assign pitch 69 (A) to 440Hz. In most cases, this will result in C not being at 261.6255653Hz.

This is unfortunate and rather painful if the track being tuned is meant to be in tune with another instrument which is tuned by other means (such as ZynAddSubFx). Faffing around ensues to get things in tune. (The MIDI Tuning script is no help because it imposes 12 tone EQ.)

Proposed solution: expose a base note selector and frequency input box in the GUI, set to C 261.6255653Hz by default.

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8592 [ardour] bugs minor always 2021-02-27 01:43 2021-02-27 01:45
Reporter: LEWISJEFFREY Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 7  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi Controllers wont work
Description: I have been able to use my Alesis 61 and my Nektar Impact LX 25, and my Akai MPK Mini with the demo version. I now cannot use any with them after reinstalling with the first tier donation version. While the Akai Mini shows up as a premapped controller the two others don't. Unplugging and plugging - and all the tricks I can try along with going into settings and calibrating do not work. I should of passed on this DAW when it said "can't find control ROM" on all the times opening.
Tags: MIDI control
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8590 [ardour] bugs minor have not tried 2021-02-26 13:10 2021-02-26 13:10
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: 6.6 Crash on undo
Description: Ardour has crashed when I tried to undo deleting a MIDI region.

I am attaching both short and full (thread) GDB backtraces.

I feel like I should start running a debug build of Ardour...
Tags:
Steps To Reproduce:
Additional Information: free(): invalid pointer
--Type <RET> for more, q to quit, c to continue without paging--c

Thread 1 "ArdourGUI" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffea9f3900 (LWP 522619)]
0x00007fffee43eef5 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007fffee43eef5 in raise () from /usr/lib/libc.so.6
0000001 0x00007fffee428862 in abort () from /usr/lib/libc.so.6
#2 0x00007fffee480f78 in __libc_message () from /usr/lib/libc.so.6
#3 0x00007fffee488c2a in malloc_printerr () from /usr/lib/libc.so.6
0000004 0x00007fffee489ffc in _int_free () from /usr/lib/libc.so.6
0000005 0x00007fffee48dce8 in free () from /usr/lib/libc.so.6
#6 0x0000555555a5c3b8 in ?? ()
#7 0x0000555555da620e in ?? ()
0000008 0x0000555556131add in ?? ()
0000009 0x0000555556136104 in ?? ()
0000010 0x000055555610c3f1 in ?? ()
0000011 0x00007ffff5c36708 in AbstractUI<Gtkmm2ext::UIRequest>::call_slot(PBD::EventLoop::InvalidationRecord*, boost::function<void ()> const&) () from /opt/Ardour-6.6.0/lib/libgtkmm2ext.so.0
0000012 0x000055555610d1f9 in ?? ()
0000013 0x000055555610c2ca in ?? ()
0000014 0x00007ffff74292db in PBD::Signal1<void, boost::weak_ptr<ARDOUR::Region>, PBD::OptionalLastValue<void> >::operator()(boost::weak_ptr<ARDOUR::Region>) () from /opt/Ardour-6.6.0/lib/libardour.so.3
#15 0x00007ffff741a6f1 in ARDOUR::Playlist::flush_notifications(bool) () from /opt/Ardour-6.6.0/lib/libardour.so.3
0000016 0x00007ffff7412f0e in ARDOUR::Playlist::end_undo() () from /opt/Ardour-6.6.0/lib/libardour.so.3
#17 0x00007ffff59ab160 in UndoHistory::undo(unsigned int) () from /opt/Ardour-6.6.0/lib/libpbd.so.4
0000018 0x00007ffff75b1cb9 in ARDOUR::Session::undo(unsigned int) () from /opt/Ardour-6.6.0/lib/libardour.so.3
0000019 0x0000555555b2f95c in ?? ()
0000020 0x00007ffff4d8cc88 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /opt/Ardour-6.6.0/lib/libglibmm-2.4.so.1
0000021 0x00007ffff4af2945 in g_closure_invoke () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000022 0x00007ffff4b0401b in ?? () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000023 0x00007ffff4b0dc30 in g_signal_emit_valist () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
#24 0x00007ffff4b0e082 in g_signal_emit () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000025 0x00007ffff3cc8fb0 in ?? () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000026 0x00007ffff3cc922c in gtk_action_activate () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000027 0x00007ffff5c17458 in Gtkmm2ext::Bindings::activate(Gtkmm2ext::KeyboardKey, Gtkmm2ext::Bindings::Operation) () from /opt/Ardour-6.6.0/lib/libgtkmm2ext.so.0
0000028 0x00005555559b43ef in ?? ()
0000029 0x00005555559b482d in ?? ()
0000030 0x00007ffff1fafa3b in ?? () from /opt/Ardour-6.6.0/lib/libgtkmm-2.4.so.1
0000031 0x00007ffff3dd6cac in ?? () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000032 0x00007ffff4af2945 in g_closure_invoke () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000033 0x00007ffff4b03bf2 in ?? () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000034 0x00007ffff4b0d69b in g_signal_emit_valist () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000035 0x00007ffff4b0e082 in g_signal_emit () from /opt/Ardour-6.6.0/lib/libgobject-2.0.so.0
0000036 0x00007ffff3f5b64c in ?? () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000037 0x00007ffff3dd538f in gtk_propagate_event () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000038 0x00007ffff3dd5723 in gtk_main_do_event () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000039 0x00007ffff39f1b4c in ?? () from /opt/Ardour-6.6.0/lib/libgdk-x11-2.0.so.0
0000040 0x00007ffff47e3b67 in g_main_context_dispatch () from /opt/Ardour-6.6.0/lib/libglib-2.0.so.0
0000041 0x00007ffff47e3dd0 in ?? () from /opt/Ardour-6.6.0/lib/libglib-2.0.so.0
0000042 0x00007ffff47e40f2 in g_main_loop_run () from /opt/Ardour-6.6.0/lib/libglib-2.0.so.0
0000043 0x00007ffff3dd43e7 in gtk_main () from /opt/Ardour-6.6.0/lib/libgtk-x11-2.0.so.0
0000044 0x00007ffff5c2ea45 in Gtkmm2ext::UI::run(Receiver&) () from /opt/Ardour-6.6.0/lib/libgtkmm2ext.so.0
0000045 0x00005555559184db in ?? ()
0000046 0x00007fffee429b25 in __libc_start_main () from /usr/lib/libc.so.6
0000047 0x000055555591ec2a in ?? ()
Attached Files: full backtrace.log (83,726 bytes) 2021-02-26 13:10
https://tracker.ardour.org/file_download.php?file_id=3953&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8587 [ardour] bugs minor have not tried 2021-02-26 09:43 2021-02-26 09:43
Reporter: unfa Platform: Ryzen  
Assigned To: OS: Manjaro  
Priority: normal OS Version: KDE  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Transport controls became locked out
Description: Somehow, the transport controls in my session became disabled (grayed out).

I can right click on a range marker and make Ardour play or loop the range, but space bar will not stop/start the transport.
I can click and place my playhead, but I can't stop the transport.

I'm running Ardour in GDB (all the time, lol) but I don't know what can I do to give you more debug info.
This has never happened to me before Ardour 6.6, and this is the first time ever.
Tags: lockup, transport, ui
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20210226_103407.png (160,862 bytes) 2021-02-26 09:43
https://tracker.ardour.org/file_download.php?file_id=3951&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8583 [ardour] other minor always 2021-02-25 11:52 2021-02-25 11:52
Reporter: unfa Platform: Ryzen 7  
Assigned To: OS: Manjaro  
Priority: normal OS Version: KDE  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Editor list doesn't respond to keyboard events as expected
Description: When I start editing range names in the Editor List / Ranges panel I expect to the Ctrl+C/Ctrl+V/Ctrl+X/Ctrl+A shortcuts to work in the context of an active text field (just like they do when editing track names for example).

These shortcuts however work in the context of the timeline instead.

(I've tested in the official 6.6 BTW)
Tags: ui
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8363 [ardour] bugs minor unable to reproduce 2020-08-15 14:27 2021-02-24 18:55
Reporter: asedlack Platform: Redhat  
Assigned To: OS: Fedora  
Priority: normal OS Version: 32  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: General MIDI Synth doesn't produce sound on loading saved project
Description: I have a project with a MIDI track recorded and played on the default Ardour General MIDI synth. I had no problems when I first created the track. The next time I opened the project in Ardour the General MIDI Synth plugin wasn't producing any sound. The MIDI track was still intact, not muted, same volume etc. The only other plugins on the track after the synth are the default fader and a Calf equalizer, but bypassing both had no effect. To resolve the problem I simply deleted the General MIDI synth plugin, added it back, and set the patch again. Every time I reload this particular project it does the same thing until I repeat this procedure.
Tags:
Steps To Reproduce: This happens every time this particular project is loaded. I have been unable to produce by creating a MIDI track with the same plugins on a new project though.
Additional Information:
System Description
Attached Files: Bass-10_F_bug.mid (478 bytes) 2021-02-24 18:55
https://tracker.ardour.org/file_download.php?file_id=3949&type=bug
Notes
(0025549)
mauriciomarinho   
2021-02-24 18:55   
Got the same issue, but it only happens if playhead goes through a specific midi note, then the whole track goes silent, even the notes that had sound before it. Velocity meter still shows that it is being read, just doesn't produce sound.

Only fix is to delete the plugin, then add it back, but if it reaches that note again, all goes silent. Same project had issues with ZynAddSubFX not saving changes and reverting back to default sinewave when reloading. Fixed by adding a new track and adding it all back together.

Terminal shows: "failed to deliver ALL NOTES OFF on channel" from 1 to 15. Attached is the midi file from ardour, it fails when it reaches the F note, also happens when importing this to any new session.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8579 [ardour] bugs minor always 2021-02-17 14:10 2021-02-18 22:45
Reporter: sciurius Platform: x86_64  
Assigned To: OS: Fedora  
Priority: normal OS Version: 33  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Save as of a modified session yields a confusing dialog
Description: When a session is modified and I select Session > Save As..., a dialog appears with a confusing text.

"Any changes made this time will be lost unless you save it."

It seems to imply that things will go wrong horribly unless I save the session first. Saving will affect the current saved state of the session, and that is what I want to avoid by using Save As... .

Tags:
Steps To Reproduce: Create a session, modify something, and then Session > Save As...
Additional Information:
Attached Files: scrot20210217145924.png (14,620 bytes) 2021-02-17 14:10
https://tracker.ardour.org/file_download.php?file_id=3944&type=bug
png
Notes
(0025531)
x42   
2021-02-18 20:40   
>Saving will affect the current saved state of the session, and that is what I want to avoid by using Save As... .

You really want to save a snapshot of the current session, and not save the whole session under a different name in a different place. Save-as does the latter.

https://manual.ardour.org/working-with-sessions/snapshots/
(0025532)
sciurius   
2021-02-18 22:45   
In this particular case I want to make a new, distinct copy of the project, under a different name and location, to be used for an other, separate, project. To the best of my knowledge that is what "Save As..." is for.
Also, for all applications that I know "Save As..." will save the *current* state, even if modified, to the new destination.

In either case, the "unsaved session" dialog is confusing.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8465 [ardour] bugs minor always 2020-11-01 17:42 2021-02-18 20:34
Reporter: jcfitn Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when change the meter.
Description: Each time the playhead arrive to a Meter Change Ardour Crash.

But

If i change the Tempo in the same position don't crash.

And...

If i put a new tempo marker with the same BPM Ardour crash in the same way

So...

Ardour Crash when there are a Tempo Marker without change the Tempo.

Sorry for my english :)

Thanks Team!
Tags: tempo
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025186)
x42   
2020-11-01 19:21   
This is unusual. Could you attach the .ardour session file that produces this issue?
(0025478)
jcfitn   
2021-01-28 10:22   
Sorry, I lost the session and that didn't happened again...

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8580 [ardour] features minor N/A 2021-02-18 14:34 2021-02-18 14:34
Reporter: joel_graff Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Pre-record feature for punch in
Description: A typical punch-and-roll workflow is easy enough to manage in Ardour, but a key advanced feature in many DAWs is a "pre-record" option for a set punch-in point. This is especially useful in applications like audiobook narration where the narrator may use punch and roll to correct a mistake, only to begin speaking too soon or cut off the initial breath before they start speaking. In these cases, a brief "pre-record" prior to the punch in point would provide enough additional audio to allow the editor to preserve the recording without having to edit out a cut-off initial breath or, worse yet, require the narrator to re-record because they started speaking too soon.

In most cases, a 1-second pre-record buffer is likely sufficient, though making it variable would obviously be more desirable.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8498 [ardour] bugs minor always 2020-12-14 04:25 2021-02-14 12:39
Reporter: seablade Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Drag and Drop Import Stops on Unknown File Types
Description: One thing about the import process, I think when Ardour hits a file it doesn't recognize it stops the import, given that the import doesn't happen in order this can make it confusing to recover from. I would suggest it skip the file and continue the rest of the import
In my case I had a zip file in the middle of about 10 audio files, Ardour correctly doesn't import the zip, but it causes the import to stop halfway through
Tags:
Steps To Reproduce: 1. Select multiple files to import, at least one of them in the middle needs to be a non-audio file.
2. Drag and Drop those into editor window
3. Ardour imports files, but stops the import when it gets to unknown file type
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8574 [ardour] bugs minor always 2021-02-12 17:05 2021-02-12 17:05
Reporter: ardourwlk Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: CLI-created session-name does not show full name
Description: Hi, this seemed to change/break either between 5.12 and 6 or somewhere in 6.

I try to create a session like this:
/opt/Ardour-6.5.0/bin/ardour6 -N ~/ArdourSessions/$(date +%Y%m%d\.%H%M) -T BetterQuickGuitarWithGuitarix

and while it correctly creates the session under, say, ~/ArdourSessions/20210212.1200/, the session name that is displayed at the top of the window would only be "20210212". Not life-threatening, but, occasionally inconvenient.

As I suggested, this used to work fine. I've been sitting on this for a while, as it's mostly cosmetic.

Thanks!
Tags: ardour6
Steps To Reproduce: /opt/Ardour-6.5.0/bin/ardour6 -N ~/ArdourSessions/$(date +%Y%m%d\.%H%M)
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8567 [ardour] bugs minor always 2021-02-07 18:59 2021-02-12 11:33
Reporter: gwyndaf Platform: Lenovo ThinkPad R61i  
Assigned To: OS: Linux Debian  
Priority: normal OS Version: 10 (bullseye)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: <Delete> key doesn't delete automation control point/s (but <Backspace ?> does)
Description: According to the manual, control points can be deleted by selecting (left-click) then pressing <Delete>, or by <Shift>+<Right-click>
https://manual.ardour.org/editing/gain-envelopes/

<Shift>+<Right-click> works, but selecting followed by <Delete> doesn't.

However, select followed by <Backspace ?> does.

In fact, it works when multiple control points are selected (which was what I was after doing), so might be worth adding to the manual, as this seems quite handy to know.
Tags: control points, envelope
Steps To Reproduce: <Left-click> a control point, to select, or draw around several with edit tool.
Press <Delete> -> Nothing happens.
Press <Backspace ?> -> Control points deleted.
Additional Information: I don't know if this is a functionality bug, or a manual omission. However, since Ardour's built-in keybindings list suggests <Delete> and <Backspace> are largely synonymous, I'm guessing the <Delete> key should be doing the same as <Backspace> in this context.

It may or may not be relevant that I'm using a laptop keyboard (Lenovo Thinkpad R61i), but both <Delete> and <Backspace ?> are distinct keys, as on a bigger keyboard.
System Description
Attached Files:
Notes
(0025496)
gwyndaf   
2021-02-07 19:04   
? at the end of <Backspace > should be the left-pointing block arrow symbol with an 'X' inside. I inserted that Unicode character, but it doesn't seem to register/reproduce after posting.
(0025499)
gwyndaf   
2021-02-09 08:14   
Now tested on desktop machine with same OS and Ardour versions, with full-sized keyboard, and experience same behaviour as described previously.

Also occurs with Draw tool (i.e. after clicking on a control point to select): <Delete> doesn't, but <Backspace> does.
(0025515)
gwyndaf   
2021-02-12 11:33   
Additional information:

<delete> key not deleting control points affects both gain and automation envelopes.

However, the 'drag to select multiple control points' feature seems to work only in automation envelopes (not gain). This seems undocumented, so I'm not sure what correct functionality should be, but it's a useful feature.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8573 [ardour] features minor always 2021-02-12 09:34 2021-02-12 09:34
Reporter: muzzol Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: enhance selected channel visibility in mixer
Description: this is a feature request to make selected channel more prominent in mixer.

in editor is really easy to spot but in mixer is just a thin outline and it's hard to see.
that's aggravated if you work with more than one monitor because your eyes go fast from editor to mixer.
Tags:
Steps To Reproduce: just select a channel and search it in mixer.
Additional Information: cubase does it quite good, it even got a setting just for that: https://youtu.be/IU5cLlBKJFc?t=191
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8570 [ardour] documentation minor always 2021-02-09 09:40 2021-02-10 08:39
Reporter: breatheoutbreathein Platform: Web  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Webpage for PDF docs 404s
Description: https://manual.ardour.org/manual.pdf 404s
This page is accessible by clicking on the book icon to the right of the search bar on the manual page: https://manual.ardour.org/toc/
Tags:
Steps To Reproduce:
Additional Information: Apologies if this is not the correct place to report this kind of bug :)
Attached Files:
Notes
(0025506)
Headwar   
2021-02-10 08:39   
Thanks for reporting this.
The reason for this 404 is, the manual is created automatically on building the docs. For multiple of (good) reasons, the server software stack is not recent enough to run the latest version of the underlying html->pdf conversion software, hence a lot of features are lacking in the generated PDF.
It has then been decided to postpone the upgrade and the PDF generation has been disabled in the meantime, in order not to deliver a PDF that wouldn't be on par with our quality standards.
Regards,
Edouard

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8569 [ardour] bugs minor random 2021-02-09 00:10 2021-02-09 00:10
Reporter: kkietzke Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: crashes at end of audio recording
Description: Ardour sometimes crashes at the end of recording audio, before adding the audio to the track. It seems more likely to do it on the first recording after I open a session, but sometimes it does it at other times as well.
Tags: 6.5, audio, crash, recording crash, Windows
Steps To Reproduce: I can't reproduce it on command, unfortunately, but I'm using shift-R to arm the recording and space to start it. The track that I'm recording to is already armed when I open the session.
Additional Information: This is too big to upload, but if it helps, you can grab a copy of a session where this has occurred here: <https://www.dropbox.com/s/p5kjiaesjd15kkr/16-Choir-Ode5-AmazedWasTheUniverse.zip?dl=0>
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8565 [ardour] bugs minor always 2021-02-06 20:59 2021-02-07 01:29
Reporter: AlexPHorta Platform: Intel  
Assigned To: OS: Linux Mint  
Priority: normal OS Version: 19.3  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 5.12.0 crashes when opening project file
Description: I was editing one project I'm working on (I triggered selected regions > edit > combine in a track while the system was playing the project). Then, Ardour crashed. After that, when I try to open that same project, Ardour loads everything until the history file (that's what I can see from the startup windown) and crashes.

I tried opening the same project in safe mode, with no success. I tried opening another project, so to get Ardour started, and then open the troubled project, but Ardour crashed in the same way.

Other projects I have are working just fine.
Tags: crash
Steps To Reproduce: Simply opening the defective project.
Additional Information: I'm using QjackCtl version 0.4.5.
I ran Ardour through GDB and attached the stacktrace below.
System Description
Attached Files: ardour_gdb_log (20,940 bytes) 2021-02-06 20:59
https://tracker.ardour.org/file_download.php?file_id=3939&type=bug
Notes
(0025495)
AlexPHorta   
2021-02-07 01:29   
Just remembered, I tried to open the backup file, without success.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8352 [ardour] bugs minor always 2020-08-08 12:16 2021-02-04 12:23
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Control "Smoothing" fixes
Description: 1. The name is misleading - I thought it's a lowpass effect on the control motion, but it's a threshold of changes that'll be rejected if farther than X from the current control position. Mixxx calls this "Smooth Takeover" which I think is much more helpful. Please rename.

2. Also a tooltip would be nice to explain what this dos.

3. The default is at 10 which means is the user performs a fast movement and the CC change will be higher than 10 in a single frame - which is super easy to do - the control will fail to follow user's actions, which is completely unexpected and feels like a bug. I personally set it to 127 (maximum) for this reason, as recording any fast automation will inevitably result in glitched out captures. Until this can be fixed I'd recommend setting default to 127.

Tags: Midi, MIDI control
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024905)
paul   
2020-08-08 15:28   
This isn't actually 100% dependent on user behavior. Device behavior plays a role too. Some devices, if you do a full knob/fader sweep from start to finish will send every value from 0 to 127. Some will leave gaps, of varying sizes. I have devices that send every value, send every 16, and send every 30 or so.
(0025485)
DBA   
2021-02-04 00:11   
I spent hour to figure out why my expression pedal "was not working properly" while there is this undocumented setting that is set by default to a value which lead to a misbehavior. The default should be 127 or "no smoothing".
(0025486)
paul   
2021-02-04 02:59   
Sorry you had to spend that long on it.

Unfortunately, there is no "correct" default value for smoothing. I have devices that only function well with almost opposite settings. FIxing the default for your expression pedal would just break it for something else.
(0025487)
DBA   
2021-02-04 07:30   
In this case, can you at least put a word about this in the manual?
(0025489)
unfa   
2021-02-04 12:23   
I've covered issues I have with this feature in my Ardour MIDI Masterclass:
https://youtu.be/ACJ1suTVouw?t=6317

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8561 [ardour] other minor have not tried 2021-02-03 16:28 2021-02-03 16:28
Reporter: jacksonluke Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Window Cleaning
Description:  we do windows! Our professionals clean the inside or outside of your windows using methods and equipment that will leave windows sparkling. Because window cleaning can be a bit hazardous, our staff is thoroughly trained in the safe use of all equipment and fall protection. We comply with all OSHA safety standards and are fully insured and bonded.
https://allegianceclean.com/
https://allegianceclean.com/office-cleaning-vancouver/
https://allegianceclean.com/strata-building-cleaning-vancouver/
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8560 [ardour] features minor N/A 2021-02-02 08:50 2021-02-02 08:50
Reporter: thebutant Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 6.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: Pan option in region properties
Description: A neat feature I often long for, is the option to pan a region directly in the region properties.
When double clicking the region, you can change gain, you can see peak amplitude etc, but it'd be handy to also have the option of panning the region.

Qtractor actually has this, and it's clever when making for instance voice effects with several short regions in opaque stacked upon eachother.
You then don't need to make new tracks with new FX instances. They all go in the same track, using the same FXs, while still emplyoing different places in the stereo image.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8557 [ardour] bugs minor always 2021-01-29 10:07 2021-01-30 16:12
Reporter: slavikator Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 6.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Store and recall global mixer settings.
Description: Store and recall global mixer settings.
Tags:
Steps To Reproduce: 1. Store mixer settings global
2. Create another project with the same track names and routings.
3. Recall mixer settings from global

Issue:
All PAN knobs are set to the left positions (tracks and buses). You have to manually put them to the center or desired place.
Additional Information:
System Description
Attached Files:
Notes
(0025479)
slavikator   
2021-01-29 17:14   
Also, when you recall the mixer settings (global) it removes all the aux sends and mixbus sends
(0025480)
slavikator   
2021-01-29 17:18   
Fase on aux buses ignored.
(0025481)
x42   
2021-01-30 16:12   
Forward from Mixbus support: "The actual issue is a locale issue" (e.g. "1.0" vs. "1,0")

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2682 [ardour] bugs minor always 2009-05-17 20:57 2021-01-28 06:26
Reporter: agorka Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: Karmic  
Status: new Product Version: 2.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: VST plug-in editors are not really closed when closed.
Description: I'm working on an Spectrum Analyzer VST plug-in. It uses lots of CPU when analyzing, so it automatically deactivates analyzing when editor window is closed. It works OK everywhere except Ardour, where editor window isn't destroyed when user closes the window. Editor window probably just remain hidden, still using resources. It is evident with my plug-in, but not so evident with other plug-ins. Still, having multiple VST plug-ins updating their invisible GUI's might seriously affect overall performance of DAW.
Tags:
Steps To Reproduce: 1) Open a session
2) Add a VST plug-in
3) Open it's editor - effEditOpen is sent to the plug-in
4) Close editor - nothing is send to the plug-in
5) Remove VST plug-in - now effEditClose is actually send
Additional Information:
Attached Files:
Notes
(0025472)
weirdconstructor   
2021-01-27 07:22   
Other hosts, like Bitwig, call effEditClose / effEditOpen whenever the GUI is opened/closed.
I believe that would be the right behavior, just because you opened a plugin once, you don't want it's GUI
to linger around for the rest of the session.

Especially OpenGL plugins (of which there are many, and more to come) usually redraw the GUI many times per second.
So keeping around the window is very wasteful.
(0025474)
weirdconstructor   
2021-01-27 11:10   
Another data point I got from #lad (IRC freenode) is, that not only does Bitwig do this, also REAPER and Renoise call effEditClose properly.
(0025475)
x42   
2021-01-27 19:58   
The problem you mention cannot be solved simply by destroying the Window.

Plugins should not render their UI when they're not mapped on the screen, regardless of the window being realized or not. A window that is off-screen or on a different desktop should not render itself unless it is mapped and visible. Most professional plugins heed that. Force closing the window is just a poor workaround.

I expect you come from the windows world where the window "X" button is often misinterpreted to mean "exit/quit", rather than close/hide on other OS.

The main motivation behind Ardour keeping windows around is to be able to show them again instantly, without requiring to reload resources.
And in some cases also so that the plugin GUI already has accumulated history in case it features analyzers or meters. As opposed to Bitwig, Renoise etc. Ardour is focused on live audio realtime signal processing
where the mixer runs constantly and does not freeze or idle.
(0025477)
weirdconstructor   
2021-01-28 06:26   
Thanks for your reply, I'll look into the toolkit I'm using then to stop drawing.

btw.: I do not come from the "windows world", but I did not encounter that interpretation yet.
I guess it kind of makes sense when you view the plugin as being a dialog window of the host application,
instead of a separate application UI.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8556 [ardour] bugs minor always 2021-01-27 23:24 2021-01-27 23:43
Reporter: jcfitn Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour don't record legato notes in MIDI
Description: Hi!
I record something that sounds legato, but when i play the region Ardour retriger each note...
Tags: ewi
Steps To Reproduce: When i use mi EWI (Midi wind controller) with Surge, i play the notes "legato" and they sounds legato, without retrigger, but when i play the recorded region Ardour retrigger the envelope, i tried with every option in preferences
Additional Information: I tried with the option session for overlapping but dont works.
System Description
Attached Files:
Notes
(0025476)
jcfitn   
2021-01-27 23:43   
Even when i legatize all the notes daesn't work, i need to make a little bit longer each note to have the legato or portamento...
It's like Ardour don't play the notes until the end

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8555 [ardour] bugs minor always 2021-01-27 13:13 2021-01-27 13:13
Reporter: feaneron Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when changing buffer size with JACK
Description: When I run Ardour with the JACK backend, using the pipewire-jack replacement libraries, and I try and change the buffer size, Ardour crashes with the following backtrace:

---

double free or corruption (!prev)

Thread 18 "ardour" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe0a9b700 (LWP 94)]
0x00007ffff49f7775 in raise () from /usr/lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ffff49f7775 in raise () at /usr/lib/x86_64-linux-gnu/libc.so.6
0000001 0x00007ffff49e0855 in abort () at /usr/lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff4a3b277 in __libc_message () at /usr/lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff4a4279c in () at /usr/lib/x86_64-linux-gnu/libc.so.6
0000004 0x00007ffff4a43dec in _int_free () at /usr/lib/x86_64-linux-gnu/libc.so.6
0000005 0x00007ffff758886d in ARDOUR::AudioBuffer::~AudioBuffer() () at /app/lib/ardour6/libardour.so.3
#6 0x00007ffff758888d in ARDOUR::AudioBuffer::~AudioBuffer() () at /app/lib/ardour6/libardour.so.3
#7 0x00007ffff760cde3 in ARDOUR::BufferSet::ensure_buffers(ARDOUR::DataType, unsigned long, unsigned long) () at /app/lib/ardour6/libardour.so.3
0000008 0x00007ffff7bd9d38 in ARDOUR::ThreadBuffers::ensure_buffers(ARDOUR::ChanCount, unsigned long) () at /app/lib/ardour6/libardour.so.3
0000009 0x00007ffff760b78f in ARDOUR::BufferManager::ensure_buffers(ARDOUR::ChanCount, unsigned long) () at /app/lib/ardour6/libardour.so.3
0000010 0x00007ffff7bdb4c4 in ARDOUR::Track::set_block_size(unsigned int) () at /app/lib/ardour6/libardour.so.3
0000011 0x00007ffff7ab38d7 in ARDOUR::Session::set_block_size(unsigned int) () at /app/lib/ardour6/libardour.so.3
0000012 0x00007ffff75b96e1 in ARDOUR::AudioEngine::buffer_size_change(unsigned int) () at /app/lib/ardour6/libardour.so.3
0000013 0x00007ffff04159bb in ARDOUR::JACKAudioBackend::jack_bufsize_callback(unsigned int) () at /app/lib/ardour6/backends/libjack_audiobackend.so
0000014 0x00007ffff03d15ff in do_buffer_frames () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#15 0x00007ffff0310868 in flush_items () at /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so
0000016 0x00007ffff0310742 in source_event_func () at /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so
#17 0x00007ffff0311043 in loop_iterate () at /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so
0000018 0x00007ffff0387426 in do_loop () at /usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0
0000019 0x00007ffff54c84d2 in start_thread () at /usr/lib/x86_64-linux-gnu/libpthread.so.0
0000020 0x00007ffff4abc2a3 in clone () at /usr/lib/x86_64-linux-gnu/libc.so.6

---

It seems that the `ARDOUR::AudioBuffer::~AudioBuffer()` destructor is being called twice. By inspecting the code at https://github.com/Ardour/ardour/blob/master/libs/ardour/audio_buffer.cc#L45, it seems `_owns_data` is not set to `false` after freeing the data, which would allow for a double-free in the above scenario.
Tags: 6.5
Steps To Reproduce:  - Run Ardour with `$ pw-jack ardour6`
 - Open a project with JACK
 - Play any audio
 - Change the buffer size (might need to change a few times until it crashes)
Additional Information: I understand this is an exotic setup, and don't expect
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8554 [ardour] features minor always 2021-01-25 20:59 2021-01-25 20:59
Reporter: mantis_n1oif Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Improvements around plugin presets
Description: Would like a couple of quality-of-life improvements around plugin preset handling:

1. It would be great to have a "Are you sure you want to overwrite this preset?" dialog when clicking the save button. A lot of times what I really want is to save as new (i.e. the "+" button) but click the down arrow (save) button instead, nuking the preset I was working from.

2. It would be great to have a "Are you sure you want to navigate away from this preset?" dialog when selecting presets. I'll often have unsaved changes on the current preset and lose them by misclicking into another preset.
Tags:
Steps To Reproduce: n/a, or see description
Additional Information: I'm on 6.3, I don't know if any of this has changed by 6.5, but I doubt it.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8547 [ardour] bugs minor always 2021-01-21 23:10 2021-01-25 00:21
Reporter: ryan_c_scott Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OSC feedback not sent when no midi ports are enabled
Description: Some OSC feedback isn't sent if no midi ports are connected at startup.

All midi ports disconnected in "Audio/MIDI Setup/Midi Device Setup".

OSC feedback value set to:
  /set_surface/feedback = 3

These specific messages were observed to not be sent when expected:
  - /rec_enable_toggle
  - /transport_play
  - /transport_stop
  - /strip/recenable
  - /strip/mute

With a single midi port selected the above OSC messages are sent as expected.

Expected behavior:
OSC message /strip/recenable or /strip/mute enable (respectively) sent to connected clients.

Observed behavior:
/strip/recenable /strip/mute messages are not sent.
Tags:
Steps To Reproduce:   1. New session
  2. Empty template
  3. Audio/MIDI Setup/Midi Device Setup
  4. Disconnect/disable all ports
  5. OSC surface protocol enable
  6. OSC feedback set to 3
  7. Create audio track
  8. Arm track or mute track
  9. Observe missing outgoing OSC messages
Additional Information: /strip/fader and /strip/pan_stereo_position work as expected.
/strip/recenable and /strip/mute are sent correctly if any proper midi IO port is selected (i.e. besides "Microsoft GS Wavetable Synth").
Also works with LoopMIDI virtual port (no data throughput is reported on LoopMIDI when used as the only connected port)
System Description
Attached Files:
Notes
(0025463)
ovenwerks   
2021-01-24 02:54   
OSC feedback value set to:
  /set_surface/feedback = 3
means:
  - /rec_enable_toggle
  - /transport_play
  - /transport_stop
 Should have no feedback
Setting feedback to 19 makes them work for me.
 - /strip/recenable
  - /strip/mute
both work for me if any MIDI port is available or not. However, I did find that in order to enable/disable a MIDI port I had to stop the audio engine. This is the top line in the Audio/MIDI Settings window. Unless this line says Running, sending OSC message has no effect and so there is no control change and so no feedback. I would note that it is not possible to make any changes from the GUI at this point either, but in that case a warning dialog pops up and complains the audio engine is dissabled. OSC does not have warning dialogs but could perhaps have a generic feedback message of /audio/engine s "FAIL" That control surface designers could use.

Please check that the Audio engine is "Running" and that these changes can be made from from the GUI too.
(0025465)
ryan_c_scott   
2021-01-25 00:21   
The audio engine is definitely running. I get audio output and several other OSC messages, just missing certain things.
I was disabling that only through the Ardour setup/launching UI (i.e. not after the app is fully showing a session).
And to make sure we're talking about the same thing, this is on Windows (10 to be specific), yeah?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8546 [ardour] features minor N/A 2021-01-20 17:59 2021-01-24 01:51
Reporter: esb Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add pan option to OSC/foldback send commands (e.g. /cue/send...)
Description: The UI has the ability to set the panning for each foldback send, but those can't be controlled remotely with OSC.

It would be beneficial to have a pan control available with the foldback send (/cue/send) commands. For example:

/cue/send/pan_stereo_position/# <position>
Tags: 6.5, foldback, osc
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025457)
ovenwerks   
2021-01-24 01:50   
Sounds good... I think it was intended but not implemented yet. Foldback development actually started on the OSC end and the GUI part was added after. At which time some things got a rethink which needs to get back to OSC. I think sends in general should be able to control pan. There is a way now with the spill option, but not with the cue set of commands.

Thank you for mentioning it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8406 [ardour] bugs minor have not tried 2020-09-13 21:37 2021-01-20 12:51
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Exporting a 1-second long audio region takes about 10 minutes
Description: While working around the problems I've reported elsewhere (https://mantis.ardour.org/view.php?id=8404), I've stumbled upon another issue.

Exporting an audio region of about 1-second when there's no processing applied takes hundreds of times longer than it should.

I can make my sounds, but I can't deliver them to the client.
Tags: export
Steps To Reproduce: 1. Right click on an audio region
2. Select "export"
3. Proceed to export the file
4. Wait until Ardour finishes
5. Realize it took forever.
Additional Information:
System Description
Attached Files: Screenshot_20200913_233255.png (89,868 bytes) 2020-09-13 21:37
https://tracker.ardour.org/file_download.php?file_id=3833&type=bug
png
Notes
(0025439)
gusnan   
2021-01-20 02:07   
I run in to this too, on Ardour 6.5 just downloaded from the ardour site, Debian stable, Xfce, Full version from about dialog: Ardour 6.5.0 "Old Land" (rev 6.5) 64-bit Intel.
(I do run into the same problem when using the older Ardour from the Debian repositories).
This is on Jack, with a Behringer U-Phoria UMC204HD. If you need more / other info that can help to solve this, feel free to ask.
(0025440)
gusnan   
2021-01-20 02:22   
And just a little bit later I manage to export sound just fine. This newer version of Ardour have a rearranged Sound/MIDI-installation dialog (Sorry if I get the name wrong, I am translating from the Swedish user interface) - I believe I had the Device setting wrong, and when I set it to the UMC204HD 192k, the sound export started working just fine.
(0025441)
x42   
2021-01-20 10:36   
1) Can you reproduce this without JACK (Menu > Window > Audio/MIDI Setup)?
2) Is it the export by itself that takes this long, or start/end of he export?
3) Could it be that the export target is a slow USB disk or thumbdrive?
(0025442)
gusnan   
2021-01-20 12:51   
@x42 - Changing from JACK to Alsa or Pulseaudio doesn't affect it, now it works just fine disregarding what is selected.

Unfortunately I cannot find the setting which causes the problem again - the export works just fine.

Most of the time the export just wrote 42 bytes to the file, and then simply paused. I experienced it as if it was completely stuck, but sometimes I managed to get a file that represented parts of the track in ardour, something like 1.4 MB, for a 18 sek clip.

For your question 3, the answer is no. When using ardour I have written the file to a M.2 SSD.

Earlier it would get stuck exactly as in the image unfa provided above ^.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8542 [ardour] translation minor always 2021-01-14 21:11 2021-01-20 10:40
Reporter: JackRussel Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Wrong czech translation of automation states
Description: In czech translation, there is word "P?íru?ka" for manual state, which is just wrong translation, which does not make any sense. I also do not know what does the fifth state "Zaklapnout" mean, since there is nothing about this fifth state in Ardour online manual (pun not intended).
Tags: 6.5, automation, czech
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025422)
x42   
2021-01-14 21:32   
Looks like the first was already addressed: https://github.com/Ardour/ardour/pull/588/files
(0025423)
x42   
2021-01-14 21:36   
https://github.com/Ardour/ardour/blob/a307cc602c03c56072e40a403d986906ae6c5427/gtk2_ardour/po/cs.po#L3236-L3239

"Latch" is translated as "Zaklapnout"

"Latch" works like "Touch", but after touching a control writing continues until transport-stop.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8216 [ardour] translation minor have not tried 2020-06-07 17:50 2021-01-20 10:39
Reporter: JackRussel Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Incorrect czech translation for automation states
Description: There is an incorrect czech translation for the automation state "Manual", which is currently translated as "P?íru?ka" (meaning documentation or guide). I suggest to translate it as "Ru?n?", which keeps the original meaning of manual control.
Tags: automation, czech
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025421)
JackRussel   
2021-01-14 21:02   
This bug persists in Ardour 6.5.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8545 [ardour] bugs minor always 2021-01-19 13:32 2021-01-19 13:34
Reporter: nick_stephens Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 6.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: If there is a tempo change, any editing of automation points no longer snap to the music grid.
Description: If automation points in a MIDI region are moved around after a tempo change, the points no longer snaps to the music grid.
I have attached two images that illustrate this. The second image shows where the automation point has snapped to, and in the second region, it doesn't line up.
Tags:
Steps To Reproduce: Create two midi regions next to each other. Create a tempo change in between them. Select snap to 1/4 notes. Create some automation points in both regions. The snapping works as expected. Move the automation points left to right in both regions. Movement of the automation points respects the grid before the tempo change, but not after the tempo change.
Additional Information:
System Description
Attached Files: automation-points-created.png (44,344 bytes) 2021-01-19 13:32
https://tracker.ardour.org/file_download.php?file_id=3934&type=bug
png

automation-pints-moved.png (36,490 bytes) 2021-01-19 13:32
https://tracker.ardour.org/file_download.php?file_id=3935&type=bug
png
Notes
(0025438)
nick_stephens   
2021-01-19 13:34   
I have used Ardour 6.5 in this example, in the hope that the bug only affects Mixbus 6. It affects both.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8306 [ardour] bugs minor always 2020-07-13 05:37 2021-01-18 23:23
Reporter: jdfox Platform: Debian GNU  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cancel Selection fails in Draw and Internal Edit modes.
Description: ESC wont cancel selection in Draw and Internal Edit modes. Markers or regions left selected. Using 6.0
Tags:
Steps To Reproduce: Select a marker or region in either of these modes and try to cancel selection with ESC
Additional Information: https://discourse.ardour.org/t/unselect-playhead-nudging/104410/
System Description
Attached Files:
Notes
(0025437)
paul   
2021-01-18 23:23   
git now contains fixes for this behavior. The changes are as follows:

1) the first selection of a MIDI note cancels all other selections. This follows a general rule we have that only 1 type of thing can be selected at once.

2) pressing escape to cancel note selection now also cancels the region selection

I'd appreciate feedback on whether this improves the workflow and/or meets expectations here.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8457 [ardour] features minor always 2020-10-26 16:11 2021-01-18 06:58
Reporter: Stemby Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Export tempo-mapped MIDI
Description: As reported here[1], Ardour does not currently export tempo information when exporting MIDI.

[1] https://discourse.ardour.org/t/export-tempo-mapped-midi/104866
Tags: ardour6, export, Midi, tempo
Steps To Reproduce: 1) create an Ardour project with a MIDI track and some MIDI notes. Time: 4/4; for the first bar, tempo 120/4; second bar, tempo starts at 120/4 and finishes at 60/4 (simulating a big rallentando); third and last bar, tempo 60/4.

2) select the MIDI track, Region ? Export… ? Test.mid

3) $ fluidsynth -a alsa -m alsa_seq -l -i /usr/share/sounds/sf3/default-GM.sf3 Test.mid

fluidsynth (or any other software) plays the MIDI file at 120/4, from the beginning to the end.
Additional Information:
System Description
Attached Files:
Notes
(0025430)
paul   
2021-01-17 22:59   
Your example in (1) cannot be correctly represented in an SMF file. The standard has no support for accelerando/ritardando.

It's not really correct to call that a "simulation" - it actually is a ritardando/rallentando.

Ardour would have to simulate this by inserting dozens of tempo changes into the SMF file (which some other software may or may not be able to handle.
(0025431)
timetre   
2021-01-18 06:58   
If the standard supports it, supporting signature change (4/4 -> 2/4) and immediate tempo change (120 -> 80) would already be an improvement.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8482 [ardour] bugs minor always 2020-12-03 10:07 2021-01-17 13:49
Reporter: peder Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Importing MIDI file crashes Ardour running on jack2
Description: All versions of Ardour after 6.2-38-ga7a938275f crash while importing MIDI files if it is running it on jack2
The error thrown is "JACK HALTED: JACK server has been closed"
I've tried self compiled versions up to 6.5-8-g8d0a655608 and also the official 6.3 release and they all fail.

Importing using Alsa or Pulseaudio works fine.

Tested on Ubuntu 18.04 and openSUSE 15.2

Tags:
Steps To Reproduce: Start jack2; my settings are "-r -dalsa -r48000 -p512 -n2 -D -Chw:MID,0 -Phw:MID,0" and I've tried jack2-1.9.12 and .16
Start ardour-6.2-39-gf6c0b02d9f or later
Import a MIDI file; I've used https://bitmidi.com/uploads/96653.mid
Additional Information:
System Description
Attached Files:
Notes
(0025313)
peder   
2020-12-15 12:28   
Brief error log from dmesg and syslog

ArdourGUI[9954]: segfault at 8 ip 00007fbf24aeeb3a sp 00007ffcf963bc30 error 4 in libjack_audiobackend.so[7fbf24ac8000+3e000]
Code: 35 c3 83 21 00 48 8b 15 94 83 21 00 31 c9 e8 cd fe fe ff 48 85 c0 0f 84 43 01 00 00 48 8b 5b 08 48 85 db 74 05 f0 83 43 08 01 <48> 8b 78 08 e8 6d f0 fe ff 4c 8d 6d 10 48 85 c0 49 89 c6 4c 89 6d
ArdourGUI[10348]: segfault at 8 ip 00007f4d75f7db3a sp 00007ffcb67a7d70 error 4 in libjack_audiobackend.so[7f4d75f57000+3e000]
Code: 35 c3 83 21 00 48 8b 15 94 83 21 00 31 c9 e8 cd fe fe ff 48 85 c0 0f 84 43 01 00 00 48 8b 5b 08 48 85 db 74 05 f0 83 43 08 01 <48> 8b 78 08 e8 6d f0 fe ff 4c 8d 6d 10 48 85 c0 49 89 c6 4c 89 6d

xubuntu kernel: [ 1660.462816] ArdourGUI[9954]: segfault at 8 ip 00007fbf24aeeb3a sp 00007ffcf963bc30 error 4 in libjack_audiobackend.so[7fbf24ac8000+3e000]
xubuntu kernel: [ 1830.400977] ArdourGUI[10348]: segfault at 8 ip 00007f4d75f7db3a sp 00007ffcb67a7d70 error 4 in libjack_audiobackend.so[7f4d75f57000+3e000]
(0025429)
jarinox   
2021-01-17 13:49   
I have the same problem - same error is thrown.
Importing using ALSA and Pulseaudio works for me fine too.
I'm using Ardour 6.5.0 on Arch Linux 5.10.6-arch1-1.

Error:
Reading MIDI 1 took 1 microseconds, final size = 0
JACK HALTED: JACK server has been closed
Segmentation fault (core dumped)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8539 [ardour] bugs minor always 2021-01-13 12:57 2021-01-16 14:11
Reporter: inFlowiaLab Platform: Linux  
Assigned To: OS: Ubuntu Studio  
Priority: normal OS Version: 19.10 x64  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When "saving as" a project to FAT32, all files with the case insensitive same name will be lost,
Description: If the project contains files with the same case-insensitive names, such files will be lost when the "Save As" operation is performed on a media with the FAT32 or FAT16 file system. At the same time, Ardour WILL NOT SAY ANYTHING.
Tags: fat16, fat32, filesystem, missing source
Steps To Reproduce: 0 Create a project on a disk with NTFS file system.
1 Create an audio track named "a".
2 Record 1 audio region (it will be named a-1.1 and a-1.wav file will be created).
3 Rename the track to "A".
4 Record 1 audio region (it will be named A-1.1 and A-1.wav file will be created).
5 Run: "Session - Save As" and specify the media with the FAT16 or FAT32 file system as the destination
6 Check the presence of both files (a-1.1 and A-1.1) in the project directory on the FAT media.
One of the files will not be there.
Additional Information: I quite often got a problem after going to the studio with a project and transferring it to a USB flash drive with FAT32. I returned home, opened a project saved in the studio and found that Ardour was swearing about missing files. I didn't understand where they were going, because there were no problems with saving.

In addition, there will be problems if you open the project directly from a USB flash drive with FAT and try to follow steps 1-4. The second region will simply not be recorded. A striped yellow region with no audio data appears.

Also, I constantly face problems when synchronizing a project with a project on a USB flash drive using some program like Free File Sync. Just because of files with the same names, case insensitive.
System Description
Attached Files:
Notes
(0025413)
x42   
2021-01-13 13:28   
You have to zip up the session to transport it on a USB/FAT file system.
Session > Archive may also be an option.

You're right that Ardour should warn about this and refuse to save sessions to case-insensitive file systems.
(0025428)
inFlowiaLab   
2021-01-16 14:11   
In fact, it would be much cooler if you added support for case-insensitive file systems (by eliminating the generation of names that differ only in case) and here's why:
FAT32 is the best file system for flash drives as it extends the lifespan of flash drives.
Another great way to prolong their life is to minimize their use. Moving a project in the archive is very suboptimal in relation to a USB flash drive. My average project is 1.5GB. During one trip to the studio with a flash drive, I usually make changes of 100-400MB. If I use the archive, then in any case I will have to overwrite the entire 1.5GB, but if I have the project just as it is, then I can use synchronization and make changes to 100-400MB, which is much more economical in terms of time and life of the flash drive.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8540 [ardour] bugs minor always 2021-01-13 22:47 2021-01-14 17:06
Reporter: zettberlin Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ACE EQ crashes Ardour when opening GUI
Description: I used ACE EQ successfully in a project including its GUI.
In the very same project it crashed Ardour after inserting a new instance in the master channel, when I tried to open its GUI(double click in the mixer strip).
After this happened, ACE EQ crashed a very new project also, that I had set up to test the problem.
But in that new project, Ardour crashes as soon as I try to insert the ACE plugin.
Inserting other ACE (compressor)works but also crashes as soon as I attempt to open the GUI.
Tags: ACEplugins, ardour6
Steps To Reproduce: Open project
insert ACE EQ:

HOST BG COLOR RGBA: 0x3d3d3dff
HOST CONTRAST COLOR RGBA: 0x4bcd2fff
HOST THEME BOXY: FALSE
HOST THEME FLAT: FALSE
doublebuffered rendering available
GLX-Version 1.4
The program 'ardour-6.5.0' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 22 error_code 2 request_code 151 minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Speicherzugriffsfehler (Speicherabzug geschrieben)

I ran ardour6 with that --sync option BTW


Additional Information: The only faint hint I could give is, that I tried to inster a Harrison Plugin while working on the first session, got some Message, no success with the Harrison and so I moved on.
As far as I remember, I used the ACE EQ GUI before that attempt on Harrison successfully, I cannot tell, if I did so after too...

I do this with the latest official release from ardour.org
In Ubuntu Studio 20.4.1 LTS

Test project is attached.
System Description
Attached Files: ACETest-2021-01-13-23-13-30.ardour (10,977 bytes) 2021-01-13 22:47
https://tracker.ardour.org/file_download.php?file_id=3930&type=bug
instant.xml (1,643 bytes) 2021-01-13 22:47
https://tracker.ardour.org/file_download.php?file_id=3931&type=bug
Notes
(0025415)
zettberlin   
2021-01-13 23:14   
HINT:

All xt-* Harrison plugins do crash the project as well... at instert in the mixerstrip
(0025416)
x42   
2021-01-14 00:04   
That smells like an OpenGL issue. - Which graphics card and driver are you using?

Can you load them after disabling Preferences > Plugins > Automatically open the plugin GUI when adding a new plugin ?
(0025417)
zettberlin   
2021-01-14 00:33   
I can insert them, when the auto opening of the GUI is disabeled, and they seem to work perfectly OK with the generic builtin GUI

My Graphics is this:

01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)

Running with thr recent proprietary driver.
(0025419)
zettberlin   
2021-01-14 10:59   
After restarting the whole machine, the GUI of ACE EQ works OK, takes a few seconds to load tho.
I also see some lags in the transport animation, when their GUI is open.
Maybe related: All Plugins from Pere Ráfols Soler (several EQ) do not show their GUI as well...
(0025420)
x42   
2021-01-14 17:06   
The latter is a binary incompatibility (gtk2 libs) you have to use binaries from http://eq10q.sourceforge.net/?page_id=16

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8541 [ardour] bugs minor always 2021-01-14 00:06 2021-01-14 00:06
Reporter: kidorion Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi quantize not working
Description: I can't get quantize to work at all.
I tried quantizing whole regions and individual notes.

Tags:
Steps To Reproduce: Open new session
Create a midi track
With edit tool drag to make a midi region and draw in a single midi note.
Drag note so it is approx 50 tics late.
Right click on note and select Quantize.
Quantize Settings [I didn't find any combination to work yet]:
Snap not start and end = 1/4 note
Threshold (ticks) = 300
Strength = 100
Swing = unticked
Click Quantize
Note doesn't move. No messages or feedback.




Additional Information: I'm new so I could be making a fundamental error!
Thanks.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8538 [ardour] bugs minor random 2021-01-11 21:49 2021-01-11 21:58
Reporter: newbie44 Platform: microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 7 64 bits  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes on exit when the audio/midi setup menu isn't stop.
Description: I use ardour 6.5 64 bits on windows 7 64 bits. With Asio4All.

When I quit ardour, I must first stop Asio4All in the audio/midi setup menu. If I forget to do it, Ardour freeze and the windows splash menu "This application has stopped responding what do you want to do? (wait, force leave..)" appears.
Tags:
Steps To Reproduce: Open Ardour. Quit ardour.
Ardour seems to freeze a moment and the "this application has stop responding" Windows menu appears. One can only exit ardour by forcing stop in the task manager.
Additional Information:
System Description
Attached Files: Ardour-6.5.0-crash-1610400187.txt (221 bytes) 2021-01-11 21:49
https://tracker.ardour.org/file_download.php?file_id=3927&type=bug
Ardour-6.5.0-crash-1610400652.txt (445 bytes) 2021-01-11 21:49
https://tracker.ardour.org/file_download.php?file_id=3928&type=bug
Notes
(0025412)
x42   
2021-01-11 21:58   
Sadly the crashlogs are not very useful for the case at hand :(

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8536 [ardour] features minor always 2021-01-08 15:19 2021-01-08 15:19
Reporter: slavikator Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Chords line under timecode
Description: Timecode, Ranges, Markers...

One more line for "Chord Markers" that wouldn't be visible in "Navigation Timeline"

I tried using CD markers for that purpose but in such a case the "Navigation Timeline" gets overfilled and marker-useless. So adding one more line that doesn't visualize in "Navigation Timeline" could help.

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20210108_170405.png (20,148 bytes) 2021-01-08 15:19
https://tracker.ardour.org/file_download.php?file_id=3920&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8532 [ardour] bugs minor sometimes 2021-01-07 11:15 2021-01-07 11:15
Reporter: Derrickkkw Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: no sound
Description: audio already record and can replay after closing and reopen the audio still can running but without sounds but other audio in ardour still work fine .
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8530 [ardour] bugs minor always 2021-01-05 20:28 2021-01-06 10:49
Reporter: studiodv Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: Mixbus 6.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ArdourMIDIBindings / all msg data received not executed
Description: Hi Dev team, congratulations for your genial software.

I've connected my Audient ZEN analog console to Mixbus. The automation of the console faders and mutes works very well using the Audient Faderlink plugin inserted on each track.

The ZEN console has five standard transport buttons: <<, >>, Stop, Play, Record
To be able to remote the Mixbus transport functions, I've built and added a "ZEN console midi map" file (see file attached).

Everytime that a ZEN transport button is pressed, the console sends a sentence of 6 bytes (2x controls msg), like "b0 0f 0e b0 2f 43" in the Stop example.
When the midi map contains <Binding msg="b0 0f 0e b0 2f 43" function="transport-stop"/>, Mixbus ignores the transport function. Nothing occurs.

To trigger Mixbus with success, you should reduce the "sentence to receive" to 3 bytes (1x control msg), like "b0 2f 43" is the same Stop example: <Binding msg="b0 2f 43" function="transport-stop"/>

Using this protocol reduction, there is of course no feedback on the ZEN console, the console buttons remain unlighted.

Many thanks in advance for your cooperation,
happy new year 2021 !
Sincerely,
Chris
Tags: automation, control, MIDI control, surfaces
Steps To Reproduce: You should add a new folder: ~/Bibliothèque/Preferences/Mixbus6/midi_maps/
Copy this zen-transport.map (file attached) in it

Declare a Generic midi Control surfaces in the Mixbus preferences, and select the "Zen Console master transport" item.
Enable Feedback

Press the ZEN console transport buttons
Additional Information:
System Description
Attached Files: zen-transport.map (585 bytes) 2021-01-05 20:28
https://tracker.ardour.org/file_download.php?file_id=3917&type=bug
Notes
(0025384)
studiodv   
2021-01-06 10:49   
Just to add that this solution is not the best (the console buttons remain unlighted), because there's a midi data conflict between the ch#1 mute and the "Go to end" transport function. In consequence, I've inihibited the "transport-end" function in the zen-transport.map file.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5457 [ardour] bugs minor always 2013-04-23 19:24 2021-01-05 19:09
Reporter: Lost_Highway Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 3.0  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feedback loop detection [was: No sound and unrealistically low CPU load on re-opening a specific session]
Description: Using Ardour 3.1 binary from the Ardour website (3.1-3-g1606996)

A session I was working on, which had a CPU load ~50%, was saved and closed. Upon re-opening the session the following day, the CPU load now registers 2% and there is no sound at all from the session.

Notes:
-- No tracks are soloed
-- Mute isn't activated on either the Master or Monitor section, Monitor volume at 0 dB
-- Transport appears to work normally
-- The session has been saved and re-opened numerous times before
-- Other sessions work fine
-- Not aware of any relevant lib upgrades from Ubuntu (doesn't using the binary from the website negate this?)
-- In qjackctl, all the relevant track/bus connections look to be in place, with tracks connected to Master, Master connected to Monitor, Monitor connected to system playback_1 and _2
-- Renaming and using the .bak session file instead makes no difference
-- Session file attached

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: SPANISH THEME ICE AXXE.ardour (547,686 bytes) 2013-04-23 19:24
https://tracker.ardour.org/file_download.php?file_id=2126&type=bug
Notes
(0014878)
the_CLA   
2013-04-23 22:20   
Loading the session I noticed that the feedback button is blinking. The feedback detection is intended to keep you from accidentally creating a feedback loop wich might be harmful for your hearing and/or equipment, but I believe it is currently a bit broken in that it only blocks the audio after a session reload.

Also I dislike the way it currently is implemented. IMHO instead of blinking a button it should open a popup on creation and ask if the loop is intended, as there are cases where one wants to create a feedback loop - for example for adding filters in a delay loop etc... Maybe the feature should be disabled as long as it is not implemented properly.

Regarding your session I wasn't able to indentify a loop on a quick overview. So not sure if there actually is a loop or if Ardour only *thinks* there is one.
(0014879)
Lost_Highway   
2013-04-23 22:28   
There should be a feedback loop and it was intentional: a bus (with delay) feeds into a second bus (with reverb) that then feeds back into the first one.

The session operated fine with the feedback loop. Can't remember whether I've successfully re-opened it since, or whether it was the day after creating the feedback loop that it wouldn't re-open correctly.
(0014880)
the_CLA   
2013-04-23 22:34   
Ah, I see it now. Deleting (only disabling doesn't work AFAIK) one of the sends should bring back the sound again.
(0014881)
Lost_Highway   
2013-04-24 09:06   
Deleting one of the sends has restored audio.

So it's a "feature" of the feedback detection. I agree that the way it is implemented is not helpful: as you say, the fact that feedback loops can be purposefully implemented and serve a useful purpose, but also the fact that sound is disabled automatically without there being any message or warning of why it has been disabled.
(0014882)
Lost_Highway   
2013-04-24 09:08   
Disabling of audio is a "feature" when there is an audio feedback loop present in a session.
(0014883)
nettings   
2013-04-24 10:11   
I got bitten by the same issue recently, and briefly discussed this with las and rgareus on IRC.
There is a "workaround": the audio only gets disabled when you load the session with feedback present. When you create a feedback loop at runtime, the warning lamp will blink but the audio graph will continue processing.
So before you save, break the feedback loop, and reconnect it manually when you resume working the next day. Ugly, but will get you going.
(0014884)
nettings   
2013-04-24 10:17   
I'm reopening this bug because the reporter got bitten by the current implementation, which is less than ideal.
The way I see it, Ardour3 should

* mute audio the moment a feedback loop is created at runtime (which it doesn't, right now)
* blink the warning button red (which it does)
* allow the user to acknowledge that this particular feedback is intentional, and continue working, or detect that the user has removed an unintentional feedback loop, and continue working.

The problem with the status quo is that Ardour makes you believe creating feedback loops is ok and works, and then stops cooperating when you restore the session.
(0014887)
x42   
2013-04-26 11:11   
Feedback detection is not a feature. It's a side-effect.

Ardour tries to determine the order in which audio from all tracks/routes needs to be processed. IOW "it builds an execution graph and topologically sorts it".

If there is a feedback loop, the graph cannot be sorted.
Ardour it just uses the old graph - until the feedback loop is resolved.

When you reload a session -> there is no old graph.

The old graph order /may/ work with the feedback-loop that you've created but when you add new tracks or busses after creating a feedback loop, those nodes will not be included in the audio-processing graph.

There is no easy way to "disactivate" this feature. -- Ardour could break the loop for you (at some arbitrary point) in order to sort the graph:..the looped-back signal would arrive one cycle later. Yet Ardour cannot know which path it should keep and does not make any assumptions.

The old execution graph may produce feedback with the new set of connections.. Hence Ardour should just not use the old graph -> that'd fix the aspect of "makes you believe it works" and it would always mute the audio in case of a feedback.
(0025382)
caryoscelus   
2021-01-05 19:09   
even though this issue is old, it seems to be the most up-to-date discussion on topic, so since it's still not resolved i'm going to write my thoughts here.

that's a good explanation of the issue i haven't understood previously. thanks, x42.

but i think it also reveals potential solution. i'm not sure if there's any other valid use for feedback loops, but the only way i find them useful is when there's a delay (as explained here: https://discourse.ardour.org/t/creating-and-controlling-feedback/90481/7). in such situations proper sorting is still possible if delay plugin is discovered correctly (one way would be to make delay a built-in feature, but i'm not sure what would be easier/more convenient/generally better for ardour). would it be possible to implement this?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8522 [ardour] features minor have not tried 2020-12-25 00:03 2021-01-05 16:27
Reporter: rozea Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Display parameters of a instrument plugin instead as alternative to a GUI
Description: GUIs of (instrument) plugins do cover the canvas of a DAW. This is not always pleasant to work with.

I want to share how Radium is doing this, which I find pretty pleasant to work with. (It has also a option to display the GUI.)

Tags: GUI, lv2, plugin, VST
Steps To Reproduce:
Additional Information:
Attached Files: radium_VST_parameters.png (123,919 bytes) 2020-12-25 00:03
https://tracker.ardour.org/file_download.php?file_id=3901&type=bug
png

bitwig_instrumentdisplay_parameters.png (169,662 bytes) 2020-12-25 21:25
https://tracker.ardour.org/file_download.php?file_id=3902&type=bug
png
Notes
(0025354)
rozea   
2020-12-25 21:25   
Bitwig-studio does something similar
(0025380)
paul   
2021-01-05 16:27   
You can already put any parameters from a plugin into the mixer strip, to achieve something extremely close to what you are asking about.

Right click on the plugin "bar" in the mixer strip, and navigate to "Controls"

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8515 [ardour] bugs minor always 2020-12-23 15:15 2021-01-05 16:19
Reporter: reaw Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes at start when opening a specific session
Description: I recently created a new Ardour 6.5 session, and when I try to open it Ardour crashes.
I tried to open it on a different computer and the same issue occurs.

I tried to open it in safe mode, and the session manages to load correctly.
I think that the issue is related to a midi file.

Here is the output of the gdb console.
Tags: crash, Midi
Steps To Reproduce: Start Ardour, open session
Additional Information: Running on Windows 10 64bits
Intel i7-6500
16GB RAM
Radeon RX480
System Description
Attached Files: output_gdb.txt (17,064 bytes) 2020-12-23 15:15
https://tracker.ardour.org/file_download.php?file_id=3897&type=bug
Notes
(0025377)
paul   
2021-01-05 16:19   
If safe mode fixes the issue, then the problem is with a plugin.

Also, for the gdb output, you need to type this command:

    threads all bt

to get a full backtrace.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8514 [ardour] other minor have not tried 2020-12-22 18:45 2021-01-05 16:16
Reporter: iur.n Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Parts of MIDI notes shown outside of the MIDI region
Description: Parts of the MIDI notes are shown outside of the MIDI region. I don't know if it should be like this but I don't remember this kind of behaviour before.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: midi.png (14,353 bytes) 2020-12-22 18:45
https://tracker.ardour.org/file_download.php?file_id=3895&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8512 [ardour] bugs minor always 2020-12-21 13:32 2021-01-05 16:15
Reporter: finotti Platform: Linux  
Assigned To: paul OS: Debian  
Priority: normal OS Version: Unstable  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI not editable after first import
Description: When editing a MIDI file (like deleting or moving notes) after first importing it (and before restarting Ardour), the changes can be seen visually, but playing only plays the original (unedited) MIDI file.

Saving and restarting the changes previously made take effect and any new changes in the MIDI track work as expected.
Tags: Import, Midi
Steps To Reproduce: 1) Create a MIDI file (in Muse, in my case). I made one with a single track and only 3 notes.
2) Create new Ardour session.
3) Import the MIDI file.
4) Add synth plugin.
5) Play it and all is fine.
6) Edit it. Visually you see the notes changes. But playing plays the notes before editing.
7) Create a new MIDI region in the same track. Add some notes. It plays as expected.
8) Move some notes around, and it also works as expected.
9) Play the imported region, and the previous edits take effect.
10) Editing this imported region has again no effect!
11) Edit the created region, and it again works as expected.
12) Play the imported region and the second set of changes now play correctly.
13) Saving and restarting the imported region works as expected.
Additional Information:
System Description Using also KXStudio repositories.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8492 [ardour] features minor have not tried 2020-12-10 22:38 2021-01-05 16:11
Reporter: ksawerytreningowski Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Controller lane combobox menu
Description: It would be a few times faster and easier to select the controlers from the menu
or from the combo box
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Controler lane combobox menu.png (49,563 bytes) 2020-12-10 22:38
https://tracker.ardour.org/file_download.php?file_id=3878&type=bug
png
Notes
(0025376)
paul   
2021-01-05 16:11   
If I understand correctly, you're suggesting a way to switch the contents of an existing controller lane (thus avoiding having to hide the current one and then show the new one) ?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8489 [ardour] features minor N/A 2020-12-07 14:41 2021-01-05 16:10
Reporter: gnzg Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Improving the Editor List - 3
Description: (using i3wm)
Oops, yet another Editor List feature request, sorry for spamming, but it's a cool feature that would benefit a lot from being expanded imo :)
For the sake of spamming a little less on this board, I'm going to mention 2 features here:

1: Editor Auto-Play
It would be great to have a little checkbox somewhere in the "Sources" panel (and maybe the "Regions" one?) to auto-play whatever source is selected, very similar to the auto-play feature from the import menu, except directly within the editor list !

2: Copy and paste directly from source list
Pretty self explanatory, allowing the user to Ctrl-C a source from the source list, pasting it anywhere in the editor timeline automatically creates a corresponding region in the "Regions" list

One thing that makes this feature pretty powerful is that you can assign the Edit Point to the mouse and snap the mouse to the grid and then copy the same file several times, allowing you to create patterns with percussions samples in a pinch :)

Thinking about it, maybe "Copy" isn't the right word because Ctrl-X "Cut" wouldn't really make sense in this context, but the general idea still stands :)

This is my last feature request for today, pinky promise !
Again, sorry for the spam, hope this is constructive :)
Tags: auto-play, copy, editor list, paste
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025375)
paul   
2021-01-05 16:10   
thanks for the constructive ideas.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8528 [ardour] bugs minor always 2020-12-30 19:42 2021-01-02 21:21
Reporter: szszoke Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6.5 crashes after the BOSS GT-1000 is selected as an input and output device in the Audio/MIDI Setup dialog
Description: When I start a new Ardour 6.5 session
Or I load an existing session and bring up Audio/MIDI Setup Window
And I select the BOSS GT-1000 CORE as Input and Output devices
And I press the Start button
Then the splash screen is visible for about a second
And then Ardour.exe crashes without any
Tags:
Steps To Reproduce: 1. Start a new session or open an existing session and bring up the Audio/MIDI Setup dialog
2. Select the BOSS GT-1000 CORE as Input and Output device
3. Press the Start button
Additional Information: I have a Focusrite Scarlett 2i2 2nd Gen that does not trigger the crash.
I tried with both the official 6.5 version and the latest nightly at the time (rev 6.5-63-g3f60d12). The bug can be reproduced in both.

Other BOSS/Roland devices that were tested:
1. BOSS Pocket-GT - reproducible
2. BOSS SY-300 - reproducible

Multiple USB ports and USB cables were tested and made no difference to the outcome.

I do not own any other ASIO compatible devices that I could use for testing.
System Description
Attached Files: Ardour-debug.log (38,195 bytes) 2020-12-30 19:42
https://tracker.ardour.org/file_download.php?file_id=3916&type=bug
Notes
(0025366)
szszoke   
2020-12-30 19:47   
I forgot to mention that I was using the PortAudio audio system.
(0025367)
szszoke   
2020-12-30 19:51   
Ableton Live 10 Lite has no issues using the GT-1000 CORE so I am quite confident that at least the USB connection and drivers are working.
(0025368)
szszoke   
2020-12-30 19:54   
The bug cannot be reproduced if I use the MME driver instead of ASIO but that is not desirable because the different channels of the GT-1000 appear as different audio devices and I can only select one input/output.
(0025369)
szszoke   
2020-12-30 20:03   
It seems that enabling buffered IO prevents the crash from happening.
(0025372)
szszoke   
2021-01-02 21:21   
While there is a workaround for this bug, I think an error message would be better instead of a crash.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5826 [ardour] bugs major always 2014-01-14 17:09 2020-12-31 15:18
Reporter: oofus Platform: i7 3770K 3.5GHz,16GB Memory  
Assigned To: OS: Kubuntu  
Priority: high OS Version: 13.10 64bit  
Status: new Product Version:  
Product Build: 3.5-1232-gcfc9a1f Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: There is a noticeable glitch in the audio when playing back a region and moving another region on the same track.
Description: There is a noticeable glitch in the audio when playing back a region and moving another region on the same track.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0015595)
oofus   
2014-01-19 13:43   
There is also a noticeable artefact in audio playback when trimming a region while it is playing back. More noticeable on stereo regions, the right hand side sounds like it becomes delayed for a fraction of a second at the point the mouse button is released to end the trim.
(0025371)
jmtrivial   
2020-12-31 15:18   
This bug is still present in ardour 6.3 on Debian Testing. It was also still present in ardour 5.x on Debian stable.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8159 [ardour] bugs minor always 2020-05-28 16:48 2020-12-27 18:03
Reporter: sk-os Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: contour - controller not working
Description: my contour shuttleXpress is not working
Ardour detects it "found shuttleexpress" but no action is working
if I press any button nothing happens. with and without "button test" enabled. joggle wheel not working
Tags: control
Steps To Reproduce: plugin controller in - start ardour - press a button or use the joggle
Additional Information: ardour 6.0.0 on archlinux 5.6.14-arch1-1 0000001 SMP PREEMPT Wed, 20 May 2020 20:43:19 +0000 x86_64 GNU/Linux
lsusb: Bus 001 Device 011: ID 0b33:0020 Contour Design, Inc. ShuttleXpress
System Description
Attached Files:
Notes
(0024732)
sk-os   
2020-07-13 18:38   
same in ardour 6.2
(0025265)
mschultz777   
2020-11-25 07:21   
Same issue with Shuttle Pro 2

ardour 6.5 on Intel® Core™ i5-4570R CPU @ 2.70GHz × 4 running Ubuntu 20.04.1 LTS
(0025359)
sk-os   
2020-12-27 18:03   
seems like the problem is based on the udev rules

working udev rule:
SUBSYSTEM=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0030", MODE="660", GROUP="audio"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0020", MODE="660", GROUP="audio"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0010", MODE="660", GROUP="audio"

however, if you are using the contour with kdenlive, you need:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0020", MODE="0444"
which doesn't work with ardour

so you have to choose to use the shuttle device in kdenlive or ardour

my solution to use it for both programs - set udev rule to:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0020", MODE="0664" OWNER="MYUSER"

I'm not shure exactly why this is the only version that works.. maybe someone who understands udev better than me could clarify that.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8525 [ardour] features minor have not tried 2020-12-27 10:08 2020-12-27 10:08
Reporter: rozea Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Swing (the Radium way)
Description: Something to consider. Radium tracker gives the possibility to apply a swing weight to every part of a beat / quarter note

http://users.notam02.no/~kjetism/radium/documentation/swingtext_editor_framed.html

One area where Radium seems to shine is the possibilities it gives you to edit and automate musical / dynamics parameters. Like adding swing very detailed, automated tempo etc.
Tags: swing
Steps To Reproduce:
Additional Information:
Attached Files: globalswing_radium.png (21,060 bytes) 2020-12-27 10:08
https://tracker.ardour.org/file_download.php?file_id=3912&type=bug
png

trackswing_radium.png (24,389 bytes) 2020-12-27 10:08
https://tracker.ardour.org/file_download.php?file_id=3913&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8524 [ardour] bugs minor random 2020-12-27 05:53 2020-12-27 05:53
Reporter: inFlowiaLab Platform: Linux  
Assigned To: OS: Ubuntu Studio  
Priority: normal OS Version: 19.10 x64  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Captured For" is not always displayed on the "Sourses" tab In the Editor List
Description: Found that a midi clip for which the "Capture for" field remains empty is actually successfully in the track. See screenshot.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 2020-12-27_08-34-52.png (95,151 bytes) 2020-12-27 05:53
https://tracker.ardour.org/file_download.php?file_id=3911&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8520 [ardour] bugs minor always 2020-12-24 17:42 2020-12-24 17:42
Reporter: inFlowiaLab Platform: Linux  
Assigned To: OS: Ubuntu Studio  
Priority: normal OS Version: 19.10 x64  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Clips with cut notes are not transposed correctly.
Description: Either only the uncut note is transposed, or only the cut note and is not always transposed in the desired direction (+ -)
Tags: Midi, MIDI region, midi transpose, notes, Trim
Steps To Reproduce: 1 Create a midi clip 4 beats long
2 Draw a note in a clip with a length of 2 beats from the beginning to the middle of the clip
3 Draw a note in the clip 2 beats long from the middle to the end of the clip
4 switch to G mode
5 reduce the length of the clip by 1 beat from the end
6 try to transpose an 1 octave
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8517 [ardour] features minor always 2020-12-23 19:38 2020-12-23 19:38
Reporter: bachstudies Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add CD Marker via keyboard shortcut
Description: Allow for direct CD Marker creation via keyboard shortcut like Ctrl+Alt+I. Very useful for adding CD markers while listening back and judging gaps between tracks. Currently I use TAB shortcut for general marker but then I need to go into the location window and click on every single CD checkbox.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8516 [ardour] features minor always 2020-12-23 19:29 2020-12-23 19:32
Reporter: bachstudies Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Multi-track ripple edit
Description: As per discussion here: https://tracker.ardour.org/view.php?id=7714

Multi-track ripple edit would be great. It is a feature I have used heavily in Reaper and Samplitude. Ideally all markers by default should move along with the regions. Much quicker than inserting or removing time via the track menu!
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025350)
bachstudies   
2020-12-23 19:32   
While session-wide "multi-track ripple" would be best, a second option would be to allow tracks that are grouped to have this behavior. Option for markers/ranges to ripple would still be very important.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2631 [ardour] features feature N/A 2009-04-10 16:55 2020-12-23 12:49
Reporter: rozea Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 2.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Advanced CLICK options for musicians
Description: I have some suggestions to make the CLICK function more musical useful.

1) Especially Jazz and Blues musicians, use the metronome on the second and fourth beat, this allows them to add a little swing in the
rhythm.
With Ardour this is of course possible with cutting the tempo of the click in half. But then there is an annoying first loud beat in
it. It would be nice if it would be possible to use CLICK without such an first loud beat too (so you got two options).


2) It could be useful to allow the CLICK function to flash lights instead of sound clicks. When you don't have an headphone, or want to
use your ears to listening to the music you make (instead of covering them with an headphone). It would be nice if you could enlarge
that flashing light, like you can enlarge the play/control buttons. (most of the metronomes have this feature)

maybe something can be done in corporation with the nice metronome for JACK
http://das.nasophon.de/klick/
Tags: Metronome, swing, workflow
Steps To Reproduce:
Additional Information:
Attached Files: renoise_metronome_beatsperbar.png (11,095 bytes) 2020-12-23 12:49
https://tracker.ardour.org/file_download.php?file_id=3896&type=bug
png
Notes
(0005883)
rozea   
2009-04-10 19:59   
I see Gtick has also an visual option. I'm in doubt whether is should be displayed like in Gtick, (visual stimulus moves from left to right and back),
or just an flashing light dot or button.

http://www.antcom.de/gtick/
(0005884)
rozea   
2009-04-10 20:00   
uh Gtick is not the same metronome as KLICK...

klick: http://das.nasophon.de/klick/ (has also an gui gtklick) (jack application)
gtick: http://www.antcom.de/gtick/ (non-jack, but visual option)
(0025348)
rozea   
2020-12-23 12:49   
Not sure what is possible with Ardour in Ardour 6, but in renoise you set metronome beats per bar. Not sure if you can set it on the 2nd and 4th beat.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8499 [ardour] features minor N/A 2020-12-15 00:50 2020-12-22 18:21
Reporter: Exaaactly Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add effects to clip
Description: Hi to Ardour developers team and to all. I'm new user of Ardour and i'm trying to use it for creating a small video/film postproduction, podcasting and as music editing tool. And everything is going fine for now. But what i really missing is ability to add fx on separate clips. To render them as new files and use in project. For some of denoising/deessing staff, declicking for EQing etc. Automation is a good thing, but sometimes we need some of destructive editing. Hope you will add this feature soon.

Thanks for your work, you guys doing a great thing.
Tags: Ardour, Effect to clip, Renderring audio
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8351 [ardour] bugs minor always 2020-08-07 08:42 2020-12-22 16:37
Reporter: tavasti Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 6.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Import dialog midi auditioner plays notes in start of file as percussive
Description: Import dialog auditioner plays midi files first note/chord as percussive. First note will get note-off immediately, so that it won't ring. Following notes work as expected.
Behaviour is same regardless is auditioning with caused by auto-play selected or pressing play manually.

Tested in Mixbus rev 6.1-22-ge24d44dce
Tags:
Steps To Reproduce: 1) Open import dialog
2) Select suitable instrument plugin which will allow hearing when note off happens (for example piano sound works ok)
3) select some midi file containing notes in the beginning of midi file (for example attached doesntwork.mid)
4) try listening it

Attached two midi files, one where notes are 60 ticks late, and it works, and another where notes are in the beginning, and does not work.
Additional Information:
System Description
Attached Files: doesntwork.mid (68 bytes) 2020-08-07 08:42
https://tracker.ardour.org/file_download.php?file_id=3796&type=bug
works.mid (68 bytes) 2020-08-07 08:42
https://tracker.ardour.org/file_download.php?file_id=3797&type=bug
Notes
(0024904)
tavasti   
2020-08-07 17:26   
Tried also inserting short note in the beginning, but that does not change anything. For me 30 or 40 ticks after start did not fix the problem.
(0025346)
tavasti   
2020-12-22 16:37   
Made youtube video demoing problem: https://www.youtube.com/watch?v=esO-m1uvc3g

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8505 [ardour] bugs minor always 2020-12-16 21:08 2020-12-21 10:09
Reporter: toastjam Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI playback will not stop after using Home key
Description: When you press the home key to return the playback head to the beginning of a midi-only recording, you are unable to stop playback with the keyboard or graphic play button. The only solution is to save the file, exit and reopen the file.

Note: Starting and stopping a freshly loaded song with spacebar or onscreen buttons works until you press the Home key.
Tags:
Steps To Reproduce: 1. Open empty file

2. Record anything on a midi track

3. Press play and then press the Home key

4. Notice that you can't stop playback.
Additional Information: When you add an audio track, save file, restart Ardour 6.5 and play the save file, the home key works as expected. When I delete the dummy audio track and use the Home key, the problem appears again.

If you delete just the audio data in the track, the home key works and you are able to stop playback.

Ardour 6 in Ubuntu Studio does not have this problem.
System Description
Attached Files:
Notes
(0025327)
plimptm   
2020-12-17 14:21   
I'm experiencing the same problem, but the home key is not triggering the issue. The stop function seems to be disabled after making edits and playing a section of the MIDI file. Exiting Ardour is the only way I've been able to stop the playback.

Version 6.5
OS: Ubuntu 20.04
(0025338)
mikefaille   
2020-12-21 10:09   
It's a related issue : https://tracker.ardour.org/view.php?id=8490

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8511 [ardour] bugs minor always 2020-12-20 21:47 2020-12-20 21:49
Reporter: ranedmusic Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 7  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Plugins don't load
Description: I was using Ardour 5.6 x86-64 on my pc with linux, now i just moved to windows and downloaded the same version from ardour.org a 64bit version but lv2 plugins fails to load and the program crash. My motherboard is a q35m s2, processor is Pentium E5500, memory is 8gb ram ddr2 667
Tags: lv2
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Sem título.png (125,466 bytes) 2020-12-20 21:47
https://tracker.ardour.org/file_download.php?file_id=3892&type=bug
png
Notes
(0025336)
ranedmusic   
2020-12-20 21:49   
* Ardour 6.5 and not Ardour 5.6

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8508 [ardour] bugs minor random 2020-12-17 11:13 2020-12-17 11:14
Reporter: miroshko Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when starting a new recording with Shift+Space immediately after discarding the ongoing one with Ctrl+Space
Description: I am recording a piece, then want to discard it and instantly start over, so I press Ctrl+Space and then immediately Shift+Space.
As a result Ardour crashes.
This happens ca. 1 out of 20 times on Ardour 6 but used to happen much more frequently with Ardour 5 both on Linux and Windows.

Also this is getting worse the more takes I record. Presumably this has to do with the growing amount of temporary files the more takes I have made, because also the returning of the cursor to the initial point takes longer after Ctrl+Space. After cleaning up the unused session files the returning after Ctrl+Space is happening fast again and the crashes occur less frequently.

Debug log is attached.
Tags: crash, recording
Steps To Reproduce: Open empty session
Add 1 audio track
Arm the track
Hit Shift+Space (Record)
Hit Ctrl+Space (to stop recording, discard the record and return to the initial position)
Immediately after that press Shift+Space to start a new recording without waiting for the position marker to return to the initial position.
Repeat 20 to 30 times (presumably the amount of temporary files in the session has to grow large enough)
Observe the crash
Additional Information:
System Description
Attached Files: Ardour-debug.log (64,514 bytes) 2020-12-17 11:13
https://tracker.ardour.org/file_download.php?file_id=3886&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8506 [ardour] features minor always 2020-12-16 22:00 2020-12-16 22:03
Reporter: Houston4444 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature request: Varispeed improves
Description: Hi.
As said on IRC, I have some problems with the speed control of the play.
I try to use it to record some voices with a different speed (and also tone), but there are many uses where the current design is not comfortable (for example, listen slower to detect easily groove problems).
1 °) The fact that the speed is always reset to 100% (normal speed) each time transport is stopped or playhead is moved is annoying, because we have to start the play, and then change the speed, sometimes hardly because there is no quick tool to go back to a previous selected speed. It induces a 3 or 4 seconds manipulation between each take.
2 °) we can't manually change the speed value, making precise value impossible, for example, access to -1 semitone is impossible, the wheel goes directly from 0 to -2st. Same problem with %, there is a big difference between 87.1% and 103.0 % of the speed. Maybe a spin box appearing with double click on the speed label would achieve this.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025326)
Houston4444   
2020-12-16 22:03   
I saw that mouse wheel on the speed wheel affects fine changes, however here ardour crashes when change overlaps 100% (normal speed), I need to investigate before submit an issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8501 [ardour] bugs minor always 2020-12-15 22:37 2020-12-16 14:59
Reporter: rozea Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Renoise redux not working Ardour 6.5 (git)
Description: Renoise Redux demo version https://www.renoise.com/download

Very hard to get the editor open. After several clicks, it sometimes succeeds, I hear the 'hish' demo sound, but don't hear the instrument.

Main problem, not responsive in Ardour.

Plugin works in Carla

ardour$ git show
commit bbc54873aebeecf10571540963a6fdebebc36ab6 (HEAD -> master, origin/master, origin/HEAD)
Author: Robin Gareus <robin@gareus.org>
Date: Mon Dec 14 19:29:53 2020 +0100


I'm not using the plugin, so I can't guarantee I'll help with debugging. But if you need some info, you can always ask.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025320)
rozea   
2020-12-15 22:50   
Set cursor set to default
 loading from /home/debian/linuxaudio/Ardour/redux2 as redux2 templ is_new 0 bp 0
Renoise Redux LOG> ============================================================
Renoise Redux LOG> Version : Renoise Redux V1.1.4 (Nov 16 2020)
Renoise Redux LOG> Date : 2020-12-15
Renoise Redux LOG> Time : 23:27:24
Renoise Redux LOG> OS : Linux version 5.9.0-4-rt-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.0-19) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) 0000001 SMP PREEMPT_RT Debian 5.9.11-1 (2020-11-27)

Renoise Redux LOG> ============================================================
Renoise Redux LOG> VST Shell: Running in 'Linux Audio Systems Ardour 900'
Preparing to start...
Renoise Redux LOG> Redux: Initializing the API...
Renoise Redux LOG> System: Application path retrieved from dladdr: '/home/debian/.vst/renoise_redux.so'
Renoise Redux LOG> IPP: Detected CPU type: 0x46
Renoise Redux LOG> File-IO: Enabling MP3 decoding support using system's mpg123 library...
Renoise Redux LOG> Graphport: Initializing Freeimage...
Renoise Redux LOG> Graphport: Opening XDisplay ':0' (configured via 'DISPLAY' env)...
Renoise Redux LOG> Graphport: XDisplay was successfully opened
Renoise Redux LOG> GraphPort: Loading cursor images (libXcursor is present)...
Renoise Redux LOG> System: Running from directory '/home/debian/.vst/'...
Renoise Redux LOG> System: Using '/home/debian/.vst/renoise_redux.res/' as local resource directory...
Renoise Redux LOG> GraphPort: Initializing the Font Engine...
Renoise Redux LOG> GraphPort: Enumerating system fonts...
Renoise Redux LOG> Graphport: Initializing Keyboard mappings...
Renoise Redux LOG> Graphport: Initializing XAtoms...
Renoise Redux LOG> Application: Initializing Icon Bitmaps...
Reading the plugin caches...
Renoise Redux LOG> Application: Loading the preferences...
Loading the preferences...
Renoise Redux LOG> Application: Init...
Renoise Redux LOG> DspDevices: Registering native DSP effects...
Renoise Redux LOG> Application: Init OK
Renoise Redux LOG> Redux: Creating plugin shell instance...
Building player engine...
Renoise Redux LOG> Player: Constructing...
Renoise Redux LOG> Player: Start running...
Configuring audio subsystems...
Starting audio subsystems...
Starting MIDI subsystems...
Renoise Redux LOG> VST Shell: Unsupported host canDo: bypass
Opening the zip archive...
Loading instrument 'Renoise Redux_TmpFile-0-1.xrni'...
Loading sample 'SquareBrightGrit.flac'...
Loading sample 'phaseDistA.flac'...
Loading sample 'TchebyshevOsc.flac'...
Loading sample 'phaseDistDyadSmoothed.flac'...
Instrument was successfully loaded.
JackGraphManager::Connect already connected port_src = 25 port_dst = 20
JackGraphManager::Connect already connected port_src = 26 port_dst = 21
JackGraphManager::Connect already connected port_src = 1 port_dst = 24
JackGraphManager::Connect already connected port_src = 25 port_dst = 20
JackGraphManager::Connect already connected port_src = 26 port_dst = 21
JackGraphManager::Connect already connected port_src = 11 port_dst = 3
JackGraphManager::Connect already connected port_src = 12 port_dst = 4
JackGraphManager::Connect already connected port_src = 22 port_dst = 3
JackGraphManager::Connect already connected port_src = 23 port_dst = 4
JackGraphManager::Connect already connected port_src = 27 port_dst = 3
JackGraphManager::Connect already connected port_src = 28 port_dst = 4
locate to 0 took 2018 usecs for 2 tracks = 1009 per track
locate to 1984000 took 952 usecs for 2 tracks = 476 per track
Renoise Redux LOG> VST Shell: Open plugin editor...
Renoise Redux LOG> System: Application path retrieved from /proc/self/exe: '/usr/local/lib/ardour6/ardour-6.5.46'
Renoise Redux LOG> VST Shell: Requesting new window size: 870, 220
audioMasterSizeWindow 870 220
dispatch_x_events: ConfigureNotify cfg: (870 220) plugin: (870 220)

(ardour-6.5.46:3268): GLib-GObject-CRITICAL **: 23:28:52.406: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Reading Renoise Redux took 35 microseconds, final size = 0
Renoise Redux LOG> GraphPort: Loading cursor images (libXcursor is present)...
JackEngine::XRun: client = ardour was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Reading the plugin caches...
Renoise Redux LOG> Application: Loading the preferences...
Loading the preferences...
Renoise Redux LOG> Application: Init...
Renoise Redux LOG> DspDevices: Registering native DSP effects...
Renoise Redux LOG> Application: Init OK
Renoise Redux LOG> Redux: Creating plugin shell instance...
Building player engine...
Renoise Redux LOG> Player: Constructing...
Renoise Redux LOG> Player: Start running...
Configuring audio subsystems...
Starting audio subsystems...
Starting MIDI subsystems...
Renoise Redux LOG> VST Shell: Unsupported host canDo: bypass

(ardour-6.5.46:3268): GLib-GObject-CRITICAL **: 23:29:18.373: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(ardour-6.5.46:3268): GLib-GObject-CRITICAL **: 23:29:23.763: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(ardour-6.5.46:3268): GLib-GObject-CRITICAL **: 23:29:26.152: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(ardour-6.5.46:3268): GLib-GObject-CRITICAL **: 23:29:31.484: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Renoise Redux LOG> VST Shell: Open plugin editor...
Renoise Redux LOG> VST Shell: Requesting new window size: 1320, 720
audioMasterSizeWindow 1320 720
LXVSTPluginUI::resize_callback 1320 x 720
dispatch_x_events: ConfigureNotify cfg: (1320 720) plugin: (1320 720)
Butler drops pool trash
PluginWindow deleted for 0x563766e97960
Renoise Redux LOG> VST Shell: Closing plugin editor...
Renoise Redux LOG> Redux: Releasing plugin shell instance...
Renoise Redux LOG> Redux: Shutting down graphport...
Renoise Redux LOG> Redux: Releasing preferences...
Renoise Redux LOG> Redux: Shutting down MIDI subsystems...
Renoise Redux LOG> MIDI-IO: Shutting down the MIDI sequencers...
Renoise Redux LOG> Redux: Shutting down audio subsystems...
Renoise Redux LOG> Redux: Releasing player engine...
PluginWindow deleted for 0x563761443910
Renoise Redux LOG> VST Shell: Closing plugin editor...
Renoise Redux LOG> Redux: Releasing plugin shell instance...
Renoise Redux LOG> Redux: Shutting down graphport...
Renoise Redux LOG> Redux: Releasing preferences...
Renoise Redux LOG> Redux: Shutting down MIDI subsystems...
Renoise Redux LOG> MIDI-IO: Shutting down the MIDI sequencers...
Renoise Redux LOG> Redux: Shutting down audio subsystems...
Renoise Redux LOG> Redux: Releasing player engine...
Renoise Redux LOG> Redux: Finalizing the API...
Renoise Redux LOG> Closing log file...
JackTemporaryException : now quits...
Jack main caught signal 2
Released audio card Audio0
audio_reservation_finish
WARNING: 1 message buffer overruns!
(0025323)
rozea   
2020-12-16 14:59   
I've got it working now. The GUI is just not very responsive. Still count as a bug/ issue I think.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8504 [ardour] bugs minor random 2020-12-15 23:09 2020-12-15 23:09
Reporter: rosslagerwall Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Lockup when jack client changes
Description: If I'm running Ardour and I start the Hydrogen drum machine, the Ardour GUI sometimes locks up. It also sometimes happens if I'm running Ardour and Hydrogen and then I quit Hydrogen.

Investigation with top showed that Ardour was spinning at 100% CPU usage. I did poke it with gdb a bit and it seemed to be doing something with a jack port but unfortunately I lost the debugging session. I'll try to get some more logs if it happens again.
Tags:
Steps To Reproduce:
Additional Information: I'm using jack as the audio backend. I compiled Ardour from the 6.5 tag.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8503 [ardour] bugs minor random 2020-12-15 23:03 2020-12-15 23:03
Reporter: rosslagerwall Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Segfault when quitting (related to jack)
Description: Since upgrading to 6.5, I get sporadic segfaults when quitting Ardour. It has happened several times, but not consistently.

It seems to be related to jack clean up. The stack trace is below but unfortunately I didn't have full debugging information. I will try to capture better stack trace in case it is useful.

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fe585a1b8e7 in std::_Rb_tree<void*, std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> >, std::_Select1st<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > >, std::less<void*>, std::allocator<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > > >::_M_erase(std::_Rb_tree_node<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > >*) [clone .isra.0] ()
   from /usr/lib/ardour6/backends/libjack_audiobackend.so
[Current thread is 1 (Thread 0x7fe58d841d40 (LWP 5757))]
(gdb) bt
#0 0x00007fe585a1b8e7 in std::_Rb_tree<void*, std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> >, std::_Select1st<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > >, std::less<void*>, std::allocator<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > > >::_M_erase(std::_Rb_tree_node<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > >*) [clone .isra.0] () at /usr/lib/ardour6/backends/libjack_audiobackend.so
0000001 0x00007fe585a1b8b8 in std::_Rb_tree<void*, std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> >, std::_Select1st<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > >, std::less<void*>, std::allocator<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > > >::_M_erase(std::_Rb_tree_node<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > >*) [clone .isra.0] () at /usr/lib/ardour6/backends/libjack_audiobackend.so
#2 0x00007fe585a1b8b8 in std::_Rb_tree<void*, std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> >, std::_Select1st<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > >, std::less<void*>, std::allocator<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > > >::_M_erase(std::_Rb_tree_node<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > >*) [clone .isra.0] () at /usr/lib/ardour6/backends/libjack_audiobackend.so
#3 0x00007fe585a21452 in ARDOUR::JACKAudioBackend::~JACKAudioBackend() () at /usr/lib/ardour6/backends/libjack_audiobackend.so
0000004 0x00007fe585a21d59 in ARDOUR::JACKAudioBackend::~JACKAudioBackend() () at /usr/lib/ardour6/backends/libjack_audiobackend.so
0000005 0x00007fe585a174c2 in deinstantiate() () at /usr/lib/ardour6/backends/libjack_audiobackend.so
#6 0x00007fe59877ed0f in ARDOUR::AudioEngine::~AudioEngine() () at /usr/lib/ardour6/libardour.so.3
#7 0x00007fe59877fd21 in ARDOUR::AudioEngine::destroy() () at /usr/lib/ardour6/libardour.so.3
0000008 0x00007fe5988a1da4 in ARDOUR::cleanup() () at /usr/lib/ardour6/libardour.so.3
0000009 0x000056529ac3ad40 in main ()
(gdb) frame 0
#0 0x00007fe585a1b8e7 in std::_Rb_tree<void*, std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> >, std::_Select1st<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > >, std::less<void*>, std::allocator<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > > >::_M_erase(std::_Rb_tree_node<std::pair<void* const, boost::shared_ptr<ARDOUR::JackPort> > >*) [clone .isra.0] () from /usr/lib/ardour6/backends/libjack_audiobackend.so
(gdb) info locals
No symbol table info available.
(gdb) disas
Dump of assembler code for function _ZNSt8_Rb_treeIPvSt4pairIKS0_N5boost10shared_ptrIN6ARDOUR8JackPortEEEESt10_Select1stIS8_ESt4lessIS0_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E.isra.0:
   0x00007fe585a1b8a0 <+0>: test %rdi,%rdi
   0x00007fe585a1b8a3 <+3>: je 0x7fe585a1b910 <_ZNSt8_Rb_treeIPvSt4pairIKS0_N5boost10shared_ptrIN6ARDOUR8JackPortEEEESt10_Select1stIS8_ESt4lessIS0_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E.isra.0+112>
   0x00007fe585a1b8a5 <+5>: push %r12
   0x00007fe585a1b8a7 <+7>: push %rbp
   0x00007fe585a1b8a8 <+8>: push %rbx
   0x00007fe585a1b8a9 <+9>: mov %rdi,%rbx
   0x00007fe585a1b8ac <+12>: mov 0x18(%rbx),%rdi
   0x00007fe585a1b8b0 <+16>: mov %rbx,%r12
   0x00007fe585a1b8b3 <+19>: callq 0x7fe585a1b8a0 <_ZNSt8_Rb_treeIPvSt4pairIKS0_N5boost10shared_ptrIN6ARDOUR8JackPortEEEESt10_Select1stIS8_ESt4lessIS0_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E.isra.0>
   0x00007fe585a1b8b8 <+24>: mov 0x30(%r12),%rbp
   0x00007fe585a1b8bd <+29>: mov 0x10(%rbx),%rbx
   0x00007fe585a1b8c1 <+33>: test %rbp,%rbp
   0x00007fe585a1b8c4 <+36>: je 0x7fe585a1b8cc <_ZNSt8_Rb_treeIPvSt4pairIKS0_N5boost10shared_ptrIN6ARDOUR8JackPortEEEESt10_Select1stIS8_ESt4lessIS0_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E.isra.0+44>
   0x00007fe585a1b8c6 <+38>: lock decl 0x8(%rbp)
   0x00007fe585a1b8ca <+42>: je 0x7fe585a1b8e0 <_ZNSt8_Rb_treeIPvSt4pairIKS0_N5boost10shared_ptrIN6ARDOUR8JackPortEEEESt10_Select1stIS8_ESt4lessIS0_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E.isra.0+64>
   0x00007fe585a1b8cc <+44>: mov %r12,%rdi
   0x00007fe585a1b8cf <+47>: callq 0x7fe585a146d0 <_ZdlPv@plt>
   0x00007fe585a1b8d4 <+52>: test %rbx,%rbx
   0x00007fe585a1b8d7 <+55>: jne 0x7fe585a1b8ac <_ZNSt8_Rb_treeIPvSt4pairIKS0_N5boost10shared_ptrIN6ARDOUR8JackPortEEEESt10_Select1stIS8_ESt4lessIS0_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E.isra.0+12>
   0x00007fe585a1b8d9 <+57>: pop %rbx
   0x00007fe585a1b8da <+58>: pop %rbp
   0x00007fe585a1b8db <+59>: pop %r12
   0x00007fe585a1b8dd <+61>: retq
   0x00007fe585a1b8de <+62>: xchg %ax,%ax
   0x00007fe585a1b8e0 <+64>: mov 0x0(%rbp),%rax
   0x00007fe585a1b8e4 <+68>: mov %rbp,%rdi
=> 0x00007fe585a1b8e7 <+71>: callq *0x10(%rax)
   0x00007fe585a1b8ea <+74>: lock decl 0xc(%rbp)
   0x00007fe585a1b8ee <+78>: jne 0x7fe585a1b8cc <_ZNSt8_Rb_treeIPvSt4pairIKS0_N5boost10shared_ptrIN6ARDOUR8JackPortEEEESt10_Select1stIS8_ESt4lessIS0_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E.isra.0+44>
   0x00007fe585a1b8f0 <+80>: mov 0x0(%rbp),%rax
   0x00007fe585a1b8f4 <+84>: mov %rbp,%rdi
   0x00007fe585a1b8f7 <+87>: mov 0x18(%rax),%rdx
   0x00007fe585a1b8fb <+91>: cmp 0x2642e(%rip),%rdx # 0x7fe585a41d30
   0x00007fe585a1b902 <+98>: jne 0x7fe585a1b911 <_ZNSt8_Rb_treeIPvSt4pairIKS0_N5boost10shared_ptrIN6ARDOUR8JackPortEEEESt10_Select1stIS8_ESt4lessIS0_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E.isra.0+113>
   0x00007fe585a1b904 <+100>: callq *0x8(%rax)
   0x00007fe585a1b907 <+103>: jmp 0x7fe585a1b8cc <_ZNSt8_Rb_treeIPvSt4pairIKS0_N5boost10shared_ptrIN6ARDOUR8JackPortEEEESt10_Select1stIS8_ESt4lessIS0_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E.isra.0+44>
   0x00007fe585a1b909 <+105>: nopl 0x0(%rax)
   0x00007fe585a1b910 <+112>: retq
   0x00007fe585a1b911 <+113>: callq *%rdx
   0x00007fe585a1b913 <+115>: jmp 0x7fe585a1b8cc <_ZNSt8_Rb_treeIPvSt4pairIKS0_N5boost10shared_ptrIN6ARDOUR8JackPortEEEESt10_Select1stIS8_ESt4lessIS0_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E.isra.0+44>
End of assembler dump.
Tags:
Steps To Reproduce:
Additional Information: I'm using jack as the audio backend. I compiled Ardour from the 6.5 tag.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7831 [ardour] bugs minor always 2019-10-24 22:43 2020-12-15 09:54
Reporter: agfline Platform: Linux debian 4.19.0-6-amd64  
Assigned To: OS: Linux debian 4.19.0-6-amd64  
Priority: normal OS Version: Linux debian 4.1  
Status: new Product Version: 5.X git (version in description)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Video not playing until click event on rulers, when session starts with offset (01:00:00:00)
Description: Running : Ardour 6.0.pre0.2385 "The Pearl" (rev 6.0-pre0-2385-gec35afef38) Intel 64-bit - debug
Tags: video timeline
Steps To Reproduce: * Import a video file to a session, move it on the timeline at for example 01:00:00:00. Everything works as expected, video starts playing in xjadeo when the playhead reach 01:00:00:00.
* Save session and quit.
* When you open that session again, video region is well positioned on the timeline, beginning at 00:01:00:00, but when you hit play, xjadeo plays the video only if playhead is at 00:00:00:00. So if the video is less than an hour, nothing plays in xjadeo when playhead reach the beginning of video region on the TL.

The problem is solved when clicking somewhere on the rulers. I guess the click event triggers something that notify xjadeo about the offset or something..
Additional Information: This is a problem, especially when working in video post production, when sessions often start at 01:00:00:00.

Thank you for your time and work.
System Description
Attached Files:
Notes
(0025310)
jachhunter777   
2020-12-15 09:54   
0007831: https://goo.gl/2DqXGj
* Import a video file to a session, move it on the timeline at for example 01:00:00:00. Everything works as expected, video starts playing in xjadeo when the playhead reach 01:00:00:00.

Issue fixed?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8495 [ardour] bugs minor always 2020-12-13 12:44 2020-12-13 12:44
Reporter: unfa Platform: Ryzen 7  
Assigned To: OS: Manjaro Linux  
Priority: normal OS Version: KDE  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Input list break with a lot of items when selecting an item at the bottom
Description: With a lot of items in the MIDI Input table, ticking a checkbox on the bottom of the list hides that item.

I've attached a video of what happens - I think it explains the situation best.

To reproduce:

Tags: Midi, ui
Steps To Reproduce: 1. Create a Carla project with a lot of plug-ins, so that Ardour populates the MIDI Input list with their MIDI Inputs/Outputs.
2. Find your Physical MIDI controller on the very bottom of the list
3. Tick a checkbox
4. See the item disappear
5. Can't scroll down
6. The *only* way to get back the lost list item is to scroll up and then down
Additional Information:
System Description
Attached Files: Ardour scroll MIDI input bug.webm (525,671 bytes) 2020-12-13 12:44
https://tracker.ardour.org/file_download.php?file_id=3879&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8493 [ardour] bugs minor always 2020-12-12 06:34 2020-12-12 06:34
Reporter: wolftune Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: latency compensation numbers do not get activated initially (takes a couple tries)
Description: Testing if my latency I/O settings were right, I couldn't reliably get Ardour to use the new numbers, it takes a couple attempts before they are active.

I suspect this is relevant to ALSA and Jack and other situations, but to be simple I tested all with ALSA directly.

Strangely, this seems to have some inconsistency, such as perhaps a large number always registers.
Tags: latency
Steps To Reproduce: Get any sort of simple setup to check for latency compensation (e.g. a physical loop and record the metronome output back to the audio input).

Open the Audio/MIDI setup window. Enter numbers in the I/O latency fields.

Close the window. Do a trial recording.

Open the window again and change the numbers and close it. Redo the test. Notice that the compensation remains unchanged.

Do it all again and notice that the compensation is now finally different.

To be clear, I tried large numbers like 4000, and it had an obvious effect. Then, I went down to 140 or some other small number and the compensation was stuck at the high amount. I was able to get it to activate a low number by trying 145 or similar and then the change activated. I was able to consistently reproduce this pattern.
Additional Information: This is not something likely to arise other than initial setup. However, it's very frustrating to set the numbers and still have bad results. And if that's because the numbers haven't been activated, this could cause others (like me) to spend hours feeling crazy that nothing works and they can't get compensation set right.

I suspect there's some way that the numbers get actually engaged. If there were a button in the window or some other way to verify not just that numbers were entered in the fields but to check what the active compensation is set to, that would make this much more straightforward.
System Description
Attached Files:
Notes
(0025301)
wolftune   
2020-12-12 06:34   
perhaps related to https://tracker.ardour.org/view.php?id=8049 ?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8491 [ardour] bugs minor always 2020-12-10 00:38 2020-12-10 00:39
Reporter: polygon Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour CPU gradually increases while recording
Description: I am recording tracks using Ardour. Especially when I have the application take the whole screen (my monitor has a resolution of 3440x1440) the CPU usage gradually increases during recording. This makes the GUI become very stuttery and, more importantly, starts producing tons of xruns which completely kills the take.

I've attached a screenshot where this can be seen. The recording started shortly after the CPU graph begins. In the beginning, everything is normal, but after a while, you can see CPU spikes appearing which also happen in sync with heaps of xruns. Now, in this song, lots of tracks are already disabled, I've seen the CPU spikes often going up to 100%, especially when the session gets more plugins. After stopping the recording, CPU usage will quickly go down to normal. This seems to only happen when recording, I can play back these tracks even with all Plugins activated without any issues.

So far, I could mitigate the problem by reducing the Ardour window size to the smallest size it lets me (helps a lot!) and either disabling all unneeded tracks or render them to temporary tracks and then deactivating them so that the DSP load goes down (helps, but still need to reduce window size). However, even that does not completely mitigate the problem, the CPU spikes are still there, just usually not bad enough to start causing xruns.

I can also see these CPU spiked on a completely new and empty Ardour session where all I do is insert a new Audio track and start recording. However, here they usually remain much lower and don't cause xruns, but they are definitely visible.
Tags:
Steps To Reproduce: * Start Ardour on a large screen
* Start recording a track for longer than 2-3 minutes
* Usually the problem is amplified, if other tracks are already present in the application
Additional Information: I am running Ardour6.3 from the Debian Testing repo
System Description
Attached Files: ardour_issue_smaller.jpg (698,248 bytes) 2020-12-10 00:39
https://tracker.ardour.org/file_download.php?file_id=3877&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7730 [ardour] bugs minor always 2019-03-01 07:32 2020-12-09 11:18
Reporter: soundbooze Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 5.X git (version in description)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Recording segmentation fault on MIDI multiple fan out tracks
Description: Audio recording crashed with segmentation fault on x42 avl drumkit - fan out tracks.

Suspect bug found:
- disk_writer.cc [DiskWriter::run (BufferSet& bufs, samplepos_t start_sample, samplepos_t end_sample,
                 double speed, pframes_t nframes, bool result_required)]

If i disabled/commented-out all the MIDI recording sources from the above function, it works just fine.

gcc (Debian 6.3.0-18+deb9u1)

[git] Ardour 6.0.pre0.1541 and probably previous/newer version too.
Debian Stretch (9.6 - 9.8)
Tags:
Steps To Reproduce: 1 MIDI Track [x42 avl drumkit], 9 multiple fan-out tracks
1 Audio Track with jack port capture

Aiming for audio recording, I click transport record then Ardour suddenly crashed
Additional Information: Attached is the video snapshot that describes the situation.
System Description
Attached Files: anehcd.mp4 (759,641 bytes) 2019-03-01 07:32
https://tracker.ardour.org/file_download.php?file_id=3442&type=bug
Notes
(0020599)
soundbooze   
2019-03-01 12:42   
Here's the code snippet [disk_writer.cc] that produces the segmentation fault

if (ev.time() + rec_offset > rec_nframes) {
  break;
}
(0020600)
soundbooze   
2019-03-01 15:48   
Here's the correction from the above note:

_midi_buf - aka _midi_buf->write (event_time, ev.event_type(), ev.size(), ev.buffer());

was empty, while audio recording's running
(0025297)
marthasimons   
2020-12-09 11:18   
Suspect bug found:
- disk_writer.cc [DiskWriter::run (BufferSet& bufs, samplepos_t start_sample, samplepos_t end_sample,
                 double speed, pframes_t nframes, bool result_required) https://goo.gl/2DqXGj ]

_midi_buf - aka _midi_buf->write (event_time, ev.event_type(), ev.size(), ev.buffer());

was empty, while audio recording's running

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8487 [ardour] features minor always 2020-12-07 10:59 2020-12-07 14:42
Reporter: gnzg Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Improving the Editor List - 2
Description: (Profile: Ubuntu Studio with Ardour 6.5, using i3wm)

This one is a more specific feature request so I made a separate issue for it if that's okay :)

It would be great to have a way to group regions based on which tracks they're on in the "Regions" panel, in the Editor List:

Ideally it wouldn't be the same as sorting regions by name or length, but would rather be an option that can be toggled on or off which would "group" regions depending on which track they're on
(this option could be accessed by right clicking on the top row of the Editor List, similar to what I described in my previous issue (0008485)

The reason for this distinction would be that the user would have the option to sort regions by any characteristic they want (name, start and so on) while keeping the track structure

Here's a more specific user case:

I have a whole bunch of percussion samples on several tracks
Each track corresponds to a different instrument (Kick, Snare, Hi-Hat etc)

I want to be able to quickly select and edit objects on each individual tracks using the arrow keys
for instance maybe I want to cycle through all of the Hi-hats hits to "Reverse" them

I would simply need to toggle the "group by track" option in the list menu and sort them by their "start" time

Then I could use up and down arrows to cycle through each individual hit and just use the "Reverse" keyboard shortcut (Ctrl-4 by default I believe ? I use Alt-R personally but whatever)

This is secondary but it would also be pretty cool if grouped regions were highlighted with their respective track's color

I don't know how simple/complex to implement this would be and I understand that you may have other priorities but I thought I'd give it a try :)
Tags: editor list
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8485 [ardour] features minor always 2020-12-07 10:38 2020-12-07 10:38
Reporter: gnzg Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Improving the Editor List - 1
Description: (Profile: Ubuntu Studio with Ardour 6.5, using i3wm)
(I had the same issue using the default Ardour build Ubuntu Studio's repo and Plasma, so I'm assuming this isn't specific to my configuration, but I could be wrong of course)

Hi !
The "Editor List" pannel has a couple of issues:

-Columns are not resizable, except for the "name" column in "Sources" for some reason
-There should be a way to change the orders of columns and choose which ones to show or hide

A way to do this would be to have the option to right click on the top row and have a list of characteristics (name, ch, start and so on) which can be toggled on or off and an option to "lock columns in place"

when this last option is untoggled, you'd be able to simply drag and drop individual columns, sort and resize them however you like
Tags: Accessibility, column width, editor list
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8470 [ardour] bugs minor always 2020-11-16 20:54 2020-12-06 19:30
Reporter: bachstudies Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Source list contains duplicates when audio is dragged into the editor versus using the import dialog
Description: See discussion here: https://discourse.ardour.org/t/expected-source-list-behavior/104961

Summary pretty much says it all.
Tags:
Steps To Reproduce: Drag audio into Ardour and duplicate sources appear in the source list. Using import dialog doesn't exhibit this behavior.
Additional Information:
System Description
Attached Files:
Notes
(0025244)
AliMacD   
2020-11-21 12:32   
this happens when dragging a sound onto an existing track,
it does not happen when dragging into an empty space (which creates a new track)
having just bought Mixbus I see the problem is exactly the same there (I guess this is not a surprise)
(0025245)
AliMacD   
2020-11-21 12:52   
...then I tried again on Mixbus just to check I hadn't been dreaming and it didn't show double copies,
but then I clicked to view Regions, back to Source lists and hey presto - doubles are there after all
(couldn't get this to happen in Ardour, or to happen again in Mixbus)
(0025254)
AliMacD   
2020-11-22 16:18   
seems to be fixed in Ardour 6.4 for me (OS X 10.15.7)
(0025255)
x42   
2020-11-22 16:41   
The bad news is: I have no explanation why it was an issue, nor why it's now gone.
Looking at the changelog, I don't see an explicit fix for this between 6.3 and 6.4.

Maybe it only happens sometimes, or only for some files...
(0025256)
bachstudies   
2020-11-22 17:21   
Still happens on 6.4 here (Win). When I switch over to Linux I'll test there too. However, I can confirm AliMacD's finding that it doesn't add duplicates when you drag a file into empty space.
(0025257)
AliMacD   
2020-11-22 17:41   
it's back...
I did a few more tests all starting with new, empty sessions (using the same folder of sounds I used for testing above in 6.3 and 6.4) and all was fine. No duplicates.
Then I opened an existing session and the problem returned immediately.
And now even with clean sessions I get doubles.
(0025266)
AliMacD   
2020-11-25 09:41   
related - I'd like to be able to drop files into the Source List instead of directly onto the timeline (though I'd be happy for both to co-exist). Drag & drop is really useful when bringing together audio from a number of different disks & folders into a new project.
...I wonder if fixing this might uncover the solution for the problem above.
(0025289)
thekoala2   
2020-12-06 19:30   
Also occurs when dragging directly from the source list (6.5/Linux).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8484 [ardour] features minor always 2020-12-05 10:19 2020-12-05 10:19
Reporter: dgdgddgd Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Note Cuter Tool
Description: hello guys
 add a tool for cut NOTE not midi region
 or option to cut tool for cut note in midi region

 

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8475 [ardour] bugs minor always 2020-11-25 10:47 2020-12-01 19:14
Reporter: consint Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Editing automations with Range-Tool
Description: Since Ardour 6.x the editing auf automation lanes with the Range-Tool does not work anymore. I cannot describe it well therefore here the reference to a Mixbus Turorial Video from minute 4:40: https://youtu.be/ZA8Hm_66WSQ?t=280

Selecting automations with the Range tool works, but moving them afterwards with the Draw tool does not.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: automation_range_bug_01.png (95,712 bytes) 2020-11-30 16:51
https://tracker.ardour.org/file_download.php?file_id=3869&type=bug
png

automation_range_bug_02.png (95,273 bytes) 2020-11-30 16:51
https://tracker.ardour.org/file_download.php?file_id=3870&type=bug
png

automation_range_bug_03.png (113,346 bytes) 2020-11-30 16:51
https://tracker.ardour.org/file_download.php?file_id=3871&type=bug
png
Notes
(0025272)
jumase   
2020-11-28 21:52   
Hi, on Ardour 6.5 I have experienced the same issue only in one particular session. However I'm not able to tell why this is happening yet. I tested other old projects and the tool works fine, even in new projects/sessions. I also checked Session Properties (Alt+O) for something that could affect this particular session, changed Edit Modes and Points, but couldn’t find anything significant. It affects all tracks on that session.
Just in case, the tool only works using the Draw Mode, not the Internal Edit Mode.
One thing to have in mind is that Ardour version which files were created doesn't seem to be related to this issue.
Does this happens to you on all sessions?
(0025273)
consint   
2020-11-30 16:51   
This is a very strange behavior. I have tried it in my 5 current projects. In one of them the editing of automation lines with the Range and Draw tool worked. In the other 4 it did not work. I can mark an area of automation with the Range tool, but then when I switch to the Draw tool, the mark is removed and I can only draw new points.

I opened a new empty project, created several tracks and loaded several plugins and tried to reproduce the behaviour. Unfortunately I did not succeed. But I noticed another bug that might be related to this one:

When I first mark a range with the Range Tool and then move it with the Draw Tool everything works as it should. If I then mark a range within this range again with the Range tool and then move it with the Draw tool, the two outer new points will jump either all the way down or (more rarely) slightly up. I hope you can follow this with the screenshots. I haven't updated yet and tested it with Ardour 6.3 on Ubuntu 20.4.
(0025274)
jumase   
2020-12-01 19:14   
> I can mark an area of automation with the Range tool, but then when I switch to the Draw tool, the mark is removed and I can only draw new points.

That's precisely what I've also experienced. However, I tried again with the same "buggy" session and it works as expected (i.e. select a range and then with Draw Mode change the automation or gain curves). So I have no clues about what was going on before.

> When I first mark a range with the Range Tool and then move it with the Draw Tool everything works as it should. If I then mark a range within this range again with the Range tool and then move it with the Draw tool, the two outer new points will jump either all the way down or (more rarely) slightly up.

I can reproduce this other issue on version 6.5 from ardour.org

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8480 [ardour] other minor unable to reproduce 2020-11-29 07:53 2020-11-29 07:53
Reporter: imstre Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: PSP InfiniStrip not work
Description: does not work on PSP InfiniStrip
after scanning in blacklist
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8479 [ardour] features minor always 2020-11-27 17:22 2020-11-27 17:22
Reporter: dgdgddgd Platform: all  
Assigned To: OS: all  
Priority: normal OS Version: all  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Rating favorite plugin window
Description: Hello guys
add a option for rating plugin in favorite plugin window

i have many favorite plugin +100 this idea is a best for manage it

for screenshot follow bellow link

https://discourse.ardour.org/t/rating-favorite-plugin/105053
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8477 [ardour] bugs minor always 2020-11-26 19:21 2020-11-26 19:21
Reporter: Xard Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Tracer reports hardware midi note events twice
Description: Window > MIDI Tracer tool shows all midi notes coming from hardware midi keyboard twice.

However when recording ACE MIDI Monitor displays notes only once and MIDI track recordings do not have overlapping notes even with all MIDI overlapping options disabled.
Tags:
Steps To Reproduce: 1. create or select MIDI track (can be empty)
2. route MIDI keyboard input to the track
3. open Window > MIDI Tracer tool
4. set tracer to log the midi_in from the track selected in step 1
5. input notes to tracer
Additional Information: Tracer output looks like:
     3722723 NoteOn chn 1 42 44
     3722723 NoteOn chn 1 42 44
     3727360 NoteOff chn 1 42 00
     3727360 NoteOff chn 1 42 00
     3729408 NoteOn chn 1 42 47
     3729408 NoteOn chn 1 42 47
     3733504 NoteOff chn 1 42 00
     3733504 NoteOff chn 1 42 00
     3741696 NoteOn chn 1 3f 4d
     3741696 NoteOn chn 1 3f 4d
     3745792 NoteOff chn 1 3f 00
     3745792 NoteOff chn 1 3f 00

Ardour Virtual keyboard does not have this issue.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7969 [ardour] bugs minor always 2020-04-02 01:04 2020-11-26 12:56
Reporter: Cristian Ramos Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 6.0-pre1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash at start in KDE Neon whit Global menu
Description: I am using KDE Neon and when I enable “global menu” ardor5 or ardour6 does not start
Tags:
Steps To Reproduce: Type in terminal
$ ardour6
Additional Information: /usr/local/bin/ardour6 --gdb
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
Para las instrucciones de informe de errores, vea:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Leyendo símbolos desde /usr/local/lib/ardour6/ardour-6.0.pre1.90...hecho.
(gdb) r
Starting program: /usr/local/lib/ardour6/ardour-6.0.pre1.90
[Depuración de hilo usando libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
(gdb) bind txt domain [gtk2_ardour6] to /usr/local/share/ardour6/locale
Ardour6.0.pre1.90 (built using 6.0-pre1-90-g42af08fb92 and GCC version 7.5.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 65536 open files
Ardour: [INFO]: Loading system configuration file /usr/local/etc/ardour6/system_config
Ardour: [INFO]: Loading user configuration file /home/cristian/.config/ardour6/config
[Nuevo Thread 0x7fffdf0fc700 (LWP 6800)]
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: CPU brand: AMD A10-7860K Radeon R7, 12 Compute Cores 4C+8G
Ardour: [INFO]: Using SSE optimized routines
[Nuevo Thread 0x7fffde8fb700 (LWP 6801)]
[Nuevo Thread 0x7fffde0fa700 (LWP 6802)]
[Nuevo Thread 0x7fffdd8f9700 (LWP 6803)]
Ardour: [INFO]: Loading plugin meta data file /usr/local/share/ardour6/plugin_metadata/plugin_tags
[Nuevo Thread 0x7fffccefd700 (LWP 6805)]
[Thread 0x7fffccefd700 (LWP 6805) terminado]
[Nuevo Thread 0x7fffccefd700 (LWP 6806)]
[Nuevo Thread 0x7fffc71a7700 (LWP 6807)]
[Nuevo Thread 0x7fffbffff700 (LWP 6808)]
Ardour: [INFO]: Loading default ui configuration file /usr/local/etc/ardour6/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/cristian/.config/ardour6/ui_config
Ardour: [INFO]: Loading 449 MIDI patches from /usr/local/share/ardour6/patchfiles
[Nuevo Thread 0x7fffbf5f1700 (LWP 6809)]
[Nuevo Thread 0x7fffbedf0700 (LWP 6810)]
[Nuevo Thread 0x7fffbe5ef700 (LWP 6811)]
[Nuevo Thread 0x7fffbddee700 (LWP 6812)]
Color shuttle bg not found
Color play head not found
Ardour: [INFO]: Loading color file /usr/local/share/ardour6/themes/dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file /usr/local/etc/ardour6/clearlooks.rc
Ardour: [INFO]: Loading bindings from /usr/local/etc/ardour6/ardour.keys
Loading ui configuration file /usr/local/etc/ardour6/clearlooks.rc
[Nuevo Thread 0x7fffc40d2800 (LWP 6813)]
[Nuevo Thread 0x7fffbcfaa700 (LWP 6814)]
[Thread 0x7fffbcfaa700 (LWP 6814) terminado]
[Nuevo Thread 0x7fffbc18d700 (LWP 6815)]
[Nuevo Thread 0x7fffbc10c700 (LWP 6816)]
[Thread 0x7fffbc10c700 (LWP 6816) terminado]
[Thread 0x7fffbc18d700 (LWP 6815) terminado]
[Nuevo Thread 0x7fffbc18d700 (LWP 6817)]
[Nuevo Thread 0x7fffbc10c700 (LWP 6818)]
[Thread 0x7fffbc10c700 (LWP 6818) terminado]
[Thread 0x7fffbc18d700 (LWP 6817) terminado]
[Nuevo Thread 0x7fffbcfaa700 (LWP 6819)]
[Nuevo Thread 0x7fff9b0f5700 (LWP 6820)]
Found nothing along /home/cristian/.config/ardour6/templates:/usr/local/share/ardour6/templates

Thread 1 "gui" received signal SIGSEGV, Segmentation fault.
0x00007ffff2e92fa4 in gtk_widget_get_toplevel () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
(gdb) bt
#0 0x00007ffff2e92fa4 in gtk_widget_get_toplevel () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000001 0x00007ffff2e9339c in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#2 0x00007ffff2e93472 in gtk_widget_get_screen () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#3 0x00007fffc4359248 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000004 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000005 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
#6 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
#7 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000008 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000009 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000010 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000011 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000012 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000013 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000014 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
#15 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000016 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
#17 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000018 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000019 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000020 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000021 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000022 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000023 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
#24 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000025 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000026 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000027 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000028 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000029 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000030 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000031 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000032 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000033 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000034 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000035 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000036 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000037 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000038 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000039 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000040 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000041 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000042 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000043 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000044 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000045 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000046 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000047 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000048 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000049 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000050 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000051 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000052 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000053 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000054 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000055 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000056 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000057 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000058 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000059 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000060 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000061 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000062 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000063 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000064 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000065 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000066 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
0000067 0x00007fffc4359277 in () at /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so
System Description
Attached Files:
Notes
(0021155)
paul   
2020-04-03 14:50   
This is probably a "Not Fixable" issue. Whatever KDE is doing with it's global menu probably involves a mechanism not known to the GUI toollkit (GTK+2) that we use.

I'm intrigued that KDE is continuing to offer this. Ubuntu tried to go down the "global menu" route a few years ago (via GNOME) and as far as I know they abandoned it after significant user feedback.
(0021159)
Cristian Ramos   
2020-04-03 16:09   
Ok, you can close the report if you want.
I was able to add ardor to the blacklist and now it works normally
I have noticed that "Plasma globalmenu" shows the result of the "appmenu" (gtk3 / gtk2 / qt) therefore I understand that the same should be for Budgie / Mate / XFCE
So far, the only apps that are not integrated are Ardor and Hydrogen. (sure there are others)
But only Ardor crashes
Thanks
(0025270)
djeremaille   
2020-11-26 12:56   
@Cristian Ramos
Can you explain me how have you been able to make it work?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8476 [ardour] features minor always 2020-11-26 10:05 2020-11-26 10:05
Reporter: dgdgddgd Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mark & unmake simitone in piano roll idea
Description: Hello
i post this feature idea in forum follow bellow link for more info
https://discourse.ardour.org/t/mark-unmake-simitone-in-piano-roll/105042

this feature help ardour user to easy find scale and chord position and etc...
and better than bellow case

https://github.com/Ardour/ardour/pull/477

because you dont need define functions for scale and other option e.g change color ...

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8215 [ardour] bugs minor sometimes 2020-06-07 13:10 2020-11-25 18:45
Reporter: mantis_n1oif Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI notes sometimes not updating. Have to restart to get Ardour to register additions/movements.
Description: MIDI notes sometimes not updating. Have to restart to get Ardour to register additions/movements.
Tags:
Steps To Reproduce: Import some midi tracks into a session.
Play
Stop
Move some notes around
Play again, movements won't have registered.
Additional Information: Examples here. Note that moving some "crash" notes to "ride" doesn't immediately update.
Then, notice that adding 4 count-off "stick" notes at the beginning doesn't register, but then the ride notes register.
Something is amiss with midi note updating.

https://youtu.be/Gut6A2mynnI
System Description
Attached Files:
Notes
(0024514)
mati_navas   
2020-06-27 11:30   
I experience the same issue. After importing a midi file, changes within the midi region are not reflected in the playback.

Current workaroud: one can drag the imported midi from the region list onto a new track. But that gets cumbersome after a while.
(0024559)
mantis_n1oif   
2020-07-02 13:19   
Still having issues of this nature. Here's an example where I'm moving all notes in a midi track from channel 1 to channel 3 and they should sound like fingered bass. But they continue to sound like piano (channel 1).

https://youtu.be/J-Txxu6MpIc
(0024764)
paul   
2020-07-18 15:58   
I am unable to reproduce these behaviors.

Can you verify that this only happens with imported MIDI ? If you create the MIDI from scratch do the same issues still occur?
(0024765)
mati_navas   
2020-07-18 16:54   
Yes, it only happens with imported MIDI. Recording/drawing in MIDI from scratch does not come with this issue.
(0024780)
mantis_n1oif   
2020-07-21 22:26   
Not sure if this is related, but there seem to be other "not updating" problems on midi tracks. I dragged an instance of fluidsynth from a drum track over to a bass track. I went into the new instance and changed the sf2 file to the "strings" sf2 file instead of my "drums" sf2 file (the setting had come over from the drag+drop).

But when I pressed play, my bass line was making drum sounds. I opened up the instance of fluidsynth for the bass track and verified that the notes on channel 3 should have sounded like "fingered" bass. Closed the window and tried again. Still drum sounds.

Closed ardour. Opened session again. Now it sounds like bass.

So yeah, just some weird "not registering the recent things changes I've made" type errors.
(0024902)
tavasti   
2020-08-07 06:19   
1) would say this reproducibility is always. With drag'n'drop midi, they seem too be 'immutable' for all cases

2) for me in mixbus 6.1 there seems to be at least 2 working ways to circumvent bug:
  a) with grab mode, select region, and in context menu midi -> unlink from other copies
  b) select with region tool, and consolidate
(0024965)
mantis_n1oif   
2020-08-26 19:18   
I've noticed that you can adjust a midi region to fix the problem without restarting Ardour. e.g. Drag a region edge a little. This will force an "update" or whatever is going on.
(0025040)
mantis_n1oif   
2020-09-17 16:24   
I just upgraded to 6.3.40 and this is still an issue
(0025268)
martin.vlk   
2020-11-25 17:15   
I also experience a lot of weird behaviour around MIDI tracks editing.
One that hasn't been mtentioned yet is that a note at the very beginning of a section doesn't show or play. It appears and starts playing as soon as I move the section start so that it doesn't coincide with the note startin position.
(0025269)
paul   
2020-11-25 18:45   
> One that hasn't been mtentioned yet is that a note at the very beginning of a section doesn't show or play.

This has bene mentioned in literally dozens of bug reports, along with explanations for why it happens, and suggested workarounds.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7874 [ardour] bugs minor always 2020-01-11 18:21 2020-11-24 14:48
Reporter: Oliver Platform: x86_64  
Assigned To: OS: Xubuntu  
Priority: normal OS Version: 18.04 LTS  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Temporary solo does not revert correctly if another track soloed
Description: I use a session without a monitor section and have set solo to 'exclusive'.

I solo one track permanently, then use the middle mouse button to temporarily solo another track. That works as expected, but when I let go of the middle button, all tracks are un-soloed.

i would expect that the previously soloed track is soloed again, so the state after the temporary action is the same as before.
Tags:
Steps To Reproduce: see description
Additional Information:
System Description Low latency kernel
Attached Files:
Notes
(0021083)
Oliver   
2020-03-28 21:11   
Still the same behaviour with Ardour 6.0.pre1.21.
(0023822)
Oliver   
2020-04-20 05:23   
Still not fixed in Ardour 6.0.rc1.2.
(0024672)
Oliver   
2020-07-09 23:29   
Still not fixed in Ardour 6.2.

Could the developers please kindly comment if that is expected behaviour (then I can stop reporting it) or if it will be fixed eventually?
(0024682)
paul   
2020-07-11 03:18   
it's a bug. the dimensionality of solo-ing makes it hard to test every possible case. you've just found one we haven't tested before.
(0024889)
Oliver   
2020-08-04 19:18   
The (really useful) new audition feature (Transport->Solo selection, or keyboard short cut 'A') suffers from the same issue. If prior to engaging the audition feature some track is soloed, it won't be soloed anymore after the auditioning ended, presumably due to the same bug.
(0025264)
Oliver   
2020-11-24 14:48   
Not fixed in Ardour 6.5.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8474 [ardour] bugs minor always 2020-11-23 18:57 2020-11-24 09:29
Reporter: ahms Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: uninstaller fails to remove all .desktop items
Description: Ardour's uninstaller (.run bundle) fails to remove all .desktop items
Tags:
Steps To Reproduce: 1. Install Ardour(.run bundle) through sudo or directly as root user.
2. Run the uninstaller directly as the root user(no sudo) with /opt/Ardour-6.5-uninstall.sh

The uninstaller should be able to remove all .desktop files whether the user is using sudo or not.

discovered this bug by luck when uninstalling an earlier release prior to trying out this latest one with 6.5..

the user can try to search paths in "XDG_DATA_DIRS=" and see if any ardour .desktop files have not fully been removed by /opt/Ardour-*uninstaller.sh

paths that have been spotted with lingering ardour .desktop files:
/var/lib/flatpak/exports/share/applications/
/usr/local/share/applications/

Observation:
- When using sudo with the uninstaller, all .desktop files are removed.

occurs on a Debian-10 64-bit linux system.

Additional Information:
System Description
Attached Files:
Notes
(0025258)
ahms   
2020-11-23 19:35   
the latest installer when running without sudo, installs a .desktop in /home/user/Desktop instead of a system path. This seems incorrectly handled, now that I have bothered to verify the installer without the usage of sudo.
"Adding Ardour to the applications menu
Creating a desktop link for Ardour in /home/user/Desktop
"
The user shouldn't have to rely on using sudo to behave diferently than going without it.

When the root user is used, the installer should install everything in system paths and not at all in user paths.

There's a bug with the installer portion regarding .desktop items, and not only with the uninstaller as one would be able to tell.
(0025260)
Oliver   
2020-11-24 09:24   
With Ardour 6.5 I also see that I get a .desktop file on the actual Desktop in Xubuntu 20.04 LTS, but the program in the start menu has only a generic icon. Something is indeed incorrect with the .desktop handling. It also occurred already with 6.3, maybe with any of the version 6 programs.
(0025261)
Oliver   
2020-11-24 09:29   
Correcting my last comment, the issue was indeed that the previous Ardour 6.3 .desktop file was not removed, as the OP mentioned, so I saw a stale link to 6.3 after it was deinstalled.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8473 [ardour] bugs minor have not tried 2020-11-22 15:37 2020-11-22 15:37
Reporter: unfa Platform: Ryzen  
Assigned To: OS: Manjaro  
Priority: normal OS Version: KDE  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Fatal error when using Range Tool Duplicate with amount of 4.25
Description: I've used the range tool to select a few bars on a MIDI track, then pressed Shift+D to open the Duplicate dialog, typed in 4.25 and hot this message box:

Ardour -: Fatal Error

programming error: request for non-existent audio range (11)!

[ Press to Exit ]

Which then terminates Ardour.

This happened when i was recording a video, and I'm attaching two frames from that.

I did not try to reproudce this.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8471 [ardour] bugs minor always 2020-11-19 11:37 2020-11-19 11:45
Reporter: unfa Platform: AMD Ryzen  
Assigned To: OS: Manjaro  
Priority: normal OS Version: KDE  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on loading session (Thread 29 "audioengine" received signal SIGABRT)
Description: I've created a session on one machine running Manjaro (desktop PC). Then I've copied it to another machine also running Manjaro (laptop).

One the desktop it works fine - on the laptop it crashes Ardour every time I try to load it.

I've tried the newest nightly build 6.3.333 in debug and produced a complete backtrace.

I've tested this loading he project in "safe mode" - no difference.

I'm attaching two backtraces from two versions of Ardour.
Tags: crash
Steps To Reproduce:
Additional Information: If you need a test project, please contact me in person.
System Description
Attached Files: Ardour gdb dbg.log (28,616 bytes) 2020-11-19 11:37
https://tracker.ardour.org/file_download.php?file_id=3865&type=bug
Ardour gdb.log (18,250 bytes) 2020-11-19 11:37
https://tracker.ardour.org/file_download.php?file_id=3866&type=bug
Notes
(0025242)
unfa   
2020-11-19 11:41   
Correction: this happens on loading or creating *any* session. The problem didn't occur before I've updated the system (pacman -Syu), I'll reboot and see if that changes anything.
(0025243)
unfa   
2020-11-19 11:45   
Allright, rebooting the system fixed the problem.
I wonder if something could be done to communicate such situations to the user and instruct them what to do.
I suspect maybe some libraries on disk were in different versions than in memory?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8469 [ardour] bugs minor always 2020-11-14 19:59 2020-11-14 22:55
Reporter: audiodef Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Follow Range does not work
Description: Follow Range does not work when activated, even when rm'ing ~/.config/ardour6 and letting Ardour create a new config.
Tags:
Steps To Reproduce: Install or start Ardour, make sure Follow Range is on.
Additional Information: It has been several versions since Follow Range has worked for me.
System Description
Attached Files:
Notes
(0025222)
audiodef   
2020-11-14 20:46   
On further examination, this appears to happen under specific circumstances. If I open any of my older sessions, Follow Range works. If I create a new session and import files, Follow Range does not work.
(0025223)
audiodef   
2020-11-14 20:47   
Also, if I create a new session and record a track, Follow Range does not work. It appears to work only if I open one of my older sessions.
(0025224)
audiodef   
2020-11-14 20:52   
And this seems to be the case on one of my computers but not on another.
(0025225)
audiodef   
2020-11-14 22:45   
More stuff:

FR didn't work when I tried to open a recently-created existing file. A ~/.config/jack dir was created by something unknown to me. rm'ing that dir and the ardour6 config dir eliminated the issue. Opening that session again re-created the issue. Performing above fix and importing the audio from the problematic session seems to not bring the FR not working issue with it.

So, very specific circumstances and I'm sadly not IT-savvy enough to do more than report what I observed.
(0025226)
audiodef   
2020-11-14 22:55   
Interesting. I don't know if this is how it's supposed to work, but now when the FR button is lit, the playhead scrolls off the screen and disappears. When the FR button is unlit, the view tracks the playhead.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8218 [ardour] bugs minor sometimes 2020-06-08 00:32 2020-11-11 10:56
Reporter: mantis_n1oif Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI notes paste unpredictably and sometimes not at all
Description: Copying and pasting MIDI notes breaks in a lot of different ways.
Sometimes pasting happens in the wrong track
Sometimes pasting happens at the wrong spot in the right track
Sometimes pasting happens at the wrong spot in the wrong track
Sometimes pasting fails entirely


Tags:
Steps To Reproduce: This happens very very frequently, so any midi session should do. Just edit around. Work in a session and you'll start to see oddities.
Additional Information: Video of an errant paste here. Note where my cursor is when i paste and then where the notes appear.

https://youtu.be/O9BqlDq9BNI
System Description
Attached Files:
Notes
(0025041)
mantis_n1oif   
2020-09-17 16:27   
I just upgraded to 6.3.40 and this is still an issue
(0025213)
Bransby   
2020-11-11 10:56   
Confirming this in Ardour 6.3.0, Ubuntu 20.04.1

Copying and pasting MIDI notes within a track frequently results in them being pasted into different, unselected MIDI track.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8468 [ardour] bugs minor always 2020-11-09 17:26 2020-11-09 17:26
Reporter: magnetophon Platform: Linux  
Assigned To: OS: NixOS  
Priority: normal OS Version: unstable  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Changing the HW latency messes up the alignment of the click track
Description: I recorded a click track to an audio track.
It lines up with the generated click, both visually and audibly.

When I change the latency in qjackctl, the two clicks are no longer alligned.
This happens both when changing the latency with a running jack and when stopping jack to change the latency.
Tags:
Steps To Reproduce: - record a bit of click to an audio track
- check if it aligns with the generated click
- change the HW latency (preferably by a lot, so it's easy to hear)
- the two clicks no longer align.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8466 [ardour] bugs minor always 2020-11-08 01:06 2020-11-08 01:06
Reporter: miroshko Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Paste multiple notes in piano roll -> only the last one remains selected
Description: After copying and pasting a group of notes in the piano roll, only the last one of the pasted ones gets selected which makes no practical sense and makes the following use cases impossible:
- copy paste a group of notes and then align them without having to select them again
- create recurring patterns by repeatedly drag'n'dropping a group of notes with pressed Ctrl
Tags: pianoroll
Steps To Reproduce: - Open piano roll
- Add at least 2 notes
- Select multiple notes
- Copy-paste either with Ctrl-C + Ctrl-V or by drag'n'dropping with Ctrl pressed

Actual Result:
Only the last of the pasted ones is selected

Expected Result:
All pasted notes are selected so they can be aligned together or copy-pasted further
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7994 [ardour] bugs minor always 2020-04-08 11:57 2020-10-30 10:20
Reporter: mpk Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.0-pre1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Split affects topmost region instead of active region
Description: The 's' keyboard shortcut when used with Mouse as edit point now splits the topmost region rather than the selected region. This is a behaviour change from Ardour-5. The selected region is split when Playhead is used as the edit point.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 0001-Only-prioritize-entered_regionview-if-it-doesn-t-ove.patch (1,750 bytes) 2020-04-17 15:36
https://tracker.ardour.org/file_download.php?file_id=3580&type=bug
split-situation.png (89,992 bytes) 2020-04-18 09:17
https://tracker.ardour.org/file_download.php?file_id=3582&type=bug
png

0001-Add-configuration-option-for-new-split-action-behavi.patch (3,202 bytes) 2020-06-02 10:30
https://tracker.ardour.org/file_download.php?file_id=3715&type=bug
Notes
(0021374)
mpk   
2020-04-17 15:36   
I see this is an intentional change:

commit 22deebb42fa32e618ddfb9fbdaa93449a57b1717
Author: Ben Loftis <ben@harrisonconsoles.com>
Date: Tue Feb 12 10:29:03 2019 -0600

    Selection-after-split behavior (gtk2 part)

    * When splitting in MouseObject, entered_region should get priority over selected regions.
        This fixes the unexpected case where you try to split an unselected a region, but
           a) nothing happens OR
           b) some other region (maybe off-screen) is split


But I question the logic and consistency here. The behaviour makes it awkward to split regions in a lower layer which is often used when editing with the "later is higher" editing model. It also seems strange and confusing that this behaviour is specific to the Mouse Edit Point.

Attached is a patch to only prioritize the entered_regionview if it does not overlap a selected region at the edit position.
(0021377)
BenLoftis   
2020-04-17 21:06   
Yes, this change was made intentionally for the Mixbus commercial product. It has been released for about 15 months.

The intent was to address complaints like "I am finding splits in my regions that I didn't make". This was found to be the result of users expecting the Object tool to work on the "highlighted" (entered_region) region, but instead it was operating elsewhere. Either in lower layers that were current invisible, or in regions on a different track.

Since this change, I don't recall any reports of that problem.

If you want to split multiple regions as you've described, there are 3 good tools for that: The Cut tool, the Range tool, and EditPoint=Playhead (all of which can use a track selection). Those operations work on the whole layer stack.
(0021381)
mpk   
2020-04-18 09:17   
Thanks Ben, I appreciate the response and recognise that this is unlikely to change :) However if I may at least request a configurable option for this behaviour?

Consider the attached screenshot as an example. In this situation virtually every action in the Region menu (via keyboard shortcuts) operates on the selected (red) regions [Audio-1.1, Audio-1.23]: trim start and end, boost/cut gain, set fade in/out, mute, raise/lower etc. Except Split, which now operates on Audio-1.24 - a region visually distinguished only by the fade handles, not really "highlighted" (perhaps this is different in Mixbus?).

I guess I don't quite understand why a user would have selected regions and NOT want the action to operate on them.

Regarding your suggested alternative tools:

- The Cut tool is not able to take a region selection so will not help in this situation
- The Range tool will split all the layered regions, not just the selected regions
- Yes, using EditPoint=Playhead does work as expected, but requires changing to a different editing model and loses the efficiencies of EditPoint=Mouse.
(0021383)
x42   
2020-04-18 23:22   
I think "entered_regionview should only be prioritized if it does not overlap a selected region at the edit position" as proposed by the patch is the best of both worlds.

@BenLoftis this should still prevent your "I am finding splits in my regions that I didn't make" issue. If a selection is elsewhere, entered_regionview is used. Am I missing something?
(0021386)
mpk   
2020-04-19 10:53   
TBH this still seems pretty messy to me - it's not logical why the Split action in particular should be special-cased to behave differently.

Perhaps what @BenLoftis‘s user really wants is an additional mouse mode (or sub-mode, like the Smart switch) where the region under the pointer (entered_regionview) is ALWAYS prioritised over the selection for all region actions.

The current situation seems to be analogous to a word processor where Ctrl-i italicises the current selection, but Ctrl-B emboldens the word under the mouse pointer.
(0024338)
mpk   
2020-06-01 07:22   
Any thoughts on a resolution for this? Is it worth me working up a patch to make this behaviour optional?
(0024346)
mpk   
2020-06-02 10:30   
OK, here's a patch to make this behaviour configurable.
(0024381)
paul   
2020-06-04 16:02   
The analogy with a word processor isn't really fair.

Both of those examples (italicize and embolden) only require knowledge of the target of the operation: which word?

Split requires 2 things: the target of the operation (which region(s)?) and the location of the operation. Neither the region selection nor the mouse location alone provide all the required information.
(0024395)
mpk   
2020-06-05 08:54   
Sure, it's not an exact analogy, but the fact that currently the selection is ignored is the point.
(0024399)
colinf   
2020-06-05 09:12   
A radical thought perhaps, but isn't the idea of a persistent "selection" when Edit point=mouse actually redundant? Shouldn't "the selection" be considered to be whatever is under the mouse pointer (plus any other equivalent regions) at any particular moment? If the mouse is over the track headers, it should be a track selection: if it's over a region, it should be a region selection.

I rarely use EP=mouse, possibly because it's not always clear in my mental model of it what will happen, depending on what (if anything) is selected. Having the selection explicitly and visually follow the mouse would make it absolutely clear what any editing operations were about to apply to.
(0024400)
mpk   
2020-06-05 10:15   
This could be a possibility, perhaps for a new edit mode (essentially what I suggested in 0007994:0021386). But this mode would not be useful for the particular case which prompted this issue, being that it is now impossible to split a region that is not the topmost.

(AFAICT, the use-case for which the change was made seems to be a situation where the user should just use the Cut tool anyway.)
(0025184)
mpk   
2020-10-30 10:20   
Hi, sorry to bump this, but would it be OK to have some feedback on the configuration patch I offered?

No-one can deny that the new behaviour makes operations difficult or time-consuming, that were previously straightforward. And this change seems to have been prompted by a single request from one user on the Mixbus forum. There are configuration options for many more specialist preferences.

https://tracker.ardour.org/view.php?id=7994#c24346

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8444 [ardour] bugs minor always 2020-10-14 20:27 2020-10-29 14:46
Reporter: htrembl Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6.3.0 quits instantly when importing any MIDI file.
Description: Ardour 6.3.0 quits instantly when importing any MIDI file. I've tried the debug version (nightly builds) and it works fine but, still, Ardour 6.3 will crash if I try to open a file created with the debug version. I had the same problem with Ardour 6.2 and i thought it had been solved, but now I can't import any MIDI file. I'm on Ubuntu Studio 16.04.
Tags:
Steps To Reproduce: Import MIDI file.
Additional Information:
System Description
Attached Files: AllIveGotToDo.mid (22,671 bytes) 2020-10-22 15:16
https://tracker.ardour.org/file_download.php?file_id=3851&type=bug
auclaird.mid (3,495 bytes) 2020-10-22 15:16
https://tracker.ardour.org/file_download.php?file_id=3852&type=bug
IWill.mid (16,658 bytes) 2020-10-22 15:16
https://tracker.ardour.org/file_download.php?file_id=3853&type=bug
GDB Core Ardour6 (3,771 bytes) 2020-10-22 17:14
https://tracker.ardour.org/file_download.php?file_id=3854&type=bug
Notes
(0025126)
htrembl   
2020-10-17 18:50   
I just checked again and I can open the MIDI files "notesweep.mid" and "velocitysweep.mid" provided to me by Robin in July.
(0025143)
htrembl   
2020-10-22 15:16   
Most of my MIDI files will crash Ardour 6.3 but load fine into Ardour 4.
(0025145)
htrembl   
2020-10-22 17:14   
GDB output file for Ardour6 crash.
(0025181)
htrembl   
2020-10-29 14:46   
I have now upgraded from Ubuntu 16.04 to 18.04 and also renamed the ladspa folder as some plugins seem to crash Ardour. Now I can import MIDI files that play with General MIDI Synth.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8461 [ardour] other minor always 2020-10-28 00:47 2020-10-28 00:47
Reporter: xhfce Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: se estrella ardour al exportar
Description: al exportar el audio, a como 40% del camino ardour causa un seg fault en jack
Tags: crash, export
Steps To Reproduce: exportar
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8085 [ardour] features minor N/A 2020-05-04 13:53 2020-10-27 11:32
Reporter: dhealey Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Aubio Pitch Detection
Description: Please include the aubio pitch detection VAMP plugin with Ardour. I've found it to be more useful and the pyin one. Thanks
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024062)
x42   
2020-05-04 21:11   
Ardour uses aubio for onset detection, and since libaubio version 0.4 removed multi-channel support, Ardour still comes with the old aubio 0.3 version..

So some additional work has to be done first before we can ship recent vamp-aubio-plugins with pitch detection.
(0024065)
dhealey   
2020-05-04 22:10   
I'm using the plugin at the moment, downloaded from the aubio site and it seems to work without issue.
(0025165)
soundguy30   
2020-10-27 08:59   
Is this a lv2 plugin, also does it have. GUI
(0025167)
dhealey   
2020-10-27 11:32   
No it's a VAMP plugin which can be used by Ardour in a lua script for analysys purposes - https://www.vamp-plugins.org/

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8458 [ardour] features minor N/A 2020-10-26 21:34 2020-10-26 23:37
Reporter: Reuben Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Allow option to use ISO 226:2003 profile in trim faders
Description: Feature request for option to enable use the ISO 266:2003 contour profile when adjusting trim. The LSP "Loudness Compensation" plugin already provides this functionality, but it's a bit finicky to be adjusting trim in a plugin, even when exposing the output control level in the channel strip. If implemented, it would probably be best to be set on a per-channel-strip basis since FFT can get expensive.

One alternative might be to make it possible to assign the trim fader control to one of the controls of a plugin in the channel strip instead of the default fader. This would allow binding the trim control to the output knob in the Loudness Compensation plugin, achieving the same result with the ability to use the same functionality for many other purposes as well.

But then again there may be a good case for building in an ISO 266:2003 variant of the default channel fader.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025159)
x42   
2020-10-26 22:13   
Unlikely to happen. Ardour itself does not do any DSP except for simple lossless gain staging.

All signal processing is done by plugins. The only option would be to create a plugin with tight integration.
Also it sounds rather expensive. Ardour easily handles 1000 tracks, but realtime FFT likely won't scale.
Then there's also the question which of the usefulness of loudness contours during mixing, but that is rendered moot.
(0025160)
x42   
2020-10-26 22:17   
NB. LSP's Loudness Compensator also adds a significant amount of latency (~80ms). You definitely do not want this by default on every track.
(0025161)
Reuben   
2020-10-26 23:28   
Yes, I'm aware of the DSP load and latency stuff, that's why I was thinking the alternative would make more sense of being able to bind the trim fader to a plugin control rather than the default channel-strip fader.
(0025162)
Reuben   
2020-10-26 23:37   
The usefullness aspect for me is when I create a submix that sums to a bus, and then go back to the mix as a whole and pull that submix down stuff gets lost in the submix in ways that seem to be helped by using the Loudness Compensator to trim the submix bus rather than the regular fader.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8452 [ardour] bugs minor sometimes 2020-10-24 05:12 2020-10-26 21:49
Reporter: kfrz Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour 6.3 crashes seconds after loading moderately sized session post-reboot
Description: I worked without issue on a session, sixteen tracks and a handful of built-in plugins.

After a reboot I am having an issue with this session crashing every time I load, roughly 5-10 seconds after loading. Playback works, editing works, until the crash.

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: ardour-6.3.gdb (10,414 bytes) 2020-10-24 05:12
https://tracker.ardour.org/file_download.php?file_id=3855&type=bug
Notes
(0025146)
kfrz   
2020-10-24 05:13   
This does not happen when starting a new session, as far as I can tell.
(0025148)
x42   
2020-10-24 09:01   
The gdb backtrace is sadly not useful (you need a debug build e.g. from https://nightly.ardour.org).

When opening the session, does using "Safe mode: disable plugins" (checkbox in recent session dialog) help?
(0025151)
kfrz   
2020-10-25 02:32   
Disabling plugins with safe mode does not resolve the issue.

For reference, there are 3564 resources defined on the (default) right-side panel.

I'm unable to install the nightly build:

?sh Ardour-6.3.246-dbg-x86_64-gcc5.run
Verifying archive integrity... 100% All good.
 Uncompressing Ardour 100%

Welcome to the Ardour installer

Ardour will be installed for user kf in /opt

[sudo] password for kf:
Sat 24 Oct 2020 09:32:09 PM CDT
Architecture is x86_64
Checking for required disk space

!!! ERROR !!! - Insufficient disk space in /tmp/selfgz1712921
Install requires 1491490184 bytes and
there is only 1062330368 bytes of free space

Press ENTER to exit installer:



Output of df -h
?df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 1.8M 1.6G 1% /run
/dev/mapper/kfbook--vg-root 23G 7.9G 14G 37% /
tmpfs 7.8G 278M 7.5G 4% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup
/dev/sda2 237M 149M 76M 67% /boot
/dev/mapper/kfbook--vg-tmp 1.8G 5.7M 1.7G 1% /tmp
/dev/sdb1 511M 5.4M 506M 2% /boot/efi
/dev/mapper/kfbook--vg-var 9.2G 5.3G 3.4G 62% /var
/dev/mapper/kfbook--vg-home 867G 89G 734G 11% /home
tmpfs 1.6G 52K 1.6G 1% /run/user/1000


I realize there's no support offered for these builds, but is there another way to install? What might I be missing?
(0025152)
x42   
2020-10-25 22:48   
!!! ERROR !!! - Insufficient disk space in /tmp/selfgz1712921
/dev/mapper/kfbook--vg-tmp 1.8G 5.7M 1.7G 1% /tmp


The install unzips itself to /tmp first, you can try

 chmod +x Ardour-6.3.246-dbg-x86_64-gcc5.run
 TMPDIR=$HOME ./Ardour-6.3.246-dbg-x86_64-gcc5.run

or install it manually in steps, see `./Ardour-6.3.246-dbg-x86_64-gcc5.run --help`
(0025153)
x42   
2020-10-25 22:52   
> For reference, there are 3564 resources defined on the (default) right-side panel.

That is a lot, but not usually an issue of concern. Another guess: Ardour runs out of Memory. Perhaps caching waveforms for all those regions (which are rendered in the background).
does `dmesg` show some "OOM" message?
(0025154)
kfrz   
2020-10-26 00:01   
Thank you for the assist here.

I was able to install the debug version 6.3.246-dbg-x86_64-gcc5

I'm using ALSA in lieu of JACK, which hasn't been an issue in the past. Not sure of the details regarding memory and if it could be causing the issue I'm seeing.

Opening and playing the session is now working, without crashing, but the audio is overloading and the DSP indicator is between 95%-100% where it usually is 0000023:0000020% average. This only happens when plugins are *enabled,* playback and editing seem to work fine without crashing on the debug build w/ safe mode enabled.

To summarize:

Release Build:
Without Safe mode, nominal DSP, overflows detected and aborts.
With Safe mode, nominal DSP, overflows detected and aborts.

Debug Build:
Without safe mode, extreme DSP, overflows ignored (?), playback continues without abort but is choppy.
With safe mode, nominal DSP, playback continues, no aborts.

Here's a gist including the output of a few configuration files, the "Help -> About -> Config" output, as well as the Ardour stdout output for both debug and release executions. No core file to be had, yet, until I can reproduce a crash w/ the debug g


https://gist.github.com/kfrz/648cb12daf47d42ff471dbe277612179
(0025155)
kfrz   
2020-10-26 00:03   
Whoops, didn't realize my syntax error in the last note, "0000023:0000020% average." should read " about 20% average"
(0025156)
kfrz   
2020-10-26 03:04   
No "oom" in `dmesg`, nor anything else of note.
(0025157)
x42   
2020-10-26 14:04   
Does an optimized nightly build 6.3-250 also crash?

Debug builds need more DSP (sometimes twice that of an optimized version). What buffersize / sample-rate are you using (Menu > Window > Audio/MIDI Setup)

Also Ardour/ALSA (and other built-in backends) report worst-case DSP load, while JACK averages it (I've seen cases where jack reported 30% on average, but there were x-runs -- occasionally spikes 100% load, but still low average).
(0025158)
kfrz   
2020-10-26 21:49   
Good news (I hope) - the optimized nightly build seems to work fine, without any crashing (yet).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8455 [ardour] bugs minor always 2020-10-25 18:43 2020-10-25 18:43
Reporter: soundguy30 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: File name session bug
Description: When first naming a session then opening the session and trying to save opens up a window to make the session again as if the session wasn’t name, when you type in the same name you typed in it says the name is already used by another directory/folder. Please try again. This is a bug because it should just save the session since it’s already been named.
Tags:
Steps To Reproduce: When first naming a session then opening the session and trying to save opens up a window to make the session again as if the session wasn’t name, when you type in the same name you typed in it says the name is already used by another directory/folder. Please try again. This is a bug because it should just save the session since it’s already been named.

This big appears to happen when I use # in the name of the session. When I tested it without special characters it saved normal.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8454 [ardour] bugs minor always 2020-10-24 19:31 2020-10-24 20:00
Reporter: hecanjog Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Dragging regions creates ghost regions or crashes
Description: In a new session, dragging a sound region to an empty existing track leaves behind a ghost region which I cannot move or interact with. Resizing the track draws a second region askew with the first. Additionally, dragging a region on the same track leaves behind its own ghost, while the existing ghost is always drawn on top of the real region if they are dragged into overlapping positions.

Creating a new session, importing a sound, and dragging the sound into the space below the only track causes ardour to crash instead of creating a new track below as expected.
Tags:
Steps To Reproduce: Please see attached images.
Additional Information:
System Description
Attached Files: a-after1.jpg (131,691 bytes) 2020-10-24 19:31
https://tracker.ardour.org/file_download.php?file_id=3856&type=bug
jpg

a-after2.jpg (151,361 bytes) 2020-10-24 19:31
https://tracker.ardour.org/file_download.php?file_id=3857&type=bug
jpg

a-after3.jpg (159,569 bytes) 2020-10-24 19:31
https://tracker.ardour.org/file_download.php?file_id=3858&type=bug
jpg

a-before.jpg (117,688 bytes) 2020-10-24 19:31
https://tracker.ardour.org/file_download.php?file_id=3859&type=bug
jpg
Notes
(0025149)
hecanjog   
2020-10-24 19:32   
I forgot to mention that closing and reopening Ardour has no effect. Logging out and even rebooting the computer also has no effect.
(0025150)
hecanjog   
2020-10-24 20:00   
Another update: downloading Ardour from ardour.org directly has resolved these issues for me. The issues I was experiencing were using the version packaged for arch linux: https://www.archlinux.org/packages/community/x86_64/ardour/

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8453 [ardour] bugs minor always 2020-10-24 07:29 2020-10-24 07:29
Reporter: soundguy30 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Playback timeline freeze/system lock up
Description: Clicking through various timelines very fast locks up system
Tags:
Steps To Reproduce: click sections very fast from the time line back and forth along the song length eventually ardour freezes. I
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8447 [ardour] bugs minor always 2020-10-19 12:20 2020-10-19 12:20
Reporter: nettings Platform: AMD64  
Assigned To: OS: LInux  
Priority: normal OS Version: openSUSE Tw  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Audio files" selector in file manager dialog does not include .rf64
Description: The "audio files" selector active by default in the ardour file manager dialog in "Session"->"Import" (and probably elsewhere) does not include the RF64 file type which can be selected as default under "Session"->"Properties"->"Media".
The user is thus led to believe that the folder in view is devoid of audio data. This causes a massive release of stress hormones behind the keyboard, which might impair audio quality later on.
Switching the selector to "All files" enables such files to be seen, and imported successfully
Tags: Import
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8415 [ardour] bugs minor random 2020-09-18 20:27 2020-10-19 00:55
Reporter: Fruit tree Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes sometimes when I stop playback
Description: $ Ardour6 --version
bind txt domain [gtk2_ardour6] to /opt/Ardour-6.3.8-dbg/share/locale
Ardour6.3.8 (built using 6.3-8-gf61ecae4b2 and GCC version 6.3.0 20170516)

It's from the nightly builds page, with debug symbols allegedly.

I think this is an instance of a bug that crashes ardour within minutes every time I use it.
It always happens when I stop playback (pressing space). (But not every time I do this)

This time I was finally prepared with a debug build and coredumpctl. I thought. So I ran `coredumpctl debug` after the crash, and in gdb I wrote `thread apply all bt` and just `bt`; both just say a lot of:

Thread 41 (LWP 176868):
#0 0x00007f07a64696a2 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7f0782c0db80

.. So it doesn't have debug symbols?

I'm saving the coredump and I would be very happy if someone could help me extract some useful information out of it, or set up my system to get more useful information next time this bug happens!
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025042)
Fruit tree   
2020-09-18 20:31   
Update: Opened the same project, pressed space to play then space to stop, and it happened again.
So, as I suspected before, I think the reproducibility is 100% reproducible on my machine for a certain project, from some point in time and forth.
A bit more detail: when it happens, there's a buzzing sound for about 10 seconds and this time my system froze completely until Ardour finally exited.
(0025043)
Fruit tree   
2020-09-19 12:48   
Update: This happens only with JACK backend, not ALSA. (but I won't use ALSA)
(0025059)
alandmoore   
2020-09-26 21:43   
I have been having the same bug, only for me it happens fairly often. Often enough to make using ardour extremely frustrating.

I am running version 6.3.0 built using 6.3 and GCC Version 10.2.0, straight from the Arch Linux repositories. (Package version 6.3.0-2). It's been happening since I upgraded from 5.x to 6.x.

I use JACK exclusively.
(0025133)
x42   
2020-10-19 00:55   
If a recently nightly still produces this issue, please try if you can get it to crash while running in gdb, start it: Ardour6 --gdb
in gdb: run

see also https://ardour.org/debugging_ardour "Option 1: Running Ardour inside GDB"

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8442 [ardour] bugs minor always 2020-10-13 19:37 2020-10-17 16:20
Reporter: zeograd Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.3  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: reproducible SIGSEGV in x86_sse_avx_apply_gain_to_buffer > _mm256_load_ps on given project
Description: I have one project (created several years ago) which crashes around the same area (not always at the exact timecode, though) when playing or rendering.
Tags:
Steps To Reproduce: Open project file : https://drive.google.com/file/d/10lC1siJEHxyEqFTR-YEw2-cVwstXvNeE/view?usp=sharing (~ 3Mb, too large to attach here)
Place playhead at 12:08:00
Play

After a few seconds, usually between 12:10:00 and 12:12:00, SIGSEGV occurs
Additional Information: One of the backtrace I got

#0 0x00007ffff78e7a93 in _mm256_load_ps(float const*) (__P=0x7fff998ee000) at /usr/lib/gcc/x86_64-linux-gnu/10/include/avxintrin.h:874
0000001 x86_sse_avx_apply_gain_to_buffer(float*, uint32_t, float) (dst=0x7fff998edfe0, nframes=4290770957, gain=1.37248135) at ../libs/ardour/sse_functions_avx_linux.cc:303
#2 0x00007ffff70d8a2b in ARDOUR::AudioRegion::read_at(float*, float*, float*, long, long, unsigned int) const (this=0x5555620a8290, buf=0x7fff99113f0c, mixdown_buffer=0x7fff988ec010, gain_buffer=0x7fff980eb010, position=32492480, cnt=1, chan_n=0)
    at ../libs/ardour/audioregion.cc:606
#3 0x00007ffff7094944 in ARDOUR::AudioPlaylist::read(float*, float*, float*, long, long, unsigned int) (this=0x55556203ba40, buf=0x7fff990ed010, mixdown_buffer=0x7fff988ec010, gain_buffer=0x7fff980eb010, start=32452609, cnt=65536, chan_n=0) at ../libs/ardour/audio_playlist.cc:263
0000004 0x00007ffff7164c7e in ARDOUR::DiskReader::audio_read(float*, float*, float*, long&, long, ARDOUR::DiskReader::ReaderChannelInfo*, int, bool)
    (this=0x555566cb8bb0, sum_buffer=0x7fff990ed010, mixdown_buffer=0x7fff988ec010, gain_buffer=0x7fff980eb010, start=@0x7fff9a276b68: 32452609, cnt=65536, rci=0x55555d26c5e0, channel=0, reversed=false) at ../libs/ardour/disk_reader.cc:1048
0000005 0x00007ffff7165e56 in ARDOUR::DiskReader::refill_audio(float*, float*, float*, long, bool) (this=0x555566cb8bb0, sum_buffer=0x7fff990ed010, mixdown_buffer=0x7fff988ec010, gain_buffer=0x7fff980eb010, fill_level=0, reversed=false) at ../libs/ardour/disk_reader.cc:1306
#6 0x00007ffff716524d in ARDOUR::DiskReader::refill(float*, float*, float*, long, bool) (this=0x555566cb8bb0, sum_buffer=0x7fff990ed010, mixdown_buffer=0x7fff988ec010, gain_buffer=0x7fff980eb010, fill_level=0, reversed=false) at ../libs/ardour/disk_reader.cc:1129
#7 0x00007ffff71650b7 in ARDOUR::DiskReader::do_refill() (this=0x555566cb8bb0) at ../libs/ardour/disk_reader.cc:1103
0000008 0x00007ffff784c9f0 in ARDOUR::Track::do_refill() (this=0x555566ca1df0) at ../libs/ardour/track.cc:499
0000009 0x00007ffff712e4ba in ARDOUR::Butler::thread_work() (this=0x5555589d7300) at ../libs/ardour/butler.cc:253
0000010 0x00007ffff712d689 in ARDOUR::Butler::_thread_work(void*) (arg=0x5555589d7300) at ../libs/ardour/butler.cc:153
0000011 0x00007ffff58e16a1 in fake_thread_start(void*) (arg=0x55555b9d7b00) at ../libs/pbd/pthread_utils.cc:113
0000012 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000013 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95


with the complete one for all threads as instructed in the doc :

Thread 90 (Thread 0x7fff3ffff700 (LWP 21667)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7f30b8b in ArdourWaveView::WaveViewDrawRequestQueue::dequeue(bool) (this=0x55556e9a7ec8, block=true) at ../libs/waveview/wave_view_private.cc:299
#3 0x00007ffff7f30eb0 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at ../libs/waveview/wave_view_private.cc:368
0000004 0x00007ffff7f31220 in ArdourWaveView::WaveViewDrawingThread::run() (this=0x5555605b9ec0) at ../libs/waveview/wave_view_private.cc:450
0000005 0x00007ffff7f35dcb in sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>::operator()() const (this=0x5555777ecf18) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#6 0x00007ffff7f358d6 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread> >::operator()() const (this=0x5555777ecf10) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007ffff7f352a5 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>, void>::call_it(sigc::internal::slot_rep*) (rep=0x5555777ecee0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000008 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000009 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000010 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 89 (Thread 0x7fff48ffb700 (LWP 21666)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7f30b8b in ArdourWaveView::WaveViewDrawRequestQueue::dequeue(bool) (this=0x55556e9a7ec8, block=true) at ../libs/waveview/wave_view_private.cc:299
#3 0x00007ffff7f30eb0 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at ../libs/waveview/wave_view_private.cc:368
0000004 0x00007ffff7f31220 in ArdourWaveView::WaveViewDrawingThread::run() (this=0x555575f7e750) at ../libs/waveview/wave_view_private.cc:450
0000005 0x00007ffff7f35dcb in sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>::operator()() const (this=0x5555777eccc8) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#6 0x00007ffff7f358d6 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread> >::operator()() const (this=0x5555777eccc0) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007ffff7f352a5 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>, void>::call_it(sigc::internal::slot_rep*) (rep=0x5555777ecc90) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000008 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000009 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000010 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 88 (Thread 0x7fff497fc700 (LWP 21665)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7f30b8b in ArdourWaveView::WaveViewDrawRequestQueue::dequeue(bool) (this=0x55556e9a7ec8, block=true) at ../libs/waveview/wave_view_private.cc:299
#3 0x00007ffff7f30eb0 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at ../libs/waveview/wave_view_private.cc:368
0000004 0x00007ffff7f31220 in ArdourWaveView::WaveViewDrawingThread::run() (this=0x55555d094280) at ../libs/waveview/wave_view_private.cc:450
0000005 0x00007ffff7f35dcb in sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>::operator()() const (this=0x5555777eca78) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#6 0x00007ffff7f358d6 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread> >::operator()() const (this=0x5555777eca70) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007ffff7f352a5 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>, void>::call_it(sigc::internal::slot_rep*) (rep=0x5555777eca40) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000008 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000009 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000010 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 87 (Thread 0x7fff49ffd700 (LWP 21664)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7f30b8b in ArdourWaveView::WaveViewDrawRequestQueue::dequeue(bool) (this=0x55556e9a7ec8, block=true) at ../libs/waveview/wave_view_private.cc:299
#3 0x00007ffff7f30eb0 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at ../libs/waveview/wave_view_private.cc:368
0000004 0x00007ffff7f31220 in ArdourWaveView::WaveViewDrawingThread::run() (this=0x555574740250) at ../libs/waveview/wave_view_private.cc:450
0000005 0x00007ffff7f35dcb in sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>::operator()() const (this=0x5555777ec828) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#6 0x00007ffff7f358d6 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread> >::operator()() const (this=0x5555777ec820) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007ffff7f352a5 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>, void>::call_it(sigc::internal::slot_rep*) (rep=0x5555777ec7f0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000008 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000009 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000010 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 86 (Thread 0x7fff4a7fe700 (LWP 21663)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7f30b8b in ArdourWaveView::WaveViewDrawRequestQueue::dequeue(bool) (this=0x55556e9a7ec8, block=true) at ../libs/waveview/wave_view_private.cc:299
#3 0x00007ffff7f30eb0 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at ../libs/waveview/wave_view_private.cc:368
0000004 0x00007ffff7f31220 in ArdourWaveView::WaveViewDrawingThread::run() (this=0x5555757fe180) at ../libs/waveview/wave_view_private.cc:450
0000005 0x00007ffff7f35dcb in sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>::operator()() const (this=0x5555777ec588) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#6 0x00007ffff7f358d6 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread> >::operator()() const (this=0x5555777ec580) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007ffff7f352a5 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>, void>::call_it(sigc::internal::slot_rep*) (rep=0x5555777ec550) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000008 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000009 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000010 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 85 (Thread 0x7fff4afff700 (LWP 21662)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7f30b8b in ArdourWaveView::WaveViewDrawRequestQueue::dequeue(bool) (this=0x55556e9a7ec8, block=true) at ../libs/waveview/wave_view_private.cc:299
--Type <RET> for more, q to quit, c to continue without paging--c
#3 0x00007ffff7f30eb0 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at ../libs/waveview/wave_view_private.cc:368
0000004 0x00007ffff7f31220 in ArdourWaveView::WaveViewDrawingThread::run() (this=0x5555777b7b90) at ../libs/waveview/wave_view_private.cc:450
0000005 0x00007ffff7f35dcb in sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>::operator()() const (this=0x5555777ec338) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#6 0x00007ffff7f358d6 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread> >::operator()() const (this=0x5555777ec330) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007ffff7f352a5 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>, void>::call_it(sigc::internal::slot_rep*) (rep=0x5555777ec300) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000008 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000009 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000010 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 84 (Thread 0x7fffa5e66700 (LWP 21661)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7f30b8b in ArdourWaveView::WaveViewDrawRequestQueue::dequeue(bool) (this=0x55556e9a7ec8, block=true) at ../libs/waveview/wave_view_private.cc:299
#3 0x00007ffff7f30eb0 in ArdourWaveView::WaveViewThreads::dequeue_draw_request() () at ../libs/waveview/wave_view_private.cc:368
0000004 0x00007ffff7f31220 in ArdourWaveView::WaveViewDrawingThread::run() (this=0x5555777c28f0) at ../libs/waveview/wave_view_private.cc:450
0000005 0x00007ffff7f35dcb in sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>::operator()() const (this=0x5555777ec2d8) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#6 0x00007ffff7f358d6 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread> >::operator()() const (this=0x5555777ec2d0) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007ffff7f352a5 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ArdourWaveView::WaveViewDrawingThread>, void>::call_it(sigc::internal::slot_rep*) (rep=0x5555777ec2a0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000008 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000009 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000010 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 82 (Thread 0x7fffcaffd700 (LWP 21655)):
#0 0x00007ffff3ef8d21 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7fffcaffc880, rem=0x7fffcaffc890) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
0000001 0x00007ffff3efe503 in __GI___nanosleep (requested_time=<optimized out>, remaining=<optimized out>) at nanosleep.c:27
#2 0x00007ffff558586f in g_usleep () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff71171e7 in ARDOUR::AutomationWatch::thread() (this=0x55556812bf90) at ../libs/ardour/automation_watch.cc:195
0000004 0x00007ffff711c4eb in boost::_mfi::mf0<void, ARDOUR::AutomationWatch>::operator()(ARDOUR::AutomationWatch*) const (this=0x55557453ce10, p=0x55556812bf90) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000005 0x00007ffff711c0ff in boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>&, boost::_bi::list0&, int) (this=0x55557453ce20, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
#6 0x00007ffff711b9cd in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> > >::operator()() (this=0x55557453ce10) at /usr/include/boost/bind/bind.hpp:1294
#7 0x00007ffff711b95e in sigc::adaptor_functor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> > > >::operator()() const (this=0x55557453ce10) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000008 0x00007ffff711b3b4 in sigc::internal::slot_call0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::value<ARDOUR::AutomationWatch*> > >, void>::call_it(sigc::internal::slot_rep*) (rep=0x55557453cde0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000009 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000010 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000011 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000012 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 81 (Thread 0x7fffa6667700 (LWP 21654)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x55555cdb84b8) at ../sysdeps/nptl/futex-internal.h:183
0000001 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55555cdb8468, cond=0x55555cdb8490) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=0x55555cdb8490, mutex=0x55555cdb8468) at pthread_cond_wait.c:638
#3 0x00007ffff7711b2d in ARDOUR::Session::auto_connect_thread_run() (this=0x55555cdb6670) at ../libs/ardour/session.cc:7156
0000004 0x00007ffff77117fc in ARDOUR::Session::auto_connect_thread(void*) (arg=0x55555cdb6670) at ../libs/ardour/session.cc:7095
0000005 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 80 (Thread 0x7fffc989a700 (LWP 21653)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x55555cdb844c) at ../sysdeps/nptl/futex-internal.h:183
0000001 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55555cdb83f8, cond=0x55555cdb8420) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=0x55555cdb8420, mutex=0x55555cdb83f8) at pthread_cond_wait.c:638
#3 0x00007ffff7788d69 in ARDOUR::Session::emit_thread_run() (this=0x55555cdb6670) at ../libs/ardour/session_process.cc:1110
0000004 0x00007ffff7788d06 in ARDOUR::Session::emit_thread(void*) (arg=0x55555cdb6670) at ../libs/ardour/session_process.cc:1099
0000005 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 69 (Thread 0x7fff9a0ee700 (LWP 21632)):
#0 0x00007ffff3f264bf in __GI___poll (fds=0x7fff441324e0, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff555adce in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff555b12b in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff58a8690 in BaseUI::main_thread() (this=0x55555a4c1910) at ../libs/pbd/base_ui.cc:98
0000004 0x00007ffff58ac663 in sigc::bound_mem_functor0<void, BaseUI>::operator()() const (this=0x5555602f54f8) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
0000005 0x00007ffff58ac300 in sigc::adaptor_functor<sigc::bound_mem_functor0<void, BaseUI> >::operator()() const (this=0x5555602f54f0) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#6 0x00007ffff58abd67 in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, BaseUI>, void>::call_it(sigc::internal::slot_rep*) (rep=0x5555602f54c0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
#7 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000008 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000009 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000010 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 68 (Thread 0x7fff9a278700 (LWP 21631)):
#0 0x00007ffff78e7a93 in _mm256_load_ps(float const*) (__P=0x7fff998ee000) at /usr/lib/gcc/x86_64-linux-gnu/10/include/avxintrin.h:874
0000001 x86_sse_avx_apply_gain_to_buffer(float*, uint32_t, float) (dst=0x7fff998edfe0, nframes=4290770957, gain=1.37248135) at ../libs/ardour/sse_functions_avx_linux.cc:303
#2 0x00007ffff70d8a2b in ARDOUR::AudioRegion::read_at(float*, float*, float*, long, long, unsigned int) const (this=0x5555620a8290, buf=0x7fff99113f0c, mixdown_buffer=0x7fff988ec010, gain_buffer=0x7fff980eb010, position=32492480, cnt=1, chan_n=0) at ../libs/ardour/audioregion.cc:606
#3 0x00007ffff7094944 in ARDOUR::AudioPlaylist::read(float*, float*, float*, long, long, unsigned int) (this=0x55556203ba40, buf=0x7fff990ed010, mixdown_buffer=0x7fff988ec010, gain_buffer=0x7fff980eb010, start=32452609, cnt=65536, chan_n=0) at ../libs/ardour/audio_playlist.cc:263
0000004 0x00007ffff7164c7e in ARDOUR::DiskReader::audio_read(float*, float*, float*, long&, long, ARDOUR::DiskReader::ReaderChannelInfo*, int, bool) (this=0x555566cb8bb0, sum_buffer=0x7fff990ed010, mixdown_buffer=0x7fff988ec010, gain_buffer=0x7fff980eb010, start=@0x7fff9a276b68: 32452609, cnt=65536, rci=0x55555d26c5e0, channel=0, reversed=false) at ../libs/ardour/disk_reader.cc:1048
0000005 0x00007ffff7165e56 in ARDOUR::DiskReader::refill_audio(float*, float*, float*, long, bool) (this=0x555566cb8bb0, sum_buffer=0x7fff990ed010, mixdown_buffer=0x7fff988ec010, gain_buffer=0x7fff980eb010, fill_level=0, reversed=false) at ../libs/ardour/disk_reader.cc:1306
#6 0x00007ffff716524d in ARDOUR::DiskReader::refill(float*, float*, float*, long, bool) (this=0x555566cb8bb0, sum_buffer=0x7fff990ed010, mixdown_buffer=0x7fff988ec010, gain_buffer=0x7fff980eb010, fill_level=0, reversed=false) at ../libs/ardour/disk_reader.cc:1129
#7 0x00007ffff71650b7 in ARDOUR::DiskReader::do_refill() (this=0x555566cb8bb0) at ../libs/ardour/disk_reader.cc:1103
0000008 0x00007ffff784c9f0 in ARDOUR::Track::do_refill() (this=0x555566ca1df0) at ../libs/ardour/track.cc:499
0000009 0x00007ffff712e4ba in ARDOUR::Butler::thread_work() (this=0x5555589d7300) at ../libs/ardour/butler.cc:253
0000010 0x00007ffff712d689 in ARDOUR::Butler::_thread_work(void*) (arg=0x5555589d7300) at ../libs/ardour/butler.cc:153
0000011 0x00007ffff58e16a1 in fake_thread_start(void*) (arg=0x55555b9d7b00) at ../libs/pbd/pthread_utils.cc:113
0000012 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000013 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 67 (Thread 0x7fffc81f1700 (LWP 21630)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55555d20fe40) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x55555d20fe40) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff7245d94 in ARDOUR::Graph::run_one() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:426
0000005 0x00007ffff724626e in ARDOUR::Graph::helper_thread() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:470
#6 0x00007ffff724c64f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fffc81f09b8, p=0x55555d20fd90) at /usr/include/boost/bind/mem_fn_template.hpp:49
#7 0x00007ffff724bea7 in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fffc81f09c8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000008 0x00007ffff724b34b in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fffc81f09b8) at /usr/include/boost/bind/bind.hpp:1294
0000009 0x00007ffff724abb2 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000010 0x0000555555ba1844 in boost::function0<void>::operator()() const (this=0x7fffc81f09b0) at /usr/include/boost/function/function_template.hpp:763
0000011 0x00007fffde140eb8 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x555558269190) at ../libs/backends/jack/jack_audiobackend.cc:953
0000012 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000013 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 66 (Thread 0x7fffc8272700 (LWP 21629)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55555d20fe40) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x55555d20fe40) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff7245d94 in ARDOUR::Graph::run_one() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:426
0000005 0x00007ffff724626e in ARDOUR::Graph::helper_thread() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:470
#6 0x00007ffff724c64f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fffc82719b8, p=0x55555d20fd90) at /usr/include/boost/bind/mem_fn_template.hpp:49
#7 0x00007ffff724bea7 in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fffc82719c8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000008 0x00007ffff724b34b in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fffc82719b8) at /usr/include/boost/bind/bind.hpp:1294
0000009 0x00007ffff724abb2 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000010 0x0000555555ba1844 in boost::function0<void>::operator()() const (this=0x7fffc82719b0) at /usr/include/boost/function/function_template.hpp:763
0000011 0x00007fffde140eb8 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x555559f46d80) at ../libs/backends/jack/jack_audiobackend.cc:953
0000012 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000013 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 65 (Thread 0x7fffc82f3700 (LWP 21628)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55555d20fe68) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55555d20fe68, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x55555d20fe68, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x55555d20fe68) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff7245103 in ARDOUR::Graph::reached_terminal_node() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:301
0000005 0x00007ffff724cd87 in ARDOUR::GraphNode::finish(int) (this=0x5555625ed528, chain=0) at ../libs/ardour/graphnode.cc:73
#6 0x00007ffff7248690 in ARDOUR::GraphNode::run(int) (this=0x5555625ed528, chain=0) at ../libs/ardour/ardour/graphnode.h:63
#7 0x00007ffff7245f0e in ARDOUR::Graph::run_one() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:442
0000008 0x00007ffff724626e in ARDOUR::Graph::helper_thread() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:470
0000009 0x00007ffff724c64f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fffc82f29b8, p=0x55555d20fd90) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000010 0x00007ffff724bea7 in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fffc82f29c8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000011 0x00007ffff724b34b in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fffc82f29b8) at /usr/include/boost/bind/bind.hpp:1294
0000012 0x00007ffff724abb2 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000013 0x0000555555ba1844 in boost::function0<void>::operator()() const (this=0x7fffc82f29b0) at /usr/include/boost/function/function_template.hpp:763
0000014 0x00007fffde140eb8 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x555559fa99d0) at ../libs/backends/jack/jack_audiobackend.cc:953
#15 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000016 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 64 (Thread 0x7fffc8374700 (LWP 21627)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55555d20fe40) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x55555d20fe40) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff7245d94 in ARDOUR::Graph::run_one() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:426
0000005 0x00007ffff724626e in ARDOUR::Graph::helper_thread() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:470
#6 0x00007ffff724c64f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fffc83739b8, p=0x55555d20fd90) at /usr/include/boost/bind/mem_fn_template.hpp:49
#7 0x00007ffff724bea7 in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fffc83739c8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000008 0x00007ffff724b34b in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fffc83739b8) at /usr/include/boost/bind/bind.hpp:1294
0000009 0x00007ffff724abb2 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000010 0x0000555555ba1844 in boost::function0<void>::operator()() const (this=0x7fffc83739b0) at /usr/include/boost/function/function_template.hpp:763
0000011 0x00007fffde140eb8 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x555559f44230) at ../libs/backends/jack/jack_audiobackend.cc:953
0000012 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000013 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 63 (Thread 0x7fffc83f5700 (LWP 21626)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55555d20fe40) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x55555d20fe40) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff7245d94 in ARDOUR::Graph::run_one() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:426
0000005 0x00007ffff724626e in ARDOUR::Graph::helper_thread() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:470
#6 0x00007ffff724c64f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fffc83f49b8, p=0x55555d20fd90) at /usr/include/boost/bind/mem_fn_template.hpp:49
#7 0x00007ffff724bea7 in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fffc83f49c8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000008 0x00007ffff724b34b in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fffc83f49b8) at /usr/include/boost/bind/bind.hpp:1294
0000009 0x00007ffff724abb2 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000010 0x0000555555ba1844 in boost::function0<void>::operator()() const (this=0x7fffc83f49b0) at /usr/include/boost/function/function_template.hpp:763
0000011 0x00007fffde140eb8 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x555558430160) at ../libs/backends/jack/jack_audiobackend.cc:953
0000012 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000013 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 62 (Thread 0x7fffc8476700 (LWP 21625)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55555d20fe40) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x55555d20fe40) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff7245d94 in ARDOUR::Graph::run_one() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:426
0000005 0x00007ffff724626e in ARDOUR::Graph::helper_thread() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:470
#6 0x00007ffff724c64f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fffc84759b8, p=0x55555d20fd90) at /usr/include/boost/bind/mem_fn_template.hpp:49
#7 0x00007ffff724bea7 in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fffc84759c8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000008 0x00007ffff724b34b in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fffc84759b8) at /usr/include/boost/bind/bind.hpp:1294
0000009 0x00007ffff724abb2 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000010 0x0000555555ba1844 in boost::function0<void>::operator()() const (this=0x7fffc84759b0) at /usr/include/boost/function/function_template.hpp:763
0000011 0x00007fffde140eb8 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x5555583cf190) at ../libs/backends/jack/jack_audiobackend.cc:953
0000012 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000013 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 61 (Thread 0x7fffc84f7700 (LWP 21624)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55555d20fe40) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x55555d20fe40, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x55555d20fe40) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff7245d94 in ARDOUR::Graph::run_one() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:426
0000005 0x00007ffff7246687 in ARDOUR::Graph::main_thread() (this=0x55555d20fd90) at ../libs/ardour/graph.cc:523
#6 0x00007ffff724c64f in boost::_mfi::mf0<void, ARDOUR::Graph>::operator()(ARDOUR::Graph*) const (this=0x7fffc84f69b8, p=0x55555d20fd90) at /usr/include/boost/bind/mem_fn_template.hpp:49
#7 0x00007ffff724bea7 in boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> >::operator()<boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::Graph>&, boost::_bi::list0&, int) (this=0x7fffc84f69c8, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000008 0x00007ffff724b34b in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >::operator()() (this=0x7fffc84f69b8) at /usr/include/boost/bind/bind.hpp:1294
0000009 0x00007ffff724abb2 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::Graph>, boost::_bi::list1<boost::_bi::value<ARDOUR::Graph*> > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:158
0000010 0x0000555555ba1844 in boost::function0<void>::operator()() const (this=0x7fffc84f69b0) at /usr/include/boost/function/function_template.hpp:763
0000011 0x00007fffde140eb8 in ARDOUR::JACKAudioBackend::_start_process_thread(void*) (arg=0x55555b9d73b0) at ../libs/backends/jack/jack_audiobackend.cc:953
0000012 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000013 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 60 (Thread 0x7fffc901fc40 (LWP 21623)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x7fffd2e3d0e0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x7fffd2e3d0e0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff76d3f59 in ARDOUR::RTTaskList::run() (this=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:112
0000005 0x00007ffff76d3d46 in ARDOUR::RTTaskList::_thread_run(void*) (arg=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:68
#6 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 59 (Thread 0x7fffc902bc40 (LWP 21622)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x7fffd2e3d0e0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x7fffd2e3d0e0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff76d3f59 in ARDOUR::RTTaskList::run() (this=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:112
0000005 0x00007ffff76d3d46 in ARDOUR::RTTaskList::_thread_run(void*) (arg=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:68
#6 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 58 (Thread 0x7fffc9037c40 (LWP 21621)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x7fffd2e3d0e0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x7fffd2e3d0e0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff76d3f59 in ARDOUR::RTTaskList::run() (this=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:112
0000005 0x00007ffff76d3d46 in ARDOUR::RTTaskList::_thread_run(void*) (arg=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:68
#6 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 57 (Thread 0x7fffc9043c40 (LWP 21620)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x7fffd2e3d0e0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x7fffd2e3d0e0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff76d3f59 in ARDOUR::RTTaskList::run() (this=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:112
0000005 0x00007ffff76d3d46 in ARDOUR::RTTaskList::_thread_run(void*) (arg=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:68
#6 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 56 (Thread 0x7fffc904fc40 (LWP 21619)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x7fffd2e3d0e0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x7fffd2e3d0e0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff76d3f59 in ARDOUR::RTTaskList::run() (this=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:112
0000005 0x00007ffff76d3d46 in ARDOUR::RTTaskList::_thread_run(void*) (arg=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:68
#6 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 55 (Thread 0x7fffc905bc40 (LWP 21618)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x7fffd2e3d0e0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x7fffd2e3d0e0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff76d3f59 in ARDOUR::RTTaskList::run() (this=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:112
0000005 0x00007ffff76d3d46 in ARDOUR::RTTaskList::_thread_run(void*) (arg=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:68
#6 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 54 (Thread 0x7fffdcd72c40 (LWP 21617)):
#0 futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x7fffd2e3d0e0) at ../sysdeps/nptl/futex-internal.h:320
0000001 do_futex_wait (sem=sem@entry=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:112
#2 0x00007ffff464b278 in __new_sem_wait_slow (sem=0x7fffd2e3d0e0, abstime=0x0, clockid=0) at sem_waitcommon.c:184
#3 0x00007ffff7248626 in PBD::Semaphore::wait() (this=0x7fffd2e3d0e0) at ../libs/pbd/pbd/semutils.h:64
0000004 0x00007ffff76d3f59 in ARDOUR::RTTaskList::run() (this=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:112
0000005 0x00007ffff76d3d46 in ARDOUR::RTTaskList::_thread_run(void*) (arg=0x7fffd2e3d0b0) at ../libs/ardour/rt_tasklist.cc:68
#6 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 36 (Thread 0x7fffca7fc700 (LWP 21594)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007fffde04ebb2 in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#2 0x00007fffde031975 in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#3 0x00007fffde030438 in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
0000004 0x00007fffde140f66 in ARDOUR::JACKAudioBackend::process_thread() (this=0x5555573e3250) at ../libs/backends/jack/jack_audiobackend.cc:982
0000005 0x00007fffde140f06 in ARDOUR::JACKAudioBackend::_process_thread(void*) (arg=0x5555573e3250) at ../libs/backends/jack/jack_audiobackend.cc:961
#6 0x00007fffde0308eb in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#7 0x00007fffde04cd2c in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
0000008 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000009 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 35 (Thread 0x7fffdc32b700 (LWP 21593)):
#0 __libc_read (nbytes=4, buf=0x7fffdc32a850, fd=17) at ../sysdeps/unix/sysv/linux/read.c:26
0000001 __libc_read (fd=17, buf=0x7fffdc32a850, nbytes=4) at ../sysdeps/unix/sysv/linux/read.c:24
#2 0x00007fffde04df5e in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#3 0x00007fffde0516dd in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
0000004 0x00007fffde051522 in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
0000005 0x00007fffde04cd2c in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#6 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 34 (Thread 0x7fffdc3ac700 (LWP 21592)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x55555809c858) at ../sysdeps/nptl/futex-internal.h:183
0000001 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55555809c800, cond=0x55555809c830) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=0x55555809c830, mutex=0x55555809c800) at pthread_cond_wait.c:638
#3 0x00007fffde04d7ee in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
0000004 0x00007fffde041ca5 in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
0000005 0x00007fffde04cd2c in () at /usr/lib/x86_64-linux-gnu/libjack.so.0
#6 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 14 (Thread 0x7fffcbfff700 (LWP 21543)):
#0 0x00007ffff3f264bf in __GI___poll (fds=0x555557d6af10, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff555adce in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff555b12b in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff337c746 in () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
0000004 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000005 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 13 (Thread 0x7fffdcc32700 (LWP 21542)):
#0 0x00007ffff3f264bf in __GI___poll (fds=0x555557d5f6c0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff555adce in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff555aeef in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff555af41 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000004 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000005 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7fffde983700 (LWP 21536)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff70bebc7 in ARDOUR::AudioEngine::do_devicelist_update() (this=0x55555730fb20) at ../libs/ardour/audioengine.cc:703
#3 0x00007ffff70cbaff in boost::_mfi::mf0<void, ARDOUR::AudioEngine>::operator()(ARDOUR::AudioEngine*) const (this=0x55555730b350, p=0x55555730fb20) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000004 0x00007ffff70cb513 in boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::AudioEngine>&, boost::_bi::list0&, int) (this=0x55555730b360, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000005 0x00007ffff70caced in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >::operator()() (this=0x55555730b350) at /usr/include/boost/bind/bind.hpp:1294
#6 0x00007ffff70ca4b0 in sigc::adaptor_functor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > > >::operator()() const (this=0x55555730b350) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007ffff70c99d6 in sigc::internal::slot_call0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >, void>::call_it(sigc::internal::slot_rep*) (rep=0x55555730b320) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000008 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000009 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000010 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 6 (Thread 0x7fffdf1c7700 (LWP 21535)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff70be988 in ARDOUR::AudioEngine::do_reset_backend() (this=0x55555730fb20) at ../libs/ardour/audioengine.cc:667
#3 0x00007ffff70cbaff in boost::_mfi::mf0<void, ARDOUR::AudioEngine>::operator()(ARDOUR::AudioEngine*) const (this=0x55555730b460, p=0x55555730fb20) at /usr/include/boost/bind/mem_fn_template.hpp:49
0000004 0x00007ffff70cb513 in boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> >::operator()<boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ARDOUR::AudioEngine>&, boost::_bi::list0&, int) (this=0x55555730b470, f=..., a=...) at /usr/include/boost/bind/bind.hpp:259
0000005 0x00007ffff70caced in boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >::operator()() (this=0x55555730b460) at /usr/include/boost/bind/bind.hpp:1294
#6 0x00007ffff70ca4b0 in sigc::adaptor_functor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > > >::operator()() const (this=0x55555730b460) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#7 0x00007ffff70c99d6 in sigc::internal::slot_call0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::value<ARDOUR::AudioEngine*> > >, void>::call_it(sigc::internal::slot_rep*) (rep=0x55555730b430) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
0000008 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000009 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000010 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000011 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 5 (Thread 0x7fffed165700 (LWP 21522)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7071fbc in ARDOUR::Analyser::work() () at ../libs/ardour/analyser.cc:93
#3 0x00007ffff7071db4 in analyser_work() () at ../libs/ardour/analyser.cc:58
0000004 0x000055555643a491 in sigc::pointer_functor0<void>::operator()() const (this=0x555557057f08) at /usr/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
0000005 0x00005555564376fc in sigc::adaptor_functor<sigc::pointer_functor0<void> >::operator()() const (this=0x555557057f00) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#6 0x0000555556433b33 in sigc::internal::slot_call0<sigc::pointer_functor0<void>, void>::call_it(sigc::internal::slot_rep*) (rep=0x555557057ed0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
#7 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
0000008 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000009 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000010 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7fffed966700 (LWP 21521)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7817b94 in peak_thread_work() () at ../libs/ardour/source_factory.cc:74
#3 0x000055555643a491 in sigc::pointer_functor0<void>::operator()() const (this=0x555557057f78) at /usr/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
0000004 0x00005555564376fc in sigc::adaptor_functor<sigc::pointer_functor0<void> >::operator()() const (this=0x555557057f70) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000005 0x0000555556433b33 in sigc::internal::slot_call0<sigc::pointer_functor0<void>, void>::call_it(sigc::internal::slot_rep*) (rep=0x555557057f40) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
#6 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#7 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000008 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000009 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7fffee167700 (LWP 21520)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
0000001 0x00007ffff55abbaf in g_cond_wait () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff7817b94 in peak_thread_work() () at ../libs/ardour/source_factory.cc:74
#3 0x000055555643a491 in sigc::pointer_functor0<void>::operator()() const (this=0x555557058008) at /usr/include/sigc++-2.0/sigc++/functors/ptr_fun.h:77
0000004 0x00005555564376fc in sigc::adaptor_functor<sigc::pointer_functor0<void> >::operator()() const (this=0x555557058000) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
0000005 0x0000555556433b33 in sigc::internal::slot_call0<sigc::pointer_functor0<void>, void>::call_it(sigc::internal::slot_rep*) (rep=0x555557057fd0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
#6 0x00007ffff56e8db2 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#7 0x00007ffff5583ddd in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0000008 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000009 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7fffee968700 (LWP 21519)):
#0 0x00007ffff3ef8d21 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7fffee9678a0, rem=0x7fffee9678b0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
0000001 0x00007ffff3efe503 in __GI___nanosleep (requested_time=<optimized out>, remaining=<optimized out>) at nanosleep.c:27
#2 0x00007ffff558586f in g_usleep () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00005555567bc2ec in gui_event_loop(void*) (ptr=0x0) at ../gtk2_ardour/linux_vst_gui_support.cc:374
0000004 0x00007ffff4641ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
0000005 0x00007ffff3f30eaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7fffef389c40 (LWP 21518)):
#0 0x00007ffff3f264bf in __GI___poll (fds=0x555557d37300, nfds=5, timeout=20) at ../sysdeps/unix/sysv/linux/poll.c:29
0000001 0x00007ffff555adce in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff555b12b in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff51e612a in gtk_main () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
0000004 0x00007ffff5a8fe14 in Gtkmm2ext::UI::run(Receiver&) (this=0x55555733b510, old_receiver=...) at ../libs/gtkmm2ext/gtk_ui.cc:293
0000005 0x00005555561683d4 in main(int, char**) (argc=1, argv=0x7fffffffcca8) at ../gtk2_ardour/main.cc:395
System Description
Attached Files:
Notes
(0025123)
zeograd   
2020-10-14 21:04   
To complete the bug report and the stack trace where nframes seems to be a very large number, but could be corrupted, here is a working workaround:

audioregion.cc::606

        if (to_read == 1)
            *mixdown_buffer *= _scale_amplitude;
        else
            apply_gain_to_buffer(mixdown_buffer, to_read, _scale_amplitude);

which seems to imply that tiny buffers (1-length) crashes x86_sse_avx_apply_gain_to_buffer
(0025125)
x42   
2020-10-17 16:20   
Fixed in 6.3-215-g1a7dc947a2

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8230 [ardour] bugs minor random 2020-06-13 14:00 2020-10-17 00:50
Reporter: Fruit tree Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Upon opening a project, Helm patches in the project are completely messed up
Description: This bug has happened a few times and can be quite severe (loss of patches).
When saving, closing, and opening the project again, Helm patches are completely messed up.
I attach a screenshot of the weird patch that all Helm instances in the project are set to.
Tags:
Steps To Reproduce: Last time what I did was:
Start a new project, load Helm in some tracks.
Create a simple patch in each of the Helm instances, create some MIDI melodies, add some reverb, delay plugins etc.
Save the project.
Quit Ardour.
Launch Ardour and select the same project.
Additional Information: I don't know if this could happen to other plugins than Helm, I haven't experienced it. But I have also been using Helm most of the time, so I don't know.
System Description
Attached Files: 23.Saturday-slop5755.png (152,867 bytes) 2020-06-13 14:00
https://tracker.ardour.org/file_download.php?file_id=3736&type=bug
png
Notes
(0024459)
x42   
2020-06-13 16:02   
Helm VST or LV2 plugin?
(0024460)
Fruit tree   
2020-06-13 19:13   
VST (lxvst in the .ardour file)
(0024462)
Fruit tree   
2020-06-14 10:36   
The same problem just happened with the LV2 plugin as well. This time, Ardour actually crashed though, whereas previously I gracefully quit it before starting it.
Anyway, I think it's worth knowing this, because again it sets the knobs and envelopes etc to exactly the same as above.
(0024488)
Fruit tree   
2020-06-21 14:41   
I just found that ALL Helm instances throughout ALL my projects since 4th of June (that was my first project) are completely ruined.
That's pretty serious, am I really the only one who has this issue..?
(0025124)
x42   
2020-10-17 00:50   
Since it happens with both VST and LV2 and also in other plugin hosts (zrythm - https://github.com/mtytel/helm/issues/260) there is overwhelming anecdotal evidence that this is a helm issue.
Another hint towards this is that other plugins in Ardour do not have this issue.

I don't think there's anything we can do at the Ardour end of things.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8443 [ardour] bugs minor always 2020-10-14 05:35 2020-10-14 05:35
Reporter: unsafelyhotboots Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Always adds template bus onto the 5th track of the mix, unless there is less than 5 tracks
Description: I created a bus that happened to be on the 5th track of a mix when I made it a template. Now, whenever I add it - regardless of where I specify it to drop in the mixer - it adds it in slot 5. When I try to add it to a group, and collect that group somewhere in the mix, the group collects around that track.
Tags:
Steps To Reproduce: Create a bus on track 5
Create a template of that bus
Open a new project
Populate it with tracks
Add the bus template to the tracks
Watch as no matter where it's selected, it goes to track 5.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8408 [ardour] bugs minor always 2020-09-16 19:59 2020-10-11 20:28
Reporter: Assembled Pieces Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: moving multiple audio/midi regions does not maintain relative position of the regions in time
Description: When selecting multiple audio/midi regions of one ore more tracks (e.g. drum samples) by mouse and moving them in time in editor window with the mouse, it stacks some or all regions seemingly randomly instead of keeping the relative distance of the regions they had before dragging. Sometimes all regions are stacked, sometimes only few. having snap enabled or not does not seem to make a difference.
Tags: ardour6, buster, Editor, region
Steps To Reproduce: Select multiple regions in editor view by dragging a rectangle with the mouse and drag the regions to an earlier or later point in time
Additional Information: However this does not occure if you select the regions, then use the arrow buttons "nudge regions/selection earlier" or "nudge regions/selection later" first and only then move the whole selection by mouse to the desired point in time.

Also in the Ardour 5.12 provided by the Debian repositories, this issue is not present.
System Description
Attached Files:
Notes
(0025118)
anachromium   
2020-10-11 12:48   
Could it be that you have your regions position-locked to bars/beats with some tempo or bar type changes? Then - if I understand correctly - ardour tries to keep the relative alignment in terms of bar/beat correct. (Which ironically would make the "correct behaviour by nudging first" the unintuitive/wrong one.)
(0025119)
Assembled Pieces   
2020-10-11 20:28   
Hey anachromium thank you for your reply. It made me experiment again with the sessions where I observed this behavior. Interestingly, if I mark the regions with the rubber band and remove the checkbox to glue to bars and beats from the right-click-context menu before moving the regions this issue also does not occur.

Currently there are neither tempo changes nor changes in time signature in the project, though. I observed this so far in two projects and, if I recall correctly, I might have set some tempo changes in the beginning of each project before settling for a final tempo decision and deleting any tempo markers. Also these projects might have originally been created with an earlier Version of Ardour 6 than 6.3. I did not succeed so far in reproducing this behavior in a newly created session by purposely applying the above mentioned steps. I do not know if a bug can be inherent to a session rather than to a version of Ardour.

Bottom line is that I seemed to be able to clean the sessions of this behavior by ctrl + a in grab mode, then right mouse button and remove the checkbox or nudge everything forward and then backward. I do not find it unlikely this issue might have been created by some unfortunate combination of settings, but I have yet to discover what exactly this would be.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8441 [ardour] bugs minor random 2020-10-10 10:21 2020-10-10 10:21
Reporter: finotti Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Current Session Frequent Crashes
Description: After some stage of my current project I started to have very frequent crashes. In the middle of it I switched from 6.2 to 6.3, and I *think* that the crashes started after the switch.

Another change as replacing reverb IRs with DragonFly reverbs, and again, I *think* that the crashes might have started after that.
Tags:
Steps To Reproduce: I haven't used Ardour with other projects recently, so I can't say for sure if it happens with other sessions. But, in a brief test with a much simpler project, it did not crash. So, I assume it is something about the current project.

The crashes seem to happen at random times, and there is no sequence of steps I can follow to make it crash, but these crashes have been happening within a few minutes of work. I'd say always less than 10 minutes.
Additional Information:
System Description
Attached Files: gdb.txt (73,370 bytes) 2020-10-10 10:21
https://tracker.ardour.org/file_download.php?file_id=3848&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8440 [ardour] bugs minor always 2020-10-10 03:03 2020-10-10 03:03
Reporter: Grumplstink Platform: Linux Mint 19.1 Tessa  
Assigned To: OS: Linux 5.4.0-48-Generic(x86_64)  
Priority: normal OS Version: #52~18.04.1_Ubun  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Loop function not working
Description: Select loop section of Track, Press Loop tab on Menu bar or use hot key 'L' only as you press button, do you get green area only for a fraction of a second Also whilst trying to select the 'Play' and 'Stop' function in top Menu bar ..Flicker wildly.
Tags:
Steps To Reproduce: Just try to Loop
Additional Information: Loop works fine on my Ardour 5.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8439 [ardour] bugs minor always 2020-10-06 15:33 2020-10-06 15:33
Reporter: magnetophon Platform: GNU  
Assigned To: OS: NixOS  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Conceal LADSPA if matching LV2 exists removes Comb-splitter
Description: When I enable the above option, the "Comb-splitter" by swh is no longer available
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7537 [ardour] bugs feature always 2018-01-06 11:28 2020-10-04 17:08
Reporter: mrmrrs Platform: GNU/Linux  
Assigned To: OS: PureOS  
Priority: normal OS Version: 8  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Mix groups volume control
Description: I encountered the annoying fact, that the overall volume fader settings within a mix group (channel or bus group) change, independent from what is set in the group's settings. So if I set the volume not to be changed for the whole group, but keep the relative option checked, the volume faders still do change there positions. This does not make sense actually, because "Volume" is the upper option, "Relative" it's bottom (sub-)option. So in practice, in any other software, usually the bottom option is depending on the upper (master) option and therefore only active, if it's upper option is active. Any other behavior is just not logical.
Tags: active, control, faders, group, GUI, loudness, mixer, overwrite, Preferences
Steps To Reproduce: Set at least 2 mix channels or buses to the same mix group. Set the common properties for the group to the following: "Volume: not checked", "Relative: checked".
Additional Information: I don't know, if this applies to older versions of Ardour.
Attached Files:
Notes
(0020583)
relascope   
2019-02-17 19:57   
cannot reproduce with Lubuntu 18.10. and Ardour 5.12 and ardour from git.
(0020585)
x42   
2019-02-17 20:13   
I cannot reproduce this with Ardour 5.12 either using the Mouse. When disabling "gain" sharing, the "relative" options become insensitive (grayed-out) and is not relevant.

How do you change the fader's gain?
If you use the keyboard arrow up/down, keep in mind that this applies to all selected tracks, so you may need to disable selection-sharing of the group as well.

PS. note that you can temporarily invert/override a group by holding the "shift" key.
(0025106)
KannebTo   
2020-10-04 17:08   
I have the exactly the same problem with Ardour 6.3.0 on ArchLinux.
When i create a group for multiple tracks with all group sharing options unchecked and then select multiple tracks at once, all faders in that group are linked, even when only one track is selected. Deactivating the group has no effect. To fix this i have to check and uncheck the "Gain" option again or restart Ardour. Closing and opening the session doesn't help. Some other actions tend to trigger this strange behavior too (e.g. undo + redo).
BTW: how can i undo a fader change?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8436 [ardour] features minor always 2020-10-02 17:12 2020-10-02 17:12
Reporter: kevinw Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Korg NanoKontrol Studio mappings wrong for master gain and pan.
Description: The first channel strip in the NanoKontrol Studio should control the Ardour Master channel, but the gain and pan are not working for me.

With the following change I get gain and pan working:

$ diff Korg_nanoKONTROL_Studio.map Korg_nanoKONTROL_Studio_Kevin.map
2c2
< <ArdourMIDIBindings version="1.0.0" name="Korg nanoKONTROL Studio">
---
> <ArdourMIDIBindings version="1.0.0" name="Korg nanoKONTROL Studio (Kevin)">
113c113
< <Binding channel="1" ctl="21" uri="/bus/mute master"/>
---
> <Binding channel="1" ctl="21" uri="/route/mute master"/>
117,118c117,118
< <Binding channel="1" ctl="13" uri="/bus/panwidth master"/>
< <Binding channel="1" ctl="2" uri="/bus/gain master"/>
---
> <Binding channel="1" ctl="13" uri="/route/pandirection master"/>
> <Binding channel="1" ctl="2" uri="/route/gain master"/>

Tags: midi_map
Steps To Reproduce: Use of the gain and pan on the Master channel don't work out of the box with the NanoKontrol Studio.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8435 [ardour] bugs minor always 2020-10-02 14:46 2020-10-02 14:46
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Kill all playing notes when switching selected MIDI track to avoid stuck notes when using Follow Input
Description: When using MIDI input following selection, if the user switches between tracks before he releases a note - that note will get stuck and require the user to use the global MIDI Panic function.

Could Ardour automatically kill all notes coming from the automatically assigned input before disconnecting it in such cases?
Tags: Midi
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7294 [ardour] features minor always 2017-03-17 10:20 2020-10-02 13:05
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 5.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Making the "Bender" automation easier on the user
Description: I found it's pretty difficult to manipulate the "Bender" (pitch bend) automation for MIDI regions.

Two reasons:

1. The arbitrary range of 0 .. 16384 with 8129 in the middle is difficult to understand for a regular user. I guess it'd be much easier if the Bender values ranged from -1 to +1, with 0 in the middle.

2. It's very hard to get back to the middle (rest position) - some form of snapping to 8192 (or 0 if we change the scale) would be great. Also a visible horizontal line in the middle would make it much easier to hit the spot, even without snapping.

What do you think?
Tags:
Steps To Reproduce:
Additional Information: Another step forward could be a way to set the range of the pitchbend and interpret the values as octaves, semitones and cents, optionally even drawing a nice grid to help hitting the clean notes, octaves etc.

I don't know if there's a way to send or get this data from/to softsynths - for example ZynAddSubFX allows the user to change the Bender range, it'd be cool if the plugins could communicate about that with the DAW so the user doesn't have to set the same thing twice. But that's probably a topic for LV2 development.
Attached Files:
Notes
(0025101)
unfa   
2020-10-02 13:05   
Editing Bender automation is still a horrible experience in Ardour 6.3.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8434 [ardour] features minor always 2020-10-02 12:24 2020-10-02 12:24
Reporter: unfa Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot undo deleting a plug-in from the processor box
Description: Thre's no way to bring back a deleted plug-in.

Ans since Shift+Right click can get rid of them super easily with no confirmation of any kind, this is a bit dangerous...

Please implement a way to undo deleting plug-ins!
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8433 [ardour] bugs minor have not tried 2020-10-02 12:06 2020-10-02 12:06
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Vertical Blue Line is not shown in the Cut mode if Edit Point is not set to Mouse
Description: I've seen that a blue vertical line indicates where a cut would be done when using the Grab tool while Edit Point is set to Mouse.

It makes sense that this line is only there if the Edit Point is set to Mouse (as it is by default).

However the Cut mode will always cut on mouse position, disregarding the Edit Point setting.
Shouldn't the blue line be always visible in Cut mode even if Edit Point is not set to Mouse then?

This doesn't seem consistent, as the cuts *will* be done under the mouse in Cut Mode, and they will obey snapping, but the re's no blue line to indicate that any more.

Is that intentional?
Tags: ui
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8429 [ardour] other minor always 2020-09-29 08:38 2020-10-01 03:09
Reporter: alightalike Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: I just upgraded to 6.3 from 5.x. Why is it so slow?
Description: Ardour ran so well in version 4. I had no issue with speed. Now in Ardour 6 I am constantly waiting for the program to catch up with what I am doing. Is this an issue that devteam is planning to fix? Is Ardour just going to get slower as y'all add more features? Please advise. Although I greatly appreciate the UX improvements that have been made since version 4, I am strongly considering downgrading due to the awful performance I am getting.

Is this normal?
Tags:
Steps To Reproduce: use the program
Additional Information: I am running a core i5 6600k with plenty of RAM. My PC should be able to run this program smoothly in 2020.

locate took 51525 usecs for 20 tracks = 2576 per track
locate took 57353 usecs for 20 tracks = 2868 per track
~~~
locate took 62566 usecs for 20 tracks = 3128 per track
locate took 66015 usecs for 20 tracks = 3301 per track
locate took 46869 usecs for 20 tracks = 2343 per track
locate took 2391 usecs for 20 tracks = 120 per track

^^ this isn't the only slow thing that it is doing but it's the only one I see in the console without any flags on startup.
System Description
Attached Files: out.txt (1,881 bytes) 2020-10-01 00:09
https://tracker.ardour.org/file_download.php?file_id=3845&type=bug
Notes
(0025080)
alightalike   
2020-09-29 09:09   
Part of the problem was that I had the locked mem limit set to 250MB... I cranked it up to 25GB (my system actually has 16GB) and that helped a lot. It's not perfect but it's a lot better than it was. Please let me know if y'all have any more tips as to making this great program run more quickly.
(0025081)
x42   
2020-09-29 13:54   
I have the opposite experience. Overall Ardour 6.x is more snappy than Ardour 5.12.
Could it be that you're using a non-optimized debug build (which is significantly slower)? Menu > Help > About ("Intel 64-bit - debug) ?

How do you notice that it's slow? Is this mainly a GUI experience (scroll, zoom), session with many regions? or increased DSP load?


> locate took 66015 usecs for 20 tracks = 3301 per track

That is a debug message for profiling reading data from disk, to establish I/O performance when seeking.
(0025086)
alightalike   
2020-09-30 03:38   
I actually misread usecs as msecs and thought it was taking over a minute to do the process. It is a session with many regions, yes. The DSP load is moderately increased compared to ardour 5. The GUI is definitely the slowest part.

And, I am using a debug build. I'm going back now to rebuild the source as an optimized build
(0025093)
alightalike   
2020-10-01 00:09   
I have been so far unable to compile an optimized build that works; I have attached a log of ardour's output.

However, the optimized build I got from the arch repo works fine. It is still very slow to use the GUI (at least with a couple dozen tracks/regions in my session), especially to scroll up and down the tracks list. A workaround for me is simply to zoom out so the entire session is visible on the screen and I don't have to scroll.
(0025094)
x42   
2020-10-01 00:36   
Looks like installing went wrong somehow.
Can you run it from the source tree after compiling (without install)?

cd gtk2_ardour/ ; ./ardev
(0025095)
alightalike   
2020-10-01 00:43   
I get the same output running ./ardev from ardour/gtk2_ardour/. The same source compiled and ran perfectly without the flags '--optimize --lxvst --program-name="Ardour6-native"'

I was originally trying to compile with '--vst3 --windows-vst' as well; the flag --windows-vst threw a wine error and I dropped the --vst3 flag along with it.
(0025096)
x42   
2020-10-01 01:06   
don't set --program-name="Ardour6-native"'
(0025097)
x42   
2020-10-01 01:08   
compare to https://nightly.ardour.org/i/A_Linux_x86_64-gcc5abi/build_log.txt

vst3 and lxvst (vst2) are enabled by default.
(0025098)
alightalike   
2020-10-01 03:09   
That fixed my build error. Thanks! The GUI is still painfully slow. It takes approximately fifteen seconds for ardour6 to scroll one notch up or down or side to side on the region list.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8432 [ardour] bugs minor always 2020-09-30 22:37 2020-09-30 23:09
Reporter: ahellquist Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Metronome not in sync if jack buffer size is changed.
Description: i have a session with 8 software synths and one audio track.

Everything was recorded using a buffer of 256 for low latency and all tracks as well as the built in metronome is in perfect sync.
However, If i change buffer size to a larger size, the metronome will be offset to the tracks and if i change to 4096 it will be way off.
Even changing to 512 is too much to be usable and the click needs to be muted.

Nothing fancy regarding routing or hardware monitoring going on, Every track is routed to master and there are sends to a reverb bus. Pretty standard
.
Laptop with ubuntu+kxstudio repos and a Motu Ultralite AVB connected via USB and headphones from the Motu interface.

See additional information for update on this:
Tags: 6.2, compensation, jack, lag, latency
Steps To Reproduce:
Additional Information: I have always had my click output routed to the audio interface playback channels 1+2 for monitors and 3+4 for my headphones and that is apparently why it only works if I stay at one buffer size. Changed to output my click to Aurdour master bus and then the click will be in sync as expected.

Question. Is that by design and the correct behavior or should Ardour compensate the timing of the click to follow the total latency of the other signals from track to master out even if a user route the click to hardware ? I think it should work the same but maybe it is not possible ?

A side note, when using buffers 4096, the meters in Ardour is not at all in sync but displays audio ahead of the actual output. Is that something that is known or being addressed ? I am running 6.2 so maybe am an "barking up the wrong tree..." ;-)
System Description
Attached Files:
Notes
(0025090)
ahellquist   
2020-09-30 22:41   
To make it clear, After rerouting click to Master. Everything is in perfect sync except the metering which is early. Only visual stuff.
My questions still are important I think since there might be things overlooked regarding latency compensation.
(0025092)
x42   
2020-09-30 23:09   
Are you using jack2? That is notorious for having issues with sending latency-callbacks. Ardour 6.3 includes a workaround, but I do not know if this specific issue is addressed.
And yes, forcing a connection change is another work-around.

Ardour does not interpolate meters, so at 4k buffers, the meter only update every 80-95ms (depending on sample-rate).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8395 [ardour] features minor N/A 2020-09-04 21:24 2020-09-30 21:55
Reporter: wargreen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Export as a loop
Description: It would be very great if we could export a range as a loop.
It would be the export of the second play pass of the looped range. This would allow to get the end of the effects at the beginning of the exported sample.
Tags: loop
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025062)
alightalike   
2020-09-27 07:45   
honestly I had trouble exporting a looped file without a little gap on repeat even when the source wav looped perfectly. this was a few years ago; that may or may not have been corrected since. have you tried exporting a dry mix and checking if it even loops?
(0025064)
alightalike   
2020-09-27 07:47   
for what you want to do; just duplicate the file within ardour and export a range corresponding to the second loop? would that work?
(0025088)
wargreen   
2020-09-30 21:55   
Unfortunately no, I need the late FX (reverb, delays) of the end of the loop mixed at the beginning of the loop. So i think i need to export the second pass of the loop.
Or it is another way to do this ?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8430 [ardour] bugs minor always 2020-09-29 19:47 2020-09-29 19:47
Reporter: AliMacD Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour plays longer than selected range
Description: from https://discourse.ardour.org/t/playing-very-short-ranges-within-regions/104744/5

selecting a range, Ardour always plays longer than selected

With short buffer sizes in Audio MIDI setup this is small, but with bigger buffers it is significant
Tags:
Steps To Reproduce: using Robin’s session
http://robin.linuxaudio.org/tmp/roll-start-test.ardour-session-archive

I select a region from Spike 1 to Spike 2 (they are 1920 samples apart)
Play range/selection : I hear, and see on meters, both spikes

with 16 sample buffer size (in Audio MID setup)
If I select a region from Spike 1 1889 samples or more in length (though less than 1920 samples in length)
Play range/selection : I hear both spikes (and Spike 2 shows on its track meter)

If I select a region starting from Spike 1 1888 samples or less
Play range/selection : I hear only the first click, and see only Spike 1 meter


with 32 sample buffer
select a region 1873 samples starting from Spike 1, Play range/selection : I hear/see both spikes
select a region 1872 samples starting from Spike 1, Play range/selection : I only see/hear 1 spike

with 64 sample buffer

region 1852 from Spike 1 - see/hear both spikes
region 1826* from Spike 1 - only 1 spike
(*I can’t seem to drag/select a duration between 1826 & 1852 - the value just jumps)

128 sample buffer
region 1777 both spikes
region 1776


256 sample buffer
region 1649 both spikes
region 1648 only 1 spike

512 sample buffer
region 1391 both spikes
region 1390 only 1 spike

1024 sample buffer
880 samples 2 spikes
879 samples 1 spike

2056
the smallest distance I can select starting at Spike 1 is 26 samples but I still hear both spikes and see them on the track meter

Maybe irrelevant, but watching the screen, in 2056 buffer size, the play head (red line) starts at Spike 1 but flashes near spike 2 even with only 26 samples selected (Play range/selection)
Additional Information: Screenshot attached shows 1394 sample selection starting at first sound and stopping 526 samples before 2nd sound, but both meters show audio
System Description
Attached Files: Screenshot 2020-09-29.pdf (483,871 bytes) 2020-09-29 19:47
https://tracker.ardour.org/file_download.php?file_id=3844&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8299 [ardour] bugs minor sometimes 2020-07-09 15:43 2020-09-29 00:51
Reporter: iur.n Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Program aborted due to assertion in evoral/Note.cc
Description: Program aborted due to assertion in evoral/Note.cc

From logs:

ardour-6.0.9: ../libs/evoral/Note.cc:48: Evoral::Note<Time>::Note(uint8_t, Time, Time, uint8_t, uint8_t) [with Time = Temporal::Beats; uint8_t = unsigned char]: Assertion `length() == l' failed.

Next time maybe I'll catch the coredump

The Ardour is built from master
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0025079)
gregh3285   
2020-09-29 00:51   
I was able to duplicate this crash in 6.0.3, Linux, built from source. Three things seem to need to occur for this to happen. a) you need a region that's not aligned to the time measure of the composition, b) you need to have snap turned on, and c) you need to place a snapped note that ultimately would have its start occur before the beginning of the region.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8426 [ardour] bugs minor always 2020-09-28 00:50 2020-09-28 19:48
Reporter: mantis_n1oif Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: cut/copy/paste operations on automation points/lanes causes focus to be lost on the lane
Description: cut/copy/paste operations on automation points/lanes causes focus to be lost on the lane
Tags:
Steps To Reproduce: cut/copy/paste operations on automation points/lanes
Additional Information:
System Description
Attached Files:
Notes
(0025070)
mantis_n1oif   
2020-09-28 01:05   
Correction: ctrl+v does NOT cause focus to be lost. Just ctrl+c and ctrl+x
(0025076)
x42   
2020-09-28 19:48   
Here it happens when I select points explicitly. In grab mode either with rubberband selection of explicitly selecting points already de-selects the lane.
When you use a range selection, the automation-lane is implicitly selected (and remains so)

This happens before Ctrl+C/X.

Could you provide a recipe, or a short step by step description how to to produce this issue?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8428 [ardour] bugs minor always 2020-09-28 17:17 2020-09-28 19:47
Reporter: reaw Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash when opening a-* plugins
Description: Since 6.3 (which from what I understand introduced new gui to a-* plugins), Ardour crashes when I open any of them (tried with a-eq, a-compressor and a-delay).

Adding an a-* plugin works, but whenever I try to open the plugin window, it shows a black window for a few seconds, Ardour then freezes and crashes a few seconds later.
Tags: crash, plugin
Steps To Reproduce: Add a plugin like a-eq to a (midi) track, double click on the plugin to open it, wait for crash.
Additional Information: Running Ardour on latest Windows 10 Professionnal 64bit version. Using a laptop with Optimus (Nvidia 1070 and Intel chipset).

Specs:

OS: Windows 10 version 1909
CPU: Intel Core i7-8750H CPU @ 2.20GHz
GPU: NVIDIA GeForce GTX 1070
GPU2: Intel UHD Graphics 630
RAM: 8GB
Audio interface: Focusrite Scarlett 18i8 USB
System Description
Attached Files:
Notes
(0025074)
x42   
2020-09-28 18:08   
Do other openGL plugins work? e.g. x42-eq or any Harrison XT-* or overtoneDSP ones.
If not, a common issue there are outdated video drivers and updating the driver fixes this.

PS. meanwhile you can right-click > Edit with generic controls.
(0025075)
reaw   
2020-09-28 19:47   
So, I updated the NVIDIA drivers to the latest, and still crashed on both a-* plugins and the Harrison Consoles ones.

However, I made Ardour run on Intel integrated graphics (Intel UHD Graphics 630) and it works.
So there is a fix, but I'm not sure exactly why it is so.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8424 [ardour] bugs minor always 2020-09-27 03:37 2020-09-27 13:46
Reporter: alightalike Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: why does ardour re-compute the bitmap for each wave file whenever it shows up on screen instead of whenever the file changes?
Description: I don't have much to add from the summary. I can fix this myself but I would have to learn the code. Y'all know the code already. Please fix.
Tags:
Steps To Reproduce: scroll
Additional Information: n/a
System Description
Attached Files:
Notes
(0025067)
alightalike   
2020-09-27 13:34   
if I am wrong about this or **if y'all can't use this information to fix scrolling easily** please let me know it and I can learn the code so I can fix whatever the problem really is. I'm sure i can make the scroll/graphics display code run so much more smoothly. there is no good reason for scrolling to take so much time; some process must be running unnecessarily. the bitmaps for the whole session at a given zoom level can be "printed" to ram once and left there unless they need to be reprinted (if the file changes or if zoom changes).
(0025068)
alightalike   
2020-09-27 13:43   
there is no good reason for scrolling to take so much time (in my use case) I should say. for people who actually use zooming regularly it might be better the way it is. can y'all make this a setting at least? or do I just need to mod it myself?
(0025069)
alightalike   
2020-09-27 13:46   
what if the first time a bitmap is drawn at a zoom level it processes? like make the bitmap a member class of the track class with a flag for zoom that draws if the correct bitmap for the track doesn't exist? would that work?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8425 [ardour] features minor N/A 2020-09-27 07:00 2020-09-27 13:19
Reporter: iur.n Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: A better routing grid
Description: I know that there is a routing grid and maybe I am not used with it, but from my point of view it is easier when working with a patchage. I propose something like a patchage routing in Ardour (regardless of the audio engine).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025061)
alightalike   
2020-09-27 07:41   
why not just use patchage?
(0025063)
iur.n   
2020-09-27 07:46   
If Ardour will use other engine than jack, say ALSA, I don't know if an external routing program will help. I am refering to internal Ardour routing.
(0025065)
alightalike   
2020-09-27 07:50   
I honestly didn't even know it was possible to run ardour on dry ALSA. I use jack on top of alsa for music production as well as pulse on top of alsa for gnome playback. learn something new every day I guess.

this feature would be cool, I mean, I just use carla or catia for a patchbay because ardour's patchbay isn't as intuitive.
(0025066)
x42   
2020-09-27 13:19   
A "wire display" is unlikely to happen since it doesn't scale. With more than 20 wires when it becomes a visual mess.

We had planned to replace it with a connection-grid (inspired by the x-router), but these days a lot of Soundcards come with a web-interface mixer that has a matrix very much like Ardour's.
And a matrix is very efficient to connect many ports with a single mouse click + drag.


> I honestly didn't even know it was possible to run ardour on dry ALSA.

It's the preferred and recommended way since Ardour 4.0, especially if you use MIDI it's a lot less painful to get started.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8421 [ardour] features minor have not tried 2020-09-25 23:19 2020-09-25 23:19
Reporter: wargreen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Refill buffers when toggle loop play or loop range change
Description: Permit the refill of the disk buffers while toggle the loop playing or when the loop range change will be great. it can be very useful for live applications as looping in the timeline, when the sound need to be in sync with artists on the stage.

For now, if we change the loop range and state while playing, the buffers could remain and the played audio will don't be what we are supposed to hear.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8321 [ardour] features minor N/A 2020-07-19 13:43 2020-09-22 07:56
Reporter: AliMacD Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: add checkbox to "import into session after export"
Description: For sound design projects I gather together groups of (usually) short sounds across multiple tracks, mix them together then use the result as a single sound event. Bounce and Consolidate appear to always leave sounds separated per track so not what I need. The only option seems to be Export, but then I need to go and Import to bring the sound back in to use.

A simple check box to import the result back into the session (as soon as it has been created) would be great.
Tags:
Steps To Reproduce:
Additional Information: I was expecting Bounce Range to Source List to do this. I'm old enough to have started on analogue recorders where Bounce (down) meant mix several tracks down to one to make space form more recording. I guess changing Bounce to have that option or mean something different would be too much of a change for Ardour.

Again, sorry if I'm missing an option somewhere.
System Description
Attached Files:
Notes
(0025048)
AliMacD   
2020-09-22 07:56   
Even for 'normal' recording projects I always want to bring the exported files back in to look & listen, so 'import after export' option would be good for that too

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8417 [ardour] bugs minor always 2020-09-21 15:45 2020-09-21 20:12
Reporter: mvf Platform: x86_64, glibc  
Assigned To: OS: Linux  
Priority: normal OS Version: any  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Plugins can't start programs due to LD_LIBRARY_PATH
Description: In official Ardour builds, plugins can't start some OS-supplied programs because Ardour puts its own, potentially incompatible libraries on the library search path (LD_LIBRARY_PATH).
Tags:
Steps To Reproduce: Note: These are just to illustrate the user experience. The root cause is observable in any build without loading plugins.

1. Start an official Ardour build
2. Load the Surge LV2 plugin (https://github.com/surge-synthesizer/surge)
3. In the plugin editor, click the "Menu" button in the far bottom right
4. Select "Surge Manual" from the menu

Observed:
Nothing happens.

Expected:
Browser opens Surge Manual.
Additional Information: The 'ardour6' launch script sets LD_LIBRARY_PATH, putting the Ardour library directory first. OS programs are not always compatible with libraries in this path. In the repro case, Surge starts xdg-open, which on my machine tries to exec() firefox. This fails because the libatk-bridge-2.0.so.0 shipped with Ardour is missing a symbol:

$ LD_LIBRARY_PATH=/opt/Ardour-6.3.0/lib xdg-open https://ix.de
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/usr/lib/libatk-bridge-2.0.so.0: undefined symbol: atk_component_scroll_to_point
Couldn't load XPCOM.

The same root cause, albeit with a different library, keeps plugins from starting zenity [1][2]. In [3], x42 suggested clearing LD_LIBRARY_PATH in the child process. This is fine for a local workaround, but not something plugins can ship.

Suggested fix:

LD_LIBRARY_PATH should be left alone. Instead, the library search path should be linked into all Ardour-shipped ELFs. Relative paths are supported via the $ORIGIN variable. Plugin-less proof of concept on the official Ardour demo:

Observe that it doesn't work with empty LD_LIBRARY_PATH:

$ ldd /opt/Ardour-6.3.0/bin/ardour-6.3.0
        linux-vdso.so.1 (0x00007ffd38fde000)
        libardourcp.so => not found
...

Remove LD_LIBRARY_PATH handling from launcher script:

$ sudo sed -i '/LD_LIBRARY_PATH/d' /opt/Ardour-6.3.0/bin/ardour6

Patch RPATH into binaries:

$ sudo patchelf --set-rpath '$ORIGIN/../lib' /opt/Ardour-6.3.0/bin/ardour-6.3.0
$ sudo patchelf --set-rpath '$ORIGIN/..' /opt/Ardour-6.3.0/lib/backends/*.so
$ sudo patchelf --set-rpath '$ORIGIN' /opt/Ardour-6.3.0/lib/*.so*

Verify linker picks up the path:

$ ldd /opt/Ardour-6.3.0/bin/ardour-6.3.0
        linux-vdso.so.1 (0x00007fff77b11000)
        libardourcp.so => /opt/Ardour-6.3.0/bin/../lib/libardourcp.so (0x00007fc6c73e1000)
        ...

With Ardour running, observe that LD_LIBRARY_PATH is now unset, i.e. the following produces no output:

$ grep LD_LIBRARY_PATH= /proc/$(pidof ardour-6.3.0)/environ

Links:
[1] https://github.com/sfztools/sfizz/issues/416
[2] https://github.com/surge-synthesizer/surge/issues/2455
[3] https://github.com/sfztools/sfizz/issues/416#issuecomment-690908174
System Description
Attached Files:
Notes
(0025045)
x42   
2020-09-21 15:55   
This is correct and a won't fix.

As I've commented on both github issues in the past, it's hard to make to make forking realtime-safe. Furthermore plugins should be self-contained and not rely on external resources.
(0025047)
mvf   
2020-09-21 20:12   
> plugins should be self-contained and not rely on external resources.

Oh yes, they should _definitely_ do better than using zenity. But things like opening a website in the browser can still occasionally necessitate starting programs.

> it's hard to make forking realtime-safe

There's not much the host can do if a plugin is poorly written and forks all the time. But the fork/exec doesn't even have to be in the plugin itself. Even when using something like GTK directly, LD_LIBRARY_PATH can still hurt the user experience. Example: Right-click -> "Open in Editor" from a "File Open" dialog.

RPATH/$ORIGIN is intended precisely for this use case. It should be painless to deploy and would really make life easier for everyone, not least for Ardour subscribers. Ultimately _they_ are the ones affected by this. Distro builds don't ship a separate set of libraries.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8397 [ardour] bugs minor always 2020-09-06 00:55 2020-09-21 17:45
Reporter: Jose Luis Quiroga Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Operation "Selected Regions > MIDI > Remove Ovelap" does it for only ONE region.
Description: If more than one region is selected the operation
"Selected Regions > MIDI > Remove Ovelap"
does it for only one region.
Tags: rev 6.2-212-g151ca86fd6
Steps To Reproduce: 1. Draw more than one region
2. Draw a few notes on each region that ovelap.
3. Select the regions
4. RIght click over one of the selected regions and choose "Selected Regions > MIDI > Remove Ovelap"
Additional Information:
System Description
Attached Files:
Notes
(0025014)
Jose Luis Quiroga   
2020-09-06 16:12   
The most common case is tail to head overlapping. And the usual intention of the user is to have two notes NOT one long one.
Specially when importing multi-track MIDI files like symphonies.

What I find missing in MIDI policy is the policy of NOT removing sounds for the usual intention of the user when "dirty" overlapping happens.

Ardour should just make a new note for every overlapping section.
- 10 notes overlapping in a section? Make the section a new note.
- 2 notes overlapping in a section? Make one new note for that section.

So for the usual case leave three notes: one new one for the overlapping section and keep the non overlapping sections as separate notes.
Do not remove sound (it is almost never the intention of the user).
And give and additional option to remove in selected regions all notes with less than an specific length.

That will let the user sanitize any MIDI file by removing very small new notes generated by the overlapping removal in the most common head to tail case.

Thanks for all your work !
(0025046)
Jose Luis Quiroga   
2020-09-21 17:45   
These revisions STILL have the bug:
github
6.2-324-g8754090c47
date 2020-09-20

tarball in webpage
6.3
date 2020-09-06
"Hybrid"

I have not look into it but it seems just a loop limit kind of bug. Fairly straight to solve if it is that.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8267 [ardour] bugs minor always 2020-06-25 12:11 2020-09-21 10:58
Reporter: phaesler2 Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when adding insert to a track.
Description: Works fine on a newly added track in a new empty file. But crashes every time in particular sessions
Tags: 6.0, insert, mixer
Steps To Reproduce: 1) Open Session.
2) Right click over track processor box - select "New Insert".
3) Boom - Ardour crashes.
Additional Information: Affected sessions were probably converted from 5.12 to 6.0 format by v6.0-rc1. I'll try reproducing the bug in my other sessions to see if I can clarify exactly when it happens and doesn't happen and update here.

stderr log chatter and stack trace attached.
System Description
Attached Files: crash-stderr.txt (842 bytes) 2020-06-25 12:11
https://tracker.ardour.org/file_download.php?file_id=3743&type=bug
stack-trace.txt (71,935 bytes) 2020-06-25 12:11
https://tracker.ardour.org/file_download.php?file_id=3744&type=bug
Notes
(0024504)
phaesler2   
2020-06-25 12:21   
Doesn't seem to be related to being converted from 5.12 format by 6.0 or 6.0-rc1. Seems to be more related to the size/complexity of the session.

I've tested with 8 sessions, and only found two where I can create an insert without crashing. One is a new session created in 6.0, the other an old session converted to 6.0 by v6.0-rc1. They are however my smallest/simplest sessions.
(0024505)
phaesler2   
2020-06-25 12:30   
Should be "bug" not "documentation". Can I edit that?
(0025044)
phaesler2   
2020-09-21 10:58   
This bug is still happening for me in 6.3.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8416 [ardour] bugs minor always 2020-09-20 20:44 2020-09-20 20:44
Reporter: unsafelyhotboots Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI notes quantitizing and snapping to just beyond the barline
Description: It always seems to be the first note in a region, and it snaps to, if I'm not mistaken, a single frame beyond the barline, causing the note to disappear if I set the region to be its proper length.
Tags: Midi
Steps To Reproduce: Record some midi.
Quantitize it
Watch that first note disappear.
Feel sad.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8413 [ardour] features minor always 2020-09-18 16:25 2020-09-18 19:07
Reporter: mantis_n1oif Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unexpected behavior when selecting and manipulating multiple automation lanes
Description: <thingamagig> rgareus, las: If you click a track and then hold shift and click a lower track, all tracks between will also get highlighted. This is what I expect...
<thingamagig> rgareus, las: If you try to do the same thing on automation lanes, it does not select the tracks between
<thingamagig> which is what I do not expect
<thingamagig> is this a reportable bug or intended?
<thingamagig> similarly, if you have multiple tracks selected and drag the bottom divider to make them bigger, they will all get bigger
<thingamagig> this does not happen when you have multiple automation lanes selected
<las> thingamagig: i would say that it is a bug
<thingamagig> report or is this good enough to let you know here?
<las> thingamagig: report for sure
Tags:
Steps To Reproduce: <thingamagig> rgareus, las: If you click a track and then hold shift and click a lower track, all tracks between will also get highlighted. This is what I expect...
<thingamagig> rgareus, las: If you try to do the same thing on automation lanes, it does not select the tracks between
<thingamagig> which is what I do not expect
<thingamagig> is this a reportable bug or intended?
<thingamagig> similarly, if you have multiple tracks selected and drag the bottom divider to make them bigger, they will all get bigger
<thingamagig> this does not happen when you have multiple automation lanes selected
<las> thingamagig: i would say that it is a bug
<thingamagig> report or is this good enough to let you know here?
<las> thingamagig: report for sure
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8412 [ardour] bugs minor always 2020-09-17 15:25 2020-09-17 15:25
Reporter: mantis_n1oif Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Long notes written when writing many MIDI tracks to one
Description: See attached image. The bottom track is the target. The others are sources.
Tags:
Steps To Reproduce: find any midi file with multiple tracks. Connect the tracks' outputs to a new track's input and record. If yours doesn't work, I can provide a midi file on an individual basis (copyrighted song).
Additional Information:
System Description
Attached Files: Screenshot from 2020-09-17 11-23-20.png (33,062 bytes) 2020-09-17 15:25
https://tracker.ardour.org/file_download.php?file_id=3836&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8411 [ardour] bugs minor always 2020-09-17 08:03 2020-09-17 08:28
Reporter: mrshroomy Platform: Microsoft  
Assigned To: OS: Windows 10  
Priority: normal OS Version: Latest 17/9  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: No midi sound from saved midi region
Description: There is no sound from the midi track that was saved before i open the project. If i make a a new identical midi track (same vst, preset, plugins, untouched audio routing as i always do) there is sound but that midi track will have no sound if i save and re open the project again.
Tags: plugin, VST, Windows
Steps To Reproduce: 1. Record a midi region with a vst on Windows
2. Save project and verify that the midi region had sound before closing the project
3. Open project and midi region got no sound, the plugin itself won't produce any sound even though master bar is showing sound.
Additional Information:
System Description
Attached Files: 1db9478317f28abe9a7456e4ae22580726702344.png (236,250 bytes) 2020-09-17 08:09
https://tracker.ardour.org/file_download.php?file_id=3835&type=bug
png
Notes
(0025036)
mrshroomy   
2020-09-17 08:03   
This is also on new PC so it should not have to do with my old PC
(0025037)
mrshroomy   
2020-09-17 08:06   
The problem is on both ardour nightly and ardour 6.3
(0025038)
mrshroomy   
2020-09-17 08:09   
Audio produces sound fine but midi doesnt.
I can only hear the audio files when opening this project and need to make a new midi track to be able to hear that midi track only (Old ones still silent)
(0025039)
mrshroomy   
2020-09-17 08:28   
I get this error after some time and its repeated several times

BackendPort::connect (): wrong port-type

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8410 [ardour] features minor N/A 2020-09-17 04:27 2020-09-17 04:27
Reporter: idea Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [idea] Add paint tool for Paints multiple notes as you drag in lines
Description: this is a idea for make ardour better than before
https://discourse.ardour.org/t/ardour-idea-for-2021/104682

1-watch screenshot
2-when drag paint tool in piano roll make a multiple note in line
3-note number in beat dependent on Time signature
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_2020-09-17_00-03-17.png (47,579 bytes) 2020-09-17 04:27
https://tracker.ardour.org/file_download.php?file_id=3834&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8409 [ardour] bugs minor always 2020-09-16 20:06 2020-09-16 20:06
Reporter: unfa Platform: PC  
Assigned To: OS: Manjaro Linux  
Priority: normal OS Version: 20  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Shift+Z (undo view change) doesn't affect automation lanes
Description: To reproduce:

1. Create a track
2. Add an automation lane
3. Maximize the automation lane by selecting it's header and hitting F
4. Hit Shift+Z to undo that view change
5. It doesn't work
Tags: ui, view
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8382 [ardour] bugs minor always 2020-08-26 15:59 2020-09-16 14:50
Reporter: raven Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: resolved Product Version: 6.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash with "Segmentation Fault" when receiving OSC-commands
Description: Ardour 6 crashes instantly when receiving OSC messages.
Tags: 6.2, control, crash, osc
Steps To Reproduce: * Activate "Open Sound Control (OSC)" at Preferences > Control Surfaces (with e.g. Port-Mode = auto)
(* close and reopen Ardour)
(* create new empty project)
* send a command (e.g. "oscsend osc.udp://localhost:3819 /transport_play")
Additional Information: Environment:
==========
5.7.15-1-MANJARO
Ardour6.2.206 (built using 6.2-206-g34159e4594 and GCC version 10.1.0)


Log:
==========
$ ardour6
Ardour6.2.206 (built using 6.2-206-g34159e4594 and GCC version 10.1.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /etc/ardour6/system_config
Ardour: [INFO]: Loading user configuration file /home/q/.config/ardour6/config
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
Ardour: [INFO]: Using AVX optimized routines
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour6/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/q/.config/ardour6/plugin_metadata/plugin_stats
Ardour: [INFO]: Loading default ui configuration file /etc/ardour6/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/q/.config/ardour6/ui_config
Ardour: [INFO]: Loading 449 MIDI patches from /usr/share/ardour6/patchfiles
Ardour: [INFO]: Loading color file /usr/share/ardour6/themes/dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file /etc/ardour6/clearlooks.rc
Ardour: [INFO]: Loading bindings from /etc/ardour6/ardour.keys
Loading ui configuration file /etc/ardour6/clearlooks.rc
Found nothing along /home/q/.config/ardour6/templates:/usr/share/ardour6/templates
Scanning folders for bundled LV2s: /usr/lib/ardour6/LV2
Set cursor set to default
 loading from /home/q/osctest as osctest templ is_new 1 bp 2
locate took 58 usecs for 2 tracks = 29 per track
locate took 21 usecs for 2 tracks = 10 per track
locate took 22 usecs for 2 tracks = 11 per track
Speicherzugriffsfehler (Speicherabzug geschrieben)


Core-Dump:
==========
(gdb) core-file core.ArdourGUI.1000.95cb9c5e0a054655adee57eb568afa3e.2846.1598453130000000000000
[New LWP 2918]
[New LWP 2885]
[New LWP 2846]
[New LWP 2893]
[New LWP 2865]
[New LWP 2895]
[New LWP 2894]
[New LWP 2896]
[New LWP 2904]
[New LWP 2868]
[New LWP 2919]
[New LWP 2906]
[New LWP 2867]
[New LWP 2866]
[New LWP 2921]
[New LWP 2901]
[New LWP 2899]
[New LWP 2915]
[New LWP 2917]
[New LWP 2878]
[New LWP 2877]
[New LWP 2900]
[New LWP 2886]
[New LWP 2887]
[New LWP 2871]
[New LWP 2903]
[New LWP 2898]
[New LWP 2916]
[New LWP 2897]
[New LWP 2905]
[New LWP 2890]
[New LWP 2870]
[New LWP 2902]
[New LWP 2920]
--Type <RET> for more, q to quit, c to continue without paging--
Core was generated by `/usr/lib/ardour6/ardour-6.2.206'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f06d1884715 in ?? ()
[Current thread is 1 (LWP 2918)]
(gdb) thread apply all bt

Thread 34 (LWP 2920):
#0 0x00007f06d0435e32 in ?? ()
0000001 0x0000000000000000 in ?? ()

Thread 33 (LWP 2902):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc698f8cd0 in ?? ()
#2 0x0000000500000000 in ?? ()
#3 0x00007f06922977c0 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc698f8cd0 in ?? ()
#7 0x0000003000000002 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 32 (LWP 2870):
#0 0x00007f06cfa4e71d in ?? ()
0000001 0x00007f06d18847c1 in ?? ()
#2 0x000055bc6961d7a0 in ?? ()
#3 0x000055bc69627f00 in ?? ()
0000004 0x00007fffb32ed39e in ?? ()
0000005 0x00007f06d23872d0 in ?? ()
--Type <RET> for more, q to quit, c to continue without paging--c
#6 0x00007f06c5337700 in ?? ()
#7 0x000055bc6961de20 in ?? ()
0000008 0x000055bc6961de08 in ?? ()
0000009 0x000055bc6961dce8 in ?? ()
0000010 0x000055bc6961de10 in ?? ()
0000011 0x00007f06c53368a0 in ?? ()
0000012 0x00007f06c53368e0 in ?? ()
0000013 0x00007f06c53368f0 in ?? ()
0000014 0x0000000000000000 in ?? ()

Thread 31 (LWP 2890):
#0 0x00007f06cfa4e71d in ?? ()
0000001 0x00007f06d1884c9b in ?? ()
#2 0x0000000000000163 in ?? ()
#3 0x000000000fb8fe00 in ?? ()
0000004 0x000000000000000e in ?? ()
0000005 0x000000003b9ac688 in ?? ()
#6 0x00007f06ac8008e0 in ?? ()
#7 0xdd9be1b8df0da300 in ?? ()
0000008 0x0000000000000001 in ?? ()
0000009 0x0000000000000001 in ?? ()
0000010 0x000000001611c6e5 in ?? ()
0000011 0x000055bc698992d0 in ?? ()
0000012 0x000055bc698992e8 in ?? ()
0000013 0x00007f06d180c803 in ?? ()
0000014 0x0000000000003a98 in ?? ()
#15 0x000055bc698992d0 in ?? ()
0000016 0x000000001611c6e5 in ?? ()
#17 0x0000000000000000 in ?? ()

Thread 30 (LWP 2905):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc698f8cd0 in ?? ()
#2 0x0000000100000000 in ?? ()
#3 0x00007f06921147c0 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc698f8cd0 in ?? ()
#7 0x0000003000000002 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 29 (LWP 2897):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc6f482650 in ?? ()
#2 0x0000000300000000 in ?? ()
#3 0x00007f06923bce30 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc6f482650 in ?? ()
#7 0x00007f06923bce50 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 28 (LWP 2916):
#0 0x00007f06cfa4905f in ?? ()
0000001 0x00007f0640192ad0 in ?? ()
#2 0x00007f0640192ad0 in ?? ()
#3 0x0000000000000004 in ?? ()
0000004 0xffffffff00000001 in ?? ()
0000005 0x000055bc6b652740 in ?? ()
#6 0x00007f06d188a168 in ?? ()
#7 0x00007f0692ecb908 in ?? ()
0000008 0x000000016d2f4300 in ?? ()
0000009 0xffffffff7fffffff in ?? ()
0000010 0xdd9be1b8df0da300 in ?? ()
0000011 0x000055bc6d71cc40 in ?? ()
0000012 0x000055bc6b3b8e68 in ?? ()
0000013 0x000055bc6b3b8e60 in ?? ()
0000014 0x000055bc6b3b8e6c in ?? ()
#15 0x00007fffb32eb1cf in ?? ()
0000016 0x00007fffb32eb260 in ?? ()
#17 0x00007f0692ecc700 in ?? ()
0000018 0x00007f06d183ac03 in ?? ()
0000019 0x00007fffb32eb1cf in ?? ()
0000020 0x000055bc6d2f4300 in ?? ()
0000021 0x000055bc6b3b9030 in ?? ()
0000022 0x00007fffb32eb1ce in ?? ()
0000023 0x00007fffb32eb1cf in ?? ()
#24 0x00007f06d19b7d7a in ?? ()
0000025 0x0000000000000000 in ?? ()

Thread 27 (LWP 2898):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc6f482650 in ?? ()
#2 0x0000000600000000 in ?? ()
#3 0x00007f06923b0e30 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc6f482650 in ?? ()
#7 0x00007f06923b0e50 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 26 (LWP 2903):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc698f8cd0 in ?? ()
#2 0x0000000200000000 in ?? ()
#3 0x00007f06922167c0 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc698f8cd0 in ?? ()
#7 0x0000003000000002 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 25 (LWP 2871):
#0 0x00007f06cfa4e71d in ?? ()
0000001 0x00007f06d18847c1 in ?? ()
#2 0x000055bc6961db38 in ?? ()
#3 0x000055bc6952ba40 in ?? ()
0000004 0x00007fffb32ed39e in ?? ()
0000005 0x00007f06d23868c6 in ?? ()
#6 0x0000000000000000 in ?? ()

Thread 24 (LWP 2887):
#0 0x00007f06cfa4e71d in ?? ()
0000001 0x00007f06afdaa93b in ?? ()
#2 0x0000000000000000 in ?? ()

Thread 23 (LWP 2886):
#0 0x00007f06d043987c in ?? ()
0000001 0x0000000000000000 in ?? ()

Thread 22 (LWP 2900):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc698f8cf8 in ?? ()
#2 0x0000000000000000 in ?? ()

Thread 21 (LWP 2877):
#0 0x00007f06cfa4905f in ?? ()
0000001 0x000055bc69d46db0 in ?? ()
#2 0x000055bc69d46db0 in ?? ()
#3 0x0000000000000002 in ?? ()
0000004 0xffffffff00000001 in ?? ()
0000005 0x000055bc69d46c90 in ?? ()
#6 0x00007f06d188a168 in ?? ()
#7 0x0000000000000000 in ?? ()

Thread 20 (LWP 2878):
#0 0x00007f06cfa4905f in ?? ()
0000001 0x000055bc69d51a80 in ?? ()
#2 0x000055bc69d51a80 in ?? ()
#3 0x0000000000000002 in ?? ()
0000004 0xffffffff00000001 in ?? ()
0000005 0x000055bc69d505f0 in ?? ()
#6 0x00007f06d188a168 in ?? ()
#7 0x0000000000000001 in ?? ()
0000008 0x0000000169d505c0 in ?? ()
0000009 0xffffffff7fffffff in ?? ()
0000010 0xdd9be1b8df0da300 in ?? ()
0000011 0x000055bc69d487d0 in ?? ()
0000012 0x000055bc69d506e8 in ?? ()
0000013 0x000055bc69d506e0 in ?? ()
0000014 0x000055bc69d506ec in ?? ()
#15 0x00007fffb32ebe8f in ?? ()
0000016 0x00007fffb32ebf20 in ?? ()
#17 0x00007f06ae5ab700 in ?? ()
0000018 0x00007f06d183ac03 in ?? ()
0000019 0x000055bc69d505f0 in ?? ()
0000020 0x000055bc69d505c0 in ?? ()
0000021 0x000055bc69d51a80 in ?? ()
0000022 0x00007fffb32ebe8e in ?? ()
0000023 0x00007fffb32ebe8f in ?? ()
#24 0x00007f06d10981a8 in ?? ()
0000025 0x000055bc69d4c360 in ?? ()
0000026 0x00007f06d1864511 in ?? ()
0000027 0x0000000000000000 in ?? ()

Thread 19 (LWP 2917):
#0 0x00007f06cfa4905f in ?? ()
0000001 0x00007f0644193480 in ?? ()
#2 0x00007f0644193480 in ?? ()
#3 0x0000000000000004 in ?? ()
0000004 0x0000000900000001 in ?? ()
0000005 0x000055bc6f15a900 in ?? ()
#6 0x00007f06d188a168 in ?? ()
#7 0x00007f0693ffe908 in ?? ()
0000008 0x000000016d2f4400 in ?? ()
0000009 0x000000097fffffff in ?? ()
0000010 0xdd9be1b8df0da300 in ?? ()
0000011 0x000055bc6c5ea660 in ?? ()
0000012 0x000055bc6f15a9c8 in ?? ()
0000013 0x000055bc6f15a9c0 in ?? ()
0000014 0x000055bc6f15a9cc in ?? ()
#15 0x00007fffb32eae1f in ?? ()
0000016 0x00007fffb32eaeb0 in ?? ()
#17 0x00007f0693fff700 in ?? ()
0000018 0x00007f06d183ac03 in ?? ()
0000019 0x00007fffb32eae1f in ?? ()
0000020 0x000055bc6d2f4400 in ?? ()
0000021 0x000055bc6f15aa50 in ?? ()
0000022 0x00007fffb32eae1e in ?? ()
0000023 0x00007fffb32eae1f in ?? ()
#24 0x00007f06d19b7d7a in ?? ()
0000025 0x0000000000000000 in ?? ()

Thread 18 (LWP 2915):
#0 0x00007f06cfa4905f in ?? ()
0000001 0x00007f0686702590 in ?? ()
#2 0x00007f06867025b0 in ?? ()
#3 0x0000000000000001 in ?? ()
0000004 0xffffffff4c010ca0 in ?? ()
0000005 0x00007f06867026d0 in ?? ()
#6 0x00007f06d1bf0cb9 in ?? ()
#7 0x0000001900000019 in ?? ()
0000008 0xdd9be1b8df0da300 in ?? ()
0000009 0x000055bc6b29e7c8 in ?? ()
0000010 0x00007f06d1bf0d3b in ?? ()
0000011 0x000055bc6b29e730 in ?? ()
0000012 0x00007f06867026d0 in ?? ()
0000013 0x0000000000000000 in ?? ()

Thread 17 (LWP 2899):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc6f482650 in ?? ()
#2 0x0000000500000000 in ?? ()
#3 0x00007f06923a4e30 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc6f482650 in ?? ()
#7 0x00007f06923a4e50 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 16 (LWP 2901):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc698f8cd0 in ?? ()
#2 0x0000000000000000 in ?? ()

Thread 15 (LWP 2921):
#0 0x00007f06cfa1b571 in ?? ()
0000001 0x0000000000000000 in ?? ()

Thread 14 (LWP 2866):
#0 0x00007f06cfa4e71d in ?? ()
0000001 0x00007f06d18847c1 in ?? ()
#2 0x00007f06d2c8ab80 in ?? ()
#3 0x00007f06d2c8ab80 in ?? ()
0000004 0x00007f06d2c8ab98 in ?? ()
0000005 0x00007f06d295c900 in ?? ()
#6 0x00007fffb32ed41f in ?? ()
#7 0x0000000000000011 in ?? ()
0000008 0x00007f06b8000b80 in ?? ()
0000009 0x0000000000000011 in ?? ()
0000010 0x0000000000000011 in ?? ()
0000011 0x00007f06d1867430 in ?? ()
0000012 0x00007fffb32ed41e in ?? ()
0000013 0xdd9be1b8df0da300 in ?? ()
0000014 0x0000000000000000 in ?? ()

Thread 13 (LWP 2867):
#0 0x00007f06cfa4e71d in ?? ()
0000001 0x00007f06d18847c1 in ?? ()
#2 0x00007f06d2c8ab80 in ?? ()
#3 0x00007f06d2c8ab80 in ?? ()
0000004 0x00007f06d2c8ab98 in ?? ()
0000005 0x00007f06d295c900 in ?? ()
#6 0x0000000000000000 in ?? ()

Thread 12 (LWP 2906):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc698f8cd0 in ?? ()
#2 0x0000000300000000 in ?? ()
#3 0x00007f06920937c0 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc698f8cd0 in ?? ()
#7 0x0000003000000002 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 11 (LWP 2919):
#0 0x00007f06d0435e32 in ?? ()
0000001 0x0000000000000000 in ?? ()

Thread 10 (LWP 2868):
#0 0x00007f06cfa4e71d in ?? ()
0000001 0x00007f06d18847c1 in ?? ()
#2 0x00007f06d2c883f0 in ?? ()
#3 0x00007f06d2c883f0 in ?? ()
0000004 0x00007fffb32ed43e in ?? ()
0000005 0x00007f06d23429f0 in ?? ()
#6 0x0000000000000009 in ?? ()
#7 0x000055bc69499460 in ?? ()
0000008 0x00007f06c626d8f0 in ?? ()
0000009 0x0000000000000008 in ?? ()
0000010 0x726573796c616e41 in ?? ()
0000011 0x00007f06d1c14700 in ?? ()
0000012 0x72657a796c616e41 in ?? ()
0000013 0xdd9be1b8df0da300 in ?? ()
0000014 0x00007f06b8000b60 in ?? ()
#15 0x000055bc69499460 in ?? ()
0000016 0x000055bc6961a7e0 in ?? ()
#17 0x00007fffb32ed43e in ?? ()
0000018 0x00007fffb32ed43f in ?? ()
0000019 0x00007fffb32ed4d0 in ?? ()
0000020 0x00007f06c626e700 in ?? ()
0000021 0x00007f06d19b7d7a in ?? ()
0000022 0x0000000000000000 in ?? ()

Thread 9 (LWP 2904):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc698f8cd0 in ?? ()
#2 0x0000000400000000 in ?? ()
#3 0x00007f06921957c0 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc698f8cd0 in ?? ()
#7 0x0000003000000002 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 8 (LWP 2896):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc6f482650 in ?? ()
#2 0x0000000400000000 in ?? ()
#3 0x00007f06923c8e30 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc6f482650 in ?? ()
#7 0x00007f06923c8e50 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 7 (LWP 2894):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc6f482650 in ?? ()
#2 0x0000000000000000 in ?? ()

Thread 6 (LWP 2895):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc6f482650 in ?? ()
#2 0x0000000100000000 in ?? ()
#3 0x00007f0692eeae30 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc6f482650 in ?? ()
#7 0x00007f0692eeae50 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 5 (LWP 2865):
#0 0x00007f06cfa1b571 in ?? ()
0000001 0x0000000000000000 in ?? ()

Thread 4 (LWP 2893):
#0 0x00007f06d04388f4 in ?? ()
0000001 0x000055bc6f482650 in ?? ()
#2 0x0000000200000000 in ?? ()
#3 0x00007f0692f02e30 in ?? ()
0000004 0x00007f06d04389f8 in ?? ()
0000005 0x00007f06d04388a0 in ?? ()
#6 0x000055bc6f482650 in ?? ()
#7 0x00007f0692f02e50 in ?? ()
0000008 0x0000000000000000 in ?? ()

Thread 3 (LWP 2846):
#0 0x00007f06cfa4905f in ?? ()
0000001 0x000055bc69873800 in ?? ()
#2 0x000055bc69873800 in ?? ()
#3 0x0000000000000003 in ?? ()
0000004 0x0000002800000001 in ?? ()
0000005 0x000055bc695df3e0 in ?? ()
#6 0x00007f06d188a168 in ?? ()
#7 0x000055bc69f2a170 in ?? ()
0000008 0x00000001695ee3e0 in ?? ()
0000009 0x000000287fffffff in ?? ()
0000010 0xdd9be1b8df0da300 in ?? ()
0000011 0x0000000000000020 in ?? ()
0000012 0x000055bc69f2a178 in ?? ()
0000013 0x000055bc69f2a170 in ?? ()
0000014 0x000055bc69f2a17c in ?? ()
#15 0x0000000000000000 in ?? ()

Thread 2 (LWP 2885):
#0 0x00007f06d0435e32 in ?? ()
0000001 0x0000000000000002 in ?? ()
#2 0x0000000000000000 in ?? ()

Thread 1 (LWP 2918):
#0 0x00007f06d1884715 in ?? ()
0000001 0x000055bc683c1b62 in ?? ()
#2 0x00007f0638197d00 in ?? ()
#3 0x00007f0638196d50 in ?? ()
0000004 0x00007f06cfe784f0 in ?? ()
0000005 0x0000000000000006 in ?? ()
#6 0x00007f0638197cb0 in ?? ()
#7 0x00007f0638197e20 in ?? ()
0000008 0x00007f06c5624580 in ?? ()
0000009 0x00007f0638197c80 in ?? ()
0000010 0x0000000000000000 in ?? ()
System Description
Attached Files: coredump.txt (44,570 bytes) 2020-08-27 14:07
https://tracker.ardour.org/file_download.php?file_id=3812&type=bug
log.txt (22,352 bytes) 2020-08-27 14:07
https://tracker.ardour.org/file_download.php?file_id=3813&type=bug
coredump-2.txt (42,209 bytes) 2020-09-01 15:13
https://tracker.ardour.org/file_download.php?file_id=3823&type=bug
Notes
(0024966)
x42   
2020-08-26 23:29   
Sadly the backtrace is not helpful, debug symbols are missing.
I can also not reproduce this with the official version from http://ardour.org/download.html or https://nightly.ardour.org/

So this is either a distro-specific issue (maybe liblo or some other lib) or perhaps related to gcc-10.
You'll need a debug-build to help track this down. If your distro cannot provide one, perhaps check if the current nighly also has this issue (freebie/demo is fine, and can be installed in parallel to distro versions).
(0024968)
raven   
2020-08-27 14:07   
Should be more helpful this time hopefully as I figured out some stuff ;)
(0024969)
x42   
2020-08-27 17:02   
Yes, indeed. Thanks!

The relevant part is `ardour-6.2.208`

Thread 1 (Thread 0x7fe9c94d2700 (LWP 164724)):
#0  0x00007fe9ecfcc355 in raise () from /usr/lib/libc.so.6
0000001  0x00007fe9ecfb5853 in abort () from /usr/lib/libc.so.6
#2  0x00007fe9ecfb5727 in __assert_fail_base.cold () from /usr/lib/libc.so.6
#3  0x00007fe9ecfc4936 in __assert_fail () from /usr/lib/libc.so.6
0000004  0x00005640fc43215b in boost::shared_ptr<ARDOUR::PannerShell>::operator-> (this=0x7fe9c94d05f0) at /home/ardour/linux-x86_64-v5/gtk/inst/include/boost/smart_ptr/shared_ptr.hpp:734
0000005  0x00007fe9e1554e5f in OSCRouteObserver::refresh_strip (this=0x7fe95c17e240, new_strip=..., force=true) at ../libs/surfaces/osc/osc_route_observer.cc:212
#6  0x00007fe9e15528eb in OSCRouteObserver::OSCRouteObserver (this=0x7fe95c17e240, o=..., ss=2, su=0x7fe9c94d1420) at ../libs/surfaces/osc/osc_route_observer.cc:77
#7  0x00007fe9e14e07c3 in ArdourSurface::OSC::strip_feedback (this=0x564100ec9ec0, sur=0x7fe9c94d1420, new_bank_size=true) at ../libs/surfaces/osc/osc.cc:2337
0000008  0x00007fe9e14dff73 in ArdourSurface::OSC::get_surface (this=0x564100ec9ec0, addr=0x7fe95c17c300, quiet=false) at ../libs/surfaces/osc/osc.cc:2265
0000009  0x00007fe9e14dfba1 in ArdourSurface::OSC::check_surface (this=0x564100ec9ec0, msg=0x7fe95c002000) at ../libs/surfaces/osc/osc.cc:2207
0000010 0x00007fe9e15063a0 in ArdourSurface::OSC::cb_transport_play (this=0x564100ec9ec0, path=0x564100ecd050 "/transport_play", types=0x7fe95c01a331 "", argv=0x0, argc=0, data=0x7fe95c002000) at ../libs/surfaces/osc/osc.h:423
0000011 0x00007fe9e1506322 in ArdourSurface::OSC::_transport_play (path=0x564100ecd050 "/transport_play", types=0x7fe95c01a331 "", argv=0x0, argc=0, data=0x7fe95c002000, user_data=0x564100ec9ec0) at ../libs/surfaces/osc/osc.h:423
0000012 0x00007fe9ef472c11 in ?? () from /opt/Ardour-6.2.208-dbg/lib/liblo.so.7
0000013 0x00007fe9ef47524e in ?? () from /opt/Ardour-6.2.208-dbg/lib/liblo.so.7
0000014 0x00007fe9ef4757a8 in lo_server_recv () from /opt/Ardour-6.2.208-dbg/lib/liblo.so.7
#15 0x00007fe9e14d8097 in ArdourSurface::OSC::osc_input_handler (this=0x564100ec9ec0, ioc=Glib::IO_IN, srv=0x564100eca830) at ../libs/surfaces/osc/osc.cc:687
(0024984)
ovenwerks   
2020-08-30 14:15   
This bug should be fixed by commit 87f7dcc5f6fafbb57350ffcdb296b7c5b690c876. Please test.
(0024999)
raven   
2020-09-01 15:13   
Unfortunately still crashing with yesterdays nightly. Core-Dump attached.
(0025002)
ovenwerks   
2020-09-03 15:54   
Your core dump seems to indicate you have Ardour-6.2.212
The actual fix is in Ardour-6.2-213-g87f7dcc5f6
I should have specified that rather than the commit.
(0025032)
raven   
2020-09-16 09:49   
Please excuse the late reply.

I can confirm that this version fixes the crash. Issue can be closed!

Thank you! :)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7947 [ardour] bugs minor random 2020-03-27 23:12 2020-09-15 09:10
Reporter: chaot Platform: Some Other Linux  
Assigned To: paul OS: Arch Linux  
Priority: normal OS Version: unknown  
Status: assigned Product Version: 6.0-pre1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Midi note micro-shifted on region resize
Description: See the attached video. It should be self-explanatory.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0021063)
chaot   
2020-03-27 23:14   
Upload file...
(0021064)
chaot   
2020-03-27 23:20   
The file upload here somehow doesn't work for me. So, here a temporary upload somewhere else:

https://www.file-upload.net/download-13967146/midi_note_move_bug.mkv.html
(0021068)
chaot   
2020-03-28 10:51   
Sorry for the brief description. I had a long version of this report but it got lost due to reload. So, here's a bit more info.

* This issue does not happen always, but I cannot predict when it happens and when it does not.
* This micro-shift forward of the midi note happens when resizing the region at the front.
* This might be connected to some snapping issues that I observed, but I still try to figure out when/why those happen.
(0021070)
chaot   
2020-03-28 11:43   
I think I have a deterministic way to reproduce it:

1) Create a new session and add a midi track
2) Create a midi region at bar 41
3) Resize it such that the end is at bar 42
4) Add a note (quarter) at the beginning (i.e., bar 41)
5) Move region to start at bar 42
6) Resize the beginning of the region to start at bar 41
7) Resize it back to start at bar 42

Now the note was shifted very slightly to the front and thus disappears in 7).
(0021076)
paul   
2020-03-28 17:36   
After moving the region start earlier, the beat ends up with a start at 0|1|1919 .... 1 ppqn before beat 2 (within the region). Now when you move the region start back, the note start ends up 1 ppqn *before* the new region start.

Not sure yet if this is a logic error or a rounding error.
(0021077)
paul   
2020-03-28 18:17   
OK, it's a rounding error. During the "trim" that moves the start back to bar 41, the region's start gets computed (in beats) as -3.99995 rather than -4.0 earlier in time.
(0021080)
paul   
2020-03-28 21:04   
Here are some notes from debugging.

The region is ending up 1 sample to early. When dragging from bar 41 to bar 42 @ 441kHz and 120bpm 4/4 it should end up at 3616200 but finishes at 3616199

Here's some debug output from the drag:

pointer sample = 3552746 unsnapped, region pos = 3528304 lp 3528000
motion, xdelta = 0 pending pos 3528000
 qn delta 0
Dragging region(s) from 1 different track(s), max dist: 0
pointer sample = 3553962 unsnapped, region pos = 3529520 lp 3528000
motion, xdelta = 0 pending pos 3528000
 qn delta 0
pointer sample = 3554874 unsnapped, region pos = 3530432 lp 3528000
motion, xdelta = 0 pending pos 3528000
 qn delta 0
pointer sample = 3563082 unsnapped, region pos = 3538640 lp 3528000
pixels since last 35 total = 35
total samples 10640 vs 10640 @ 304
 offset = 3538640
motion, xdelta = 35 pending pos 3538640
 qn delta 0.48254
pointer sample = 3569162 unsnapped, region pos = 3544720 lp 3538640
pixels since last 37.5329 total = 72.5329
total samples 22050 vs 22050 @ 304
 offset = 3550050
motion, xdelta = 37.5329 pending pos 3550050
 qn delta 0.51746
pointer sample = 3582234 unsnapped, region pos = 3557792 lp 3550050
pixels since last 25.4671 total = 98
total samples 29792 vs 29792 @ 304
 offset = 3557792
motion, xdelta = 25.4671 pending pos 3557792
 qn delta 0.351111
pointer sample = 3592874 unsnapped, region pos = 3568432 lp 3557792
pixels since last 47.0658 total = 145.066
total samples 44100 vs 44100 @ 304
 offset = 3572100
motion, xdelta = 47.0658 pending pos 3572100
 qn delta 0.648889
pointer sample = 3607162 unsnapped, region pos = 3582720 lp 3572100
pixels since last 34.9342 total = 180
total samples 54720 vs 54720 @ 304
 offset = 3582720
motion, xdelta = 34.9342 pending pos 3582720
 qn delta 0.481633
pointer sample = 3610810 unsnapped, region pos = 3586368 lp 3582720
pixels since last 12 total = 192
total samples 58368 vs 58368 @ 304
 offset = 3586368
motion, xdelta = 12 pending pos 3586368
 qn delta 0.165442
pointer sample = 3619018 unsnapped, region pos = 3594576 lp 3586368
pixels since last 25.5987 total = 217.599
total samples 66150 vs 66150 @ 304
 offset = 3594150
motion, xdelta = 25.5987 pending pos 3594150
 qn delta 0.352925
pointer sample = 3619930 unsnapped, region pos = 3595488 lp 3594150
motion, xdelta = 0 pending pos 3594150
 qn delta 0
pointer sample = 3622666 unsnapped, region pos = 3598224 lp 3594150
motion, xdelta = 0 pending pos 3594150
 qn delta 0
pointer sample = 3623274 unsnapped, region pos = 3598832 lp 3594150
motion, xdelta = 0 pending pos 3594150
 qn delta 0
pointer sample = 3623578 unsnapped, region pos = 3599136 lp 3594150
motion, xdelta = 0 pending pos 3594150
 qn delta 0
pointer sample = 3624186 unsnapped, region pos = 3599744 lp 3594150
motion, xdelta = 0 pending pos 3594150
 qn delta 0
pointer sample = 3624490 unsnapped, region pos = 3600048 lp 3594150
motion, xdelta = 0 pending pos 3594150
 qn delta 0
pointer sample = 3624794 unsnapped, region pos = 3600352 lp 3594150
motion, xdelta = 0 pending pos 3594150
 qn delta 0
pointer sample = 3625098 unsnapped, region pos = 3600656 lp 3594150
motion, xdelta = 0 pending pos 3594150
 qn delta 0
pointer sample = 3625402 unsnapped, region pos = 3600960 lp 3594150
motion, xdelta = 0 pending pos 3594150
 qn delta 0
pointer sample = 3625706 unsnapped, region pos = 3601264 lp 3594150
motion, xdelta = 0 pending pos 3594150
 qn delta 0
pointer sample = 3626922 unsnapped, region pos = 3602480 lp 3594150
pixels since last 27.4013 total = 245
total samples 74480 vs 74480 @ 304
 offset = 3602480
motion, xdelta = 27.4013 pending pos 3602480
 qn delta 0.377778
pointer sample = 3627530 unsnapped, region pos = 3603088 lp 3602480
pixels since last 2 total = 247
total samples 75088 vs 75088 @ 304
 offset = 3603088
motion, xdelta = 2 pending pos 3603088
 qn delta 0.0275737
pointer sample = 3629050 unsnapped, region pos = 3604608 lp 3603088
pixels since last 5 total = 252
total samples 76608 vs 76608 @ 304
 offset = 3604608
motion, xdelta = 5 pending pos 3604608
 qn delta 0.0689342
pointer sample = 3629658 unsnapped, region pos = 3605216 lp 3604608
pixels since last 2 total = 254
total samples 77216 vs 77216 @ 304
 offset = 3605216
motion, xdelta = 2 pending pos 3605216
 qn delta 0.0275737
pointer sample = 3630266 unsnapped, region pos = 3605824 lp 3605216
pixels since last 2 total = 256
total samples 77824 vs 77824 @ 304
 offset = 3605824
motion, xdelta = 2 pending pos 3605824
 qn delta 0.0275737
pointer sample = 3631482 unsnapped, region pos = 3607040 lp 3605824
pixels since last 4 total = 260
total samples 79040 vs 79040 @ 304
 offset = 3607040
motion, xdelta = 4 pending pos 3607040
 qn delta 0.0551474
pointer sample = 3631786 unsnapped, region pos = 3607344 lp 3607040
pixels since last 1 total = 261
total samples 79344 vs 79344 @ 304
 offset = 3607344
motion, xdelta = 1 pending pos 3607344
 qn delta 0.0137868
pointer sample = 3632090 unsnapped, region pos = 3607648 lp 3607344
pixels since last 1 total = 262
total samples 79648 vs 79648 @ 304
 offset = 3607648
motion, xdelta = 1 pending pos 3607648
 qn delta 0.0137868
pointer sample = 3632698 unsnapped, region pos = 3608256 lp 3607648
pixels since last 2 total = 264
total samples 80256 vs 80256 @ 304
 offset = 3608256
motion, xdelta = 2 pending pos 3608256
 qn delta 0.0275737
pointer sample = 3633002 unsnapped, region pos = 3608560 lp 3608256
pixels since last 1 total = 265
total samples 80560 vs 80560 @ 304
 offset = 3608560
motion, xdelta = 1 pending pos 3608560
 qn delta 0.0137868
pointer sample = 3633610 unsnapped, region pos = 3609168 lp 3608560
pixels since last 25.1283 total = 290.128
total samples 88199 vs 88199 @ 304
 offset = 3616199
motion, xdelta = 25.1283 pending pos 3616199
 qn delta 0.34644
pointer sample = 3633914 unsnapped, region pos = 3609472 lp 3616199
motion, xdelta = 0 pending pos 3616199
 qn delta 0
pointer sample = 3634522 unsnapped, region pos = 3610080 lp 3616199
motion, xdelta = 0 pending pos 3616199
 qn delta 0
pointer sample = 3634826 unsnapped, region pos = 3610384 lp 3616199
motion, xdelta = 0 pending pos 3616199
 qn delta 0
pointer sample = 3635130 unsnapped, region pos = 3610688 lp 3616199
motion, xdelta = 0 pending pos 3616199
 qn delta 0
pointer sample = 3635738 unsnapped, region pos = 3611296 lp 3616199
motion, xdelta = 0 pending pos 3616199
 qn delta 0
pointer sample = 3636042 unsnapped, region pos = 3611600 lp 3616199
motion, xdelta = 0 pending pos 3616199
 qn delta 0
MIDI-25 SP to 3616199 allow bbt 0

If there was 1 more pixel of recorded motion, we'd be in the right place.

I find that dragging the region later then earlier again frequently (always) moves it to the right location.
(0021084)
ngeiswei   
2020-03-28 21:22   
Paul, Chaot, do you think the following branch fixes the problem

https://github.com/ngeiswei/ardour/tree/fix-beats-operators-no-test

?

This is a rebased version of https://github.com/Ardour/ardour/pull/328 minus some operator refactoring and test units.
(0021088)
paul   
2020-03-28 22:46   
It will not fix the problem.

Also, master already contains the "ticktime" work (ie. Temporal::Beats is now fundamentally a fixed point class, with the double representation being used only for particular situations.
(0021104)
paul   
2020-03-29 22:23   
while running today, i realized that there is a different angle on this problem. given that we are moving between snapped positions, there's no possible excuse for how the start of the region can end up 1 sample off the snap position. i'll look into how that happens ... there may be a fix from that approach.
(0021115)
paul   
2020-03-30 23:34   
Current master should contain a fix for this.

It turned out that rounding was not the heart of the problem here. Ardour builds a cache of region positions (start, end) for use as snap positions during drags (optional) and for alignment operations. This cache used the last sample of a region. If a region is 1 bar long, its last sample is 1 sample before the bar next bar position. During the trim drag, we ended snapping to this position, and that led to the arithmetic "errors" that ultimately compute the start fo the note as "before" the start of the region. Now, the boundary cache uses the "end" of the region - the sample after its last sample. I believe this should fix the problem.
(0021118)
chaot   
2020-03-31 22:20   
I checked with 1aae553daec91a777656bb2cef687556c79b44c6 (which is master at the time of writing) and the problem seems to occur significantly less, especially, I cannot reproduce it anymore with the recipe I stated above. However, I could still trigger the same behavior. Maybe this remaining bug is due to rounding errors? Should I try to find a recipe for reproducing this bug? Or should I enable debug output and paste the output for you, when the bug happens?
(0021119)
paul   
2020-03-31 22:47   
A recipe is more useful - the amount of debug output that I had to add to track this down was immense. The existing -D foobar stuff isn't close to adequate.
(0021120)
paul   
2020-03-31 22:48   
One "known" recipe will be if you perform the drag with snap disabled. That could lead to the region being positioned in a way that the rounding errors show up and hide the note againl.
(0024290)
PeterSutton   
2020-05-28 09:17   
Can confirm this happens regularly in both A5 and A6 (final release). I've had to stop using Ardour for work. My workflow involves lots of small MIDI regions, each of which has their first note hidden and muted.
(0025031)
gonsolo   
2020-09-15 09:10   
Is there any progress on this? I'm also hit by notes at weird locations like 338/4/959 or 356/4/1919. Is there at least a workaround or a recipe how to correct his? Quantizing doesn't work.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8404 [ardour] bugs minor random 2020-09-13 21:22 2020-09-13 21:45
Reporter: unfa Platform: PC  
Assigned To: OS: Manjaro Linux 20  
Priority: normal OS Version: KDE  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot export ranges from session
Description: This is not new, but I'm fighting this issue again more then ever.

I'm working on sound effects and often when I try to export specific regions the export process would either stall in the middle, never begin or crash Ardour all together.

Often I would start the export, stare at the progress bar doing nothing for a minute, then cancel the export and have Ardour go back to normal, only to freeze or crash a few seconds later.

What is strange is that this seems to happen only on specific regions - some CD ranges export without issues, but some require me to record the Master output to an Audio track and export a region (not a timeline range) to work around the crashing.

I'm providing an example session that I am having issues with so you can try to reproduce the problems:
https://is.gd/2pJtQR (Google Drive Download)

Some of the plug-in I used here are from AirWindows (FOSS LinuxVSTs):
http://www.airwindows.com/wp-content/uploads/NewUpdates.zip

Sometimes if Ardour crashes and has a fresh start it'll export one or two ranges, then break again.

This is a major problem.
Tags: export
Steps To Reproduce: 1. Load the provided session.
2. Try to export the "Mining Consume" CD range to a file (range starts at 00:00:29:09)
3. Hit "Export"
4. Watch the export never progressing
5. Hit "Stop Export"
6. Ardour will sometimes crash after a few seconds



Additional Information: Here's all the plug-ins used in the example affected session:

CNT | TYPE | NAME
  1 * LV2 a-Compressor stereo
  2 * VST Interstage
  8 * VST ToTape5
  1 * VST Density
  2 * LV2 Calf Flanger
  3 * LADSPA TAP TubeWarmth
  2 * Lua a-Notch Bank
  2 * LADSPA DC Offset Remover
  2 * LV2 LSP Parametric Equalizer x16 Mono
  1 * LV2 Obxd
  1 * VST ADClip7
  1 * LADSPA Hard Gate
 12 * LV2 ZynAddSubFX
  1 * LV2 IR
  1 * Lua a-Amplifier
 12 * LV2 Surge
  6 * LV2 LSP Compressor Stereo
  7 * LV2 LSP Multiband Compressor Stereo x8
  1 * LV2 Calf Envelope Filter
  8 * LV2 Noize Mak3r
 14 * LV2 LSP Parametric Equalizer x16 Stereo
  4 * LV2 Calf Reverb
  1 * LV2 Bit Meter
  2 * LV2 Calf Ring Modulator
  3 * LV2 LSP Gate Stereo
  2 * LV2 Calf Filter
  1 * LV2 LSP Sidechain Limiter Stereo
  1 * LV2 Dragonfly Early Reflections
  1 * VST ToVinyl4
  1 * LV2 MaPitchshift
  9 * Lua a-High/Low Pass Filter
  4 * LV2 Dragonfly Hall Reverb
  5 * LV2 Dragonfly Plate Reverb
  2 * LV2 Calf Multi Chorus
  1 * LV2 a-Delay
  3 * LV2 Argotlunar2
  1 * VST NotJustAnotherCD
  1 * VST Mojo
  1 * LV2 Dragonfly Room Reverb
System Description
Attached Files:
Notes
(0025029)
unfa   
2020-09-13 21:45   
I've just tested it and the problem doesn't occur when using PulseAudio backend, but it does when using JACK.

I wouldn't consider PulseAudio a replacement for JACK though, so this is still a problem.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8405 [ardour] features minor always 2020-09-13 21:30 2020-09-13 21:30
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot manually route audio to the Monitoring Bus
Description: I was trying to find a way to route a track output to session's monitoring bus, but it seems to be hard wired to only work with the master bus.
Is there an explicit reason for that?
Is there a hidden way to send other tracks to Monitoring bus as well?

My use case:

A track is used to capture Master bus output and perform editing (looping audio to export seamlessly looping files) - not possible on the master directly.
The track has Master as input, so I can record there and 1+2 system as output.
However when using the Monitoring bus, I'd prefer to send both Master and that track to Monitoring - it seems to not be possible.
The only way I see is to route the Bounce track's output to Master, which creates a feedback loop, so I'd probably need to fiddle with routing every time I want to switch between recording or playing back - which is not ideal.

I see my workflow is a bit unusual, but if Monitoring bus was available in the routing grid, I could just route my Bounce track to it and have it all work smoothly.

What do you think?
Tags: audio, monitoring, routing
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8402 [ardour] bugs minor have not tried 2020-09-12 22:20 2020-09-12 22:38
Reporter: yak Platform: amd64  
Assigned To: OS: kde neon  
Priority: normal OS Version: 5.19  
Status: resolved Product Version: 6.3  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when trying to load one specific session
Description: Suddenly Ardour crashes before it can load the session, all I get from terminal is "*** buffer overload*** terminated".
Tags:
Steps To Reproduce:
Additional Information: Same thing with version 5.12
System Description
Attached Files: Ardour_6.3.8_dbg (51,674 bytes) 2020-09-12 22:20
https://tracker.ardour.org/file_download.php?file_id=3832&type=bug
Notes
(0025028)
x42   
2020-09-12 22:37   
Crash in Yoshimi LV2 plugin, nothing we can do here

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8400 [ardour] features minor have not tried 2020-09-08 13:52 2020-09-08 13:52
Reporter: dhealey Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Faster selection of multiple export ranges
Description: Selecting multiple ranges in the stem export time span window is slow. You can only check/uncheck one range at a time. If you have 100 ranges out of 200 to export then you have to click 100 checkboxes! I propose that you should be able to highlight multiple rows clicking one row, holding shift, and clicking another row, and all rows in between will be selected. You can then right click and in a context menu select check/uncheck selection. Or something similar.

The functionality could be extended further to include CTRL mouse modifier to check/uncheck individual rows in a larger selection, and keyboard shortcuts like SHIFT+UP/DN to adjust the selection - standard list selection shortcuts basically.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8399 [ardour] bugs minor always 2020-09-06 20:36 2020-09-07 21:47
Reporter: linuxuser Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour freezes when clicking "show all automation button"
Description: When I add a midi track (no matter which synth) right click > automation > show all automation ardour freezes and doesn't respond.
Tags: freeze, GUI
Steps To Reproduce: create MIDI track > right click > automation > show all automation. Happens every time.
Additional Information: I use latest arch linux, I installed ardour from aur, then tried ardour-git (from aur) and downloaded source code and built it myself. The bug happend every time.
System Description
Attached Files:
Notes
(0025020)
x42   
2020-09-07 21:47   
With16 MIDI channels, and 128 Control-Change parameters per channel, pitch-bend etc, this will result in over 2000 automation lanes to be displayed
Ardour eventually recovers if you let it run long enough.

6.3.1 speeds this up a bit (it takes around 20 sec here to show all those lanes now), and 6.3.2 now asks if you really want to display all those lanes..

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8398 [ardour] bugs minor always 2020-09-06 09:48 2020-09-07 12:02
Reporter: martin9845 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crashing in project on load with jack_bufsize 128 and on MIDI events
Description: Ardour6.2 is crashing in project with 2 scenarios. Loading with a smaller jack_bufsize and also when playing MIDI keyboard.
Project is small (2 audio tracks and using LV2 nstrument Yoshimi, Setbfree & Black Pearl Drumkit Multi)
Crashes appear to be related to JACK MIDI issues.

Crashing occurs on the current Ardour 6.2 build. I also built from Github and experienced same result.
Ardour6.2.249 (built using 6.2-249-g1a3da7e132 and GCC version 9.3.0)

--------------------
Scenario 1
--------------------
(Load crash)

Ardour crashing on opening project when jack_bufsize 128.
Just before crash Ardour outputs to console:

Reading orgran took 1784 microseconds, final size = 96
JACK HALTED: zombified

--------------------
Scenario 2
--------------------
(Crash on MIDI keyboard events)

Ardour crashing on MIDI event from controller keyboard (Arturia Keylab essential).
This appears in the console:

ardour-6.2.249: midiport.c:317: jack_midi_port_mixdown: Assertion `out_info->event_count == num_events - out_info->events_lost' failed.
ardour-6.2.249: midiport.c:317: jack_midi_port_mixdown: Assertion `out_info->event_count == num_events - out_info->events_lost' failed.
Tags: 6.2
Steps To Reproduce: --------------------
Scenario 1
--------------------
(Load crash)
set jack_bufsize 128
Attempt to load project


--------------------
Scenario 2
--------------------
(Crash on MIDI keyboard events)

set jack_bufsize 1024
load project
play about notes on MIDI keyboard
(crash)
Additional Information: Console Output:

--------------------
Scenario 1
--------------------
(Load crash)

locate took 14866 usecs for 14 tracks = 1062 per track
Reading MIDI took 1338 microseconds, final size = 162
Reading MIDI 1 took 12334 microseconds, final size = 1666
Reading orgran took 1784 microseconds, final size = 96
JACK HALTED: zombified
Graph::engine_stopped. n_thread: 7
Graph::drop_threads() sema-counts: 0, 0, 1
[Thread 0x7fffb2f90700 (LWP 30964) exited]
[Thread 0x7fffb3011700 (LWP 30963) exited]
[Thread 0x7fffb3092700 (LWP 30962) exited]
[Thread 0x7fffb3113700 (LWP 30961) exited]
[Thread 0x7fffb3194700 (LWP 30960) exited]
[Thread 0x7fffb3215700 (LWP 30959) exited]
[Thread 0x7fffb3296700 (LWP 30958) exited]
[Thread 0x7fffc8187700 (LWP 30948) exited]
ardour-6.2.249: /usr/include/boost/smart_ptr/shared_ptr.hpp:734: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = ARDOUR::JackPort; typename boost::detail::sp_member_access<T>::type = ARDOUR::JackPort*]: Assertion `px != 0' failed.
--Type <RET> for more, q to quit, c to continue without paging--

Thread 1 "ArdourGUI" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

--------------------
Scenario 2
--------------------
(Crash on MIDI keyboard events)

locate took 52579 usecs for 14 tracks = 3756 per track
locate took 2053 usecs for 14 tracks = 147 per track
locate took 42293 usecs for 14 tracks = 3021 per track
failed to deliver sustain-zero on channel 0 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 0 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 1 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 1 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 2 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 2 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 3 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 3 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 4 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 4 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 5 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 5 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 6 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 6 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 7 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 7 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 8 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 8 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 9 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 9 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 10 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 10 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 11 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 11 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 12 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 12 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 13 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 13 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 14 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 14 on port MIDI/midi_out 1
failed to deliver sustain-zero on channel 15 on port MIDI/midi_out 1
failed to deliver ALL NOTES OFF on channel 15 on port MIDI/midi_out 1
[Thread 0x7fffc8ea2700 (LWP 31145) exited]
locate took 47364 usecs for 14 tracks = 3383 per track
ardour-6.2.249: midiport.c:317: jack_midi_port_mixdown: Assertion `out_info->event_count == num_events - out_info->events_lost' failed.
ardour-6.2.249: midiport.c:317: jack_midi_port_mixdown: Assertion `out_info->event_count == num_events - out_info->events_lost' failed.
--Type <RET> for more, q to quit, c to continue without paging--

Thread 31 "RT-main-0x7fffb" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffb38d7700 (LWP 31155)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.



System Description
Attached Files: backtrace.scenario1.txt.gz (5,912 bytes) 2020-09-06 09:48
https://tracker.ardour.org/file_download.php?file_id=3829&type=bug
backtrace.scenario2.txt.gz (5,870 bytes) 2020-09-06 09:48
https://tracker.ardour.org/file_download.php?file_id=3830&type=bug
Notes
(0025015)
martin9845   
2020-09-07 12:02   
Also .. These crashes have only occurred when JACK is running prior to launching Ardour.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8393 [ardour] bugs minor always 2020-09-04 15:17 2020-09-04 15:37
Reporter: sonicentangelment Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: feedback Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Duplication of Midi Tracks loses note data in Playlist
Description: The Duplication of Midi Tracks loses note data. In this repeatable case, the range of notes in the lower octaves were lost in the duplicated track though the same play list was used. An obvious but undesirable workaround is to manually cut and paste the note data from the old track to the new track.
Tags:
Steps To Reproduce: right click on midi track that has basic piano roll data on it and select duplicate
Select same play list as an option


Additional Information:
System Description
Attached Files: midi_zoom.png (30,475 bytes) 2020-09-04 15:36
https://tracker.ardour.org/file_download.php?file_id=3828&type=bug
png
Notes
(0025009)
x42   
2020-09-04 15:36   
Can you confirm that this is not just a vertical-zoom issue, but notes are actually deleted?
Track duplication does not include the note-range setting, so you may have to expand the visible range using the scroomer left of the piano roll.

In a quick test, I cannot reproduce this, the notes are still there and playing (just not all of them are visible after track duplication):

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8394 [ardour] bugs minor always 2020-09-04 15:21 2020-09-04 15:21
Reporter: sonicentangelment Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Copying numerous regions of midi and audio results in misplacement of regions to the wrong tracks
Description: Upon selecting and copying mixed midi and audio data, the pasting improperly places the audio data in the wrong tracks while putting the midi in the correct tracks.
Tags:
Steps To Reproduce: drag and select regions across mixed midi and audio tracks
control c
control v to the tapehead
the audio track order appears to becomes confused and the audio data is placed in the wrong track but the midi is correct
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8385 [ardour] bugs minor sometimes 2020-08-30 14:11 2020-09-03 13:50
Reporter: paulsson Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI note at beginning of region disappears
Description: MIDI note at beginning of region disappears when moving and resizing the region.
Tags:
Steps To Reproduce: 1) Set snap to 1/16 Note (This should work with other settings too).
2) Create a short MIDI region with a note at the beginning.
3) Move the region forward a bit.
4) Expand the start of the region and then shrink it back to the start of the note.

This should make the note disappear, however it doesn't always work at the first try. Try playing around with the position and size of the region.

See the attached video file for a recreation of the bug.
Additional Information:
System Description
Attached Files: midi_bug.webm (962,282 bytes) 2020-08-30 14:11
https://tracker.ardour.org/file_download.php?file_id=3818&type=bug
Notes
(0025001)
paul   
2020-09-03 13:50   
This bug has been reported several times.

It can be avoided by always working in snapped-to-grid mode. Trimming the region ends and/or creating/moving notes when not snapped to grid, and then doing the same when snapped to grid will cause this. There is no other workaround.

The problem will be fixed in the next major release of Ardour (7.0), but that is many months away.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8391 [ardour] bugs minor always 2020-08-31 20:44 2020-08-31 20:44
Reporter: TatriX Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Fit Contents on percussive track makes note range too small
Description: "Note Range" -> "Fit Contents" makes notes range tiny for MIDI track in percussive mode. See attached screenshot.

Tags:
Steps To Reproduce:
Additional Information: I'm using AwesomeWM with Nvidia proprietary driver with HiDDI screen (3840x2160) if this matters.
System Description
Attached Files: 2020-08-31-222848_1642x959_scrot.png (65,027 bytes) 2020-08-31 20:44
https://tracker.ardour.org/file_download.php?file_id=3822&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8386 [ardour] bugs minor always 2020-08-30 14:31 2020-08-30 22:28
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unexplainable MIDI note emphasis in General MIDI Synthesizer
Description: I've made a simple MIDI region and realized notes starting on the beat lines are sounding a bit different, and I don't know why.
I've tested different octaves and MIDI channels (General MIDI instruments) - this is still audible.

https://youtu.be/nlnG-E33g0A

1. Crete a 1-bar ling MIDI region with 1/16 Grid snapping on and the General MIDI Synth on.
2. Fill it with 16th notes.
3. Play it and tell me if all the notes sound the same.

Can anyone reproduce this?
Tags: Midi
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024988)
x42   
2020-08-30 21:10   
You can verify with a-midi-monitor which events are sent to a synth.

GMSynth varies samples in a round-robin fashion. If there are 4 samples for a given note, it may well sound like a small rhythm when an identical note is played repeatedly.
(This avoids the machine gun effect).
(0024989)
unfa   
2020-08-30 22:28   
I think it's not round robin, because it changes depending on the session tempo - and that shouldn't affect it. At the default 120 BPM each quarter note stands out, but with other tempos this is way different or even non-existent. It seems like an interplay between two repeating events, maybe it is some kind of timing error?
Shortening the notes didn't seem to make any difference in my case. Maybe the note release was just too long for that to make any effect.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8389 [ardour] bugs minor always 2020-08-30 18:45 2020-08-30 18:45
Reporter: mantis_n1oif Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour creates search paths automatically when you launch with a relative path to a session
Description: I kept getting search path warnings and finding search paths I didn't create inside ardour properties locations.

Finally found the issue. If you open a session like this

ardour6 /absolute/path/to/sessionName/sessionName.ardour

everything is fine.

If you are sitting in /absolute/path/to and launch with

ardour6 sessionName/sessionName.ardour

you'll get extra midi/audio search paths you didn't create.
Tags:
Steps To Reproduce:  If you open a session like this

ardour6 /absolute/path/to/sessionName/sessionName.ardour

everything is fine.

If you are sitting in /absolute/path/to and launch with

ardour6 sessionName/sessionName.ardour

you'll get extra midi/audio search paths you didn't create.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8387 [ardour] bugs minor always 2020-08-30 14:50 2020-08-30 14:50
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Note Edit Dialog is only accessible for a single note selection, even though it's contents suggest otherwise
Description: The note Edit dialog is only accessible from the right-click context menu only if a single MIDI note is selected, though it has checkboxes that suggest it was intended to work with multiple notes selected as well.

I guess this feature is incomplete?
Tags: Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20200830_164812.png (16,039 bytes) 2020-08-30 14:50
https://tracker.ardour.org/file_download.php?file_id=3819&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8065 [ardour] bugs minor always 2020-04-28 09:34 2020-08-30 10:10
Reporter: neufena Platform: Windows 10  
Assigned To: paul OS: Windows  
Priority: normal OS Version: 10  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Switching project causes Mackie Control issues
Description: Switching a project causes a Mackie Control to reset and re calibrate. This takes times time as each fader moves up and down. When this is complete the track names etc to not appear on the screen and the faders do not move to the correct locations. Changing things does get sent to the Mackie. For example playing a track the meters work but the titles still do not appear.
Tags: Mackie control
Steps To Reproduce: 1) Open a project with a Mackie Control attached/configured
2) Faders will move to correct locations, screen will display track names
3) Open a different project
4) Mackie will reset/recalibrate
5) Faders will NOT move to the correct locations and the screen will not update
Additional Information: Closing Ardour, allowing the Mackie to calibrate then opening the next project is the current workaround.
System Description
Attached Files: After opening first project.jpg (305,841 bytes) 2020-04-28 09:34
https://tracker.ardour.org/file_download.php?file_id=3639&type=bug
After opening second project.jpg (264,816 bytes) 2020-04-28 09:34
https://tracker.ardour.org/file_download.php?file_id=3640&type=bug
Notes
(0023981)
paul   
2020-04-28 13:59   
Please test out a nightly version from nightly.ardour.org (there is a free/demo version available that can be installed in parallel with your current version) to verify that this is (or is not) a problem in 6.0-rc1
(0023983)
neufena   
2020-04-28 16:15   
The nightly crashes when opening a new project so I can't verify if this is an issue. It works correctly opening the first project
(0023985)
paul   
2020-04-28 16:59   
We would like a report on that crash. It is our intention that ardour 6.0 can open older sessions.
(0023986)
neufena   
2020-04-28 17:04   
I've gone back to check and it's not crashing now. However, the main issue (Mackie) is still present.
(0024983)
neufena   
2020-08-30 10:10   
I've upgraded to Ardour 6 and this still happens. The current workaround is to close ardour, wait till the faders reset then open the next project. However I have noticed something that may help.

When opening an Ardour 5 project the faders will reset (move up and down) but if I wait at the dialog to upgrade the project to 6 until after the faders have finished moving then when the new project opens the faders are set correctly. This leads me to believe that when a project is closed some kind of shutdown or reset is sent to the Mackie then when the new project loads an initialize is sent. Because the shutdown/reset takes time the initialize is ignored. Would it be possible to test not sending a shutdown/reset when switching project or (when using a real Mackie) a delay put in before the initialize is sent when switching projects?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8369 [ardour] bugs minor always 2020-08-19 04:48 2020-08-26 04:18
Reporter: alexmitchellmus Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: CC Automation Points disappear when only 2 points.
Description: If I create automation for a midi track that contains two points, (such as a ramp from 0-127) left or right clicking on the automation header area will make the graphical points and line disappear.

Please see attached animated gif screen capture.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: cc_automation_disappears_if_two_points.gif (634,349 bytes) 2020-08-19 04:48
https://tracker.ardour.org/file_download.php?file_id=3805&type=bug
Notes
(0024953)
alexmitchellmus   
2020-08-25 07:48   
I rebuilt Ardour with `distclean` and this issue has been resolved.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8381 [ardour] features minor always 2020-08-25 16:55 2020-08-25 16:55
Reporter: _Vi Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Vertically zooming in for Automation curve editor
Description: When I edit an automation curve using visual editor (green curve), it maps lowest point to minimal value supported by a plugin and highest point to the maximal value.

This is logical, but sometimes I want to fine tune something and use only subset of the available range. This makes it inconvenient to edit the points, as it least to almost straight line. I need to resort to right_click->Edit... for almost every point.
Tags:
Steps To Reproduce: 1. Start Ardour
2. Import some track
3. Add "AM pitchshifter" plugin
4. Configure "pitch shift" parameter to use automation ("Play")
5. Go to editor and show the curve (right click -> Automation -> Processor automation -> AM pitchshifter -> Pitch shift.
6. Try to adding sequence of points like 1.0 -> 1.01 -> 1.015 -> 0.996 -> 0.992 -> 1.0.
7. Notice that values go from 0.25 to 4.0, making it tricky to fine tune values with mouse.
8. Try to zoom in the curve vertically using scrolling. No luck, only horizontal zooming. Try to explore context menus for the plugin, look at settings - no luck.
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8380 [ardour] features minor have not tried 2020-08-24 14:43 2020-08-24 14:43
Reporter: AuroraBorealis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Show values (0-100%) of Transparency sliders in the Appearance/Colors menu
Description: a small feature request
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8379 [ardour] features minor always 2020-08-23 22:03 2020-08-23 22:03
Reporter: flavor8 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Request - Hybrid audio/MIDI tracks
Description: A competing commercial DAW (BW) has the concept of a "Hardware Instrument", which (in their implementation) has a MIDI input, a MIDI output, and an audio input, all in one track. You mess around with / overdub the MIDI while monitoring audio, and then when ready bounce the MIDI to audio.

There are at least two key advantages to the setup:
1) It only takes on up slot on your control surface (as opposed to separate audio / MIDI tracks for the same device)
2) You can have a per track latency analyzer; you tell it to start watching, then press a note on the keyboard; the application can then measure latency between MIDI note being sent and audio received

I can provide screenshots of how other programs have implemented this, if useful.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8378 [ardour] features minor always 2020-08-23 13:58 2020-08-23 15:06
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add Tool hotkeys to toolbar tootltips
Description: The toolbar button tooltips don't mention tool hotkeys (Grab, Draw, Timestretch, Edit etc...).

I think it's a bit strange that these are missing here.

What do you think?
Tags: ui
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20200823_155715.png (7,412 bytes) 2020-08-23 13:58
https://tracker.ardour.org/file_download.php?file_id=3810&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2262 [ardour] features feature always 2008-05-21 07:04 2020-08-23 15:06
Reporter: puddingpimp Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: SVN/2.0-ongoing  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tooltips on toolbar should have shortcut keys where appropriate
Description: Something like "Select/Move Ranges (R)" instead of "Select/Move Ranges".

This way, a (new) user can see at a glance what the shortcut is without having to hunt for it in the menu.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020034)
noedig   
2017-09-22 10:38   
Bumping this issue. This already exists for some of the toolbar buttons, but not all, so I *assume* it should be a relatively quick and easy addition. Would be very useful for the edit mode buttons.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8350 [ardour] bugs minor always 2020-08-06 18:45 2020-08-23 15:04
Reporter: prokoudine Platform: Ubuntu  
Assigned To: paul OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Shortcuts don't show up in all tooltips
Description: Some of the tooltips in the toolbar lack shortcuts, e.g. tooltips for all tools/modes (Grab, Range, Cut etc.), edit mode, snapping etc. The transport toolbar, however, works as expected in that regard.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8375 [ardour] other minor always 2020-08-23 12:00 2020-08-23 12:00
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: UI inconsistency: new track "Position" vs "Insert duplicates at"
Description: In the Add Track/Bus/VCA dialog the option determinnig theplace to put the new tracks is labeled "Position" in the Duplicate Tracks/Busses dialog it's labeled "Insert duplicates at:".

I guess it'd be good to have this be the same so users don't get confused. Both options determine where new tracks will be put and even provide the same options to choose from.
Tags: ui
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20200823_135618.png (15,160 bytes) 2020-08-23 12:00
https://tracker.ardour.org/file_download.php?file_id=3807&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6518 [ardour] bugs major random 2015-08-18 16:09 2020-08-23 08:22
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 4.X git (version in description)  
    Target Version:  
Summary: Undo goes way back and works unpredictably. Ardour 4.2
Description: I've got a big session with tens of tracks, as I'm mixing audio for a 1.5 h long documentary film. I'm cutting input 3 tracks exported from Adobe Premiere into separate persons, situations and layers.

Ardour seems to have better and worse hours for this issue - sometimes a few times in a row when I press Ctrl+Z Ardour undos not the action I've just did, but something else I did minutes ago. The indication is that view of the session changes, the scrolling jumps, sometimes I can immediately see what was undone (it's becoming selected), sometimes I don't. This leaves me fearful, that my session has some random stuff in it that I'm not aware of and I'll need to listen to all of it again to find out (I'll have to do that anyway, but still I wish I saw no surprises there).
Tags:
Steps To Reproduce:
Additional Information: I'm using Ardour 4.2 from KX Studio repositories on a Dell Latitude 3550 laptop running KX Studio 14.04 with KDE desktop.
Attached Files: separate_regions.patch (1,019 bytes) 2015-09-09 01:16
https://tracker.ardour.org/file_download.php?file_id=2759&type=bug
Notes
(0017059)
timbyr   
2015-08-19 04:07   
I also noticed this. I've pushed a fix(bb790710) for undo/redo when changing the fade out length of a region. Hopefully this was the issue you were experiencing.
(0017079)
polosson   
2015-08-20 21:21   
Same issue here (Ardour 4.2), I wanted to report it but found this bug report, and it seems to be the same.
(0017104)
Boesmann   
2015-08-24 14:27   
(Last edited: 2015-08-24 14:28)
Same issue (4.2 official, Debian 8).
Is the fix already in the nightly build?

(0017105)
x42   
2015-08-24 16:44   
(Last edited: 2015-08-24 16:44)
bb79071 = 4.2-44-gbb79071 (after 4.2-0) and yes nightly builds are currently 4.2-62 and include this fix.

(0017141)
timbyr   
2015-09-04 13:02   
Any further feedback on this issue? have you tried a more recent build to see if this is still a problem?
(0017142)
unfa   
2015-09-04 21:32   
In nightly it doesn't seem to be a problem any more.
(0017143)
timbyr   
2015-09-05 08:31   
Ok, great. Thanks for confirming.
(0017158)
timbyr   
2015-09-08 05:28   
I'm reopening this. There is another issue with undo and splitting regions.

If I move a region and then select a range within the region and use the 's' key to split at range boundaries then undo will undo the split but also move the region back to where it was before the move.

This should be easy to fix but I don't have time to look into it right now so I'm leaving this note
(0017162)
timbyr   
2015-09-08 06:05   
Just confirming this issue, not assigning it to myself. mantis seems a bit strange sometimes.
(0017170)
timbyr   
2015-09-09 01:18   
I've uploaded a patch that although seems to fix the issue, I don't believe to be correct and it has issues.

This may need to wait until a developer with more experience/time with the undo system can look into it.
(0017192)
timbyr   
2015-09-14 12:48   
I've noticed a few other issues so I'm making note of them now before I forget.

Selecting a range and cutting it with ctrl+x and pasting with ctrl+v, then undo/redo is two steps instead of one.

Selecting a range and Cut/Copy and paste and then Undo, pasting again(after undo) causes the region to be offset from the edit point by the width of the range. undo and paste again will offset it again by another range width.
(0019229)
efenstor   
2016-12-28 19:26   
(Last edited: 2016-12-28 19:27)
This bug seemingly has resurfaced again. I guess, something in my project file makes the undo/redo engine behave abnormally. When I do recording to the track "cl. guitar", sometimes there is no undo of the last action, sometimes it undoes two last actions, oftentimes it even removes the last recording take. This is a very severe problem as it often causes good takes to be destroyed.

(0019230)
efenstor   
2016-12-28 19:29   
(Last edited: 2016-12-28 19:30)
As the "Upload File" button above does not work (APPLICATION ERROR 0000401 / database error), here is the link to the troublesome project file: https://yadi.sk/d/LRUKeQwc35bsys

(0019233)
nick_m   
2016-12-29 11:12   
i think the best way to track this down is to get a copy of the session
.history file when it happens.

ideally it would be two copies - you see the bug happen, copy the history file
hit "redo" and copy that history file using a different name.
(0024950)
valiantBlunder   
2020-08-22 23:25   
I'm seeing this issue as well. Specifically it seems like, when hitting 'undo' while the ui is trying to catch up after a recording a take, Ardour will delete the take BEFORE the one just recorded. I've attached a video of this happening in a particularly large session where the track I'm recording on has multiple regions on multiple playlists which really delays the time it takes for Ardour to catch up after recording on that track. In the video, waiting for the playhead to return to the starting point allows 'undo' to work as normal.
(0024951)
mhartzel   
2020-08-23 08:22   
Another user here. I've seen many many times Ardour undo not the last recording but the one before. These all happened on Ardour 5.12 (I haven't moved to 6.x yet). I'm glad you managed to track the issue down to session update after recording stops. My sessions also tend to have many hundreds or a few thousand regions and updating might take a while. I tend to press ctrl +z immediately after stopping recording if I decided the take was bad. Maybe Ardour is still doing something at that time and the newly recorded region has not yet registered in the "undo buffer" and a wrong take is deleted.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8373 [ardour] bugs minor always 2020-08-21 02:39 2020-08-21 02:49
Reporter: AuroraBorealis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI track's keyboard and horizontal note lines are misaligned
Description: A minor bug or visual issue: it looks like the keyboard part of a MIDI track is slightly lower than corresponding note lines, which results in an untidy appearance. I drew red lines to show this, and the red circle shows a small empty area from which the keyboard seemingly "slid" downwards and where its upmost end is supposed to be in order to align.
Tags: GUI
Steps To Reproduce:
Additional Information:
Attached Files: 01.png (10,963 bytes) 2020-08-21 02:39
https://tracker.ardour.org/file_download.php?file_id=3806&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8372 [ardour] features minor have not tried 2020-08-21 02:08 2020-08-21 02:08
Reporter: AuroraBorealis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add a save/load color theme button
Description: After spending some time in the Ardour's community, I know that the developers aren't enthusiastic about extensive theming, but neither am I, it's a humble and handy feature because it's related to already existing color theme options that can't be conveniently saved and shared by the users for no good reason, and because those power users who tinker with custom color themes do it anyway - via awkwardly editing files in a direct manner, and those who are new are discouraged from sharing them despite Ardour's great color theme functionality.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8370 [ardour] other minor N/A 2020-08-19 10:53 2020-08-19 10:53
Reporter: alextee Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: missing copyright notice on libs/ardour/sse_functions_64bit_win.s
Description: please add copyright author(s) and year(s) in libs/ardour/sse_functions_64bit_win.s
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8368 [ardour] bugs minor N/A 2020-08-18 20:28 2020-08-19 09:00
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Strict I/O not working on MIDI tracks?
Description: Please watch this quick demonstration of the problem:
https://youtu.be/x-D5NAJts_U

It seems that Strict-I/O on a MIDI track doesn't really constrain the output channel count like I thought it would.
Am I doing something wrong? is this expected behaviour?
Tags: Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0024939)
x42   
2020-08-19 04:22   
from https://manual.ardour.org/signal-routing/signal-flow/

Midi Synths. When adding a synth at a point where there is a Midi port only, the synthesizer plugin will add audio output ports, which trickle down the processor chain to all follow up plugins as inputs and in turn force their outputs to match.
(0024941)
unfa   
2020-08-19 09:00   
I see. I'd expect the Strict-I/O to make sure the port layout doesn't change after the first instrument plug-in. But maybe that doesn't make sense, because there's so many different things that could be done here that'd break... Thought if they do - the user could just switch to Flexible-I/O.

I guess Strict-I/O only works if we have also audio ports in the MIDI track - for a Vocoder plug-in for example?

Do you think it could make sense to alter it's behaviour for MIDI tracks/buses?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8367 [ardour] other minor N/A 2020-08-18 18:27 2020-08-18 18:27
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Rename "Sound MIDI notes as they are selected in the editor" to something shorter
Description: I think the "Sound MIDI notes as they are selected in the editor" label is quite long and unwieldy, and I think I've got a few ideas of what it could be named instead:

1. "Audible MIDI editing feedback"
2. "Play touched MIDI notes"
3. "Audible MIDI note editing"

Additionally a tooltip could say:

"When enabled, makes Ardour play MIDI notes that are being drawn, selected or manipulated. When disabled - editing MIDI notes provides no audible feedback."

What do you think?

Tags: ui
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8262 [ardour] bugs minor random 2020-06-20 14:45 2020-08-16 10:28
Reporter: Fruit tree Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes every time I stop playback (on a specific project)
Description: It has happened several times that at some point, a project seems to enter a state where it keeps crashing Ardour within a minute after I open it.
Earlier I did almost nothing before it happened so it didn't bother me.
This time, I don't have so much either - I was just playing around with MIDI chords when it suddenly crashed. But figured I should file a bug report because this is rather fatal bug for me - can't have projects randomly "die".
The first time it crashed, it was while I was playback-ing those chords while simulatneously using my MIDI keyboard to control a Helm instance.
Every time I try to open the project thereafter, it crashes when I stop playback (after first having started it of course).

I had to upload the project folder, since it was 400MB http://www.mediafire.com/file/2vukjcpks59684y/18-jun.zip/file
Tags:
Steps To Reproduce: It's rather random, but seems to be related to MIDI. I think most of the times it happened I did at some point some MIDI recording, and afterward some MIDI editing.
Additional Information:
System Description
Attached Files:
Notes
(0024487)
Fruit tree   
2020-06-20 14:46   
I said reproducibility is "random", with which I meant on a per-project basis.
I personally _always_ get the same crash on the attached project, and I wonder if it's reproducible with said project for anyone else.
(0024931)
Fruit tree   
2020-08-16 10:10   
This keeps happening on newly created projects.
It is a problem per block of MIDI recorded. When I record some MIDI and get this bug, it will resolve if I delete that MIDI block again.
Currently using ardour-git from AUR: version 6.2.r160.g0ddaf3fe68-1
(0024932)
Fruit tree   
2020-08-16 10:21   
BUT if I remove the MIDI block and immedeiately start and stop playback it will crash. I need to remove the MIDI block ,then restart Ardour - then it will not crash.
(0024933)
Fruit tree   
2020-08-16 10:25   
I then tried to record again, but I get the same problem again. Ardour crashes when I stop playback... :( It seems like just the entire project is just corrupt now? This happens OFTEN on almost all projects I have!! It's really makes Ardour unusable to me and I cannot believe that I am the only one who has it??

It does not depend on instruments or plugins btw.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8360 [ardour] bugs minor always 2020-08-12 02:12 2020-08-13 02:55
Reporter: jumase Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Metronome bad behaviour at 130, 260, 520 BPM: one click is missed
Description: When setting tempo at 130 BPM (or n*130 BMP) it won't reproduce the second beat of the first bar. At 260 BPM the third beat will be omited. And the first beat of second bar at 520 BPM.
Tags:
Steps To Reproduce: Set tempo at 130 BPM. Enable metronome. Play from the beginning. The second beat won't sound.
Additional Information: I'm using the built-in default sounds on a version downloaded from ardour.org
System Description
Attached Files:
Notes
(0024922)
jumase   
2020-08-12 02:37   
That only happens when using JACK. Using ALSA it works as expected.
(0024926)
wargreen   
2020-08-13 02:55   
I've also got this issue with alsa, on the 3th beat. I don"t remember the tempo. Only on the second bar.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7461 [ardour] other minor always 2017-08-30 11:20 2020-08-09 19:08
Reporter: unfa Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: Maverick  
Status: new Product Version: 5.10  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [Workflow] Consolidating MIDI regions trims the end of the resulting region
Description: I found that Consolidate region works a bit differently on Audio and MIDI regions.

For audio - I get a region that is exactly as long as my selected region.
For MIDI - the end of the region is automatically trimmed to end with the last contained note.

I'd personally prefer to not have the resulting region trimmed, because when I consolidate a few bars (precisely snapping region boundaries to the bar lines), to then duplicate them with Shift+D. I need to correct the length before duplicating, or my duplicates will be offset from the bar grid and not fit the beat of my music.

If Consolidate didn't trim, but just put the end of the new MIDI region where the original region selection was - I'd have one step less to do with such operations.

Do you think that's a good idea? Or maybe someone's workflow would break if that was changed?

To trim or not to trim?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20200809_173111.png (32,211 bytes) 2020-08-09 15:36
https://tracker.ardour.org/file_download.php?file_id=3801&type=bug
png
Notes
(0024910)
unfa   
2020-08-09 15:36   
Bump!

I think the end truncation is not expected behaviour - with Audio regions, Consolidate Range doesn't truncate end silence, so I expected the new region to have the same extents as my selected range when triggering "Consilidate range".

I'm attaching a screenshot - the tracks represent
1. Input
2. Operation
3. Results

Truncating silence could be a nice function on it's own both for audio and MIDI regions though!

What do you think?
(0024912)
x42   
2020-08-09 19:08   
I do not know what motivated this, but this has a nice side-effect that in case there are no events in the range, empty regions are not created.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8357 [ardour] features minor always 2020-08-09 12:45 2020-08-09 12:45
Reporter: unfa Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: No way to reverse MIDI regions
Description: I'd be great to have the reverse operation work on MIDI regions, just like it works on audio regions.

Right now hitting Alt+3 with MIDI regions selected does nothing.
Tags: Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8356 [ardour] other minor always 2020-08-09 12:23 2020-08-09 12:23
Reporter: unfa Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Don't Continue" option for Tempo Change doesn't seem to do anything
Description: I've found this option, but I have no idea what it's supposed to do. I would expect tit to "revert" the "Continue" option which make the current tempo marker identical to the previous one on the timeline.

I'm not sure what it's supposed to do - it doesn't seem to do anything.
Tags: tempo
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8355 [ardour] bugs minor always 2020-08-08 23:21 2020-08-08 23:21
Reporter: unfa Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Shift + Z doesn't properly undo maximizing an automation lane with F
Description: I think I've found an inconsistency in the Shift+F key combination behavior.

If used on Tracks it works in a certain way, but when used on Automation lanes, it fails to do the same thing.
Tags: GUI
Steps To Reproduce: To reproduce:

1. Create a track with a visible automation lane
2. Select the automation lane header
3. Hit F to maximize the automation lane vertically.
4. Hit Shift+Z to undo that view change
5. See that the automation lane is still huge.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8353 [ardour] features minor always 2020-08-08 12:21 2020-08-08 15:29
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI Control fixes
Description: Currently after learning a MIDI Control (via Shift+RMB) - that means assigning a physical MIDI CC to a fader or automation parameter in Ardour - there is no way to:

- review or modify the assignement
- remove the assignement (the only way is to disable General MIDI Control all together)
- tell that it's there at all, besides moving a knob and seeing a control change (which may not always be possible)
Tags: Midi, MIDI control
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024906)
paul   
2020-08-08 15:29   
Generally speaking, MIDI Learn is intended for short-lived, dynamic binding. MIDI Binding Maps are more powerful and more appropriate for setting up long-lived associations between MIDI controllers and parameters inside Ardour.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8354 [ardour] bugs minor always 2020-08-08 13:55 2020-08-08 13:55
Reporter: unfa Platform: GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: The Generic MIDI Control Protocol Settings dialog resets selected device after disabling the protocol
Description: A strange thing I've encountered is that whenever I disable my Generic MIDI control surface, if I turn it on again, I have to select the MIDI device once again - I expected it to hold the previous value, but it resets it to "Disconnected" even if nothing on the hardware side changed.

Is this intentional? I find it a bit weird.
Tags: Midi, MIDI control
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20200808_155122.png (63,347 bytes) 2020-08-08 13:55
https://tracker.ardour.org/file_download.php?file_id=3799&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7913 [ardour] bugs minor always 2020-02-25 22:41 2020-08-07 17:24
Reporter: mantis_n1oif Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 6.0-pre0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Automation markers aren't fully respected. Plugin is enabled when it should be disabled.
Description: If you add a plugin to a strip and then add automation for bypass, you can place the playhead such that the automation is not respected/acted upon.
Tags:
Steps To Reproduce: Create session with audio track.
Add any plugin.
Add automation points for enabling/disabling the plugin.
Place the playhead just before the plugin should automate on (but should still be off).
Plugin will be on.
Additional Information:
System Description
Attached Files: playhead_disrespect.jpg (178,570 bytes) 2020-02-25 22:41
https://tracker.ardour.org/file_download.php?file_id=3514&type=bug
jpg

Screenshot from 2020-08-07 13-23-46.png (93,921 bytes) 2020-08-07 17:24
https://tracker.ardour.org/file_download.php?file_id=3798&type=bug
png
Notes
(0020978)
x42   
2020-02-25 23:22   
Is there a latent plugin before the automated plugin? In that case the given plugin needs to be enabled early during playback.

That would explain what you're seeing. Although It's still a bug that it's enabled when not rolling.
(0020979)
x42   
2020-02-25 23:26   
Can you try: Preferences > Appearance > Toolbar > Display Latency Compensation Info
Then in the toolbar enable "Disable PDC" -- does that work-around?

A mixer window screenshot showing the plugin-setup may be helpful.
(0024903)
mantis_n1oif   
2020-08-07 17:24   
Confirming that this still an issue as of 6.2.21. I tried the steps in your last comment and still get the same thing.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8349 [ardour] bugs minor sometimes 2020-08-05 20:39 2020-08-05 20:55
Reporter: samthursfield Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unmuting a region caused it to disappear
Description: I've had various problems with this session, some of them I can't reproduce when I go to report a bug, but this strange issue occurs every time. It may be indicative of some deeper issue.
Tags:
Steps To Reproduce: 1. Open the attached .session file (in safe mode)
2. Scroll down to 'vocals spare rhode' track
3. Edit -> Undo mute operation
4. Region 'Main vocals 4.90' will disappear completely
5. Edit -> Redo and it appears again.

In one case, repeating these steps triggered a crash. Maybe it would reproduce with MALLOC_PERTURB_= set in the environment - i didn't have time to check that.
Additional Information:
System Description
Attached Files: ardour-bug-mute-operation-deletes-track.ardour.gz (167,310 bytes) 2020-08-05 20:39
https://tracker.ardour.org/file_download.php?file_id=3794&type=bug
ardour-bug-mute-operation-deletes-track.history (13,636 bytes) 2020-08-05 20:39
https://tracker.ardour.org/file_download.php?file_id=3795&type=bug
Notes
(0024897)
samthursfield   
2020-08-05 20:52   
Video
(0024898)
samthursfield   
2020-08-05 20:55   
Sorry, I tried to attach a 1.2MB video file, but the bug tracker doesn't seem able to accept it.
I put it on Youtube instead: https://www.youtube.com/watch?v=qMu2G155TCQ&feature=youtu.be

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8348 [ardour] bugs minor always 2020-08-05 16:32 2020-08-05 16:36
Reporter: samthursfield Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cut and paste causes region layering to change
Description: Ordering of layers can change when they are moved using cut and paste.
In practice, this means a user might choose 'vocals take 4' while editing their track, but during an unrelated edit operation, maybe 'vocals take 1' is moved to the top without the user noticing or wanting that.
Tags:
Steps To Reproduce: Record 3 regions in the same track. Note which one is on top.
Select them with CTRL+SHIFT+E, then use ctrl+x to copy them.
Move the playhead and use ctrl+v to paste them.
The region on top may now be a different region.
Additional Information:
System Description
Attached Files: ardour6.2 cut paste testcase.ardour (101,264 bytes) 2020-08-05 16:32
https://tracker.ardour.org/file_download.php?file_id=3793&type=bug
Notes
(0024896)
samthursfield   
2020-08-05 16:36   
I recorded a video of the issue as well. The bugtracker doesn't accept the 1.8MB .webm file though. If the video will be useful I could upload it as a private Youtube video and share the link.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8347 [ardour] bugs minor always 2020-08-05 10:18 2020-08-05 10:18
Reporter: mantis_n1oif Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: a-Fluid synth chorus feature doesn't work
Description: I use a-Fluid synth quite a bit but never had a need to use its chorus features until just now. For the life of me, I can't hear any difference, even when I swing the settings wildly from side to side. When I use gxChorus or rkr Flanger Chorus, I hear the difference immediately.

Am I going crazy or is it simply not doing anything? (Yes, I have the chorus checkbox checked.)
Tags:
Steps To Reproduce: Create midi track.
Add some notes
Add a-Fluid Synth
Add an sf2 file to a-Fluid Synth
Try the chorus feature
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8346 [ardour] bugs minor always 2020-08-04 21:55 2020-08-04 21:55
Reporter: Ardeshir81 Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Removing everything related to `Minathon synth` crashes the program
Description: HI!
I build Ardour from source, on master branch, just updated it, (5 Aug 2020), I installed Minaton Synth (cloned it today, 5 Aug 2020, on master branch)
I do not know if I installed it incorrectly, or Minaton itself has bugs, by the way no sound came out. I tried it on 2 tracks.
That does not matter.
The problem is I cannot delete Minaton Synth, nor the plugin, neither the tracks using it.
As soon as I click remove/delete program crashes and exits and these logs are printed in console:

Minaton shutting down........
PluginWindow deleted for 0x56326542e400
The program 'ardour-6.2.6' received an X Window System error.
This probably reflects a bug in the program.
The error was 'RenderBadGlyph (invalid Glyph parameter)'.
  (Details: serial 1945350 error_code 146 request_code 139 minor_code 22)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

watched PID no longer exists - releasing device.

// ========================================
// ========================================
// ========================================

Unfortunately, I could not run ardour with --sync. I always run it using `ardev` and doing `ardev --sync` did not change the error.
Tags:
Steps To Reproduce: - update ardour on master branch
- waf configure, waf
- clone https://github.com/thunderox/Minaton
- build mihttps://github.com/thunderox/Minatonnaton too
- `ardev`
- open an existing project
- add 2 tracks each one having one Minaton
- save project
- quit project
- re-open project
- try deleting tracks/Minaton
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7107 [ardour] features minor have not tried 2016-11-12 22:27 2020-08-02 18:36
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make it easier to create unlinked MIDI region copies
Description: I'd love to be able to create an unlinked MIDI region copy with Ctrl+Shift drag.


I find that in my workflow linked MIDI regions cause more trouble than good, I'd love to have an easy what to make unlinked copies, without having to menu-dive for every unlinked copy I need.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018944)
x42   
2016-11-12 22:33   
Session > properties > Misc allows you to set the default
(0018951)
timbyr   
2016-11-13 11:59   
I agree that there should be a key modifier to explicitly make a linked/shared copy of a region, or I guess alternatively an unlinked copy (making it the opposite of the default may be confusing).

Also a visual indication that a region is a linked/unlinked copy would be useful IMO.

AFAICT Cubase does a normal copy with Alt and drag and a linked copy(what they call a shared copy) with Alt+Shift and drag.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8345 [ardour] features minor always 2020-07-31 12:04 2020-07-31 12:04
Reporter: AliMacD Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: enhance Selected Regions / Bounce naming
Description: If I use Rhythm Ferret, for example, to divide a file into many regions, then want to bounce them so that they are available in the Sources list, rather than naming them one by one, could the Bounce dialogue offer something like the formula in the Export dialogue? Simple addition of numbers _1, _2, _3 etc would be fine.

(I'm using 6.2.120 because of the excellent bounce naming which has been added since 6.2)
Tags: editor list
Steps To Reproduce: Select a number of regions
right-click
selected regions
Bounce (without processing)
type name
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6083 [ardour] features minor have not tried 2014-12-24 01:27 2020-07-30 08:52
Reporter: naught101 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Visual indication that midi patterns are linked
Description: When editing MIDI patterns, it's easy to forget that a commonly used pattern is liked to multiple other copies. This makes it possible to accidentally edit a lot of instances of a pattern, when only intending to edit one instance. If there was a simple visual indication of whether a pattern has other copies active in the track (i.e. not just sitting in the region bin), this would mitigate the problem a lot. An idea for an indicator is attached.

It might also be nice for the indicator to be interactive - e.g. click it to unlink, although perhaps that action would be too easy.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Ardour_linked_patterns.png (2,934 bytes) 2014-12-24 01:27
https://tracker.ardour.org/file_download.php?file_id=2487&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7259 [ardour] features minor have not tried 2017-03-03 20:22 2020-07-30 08:52
Reporter: rghvdberg Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Different color for linked and unlinked midi regions
Description: In order to better distinguish between linked and un-linked regions it would be good to give them each a different color or tint.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019462)
timbyr   
2017-03-04 03:26   
I would agree that a better visual indication is needed to distinguish linked and unlinked MIDI regions, but I'm not sure I agree that using a different color is the best way to represent this. Other DAW's usually represent shared/linked copies with some sort of icon on the event/region AFAIK.
(0019601)
rghvdberg   
2017-04-07 11:29   
with colours you'll be able to spot the linked regions much faster then a tiny icon
also when you zoom out .. where are the icons then ?

when I have time (never btw) I'll do a mock-up
(0019793)
cooltehno_bugs   
2017-06-15 08:35   
@rghvdberg, look here:

 https://www.youtube.com/watch?v=OOXqQxPnLso&feature=youtu.be

The linked regions could belong to different tracks and I think in this case the colorizing of linking regions could make a confusion.

I had made a feature request about highlighting linked regions few months ago:

http://tracker.ardour.org/view.php?id=7112
(0019794)
cooltehno_bugs   
2017-06-15 08:38   
Also, a similar video:
https://www.youtube.com/watch?v=JN1cCO4S7Ac

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7842 [ardour] features minor have not tried 2019-11-04 10:24 2020-07-30 08:50
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Visually discriminate MIDI regions that are linked copies to avoid user confusion
Description: I thought it'd be good to have a visual clue in the editor that'd help show which MIDI regions are linked copies, and which are not.

I initially thought about something like a chainlink symbol added in a corner, but I'm not sure that'll work.

Maybe an underline, italics or bold font for the region's name as drawn in the timeline?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8343 [ardour] other minor always 2020-07-29 17:38 2020-07-29 17:38
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Enable Editor Mixer by default
Description: I use the Editor mixer (Shift+E) 100% of the time I work with Ardour.

However a fresh Ardour installation will not have it on.
I think it's pretty indispensable, as the user will have to use it (or the full-blown mixer) to assign track inputs to record anything (audio or MIDI).

Maybe it'd be a good idea to have it enabled by default?

What do you think?
Tags: Defaults, Editor Mixer, mixer
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8339 [ardour] bugs minor always 2020-07-27 20:57 2020-07-27 21:23
Reporter: Cicalone Platform: Microsoft  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: The MIDI file is not imported correctly
Description: When the MIDI file is imported, the MIDI regions are not drawn correctly and no sound is played when the timeline reaches the "incorrect" part.
Tags: Editor, GUI, Import, Midi, region
Steps To Reproduce: Import the MIDI file and select "Use MIDI Tempo Map"
Additional Information:
System Description
Attached Files: sotc_-_a_despair_filled_farewell.mid (23,933 bytes) 2020-07-27 20:57
https://tracker.ardour.org/file_download.php?file_id=3788&type=bug
The_Opened_Way.mid (26,663 bytes) 2020-07-27 21:23
https://tracker.ardour.org/file_download.php?file_id=3789&type=bug
Notes
(0024832)
Cicalone   
2020-07-27 20:59   
Tested on Ardor 6.2.112
"Thursday Afternoon"
(rev 6.2-112-g44fc824)
Intel 64-bit
(0024833)
Cicalone   
2020-07-27 21:23   
The same problem is also present on this other MIDI file

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8340 [ardour] bugs minor always 2020-07-27 21:05 2020-07-27 21:05
Reporter: derwok Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Track Rename not possible via double-click if Track is in record mode
Description: see title
Tags:
Steps To Reproduce: Editor is active view. I have a track with audio.

Normally I can double click the track name (default; "Audio") so that I the track name get editable (selected text, blinking cursor) and can enter a new track name, press ENTER to make it persistent.

I observed that sometimes my double clicks on the the track name has no effect.
I could not rename the track. It took me some days to figure out...

=> When the track is engaged for recording (Shift+B) its not possible to rename the track.
Double click is ignored. Nothing happens.
Wow! Very surprising!

Insecure if this is a bug or a feature?
If its a feature, then a message box explaining "Renaming not possible, if track is in record mode" would be nice.
Additional Information: The same is true for MIDI tracks.
(Of course no bug on audio busses, as there is no record mode here) ;-)
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8323 [ardour] bugs minor always 2020-07-20 09:11 2020-07-27 19:27
Reporter: rjred Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash at tempo change marker
Description: I have a session with MIDI and audio data. There are tempo changes to create a rallentando, then a return to the original tempo and a further rallentando at the end. Initially, this worked OK, but now the session will crash consistently at the point in playback or export where it hits the first tempo change marker.
I have a backtrace, but as the session has audio, I can't provide that. I will attempt to reproduce the issue in a MIDI-only session and provide that if successful.
Tags: crash, tempo change
Steps To Reproduce: Crash occurs during normal session playback or audio export. The attached backtrace was from playback in session.
Additional Information:
System Description
Attached Files: Backtrace_CrashAtTempoMarker_Ardour6.2.txt (27,191 bytes) 2020-07-20 09:11
https://tracker.ardour.org/file_download.php?file_id=3780&type=bug
Backtrace_CrashAtTempoMarker_Ardour6.2.112-dbg.txt (48,677 bytes) 2020-07-27 16:27
https://tracker.ardour.org/file_download.php?file_id=3787&type=bug
Notes
(0024812)
paul   
2020-07-26 02:23   
It would be great if you could replicate this with a debug build. There are free/demo debug builds available at nightly.ardour.org

The backtrace from a non-debug build provides only vague hints about where the crash is occuring.
(0024822)
rjred   
2020-07-27 16:27   
Certainly. New backtrace from the 6.2.112-dbg build attached.
(0024829)
paul   
2020-07-27 19:27   
Hmm, nothing particular obvious there, alas.

If you succeed at creating a session with this behavior that you feel comfortable sharing, I'll be happy to take a deeper look.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8319 [ardour] bugs minor always 2020-07-19 04:24 2020-07-27 11:52
Reporter: don3 Platform: Redhat  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Remove Last Capture after deactivating a channel removes more than last capture
Description: Ardour version: 6.2.33-dbg (published nightly build)
Originally found on 5.12
Fedora + CCRMA

See procedure below.
Tags:
Steps To Reproduce:  1: Create a new session.
 2: Add a few new audio tracks. I used 5, but 2 or 3 would probably be enough.
 3: Move playhead to desired starting place. (I used 10 seconds, but it probably doesn't matter.)
 4: Arm tracks 1, 2, and 5 for recording, and the master record.
 5: Record a few seconds of audio (silence is fine) on the 3 tracks, then stop the recording.
 6: Disarm track 5.
 7: De-activate track 5 in the Editor List.
 8: Arm tracks 3 and 4. Move the playhead to a new starting place (e.g, 00:20 -- probably not necessary).
 9: Record a few more seconds of audio, then stop the recording.
10: Edit > Remove Last Capture
11: Answer Yes in the "Destroy last capture" dialog,

Expected result: New regions and audio files from the second capture (in tracks 1, 2, 3, and 4) should be removed.

Actual result: The newly captured regions *and* the region in track 5 from the previous capture are blown away!
Additional Information:
System Description
Attached Files:
Notes
(0024809)
paul   
2020-07-26 02:13   
Replicated the instructions given above with 3 tracks ... problem did not occur.
 
Replicated them more precisely with 5 tracks ... problem did not occur.
(0024820)
don3   
2020-07-27 11:52   
Hmm, it's very repeatable for me, but that was on two rather old production systems. I'm working on bringing up a new system -- when that's ready (hopefully later this week), I'll try it there.

A couple more details I didn't mention, because I didn't think they were relevant: Both systems use Jack, and both have audio interfaces with more channels than a typical on-board sound card might have. One has an M-Audio Delta 44 PCI card, the other has a USB link to a digital mixer with 32 channels each direction.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8336 [ardour] features minor N/A 2020-07-26 11:18 2020-07-26 11:18
Reporter: dhealey Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Import markers
Description: It would be very helpful, especially when moving sessions from another DAW into Ardour, to be able to import markers from MIDI files, and cue markers from audio files as location markers in Ardour.

We had a brief discussion about importing from MIDI files recently - https://discourse.ardour.org/t/importing-markers/104413/6
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8310 [ardour] other minor always 2020-07-14 07:08 2020-07-26 02:19
Reporter: iur.n Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Don't show small control things
Description: Maybe there would be a good idea not to show the automation control points, lines, when the region is such small that editing automation is impractical and their viewing gives no practical info too.

There other similar things that are too small that becomes impractical to edit or view. Probably some of them must not be shown or their display to be changed for improving the overall view.
Tags: ui
Steps To Reproduce:
Additional Information:
Attached Files: automation.png (30,830 bytes) 2020-07-14 07:08
https://tracker.ardour.org/file_download.php?file_id=3775&type=bug
png
Notes
(0024811)
paul   
2020-07-26 02:19   
where are the "small things" you are referring to in that screenshot?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8315 [ardour] bugs minor have not tried 2020-07-17 17:30 2020-07-26 02:18
Reporter: muzikermammoth Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: In the editor list, don't disable spacebar for starting play transport
Description: This is probably a feature rather than a bug, but:

In ardour, shift-L brings up the editor list where a few other tabs exist. When this pane has focus, spacebar is used to toggle the last button pressed instead of the starting the transport. This has led to instances where the master track or some other track is muted accidentally when trying to start the transport. Is there a reason why spacebar is remapped to some other function in this case?

The other observation is that when this panel has focus, the user has no visual way of knowing that this is the case, which leads to wondering why the spacebar has been disabled. Just pointing out from a user experience perspective, any changes in shortcuts or way of working based on which mode the software is in should have some kind of visual cue.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024810)
paul   
2020-07-26 02:18   
This is a very legitimate request/bug report. However, fixing it will be a lot more complex than you probably imagine. We give focus to the treeview that is used in most of the those tabs (notably the Tracks/Busses one) so that the user can use the keyboard to navigate there, change names and so on and so forth. The GUI toolkit uses the spacebar to toggle toggleable controls as a default use of the spacebar in a treeview like this. Stealing away *just* the spacebar so that it doesn't perform what the GUI toolkit would normally do with it is non-trivial, but I will look into it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8335 [ardour] bugs minor always 2020-07-25 23:24 2020-07-25 23:26
Reporter: Bleuzen Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Frozen tracks do not output audio until ardour is restarted
Description: When I freeze an audio track and then play it, the frozen track does not output any audio. After restarting Ardour, it does output the audio.
Tags: 6.2, track freeze
Steps To Reproduce: 1) Make a new audio track
2) Record something and add some effects
3) Freeze the track
4) Play the song (frozen track will be muted even if it isn't set to be muted)
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8330 [ardour] bugs minor have not tried 2020-07-24 18:31 2020-07-25 14:04
Reporter: wargreen Platform: X86_64  
Assigned To: OS: Debian  
Priority: normal OS Version: SID  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: List of Ranges in Places windows is not alway refresh when removing a range
Description: When removing the lasts ranges via the Places (Emplacement in french) window, sometime the list is not refresh, so the range is removed but not in the list.
Tags:
Steps To Reproduce: Add lot of ranges
Open the Places (Emplacements) windows
Remove ranges (the last one here) until the bug happen
Additional Information:
System Description
Attached Files:
Notes
(0024806)
wargreen   
2020-07-25 14:04   
In english, it's in the Locations window.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8316 [ardour] bugs minor have not tried 2020-07-18 13:45 2020-07-23 16:24
Reporter: unfa Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: instrument plug-ins with audio inputs are not listed in the Add Track/Bus/VCA instrument plug-in list
Description: Creating a MIDI track with the Surge synthesizer is not as easy as with say - Helm or Zyn-Fusion.

Surge has aux audio input for vocoder effect, but I think Ardour gets thrown off by this and doesn't include it in the instrument list, even though the plug-in is available in the
Tags: Midi, PLugins
Steps To Reproduce: 1. install Surge plug-in
2. Attempt to add a MIDI track with it
3. Realize it's not on the list in the Add track/Bus/VCA dialog
4. Revert to creating a MIDI track with whatever inhttps://youtu.be/bfTAKv4htDEstrument and replace it afterwards
Additional Information:
Attached Files: Screenshot_20200718_155416.png (9,813 bytes) 2020-07-18 13:55
https://tracker.ardour.org/file_download.php?file_id=3779&type=bug
png
Notes
(0024760)
paul   
2020-07-18 13:52   
our definition for "is an instrument":

    (n_inputs.n_midi() != 0) && (n_outputs.n_audio() > 0) && (n_inputs.n_audio() == 0);

for VST plugins, since they come with developer-provided categories, we also check the plugins own "is instrument" setting.
(0024761)
unfa   
2020-07-18 13:55   
Yeah, that's exactly what I would expect.
Surge LV2 also is tagged an an instrument, so I guess it should be easy to correct this, what do you think?
(0024762)
paul   
2020-07-18 13:57   
We could look at the "ardour-level" tags too, I suppose.
(0024763)
unfa   
2020-07-18 14:02   
Thanks! I got very confused by this at first and I expect other users will be too, so if we can sort it out for them - that'd be great.
(0024795)
x42   
2020-07-23 16:23   
(Last edited: 2020-07-23 16:24)
We also use plugin categories as defined by upstream: For LV2: http://lv2plug.in/ns/lv2core#InstrumentPlugin and VST's with effFlagsIsSynth


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8326 [ardour] features minor N/A 2020-07-22 14:00 2020-07-22 14:00
Reporter: mantis_n1oif Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Automation point quantization
Description: I'm zooooooming way in to precisely set automation points dozens or hundreds of times per session. It would be really sweet to have quantization for them.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8324 [ardour] bugs minor always 2020-07-20 18:29 2020-07-20 18:29
Reporter: travis.aaron Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: Mixbus 6.x  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Loop Selection breaks if missed click while changing loop markers.
Description: if a selection is looped during playback, when a user accidentally clicks slightly above/below the loop marker while adjusting it and instead gets the row for "CD Markers" or "Range Markers", then the "Play loop range" is set to default state (off.) Play loop range can now not be activated again via shortcut key L or pressing the button in the top left corner unless you stop playback.
Tags:
Steps To Reproduce: -Set valid loop markers
-Activate "Play loop range"
-Start playback
-Click in "Range Markers" or "CD Markers" instead of the loop markers.

-Now you will be unable to activate play loop range again until you stop playback (sometimes it takes a few times)
Additional Information: This bug appeared after updating to Mixbus 6.1, the Linux x64 version.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8322 [ardour] bugs minor always 2020-07-19 13:48 2020-07-19 13:48
Reporter: AliMacD Platform: Apple Macintosh  
Assigned To: OS: MacOS  
Priority: normal OS Version: 10.12 or later  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Orig Pos in Edit List / Sources not working
Description: Can't sort by clicking Orig Pos in Edit List / Sources
Tags:
Steps To Reproduce: Show Editor List
select Source Tab
Click 'Orig Pos': does nothing to a list of sources which have different numbers in this list
Additional Information: clicking 'Path' and 'Source' both do rearrange the list correctly
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8291 [ardour] features minor have not tried 2020-07-09 08:25 2020-07-17 08:27
Reporter: muzikermammoth Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add "move playhead to start of region"
Description: When multiple clips are recorded, either midi regions or audio clips, it is useful to be able to move the playhead to the exact point where the recording starts. This facilitates copy pasting, shifting of clips and any operations that need these events to be placed at the same point. There should be a shortcut key to move the playhead to the correct position
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024658)
muzikermammoth   
2020-07-09 09:26   
To clarify, this is the specifically one clip region's start, and not from the list of regions
(0024664)
x42   
2020-07-09 18:09   
Check Menu > Transport > Playhead > ...

"Playhead to prev/next region boundary" (Shift+Alt + Left/Right) sounds like what you want.

If you select a track, this operation only looks for region boundaries on the selected track(s).
(0024668)
muzikermammoth   
2020-07-09 21:51   
The shift+alt+L/R selects boundaries based on the track. It doesn't focus on the clip level, so all boundaries in a track are valid, even if there is a boundary in the middle of a clip. What i'm talking about is the boundary of one clip
(0024684)
paul   
2020-07-11 03:24   
so you mean move playhead to start of selected region ? and if > 1 region is selected, move to earliest region start?

it would have to require selection because in the scenario you're alluding to, there's a strong chance of the mouse pointer being inside more than one region.

so perhaps you mean move-playhead-to-earliest-start-of-selected-region-or-if-no-selected-region-then-uppermost-region-under-pointer ?
(0024704)
muzikermammoth   
2020-07-11 17:09   
What i meant was to Move-playhead-to-clip-start/end , and no-move-playhead-if-no-clip-selected. To be fair, playhead to prev/next boundary works as well, but it's a minor annoyance when there's many boundaries between the one that I want.
(0024709)
paul   
2020-07-11 17:46   
which clip?
(0024710)
muzikermammoth   
2020-07-11 18:56   
The latest selected clip.
(0024712)
x42   
2020-07-11 19:13   
When you say "clip" do you mean "region" ?
(0024758)
muzikermammoth   
2020-07-17 08:27   
:)
From my perspective, a clip is a record of events within a span of time. On a track the clip is represented as a movable block of data. A range is a selected span of time, and once the data from maybe multiple clips is copied and pasted, is a region, though i've seen a range referred to as a region. The ardour documentation refers to a region as "represents a single contiguous section of one or more media files".

so yes by clip i probably mean region. And by move-playhead-to-start/end, i mean if (isclipselected()){ with last-selected-clip: move-playhead-to-start/end }

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7679 [ardour] features feature N/A 2018-11-01 08:49 2020-07-16 20:43
Reporter: randomuser225 Platform: Linux  
Assigned To: OS: Arch Linux  
Priority: normal OS Version: 2018.10.01  
Status: new Product Version: 5.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Plugin preset switching is difficult and cannot be automated, and presets cannot be easily imported
Description: Many VST instruments, e.g. modular synths, depend heavily on presets. One workflow involves using a bank of presets, switching quickly between presets until you have something close to the sound you want, and then fine-tuning.

Issue 0000001: This is wildly impractical with the current interface: in a long list of presets, it can take a minute or more to switch from one preset to the next preset in the list, because when you click on the drop-down menu, it resets you the center of the list (see attached screenshot). This is unsuitable for real-time composition.

Feature Request 0000001: Assignable keyboard shortcuts to move to the next/previous preset in the list. (Compare to how digital pianos let you switch tones with a single button press)

Issue #2: While you can automate every parameter of a plugin individually, it seems you cannot automate switching presets. This would be a useful feature for live performance / recording, as it enables you to use a midi controller to switch between presets. The current workaround is to have multiple instances of the same VST on different channels set to different presets (an ugly and resource intensive hack).

Feature Request #2: Allow automation of preset selection.

Issue #3: The GUI does not have a way to import/export presets. It also seems that default presets cannot be deleted or re-ordered through the GUI.

Feature Request #3: Create a GUI means of importing/exporting presets, deleting default presets, and organizing presets.
Tags:
Steps To Reproduce: To see how difficult preset switching is (issue 0000001):

1. Load a VST plugin with >150 presets.
2. Create two new presets, one named Preset A, the other Preset B.
3. Select Preset A.
4. Now, try to switch to Preset B (which is immediately next to Preset A)
Additional Information: Issue 0000001 is the most pressing, as there is currently no workaround. It should be a relatively simple feature to implement: just create a new action which cycles forward and backwards through the list of presets for a plugin when focused on the Edit menu of a plugin.

This is not really an issue for post-production work, but it hampers creative flow when used for real-time composition.
Attached Files: PresetScreenshot.png (64,052 bytes) 2018-11-01 08:49
https://tracker.ardour.org/file_download.php?file_id=3426&type=bug
png
Notes
(0020452)
x42   
2018-11-05 03:09   
At least "Feature Request #2: Allow automation of preset selection" is a no-go for VST. It is not realtime-safe to change presets that include plugin internal state (that is not exposed as control ports).

The vast majority of VST plugins do not expose presets to begin with but have a custom preset method provided by the plugin itself.

Is there a particular plugin that has > 150 presets but no internal preset management that you can suggest to test?

I've recently toyed with https://lhiaudio.com/cadmium that comes with a lot of presets and didn't find it as unpleasant to use as you describe, granted though, user-presets are sorted last.
(0020454)
randomuser225   
2018-11-05 05:30   
Ob-Xd (one of the few free cross-platform VSTs) is an example: https://www.discodsp.com/obxd/

You can see it includes a lot of identical "default" presets. Presumably the idea being that you will fill these in as you desire. "Save" and "Delete" buttons are greyed out for these, but if you modify them, the changes are automatically persistently saved by Ardour on a per-session basis (but settings do not cross between sessions, so it's not saved anywhere internal to the VST). I presume that this means these presets are thus exposed to some degree to Ardour. I'm running on Arch Linux with Gnome 3.30 (not sure if this is relevant).

When using this plugin, you can create user presets, and these user-created presets are sorted last, but if you click on the preset drop-down menu, it puts you right in the middle of list (rather than over where you were), so you have to scroll all the way back down to switch between user-created presets that are adjacent to each other. This may be a Linux specific problem. Putting the cursor over the dropdown menu and mouse-wheeling up or down does seem to work, however, so it's only an issue when you actually click the drop-down menu.
 
Most of my problems would be solved if there were an assignable keyboard shortcut to switch between the presets in the drop-down menu. From what I understand, at least for this VST plugin, changing a preset is the same as simultaneously adjusting the already-exposed controls. If I wanted to assign a MIDI function to emulate switching between presets, I could do that by making a bunch of different tracks set to listen to different MIDI channels, but that would take hours. Preset switching for this plugin could also be emulated in a single track by automating each of the controls separately, but this is too tedious for live use. If there were an assignable keyboard shortcut, I could use an external program to intercept MIDI signals from a controller and input keystrokes.
(0020455)
randomuser225   
2018-11-05 05:47   
Prodigious Synthesizer is another example: https://www.kvraudio.com/product/prodigious-synthesizer-by-synthescience

This one I know for a fact has >100 different presets by default. I'm running it through LinVST (which wraps a Windows VST through an emulation layer as a Linux VST).

When run in Reaper on Windows, the presets have names. Here they are just labeled "Preset 1", "Preset 2", etc. That may just be LinVST doing a bad job wrapping it, though. Everything else seems to work perfectly, though.


Here's it's easy to see the problem. Click on the drop-down preset menu. Select "Preset 100". Now click on the drop-down preset menu again: your mouse is now over "Preset 18".
(0020456)
randomuser225   
2018-11-05 06:01   
(Last edited: 2018-11-05 07:48)
Is there a reason why the "Program Change" MIDI signal can't be routed to select the preset of a VST instrument (as it would do for a physical instrument)? Ardour has access to this preset list, since they can be switched between in the part of the GUI controlled by Ardour and not the plugin. I'm not sure I understand the safety concern, since this switching can be done "live" using the mouse, even in the middle of recording automation. The only issue is that when you change the preset in, say, Prodigious, the corresponding changes in parameters are not registered in the automation recording until some other slight manual change is made to one of the parameters. Perhaps the values of the parameters are not polled when a preset is changed?

I have not personally encountered a VST instrument whose preset cannot be changed live. I can see how this might be an issue for a VST which has hidden parameters and an internal preset switching, but for these Ardour would not see this internal preset list anyway (so let's put these VSTs aside for this discussion).

I'm open to an argument that if a VST instrument does not make any use of Program Change commands, that's its own fault, and not the fault of the DAW. It would also be possible (although tedious) to use write a plugin to control the parameters of a VST instrument based on Program Change commands (it would require configuring each VST instrument separately). A third option would be to write a VST wrapper that acts as a primitive VST host, accepts Program Change commands, and changes the preset of the wrapped VST instrument, and passes through all other parameters.

It's just as a practical matter, there are many VSTs which do not respond to Program Change commands, but do have a somewhat standard way of switching between presets, and it would be nice to be able to trigger this by a MIDI event or something similar.

One more thing: the situation with preset switching is most difficult on a laptop trackpad. Trying to double-finger scroll on a tiny drop-down menu without accidentally clicking is difficult. Even just adding two buttons for "<" and ">" for previous and next preset would help a lot with usability.

In any case, thanks for considering this!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8309 [ardour] features minor have not tried 2020-07-14 06:41 2020-07-16 15:34
Reporter: iur.n Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Maximize the region for editing
Description: I am experimenting with adding a feature like this:

Actual situation:

Double click on region --> the region editor dialog is shown

What I want to add:

[A key modifier] + mouse double click on the region -->

* Store the current viewing state
* Perform vertical zooming of the region to maximized (the same as key F)
* Perform horizontal zooming
                  - until the region width will fit the window (will not work for long regions)
                  - or to take in consideration other criteria of the horizontal zooming factor (major grid line, minor grid lines, or something else)
* Move the horizontal viewing where the lick was performed (could be move to beginning of the region but this will not work for long regions)
* Add other (say XXX) action to reset this special the viewing state to the original state. There is Shift + Z, but I don't think will work for this purpose.
* Additional behaviour : leaving this special viewing state by other means than XXX will clear the original stored state (still thinking about this behaviour).

The result should be a more easy way to see the arrangement, and at the same time easily to start editing the region and go back to the same unaltered view of the tracks.

Other ideas regarding the behaviour in this special viewing state would be to add actions to mouse (plus a key modifier) to move the view by dragging horizontally. There are areas for dragging, but I think in place dragging will be more straitforward.

Impacts:

Old user experience is not impacted
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024749)
iur.n   
2020-07-16 15:34   
Here the commit that implements the above points: https://github.com/iurienistor/ardour/commit/4d65d94fcb5bfe1b133ccb4217d54912baaca443

- Ctrl+double click - stores the viewing state and maximizes the region. It is like viewing state is entering into the maximized region mode.
- Ctrl+double click - will restore the viewing state. This is different from Shift + z because in maximized mode if there was additional horizontal zooming, Shift+z will add new states in the stack.
- Stored viewing state will be lost when there is a vertical scroll, i.e. leaving the maximized region
- Maybe there would be better to disable vertical scroll when the we are in this special mode of viewing, but this will change the old user exeprinece.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8308 [ardour] bugs minor always 2020-07-13 22:49 2020-07-14 23:36
Reporter: RohanM Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ardour crashes when previewing sound from import dialogue
Description: From this particular snapshot on this session, when I attempt to play a sound from within the Import dialogue, Ardour crashes.
Tags:
Steps To Reproduce: 1. Download this session: http://rohanmitchell.com/random/ardour-crash-session-20200714.tgz
2. There are two snapshots, included; open the "riffing on beats" snapshot
3. Press ctrl-i to open the import dialogue
4. Click on a wav file, or with autoplay disabled, click on a wav file then click play
5. Ardour crashes
Additional Information:
System Description
Attached Files:
Notes
(0024739)
x42   
2020-07-14 10:51   
I cannot reproduce this, but I also do not have any of the calf-plugins installed.
Those are known to cause crashes, even seemingly unrelated ones.

Can you still reproduce this after removing all calf-plugins from the session? (You will also have to restart Ardour after removing the plugins)
(0024741)
RohanM   
2020-07-14 23:36   
Thanks for the quick reply! The session had Calf Reverb on a bus and and Calf Pitch Tools on two tracks. After I removed Calf Pitch Tools from both tracks and restarted Ardour, the problem went away. I'll re-report this one to Calf. Thank you!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8312 [ardour] features minor N/A 2020-07-14 22:54 2020-07-14 22:54
Reporter: mantis_n1oif Platform: Ubuntu  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: humanize/de-quantize feature request
Description: I'd be interested in a feature to de-quantize MIDI notes. Algorithm would be something like "quantize, then move forward/backwards randomly up to 0.xxx beats"
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8311 [ardour] bugs minor always 2020-07-14 17:18 2020-07-14 17:18
Reporter: jumase Platform: Debian GNU  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Weird display on send automation faders when playing related automation curves
Description: As far as I could test, it seems to be an issue of displaying rather than playing. I mean that the automation is working fine, but it's not showing properly.

Create a send to a bus, then record or write automation curves, especially with abrupt changes (one point at 0 dB and the next one at 6 dB, for example). Both the send indicator on the processor box and the fader on the automation lane display (the same) wrong values.

The same weird thing happens when recording on 'write' or 'touch' mode, but this is not exclusive. You can draw points with mouse and it still happens.

I think it has to do with "abrupt" changes. Increasing the slope mitigates the effect, but it's not enough. For example, for changes from 0 dB to +6 dB, it will show +4,5 dB, +5 dB, +5,8 dB, never reaching +6 dB, although the slope is soft enough so that the automation could not make sense if you want quick changes.
Tags: automation
Steps To Reproduce: Ceate an audio and a bus track, then aux send from the audio to the bus track. Draw an automation curve to control send level that consist of four segments: the first one at 0 dB, the second one at -inf dB, the third one at 0db again, and the last one at 6 dB. All points must be at minimum distance in time. Set automation lane to "play" and see what both faders show while playing.
Additional Information: Manually dragging and dropping playhead along the four segments cause all faders to display the right values.
System Description
Attached Files: Automation display.png (112,000 bytes) 2020-07-14 17:18
https://tracker.ardour.org/file_download.php?file_id=3776&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8298 [ardour] other minor always 2020-07-09 15:15 2020-07-14 05:52
Reporter: iur.n Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Activation / deactivation of track
Description: When I make an track inactive it will remove all the track controls and also the name. At least for me is confusing because I can't even see what tracks stay there deactivated. I think what was in version 5 was better (just grayed out controls and the name).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: track_controls.png (10,424 bytes) 2020-07-09 15:15
https://tracker.ardour.org/file_download.php?file_id=3760&type=bug
png

disabled-track.png (25,197 bytes) 2020-07-09 18:53
https://tracker.ardour.org/file_download.php?file_id=3761&type=bug
png

disabled_track.png (27,437 bytes) 2020-07-10 07:34
https://tracker.ardour.org/file_download.php?file_id=3765&type=bug
png

inactive_midi.png (33,689 bytes) 2020-07-14 05:52
https://tracker.ardour.org/file_download.php?file_id=3774&type=bug
png
Notes
(0024667)
x42   
2020-07-09 18:53   
That is odd. The name should still be visible (see screenshot below). I cannot reproduce it.

Is that issue reliably repeatable? Is this Ardour from ardour.org or a self-built (different gtk version)? Does it persist across session reloads? Which operating system are you using?
(0024673)
iur.n   
2020-07-10 07:34   
It is self built from the master branch
, is built on Ubuntu 18.04.4 LTS
I see libgtkmm-2.4.so.1 used by the binary
Maybe there are some file settings that I need to remove left by version 5.
Also, when expanding the inactive track there comboboxes will be shown, I don't know if this is intended.
(0024674)
iur.n   
2020-07-10 15:31   
Made pull request here: https://github.com/Ardour/ardour/pull/535
For now it fixes for audio tracks only. I hope I am going in the right direction. Ideally would to be able to re-attache the label from control table to inactive table somehow.
(0024736)
jumase   
2020-07-14 01:51   
I can reproduce that and it only seems to affect MIDI tracks. Audio and buses names are still visible between ()
(On Ardour 6.2 from ardour.org; Debian 10)
(0024738)
iur.n   
2020-07-14 05:52   
I am using the code from the master and the name for MIDi is shown ok.

I think there is also a need to change the color of the name to gray, and remove the parentheses.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8163 [ardour] bugs minor always 2020-05-29 18:11 2020-07-14 02:10
Reporter: mantis_n1oif Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "delete" key doesn't work to delete automation points when they are highlighted
Description: Self-explanatory
Tags:
Steps To Reproduce: Create session
add audio track
add plugin with automation
add a few automation points
highlight one or two of them
hit delete key
nothing happens
Additional Information:
System Description
Attached Files:
Notes
(0024737)
jumase   
2020-07-14 02:10   
You have to be editing on "grab" mode in order to press "del" key and delete one or several automation points. Generally, you can shift+secondary-click to delete a single automation point. Could be that?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8124 [ardour] bugs minor always 2020-05-18 16:38 2020-07-13 18:05
Reporter: joboschetti Platform: Gnu/Linux  
Assigned To: OS: openSUSE  
Priority: normal OS Version: 15.1 / 15.2  
Status: new Product Version: 6.0-pre1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash on deleting track (gtkmm:ERROR)
Description: Application crash when deleting track.
Tags:
Steps To Reproduce: Open a project, select track, and deleting (or cutting)
Additional Information: 113733947 DEBUG::Keyboard: Snoop widget 0x558447b714b0 name: [gtkmm__GtkWindow] key 65535 [Delete] type 8 state 16 [+MOD2] magic 0
113734117 DEBUG::Keyboard: snooper returns 0
113734329 DEBUG::Accelerators: main window key event, bindings = 0x558448519700, global = 0x558447b15ad0
113734565 DEBUG::Accelerators: Win = 0x558447b714b0 [title = ard6test - Ardour] focus = EditorMainCanvas (no) Key event: code = 65535 [Delete] state = +MOD2 special handling ? 0 magic widget focus ? 0 focus widget 0x55844c1e8300 named EditorMainCanvas mods ? no
113734591 DEBUG::Accelerators: activate, then propagate
113734663 DEBUG::Accelerators: using widget bindings MIDI @ 0x5584486b1d10 for this event
113734800 DEBUG::Bindings: binding for Key 65535 (Delete) state 0 : Notes/alt-delete - insensitive, skipped
113734876 DEBUG::Accelerators: using widget bindings Editor @ 0x558448519700 for this event
113734939 DEBUG::Bindings: binding for Key 65535 (Delete) state 0 : Editor/editor-delete
113735452 PBD::DEBUG::UndoHistory: 3045: Begin Reversible Command, new transaction: elimina oggetti
113736945 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288f1a0, invalidation 0x55844a504c00
113737034 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288e990, invalidation 0
113737082 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288e990, invalidation 0
113737122 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288e990, invalidation 0
113737160 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288e990, invalidation 0x5584479b8570
113737865 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288e820, invalidation 0
113737918 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288e820, invalidation 0
113738121 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288e820, invalidation 0
113738183 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288e820, invalidation 0
113738537 PBD::DEBUG::EventLoop: ArdourGUI: invalidating request from 0x558447b15970 (gui) @ 0x55844abb7400
113738593 PBD::DEBUG::EventLoop: ArdourGUI: invalidating request from 0x558447b15970 (gui) @ 0x55844eecac00
113738628 PBD::DEBUG::EventLoop: ArdourGUI: invalidating request from 0x558447b15970 (gui) @ 0x55844d0af530
113740158 PBD::DEBUG::CanvasEnterLeave: (156, 278) covers 9 items
        Item Root/ROOT ignore events ? 0 vis ? 1
        Item ScrollGroup/canvas h scroll ignore events ? 0 vis ? 1
        Item Container/time line group ignore events ? 0 vis ? 1
        Item ScrollGroup/canvas hv scroll ignore events ? 0 vis ? 1
        Item Container/Canvas TrackViews ignore events ? 0 vis ? 1
        Item Container/main for Audio 1 ignore events ? 0 vis ? 1
        Item Container/SV canvas group Audio 1 ignore events ? 0 vis ? 1
        Item Rectangle/SV canvas rectangle Audio 1 ignore events ? 0 vis ? 1
        Item ScrollGroup/canvas cursor scroll ignore events ? 0 vis ? 1
113740944 PBD::DEBUG::CanvasEnterLeave: after filtering insensitive + containers, we have 1 items
113741010 PBD::DEBUG::CanvasEnterLeave: enter Container/SV canvas group Audio 1
113741044 PBD::DEBUG::CanvasEnterLeave: enter Container/main for Audio 1
113741074 PBD::DEBUG::CanvasEnterLeave: enter Container/Canvas TrackViews
113741104 PBD::DEBUG::CanvasEnterLeave: enter ScrollGroup/canvas hv scroll
113741133 PBD::DEBUG::CanvasEnterLeave: enter Root/ROOT
113741162 PBD::DEBUG::CanvasEnterLeave: ENTER Rectangle/SV canvas rectangle Audio 1
113741271 PBD::DEBUG::CanvasEnterLeave: CURRENT ITEM Rectangle/SV canvas rectangle Audio 1
113741868 PBD::DEBUG::EventLoop: ArdourGUI: invalidating request from 0x558447b15970 (gui) @ 0x5584482f8940
113742184 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288f0e0, invalidation 0x55844d5d3170
113742275 PBD::DEBUG::AbstractUI: gui/ArdourGUI direct dispatch of call slot via functor @ 0x7fff3288f0e0, invalidation 0
**
gtkmm:ERROR:treestore.cc:49:Gtk::TreeModel::iterator Gtk::TreeStore::erase(const iterator&): assertion failed: (iter.get_gobject_if_not_end() != 0)
Annullato (core dump creato)
System Description
Attached Files: debug.txt (4,378 bytes) 2020-05-18 16:38
https://tracker.ardour.org/file_download.php?file_id=3685&type=bug
ardour-crash-bt.txt (47,467 bytes) 2020-07-13 16:31
https://tracker.ardour.org/file_download.php?file_id=3773&type=bug
Notes
(0024587)
paul   
2020-07-03 05:34   
Nobody else has reported this. If it is still reproducible, please see http://ardour.org/debugging_ardour for instructions on how to get a useful debug backtrace (the output above is not useful, unfortunately.
(0024728)
sbahling   
2020-07-13 16:31   
I have reproduced this also on openSUSE Leap 15.2 with Ardour 6.0.0.

Steps to reproduce are:
1. start new / empty session
2. add an audio track
3. record a bit of audio
4. delete or split the resulting region (delete or split cause the crash for me)

I believe the crash is triggered in the following block of EditorRegions::region_changed

        boost::shared_ptr<ARDOUR::Playlist> pl = r->playlist ();
        if (!(pl && _session && _session->playlist_is_active (pl))) {
                /* this region is not on an active playlist
                 * maybe it got deleted, or whatever */
                if (map_it != region_row_map.end ()) {
                        region_row_map.erase (map_it);
                        _model->erase (map_it->second);
                }
                return;
        }

which is failing the following assert in TreeModel::iterator TreeStore::erase of gtkmm

  g_assert(iter.get_gobject_if_not_end() != 0);

Attaching the backtrace

Since I can't reproduce this with openSUSE Tumbleweed, I'm guessing we are hitting a bug with another library. I tried updating glib to the version in Tumbleweed, but that didn't help. Trying to build Ardour now using the boost libs from Tumbleweed so see if that helps. I'm not that experienced debugging c/c++ so perhaps I'm barking up the wrong tree.
(0024729)
paul   
2020-07-13 16:34   
This is already fixed in git. Commit 89a7c41175ecfc
(0024731)
sbahling   
2020-07-13 18:05   
Verified. A rebuild of the package with that patch seems to fix it. I will push an update to openSUSE as soon as there is another Ardour release.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8305 [ardour] bugs minor always 2020-07-12 14:50 2020-07-12 14:50
Reporter: inFlowiaLab Platform: Linux  
Assigned To: OS: Ubuntu Studio  
Priority: normal OS Version: 19.10 x64  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When recording pan automation over the old automation, I hear the old automation but not the new one.
Description: When recording a panorama automation in recording or touch mode, the old automation rather than the new one sounds on top of the already recorded automation.
Tags: automation, pan
Steps To Reproduce: Create Midi Track with General-MIDI Synth. Record pan automation so that only the left channel sounds. Go to the touch or record mode and record the automation on top of the already recorded one but transferring theAzimuth-Fader with the MOUSE so that the sound goes to the right channel.
Sound will still come from the left channel while you record. But after the recording is completed and during repeated playback, everything will be correct and the new automation will sound.
Additional Information: This was not observed on version 5.12. Observed on 6 and 6.2.
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8169 [ardour] bugs minor random 2020-05-30 14:39 2020-07-12 14:16
Reporter: inFlowiaLab Platform: Linux  
Assigned To: OS: Ubuntu Studio  
Priority: normal OS Version: 19.10 x64  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIDI note at the intersection of clips sounds too short
Description: I recorded a short video with an example of this bug.

http://inflowia.ru/tmp/2020-05-30 17-30-08.mkv

The last sounding note sounds too short, as if cutting off the border of the first clip.
This works the same for Yoshimi and for General Midi Sinth, but only within this session. I tried to repeat with the same MIDI clips in another session and this did not happen again.
Tags: Midi
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0024718)
inFlowiaLab   
2020-07-12 14:16   
broken link fixed: http://inflowia.ru/tmp/2020-05-30-17-30-08.mkv

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8295 [ardour] features minor have not tried 2020-07-09 12:50 2020-07-11 17:12
Reporter: muzikermammoth Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Zero crossing selection when resizing audio clip
Description: Currently when an audio clip is resized, the user can select the granularity by choosing the snapping metric, ranging from a bar to 1/128th notes, etc, or free resizing. However, without a selection to a zero crossing, this clip can have audible artifacts. To stop this from happening, there should be a select to zero crossing function, or a very short ramp up/down envelope.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024663)
muzikermammoth   
2020-07-09 12:59   
My bad, it seems like the process of selecting and moving clips, inadvertently there was a very short clip that was copied and was enough to cause a non zero crossing clipping sound. Be that as it may, having a select next zero crossing function would be great
(0024665)
x42   
2020-07-09 18:35   
I assume you'd like this feature to splice regions to create loops.

Despite what many assume, zero crossings is not a good way to splice regions. It can work in some special circumstances (usually when you apply a band-pass or high-pass) to track the phase of a signal.
For creating loop samples, you're much better off to add a short fade, reduce the energy of the signal instead of concatenate data using zero points as glue.

Ardour does add region-fades when you split a region. You may want to change the region-fade to be fast ( https://manual.ardour.org/editing-and-arranging/create-region-fades-and-crossfades/ )
Also Menu > Transport > Playhead > Move to prev/next transient (Ctrl + left/right) may come in handy.

PS. If I misunderstood your use-case please elaborate what you'd like to achieve with "move to next zero"
(0024685)
paul   
2020-07-11 03:25   
zero crossings are a bogus concept invented in the early days of digital audio.

they are not useful for editing, and DAWs or writers that claim otherwise are not being honest with you.

i will do a write up for the Ardour FAQ at some point (soon?) explaining why this is true. but trust me, it is true.
(0024705)
muzikermammoth   
2020-07-11 17:12   
"Also Menu > Transport > Playhead > Move to prev/next transient (Ctrl + left/right) may come in handy."

This is probably the function i was looking for.

"zero crossings are a bogus concept invented in the early days of digital audio. "

I've heard about this as well. But a nice writeup would be fun to read.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8302 [ardour] other minor always 2020-07-11 10:03 2020-07-11 10:03
Reporter: iur.n Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Tacks separation lines hardly visible
Description: In Ardour 6 the separation lines between the tracks of the same type is hardly visible comparing with version 5.
Tags: ui
Steps To Reproduce:
Additional Information:
Attached Files: track_distinction5.png (28,281 bytes) 2020-07-11 10:03
https://tracker.ardour.org/file_download.php?file_id=3768&type=bug
png

tracks_distinction.png (37,438 bytes) 2020-07-11 10:03
https://tracker.ardour.org/file_download.php?file_id=3769&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8173 [ardour] bugs minor always 2020-05-31 12:11 2020-07-11 09:56
Reporter: mantis_n1oif Platform: Some Other Linux  
Assigned To: OS: Some Other Linux  
Priority: normal OS Version: unknown  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Loop ranges don't loop
Description: Loop ranges don't loop
Tags:
Steps To Reproduce: Create session
Create loop range
Right-click marker and select "Loop range" (not visible in my video)
Playhead will just keep on going past the end of the loop range
Additional Information: Demonstration here:

https://youtu.be/ecj3pPo0LJI

(ignore the guitar solo. I was just effing around... yeah that's the ticket)
System Description
Attached Files:
Notes
(0024518)
mantis_n1oif   
2020-06-27 19:58   
This one is still a problem as of 6.0.143. Seems like a pretty big deal to me which means either I'm wrong about that (people don't use the loop range feature much) or it's not actually broken and I'm simply doing something wrong.

Can someone at least confirm/reproduce?
(0024523)
jeythekey   
2020-06-29 07:01   
I was experiencing the same thing (v 6.0.178). Looping works when first creating the loop range by marking a range and clicking "loop range" via context menu, which is accompanied by a green shade over all tracks indicating the loop is active. But then re-starting the loop from e.g. the context menu of the created loop/punch range markers does not loop, also no green shading.
(0024527)
phaesler2   
2020-06-30 07:15   
I get definitely get some weird behaviour on looping. Works for a few loops but after a while sometimes little time offsets start to appear between tracks and sometimes the cursor wanders off past the end of the loop range - the audio keeps looping but the cursor keeps moving forward with a mind of its own.
(0024608)
paul   
2020-07-06 00:56   
This should now be fixed in git.
(0024636)
paul   
2020-07-08 15:07   
rescinding my previous comment. I need lots more details/recipe because I cannot replicate this behavior.
(0024637)
paul   
2020-07-08 15:10   
(Last edited: 2020-07-08 15:17)
I watched the video and i do not see what you did at the beginning that would have been expected to cause loop playback anyway. The existence of a loop range does not mean that ardour will loop.

(0024638)
mantis_n1oif   
2020-07-08 15:27   
Doesn't quite work yet. If you tell it to "loop range" while it's playing anywhere, it'll fail. if the playhead is stopped, and you do "loop range", it'll work
(0024640)
paul   
2020-07-08 17:01   
I cannot replicate that behavior in the current code. We're about to release 6.2 so please check that out.
(0024645)
mantis_n1oif   
2020-07-08 17:14   
I'm using 6.2, so the nightly version number says.
(0024655)
muzikermammoth   
2020-07-09 06:27   
Don't you need to press the Loop play button ( shortcut L ) to loop?
(0024660)
krischan941   
2020-07-09 10:08   
" Doesn't quite work yet. If you tell it to "loop range" while it's playing anywhere, it'll fail. if the playhead is stopped, and you do "loop range", it'll work "

Have you installed Ardour 6 pre nightly releases and do you use their config files in official Ardour 6? I remember having a similar problem (by invoke looping via "L" button) and deleting the old config folder in ~/.config/ardour6 solved it for me. Although I don't know why it solved it.
(0024694)
phaesler2   
2020-07-11 09:56   
I can't replicate this issue with recent builds. But I find looping gets unstable pretty quickly if you loop continuously and move the start and end markers around a bit.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7310 [ardour] features feature N/A 2017-04-03 16:44 2020-07-11 08:46
Reporter: Oliver Platform: i686  
Assigned To: OS: Xubuntu  
Priority: low OS Version: 16.04 LTS  
Status: new Product Version: 5.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make secondary clock selectable in Appearance->Toolbar
Description: As far as I know the secondary transport clock only becomes visible with wide enough screens. With the options available in Appearance->Toolbar, however, it is now possible to make enough space by deselecting some items.

For me this secondary clock is more useful than the new 'Navigation Timeline'. Could therefore the secondary clock also be made selectable?
Tags:
Steps To Reproduce:
Additional Information:
System Description Low latency kernel
Attached Files:
Notes
(0019599)
mhartzel   
2017-04-05 17:11   
Another user here. It can be done right now: Edit / Preferences, On the left panel click on "Toolbar", there select: Display Secondary Clock, deselect: Display Navigation Timeline.

My display is 1366 x 768 and Selection Clock fits nicely and there is still some unused space on the right side of it.

To me also the Selection Clock is more useful than the navigation timeline.
(0019600)
Oliver   
2017-04-05 18:29   
Thanks mhartzel, but I don't have that option 'Display Secondary Clock'. Only the following five appear: Record/Punch, Monitor, Selection Clock, Navigation Timeline, Master Level Meter.

Maybe that is so because my screen is only 1024 pixel wide. The secondary clock would fit, however, if enough of the other are deselected.
(0021078)
Oliver   
2020-03-28 20:41   
Still not possible to select the Secondary Clock with Ardour 6.0.pre1.18 on Xubuntu 18.04 LTS with a screen of 1024 pixel width.
(0024692)
Oliver   
2020-07-11 08:46   
...how I still wish with Ardour 6.12 to select the secondary clock in Appearance->Toolbar and deselect other items.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7996 [ardour] bugs minor always 2020-04-08 19:09 2020-07-11 06:56
Reporter: Oliver Platform: x86_64  
Assigned To: johmue-eo OS: Xubuntu  
Priority: normal OS Version: 18.04LTS  
Status: assigned Product Version: 6.0-pre1  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Crash of 5.12 after session touched with 6.0-pre1
Description: An empty session created in 5.12 makes 5.12 crash if it has been opened once with Ardour-6.0.pre1.208 (from https://nightly.ardour.org/). It does not matter if I try to open the backup session created by 6.0 with suffix -3002, or the latest one.

I don't use a debug built for 5.12, but the last messages in the terminal are

terminate called after throwing an instance of 'PBD::unknown_enumeration'
  what(): unknown enumerator Samples in PBD::EnumWriter
Aborted
Tags:
Steps To Reproduce: - Create an empty session with Ardour 5.12, save the session, and quit.
- Open in Ardour-6.0.pre1.208 and just quit again (no saving).
- Try to open again in Ardour 5.12 -> crash.
Additional Information: This also happened with previous nightlies. It crashes also in 'Safe mode' (but there are no plugins, anyway).
System Description Pentium Dual-Core E5200 (2.50GHz)
Attached Files: instant.xml (2,158 bytes) 2020-07-09 23:25
https://tracker.ardour.org/file_download.php?file_id=3762&type=bug
Layla (Ardour)-3002.ardour (81,459 bytes) 2020-07-09 23:25
https://tracker.ardour.org/file_download.php?file_id=3763&type=bug
Notes
(0021258)
johmue-eo   
2020-04-08 20:14   
I can't reproduce this here.

Can you try the following:
- Create an empty session with Ardour 5.12, save the session, and quit.
- Copy the file "instant.xml" of the session folder somewhere (like to /tmp)
- Open in Ardour-6.0.pre1.208 and just quit again (no saving).
- Copy the "instant.xml" that you copied somewhere back to the session folder
- Try to open again in Ardour 5.12 and see if it crashes.
(0021259)
Oliver   
2020-04-08 20:23   
Indeed it does not crash in 5.12 if I use the saved "instant.xml", neither with the -3002 session nor with the normal one.

I also saved the version of the file after opening in Ardour-6.0.pre1.208. Ardour 5.12 crashes again if I use this one.
(0021267)
johmue-eo   
2020-04-09 12:01   
So it reproducibly crashes as soon as the "instant.xml" that Ardour6 has touche is in place?

Maybe you can attach the session file and the two instant.xml, one of which makes Ardour5 crash and the other doesn't.
(0021271)
Oliver   
2020-04-09 18:23   
Sadly... today, I cannot reproduce it with the exact same recipe that I put down yesterday. Ardour 5.12 does not crash today on a session touched with 6.0-pre1 (same version).

Interestingly, I even did revive a real session (not a test) that I could not open in Ardour 5.12 anymore because of (I thought) this issue by deleting the 'instant.xml' - and it opened again in 5.12.

That is strange. The recipe is very simple and I tried yesterday on three new sessions. Earlier yesterday, I was playing with ggc4/gcc5 versions of Ardour in connection with another bug report (ID 0007992), but I have used always the same version for the test of this issue.
(0021285)
Oliver   
2020-04-10 18:44   
Still could not reproduce today with Ardour-6.0.pre1.208.

For the first time, I observed today a warning in 5.12 that a session could not be loaded because it was generated with a more recent version of Ardour. The warning is as expected, but I did not get this warning before.
(0024669)
Oliver   
2020-07-09 23:11   
After installing Ardour 6.2, this happens again now, with the same message in a terminal.

This time, I opened an old session previously used in Ardour 5.12, and Ardour 6.2 created the -3002 copy of the session. Ardour 5.12 now crashes as described with both sessions ('normal' and -3002).
(0024670)
Oliver   
2020-07-09 23:15   
Attached the instant.xml file of the session that crashes Ardour 5.12. As suggested before, deleting this file stopped Ardout 5.12 from crashing.
(0024671)
Oliver   
2020-07-09 23:25   
Looks like attaching failed. Try again, now also the session file.
(0024683)
paul   
2020-07-11 03:21   
this is sort of a design-error, sort of unavoidable error. we copy the .ardour file for safe-keeping, but instant.xml (used to store settings that should always be stored "instantly" rather than on explicit save) is in some senses "part of" the session too.

the versioning provided for the .ardour file is not done for the instant.xml file, which can lead to this sort of problem. The session can still be opened as you've discovered ... i'm not sure how much of a priority we would put on versioning the instant.xml file as well as the .ardour file.

there is a case for doing so, don't mistake what i'm saying. i think it's just going to be low priority.
(0024691)
Oliver   
2020-07-11 06:56   
This is maybe less an issue now that the new release is out and hopefully there is no need to go back to Ardour 5.12 for work on older sessions. Judging from what I see in instant.xml, simply deleting it does not destroy too valuable information, but only things like window positions and clock mode.

However, during testing towards 6.0 is was VERY (if possible I'd also underline this word) disconcerting to suddenly see Ardour 5.12 crash when trying to open a production session after just touching it with the new version (no saving!).

Apparently not many other people have found this behaviour, maybe it is particular to my computer, but fixing it for the next major release would be appreciated.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8289 [ardour] bugs minor random 2020-07-08 15:45 2020-07-11 03:31
Reporter: unfa Platform: Arch  
Assigned To: OS: Linux  
Priority: normal OS Version: (any)  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Muted MIDI regions still sound
Description: I'm encountering this randomly in Ardour 6 - I mute a MIDI region or a bunch of them and they still make sounds.

After I give up and do something else they mute themselves.

Unmuting always works, but muting can fail.

I'm atttaching a screenshot - you can see a muted MIDI region making sound.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20200708_174156.png (31,411 bytes) 2020-07-08 15:45
https://tracker.ardour.org/file_download.php?file_id=3758&type=bug
png
Notes
(0024689)
paul   
2020-07-11 03:31   
should be a simple fix. thanks for the report.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8300 [ardour] bugs minor always 2020-07-10 06:04 2020-07-10 19:27
Reporter: apoorv569 Platform: Arch Linux  
Assigned To: OS: GNU/Linux  
Priority: normal OS Version: Arch Linux  
Status: new Product Version: 6.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Moving one clip from a track moves all clips in the current track.
Description: I was doing some editing, trying to delete some clips from track, and discovered that moving one clip left or right moves all the clips to right with it. I have attached a video to better explain what I'm trying to say.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: simplescreenrecorder-2020-07-10_11.26.22.mp4 (854,199 bytes) 2020-07-10 06:10
https://tracker.ardour.org/file_download.php?file_id=3764&type=bug
Notes
(0024680)
colinf   
2020-07-10 19:19   
You've enabled 'Ripple' edit mode somehow. Set it back to 'Slide' if you don't want later regions to move when you move earlier ones.
(0024681)
apoorv569   
2020-07-10 19:27   
@colinf I don't know of any such feature, never heard of it. Where can I find the setting for this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8296 [ardour] bugs minor have not tried 2020-07-09 13:44 2020-07-09 18:42
Reporter: muzikermammoth Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: feedback Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Audio clip right context menu has "Bounce" options that do not do anything
Description: In the Editor, when working with audio clips, there are occasions when the user wants to bounce down a clip. To do this the clip needs to be set as a range selection, after which the right context menu changes to allow the "consolidate Range" function to appear.

However, originally the audio clip's right context menu has two "Bounce" functions, but these do not create an entirely new clip from the original. The interchange folder audio files on disk do not show any new wav files being created. If the functions don't do anything, then it shouldn't be there.

Also since most music these days are loop based, the amount of menu diving to create a looping clip seems counterintuitive.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0024666)
x42   
2020-07-09 18:40   
Works here, new (bounced) sources are added to the editor's source-list (Menu > View > Show Editor Lists).
 Both "Bounce (with processing)" and "Bounce (without processing)".

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8294 [ardour] bugs minor have not tried 2020-07-09 10:24 2020-07-09 10:24
Reporter: muzikermammoth Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: When in internal edit mode for midi, sometimes selecting a note includes a previously selected note
Description: When doing midi edits, the hot-key E sets the editor view into internal edit mode. From there the user can use the mouse to extend or contract notes, or move notes in the midi clip. When operating on another note, if one note is already selected/highlighted, sometimes the mouse pointer is able to move/extend/contract the midi note of both notes. Usually once a note is highlighted, when using the mouse pointer to select a different note, the previously selected note is deselected/dehighlighted, and in this manner, only the current note selected is operated on.

To mitigate this, i have to consciously select an open portion of the clip to deselect any notes and proceed with the note selection.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8293 [ardour] bugs minor have not tried 2020-07-09 09:44 2020-07-09 09:44
Reporter: muzikermammoth Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Ctrl-F follow mode does not follow playhead
Description: When ctrl-F is toggled, the follow playhead is enabled, and the viewport of tracks follows the playhead position by scrolling or paging to the next set of events as the playhead moves. Ctrl-F and toggling follow in the menu does not enable this behaviour. The page view of the tracks do not follow the playhead. It did work in the beginning but after a long session, this does not work.

To reenable, hit ctrl-f in the summary view at the bottom of the page to unset follow playhead, and ctrl-f again to start follow playhead. The page view will page to where the playhead is. After which, once the playhead is past the extent of the view, the page does not follow the playhead. So the user must once again unset and reset the playhead toggle
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8150 [ardour] bugs minor have not tried 2020-05-26 13:41 2020-07-09 08:32
Reporter: laex Platform: Ubuntu 14.04 (Trusty)  
Assigned To: paul OS: Ubuntu  
Priority: normal OS Version: 14.04 (Trusty)  
Status: assigned Product Version: 6.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Click (metronome) is unwantedly assigned to track after restart of audio engine
Description: I want the click out to go directly to a hardware-output ONLY and therefore I don't route it to any track input.

After stopping and restarting the audio engine (ALSA), the click is again assigned to input of track 1.
Tags: Metronome
Steps To Reproduce: Make sure that the click is not routed to any audio track input.

In audio/midi settings, click stop (so ALSA audio engine stopped), then click start again and see that click is again routed to track input automatically.
Additional Information: