Cool new plug in format on the way -- CLAP

[EvilDragon]

But I'm not offering advice on Linux?

[chmaha]

Originally Posted by EvilDragon

But I'm not offering advice on Linux?

Never mind.

[Xasman]

Originally Posted by EvilDragon

Correct. SC is a complete antithesis to Kontakt. There's even no disk streaming and no timestretching!



DFD is not a planned feature for SC, for the time being. The main goal of initial SCXT release is to attempt and provide feature parity with SC1 and SC2 (and try to reconcile any differences they have), and maybe extend certain aspects a bit (4 instead of 2 effect slots per zone, more matrix slots, etc.).

OK - thanks for the info. I'm still not going to buy Kontakt, though. The challenge/response copy prevention alone rules it out for me in any case (as a matter of principle).

[Glennbo]

Originally Posted by Xasman

OK - thanks for the info. I'm still not going to buy Kontakt, though. The challenge/response copy prevention alone rules it out for me in any case (as a matter of principle).

I bought a license for Kontakt back when I ran Win7 so when I switched to Linux, I deactivated the Win7 license and reactivated in WINE. Seems I only needed to run Native Access and it was all happy.

That said, I won't be buying any additional libraries for it, or installing any new Windows plugins at all in the future, because I'm only supporting native Linux vendors with cash from my wallet.

If there were a native Linux alternative, I would buy it and retire Kontakt. I used to run GigaStudio96 and have a fairly good assortment of .gig files that do work in LinuxSampler.

[audiojunkie]

Originally Posted by Xasman

OK - thanks for the info. I'm still not going to buy Kontakt, though. The challenge/response copy prevention alone rules it out for me in any case (as a matter of principle).

Your best bet, as I mentioned above, is LinuxSampler (along with gigedit, QSampler, etc) It supports Gig, SFZ, and SF2. It supports more SFZ opcodes than most other plugins (comparable with Sfizz). I personally have about 60Gb of giant high quality multisamples. It's really great! It's a full-blown, feature complete tool. :-)

The "ONLY" exception is selling the linuxsampler code commercially. Everything else is completely GPL'ed. The reason you won't find it in strict open source repositories is because of that single clause. See below:

https://www.linuxsampler.org/faq.html
Can I use LinuxSampler in commercial hardware or software products?
You are NOT ALLOWED to use LinuxSampler source code, libraries or applications in COMMERCIAL hardware or software products without prior written authorization by the authors. See here

Can I use LinuxSampler for commercial music production?
Hell, yes! Every indirect commercial usage of LinuxSampler, which essentially means using its audio output, can of course be used in commercial applications like music productions, live shows, etc. Don't get us wrong, with the mentioned commercial exception we don't want to restrict the normal user / musician, we just want to avoid somebody to directly make money with our work, that is by selling our software in a sampler product like a sampler + sample library bundle, a hardware sampler or something equivalent, at least not without giving something back to the open source Community.

LinuxSampler is not open source, you are evil!
There are of course many definitions of the term "open source", but according to the definition on Wikipedia LinuxSampler is in fact open source, since you've got complete access to its source code. So due to this fact, a normal user / musician is free to do with LinuxSampler what he likes to do, he can even adjust and tweak every single part of the software by modifying and compiling its source code. And just the fact that we want to avoid our work to be directly exploited in commercial software or hardware products is definitely not an "evil" intention. For the normal user / musician the commercial restriction is even an advantage, since that way commercial actors are forced to support this or another open source project either directly by coding or indirectly by funding and thus increase development speed.

Will LinuxSampler turn closed-source?
No, LinuxSampler will remain open source. Again, the commercial exception is just to prevent commercial exploitation by third parties that haven't contributed anything to open source projects.

I've heard the commercial exception of LinuxSampler was added at a certain version?
No, the commercial exception in LinuxSampler's license terms were there since day one. Even further it's not only there since the very first publicly available CVS (developer) version of LinuxSampler, that commercial exception was even already in Benno Senoner's proof of concept code called "EVO", which LinuxSampler was based on. There was even a rumour that we would have manipulated CVS history to "pretend" this exception wasn't added at a later point. Needless to say that this rumour is completely false as well. Think about it! We're a group of developers spread around the world who work on this project for fun and ideology in our spare time. Most of us contributed to various other open source / free software projects. Do you seriously think we would cheat on such an issue? Beside that you certainly find various people completely unrelated to this project who still have early versions of LinuxSampler and / or EVO and thus can confirm that this commercial exception was always there.


You can get it very easily regardless of the distro you are using:

Debian family (Debian, Ubuntu, Mint, PopOS, etc): Use the KXStudio repository

Fedora: Use find it in the COPR repository

Arch family (Arch, Manjaro, EndeavourOS, etc) Use the AUR repository.

Open Suse: Use the OBS repository.


You don't have to compile it yourself to use it.

[Xasman]

Originally Posted by audiojunkie

Your best bet, as I mentioned above, is LinuxSampler...

Thank you, audiojunkie, for that massive missive!

I remember trying Linux Sampler a few (come to think of it, many) years ago and it was terribly unstable (as well as not seeming very user-friendly), for me at any rate, at that time. I think that experience has automatically ruled it out in my mind as an option ever since, probably unfairly as that was, as I say, admittedly a long time ago.

I'll take your advice and check out the current version, especially as you recommend it so highly.

[Xasman]

Originally Posted by Glennbo

I bought a license for Kontakt back when I ran Win7 so when I switched to Linux, I deactivated the Win7 license and reactivated in WINE. Seems I only needed to run Native Access and it was all happy.

That said, I won't be buying any additional libraries for it, or installing any new Windows plugins at all in the future, because I'm only supporting native Linux vendors with cash from my wallet.

If there were a native Linux alternative, I would buy it and retire Kontakt. I used to run GigaStudio96 and have a fairly good assortment of .gig files that do work in LinuxSampler.

I get what you say here - makes sense. My only question then is what's stopping you from retiring Kontakt now and moving over to Linux Sampler straight away?

[Glennbo]

Originally Posted by Xasman

I get what you say here - makes sense. My only question then is what's stopping you from retiring Kontakt now and moving over to Linux Sampler straight away?

I'm using LinuxSampler for some things already. My goto piano is now a .gig format Yamaha grand piano from the LinuxSampler site, but when it comes to horns and strings, the Factory Library that comes with Kontakt is more playable than most of the horn and string samples I have in .gig and .sf2/sfz format.

[audiojunkie]

Originally Posted by Xasman

Thank you, audiojunkie, for that massive missive!

I remember trying Linux Sampler a few (come to think of it, many) years ago and it was terribly unstable (as well as not seeming very user-friendly), for me at any rate, at that time. I think that experience has automatically ruled it out in my mind as an option ever since, probably unfairly as that was, as I say, admittedly a long time ago.

I'll take your advice and check out the current version, especially as you recommend it so highly.

Here are some tips:

1. LinuxSampler (the engine) is separate from the GUI. You choose LinuxSampler as the option when choosing the plugin for your track, and then you open the GUI as a separate program to make the changes to the LinuxSampler engine. It's different from most plugin programs.

2. Because the LinuxSampler (engine) is decoupled from the LinuxSampler (GUI), there is more than one front end GUI available for LinuxSampler. Use Qsampler. I believe it is the easiest and the only one still getting active development.

3. When you go to load a sampler through the QSampler GUI, choose the same sample engine of the multisamples you are using. You have three options, Gig, SFZ, and SF2. Once you have chosen the engine that matches your samples, load your sample file.

4. As long as you have your midi channels set right for your keyboard, you should now be able to listen to your playing of the samples.

NOTE: There's a lot more that can be done. For example, you can load up 16 channels of samples per port, but you can load multiple ports to have as many multisamples as you need (in batches of 16) For example Port0 Channels 1-16, Port1 Channels 1-16, etc..

I really like LinuxSampler! In my opinion, it is the best native Sample player available in the Linux world for large DFD multisamples.



Edit: Be sure to not only install the LinuxSampler Engine and the QSampler GUI, but also GigEdit so that you can create/modify instruments.

Also, Be sure to install the dependencies it uses if you run into problems. It should pull them in by default in most distros, but it may not in some.

There was something else.....Oh yeah! You will notice that you don't have any controls for essential functions such as ADSR and such. Use Reaper automation and CC controls to set things exactly how you want them. Because it's automation, you can also make changes to those settings while playing.

Best of luck!

[Glennbo]

Also, because LinuxSampler is a client/server relationship, if you use multiple instances of it, you have to keep close tabs on what midi channels and midi busses you have already used, or you end up with tracks in REAPER with contention about what sample set should be loaded for a specific midi bus and channel.

[Lynx_TWO]

Originally Posted by audiojunkie

I've already been down that road. None of the sample converters can translate the encrypted monolithic formats, including Native Instruments. I've got arguably the best converter available (by ChickenSys), and it's still a "nope". Very early versions of Native Instruments samples that weren't encrypted could be translated.

This one is QUITE different; basically, you set it up to play and capture a range of velocities and notes over your set period of time (5 seconds per note, 10, 15, etc), and then SampleRobot goes ahead and plays your request through the Kontact player capturing the resultant sounds, and then builds a new instrument in whatever format you want. It takes a while, (easily calculatable based on time selection and the number of velocities and notes; I'd run it overnight), but when you are done you have a usable format to use elsewhere. I believe there's also an option to auto-find loops in the sounds for a suitable sustain. Of course, it's not going to have the scripting that Kontakt has, but since it captures the resultant sounds directly through Kontact, you already have a very usable instrument - certainly much better than converting each library to WAV through Kontact and then trying to manually build a library from those.

And yes, there's a demo.

5 seconds at 128 velocities and 96 keys would be 17.07 hours to capture, for example.

[audiojunkie]

Originally Posted by Lynx_TWO

This one is QUITE different; basically, you set it up to play and capture a range of velocities and notes over your set period of time (5 seconds per note, 10, 15, etc), and then SampleRobot goes ahead and plays your request through the Kontact player capturing the resultant sounds, and then builds a new instrument in whatever format you want. It takes a while, (easily calculatable based on time selection and the number of velocities and notes; I'd run it overnight), but when you are done you have a usable format to use elsewhere. I believe there's also an option to auto-find loops in the sounds for a suitable sustain. Of course, it's not going to have the scripting that Kontakt has, but since it captures the resultant sounds directly through Kontact, you already have a very usable instrument - certainly much better than converting each library to WAV through Kontact and then trying to manually build a library from those.

And yes, there's a demo.

5 seconds at 128 velocities and 96 keys would be 17.07 hours to capture, for example.

Ah, yes! You are correct. I was thinking of sample "converters" rather than autosample tools--I've pretty much tried all of the sample converter programs. Autosample tools don't do any conversions, but they capture the output of the instrument and multisample a new instrument. I use Bliss sampler for this. I have never tried SampleRobot, although I looked into it a couple of times. Autosample tools may indeed be the only way to capture encrypted formats like Native Instruments. It's too bad that converters don't work with encrypted instruments however, because then you wouldn't have to try to reinvent the black art of sample looping. I doubt the autolooping would be as good as the originals, but then again, except for a few formats, sample converters don't convert perfectly either. Autosample tools may indeed still may be useful in this case.

[Lynx_TWO]

Here's a SoundFont2 file that was converted from an Oboe in Kontakt for proof of concept. It's 33MB, 16-bit mono at 22kHz with 3 velocity layers, with auto-loop and crossfaded points since that's all the trial of SampleRobot exports (and I wouldn't want to anger the Kontakt gods by sharing a high-quality file )

https://drive.google.com/file/d/1-NJ...ew?usp=sharing

[4duhwinnn]

Originally Posted by BethHarmon

Let's see Kontakt on Linux then and without yabridge's help!

Spent a few days at the bay without computer/phone, watching the tide come in and out, gulls swirling by, geese and goslings, ducks and ducklings, sunrise and sunset, boats of all and sundry size, heading out to sea, or just enjoying the sunny days on the water...
Lot's of comments here.

[4duhwinnn]

Originally Posted by alextone

Exactly.

We should cheer and encourage projects like CLAP and HISE, as, with enough support, they'll create a challenge for the assumption of monopolistic privilege and exclusively profit driven software corporate shareholders.

In the case of NI and Kontakt, it was innovation and hard work that gained them market share, not assumption or priviledge.

If you take out "profit driven" from any business model, it becomes a hobby.
Even supposedly 'non-profit' and charitable organizations must budget for unforseen costs to their operations, and income that exceeds expenses, is indeed profit, but it's re-labeled and it's use then regulated per the local business laws.

[4duhwinnn]

Originally Posted by alextone

I think sample lib developers will come to regret giving NI a monopoly, with their hostility toward linux, and alienating the growing number of linux users who want an alternative.

Alex.

NI is very far from being a monopoly, but some of their competition require dongles, or use registration systems far more unpopular than Native Access.
Which helps NI keep the doors open.

Hostility implies 'taking action against' some target

Choosing not to support linux is a passive decision, not an act of hostilty. An act of hostility would be to add some simple code to Native Access, which would detect linux, and then terminate the installer.

[4duhwinnn]

Originally Posted by Xasman

It's not cool though, because Kontakt is a proprietary format and consequently intrinsically restrictive in many annoying ways. I, for one, would prefer and welcome an open source alternative.

I use DecentSampler, and it's samples are .wav, with some great free libs.
While the sampler software isn't open-source, there is info to help samplists set up basic gui controls, and there are personal accounts of the many samplist's recording sessions.

The local car lot was intrinsically restrictive in many annoying ways,
when I wanted a free car.

[4duhwinnn]

Originally Posted by BethHarmon

As you point out, we are not really lacking anything in the Linux realm for regular effects. It's only sample library stuff that is a pain.

I often use rakarrack for effects, and guitarix is easy to build guitar tones, but there are prolifically innovative effects companies, and linux users definitely lack what they offer. Fortunately, many will run in reaper/wine.

Clap will hopefully be a unifying and enhancing force, and if pipewire can be perfected, such that libpulse and libjack are not needed, a simple and effective audio setup certainly will help convince people to try linux on solid merits, rather than on flawed philosophies.

[Xasman]

Originally Posted by 4duhwinnn

The local car lot was intrinsically restrictive in many annoying ways,
when I wanted a free car.

But I'm more than happy to pay for a car - just not for one which for which I have to beg the manufacturer's permission every time I want to drive it on a different road.

To make it more explicit, I'm happy to pay for (or to contribute to) the software I use, thank you very much. Always have. Not that I need to justify myself to you or anyone else.

Anyway, with that said - I'm out of this thread.

[michael diemer]

I think we need to keep in mind that the draconian methods employed by some companies are only there because many people do not respect intellectual property rights. Blame the pirates for that. the companies are just trying to make a profit. nothing wrong with that.

If we Linux users insist on using tools made for windows and apple, we need to accept that it's not going to be easy. The only way companies are going to accommodate us if laws are passed requiring them to do so. Which is very unlikely to happen. Contacting your local representative with such a request is not likely to stimulate action in this regard. They have much bigger things to worry about (mainly, the next election. And the "Linux vote" is not going to cause them to lose any sleep).

[mschnell]

Originally Posted by 4duhwinnn

NI is very far from being a monopoly, but some of their competition require dongles, or use registration systems far more unpopular than Native Access.
Which helps NI keep the doors open.

Yep.

And on the other hand they provide a licensing scheme for Kontakt content-providers. Of course this is "nastily busyness driven", but I assume because of this - and because of the (AFAIK) very decent scripting abilities, Kontakt is the 1st choice for makers of high-class sample based instruments.
It really is a shame that they don't have a Linux version (not even speaking of Linux on ARM), and AFAIK not even a fully supported native OSX ARM.
-Michael

[4duhwinnn]

Originally Posted by Xasman

But I'm more than happy to pay for a car - just not for one which for which I have to beg the manufacturer's permission every time I want to drive it on a different road.

For those not yet out, that's easy to say, when you don't see websites with free cars...very often. Soon, you may have to beg the govt for just such permissions, let alone the electricity needed for charging if it's an electric car. With gubbamint access to car computers, your drive can be cancelled, and your private charging station cut off. And toll roads are getting more popular among local control-freak gubbamints.

Clap is like a giant razor sharp scissors cutting through yamasteins
governing vst3 red tape. Snip. Snippety snip snip...

[4duhwinnn]

Originally Posted by mschnell

Yep.

And on the other hand they provide a licensing scheme for Kontakt content-providers. Of course this is "nastily busyness driven", but I assume because of this - and because of the (AFAIK) very decent scripting abilities, Kontakt is the 1st choice for high-class sample based instruments.
It really is a shame that they don't gave a Linux version (not even speaking of Linux on ARM), and AFAIK not even a fully supported native OSX ARM.
-Michael

The linux community is used to free software, and commercial devs are aware that only a small subset of an already small community, will become buyers.
Establishing friendly communications during the clap takeover might help improve the situation, but endless demands for free stuff is a bad look in the commercial world.

Keeping in mind that the linux kernel relies on big donations from Fortune 500 giants, and lesser but still huge household-name corporations.
Mr Torvalds net worth north of $50 million didn't come from bake sales...
(...drat, now I want some cinnamon rolls...)

Cheers

[Xasman]

Originally Posted by audiojunkie

Here are some tips:

1. LinuxSampler (the engine) is separate from the GUI. You choose LinuxSampler as the option when choosing the plugin for your track, and then you open the GUI as a separate program to make the changes to the LinuxSampler engine. It's different from most plugin programs.

2. Because the LinuxSampler (engine) is decoupled from the LinuxSampler (GUI), there is more than one front end GUI available for LinuxSampler. Use Qsampler. I believe it is the easiest and the only one still getting active development.

3. When you go to load a sampler through the QSampler GUI, choose the same sample engine of the multisamples you are using. You have three options, Gig, SFZ, and SF2. Once you have chosen the engine that matches your samples, load your sample file.

4. As long as you have your midi channels set right for your keyboard, you should now be able to listen to your playing of the samples.

NOTE: There's a lot more that can be done. For example, you can load up 16 channels of samples per port, but you can load multiple ports to have as many multisamples as you need (in batches of 16) For example Port0 Channels 1-16, Port1 Channels 1-16, etc..

I really like LinuxSampler! In my opinion, it is the best native Sample player available in the Linux world for large DFD multisamples.



Edit: Be sure to not only install the LinuxSampler Engine and the QSampler GUI, but also GigEdit so that you can create/modify instruments.

Also, Be sure to install the dependencies it uses if you run into problems. It should pull them in by default in most distros, but it may not in some.

There was something else.....Oh yeah! You will notice that you don't have any controls for essential functions such as ADSR and such. Use Reaper automation and CC controls to set things exactly how you want them. Because it's automation, you can also make changes to those settings while playing.

Best of luck!

Thanks - much appreciated.

[X-Raym]

Bitwig 4.3 jus released has official CLAP Support:


https://downloads.bitwig.com/4.3/Release-Notes-4.3.html

New Features

• CLAP plug-ins are supported for all platforms (including polyphonic modulation, voice stacking, and on and on)

[audiojunkie]

Originally Posted by Lynx_TWO

Here's a SoundFont2 file that was converted from an Oboe in Kontakt for proof of concept. It's 33MB, 16-bit mono at 22kHz with 3 velocity layers, with auto-loop and crossfaded points since that's all the trial of SampleRobot exports (and I wouldn't want to anger the Kontakt gods by sharing a high-quality file )

https://drive.google.com/file/d/1-NJ...ew?usp=sharing

Seems to work pretty well!

[EvilDragon]

Originally Posted by mschnell

and AFAIK not even a fully supported native OSX ARM.
-Michael

Kontakt has been M1 native compatible since version 6.7 (relatively recent).

[moss]

To get back on topic, here is a little sum-up I did of what happened during the first 3 weeks since the CLAP announcement:

[reapercurious]

Originally Posted by audiojunkie

Here are some tips:


2. Because the LinuxSampler (engine) is decoupled from the LinuxSampler (GUI), there is more than one front end GUI available for LinuxSampler. Use Qsampler. I believe it is the easiest and the only one still getting active development.

I installed that a long time ago, and never was able to find it. installed with pacman gui or whatever it's called. pacam. or pacman, can't remember which is which, since they are so similarly named. the search function in linux isn't showing any results for qsampler. (the search functions in linux are abominably bad.) only one lv2 location is listed in my reaper installation. /usr/lib/lv2; and qsampler isn't in that folder. what I want to know is where is your qsampler file located and how did you find it? the only option i found on the qsampler website is to build the thing, and that's a procedure that my brain refuses to retain. since i have a package manager (pacam, pacman whatever it's called) i use that, and it installed, but reaper can't find it without a path.

i do not understand why builds can't simply be built and distributed after they are built. it seems very inefficient to ask millions of users to build a thing that can be built once and then distributed to millions of users. but if I know Linux, there is an immutable neckbearded reason why.

wouldn't it be a lot easier if the LMMS crowd moved their lv2 folder once and for all into the home directory? package managers can build it, fine. but it shouldn't be a shot in the dark to find out where the build ended up. I think the linux music people decided on where that folder went before vst worked on linux. but we're in the future now.

could there be a convention decided where we just put all the various formats of plugins into one folder where all the various plugin formats can live instead of all over various locations? tracking down paths takes a lot of time if you like playing around with a lot of plugins.

and now we're adding CLAP to the mix, yet another path to keep track of, with something like 4 to 8 different vst formats, bridged old plugins, directx, au, rtas, lv2, lv2i, reajs, m4l, the formats are just growing in number and they all have different paths all over the hard drive. programfiles/steinberg/vstplugins, programfiles86/vstplugins, yabridge, ... some of the locations at least in linux's case are in protected areas that require elevated privileges to manage them.

[Glennbo]

Originally Posted by reapercurious

I installed that a long time ago, and never was able to find it. installed with pacman gui or whatever it's called. pacam. or pacman, can't remember which is which, since they are so similarly named. the search function in linux isn't showing any results for qsampler. (the search functions in linux are abominably bad.) only one lv2 location is listed in my reaper installation. /usr/lib/lv2; and qsampler isn't in that folder. what I want to know is where is your qsampler file located and how did you find it? the only option i found on the qsampler website is to build the thing, and that's a procedure that my brain refuses to retain. since i have a package manager (pacam, pacman whatever it's called) i use that, and it installed, but reaper can't find it without a path.

Qsampler is NOT a plugin that REAPER will find and do something with. Qsampler is a stand alone executable program, which if properly installed, will show up on the multimedia area of the OS menu.

The order of events I use is to start REAPER, setup a midi track and add LinuxSampler. At that point, LinuxSampler has no samples loaded.

Then I launch Qsampler, it sees the running instance of LinuxSampler and attaches itself as the GUI front end. Lastly, in Qsampler, I navigate out to some .gig, .sf2, of .sfz files and once I select one, I can play it on my midi keyboard.

If I were to save the project in REAPER, then close everything, the next time I load that project, REAPER will have LinuxSampler with the sample files I selected using Qsampler. The program Qsampler itself will not get loaded by loading a project with LinuxSampler, but if you start it up, it will populate itself to match what is in memory for LinuxSampler.

There is no need to launch Qsampler once you have initially selected some samples to use with LinuxSampler and set their parameters the way you want. From then on REAPER will load LinuxSampler with the samples you selected, at the volumes you set, on the midi channels you picked, Etc.

[reapercurious]

Thanks Glennbo, always exposing the esoteric knowledge! I'm just so used to plugins I am fuzzy on standalone situations.

I started with cakewalk and fruity loops around 22 years ago and just working with plugins, I've never used third party apps and piped the sound around outside of DAW environments, though I know it's possible with things like rewire and stuff. As I understand it's possible to just put a general midi file in the same folder as linux sampler or something?

but with respect to the thread, does anybody else agree that there is a potential user fatigue situation with almost an excess of manual path setting and mucho file browsing all over hard drives to maintain diverse plugin types?

[Glennbo]

Originally Posted by reapercurious

Thanks Glennbo, always exposing the esoteric knowledge! I'm just so used to plugins I am fuzzy on standalone situations.

I started with cakewalk and fruity loops around 22 years ago and just working with plugins, I've never used third party apps and piped the sound around outside of DAW environments, though I know it's possible with things like rewire and stuff. As I understand it's possible to just put a general midi file in the same folder as linux sampler or something?

but with respect to the thread, does anybody else agree that there is a potential user fatigue situation with almost an excess of manual path setting and mucho file browsing all over hard drives to maintain diverse plugin types?

I use Track Templates in REAPER so once I set something complicated up, I save it as a Track Template. If I want to use the Yamaha grand piano from the LinuxSampler site, I just insert my Track Template, and it's ready to play. No fuss, no muss.

I started with Cakewalk when it was a DOS program and only recorded midi, then moved through 5 versions of Sonar before jumping ship to REAPER in 2008.

[audiojunkie]

Originally Posted by reapercurious

I installed that a long time ago, and never was able to find it. installed with pacman gui or whatever it's called. pacam. or pacman, can't remember which is which, since they are so similarly named. the search function in linux isn't showing any results for qsampler. (the search functions in linux are abominably bad.) only one lv2 location is listed in my reaper installation. /usr/lib/lv2; and qsampler isn't in that folder. what I want to know is where is your qsampler file located and how did you find it? the only option i found on the qsampler website is to build the thing, and that's a procedure that my brain refuses to retain. since i have a package manager (pacam, pacman whatever it's called) i use that, and it installed, but reaper can't find it without a path.

i do not understand why builds can't simply be built and distributed after they are built. it seems very inefficient to ask millions of users to build a thing that can be built once and then distributed to millions of users. but if I know Linux, there is an immutable neckbearded reason why.

wouldn't it be a lot easier if the LMMS crowd moved their lv2 folder once and for all into the home directory? package managers can build it, fine. but it shouldn't be a shot in the dark to find out where the build ended up. I think the linux music people decided on where that folder went before vst worked on linux. but we're in the future now.

could there be a convention decided where we just put all the various formats of plugins into one folder where all the various plugin formats can live instead of all over various locations? tracking down paths takes a lot of time if you like playing around with a lot of plugins.

and now we're adding CLAP to the mix, yet another path to keep track of, with something like 4 to 8 different vst formats, bridged old plugins, directx, au, rtas, lv2, lv2i, reajs, m4l, the formats are just growing in number and they all have different paths all over the hard drive. programfiles/steinberg/vstplugins, programfiles86/vstplugins, yabridge, ... some of the locations at least in linux's case are in protected areas that require elevated privileges to manage them.

Part of the problem is that, opposed to Windows, Linux is actually just the common kernel of 600+ similar but not completely compatible operating systems. Because of this, many, if not most people, think of linux as a single operating system. It's an easy confusion to make--they all run the same programs, use the same desktop environments, and look and act the same. But the reality is exactly that--they are not the same operating system--they are all different. Every one of the 600+ Linux distributions have been assembled in different ways, using differing versions of (often) the same libraries, and having different philosophies as to how things should be done. They all are built to the specifications of the individual builders, and that means they are not the same OS. Once a person accepts this truth, and accepts that he/she has to learn "the way" that their particular distro works, it becomes easier to understand why these frustrating differences exist. This is also why all of these Linux Audio tuning manuals that everyone makes are so similar, and yet subtly different. It's why builds can't simply be built and distributed after they are built.

The linux community spent 20 years trying to get each other to cooperate on a common base. The LSB failed. Other standards bases failed. Twenty years later, we are further from a common base than ever before. This isn’t a problem if you “only” use open source. And a lot of Linux users are satisfied with that. But when it comes to closed source, whether that is freeware or commercial products, that limits the Linux user to what distros a developer is willing to compile the binaries for—which is usually the single most popular distro. As of now, because of its user friendliness, that distro is Ubuntu—whether it is actually the best Linux distro or not. Out of the 600+ Linux variants, those who want to buy a fully compatible and well supported commercial binary essentially have to use Ubuntu. Some developers purposely search for the lowest common denominator for common libraries that they use, to maintain as much multi distro compatibility as possible, but not all developers are willing to put in that work--and with those companies, you have to use Ubuntu.

Sandboxed solutions like Flatpak, Snaps, and Appimage were designed as a sort of “plan B” when it was realized that the linux community was unlikely to be able to work together to solve the solution by developing a compatible common base. So, in the future, as time progresses, it's very likely that we will see commercial developers move to these sandboxed formats, and it will then become less important what distro you are using, as long as you are using a commonly supported sandbox format. So, things are still going to get better, even if every one of these 600+ operating systems are different.

The key is to know very well exactly what you want out of a Linux distro, and then moving to the distro that fits your philosophies and style--and then staying and learning the ins and outs of that distro so that you know your chosen distro's subtle differences.

[audiojunkie]

Originally Posted by reapercurious

Thanks Glennbo, always exposing the esoteric knowledge! I'm just so used to plugins I am fuzzy on standalone situations.

I started with cakewalk and fruity loops around 22 years ago and just working with plugins, I've never used third party apps and piped the sound around outside of DAW environments, though I know it's possible with things like rewire and stuff. As I understand it's possible to just put a general midi file in the same folder as linux sampler or something?

but with respect to the thread, does anybody else agree that there is a potential user fatigue situation with almost an excess of manual path setting and mucho file browsing all over hard drives to maintain diverse plugin types?

There is no doubt that you are correct. It can be exhausting trying to keep up with the differences in each different distro. Luckily, even though there has been no agreement on defining a lasting common Linux base operating system for all of the available distros, work is being done from several fronts to unify common software packaging through sandboxing methods like those I mentioned above--Flatpak, Snaps, and appimages. It's not as efficient as having a common library base between all of the various distributions, and it has other downsides common with the technology, but it's likely the only way proprietary closed sources apps common to all distros will exist. It is what it is.

[EvilDragon]

One thing that used to plague Surge's Linux versions is xcb0 vs xcb1... it was just a ton of pain.

There's less pain now that Surge shifted to JUCE, at least.

But yes, this just shows that supporting Linux is far from a simple affair.

[4duhwinnn]

Originally Posted by reapercurious

but with respect to the thread, does anybody else agree that there is a potential user fatigue situation with almost an excess of manual path setting and mucho file browsing all over hard drives to maintain diverse plugin types?

Hi, to ease the fatigue, this is my plugin config, used in every linux setup I have:
1. For complex installations like NI and IK, I use their installer defaults
2. For average wight installers, like KV331, Sugar Bytes, BlueCat etc
I use Program Files/VstPlugins.
3. Small-shop and freeware plugins go in users/me/VstPlugins

Everything else (mainly linux native products, goes in .vst, .vst3, and .lv2

In the long run, fatique is overcome by freedom, and the ease at which the computer owner can implement common-sense alternatives to OS groupthink.
Linux is fun. Reaper is fun. Fun is a great energizer of weary souls.

[fabio77]

Originally Posted by 4duhwinnn

Hi, to ease the fatigue, this is my plugin config, used in every linux setup I have:

I think it is meant the differences between distros and their root-trees. Because it causes, that a developer has either build for various distros its own package, including all dependencies, or let the software unbuild, so that the enduser has to build it.
What we as users do, to keep the configuration simple, has nothing to do with this

EDIT: Oh, I think it was really meant the "users" fatigue, my fault
Then your solution maybe helpful.

[tony10000]

Title says it all...

[Qucifer]

Really excited about CLAP. I'm also interested in the status of CLAP in Reaper. Planning on starting development on some interesting new tools and plugins using CLAP as soon as it's supported in Reaper.

[mozart999uk]

Originally Posted by X-Raym

Bitwig 4.3 jus released has official CLAP Support:


https://downloads.bitwig.com/4.3/Release-Notes-4.3.html


[/I]

Anyone here with Bitwig tried a cpu comparison between a clap plug and a VST3?

Or is it too early?

EDIT: Found these on KVR in relation to DIVA (in case anyone was wondering):

"We have systems showing no improvement at all with some presets, and we have systems showing 100% more instances of Diva with other. A conservative estimate is 20% on average, but our sample size (number of computers tested) is too low to say for sure.

But yes. 100% more on some systems. Twice as many voice."

and

"On my M1 Air with a 256 sample buffer I can play 8 VST3 instances of the same 12 voice Diva patch before the audio drops out. With multicore enabled on the CLAP version I can play 10 instances before audio drops out, a 25% performance increase."