Don't worry, I will not change the PVOCEX header -- at least, not without further discussion and agreement.

According to the CVS log, Istvan Varga introduced the ability to use function tables for windows in pvsanal.c revision 1.18.

There is no code in CVS that uses PVOC_CUSTOM.

What happens if you use pvsanal with an ftable window and try to save the f signal using pvsfwrite?

Anyway, it looks like a solution might be to create a window using a function table, and then save it as a PVOC_CUSTOM window. A negative window type would be passed to pvanal or pvsanal, but it would be saved and read back as a custom window.

Is writing and reading custom windows actually working?

Regards,
Mike


-----Original Message-----
>From: Richard Dobson 
>Sent: Aug 18, 2007 2:36 PM
>To: 
>Cc: Developer discussions 
>Subject: Re: [Cs-dev] Proposed use of function tables as windows in phase vocoders
>
>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
>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

The code is there, but I am not sure how complete it is, will have to 
check (see for example "pvoc_writeWindow()" etc in pvfileio.c). 
Presumably it has not been used by opcodes so far?

The current code is based on a simple "PVXW" chunk to contain the window 
(see my PVOCEX page at:

http://dream.cs.bath.ac.uk/researchdev/pvocex/pvocex.html
)

This needs to be after the format chunk and before the data chunk.  As 
this is currently an unused feature (I have not used it to date in my 
own pvx programs or in CDP),  there is in principle some scope for 
discussion as to whether something more than the minimum is useful.

I wondered who had added the ftable aspect - since I had not done it myself.

Richard Dobson



Michael Gogins wrote:
> Don't worry, I will not change the PVOCEX header -- at least, not
> without further discussion and agreement.
> 
> According to the CVS log, Istvan Varga introduced the ability to use
> function tables for windows in pvsanal.c revision 1.18.
> 
> There is no code in CVS that uses PVOC_CUSTOM.
> 
> What happens if you use pvsanal with an ftable window and try to save
> the f signal using pvsfwrite?
> 
> Anyway, it looks like a solution might be to create a window using a
> function table, and then save it as a PVOC_CUSTOM window. A negative
> window type would be passed to pvanal or pvsanal, but it would be
> saved and read back as a custom window.
> 
> Is writing and reading custom windows actually working?
> 


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