Refactor audio with a dedicated Sampler #365
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Moves the
AudioClip
/AudioWave
iterator
methods to a newSampler
class.The reasons for this are the following:
AudioWave#drop
was pretty much broken for waves generated for oscillators. Turns out that I would need to add more iterator special cases.iterator
methods was to allow streaming data from audio files, but that doesn't make much sense with the current interface, which pretty much promises random access to the clip.As such, I decided to simplify the code and make those methods agnostic of the underlying
AudioWave
/AudioClip
implementation.Also, for now I'm considering streaming audio out of the scope for Minart. It's still possible for an application to implement that using something like a
Iterator[AudioClip] or a
Stream[AudioClip]`, but I imagine each application will have their preferred format.I also did some tests with HyperLoopRunner on Firefox and now the audio seems good, so I think this should close #354
Finally, this also fixes a bug with
AudioPlayer#play(wave, channel)
, which was always using channel 0.