To start with, I really, really appreciate all the excellent work you have 
put into Csound.

The bus interface permits external software (API clients) to directly get 
and set Csound variables -- is that correct? If so I think it is a very good 
idea, but the word 'bus' is misleading.

I suggest replacing rand() with csound_rand() -- either Whittle's code or 
the Mersenne Twister (I would prefer the latter since I think it is more 
random and I think we can afford the small additional overhead). Perhaps it 
could be an option to the opcode, which implementation to use.

I am not trying to get CsoundVST as a whole into libcsound, precisely for 
the reason you cite -- increased dependencies. I am only trying to get a 
Python wrapping for libcsound into libcsound. No boost or FLTK!

The Python dependency already exists in the build system for those who build 
Csound, and for those who not have Python, the interface code will just sit 
there and do nothing. It should not prevent libcsound from either linking or 
running on systems that do not have Python.

The reason for this is that my compositional productivity with Python has 
been significantly higher coding in Python than in any other language I've 
used, and I'd like to see this benefit made more accessible for other 
csounders. Plus, Python has a truly rich set of libraries that would add 
significantly to what can be done with Csound.

If this were done, I might be able to factor stuff out of CsoundVST so it 
would be easier to use it as the default FLTK user interface for Csound 
(i.e., no "Silence" classes or boost). My algo-comp stuff would go into a 
separate, independent Python extension.

I know people might say you can code scores in Python and just exec Csound, 
but that's what I used to do, and the way I work now is a lot better. 
Keeping track of one file per piece instead of 2 or 3 files ends up making a 
lot of difference in terms of production efficiency.


After thinking about plugin metadata, I think it is a bad idea. It is better 
to define a standard directory structure and format, consistent with the 
existing excellent manual, for more extensive plugin documentation. It 
should be the case that when users install plugins, they can rebuild the 
manual and the plugin pages automatically get built into the manual. If 
that's too hard, then a standard HTML format for plugin pages should be 
defined, consistent with the manual. Some Javascript should enable a kind of 
integration with the existing manual.

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.

Regards,
Mike

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


> Michael Gogins wrote:
>
>> Istvan, what do you think needs to be done before a release?
>
> I do not really have many ideas at this time, and that is one
> of the reasons why I keep asking if anyone else does.
> Currently, one unfinished project is the bus interface, but
> it seems from the relative lack of comments that there is not
> much interest or demand for it; so, I may consider removing it
> for now, keeping only the two opcodes 'chnget' and 'chnset' for
> private use by the orchestra, but no API functions or extra
> features.
> Another issue is replacing the use of rand() in various opcodes
> with an API function that generates random numbers in a more
> portable way, and without the problems associated with rand()
> when used from multiple instances at the same time. This is not
> really important, but it changes the output of the opcodes, so
> is better done before the release.
> It may also be worth to clean up the use of temporary files,
> but this is a low priority issue too.
> What is definitely to be done before a release is finishing
> the API so that all incompatible changes (even if something
> minor like renaming functions, changing the layout of structures,
> etc.) are done now. As there are no comments on this issue,
> it is tempting to leave everything as it is, but I am afraid
> that people will start to complain when the interface is already
> considered frozen and thus it is too late.
> I still do not have plans on changes related to the "plugin
> metadata" issue, because all the ideas so far are ones that I
> either do not like, require too much changes, or are just not
> sufficiently well defined to implement.
>
>> I did have another suggestion which I will repeat, getting a
> > Python binding to run Csound, create and edit scores, and so on
> > into the non-CsoundVST version of csound 5. As I see it, the main
> > obstacle to just moving CsoundVST into csound5's main library is
> > the boost stuff in the algorithmic composition classes.
>
> But why is it absolutely necessary to integrate CsoundVST into
> libcsound ? I prefer having the library small and simple with as
> few compile problems and external dependencies as possible;
> CsoundVST - or anything else - can always just wrap the main
> library.
>
>> My questions are:
>>
>> Do all the utilities run in 32 and 64 bits? I only care if they
> > run inside Csound, I don't care about the standalone invocation.
>
> In most cases, it does not matter if the utilities are running from
> csound (with -U) or as standalone, because almost all (with the
> possible exception of some rarely used ones) have already been
> converted to plugins. I think the more important utilities should
> work using both 32 and 64 bit floats, but if you find one that
> does not, then it should not be hard to fix the bug.
>
>> Is there anything we can do to get FLTK working simultaneously
> > for Ftable display and for FLTK widgets?
>
> I would prefer moving the FLTK table displays out of the engine
> as well, leaving only the old ASCII and PostScript code as built-in.
> It may be possible to integrate the display and widget code into
> a single plugin that uses the API calls to register all the MakeGraph
> and other functions, and having all FLTK stuff in one place again
> might allow for easier fixing of the problems related to using
> displays and widgets at the same time.
> Also, not having FLTK displays in the main library means no
> dependencies on FLTK or C++ at all, and the functions related to
> FLTK locking could be removed from the API as well. I do not know,
> though, if this is a problem for CsoundVST that also uses FLTK.
>
>
> -------------------------------------------------------
> 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

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

For what it's worth, I am totally in agreement with Michael on the 
python incorporation. I think it increases the scope of csound 
usefullness for unusual live or real time situations immensly.

Iain

Michael Gogins wrote:
> To start with, I really, really appreciate all the excellent work you 
> have put into Csound.
> 
> The bus interface permits external software (API clients) to directly 
> get and set Csound variables -- is that correct? If so I think it is a 
> very good idea, but the word 'bus' is misleading.
> 
> I suggest replacing rand() with csound_rand() -- either Whittle's code 
> or the Mersenne Twister (I would prefer the latter since I think it is 
> more random and I think we can afford the small additional overhead). 
> Perhaps it could be an option to the opcode, which implementation to use.
> 
> I am not trying to get CsoundVST as a whole into libcsound, precisely 
> for the reason you cite -- increased dependencies. I am only trying to 
> get a Python wrapping for libcsound into libcsound. No boost or FLTK!
> 
> The Python dependency already exists in the build system for those who 
> build Csound, and for those who not have Python, the interface code will 
> just sit there and do nothing. It should not prevent libcsound from 
> either linking or running on systems that do not have Python.
> 
> The reason for this is that my compositional productivity with Python 
> has been significantly higher coding in Python than in any other 
> language I've used, and I'd like to see this benefit made more 
> accessible for other csounders. Plus, Python has a truly rich set of 
> libraries that would add significantly to what can be done with Csound.
> 
> If this were done, I might be able to factor stuff out of CsoundVST so 
> it would be easier to use it as the default FLTK user interface for 
> Csound (i.e., no "Silence" classes or boost). My algo-comp stuff would 
> go into a separate, independent Python extension.
> 
> I know people might say you can code scores in Python and just exec 
> Csound, but that's what I used to do, and the way I work now is a lot 
> better. Keeping track of one file per piece instead of 2 or 3 files ends 
> up making a lot of difference in terms of production efficiency.
> 
> 
> After thinking about plugin metadata, I think it is a bad idea. It is 
> better to define a standard directory structure and format, consistent 
> with the existing excellent manual, for more extensive plugin 
> documentation. It should be the case that when users install plugins, 
> they can rebuild the manual and the plugin pages automatically get built 
> into the manual. If that's too hard, then a standard HTML format for 
> plugin pages should be defined, consistent with the manual. Some 
> Javascript should enable a kind of integration with the existing manual.
> 
> 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.
> 
> Regards,
> Mike
> 
> ----- Original Message ----- From: "Istvan Varga" 
> To: 
> Sent: Sunday, September 25, 2005 6:35 AM
> Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 status
> 
> 
>> Michael Gogins wrote:
>>
>>> Istvan, what do you think needs to be done before a release?
>>
>>
>> I do not really have many ideas at this time, and that is one
>> of the reasons why I keep asking if anyone else does.
>> Currently, one unfinished project is the bus interface, but
>> it seems from the relative lack of comments that there is not
>> much interest or demand for it; so, I may consider removing it
>> for now, keeping only the two opcodes 'chnget' and 'chnset' for
>> private use by the orchestra, but no API functions or extra
>> features.
>> Another issue is replacing the use of rand() in various opcodes
>> with an API function that generates random numbers in a more
>> portable way, and without the problems associated with rand()
>> when used from multiple instances at the same time. This is not
>> really important, but it changes the output of the opcodes, so
>> is better done before the release.
>> It may also be worth to clean up the use of temporary files,
>> but this is a low priority issue too.
>> What is definitely to be done before a release is finishing
>> the API so that all incompatible changes (even if something
>> minor like renaming functions, changing the layout of structures,
>> etc.) are done now. As there are no comments on this issue,
>> it is tempting to leave everything as it is, but I am afraid
>> that people will start to complain when the interface is already
>> considered frozen and thus it is too late.
>> I still do not have plans on changes related to the "plugin
>> metadata" issue, because all the ideas so far are ones that I
>> either do not like, require too much changes, or are just not
>> sufficiently well defined to implement.
>>
>>> I did have another suggestion which I will repeat, getting a
>>
>> > Python binding to run Csound, create and edit scores, and so on
>> > into the non-CsoundVST version of csound 5. As I see it, the main
>> > obstacle to just moving CsoundVST into csound5's main library is
>> > the boost stuff in the algorithmic composition classes.
>>
>> But why is it absolutely necessary to integrate CsoundVST into
>> libcsound ? I prefer having the library small and simple with as
>> few compile problems and external dependencies as possible;
>> CsoundVST - or anything else - can always just wrap the main
>> library.
>>
>>> My questions are:
>>>
>>> Do all the utilities run in 32 and 64 bits? I only care if they
>>
>> > run inside Csound, I don't care about the standalone invocation.
>>
>> In most cases, it does not matter if the utilities are running from
>> csound (with -U) or as standalone, because almost all (with the
>> possible exception of some rarely used ones) have already been
>> converted to plugins. I think the more important utilities should
>> work using both 32 and 64 bit floats, but if you find one that
>> does not, then it should not be hard to fix the bug.
>>
>>> Is there anything we can do to get FLTK working simultaneously
>>
>> > for Ftable display and for FLTK widgets?
>>
>> I would prefer moving the FLTK table displays out of the engine
>> as well, leaving only the old ASCII and PostScript code as built-in.
>> It may be possible to integrate the display and widget code into
>> a single plugin that uses the API calls to register all the MakeGraph
>> and other functions, and having all FLTK stuff in one place again
>> might allow for easier fixing of the problems related to using
>> displays and widgets at the same time.
>> Also, not having FLTK displays in the main library means no
>> dependencies on FLTK or C++ at all, and the functions related to
>> FLTK locking could be removed from the API as well. I do not know,
>> though, if this is a problem for CsoundVST that also uses FLTK.
>>
>>
>> -------------------------------------------------------
>> 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
> 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

Michael Gogins wrote:

> I suggest replacing rand() with csound_rand() -- either Whittle's code 
> or the Mersenne Twister (I would prefer the latter since I think it is 
> more random and I think we can afford the small additional overhead). 
> Perhaps it could be an option to the opcode, which implementation to use.

I have added these new API functions:

   /**
    * Simple linear congruential random number generator:
    *   (*seedVal) = (*seedVal) * 742938285 % 2147483647
    * the initial value of *seedVal must be in the range 1 to 2147483646.
    * Returns the next number from the pseudo-random sequence,
    * in the range 1 to 2147483646.
    */
   PUBLIC int csoundRand31(int *seedVal);

   /**
    * Initialise Mersenne Twister (MT19937) random number generator,
    * using 'keyLength' unsigned 32 bit values from 'initKey' as seed.
    * If the array is NULL, the length parameter is used for seeding.
    */
   PUBLIC void csoundSeedRandMT(CsoundRandMTState *p,
                                const uint32_t *initKey, uint32_t keyLength);

   /**
    * Returns next random number from MT19937 generator.
    * The PRNG must be initialised first by calling csoundSeedRandMT().
    */
   PUBLIC uint32_t csoundRandMT(CsoundRandMTState *p);

the CsoundRandMTState type is:

   typedef struct CsoundRandMTState_ {
     int       mti;
     uint32_t  mt[624];
   } CsoundRandMTState;

All uses of rand() have been removed. The following opcodes now use a
global (per instance of Csound) Mersenne Twister, and can be seeded
with the 'seed' opcode:

   unirand, linrand, trirand, exprand, bexprnd, cauchy, pcauchy,
   poisson, gauss, weibull, betarand

These opcodes use the 31 bit generator, also global for an instance
of Csound and seedable with the 'seed' opcode:

   bbcut, grain, adsynt, phasorbnk, noise, shaker, sndwarp,
   sndwarpst, ATSaddnz, ATSsinnoi, adsynt2

   also the various physical model opcodes (marimba, cabasa,
   sekere, singwave, etc. - there are quite a few)

In addition, the widget opcodes that allow for randomly changing
the style of displayed widgets now use a 31 bit PRNG that is always
seeded from the current time.

The 31 bit generator may be changed to use a different multiplier or
even a different algorithm if requested, and also the selection of
PRNG in the various opcodes can be changed. In fact, the MT could be
used in all, I only limited it to the "x-class" random opcodes to
make those more predictable (that is, for example to prevent the output
of unirand from changing if a grain opcode is added elsewhere).
Does anyone suggest changes ?



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> I suggest replacing rand() with csound_rand() -- either Whittle's code 
> or the Mersenne Twister (I would prefer the latter since I think it is 
> more random and I think we can afford the small additional overhead). 
> Perhaps it could be an option to the opcode, which implementation to use.

I have added these new API functions:

   /**
    * Simple linear congruential random number generator:
    *   (*seedVal) = (*seedVal) * 742938285 % 2147483647
    * the initial value of *seedVal must be in the range 1 to 2147483646.
    * Returns the next number from the pseudo-random sequence,
    * in the range 1 to 2147483646.
    */
   PUBLIC int csoundRand31(int *seedVal);

   /**
    * Initialise Mersenne Twister (MT19937) random number generator,
    * using 'keyLength' unsigned 32 bit values from 'initKey' as seed.
    * If the array is NULL, the length parameter is used for seeding.
    */
   PUBLIC void csoundSeedRandMT(CsoundRandMTState *p,
                                const uint32_t *initKey, uint32_t keyLength);

   /**
    * Returns next random number from MT19937 generator.
    * The PRNG must be initialised first by calling csoundSeedRandMT().
    */
   PUBLIC uint32_t csoundRandMT(CsoundRandMTState *p);

the CsoundRandMTState type is:

   typedef struct CsoundRandMTState_ {
     int       mti;
     uint32_t  mt[624];
   } CsoundRandMTState;

All uses of rand() have been removed. The following opcodes now use a
global (per instance of Csound) Mersenne Twister, and can be seeded
with the 'seed' opcode:

   unirand, linrand, trirand, exprand, bexprnd, cauchy, pcauchy,
   poisson, gauss, weibull, betarand

These opcodes use the 31 bit generator, also global for an instance
of Csound and seedable with the 'seed' opcode:

   bbcut, grain, adsynt, phasorbnk, noise, shaker, sndwarp,
   sndwarpst, ATSaddnz, ATSsinnoi, adsynt2

   also the various physical model opcodes (marimba, cabasa,
   sekere, singwave, etc. - there are quite a few)

In addition, the widget opcodes that allow for randomly changing
the style of displayed widgets now use a 31 bit PRNG that is always
seeded from the current time.

The 31 bit generator may be changed to use a different multiplier or
even a different algorithm if requested, and also the selection of
PRNG in the various opcodes can be changed. In fact, the MT could be
used in all, I only limited it to the "x-class" random opcodes to
make those more predictable (that is, for example to prevent the output
of unirand from changing if a grain opcode is added elsewhere).
Does anyone suggest changes ?

Istvan Varga wrote:

> All uses of rand() have been removed. The following opcodes now use a
> global (per instance of Csound) Mersenne Twister, and can be seeded
> with the 'seed' opcode:
> 
>   unirand, linrand, trirand, exprand, bexprnd, cauchy, pcauchy,
>   poisson, gauss, weibull, betarand

And also GEN21; forgot to include that.

> These opcodes use the 31 bit generator, also global for an instance
> of Csound and seedable with the 'seed' opcode:
> 
>   bbcut, grain, adsynt, phasorbnk, noise, shaker, sndwarp,
>   sndwarpst, ATSaddnz, ATSsinnoi, adsynt2
> 
>   also the various physical model opcodes (marimba, cabasa,
>   sekere, singwave, etc. - there are quite a few)

Also forgot to include: ~ in the score.