Section 5.7 introduced the functions cue
and sync
when dealing with
the issue of synchronising threads. What it didn’t explain was that it
is the Time State system which provides this functionality. It just so
happens that set
is actually a variation of cue
and is built on top
of the same core functionality which is to insert information into the
Time State system. Additionally, sync
is also designed in such a way
that it works seamlessly with Time State - any information that we plan
to store in Time State we can sync on. In other words - we sync
on
events yet to be inserted into Time State.
Let’s take a quick look at how to use sync
to wait for new events to
be added to Time State:
in_thread do
sync :foo
sample :ambi_lunar_land
end
sleep 2
set :foo, 1
In this example first we create a thread which waits for a :foo
event
to be added to the Time State. After this thread declaration we sleep
for 2 beats and then set
:foo
to be 1
. This then releases the
sync
which then moves to the next line which is to trigger the
:ambi_lunar_land
sample.
Note that sync
always waits for future events and that it will block
the current thread waiting for a new event. Also, it will inherit the
logical time of the thread which triggered it via set
or cue
so it
may also be used to sync time.
In the example above we set :foo
to 1
which we did nothing with. We
can actually get this value from the thread calling sync
:
in_thread do
amp = sync :foo
sample :ambi_lunar_land, amp: amp
end
sleep 2
set :foo, 0.5
Note that values that are passed through set
and cue
must be thread
safe - i.e. immutable rings, numbers, symbols or frozen strings. Sonic
Pi will throw an error if the value you are attempting to store in the
Time State is not valid.