falkTX audio applications

I’ve just re-discovered the KXStudio softwares that has been evolved since the last time i’ve visited their website: https://kx.studio/

Even if are mostly linux-oriented (of course), the new approach could be useful for Haiku too.
The author - Filipe Coelho, aka falkTX - have “unpacked” its software into separate and independent modules thet sounds very interesting.

Cadence is a set of tools useful for audio production.
Cadence itself is also an application (the main one).
There are other applications that are part of the Cadence suite, they are usually named as the “Cadence tools”.
They are:

  • Catarina is a Patchbay test app, created while the PatchCanvas module was being developed.
    It allows the user to experiment with the patchbay, without using ALSA, JACK or LADISH.
    You can save & load patchbay configurations too.

  • Catia is a JACK Patchbay, with some neat features like A2J bridge support and JACK Transport.
    It’s supposed to be as simple as possible so it can work nicely on non-Linux platforms.

  • Claudia is a LADISH frontend; it’s just like Catia, but focused at session management through LADISH.
    It has a bit more features than the official LADISH GUI, with a nice preview of the main canvas in the bottom-left.
    It also implements the ‘Claudia-Launcher’ add-application style for LADISH.

  • Carla Carla is a fully-featured modular audio plugin host, with support for many audio drivers and plugin formats.
    It has some nice features like transport control, automation of parameters via MIDI CC and remote control over OSC.
    Carla currently supports LADSPA (including LRDF), DSSI, LV2, VST2, VST3 and AU plugin formats, plus SF2 and SFZ file support.
    It uses JACK as the default and preferred audio driver but also supports native drivers like ALSA, DirectSound or CoreAudio.

falkTX is the project leader of another interesting project:
DISTRHO is an open-source project that provides Cross-Platform Audio Plugins.

Our main target platform is Linux, but we support Windows and Mac too.

Our entire source code is available in GitHub: https://github.com/DISTRHO/

Third parties are welcome to share their code with us if they want to see a Linux port. Contact the project leader, falkTX, if you’re interested on this.

Hope that inspieres.

1 Like

Professional audio/video editing would be a nice opportunity for Haiku, but the people who working on Haiku and porting software currently have many - but less interesting - things to do under the hood to keep things rolling, and nobody have the capacity to port all-the-interesting-things ™, so if you want to make it happen, join to the HaikuPorts and start to work on it. We got cookies :slight_smile:

1 Like

exciting idea, but points also to an old problem: the lack of support for (semi/professional) audio hardware. i have not found a usable solution especially for mobile computers. of course i would like to support instead of »complain«, but i have no programming or porting skills :frowning:

Sorry to revive this old thread but I wanted to comment on this. The AES standardised network audio a few years ago (AES67) so implementing that in Haiku would open up a whole world of professional devices for audio IO. This has already been done for ALSA, Windows and Mac OS. The popular protocols all interoperate using AES67 even though a lot of things (including sync and discovery) of course differ between Dante, Ravenna etc.

This is the only solution to the problem of drivers for professional devices. The vendors will never support anything but Windows and Mac (this has been an issue with Linux for decades) and the industry is moving towards networked interfaces anyway.

I have advocated for this move before, but unfortunately I don’t know how to do anything useful in this area myself. I would love to help, though. The dream would be to have the IO of networked devices simply appear in Cortex to route stuff to.

Maybe donating some hardware to Haiku inc so they can put it in the hands of a developer would help. I had looked into it but even the simplest interfaces aren’t really cheap, and IIRC they had only XLR output so it would need even more specialized equipment to actually get sound in and out of them.

What sort of hardware would be useful?

Well on second look it seems that most of the testing could be done with another software implementation on the other side, such as https://www.merging.com/products/alsa_ravenna_aes67_driver

Otherwise I was looking into one of these, for example: https://www.thomann.de/fr/dante_avio_analog_output_adapter_0x1.htm the price for one of these would probably be acceptable, but then you need something to convert the output to consumer grade audio, and also a power over ethernet injector to power it, so it adds up quickly.

I guess the software solution is easier to set up and should be good enough to get most of this working?

Usually, a Ravenna or Dante (etc.) device would act as the master clock rather than a computer. I don’t know if this is necessarily so, maybe the computer can act as master but from memory I don’t think this option is available in for example the Audinate Dante driver. If the clocking works, I can’t see any reason the software solution shouldn’t be fully sufficient.

Also, if anyone needs a converter from XLR to some consumer connector to be able to work on this, I can surely make it out of stuff I have lying about and send it in the mail :slight_smile:

Someone is talking about me and I didn’t realize hah.

I am quite interested on getting these things to work on Haiku.

Carla is almost there, I have the full GUI working, just don’t have an engine driver that does.
One possibility is to add a SDL driver, that would work similar to RtAudio.
But the proper deal would be a MediaKit integrated driver, alike it does for JACK.

The 2nd step would be to get plugins to work.
From what I saw on HaikuDepot, there is no standardized way to handle audio plugins on Haiku yet.
some ladspa stuff and mda-vst is there, but:

  1. they install in completely different places
  2. ladspa plugins have *.so extension while mda-vst has none

There is also the need to define the mechanism for plugin UI embedding. I suppose it will use BView* as system type, but didn’t do any tests on that yet.

Personally the biggest problem I see at the moment is the lack of class-compliant USB2 audio device support in Haiku. It is the most common way people have nowadays of doing audio production (at least on the so-called “bedroom producers”, which includes me :stuck_out_tongue:)


Haiku have his own audio apps running and some ports like the great audio tool fre:ac. It could be of interest for you to contact this people or/and watch there sources.

Added an experimental SDL driver to Carla.
Sound mostly works, but get a dialog regarding a crash right at the start (both with SDL1 and SDL2). The application still works though.
Qt5 is behaving very oddly, and the haiku specific hacks force a specific style on the application.
But well, it is a start and better than before.



Fyi, we like the native look of the qt5 port.

You can set the style to fusion or windows if you really want. But our port in this sense behaves just like kvantum on linux would, it just uses a different qt engine, in this case one that uses native controls.

I like Haiku’s native look too. Is there any particular reason to use a less native look?

I am setting a custom style, in fact I implement it in C++ as my own custom theme.
But haiku overrides parts of it still.

The native look is mostly fine, but it makes custom widgets harder to do.
If we know exactly how the base theme looks, it is much easier to draw around it.
There are some widgets that DAWs/hosts use that typical applications have no need for (like hw-like knobs, piano keyboard, piano roll) so they are often made from scratch. On haiku those look a bit off.
So I think I would skip on the custom theme entirely, and will just try to make things look okay-enough with the stock Haiku theme.

Would be great to have a native dark look though. It is possible to get things dark/black on Haiku, but the process is a bit involved.

Heh, indeed, but I an working on it :grin:.

1 Like

There’s a piano roll in one of the native midi players iirc, might be able to use that.

oh tell us please, some kind of integration for dark mode would be so so good to have

Maybe i should post there a bit more what I am working on currently, my private build has dark mode mostly, but i need to clean up severall components to work with both light and dark (where they only work with dark in my tree, like the kernel debugger)

Also working on updating the css of the userguide etc to have a dark mode (like the main site which I have already changed)