Hi! New X-Touch owner here. I noticed a few things that led me down a few small rabbit holes that I’d love feedback on.
meta-question: what’s the best way to talk about dev? The mailing list I found seems pretty dead. Should everything just be made into a bug and then discussed there, or is the forum truly the best place for code-related questions? (Edit: I just discovered the IRC link I was using was outdated, so I’ll try libera.chat!)
So, some problems that jumped out at me…
strip colors are not updated immediately
strip colors reflect the current track color, but I thought it might be nice if they were modal; eg, changing to a different color for ‘plugin’ subview, for example
EQ/INST = EQ/Dynamics (mixbus); is there some reason we are not mapping those to (eg) the first eq/compressor on the strip for both mixbus & ardour?
Details…
A previous comment said, “The notification about color changes will be a PropertyChange signal, with the argument containing (at least) Properties::color, so you need to attach a handler to that signal from the Stripable’s PresentationInfo” (Summary of the X-Touch - #10 by comgang). On Master in Strip::set_stripable, I do see _stripable->presentation_info().PropertyChanged.connect () called, so I’m not sure what’s missing but I’d love to fix this but might need a pointer.
I made a patch (against master) to set the strip colors to static colors when in track/send/plug-in subviews, because I realized (as nice as it was to, for example, have some tracks be red for identification) that tweaking plugin settings was actually painful when the colors were wildly different. I don’t know if it’s a desirable feature for others, or if I implemented it poorly. What’s the best way to seek feedback?
I figure that even on mixbus, you might want to use different eq/dynamics plugins - wouldn’t it just make sense for the eq/inst(dynamics) buttons to select the first eq/dynamics device on the chain for a track?
I’m relatively new to docker, but I built up a nice shareable environment to build ardour in a containerized manner that was immensely helpful for me. https://ardour.org/building_linux.html seems really out of date - wouldn’t we want to make it easier for everyone to build and contribute to it? Is that open for updates?
I also have random questions about using vscode/codium with waf if this is the appropriate place to ask…
I’m too old-skool to really make good use of VSCode, but I have dabbled a bit. If you have a Docker image that works for you to ease building Ardour on Linux, then you might consider publishing a devcontainer that uses that image in a fork of the Ardour repository.
Casual users can even use that devcontainer as a “codespace” in their own forks (so that the Ardour crew don’t end up paying for the codespaces).
I really liked that idea as well and I already started trying to use dev containers in vscode (well, codium). I haven’t had any success yet, though (extension problems: it tries to wget a non-existent file for installation into the container). I don’t know if it would make sense for the dev container to be part of the same repo - why do you think that is a better idea than keeping it separate? Perhaps a single repo of various dev containers might be nice for different build targets.
There’s the label on the can: “We do not make regular efforts to keep this page up to date.” …
Sorry, Paul! I may have misspoken when I said, “seems really out of date” - I was oversimplifying and just expecting to find more depth. I was able to install dependencies for my platform, but it would probably be useful to list them (even if not by package name) - the list obviously extends well beyond gcc, git, python, and jack.
There’s not discussion of configuration options, what compilers might work (though gcc is called out as a dep), how to enable debugging (specifically how to use DEBUG_TRACE - though that probably belongs on https://ardour.org/debugging_ardour.html), etc. These are relatively small things, but they create a higher barrier to entry. The mention of ‘ardev’ was absolutely brilliant and I would not have figured that out on my own though! (although I did note that I had to build into the tree to use it; I like to set --out to something outside of my git tree and that broke it). I would say that it accomplishes its job as a minimal doc. In the end, I found the ubuntu source package and looked at their build rules as my own basis.
What I’m personally looking for is something that is perhaps less linux-specific and belonging more on https://ardour.org/development - eg, how does one begin to develop in this project? Perhaps something like dev containers could help, and I’ll see what I can do. I’m also curious about software processes for patches - I’m guessing that I should throw a branch up on github and ask for feedback, but I don’t know how formal the process is, if there are tests that I should be running first, etc.
I like Ardour and really appreciate the hard work that people have obviously put into it. I’d love to help improve it even a little bit if I can!
Well, the thing is … the two main developers don’t really go in for this web-inspired container development model. We also both use Debian, which means that building ardour looks like:
and that’s the end of the story (for us). Debugging is enabled by default. There are almost no configuration options that are of any significance for developers, other than the incredibly handly --address-sanitizer which we both use all the time to find bugs before they bite us, and --backtrace to make code-drive stacktraces possible.
My intuitions are likely borken here: I haven’t made use of either devcontainers (the abstract model) or codespaces (the Github-specific concrete implementation of the idea) except for work on a client’s private repo. There, the client pays for the usage costs, because their dev team can work with the stuff I’ve built without needing to go through the “how do I get everything installed to be productive?” weeklong dance.
I have successfully used a devcontainer spec I wrote originally for that usecase (other devs using it on Github) with a remote host over SSH. For the Ardour case in particular, I can’t see the win for using it (or VSCode, actually, but that is just me) on a local machine: I’m perfectly capable of installing all the dependencies Ardour needs myself.
Docker / VScode - I’m somewhat new to Docker and brand new to VScode, but I was able to get everything working together to my satisfaction. I’m a ctags/cscope/vim person, but I’ve never been satisfied with using those tools to learn a codebase (follow references, develop call graphs), and honestly I’ve never loved using gdb for debugging. I only needed a little bit of work to get builds working in Docker, and a bit more work to get everything working in a Docker ‘dev container’ in VScode - but I now immediately see benefits. I suspect (hope) that other devs would see these benefits quickly as well:
you can very quickly configure N build / test environments with whatever distributions / versions of libraries you would like to build against
you can very easily communicate an environment in a few lines of code to others to help reproduce a problem that might only appear in a particular environment
everything about the build environment is decoupled from your local OS (local upgrades cannot break builds)
you are able to pass through JACK and ALSA to the docker containers, so you can in fact also run and debug the code in the containerized environment while accessing your real host hardware, which allows you to execute against the libraries you built against
vscode allows you to use the clang extension (and others) for better insights into the code, and is more accessible for some developers
In summary: flexibility, portability, reproducibility, and better debug features. Here are two quick demo videos of how to build and execute/debug with Docker and VScode:
There seems to be a supposition here that “decoupling your development environment from the host OS” is a win.
I’m not clear why this is.
We do this (using a much simpler system) for our build process, where we need a defined set of libraries that are independent of the host OS.
But as a developer, I have no reason to care about that on any day to day basis. I don’t need N different environments for working on Ardour, I just need one, and stock Debian (along with stock-just-about-any-other-Linux distro) is just fine for that.
We already use clang extensions, we just don’t use clang for our Linux executable builds (e.g. we use it for static analysis etc)
I am guessing that we have had rather different experiences in development and test, and if your experience does not support the same supposition then you are blessed. Developing and debugging natively on a host indeed keeps life simple; my only intent was to offer additional options without impacting the native workflow.
If it’s not interesting to anyone else, let’s move on - it is helpful for me and I like to share work where I can, but I’m more interested in the original focus of this topic. Thank you!
