[HN Gopher] OpenDAW - a new holistic exploration of music creati...
___________________________________________________________________
OpenDAW - a new holistic exploration of music creation inside the
browser
Author : raggi
Score : 142 points
Date : 2025-02-09 06:31 UTC (2 days ago)
(HTM) web link (opendaw.studio)
(TXT) w3m dump (opendaw.studio)
| raggi wrote:
| About: https://opendaw.org/
| dnjdkdldh wrote:
| Is this open source?
|
| Does it support plugins?
| rock_artist wrote:
| > To make the most of being open-source, we believe that there
| should be an appropriate infrastructure for documentation and
| quality assessment of code contributions. Our current focus is
| to lay the foundation for an MVP and release a public
| standalone version 1 by the end of the year.
|
| > If you want to help programming please be patient and wait
| for openDAW to be fully open-source. We will communicate this
| step loud and clear. Until then, we appreciate any feedback,
| testing and suggestions. Please log into our Discord server.
|
| > Yes, the offline native app will have VST support at some
| point in future.
|
| Source: https://opendaw.org (FAQ)
| twelvechairs wrote:
| Does 'MVP' in this context mean they want to sell something
| as a business, or just that they want a good functioning
| version (like, be out of alpha stage)?
| PaulDavisThe1st wrote:
| Or they just read HN too much?
| handity wrote:
| This is remarkably complete.
|
| But it makes me question why "the browser" is apparently still
| the inevitable platform of the future.
|
| In order for a PWA to be normal and usable, it must be available
| offline, open in a window without browser chrome, have similar
| performance to a native application, be launchable via a shortcut
| on the host OS, and respond to the mouse and keybaord shortcuts
| the way you'd expect. I think I've just described... an Electron
| app?
|
| It's cool that this kind of thing can run in a web browser. With
| no install hurdle, it's much easier to convince people to try it
| out, and it's cross platform. Beyond that I can't really think of
| any advantages to having it run in the browser.
|
| If what's lacking is an easy way to try software, I can't help
| but imagine lots of ways this could be addressed that would be
| much more pleasant to use than loading PWAs. Right now I can't
| seriously see myself enjoying using a PWA for work.
|
| I say this having recently finished several large design projects
| in Figma, which is apparently a gold standard success story for
| browser based apps. Despite the years of development and
| herculean engineering efforts, I can still _feel_ the browser
| jank. I begrudgingly open the thing in chrome, as it completely
| chokes in Firefox. It still chokes on moderately sized canvases,
| moving things is slow and laggy compared to native apps, keyboard
| shortcuts sometimes don 't work or keys get stuck in a weird
| pressed or unpressed state, loading is slow, elements pop-in over
| tens of seconds.
|
| I know I'm an old man yelling at clouds at this point, I'm just
| disappointed that we seem to be going backwards in performance
| and usability of software.
| jampekka wrote:
| > In order for a PWA to be normal and usable, it must be
| available offline, open in a window without browser chrome,
| have similar performance to a native application, be launchable
| via a shortcut on the host OS, and respond to the mouse and
| keybaord shortcuts the way you'd expect. I think I've just
| described... an Electron app?
|
| You've just described a PWA. You can install them as a host OS
| shortcut, they run without browser chrome, should have
| performance equal to Electron.
|
| Also if you really want extra bloat and faff, any PWA is
| trivial to turn into an Electron app.
|
| Most of PWA criticism is based on misunderstanding PWA
| capabilities.
| handity wrote:
| I'm reassured that my comparison to Electron was not far off.
| My point was, if a PWA is usable when all the above is
| implemented, what you end up with is very similar to a self-
| updating Electron app, just one that may or may not rely much
| more heavily on the network at runtime and might work offline
| (or not).
|
| I admit I didn't realize creating a shortcut to a PWA was
| already supported as it's not pushed very hard. In Chromium
| it's buried under dots, "Cast, Save and Share" (which is a
| bizarre mashup of disparate functions), and finally "Install
| page as app".
|
| The window that loads still has browser chrome, in the form
| of a back, refresh, and three dots button. As soon as you
| navigate somewhere, even within the same app, the url bar
| appears again, but you can't edit it. It seems that to be
| able to always hide this bar, you'd need a way to
| differentiate between "internal" links that should navigate
| within the page, and external links that should open in a
| browser.
|
| I tried turning off my internet, and neither figma nor
| openDAW showed anything more than a blank page, which
| confirms my feeling of uncertainty around PWAs, namely, how
| do you know what will actually work offline. It feels
| fragile, like if I reset my browser or my clear my cache, my
| installed applications will disappear. I'm not sure I'm
| comfortable with the blurring of the lines between bookmarks
| and installed applications.
|
| All this is of course addressable with a lot more
| infrastructure and work from browser and OS makers. To me it
| seems like a lot of development to end up with something that
| behaves a lot like Electron, with the added easteregg of
| being able to access applications in a browser, without
| intending that anybody actually do so.
| jampekka wrote:
| > just one that may or may not rely much more heavily on
| the network at runtime and might work offline (or not).
|
| PWAs can run fully offline using service workers.
|
| https://developer.mozilla.org/en-
| US/docs/Web/Progressive_web...
|
| > In Chromium it's buried under dots, "Cast, Save and
| Share" (which is a bizarre mashup of disparate functions),
| and finally "Install page as app".
|
| Chromium supports prompting the user to install the app.
| There's also an icon in the address bar if the page has an
| app manifest.
|
| https://khmyznikov.com/pwa-install/
|
| https://developer.mozilla.org/en-
| US/docs/Web/Progressive_web...
|
| > The window that loads still has browser chrome, in the
| form of a back, refresh, and three dots button.
|
| The window appearance and behavior can be changed using the
| app manifest, although getting rid of the three dots may be
| impossible in some platforms.
|
| https://developer.mozilla.org/en-
| US/docs/Web/Progressive_web...
|
| > I tried turning off my internet, and neither figma nor
| openDAW showed anything more than a blank page, which
| confirms my feeling of uncertainty around PWAs, namely, how
| do you know what will actually work offline.
|
| Figma nor OpenDAW don't seem to be configured as offline
| PWAs.
|
| > All this is of course addressable with a lot more
| infrastructure and work from browser and OS makers.
|
| The problems you encountered are mostly solved in PWA APIs
| already, at least for Chromium based browsers. There is
| some variation in some features between browsers and OSs
| (Safari and iOS are particularly bad).
|
| > To me it seems like a lot of development to end up with
| something that behaves a lot like Electron, with the added
| easteregg of being able to access applications in a
| browser, without intending that anybody actually do so.
|
| PWAs are e.g. easier to install, have smaller footprint,
| are more portable and are a lot more secure. Not sure what
| you mean by "accessing applications in a browser". PWAs
| can't access anything a normal website can't.
| zb3 wrote:
| > why "the browser" is apparently still the inevitable platform
| of the future.
|
| Because it doesn't require trust. The browser actually got the
| permission model (almost - but there are extensions) right. I
| can safely open this and not worry about security.
| akx wrote:
| We've had https://www.audiotool.com/ for 15 years...
| Polarity wrote:
| the developer of audiotool literally is the creator of openDAW
| demarq wrote:
| Definition of success. When people point to your competitor
| and the competitor is still you.
| akx wrote:
| Heh, the more you know! OpenDAW didn't make that obvious.
| gordy_gordstein wrote:
| And I've been trying to use it for 15 years, and each time I
| think "ok, next PC upgrade, this is gonna be sick!" ...and it's
| still molasses. Not even criticizing it. I've been pumped about
| it from the start, but it was asking a lot of the web as a
| platform 15 years ago.
|
| This is featherweight in comparison, and a lot closer to a
| traditional DAW than audiotool's skeuomorphic virtual analogue
| approach.
| inatreecrown2 wrote:
| This is impressive but, why would I use this over other DAWs? Why
| name it openDAW if it is not open source?
|
| edit: I like the idea of the "Discoverable Toys" and can see how
| this could develop into something new. But why not just
| concentrate on that and bring it to other DAWs in form of a
| plugin, instead of writing a whole new DAW in the browser?
| mijoharas wrote:
| Good question, I read the about page[0] which says:
|
| > Will the DAW be open source from the start or only become
| open source later?
|
| > To make the most of being open-source, we believe that there
| should be an appropriate infrastructure for documentation and
| quality assessment of code contributions. Our current focus is
| to lay the foundation for an MVP and release a public
| standalone version 1 by the end of the year.
|
| So it seems that they intend to open source it later. Still a
| bit of a strange move, but fair enough I guess.
|
| [0] https://opendaw.org/
| jampekka wrote:
| I would welcome a new open source DAW. Ardour is the go-to
| option now, and is very capable, but it's starting to show its
| age and the UI is quite clunky (or an acquired taste at least).
|
| Also the open source audio editor situation is quite dismal.
| Audacity is really the only game in town. It's showing its age
| too and its trajectory doesn't look great. A more editing-
| focused DAW, which OpenDAW seems to be, would be very welcome.
| Mashimo wrote:
| > instead of writing a whole new DAW in the browser?
|
| Ease of use. Login without installing anything, work on a
| project on the tabled on the train, later on continue the
| project without syncing it somehow, all while working in
| collaboration with a friend.
| p0w3n3d wrote:
| There is no such thing as DAW inside a browser. DAW is mostly
| about the lowest latency possible unless it's for the sole
| purpose of sound creation (synthesis/sampling). This would allow
| it to bear the name Digital Audio Rework Station (DARwS) In all
| other cases lowest latency, ASIO drivers etc. are a must-have.
| jampekka wrote:
| Minimal latency is only really needed for live performance and
| monitoring, though these do tend to be crucial demands in most
| cases. A major problem for browsers is also poor support for
| multichannel devices.
|
| They do plan to have a "native wrapper like tauri" in the
| future. I've played around with node-web-audio-api for low
| latency multichannel for Electron, but it wasn't a great
| success. Mostly because Rust audio backends (and almost all
| audio backends in general) aren't very good in such usage.
|
| https://github.com/ircam-ismm/node-web-audio-api
| input_sh wrote:
| If you're just picking up samples from Splice or whatever and
| arranging them, sure, latency means nothing, but it becomes
| pretty crucial when you're recording an instrument.
| worthless-trash wrote:
| Why would recording be the latency sensitive part, wouldnt
| it be the playback ?
| fnordlord wrote:
| I'm guessing they mean the monitoring latency while
| recording. For me, that's one of the most vital parts of
| a recording environment. If I hit the key or the drum and
| hear it come through the headphones 50ms later, it's
| completely unuseable.
| itishappy wrote:
| Delays can be compensated for during either recording or
| playback, the problem is when both at the same time. It
| just so happens that recording is typically done "in-the-
| loop" with the backing track being played through
| headphones during the session.
| p0w3n3d wrote:
| Not if multitrack recording. If you record it with different
| latencies you're toast.
| jampekka wrote:
| Not if you know the latencies.
| Mashimo wrote:
| Why do you need the lowest latency possible to operate a DAW?
| prmoustache wrote:
| It is important if you are driving hardware synths and
| samplers through midi.
|
| Otherwise latency is not really a problem.
| wdfx wrote:
| > Otherwise latency is not really a problem
|
| This is absolutely not true. Latency in audio systems is
| important in almost every aspect of using a DAW
| jcelerier wrote:
| it's pretty hard for me as a musician to record guitar
| tracks in sync if I'm not getting the lowest latency
| through my computer (since I try to use e.g. software amp
| sims & pedals, etc.). Past ~8ms I feel it when I play, past
| 15ms I can hear the less accurate playing in the recorded
| tracks.
| Aldipower wrote:
| Use direct monitoring of your interface or an mixer in
| front of your interface. Then you can get away with 0ms
| (an analog mixer) or 2-4ms (interface direct monitor).
| Your DAW will latency compensate the "record head". It is
| just a matter of signal routing. It took me 20 years to
| get to this simple solution. :-D
| TehCorwiz wrote:
| There are three places to accumulate latency, the input from
| the instrument to the computer, the processing of filters,
| the output to the monitor (headphones/speakers)/recording.
| Sometimes you can get away with 2 or 3 ms of latency, but
| anything over 5 ms is super frustrating. Remember, you're
| fighting the latency between plucking a string or hitting a
| key and when the computer acknowledging the data and sending
| it back out to the monitor which you're using as your guide.
| Best case you go and "massage" the new track to line up with
| the existing tracks, worst case it sounds like an out of sync
| high school marching band.
|
| EDIT: The concerns here are primarily with input latency.
| Between plucking a string and heading it in your monitor it
| has to go through: your input hardware, the USB interface,
| the OS, the browser (which doesn't have explicit low latency
| capabilities), and JS. Most platforms support ASIO which is a
| low-level driver for reading audio data from devices. About
| as close to reading the ADCs yourself. Without a low-latency
| driver working with the OS there's so much latency overhead
| it's audible.
| Mashimo wrote:
| Thanks.
|
| AFAIK ASIO is windows only.
| TehCorwiz wrote:
| I think you're right. I remember trying to use it on
| Ubuntu about a decade ago, but it seems that was through
| some wrapper.
| gordy_gordstein wrote:
| JACK Audio Connection Kit is generally the way to go on
| Linux. Arch wiki has a page on "Professional Audio" with
| more detail for the curious.
| PaulDavisThe1st wrote:
| There has never been ASIO on Linux. ASIO is a 3rd party
| (Steinberg) driver API exclusively for Windows.
| TehCorwiz wrote:
| I used WineASIO way back on Ubuntu 14.
| https://sourceforge.net/projects/wineasio/.
|
| Checkmate ;) j/k
|
| You're right, it's not natively on Linux, and you
| wouldn't use it on Linux today since the kernel supports
| lower latency IO and has better scheduling. Jack has
| gotten so much better. We didn't have that at the time
| and I was desperate to use the only interface card I had.
|
| That said, there are plenty of open source
| implementations of ASIO drivers now that aren't hardware
| tied.
| PaulDavisThe1st wrote:
| > you wouldn't use it on Linux today since the kernel
| supports lower latency IO
|
| Actually you absolutely would use it, in the same way you
| did back then.
|
| WineASIO is a layer that allows a Wine application to use
| the ASIO API. Since ASIO is not a part of Windows itself,
| anything that wants to use ASIO can't do so on "bare
| Wine", and Wine doesn't allow for the installation of a
| windows kernel driver layer like ASIO. Hence: WineASIO -
| an implementation of ASIO for use by Windows applications
| running inside Wine.
|
| Also, Ubuntu 14 dates to 2014; JACK dates back to 2002.
| Very little, if anything has changed about JACK since
| 2014. AFAIR, WineASIO could or did use JACK itself at
| some point in its development history, since it was a
| pretty natural fit.
|
| I don't know of any open source ASIO implementations. The
| only 3rd party one of, ASIO4ALL, is not open source. Then
| again, I don't track the Windows environment much at all.
| TonyTrapp wrote:
| ASIO was just one of the first audio APIs to provide
| high-quality, low-latency audio. Many people haven't
| realized that native audio APIs have moved on since then.
|
| macOS has proper audio APIs out of the box, and arguably
| since the introduction of WASAPI exclusive mode and
| WaveRT in Windows Vista, Windows has all the needed tools
| as well. But most of the more "professional" DAW products
| (in particular those by Steinberg, the author of ASIO)
| seem to ignore the existence of those. REAPER is one of
| the exceptions. Even WASAPI shared mode latency is really
| usable (below 30ms), but not low enough for tightly
| synchronized real-time recording.
|
| Linux audio can be set up to provide low-latency audio as
| well, but I cannot comment on the details there as I'm
| not using it for that purpose.
| bugbytz wrote:
| Not to mention DPC latency for us Windows customers
| IsTom wrote:
| 5 ms is 1.7 meters at speed of sound. If that was the issue
| then any acoustic live band would fall apart.
|
| Jitter is a much bigger problem.
| Aldipower wrote:
| And it does. A live band on a bigger stage with improper
| monitoring (too far away, not existent) isn't fun to play
| in.
| IsTom wrote:
| That "bigger" is certainly more than two meters.
| wdfx wrote:
| Because when you want to record your instrument along with
| whatever else is in your project, timing is critical and
| everything needs to line up.
|
| You cannot be performing to audio that you are hearing with
| any delay, especially if the monitoring of the live audio is
| also being routed through software.
|
| At a certain point of latency it introduced delays and badly
| affects how you perform. In some circumstances it makes
| performance actually impossible.
|
| There are ways around this, namely if the software knows
| exactly what the input and output latency is then the
| playback and recording can be compensated. For live
| monitoring though you really need that done in the audio
| hardware itself in hard real time.
| tigeba wrote:
| Music is very latency sensitive. If you are recording any
| source you generally want to have overall latency < 5ms.
| Input and monitoring latency is usually either handled by
| using fancy DSP systems or a "hack" where input audio
| bypasses any internal processing and gets routed directly
| back for monitoring.
| tnolet wrote:
| No, low latency is not needed for all non-realtime things. Even
| then, you are looking for latency compensation. Just add one
| VST plugin to an audio track and you will instantly add
| latency.
|
| The crux is you want everything to play in sync when doing
| recording and overdubbing, e.g. "hit record and what I hear
| live is in sync with what I have recorded already". Almost all
| DAWs solve this by just starting things a bit later (latency
| compensation). Some audio cards solve this by allowing direct
| hardware monitoring. But even then you will have some samples
| of latency.
| jcelerier wrote:
| > Just add one VST plugin to an audio track and you will
| instantly add latency.
|
| most plug-ins don't add latency ?
| tnolet wrote:
| All plugins add latency. They just report that in their API
| and your DAW compensates. There is no way eliminate CPU
| cycles being spent on whatever the plugin does.
| squeaky-clean wrote:
| That's for plugins with an explicit fixed latency to use
| PDC. If a plugin doesn't request latency, which most do
| not, they have the duration of the DAW audio buffer to
| complete their processing. If the combined processing of
| all active plugins on a single thread exceeds the audio
| buffer duration you get audio drop-outs, or portions of
| the buffer which are just zeroes because they were unable
| to be processed in time.
| nerflad wrote:
| A lot of people who have apparently never stepped foot in a
| recording studio are replying to you. Pre-plugin era was
| exactly about this. Drive the DAC and manage writes to the disk
| without introducing (much) latency so tracking can get done.
| Perhaps no one who uses this will intend to setup more than one
| microphone.
| wdfx wrote:
| Absolutely agree with you here.
|
| There's a huge divide between people who might play with this
| at home as a toy and those who would be able to work with
| professional musicians with it.
|
| The latter group will have some very strict requirements
| around performance, latency and workflow.
|
| Edit: and reliability
| tigeba wrote:
| Just going to add this RE: reliability. Today CPUs are so
| powerful you don't need DSP systems anymore to do things
| like low latency tracking. It is still up to the user to
| manage latency by carefully selecting plugins, etc. With
| DSP based systems, the latency is generally fixed and
| extremely stable. I still use a very old PTHD system
| because it works great for recording audio :)
| PaulDavisThe1st wrote:
| Latency is not related to CPU power, until the DSP load
| starts creeping up. For just low latency tracking, a 486
| is perfectly capable.
| tigeba wrote:
| As a practical matter, the CPU has to deal with IO as
| well, I don't believe any 486 systems could handle this.
|
| DSP based systems struggled a lot with IO in the late 90s
| until faster SATA drives became ubiquitous. Lots of them
| used SCSI or exotic hardware cards to deal with large
| track counts.
| PaulDavisThe1st wrote:
| The first version of Ardour was written on a 25Mhz 486
| and could record 24 tracks of 24bit 48kHz audio without
| breaking a sweat.
|
| It did have a SCSI drive, but in 1999 I did not consider
| that "exotic", having been using them on various Unix
| workstations for more than a decade before that.
| Aldipower wrote:
| My 286 with a Voyetra Sequencer, which is still in use,
| is much more reliable then my modern PC in terms of
| tracking and timing. You need a real time system, perfect
| task separation and _not_ an unreliable USB interface. It
| has absolutely nothing to do with CPU power. Also my
| Atari with Cubase 3.1 is much much better with MIDI
| timing then every modern PC setup. Think about it. :-)
| tigeba wrote:
| Just to be clear I'm talking about digital audio, not
| MIDI. I ran Cakewalk on my 386/486 as well, it worked
| great including SMPTE sync over to an analog tape machine
| p0w3n3d wrote:
| I used to use special FireWire extension card to have low
| latency, however I think this has been fixed in usb 3.0.
| the problem is when you have multitrack mixer that sends
| you many outputs all of them being different soundcards
| visible to the computer. Of course one guitar + VST will
| give you a little lag but you'll just push it back a
| little and it will do. Or will it?
| beAbU wrote:
| Most audio interfaces support direct monitor, so there is
| essentially zero latency between your source and the monitor
| when recording tracks. DAWs then allow you to set the latency
| as a "take nudge" where the take is immediately nudged by the
| known latency amount, so that when you play back your tracks
| they are in sync.
|
| Lastly, some fancy interfaces have built in DSP, so that you
| can load your effects right in the interface, for when you want
| effects in your recording monitor feed...
|
| So I dont think latency is that critical anymore, and with a
| decent interface its mostly sorted out.
| Aldipower wrote:
| Second this. You can even go down to exactly 0ms of latency,
| if you are using an analog mixer with multiple simultaneous
| output routes in front of your digital interface. One output
| route is for live monitoring the other is for live recording.
| The DAW just needs to latency compensate the "record head",
| which almost every professional DAW is doing of course.
| _Every_ studio is working like that. OK, a lot of studios
| have digital mixers nowadays, that adds maybe 2-4ms of
| latency, which is still ok.
| Polarity wrote:
| I think it's time for a truly open Digital Audio Workstation one
| that's actually usable, well-designed, functional, and free from
| logins, cloud dependencies, or mandatory subscriptions. Something
| you can simply download or access from any platform that supports
| a browser.
|
| That's why I really like the idea of building a DAW in the
| browser, it has huge potential for all kinds of users, especially
| in education, whether for kids, older people, or just anyone who
| wants to make music on the go, no matter what device they're
| using.
|
| I see a lot of promise in this project and fully support Andre,
| who has already contributed to developing great audio tools.
| Parae wrote:
| It already exists. It's called Ardour. Paul, the main developer
| is quite active on HN.
| PaulDavisThe1st wrote:
| I suspect the GP doesn't think much of Ardour's design :)
| Aldipower wrote:
| Try Bitwig under Linux. I am very happy with it.
| jdefr89 wrote:
| Neat.. But.. Why? There are already a ton of DAWs and at this
| point all of them essentially support the same features and folks
| end up using all the same Waves VSTs... DAWs can be resource
| intensive when low latency is key (say recording vocals). Browser
| DAW ain't gonna do so well for that type of thing. Still cool
| though..
| anthk wrote:
| ORCA under Uxn (or a browser) it's far more fun.
| sramsay wrote:
| But is not, in any sense of the term, a DAW.
| HelloUsername wrote:
| "reece" should be "reese"
| dmje wrote:
| This is deeply impressive, and of course the first thing I'm
| doing is sharing it with some mates. The technical completeness
| of this, the fact that you can do this sort of thing in the
| browser at all - that to me is mindblowing (I'm 52 and remember
| when marquee tags were a bit of a stretch...).
|
| But... like other commenters - there it stops, and I'm just not
| quite sure _why_.
|
| The audience is probably me. I'm an avid Ableton user - I pay a
| bloody fortune for it, I upgrade it every year, I am happy to
| support their development because it's an insanely - insanely -
| good piece of software that does everything I need it to do. I'm
| also now completely embedded in the clip view, so going back to a
| linear view just isn't a possibility for me.
|
| More to the point though - this clearly isn't aimed at people who
| know nothing about what they're doing. It's very non-amateur and
| clearly very, very powerful. But at the same time it isn't aimed
| at me, either - as someone who does know what they're doing, I'm
| thinking "um, VSTs?" or "clip view?" or "live performance /
| latency issues?" or whatever.
|
| So... who is the audience? Maybe there is a middle ground of
| people who don't have the means to fork out for a good desktop
| DAW. Maybe teenagers who are wanting to learn the principles
| without the spend. Maybe because it'd be very cool for
| collaborating? I just don't know.
|
| Nonetheless, it's an insane demonstration of what can be done in
| a browser these days and for that I massively doff my cap -
| amazing work!
| bugbytz wrote:
| My question is why not just have a desktop daw implement rpc on
| their daemon to work collaboratively natively instead of being
| sandboxed in a browser? Or does this already exist?
| wdfx wrote:
| Isn't that's asking for terrible UI latency?
| sowbug wrote:
| IPC latency is typically measured in nanoseconds.
| wdfx wrote:
| Even with an electron UI?
| gravitronic wrote:
| there is a DAW with that feature, they then extracted the
| multiplayer core and license that. Forget the name, though.
| conradfr wrote:
| Never tried it but there was was Ohm Studio from French
| company Ohm Force.
| rdelpret wrote:
| I would be down for a browser ableton suite that had all the
| stock devices and didn't have vst support. I think over time
| people learn that you can do 90% of what you need to do with
| just stock devices (although max4live support would be amazing)
| catapart wrote:
| I will never understand "music software" people. I just do NOT
| get where their heads are at, in any way, shape, or form. If you
| asked me to come up with the worst way to deal with audio in
| software, it would look very much like what most DAWs currently
| look like.
|
| I say this as someone who makes music and records it on a PC
| (MacOs/Windows/Linux), AND as someone who makes software for
| those same OSes. Admittedly, I do not really mess with loops or
| synthesizers, so I acknowledge those use-cases as some that might
| actually seem reasonable with current DAWs, but I definitely do
| not "get" it. I get bored screwing with synthesizers/filters
| (funny noise machines), and I use loops mostly with simple
| sequencers. So most of my time is spent producing and managing
| waveforms. To that end, every DAW looks - to me - like a god
| damned file manager, rather than a space for making content.
|
| I'd LOVE for one piece of software to treat me like a user,
| rather than an audio engineer. I need a timeline, sure, but FIRST
| I need to pick an instrument; either by plugging it in (and the
| software auto-recognizing it), or by selecting a synth. I also
| need to pick a controller, if it's a synth. THEN I need to be put
| into an area where I can immediately get feedback for that thing.
| I don't need it to ONLY play when I hit record, or when I'm
| logging to the timeline. I need to have an empty space where I
| can start doing "takes". Simple snippets that I can refer back
| to. Auto-split during "silence", so I don't have to scan through
| a massive timeline to find the bit I liked. Obviously the mixers
| and things need to be summonable, here, for tuning. But they
| don't necessarily need to already be present. I don't need 18
| knobs for tuning while I'm scritching out a riff, or finding the
| melodic line with my voice. I need to be able to try a thing,
| edit the settings, try again, edit again, back and forth until I
| feel like I'm "here in the space".
|
| Again, this is like...every recording studio I've ever been to.
| You take some time to get your gear set up and, while that's
| happening, you play the things and find your sound in this space.
| Yet every piece of audio software just pretends like all of their
| audio processing isn't a change to the "space". It treats audio
| input a kind of "pure" input which it will alter, but doesn't
| immediately let musicians get a feeling for that alteration.
| Instead, we get infinite complexity right up front because
| "that's how computers work" or "that's how the files are handled"
| or "it's based on older stuff that had such limited processing
| this was the only way it could be done; now people are used to
| it, so we can't change it".
|
| All nonsense. I'm not asking for every DAW to be geared towards
| musicians, I'm asking for ONE. Let ProTools still be ProTools. Or
| Audacity still be Audacity. But I'd really love if someone could
| make software for a 6 year old to plug a guitar into and start
| playing.
|
| *yes, I am in a position to make that kind of DAW, and yes I do
| have the requisite insight to build the thing I'm asking for.
| And, boy, if I ever get the time, it's on. But I won't be holding
| my breath for my other projects to clear out enough to make this
| happen.
| gizajob wrote:
| One of your main issues is describing art and music as
| "content".
|
| Ableton Live at least is a phenomenally powerful tool for
| arranging and recording music in a way that is completely
| elastic and transformative. I've been using it for over twenty
| years to make records and every time I've wanted it to do more,
| somehow those features have been magically added on every
| version without me having to ask.
|
| The thing with any tool is that one has to know what result one
| wants rather than focussing on the method.
|
| Your post reads like you should maybe think about doing
| creative things other than music. And I'm sure we'd be all ears
| for the improved DAW that you never got round to writing yet.
|
| Apple also made that tool for six-year-olds and their guitars.
| It's called GarageBand. Some of those six-year-olds have made
| albums with it.
| catapart wrote:
| I'm game: give me the steps it takes to get a kid with an
| electric guitar and an appropriate USB connection to A) start
| making noise with the guitar in the software, and then B)
| start filtering that noise to sound like electric guitar
| distortion.
|
| My post reads like a person who has tried every DAW I know of
| and ended up with at least 10 steps (usually involving "sign
| up" and "log in" for no fucking reason), when there should
| only be 3: Plug in, open app, pick guitar.
|
| I've mastered enough CONTENT to know that Ableton is great!
| Not just at MUSIC but at sound effects, at
| atmospheric/environmental engineering, too. But Ableton is
| still an engineer's software, not a musicians.
|
| Again, I'm not complaining that the good things work good at
| what they're good at. I'm complaining that no one seems to be
| working on different good stuff for different kinds of
| people.
| gizajob wrote:
| The people that made Ableton were musicians - see Monolake.
| I've used it for making psyche rock albums and I'm pretty
| sure I could use it for producing pretty well any kind or
| genre of music. I'm a musician primarily and not an
| engineer, so I've no idea what you're talking about saying
| Ableton is an engineers software. Some of your point about
| Pro Tools is right because that's completely hamstrung and
| backward due to it being from the era of Amigas and MacOS7.
| But modern alternatives exist that overcome that. It really
| sounds like you need to buy Ableton - it really is turn on,
| plug in, make music.
| catapart wrote:
| Again, I have Ableton. It's great software (for audio-
| engineer-inclined people).
|
| Whether the people that made Ableton are musicians or
| not, or whether you're a musician, or not, is all
| irrelevant. They made software that is a thin layer over
| the literal functions of the machine because that's how
| all DAWs are made. "Don't fix what ain't broke." It's a
| great way to run a business. You learned their way of
| working, either from the software itself, or from other
| DAWs, and you like it. Great! Literally every musician
| for the past 2 decades has come to work with these DAWs,
| so it's not like working in a format for audio engineers
| is incompatible with being a musician. I'm quite certain
| it helps, actually.
|
| But, again, none of that speaks to the complexity of
| using the software as someone who doesn't know anything
| about DAWs or modern audio software. I know a guy who can
| play the guitar beautifully; yet he can't figure out
| Ableton. I've sat him down multiple times and showed him
| some really cool stuff that he really liked, but he has
| never once not called me when he tried to use the
| software. Some people just aren't built like that. He is
| thinking about music in one form, and the computer wants
| him to formalize it in some different form. And he just
| can't or won't make the bridge.
|
| And you may say: "well, fuck him; he should learn Ableton
| or be doomed to live without its benefits". More power to
| you. But I just wish there were something ELSE that would
| speak to him in his language.
| PaulDavisThe1st wrote:
| I think the deeper process here is this: if you're a
| musician and you start using a DAW, pretty soon you'll be
| an engineer, whether you intended to be or not.
|
| In the days before DAWs, the role of musician and
| engineer were both critical for recorded music, but also
| mostly distinct. DAWs have changed that fundamentally
| because there's very little capital outlay required for
| the engineer's tools these days.
|
| We've seen this over the years in Ardour. A musician
| wants a big red button and an application that will find
| their device signal all by itself. Two weeks later they
| want to use an EQ. Two months later they want to be to
| arrange whole sections. Two years later, and they don't
| like the pan power law and have some criticisms of the
| automation interpolation.
| tonyarkles wrote:
| > I think the deeper process here is this: if you're a
| musician and you start using a DAW, pretty soon you'll be
| an engineer, whether you intended to be or not.
|
| There's a bunch of stuff like that happening in that
| industry as the equipment evolves. I've been doing
| software/networking/hardware for coming up on 30 years
| now. My wife's been doing mostly live audio/production
| with some recording for about the same amount of time.
| Starting about 10 years ago she had to start learning
| about networking. It started simple with things like
| setting up routers/WiFi access points for controlling
| consoles with iPads. Now with AES-67 she's had to learn a
| whole bunch about RTP, PTP, QoS, VLANs, DHCP, subnetting,
| etc. It's working out well for her, she's incredibly
| sharp and many of her peers come to her for
| advice/consultation when things aren't working right, but
| it was definitely not something she expected to need to
| learn. When everyone's stumped they give me a call... I
| don't know much at all about the audio side of it but a
| little bit of Wireshark can usually explain what's broken
| in their systems.
| gizajob wrote:
| What are you on about at this point. It's just a rant.
| Buy a tape machine.
| HelloNurse wrote:
| 10 steps are very few. The right combination of hardware
| and software allows plugging in the guitar and playing, but
| only after an unavoidable adventure in "computers are
| complicated" land.
|
| The difficulty is essential: compared to plugging the
| guitar into an analog amplifier, you have a minimum of
| three devices (ADC with guitar-compatible input, computer
| including DAC, speakers), the user interface is
| virtualized, you need to find and install the right
| software (including device drivers).
|
| So your kid with an electric guitar should either use
| analog amplifiers and effects, or borrow a good setup from
| some "engineer", or take advantage of their youthful
| stubbornness and enthusiasm to learn enough about the
| technical aspects you dislike.
| bugbytz wrote:
| Still waiting on a "copy time" function to magically appear
| wdfx wrote:
| I understand the frustrations with the current DAW offerings.
| Many of them have a very long history in taking over where the
| analogue tape machine left off.
|
| Some have developed much further though to support a more
| digital-first approach.
|
| But it's true that the barrier to entry can still be very high.
| Trying to explain any of these packages to a musician who is
| not also a computer power user is extremely challenging,
| believe me I've tried.
|
| If we could arrive at a point where a DAW can be intuitive to a
| musician and not technically overwhelming that would be very
| interesting.
|
| What would be more interesting though would be if that same
| project could be viewed in an "engineer mode" which exposes the
| technical view for someone else to work on at a different
| level.
| catapart wrote:
| Exactly! It's too high a barrier to entry. And it doesn't
| matter how low that barrier is: if people won't use it due to
| it, that's too high. Crazy how much pushback I get on that
| idea.
|
| As far as the "engineer mode" that's what I think galls me
| most: You can't really write audio software without all of
| the technical stuff so you're going to NEED that stuff
| anyway. AND, as someone matures in their musical ability,
| they often need to do more specific fine-tuning which would
| require those features. And that means that you could
| basically funnel non-audio-engineers into understanding at
| least the parts they need to make their own music when the
| time came. There's no better way to learn than to solve a
| "problem", even if that "problem" is just "how do I tighten
| up the high end on this so it makes this cool sound I want?"
|
| In short: making a DAW for musicians is not only accessible
| to non-audio-engineers, it's also a gateway drug to semi-
| audio-engineers and their explorations. I'm just all for
| that!
| wdfx wrote:
| Dare I say it but perhaps some sort of natural language
| input would be interesting here.
|
| If the software was primarily driven by a command list
| back-end, had a bunch of semi-preset solutions to common
| problems, and also could be "spoken to" - would that feel
| more comfortable for our musician user?
| catapart wrote:
| I could definitely see it! I would think that voice
| commands would be more for the musician side of it, such
| as "start", "stop", "cut", "redo", "alternate", stuff
| like that. Don't really need tensors for that. But yeah,
| once they have a question about "how do I...?", you can
| layer in some of the latest DeepSeek-style chain-of-
| thought stuff and probably get some actually useable
| results with it.
|
| Still though, all of that is a layer AFTER that initial
| barrier to entry.
| wdfx wrote:
| > how do I...?
|
| Even this is still a problem, because it's unlikely they
| know even what question to ask. Or if a sensible question
| is asked it may be an XY problem, where what is really
| intended is not what is asked.
|
| Having thought about this for the last few minutes, it
| does seem inevitable that the software would have to
| start coaching the musician in the ways of the
| engineering and of "music software" people, so that the
| inputs become more accurate and aligned with the outcomes
| the software is capable of providing.
|
| I think everyone would crave becoming more productive in
| the environment over time and not have to suffer the
| initial baby steps forever.
|
| It's very difficult to imagine a DAW environment which
| exposes deeper functionality that is not already like a
| lot of the existing packages.
|
| Edit: and one final thought - it's a hard environment to
| build by the nature of the work being done being a
| creative process with no correct answers and which needs
| to support a multitude of different approaches to
| creativity. It's pretty opposed to software being
| generally a machine with a fixed number of functions
| duped wrote:
| > 6 year old to plug a guitar into and start playing.
|
| It's called MainStage, and it's an industry standard tool
| (although recording engineers probably never use it)
| cheeseomlit wrote:
| This is how I feel about ableton every time I try it, the
| workflow and interface is just not intuitive to me and sucks
| the fun out of playing music. I landed on FL studio- it feels a
| lot more natural. If its good enough for soulja boy its good
| enough for me
| gravitronic wrote:
| hey, this is really nice. Have you seen web audio modules?
| https://webaudiomodules.com
|
| It is an audio/video/midi plugin standard for the web and it is
| rather mature.
|
| During covid I worked on a collaborative browser-based DAW,
| https://sequencer.party. I definitely bit off more than I could
| chew, but you can wire up plugin chains at least.
|
| I would strongly suggest you consider adding webaudiomodule
| support and instantly get ~50 plugins supported in the DAW. I
| also packaged up a bunch of them ready for consumption here:
| https://github.com/boourns/wam-community
| gordy_gordstein wrote:
| At first glance, this looks like it's going to be a lot of fun.
| Would be nice if the built-in samples featured some one shots as
| opposed to just loops, though I haven't dove in deep enough to
| see if there are facilities for chopping up longer samples.
| Definitely plan to fool around with this some more after work and
| see what it can do.
| PaulDavisThe1st wrote:
| The thing that people complain about most when it comes to using
| DAWs on Linux is that 90% of the plugins in the world are not
| available (at least, not without some relatively technical magic
| such as yabridge).
|
| It is therefore quite curious to see people get all excited about
| a DAW on another "platform" where at least 90% of the plugins in
| the world are not available, and in all likelihood are even less
| likely to ever become available than they are on Linux.
|
| There's certainly a role for a tool like this in education and
| for people who so far have no realized that they really need to
| have Pigments or fabfilter for their project. And yes, people do
| exaggerate the extent to which a specific plugin is needed.
| Nevertheless, the lack of ability to run essentially any of the
| existing 3rd party plugins would, were it a native DAW, be viewed
| as completely crippling.
|
| The webaudio modules "standard" offers some hope here, and I
| suspect that within 2-5 years, plugin toolkits like JUCE will
| allow you to build not just as "windows/VST3" or "Linux/LV2" or
| "macOS/AudioUnit" formats, but also "wasm/webaudiomodule" (or
| something like it). However, given how easy the various Linux
| options already are with JUCE, and how few plugin developers
| choose to use them, I have to wonder if the massively larger size
| of a "browser platform market" would be enough to get them to add
| another platform.
| wdfx wrote:
| Drivers and control panels for interfaces are also an issue on
| non macOs and windows platforms. I don't see hardware vendors
| changing that any time soon.
| duped wrote:
| I was a longtime JUCE user and won't hold my breath for them to
| support the web. They skate strictly where the puck was two
| years ago, not where it's going. I also wouldn't call their
| Linux support "easy" - it's not surprising to me very few JUCE
| developers even consider using Linux in CI, let alone as a
| supported target.
|
| That said, I think there's something interesting about building
| out an audio platform with "no VSTs" as a constraint - about 6
| years ago I was convinced that the web was a deadend for even
| middling complexity audio projects when I saw Bandlab at NAMM,
| and I was very wrong. It seems like the value of a DAW that you
| can fire up in a browser and instantly access all your
| projects/share them with your friends is more valuable than
| having no plugins and crashing after hitting browser tab memory
| limits. And looking down the road it frees you from the serious
| problems with native plugins and current plugin APIs.
| MDGeist wrote:
| I think you make an interesting point about the implications
| of the no-VST constraint. In the earlier days of Reason
| (before they had VST support or even Rack Extensions) it was
| great because I could work on a song on any system that had
| just Reason installed and anyone that also had the current
| version could open it as is. No installing plugins and no
| plugin compatibility issues between users. Away from the
| studio for a weekend? Just install on a laptop and use the
| dongle, no problem!
|
| Creatively it was very freeing. Naturally, plugin envy
| eventually crept in and I was glad when they did add VST
| support, but I miss the ease of use and portability. And you
| got to know the stock effects inside and out which offered
| some streamlining in workflow.
| peepee1982 wrote:
| I recently used Bandlab when I was at my girlfriend's and the
| only thing I had with me was my company's laptop, which I
| don't install any audio software on.
|
| I wrote and recorded a little song and published it withing
| three hours or so, just as an experiment.
|
| I had to reload the UI a few times after moving too quickly
| and because of a janky internet connection, but other than
| that I thought it was a well designed tool. I think it's
| liberating to be shielded from the many choices you make when
| working in a "real" DAW, and when I don't have REAPER or
| Studio One around, I'll happily work with a tool like this to
| simply stay in the habit of producing music when on the road.
| 70rd wrote:
| Doesn't Ardour support VST?
| PaulDavisThe1st wrote:
| Yes, but that in and of itself does nothing to make specific
| 3rd party plugins available in native format for, say, Linux.
| entropicdrifter wrote:
| Yes. Reaper does too. The thing that makes plugins
| incompatible on Linux is just that they aren't compiled for
| Linux. You can run some plugins through WINE via some tools,
| but it's more bug-prone than natively compiled Linux LV2 or
| VST
| kundi wrote:
| Impressive work. We would love to get this integrated into
| Formaviva (https://formaviva.com)
|
| How could we get in touch with your team?
| turnsout wrote:
| Doesn't work in Safari. It reports "An important feature
| 'extended methods in iterators' is missing."
|
| "Extended methods in iterators" sounds like a developer-
| experience quality of life feature that could be easily avoided.
|
| Still, I'm happy to see that this seems to work in Firefox, so
| it's not Chrome-only.
| shidoshi wrote:
| Got a little beat going with it, but the lack of VSTs and fine-
| grained control will be limiting in the long run. It's a super
| cool in-browser demo though. Overall, I'm very positive on the
| efforts.
| spicy-punk-fog wrote:
| Yay, let's totally try to cram things that don't belong there
| into a memory-hungry beast that eats gigabytes of RAM instead of
| using every available byte of it efficiently, and take away
| precious CPU cycles from running actual DSP and sacrifice them to
| all the web APIs, javascript engines, css and html parsers, svg
| renderers and other stuff one would never need in a sane DAW
___________________________________________________________________
(page generated 2025-02-11 23:01 UTC)