|
|
|
|
|
There seem to be no regions to adjust the fades on here. Could you set up the session that is failing and then attach that? If I record a region in the session you attached i can adjust the fades without issue. |
|
|
sorry, am uploading again. |
|
|
I can reproduce the issue if the fade you want to set is bigger than ca. 7 senconds. |
|
|
yes, that is exactly the problem i'm having. |
|
|
and i don't believe that i was experiencing this in 6.9. |
|
|
Okay 7 seconds is not constant but I canmostly reproduce the behaviour in all new sessions. Here are some archives where you can trigger it. https://www.dropbox.com/scl/fo/k6msstjkpujjfig7s8so9/h?dl=0&rlkey=a37tghs1uwqrozenfglphf5v9 |
|
|
"test fade.ardour-session-archive" is the max-7-seconds-fade session |
|
|
On Manjaro KDE, I have the same issue with Ardour 7.0.0. But running Ardour 7.0.105-dbg changing fading works as expected. |
|
|
i just installed nightly build Ardour-7.0.170-x86_64-gcc5.run and i'm still experiencing the same problem with not being able to create long fades without the fade region snapping back. |
|
|
have attached an archive using Ardour-7.0.170-x86_64-gcc5 |
|
|
Which archive? I only see the one from Oct 31 ... is that it? |
|
|
am attaching again |
|
|
would there be any way to get v. 6.9 to try this again? i no longer have the installer for this version on my computers. |
|
|
I see only 1 attachment, call ed test_2022-10-31_223322.ardour-session-archive that was added yesterday. We do not make older copies available. You can (and likely should) parallel instal multiple versions. |
|
|
ah, you put it on dropbox. |
|
|
pulled the latest ... tested here ... dragged fades long (very long) and short ... no issues Maybe try renaming ~/.config/ardour7 and see if that helps at all btw, nice guitar playing from someone! |
|
|
ah, found a likely related issue. i don't have the problem you describe but after some manipulation i can no longer shorten the fades. Will investigate shortly. |
|
|
Hi Paul, I deleted my ardour7 config, no difference. Always reproducible. Here is a short video: https://www.dropbox.com/s/9owiriq00y74kzd/Bildschirmaufzeichnung%20vom%202022-11-01%2C%2020-32-42.webm?dl=0 (It didn't record the cursor but the blue line in Ardour indicates its position) If you mean the little acoustic guitar peace, yep thats mine. But to be honest it is an instrument plugin. I had no microphone to record it (And apart from that, I would never have been able to play it so well). But the composition is mine and I simply take it as compliment anyway / too ;D |
|
|
I was wrong. Just confused about dragging the handles. As far as I can tell, this is fixed in current git master OR it's something that we don't understand. |
|
|
i just installed the latest nightly but am still experiencing this problem. would anyone happen to have an installer for v. 6.9? i no longer have this on any of my computers, and this situation is putting me in a bind. thanks. |
|
|
If it's OK by Paul, you can get the installer for 6.9.0 from me. I'll put it online in a temporary folder. |
|
|
thanks, this is putting me in a bind. i should've done a parallel install with the newest version, keeping 6.9, but actually i've never run into an issue like this with ardour before. learned my lesson! |
|
|
https://send.bitwarden.com/#zXXXX0uqCkOVKa9BAJYOXA/cmclh63b32LXm4rspwtQUw This link will expire after 1 download. Just for you, jaskah :-) |
|
|
thanks, but i just tried to download but got the message, "file cannot be found." |
|
|
Try agai. If not email me (address at the link) and we'll find another way. |
|
|
Still present in latest nightly v7.0-197 2022-11-02 (after deleting .config/ardour7 again) https://www.dropbox.com/s/fdhn2a997ehdx9b/Bildschirmaufzeichnung%20vom%202022-11-02%2C%2012-12-41.webm?dl=0 |
|
|
My observations so far have been made in Ubuntu 22.10 On the same machine I also have Windows 11 installed (dual boot). I installed latest Ardour nightly on Windows and there I don't have this issue. What I noticed as well is that the fades I set on Ubuntu and Windows look slightly different. I have sreenshots attached. Maybe there is a relation to this? I don't know. (At least Linux fade looks a bit like a spring so that might explain it ;D ) My system is a Huawei Matebook 2020 AMD Ryzen 7 4800H, 16gb ram, 512gb ssd, Ubuntu 22.10 and Windows 11 Dualboot |
|
|
(Linux Screenshot was taken while holding mouse button on fade edge to prevent the fade snapping back) |
|
|
was able to finally download v. 6.9 thanks again for your help. |
|
|
I installed Nightly-Ardour on an old Thinkpad T420 with Ubuntu 22.04 and there fades do work. Although they look like the screenshot Linux.png in my last reply (little bend in the cross). |
|
|
i also have an old thinkpad (T530) and fades -- also with a nightly build -- definitely do not work here. i'm on debian 11. |
|
|
I did a Ubuntu upgrade on my Thinkpad T420 from 22.04 to 22.10. Started Ardour nightly again, Fades worked. Removed Ardour nightly, removed .config/ardour7, installed Ardour 7.1 Now Fades dont't work anymore. Maybe I did some other minor steps between removing Ardour nightly and installing 7.1 but I can't remember. Silly me. |
|
|
just installed 7.1 but am still experiencing this issue with fades springing back. is there any way this could be addressed? thanks. |
|
|
Manjaro KDE with Ardour 7.1.0. Fades < about 7 seconds works as expected Fades > about 7 seconds cannot be reliably placed. Behaviour documented in a short video at https://mega.nz/file/ZToUUAgA#_SUkK5WA3dwnvDW0P4Uiqe0C5izYXpg1AozK-RBtBvw |
|
|
I installed latest Ardour nightly v7.1-196 2022-11-30 on my thinkpad t420 and my Huawei matebook 2020 AMD, both latest Ubuntu 22.10. On Thinkpad it's gone, on my Matebook the issue is still present. |
|
|
For what it's worth, this happens to me too in Ardour 7.1.0, but appears to be fixed in rev 7.1-196-g5d42509a21 Here's something interesting to try for those who are experiencing this issue: 1. Open your 7.1.0 session where you can't make fades longer than 7 seconds in 7.1-196 (current nightly) 2. In 7.1-196, extend a fade beyond 7 seconds, save the session. 3. Open the session again in 7.1.0. Observe that the fade is still there, and is how you left it in 7.1-196 (and longer than 7 seconds). 4. Attempt to change the length of the fade. For me, each time I changed the length of the fade, it got incrementally bigger. 5. Eventually as more modifications to the fade are made, the fade will go beyond the end of the region (screenshot attached). Strange stuff indeed. (In case it's relevant, my system is: UbuntuStudio 22.04 LTS, Ubuntu GNOME desktop, kernel 6.0.11, Mesa 22.3.0. Ryzen 5900X, Radeon 6800XT. JACK + PulseAudio.) Ardour 7.1.0 fade beyond region.png (115,827 bytes) |
|
|
Sadly still present in 7.2. I was hoping it will be fixed as this is probably the most obvious of all bugs. Fades are the basic feature, so bad that other bugs were fixed instead and this was not. |
|
|
to repeat what i would hope is obvious: most/many pepople are not having issues with fades, and we cannot (so far) reproduce the error. no reporter thus far has found a reproduceable recipe. once we can reproduce it, we will fix it, but it is impossible to do anything about it before then. meanwhile, most people (on IRC and our forums) are not having this issue. |
|
|
I am experiencing this bug on both the main and the studio PC, they have completely different hardware configuration (one even has a HiDpi monitor and the other is not) but both use Debian 10 with MATE. Building Ardour from source does not change anything. Can Debian somehow be the cause? The bug was introduced only in the version 7.0 that's for sure. |
|
|
I have AMD video cards on both PCs. May be this bug is related to reading the mouse pointer coordinates? There is a similar problem with the video editor called Shotcut: there dragging the edge of a clip causes it to become more and more desynchronized with the real mouse pointer position, and that bug remains there for years because only some people are experiencing it. |
|
|
Right, we know it started in 7.0, but other than that ... we know nothing. The other alternative for a fix will be someone who is experiencing the bug and is also code-comfortable digging into it. Please believe me when I say that we'd love to fix this bug, we know nobody capable of fixing it who is experiencing it, and very few people (relatively) who are experiencing it. |
|
|
This seems highly unlikely. Mouse data arrives via a pathway completely disconnected from your video interface. |
|
|
May be this can help: that's the bare-minimum session with a single mono track with the fade-in which I set to the absolute maximum length that I could achieve by very carefully approaching the limit. |
|
|
For some reason I cannot attach the file (it's only 1.1 MB). Anyway then here is external link: https://disk.yandex.ru/d/H9ZKPbWiZObPSA |
|
|
Unsurprisingly, works without any issues here. |
|
|
I thought so, but I thought there would be some clues in the project file itself. The length of the fade in for example. |
|
|
really strange, this definitely does not work for me on debian 11, lenovo thinkpad t530. worked perfectly before v. 7.0. |
|
|
I can suppose some shared library incompatibility. Floating point problem? |
|
|
Okay Thinkpad T420, Ubuntu 22.10: Ardour 7.1: Fades do not work Ardour nightly v7.1-196 2022-11-30: Fades *DO* work Ardour 7.2: Fades do not work All three Ardours installed parallely. |
|
|
I did some further testing: 1. Empty session, add 1m35s FLAC file via drag and drop from Nautilus. 2. Save session, load into the following test setups to add a fade at the end of the audio region via clicking and dragging the fade handle. The results were the same on all of the following configurations: Ardour-7.1.196-dbg-x86_64-gcc5.run: Fades *can* be extended past 0000014:0000007 seconds. Ardour-7.2.0-x86_64.run: Fades *cannot* be extended past 0000014:0000007 seconds. Test systems: AMD Ryzen 4700U laptop, latest default Manjaro, KDE on Xorg. Intel Core i7-6700HQ+nVidia 970m laptop, PopOS 22.04, Mesa+nVidia 515 driver (pretty sure runs on Xorg). AMD Ryzen 5900X+6800XT desktop, Ubuntu 22.04, latest kernel+Mesa, GNOME on Xorg. AMD Ryzen 5700U laptop, Ubuntu 22.04, latest kernel+Mesa, GNOME on Xorg. AMD Ryzen 5700U laptop, Ubuntu 22.04 live USB (standard desktop ISO). Seems like it's reproducible on both Intel and AMD hardware at least, and across a variety of distributions and desktop environments. Session archive: https://drive.google.com/file/d/1nz763qyzPxmqiNoUYbGMvA4V2l3V_Wkn/view?usp=sharing |
|
|
Woops .. didn't realise the tilde would link to specific bug reports. The above should read: Ardour-7.1.196-dbg-x86_64-gcc5.run: Fades *can* be extended past about 7 seconds. Ardour-7.2.0-x86_64.run: Fades *cannot* be extended past about 7 seconds. |
|
|
If there really is a difference between 7.1.196 and 7.2 (which is roughly 7.1.308), it can only be tracked down (sensibly) by someone comfortable with (a) building from source (b) using git bisect. |
|
|
Just out of curiosity, I downloaded Ardour-7.2.0-dbg-x86_64-gcc5.run just now, and fades *work*. Perhaps others here who have observed 7.1.196 to work but 7.1/7.2 not to work can also try the latest dbg version too? I assume that would avoid the need for bisecting back to 7.1.196. |
|
|
In https://tracker.ardour.org/view.php?id=9057#c27050 efenstor says "Sadly still present in 7.2" |
|
|
That's right, which is why I wondered if the dbg archive of 7.2.0 works for efenstor and others here. For me it's reproducible (though I don't have the know-how to delve into git bisecting). I've attached a screenshot of both versions running simultaneously (one using a snapshot, the other using the original session.. I realise this is probably a bad idea, but seemed to work for this test at least). If others find out the dbg version works, I imagine that would narrow things down somewhat? In the screenshot: The top window cannot fade past 7 seconds, running the official 7.2.0 version: sha256sum Ardour-7.2.0-x86_64.run 1f477d474a98ccabb45a62ddf0e5349f23b9efe73d2302b1517ab35cf9a1a8bb Ardour-7.2.0-x86_64.run The bottom window can fade past 7 seconds, running the dbg version as of today (2022-12-14 UTC+8): sha256sum Ardour-7.2.0-dbg-x86_64-gcc5.run 2d638f769fd4a7fd9ee48a41f8d5b040d4a96ac82f674e48cfed4f22b20b269f Ardour-7.2.0-dbg-x86_64-gcc5.run |
|
|
If the debug version works and the regular build does not, this would be concerning since it would suggest a compiler problem. There should never be any difference in the behavior of the two versions, one is just faster than the other. You cannot use any ordinary tools to analyse the difference, certainly not git bisect, because there are no differences in the code at all. |
|
|
Just to follow up, the debug version (Ardour-7.2.0-dbg-x86_64-gcc5.run) works for fades >7 seconds on all of the previously mentioned setups (Manjaro up to date, PopOS 22.04, Ubuntu 22.04 desktop, Ubuntu 22.04 live ISO on Intel and AMD) while the official 7.2.0 doesn't. I'm not sure if it helps, but when trying to drag a fade beyond the point where it will snap back, the distance it will snap back seems to be proportional to how far it was dragged beyond that point to start with. i.e. drag it 2-3 beats past that point, it'll snap back to 2-3 beats *before* that point, like a something is overflowing or wrapping. |
|
|
Confirmed: the debug version 7.2 DOES work fine for me as well. Undefined behavior then? |
|
|
Indeed, Ardour 7.2 debug works. (On Thinkpad T420 and Huawei Matebook 2020, both Ubuntu) The nightly v7.1-196 I mentioned earlier is a debug version, too. Should have mentioned that. |
|
|
(0009057:0026965 on Huawei Matebook it was initially a non-dbg v7.1-196, on my Thinkpad it was a dbg v7.1-196, which explains that behaviour) |
|
|
I'll try playing with different compile options, may be I'll find the combination that works for the optimized build. It would be good to know though where to begin. Currently trying compiling with clang but I don't think that will change anything. |
|
|
Actually clang helped! Compiled with CXX=clang++ ./waf configure --optimize --freedesktop and there is no bug anymore. |
|
|
That is simultaneously very helpful but also very worrying. There's the additional wrinkle of course that the precise same version (built by gcc) works on some systems but not on others. |
|
|
I have the same problem. With official download 7.2 the fades are snapping back, and with dbg from nighly builds ((rev 7.2-32-ge32d4f7b71) Intel 64-bit - debug) it works as it should. I'm on Ubuntu 20.04.4 LTS with i3 window manager. |
|
|
I also tried with exactly the same nightly build as mentioned above but NOT the debug version, and the bug is present - the fades again *do* snap back. |
|
|
Manjaro KDE Ardour 7.2.0: long fades misbehave Ardour 7.2.41-dbg: all fades behave Attaching the dbg log for 7.2.41 Ardour2022-12-21.log (89 bytes) |
|
|
Steps done in both versions are the same: 1. open a new session (recording template with 2 tracks) 2. Import the same wav file (download from Freesound) 3. Change fade-in to 10 seconds Fades in 7.2.0 "snap back" to some arbitrary point (5.217 sec). If I try to make the fade 12 seconds long, it snaps back to 3.217 sec. At 11 it snaps back to 4.217. Fade-ins up to 7.5 seconds stay in place. If the clock shows bars / beats, the "limit" is at bar 5 - fades shorter stays in place, longer fades snap back. Longer fades snap longer back. Fades in 7.2.41-dbg stays in place. |
|
|
In the screenshot above, the audio-region is "glued to bars and beats" -- are you also using a music time grid and snap to grid? are there tempo-changes in the session? I expect that if you disable snap to grid, change the time-domain of the region to audio (and/or remove all tempo-changes and/or use a timecode grid) things may work. |
|
|
@x42: I couldn't untick "Glue to bars and beats" in the Position menu, should that have been possible? I tried turning off snap to grid, and changing the time display to timecode, and various combinations of snapping. Nothing seemed to change with fades, they always snapped back if they were dragged to be longer than 0000014:0000007 seconds. I didn't create any tempo changes or anything else in the session, it was just a new session using an empty template, and adding a single WAV file. I'm very curious why the debug version works as intended, and why efenstor's clang compiled version works as well (though I haven't tried that here). |
|
|
Hi I created a new session, imported a single audio file. I tried with snap on or off, with different snap setting, changed the tempo and time signature, nothing influences the behaviour. If the the end of fade-in point / handle / is moved beyond 7.608 seconds, it will snap back to position that is a mirror from the 7.608: if moved to 7.808, it will jump to 7.408 15.216 => 0 15.416 => 0.200 etc. It's a ping-pong wrap/modulo? this is in ardour-7.2 from the website and in nightly Ardour-7.2.32-x86_64-gcc5 it does not happen in Ardour-7.2.32-dbg-x86_64-gcc5 also, this is at 48kHz sample rate. |
|
|
just to add some more information * zooming in, the wrap point seems to be at approx. 7608.6 milliseconds. * different sample rates make no difference - tried with both 44100 and 48000Hz. |
|
|
Fixed in Ardour 7.2-97-g6407ca51cd |
|
|
I can confirm that on my system in a nightly build rev 7.2-101-gb0f5fea53a the repported behaviour is not present anymore and that fades can be applied as expected. thank you Ardour devs!, @x42 |
- Anonymous
