Does anyone use, or remember Chionic sampler? Om?

[slowpick]

I think I found the sampler I'm going to fork into my sampler: Less_Trivial_Sampler aka Simple_Sampler, one of the DSSI example plugins. It's actually a fine sampler under the hood, the only problem with it is that it only loads and plays back one sample at a time, with no effects or anything... It just needs a GUI that can do more, and a bit more magic under the hood....

sweet!!!

is it possible to make tarballs too as I'm for one ain't a Deb/Ubuntu user??

I used to need
to use alien to make an up-to-date rakarrack rpm

alien -r ray-v_1.2.0-2_i386.deb watch for success, if rpm is made, then

rpm -i ray-v-1.2.0-2.i386.rpm

Desperate measures for desperate pickers

[emillo]

Speaking of samplers there's also petri-foo, a fork of specimen which is quite capable:
http://petri-foo.sourceforge.net/

[jeffh]

is it possible to make tarballs too as I'm for one ain't a Deb/Ubuntu user??

I started on that tonight, but I didn't quite finish. If all goes well, I might have it ready some time tomorrow night.

If layers could be added in the same way new parts are loaded in yoshimi,
that would be most excellent.

To be honest, I've never used Yoshimi, but I'll check it out.

There is a vst synth, Synth1, that allows one to input hex data, to choose colors
for background, and text. That would be a great feature to add to lms, if it's easily done.

I've used Synth1 before, but I wasn't aware of that feature. Qt actually has the ability to use the Qt variant CSS to theme plugins, if you're HTML savvy... I could probably expose that feature pretty easily if there is an interest in it. Currently, developers can change the CSS to theme their own forks of LMS plugins, but I haven't made it dynamically loadable.

Speaking of samplers there's also petri-foo, a fork of specimen which is quite capable:
http://petri-foo.sourceforge.net/

Looks interesting, I'll check it out. Unfortunately, it looks like the guys who forked it abandoned the project 4 months after they started it

FWIW, tonight I forked Trivial_Sampler into the official LMS Sampler, that I've tentatively named "Euphoria", or "U4ia". I'm hoping it will evolve pretty quickly the way that Ray-V did.

[jeffh]

is it possible to make tarballs too as I'm for one ain't a Deb/Ubuntu user??

I started on that tonight, but I didn't quite finish. If all goes well, I might have it ready some time tomorrow night.

Unfortunately, I didn't quite get around to this tonight, sorry... I'll try again tomorrow.

FWIW, tonight I forked Trivial_Sampler into the official LMS Sampler, that I've tentatively named "Euphoria", or "U4ia". I'm hoping it will evolve pretty quickly the way that Ray-V did.

However, I've outdone myself on this one... I designed a full-feature sampler GUI(and I mean, really full-featured, modular effects, graphs of the samples, a modulation matrix, start/end and looping) in just a few hours, and shoehorned it into Trivial_Sampler. At this rate of progress, there could be an alpha-preview release of my sampler some time this weekend.

For the adventurous, you can actually check it out in my GIT repository with these commands:

cd libmodsynth-git/plugins/euphoria
perl build.pl --debug

Of course, half the buttons don't do anything yet, but it can already load and display a sample already.

[slowpick]

[jeffh]

I've posted a source tarball of the latest LMS Suite from GIT here:

http://sourceforge.net/projects/libmods ... ns/source/

There is a script that will compile and install all of the plugins with a single command. See the README.txt files for how to use it.

[funkmuscle]

why /usr/local/lib and not /usr/lib?
just wanna know before I try to tackle the install script.. I use Arch and /usr/lib is preferred.

[jeffh]

why /usr/local/lib and not /usr/lib?
just wanna know before I try to tackle the install script.. I use Arch and /usr/lib is preferred.

Well... To be completely honest... I don't know.

Those Makefiles came from the DSSI developer's distribution, I didn't write them myself, I just tweaked them. I think that it's some default behaviour of compiling things yourself, that they go to /usr/local/bin, /usr/local/lib, etc... My regular package puts them in /usr/lib is because I wrote a script to that assembles the .deb packages from scratch, rather than using the Makefiles to install.

The install script does delete my plugins from /usr/lib first to avoid conflict.

[slowpick]

https://launchpad.net/~jari-tasankokaik ... /+packages

There is a commandline soundfont sampler at the link, Humma,
in case a peek at the code could help implement soundfont support.
sfz i/o would also be very nice.

[jeffh]

https://launchpad.net/~jari-tasankokaik ... /+packages

There is a commandline soundfont sampler at the link, Humma,
in case a peek at the code could help implement soundfont support.
sfz i/o would also be very nice.

I'll think about it, but that would definitely come after I finish the sampler's core functionality, which will be:

1. The ability to load any sound file type (courtesy of libsndfile)
2. The ability to save sampler instruments to an open file format I'm going to create
3. The ability to record into the sampler, and then to edit the sounds with a built-in editor and directly use them in the sampler(or save to disk in any format, again, courtesy of libsndfile).
4. My gorgeous sounding and surprisingly efficient SINC interpolation algorithm I wrote around 2004... For that nice, creamy sounding transposed sample playback...
5. Modular effects, with a modulation matrix of envelopes and LFOs

I think #2 would be an adequate substitute for soundfont. It's basically going to gather up all of the samples you've loaded, copy them to a new directory, create a text file with information about the instrument, and then compress it all in a tar.gz file that other people with Euphoria Sampler(tm) can load. I can even host 3rd party created sampler instruments on my sourceforge page.

It's actually coming along very, very quickly. At this rate of progress, it could conceivably be finished in time for LMS Suite 12.04 if I do the release later in the month... Maybe tomorrow or Sunday I'll have an alpha-preview of it ready...

[varpa]

I think what you are doing is very cool. I would encourage you to think about using the SFZ format, which is a open (but perhap not open source), standard already supported by Linuxsampler and other programs. The format is a text file, so can be easily edited. Just a suggestion.

[slowpick]

http://www.mega-nerd.com/libsndfile/

a chart showing audio supported by libsndfile is at the link
including .w64

[jeffh]

I have the preview packages uploaded:

http://sourceforge.net/projects/libmods ... s/plugins/

Please keep in mind that it's nowhere near finished yet, don't expect to be able to use it in a tune. According to git log, I only started working on it Monday

Here's what works:

• Loading samples and viewing them
• Playing back samples

Here's what doesn't work:

• Polyphonic effects
• Sample start, sample end, loop start, loop end, key mapping, velocity mapping
• Probably lots of other stuff

As far as SFZ support, etc... I'll revisit that when the sampler is closer to being finished, that's not a feature I can really start working on until the sampler itself is fully functional.

[reduz]

Heyo, I'm the author of Chionic, a friend let me know about this thread.
Chionic was probably one of the most complex sampler+editors ever for linux, but it was way ahead of its time and the combination of alsa+jack simply didn't work at the time.
I still have some audio projects in the "will complete" list at some point, but there is some things i have learned from the Linux audio ecosystem that make me not care much about it anymore.

1) You can't reuse anyone else's work because it eventually stops being mantained, or a new version that is incompatible comes out and in either way becomes obsolete. Windows developers have learned this much before us and do NIH approach everywhere. The amount of software written for Unix/X11 that is obsolete right now (un-runnable or un-compilable) because of this is enormous. I used to depend on libraries made by others too much in the past, so it forced me to learn how and write my own eventually.
I wrote my first apps in GTK1.2, then GTK 2.0 came out and it was obsolete, decided to move to Qt3 since at the time, trolltech seemed serious. Now Qt3 is obsolete. Same with portaudio/rtaudio/etc.
By the time i wrote Chibitracker, i ended up using my own GUI system, and Chibitracker still works fine today.

2) Developers can't agree on anything useful and instead try to do pharaonic projects to please everyone, which result unusable in the end. Is jack useful? yeah i guess, with midi support a little more.
But for 99% of use cases, a good plugin system would have worked, since writing in-app audio routing is still faster, simpler to do and consumes less resources.
So why don't we have a proper plugin system on Linux to this day? LADSPA tried and is quite ok, but a good part of the time you need more visual feedback over what you do, also it sucks for synths.
In X11 to this day it's impossible to mix up toolkits (Qt and GTK for example) in a single app, even in different threads. They can't share an X11 connection, and even if they could they use too many singletons, which makes it impossible to load them straight from a .so.
For this reason, DSSI was created, but it's horrible. The examples are extremely complex and relies on too much error handling as well as data overload between GUI and plugin for complex stuff, so it never did catch on. VST, in contrast, which worked on SGI also pulled a NIH and has a toolkit of its own.
End result, pretty much no useful plugins, so what did end up happening?, VST is used over wine..

3) The platform (Linux) is hostile. try mixing "pro-audio" apps with regular ones and see what happens, dmix, then pulseaudio can't connect anymore. Any other operating system has the concept of primary and secondary mixing buffers (BeOS, OSX, Windows), where at kernel-level the one with realtime is opened in realtime priority with native parameters, and the second (with system audio or regular latency APIs) one mixes over it with a large secondary buffer. This only works well and reliably at kernel level (mixing a huge, second buffer into a small realtime one), because otherwise the kernel -> user ->kernel loop is a waste. This is usually done at the interrupt handler. Even commercial OSS works this way. But ALSA?
When this issue was brought up to Linux/ALSA developers, they understood the problem but the answer was that it couldn't be solved because "resampling" belonged to userland. The kernel couldn't be bothered with resampling. After much insistence and asking why , the answer was that proper resampling is done in floating point, and the kernel can't use the fpu.
I insisted that you can do resampling fine using fixed point and that most commercial audio gear does it that way. You can even use oversampling, but the answer was "no, because it's a shitty solution that generates aliasing, it's shitty code so it doesn't belong to the kernel". Even if i insisted and tried convincing them with blind tests that you CANT hear the aliasing in real-use scenarios and that commercial hardware used fixed point for this for decades, it was no good. The answer was sort of like "Want to do pro audio? purchase actual (expensive) hardware with multi channel".

So, after a while I just gave up. There's just way too many people in power that will not accept to make developer's and users life happier, they don't want to talk with you and it's too much effort to fight against them. In other platforms, the APIs may be worse, the OS may be worse, but money is king and stuff works.

[linuxdsp]

@reduz: as a commercial plugin developer (perhaps the only commercial developer insane enough to focus primarily on linux audio.. ) I understand a lot of your pain regarding linux audio, however I don't think its quite as bad as you make it seem, though there are some bits I agree with:

You can't reuse anyone else's work because it eventually stops being mantained, or a new version that is incompatible comes out and in either way becomes obsolete.

As a commercial developer, I don't use any GPL'd code - for obvious reasons, but I've lost count of the number of projects I've tried to build that are GPL, and which either use some obscure library which is no longer maintained, or simply provide links to libraries which no longer exist. It's difficult to get the right balance between re-inventing the wheel, and / or forking existing libraries and / or generating code which depends on a huge tree of libraries just to do something relatively simple. (All my plugins have minimal dependencies on system libraires, normally just a subset of the standard C / C++, and X11 for GUI code as this is about the only way I can create binaries that have a good chance of being compatible across most linux distros from more than a few days..)

In X11 to this day it's impossible to mix up toolkits (Qt and GTK for example) in a single app, even in different threads. They can't share an X11 connection, and even if they could they use too many singletons, which makes it impossible to load them straight from a .so.

One of the things I had to spend a lot of time on before I was prepared to release anything was getting a GUI that would work in any host application regardless of native toolkit (I figured if a plugin was LV2 or VST or whatever, users would / should expect it to work in any host which claimed to be LV2 or VST compatible - it made no sense to have it LV2, but only GTK or LV2 but only Qt etc etc). The only sane option was to go to the lowest common denominator and use native X11. You can get multi-threaded stuff to work using X11 but its not straight forward, and I had to invest a significant amount of time in getting this working properly. A useful side-effect of doing this is that I then had an X11 toolkit which was easily re-used when porting to native linux-VST which is entirely dependent on having an X11 based GUI.

For this reason, DSSI was created, but it's horrible.

Yes - I think DSSI is possibly the worst solution ever invented (but I also think it was in some way intended to be a temporary solution, so apologies to the developers if I'm being too harsh - but having tried to use it and had plugins fail to load their GUI because my network config was wrong... well, if something like that can happen, it's a big big warning sign that the underlying architecture is totally wrong. A user is absolutely not going to think "Plugin X doesn't seem to have a working GUI, I wonder if that has anything to do with my network config..?" )

There's just way too many people in power that will not accept to make developer's and users life happier, they don't want to talk with you and it's too much effort to fight against them

It seems to depend on who decides to step up and make things happen - and regrettably that doesn't always mean the right decisions being made by the right people - but I don't think this is a problem which is unique to linux... and a lot of the right decisions do eventually get made, it can just involve a lot of work / diplomacy to convince people sometimes

I have a lot of belief that linux can be an excellent platform for audio, but the pieces aren't always connected up properly, and that can be frustrating (especially as I know how well it can work).