[PD] For sample players based on [line~], [vline~], or [phasor~], how can we be sure all samples are being played?

Jonathan Wilkes jancsika at yahoo.com
Sun Mar 22 18:43:45 CET 2015


On 03/20/2015 12:57 PM, Reed Perkins wrote:
> Hello all,
>
> [line~], [vline~], and [phasor~] are used to generate line ramps in 
> basic sample-playback patches. The output of these objects is usually 
> multiplied by the total number of samples in a sound file (that has 
> already been loaded into an array or table) and fed into the input of 
> something like [tabread4~]. In other words, we use these line-ramp 
> objects to traverse the indices of a table where a sample is loaded at 
> a given speed.
>
> My questions are these:
>
> 1. Do these line-ramps generate enough numbers such that every sample 
> in a table will be read?

No.  (And I assume you are wanting the values of the table to be output 
one after the other, in sequence, when you output them as a signal.)

The determining factors for how table values are output: a) ramp 
duration (in time units), b) ramp height (end value - start value), c) 
the sample rate, and d) whether the object doing the reading is 
interpolating the index values.

The sample rate in Pd is fixed, so you are only guaranteed to read every 
table value when the ratio of ramp height/duration matches the sample 
rate ratio.  If you wanted something like [line~] and [tabread~] to 
guarantee that every sample of the table is read/output/whatever, you'd 
need a system in which the sample rate changes based on the size of the 
array being read.

>
> 2. Does it matter if, say for example, [tabread4~] receives a decimal 
> number for an index, like 333987.8, which can be caused by multiplying 
> the output of [phasor~] (which goes from 0-1) by the total amount of 
> samples (usually a much larger number).

Yes, because [tabread4~] does interpolation.  The [tabread~] object does 
no interpolation so the number after the decimal point in your index 
wouldn't make any difference.

For example:

[0 44099 2000(
|
[line~]
|
[tabread~ array1] <-- a table of size 44,100

This will output every value of your table twice in a row, because your 
taking twice as long to read the entire table.  However, that's probably 
not what you want, and if you listen to that results vs. [tabread4~], 
you'll hear why interpolation is a good thing in this case.

>
> 3. Does the output of [line~] and [vline~] vary due to being asked to 
> generate a ramp faster or slower? If I ask [line~] to go from 0-555987 
> in 3789 milliseconds, will the actual output be the same or different 
> if I then ask [line~] to go from 0-9876545 in 40 milliseconds

I'm not sure what you're asking.  Are you asking whether the samples 
output from 0-555987 will be the same in both cases?  If so, the answer 
is no.  The [line~] object is outputting floating point numbers in the 
range you specify, over the duration you specify, aligned to block 
boundaries.

>
> I realize this is totally theoretical, because in all honestly I 
> wouldn't be able to hear a difference if samples are being skipped, 
> but I want to know :)

But you do.  If the sample rate is 44,100 samples per second, and you 
read from 0 to 44,099 in one second with [tabread~] you'll hear all the 
samples being output.  But if you read from 0 to 44,099 in _half_ of a 
second you'll be skipping every other sample.  You'll certainly perceive 
the difference as the sound recording going _twice_ as fast.

Essentially, the [tabread4~] object is for those situations where you 
know you'll be playing back at a ramp height/duration ratio that doesn't 
match the sample rate ratio.  Or where you'll often be speeding up or 
slowing down.

-Jonathan

>
> Thanks for your time.
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150322/1ed9e12b/attachment.html>


More information about the Pd-list mailing list