TempoClock timing figure (and Pfindur)

Questions
1

Hi, I was just looking up some of the ways of working with Ptpar and Pfindur and came across an example in the Practical Guide Cookbook which is very interesting. However, I have one question concerning the value used for the TempoClock which is 0.35953685899971, and then used later in a Pbind key as \time, 0.35953685899971.reciprocal. In the TempoClock it’s multiplied by 4 which I understand gives the beat of ‘4’. But why such a precise number? I looked through the code (which involves synching a sample), but can’t see why this very precise figure. Can someone explain how that number comes up (and again as mentioned in the Pbind)?

Since the example is quite long, and already in the SC help pages, I haven’t printed it out, however, here’s the online link:

http://doc.sccode.org/Tutorials/A-Practical-Guide/PG_Cookbook05_Using_Samples.html

Thanks in advance - joesh

p.s. I can post the whole code if people think it would be a good idea!

2

Identical question here and on the mailing list. I’m not sure where you want the answer. I guess I’ll put it here because of better searchability.

OK… the title of that example is “Playing a pattern in time with a sampled loop.” So, one might suppose that timing values will be related to the timing of the sample being used.

Time (seconds/beat) and tempo (beats/second) are in an inverse relationship, so timing in the sample should be related to 1 / 0.35953685899971 = 2.781356.

Also note in the \oneLoop Pbind, we are starting at frame index 17841. 17841 samples / 44100 samp/sec = 0.404558 sec.

So, if you open a11wlk01.wav in your trusty Audacity, and make a selection starting at 0.404 sec extending forward 2.781 sec, this will be the portion of the file being looped.

The start time and duration are chosen to make musical sense. But the duration makes musical sense only if the meter evenly divides it. So the example chooses a tempo related to the duration, fitting four beats within the loop. It must be exactly this tempo, or the four beats will divide a duration that is not musically sensible.

If you want to play at a different tempo, you could change the playback rate (not currently in the \oneLoop synth, but it’s easy to add). But then you should scale the desired tempo against the loop’s original tempo, and you still have to have the “magic number.”

hjh

1 Like
3

Thanks James for your answer (and sorry for posting twice).

I understood most of your explanation, and had already understood the use of the various figures within the Pbind. However, the figure that I want to know/understand where it comes from is the figure 0.35953685899971. I’m clearly missing something in your answer, but why “timing in the sample should be related to 1 / 0.35953685899971”? Why not 1/ 0.12345678910?

Sorry if my maths isn’t up to scratch or I’ve misread something, but I don’t see where this precise figure comes from.

Thanks in advance - joesh

4

Did you open up a11wlk01.wav in a sample editor and highlight/play back the portion I described?

The tempo is chosen to match a specific segment of the audio source file. If you aren’t looking at the audio source file, then the tempo will appear to be an arbitrary choice. But it isn’t. It is very specific, to this audio file. If you use a different audio file, you would need different numbers.

If the tempo is 0.1234567891 * 4, then one bar would span 8.1 seconds. There aren’t 8.1 seconds in the source file, so you would get silence for part of the bar.

hjh

5

Okay, I finally see how the calculation 1 / 0.35953685899971 = 2.781356 is determined, many many thanks. So, as I now see:

1 / 2.781356 = 0.35953685899971

Indeed I did open up Audacity and loaded and selected the file. So, one last thing which I need to understand is why use the 2.781 - which I understand is the end of our looped section/choice. The reason I ask this is, if I take the portion 0.404 secs - 2.781 secs, then according to Audacity I have a 2.377 seconds of sample selected. Does this mean that one should use 1 / 2.376 = 0.42087542087542, or more than likely I a) have the wrong figure, b) just didn’t look properly.

Once more, big thanks … it’s getting clearer.

joesh

6

Beginning = 0.404
Ending = 0.404 + 2.781

hjh

1 Like
7

Brilliant, just trying out my own version here.

Thanks again, glad I finally got there.

joesh

8

I think I will make this more explicit in the help file. The explanation skips too many steps.

hjh

9

Indeed, it could be a bit more clear. The main thing - IMHO - that needs to be explained is the connection (as you’ve been explaining) between the figures and the tempo/time.

If I’ve understood correctly:

a = 0.404 the chosen starting point in the sample
b = 2.781 the end point of the sample
c = the amount of time between a and b

The calculation:
1/c = 1/4 of the sample portion chosen

In the example:
TempoClock.default.tempo = c * 4;

It might be useful to explain the \time key. The use of .reciprocal surely gives us the end point value. Meaning in this case, why not just use 2.781?

The only bit which isn’t clear in your explanations above, is the last bit where you say:

Beginning = 0.404
Ending = 0.404 + 2.781

If we look again at the calculations, and use the endpoint of the sample 2.781, we indeed get 1 / 2.781 = 0.3595(etc). However, if we put the sample into Audacity, and select ‘length’ of the sample, we get 2.377 This means we get a different figure, 1 / 2.377 = 0.4206(etc)?

This (for me) needs to be clarified, as I took your comment above to mean the amount of time between 0.404 and 2.781.

joesh

p.s. Don’t pull your hair out if I still haven’t got it correct.

10

b = 2.781 is the duration of the portion to be played. It isn’t the endpoint of the sample. I’m not quite sure where the idea got stubbornly stuck in your head that 2.781 is the endpoint (in fact, the help file gives the endpoint as 3.185917 in the first paragraph).

Pretty much all of your confusion derives from this.

When I wrote this help file originally, I took too many shortcuts in the logic. So, basically, forget the entire discussion in the help file and let’s start completely over from the beginning. 0.3595368 – forget it – even though it’s a valid number, we can arrive at the destination by a clearer path.

So, from the beginning:

We want to play a portion beginning at 0.404561 and ending at 3.185917. Why do we want to play this portion and not some other portion? Because it makes musical sense. There’s nothing special about these numbers – you choose them carefully to get the rhythm you want.

The duration of this section is end - start = 3.185917 - 0.404561 = 2.781356 seconds.

We want to use this section for a complete bar of 4/4 time. Therefore the 2.78xx seconds = 4 beats. Therefore 1 beat = 2.78xx seconds / 4 beats = 0.695339 seconds/beat.

TempoClock expects tempo to be expressed as beats/second. We have seconds/beat. So we need to take the reciprocal. 1 / 0.695339 = 1.438147. (At this point, you might note that 0.3595368 * 4 = 1.438147 – like I said, we end up at the same place, but maybe this route is clearer. 0.359xx is actually 1 / 2.78xx, i.e., 1 / duration.)

The above gets us to:

1 / ((end - start) / beats)

Using a bit of algebraic reduction:

(1 / (end - start)) * beats <<-- (this is 0.35953685899971 * 4)

beats / (end - start)

4 / 2.78xx = 1.438xx

It might be useful to explain the \time key.

It’s a little clearer in the rewrite (maybe).

Step A: You want the loop segment to span the entire bar – i.e. 4 beats. We can get 4 beats from the dur key.

Step B: The server operates in seconds, not beats. So we have to convert by dividing by the tempo.

\time, Pkey(\dur) / Pfunc { thisThread.clock.tempo },

Admittedly I didn’t explain that in the text, but at least there are no more magic numbers in that part and it’s possible to reason it through: beats divided by beats/sec = beats * secs/beat, beats cancel out leaving seconds.

hjh

11

James, I’m so sorry I hadn’t seen in the help file, or probably skipped over, that the end point was 3.185917 - the old dyslexia reflex where one scans, rather than reads details carefully. So, indeed you’re right, I’d got it into my head that 2.781 was the endpoint, and hadn’t realised that in fact it was the length. Once that becomes clear everything else drops into place. I think you can now see why I couldn’t get the various numbers to make sense due to this (stupid) misunderstanding.

A very big thank you for persevering with the explanation, which now becomes crystal clear.

joesh