Hello list,
I'm creating long tables (+20m, @22.05KHz, Pd 32b windows), where I read a
short voice sample from another table and copy them into different places
in the long table. Since that's running outside of the audio chain, I'm
using [tabread]+[tabwrite]. The idea is to generate an audio file from a
list of events without having to "bounce" the playback.
I notice that the further away the samples are copied to, the worse the
audio quality gets. There is an onset parameter for [tabread4~] to help in
these cases, but not any for [tabwrite]. Do you advise any solutions to
this? I could split the long buffer in several buffers, but at some point
it would have to be put together. Or maybe a clever use of [block~] to
make a subpatch that would go very fast through the table?
Since this patch uses extended objects, I can't use Pd64b. I would prefer
to use vanilla objects for this module, if possible.
Best,
Joao
Since this patch uses extended objects, I can't use Pd64b.
64-bit is only about pointer size, *not* about double precision.
the problem with using floats for large array indices is that after a certain size you gradually loose precision in the lower bits. in your case you could use [array set] and [array get] to read/write several samples at once. this way you don't have to give precise indices for every sample but only an onset plus a size. the onset value will not be precise (a few samples off depending on the size) but the actual samples will be written consecutively and thus won't degrade in quality.
Christof
Gesendet: Sonntag, 02. Dezember 2018 um 14:22 Uhr Von: "João Pais" jmmmpais@gmail.com An: PD-List pd-list@lists.iem.at Betreff: [PD] tabwrite onset
Hello list,
I'm creating long tables (+20m, @22.05KHz, Pd 32b windows), where I read a
short voice sample from another table and copy them into different places
in the long table. Since that's running outside of the audio chain, I'm
using [tabread]+[tabwrite]. The idea is to generate an audio file from a
list of events without having to "bounce" the playback.I notice that the further away the samples are copied to, the worse the
audio quality gets. There is an onset parameter for [tabread4~] to help in
these cases, but not any for [tabwrite]. Do you advise any solutions to
this? I could split the long buffer in several buffers, but at some point
it would have to be put together. Or maybe a clever use of [block~] to
make a subpatch that would go very fast through the table?Since this patch uses extended objects, I can't use Pd64b. I would prefer
to use vanilla objects for this module, if possible.Best,
Joao
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
if you need to be really sample accurate, checkout https://git.iem.at/pd/iem_dp. it provides several table objects with an additional onset inlet.
Gesendet: Sonntag, 02. Dezember 2018 um 15:00 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "João Pais" jmmmpais@gmail.com Cc: PD-List pd-list@lists.iem.at Betreff: Re: [PD] tabwrite onset
Since this patch uses extended objects, I can't use Pd64b.
64-bit is only about pointer size, *not* about double precision.
the problem with using floats for large array indices is that after a certain size you gradually loose precision in the lower bits. in your case you could use [array set] and [array get] to read/write several samples at once. this way you don't have to give precise indices for every sample but only an onset plus a size. the onset value will not be precise (a few samples off depending on the size) but the actual samples will be written consecutively and thus won't degrade in quality.
Christof
Gesendet: Sonntag, 02. Dezember 2018 um 14:22 Uhr Von: "João Pais" jmmmpais@gmail.com An: PD-List pd-list@lists.iem.at Betreff: [PD] tabwrite onset
Hello list,
I'm creating long tables (+20m, @22.05KHz, Pd 32b windows), where I read a
short voice sample from another table and copy them into different places
in the long table. Since that's running outside of the audio chain, I'm
using [tabread]+[tabwrite]. The idea is to generate an audio file from a
list of events without having to "bounce" the playback.I notice that the further away the samples are copied to, the worse the
audio quality gets. There is an onset parameter for [tabread4~] to help in
these cases, but not any for [tabwrite]. Do you advise any solutions to
this? I could split the long buffer in several buffers, but at some point
it would have to be put together. Or maybe a clever use of [block~] to
make a subpatch that would go very fast through the table?Since this patch uses extended objects, I can't use Pd64b. I would prefer
to use vanilla objects for this module, if possible.Best,
Joao
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/2/18 3:00 PM, Christof Ressi wrote:
Since this patch uses extended objects, I can't use Pd64b.
64-bit is only about pointer size, *not* about double precision.
the problem with using floats
btw, this is a general problem of floating point numbers, affecting *both* single precision (aka "float") and double precision. however, with double-precision this usually affects only numbers that are so incredibly large, that your head explodes first.
gadsr IOhannes
Hi João,
if you need to be sample precise and use pd vanilla, I'd recommend to define custom tabread~/tabwrite~ abstractions using multiple arrays for access (similar to an old memory mapping technique called "paging").
You'd have to define a custom number format using a list of two numbers in the range [0..2^24] to specify a precise sample offset. In addition you'd need a custom tabread~ and tabwrite~ abstraction, abstracting the paging so they can be used the same way as the builtin objects (albeit with the sample idx being the two number lists). As tabwrite~ accepts a table offset you'd have the same functionality as the builtin objects.
I did this some years ago and it worked pretty well. The only disadvantage is that saving such a multi-array buffer will result in multiple files, but this probably is of minor concern as you can combine them into a single buffer when this is needed in an external app.
-- Orm
Am Sonntag, den 02. Dezember 2018 um 14:22:35 Uhr (+0100) schrieb João Pais:
Hello list,
I'm creating long tables (+20m, @22.05KHz, Pd 32b windows), where I read a short voice sample from another table and copy them into different places in the long table. Since that's running outside of the audio chain, I'm using [tabread]+[tabwrite]. The idea is to generate an audio file from a list of events without having to "bounce" the playback.
I notice that the further away the samples are copied to, the worse the audio quality gets. There is an onset parameter for [tabread4~] to help in these cases, but not any for [tabwrite]. Do you advise any solutions to this? I could split the long buffer in several buffers, but at some point it would have to be put together. Or maybe a clever use of [block~] to make a subpatch that would go very fast through the table?
Since this patch uses extended objects, I can't use Pd64b. I would prefer to use vanilla objects for this module, if possible.
Best,
Joao
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/2/18 2:22 PM, João Pais wrote:
I'm creating long tables (+20m, @22.05KHz, Pd 32b windows), where I read a short voice sample from another table and copy them into different places in the long table. Since that's running outside of the audio chain, I'm using [tabread]+[tabwrite]. The idea is to generate an audio file from a list of events without having to "bounce" the playback.
two vanilla options that come to my mind:
#1 use [array get] to get the contents of the array your are interested in, and dump that into a table (either using [array set] or an old-school [list prepend 0]->[send <tablename>]
#2 use [tabread4~] in a [switch~]ed-off subpatch and bang the [switch~] to do on-demand "signal-processing" (in your case: table-access with [tabplay~] and [tabwrite~])
personally, i'd go for the former.
fgdsa IOhannes
I'm creating long tables (+20m, @22.05KHz, Pd 32b windows), where I read a short voice sample from another table and copy them into different places in the long table. Since that's running outside of the audio chain, I'm using [tabread]+[tabwrite]. The idea is to generate an audio file from a list of events without having to "bounce" the playback.
two vanilla options that come to my mind:
#1 use [array get] to get the contents of the array your are interested in, and dump that into a table (either using [array set] or an old-school [list prepend 0]->[send <tablename>]
Thanks everyone for the suggestions. I ended up using get+set, as it's
important to click once and have a wav file ready, with no extra steps.
One problem is that some samples overlap, so I had to use different tables
and [iem_tab/tab_sum] to mix them. Maybe with more time I'll be able to
have a look at another solution.
#2 use [tabread4~] in a [switch~]ed-off subpatch and bang the [switch~] to do on-demand "signal-processing" (in your case: table-access with [tabplay~] and [tabwrite~])
That could be interesting, but I'll have to experiment a bit more, I'm not
sure I get the principle.
Best,
Joao
-
Christof Ressi -
IOhannes m zmölnig -
João Pais -
Orm Finnendahl