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@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