I wouldn't use the metadata stuff myself, though others might, so it would 
be OK for me to omit it. But in that case, is the 'bus' redundant with 
existing facilities? Just having names is a definite plus, however. Even if 
that's the only difference, it's worth doing.

Regards,
Mike

----- Original Message ----- 
From: "Istvan Varga" 
To: 
Sent: Sunday, September 25, 2005 7:31 AM
Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 status


> Michael Gogins wrote:
>
>> The bus interface permits external software (API clients) to directly get 
>> and set Csound variables -- is that correct?
>
> Yes, although the variable is not accessed by its name, but is rather
> exported by the orchestra as a channel of the bus, for example:
>
> /* orchestra header */
>
> gaOutL  chnexport "AudioOutput_Left", 2
>
> /* C code in host */
>
> CSOUND *csound;
> MYFLT *buf;
> ...
> if (csoundCompile(csound) != 0)
>   error();
> if (csoundGetChannelPtr(csound, &buf, "AudioOutput_Left",
>                         CSOUND_AUDIO_CHANNEL | CSOUND_OUTPUT_CHANNEL)
>     != 0)
>   error();
> /* now ksmps MYFLT values can be read from buf after every call to */
> /* csoundPerformKsmps(), and buf actually points directly to the */
> /* data of gaOutL */
>
> I can also post a more complete example of a simple host and CSD
> file.
>
> > If so I think it is a very good idea, but the word 'bus' is misleading.
>
> I am still not sure about the details (including names), so any
> suggestions are welcome (more information about the current interface
> is included below, quoted from an earlier post).
>
>> I like the idea of moving FLTK graphs into a plugin for FLTK. I do not 
>> know if this creates a problem for CsoundVST. Probably, if the plugin has 
>> the right kind of event loop and thread locking, it should be possible to 
>> transfer the event loop to the plugin when CsoundVST is running, and get 
>> it back when Csound is finished, or something. As long as there is a 
>> Csound yield API this should all be doable.
>
> And how about these functions ? Is it important to keep them ?
>
>   PUBLIC void csoundSetFLTKThreadLocking(CSOUND *, int isLocking);
>   PUBLIC int csoundGetFLTKThreadLocking(CSOUND *);
>
> -------------------------------------------------------------------------
>
> Steven Yi wrote:
>
> > I am a little confused about all the modes and why you might want all
> > those options, but I only read enough of the email to do a test of the
> > encapsulated instrument, and will look into it a bit more.
> >
> > As for linear/exponential, etc., those seem like things that should be
> > handled by the code before and after going through the channels, yes?
> > Seems like it might limit the purpose of the bus.
>
>
> As I already mentioned, I am not sure about the channel metadata,
> so it may be changed significantly if requested, or it may even be
> removed completely. Generally, the information on input/output direction,
> unknown/integer/linear/exponential control type, default, minimum,
> and maximum control value are only hints that can be used by the host
> application to allow the user to connect channels of the bus to some
> external ports. For example, knowing that a control channel named
> "FilterFrequency" is expected to receive input, has an exponential
> scale, should be in the range 100 to 10000 with a default "normal"
> setting of 1000, is useful for attaching a knob to that channel.
> Basically, there are two types of metadata: the input/output bitmask
> is always present, and if a new query of the channel is made with an
> inconsistent bitmask, it is simply updated using bitwise OR:
>
> asig    chnget "foo"       ; creates channel, with input bit set
>         chnset asig, "foo" ; this will set output too, so mode is now 3
>
> The other type of metadata is optional and is for control channels only,
> it provides information on the expected range of the control data; the
> parameters included are "type" (unknown, integer, linear, exponential),
> "default value", "minimum value", and "maximum value".
>
> All these additional parameters are only relevant if you intend to use
> this system for implementing communication between the orchestra and
> the host application (as an alternative to invalue/outvalue).
> If all you need is "named ZAK", accessed only from the orchestra, then
> using only chnset and chnget should be fine, without caring about the
> rest of the opcodes or the various special parameters (they do make
> the channel lookup somewhat slower, though, so that may be one reason
> to remove all support for metadata).
>
> > As for chn_k, I'm a little confused on itype for that opcode, as it
> > would seem to me by its nature it's going to be a control signal.
>
>
> itype for chn_k selects an optional "sub-type" for the control channel,
> which can also be changed by a later chn_k call.
>
>   itype = 0
>
>     generic control channel (idflt, imin, and imax are ignored),
>     with no information on the range of the data
>
>   itype = 1
>
>     the channel data is expected to be limited to integer values
>
>   itype = 2
>
>     the channel data is expected to have a linear scale
>
>   itype = 3
>
>     the channel data is expected to have an exponential scale
>
> example (declarations in the orchestra header):
>
> ;                         name      mode type default  min     max
> gkamp     chnexport   "Amplitude",    1,   3,   0.5,  0.001,     1
> gkampDB   chnexport   "Amplitude_DB", 1,   2,  -6,  -60,         0
> gkfreq    chnexport   "Frequency",    1,   3, 440,   20,     20000
> gknote    chnexport   "Note_Number",  1,   1,  60,    1,       127
>
> Note again that all the parameters are only hints, and have no effect
> at all on the actual use of the channel.
>
> >> On 9/23/05, Istvan Varga  wrote:
> >>
> >>> There is an implementation of the opcodes and API functions in the CVS
> >>> sources now, so you can try it and suggest changes (probably many are
> >>> needed, but at least there is something to get started with).
> >>> The "casting" of types by opcodes, as requested by Steven Yi, is not
> >>> (yet) supported, however, it is possible to create channels from 
> >>> actual
> >>> orchestra variables, making it easier and more efficient to implement
> >>> communication between the orchestra and the host application.
> >>> Also, there is some "metadata" such as input/output direction, and
> >>> optional parameters for control channels (integer/linear/exponential
> >>> type, default, minimum, and maximum value); these probably need to be
> >>> changed too, or may be removed if not found to be useful.
> >>>
> >>> OPCODES
> >>>
> >>> ival    chnget      Sname
> >>> kval    chnget      Sname
> >>> aval    chnget      Sname
> >>> Sval    chnget      Sname
> >>>
> >>> Read value from a channel (created if does not exist yet, with an 
> >>> initial
> >>> value of zero; otherwise, it must be of a compatible type).
> >>>
> >>>         chnset      ival, Sname
> >>>         chnset      kval, Sname
> >>>         chnset      aval, Sname
> >>>         chnset      Sval, Sname
> >>>
> >>> Write to a channel (created if does not exist yet; otherwise, it must 
> >>> be
> >>> of a compatible type).
> >>>
> >>>         chn_k       Sname, imode[, itype, idflt, imin, imax]
> >>>
> >>> Declare control channel. imode is a sum of 1 for input and 2 for 
> >>> output.
> >>> For more information on input/output mode and the optional arguments, 
> >>> see
> >>> the API function below.
> >>>
> >>>         chn_a       Sname, imode
> >>>         chn_S       Sname, imode
> >>>
> >>> Declare audio or string channel.
> >>>
> >>> gival   chnexport   Sname, imode[, itype, idflt, imin, imax]
> >>> gkval   chnexport   Sname, imode[, itype, idflt, imin, imax]
> >>> gaval   chnexport   Sname, imode
> >>> gSval   chnexport   Sname, imode
> >>>
> >>> Export a global variable as a channel of the bus that should not exist
> >>> before calling the opcode. Allows the host application to read or 
> >>> write
> >>> orchestra variables directly.
> >>> The parameters are the same as in the case of chn_k/chn_a/chn_S.
> >>>
> >>> itype, imode, ictltype, idflt, imin, imax   chnparams
> >>>
> >>> Query parameters of a channel (if it does not exist, all returned 
> >>> values
> >>> are zero):
> >>>
> >>>   itype:
> >>>     channel data type (1: control, 2: audio, 3: string)
> >>>   imode:
> >>>     sum of 1 for input and 2 for output
> >>>   ictltype, idflt, imin, imax:
> >>>     special parameters for control channel only; if not available, all 
> >>> are
> >>>     set to zero
> >>>
> >>> API FUNCTIONS
> >>>
> >>>   /**
> >>>    * Stores a pointer to the specified channel of the bus in *p,
> >>>    * creating the channel first if it does not exist yet.
> >>>    * 'type' must be the bitwise OR of exactly one of the following 
> >>> values,
> >>>    *   CSOUND_CONTROL_CHANNEL
> >>>    *     control data (one MYFLT value)
> >>>    *   CSOUND_AUDIO_CHANNEL
> >>>    *     audio data (csoundGetKsmps(csound) MYFLT values)
> >>>    *   CSOUND_STRING_CHANNEL
> >>>    *     string data (MYFLT values with enough space to store
> >>>    *     csoundGetStrVarMaxLen(csound) characters, including the
> >>>    *     NULL character at the end of the string)
> >>>    * and at least one of these:
> >>>    *   CSOUND_INPUT_CHANNEL
> >>>    *   CSOUND_OUTPUT_CHANNEL
> >>>    * If the channel already exists, it must match the data type 
> >>> (control,
> >>>    * audio, or string), however, the input/output bits are OR'd with 
> >>> the
> >>>    * new value. Note that audio and string channels can only be 
> >>> created
> >>>    * after calling csoundCompile(), because the storage size is not 
> >>> known
> >>>    * until then.
> >>>    * Return value is zero on success, or a negative error code,
> >>>    *   CSOUND_MEMORY  there is not enough memory for allocating the 
> >>> channel
> >>>    *   CSOUND_ERROR   the specified name or type is invalid
> >>>    * or, if a channel with the same name but incompatible type already 
> >>> exists,
> >>>    * the type of the existing channel. In the case of any non-zero 
> >>> return
> >>>    * value, *p is set to NULL.
> >>>    * Note: to find out the type of a channel without actually creating 
> >>> or
> >>>    * changing it, set 'type' to zero, so that the return value will be 
> >>> either
> >>>    * the type of the channel, or CSOUND_ERROR if it does not exist.
> >>>    */
> >>>   PUBLIC int csoundGetChannelPtr(CSOUND *,
> >>>                                  MYFLT **p, const char *name, int 
> >>> type);
> >>>
> >>>   /**
> >>>    * Returns a list of allocated channels, storing a pointer to an 
> >>> array
> >>>    * of channel names in *names, and a pointer to an array of channel 
> >>> types
> >>>    * in *types. (*types)[n] corresponds to (*names)[n], and has the 
> >>> same
> >>>    * format as the 'type' parameter of csoundGetChannelPtr().
> >>>    * The return value is the number of channels, which may be zero if 
> >>> there
> >>>    * are none, or CSOUND_MEMORY if there is not enough memory for 
> >>> allocating
> >>>    * the lists. In the case of no channels or an error, *names and 
> >>> *types are
> >>>    * set to NULL.
> >>>    * Note: the caller is responsible for freeing the lists returned in 
> >>> *names
> >>>    * and *types with free(), however, the actual channel names should 
> >>> not be
> >>>    * changed or freed. Also, the name pointers may become invalid 
> >>> after calling
> >>>    * csoundReset().
> >>>    */
> >>>   PUBLIC int csoundListChannels(CSOUND *, char ***names, int **types);
> >>>
> >>>   /**
> >>>    * Sets special parameters for a control channel. The parameters 
> >>> are:
> >>>    *   type:  must be one of CSOUND_CONTROL_CHANNEL_INT,
> >>>    *          CSOUND_CONTROL_CHANNEL_LIN, or 
> >>> CSOUND_CONTROL_CHANNEL_EXP for
> >>>    *          integer, linear, or exponential channel data, 
> >>> respectively,
> >>>    *          or zero to delete any previously assigned parameter 
> >>> information
> >>>    *   dflt:  the control value that is assumed to be the default, 
> >>> should be
> >>>    *          greater than or equal to 'min', and less than or equal 
> >>> to 'max'
> >>>    *   min:   the minimum value expected; if the control type is 
> >>> exponential,
> >>>    *          it must be non-zero
> >>>    *   max:   the maximum value expected, should be greater than 
> >>> 'min';
> >>>    *          if the control type is exponential, it must be non-zero 
> >>> and
> >>>    *          match the sign of 'min'
> >>>    * Returns zero on success, or a non-zero error code on failure:
> >>>    *   CSOUND_ERROR:  the channel does not exist, is not a control 
> >>> channel,
> >>>    *                  or the specified parameters are invalid
> >>>    *   CSOUND_MEMORY: could not allocate memory
> >>>    */
> >>>   PUBLIC int csoundSetControlChannelParams(CSOUND *, const char *name,
> >>>                                            int type, MYFLT dflt,
> >>>                                            MYFLT min, MYFLT max);
> >>>
> >>>   /**
> >>>    * Returns special parameters (assuming there are any) of a control 
> >>> channel,
> >>>    * previously set with csoundSetControlChannelParams().
> >>>    * If the channel exists, is a control channel, and has the special 
> >>> parameters
> >>>    * assigned, then the default, minimum, and maximum value is stored 
> >>> in *dflt,
> >>>    * *min, and *max, respectively, and a positive value that is one of
> >>>    * CSOUND_CONTROL_CHANNEL_INT, CSOUND_CONTROL_CHANNEL_LIN, and
> >>>    * CSOUND_CONTROL_CHANNEL_EXP is returned.
> >>>    * In any other case, *dflt, *min, and *max are not changed, and the 
> >>> return
> >>>    * value is zero if the channel exists, is a control channel, but 
> >>> has no
> >>>    * special parameters set; otherwise, a negative error code is 
> >>> returned.
> >>>    */
> >>>   PUBLIC int csoundGetControlChannelParams(CSOUND *, const char *name,
> >>>                                            MYFLT *dflt, MYFLT *min, 
> >>> MYFLT *max);
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net