I’m figuring out how to stop a generative piece of music when a case is being switched.
so case a[0]
when 1
something
when 2
n = (ring :a7, :d3, :f1, :d3, :f2)
live_loop :electric do
if rand(1) > 0.75
n = (ring :a2, :d3, :r, :f3, :d3, :r, :f2)
else
n=n.shuffle
end
use_synth :pluck
use_synth_defaults attack: 0.04, sustain: 0.8, decay: 0.4, release: 0.4, amp: 1, note_slide: 0.25
use_transpose +4
with_fx :distortion do
with_fx :nrlpf, centre: 70 do
60.times do
play n.look, cutoff: 77, res: 0.3
sleep 0.29
tick
end
end
end
end
when 3
something else
I know the sound is endless thus the case doesn’t tell it to stop. A typical case when
in this example lasts for about three days…
So how can I make stop give or take around three days so it doesn’t interferes to much with the next case when
.
Hi @dewildequinten,
If your goal here is to have different live_loops where one at a time plays continuously until some kind of external event occurs to switch to a different live_loop, this is a good case :badum-tish: for get
and set
, as seen in Chapter 10.1 of the tutorial: Sonic Pi - Tutorial. One idea here might be to have a variable set in Time-State that tracks the current active loop, and each live_loop knows to stop itself if it is not the right one. Something perhaps like the following:
when 1
set(:active_loop, :blah)
...
when 2
set(:active_loop, :electric)
live_loop :electric do
stop unless get(:active_loop) == :electric
...
You could also separate the sound generating live_loops from the conditional statements: have a live_loop dedicated to just receiving the external event, and setting the variable in Time-State, and then the other live_loops below it, separate, that read the variable from Time-State and act on it.
Having said all that, it also depends on a few other things - like whether you want to make sure the sound in each non-active live_loop stops as soon as the new when
condition is triggered, or whether you’re happy for the loop you’re turning off to finish the last of its current cycle; whether you’re comfortable using either something like an external script or program to trigger an automated keyboard shortcut or a currently unsupported internal Sonic Pi command to tell Sonic Pi to start a new ‘Run’. (Since from what you’ve said about a sound choice lasting for up to three days, this might be a semi-automated sound installation of some kind? it’s always helpful to know a bit more about your project - that way we can suggest ideas that are appropriate to your situation
)
2 Likes
I’m thinking a good option might be a live loop that runs functions depending on the case.
define :something do
#thing
end
define :something_else do
#other thing
end
live_loop :controller do
case get(:case)
when 1
something
when 2
something_else
end
end
Then you can set the case using the Time State as Ethan has done.
1 Like
Yes, I would agree that having a single loop that just makes different sounds depending on conditions is probably the much easier route to go down here.
(Though the above single loop example as is would need to run the whole of whichever conditional sound function was selected before it could choose to run a different one. If you needed to be able to trigger a different sound function at any arbitrary point in time, then a multi-loop/multi-thread solution is more flexible).
I had the idea of doing it with level controls. But there’s a little overlap, which ends up being ugly. Also comes with the problem that with a very tight level control loop the thread falls too far behind. I’ll leave the code here in case you can make something better of it.
set :case, 1
with_fx :level do |lev|
set :one_level, lev
live_loop :one do
stop unless get(:case) == 1
sample :loop_amen, beat_stretch: 4
sleep 4
end
end
with_fx :level do |lev|
set :two_level, lev
live_loop :two do
stop unless get(:case) == 2
sample :loop_breakbeat, beat_stretch: 4
sleep 4
end
end
live_loop :controller do
case get(:case)
when 0
control get(:one_level), amp:0
control get(:two_level), amp:0
when 1
control get(:one_level), amp:1
control get(:two_level), amp:0
when 2
control get(:one_level), amp:0
control get(:two_level), amp:1
end
sleep 0.25
end
If a quicker response is needed then I have a couple of other ideas, in addition to Ethan’s external script idea:
- Keep track of the running synth and use synth control
- Have the stop check more frequently
...
60.times do
stop unless get(:active_loop) == :electric
play n.look, cutoff: 77, res: 0.3
sleep 0.29
tick
end
...
Hi Ethan,
Well I’m getting data from ESP8266 and putting them in to sonic pi on a RPI
(I have lots of questions for this too but that’s not for know (timing errors appear))
So for the moment I’m using my macbook to get the data in.
I’m using this code Extensive OSC tutorial - #24 by robin.newman
To alter the autonomous generating sound over the cases.
So
case a [0]
when 0
make a 3 day generative audio work and let the osc data alter the frequencies, delays or anything that makes the sound interesting and especially shows that the data is is changing the music. (I’m have not completely figured out how to do this perfectly so far)
vibe: industrial, CAN-like, Harmonia-like, but starting of as a simple droney soundscape.
when 3
from day three the sound would get a new form that is also being altered by the same osc data that’s coming in. But the sound is now getting “mature” and becoming more though still generative like more musically like.
when 6
etc…
when 24
the sound is somewhat dying or becoming very monotonous .
when 30
music stops
This is about all I can say about the project
I’ve been working at it for months now and this is al because my music skills coding is not good enough hard to combine with other projects. But i’m slowly getting there! 
And that’s offcourse all because of the wonderful help this thriving forum gives me!!