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
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
Hi Roman,
Thanks for sharing your experience.
I've been experimenting with higher sampling rates and block sizes to
get smoother images and on one hand, I'm getting some nice results.
On the other, I wasn't approaching it with as much knowledge as much
as experimenting and so I'm sure burning up cpu cycles unnecessarily.
By the way... this is exactly the kind of thing that I was hoping to
try to do in a net-pd setting since users can create visuals without
having to share texture information, etc.
Best, p
On May 15, 2006, at 11:31 AM, Roman Haefeli wrote:
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Oh man, thanks for the breakdown! I was trying to figure out how it was working while futzing about with Paris' great experimental patches a few weeks back. Impressed a bunch of friends, now I'm going to try doing some "VJ-ing" for a show coming up.
Where can I find out more about this kind of stuff? I'd love to be able to use live audio and project the FFT or even direct waveform into the Gem window. Anybody done this yet?
~Kyle
On 5/15/06, Roman Haefeli reduzierer@yahoo.de wrote:
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Kyle,
I do this quite often in a live setting - something like this -
others may have better ideas...
- have main patch at pd's default block size that takes audio in.
there you can do all of your audio fun stuff, bonk~, fiddle~, etc.. i generally take the audio and filter it into low, bp and hi as well.
- send whatever you want from (1) (e.g. your hi, med and low audio)
to an abstraction containing pix_sig2pix~
with block~ size 4096 or whatever - higher depending on what you want
to do.
In this patch you can apply all kind of pix_something objects to make
it more interesting as well.
- send gem a fullscreen message and that's it! (well, svideo-
projector, etc)
There's a ton of variations on all of this and it's fun to try
different audio processing on the input signals and toggle what you
send to gem patch.
There's also scopeXYZ~ if you want to do some more oscillographic
visualization.
It does Lissajous curves :-)
Best, p
On May 16, 2006, at 12:30 PM, Kyle Klipowicz wrote:
Oh man, thanks for the breakdown! I was trying to figure out how it was working while futzing about with Paris' great experimental patches a few weeks back. Impressed a bunch of friends, now I'm going to try doing some "VJ-ing" for a show coming up.
Where can I find out more about this kind of stuff? I'd love to be able to use live audio and project the FFT or even direct waveform into the Gem window. Anybody done this yet?
~Kyle
On 5/15/06, Roman Haefeli reduzierer@yahoo.de wrote:
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
I was just playing around with this, but these objects (pix_sig2pix~ and scopeXYZ~) don't quite do what I want. I really want that cheezy "Geiss" effect: to display the waveform as a 2d texture. The problem I see with pix_sig2pix~ is that it is mapping a 2d frame based upon color, but I actually want the table to be displayed. Is this possible?
Also, how can I get rid of the green background when using pix_sig2pix~? It limits my color pallet otherwise...
~Kyle
On 5/16/06, Paris Treantafeles paris@parisgraphics.com wrote:
Hi Kyle,
I do this quite often in a live setting - something like this - others may have better ideas...
- have main patch at pd's default block size that takes audio in.
there you can do all of your audio fun stuff, bonk~, fiddle~, etc.. i generally take the audio and filter it into low, bp and hi as well.
- send whatever you want from (1) (e.g. your hi, med and low audio)
to an abstraction containing pix_sig2pix~ with block~ size 4096 or whatever - higher depending on what you want to do. In this patch you can apply all kind of pix_something objects to make it more interesting as well.
- send gem a fullscreen message and that's it! (well, svideo-
projector, etc)
There's a ton of variations on all of this and it's fun to try different audio processing on the input signals and toggle what you send to gem patch.
There's also scopeXYZ~ if you want to do some more oscillographic visualization. It does Lissajous curves :-)
Best, p
On May 16, 2006, at 12:30 PM, Kyle Klipowicz wrote:
Oh man, thanks for the breakdown! I was trying to figure out how it was working while futzing about with Paris' great experimental patches a few weeks back. Impressed a bunch of friends, now I'm going to try doing some "VJ-ing" for a show coming up.
Where can I find out more about this kind of stuff? I'd love to be able to use live audio and project the FFT or even direct waveform into the Gem window. Anybody done this yet?
~Kyle
On 5/15/06, Roman Haefeli reduzierer@yahoo.de wrote:
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
Hi Kyle,
Hmm.. not sure how to go about getting that effect.
As for the other question, you might try something like sending your
audio into one of R, G or B and then using sig~ to send floats less
than 1 to the other two inputs.
Not sure if that will eliminate all colors besides the waveform but
at least will give you a larger pallet.
-p
On May 17, 2006, at 1:07 PM, Kyle Klipowicz wrote:
I was just playing around with this, but these objects (pix_sig2pix~ and scopeXYZ~) don't quite do what I want. I really want that cheezy "Geiss" effect: to display the waveform as a 2d texture. The problem I see with pix_sig2pix~ is that it is mapping a 2d frame based upon color, but I actually want the table to be displayed. Is this possible?
Also, how can I get rid of the green background when using pix_sig2pix~? It limits my color pallet otherwise...
~Kyle
On 5/16/06, Paris Treantafeles paris@parisgraphics.com wrote:
Hi Kyle,
I do this quite often in a live setting - something like this - others may have better ideas...
- have main patch at pd's default block size that takes audio in.
there you can do all of your audio fun stuff, bonk~, fiddle~, etc.. i generally take the audio and filter it into low, bp and hi as well.
- send whatever you want from (1) (e.g. your hi, med and low audio)
to an abstraction containing pix_sig2pix~ with block~ size 4096 or whatever - higher depending on what you want to do. In this patch you can apply all kind of pix_something objects to make it more interesting as well.
- send gem a fullscreen message and that's it! (well, svideo-
projector, etc)
There's a ton of variations on all of this and it's fun to try different audio processing on the input signals and toggle what you send to gem patch.
There's also scopeXYZ~ if you want to do some more oscillographic visualization. It does Lissajous curves :-)
Best, p
On May 16, 2006, at 12:30 PM, Kyle Klipowicz wrote:
Oh man, thanks for the breakdown! I was trying to figure out
how it
was working while futzing about with Paris' great experimental
patches
a few weeks back. Impressed a bunch of friends, now I'm going
to try
doing some "VJ-ing" for a show coming up.
Where can I find out more about this kind of stuff? I'd love to be able to use live audio and project the FFT or even direct waveform into the Gem window. Anybody done this yet?
~Kyle
On 5/15/06, Roman Haefeli reduzierer@yahoo.de wrote:
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Hi Roman,
i'd use a traditional [delread~], with an [env~] as audio-to-msg converter.
lg, Peter
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Kyle Klipowicz -
Paris Treantafeles -
Peter Plessas -
Roman Haefeli