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.
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.
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.
@samaaron this did happen once again, and unfortunately I wasn’t in a position to down tools and capture it I’m afraid. However, I did notice that the PC was accidently unplugged and running on battery and I remember that was the case the last time. It was behaving a bit oddly - e.g. Windows Explorer appeared stuck browsing the file system when I went to look at that folder. My guess is that it’s a quirk on this PC and not worth looking into further.
It’s also known that some PCs pause their CPU for long periods of time (long in the CPU sense of timing not human timing) in order to preserve battery life. This has the tendency to slow the computer down, which if you’re browsing the web or writing a document may not impact you too much (slightly slower rendering for example) but if you’re doing time critical activities (such as making music) this can cause real issues. However, whenever I’ve directly or indirectly observed this kind of behaviour the result is that one or more of Sonic Pi’s threads realises that it can’t keep up and self-terminates throwing an “out of time” error. This is what I would have expected here. However, as you’re not seeing any error it’s possible that one or more of the threads could somehow have been completely blocked. This is even more confusing as Ruby (the underlying runtime language) doesn’t use multiple real operating system threads - it uses its own pretend ones (so-called green threads) so if you’re seeing blocking behaviour, it’s not just a single thread that’s blocking it’s the whole Ruby runtime.
Anyway, if you do find any more information about this I’d love to hear it
Thanks. Given what you say, the symptom that the synth-based loops run fine, but the sample-based loops don’t is interesting. Makes me suspect the file system/disk rather than CPU. Even though I’ve got the power options to be similar plugged-in vs battery who knows what Windows actually does.
Ah ok - then what could be happening in that case is that the sample based thread is blocking on the disk. Depending on how that’s implemented in the Ruby runtime on Windows, it might be that the Ruby runtime does actually use an extra operating system thread for IO operations. Unfortunately my understanding of the low-level implementation details of Ruby don’t extend to this.
I have observed weird disk blocking issues on my system when I’ve used a * in my path on a huge nested set of directories containing many, many samples. This definitely behaved a lot worse on Windows than on macOS and my feeling is that this was due to differences in either Ruby’s disk IO implementation and the Windows file system implementation.
That feels more like the kind of thing. I’m going to see if I can force it running on battery. If no one else has reported it, might not worth worrying about. But on the other hand, you can’t account for the people who don’t report something but just give up on the program.
BTW Do you have a vid/talk explaining why you used Ruby to do this? I’ve not had a reason to use Ruby before now.
Sonic Pi started off as a 3 month project funded by the Broadcom Foundation (who make the main chips in the Raspberry Pi Foundation). At the time I was a Postdoc researcher at the University of Cambridge’s Computer Labs and it was the year that the Raspberry Pi was launched. It was also the same time that the UK’s government announced a new curriculum for Computer Science in schools. The project was to build and evaluate a new system for engaging school children in Computer science that both specifically targeted the UK’s new CS curriculum and also ran well on the original Raspberry Pi 1. In that 3 months I was expected to not just design and implement a new software system, I was also expected to work with a teacher to design and teach a new set of lesson plans, and also evaluate it all.
3 months for all of this was an incredibly short period of time to say the least. In order to meet this I decided to make the first version of Sonic Pi the most simple and basic system it could be in order to get to the point that it could be useful in the classroom. I therefore chose Ruby as it was a language I had used both in my PhD for language design work and as a professional software engineer in industry for similar work. I therefore had significant expertise using it and knew that as a language it was (and is) sufficiently flexible to be manipulated into something that feels more like a notation for music. Additionally, the language had to be something that a teacher would by happy to use and at the time (and still) the majority of education work was in Scratch and Python. It was easy to make the case that Ruby is sufficiently similar to Python to make it simple and intuitive to learn and have a large amount of cross-pollination when moving between the two languages.
I hadn’t done anything with Ruby before Sonic-Pi, too. But it’s actually a pretty nice and comfortable language and can therefor help a lot in doing something as Sonic-Pi does. I think this choice is actually a pretty good one. Creating a nice and comfortable programming language which is sanely defined in all needed areas without side effects and be able to run on all different kinds of architectures and systems is a really daunting task. So using something existing is the best choice in most cases especially if you don’t have a huge amount of time at hand. Ruby is maybe not the best choice if performance and realtime ability comes in mind, but most of these cases are more critical in the SuperCollider domain. So, this is not such a big deal in most cases. But the strong parts of Ruby (a lot of syntactic sugar, easy to learn and use) really shine in Sonic-Pi and make it very accessible. So all in all, I actually like the choice of Sam even though I didn’t do anything with Ruby before. A similar approach could be Python which has similar strong and weak points. If you focus more on performance and realtime than languages like Eiffel or (with a huge amount more work) C/C++ come into mind, but I think with these choices a lot of the nice accessibility of Sonic-Pi will go away.
So to sum it up, Ruby is a really good choice not just for Sam
Interesting. I’ve been reading up on Ruby wiki says under ‘philiosphy’ by the author…
“I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language.”
Nothing to disagree with there!
I’m from a Unix background originally and have used lots of interpreted scripting languages - you know, shell scripts, PERL, php…all those. Then VBScript on Windows (yuch), now PowerShell hmm. I had look at Python when everyone started going on about that. Over the years I’ve lost my mojo for chalking up another language for fun…but maybe I should revisit that
I do dig software that started out (or are still) basically one-person projects but are being used worldwide. I think that’s great.
BTW I see we are getting off topic on this thread - sorry, Moderators
