Congratulations on the new release! I've seen some forum discussions on this in the past, and I'd imagine it's a frequently debated topic. However, I'd like to ask about the technical feasibility of implementing a feature similar to Ableton's 'Warp' within Ardour. I understand that Ardour and Ableton have fundamentally different architectures and that different DAWs can prioritize different workflows. Given the current state of the codebase and the development roadmap, I'm curious how realistic the implementation of BPM-synced time-stretching actually is or if it remains significantly outside the project's scope.
I had an excellent experience using niri to manage visuals for a university event recently. I was handling background loops, videos, and slides, and since it was a last-minute setup I had to improvise the entire workflow. The scrollable layout was perfect for this, I organized the windows horizontally in the exact sequence they needed to appear, which effectively turned a mix of an image viewer, video player, browser, and PDF readers into a seamless presentation (I could just have used the browser but it would have felt clumsy in comparison). The ability to keep everything in fullscreen and instantly exchange windows between displays via keyboard shortcuts made the transitions almost invisible to the audience.
PS although the add-on was removed from Mozilla’s add-on store (AMO) (because of DMCA Takedown Notice) it’s still signed and manually checked for security by Mozilla (hence the delay in signing).
That explains why I couldn't find it. I believe this is the most comprehensive and up-to-date paywall bypasser out there.
What is the actual complaint here? Are people demanding commercials be beautiful? Before being AI slop, it is marketing slop. Why are they demanding 'soul' from an ad in 2025? Everything in this late-stage capitalist landscape is slop. They could have filmed it with real actors (or just reprised a spot from 15 years ago) and it wouldn't make any difference.
"In 2025, YouTube started rolling out a new streaming protocol, known as SABR, which breaks down the video into smaller chunks whose internal URLs dynamically change rather than provide one whole static URL. This is problematic because it prevents downloaders (such as yt-dlp) from being able to download YouTube videos at resolutions higher than 360p due to only detecting format code 18 (which is the only format code available that doesn't use SABR). So far, this issue has only affected the web client, so one workaround would be to use a different client, such as tv_embedded (where SABR has not yet been rolled out to), so for instance in yt-dlp you could add --extractor-args "youtube:player_client=tv_embedded" to use that client. It is not known how long this workaround will work as intended, as YouTube rolls out SABR to more and more clients."