search

jbclements / RSound

A cross-platform sound library for DrRacket
http://www.brinckerhoff.org/clements
Other
45 stars 11 forks source link

Pressing "Stop" doesn't stop the sounds #12

Open samth opened 9 years ago

samth commented 9 years ago

When I run an rsound program, such as the examples, in DrRacket in #lang racket, then hitting stop doesn't stop the sound from playing. Instead, I have to close the tab to stop the sound.

jbclements commented 9 years ago

It's not clear to me what the right thing here is. In particular, as I understand it, the "stop" button currently means "raise an exception on the user's computation, and return control to the REPL. If I run (play long-sound), then the evaluation of this expression returns immediately to the REPL, while the sound plays.

Put differently, It seems like hitting the "stop" button when the cursor is at the REPL prompt is currently a no-op, and it seems like changing that behavior might be difficult to implement or have unforseen consequences.

However, you could always call the '(stop)' function...

samth commented 9 years ago

Can you spawn a thread that kills the sound on stop? It seems like this ought to be already possible in DrRacket. @rfindler, any thoughts?

rfindler commented 9 years ago

Stop breaks the thread. Rsound's prims just enquque the sounds to some other thread I guess?

Do sounds stop when there are runtime errors?

Robby

On Monday, September 22, 2014, Sam Tobin-Hochstadt notifications@github.com wrote:

Can you spawn a thread that kills the sound on stop? It seems like this ought to be already possible in DrRacket. @rfindler https://github.com/rfindler, any thoughts?

— Reply to this email directly or view it on GitHub https://github.com/jbclements/RSound/issues/12#issuecomment-56443275.

jbclements commented 9 years ago

No, they don't. Getting that right seems a bit fiddly, seems like I'd have to rewrite #%top or something.

rfindler commented 9 years ago

I guess the question is how do you want to decide how to stop a sound. What is the criterion that's best to use? The prompt appearing?

On Monday, September 22, 2014, John Clements notifications@github.com wrote:

No, they don't. Getting that right seems a bit fiddly, seems like I'd have to rewrite #%top or something.

— Reply to this email directly or view it on GitHub https://github.com/jbclements/RSound/issues/12#issuecomment-56457359.

benoid commented 7 years ago

I think the confusion here is that pressing the stop button in DrRacket seems to do nothing if the repl is waiting for user input. It doesn't even clear the current line of text like the command line repl does. If DrRacket does not throw an exn:break?, there is nothing really for RSound to catch in order to know when to kill the sounds.

Regardless, I think that the sounds should not stop playing on a user-break. RSound is awesome to use for live synth coding, and sounds persisting on a user-break is really necessary for creating music via the repl.

However, I should add that when I first began using RSound about a year ago (I was new to Racket at the time), lack of sound stopping in DrRacket confused me for a while too. Maybe the solution to this issue is discussing behavior early in the documentation, including why it is beneficial to the library for it to remain this way.

rfindler commented 7 years ago

Just to be sure we are all on the same page: when the program contains a call to read and that call happens, then the REPL will be accepting user input and clicking the break button will break it and cause it to stop accepting user input.

DrRacket views the prompt where expressions are input as not part of the user's program, so clicking the break button doesn't break that loop. Running read-eval-print-loop from inside the program is closer to what you get when you type "racket" at the command-line.

Robby

On Sun, Feb 12, 2017 at 11:45 PM, David Benoit notifications@github.com wrote:

I think the confusion here is that pressing the stop button in DrRacket seems to do nothing if the repl is waiting for user input. It doesn't even clear the current line of text like the command line repl does. If DrRacket does not throw an exn:break?, there is nothing really for RSound to catch in order to know when to kill the sounds.

Regardless, I think that the sounds should not stop playing on a user-break. RSound is awesome to use for live synth coding, and sounds persisting on a user-break is really necessary for creating music via the repl.

However, I should add that when I first began using RSound about a year ago (I was new to Racket at the time), lack of sound stopping in DrRacket confused me for a while too. Maybe the solution to this issue is discussing behavior early in the documentation, including why it is beneficial to the library for it to remain this way.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jbclements/RSound/issues/12#issuecomment-279299444, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYWsNUoEbFj48k5Z31nvrlGsliJST_Bks5rb-4WgaJpZM4Ck_1U .

benoid commented 7 years ago

Ah, thanks! It's helpful to know DrRacket works as such.