Why not create a pull request to update the Linux docs?
because I dont know how to do this, hehehehehehe.
Ok, I will try to do that this night.
Every Unix flavor build will have its own specificity. Ubuntu 18.04 (which is the one I initially built BBM on) requires extra libraries to work that in the subsequent versions of Ubuntu become part of the official repo… And what about Arch, Mint, or others…
Building the software should be a matter of developers. So the instruction should guide you on how to build the software. The more clearly the better, by explicitly describing the dependencies and versions required. But it is very unlikely you can provide accurate information for each and every distro on which package has potentially to be built…
What is now important is that Singular Sound put in place an official CI/CD based build for each platform (And for Linux I suggest the AppImage format which would allow the software to run on every flavor of Linux without the need to tweak anything). And the official built releases should be available here for Windows, Mac and Linux… So that having the latest version of BBM is no more something for developers…
Linux users are not allways “end users”… And I think that end users as betatesters are interesting too…
In any case, as u wish, you have more knowledge about the projects needs.
Not sure I get what you mean there, but even if on Linux, there is probably a lot of users who are actual developers or power users, “standard” end-users exist as well (I know a lot). For them, but not only, any software has to provide a kind of binary packaged delivery. Especially as here we are not only talking about beta, but the official releases…
The point is that due to the rich Linux distros ecosystem, there are various packaging formats (debs, rpms…) and package managers (apt, urpmi…). Obviously having distros specific packages is super nice, but I doubt that for a niche software like BBM is, it is reasonable to request to have distros specific packages. Then remain some distro-agnostic packaging mechanisms, like Docker Images, Snap packages or AppImage format. I doubt a Docker Image would really be relevant for something like BBM, Snap could be nice, but AppImage is fairly simple and does not even require a host deamon (like Snap would).
I don’t want to stop you in anything you would like to do. Improving the doc is always valuable. If you do a pull request, just ensure you remain consistent with the rest and create a specific paragraph for your distro version (19.10). I do not have much more knowledge than you may have about the project needs.
Any version of this available for the mere simple Windows users. I would like to be a beta tester if allowed.
1 Like
Also add Flatpak to these it is a quite good one…
tbh if the devs created a package for just ONE of these distribution systems it would be a great help and get away from the rampant Linux snobbery that exists.
Yep, I forgot Flatpak, and there are probably some others around…
But AFAIK Flatpak, like Snap, requires a daemon pre-installed on the machine you want to install packages to.
To my knowledge, only AppImage has absolutely no requirement for the Linux machine you want to run it onto. You just download a big executable and run it, fullstop (you could have a daemon, a bit like the other contenders, to manage icons, desktop shortcuts or stuff like that but it’s fully optional)…
On top of this, unlike Snap and probably Flatpak (tbv), it doesn’t require to publish your package in a kind of store, which makes another good point for releases directly published within Github as a result of official builds (I see more and more releases in this format in Github-hosted open source projects).
In a nutshell Apt, Urpmi, Snap, Flatpak (, …) are package managers, whereas AppImage is just a portable distribution format.
Last but not least (but that’s probably the case for the others, but at least for AppImage I know it exists), there is even a qmake recipe to easily integrate the image build as a standard build target.
Yep, fair.
Would really love any sort of update as to what is being worked on in the open source BBM? Can anyone who is involved with it maybe give us a bit of a run down?
Thanks guys!
What I can tell from the code repository activity, is that there is not a lot happening.
If you look at what has been done, if you look at the commits content you see that it’s basically bugfixes. I didn’t open all the PRs, but I checked 10 randomly and it was the case.
If you have a look to what is pending or ongoing, it mostly bug reports or simple UI enhancements. Nothing fancy. And it doesn’t look like activity is increasing.
And I didn’t find any roadmap or target release content… Maybe someone can add to this.
2 Likes
Agreed! I have been watching for a while as well. Not much happening.
Lots of bugs. Too bad I can’t code
Singular Sound should own this and make it happen.
I have been hoping for years.
Very disappointed. 
1 Like
Yeah it is disappointing. I was hoping we were going get some standard features added (copy, paste, play from cursor position etc) and bug fixes, especially with someone from SS being dedicated to working on it but just doesn’t look like it’s going to be happening. Great pedal, crap software!
2 Likes
I’ve been saying that for years.
The potential of BeatBuddy is untapped because of software limitations.
2 Likes
Exactly! I know SS say ‘you can use other software to put the MIDI together’ which of course you can but you still need the BBM to compile it and fine tune it before putting across to the pedal. With software that can’t even do basic functions that has been a part of computing for decades and full of bugs it really lets the pedal down, and I hate to say it but let’s Singular Sound down too. Great innovative products but in regards to the BB let down by half finished software.
2 Likes
My confidence in their products is now shaken.
Why would I take a chance and buy another device?
Step up Singular Sound and pay someone to bring the BBM up to date.
3 Likes
This is it I think. Pay someone to make the BBM the beast it could be and the beast it SHOULD be.
1 Like
Pretty sure SS is (and has) paid people to work on this. Suspect this is much more than anyone would expect without anything shipping.
It’s likely much of this work and money has been ineffective and poorly managed.
1 Like
The point is that, as usual, there is a misconception about Open Source.
The code has been released end of May. So I understand people need to organize (maybe it could have been thought beforehand) in order to transition to an Open Source governance.
A lot of people/companies think that providing the code is enough to be an Open Source company. This is not the case. If you want your open source project to be successful there are a number of pre-requisites to absolutely put in place:
- Having a fully automated CI/CD infrastructure is a must-have. For non-CS guys it means that everything is automated from code delivery to build packaging and availability of the built package (and in this case multi-platform). This is not in place.
- Having some code design documents to ease the work of anyone that would like to contribute. Explain the goals of the design for the people to understand the “philosophy” of the code. This is not in place. Some languages or frameworks make this obvious by design, this is not the case of C++/Qt thus the need to document it.
- Put in place a clear governance mechanism. Let’s say half done. The nature of Github-like tools makes it easy to submit bug reports, Pull Requests… But this is neither governance nor vision…
- A number of mandatory things, like … a Licence (although the “about box” of BBM states GPLv2 this is nowhere in the repo, which I doubt is really legal, but I am no expert in licensing… what I can say is that I’ve almost never seen that…).
C++ is not the easiest language to step-in, so if SingularSound wants to give a chance to the project they definitely need to focus on these (normally preliminary) tasks, but with tangible results and deadlines !
We could keep on asking new features / bug fixes, but I really think we should just give Singular Sound a bit of time to turn towards that new organization, because if they don’t the project is doomed to die.
Today the activity is mainly bugfixes and there is no vision and I am afraid it will remain the same until pre-requisites are fulfilled.
1 Like
All 100% agreed.
Can I add: don’t do long periods of internal development. The public repo should be the repo. I’m not willing to put time in fixing bugs that might already be fixed or developing features that might require a huge refactor when the next code drop from upstream adds a thousand new commits and I have to rebase.
While open source does bring a lot of benefit to a corporate project it isn’t just a way of getting free developers. And at the moment it seems that’s a little bit what singular seems to have expected. That being said: perhaps I’m overly cynical. It might just be that they’re a small company and development is hard. Managing open source is a skill in itself, and maybe they need time to get to it.
3 Likes