Hi Jonathan. Thank you for the reply. I still have a question about something you wrote, with my original question reproduced below:
- 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
You wrote : "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."
What I meant to ask is whether or not [phasor~], [line~], and [vline~] behave the same in terms of outputting sequential values regardless of the "speed" they are "driven at".
From what I understand now, if you "drive" [line~] at the speed of the
sample rate, the output should be a steady stream of numbers that increase by 1 from number to number. However, if you try to "drive" [line~] at a speed that is faster or slower than the sample rate, you'll get dropped samples or duplicated samples, respectively. So in this example:
[0, 40999 1000( <--jump to 0, then read from 0-40999 in 1000 ms | [line~] | [tabread4~ array1] <--where array1 is a size of 41000
- If we were to print the output of the first ten
numbers of [line~] , it should look like this: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 .
- If we change the time in the message box to 2000, does the output of
line become 0, 0, 1, 1, 2, 2, 3, 3, 4, because we are now taking twice as long to read through the table?
- If we change the time in the message box to 500, does the output of
the [line~] become 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, because now [line~] has to skip samples in order to reach the end goal of 40999 in time?
I did some tests using the patch I outlined above using [print~] and these stipulations seems to hold true. So now I am curious about what [tabread4~] does. For the second scenario I outlined (2000ms time), does [tabread4~] change 0, 0, 1, 1, 2, 2, 3, 3, 4, 4... into 0, 0.5, 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5...? Or in the third scenario (500ms time), does [tabread4~] change, 0, 2, 4, 6, 8, 10... into 0, 1, 2, 3, 4, 5, 6...?
On Sun, Mar 22, 2015 at 10:43 AM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
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:
- 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.
- 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.
- 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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list