Live data from Hacker News

C++ audio mixing library design

lisyarus.github.io

51–54 of 54 posts

Re: C++ audio mixing library design

#51
> The stream interface is the core of the library, so let’s discuss it first. It is remarkably simple

It's interesting (odd?) that the interface doesn't just expose a function to get the next value, similar to a lazy list in Haskell, which also goes well with the original statement in the post that a stream is basically a function. The 'sine_wave' stream for example is 90% filling the array and 10% actual stream logic, which I imagine you're duplicating in other stream implementations.

Re: C++ audio mixing library design

#52
post #51

> The stream interface is the core of the library, so let’s discuss it first. It is remarkably simple It's interesting (odd?) that the interface doesn't just expose a function to get the next value, similar to a lazy list in Haskell, which also goes well with the original statement in the post that a stream is basically a function. The 'sine_wave' stream for example is 90% filling the array and 10% actual stream logi…

That's for efficiency reasons: most streams have way more logic than just filling the array, which can hardly be represented in terms of "getting the next value", and loops are good for optimization by compiler, etc. In fact, the actual sine wave implementation looks exactly the way you describe: it handles a generating function to a helper class that just fills the array https://bitbucket.org/lisyarus/psemek/src/master/libs/audio/...

Re: C++ audio mixing library design

#53
post #15

Earlier quoted context omitted.

std::span is new enough to not be in muscle memory of C++ programmers. Even the standard library commits a similar sin with `from_chars` and not taking a `string_view`.

string_view would definitely have been wrong. std::span did not exist in the Standard at the time std::from_chars was adopted. An overload that takes std::span would be easy, and harmless. But as std::from_chars is only ever used from within some other abstraction, any benefit would be minimal.

Why would string_view be wrong there?

Re: C++ audio mixing library design

#54
post #53

Earlier quoted context omitted.

string_view would definitely have been wrong. std::span did not exist in the Standard at the time std::from_chars was adopted. An overload that takes std::span would be easy, and harmless. But as std::from_chars is only ever used from within some other abstraction, any benefit would be minimal.

Why would string_view be wrong there?

Because, then, to parse out a number you would first need to get it into a string.
Post reply on HN