But that would mean we wouldn't use Jack, by order of the Dev.
There would be no point in using a computer at all.
Moderators: MattKingUSA, khz
But that would mean we wouldn't use Jack, by order of the Dev.
Let's see. What problem would be solved if endusers could download binaries (instead of compiling code) tested and known to work on a standardized, minimal base system for music?merlyn wrote: What problem would (ease of use) solve?
I've done that for some of my systems. But that's moot to the issue of wanting a minimal base standard for music development/deployment. Think of it as a music-focused addendum to the LSB. It just happens that AV Linux is the closest to that goal. I have no problem with some other entity stepping forward and doing the work. I just want working results, and I want them as soon as possible. Right now, I see universal binary support for AV Linux as the quickest means to the end.point of Linux is that you can choose the OS with the features that you like
Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
A bit of both. But yes, you will have to explain. You haven't clearly stated the problem. If the problem is that you're too brain damaged to use a compiler, that's more of a jeff problem than a Linux problem.
If your Distro is AV Linux then both MuSE and Qtractor are at the very latest versions if you use the MX Package Installer and install from the 'MX Test' Repo tab...j_e_f_f_g wrote: ↑Wed Aug 03, 2022 8:17 pm Of course, appimage files, while not my preferred choice, at least nudge the ball forward. I'm finally able to use newer versions of Muse and QTractor in lieu of the ancient relics found in my distro's repository, just because there are appimage binaries. But, I'd prefer my preceding solution.
That's exactly it. It is a moot point for you. It isn't for me. When a developer releases a new version of their plugin that uses a version of glibc newer than what is provided in avlinux I want to be able to use it. You might not care but I do. I want to run the newest kernels and the newest versions of yabridge, etc. It's part of my workflow. Building everything to work with one OS wouldn't work for me and it shouldn't be the norm. I don't find it hard to setup or maintain my Manjaro system and what's more it's getting much easier all the time. Furthermore, as a rolling release I haven't needed to reinstall in years and am still up to date. The base kernal has preempt built in as well. I think Avlinux is a fantastic OS. I used it for years. It isn't right for me at this time though. This sounds like a you problem.j_e_f_f_g wrote: ↑Wed Aug 03, 2022 8:17 pmI've done that for some of my systems. But that's moot to the issue of wanting a minimal base standard for music development/deployment. Think of it as a music-focused addendum to the LSB. It just happens that AV Linux is the closest to that goal. I have no problem with some other entity stepping forward and doing the work. I just want working results, and I want them as soon as possible. Right now, I see universal binary support for AV Linux as the quickest means to the end.point of Linux is that you can choose the OS with the features that you like
Of course, appimage files, while not my preferred choice, at least nudge the ball forward. I'm finally able to use newer versions of Muse and QTractor in lieu of the ancient relics found in my distro's repository, just because there are appimage binaries. But, I'd prefer my preceding solution.
What makes it easier, in comparisson to Manjaro, Debian, etc? e.g. on Manjaro, i install let's say ardour and jack and it's running.By using AV Linux, setting up a music system will be as easy for endusers as any other OS.
I don't understand why this should be easierPeople having problems with other distros will be able to quickly identify whether a problem is software or hardware related just by running their system under an AV linux live boot distro.
On Manjaro for example, this works flawlessly. I guess on arch, too, probably also on gentoo (but Manjaro is the point because it's targeted to common users who simply want to have a running system).Endusers will be spared the horrible, unnecessary experience of compiling software
Not better than on other distros, i think. How will this be reached?Conflicts between apps can be better resolved when developers are testing all apps using a standardized music base.
I know a few musicians to falsify that point, layer 8 is everywhere...Less time will be wasted on trouble-shooting and enduser technical support.
I guess, Glen is the maintainer behind AVLinux? Maybe you should have a look on organization on slackware linux: that's a one man show by Pat Volkerding. There are a few people around him, but in the end, he's the guy behind it. It's a full time job to maintain a distro with professional requirements. It rises and falls with illnesses, income and a lot of things around, that have nothing to do with the distro itself.By having developers create the AV linux binaries of their software, this frees up Glen to concentrate on documentation and advancement of the base system. In fact, perhaps he can work on a "music app-store" type of program in which devs send him download links to their binaries, and he adds those to the "app-store".
Right, but that's a personal thing: for that reason, i prefer Slackware over e.g. Mint or Debian. Other people do vice versa.The only applicable influence of human nature here is that people tend to like things that are easy and effective.
That's the right question. All the great and stable Software we have under free licences initially solved a problem and was adopted by other people with the same or a similar problem and then evolved.What problem would that solve?
Currently working with
https://www.honeysuckers.rocks/?lang=en
Fiddling with sequencers does not evolve into music necessarily and Mac users have smelly feet and guzzle little children.
Well alright. You don't have much choice but to compile the software from sources. And you would still have that option even if music developers also adopt a particular distro as a minimal base standard for testing/deploying their binaries.Robin Cherry wrote: I want to be able to use (the newest kernel, libc, etc)
No. The apps, compiled from sources, should work for any distro. "Everything" is not being limited to "one OS". Only the binary would be tested/deployed to a base standard.Building everything to work with one OS
Exactly. It's not realistic to expect otherwise.GMaq wrote: new Plugins and updates to existing Plugins a team of 10 people couldn't keep up with it even if a grizzly bear was chasing them
This is pretty much what I do in providing folks with a downloadable binary of BackupBand (in lieu of doing something like AppImage or Snap). It seems to work. But, I'd feel more confident if there was a "minimal base standard" for music app (binary) testing/deployment.Plugin developers should provide ready to use binaries and they should be compiled on a one-version old Debian Stable or Ubuntu-LTS
To be clear, I'm not suggesting rebooting after each line of code you write. I'm suggesting either "Do all your music app development on a copy of AV Linux" or "When it comes time to make your finished app available to the public, boot to AV Linux, make a binary of your app, test it, and then release it".tseaver wrote:a reboot-to-the-separate-partition dance that Jeff seemed to be suggesting
Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
You've blown any cred you might have had with me. I find that idea -- Snap, AppImage, Flatpak truly horrible. I prefer the idea of using a package manager and the system libraries.