Hacker News Reader

That was my impression too, it looks very much like an SC style computer music language. Which begs the question, who is this for? Someone who writes plugins doesn't need or want the high level SC style language. Someone seriously into computer music/audio isn't going to want the limitations, and has a lot of options already to choose from that are mature, if relatively unknown outside music circles.

If it were my company, I would be marketing this squarely at people with the need for high level procedural audio in a web context. This looks like it could be great for browser-based game devs, for example. I do know that Pure Data and Andy Farnell's great sound design book for it were a hit in the game dev world of procedural audio, FWTW.

It's probably for people who are smart enough to know DSP, but only know JavaScript and refuse to learn anything else. If you squint it looks like an empty set.

SC is typical OOP language. From this perspective, the raw Web Audio API or Tone.js are more relevant for SC.

This Elementary Audio prefers FP, which makes it quite different and I think it has the potential to be very friendly for beginners. But the docs need a lot of more works there.

Can you provide an example of where SC syntax and Elementary/JS syntax for the same thing differ in a significant way?

```Elementary JS

core.render(el.cycle(440));

```

```SuperCollider

{ SinOsc.ar(440) }.play

```

If that seems "quite different" to you, then good luck!

Personally speaking, SC's approach seems more amenable to composition (in the programming, not the musical sense). Collapsing everything down to core.render() puts the emphasis in the wrong place IMO. The oscillator is better considered to be an independent entity, and the "render" step really ought to be implicit. But to each, their own!

It really depends on your angle.

for example, "1 + 1" in FP is different from "1 + 1" in OOP.

In FP, everything is func. 1 is func; + is a combinator.

In OOP, 1 is an obj, + is the method of that obj that takes another obj.

It looks like you really enjoy SC's syntax. It's great. But essentially, the language is just one part of SuperCollider.

SuperCollider = sclang + scsynth

sclang -> OSC msg -> scsynth

The scsynth is actually the soul of SuperCollider to many computer musicians and that is what drives many to develop different language front-ends for scsynth.

Language is just a wrapper, with different programming paradigms. But down to the lower abstraction, it's the audio graph. I have no connection with Elementary js at all but I think it does a good job for providing a new angle for Web audio. Yet I understand your concern of using it for developing vst plugins.

> In FP, everything is func. 1 is func; + is a combinator.

In Clojure we use RP notation, so + can be a n-ary function: (+ 1 1 1 1)

I guess another thought, mind you, is that Elementary doesn't need to succeed for hard core audio devs in order for it to succeed as a business - it just needs enough people who think they will succeed. If this turns out to be a great tool for casual or beginner plugin devs, I could see that being a valid market. Witness the explosion of casual Ableton Live plugin devs from Max for Live. I'm sure the vast majority of JUCE licenses don't wind up becoming sustaining businesses too, and the barrier to entry is a lot higher there. Whether those folks will get to the point of paying a license fee is the million dollar question I guess.

Ain't nothing wrong with selling pickaxes to miners and all that....

Overall I think these are all fair points.

Still, I think that we have an obligation towards non-hard-core audio devs (whatever that actually means) to remind them that if you want to find gold you likely need a pickaxe, but if you want to turn over a field, you need a plough.

It's not important that everyone's efforts become successful businesses. What seems more important to me is two-fold:

1. the existence of suitable entry points for "non-hard-core audio devs"

2. if it isn't possible to provide those entry points using the same tools that the "hard-core audio devs" would use, to be sure that the "non-hard-core" folks understand that there is a difference and that there is a smooth migratory pathway between the two worlds.

On that front, Elementary looks fairly good, other than its fairly strong claims that this is a suitable technology for creating commercial audio plugins.

Let's be honest: the main thing that gets in the way for "old school" technologies these days is just compilation. Perry Cook's synthesis toolkit is a very old bundle of C++ modules that lets you do more or less the exact same thing that Elementary does. But being C++ means that there's a build step (which may generate errors). For people more familiar with interpreted languages like JS and its cousins, this appears to have become an almost insurmountable obstacle. If you can't just type it and run it, it's crap.

I think that's wrong, but I understand the appeal of "type and run" for people starting out on the path of "make the computer do what I want".

As a total outsider to the audio programming world, what's the best in class framework / environment to be writing plugins in in 2022 if one were to start today?

JUCE is a common choice in commercial audio/music software.

https://juce.com/

JUCE is also reasonably popular among GPL'ed plugins, since it does allow for a GPL option. It's not perfect, and in fact has many important issues, but it's probably the least bad of a bunch of not-very-good options (no matter what type of license you're planning to use).

Yes... although the Projucer does not make it very obvious since it only shows "personal", "education", "indie" and "pro" license options.

This page does mention GPL3: https://juce.com/get-juce

As an alternative to JUCE, you can use write VST with Rust, using EGUI lib:

https://github.com/DGriffin91/egui_baseview_test_vst2

Audio lib choice:

- https://github.com/RustAudio/dasp

- https://github.com/SamiPerttu/fundsp

- https://github.com/chaosprint/glicol

Typically, you can use MIT license in Rust community.

In this video demo, you can even live coding audio effect in DAWs with Glicol as VST plug-in, built with EGUI:

https://youtu.be/tmmBhBmIEW0

Apparently, you can use the same combo to make your own.

Realistically, the hard parts of writing a plugin are:

1. understanding the DSP behind it

2. correctly implementing the GUI

I have yet to see a mechanism by which language choices really help with the problems of either of those aspects of the job.

The visual programming languages tend to have really thorough guides on the DSP - max/msp's built in docs in particular, but pure data and external libraries are super in depth too. They also tend to have horrible GUI practices...

Actually I am teaching both pd and glicol in the University of Oslo this semester. It's even quite surprising to me that most students seem to gain more logic programming ideas from pd (such as the counter and metro controlled sequencer) while learning more dsp from glicol and its browser console based docs: https://glicol.org

Of course, Miller's book is always there http://msp.ucsd.edu/techniques.htm and the examples are in pd, which is always helpful for learning dsp.

I agree with the first half. For the second half, I think for beginners, the examples are very important. From this perspective, many Rust projects comes with examples:

https://github.com/RustAudio/vst-rs

Once following the readme, it is very easy to get it work in your own machine. Then beginners can play around the examples, tweaking parameters, etc. while learning new stuffs with books or online resources.

Rust audio has also got a very helpful Discord community where beginners can always ask questions.

For the GUI part, I am not an expert, but there are more and more Rust GUI libraries (egui, iced, druid, rui): among them, egui-rs and iced-rs can all be used for VST. Still, there are some examples to get started with.

You have to use the steinberger SDK to make a vst

https://github.com/steinbergmedia/vst3sdk

But audio plugins come in many formats.

> SuperCollider or something similar remains more powerful and more flexible

SuperCollider's license effectively stops you from designing commercial products. Even the free version of Elementary allows that.

Well, if you plan to release a commercial product based on writing JS, compiling that to WASM, running somehow inside or alongside a C/C++ core engine also compiled to WASM, both running in some standalone WASM environment ... good luck!

Elementary looks like a nice playground for audio if you have a web-leaning bent. Just like SuperCollider is a nice playground for audio if you are familiar with some its fundamental assumptions.

Neither of them seem appropriate to be the basis of products I would charge someone for, other than maybe as a one-off custom tool of some sort.

What are you talking about? SuperCollider is licensed under GPLv3 [1].

[0] https://github.com/supercollider/supercollider#license

Exactly.

Any product you produce must include full source code, at which point anyone can legally post all your code on the internet.

So - very difficult to build a commercial software product with it.

The entire source code of Ardour is posted on the Internet. Nevertheless, it has no known bad-intent copies, and generates more than US $200k/yr. It is also the basis of two products generally viewed as "commercial", even though they are also GPL-licensed.

Almost all of the source code of VCV Rack is posted on the Internet. There have been a few forks for specific reasons, but it's almost certainly the most widely used software modular synthesis in existence, and has created both a paying job for its creator and a mixed libre/paid ecosystem for module developers.

The entire source code of Vital, one of the most acclaimed software synthesizers of 2021 is posted on the Internet. The author (Matt Tytel) makes a living from his work.

The definition of commercial might be a little wider than you think.

Finally, there are several ways to use SC in a product that do not involve the GPL. You fire up sclang as a separate process, feed it SC code, and sclang controls the server. Nothing you write is linked to anything GPL licensed.

Paul, I am very happy to hear that Ardour is succeeding in supporting you. While I'm not really using Linux these days for audio as I'm doing my Scheme in Max stuff now, your contributions were very influential to me back in the oughts when I was, and I remember learning a lot from your posts on various linux audio forums. It's heartwarming to know that the work is succeeding in making a good lifestyle business for you. :-)

So is one of those Harrison MixBus? It would be nice to hear that worked out. What's the other? (or both if I'm wrong on the first count)

Mixbus is one, Waves Tracks Live is the other (but is now discontinued, for reasons largely unrelated to the product itself).

I'm glad to hear Ardour is working well for you. I honestly had assumed it wouldn't be making much income, though I now realize that was based on just about no information (the sole data point I had was that it worked poorly for me when I attempted a trial on macOS about two years ago). I'm glad to hear I was mistaken about that.

I wasn't aware that VCV Rack was actually profitable either, nor that there's a mixture of libre and paid modules available for it. I'd vaguely considered that as a business model for OSS audio stuff in years past but didn't think it was likely to work in practice. Apparently I may be wrong about that - do you know if anyone's actually making decent income selling closed modules for VCV Rack?

You make a good point about running sclang as a standalone process to firewall the GPL from the rest of a product. Somehow that hadn't occurred to me, but it seems like it would work.

Overall - thanks for the rebuttal. You make a strong case that open source audio software is more compatible with commercial sales than I thought, and I appreciate you taking the time to do it.

This is a bad faith argument and is effectively FUD.

The list of open source projects that people use in a commercial setting is long. Linux, Apache, Nginx, mysql/postgres/SQLite, Redis, Git, nearly every major programming language (C, PHP, Go, Python, Node), Firefox/Chromium, to name a tiny fraction.

Businesses that have libre/free/open source as their core product are also numerous: SQLite, Gitlab (open core), Red Hat, Docker, Nginx, Npm, Redis, Wordpress to name a few of the big players. There is a long tail and companies like Draw.io, Gratipay, Overleaf, Jitsi and the list goes on.

The list of open source hardware companies is also long: Adafruit, Arduino, Sparkfun, Seeed Studios, Gaudi Labs, LittleBits, Olimex, Zynthian, to name a few.

GPLv3 is a so-called "viral" license, making sure that any changes are given back to the community. This is done to prevent bad actors from taking the code, modifying it and then claiming it as their own intellectual property. From what I understand, this has the effect of preventing larger businesses with a more "classic" intellectual property stack from using smaller business's code base without giving back.

I have heard rumors that larger businesses, like Amazon, specifically use GPLv2 so as to not trigger the viral licensing, effectively benefiting from the commons without giving back to the broader community at large. I have also heard companies like NVidia use MIT licensing for code given to potential clients/customers/internally and strongarm everyone involved to not release it, creating a situation where they're not violating the licensing terms but never releasing it to the public.

Though a cultural or psychological effect, from what I understand, smaller businesses tend not to be too successful at "stealing" competitors code as the brand awareness and domain intelligence looks to be the more relevant factor to success. For businesses that do use others libre/free/open source code, there tends to be a virtuous cycle, where they each build on the others success and widen the market. Perhaps it's the other way around that success in one business allows for others to expand the market further.

Making money from business is difficult to begin with regardless of whether the core product is libre/free/open. Understanding how to create a business that has libre/free/open source products at its core is still being discovered, so it's not like there's a definitive answer but to say that it kills the opportunity is flat out incorrect.

> This is a bad faith argument and is effectively FUD.

As the one who made the argument, I can assure you that it was not made in bad faith.

I'm a big fan of open formats, open source, and libre software, and have made small contributions to various projects for a number of years (usually code contributions and bug reports, but occasionally financial donations too).

The argument was made from my sincere belief that, difficult as it is to make a sustainable software business (which I've seen up close, having participated in multiple failed startups), it's much harder to make a successful business with an open source product.

I would love to find out my belief is wrong, but it's still the one I've got until persuaded otherwise.

Accusing me of bad faith added nothing to your argument and violated the site's guidelines. Maybe skip that next time?

> The list of open source projects that people use in a commercial setting is long. Linux, Apache, Nginx, mysql/postgres/SQLite, Redis, Git, nearly every major programming language (C, PHP, Go, Python, Node), Firefox/Chromium, to name a tiny fraction.

Yep, OSS is everywhere and used for commercial purposes all the time. Large swaths of what you've listed above aren't commercial products, though, AFAIK.

I think most commercial software products use open source tools somewhere in their stack.

I should have been more specific with my claim - I think if the core components that form your software's value proposition are OSS, it's very hard to make a sustainable business out of selling that software.

The fact that open core products are a popular and successful way of monetizing OSS tools suggests as much, as there's some proprietary "secret sauce" that the users pay to get access to.

Open hardware works much better, I think, because people instinctively understand they've got to pay for someone to build the physical artifacts. Somehow, even developers seem to undervalue the effort it takes to build and maintain a useful piece of software.

> but to say that it kills the opportunity is flat out incorrect.

I don't believe I said it kills the opportunity. Just that it makes it much more difficult.

> Accusing me of bad faith added nothing to your argument and violated the site's guidelines. Maybe skip that next time?

I called out bad faith argument then steel-manned your argument and responded in good faith. In this case I felt calling out a bad faith argument and FUD was concisely pointing out part of your argument, which I take to be part of being a critical reader. I assume good faith until evidence suggests otherwise, which it did in this case.

> Large swaths of what you've listed above aren't commercial products, though, AFAIK.

I point out that there are many open source projects that fuel businesses and then go on to explicitly list businesses that have as their core product a piece of open source software. You conveniently left out the line directly underneath it listing those businesses. I qualified each of the sentences correctly.

> I don't believe I said it kills the opportunity. Just that it makes it much more difficult.

This is the original sentence you wrote:

""" SuperCollider's license effectively stops you from designing commercial products. Even the free version of Elementary allows that. """

---

You continue to argue in bad faith. Me pointing it out highlights that you are engaging in behavior that is undermining constructive debate.

> This is the original sentence you wrote: """ SuperCollider's license effectively stops you from designing commercial products. Even the free version of Elementary allows that. """

I did not write that.

Here is my comment you responded to:

https://news.ycombinator.com/item?id=30998118

You're thinking of Archit3ch's post here:

https://news.ycombinator.com/item?id=30995834

Maybe you should check identities before levelling accusations at people.

Yikes, my apologies.

Some of what I said still stands but that's a big enough mistake on my part that I just need to apologize and back off.

I forgive you, and appreciate the apology and recognition that you needed to step away and take a breather.

I do think you make a decent case for open source being a viable way to make a profitable business. There are certainly businesses that achieve that, and I would love to see more of them.

I wasn't trying to give a blow-by-blow rebuttal to everything you wrote, so it's certainly fair to say I was cherrypicking.

I was just trying to explain some of why I think making a business's core product open source ticks the difficulty level up a notch. I believe AWS has made a practice of snagging OSS systems and making them effectively their own, thus undercutting the original developers' attempts at running a business. I may be mistaken about that, though.

As I said, though, you make a number of good points (most of which I already agree with). There are a number of ways to make it work, and I may well have overstated the difficulty of building businesses with GPL software.