Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAudioScheduledSourceNode #31
Conversation
|
r? @Manishearth |
|
Overall looks good. Also, is it possible to schedule multiple events? If so we'd need to store these as a list of events (in a smallvec probably) and check them each time. |
Good point! Yes, I believe it's possible. |
|
Also, we should ensure that these events only need to be checked per-block
(not frame) when we handle the timings.
Otherwise we need to make this part of an updateparameters step.
AudioParams need something like this too, so if you want we can leave it as
is as a k-type schedule till I add that support.
…On Tue, May 29, 2018, 12:06 PM Fernando Jiménez Moreno < ***@***.***> wrote:
Also, is it possible to schedule multiple events? If so we'd need to store
these as a list of events (in a smallvec probably) and check them each time
Good point! Yes, I believe it's possible.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#31 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABivSF38K3ZffkmX31jAvCIHKr_gjJ4Wks5t3R2wgaJpZM4UQRyF>
.
|
ferjm
force-pushed the
ferjm:audioscheduledsourcenode.start.stop
branch
2 times, most recently
from
ee445de
to
1a9608b
|
Given that we now have ticks, can we internally use ticks for this? We can convert time floats to ticks at the user API boundary |
ferjm
force-pushed the
ferjm:audioscheduledsourcenode.start.stop
branch
from
1a9608b
to
8429e84
ferjm
force-pushed the
ferjm:audioscheduledsourcenode.start.stop
branch
from
8429e84
to
3748b6b
|
@Manishearth I think this is ready for a final review. I checked the spec and found that we cannot schedule more than one start or stop times, so my believes here where incorrect. |
| fn message(&mut self, msg: AudioNodeMessage, sample_rate: f32) { | ||
| match msg { | ||
| AudioNodeMessage::SetAudioParamEvent(event) => { | ||
| self.gain.insert_event(event.to_event(sample_rate)) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Manishearth
Jun 1, 2018
Member
Oh, I see what you did.
(sorry, reviewing on a phone)
I guess this is ok. A lot of the messages are common between nodes so I thought we'd have common messages. But this works.
| pub enum AudioNodeMessage { | ||
| SetAudioParamEvent(UserAutomationEvent) | ||
| OscillatorNode(OscillatorNodeMessage), | ||
| GainNode(GainNodeMessage), |
This comment has been minimized.
This comment has been minimized.
Manishearth
Jun 1, 2018
Member
I think we should be able to send all kinds of messages to all nodes, and nodes filter what they can actually handle.
Also, this reverts the AudioParam changes.
So you have SetAudioParam, Start, and Stop.
ferjm commentedMay 28, 2018
•
edited
Fixes #21.