I have a fix that seems to work.<div><br></div><div>In fluxa.ss starting at line 991 my file now looks like this;</div><div><br></div><div><div>  ; time for an update?</div><div>  (cond ((> (time-now) logical-time)</div>
<div>       ; todo: fall back on last thunk if there is an error</div><div>     (with-handlers ([(lambda (x) #t) fluxa-error-handler])</div><div>           (set! tempo (proc (+ logical-time (* bpb tempo)) clock)))</div><div>
<font class="Apple-style-span" color="#CC0000">         (when (not (number? tempo))</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" color="#CC0000">               </font></span><font class="Apple-style-span" color="#CC0000">(set! tempo 1)</font></div>
<div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" color="#CC0000">             </font></span><font class="Apple-style-span" color="#CC0000">(display "proc should return a number, correcting."))  </font></div>
<div><span class="Apple-tab-span" style="white-space:pre">      </span> (set! logical-time (+ logical-time tempo)) </div><div>         (set! clock (+ clock 1))</div><div>         (set! sync-clock (+ sync-clock 1))))</div></div>
<div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><br class="Apple-interchange-newline">Surprisingly testing for "tempo" being a number is enough. When tempo is non-positive you just get loads of notes. I didn't consider imaginary or complex tempos.</div>
<div><br></div><div>I tried to use this;</div><div>(when (number? tempo) (set! logical-time (+ logical-time tempo)))</div><div><br></div><div>But that wouldn't fly. I think that not allowing time to pass got something stuck. Using "error" instead of "display", which I thought was more proper as there *is* a error also meant the end of the fluxa task (probably because it's outside of the scope of that error handler?). Like this it works. There may be better ways to make it work; I tried this;</div>
<div>(seq null)</div><div><br></div><div>I felt that might reset the sequencer when we've had enough of the beeps for a bit. It does, but it also generates a whole train of non-crashing errors. I think that's a separate issue though, one of seq's input, as opposed to the output of proc.</div>
<div><br></div><div>Yours,</div><div>Kas.</div><meta http-equiv="content-type" content="text/html; charset=utf-8">