| This is an automatic reply. Feel free to send additional
mail, as only this one notice will be generated. The following
is a prerecorded message, sent for root
I am away from Bath again; Boston again I am afraid. I expect to
return on 26 August 1998. I hope to have access to e-mail but in case
of difficulty you could mail Audrey on jpff=aff@maths.bath.ac if you
think she could help.
The Computing Group secretary, Angela, can be reached on
amc@maths.bath.ac.uk and she may also know how to contact me.
==John ff
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11039;
9 Jul 98 19:32 BST
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa07387;
9 Jul 98 19:32 BST
Received: (qmail 27758 invoked from network); 9 Jul 1998 18:32:00 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 9 Jul 1998 18:32:00 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (TAA24938); Thu, 9 Jul 1998 19:28:09 +0100 (BST)
Received: from hermes.ex.ac.uk by maths.ex.ac.uk; Thu, 9 Jul 98 19:27:50 +0100
Received: from endeavor.flash.net [209.30.0.40] by hermes via ESMTP (TAA24738); Thu, 9 Jul 1998 19:27:44 +0100 (BST)
Received: from flash.net (fwasc5-231.flash.net [209.30.14.231])
by endeavor.flash.net (8.8.8/8.8.5) with ESMTP id NAA18320
for ; Thu, 9 Jul 1998 13:27:45 -0500 (CDT)
Message-Id: <35A50BC9.CB4EDF21@flash.net>
Date: Thu, 09 Jul 1998 13:28:25 -0500
From: pete moss
Organization: pete moss GmbH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
Mime-Version: 1.0
To: csound
Subject: Re: About randomness in Csound, and a suggestion...
References: <199807091038.UAA01001@gair.firstpr.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
> and time is used to seed the C library's PRNG. Note that the output
> of this PRNG could also be affected by other programs running on the
> computer, which could be seeding the PRNG and taking numbers from it
> - either of which would affect the numbers being returned to the
> various points in Csound which call rand() to get pseudo random
> numbers.
>
how is this possible? how can a function in one program call a function in
another program, unless designed to do so? csound doesnt use a common dll for
the rand() function does it?
also, i think the seed opcode should be put in the manual, as i had the same
problem that i discussed on the list a year ago, and just now i heard of the
seed opcode.
pete
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11668;
9 Jul 98 22:35 BST
Received: from mercury.bath.ac.uk by stork.maths.Bath.AC.UK id aa17801;
9 Jul 98 22:35 BST
Received: (qmail 8517 invoked from network); 9 Jul 1998 21:35:32 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by mercury.bath.ac.uk with SMTP; 9 Jul 1998 21:35:32 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (WAA25653); Thu, 9 Jul 1998 22:31:53 +0100 (BST)
Received: from hermes.ex.ac.uk by maths.ex.ac.uk; Thu, 9 Jul 98 22:31:35 +0100
Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (WAA25041); Thu, 9 Jul 1998 22:31:29 +0100 (BST)
Received: (qmail 27096 invoked from network); 9 Jul 1998 21:31:31 -0000
Received: from unknown (HELO cableinet.co.uk) (194.117.146.42)
by jaguars with SMTP; 9 Jul 1998 21:31:31 -0000
Message-Id: <35A53551.AE2C23A8@cableinet.co.uk>
Date: Thu, 09 Jul 1998 22:25:37 +0100
From: Richard Dobson
Organization: Composers Desktop project
X-Mailer: Mozilla 4.04 [en] (Win95; I)
Mime-Version: 1.0
To: csound
Subject: Re: About randomness in Csound, and a suggestion...
References: <199807091038.UAA01001@gair.firstpr.com.au> <35A50BC9.CB4EDF21@flash.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
No. The rand function is a standard library ~algorithm~ in C (and in languages
generally), it is not any sort of object at the system or machine level
(discounting esoteric machines with hardware-based noise generation).
Output form the standard C library rand() routine is always the same, fully
determined by the particular formula used, usually the 'linear congruential'
algorithm. There is an interesting discussion of this in the book 'Numerical
recipes in C', which explains why this algorithm is not as wonderful as one
might like. It has the advantage of computational economy, however.
Most programs seed the random number generator from the system time, so that the
result is different for each execution of the program. This is exactly what
Csound does (using the library funtion srand(seed)).
So, indeed, to get a sequence of identical runs (or just to escape from the
default), any opcode which uses rand() needs to allow for a user-specified seed.
However, it is also true to say that, within a program, each call to the rand
function, from wherever, gets the next number in the sequence, so that so long
as one opcode enables seeding (even if the result is not used), that will affect
all other opcodes which call rand().
Richard Dobson
pete moss wrote:
>
> > and time is used to seed the C library's PRNG. Note that the output
> > of this PRNG could also be affected by other programs running on the
> > computer, which could be seeding the PRNG and taking numbers from it
> > - either of which would affect the numbers being returned to the
> > various points in Csound which call rand() to get pseudo random
> > numbers.
> >
>
> how is this possible? how can a function in one program call a function in
> another program, unless designed to do so? csound doesnt use a common dll for
> the rand() function does it?
>
> also, i think the seed opcode should be put in the manual, as i had the same
> problem that i discussed on the list a year ago, and just now i heard of the
> seed opcode.
>
> pete
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11708;
9 Jul 98 23:00 BST
Received: from mercury.bath.ac.uk by stork.maths.Bath.AC.UK id aa19262;
9 Jul 98 23:00 BST
Received: (qmail 9418 invoked from network); 9 Jul 1998 22:00:53 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by mercury.bath.ac.uk with SMTP; 9 Jul 1998 22:00:53 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (WAA02305); Thu, 9 Jul 1998 22:57:48 +0100 (BST)
Received: from hermes.ex.ac.uk by maths.ex.ac.uk; Thu, 9 Jul 98 22:57:23 +0100
Received: from root@ppp-109-5.villette.club-internet.fr [194.158.109.5] by hermes via ESMTP (WAA19458); Thu, 9 Jul 1998 22:57:05 +0100 (BST)
From: intent@club-internet.fr
Received: from localhost (intent@localhost [127.0.0.1])
by localhost.localdomain (8.8.7/8.8.7) with SMTP id XAA05829
for ; Thu, 9 Jul 1998 23:55:23 +0200
Date: Thu, 9 Jul 1998 23:55:23 +0200 (CEST)
X-Sender: intent@localhost
To: csound
Subject: MIDI timing irregularities
In-Reply-To: <35A50BC9.CB4EDF21@flash.net>
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Hello, I'm a new Csounder and I experiment some timing irregularities with
the MIDI OUT opcodes.
Another strange thing is that when I compile a orc/sco with " -Q0 -n "
or " -Q0 -o /dev/null " as it is indicated in the Linux-midiOUT text file
joigning the 3.48X Linux distribution, all the notes of the score are
read at the same time with no more regards at their placement.
I have to maintain "-odevaudio" for the things to work.
Is there a way to solve these problems ? In a score where I
have both a bass drum on the beat (a simple soundin) and a MIDI instrument
off the beat, the both together are not all right.
Francois Ernst.
Thanks to all the Csound Community.
PS: I have OSS Linux and a SB64 gold, RH5 linux 2.0.32 on a 233mhz PPRo/64
megs
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12862;
10 Jul 98 10:25 BST
Received: from mercury.bath.ac.uk by stork.maths.Bath.AC.UK id aa01054;
10 Jul 98 10:25 BST
Received: (qmail 13154 invoked from network); 10 Jul 1998 09:22:37 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by mercury.bath.ac.uk with SMTP; 10 Jul 1998 09:22:37 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (KAA26584); Fri, 10 Jul 1998 10:17:43 +0100 (BST)
Received: from hermes.ex.ac.uk by maths.ex.ac.uk; Fri, 10 Jul 98 10:17:25 +0100
Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (KAA19611); Fri, 10 Jul 1998 10:17:19 +0100 (BST)
Received: (qmail 18988 invoked from network); 10 Jul 1998 09:17:17 -0000
Received: from unknown (HELO cableinet.co.uk) (194.117.146.17)
by jaguars with SMTP; 10 Jul 1998 09:17:17 -0000
Message-Id: <35A5DABB.FCAD5FE9@cableinet.co.uk>
Date: Fri, 10 Jul 1998 10:11:23 +0100
From: Richard Dobson
Organization: Composers Desktop project
X-Mailer: Mozilla 4.04 [en] (Win95; I)
Mime-Version: 1.0
To: Michael Gogins
Cc: Jim_Ravan@avid.com, csound@maths.ex.ac.uk
Subject: Re: Making Csound re-entrant (was Re: compiler)
References: <003501bdab98$bc058920$4a8256d1@axe>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Michael Gogins wrote:
[snip]
>
> I want to avoid unnecessary work, and I have no intention of doing anything
> more than the bare minimum required to get Csound re-entrant in the first
> phase, and working as a transform filter in the second phase.
This was more-or-less the situation I reached last year. I simply created an
'init' function for each module, which was called in main(). I was able to run
several orchestras over and over, without errors or memory leaks. That was using
Csound V.3.45. John Fitch has preserved these init functions in the current
sources, under #ifdef RESET. So we should be able to leverage that stuff and get
something going farirly quickly.
Perhaps we need to fix on a particular working version, say 3.478, or whichever,
and settle on some core test orchetstras which we all use to validate the
re-entrancy code. With care, the Winsound GUI front end can work adequately to
drive everything; though at some point a more Windows-friendly (and simpler...)
version might haver to be created just for this task.
Re plugins: although they are not ~required~ to run in real time, most users
will want to wherever possible. There may therefore be a case for some strategic
optimisations in assembler, given that plugins are utterly platform-specific. I
am thinking, for example, of the places where blocks of data are converted from
floats or doubles to shorts. This is actually quite a slow operation, as the
cast (under VC++) involves a function call to reconfigure the fpu to truncate,
instead of round). By writing an assembler routine to do this block casting,
significant speedups can be made (factor of three, from my recent experiments).
There is some interesting information about this on Intel's web site (in
relation to their own C++ compiler - plugs into Developer Studio - which I am
tempted to try, but its another 100MBytes to put somewhere...)
Richard Dobson
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12875;
10 Jul 98 10:34 BST
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa01570;
10 Jul 98 10:34 BST
Received: (qmail 25209 invoked from network); 10 Jul 1998 09:34:24 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 10 Jul 1998 09:34:24 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (KAA10917); Fri, 10 Jul 1998 10:18:10 +0100 (BST)
Received: from hermes.ex.ac.uk by maths.ex.ac.uk; Fri, 10 Jul 98 10:17:25 +0100
Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (KAA19611); Fri, 10 Jul 1998 10:17:19 +0100 (BST)
Received: (qmail 18988 invoked from network); 10 Jul 1998 09:17:17 -0000
Received: from unknown (HELO cableinet.co.uk) (194.117.146.17)
by jaguars with SMTP; 10 Jul 1998 09:17:17 -0000
Message-Id: <35A5DABB.FCAD5FE9@cableinet.co.uk>
Date: Fri, 10 Jul 1998 10:11:23 +0100
From: Richard Dobson
Organization: Composers Desktop project
X-Mailer: Mozilla 4.04 [en] (Win95; I)
Mime-Version: 1.0
To: Michael Gogins
Cc: Jim_Ravan@avid.com, csound@maths.ex.ac.uk
Subject: Re: Making Csound re-entrant (was Re: compiler)
References: <003501bdab98$bc058920$4a8256d1@axe>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Michael Gogins wrote:
[snip]
>
> I want to avoid unnecessary work, and I have no intention of doing anything
> more than the bare minimum required to get Csound re-entrant in the first
> phase, and working as a transform filter in the second phase.
This was more-or-less the situation I reached last year. I simply created an
'init' function for each module, which was called in main(). I was able to run
several orchestras over and over, without errors or memory leaks. That was using
Csound V.3.45. John Fitch has preserved these init functions in the current
sources, under #ifdef RESET. So we should be able to leverage that stuff and get
something going farirly quickly.
Perhaps we need to fix on a particular working version, say 3.478, or whichever,
and settle on some core test orchetstras which we all use to validate the
re-entrancy code. With care, the Winsound GUI front end can work adequately to
drive everything; though at some point a more Windows-friendly (and simpler...)
version might haver to be created just for this task.
Re plugins: although they are not ~required~ to run in real time, most users
will want to wherever possible. There may therefore be a case for some strategic
optimisations in assembler, given that plugins are utterly platform-specific. I
am thinking, for example, of the places where blocks of data are converted from
floats or doubles to shorts. This is actually quite a slow operation, as the
cast (under VC++) involves a function call to reconfigure the fpu to truncate,
instead of round). By writing an assembler routine to do this block casting,
significant speedups can be made (factor of three, from my recent experiments).
There is some interesting information about this on Intel's web site (in
relation to their own C++ compiler - plugs into Developer Studio - which I am
tempted to try, but its another 100MBytes to put somewhere...)
Richard Dobson
|