Occasional Silent Samples Loops, Windows 10

I’ve had a couple of times now where pieces were correctly playing loops with synths in, but failing to play loops with samples. I’m using multiple buffers if that’s relevant but I don’t think so.

Restarting Sonic Pi didn’t fix it - I had to reboot the PC. Is there something I can do in the moment to kick it into life e.g. stopping a process in task manager?

I can’t replicate it, it happened out of the blue both times, and it could well just be this PC. But it would be a problem in performance so a workaround tip or guess would be welcome, thanks.

Symptoms: loop with a ‘sample’ statement seems not to run at all, no error messages. Comment out the sample statement, and put in a synth play, it runs. Uncomment the sample statement, fails to run.

Interesting issue!

How do you know that the live loop with the sample is t playing? Is it’s just because you can’t hear it? Things to try

  • Do you see the name of the live loop appear in the cue pane (in which case it is running and somethings up with the call to sample)
  • Put an call to play in the same live loop and hit run again - do you hear the synth too?
  • Are you using your own sample or one of the built in ones? If it’s your own, try swapping it out for a built in one (without stopping the code again) and hit run. Do you hear the built in one?
  • What do the logs say? Does it think it’s triggering the sample? Do you see the correct path to the sample printed?

The loops didn’t seem to be running at all - nothing appearing in either window. First thought was a coding error. I put in some puts statements - nothing. But when I commented out the sample statement then it did run. Uncommented, it stopped again. After a reboot it all worked fine.

Yes they were my own samples.

Next time it happens I’ll try using a builtin sample. But really, I just want to kill off the whole thing and start again as quick as possible without rebooting the PC. First time it happened was in a rehearsal (sod’s law in action) and it’s not the place to start investigating.

If SP doesn’t normally leave anything running after a quit, then OK next it happens I’ll see if anything is left dangling. Must be something. Any tips, pleased to hear them.

I’d like to get to the bottom of this really.

Threads rarely, if ever, stop without throwing an error.

It might somehow be the case that this particular thread got blocked in a bad state with your sample - in which case I’d really like to figure out what’s going on.

I would love to know if changing the sample - without stopping the loop - and hitting run again fixes it. If the loop is blocked then it won’t.

I’d also like to know the contents of the debug logs in ~/.sonic-pi/logs Immediately after it happens they might shed some light here.

OK, next time it happens I’ll capture the log and try changing to a built in sample too. If I’m able I’ll take vid too, as it unlike what I’ve been see generally - as you say normally there’s a message.

1 Like