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

  <refnamediv>
    <refname>xout</refname>
    <refpurpose>
      Retrieves variables from a user-defined opcode block,
      <indexterm id="IndexXout"><primary>xout</primary></indexterm>
    </refpurpose>
  </refnamediv>
  
  <refsect1>
    <title>Description</title>
    <para>
      The <emphasis>xin</emphasis> and <emphasis>xout</emphasis> opcodes copy variables to and from the opcode definition, allowing communication with the calling instrument.
    </para>

    <para>
      The types of input and output variables are defined by the parameters <emphasis>intypes</emphasis> and <emphasis>outtypes</emphasis>.
    </para>

    <note>
      <title>Notes</title>
      <para>
        <itemizedlist>
          <listitem><para><emphasis>xin</emphasis> and <emphasis>xout</emphasis> should be called only once, and <emphasis>xin</emphasis> should precede <emphasis>xout</emphasis>, otherwise an init error and deactivation of the current instrument may occur.</para></listitem>
          <listitem><para>These opcodes actually run only at i-time. Performance time copying is done by the user opcode call. This means that skipping <emphasis>xin</emphasis> or <emphasis>xout</emphasis> with <link linkend="kgoto"><citetitle>kgoto</citetitle></link> has no effect, while skipping with <link linkend="igoto"><citetitle>igoto</citetitle></link> affects both init and performance time operation.</para></listitem>
        </itemizedlist>
      </para>
    </note>
  </refsect1>

  <refsect1>
    <title>Syntax</title>
    <synopsis><command>xout</command> xoutarg1 [, xoutarg2] ... [, xoutargN]</synopsis>
  </refsect1>

  <refsect1>
    <title>Performance</title>
    <para>
      <emphasis>xoutarg1</emphasis>, <emphasis>xoutarg2</emphasis>, ... - output arguments. The number and type of variables must agree with the user-defined opcode's <emphasis>outtypes</emphasis> declaration. However, <emphasis>xout</emphasis> does not check for incorrect use of init-time and control-rate variables.
    </para>

    <para>
      The syntax of a user-defined opcode block is as follows:

      <literallayout>
opcode  name, outtypes, intypes
xinarg1 [, xinarg2] [, xinarg3] ... [xinargN]  xin
[setksmps  iksmps]
... the rest of the instrument's code.
xout  xoutarg1 [, xoutarg2] [, xoutarg3] ... [xoutargN]
endop
      </literallayout>
    </para>

    <para>
      The new opcode can then be used with the usual syntax:

      <literallayout>
[xinarg1] [, xinarg2] ... [xinargN]  name  [xoutarg1] [, xoutarg2] ... [xoutargN] [, iksmps]
      </literallayout>
    </para>
  </refsect1>

  <refsect1>
    <title>Examples</title>
    <para>
      See the example for the <link linkend="opcode"><citetitle>opcode</citetitle></link> opcode.
    </para>
  </refsect1>

  <refsect1>
    <title>See Also</title>
    <para>
      <link linkend="endop"><citetitle>endop</citetitle></link>, 
      <link linkend="opcode"><citetitle>opcode</citetitle></link>, 
      <link linkend="setksmps"><citetitle>setksmps</citetitle></link>, 
      <link linkend="xin"><citetitle>xin</citetitle></link>
    </para>
  </refsect1>

  <refsect1>
    <title>Credits</title>
    <para>Author: Istvan Varga, 2002; based on code by Matt J. Ingalls</para>
    <para>New in version 4.22</para>
  </refsect1>
</refentry>
