[PD] For sample players based on [line~], [vline~], or [phasor~], how can we be sure all samples are being played?
Miller Puckette
msp at ucsd.edu
Sat May 14 18:53:42 CEST 2016
I believe that vline~ output is more nearly correct than line~. It
seems appropriate to pre-increment the output as vline~ and phasor~
do. Note that the previous sample was 0, so that there is in fact a ramp
from 0 to 64 that lasts exactly 65 samples and has a slope of exactly
(sample rate).
cheers
Miller
On Sat, May 14, 2016 at 07:12:50PM +0900, Jonghyun Kim wrote:
> I tested it, if I have 64 samples and how it plays back. It's a bit strange
> to me. I was preferred to use [vline~], but it's incorrect, neither line~
> does.
>
> akntk
>
> =====
> 0, 64 1.451247
>
> vline~ outputs
> vline~:
> 1 2 3 4 5 6 7 8
> 9 10 11 12 13 14 15 16
> 17 18 19 20 21 22 23 24
> 25 26 27 28 29 30 31 32
> 33 34 35 36 37 38 39 40
> 41 42 43 44 45 46 47 48
> 49 50 51 52 53 54 55 56
> 57 58 59 60 61 62 63 64
>
> line~ outputs
> line~:
> 0 1 2 3 4 5 6 7
> 8 9 10 11 12 13 14 15
> 16 17 18 19 20 21 22 23
> 24 25 26 27 28 29 30 31
> 32 33 34 35 36 37 38 39
> 40 41 42 43 44 45 46 47
> 48 49 50 51 52 53 54 55
> 56 57 58 59 60 61 62 63
>
>
> On Fri, May 13, 2016 at 8:17 AM, Thomas Grill <gr at grrrr.org> wrote:
>
> > As a followup on that old thread:
> >
> > - I strongely advice against the use of line~ to drive tabread4~. Under
> > the hood, it works with single precision, so that the sample positions are
> > prone to round off errors pretty quickly.
> > Make the test and send the output of [line~] to [print~]. In the simplest
> > case of sending a [0, 44100 1000( message to line (and sending a bang to
> > [print~] at the same time), the output should show incremented sample
> > positions by exactly one. It is easy to see that the numbers are off
> > integers quite quickly.
> >
> > - vline~ works with double precision and doesn't show the same numeric
> > problems, but has a different issue, which i consider a severe bug.
> > Doing the same as above, the output of [vline~] starts with 1, not with 0 !
> > This can be circumvented by delaying the output of vline~ by a sample,
> > e.g. by sending [0, 44100 1000 0.0226757(, but this is certainly a bad
> > workaround.
> >
> >
> > The test patch is this:
> >
> > #N canvas 68 90 450 300 10;
> > #X obj 26 98 print~;
> > #X obj 26 16 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1;
> > #X msg 58 42 0 \, 44100 1000;
> > #X obj 58 65 line~;
> > #X text 99 66 or vline~;
> > #X connect 1 0 2 0;
> > #X connect 1 0 0 0;
> > #X connect 2 0 3 0;
> > #X connect 3 0 0 0;
> >
> >
> > --
> > Thomas Grill
> > http://grrrr.org
> >
> >
> >
> > > Am 23.03.2015 um 05:50 schrieb Reed Perkins <reedperkins32 at gmail.com>:
> > >
> > > 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
> > >
> > > • 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 at 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 at lists.iem.at mailing list
> > > > UNSUBSCRIBE and account-management ->
> > > > http://lists.puredata.info/listinfo/pd-list
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Pd-list at lists.iem.at mailing list
> > > > UNSUBSCRIBE and account-management ->
> > > > http://lists.puredata.info/listinfo/pd-list
> > > >
> > >
> > > _______________________________________________
> > > Pd-list at lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > https://lists.puredata.info/listinfo/pd-list
> >
> >
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
More information about the Pd-list
mailing list