[PD] non-interpolating [vd~]

[Roman Haefeli]

hi paris

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% 
(1-(19200/32768).

roman






"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 
> results?
> I'm guessing that there's some combination that is a good trade off 
> between smooth visuals and taking complete control of the cpu.
>
> Thanks,
> p
>
>
> 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?
>>
>> roman
>>