Low performance on new PC

I have tried re-installing a completely clean Windows 10 Home, and the issue persists on both 3.2.2 and 3.1 (both installs and portable apps). I tried installing the runtime, and that didn’t help. Seeing as windows was syncing and updating in the background, I tried putting the system in Airplane Mode, which didn’t help either.

I tried to limit the number of active cores on my CPU, since that might be a thing. Nope. Tried running it in compatibility mode, didn’t do anything. Running as administrator changes nothing. Moving the portable install to a slower hard drive didn’t do anything (really grasping at straws here).

I have no idea where to go from here.

Perhaps you could try building the latest release yourself?

I’ve tried to build the latest release, and the issue persists. I tested Supercollider running on its own (figured that if supercollider gets messy, so does SP). Supercollider works as it should.

I installed Ubuntu Studio 20.04 64-bit on my desktop this weekend, and sonic pi version 3.2.2 works like a charm. This would indicate that the problem is related to windows and not the hardware, since Supercollider doesn’t show any signs of trouble (at least the newest version)

2 Likes

Alright, I’ve learned something new (which is why I’m resurrecting this 7-month-old thread).

I’m running 3.3.1 now. Same computer. This piece of code makes my machine choke within seconds.

use_bpm 120   

 live_loop :main do
  with_fx :reverb do
    64.times do
      tick
      
      synth :tb303, note: :c1, cutoff: 70, release: 0.125, res: 0.9
      
      synth :tb303, note: :c1, cutoff: 70, release: 0.125, res: 0.9
      synth :tb303, note: :c1, cutoff: 70, release: 0.125, res: 0.9
      synth :tb303, note: :c1, cutoff: 70, release: 0.125, res: 0.9
      
      synth :dsaw, note: :c1, sustain: 16, cutoff: 60 if (spread 1,64).look
      
      sleep 0.25
    end
  end
end

However! if I run this code instead, I can start up the loop just fine. What’s more I can run as many of these loops as I want (I stopped trying more at 15 loops, which should have choked it).

live_loop :main do
  with_fx :reverb do
64.times do
  tick
  
  synth :tb303, note: :c1, cutoff: 70, release: 0.125, res: 0.9
  
  synth :tb303, note: :c1, cutoff: 70, release: 0.125, res: 0.9
  
  
  synth :dsaw, note: :c1, sustain: 16, cutoff: 60 if (spread 1,64).look
  
  sleep 0.25
end
  end
end

I don’t know if this brings anyone closer to the truth, but I’m shooting it out there in a vague hope that It might help solve the mystery. My layman’s guess is that it’s somehow related to how my CPU handles threading. I’m not giving up yet.

Default bpm for SP is (I beleive) 60 bpm.

In the first example you are doubling the bpm, which means
you are halving the sleep time of the loop…

It’s probably enough, to put your CPU usage through the roof…

Try putting the reverb -outside- the loop, so you aren’t spawning
a new reverb faster than the old reverb(s) expire.

Well… something like that.

Eli…

1 Like

It really is weird and counter-intuitive that both these behave so differently.

This is definitely a useful real-case scenario that I’d like to return to as I work on the internals making things progressively more efficient.

To my mind, neither of these should be problematic on any hardware more recent than the Pi2.

Ok here’s an interesting tidbit. For me, the original code starts slowing right away and stops after ~6s.

Testing with use_sched_ahead_time 1 it worked fine. So, I wanted to see how low it could go and still run fine. Turns out it works fine with use_sched_ahead_time 0.

Just to be clear, the following code ran for over a minute without issues.

use_sched_ahead_time 0
use_bpm 120
live_loop :main do
  64.times do
    tick
    
    synth :tb303, cutoff: 60, release: 0.125, note: (chord :c3, :minor).choose
    sample :bd_tek if (spread 1,4).look
    sample :bd_zome if (spread 3,16).look or (spread 7,16).look
    synth :beep, note: (chord :c6, :minor).look, release: 0.125, amp: 0.2
    sample :elec_tick
    
    sleep 0.25
  end
end

The thing is though, on my substantially weaker laptop the code runs pretty smooth. I’m also running 120 bpm in the other example, I just forgot to include that line.

Well heck me sideways, it worked on my end too. It completely eliminated the issues if I added use_sched_ahead-time 0. I have absolutely no idea why it would work. I guess I’ll just include it from now on as a “do not turn this button off” thing.

I blame machine elves until another explanation surfaces.

2 Likes

How very interesting!

I’ve blown the dust off Sonic Pi recently and tried v3.3.1 and can confirm that v3.2.2 performs much better. Some of my old tracks get into timing problems within about 15 seconds on 3.3.1 - Same laptop.

The samples vary in length between 1 - 11s, doesn’t seem to make a difference though.

My assumption is that the ixi_techno effect in the spin loop is taking up too much resource.

Code example:

# Sonic Pi v3.2.2 (Win 10)

# Settings
use_bpm 85
bar_length = 4
use_random_seed 20210712
swing = (ring 0.01, -0.01)
sample_root = "/Samples/"
sample_folder = "/OtherSamples/"

# Scale
mode = :minor
scl = scale(:e1, mode, num_octaves: 4)

# Functions
define :get_pitch_from_note do |note, sample_base_note, fine_tune|
  return note - sample_base_note + fine_tune
end
define :bar do |length = 8|
  sleep bar_length * length
end

# Loops
define :bass do |length = 8, pattern = 1|
  in_thread do
    s = sample_root + "twobass.wav"
    notes = (ring 7,8,6,5)
    
    ((bar_length * length)).times do ; tick
      sample s, rpitch: get_pitch_from_note(scl[notes.tick(:n)], 40, 0),
        amp: rrand(2, 2.2) if pattern == 1 and bools(1,0,1,0).look
      
      with_synth :square do
        play scl[notes.look(:n)],
          amp: 0.2,
          attack: 0,
          sustain: 1,
          release: 0
      end
      
      sleep 1 + swing.look
    end
  end
end

define :spin do |length = 8, pattern = 1|
  in_thread do
    s = sample_root + "spin.wav"
    idx = get[:lead_counter]
    
    ((bar_length * length * 4)).times do ; tick
      with_fx :ixi_techno, phase: (line 8, 1, steps: 128, inclusive: true).mirror[idx] do
        sample s, slice: look, amp: rrand(2, 2.2)
      end
      
      sleep 0.25 + swing.look
      set :lead_counter, idx += 1
    end
  end
end

define :fart_moves do |length = 8, pattern = 1|
  in_thread do
    s = sample_root + "fart_moves.wav"
    slices = (line 4, 7, steps: 4, inclusive: true).mirror
    
    with_fx :eq, low_note: 42, low: -1 do
      ((bar_length * length * 4)).times do ; tick
        sample s, slice: slices.look, num_slices: 32, amp: rrand(1.8, 2.1)
        
        sleep 0.25 + swing.look
      end
    end
  end
end

define :breakbeat do |length = 8, pattern = 1|
  in_thread do
    s = sample_folder + "Urban Technologies/STRANGER BREAKS/UT_011_STRNGR BRK_95_A#.wav" #UT_008_STRNGR BRK_90_E.wav"
    slices = (line 0, 15, steps: 16, inclusive: true) if pattern == 1
    slices = (line 0, 7, steps: 8, inclusive: true) if pattern == 2
    slices = (line 0, 15, steps: 16, inclusive: true).shuffle if pattern == 3
    sample_rate = 1
    sample_rate = 0.5 if pattern == 3
    
    ((bar_length * length) * 4).times do ; tick
      beat_stretch = 8 #[16,16,16,17].choose
      
      sample s, slice: slices.look, amp: rrand(0.9, 1.2),
        ##rate: sample_rate, beat_stretch: beat_stretch,
        rpitch: 0.02, pan: 1
      
      sample s, slice: slices.look, num_slices: 16, amp: rrand(0.9, 1.2),
        #rate: sample_rate, beat_stretch: beat_stretch,
        rpitch: -0.02, pan: -1
      
      sleep 0.25 + swing.look
    end
  end
end

live_loop :metro do
  stop
  play :c5, amp: 0.2
  sleep 1
end


# Reset globals
set :lead_counter, 0

# Structure
#spin ; bar
#breakbeat(8,1) ; bar
#breakbeat(8,1) ; spin ; bar
#breakbeat(8,3) ; fart_moves ; bar
bass ; breakbeat(8,1) ; fart_moves ; spin ; bar

Yeah wanted to play with some sonic pi tonight and found out all my scripts don’t work anymore.

Never had any problems until recently.

Not sure what’s going on or why sonic pi freezes up anymore.