On Apr 6, 2016, at 15:18, John Clements <[email protected]> wrote:
> 1) The “stop” procedure is a giant end-of-the-world hammer; I wouldn’t expect
> it to be useful while a program is running.
OK. It had that feel.
> 2) I hesitate to suggest this, but there is a “pstream-set-volume!” function
> that can silence a pstream. (that was the caveat.)
I think this points to a hackish solution that’ll work for us for now:
https://gist.github.com/RenaissanceBug/da7027d8c55a1819f9bae274e189ccac
<https://gist.github.com/RenaissanceBug/da7027d8c55a1819f9bae274e189ccac>
The only concern I have thought of so far is whether this’ll cause memory
leakage over the course of a number of switches between pstreams; I don’t know
if there’s anything that will keep the GC from cleaning up the pstream when it
becomes unreachable.
> 3) You are also correct in your supposition that the interface I proposed is
> not implemented. It looks like it could be done quickly, meaning probably on
> the order of 10-20 hours of work for me.
I’m glad I asked rather than just dive in trying to figure it out in the middle
of a busy semester.
> The relevant code to look at here would probably be
> https://github.com/jbclements/RSound/blob/master/rsound/sequencer.rkt
> <https://github.com/jbclements/RSound/blob/master/rsound/sequencer.rkt>
> [...]
> Adding the stop-playing! call would probably involve adding some king of
> message queue to the sequencer to receive fade-out messages, and updating the
> ‘entry’ structure to contain information about sounds that are currently
> fading in or out.
I’ll look into it at some point, time permitting. But I think the gist above
will obviate my need for it, at least for the time being.
Thanks again!
Best,
jmj
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
