[PD] non-interpolating [vd~]
reduzierer at yahoo.de
Mon May 15 17:31:40 CEST 2006
what i can say from my experience (maybe wrong):
- it seems that pix_pix2sig~ and pix_sig2pix~ follow the sample-by-pixel,
respectively pixel-by-sample concept.
- it seems that every audio-block refers to one frame of the videostream.
- to synthesize a picture, you need to set a block~size higher/equal than
the desired resolution. if blocksize is lower than the resolution, you won't
get the whole frame converted to audio, respectively you can only draw a
part of the frame with the audio signal
- to choose freely the framerate of the videosynthesizer, the samplerate
should be: framerate * blocksize
- of course you could use also any audio-typical samplerate and set a higher
samplerate in the processing subpatch by setting [block~], but then you have
big quantization and maybe won't come close to the desired framerate.
which settings worked for me?
-i'm using a resolution of 160x120px, that are 19200px per frame -> i set
blocksize to 32768.
-i wanted to have a framerate of 25: 32768 * 25 = 819200 Hz
i'm running it on winxp on a pentium m 1.7GHz and and my patch takes around
70% of my cpu, so this is almost the maximum i can work with in realtime.
the problem with the resolution i use now, is that it has an overhead of 41%
"Paris Treantafeles" <paris at parisgraphics.com> wrote:
> Hi Roman,
> Sorry to hijack your question with another question but...
> I'm wondering when you use a high sample rate like this, what combination
> of dimen message to pix_sig2pix~ and what block~ size do you use for best
> I'm guessing that there's some combination that is a good trade off
> between smooth visuals and taking complete control of the cpu.
> On May 15, 2006, at 6:16 AM, Roman Haefeli wrote:
>> hi all
>> i'm working on a project based on [pix_sig2pix~] and therefore i'm using
>> a very high samplerate (819200) and a few [vd~]s. since [vd~] does
>> interpolation, it uses a lot of cpu-power, though i would just need a
>> delay~-object with audio-inlet, but without interpolation. is there such
>> an external? or is there another cpu-friedly way of reading out from a
>> delayline in audiorate?
More information about the Pd-list