Hi all,
Thanks for your answers. Actually I need a phase vocoder to perform an extreme time compression of the recording of a music piece (22 minutes -> 5 seconds). I want the final sound to keep as much as possible of the original recording's timbral colour and dynamics evolution. Thus I don't need to do it in realtime, but I wanted anyway to use pure data, because of the quality of Miller's implementation of the pvoc, which sounds amazingly better than any other I know, even without phase locking (I guess it's because ffts are computed on the fly, and not by interpolating between fixed frames).
Kyle, thanks for the infos about recompiling. Anyway I already looked in the sources and among others in d_soundfile.c, but only found the soundfiler's default maximum size. As I mentionned the limitation is independent from soundfiler and seems to be inherent to table.
I think I will follow Miller's suggestion to use several successive tables. Of course they should overlap on at least one block, since (correct me if I'm wrong) it may be difficult to switch from one table to another at the middle of a block.
Cheers,
Alexis
Message: 3 Date: Mon, 29 May 2006 09:45:55 -0700 From: Miller Puckette mpuckett@imusic1.ucsd.edu Subject: Re: [PD] table size limit To: Piotr Majdak piotr@majdak.com Cc: pd-list@iem.at Message-ID: 20060529164555.GA11160@imusic1.ucsd.edu Content-Type: text/plain; charset=us-ascii
Hi all,
It's probably not too hard to fix the phase vocoder to use a series of short tables. The "bang~" object resets two tabread4~ objects every block, so at the same time one could hop to the next table when appropriate.
Although audacity will do this too, it's interesting to be able to scroll through a long soundfile (Kontakte in 4 channels for instance) at any forward or backward speed. One can listen to a 6-channel version of the entire 35-ish-minute long piece to test Stochhausen's assertion that the large scale structure has the same identity as the piece does locally...
cheers Miller
On Mon, May 29, 2006 at 11:17:12AM +0200, Piotr Majdak wrote:
Hi Alexis,
Alexis Baskind wrote:
I am trying to use Miller's wonderful phase-locked vocoder on a big
sound
file (i.e. some 20 minutes on 2 channels). My problem is that "table",
in
which the audiofile is supposed to be loaded, even including the
'maxsize'
option in soundfiler, does not seem to afford sizes bigger than some 1.700.000 elements, i.e. 24 bits I guess. Is there a means to overcome this limit ?
I don't know the answer, but I have a (maybe stupid) question: One great advantage of pd is processing audio in real-time. Why do you want to load signals into tables and perform the processing offline?
br, Piotr
-- Piotr Majdak Institut f?r Schallforschung ?sterreichische Akademie der Wissenschaften Reichsratsstr. 17 A-1010 Wien Tel.: +43-1-4277-29511 Fax: +43-1-4277-9296 E-Mail: piotr@majdak.com WWW: http://www.kfs.oeaw.ac.at
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Alexis Baskind hat gesagt: // Alexis Baskind wrote:
I think I will follow Miller's suggestion to use several successive tables. Of course they should overlap on at least one block, since (correct me if I'm wrong) it may be difficult to switch from one table to another at the middle of a block.
If you use [bang~] to switch tables, this won't matter because it won't happen: [bang~] bangs after [tabread4~] is done.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Tue, 2006-05-30 at 12:55 +0200, Frank Barknecht wrote:
I think I will follow Miller's suggestion to use several successive tables. Of course they should overlap on at least one block, since (correct me if I'm wrong) it may be difficult to switch from one
table
to another at the middle of a block.
If you use [bang~] to switch tables, this won't matter because it won't happen: [bang~] bangs after [tabread4~] is done.
please correct me, if i'm wrong, but they should overlap by a few samples to have a sample-accurate 4-point interpolation ... (at least when reading from the table with tabread4~)
however, this would be a wonderful application for a double-precision floating point signal, which could possibly be implemented by using two single-precision floating point signals to represent one double-precision signal on top of the pd signal backend ... the gained precision would be enough to address several years of audio material :)
tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
Every word is like an unnecessary stain on silence and nothingness Samuel Beckett
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
On Tue, 2006-05-30 at 12:55 +0200, Frank Barknecht wrote:
I think I will follow Miller's suggestion to use several successive tables. Of course they should overlap on at least one block, since (correct me if I'm wrong) it may be difficult to switch from one
table
to another at the middle of a block.
If you use [bang~] to switch tables, this won't matter because it won't happen: [bang~] bangs after [tabread4~] is done.
please correct me, if i'm wrong, but they should overlap by a few samples to have a sample-accurate 4-point interpolation ... (at least when reading from the table with tabread4~)
You're right, a little overlap for the interpolation is needed and also care needs to be taken where to position the tabread4~'s inlet signal. But the table switching will not per se lead to a click if it's initiated by [bang~], as that always happens on block-boundaries.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Alexis Baskind -
Frank Barknecht -
Tim Blechmann