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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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...
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
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.
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.
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.
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.
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 :-).
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
In fact, if it was all MIDI controlled, it's just a matter of mapping the mouse scroll wheel to a midi channel.
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.
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.
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.
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.
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...
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
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.
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.
Yet somehow the two industries have pretty much entirely different tech stacks and don't seem to talk to one another.
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.
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 :-).
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.
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.
https://kx.studio/
https://youtu.be/GMsUqsyy62Q?t=46
https://linuxmusicians.com/