There is a problem, though; if pvsfwrite writes
a custom window, how is this window retrieved from
the file by a pvsfread instance and then passed to
pvsynth?

The only way I see this is that pvsfread will take
in a function table number, write to it and then
fill the PVSDAT fsig struct with the (negative)
ftable number, so that pvsynth can look it up.

Victor

>
> In internal opcode code, yes. But, just to clarify the
> general picture:  there is no need (nor advantage) to
> expose PVOC_CUSTOM directly in an  opcode; the -1 window
> number in the opcode can stay as it is (with the
> understanding that we can't support it for the SDFT). It
> is important to  have opcodes independent of specific file
> format stuff wherever  possible. For a pvsfwrite opcode,
> the internal implementation would use  PVOC_CUSTOM, but
> again we would want to avoid using PVOC_CUSTOM as a
> parameter value at opcode level.
>
> In principle, someone could devise an opcode to write an
> fsig to an SDIF  file, comnplete with custom window data.
> They would have many mountains  to climb (and streams to
> ford...), but in principle it is possible.
>
> Though they will want to avoid doing that for the sliding
> version!
>
>
>
> Richard Dobson
>
>
>
>
> Michael Gogins wrote:
> > OK, thanks.
> >
> > It sounds like I should probably use the PVOC_CUSTOM
> > facility to write and read ftable windows.
> > Regards,
> > Mike
> >
>
>
> ----------------------------------------------------------
> --------------- 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

Well, it has to be designed and implemented, but is it so big a problem? 
  My first thought is to do it internally if it is at all possible.  We 
would need to add some code to copy the window data from  the input 
fsig-based opcode and rescale as required. pvsfread can be expanded to 
load the window read from the file into its newly allocated window 
space, instead of calculating a preset one. There is already a function 
"pvoc_readwindow()" in pvfileio.h with which to do this. It will then be 
sufficient to set the internal window type field in the struct to 
PVOC_CUSTOM if it finds a custom window in the file. Other opcodes can 
test this field directly.

Perhaps it may even be as simple as making the PVSDAT structure 
extensible (PVSDATEX, castable to PVSDAT ?) with a final window pointer, 
used iff wintype==PVOC_CUSTOM. Is that likely to  break any plugin etc 
opcodes? (And of course in PVSDAT itself wintype is  a plain signed int; 
only the file format requires it to be unsigned).

The ideal reason to use an ftable as the conduit is if for any reason 
the user wants to expose the window used for other purposes (?). That is 
a more delicate question as the user will in the general case not know a 
priori if the stream is using a custom window. If that proves to be a 
required facility then we would need an init level opcode ("pvsgetw") to 
copy the internal window (which may or may not be a custom one) to a 
given ftable, and return a simple i-rate value to disclose whether it is 
a custom window or a defined one. This output can quite possibly use a 
negative value for that (my only concern is that code used for the 
PVOCEX file i/o itself is not changed). I am assuming that it is not 
possible to compatibly modify "pvsinfo" to supply the extra information. 
Which suggests then that a complementary "pvsputw" may also be required, 
that can update a PVSYNTH fsig at inittime. Unless there really is some 
use for changing windows dynamically.

With a little time (after return from ICMC) I can setup my code here to 
create a few test analysis files with a custom window, that people can 
use for testing. I still have a bit of work to do this week finishing 
off SDFT things before the conference. That is unless I can track down 
some old development versions of "pvocex" that I may still have, that 
already do it.



Richard Dobson





Victor Lazzarini wrote:
> There is a problem, though; if pvsfwrite writes
> a custom window, how is this window retrieved from
> the file by a pvsfread instance and then passed to
> pvsynth?
> 
> The only way I see this is that pvsfread will take
> in a function table number, write to it and then
> fill the PVSDAT fsig struct with the (negative)
> ftable number, so that pvsynth can look it up.
> 
> 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