<!-- Converted to DocBook/SGML by Kevin Conder -->
<refentry id="pvsftr">
  <refmeta>
    <refentrytitle>pvsftr</refentrytitle>
  </refmeta>

  <refnamediv>
    <refname>pvsftr</refname>
    <refpurpose>
      Reads amplitude and/or frequency data from function tables.
      <indexterm id="IndexPvsftr"><primary>pvsftr</primary></indexterm>
    </refpurpose>
  </refnamediv>
  
  <refsect1>
    <title>Description</title>
    <para>
      Reads amplitude and/or frequency data from function tables.
    </para>
  </refsect1>

  <refsect1>
    <title>Syntax</title>
    <synopsis><command>pvsftr</command> fsrc, ifna [, ifnf]</synopsis>
  </refsect1>

  <refsect1>
    <title>Initialization</title>
    <para>
      <emphasis>ifna</emphasis> -- A table, at least inbins in size, that stores amplitude data. Ignored if ifna  = 0
    </para>

    <para>
      <emphasis>ifnf</emphasis> (optional) -- A table, at least inbins in size, that stores frequency data. Ignored if ifnf = 0
    </para>
  </refsect1>

  <refsect1>
    <title>Performance</title>
    <para>
      <emphasis>fsrc</emphasis> -- a PVOC-EX formatted source.
    </para>

    <para>
      Enables the contents of <emphasis>fsrc</emphasis> to be exchanged with function tables for custom processing. Except when the frame overlap equals <emphasis>ksmps</emphasis> (which will generally not be the case), the frame data is not updated each control period. The data in <emphasis>ifna</emphasis>, <emphasis>ifnf</emphasis> should only be processed when <emphasis>kflag</emphasis> is set to 1. To process only frequency data, set <emphasis>ifna</emphasis> to zero.
    </para>

    <para>
      As the function tables are required only to store data from <emphasis>fsrc</emphasis>, there is no advantage in defining then in the score, and they should generally be created in the instrument, using <link linkend="ftgen"><citetitle>ftgen</citetitle></link>.
    </para>

    <para>
      By exporting amplitude data, say, from one fsig and importing it into another, basic cross-synthesis (as in <link linkend="pvscross"><citetitle>pvscross</citetitle></link>) can be performed, with the option to modify the data beforehand using the table manipulation opodes.
    </para>

    <para>
      Note that the format data in the source fsig is not written to the tables. This therefore offers a means of transferring amplitude and frequency data between non-identical fsigs. Used this way, these opcodes become potentially pathological, and can be relied upon to produce unexpected  results. In such cases, resynthesis using <link linkend="pvsadsyn"><citetitle>pvsadsyn</citetitle></link> would almost certainly be required.
    </para>

    <para>
      To perform a straight copy from one fsig to another one of identical format, the conventional assignment syntax can be used:

      <literallayout> 
fsig1 = fsig2
      </literallayout> 
 
      It is not necessary to use function tables in this case.
    </para>
  </refsect1>

  <refsect1>
    <title>Examples</title>
    <para>
      <informalexample>
        <programlisting>
ifn     ftgen      0,0,inbins,10,1        ; make ftable
kflag   pvsftw     fsrc,ifn          ; export  amps to table,
kamp    init       0
if      kflag==0   kgoto contin   ; only proc when frame is ready
; kill lowest bins, for obvious effect
        tablew      kamp,1,ifn
        tablew      kamp,2,ifn
        tablew      kamp,3,ifn
        tablew      kamp,4,ifn
; read modified data back to fsrc
        pvsftr      fsrc,ifn
contin:
; and resynth
aout    pvsynth    fsrc
        </programlisting>
      </informalexample>
    </para>
  </refsect1>
 
  <refsect1>
    <title>See Also</title>
    <para>
      <link linkend="pvsftw"><citetitle>pvsftw</citetitle></link>
    </para>
  </refsect1>
 
  <refsect1>
    <title>Credits</title>
    <para>
      <simplelist>
        <member>Author: &namerichard;</member>
        <member>August 2001 </member>
      </simplelist>
    </para>

    <para>New in version 4.13</para>
  </refsect1>
</refentry>
