[HN Gopher] Bespoke Synth 1.0 - open-source software modular syn...
___________________________________________________________________
Bespoke Synth 1.0 - open-source software modular synthesizer
Author : paulshen
Score : 707 points
Date : 2021-09-14 19:21 UTC (1 days ago)
(HTM) web link (www.bespokesynth.com)
(TXT) w3m dump (www.bespokesynth.com)
| grae_QED wrote:
| >five fewer dollars in your pocket
|
| >fifteen fewer dollars in your pocket
|
| Definitely gave me a chuckle
| nxpnsv wrote:
| The most compelling pricing box I have seen so far!
| bambax wrote:
| Funny, but incorrect?
|
| Bespoke Plus is $5 and Pro is $15; there should be no check in
| the $5 line for Pro, OR if both lines are checked, the second
| line should be $10 and not $15.
|
| As it is it means Pro is $5+$15=$20.
| bambax wrote:
| Replies and downvotes mark a strong disagreement. So okay, my
| interpretation is not mainstream, but I still think it's a
| possible interpretation.
|
| The difference in interpretation comes from the nature of
| "features": are they actions or verifications? A verification
| is (usually) idempotent / has no consequence on the state of
| the world, but an action isn't.
|
| I read the lines as "takes $x from your pocket".
| y4mi wrote:
| i disagree.
|
| what you propose wouldn't make sense in my opinion, as its
| basically two consecutive boolean declaration
| $5 less = pocket - paid <= pocket - 5 $15 less =
| pocket - paid <= pocket - 15
| mekkkkkk wrote:
| const originalDollars = 30; const myDollars =
| originalDollars - 15; const fiveDollarsLess = myDollars
| <= (originalDollars - 5); const fifteenDollarsLess =
| myDollars <= (originalDollars - 15);
| console.log(fifteenDollarsLess && fiveDollarsLess); //
| true
| boomlinde wrote:
| $15 less in the pocket is _at least_ $5 less in the pocket.
| Lurkars wrote:
| It depends a bit on interpretation: if you pay 15, you of
| course have also 5 fewer in your pocket, so the 5 fewer can
| be included in the 15 fewer, than it's correct.
| sigg3 wrote:
| As a total amateur this is mind-blowing :D
|
| Can't wait to play around with it!
| Jenz wrote:
| Haha this is the most amazing feature matrix I've ever seen.
|
| On a more serious note, modular music is an extremely interesting
| and growing area and just about every module is surprisingly
| expensive; I'm curious to how well this translates to virtual
| racks.
| 41209 wrote:
| Agreed.
|
| That alone makes me want to donate.
|
| Can it work as a VST plugin ?
| yellowapple wrote:
| If there's a plugin version of this I can see it giving
| ZynAddSubFx a run for its money in my workflow.
| 41209 wrote:
| It's GPL so you can always create your own.
|
| I wouldn't mind feature bounties for a project like this.
| armchairhacker wrote:
| I've never heard about modular music, but I know must VSTs are
| extremely expensive. And they're expensive to even seriously
| try.
|
| I want to get into music production but a barrier is that
| Omnisphere and FL Studio are $500 and have a super-limited
| trial version. As a grad student I'm not going to spend $500
| for a piece of software I _might_ be interested in using.
|
| I would much rather have it be like software development where
| almost everything is free. And instead of paying upfront,
| synths / effects can make money by taking a cut of your revenue
| (I don't think that's like software development but it means
| synth producers still make revenue).
| strenholme wrote:
| I used to have a synth buying guide. For people just starting
| out I would go for:
|
| * Get Reaper. It's a mainstream DAW, is fully functional, a
| free download, and only $60 to register after 90 days.
|
| * Valhalla Supermassive for reverb:
| https://valhalladsp.com/shop/reverb/valhalla-supermassive/
|
| * The VST fork of VCVrack for a modular synth:
| https://github.com/bsp2/VeeSeeVSTRack#downloads
|
| I would get a keyboard controller with full sized keys and a
| 5-pin DIN MIDI out for just over $200, but that can come
| later.
|
| One thing to avoid is the rabbit hole of concentrating on
| what gear to buy over actually making music with the gear.
| PaulDavisThe1st wrote:
| Valhalla plugins are restricted to Windows or macOS, unless
| you are willing to use a Windows VST bridge such as
| yabridge.
|
| No reason to get 5 pin DIN MIDI at this point; almost all
| devices offer USB MIDI and its as good as DIN MIDI in
| almost all scenarios.
|
| [ EDIT: VCV Rack ] 2.0 will be out "soonish" which will
| offer an "official" VST (and if we're lucky, LV2 also)
| plugin, though at a price.
|
| People's mileage will vary when it comes to the DAW. As the
| author of another (libre & open source) DAW, I get emails
| that vary from "Oh my god, I've used X and Y and Z and
| yours is so much easier to use and incredibly fast and
| reliable" to "how can you look at yourself in a mirror when
| you make such shit software". Reaper works for a bunch of
| people, but not for another bunch, as is the case for most
| DAWs.
| strenholme wrote:
| _almost all devices offer USB MIDI and its as good as DIN
| MIDI in almost all scenarios_
|
| DAWless setups are definitely a thing, and you need DIN
| MIDI to connect the keyboard directly to a sound module
| (USB can only be connected to a computer).
| PaulDavisThe1st wrote:
| But the setup being described doesn't involve any sound
| modules, and for general ease of use and extensibility, I
| would say that at this point USB MIDI probably wins. If
| you want to go to a sound module of some sort, there are
| some cheap and reliable USB->DIN MIDI cables available
| (along with some cheap and totally unreliable ones).
| strenholme wrote:
| USB - DIN MIDI adapters are expensive, unreliable (they
| may or may not work, depending on how the MIDI over USB
| device exactly converts MIDI in to USB), and another
| moving part to have in a recording studio.
|
| It is a $50-$100 extra investment to get a quality
| keyboard with DIN MIDI, but those quality keyboards come
| with better software and have a better build quality to
| them.
|
| It's a lot better to spend the extra money up front to
| get a keyboard with a DIN MIDI connection (e.g. an
| Arturia Keylab or Novation Launchkey) than to have
| something which will need a hacked together USB-to-DIN
| box (and I notice I haven't seen any names of make and
| models of MIDI USB to DIN boxes which supposedly will
| always work) if they ever want to go DAWless.
| xyzzy123 wrote:
| Retrokits rk006 is amazing for this (usb host mode) ->
| DIN midi all ways bridging.
| jacquesm wrote:
| I have a bunch of older stuff that only has 5 pin MIDI.
| The adapter I use is made by Yamaha, it hasn't let me
| down even once over a year and a half of pretty heavy
| use.
| jasondoty wrote:
| If you're not going to make money off it, my opinion is you
| can use cracked VSTs without any concerns of "is it right".
|
| In fact, as with a lot of pirated soft/media the experience
| is superior. Licensing and DRM of music software is a
| headache - dongles, software centers and other bloat. Scene
| groups like R2R even optimize performance and patch out bugs
| in addition to cracking protections, making their releases
| superior than that of the original developers.
|
| Otherwise have a look at Splice rent-to-own plugin licensing.
| P_I_Staker wrote:
| It doesn't have to be. Logic Pro X was $199 when I got it. GB
| is free, and pretty useful. I haven't used cakewalk, but it's
| free.
|
| I imagine there are oodles of cheap DAW(s) that will at least
| let you sequence and mix everything together. Technically, I
| don't think you need a DAW, if you're just playing (though
| obviously that's a very limited use case). I feel like you
| could even record tracks into Audacity straight from the
| instrument
|
| There are TONS of great sounding free VSTs and some very good
| cheap ones. Some of them can be gotten at a deep discount
| (though you're usually shelling out $50-100+), but the MSRP
| is something outrageous. I don't want to shill, but you can
| "rent-to-own" for zero fee now (don't know how many DAWs are
| available, but plugins for sure.
|
| It doesn't HAVE to be expensive, though there's probably some
| stuff you'll inevitably be tempted to buy, as with any
| hobbies. Is dropping eg. $100-500 on a hobby once or twice a
| year "expensive"? It's also pretty easy to get into and buy
| things as you go. You really don't have to drop thousands of
| dollars on tons of software.
|
| You don't have to pay a dime. Don't quote me on this, but I
| think there's a major free modular simulator that's pretty
| good. You could get some solid vintage synths, some drum
| machine/groovebox, and effects for like $50-80.
|
| If you think about everything going into it that's a ton of
| functionality for your buck, especially compared with
| traditional hardware synths. I have $3-5k in my rig (plus I
| buy VSTs), and it's still relatively basic. I don't own a
| single high end synth, my most expensive would be considered
| midrange at ~$1200... ONE BOX ... you could buy so much
| fucking software for that, it's crazy.
|
| BTW almost none of this is necessary for you to experiment
| and create. You need very little... like 1-5 vsts, some
| utility(s), and minimal plug-in. I encourage OP and anyone
| reading this to create if they have the urge. I'm 100%
| positive you can get into it at any price point. Paying more
| money won't help you as much as you think here. Much better
| to keep it small and master one box at a time.
|
| >I would much rather have it be like software development
| where almost everything is free. And instead of paying
| upfront, synths / effects can make money by taking a cut of
| your revenue (I don't think that's like software development
| but it means synth producers still make revenue).
|
| I have to disagree with you there. First of all, I don't
| agree with this generalization, as it seems very focused on
| your own background. There are lots of people selling
| software (including design tools), sometimes for outrageous
| prices, if it's sought after.
|
| It seems like almost all software is sold. I don't know how
| this business model is supposed to work. This is how small to
| medium sized software companies work. They have to sell to as
| many people as possible TBH, because most of their userbase
| is going to make $0.
|
| I think your frame of reference is out of wack regarding what
| stuff costs, because we're getting screaming bargains on soft
| things (eg. media, newspapers, ect.) This "everything must
| be" free attitude is really toxic and having some troubling
| effects. I think it would also be hard to prove what people
| are using, and enforce this. Even for recordings, but so much
| money is made live.
|
| Wow, what a tirade. Sorry folks, but I wanted to get that out
| there.
| peapicker wrote:
| To echo a little, as a dev who gets paid to write software,
| I'm happy to pay other devs for quality software.
|
| Quality DSP from Xfer Records (Serum), Fabfilter (Many
| amazing data viz plugs and good sounding compressor,
| limiter, gate, multi band eq, saturator, etc), izoTope
| (trash2 distortion) etc etc etc have been worth every cent
| for their clarity and performance.
|
| Carefully shop around for some of these and you will
| realize that money does actually buy real quality
| sometimes. But only sometimes. Most quality products has
| free limited demos that can be very informative.
|
| Sometimes free/libre stuff is also amazing, like Dexed. And
| perhaps also Bespoke - I'll definitely be trying it out,
| and sending $$$ if I think I'll use it.
| fancy_hammer wrote:
| There are sooooo many VST plugins out there. If you don't see
| the value in the cost of Omnisphere don't buy it. Look for
| other options. It's an extremely competitive market.
|
| Ableton Live Suite has a tremendous amount of tools out of
| the box and contains everything you need to make music with.
| Look for second hand copies on forums. You'll likely be able
| to pick a copy up for $400 or so. You could buy that and
| never buy any software again.
|
| > And instead of paying upfront, synths / effects can make
| money by taking a cut of your revenue
|
| Hahahaha, have you asked how much the average electronic
| music producer makes vs the average software dev? ;)
| munificent wrote:
| Take a look at Reaper, VCV Rack, Surge, Tyrell, Zebralette,
| Dexed, and Helm.
| chrislo wrote:
| Vital[1] is fantastic, I've been using it a lot.
|
| https://vital.audio/
| yummypaint wrote:
| Second for vcv rack. Waveform free has been working well as
| a DAW for me recently, and it has a linux version.
| peapicker wrote:
| Of that list, Dexed is the only one appearing in my tracks
| regularly. This is because I'm more likely to use Serum,
| Massive, or Pigments for the other duties. But Dexed,
| especially after downloading many preset libraries, is
| freaking amazing in its DX7 early FM synthesis emulation.
| TheOtherHobbes wrote:
| Omnisphere is the last thing you should buy.
|
| There are countless _free_ VSTs that are very, very good.
| KVRAudio is a good news source for what 's happening in VST
| World, both paid and free.
|
| https://www.kvraudio.com/
|
| There are also numerous plug-in discount stores (Audio Plugin
| Deals, Plugin Boutique, Emmett VST Buzz, and others) that
| regularly sell mainstream VSTs at hugely discounted sale
| prices.
|
| Free DAWs are harder to find, but you can get intro-level
| DAWs with enough features to get started for less than $200.
|
| On a Mac Logic Pro is $199, which is a full-featured DAW with
| a solid collection of virtual instruments.
| tomc1985 wrote:
| Second on watching the plugin stores, particularly Plugin
| Boutique. Some of their sales are nuts, and they even have
| a very well organized free section.
|
| Ableton Live Lite (1 step up from intro) comes free with a
| lot of music gear. I had a bunch of licenses lying around
| because it came with my USB audio box, my MIDI keyboard,
| etc etc.
|
| Also consider FL Studio. Unlike nearly everyone else it
| comes with free lifetime updates. Like Ableton, every
| edition except the cheapest has a ton of plugins to cover
| nearly every need. My license is almost 20 years old, and
| I'm still running the latest version. Easily the best money
| my broke-student ass ever spent.
| scns wrote:
| Then you could mail him one of those licenses no?
| tomc1985 wrote:
| I've already given them away
| quantified wrote:
| Pricing plan you can understand!
| 112233 wrote:
| Is there a modular audio environment like vcv/reaktor/max, where
| I could plug stuff together by typing text, instrad of mousing
| pips? I honestly tried to get into pd, but it felt like typing
| book using the character map.
| adriancooney wrote:
| I actually made something slightly like what you're looking
| for: https://noise.sh
|
| It's certainly not as powerful nor polished as Bespoke but
| might be worth a look.
| iainctduncan wrote:
| I'm the author of Scheme for Max and Scheme for Pd, open source
| (sibling) projects for scripting, live coding, and doing
| algorithmic music and sequencing in Max/MSP, Ableton Live, and
| Pure Data in S7 Scheme. I work in them using an OSC bridge from
| Vim so that I have a REPL in my editor controlling the
| environment entirely with lisp.
|
| Project: https://github.com/iainctduncan/scheme-for-max
|
| Demos: https://www.youtube.com/channel/UC6ftX7yuEi5uUFkRVJbJyWA
| pierrec wrote:
| Yes, most audio programming languages allow you to create DSP
| graphs by connecting nodes together. This is often done with
| some kind of pipe operator (for example, ChucK has the "chuck
| operator", Faust has a bunch of operators for connecting
| batches of nodes in different ways).
|
| My favorite approach is in Sporth: because it's concatenative,
| you don't need any operator, you just type the things you want
| to connect. Shameless plug, I made a playground for it:
| https://audiomasher.org/browse
| georgeoliver wrote:
| thanks so much for the link, that is super cool!
| kleer001 wrote:
| Second vocal vote for that. It'd make it a more powerful tool
| and be less of a pain at the same time.
|
| Or at the very least some kind of remedial hot key navigation
| would be great too.
| premek wrote:
| sonic pi is not exactly like modular but easier than pd
| lgas wrote:
| If you like Haskell you might like Tidal Cycles[1] and if you
| like Clojure you might like Overtone[2].
|
| [1] https://tidalcycles.org/
|
| [2] https://overtone.github.io/
| premek wrote:
| there's also ChucK
|
| https://chuck.cs.princeton.edu/doc/language/
| yata69420 wrote:
| There's quite a few actually. The term is "live coding".
|
| Supercollider sounds like what you're after. You can even use
| vim :)
|
| https://github.com/pjagielski/awesome-live-coding-music here's
| a list of related stuff
| dewert wrote:
| Saw a good talk at PyCon a couple of years ago about FoxDot,
| which is a wrapper around SuperCollider. Bit foggy on the
| details now, but it seemed like a good place to start.
| PaulDavisThe1st wrote:
| Here's a list/overview of all things "live coding":
| https://github.com/toplap/awesome-livecoding
| kennywinker wrote:
| This looks very interesting, checking it out now (download links
| were broken, but I found releases on github). For people new to
| this type of software, definitely also check out VCV Rack for a
| more skeuomorphic take on open source software modular.
| [deleted]
| bravura wrote:
| Is there a headless mode, for synthesizing sounds and performing
| FX, from an API? Or is this like 99.9% of music software that the
| authors assume only a human will be the user?
|
| I've been doing research on music AI, inverse synthesis, and the
| like, and shockingly few open-source software packages were
| usable for creating training sets.
| chrislo wrote:
| There's a scripting interface[1] which might help you do some
| of what you want, but I'm not sure if patches can be run
| headless.
|
| If you haven't seen them already, SuperCollider, Chuck, PD,
| Faust and/or the Web Audio API might be better suited to
| generating training sets in an offline fashion.
|
| [1]
| pier25 wrote:
| > _In a way, Bespoke is like if I smashed Ableton to bits with a
| baseball bat, and asked you to put it back together._
|
| LOL
| Adduh wrote:
| I love the business model!
| rcarmo wrote:
| This seems awesome. I've been playing with Bitwig's Grid and VCV
| Rack, and it looks like something else to explore.
| ruph123 wrote:
| Another instance where "Linux == Ubuntu". At least regarding the
| dependency install script which is just a bunch of "apt-get"s.
| Sad that it has come to this.
| codetrotter wrote:
| Tbh I don't blame them all that much. Even as someone who is
| enthusiastic about Linux and has been a Linux user for many
| years I find it difficult to support other distros than the one
| I actually use. And lately I've been booting my main Linux box
| more and more rarely too, as my MBP M1 with macOS is suitable
| for almost everything of what I do.
|
| So for example when I recently went to describe in a README how
| to install some software that I'm workin on, I relied mostly on
| my memory and secondary sources in order to try and give a
| pointer to users on various distros for how to install the
| dependencies in question. And for example from what I could
| find for openSUSE Leap 15.3, both of the pieces of software
| are/were not in the official package repos at the time so I
| simply stated that, linking to the relevant pages under
| software.opensuse.org that told me this, but not having run
| openSUSE myself for years I am not sure the reason for it or
| indeed if it's even completely correct.
|
| I guess there'd be room for some CI service where instead of a
| specific Docker image like many use you'd instead list the
| dependencies in a kind of meta format and the service would
| install the corresponding packages and run the tests across
| many distros. Then the service could generate scripts or readme
| instructions for each distro.
|
| At the moment I think realistically in most cases it will need
| to be that people who run various distros take it upon
| themselves to sort it out and to submit pull requests to
| projects about how to install and use on any given distro.
|
| My own preferred Linux distro for desktop is Debian-based too.
| KDE Neon.
|
| But so, I think it may be worth it that you try and submit a PR
| to the OP for adding instructions or an install script adapted
| to your own distro of choice.
|
| Although ultimately, if the software grows big enough
| eventually someone will add it to the package repositories of
| each distro and then there will be no need for manually or
| scriptually installing the deps, because the deps will be
| specified in the package repos. And for example if you use Arch
| I guess someone is bound to add it to AUR if it's there
| already.
| [deleted]
| ruph123 wrote:
| AppImage works perfectly fine in nowadays. But I would be
| totally fine if it would simply say "Ubuntu" than "Linux".
| That is really all I'm asking.
| makeworld wrote:
| Hopefully it'll be fixed!
| https://github.com/awwbees/BespokeSynth/issues/108
| whateveracct wrote:
| oh don't worry - someone will Nixify it at some point. Maybe
| even me!
| spindle wrote:
| Then you have an opportunity to be my hero!
| runjake wrote:
| Yeah, it's a bummer.
|
| But at least its a short install list [1] and its probably not
| too difficult to install the deps on your distro of choice and
| fire it up.
|
| 1. Deps: g++ libfreetype6-dev
| libx11-dev libxinerama-dev libxrandr-dev
| libxcursor-dev mesa-common-dev libasound2-dev
| freeglut3-dev libxcomposite-dev libcurl4
| libusb-1.0-0-dev libgtk-3-dev python3-dev
| libcurl4-openssl-dev libwebkit2gtk-4.0-dev libjack-
| dev
| tomxor wrote:
| I'm running Debian 11 and it still doesn't run.
|
| Thought I'd try build it and...
|
| > Use the "Projucer" from https://juce.com/ to generate
| solutions/project files/makefiles for building on your
| platform. [0]
|
| eh?
|
| https://juce.com/get-juce
|
| Is this really a FOSS project?
|
| [0] https://github.com/awwbees/BespokeSynth
| adultSwim wrote:
| Projucer is GPL3, as is this project. I think it just needs
| a little better build instructions...
| [deleted]
| fjfaase wrote:
| I am running Ubuntu 18.04 and after having run the script,
| installing Python3.8 and running ldconfig, it still complains
| that 'libpython3.8.so.1.0' cannot be found.
| lunarpunk wrote:
| Incredibly cool. What is the visualisation in the background
| called?
| ejarzo wrote:
| Really well thought out interface, looks super easy to quickly
| make a bunch of edits -- The SHIFT+Touch to connect modules is
| nice and I love that you can always just export the last 30
| minutes. Looks like a ton of work went into the documentation as
| well -- can't wait to dive in!
| MrScruff wrote:
| So this is of course very cool, but I would say that one of the
| main appeals of a hardware modular is the tactile nature of it.
| It feels very different to experiment with vs plugging virtual
| cables in software.
| fivre wrote:
| Modern MIDI controllers are quite flexible in that regard.
| Stuff like
|
| https://roli.com/products/blocks/seaboard-block-studio-editi...
| https://artiphon.com/pages/instrument1
|
| are designed such that you can easily assign fine-grained
| inputs on the controller to whatever software parameter you
| like. Traditional modular required you build a lot of things
| you'd expect from a physical instrument incrementally, and
| there's some interesting music that comes from that alone, but
| it's a real joy to have something you can use to construct,
| say, lifelike vibrato that responds to multidimensional inputs,
| without a shitton of work.
|
| much more cost-effective too. you can use a single $300
| controller and software to make the same shit that'd require
| several discrete multi-grand dollar setups if fully implemented
| in hardware
| MrScruff wrote:
| Yes, this is where I came from. I spent a great deal of time
| building stuff in Reaktor/Max and software is still useful
| for some things. However dedicated hardware (which granted is
| an expensive hobby) wins on intangibles like happy accidents,
| touch and feel, muscle memory. It feels less like working
| with a computer and more like experimenting in an audio
| laboratory.
|
| I think with instruments it's more about what keeps you in
| the creative flow than anything else. At least for me
| hardware has been 10x more productive than software in terms
| of actually making music.
| ChuckMcM wrote:
| This is awesome! It looks a bit like the love child between Visio
| and GNU Radio Companion re-spun for audio frequencies :-). I
| found the explainer video linked to the github repo[1] as a good
| way to figure out what its doing.
|
| [1] https://github.com/awwbees/BespokeSynth
| peterfield wrote:
| One more tool to play with - cool.
|
| https://non.tuxfamily.org/
|
| http://openavproductions.com/
|
| https://kx.studio/Applications
|
| https://www.renoise.com/
|
| https://www.giadamusic.com/
|
| https://github.com/jackaudio/new-session-manager
| officeplant wrote:
| Renoise is forever the best bang for my buck I've ever gotten
| out of a DAW.
| bodge5000 wrote:
| Renoise has been my "daily driver" for a good number of years
| now, but I'm looking at getting into more modular or
| programming (like live coding, but without the live bit) stuff
| as I want to be doing more generative stuff.
|
| Still, can 100% recommend renoise for what it is, and more, and
| I doubt I'll ever fully stop using it
| yojo wrote:
| Reminded me of SunVox: https://warmplace.ru/soft/sunvox/
| molotovbliss wrote:
| Avid tracker musician here from days past. ReNoise, is one of
| the purchased license holders I'm proud to promote. +ReNoise
|
| Also, add this to your list. :-) *
| https://www.kvraudio.com/product/4klang-by-alcatraz
| molotovbliss wrote:
| http://4klang.untergrund.net/ specific details about 4klang
| for those curious.
| Lucasoato wrote:
| I'm a software developer right now but I've worked with DAWs as a
| producer for more than 5 years. You can't even imagine how
| frustrating is working with Digital Audio Workstation. One messy
| plug-in and you can lose hours and hours of work. Preset
| management is a nightmare, there are so many things that they
| could do to go forward, but the Sequencer market is stall and
| hasn't moved in years.
|
| Imagine if they applied something similar to a git versioning
| system to music projects.... I don't even know if the VST
| interface can be used or if it's licensed somehow from Steinberg.
|
| Also consider that there are no good audio drivers for Linux
| (like Asio for example) so you're almost forced to stay in
| windows or Mac...
|
| No plug-in or DAW has a CLI... I could go on for hours...
|
| I'm doing some digital audio processing for a startup idea and
| the only thing I've came up with is using sox trough a Python
| API.
| Minor49er wrote:
| > No plug-in or DAW has a CLI
|
| You might be interested in MrsWatson. Even though the
| development on it has been discontinued, there is still a lot
| of potential for its use:
|
| http://teragonaudio.com/MrsWatson
| sharklazer wrote:
| Been using DAWs for 20 years now. Of course they aren't
| changing... what even should change? They work, and do what
| they're supposed to.
|
| Most plugins these days are stable, and don't crash. I haven't
| had issues in like 10 years honestly. At least if you're paying
| for them from groups who have a reputation.
|
| Git for a music project would be detrimental, going to be
| really honest.
|
| Linux can run things just fine. JACK has been a relatively
| stable audio platform. RT pre-emption can help. The only issue
| with Linux I see is software support. But with Apple making
| some less than stellar choices, I expect linux to become more
| important to the daw/digital recording ecosystem
|
| One fantastic one that does work well on linux (reaper) also
| has a scripting interface. Not a CLI but actually more useful.
| supernintendo wrote:
| > Also consider that there are no good audio drivers for Linux
| (like Asio for example) so you're almost forced to stay in
| windows or Mac...
|
| ASIO, really? Sorry but you couldn't pay me to go back to that
| broken piece of crap after switching to Linux and JACK2. I'm
| actually traumatized by that piece of software, thinking of
| moments where ASIO would just break and cause my Live session
| to collapse into a glitchy cacophony of latency-induced noise.
| I've seen this happen on several computers with different
| Windows installations and external audio hardware and the
| problem always ends up being ASIO. Some of the producers I knew
| swore off anything that wasn't a Mac because of this exact
| problem.
|
| The problem with audio production on Linux in 2021 isn't the
| audio protocol. It's that most free and open source audio
| production software for Linux is dreadful to use. UX is
| actually very important for DAWs. I want to like Ardour but
| it's a miserable piece of software to try to make music in.
| Feels like a chore to perform any action, kills my vibe, would
| not recommend. After trying really hard to become comfortable
| using it, I finally gave up and bought Bitwig. It's a
| proprietary DAW and kinda expensive but I've been producing
| music with it for a couple of years and it's a dream to use -
| sort of a spiritual successor to Ableton IMO.
|
| > No plug-in or DAW has a CLI...
|
| Most people who make music don't care about this. I'm a
| software developer and musician who only uses Linux and I don't
| care about this. In my opinion, Linux developers of free and
| open source creative software should spend less time building
| these features for other developers and focus more on making
| their software feel good to create with. If I feel bad trying
| to use your clunky-ass UI to make my art / music / whatever
| then I'm not going to hold myself back because it has a free
| software license. I'm going to find a piece of software that
| gets out of the way and lets me make what I want to make.
| PaulDavisThe1st wrote:
| > I want to like Ardour but it's a miserable piece of
| software to try to make music in. Feels like a chore to
| perform any action, kills my vibe, would not recommend. After
| trying really hard to become comfortable using it, I finally
| gave up and bought Bitwig. It's a proprietary DAW and kinda
| expensive but I've been producing music with it for a couple
| of years and it's a dream to use - sort of a spiritual
| successor to Ableton IMO.
|
| As I've mentioned above, I get all kinds of email about
| Ardour, some declaring their love for it, and some much more
| condemnatory than anything you've said here.
|
| The point is that "trying to make music" isn't much of a
| description: people's workflows for "making music" vary
| dramatically. Not many years ago, more or less the only way
| to do this was to record yourself playing one or more
| instruments and/or singing. These days, there are many
| fundamentally different workflows, and countless minor
| variations of each one. If Bitwig works for you, it's no
| surprise that Ardour doesn't. There's a bunch of people for
| whom the opposite is true. You have to be prepared to try
| different tools and figure out which ones work for you.
|
| Finally, ASIO and JACK don't really at the same level. JACK
| on Windows actually uses ASIO. The comparison to ASIO on
| Linux is ALSA, and sure, I'd agree that it's better than ASIO
| is most ways (though maybe not 100%).
| supernintendo wrote:
| > The point is that "trying to make music" isn't much of a
| description: people's workflows for "making music" vary
| dramatically. Not many years ago, more or less the only way
| to do this was to record yourself playing one or more
| instruments and/or singing. These days, there are many
| fundamentally different workflows, and countless minor
| variations of each one.
|
| Excellent point and apologies if that comment came across
| as inflammatory. I really respect the work you and the
| Ardour team have done even if it's not for me (and infinite
| thanks for your work on JACK, it truly is a special piece
| of software). My frustration has more to do with there not
| being a FOSS DAW that gives me that true Ableton-like
| experience. I understand why though, this stuff is hard to
| build and one workflow does not fit all as you point out.
| jefftk wrote:
| _> > No plug-in or DAW has a CLI_
|
| _> I'm a software developer and musician who only uses Linux
| and I don't care about this._
|
| I am a software developer and musician who uses Linux and I
| do care about this. I run headless, and control my audio
| software through custom logic and hardware while playing
| live. I ended up writing a custom synthesizer and see because
| I couldn't find anything that works well for my use case
|
| (I'm still open to something else; my synth doesn't sound
| very good. Designing custom sounds is not something I'm great
| at or something where I really want to focus.)
| nprateem wrote:
| There will always be tinkerers who write their own synths.
| Everyone else just uses serum or whatever and makes music.
| supernintendo wrote:
| > I am a software developer and musician who uses Linux and
| I do care about this. I run headless, and control my audio
| software through custom logic and hardware while playing
| live. I ended up writing a custom synthesizer and see
| because I couldn't find anything that works well for my use
| case
|
| That's pretty cool. Most modern DAWs allow you to define
| per-controller triggers for custom logic in the form of
| MIDI events. I guess you _could_ write a CLI that maps
| custom commands to MIDI events and allows you to send those
| events to your DAW when they are called. It 's not exactly
| what you're describing (and maybe it doesn't fit your use
| case) but is that something you've considered?
| PaulDavisThe1st wrote:
| You can run Ardour headless and control it 100% using OSC
| (from the command line, with oscsend, or from a touch
| device (phone/tablet) using eg. TouchOSC). You could also
| get significant but not as extensive control using MIDI.
| stinos wrote:
| _ASIO, really?_
|
| Havng had zero problems with this (already many years ago, in
| the days where getting low latency on linux was extremely
| hard) on a variety of machines but all with pretty decent
| cards is it possible that the problem has nothing to do with
| ASIO but rather with crappy drivers / manufacturers? Or
| perhaps you just had bad luck?
| sasaf5 wrote:
| JACK2? Sorry my ignorance, it's been a while I abandoned
| Linux audio for Ableton on Windows with a focusrite Scarlet.
| Did they solve that JACK/alsa problem? Without running a2j in
| the background?
| lavabiopsy wrote:
| Which problem are you referring to? a2jmidi should work
| fine as long as you have access to the device. But in any
| case that should not be necessary anymore if you use
| pipewire, which should be able to manage all the devices at
| once.
| sasaf5 wrote:
| The problem was that extra a2jmidi hoop adding a lot of
| friction to my creative process. Also I wanted to keep it
| on indefinitely to use it as an instrument, and a2jmidi
| would crash after a few days.
|
| Also there was the night spent recompiling the right
| version of bison in the middle of Qsampler's dependency
| hell, so that I could have a piano sound. That was all in
| 2017.
| lavabiopsy wrote:
| I'm not sure what you mean extra hoop? You just start
| a2jmidi and then connect the device. Crashes would indeed
| be an issue, generally if you want to mitigate those, you
| would want to:
|
| - Auto restart any important services (with systemd or
| similar)
|
| - Use JACK/Pipewire session management
|
| - Report the crash to the developers (of a2jmidi in this
| case, but it could be anything)
|
| I honestly have never used LinuxSampler so I can't
| comment on that, I believe they have some strange
| licensing thing going on.
| PaulDavisThe1st wrote:
| The extra hoop is having to start a2jmidi and have the
| ports not be as "integrated" into the JACK server ports
| as they could be.
|
| By contrast, JACK1 contains a2jmidid as a builtin client,
| no extra work is needed. You just start JACK, all your
| MIDI devices are listed.
| lavabiopsy wrote:
| I have switched to Pipewire but last time I tried JACK2
| there were tools that would auto-start a2jmidi for all
| available midi ports. This is trivial to do. If hotplug
| was a concern then someone could just write it to run
| based on udev triggers.
| supernintendo wrote:
| I don't run a2j or even have it installed so in my case it
| doesn't seem to be a problem. My audio production setup
| isn't highly complex FWIW but with the following
| configuration I have had no issues with audio or MIDI input
| and output. All of my devices are just plug-and-play for
| both Bitwig and qjackctl:
|
| - Distro: Arch Linux
|
| - Audio backend: JACK2 and PipeWire
|
| - USB Audio Interface: Behringer U-Phoria UMC404HD
|
| - USB controllers: Akai APC 40 mkii, Casio CTK-6200
|
| - Microphone: Zoom H6
|
| I run this exact setup on my Ryzen desktop and a Thinkpad
| T480 with no problems. I've also tried routing the audio
| output of various software directly into my DAW using
| qjackctl, works perfectly fine.
| container wrote:
| I kind of dropped out of Linux audiosome time ago. Can I
| ask why both pipewire and jack? I thought pipewire was
| supposed to implement most (all?) the stuff that jackd
| does.
| tomduncalf wrote:
| > One messy plug-in and you can lose hours and hours of work
|
| If you're meaning from crashes, Bitwig has configurable levels
| of process isolation for plugins - I guess the trade off is
| performance, I haven't tested it out so can't comment on how
| well it works.
| obiefernandez wrote:
| My holy grail project sounds like something you and I could
| collaborate on someday. Essentially a way to represent a DAW
| project in plain text so it can be versioned in Git and easy to
| collaborate on. Happy to discuss anytime
| obiefernandez@gmail.com
| PaulDavisThe1st wrote:
| > Also consider that there are no good audio drivers for Linux
| (like Asio for example) so you're almost forced to stay in
| windows or Mac...
|
| This is false.
|
| > Imagine if they applied something similar to a git versioning
| system to music projects.
|
| People have done this. Using git itself is a little problematic
| because it is very line-oriented and most project file formats
| for DAWs are not.
|
| Regarding plugins, I know that I'm not the only lead developer
| of a DAW who, if they possibly could, would refuse to support
| plugins entirely. The problem is that most users want more
| functionality than a DAW itself could feasibly provide (they
| also sometimes like to use the same functionality (plugin) in
| different DAWs or different workflows).
|
| There are things close to DAW functionality that have a CLI
| (such as ecasound). You can also run plugins from the command
| line by using standalone plugin hosts. You can use oscsend(1)
| to control plugins inside several different plugin hosts.
|
| It sounds to me as if you've worked with a relatively small
| number of DAWs on only Windows and macOS and are not really
| aware of the breadth or depth of the "field".
| dewert wrote:
| > > Also consider that there are no good audio drivers for
| Linux (like Asio for example) so you're almost forced to stay
| in windows or Mac...
|
| > This is false.
|
| This was my immediate thought as well. Not sure what level
| we're talking here, so sorry if I'm addressing the wrong part
| of the stack, but JACK on Linux has been a great experience
| for me in terms of latency and ease of use. I run into way
| more day-to-day problems on Windows.
|
| What feature specifically are you missing on Linux?
|
| Re: plugins, DAWs with VST sandboxing are great. I use
| Bitwig, and I've never lost work due to a plugin crash.
| hammyhavoc wrote:
| PipeWire is love. PipeWire is life. Doing post on a
| documentary whilst using PipeWire. Linux for audio is
| finally there.
| officeplant wrote:
| >Re: plugins, DAWs with VST sandboxing are great. I use
| Bitwig, and I've never lost work due to a plugin crash.
|
| Exactly, the original thread reads as someone who hasn't
| touched a modern DAW from the last 8 years or so. Even
| Renoise has multicore support with sandboxed plugins so one
| of my ancient free shitty vsts doesn't bring down the whole
| system.
| noahadavis wrote:
| And now that we have PipeWire, getting low latency audio is
| extremely easy too.
| lolcat_cowsay wrote:
| JACK is also really easy to setup with PipeWire.
| stevefolta wrote:
| > Using git itself is a little problematic because it is very
| line-oriented and most project file formats for DAWs are not.
|
| Ardour and Reaper use plaintext project formats that work
| well with Git, at least for basic versioning.
|
| > Regarding plugins, I know that I'm not the only lead
| developer of a DAW who, if they possibly could, would refuse
| to support plugins entirely. The problem is that most users
| want more functionality than a DAW itself could feasibly
| provide (they also sometimes like to use the same
| functionality (plugin) in different DAWs or different
| workflows).
|
| I think the answer to this would be something like Reaper's
| "JS" plugins, which are written in a small compiled language
| and distributed as source code. Compared to "JS", it would
| need to: 1) be open source; 2) be a better language; and 3)
| support pretty skeuomorphic graphics ('cause people seem to
| really want that in their plugins). Ardour seems to be
| working on something like this using Lua (don't know about
| the graphics, or if the plugins could be supported in other
| DAWs).
| PaulDavisThe1st wrote:
| Ardour uses XML for its session format, which is not a
| line-oriented format. Git can handle it, most of the time,
| but is not ideal. Something that groks the concept of XML
| nodes would do a better job (i.e. less conflicts duing
| merge resolution).
|
| Ardour comes with a small set of basic "curated" plugins
| written in C or C++, that are "blessed" by us. Writing DSP
| plugins in Lua is also possible, but generally discouraged
| and, as you guessed, you can't provide a dedicated GUI for
| them, nor can they be used elsewhere (same limitation as
| Reaper's Jesusonic plugins).
|
| However, even if those details were improved, the idea that
| a DAW manufacturer is going to be able to supply the
| precise EQ that demanding users want, let alone noise
| reduction, polyphonic pitch correction, and so, so much
| more, strikes me as unrealistc.
| kortex wrote:
| Just use DVC for any non-line-oriented files. If you
| don't want cloud backing stores, it's pretty easy to set
| up using the "local remote" pointing to a custom path
| (e.g. External drive) if you are the only person working
| on it. Otherwise I'd recommend symlinks.
|
| www.dvc.org
| tialaramex wrote:
| Note that git's diffs and merges are customisable. If
| somebody wants to put in the effort for a particular
| format, they can write tools that perform these two
| specific tasks and git can be told "Here are the tools
| for this repo" and deliver the benefits of improved
| tooling. It's definitely possible that could be worth
| doing for a DAW if used with git.
|
| Git even understands that it's possible that you can
| neatly summarise a change in text (for display e.g. as
| part of the change log) but that summary is not
| actionable (so the data stored to _implement_ that change
| is different), e.g. I believe git 's man pages provide an
| example showing how you can get EXIF from a JPEG so that
| your git tools say the change was from "Photo of Pam and
| mummy" to "Cropped image of Pam" when actually it's a
| huge binary data change that is unintelligible to reader.
| Arelius wrote:
| I mean, If git's been around for ages by now, and this
| doesn't exist for even json + xml already and robustly,
| there must be some sort of problem?
| wizzwizz4 wrote:
| The tools don't preserve the literal contents of the
| file; only the JSON / XML semantics. This makes them
| unpopular. (Source: I decided not to use them because of
| this; I needed hashes to remain stable for some reason I
| can't quite recall.)
| jacquesm wrote:
| The problem is quite simple: if it isn't supported by the
| base installation it might as well not exist.
| Github/Gitlab is how most companies and people now
| experience git, and afaik you can't add those custom
| plug-ins to those platforms easily if at all.
| Elv13 wrote:
| > you can't provide a dedicated GUI for them
|
| You could expose enough GTK bits to expose an event loop
| to the LGI lua library. It's gobject-introspection for
| Lua. Since you already use these libs, it would not make
| Ardour any bigger.
|
| I am not saying it's a great idea to mix GUI and a
| realtime DSP in the same thread, but it would be
| supported in you see some demand there.
| PaulDavisThe1st wrote:
| I've previously written a long-ish article about the role
| of Lua/scripting in general in the context of a libre &
| open-source DAW before:
|
| https://discourse.ardour.org/t/is-open-source-a-
| diversion-fr...
|
| There's really no technological reason for not allowing
| Lua to create GUIs within Ardour. It's more a question of
| whether or not we actually want to. Either way, you would
| not be mixing GUI and realtime code - the architecture of
| Ardour doesn't allow that.
| jacquesm wrote:
| I've been reading all of your comments in this thread and
| the links provided carefully, thank you for all the great
| work on Ardour and the degree of forethought that goes
| into it, it _really_ shows in the final product.
| diskzero wrote:
| Nice article Paul. It is motivating me to take another
| look at Ardour. I have also worked on some very large
| audio/video authoring tools. When we made the new
| lighting tools at Dreamworks, you could only create the
| UI using the scripting system. I am not sure if that
| discipline is still observed, but it was a good way to
| make sure that there wasn't a 2nd class citizen status
| given to extending the UI.
| PaulDavisThe1st wrote:
| Thanks. Thing is, in an open source system, there are no
| 2nd class citizens caused by the "eat your own dogfood"
| rules (or lack thereof). You want to change the GUI in
| Ardour? The code is all right there.
|
| The question I was raising (which I think you understand)
| is whether most users care that this is possible if it
| can't be done without a rebuild (compiling).
| diskzero wrote:
| Right. In the case of the studio tools, artists could
| extend the application but not touch the core. Much like
| Ardour, having to build the application from source was
| more complex and who wants to make their users do that?
| wwweston wrote:
| > This is false.
|
| Suffice it to say that it's non-obvious to me where to start
| to go about getting a stable and mobile (ie laptop)
| experience. I'd like nothing better than to receive a
| response that makes me feel sheepish for thinking that Linux
| is the problem, and if anyone can give out good pointers I'd
| imagine you can.
| PaulDavisThe1st wrote:
| Well, first of all let's start with noting that hardware
| can prevent you from ever getting a stable response. Some
| explanatory background on that here:
|
| https://manual.ardour.org/setting-up-your-system/the-
| right-c...
|
| On Linux you do not (as a rule) install device drivers for
| your devices. They come with the system or they (generally)
| don't exist. I know of only one audio interface
| manufacturer who ever maintained their own drivers outside
| of the kernel tree (i.e. not part of mainstream Linux) and
| even they have had their drivers integrated now.
|
| Next, since you're on a laptop, you're relieved of the
| unenviable task of figuring out whether to use a PCI(.) bus
| device or a USB interface. USB is your only option. The
| good news here is that any USB audio interface that works
| with an iPad also works on Linux. Why? Because iPad doesn't
| allow driver installs, and so manufacturers have been
| forced to make sure their devices work with a generic USB
| audio class device driver, just like they need to do on
| Linux. With very few exceptions, you can more or less buy
| any contemporary USB audio interface these days, just plug
| it into your Linux laptop (or desktop or whatever), and it
| will work.
|
| What can be an issue is a lack of ability to configure the
| internals of the device. Some manufacturers e.g. MOTU have
| taken the delightful step of doing this by putting an http
| server on the device, and thus allowing you to configure it
| from any browser on anything at all. Others have used just
| generic USB audio class features, allowing it to be
| controlled from the basic Linux utilities for this sort of
| thing. And still more continue to only provide
| Windows/macOS-native configuration utilities. For some
| devices, dedicated Linux equivalents exist. Best place to
| check on that would be to start at linuxmusicians.com and
| use their forums.
|
| Beyond the hardware, it's hard to give more advice because
| it depends on the experience/workflow you want to use. If
| you're looking for something Ableton Live-like, Bitwig is
| likely your best option. If you want a more traditional
| linear timeline-y DAW ala ProTools, Logic etc., then
| Reaper, Ardour or Mixbus would probably be good choices. If
| you want to do software modular, VCV Rack is head and
| shoulders above anything else (and runs on other platforms
| too).
|
| There's a very large suite of LV2 plugins on Linux. Stay
| away from CALF even though they look pretty. The others
| range from functional to excellent. Your rating will depend
| on your workflow and aesthetics. You will not find libre
| plugins that do what deeply-DSP-oriented proprietary
| plugins do (e.g. Izotope, Melodyne), though you may be
| satisfied with things in the same ballpark (e.g. Noise
| Repellent and AutoTalent).
|
| There's a growing body of VST3 plugins for Linux. If you're
| looking for amazing (non-libre) synths, U-he has all (?)
| their products available in a perpetual beta for Linux.
| Great stuff. There are plenty of libre synths too. There's
| an LV2 version of Vital called Vitalium which is more
| stable than the VST3 version; this synth has had rave
| reviews from many different reviewers.
|
| Sample libraries are a problem because most of them are
| created for Kontakt. You have a choice of running Kontakt
| inside a Windows VST adapter (e.g. yabridge) or using other
| formats such as SFZ or DecentSampler, both of which have
| both free and libre players. pianobook.co.uk has hundreds
| of somewhat interesting sample libraries, many (but
| definitely not even most) of them available in DS format.
|
| Hope this helps.
| wwweston wrote:
| Thanks for the generous and informative response!
| wastholm wrote:
| > Stay away from CALF even though they look pretty.
|
| Why, what's wrong with them?
|
| Thanks for a very informative comment!
| PaulDavisThe1st wrote:
| There are egregious DSP errors, including zipper noise
| and flat-out incorrect EQ-ing, plus they are one of the
| most reliable sources of crashes for Ardour users (at
| least). There are better alternatives even just within
| libre-space for everything that CALF does (they do,
| however, look very nice).
| wastholm wrote:
| Thanks, I'll keep this in mind. (I have given some Calf
| plugins some light usage in Qtractor without noticing any
| obvious problems.)
| tomc1985 wrote:
| > Regarding plugins, I know that I'm not the only lead
| developer of a DAW who, if they possibly could, would refuse
| to support plugins entirely. The problem is that most users
| want more functionality than a DAW itself could feasibly
| provide (they also sometimes like to use the same
| functionality (plugin) in different DAWs or different
| workflows).
|
| Honestly the sound quality of most DAWs' built-in effects and
| synths are garbage. Even the effects section of most VST
| synths is bad! Best to allow plugins rather than trying to
| reinvent the wheel; you'll have to pry my beloved
| serum/iZotope/u-he/softube plugins out of my cold dead hands
|
| Also, the "sometimes" is an understatement. Anyone who's been
| doing this a while likely to be pretty invested in the
| plugins they have. I would say the majority of working
| musicians that use DAWs work this way
| officeplant wrote:
| >Honestly the sound quality of most DAWs' built-in effects
| and synths are garbage.
|
| Have you ever tried Reason? Then again I'm actually using
| Reason as a plugin (via vst3 to vst2 wrapper) so I can
| sequence it easily with renoise. Because why not just load
| a DAW in your DAW.
| lavabiopsy wrote:
| I think you are misinterpreting that comment, I believe the
| idea there would be to have built-in functionality that
| would be equal or surpassing to those plugins, possibly by
| merging the actual plugins with the DAW. Of course doing
| that in a way that will please everyone is a lot harder to
| do than it sounds and is likely not even feasible, but the
| supposed benefit would be that the DAW could better
| integrate that functionality and would not have to deal
| with a lot of the reliability issues that exist with
| plugins. (Disclaimer: I agree with the GP comment in the
| sense that dropping plugins from DAWs would be a great
| thing to do if it were at all possible, but it currently
| really isn't)
| PaulDavisThe1st wrote:
| It wasn't really a misinterpretation.
|
| Merging plugins "with the DAW" is entirely feasible in
| the open source world where I live and work, and we do
| that sort of thing when appropriate.
|
| But the reliability issues do not come from the fact that
| plugins are dynamically loaded shared objects (mostly);
| they come from the vastly different levels of skill _AND_
| very different interpretations of subtle aspects of
| plugins APIs (notably threading, GUI <->DSP communication
| and more). These are hard to get rid of if you've really
| got a diverse, distributed and largely independent "team"
| of developers working on something.
| lavabiopsy wrote:
| I still don't get how that is related, in my opinion,
| that is unlikely to change until there are tools that
| make it easy to resolve all those various
| threading/communication/latency issues on the developer
| side before a plugin is even distributed. So as long as
| you can just distribute any old shared object to get
| around that, I don't expect to see it to improve.
|
| Maybe someone could come up with another way to do it
| that works across DAWs, and then plugins could still
| happen, but I consider this unlikely because with that
| there is never going to be a reliable way for the host to
| verify it that works better than what we have now (user
| reports X plugin works with Y host, etc).
| PaulDavisThe1st wrote:
| It's not hard to stress test plugins. There are a few
| good tools for some formats out there. They can verify
| things that most DAWs will not (e.g. by deliberately
| cross-threading calls and so forth).
|
| The problem is getting people to care. For years, on
| macOS, the "standard" for plugin developers has been
| "does it work in Logic?" There were even plugins that
| would fail auval(1) (the command line AudioUnit
| validator), but somehow pass in Logic. As far as their
| developers were concerned, the plugin worked. Working on
| Ardour, I've seen at least a dozen plugins that used
| ambiguity in the AU spec to justify why "well, it works
| in Logic even if it doesn't follow your interpretation of
| the spec" was the end of their interest.
| lavabiopsy wrote:
| That's what I mean. The solution there would be to get
| Logic to run "auval" before loading the plugin which
| ensures that developers don't do that. But for users of
| Logic doing that serves no benefit as it doesn't actually
| guarantee the plugins run more reliably, so it won't
| happen. And even if it did happen, there would be no
| guarantee that the stress testing tool wasn't also
| written against other ambiguities in the spec.
|
| Edit: I also think testing is hard in general for plugin
| developers to use correctly. I personally would prefer to
| see plugin APIs designed in a better way that make it so
| it's hard to accidentally cause race conditions.
| PaulDavisThe1st wrote:
| Logic does actually use auval these days, so things are
| improving. But this still doesn't catch the cases where
| the issue is something that auval can't or doesn't test
| (e.g stuff related to GUI interaction).
|
| Plugin API design is an art, indeed. There was recently a
| brief bubble of activity on KVR among a number of
| independent plugin devs who found many things to dislike
| about VST3. A long discussion ensued, there was some talk
| of picking up LV2 instead, then it all evaporated and
| nothing was left. The last time the industry tried this
| was in around 2003, and nothing came (directly) of that
| effort either.
| lavabiopsy wrote:
| That's also another aspect where the plugin API vendors
| have not much incentive to fix things, because users can
| just use another thing on top of it (JUCE, DPF, etc) that
| makes better progress towards solving these issues from
| the developer perspective, but still DAWs are left with
| the tractability problem for other plugins that don't use
| that.
|
| To me, if there is any interest in solving that, I would
| just expect someone to put a new plugin backend in
| JUCE/DPF that is specific to the DAW and then compile
| that together with the plugins into a big giant build.
| That's more what I mean by "dropping plugins", it's how
| you avoid the MxN problem too. But I think that many DAWs
| (including Ardour) gain little benefit from doing this at
| this time, so if that was what your original sentiment
| was, I agree.
| tomc1985 wrote:
| The thing is, doing something that would 'be equal or
| surpassing' is pretty much impossible at an acceptable
| cost. You can probably write something that's 'good
| enough' that some people might be happy with -- that is
| what most all-in-one DAWs do -- but the beauty of the
| plugin system is that you can delegate development duties
| for those components to someone who a company who
| specializes in effects, for example. Or even a specific
| effect! There are developers who just write synths, or
| just write reverbs, or whatever. And we want to use their
| products!
| lavabiopsy wrote:
| That's the thing though, not having plugins would not
| mean that you can't delegate development duties for a
| synth or reverb out to another company. I am not sure
| where you are drawing that conclusion from. It just means
| that the development would be happening within the DAW.
| PaulDavisThe1st wrote:
| Why would people who can sell (or at least pitch) their
| plugin(s) to the users of 12-20 excellent DAWs decide to
| go work for just one of those DAWs ?
| lavabiopsy wrote:
| I don't understand why you are saying that either, please
| explain. Nobody needs to work for just one, as any code
| can be linked into any number of DAWs.
| tomc1985 wrote:
| How is that much different from a plugin system? Because
| now you have developers writing bespoke code with a shim
| for each host DAW. At that point you've pretty much
| developed your own modular component protocol...
| literally a step away from a plugin system
| lavabiopsy wrote:
| It's not different, and in fact most DAWs are already
| doing something along these lines internally to actually
| implement an abstraction layer that can load various
| plugin formats and have them all interact. That's
| actually my key point: it wouldn't be significantly
| different for users.
| PaulDavisThe1st wrote:
| But there are (at least) 12-20 DAWs, each with their own
| (internal) abstraction designs. It's bad enough having to
| write (or being able to write) plugins for:
| AAX, VST, AU, LV2 (at least)
|
| Now you'd be talking about 12-20+ different "plugin
| APIs". That's not going to fly.
| lavabiopsy wrote:
| As per your other comment, it seems things are already
| going in that direction, if developers are treating their
| plugins as being written in a format that could be
| described as "AU that is compatible with Logic but
| nothing else" or something like that (substitute for any
| format/DAW combination that the developer wants). So I
| would say that in a way it has already flown regardless
| of how we feel about it.
| tomc1985 wrote:
| A large part of the reason those developers can exist
| independently is because they can target _every_ DAW. So
| either you will have to hire them all or find new
| specialists, or develop that specialization yourself.
|
| Even in the case of developers only targeting one DAW
| (Pro Tools), at least one company (AIR music) saw that it
| was worth the extra effort to release its products in
| other plugin formats like VST.
|
| Honestly, I would not like to see new developers trying
| to oust the plugin standard. It's one of those quirks
| about music software that exists for very good reason.
| lavabiopsy wrote:
| I'm sorry, I don't get where this is coming from, the
| specialists don't need to be hired to write the same code
| again. The old code can just be re-used. If I could
| guess, I think this is stemming from a misunderstanding
| that "no plugins" means "no code re-use" which is an
| understandable misunderstanding (say that 5 times fast)
| but it isn't the case.
|
| In my opinion, plugins only exist because it's convenient
| to package a synthesizer/reverb/whatever for users that
| way, but there is no reason that can't be supplanted with
| something that is more convenient. Of course if it's less
| convenient then that wouldn't be worth doing, if that is
| your concern then I agree with you there.
| tomc1985 wrote:
| Not saying no code reuse. But if you're going to reuse
| code across multiple DAWs, then a plugin system is the
| established standard.
|
| Do you think those existing developers are just going to
| drop their code into your environment and hit compile?
| How do you plan on getting all these musical components
| into your DAW? It doesn't work like that. _Someone_ is
| going to have to write _something_ , or you're going to
| be acquiring the rights to existing code somehow, which
| is still going to have to be ported to your environment.
|
| Or you could skip all that and implement VST. There are
| even libraries that present a standard interface and
| output plugins in all the major formats, so you could
| target that instead. (I forget the name of the framework
| I'm thinking of but it was written by the Cockos guy and
| his DAW's ReaPlugs effects suite targets that library)
|
| How would you motivate a synth/effects developer want to
| spend time on your project? Unless you hire them, and if
| you're going to ask them to "write reusable code,"
| they're going to point to their existing portfolio of
| plugins.
| lavabiopsy wrote:
| It doesn't really matter who does the work, if you were
| writing a new DAW, you'd probably do it. But if you were
| working on an established & popular DAW, plugin
| developers could be convinced to do it if there was
| benefit to them (more optimizations, more features, more
| convenience, less bugs, etc).
|
| I don't think it is currently popular for plugin
| developers to implement against VST themselves, the
| libraries you mention seem to be gaining a lot of
| traction, at least from my experience from trying to
| catalog open-source plugins on github.
| rudenoise wrote:
| Things to check:
|
| For audio on linux: https://pipewire.org/
|
| For a more code oriented audio workflow (python lib to load VST
| and AU) https://github.com/spotify/pedalboard
| pandakar wrote:
| For you pythonheads, please check out Olivier's wonderful pyo
| https://github.com/belangeo/pyo
| PaulDavisThe1st wrote:
| Pipewire is a layer above most of the really important stuff.
|
| Pedalboard is also _not_ a realtime audio environment (as was
| clarified by one of its developers here on the HN thread last
| week). In that sense it is extremely different from Bespoke
| (and nearly everything else).
| Lucasoato wrote:
| I'll never thank you enough for linking pedalboard... That's
| exactly what I've always needed lol
| gregsadetsky wrote:
| It was posted here less than a week ago too!
|
| https://news.ycombinator.com/item?id=28458930
| scns wrote:
| Try Bitwig, plugins will crash on their own there. It even runs
| on Linux.
| xbpx wrote:
| Since you're a software dev you may have explored supercollider
| and other environments where you can employ great tools. I've
| been looking for a hybrid UI/UX + Audio programming environment
| that would combine the freedom of code with the visual cues of
| a DAW but haven't found the ideal fit. So far I've been rolling
| my own with cl-collider, a common lisp client for Supercollider
| which uses some lisp tricks (macros) to good effect.
| grishka wrote:
| > One messy plug-in and you can lose hours and hours of work.
|
| What if you run each plugin in a separate process, or does IPC
| add too much overhead or not provide enough bandwidth for this
| to be feasible?
| PaulDavisThe1st wrote:
| Although we are still debating with some smart people about
| this (since actual measurements call it into question), this
| was our (Ardour dev team's) take on this question:
|
| https://ardour.org/plugins-in-process.html
| grishka wrote:
| The answer is "too much overhead" but the overhead isn't
| coming from where I assumed it would. I thought it could be
| too expensive to pass the required amount of data through
| the kernel (at least 48000 samples per track per second),
| but that's not the problem, it turns out it's the context
| switches. Huh.
|
| edit: I now also remembered that virtual memory is a thing
| and you can share a chunk of physical memory between
| processes to avoid the need to copy anything at all.
| jacquesm wrote:
| Context switches on Linux are a pretty heavy affair, this
| is the result of some choices in the distant past when
| the number of context switches per second was much higher
| than on most other platforms and so it was deemed to be
| 'good enough'. Unfortunately this rules out a lot of real
| time or near real time work, especially when the workload
| is divided over multiple user space processes.
| PaulDavisThe1st wrote:
| A citation is required for this claim.
|
| I know of no evidence that Linux context switching on
| x86/x86_64 is slower than any other OS, and some
| suggestions that it is faster (Linux does not
| save/restore FP state, which Windows (at least at one
| point) does).
|
| Linux is as capable or more capable of realtime work than
| any other general purpose OS, and the latency numbers
| from actual measurement are excellent (when using
| RT_PREEMPT etc).
|
| What are you referring to?
| jacquesm wrote:
| Back in the day when the Linux kernel was first written
| there was a huge argument between Linus and Andrew
| Tanenbaum about whether or not the micro or macro kernel
| road was the superior one.
|
| Tanenbaum argued that a microkernel was lighter, and
| could switch context faster than a macrokernel (the likes
| of which UNIX was typically reincarnated with). Linus
| argued that throughput, not latency is what matters to
| end users. At that time your typical OS switched tasks
| 18.5 times per second and Linux did substantially better
| than that. Case closed, the throughput argument won.
|
| But now, many years later the consequences of that mean
| that we are switching contexts orders of magnitude slower
| than we could have because the context contains a lot
| more information than it strictly speaking has to. My own
| QnX clone switched 10K / second on a 486/33, and yes, the
| IPC mechanism meant that throughput suffered but for real
| time applications with a lot of the hard stuff in
| userspace context switches are far more important than
| throughput (and incidentally, also for perceived
| responsiveness of the OS and apps).
|
| The latency numbers are excellent from the perspective of
| very forgiving applications, a typical DAW runs with 1K
| or even larger sample buffers which is acceptable, but
| for many real time applications that is an eternity and
| so those are not typically built using Linux as the core
| but some dedicated RTOS.
|
| edit: I had 100K / second before, this was in error. It's
| been 30 years ;)
| PaulDavisThe1st wrote:
| If you read the article linked to in the article I linked
| to above (which is fairly out of date, from 2010):
|
| https://blog.tsunanet.net/2010/11/how-long-does-it-take-
| to-m...
|
| you will find that _on Linux_ a context switch takes
| about 30 usec. More recent measurements that take account
| of the effect of the TLB flush put the range at
| 10-300usec.
|
| That means that in 2010, _on Linux_ , you could
| reasonably expect to do at least 30k/sec. In 2021, with
| realistic audio processing workloads, the range is
| probably 3-50k/sec.
|
| The 486 is a much lower register count than contemporary
| processors, which accounts for the faster context
| switching.
|
| Modern audio processing software _on Linux_ can run with
| 64 sample buffers, not 1k.
|
| This recent paper on RT linux on RPi/Beagleboard single
| board systems concludes that on some of these relatively
| "low power" systems, 95% of latencies are in the
| 40-60usec range, which is completely adequate for the
| majority of RTOS tasks (but not all).
|
| https://www.mdpi.com/2073-431X/10/5/64/pdf
|
| >"The majority of Linux kernels' measurements with
| PREEMPT_RT-patched kernel show the minimum response
| latency to be below 50 ms, both in user and kernel space.
| The maximum worst-case response latency (wcrl) reached
| 147 ms for RPi3 and 160 ms for BBB in user space, and 67
| ms and 76 ms, respectively, in kernel space (average
| values). Most of the latencies are quite below this
| maximum (90% and 95%, respectively, for user space and
| kernel space). In general, it seems that maximal
| latencies do not often cross these values."
|
| [ ... ]
|
| "As an outcome, Linux kernels patched with PREEMPT_RT on
| such devices have the ability to run in a deterministic
| way as long as a latency value of about 160 ms, as an
| upper bound, is an acceptable safety margin. Such results
| reconfirm the reliability of such COTS devices running
| Linux with real-time support and extend their life cycle
| for the running applications."
|
| This slide presentation offers up very similar numbers
| with graphs, also on ARM systems (I think):
|
| https://elinux.org/image/d/de/Real_Time_Linux_Scheduling_
| Per...
|
| This article shows cyclictest, a very minimal scheduling
| latency tester, getting the following results on an
| x86_64 system:
|
| "The average average latency (Avg) is 4.875 us and the
| average maximum latency (Max) is 20.750 us, with the Max
| latency on 23 us. So, the average latency raises by 1.875
| us, while the average maximum raises by 1.875 us, with
| the maximum latency raised by 2 us."
|
| https://bristot.me/demystifying-the-real-time-linux-
| latency/
|
| They conclude
|
| > "Maximum observed latency values generally range from a
| few microseconds on single-CPU systems to 250
| microseconds on non-uniform memory access systems, which
| are acceptable values for a vast range of applications
| with sub-millisecond timing precision requirements. This
| way, PREEMPT_RT Linux closely fulfills theoretical fully-
| preemptive system assumptions that consider atomic
| scheduling operations with negligible overheads."
|
| I'm not sure where you're getting your current info from,
| but I'm extremely confident that it's wrong. If I had to
| guess, you have not kept up with the impact of the
| PREEMPT_RT patchset on the kernel, nor scheduling
| improvements in general, but I don't know (obviously).
| jacquesm wrote:
| The last time that I've been actively involved with the
| development of real time control of time critical
| hardware on linux was about 2007 (very high speed stepper
| motor driven plasmacutter, slow down in a curve and
| you've ruined the workpiece), so for sure I'm out of the
| loop but I do have a fairly large Linux audio setup with
| all of the real time patches installed and clearly if it
| is possible to run with 64 sample buffers I have not been
| able to do so on my hardware, 1K really is the minimum
| before I get - inevitably, unfortunately - dropouts under
| relatively light load.
|
| It might be worth documenting my setup (reproduced across
| three different machines, a laptop, an 'all-in-one' and a
| very beefy desktop), to see what could be improved
| because that difference is substantial.
| jcelerier wrote:
| > but I do have a fairly large Linux audio setup with all
| of the real time patches installed and clearly if it is
| possible to run with 64 sample buffers I have not been
| able to do so on my hardware, 1K really is the minimum
| before I get - inevitably, unfortunately - dropouts under
| relatively light load.
|
| that sounds very weird, I don't even run a RT kernel and
| I have no trouble running at 64 with a fair amount of
| plug-ins and even 32 samples when I just want some live
| guitar effects (i7 6900k, RME multiface 2). My _only_
| configuration is installing this AUR package:
| https://archlinux.org/packages/community/any/realtime-
| privil...
| PaulDavisThe1st wrote:
| I've linked to it elsewhere in these comments, but this
| tries to describe in broad terms why any given x86*
| computer may not be able to meet your latency goals:
|
| https://manual.ardour.org/setting-up-your-system/the-
| right-c...
|
| There's a wide variety of reasons, all of which can
| interact. It's one of the few good arguments for buying
| Apple hardware, where this is not an issue.
|
| Over the years I've been working on pro-audio/music
| creation on Linux (22+ years), I've had a couple of
| systems that could perform reliably at 64 samples/buffer.
| My current, based on a Ryzen Threadripper 2950X, can get
| down to 256 but not 128 or 64.
| jacquesm wrote:
| Ok, so at a guess then that 64 is an optimum configured
| set of hardware bought specifically with the goal of
| reaching that minimum, and for more realistic 'run of the
| mill' hardware it would be 256 and up?
|
| If someone were to put together a guaranteed low latency
| config and keep it patched using a custom distro
| (assuming say 'Ubuntu Studio' would not be up to the
| task, would there be a market for that? Are there such
| suppliers? What specifically is different in Apple
| hardware that it works there?
|
| I read that page earlier, its helpful, but more helpful
| would be a shopping list that says 'get this: it will
| work, assuming you install this particular distro'. And
| after independent verification you could then add
| alternatives for each slot. For me for instance a big
| question would if NVidia video cards would break the
| latency guarantees (their driver is pretty opaque) by
| keeping interrupts masked for too long in their drivers.
| If that would be a deal breaker then I'd have to set up a
| system only for studio use.
| PaulDavisThe1st wrote:
| The problem with "shopping lists" is that, at least in
| the past, it's turned out that companies like e.g. mobo
| manufacturers change the chipsets in the corners of these
| devices without even changing the product ID. If I told
| you a mobo to buy, there's no guarantee that you'll
| actually get what I was recommending.
|
| Lots of efforts have been made over the years to create
| "audio PC" companies. Even with the Windows market within
| their intent, I don't know of a single one that has
| lasted more than a year or two. How much of that is a
| market problem and how much of it is a problem of
| actually sourcing reliable components, I don't know. I do
| know that when large scale mixing console companies find
| mobos that work for them, they buy dozens of them, just
| to ensure they don't get switched out by the
| manufacturer.
|
| Apple stuff works because Apple sort of has to care about
| this workflow functioning correctly. There's no magic
| beyond careful selection of components and then
| rigorously sourcing them for the duration of a given
| Apple product's lifetime.
|
| I have no actual evidence on the video adapter front, but
| my limited experience would keep me aware from NVidia if
| I was trying to build a low latency audio workstation.
| Back in the olden days (say, 2002), there were companies
| like Matrox who deliberately made video adapters that
| were "2D only, targetting audio professionals". These
| cards were properly engineered to get the hell off the
| bus ASAP, and didn't have of the 3D capabilities that
| audio professionals (while wearing that hat) really don't
| tend to need.
| [deleted]
| rhizome wrote:
| Sox was a significant player in a pipeline I wrote for a
| YouTube-y company 15 years ago. Worked well enough to (help)
| get the company acquired!
| Amir6 wrote:
| I love the pricing scheme! I would certainly be paying for the
| top tier if I were a user.
|
| Good luck
| Aeolun wrote:
| This is very similar to a modular synth that I used in
| university.
| WillEngler wrote:
| Can anyone in the know compare and contrast bespoke's feature set
| with Max for Live? (https://www.ableton.com/en/live/max-for-
| live/) It also has a circuit diagram-ish UI and supports
| scripting with Node. Put another way, does Ableton already offer
| Ableton smashed to bits with a baseball bat?
|
| (fwiw, you have to pay for the $1k suite version of Ableton to
| get Max, so Bespoke could still be a great alternative even if
| they do a lot of the same things)
| andrewmg wrote:
| Standalone Max is available for $10 / month.[0] And the similar
| Pure Data is open source.[1]
|
| [0] https://cycling74.com/shop
|
| [1] https://puredata.info
| zwegner wrote:
| I only found out about Bespoke a few minutes ago, but I will
| say using Max as a programmer can be incredibly frustrating.
| I've made a handful of nontrivial M4L devices and have run up
| into tons of weird decisions, limitations, bugs, and plenty of
| Ableton crashes. (Caveat: this information in this post is
| mostly from a couple years ago and might be out of date, I
| haven't gotten the latest Ableton)
|
| The JS support is really weird. It's only JS 1.6 (from 2005),
| and had weird glitches (like loading two instances of the same
| device causing the first device to stop working), and I
| couldn't get the timing tighter than about 30ms. Ideally you
| could write code that runs at audio rate.
|
| There's also "gen", which is a Max-specific scripting language
| that is presumably real-time suitable through a JIT.
| Unfortunately you need a separate Max license to use it, even
| the full Ableton Live Suite doesn't give you gen support. You
| can sorta hack around and use it by manually editing the
| .maxpat files (which are almost JSON), copying from a device
| that uses gen, but there are lots of weird glitches going this
| route.
|
| A list of a few annoying things about M4L:
|
| * Documentation is pretty sparse and/or low quality, and
| weirdly split into two (help and references).
|
| * All variables are global _across devices_ by default, local
| (device-specific) variables need the prefix "---", which is
| barely documented
|
| * Tons of annoying UX issues, like entering an invalid value in
| the inspector just reverts to the old value. You can't enter an
| empty string for parameter values, that reverts too (you need
| to enter a literal ""). Certain functionality is only available
| depending on whether the device is "locked", so you have to
| lock/unlock the view all the time if you're working with e.g.
| subpatchers
|
| * Abstraction is quite annoying to do. There's three different
| types of patches, and it's not really clear what the difference
| is between them. Creating subpatches and then duplicating them
| creates _two different_ subpatches--changes in one are not
| shared with others.
|
| * ...and a ton of other things. I have a big text document of
| these gripes I was intending to turn into a blog post, but
| haven't gotten around to it.
|
| Maybe I'm wrong and there's better ways to do some of these
| things, but overall my experience learning M4L was pretty bad.
| If it wasn't the only way to do certain advanced things in
| Ableton, I'd never touch it again.
| iainctduncan wrote:
| I'm also a programmer, and it sounds to me like you're
| expecting Max to be something it isn't. It's not meant to be
| a regular programming environment, it was created to be
| accessible to non-programmers. But you can extend it with C,
| C++, Java, Csound, Chuck, SuperCollider, etc.
|
| I will agree however that the JS implementation is neutered,
| probably because they have to worry about support volumes.
| This is one of the reasons I created Scheme For Max, which
| unlike the JS object, allows running in the high priority
| thread, does hot code reloading, and is open source and can
| be recompiled to your liking. Now that I have Scheme for Max,
| I love Max (and Max4Live) to bits, they are a fantastic
| environment, and I do all the coding in S7 Scheme or C. :-)
|
| https://github.com/iainctduncan/scheme-for-max
| zwegner wrote:
| I really don't think being accessible to non-programmers is
| the cause of my issues. If anything, I'd say that targeting
| non-programmers might exacerbate these issues, because
| those users would be less likely to realize how unintuitive
| some aspects of Max are, thinking it's because programming
| in general is difficult.
|
| I didn't touch too much on the specifics in my post, but
| there are lots of little design oddities I ran into when
| doing relatively simple tasks. Like creating a multiplexer
| for messages: the [switch] object has an "empty" channel
| for input 0 (and regular inputs are 1-indexed), so you'll
| often need an extra +1 object for the control input. And
| the inputs of [switch] have no memory, so every time the
| control changes, you need to send a bang to resend the
| message in the now-active channel. Or say you want to
| multiplex signals. That uses the [selector~] object (why
| not [switch~]?), and has the same +1 issue as [switch]. But
| what if you want a short crossfade when switching inputs to
| avoid harsh transients? "Good luck" is all I'll say here.
|
| I'm not generally trying to do anything super-complicated
| with Max. I have indeed used the C extension API when it
| makes sense (building a wavetable synth), and it was OK. I
| still contend that the main visual programming environment
| is not very good, for programmers and non-programmers
| alike.
|
| ...anyways, all that said, Scheme For Max looks really cool
| :)
| tomduncalf wrote:
| Yeah Max's JS support is pretty weird.
|
| I spent some time figuring out nicer ways to work with it in
| order to build an Octatrack-style parameter crossfader for
| M4L, it provides some abstractions and setup to make using
| Typescript with Max a bit more pleasant. Still plenty of
| limitations but I was able to get my device working pretty
| well in the end. Apologies for lack of docs!
|
| https://github.com/tomduncalf/livefader
| WillEngler wrote:
| Yeesh, thanks for sharing all this. I would eagerly read that
| blog post!
|
| I've gotten really into Ableton this past year and I've been
| curious whether I should get into Max for Live. Being a
| programmer and looking at their marketing materials, it
| seemed like it should tap into the right parts of my brain.
| But seeing your comment now ... maybe not the right move.
| Especially because I'm not looking to accomplish anything
| special, I just want a sandbox to play with digital audio
| concepts.
| zwegner wrote:
| No problem! Maybe I'm just being too negative, after all
| there are lots of people having fun creating stuff with it
| (and I like having the devices I've made). But there was
| definitely a big impedance mismatch of what I had in my
| head vs. how to implement it, so I wouldn't personally use
| it for any exploratory sandbox-y type stuff.
| iainctduncan wrote:
| I would recommend the Cipriani and Giri books and plain old
| Max (or Pd). They have written the best introductions to
| playing with digital audio, full stop. Best computer music
| books made, IMHO.
| bodge5000 wrote:
| modular + live coding in a single environment sounds fantastic!
| To be honest even just another modular based DAW excites me at
| the moment, VCV is fantastic but like with traditional DAWs
| theres many different ways to break an egg
| _eLRIC wrote:
| Discovered a few days ago another nice music studio of the same
| kind that I really liked : Sunvox
| https://warmplace.ru/soft/sunvox/
|
| I'll have to try Bespoke as well ...
| tlhunter wrote:
| Bespoke has some definite SunVox UI vibes going on.
| jay-anderson wrote:
| Sunvox was my first thought as well. Watching the intro video
| it seems in bespoke the modules' internals are more visible.
| Though it's missing the sequencer portion compared with sunvox.
| ericfrederich wrote:
| Never seen this warning from Windows before. Happened when I
| tried to download this .msi
|
| Windows protected your PC Microsoft Defender SmartScreen
| prevented an unrecognized app from starting. Running this app
| might put your PC at risk.
|
| App: Bespoke-Windows.msi Publisher: Unknown publisher
| mastazi wrote:
| It's quite a common sight if you often download installers from
| smaller publishers. On MacOs you get similar warnings (even
| though Mac "notarization"[1] works differently compared to
| Windows certification[2]) Obviously it's up to you if you want
| to consider the application trusted or not. My rule of thumb
| for open source projects is that I trust them if they have lots
| of "stars", and Bespoke has 1.2k
| https://github.com/awwbees/BespokeSynth/
|
| (but I'm not suggesting you follow the same rule, I'm not
| responsible for anything that happens etc. etc.)
|
| [1] https://developer.apple.com/developer-id/
|
| [2] https://docs.microsoft.com/en-
| us/windows/win32/win_cert/wind...
|
| (edit: added links to Mac notarizing / Windows certification
| guides)
| serverholic wrote:
| One thing I'd love to see in a DAW someday is houdini-like
| functionality. It'd be cool if there was this node-based
| environment that went a step further than just generating sound
| and could generate midi clips, automation clips, etc. and have it
| integrated into the DAW. Like you could see what was generated in
| the arrangement view.
| jcelerier wrote:
| The sequencer I'm working on, https://ossia.io, has a plug-in
| API which allows that. But no interesting "meta-creation" plug-
| ins so far for it ^^' at some point I'd like to provide
| primitive composition-like tools like some of the OpenMusic
| objects for instance, and there has been work towards e.g.
| segmenting a sound file with audio improvisation algorithms by
| an intern.
| gavinray wrote:
| You can do this with scripts or native extensions in REAPER
| https://www.reaper.fm/sdk/reascript/reascript.php
| https://www.reaper.fm/sdk/plugin/plugin.php
| mejutoco wrote:
| Sounds a lot like Bitwig's grid.
|
| https://www.bitwig.com/learnings/getting-around-in-the-grid-...
| tomcam wrote:
| Bought it based on the feature matrix, which is worth $15 for
| honesty\comedic value alone. Probably no time actually to use it
| onionisafruit wrote:
| > Probably no time actually to use it
|
| That describes every music related purchase I've made in the
| past 20 years. I'm glad I've done a small part to support some
| creative people, but aside from that I've got a bunch of pedals
| I've used once.
| raffraffraff wrote:
| Haha. I love that. Fuck it I'm gonna buy it too!
|
| I played piano for 9 years as a child, and then stopped when I
| went to college (because no piano). But I taught myself to play
| guitar in (boredom + found guitar and music know-how). But I'm
| in my mid 40s now and have done very little musically in 20
| years. I really really really want to play more music, but I'll
| probably end up saying that on my deathbed (in past tense).
| Maybe downloading this thing and plugging a guitar or piano up
| to a computer will change that.
| sydthrowaway wrote:
| How do GUI DAW's compare against pure code approaches?
|
| Are there any artists today working with pure code?
| chefandy wrote:
| Surely there are _some_ -- every artist has a different
| process. But I doubt there are many.
|
| I'm less of an audio artist than a visual artist (which I do
| professionally to some extent) but I imagine the reasons are
| similar to why few people make visual art using scripts and
| imagemagick or some similar workflow.
|
| Most creative output is birthed in a more freeform state of
| play, to some extent, rather than being reasoned about and
| assembled like code. Coding itself can be playful, but when
| your goal is expressing emotions and ideas in art, having to
| pipe that through a rigid, logical process is much less
| expressive than grabbing something, even a virtual something,
| and making some sort of gesture with it. So unless you're
| trying to express something algorithmic, code is a layer of
| abstraction that operates in a very different way with
| persnickety bounds that just aren't useful in most creative
| expression.
|
| I've done generative design using action script in Photoshop
| and made some really cool algorithmic photo collages, but even
| as a long-time developer, the frequency with which I think
| "this could look cool if I set up a function to do it like
| this" is pretty rare.
| megameter wrote:
| I think all the arts eventually gain a calculated precision
| to them, just at different stages of the process. With music,
| structure arrives at the very beginning: rhythm and harmonic
| structure have some concrete rules to make them cohere.
| Likewise, visual arts usually require taking measurement from
| a reference to build up proportionate construction; if it's a
| cartoon this tends to be redefined into a composite of simple
| mathematical ratios of primitives, while a more realistic
| look develops from something more measured and scientific in
| nature(using a proportionate divider really is lab work).
|
| Once you get past the preliminaries, play can begin...except,
| you can usually return to structure by adding another layer
| of it. Harmonization principles in music have layers of
| structure to them, and "expressive" pop harmony can often be
| seen as a very calculated thing of crafting maximal tension
| and release in a short period. Likewise, you can definitely
| go in the direction of technical visuals, either with
| detailed illustration or computer renderings. Often there's a
| desire to digitally emulate analog workflows without
| literally using those workflows, which results in some
| additional technical considerations around achieving that.
|
| I think this is how all content creation software eventually
| grows into a spaceship panel UI - even if you have a specific
| thing in mind for each process layer and can reduce it to a
| preset or template, you have to configure the software to get
| there.
| sydthrowaway wrote:
| Interesting perspective. I also think of OpenSCAD vs a tool
| like Solidworke. The latter is far more popular
| chefandy wrote:
| Even then I'd say the difference is less extreme. When I'm
| designing physical objects, my free-wheeling creative
| energies will largely be expended during the sketching
| phase, and when I'm in the CAD phase, that's more like
| coding-- it's more about getting things to line up, be the
| proper dimension, etc. In music or visual art, what you're
| creating is the expressive end product, not a precisely
| crafted representation of the end product.
|
| Then again, I'm not architect or mechanical engineer so
| maybe that's different for different folks.
| qwertox wrote:
| 17 MB installer...
|
| I've just installed it and wanted to try this Python live-coding
| but it crashes when loading the example file.
|
| This looks all so promising, it could well be what I've been
| waiting for for years.
| gtvwill wrote:
| Linked it to a mate...he had a wee geez :)
| https://www.youtube.com/watch?v=GFcGtq_dM8k
| [deleted]
| jmaclabs wrote:
| I'm sorry I'm late to this 10 year project - but I'm glad I'm
| here now. Congrats on the 1.0.0 release!
| squarefoot wrote:
| Very interesting. A possible improvement could be some "knob
| linkable objects" (can't imagine the correct name) that could be
| tied to analog inputs (GPIOs, ADC connected to i2c or USB, etc).
| The purpose would be to be able to modify certain parameters live
| on the fly, should anyone want to create a physical synth out of
| this software and a *PI like small SBC.
|
| Also, I like a lot the way it links inputs and outputs just by
| dragging the mouse. Does anyone know if there is any general
| purpose library to do that? I mean, Ideally I create some list
| nodes, then use that library to link them in a certain order by
| using the mouse.
| capableweb wrote:
| > Very interesting. A possible improvement could be some "knob
| linkable objects" (can't imagine the correct name) that could
| be tied to analog inputs (GPIOs, ADC connected to i2c or USB,
| etc). The purpose would be to be able to modify certain
| parameters live on the fly, should anyone want to create a
| physical synth out of this software and a *PI like small SBC.
|
| This is usually called "MIDI mapping" or similar and is
| available in basically every DAW these days.
|
| > Also, I like a lot the way it links inputs and outputs just
| by dragging the mouse. Does anyone know if there is any general
| purpose library to do that? I mean, Ideally I create some list
| nodes, then use that library to link them in a certain order by
| using the mouse.
|
| Something like qjackctl (with Jack, obviously) could do this
| for you, as you can route things however you want in a drag-
| and-drop UI.
| squarefoot wrote:
| > This is usually called "MIDI mapping" or similar and is
| available in basically every DAW these days.
|
| I'm aware of MIDI mapping, my question was about the
| possibility to make a stand alone sysnthesizer (with keyboard
| and knobs) in which the necessary controls would be read from
| analog inputs while still displaying them on the screen as if
| they were changed with the mouse, which is not easy to do
| when playing live.
|
| > Something like qjackctl (with Jack, obviously) could do
| this for you, as you can route things however you want in a
| drag-and-drop UI.
|
| Sorry, my second sentence wasn't clear at all. I'd love to
| see a general purpose (not related to sound or any other use)
| library to allow the graphical representation of structures
| links (list nodes) together as this software and others do
| with generators, effects, etc. Ideally, it should operate on
| the header of a structure which contains the relevant fields
| for linking to others. When I alter the links on the screen,
| it does the same on the represented nodes. That would be the
| way I would build for example a drum machine in which each
| structure contains also a pattern and I can move them at will
| back and forth, replicate them, set their own fields (number
| of repeats, etc). This would be again a sound related
| application, but what I'm looking for is something really
| general purpose.
| capableweb wrote:
| > I'm aware of MIDI mapping, my question was about the
| possibility to make a stand alone sysnthesizer (with
| keyboard and knobs) in which the necessary controls would
| be read from analog inputs while still displaying them on
| the screen as if they were changed with the mouse, which is
| not easy to do when playing live.
|
| I see, I understood the opposite way! But yeah, what you
| are describing also exists! Many (high-end) mixers have
| motorized faders, also using MIDI if I remember correctly,
| so you can change the fader in your DAW and it's
| represented in meat space.
| PaulDavisThe1st wrote:
| To be fair, most control surfaces and mixers these days
| tend to have rotary encoders, so the only thing involved
| in "representing in meat space" is changing the LED
| indicator around/near the encoder. Motors are only
| required for actual faders that have real linear
| movement.
| mastazi wrote:
| While I have used modern DAWs in recent years, the music making
| tool I've used the most was Jeskola Buzz[1], it's a weird mix of
| music tracker[1] and modular setup[2] (but not modular in the
| same way a modular synth works, you connect "machines" such as
| sequencer->generator->effect->[more effects]->mixer).
|
| This was when I was a "poor" student and I couldn't spend money
| on music.
|
| Later I could afford real modular/semi-modular synths and I enjoy
| them a lot but I still appreciate being able to connect cables on
| a screen where you can save the state and rapidly recall it,
| rather than having to free up a table, setup all the modular
| synths, connect them together etc. - So I think I'm going to
| enjoy Bespoke Synth a lot.
|
| Another alternative that I have enjoyed is VCV Rack[3] and its
| little brother for iPad/iPhone miRack[4].
|
| PS I loved the "Feature Matrix" on the Bespoke home page ahah :-D
|
| [1] https://en.wikipedia.org/wiki/Jeskola_Buzz
|
| [2] https://en.wikipedia.org/wiki/Music_tracker
|
| [3] https://vcvrack.com/
|
| [4] https://apps.apple.com/us/app/mirack/id1468259834
| nikki93 wrote:
| There's also NerdSEQ: https://xor-electronics.com/nerdseq/ +
| actual Eurorack modules! :D I like the Ableton clip style main
| view in NerdSEQ which allows you to live mix and match
| patterns, haven't come across as good a flow for that in
| regular software sequencers, especially ones that let you do
| chains of patterns of different lengths and polyrhythm them,
| while having some of them be automation parameters for some
| part of the DSP and others notes for other parts of the same
| chain (Buzz, Buze, SunVox kind of let you do that).
| mastazi wrote:
| Yes! Thank you for reminding me how it's called! I remember
| seeing it some time ago and it's absolutely in my wish list!
| oidar wrote:
| Buzz was my first "DAW" too. I immediately thought this kinda
| looked like what the buzz patching area might look like had
| development continued to now. I'm on mac now, but the thing
| that reminds me of Buzz the most currently is SunVox which is
| free. I haven't played with it in ages, mainly b/c I use live
| now. Did you spend any time in the tracker communities when
| Buzz was around? I was on em411 in various guises. Nothing like
| that community online now - too much noise everywhere.
| mastazi wrote:
| I have tried SunVox on the iPad, it's a very nice
| application.
|
| On tracker websites I used to be mastazi just like my HN
| username, but I never released my own music I think. However
| I made a CD and gave it to friends, I might still have a copy
| somewhere at my parents' home in Italy. That's the only
| memory I have, because I lost all of my Buzz project files in
| a HD failure many years ago.
|
| The modern web is different from what we have back then, but
| if you look hard enough you can still find corners of the web
| that look familiar :-)
| sandos wrote:
| Wow, talk about a flash from the past! I was super-into jeskola
| buzz, I also worked with game development of very small games
| (<400KiB) and we wanted better sound effects in those, so I
| basically developed a softsynth that was very similar to
| jeskola buzz! I mean, it was sort-of horrible but it did
| produce some very interesting sounds with tens or hundreds of
| bytes in data size, which was a hugh improvement.
| tomduncalf wrote:
| Yes Buzz! Absolutely loved that software. So powerful and
| esoteric yet fairly easy to use (if you were familiar with
| trackers at least).
|
| It was a shame there was the whole thing of losing the source
| code that killed development for years, and that it never made
| the leap to cross platform, otherwise I'm sure I'd still use it
| today!
|
| Have you tried Drambo on iOS? I guess in some ways it's the
| closest thing I've found to Buzz, in that it operates at the
| same level of "granularity" in terms of the modules, and in
| that it has sequencing (step based in this case, though piano
| roll is coming) built in. It's easily my most used iOS music
| making app these days, really brilliant bit of software.
|
| MiRack is also really fun, although I find dealing with the
| myriad UIs for each module a bit challenging sometimes (though
| it is a fun touch!) - Drambo has a much more standardised
| layout for each module (like how Buzz was just sliders IIRC).
| mastazi wrote:
| > It was a shame there was the whole thing of losing the
| source code
|
| Yes, I can remember that very well! Eventually Oskari rebuilt
| the app basically from scratch, using .NET (at least IIRC)
| and that's what you get today if you go to the site and
| download it. It's not the original app but it maintains the
| same API for modules. Oskari nowadays is a researcher and he
| published some interesting articles:
| https://arxiv.org/abs/1407.5042
|
| > Have you tried Drambo on iOS?
|
| Nice, thank you! I had never heard of it but after watching a
| couple of YouTube videos I decided I'm going to download it
| tomduncalf wrote:
| Ah interesting! I think I had moved away from Buzz by the
| time it was rebuilt but have very fond memories of the
| software and the community around it.
|
| I hope you enjoy Drambo! It can take a little while to get
| into the swing of it but if you used to use Buzz I really
| think you'll enjoy it. There are a tonne of tutorials on
| YouTube about it to get going. Being able to host AUv3
| plugins is awesome too!
| marcodiego wrote:
| Love the feature matrix.
| PaulDavisThe1st wrote:
| "Five dollars less in your pocket". Brilliant!
| diskzero wrote:
| I like it, I bought it! Lot's of nice features and a tweaky graph
| UI. Added bonus for implementing the "kissing nodes" connection
| idiom.
|
| I would love see more prefabs, especially ones designed to
| emulate some classics synths.
|
| It also might be time to add undo. Everyone (especially me) likes
| to save it for last.
|
| Keep up the good work!
| adultSwim wrote:
| It looks like the Linux Makefile is included in .gitignore
|
| Linux build instructions would be great. I wasn't able to get the
| binary running on Debian 11 due to library version differences.
| makeworld wrote:
| Not sure how to get it running on Arch Linux either. Opened an
| issue for this:
| https://github.com/awwbees/BespokeSynth/issues/108
| MadWombat wrote:
| Paid my $15. Great effort. A bit cryptic, but a nice deviation
| from a standard DAW experience. A bit weird how a lot of things
| you would expect to be separate modules are combined (like LFOs
| are created by right clicking on parameters and filters are
| buried somewhere under "effect chain" module. Naming is a tad
| weird as well. LFO is LFO, but VCO is a sig gen. I get that it is
| not really "voltage controlled" but it has been an industry
| standard naming for decades. I will definitely play more with it
| and hope it matures.
| PaulDavisThe1st wrote:
| Inside of similar-ish computer environments (CSound,
| SuperCollider, Chuck, PureData), these things have been known
| as "gens" (short for generator) for at least as long as [ EDIT:
| digital synthesis ] has existed (since it dates back to Max
| Miller and the origin of the MusicN language family).
|
| [ I edited it because I realized that VCO's actually go back to
| about 1910 ]
| detay wrote:
| Genius work. There are real UX gems here, very intuitive.
| smt923 wrote:
| damn, I've been looking for something similar to Max/PPOOLL but
| more accessible (especially on windows/linux) after reading about
| Tim Hecker using it and this seems like it could get to that
| point
| PaulDavisThe1st wrote:
| > I've been looking for something similar to Max/PPOOLL
|
| That would probably be PureData.
| smt923 wrote:
| that's definitely got a lot of stuff too, though from what
| I've seen the PPOOLL stuff seems a bit more high level closer
| to bespoke synth, I guess the ideal thing is something that
| spans both, though bespoke is one of the easiest to use ones
| I've seen yet which is nice
| operatorius wrote:
| > reading about Tim Hecker using it
|
| hey could you please share the link where you've read that.
| Thanks!
| smt923 wrote:
| the other link has a little, it's kinda just something i've
| seen around in different places when I was super curious
| about his music and how you'd produce stuff like that,
| specific ones I can find right now are in random threads[1]
| and in a red bull music interview he talks about it a tiny
| bit[2]
|
| [1] https://llllllll.co/t/ppooll-max-msp-networking-
| system/28352
|
| [2] https://www.redbullmusicacademy.com/lectures/tim-hecker-
| lect... (ctrl f for "P-P-O-O-L-L")
| Minor49er wrote:
| You can see it being used here at :22. The original title of
| this video is "Rewire - Studio Visit: Tim Hecker"
|
| https://scontent-
| frt3-1.xx.fbcdn.net/v/t66.36240-6/10000000_...
| fivre wrote:
| damn, the audio wave visualization on the wires in the thing
| that's like the Bitwig grid editor is just BRILLIANT.
|
| probably would be a bit much in a complex finished instrument but
| that's amazingly intuitive for the building phase, or for reading
| someone else's instrument.
|
| i wish there a way to translate old Reaktor library stuff into
| more modern synth GUIs. there's some amazing gold in there but it
| is nigh impossible to understand between Reaktor's uh...
| challenging UI and the total lack of documentation for the signal
| paths to try and explain them to a relative novice. you can very
| easily see _what's_ built, but god help you try to understand why
| on your own without adding a ton of scopes everywhere manually
| smusamashah wrote:
| Is there a similar tool for doing graphics?
| mortenjorck wrote:
| The oscilloscope-as-wire idea is one of those rare ideas that
| seems obvious in hindsight, yet no one (to my knowledge) has
| done it before, at least in a box-and-pin UI.
|
| I wouldn't be surprised to see it start popping up elsewhere,
| similar to how Ableton made everyone realize they had somehow
| been living without retrospective MIDI capture.
| awwbees wrote:
| hey! I'm the guy who developed bespoke. I too thought that
| the waveform-in-wire thing was original, but a few years
| after I put it in, I realized that I had subconsciously
| stolen it from ReacTable. there's nothing new under the sun,
| everything is a remix!
|
| https://www.youtube.com/watch?v=Mgy1S8qymx0
| ioseph wrote:
| Not quite the same but I love the way the ports in VCV Rack
| are LED's who's intensity changes with the signal voltage,
| really makes debugging at a glance easier.
| bouvin wrote:
| This, I believe, was something introduced by Expert
| Sleepers in their Eurorack modules. That was certainly the
| first place I saw it.
| thenberlin wrote:
| This is incredibly cool. Looking forward to loading it up.
|
| Reminds me a bit of Reaktor's builder environment, but based on
| that demo video, it seems like a more useable, better thought out
| version (and you can't beat that price / feature matrix).
___________________________________________________________________
(page generated 2021-09-15 23:02 UTC)