Music Production on Guix System | Hacker News Reader

Music Production on Guix System

guix.gnu.org

181 pointsrekado57 comments

The author is honest enough to admit their "superficial" reasons for using the CALF plugin suite, but unfortunately then claims that they also "sound really good".

People should be aware that we (the developers of Ardour) STRONGLY recommend against the use of the CALF plugin suite. Not only do numerous of these plugins have basic DSP mistakes in them, but they are also one of the most regular source of crashes for Ardour users.

There are better alternatives for every single plugin the CALF suite, and we encourage you to use try them, even if they don't look quite so "pretty".

Is there a list of suggestions or alternatives for Ardour?

We don't keep this list as up to date as I'd like:

https://manual.ardour.org/working-with-plugins/getting-plugi...

There are better alternatives for every single plugin the CALF suite"

Is there a list of these anywhere?

Check out the LSP plugins. Don't think they can replace all calf plugins but I've been starting to replace the calf plugins I use with them. I like their equalizers better than the calf ones. Been starting to check out their filters. Their room builder looks pretty awesome but I haven't played with it.

https://lsp-plug.in/

Ah, yes, I remember the days when I would try to use the CALF Reverb plugin, only to have its use result in numerous "audio explosions" while working on mixes. Luckily none of my gear ever got damaged but it was possible given the wacky setup I was using at the time.

I discovered the Dragonfly Reverb [0] at some point and I never looked back.

PS, every time I encounter you on the internet I make sure to say, THANK YOU for Ardour!

[0] https://github.com/michaelwillis/dragonfly-reverb

Honest author here -- I'm very happy that you noticed my humble blog post! I'm a big fan of Ardour and have been using it in my amateurish ways on and off since 200...7?

I wasn't aware of the Calf plugins being a source of crashes. Recent versions of Ardour have never crashed on me (different story for earlier versions). "Basic DSP mistakes" also sounds alarming. I'll take note of that for future projects.

Perhaps the pretty UI could be adapted for suggested alternatives. It would help all those superficial people like me to migrate :)

On a more serious note I like how intuitive the Calf UI is; almost every plugin lays out its primary parameters in a way that is very compatible with how I approach my work. I'm a command line person, so I certainly could make do with automatically generated interfaces from the LV2 manifests, but ... I try to shed my developer persona when having fun with audio, so anything pretty that keeps me from thinking too much helps to keep me in the zone.

> "Basic DSP mistakes" also sounds alarming.

It does, but as a musician, I don't think anyone should care so much about this. If you like how it sounds, and it's working in your productions - great!

Zipper noise when adjusting parameters? This is about as basic as it gets. If you can't hear it, you probably shouldn't be mixing your own music, because lots of other people will.

(of course, "DSP mistakes" can often be used creatively and there's nothing wrong with that)

Dude, chill. End result is what matters, if it’s music, it’s music.

Lol. The guy wrote Ardour. Might know a thing or two.

He said the guy shouldn’t be making music, which takes it from technical criticism to bs. It’s the music that counts, not how it’s made.

It doesn't faze me, because I'm not automating plugin parameters for things like reverb, compression, etc, so zipper noises simply don't happen. If I were to use automation and dynamically adjust parameters during playback and noise littered my tracks I'd agree with Paul: if I couldn't hear that it would be a terrible idea for me to mix the tracks myself!

That said, I did find a couple of spots where I forgot to crossfade the edges of punch in/out points, so there are quiet but audible clicks. Oh well. That's what happens when you mix audio with the headphones slightly off to be able to hear if the baby is sleeping poorly next door... :)

The point was to have some creative fun and have it quickly. That's what it was, so I'm happy.

Actually, I didn't say that. I said they shouldn't be mixing their own music.

Until a decade or two ago, almost no musician ever mixed their own music, they relied on audio engineers to do that. The proliferation of DAWs and cheap powerful computers has changed that so that now many musicians believe they can/should do this work themselves. They're not necessarily wrong, but a little humility is required I think, mostly by remembering that good audio engineering is a distinct skill set, quite different from being a good musician.

Although there are few exceptions, I'd wager that almost no example of whatever you (or anyone else) considers "great music" was mixed by the musicians who made it.

> It’s the music that counts, not how it’s made.

Exactly. That's why PaulDavisThe1st's suggestion was IMO completely reasonable. Mixing is a skillset that not only takes time to master, but also requires that you keep your ears healthy - which is something that many musicians don't always do (myself included). Not only that, a professional mixer understands that you can only mix for so long in a single session before your ears become fatigued and you can no longer trust them (until you give them rest).

I would argue that if someone cares primarily about the end result of the music then it should be easy to put aside their pride and allow the experts to do their job and help them sound better.

I'm curious about why the author's using Jack1 rather than Jack2. Is Jack2 not available for guix? Jack1 has a bunch of limitations compared to jack2 and hasn't been in active development for a while apart from bugfixes.

In general though, it looks much the same as music production on linux, which I absolutely love the workflow of.

Being able to arbitrarily patch the inputs and outputs to any other input and output between jack aware software is honestly one of the coolest things i've seen.

I started making music on the computer back on windows. After switching to linux for regular usage, I started looking into music production stuff, as soon as I figured out how it all worked, i was amazed. I couldn't imagine going back to a system where you're confined to a DAW.

Your entire computer becomes one big modular DAW that you can combine nearly endlessly.

There may not be as wide a selection of proprietary plugins as on windows or Mac, but what is there can be up there in quality and there's so many available, you're bound to find something with a sound you like.

The calf plugins mentioned in the article are phenomenal. Also a fan of the LSP plugins, the togu audio line ones are always pretty decent.

There's a ton available and new ones appearing all the time.

https://www.kvraudio.com/plugins/the-newest-plugins/linux

> I'm curious about why the author's using Jack1 rather than Jack2. Is Jack2 not available for guix? Jack1 has a bunch of limitations compared to jack2 and hasn't been in active development for a while apart from bugfixes.

I write in a rambling little post I made last year about my Linux audio mastering workflow [0],

>> We will be using jack2 because using jack1 in 2019 is stupid! The multi-threading, MIDI, and other various features of jack2 are deal-breakers, not nice-to-haves.

In my experience, the need for jack2 is amplified even further when you want to work with modern plugins like the ones you mention at KVR.

> Being able to arbitrarily patch the inputs and outputs to any other input and output between jack aware software is honestly one of the coolest things i've seen.

Indeed! When I was a studying audio engineering at university this was a huge revelation and few of the professors & professionals I was surrounded by had any idea this functionality was out there. The fact that it was FOSS blew their minds.

If you want to go even further down the modularity rabbit hole, check out non-daw [1].

[0] https://grathwohl.me/2019/05/05/linuxmasteringflow-1.html

[1] https://non.tuxfamily.org/

JACK2's benefits over JACK1 are:

   * dbus integration
   * multi-core parallelism
   * click-free port connect/disconnect

But: the first only matters on systems with PulseAudio installed (or where you insist on being able to use dbus to control JACK). The second only matters if you have actual parallel signal flows, which many people do not. The third is only possible if you run JACK2 in non-sync mode, which adds an extra cycle of latency.

JACK1's continuing benefits over JACK2:

   * integration of a2jmidid so no need to use separate tools to make MIDI devices visible
   * integration of zita-a2j making it easy to use multiple audio devices from a single JACK instance

I believe that Filipe, the current maintainer of both JACK versions, plans to unify these features.

> I believe that Filipe, the current maintainer of both JACK versions, plans to unify these features.

If you don't mind me asking: With PipeWire on the horizon, do you think this will still be a useful thing to spend time on?

I don't have much of an opinion. Precisely how PipeWire might affect (or not affect) the direct use of the existing implementations of the JACK API (JACK1 and JACK2) isn't of a lot of interest to me. But I trust Filipe to know what to do.

I've used non, I like it and I like the idea, I wasn't really a fan of the ui though. I used non-sequencer for a bit but ended up switching to muse and rosegarden before Ardour got midi. I find it almost a bit too modular. I do like the idea of having ardour as an end point for various things.

I tend to sequence and record audio into ardour then do some processing and mixing there.

Then I'll mixdown in ardour then patch that track through jamin into a new ardour track for mastering.

I find that setup still gives me flexibility while having a sort of centralized 'master console' or something.

jamin ... i hate to be a nag, but please please please stop using this software. Conceptually it's a cool application, but the DSP artifacts it generates are just awful.

There are plugins you can use within Ardour that will do a much better job than jamin.

Could you point me to some? I started using jamin when it was pretty much the only mastering available, if there's something better now I'd like to check them out.

The Harrison XT plugins would be the obvious thing to point to, though they are not FLOSS.

LSP multiband compressor. x42 limiter. Zam multiband compressor.

Thank you. As awesome as the Harrison stuff all is, I make music for fun, so it's a bit out of my price range. I've been really liking the LSP plugins though, i'll have to check those out.

> If you want to go even further down the modularity rabbit hole, check out non-daw

falkTX (of KXStudio/Carla/JACK/etc) made a fork of non-mixer that supports LV2 plugins;

https://github.com/falktx/non

Even deeper is JACK/LV2 CV;

https://linuxmusicians.com/viewtopic.php?f=1&t=20701

Author here. I use JACK 1 because it serves me well enough. I don't need the DBus features JACK 2 has, for example. Up until recently the recommendation was to use whichever version you want; now I just checked and the JACK authors recommend the use of JACK 2.

JACK 2 is, of course, available in Guix and has been for a long time.

Fair enough. Makes sense. Thanks for responding and for your article. I did enjoy the read. It's always good to see more stuff on FOSS music production and see how other people work.

>After switching to linux for regular usage, I started looking into music production stuff, as soon as I figured out how it all worked, i was amazed. I couldn't imagine going back to a system where you're confined to a DAW. Your entire computer becomes one big modular DAW that you can combine nearly endlessly.

Most perspectives on Linux audio tend to come from an angle of 'working with what you got', and looking own it as some sort moral handicap. However your comment sings a different tune. I really appreciate you inputting your thoughts here, as it concisely put together what I've thought all along but never assimilated. There is no reason why Linux shouldn't be a percived as a first class audio production system. Perhaps the only thing holding it back is the time investment it takes to understand the modularity, along with learning Linux itself.

Amazing timing to see this on the front page. I used to do hobby electronic music production using proprietary tools, but as I gradually grew more passionate about the free software movement (and more fatigued with the constant, expensive DAW upgrades/new versions), I stopped in favor of other hobbies. But recently I've realized how far free software tooling has come in terms of usability, especially for amateurs like me. Writing beats and melodies in Sonic Pi [1] and mastering/mixing them in Ardour/LMMS [2] has rekindled my love of music production.

[1] https://sonic-pi.net/

[2] https://lmms.io/

And there's a vibrant community ! We are having the linux audio conference online right now : https://lac2020.sciencesconf.org/ with tons of cool talks and workshops

Lilypond is a marvel. I use it for transcription currently as it can easily generate tabs as well as regular notation.

Seeing others use linux for music production is inspiring. I'm currently in the stages of building a home music studio and I'm strongly considering giving linux a go instead of going with a mac mini. However it's really hard giving up Pro Tools...

Ha, that's funny, I abandonned lilypond precisely to create combined stave/tab scores more easily. I found that flipping back and forth between the lilypond "source" and the rendered result was too slow. I read music notation much better than lilypond's "musical LaTex" notation and I found it hard to remember the nuances each time I came back to it. (Adding lyrics to an existing piece was the last straw).

I switched to Musecore. Although I generally eschew GUI apps I much prefer it to LP: I can see my editing changes directly without the "compile, run" steps. My efforts are less DRY, to continue the programming metaphor (eg copy/paste the chorus) but that's acceptable. I don't plan on writing any massive symphonies. As @rekado elsewhere on this page, I don't have to act-as-programmer when I'm making music.

Musecore has had lots of criticism of its design but that area has apparently improved a lot recently. It might be "Word for music" but it's a mostly-complete-but-simple version (so... Word 6? AbiWord?). Works for me.

> I found that flipping back and forth between the lilypond "source" and the rendered result was too slow.

I found Frescobaldi to be a decent compromise in that regard as it serves as a decent Lilypond editor while keeping the rendering of the score up to date at the same time.

Personally, I'm going to experiment a little more with tighter Emacs and perhaps Org mode integration. I don't care for the full score at all times, so using Lilypond as a server and sending it only short snippets to be displayed in an Org mode babel buffer might be a viable option.

(I know that you can tell Lilypond to skip time and only start rendering after some offset, but I'd rather not have to keep adjusting that offset number all the time; it also doesn't work so well for pieces with different odd meters.)

For anyone wondering specifically why Guix, the author is playing a Chapman Stick[1] so clearly enjoys a challenge.

[1] https://www.youtube.com/watch?v=2GS0nKIebCc

Hah, it would seem so. I'm no Bob Culbertson, but I should say that I find the Stick to be rather easy to learn. Its inverted fifths tuning for the bass side makes a whole lot of sense to this recovering guitarist.

What's certainly not easy is to play patterns between hands that are not merely interlocking or interlaced but truly independent. I have given up on trying to do this without breaking down the pattern and learning them chunk by chunk. Perhaps true independence is a myth or a well-guarded secret.

Never heard of Guix, but it's interesting to read what tools they used to produce the song on Linux. Ardour looks pretty impressive.

Ardour is riddled with bugs. The GUI is incredibly ugly. MIDI workflow is terrible. The developers seem slow, old, and very opposed to new ideas. You can't run Windows plugins in it, so goodbye productive work. No professional anywhere uses it. You have to use C++ (!!) to write support for control surfaces instead of scripting in a real language. Setting up your audio/MIDI hardware settings has its own window instead of being part of Preferences like any real DAW. And of course, no proper DAW workflow like Live or FL Studio. You can't make beats with Ardour, you need actual musicians which is just stupid.

I would definitely stick to Audacity.

To those who wouldn't realize, this message is from the creator of Ardour. I suppose he's tired of hearing the same complaints again and again so he decided to pack them all in a single message.

I'm not going to talk about how much I like Ardour because I feel guilty for not having donated yet.

Well, as Ardour's the only DAW i've paid for and you saved me from making a fool of myself countering all the things said above allow me to step in and say.

I really love ardour, thank you for all the hard work to the creator and devs that have worked hard making an amazing piece of open source software I obnoxiously like to point out every time people complain about a lack of professional quality open source tools.

I will take a look at it anyway. Using C++ to implement a DAW is a very good idea IMHO. Audacity is a mastering tool, not a DAW. I'm actually a musician myself but don't use Linux yet for music productions, but for everything else.

I love that the soul of this post is about music production on Guix using FOSS -- over the years I've used most of the tools the author listed.

That being said, I have been super impressed with the non-free DAW Bitwig [1]. It was built by some ex-Ableton folk and has a similar polish and depth. I'm running it on Linux and have no problems connecting to audio or midi devices. I'm even able to load Windows VST plugins, e.g. Serum, via a wine emulator. It contains some pretty novel features, too, like being able to build complex audio FX as if from legos [2]

1. https://www.bitwig.com/ 2. https://www.youtube.com/watch?v=-wHHbV8Zw4g&feature=emb_logo

Reaper [1] is another excellent proprietary DAW that has a Linux version (albeit "experimental"). At this point, if only a couple of plugin companies started releasing for Linux, I could seriously consider switching. And as Apple becomes more locked-down, I would like to be able to.

1. https://www.reaper.fm

Late to response, but I'm a big fan of reaper also -- its fantastic comping tools in particular keep me coming back.

This is the nerdiest thing I've seen in a long, long, long time (a Chapman Stick?!?) and I love it.

I’ve seen Guix pop up a few times and I’m intrigued ... ostensibly a package manager but this article says it can work as an operating system in its own right. Can somebody explain this to me? Is this HURD? Or does it have a kernel? Is it some sort of hypervisor or application container? I always found HURD to be exciting in a sci-fi kind of way but from what I’ve heard this sounds like it’s actually something that could be practically useful. Where would I start? Does it make any sense running in VirtualBox let’s say?

Guix system uses linux-libre currently

So that’s just the kernel and it provides it’s own user land? Is that user land itself some a kind of app container host I could run Linux apps in for instance - but at arms length from each other? Am I getting this right?

guix-the-package-manager can be installed on any GNU/Linux distribution. It's a great way to access bleeding-edge software on a "stable" distro such as Debian or CentOS.

It has some nice properties such as not needing root privileges to install things, atomic upgrades and rollbacks, reproducible builds, multiple or transient (optionally containerized) "environments" (collections of packages), etc.

Guix System is a full distro built around the package manager. It gives you atomic upgrades and roll-backs for the entire system (you can choose any previous "generation" in the boot loader).

This sounds quite exciting. I could use this right away, with all the software I’m used to, and get all the benefits.

aside from the standard GNU utils right now it's mostly just guix the package manager and https://www.gnu.org/software/shepherd/

It's a whole GNU system distribution using Guix to build the system reproducibly, providing roll-backs at the system level, using Guile Scheme even as early as the initrd, etc. I don't know what you mean by "GNU utils", but "Guix System" is quite a bit more than just Shepherd and coreutils.

Ah lovely, as an alternative to systemd? Sweet!

> I’ve seen Guix pop up a few times and I’m intrigued ... ostensibly a package manager but this article says it can work as an operating system in its own right. Can somebody explain this to me?

Guix as a package manager knows how to build software, and how to manage all the files. If you build the right software, plus a few more things with some files, then you end up with something that'll boot.

One really neat thing about this is that this is set out in one Git repository, making it pretty easy to reason about.

> Is this HURD? Or does it have a kernel? Is it some sort of hypervisor or application container? I always found HURD to be exciting in a sci-fi kind of way but from what I’ve heard this sounds like it’s actually something that could be practically useful. Where would I start? Does it make any sense running in VirtualBox let’s say?

Guix by default uses Linux-libre, but you can run it with the Hurd.

You can start by using Guix as a package manager, it'll fit alongside your existing operating system (providing it's something using Linux). There's also a VM image you can download from the website if that's of interest.

I wonder if the author will release their source data under a free license.

Yes, that's the plan. I've been really busy these days, so even finishing the blog post was very difficult, but I intend to upload everything to my own blog at https://elephly.net within a month or so.

The license will either be CC-BY-SA or CC0 / public domain.

Excellent! Thanks for that! It is extremely rare that people think about releasing source data for multimedia assets.

Reply on news.ycombinator.com