Open meyertime opened 3 years ago
You are right, the git version has some good improvements. Unfortunately we never got a stable developer base for this project (everyone just wants to make music :))) and recently I hardly found time to hack on it. Having a buzztrax-git package might be a good idea. The current git version has some partially implemented features and I am reluctant to release it as it is.
I hear you on finding time... I am not even sure when I will have time to try out Buzztrax. But when I do, I will use the latest code and look into adding a buzztrax-git
package.
Are you tracking those partially-implemented features anywhere in case I am able to work on finishing them in the future?
I just filed https://github.com/Buzztrax/buzztrax/issues/99 to track the major issue this project faces.
Unfortunately we never got a stable developer base for this project
That's unfortunate. Buzztrax seems like a really innovative project for modular synthesis.
The package from 2015 doesn't render the UI elements correctly on my Ubuntu 21.10.
For some of the UI issues I am afraid the pace of the OSS community is to blame. I've started buzztrax on gtk+2, posted to gtk-3 and replaced deprecated gnome-canvas with clutter. Now clutter is not supported anymore and I'd need to rewrite the whole canvas stuff again for gtk+4 :/
Since a rewrite would be required to stay on the GTK train, what about considering a move to Qt? The Qt stability/backward compatibility story may be a bit better than GTK, and a major Qt version (6) was released recently (after seven years of Qt 5 development):
https://www.qt.io/blog/qt-6.0-released https://www.qt.io/blog/2019/08/07/technical-vision-qt-6
Also going from QT4 to 5 (or from 5 to 6) is not without pain. And rewriting everything from c to c++ is not easy peasy either. In the end it is really a matter of helping hands. The git version has a couple of fixes, so maybe I'll get a new releasse out and then we'll see.
Random idea: let's port to web! Most Web APIs will not break for a very long time. :) If we compile the audio engine to Wasm (plus allow Web Audio hook ins), we can rebuild the UI in web, and we can also more easily distribute cross-platform released with ease because the browser vendors took care of the tedious cross-platform builds.
It's a pipe dream, but if some focus is put on decoupling the audio engine (if not already, its been a while since we last chatted about this), the more maintainable it will be moving forward, especially important for a single-person-sometimes-one-or-two-more-people project.
I've still been working on Lume, HTML elements for GPU-powered graphics. It would be neat to make web-based audio-visuals with it. We could experiment with 3D node graphs, not just 2D (for the machines layout). Etc.
I think it would be a total rewrite. the audio engine is heavily multi threaded and I think this is still a challenge for wasm. But I agree, it would be awesome - apps like sounds-trap show that it is possible.
Hi, I'm not sure if this is the best forum, as this is more of a question than an issue.
A little background: I'm a long-time Buzz user from back in the day and former Windows user who switched to Arch Linux about 2 years ago. I've read about Buzztrax and I'm considering using it to try to get back into making music again.
It looks like the last release was from 2015, yet there appears to be regular activity on the master branch since then. Which is better to use? The old release or the latest code?
If the latest code, I'd prefer to install it through the AUR. Commonly a package like
buzztrax-git
would be set up which would install from the latest source rather than download the last release. Any chance we could set that up? I'd be willing to contribute, though I admit I'm new to Linux development and might take me some time to figure it out. Any tips you could offer on installing it on Arch would be appreciated. Thanks!