Hi Jonathan. Thank you for the reply. I still have a question about something you wrote, with my original question reproduced below:

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

​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

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:
>
> 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@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
>