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

C++ audio mixing library design

lisyarus.github.io

Post reply on HN
Print view View original

31–40 of 54 posts

Re: C++ audio mixing library design

#31

Post by pjmlp »

jstimpfle wrote: post #26
pjmlp wrote: post #24

Earlier quoted context omitted.

You have to look forward to what in the plate post C23 like lambdas, improved constexpr, more _Generic support, and so forth. https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_lo...

Lambdas and some other complicated looking extensions have been on the plate for quite some time, and it seems like none of them made it into C23. Lambdas in particular have been promoted for the most part by a single person AFAICT. "C is becoming into everything C++ has" is a drastic misrepresentation.

I did not assert that C23 was it, rather that is how it looks like going forward.

What did not land in C23, will land in C26, C29, ....

Re: C++ audio mixing library design

#32

Post by secondcoming »

lisyarus wrote: post #9
chaosprint wrote: post #6

"All my engine is in C++, and I’m really sick of SDL_DoThatThing(&options, pointer_to_void, size_in_magical_units, &callback, user_data, legacy_value) (sorry for all C admirers, I do respect you, it’s just that I’m not one of you)." How about Rust audio ( https://github.com/RustAudio ) and then FFI? I am developing the audio lib for the music live coding language I design in Rust and I think the experience of Rust is…

Adding a whole new language (meaning compiler, packaging, libs, ecosystem) into my engine just for the audio lib which I _wanted_ to implement myself in the first place? No, thanks.

You insensitive clod!

Re: C++ audio mixing library design

#33

Post by pjmlp »

chaosprint wrote: post #27
pjmlp wrote: post #23

Earlier quoted context omitted.

One does the same approach as Rust, wrap the unsafe C stuff into type safe C++ wrappers. Which the author did quite alright, minus the issue I discussed on separate comment. You will have better luck moving the audio industry from bad C practices into modern C++, than making most learn a complete new language. JUCE rules in the audio industry for example.

This argument can apply to every application scene of Rust: no need to learn a new language. Yet the fact is that the Rust community is growing rapidly, from audio to embedded devices. I think the key is how much you can get from the investment, and I totally understand if people want to stick to the ecosystem they are already familiar with, a completely different story compared with a beginner. Also, I don't think t…

It is growing, it is like going through the C++ adoption as I did 30 years ago, and still there are domains it could never take over from C.

So while it is nice for the security of the IT stack, we also need to keep things in perspective.

Re: C++ audio mixing library design

#34

Post by throwaway17_17 »

Jasper_ wrote: post #7

I love audio programming, it's one of those things that's provided me with a lot of joy. I've been working on our in-house audio library for our game engine as well, and designing custom effects for it. In our case, we wanted an 80s DSP sound, so it was fun diving into the old literature. In the end, a simple design won out: https://twitter.com/JasperRLZ/status/1567546255454371842

Do you have any references for the old literature you looked at while trying to capture that sound. I would love to add some of it to my reading list. Also, the processing and track itself in your video are fantastic.

Re: C++ audio mixing library design

#35

Post by lisyarus »

qalmakka wrote: post #29

- A stream is something you can play as a sound. It may be loaded from a file or generated on the fly. It may be finite or infinite. One important thing is that a stream is single-shot: it doesn’t have a restart method or anything like that. - A channel is something where a stream is actually played. You can request the channel to stop, or you can replace the stream this channel is playing. Am I mistaken, or isn't th…

It pretty much may be!

Re: C++ audio mixing library design

#36

Post by emsy »

Jasper_ wrote: post #7

I love audio programming, it's one of those things that's provided me with a lot of joy. I've been working on our in-house audio library for our game engine as well, and designing custom effects for it. In our case, we wanted an 80s DSP sound, so it was fun diving into the old literature. In the end, a simple design won out: https://twitter.com/JasperRLZ/status/1567546255454371842

I'm a huge fan of Shovel Knights sound so I'm looking forward to Mina the Hollower!

Re: C++ audio mixing library design

#37

Post by ohgodplsno »

hgs3 wrote: post #30
jstimpfle wrote: post #22

Earlier quoted context omitted.

Examples? Because the list of accepted proposals seems conservative. https://en.wikipedia.org/wiki/C2x https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu

It is conservative, except for nullptr which duplicates NULL. This violates C's own charter of "provide only one way to do an operation."

Because NULL is dogshit. It's a #define 0. That's not one way to do an operation, that's one way to do an operation, horribly badly. That int on your stack ? Sure it can equal NULL. Hope that wasn't the result of (2 - 2).

Re: C++ audio mixing library design

#38

Post by throwaway17_17 »

jstimpfle wrote: post #26
pjmlp wrote: post #24

Earlier quoted context omitted.

You have to look forward to what in the plate post C23 like lambdas, improved constexpr, more _Generic support, and so forth. https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_lo...

Lambdas and some other complicated looking extensions have been on the plate for quite some time, and it seems like none of them made it into C23. Lambdas in particular have been promoted for the most part by a single person AFAICT. "C is becoming into everything C++ has" is a drastic misrepresentation.

I think I take the middle position between you and GP, C is slowly working it’s way towards unnecessary complexity. Most of the ‘X language is a C replacement’ posts and threads here on HN seem to disregard C’s development (particularly from 2017 onward) through committee standards releases. Everyone keeps arguing about Rust, Zig, Odin, etc and claiming one or the other is clearly more C like and the others are too complicated/expansive/growth-prone. But no one ever stops and claims that the simple C in there heads is not C in 2022, but C in 1990.

C is not yet at the point where added features, idioms, or concepts have totally removed the ability to return to or regularly restrict yourself to some ‘simple’ subset of the language. However, the push to add more and more to the standard does not inspire hope that this situation will remain.

So while I don’t think it’s there yet, it certainly looks like complexity via continual expansion is the path forward. I may not like it, but it does seem to be a reasonable supposition by GP.

Re: C++ audio mixing library design

#39

Post by UncleEntity »

lisyarus wrote: post #9
chaosprint wrote: post #6

"All my engine is in C++, and I’m really sick of SDL_DoThatThing(&options, pointer_to_void, size_in_magical_units, &callback, user_data, legacy_value) (sorry for all C admirers, I do respect you, it’s just that I’m not one of you)." How about Rust audio ( https://github.com/RustAudio ) and then FFI? I am developing the audio lib for the music live coding language I design in Rust and I think the experience of Rust is…

Adding a whole new language (meaning compiler, packaging, libs, ecosystem) into my engine just for the audio lib which I _wanted_ to implement myself in the first place? No, thanks.

I think you’re meant to rewrite your whole game engine in rust to make it easier.

Re: C++ audio mixing library design

#40

Post by hgs3 »

ohgodplsno wrote: post #37
hgs3 wrote: post #30

Earlier quoted context omitted.

It is conservative, except for nullptr which duplicates NULL. This violates C's own charter of "provide only one way to do an operation."

Because NULL is dogshit. It's a #define 0. That's not one way to do an operation, that's one way to do an operation, horribly badly. That int on your stack ? Sure it can equal NULL. Hope that wasn't the result of (2 - 2).

In C the NULL macro can be defined as either (void*)0 or 0. It's only mandated as 0 in C++.

The nullptr concept was introduced into C to fix a type ambiguity when NULL is used with generic selection or varargs functions. The ambiguity could have been solved by mandating that NULL be defined as (void*)0. My issue with nullptr is its an overkill solution that unnecessarily duplicates the concept of NULL in the language.

Post reply on HN