My suggestion to use a extern ftable was to find a means
of passing the window from pvsfread to pvsynth.

But I don't see any particular problem in adding an extra
field
in an fsig PVSDAT to hold a custom window for it. This
of course would only affect the in-memory data structure
and would not change the file format. That would be more
transparent and would not require any extra parameters
to any opcode. I think it's a good idea.

Victor

> 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