Csound Csound-dev Csound-tekno Search About

[Cs-dev] Question on CVS changes

Date2005-02-02 18:46
Fromsteven yi
Subject[Cs-dev] Question on CVS changes
Hi Istvan and All,

I was taking a look at the new CVS changes today and was wondering about 
the "static  void    **global_cfg_db" and is this temporarily a static 
global variable to be moved into the ENVIRON struct later?  I haven't 
looked at this enough this morning to figure out what purpose it has 
being global.

Also, for the audio I/O as plugins, it seems to load all, then check for 
a globalVariable _RTAUDIO to decide which plugin to enable.  This is 
hardcoded in csound.c to PortAudio for the timebeing, or is there a 
configuration flag I am not seeing to enable other plugins? Is there a 
way to query/list what audio plugins are available?  (I haven't had a 
chance to compile yet, so apologies if this is already there, but I 
haven't found it in code yet).

And could you discuss the cfgvar file design and how the different 
global/non-global functions relate, when each is designed to be used?

Thanks,
steven




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2005-02-02 19:39
FromIstvan Varga
SubjectRe: [Cs-dev] Question on CVS changes
steven yi wrote:

> I was taking a look at the new CVS changes today and was wondering about 
> the "static  void    **global_cfg_db" and is this temporarily a static 
> global variable to be moved into the ENVIRON struct later?  I haven't 
> looked at this enough this morning to figure out what purpose it has 
> being global.

It is not used yet, but is really a global and is not supposed to be in
ENVIRON. However, it does have its counterpart in ENVIRON, named
'void **cfgVariableDB'. The difference between the two variables is
that the static global one is for use by the host application, and
the other in ENVIRON is specific to Csound instances.
More about this below.

> Also, for the audio I/O as plugins, it seems to load all, then check for 
> a globalVariable _RTAUDIO to decide which plugin to enable.  This is 
> hardcoded in csound.c to PortAudio for the timebeing, or is there a 
> configuration flag I am not seeing to enable other plugins? Is there a 
> way to query/list what audio plugins are available?  (I haven't had a 
> chance to compile yet, so apologies if this is already there, but I 
> haven't found it in code yet).

You can select the RT audio plugin with the command line option
'-+rtaudio=MODULENAME', where MODULENAME is something like 'alsa'
or 'portaudio'. Currently there are two modules, librtalsa.so and
librtpa.so, both print a message when found and loaded by Csound:

   "Localisation of messages is disabled, using default language.
    PortAudio real-time audio module for Csound by John ffitch
    ALSA real-time audio module for Csound by Istvan Varga
    0dBFS level = 32767.0
    [...]"

> And could you discuss the cfgvar file design and how the different 
> global/non-global functions relate, when each is designed to be used?

The files cfgvar.c/cfgvar.h do not have documentation yet (I will write
it soon), but the main purpose is to allow for dynamic creation of Csound
options, without the need to edit argdecode.c. So, for example, a plugin
can register its own command line options, but there are other, more
advanced uses.

Here is a short explanation of the code in csoundCreate():

   int   max_len = 21;

This is the maximum length (+1 for the null byte at the end) of the
string option to be created.

   csoundCreateGlobalVariable(csound, "_RTAUDIO", (size_t) max_len);

Allocates a named dynamic "global" variable for Csound instance
'csound', with max_len bytes of space (which is cleared to zero).
Note that this function has a return value to report errors (such
as an already used name), but I did not bother to check it.

   s = csoundQueryGlobalVariable(csound, "_RTAUDIO");

This is how you can access the newly created "variable". s will now
contain a pointer to 21 bytes of allocated memory (or NULL if the
specified name is invalid, but we have just created it).

   strcpy(s, "PortAudio");

Sets csound->"_RTAUDIO"="PortAudio"

   csoundCreateConfigurationVariable(csound, "rtaudio", s,
                                     CSOUNDCFG_STRING, 0, NULL, &max_len,
                                     "Real time audio module name", NULL);

Registers a local (that is, specific to 'csound') configuration variable
named "rtaudio" (that's where that -+rtaudio=MODULENAME comes from), of
which the value is stored at 's', of type CSOUNDCFG_STRING (an array of
characters), with zero flags, no minimum value (a minimum value only makes
sense for integer and float types), a maximum length of max_len=21 bytes,
short description is "Real time audio module name", and there is no long
description.
Now type './csound --help', and notice this:

   "[...]
    --help                  Long help

    -+rtaudio= (max. length = 20 characters)
            Real time audio module name

    Short form:
    [...]"

You can find out more about the system by having a look at cfgvar.c/cfgvar.h.

So far, only 'local' configuration variables were dealt with. These are
created from within an instance of Csound. 'Global' configuration variables
are created by the host application, and could possible be used for
initializing local ones with the same name and type, but I am not sure about
the details yet.

I also recommend checking the files csmodule.c and InOut/rtalsa.c.
csmodule.c already has usable documentation on a new plugin interface
that is used by the real time audio modules, and rtalsa.c is an example
of how such a module can be made (it may have bugs, though, as it tends
to crash at the end of performance, but until that point the ALSA plugin
seems to work).


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2005-02-02 20:06
Fromsteven yi
SubjectRe: [Cs-dev] Question on CVS changes
Hi Istvan,

Thanks for the explanation.  After a little more looking around, I have 
a few more questions =) :

-for your module format, you are proposing a change that would make all 
modules generic, so there is no difference between a opcode library, an 
ftable library, or audio plugin library, it's a matter of what the 
module wants to do when csoundModuleCreate or csoundModuleInit is 
called, whether to add opcodes, ftables, commandline flags, etc.  Is 
this correct?

-Not having looked too deeply, it seems that csoundModuleCreate and 
csoundModuleInit are very similar; perhaps I am not understanding the 
order of operations, but is there a case where the code in 
csoundModuleInit couldn't just be done in csoundModuleCreate?  Is this 
here to have messages out to the console before other internal engine 
messages?

-for dynamically added configuration options, it seems that they should 
be used strictly for very machine-dependent or architecture dependent 
options, and likely to be only used within .csoundrc files or in 
testing.  Otherwise there is the sense that CSD's will become less and 
less portable.  Is the use of -+ configuration options with .csoundrc 
what you envision with this?

Thanks,
steven


Istvan Varga wrote:
> steven yi wrote:
> 
>> I was taking a look at the new CVS changes today and was wondering 
>> about the "static  void    **global_cfg_db" and is this temporarily a 
>> static global variable to be moved into the ENVIRON struct later?  I 
>> haven't looked at this enough this morning to figure out what purpose 
>> it has being global.
> 
> 
> It is not used yet, but is really a global and is not supposed to be in
> ENVIRON. However, it does have its counterpart in ENVIRON, named
> 'void **cfgVariableDB'. The difference between the two variables is
> that the static global one is for use by the host application, and
> the other in ENVIRON is specific to Csound instances.
> More about this below.
> 
>> Also, for the audio I/O as plugins, it seems to load all, then check 
>> for a globalVariable _RTAUDIO to decide which plugin to enable.  This 
>> is hardcoded in csound.c to PortAudio for the timebeing, or is there a 
>> configuration flag I am not seeing to enable other plugins? Is there a 
>> way to query/list what audio plugins are available?  (I haven't had a 
>> chance to compile yet, so apologies if this is already there, but I 
>> haven't found it in code yet).
> 
> 
> You can select the RT audio plugin with the command line option
> '-+rtaudio=MODULENAME', where MODULENAME is something like 'alsa'
> or 'portaudio'. Currently there are two modules, librtalsa.so and
> librtpa.so, both print a message when found and loaded by Csound:
> 
>   "Localisation of messages is disabled, using default language.
>    PortAudio real-time audio module for Csound by John ffitch
>    ALSA real-time audio module for Csound by Istvan Varga
>    0dBFS level = 32767.0
>    [...]"
> 
>> And could you discuss the cfgvar file design and how the different 
>> global/non-global functions relate, when each is designed to be used?
> 
> 
> The files cfgvar.c/cfgvar.h do not have documentation yet (I will write
> it soon), but the main purpose is to allow for dynamic creation of Csound
> options, without the need to edit argdecode.c. So, for example, a plugin
> can register its own command line options, but there are other, more
> advanced uses.
> 
> Here is a short explanation of the code in csoundCreate():
> 
>   int   max_len = 21;
> 
> This is the maximum length (+1 for the null byte at the end) of the
> string option to be created.
> 
>   csoundCreateGlobalVariable(csound, "_RTAUDIO", (size_t) max_len);
> 
> Allocates a named dynamic "global" variable for Csound instance
> 'csound', with max_len bytes of space (which is cleared to zero).
> Note that this function has a return value to report errors (such
> as an already used name), but I did not bother to check it.
> 
>   s = csoundQueryGlobalVariable(csound, "_RTAUDIO");
> 
> This is how you can access the newly created "variable". s will now
> contain a pointer to 21 bytes of allocated memory (or NULL if the
> specified name is invalid, but we have just created it).
> 
>   strcpy(s, "PortAudio");
> 
> Sets csound->"_RTAUDIO"="PortAudio"
> 
>   csoundCreateConfigurationVariable(csound, "rtaudio", s,
>                                     CSOUNDCFG_STRING, 0, NULL, &max_len,
>                                     "Real time audio module name", NULL);
> 
> Registers a local (that is, specific to 'csound') configuration variable
> named "rtaudio" (that's where that -+rtaudio=MODULENAME comes from), of
> which the value is stored at 's', of type CSOUNDCFG_STRING (an array of
> characters), with zero flags, no minimum value (a minimum value only makes
> sense for integer and float types), a maximum length of max_len=21 bytes,
> short description is "Real time audio module name", and there is no long
> description.
> Now type './csound --help', and notice this:
> 
>   "[...]
>    --help                  Long help
> 
>    -+rtaudio= (max. length = 20 characters)
>            Real time audio module name
> 
>    Short form:
>    [...]"
> 
> You can find out more about the system by having a look at 
> cfgvar.c/cfgvar.h.
> 
> So far, only 'local' configuration variables were dealt with. These are
> created from within an instance of Csound. 'Global' configuration variables
> are created by the host application, and could possible be used for
> initializing local ones with the same name and type, but I am not sure 
> about
> the details yet.
> 
> I also recommend checking the files csmodule.c and InOut/rtalsa.c.
> csmodule.c already has usable documentation on a new plugin interface
> that is used by the real time audio modules, and rtalsa.c is an example
> of how such a module can be made (it may have bugs, though, as it tends
> to crash at the end of performance, but until that point the ALSA plugin
> seems to work).
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2005-02-02 21:09
FromIstvan Varga
SubjectRe: [Cs-dev] Question on CVS changes
steven yi wrote:

> -for your module format, you are proposing a change that would make all 
> modules generic, so there is no difference between a opcode library, an 
> ftable library, or audio plugin library, it's a matter of what the 
> module wants to do when csoundModuleCreate or csoundModuleInit is 
> called, whether to add opcodes, ftables, commandline flags, etc.  Is 
> this correct?

Yes, the module has access to the API, and it can be used for any
purpose.

> -Not having looked too deeply, it seems that csoundModuleCreate and 
> csoundModuleInit are very similar; perhaps I am not understanding the 
> order of operations, but is there a case where the code in 
> csoundModuleInit couldn't just be done in csoundModuleCreate?  Is this 
> here to have messages out to the console before other internal engine 
> messages?

There is a difference in the time at which the functions are called.
csoundModuleCreate is called very early from csoundCreate(), while the
other function is called just before orchestra translation. So, for
example if you want to add a new option, then it should be done from
csoundModuleCreate, as by the time csoundModuleInit is called the
options will have been already parsed. On the other hand, you want to
add new opcodes from csoundModuleInit, because doing this earlier
would result in your opcodes being overwritten by standard Csound
opcodes as the list is created.
Having csoundModuleCreate is required for identifying the library
as a plugin (although it may very well just contain a 'return 0;'),
however, any other interface functions are optional. This also
allows for later extension with new functions, if there are reasons
to do so, without having to change existing plugins.

> -for dynamically added configuration options, it seems that they should 
> be used strictly for very machine-dependent or architecture dependent 
> options, and likely to be only used within .csoundrc files or in 
> testing.  Otherwise there is the sense that CSD's will become less and 
> less portable.  Is the use of -+ configuration options with .csoundrc 
> what you envision with this?

Of course, having any options in CSD files not related to the CSD itself
(such as a -F flag for an included MIDI file, -L stdin for an orchestra
that reads events from the standard input etc.) is generally a bad idea.
Options like buffer sizes, device names, message level, --sched and others
are to be specified by the user; a setting that is preferred by the
author of the CSD may not be optimal for other people.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net