Sonic Pi file won't run with too many lines

Support, Help & Resources
#1

Running Sonic Pi on Windows 7.
Everything is working fine until I try to run a file with too many lines. I click “run” and nothing appears in the “Log” section (292 lines total). I then delete only commented lines, click “run” and it goes normally (209 lines total).
No clue what would cause this. The numbers of lines where it works or doesn’t work is not consistent. I’ve tried changing between # comments and =begin … =end comments, similar results.

Anyone else have this problem? Any suggestions?
Thanks

#2

Hello @ybsonify,

I’m not sure exactly what’s going on. There is a limit to the amount of code per buffer that will run, but usually there is an error message that pops up when this occurs. It seems that a few people have noticed situations where this error fails to appear; it’s probably something that we will want to look into.

#3

Hi @ethancrawford ,

Thanks for the reply!
Is there any way around this? Perhaps defining all my variables and parameters in another file and importing them? I don’t have a ton of experience with Sonic Pi/Ruby, so I don’t know for sure if this is possible.

#4

You can define and press run to evaluate functions in a separate buffer, and then the rest of your composition can refer to them - that’s one way. Alternatively you can run external files with the run_file command.

#5

Hi @ybsonify,

Welcome! Foreword: I’ve been using Sonic Pi for a month and a half. I primarily work on Windows 10.

I first crossed the threshold over a month ago. I think I hit it at around 500 lines. I too got no error message, no log upon running, nothing. I found the solution on this forum or on GitHub (I can’t find the topic at the moment), which solution is what @ethancrawford has suggested.

To illustrate the run_file way, with my 1700-line program:

image
image1821×67 8.64 KB

Note the *NIX-style file path, with forward slashes (/) rather than backslashes (\).

Eventually, you might also hit the limit on the number of lines and characters that you can enter into a single buffer. By then, I think you’ll be familiar enough with the API that you could consider switching to an IDE/text editor of your choice (I use Atom at the moment).

Hitting the buffer limit is to me something like a rite of passage haha :slight_smile: So welcome again, and happy coding!

#6

!!!

Just shows what a versatile toolkit is SPi. I was inspired by watching Sam’s live coding set, where he seemed to have just one buffer, and a bit over a screen’s worth of code going on

1 Like
#7

:’) i’m making every effort to add no more settings than there are variables, but the complexity of the generative algorithm reminds me of one of my favourite interviews ever with a composer i’ve mentioned before, caterina barbieri:

… the design of the Buchla is pretty esoteric but I never felt the need to read a manual. I just found a way to make it create sound. And there’s no right or wrong way to do it – there’s no ‘obliged’ creative path, so to say. But today it seems that the focus of music industry is very much on the simplification of music interfaces, to make the creative process faster and accessible, at least in the digital world. But I think that this approach to technology is problematic and misleading, because the creative process needs limits to overcome and esoteric interfaces to explore. In my experience, music always comes out of a process of negotiation between the design of the technology and the human imagination, rather than a simple imposition of an idea upon passive matter.

2 Likes
#8

Good point. Instrumental music has always been about man vs technology, long before electronics.

I write software for a living, and ages ago identified what I have called The Holtom Effect (he was a work colleague) where you write some app with a purpose in mind, and there’s always someone who takes it and runs away with it, pushing at every bit of the envelope.

Sounds like, with Spi, that’s you that is :smile: (that’s a good thing btw)

2 Likes
#9

@d0lfyn thanks for the tips!

I had been writing mostly in VSCode and loading the file into SPi, run_file seems to be a much better way to do that!

2 Likes
#10

My pleasure! VSCode isn’t too different from Atom, from what I recall. What I really would like is an IDE with sophisticated code completion. Giving the RubyMine EAP another go.

#11

The Holtom Effect, eh. That makes development more interesting. I hope I’ll get to witness user creativity in my career!

1 Like