[CM] stop-playing-hook problem

[Kjetil Svalastog Matheussen]

On Mon, 24 May 2004, Bill Schottstaedt wrote:

>  > Now I pressed the GO button again.
>  > The violine plays again in a loop.
> 
> There are two related problems here.  In several files, add-hook!
> is called whenever that file is loaded, so if the file is loaded
> twice, the hook gets two copies of the added hook function.  This can
> be avoided by adding (if (not (defined...)))  around the
> load-from-path calls (for example, in snd_conffile, many of the dlp
> files are loaded, but they may already have been loaded).  Or we
> could use hook-member (hooks.scm).  But currently there's little attempt to
> protect against redundant functions on the hook list. If one such

Okey, I'll remember to add checks in snd_conffile.scm when loading
files.


> hook is stop-playing-hook and it's getting a function that calls
> (play) to loop, you get an explosion of plays (each time one stops, it
> fires up two more). This works anyway if you just load the dlp stuff,
> but once snd_conffile.scm is also involved, several separate
> stop-hooks start stepping on each other (play.scm's play-until-c-g
> assumes it will be cancelled either via C-g or a function simulating that,
> but other loopers aren't aware that something like that is sitting
> on the hook).  So we shouldn't be using play-until-c-g in dlp/new-buttons.scm,
> but that's just a bandaid.
> 

That is actually not all of the reason. The recent problem with the 
looping is, as I wrote earlier, that the stop-hook has suddenly started 
to be called the same number of times as there are channels in the 
sound-file. I have started snd with -noinit, just added one stop-hook, 
and it gets called 1 time for mono files, 2 times for stereo-files, etc.

 
> I need to think of some way to make it safe to load these files any
> number of times.  But, the harder problem is that a function that wants
> to add a hook function has no way of knowing (in general) what else is
> already on that hook's function list -- whether for example a looping
> play is already queued up.  I think the whole start|stop-play|dac-hook
> business needs to be redone.  So, I propose to add an argument to the
> various play functions to associate a (stop-)function with that
> particular "play" call, calling that function when that play finishes.
> This way the various additions to the user interface can avoid accidental
> "cross-talk", and there's no problem of "dangling" stop-hook entries.

Yes, this sounds like a very good idea.


--