Hi, I have some questions about, guess what? - VASP!
I'm trying to put together a simple FFT scope.
Here are some things I'm not sure about.
First, How should I use the "detach" message, assuming that i want my scope to run always in a seperate thread (so that there's no issues in switching it back and forth)? Should I send the "detach" message first, before starting processing?
Next, "vasp.window" apparently doesn't handle the "to" message, so how do I deal with that? I thought the approach would be to chain all the objects to gether and send the first one a "to" message to set the source and destination arrays, and everything would be well.
Now about the fft stuff - I am not sure what vasp.rfft does actually. It seems like that's what I want to use, becuase I'm dealing with an audio signal. But what does it output, and how does that map into a PD array? Is it generating the full complex FFT, including the redundant conjugates? And are only the real compenents of this making it to the arrary, or is there a mag operation done before writing to the array? And if so, is there a way that I can write only the magnitudes of the first half of the output to my array?
IOW basically, for an FFT of a real signal, I only want the first half, so my output array should be half the length of the input array. And for simple energy plot, each point in the array should be the magnitude vector of the corresponding point in the FFT.
Is this somehow what is already done, or do I need to do something else to accomplish this?
Thanks in advance!
Larry
Hi Larry,
First, How should I use the "detach" message, assuming that i want my
scope to
run always in a seperate thread (so that there's no issues in switching it back and forth)? Should I send the "detach" message first, before starting processing?
It's good to use "detached" processing for all operations that are considered to take some time. Launching the thread takes some time, so don't use it for operations that are sure to be compatible with real-time operation. (btw, i just realized that vasp.! should not be detached, which would be useful for making larger temporary buffers... there's a bug causing it to crash eventually). You can either send a "detach 1" message before the first operation, or even better, set the "detach" attribute at creation time by specifying e.g. [vasp.window @detach 1]. If you have newer vasp and pd versions, you will notice that the "@detach 1" disappears, but you can use the properties dialog in the context menu (right mouse click) to display the attributes of vasps objects (or rather all attribute-enabled flext objects)
Next, "vasp.window" apparently doesn't handle the "to" message, so how do
I
deal with that? I thought the approach would be to chain all the objects
to
gether and send the first one a "to" message to set the source and destination arrays, and everything would be well.
vasp.window fills a buffer with a window curve, so a separate destination won't make much sense. There's vasp.*window to multiply half of a window with some data, or vasp.*xwindow for a symmetric version (these two have a @to attribute)
Now about the fft stuff - I am not sure what vasp.rfft does actually. It
seems
like that's what I want to use, becuase I'm dealing with an audio signal.
But
what does it output, and how does that map into a PD array? Is it
generating
the full complex FFT, including the redundant conjugates? And are only the real compenents of this making it to the arrary, or is there a mag
operation
done before writing to the array? And if so, is there a way that I can
write
only the magnitudes of the first half of the output to my array?
the vasp.rfft operation produces the following output bin 0 .... frequency 0 component bin 1... windowsize/2-1 ... real part of the spectrum (only positive frequencies) bin windowsize/2 ... Nyquist freqency component bin windowsize/2+1... windowsize-1 ... complex part of the spectrum (only positive frequencies)
There's no redundancy of data as expected for a real FFT. A magnitude operation has to be performed separately afterwards.
IOW basically, for an FFT of a real signal, I only want the first half, so
my
output array should be half the length of the input array. And for simple energy plot, each point in the array should be the magnitude vector of the corresponding point in the FFT.
Is this somehow what is already done, or do I need to do something else to accomplish this?
See the attached patch... it probably does what you want to do....
best greetings, Thomas
On Sunday 09 November 2003 20:36, Thomas Grill wrote:
You can either send a "detach 1" message before the first operation, or even better, set the "detach" attribute at creation time by specifying e.g. [vasp.window @detach 1]. If you have newer vasp and pd versions, you will notice that the "@detach 1" disappears, but you can use the properties dialog in the context menu (right mouse click) to display the attributes of vasps objects (or rather all attribute-enabled flext objects)
<various stuff snipped for your concise viewing pleasure>
detach
Ok, I didn't know you could do that at creation time - that's what I want.
Next, "vasp.window" apparently doesn't handle the "to" message
vasp.window fills a buffer with a window curve, so a separate destination won't make much sense. There's vasp.*window to multiply half of a window with some data, or vasp.*xwindow for a symmetric version (these two have a @to attribute)
Yes, I misunderstood - I thought that that vasp.window already multiplied the existing buffer with its window.
Now about the fft stuff - I am not sure what vasp.rfft does actually. It
the vasp.rfft operation produces the following output bin 0 .... frequency 0 component bin 1... windowsize/2-1 ... real part of the spectrum (only positive frequencies) bin windowsize/2 ... Nyquist freqency component bin windowsize/2+1... windowsize-1 ... complex part of the spectrum (only positive frequencies)
There's no redundancy of data as expected for a real FFT. A magnitude operation has to be performed separately afterwards.
IOW basically, for an FFT of a real signal, I only want the first half,
See the attached patch... it probably does what you want to do....
best greetings, Thomas
Taking a look in 3.. 2.. 1..
Larry
Oh, one more thing... with the fftscope-Patch there's a warning displayed when you first bang the procedure. This is because of a small bug in the new threading behavior of flext. I fixed it - the version should be mirrored to the pd cvs in about half an hour.
best greetings, Thomas
----- Original Message ----- From: "Larry Troxler" lt@westnet.com To: "Thomas Grill" t.grill@gmx.net; "PD List" pd-list@iem.kug.ac.at Sent: Monday, November 10, 2003 3:22 AM Subject: Re: Some VASP questions
On Sunday 09 November 2003 20:36, Thomas Grill wrote:
You can either send a "detach 1" message before the first operation, or even better, set the "detach" attribute at creation time by specifying
e.g.
[vasp.window @detach 1]. If you have newer vasp and pd versions, you
will
notice that the "@detach 1" disappears, but you can use the properties dialog in the context menu (right mouse click) to display the attributes
of
vasps objects (or rather all attribute-enabled flext objects)
<various stuff snipped for your concise viewing pleasure>
detach
Ok, I didn't know you could do that at creation time - that's what I want.
Next, "vasp.window" apparently doesn't handle the "to" message
vasp.window fills a buffer with a window curve, so a separate
destination
won't make much sense. There's vasp.*window to multiply half of a window with some data, or vasp.*xwindow for a symmetric version (these two have a @to attribute)
Yes, I misunderstood - I thought that that vasp.window already multiplied
the
existing buffer with its window.
Now about the fft stuff - I am not sure what vasp.rfft does actually.
It
the vasp.rfft operation produces the following output bin 0 .... frequency 0 component bin 1... windowsize/2-1 ... real part of the spectrum (only positive frequencies) bin windowsize/2 ... Nyquist freqency component bin windowsize/2+1... windowsize-1 ... complex part of the spectrum
(only
positive frequencies)
There's no redundancy of data as expected for a real FFT. A magnitude operation has to be performed separately afterwards.
IOW basically, for an FFT of a real signal, I only want the first
half,
See the attached patch... it probably does what you want to do....
best greetings, Thomas
Taking a look in 3.. 2.. 1..
Larry
On Sunday 09 November 2003 21:45, Thomas Grill wrote:
Oh, one more thing... with the fftscope-Patch there's a warning displayed when you first bang the procedure. This is because of a small bug in the new threading behavior of flext. I fixed it - the version should be mirrored to the pd cvs in about half an hour.
best greetings, Thomas
Would that be "invalid vasp detected and ignored"? I get several of these messages for several of the vasp objects?
Are things still being threaded, or do I need to get your update for that?
Larry
Would that be "invalid vasp detected and ignored"? I get several of these messages for several of the vasp objects?
Not really. Do you get those messages from my attached patch or from another one? If the latter is the case, maybe you can send me the patch to have a look.
Are things still being threaded, or do I need to get your update for that?
All operations that have the "detach" attribute set to 1 fork their own threads for the time of the operation.
best greetings, Thomas
On Tuesday 11 November 2003 06:20, Thomas Grill wrote:
Would that be "invalid vasp detected and ignored"? I get several of these messages for several of the vasp objects?
Not really. Do you get those messages from my attached patch or from another one? If the latter is the case, maybe you can send me the patch to have a look.
Are things still being threaded, or do I need to get your update for that?
All operations that have the "detach" attribute set to 1 fork their own threads for the time of the operation.
best greetings, Thomas
On Tuesday 11 November 2003 06:20, Thomas Grill wrote:
Would that be "invalid vasp detected and ignored"? I get several of these messages for several of the vasp objects?
Not really. Do you get those messages from my attached patch or from another one?
From the attached patch. However, it does not happen all the time, and so far
I haven't found a sequence that reliably reproduces the problem.
First question, which would pre-empt the rest of this message: are there any bug fixes between 0.36-devel and 0.37 that I'm missing that could relate to this?
Next, I haven't looked at the source yet to see what generates this message.
The only corelation I suspect (and I could be easily be wrong about this, it's just a vague suspicion), is that this is somehow an indirect artifact of the current TK bug (where you get a message about "bad screen distances", sometimes followed by "illegal command name", when loading a patch or moving a graph). However I can't imagine what the connection might be, and I suspect it could be just a coincidence.
If it happens again, and if I can figure out a way to reproduce it reliably, then I'll try to debug it.
Larry
Not really. Do you get those messages from my attached patch or from another one?
From the attached patch. However, it does not happen all the time, and so
far
I haven't found a sequence that reliably reproduces the problem.
First question, which would pre-empt the rest of this message: are there
any
bug fixes between 0.36-devel and 0.37 that I'm missing that could relate
to
this?
There have been some changes in the threading model that could have an influence. To see if the threading is buggy you could try to remove all the detach flags (maybe it's best to do that in the patcher text file) and try again.
Next, I haven't looked at the source yet to see what generates this
message.
You will have hard times to debug the VASP source if you're not familiar with it
The only corelation I suspect (and I could be easily be wrong about this,
it's
just a vague suspicion), is that this is somehow an indirect artifact of
the
current TK bug (where you get a message about "bad screen distances", sometimes followed by "illegal command name", when loading a patch or
moving
a graph). However I can't imagine what the connection might be, and I
suspect
it could be just a coincidence.
I don't think it's related to that - it looks like a genuine VASP bug.
best greetings, Thomas
-
Larry Troxler -
Thomas Grill