John, Richard, Victor, thanks for your responses.

What I'm going to do is make atsa and pvanal act like pvsanal in that a negative window type will be taken to represent a function table number. I'll just borrow the code from pvsanal.c, since it interpolates samples if the ftable and the window are not the same size.

In the pvsanal code, the PVOCDATA wWindowType field is type cast from unsigned to signed. But wouldn't it be better to change the type of the PVOCDATA wWindowType field from uint16_t to int16_t? I do not see why that should cause any side effects or break backward compatibility. Should I make this change and, if so, should I increment the version number of the WAVEFORMATPVOCEX structure?

Regards,
Mike

-----Original Message-----
>From: Richard Dobson 
>Sent: Aug 18, 2007 12:21 PM
>To: Developer discussions 
>Subject: Re: [Cs-dev] Proposed use of function tables as windows in phase vocoders
>
>As John indicated, this feature can't apply to the SDFT variation, as 
>there we have to window by frequency-domain convolution, hence the 
>rasied cosine reference. Kaiser for example is not defined by cosines, 
>but by Bessel functions, and so far we have not found a formal f/d form. 
>There may be a solution by finding the f/domain impulse response of the 
>t/d window, haven't explored that solution yet. But Blackman/Harris 
>variant windows are fine.
>
>Its not directly relevant to this issue, but the PVOC_EX file format 
>includes support for a "custom" window to be contained in the header, 
>though I have yet to implement that in my own code!
>
>Richard Dobson
>
>
>Victor Lazzarini wrote:
>> as I said before this is not correct, pvsanal
>> supports any window shape defined in a f-table.
>> It is just not documented, but I'll fix the manual.
>> 
>> Victor
>> 
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >>  http://get.splunk.com/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> 
> In the pvsanal code, the PVOCDATA wWindowType field is type cast from
> unsigned to signed. But wouldn't it be better to change the type of
> the PVOCDATA wWindowType field from uint16_t to int16_t? I do not see
> why that should cause any side effects or break backward
> compatibility. Should I make this change and, if so, should I
> increment the version number of the WAVEFORMATPVOCEX structure?
> 

No. That concerns the PVOC_EX file format, not opcode syntax. As I 
indicated elswhere, I defined the symbol PVOC_CUSTOM to indicate use of 
a custom window not already defined (see pvfileio.h). Perhaps one day 
the current list of defined windows in PVOCEX can be augmented (though I 
warn about gettting obsessive about minor differences between windows!), 
but even that need not justify bumping the version number, as the chunk 
structures themselves do not change. Please treat all PVOC_EX-format 
specific stuff as "read-only"!  Negative numbers can have no useful 
meaning for window type in the PVOCEX header, which is precisely why I 
defined it as unsigned. I have no plans to make any change to the 
PVOC_EX file format as it currently stands. The one possible change at 
the back of my mind is a 64bit version to enable truly huge files, maybe 
based on w64.

Richard Dobson


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net