Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elementary Audio: a modern platform for writing high performance audio software

elementary.audio

Post reply on HN
Print view View original

91–100 of 110 posts

Re: Elementary Audio: a modern platform for writing high performance audio software

#91

Post by NateEag »

PaulDavisThe1st wrote: post #80
NateEag wrote: post #75

Earlier quoted context omitted.

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 us…

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.

Re: Elementary Audio: a modern platform for writing high performance audio software

#92

Post by PaulDavisThe1st »

chaosprint wrote: post #85
iainctduncan wrote: post #54

Earlier quoted context omitted.

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 co…

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?

Re: Elementary Audio: a modern platform for writing high performance audio software

#93

Post by PaulDavisThe1st »

iainctduncan wrote: post #88
PaulDavisThe1st wrote: post #49

It's hard to know what to say. > The conventional approach to writing audio software is an challenging process requiring expertise in a wide breadth of topics– C++, multi-threading and thread safety, lock-free programming, and realtime thread safety come to quickly to mind, and we haven't even mentioned digital signal processing itself. Moreover, the tooling, workflow, and developer experience that we have in this ap…

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…

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".

Re: Elementary Audio: a modern platform for writing high performance audio software

#94

Post by chaosprint »

PaulDavisThe1st wrote: post #92
chaosprint wrote: post #85

Earlier quoted context omitted.

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

```

Re: Elementary Audio: a modern platform for writing high performance audio software

#95

Post by fenomas »

moron4hire wrote: post #10

One of the biggest problem I have with WebAudio API is managing nodes. The API is extremely verbose, when you consider that anything interesting will need to be composed of dozens of basic nodes combined in different ways. You're given a very basic set of primitive nodes, from which you can construct pretty much anything else. But those things you construct will never be "nodes" themselves. You can't create synthetic…

Yes, managing webaudio nodes is pretty hellish. If you're interested I maintain a small library for abstracting them - basically you pass the library an object describing what oscillators and filters you want, and what timing envelopes you want attached to their params, and then the library creates and destroys everything. It has no concept of plugins or processing, but it makes it convenient to play around with arbitrary configurations of basic nodes.

The library is here: https://github.com/fenomas/wasgen

Re: Elementary Audio: a modern platform for writing high performance audio software

#96

Post by fenomas »

reggieband wrote: post #55
PaulDavisThe1st wrote: post #51

Earlier quoted context omitted.

> At the low end you have ... and at the other you have ... Totally missing out on the actual DAWs where most people do most of this stuff. Yes, there is some interest in and use of standalone tools. But for all kinds of reasons, the majority of new audio software development occurs with the assumption that it will run within a DAW (or at least, a plugin host). One of the reasons for that is to offload almost all of…

For my personal interest (probably no where near the majority) I am interested in these libraries primarily for use outside of a DAW. I mean, I already have a wealth of plugins for most conceivable purposes to use in one of the several DAWs I have installed. I am also in no hurry to move the kind of things I do in a DAW to a web based app. And frankly, none of the examples I've seen so far come within a country mile…

I work on this space a lot, and maintain a couple of libraries you might be interested in. They are very much focused on light quick "good enough" web audio music/sound effects.

https://github.com/fenomas/wasgen - a declarative abstraction layer around web audio oscillators and filters

https://fenomas.github.io/wafxr/ - a GUI front-end demo for the previous

Re: Elementary Audio: a modern platform for writing high performance audio software

#97

Post by PaulDavisThe1st »

chaosprint wrote: post #94
PaulDavisThe1st wrote: post #92

Earlier quoted context omitted.

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!

Re: Elementary Audio: a modern platform for writing high performance audio software

#98

Post by chaosprint »

PaulDavisThe1st wrote: post #97
chaosprint wrote: post #94

Earlier quoted context omitted.

```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.

Re: Elementary Audio: a modern platform for writing high performance audio software

#99

Post by dharma1 »

I’m pretty bullish for more and more lightweight use cases of audio running in the browser, and it’s also nice how much of it is open source.

Audio editing (audiomass.co), fun little sequencer experiments (https://teetow.github.io/elementary_grid/) - things like this keep getting better.

I wouldn’t run a full DAW in the browser yet (too spoiled with Logic) though BandLab is having a good go at it. But makes no sense to poo poo those attempts either. Both have their uses (browser based apps and native apps)

Re: Elementary Audio: a modern platform for writing high performance audio software

#100

Post by abetusk »

NateEag wrote: post #75
abetusk wrote: post #64

Earlier quoted context omitted.

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.

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.

Post reply on HN