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 <reedperkin...@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@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 > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
