Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Endless audio stream support #331

Open
frabert opened this issue May 15, 2019 · 2 comments
Open

Endless audio stream support #331

frabert opened this issue May 15, 2019 · 2 comments
Labels
type: enhancement [MINOR] Feature that doesn't take more than a few days to implement
Milestone

Comments

@frabert
Copy link

frabert commented May 15, 2019

This is a followup from https://discourse.bsframework.io/t/endless-audio-stream-support/434

I'm willing to work on adding this feature to the codebase. I am thinking that the best way would not be to modify AudioClip to support "infinite" lenghts, but to introduce a new class (AudioStream maybe?) that only supports PCM audio from a stream.What do you think?

@BearishSun
Copy link
Member

It would be really nice to have support for this.

I would only consider doing it in a separate class if the solution requires a radically different approach than what AudioClip already does. I took a quick look at it when I answered that post on discourse, and it seemed like only minor modifications regarding checks for fixed length might be required. AudioClip already supports different load modes, so adding one more wouldn't be a stretch, even if the modifications aren't as simple.

Compare that to adding a separate class, things get a lot more complex as they need to be usable in the same places (meaning same base, which breaks the API, or deriving from AudioClip itself, which will probably be a lot of refactoring). Also the plugin implementations don't like implementing class hierarchies, requiring intermediate classes which make things even more complex, esp. if a simple if could have done the job.

@frabert
Copy link
Author

frabert commented May 15, 2019

Interesting, because the idea of creating a separate class was precisely to not introduce breaking changes for previous users 😄 I will take a look at it and report back when I know something more about it

@BearishSun BearishSun added the type: enhancement [MINOR] Feature that doesn't take more than a few days to implement label May 20, 2019
@BearishSun BearishSun added this to the Longterm milestone May 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement [MINOR] Feature that doesn't take more than a few days to implement
Projects
None yet
Development

No branches or pull requests

2 participants