[HN Gopher] Linux DAW: Help Linux musicians to quickly and easil...
___________________________________________________________________
Linux DAW: Help Linux musicians to quickly and easily find the
tools they need
Author : prmoustache
Score : 161 points
Date : 2025-12-29 12:23 UTC (10 hours ago)
(HTM) web link (linuxdaw.org)
(TXT) w3m dump (linuxdaw.org)
| cadr wrote:
| Is there a way I can see which would run on a raspberry pi?
| jjrh wrote:
| They will need arm builds sadly so the list is likely going to
| be rather small.
| jcelerier wrote:
| Pretty much everything in the linux audio world runs fine on
| ARM
| ofalkaed wrote:
| kxstudio supports rpi, it comes with a few DAWs and a great
| deal more, it is probably your best bet for this stuff on pi
| unless you want to compile stuff yourself.
|
| https://kx.studio/
| cpuguy83 wrote:
| Just an fyi to anyone making or thinking of making one of these:
|
| Turning a knob with a mouse is the worst interface I can think
| of. I don't know why audio apps/DAWs fall so hard on
| skeuomorphism here when the interface just doesn't make sense in
| the context.
| giancarlostoro wrote:
| Isn't the entire idea that you hook it up to physical hardware?
| drabbiticus wrote:
| No. MIDI controllers have their place, but many people work
| without one, or only use one for live performances. There are
| often also way more knobs in the various FX chains in a DAW
| than you would reasonably want to map to a controller, but
| still want to touch at least a few times while making a song.
|
| Knobs are confusing when converted to a mouse paradigm
| because there can be a few strategies to control them
| (click+drag up/down, click+drag right/left, weird rotational
| things, etc), and you have to guess since each FX studio and
| software may implement it just a little different.
| adzm wrote:
| If not using hardware, you just click and move horizontally or
| vertically; not sure what a better interface would be? Though I
| do like it when the numeric value shows when changing. I really
| don't know what other UI would work well here. Usually there
| are so many knobs it makes sense to be compact. Though really
| it makes sense as well to match the visualization of the knobs
| on my midi controller anyway.
| Gracana wrote:
| It allows for dense controls and everyone's used to them. I
| don't find them to be a problem, they aren't intuitive in that
| you might think you're supposed to grab the knob and "turn" it
| with a circular cursor motion or something, but once you learn
| to drag linearly, they're an easy to use and consistent
| interface. And as giancarlostoro mentioned, you can map them to
| a MIDI device if you want to twiddle knobs while
| playing/recording live.
| sroerick wrote:
| I'll add in addition - the skeumorphism here is generally
| pretty functional, you touched on this when you said
| "everyone is used to them"
|
| But the layout of these buttons, while certainly not
| standard, is generally familiar across various filters, etc.
| So if you are dealing with a complex interface the
| skeumorphism absolutely helps to make the input more familiar
| and easily accessible.
|
| This is what skeumorphism is for and this is a great place to
| use it.
|
| Imagine if the symbols for "play" "pause" and "stop" were
| changed simply because it no longer made sense to follow the
| conventions of a VCR, then multiply that by an order of
| magnitude.
| saidnooneever wrote:
| most daws allow you to map hardware to the dials so u dont need
| to tweak by mouse. that being said, good automations are a fair
| replacement depending on your style of music. lfos, adsrs and
| pattern tools for automation lanes aswell as ability to record
| automations (to keep em consistent, modify manually etc ), and
| ofc humanization algorithms that u can apply to automation
| lanes.
|
| i never use 'hardware', totally happy doin what i do. (thats
| music i think. enjoying your craft). most ppl i know using
| similar tools do have midi controllers to have more of an
| instrumental interface. theres tons of options. no need to
| discourage anyone...
| luqtas wrote:
| and most interfaces have a condition watching for CTRL or
| SHIFT to ++/-- values slower or faster depending on the
| modifier held... that allows one to turn a knob with much
| greater precision than a physical interface!
|
| double-clicking usually lets one type the value... really
| good interfaces let one scroll seamless independent of screen
| borders; the perfect pair with a trackball or a long
| surface/desk for sliding the mouse
| Lapsa wrote:
| tbf audio hardware stuff is getting obsolete. signal
| processing has become so powerful that the difference is
| marginal. nowadays you can even get an exclusive 24k gold
| plate reverb in a software form
| (https://blackroosteraudio.com/en/products/ro-gold)
| rasz wrote:
| On the other hand turning a knob with a mouse wheel is the best
| interface I can think of.
| ubercow13 wrote:
| It doesn't provide enough precision for many synth/music
| effect knobs.
| mjr00 wrote:
| > Turning a knob with a mouse is the worst interface I can
| think of.
|
| I'm racking my brain thinking of what a better interface would
| be for selecting a number between a range of values, where the
| number is a point on a continuum and not any specific value,
| and can't think of one. The equivalent "traditional" UX for
| webapps would be a slider control, but that's functionally the
| same and you'd be going against many years of domain-specific
| common understanding for not much benefit.
| jrm4 wrote:
| Is it fair to assume most mouses have a scroll wheel? Hover
| and use that? Do they do that?
| bigyabai wrote:
| Most have click+drag and a shift modifier for fine
| adjustments.
| mjr00 wrote:
| > Is it fair to assume most mouses have a scroll wheel?
|
| Probably not, a lot of musicians develop on the go (planes
| etc) so they're dealing with built-in trackpads pretty
| often. You can still scroll but it's not as ergonomic.
| ofalkaed wrote:
| This is one of the things which helped sell me on
| Thinkpads with their three physical trackpad buttons and
| trackpoint, middle click+trackpoint gets you your scroll
| wheel and it is quite ergonomic.
| camtarn wrote:
| Huh, I had one of those Thinkpads and I had no idea that
| this was a thing!
| ubercow13 wrote:
| Some audio software lets you do this but mouse wheels are
| incredibly imprecise compared to the mouse sensor itself so
| this isn't really useful for many types of control which
| require precise adjustment.
| bandrami wrote:
| I think it's even more fair to assume the user has a MIDI
| device with a bunch of knobs on it?
| ofalkaed wrote:
| I personally prefer the good old number box but they have
| their problems and you actually have to read each and ever
| box to see what the state is, with sliders and knobs we can
| see the value of a great many controls at a glance.
| mjr00 wrote:
| Some newer synths do this where it makes sense. e.g. in
| Phase Plant the wavetable frame is a number, since
| wavetable positions are discrete values from 1 to 256.
|
| Ultimately I see two problems though,
|
| 1. sometimes the number doesn't matter or make sense at
| all. A good example is a macro knob. The value is somewhere
| between "0" or "1", and synths _do_ let you set it manually
| (since this is how recorded automation works), but a macro
| slider doesn 't make too much sense IMO.
|
| 2. lots of controls deal with logarithmic values. Anything
| that corresponds to a frequency is going to need finer
| control when you're tweaking values below 500Hz vs changing
| a value between 10000Hz and 10500Hz. Knobs mask this pretty
| well. I'm sure you could build a slider that dealt with
| this, but a number box would be very weird since you'd want
| the scroll step to be much smaller at lower values.
| ofalkaed wrote:
| Number boxes can be log or expo or even an arbitrary
| list, and they can have a fine tune through holding shift
| or the like. They also generally allow you to just type
| in the number you want. They definitely are not the best
| solution for all situations, just my preference.
| ofalkaed wrote:
| A 20 pixel knob has considerably greater resolution than a 20
| pixel slider with its max resolution of 20. I don't think I
| have come across a digital knob that you have to turn with the
| mouse since the previous century, just drag up or down or left
| or right.
| mock-possum wrote:
| Or scroll your mouse wheel up and down
| cpuguy83 wrote:
| The scrolling makes sense. Dragging up and down does not.
| lukaslalinsky wrote:
| Unless the implementation is really bad, you actually have more
| control over these knobs than you would have over sliders. You
| could technically remove the knob completely, replace it with
| just textual number you click on and move your mouse, but the
| knob is easier to read.
| kgwxd wrote:
| The amount of time it takes to have 1 debate about the choice
| is more time than I'll spend in my entire life figuring out how
| all the specific "knobs" I'll ever touch work. It's just not a
| real problem.
|
| Reaper has a standard UI for controlling plugins you can use
| instead of the VST UIs, other DAWs probably do too. It's an
| awful, lifeless sea of sliders and check boxes that hurts to
| look at, and instantly drains one of all creativity.
| recursive wrote:
| I've heard this POV before. Personally, I'm glad there's a
| DAW option with a no-frills approach to UI. I don't _want_ a
| flashy or "inspiring" UI. Everything should be within arms'
| reach and do what it says on the tin. All the creativity
| happens in the audio domain. I prefer to use my ears.
|
| Some people like Reason for instance, but I find that its UI
| innovations just get in my way.
| ubercow13 wrote:
| It works great though, what's the alternative? It's visually
| small, so you can fit a lot of controls in a small space. You
| can glance at it and know the current setting and where it
| falls within the range of possible values. By making the mouse
| control modal when you click on a knob (so you start dragging
| and can drag over a much larger area than you could for say a
| slider, which isn't modal) you have immensely precise control
| over the value in realtime, while still being able to quickly
| make big changes. This is essential for performance. Combining
| this with some gentle mouse acceleration for the rate of change
| of the control when dragging gives you even more precise
| control. This isn't possible with a slider either.
|
| I would say the opposite, it's basically the perfect interface
| for a very specific scenario with requirements that don't
| really occur in much other computer software.
| reactordev wrote:
| The alternative is the mouse wheel and keybinds. Flight
| Simulators got this right. Roll up on the wheel to increase
| the value, roll back on the wheel to decrease the value. Left
| click to push, right click to pop (or context menu, left
| click to push it again to turn off).
|
| In fact, if it was all MIDI controlled, it's just a matter of
| mapping the mouse scroll wheel to a midi channel.
| yunwal wrote:
| Almost all DAWs I've used allow you to use the mouse wheel
| while clicking to increase/decrease the value on a knob.
| reactordev wrote:
| I only use logic now but used FLStudio in the past. I'm
| by no means an expert or anything, just an audiophile ex-
| musician turned software guy and find that it's similar
| between flight simulator and logic. With FLStudio I did
| everything with midi controllers so I never used the
| mouse that way.
| ubercow13 wrote:
| I don't really see how that would be precise enough, the
| mouse wheel has a DPI of like 10 vs 400-800 for a mouse. A
| mouse wheel has like 25 notches in a full rotation and even
| MIDI CC values go from 0-127, that's 5 full rotations, that
| doesn't sound practical as it would be far too slow. And
| many parameters require much more precise control than 127
| steps.
|
| I don't play flight sims but I imagine most flight surfaces
| require small adjustments and the effect of those
| adjustments on the aircraft is naturally smoothed out by
| the dynamics of the plane (you're adjusting an
| acceleration).
|
| I imagine the scroll wheel is not suitable for dogfighting.
| bolangi wrote:
| Good morning. An expanding plethora of buttons, tabs, menus
| requires geometrical memory that may have nothing directly to
| do with the function in question. The first GUIs were designed
| that functions be "discoverable," however the size of haystacks
| in which these discoverable functions hide has grown
| exponentially, adding cognitive overhead, and increasing the
| length of apprenticeship needed to master the application.
|
| A slick-looking GUI is a kind of ad for the app. As author of
| an accessible, terminal-based DAW app, I contrast remembering
| an incantation like 'add-track' or 'list-buses' with hunting
| around. These incantations can have shorter abbreviations, such
| 'lb' for list buses, and 'help bus' or 'h bus' to be
| sufficiently discoverable, easier for both implementer and
| user. And then to have hotkeys to bump plugin parameters +/-
| 1/10/100 etc. Probably I'm pissing into the wind to think the
| majority of users will ever choose this -- and GUIs do provide
| amazing facilities for many purposes -- but we do have a huge
| array of choices on linux, including this plethora of music
| creation and production apps. That is a big success, IMO.
| mimischi wrote:
| Mind sharing your DAW app?
| brindy wrote:
| What is the DAW that you are the author of?
| bandrami wrote:
| I can't think of the last time I used a knob with a mouse; you
| usually map it to a knob on a MIDI device and the GUI just
| gives you visual feedback
| mjr00 wrote:
| Really depends on your workflow. Many, many successful
| musicians are entirely or almost-entirely "in the box" and
| use mouse+kb for everything. Doubly true when you're talking
| about mixing and mastering workflows where you're not usually
| going to be using a MIDI controller at all (but doing plenty
| of knob-tweaking).
| masspro wrote:
| Also they are horrifically broken if you use OS-level magnifier
| (ctrl+scroll etc). I don't know if this is the application
| devs' fault or not; I haven't investigated OS mouse warping
| APIs. Warping the mouse back to the center of the knob goes in
| a feedback loop with the magnifier and spams crazy mouse events
| such that every knob will immediately go to min or max. Really
| shameful accessibility fail that no one cares about.
| Slow_Hand wrote:
| I use knobs everyday in my audio tools (with my track pad) and
| they're perfectly fine as long as they have three features:
|
| 1. Drag up/down to change value. 2. A modifier key to slow the
| drag for finer resolution changes when dragging. 3. The ability
| to double-click the knob and type in precise values when I know
| exactly what I want.
|
| The problem with knobs on a GUI is when designers stay with
| them when there is a faster option. Like an opportunity to
| combine three knobs.
|
| For example, the EQ on any SSL channel strip is a nightmare
| because they slavishly stick with a skeumorphic design of the
| original hardware. The hardware required mixers to use two
| hands to adjust gain and frequency at the same time, and then
| dial in Q on a third knob. Very tedious when you have a mouse.
|
| When this is done right, you get something like FabFilter's
| Pro-Q graphic EQ. The gain and frequency controls are instead
| an X/Y slider that you can easily drag across a representation
| of the frequency spectrum. In addition you can use a modifier
| key to narrow/widen your Q. All with a single click and drag of
| your band.
| mjr00 wrote:
| > For example, the EQ on any SSL channel strip is a nightmare
| because they slavishly stick with a skeumorphic design of the
| original hardware.
|
| True though I would put this very much in the "feature, not a
| bug" bucket. These tools are for people who have worked with
| the original hardware and want a very faithful emulation,
| including the look and feel. In the digital world with a
| modern PC there's not much purpose of a channel strip plugin
| in the first place, so the only people using one are doing so
| with intention.
|
| It's a bit like saying that manual transmission cars could be
| controlled more easily if they were automatic transmission;
| it's completely true, but if you're buying a manual you
| _want_ that experience.
|
| Pro-Q is a great example of a digital-first tool (the
| automatic transmission equivalent), with lots of great visual
| feedback and a lot of thought put into a mouse+kb workflow.
| All of Fabfilter's stuff is like this actually, though
| sometimes to its detriment; the Fabfilter automation and LFO
| system feels _very_ different from basically every other
| plugin. It 's actually a more efficient workflow when you get
| used to it, but due to how different it is from everything
| else most people I talk to dislike it unless they've really
| bought into the Fabfilter suite.
|
| Which kind of goes back to the original point: VSTs use knobs
| because it's what people are used to, and using something
| different might be a negative even if it's better!
| Slow_Hand wrote:
| I agree that the SSL channel strip GUI is deliberate
| because users want something that operates like the
| hardware. However, I would love the option to grab the freq
| knob and have it work like an x/y slider for freq/gain.
|
| Sure it mismatches the GUI, but it gives users the option
| when they don't want to do a click/drag for freq, then
| gain, then freq, then gain, then Q. You know?
|
| That tediousness is what keeps me from using the SSL
| channel strip altogether.
|
| Re: channel strip plugins: The advantage to using them in
| DAWs is speed and economy. Having everything in one window
| (ala the Scheps Omni Channel) saves me a lot of clicks vs.
| when I have multiple plugins in different slots.
|
| I do absolutely everything in the box with a laptop
| keyboard and track pad. My primary motive is being quick
| and precise, and the less plugin window management I have
| to do the better. The channel strip keeps the tools compact
| and my movements minimal.
| yowlingcat wrote:
| Are you experienced with DAWs as a composer or producer?
|
| Many if not most professional producers use MIDI controllers
| with knobs/sliders/buttons MIDI mapped to DAW controls. As such
| the skeuomorphism actually plays a valuable role in ensuring
| that the physical instrument experience maps to their
| workflows. Secondarily, during production/mastering, producers
| are generally using automation lanes and envelopes to program
| parameters into the timeline, and the piano roll to polish the
| actual notes.
|
| When I've historically done working sessions, the composition
| phase of what I'm doing tends to involve very little
| interaction with the keyboard, and is almost entirely driven by
| my interaction with the MIDI controller.
|
| Conversely, when I'm at the production phase, I am generally
| not futzing with around with either knobs or the controller,
| and I am entirely interacting with the DAW through automation
| lanes or drawing in notes through the piano roll. So I don't
| really ever use the knob through a mouse and I've never really
| encountered any professional or even hobbyist musicians who do
| except for throwaway experimentation purposes.
| londons_explore wrote:
| The real-time low latency multi channel audio streaming needed
| for musicians is awfully similar to the real time low latency
| multi channel audio streaming required for telephony.
|
| Yet somehow the two industries have pretty much entirely
| different tech stacks and don't seem to talk to one another.
| saidnooneever wrote:
| irony amplified by the nature of the tech stacks xD surely they
| can figure out some channel to communicate over clearly haha
| dagmx wrote:
| This is very much not true.
|
| Telephony is significantly less latency sensitive than real
| time audio processing, it's also significantly less taxing
| since you're dealing with a single channel.
|
| The level of compression and audio resolution required are
| significantly different too. You can tune codecs for voice
| specifically, but you don't want compression when recording
| audio and can't bias towards specific inputs.
|
| They're only similar in that they handle audio. But that's like
| saying the needs of a unicycle and the needs of an F1 car are
| inherently the same because they have wheels.
| sroerick wrote:
| This is a very interesting thought. I'm not super experienced
| with low level audio and basically completely ignorant of
| telephony.
|
| I feel like most people doing audio in music are not working at
| the low level. Even if they are creating their own plugins,
| they are probably not integrating with the audio interface. The
| point of JACK or Pipewire is to basically abstract all of that
| away so people can focus on the instrument.
|
| The latency in music is a much, much bigger issue than in
| voice, so any latency spike would render network audio
| completely unusable. I know Zoom has a "real time audio for
| musicians" feature, but outside of a few Zoom demos during
| lockdown, I'm not sure anybody uses this.
|
| Pipewire supports audio channels over network, but again I'm
| not entirely sure what this is for. Certainly it's useful for
| streaming music from device A to device B, but I'm not sure
| anybody uses it in a production setting.
|
| I could see something like a "live coding symphony", where
| people have their own livecoding setups and the audio is
| generated on a central server. This is not too different than
| what, say, Animal Collective did. But while live coding is a
| beautiful medium on its own, it does lack the muscle memory and
| tactile feedback you get from playing an instrument.
|
| I would love to see, as you said, these fields collaborate, but
| these, to me, are the immediate blockers which make it less
| practical.
| harvey9 wrote:
| Regarding Zoom, music lessons 1:1 online are still pretty
| common. I would guess this won't hold up with multiple
| musicians.
| NikolaNovak wrote:
| Music lessons online are common (I've been in them) because
| they're largely single duplex. Student plays, teacher
| listens. Then teacher comments and demonstrates, student
| listens.
|
| There are projects that aim to provide synced multi player
| jamming, but last I checked they are all based around
| looping. Human ear SHOCKINGLY does not lend itself to being
| fooled and will noticed surprisingly small sync issues.
|
| I always compare it with photo editing where you can cheat
| and smudge some background details with no one the wiser,
| whereas any regular non-audiophile will notice similar
| smudging or sync in audio.
| ssl-3 wrote:
| Sonobus is a software project that tries to accomplish
| live, audio-only multi-player jamming over the public
| network.
|
| It's still limited to whatever latency the network has,
| but it can be useful for some things. If that means it's
| mostly useful for loops, then that's up to the musicians.
| :)
|
| (I myself have used it for remote livestream
| participants, but only for voice. I was able to get
| distinct inputs into my console just like folks in the
| studio had, and I gave them a mix-minus bus that included
| everyone's voice but their own, for their headphones.
|
| It worked slick. Interaction was quick and quality was
| excellent. And unlike what popularly passes for
| teleconferencing these days: It all flowed smoothly and
| sounded like they were in the room with us, even though
| they were a thousand miles away.)
| qwertox wrote:
| " _Even if they are creating their own plugins, they are
| probably not integrating with the audio interface_ ".
|
| The audio interface is abstracted away in exchange for some
| metadata about the buffer's properties and the buffer itself,
| and that is true for basically everything related to audio:
| the buffer is the lowest level the OS offers you, and you are
| free to implement lower-level stuff in your dsp/instrument,
| like using assembly, maybe also functions for SSE, AVX or
| NEON based acceleration.
|
| You get chunks of samples in a buffer, you read them, do
| something with them and write the result out into another
| buffer.
|
| " _Pipewire supports audio channels over network_ " thanks
| for reminding me: I'm planning to stream the audio out of my
| Windows machine to a raspi zero to which I will then connect
| my bluetooth headphones. First tests worked, but the latency
| is really bad with shairport-sync [0] at around 400 ms. This
| is what I would use Pipewire for, if my workstation were
| Linux and not Windows.
|
| Maybe Snapcast [1] could be interesting for you: "Snapcast is
| a multiroom client-server audio player, where all clients are
| time synchronized with the server to play perfectly synced
| audio. It's not a standalone player, but an extension that
| turns your existing audio player into a Sonos-like multiroom
| solution."
|
| " _I could see something like a "live coding symphony", where
| people have their own livecoding setups and the audio is
| generated on a central server._" Tidal Cycles [2] might
| interest you, or the JavaScript port named Strudel [3]. Tidal
| can synchronize multiple instances via Link Synchronization.
| Then there's Troop [4], which "is a real-time collaborative
| tool that enables group live coding within the same document
| across multiple computers. Hypothetically Troop can talk to
| any interpreter that can take input as a string from the
| command line but it is already configured to work with live
| coding languages FoxDot, TidalCycles, and SuperCollider."
|
| [0] https://github.com/mikebrady/shairport-sync
|
| [1] https://github.com/snapcast/snapcast
|
| [2] https://tidalcycles.org
|
| [3] https://strudel.cc
|
| [4] https://github.com/Qirky/Troop*
| embedding-shape wrote:
| I feel like equating telephony and music production is like
| saying writing firmware and a HTTP/JSON backend for a website
| is the same. True, both are programming I suppose, but vastly
| different requirements, assumptions and environments.
| NikolaNovak wrote:
| Most telephony I've experienced has latency measured in seconds
| (if you ever call your friend or spouse sitting next to you it
| becomes very obvious :) vs audio recording and processing which
| is measured in milliseconds.
|
| Additionally, from what little I'm aware of, telephony is
| heavily optimized for particular frequencies of human voice and
| then heavily compressed within that. As well, any single
| telephony stream is basically a single channel. A song may have
| dozen of channels, at high resolution, full spectrum, all sorts
| of computationally demanding effects and processing, and still
| need latency and sync measured on milliseconds.
|
| So... Kind of the opposite of each other,while both being about
| processing sound :-).
| metalman wrote:
| it's an add for apps that cost as much as a box of decent used
| pedals and rack mount gear. though "linux musicians" does appear
| to be a thing, and the bot used to check if you are human, is
| amusing and fully automated.
|
| https://linuxmusicians.com/
| ofalkaed wrote:
| I actually assumed the link was linuxmusicians.com and I bet I
| am not the only one who assumed that. It is not an ad, but a
| store that also lists free software.
| belter wrote:
| Great demo of the JUNE - Classic Analog Polysynth JUNO-60 Plugin
| - AudioThing
|
| https://youtu.be/GMsUqsyy62Q?t=46
| notepad0x90 wrote:
| For some reason "Linux musicians" made me think of someone making
| art out of 'cat /dev/random > /dev/dsp', and made me wonder what
| Windows musicians are like (lots of anger and frustration to
| express I'd imagine)
| Lapsa wrote:
| any noise oscillator can serve a similar purpose
| NickC25 wrote:
| I currently run a PC based Ableton setup albeit one that is
| exclusively ITB and uses no external gear outside of a sound
| card and an Ableton Push gen 1.
|
| I've got no issues with it.
|
| deadmau5 is famously a PC guy as well, he seems to have no
| issues with Windows (that I know of or that are not extremely
| specific to a setup that involves millions of dollars' worth of
| hardware and multiple computers). His setup is like an
| amusement park for nerds.
| ofalkaed wrote:
| Back in the pre-alsa days when linux used OSS you could pipe
| /dev/random into /dev/dsp and get noise, you could pipe
| anything into /dev/dsp and generally get some sort of noise.
| Possibly can still do this on the BSDs since they still use
| OSS.
| kosolam wrote:
| The things I need are free and opensource
| bitbang wrote:
| https://lsp-plug.in/
| Joeboy wrote:
| I'm wondering if you missed that the site has checkboxes for
| "No charge" and "FOSS".
| gkhartman wrote:
| This is great. Makes these tools much more discoverable. I can
| help but notice the drop in plugin ui quality one you click the
| foss filter checkbox. Something in me wants a foss plugin to come
| with a cool skin like the free ones do, but I know that's silly.
| dylan604 wrote:
| It really says something about designers when there's so few of
| them contributing to FOSS projects. It also says something
| about FOSS devs that they don't/can't find better UI for their
| projects. Especially for web based UIs where CSS isn't _that_
| hard to look at sites you want to emulate and get much much
| closer to a respectable UI.
| Blackthorn wrote:
| Surge and vital have great UIs.
| vlowther wrote:
| It took quite a bit of scrolling until I found my old faves of
| dexed and zynaddsubfx, and I didn't see Helm
| (https://tytel.org/helm/) at all.
| anthony88 wrote:
| Surge XT is also at the bottom of the list.
| Blackthorn wrote:
| Helm has been replaced in practice by Vital (same author), I
| think.
| aeonik wrote:
| They are completely different synths.
|
| Vital is a wave table synth; Helm is a subtractive synth.
|
| Helm was the first synthesizer that I really excelled with. I
| would recommend anyone who wants to actually learn the
| fundamentals of synthesis, to start on it. Once you get good
| at to it, it's faster to dial in the exact sound you want
| than to reach for a preset.
|
| It's far more straightforward and less complicated than
| additive (ZynAddSubFX), FM, or wave table synths.
|
| That being said, if you just want a very advanced synth with
| a lot of great presets, Vital is _far_ more advanced.
| nofu7ur3 wrote:
| I submitted a suggestion to add the sophisticated multi-engine
| FOSS soft synth that I use, Yoshimi
| (https://yoshimi.sourceforge.io/) which is a linux only fork of
| ZynAddSubFX.
| sramsay wrote:
| This. Is. Awesome.
|
| Really. It amazes me that I _still_ find out about new Linux
| plugins after years of producing music on the platform. It could
| not have been easy to compile this; the information is all over
| the place online.
|
| The ability to filter (!) for compression, saturation, etc. is so
| great.
| chaosprint wrote:
| If you don't wanna use a daw on linux you are welcomed to try
| https://github.com/glicol/glicol-cli
| nartho wrote:
| Sure, as soon as you tell me how I'm supposed to record and mix
| a whole band with instruments with Glicol
| ufocia wrote:
| What about Ardour?
___________________________________________________________________
(page generated 2025-12-29 23:00 UTC)