Csound Csound-dev Csound-tekno Search About

(Gabsoundin2) oops!! an important part of code is missing!

Date1997-02-18 06:26
FromGabriel Maldonado
Subject(Gabsoundin2) oops!! an important part of code is missing!
Sorry!
In the last message with the code os soundin2 UG, I have forgotten
an important part of the code i.e. the sndin2set() function. Also I
noted
that the beginning-of-line text space formatting was lost in the email
output.
So I have added the char '@' at the beginnig of each line of code.
Remove them
with a search-replace command of a text editor before compiling!
The complete code for soundin2 implementation is the following:

 SYNTAX: 
       
a1      soundin2   ifilcod, iskptim, iformat, kfrqratio 
a1, a2  soundin2   ifilcod, iskptim, iformat, kfrqratio 

the parameter kfrqratio allows interpolated and continuous pitch-shift
reading 
of the original soundfile. Also takes care of input - output sr
difference
during the processing.

////////////////// WARNING! in this source I often used the c++
////////////////// line comment sintax (  // comment ). 
////////////////// Replace with standard c comment ( /* comment */ ) 
////////////////// if necessary

////////////////// In the SOUNDIO.H file 
////////////////// you must REPLACE the old SOUNDIN structure
////////////////// as follows:
////////////////// (this change will not affect the normal behaviour
////////////////// of the old soundin unit)

@typedef    struct {
@    OPDS    h;
@    float    *r1, *r2, *r3, *r4, *ifilno, *iskptim, *iformat;
@   /* #ifdef GAB_RT */
@    float   *kfrqratio; //GAB new parameter
@    // work variables GAB
@    double  phase_gab;    // hidden work variables
@    double  fl_buf;
@    int    base_sample_gab;
@    int    initflag_gab;
@   /* #endif */
@    short    format, channel, nchnls, sampframsiz, filetyp, analonly,
endfile;
@    long    sr, audrem, framesrem, getframes;    /* bytes, frames,
frames */
@    AIFFDAT *aiffdata;
@    void    (*bytrev)();
@    FDCH    fdch;
@    char    *inbufp, *bufend;
@    char    inbuf[SNDINBUFSIZ*4];  //gab
@} SOUNDIN;



/////////////////
///////////////// in the SOUNDIN.C file you must ADD the following
///////////////// functions:
/////////////////

@void sndin2set(SOUNDIN *p)  //see SOUNDIO.H for GAB modification of
type SOUNDIN
@{
@        int    sinfd;
@        int  initphase; //gab 
@
@        if (p->fdch.fd != 0)   return;           /* if file already
open, rtn  */
@        p->channel = ALLCHNLS;                   /* reading all
channels       */
@        p->analonly = 0;
@        if ((sinfd = sndgetset(p)) >= 0) {       /* if soundinset
successful   */
@            p->fdch.fd = sinfd;              /*     store & log the
fd     */
@            fdrecord(&p->fdch);              /*     instr will close
later */
@        }
@        else initerror(errmsg);                  /* else just print the
errmsg */
@        p->base_sample_gab = 0;
@        p->fl_buf=0;
@        p->initflag_gab=1;
@        if (p->OUTOCOUNT == 1) initphase = 27;       
@        else                   initphase = 13;
@        p->phase_gab=initphase + *p->iskptim * p->sr;
@
@}
@
@
@void soundin2(SOUNDIN *p)  //see SOUNDIO.H for GAB modification of type
SOUNDIN
@{                           
@    /* Warning! use low k rate if tranpose factor is high:
@       for example, don't use ksmps > 5 if transpose factor is 16 */
@  
@    short       nsmps;
@    float       *r1, *r2, *r3, *r4;
@    int chnsout, n, ntogo;
@    
@    float ratio;         
@    long base;             
@    double *phase;         
@    double *fl_buf;
@    double phase_diff;
@    
@    base = p->base_sample_gab; 
@    phase = &(p->phase_gab);   
@    ratio = *(p->kfrqratio) * (p->sr/esr);   
@    fl_buf = &(p->fl_buf);
@
@    r1 = p->r1; r2 = p->r2;  r3 = p->r3; r4 = p->r4;
@    chnsout = p->OUTOCOUNT;
@    ntogo = ksmps;
@    if (p->endfile)  goto filend;
@    nsmps = (p->bufend - p->inbufp) / p->sampframsiz;
@    if (nsmps > ksmps) nsmps = ksmps;
@    ntogo -= nsmps;
@    if (p->initflag_gab) {
@        size_t frame_size; 
@        p->initflag_gab =0;
@        if (chnsout == 1) frame_size = sizeof(short);
@        else               frame_size = sizeof(long);    
@        lseek(p->fdch.fd, (long) *phase * frame_size , SEEK_SET );   
@        if ((n = sreadin(p->fdch.fd,p->inbuf,SNDINBUFSIZ * 4,p)) == 0)
{
@            p->endfile = 1;
@            if (ntogo) goto filend;
@            else       return;
@        }
@        p->bufend = p->inbuf + n + SNDINBUFSIZ/32 ;
@        if (ntogo > 0) {
@            if ((nsmps = n / p->sampframsiz) > ntogo) nsmps = ntogo; 
@            ntogo -= nsmps;    
@            goto shorts;
@        }    
@    }
@         
@    
@    switch (p->format) {
@      case AE_SHORT:        
@shorts:
@        switch(chnsout) {
@          case 1:
@          {
@            register short *base_addr;
@            register short *inbufp = (short *)p->inbufp;        
@            base_addr = inbufp;
@            *fl_buf -= (long) *fl_buf; 
@    
@            do {
@                phase_diff = *phase - (long) *phase;
@                *r1++ = (float) *inbufp + (float) ( *(inbufp+1) -
*inbufp) * phase_diff;        //gab
@                //*r1++ = (float) *inbufp;        
@                *phase += ratio;
@                *fl_buf += ratio;
@                inbufp = base_addr + (long) *fl_buf;
@            } while (--nsmps); 
@
@            if (inbufp >= ((short *)p->bufend)- SNDINBUFSIZ/32) {      
@     
@                lseek(p->fdch.fd, (long) *phase * sizeof(short),
SEEK_SET );
@                        
@                if ((n = sreadin(p->fdch.fd,p->inbuf,SNDINBUFSIZ *
4,p)) == 0) {
@                    p->endfile = 1;
@                    if (ntogo) goto filend;
@                    else return;
@                }
@                inbufp = (short *) p->inbuf;
@                p->bufend = p->inbuf + n + SNDINBUFSIZ/32 ;
@                if (ntogo > 0) {
@                    if ((nsmps = n / p->sampframsiz) > ntogo) nsmps =
ntogo; 
@                    ntogo -= nsmps;    
@                    goto shorts;    
@                }
@            }
@            p->inbufp = (char *) inbufp;
@          }
@          break;
@        
@          case 2:
@          {
@            register long *base_addr;
@            register long *inbufp = (long *)p->inbufp;
@            base_addr = inbufp;
@            *fl_buf -= (long) *fl_buf; 
@    
@            do {
@                register short left,right, left1, right1;
@                phase_diff = *phase - (long) *phase;
@                
@                left = (short) (*inbufp >> 16);
@                right =(short) ( *inbufp & 0xffff);
@                left1 = (short) (*(inbufp+1)>> 16);
@                right1 =(short) ( *(inbufp+1) & 0xffff);
@                
@                *r1++ = (float) left + (float) ( left1 - left) *
phase_diff;        
@                *r2++ = (float) right + (float) ( right1 - right) *
phase_diff;        
@                
@                *phase += ratio;
@                *fl_buf += ratio;
@                inbufp = base_addr + (long) *fl_buf;
@            } while (--nsmps); 
@                            
@            if (inbufp >= ((long *)p->bufend)- SNDINBUFSIZ/32 ) {      
@                lseek(p->fdch.fd, (long) *phase * sizeof(long) ,
SEEK_SET );
@                        
@                if ((n = sreadin(p->fdch.fd,p->inbuf,SNDINBUFSIZ *
4,p)) == 0) {
@                    p->endfile = 1;
@                    if (ntogo) goto filend;
@                    else return;
@                }
@                inbufp = (long *) p->inbuf;
@                p->bufend = p->inbuf + n + SNDINBUFSIZ/32;
@                if (ntogo > 0) {
@                    if ((nsmps = n / p->sampframsiz) > ntogo)
@                        nsmps = ntogo; 
@                    ntogo -= nsmps;    
@                    goto shorts;    
@                }
@            }
@            p->inbufp = (char *) inbufp;
@        
@          }
@          break;
@          default:
@          dies("soundin2 of %s not implemented",
getstrformat((int)p->format));
@        }
@        break;
@      default:
@        dies("soundin2 of %s not implemented",
getstrformat((int)p->format));
@      }
@    return;
@
@filend:
@    nsmps = ntogo;
@    switch(chnsout) {                   /* if past end of file, */
@    case 1:
@        do *r1++ = fzero;               /*    move in zeros     */
@        while (--nsmps);
@        break;
@    case 2:
@        do {
@            *r1++ = fzero;
@            *r2++ = fzero;
@        } while (--nsmps);
@        break;
@    }
@}

//////////////// At the beginning of the ENTRY.C file you must add 
//////////////// the following function declarations.....

@void    sndin2set(void*), soundin2(void*); //GAB

//////////////// ..... and the following line in the OENTRY opcodlst[]
//////////////// structure array declaration.

@{ "soundin2",S(SOUNDIN), 5,     "mmmm", "Sook",  sndin2set,NULL, 
soundin2 } //GAB

//////////////// That's all .... and good luck!


Gabriel Maldonado

g.maldonado@agora.stm.it


Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08370;
          18 Feb 97 13:34 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id an02474;
          18 Feb 97 13:38 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 09:16:17 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (JAA03427);
          Tue, 18 Feb 1997 09:12:17 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 09:11:58 GMT
Received: from agora.stm.it [194.20.43.1] by hermes via ESMTP (JAA03367);
          Tue, 18 Feb 1997 09:11:53 GMT
Received: from agora.stm.it.stm.it (agora.stm.it [194.20.43.1]) 
          by agora.stm.it (8.7.5/8.6.6) with SMTP id KAA23172;
          Tue, 18 Feb 1997 10:10:53 +0100 (ITA)
Message-Id: <33094B88.4F80@agora.stm.it>
Date: Tue, 18 Feb 1997 07:26:16 +0100
From: Gabriel Maldonado 
Reply-To: g.maldonado@agora.stm.it
Organization: Fantalogia
X-Mailer: Mozilla 3.01 (Win95; I)
Mime-Version: 1.0
To: jpff@maths.bath.ac.uk
Cc: Csound Mailing List 
Subject: (Gabsoundin2) oops!! an important part of code is missing!
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Sorry!
In the last message with the code os soundin2 UG, I have forgotten
an important part of the code i.e. the sndin2set() function. Also I
noted
that the beginning-of-line text space formatting was lost in the email
output.
So I have added the char '@' at the beginnig of each line of code.
Remove them
with a search-replace command of a text editor before compiling!
The complete code for soundin2 implementation is the following:

 SYNTAX: 
       
a1      soundin2   ifilcod, iskptim, iformat, kfrqratio 
a1, a2  soundin2   ifilcod, iskptim, iformat, kfrqratio 

the parameter kfrqratio allows interpolated and continuous pitch-shift
reading 
of the original soundfile. Also takes care of input - output sr
difference
during the processing.

////////////////// WARNING! in this source I often used the c++
////////////////// line comment sintax (  // comment ). 
////////////////// Replace with standard c comment ( /* comment */ ) 
////////////////// if necessary

////////////////// In the SOUNDIO.H file 
////////////////// you must REPLACE the old SOUNDIN structure
////////////////// as follows:
////////////////// (this change will not affect the normal behaviour
////////////////// of the old soundin unit)

@typedef    struct {
@    OPDS    h;
@    float    *r1, *r2, *r3, *r4, *ifilno, *iskptim, *iformat;
@   /* #ifdef GAB_RT */
@    float   *kfrqratio; //GAB new parameter
@    // work variables GAB
@    double  phase_gab;    // hidden work variables
@    double  fl_buf;
@    int    base_sample_gab;
@    int    initflag_gab;
@   /* #endif */
@    short    format, channel, nchnls, sampframsiz, filetyp, analonly,
endfile;
@    long    sr, audrem, framesrem, getframes;    /* bytes, frames,
frames */
@    AIFFDAT *aiffdata;
@    void    (*bytrev)();
@    FDCH    fdch;
@    char    *inbufp, *bufend;
@    char    inbuf[SNDINBUFSIZ*4];  //gab
@} SOUNDIN;



/////////////////
///////////////// in the SOUNDIN.C file you must ADD the following
///////////////// functions:
/////////////////

@void sndin2set(SOUNDIN *p)  //see SOUNDIO.H for GAB modification of
type SOUNDIN
@{
@        int    sinfd;
@        int  initphase; //gab 
@
@        if (p->fdch.fd != 0)   return;           /* if file already
open, rtn  */
@        p->channel = ALLCHNLS;                   /* reading all
channels       */
@        p->analonly = 0;
@        if ((sinfd = sndgetset(p)) >= 0) {       /* if soundinset
successful   */
@            p->fdch.fd = sinfd;              /*     store & log the
fd     */
@            fdrecord(&p->fdch);              /*     instr will close
later */
@        }
@        else initerror(errmsg);                  /* else just print the
errmsg */
@        p->base_sample_gab = 0;
@        p->fl_buf=0;
@        p->initflag_gab=1;
@        if (p->OUTOCOUNT == 1) initphase = 27;       
@        else                   initphase = 13;
@        p->phase_gab=initphase + *p->iskptim * p->sr;
@
@}
@
@
@void soundin2(SOUNDIN *p)  //see SOUNDIO.H for GAB modification of type
SOUNDIN
@{                           
@    /* Warning! use low k rate if tranpose factor is high:
@       for example, don't use ksmps > 5 if transpose factor is 16 */
@  
@    short       nsmps;
@    float       *r1, *r2, *r3, *r4;
@    int chnsout, n, ntogo;
@    
@    float ratio;         
@    long base;             
@    double *phase;         
@    double *fl_buf;
@    double phase_diff;
@    
@    base = p->base_sample_gab; 
@    phase = &(p->phase_gab);   
@    ratio = *(p->kfrqratio) * (p->sr/esr);   
@    fl_buf = &(p->fl_buf);
@
@    r1 = p->r1; r2 = p->r2;  r3 = p->r3; r4 = p->r4;
@    chnsout = p->OUTOCOUNT;
@    ntogo = ksmps;
@    if (p->endfile)  goto filend;
@    nsmps = (p->bufend - p->inbufp) / p->sampframsiz;
@    if (nsmps > ksmps) nsmps = ksmps;
@    ntogo -= nsmps;
@    if (p->initflag_gab) {
@        size_t frame_size; 
@        p->initflag_gab =0;
@        if (chnsout == 1) frame_size = sizeof(short);
@        else               frame_size = sizeof(long);    
@        lseek(p->fdch.fd, (long) *phase * frame_size , SEEK_SET );   
@        if ((n = sreadin(p->fdch.fd,p->inbuf,SNDINBUFSIZ * 4,p)) == 0)
{
@            p->endfile = 1;
@            if (ntogo) goto filend;
@            else       return;
@        }
@        p->bufend = p->inbuf + n + SNDINBUFSIZ/32 ;
@        if (ntogo > 0) {
@            if ((nsmps = n / p->sampframsiz) > ntogo) nsmps = ntogo; 
@            ntogo -= nsmps;    
@            goto shorts;
@        }    
@    }
@         
@    
@    switch (p->format) {
@      case AE_SHORT:        
@shorts:
@        switch(chnsout) {
@          case 1:
@          {
@            register short *base_addr;
@            register short *inbufp = (short *)p->inbufp;        
@            base_addr = inbufp;
@            *fl_buf -= (long) *fl_buf; 
@    
@            do {
@                phase_diff = *phase - (long) *phase;
@                *r1++ = (float) *inbufp + (float) ( *(inbufp+1) -
*inbufp) * phase_diff;        //gab
@                //*r1++ = (float) *inbufp;        
@                *phase += ratio;
@                *fl_buf += ratio;
@                inbufp = base_addr + (long) *fl_buf;
@            } while (--nsmps); 
@
@            if (inbufp >= ((short *)p->bufend)- SNDINBUFSIZ/32) {      
@     
@                lseek(p->fdch.fd, (long) *phase * sizeof(short),
SEEK_SET );
@                        
@                if ((n = sreadin(p->fdch.fd,p->inbuf,SNDINBUFSIZ *
4,p)) == 0) {
@                    p->endfile = 1;
@                    if (ntogo) goto filend;
@                    else return;
@                }
@                inbufp = (short *) p->inbuf;
@                p->bufend = p->inbuf + n + SNDINBUFSIZ/32 ;
@                if (ntogo > 0) {
@                    if ((nsmps = n / p->sampframsiz) > ntogo) nsmps =
ntogo; 
@                    ntogo -= nsmps;    
@                    goto shorts;    
@                }
@            }
@            p->inbufp = (char *) inbufp;
@          }
@          break;
@        
@          case 2:
@          {
@            register long *base_addr;
@            register long *inbufp = (long *)p->inbufp;
@            base_addr = inbufp;
@            *fl_buf -= (long) *fl_buf; 
@    
@            do {
@                register short left,right, left1, right1;
@                phase_diff = *phase - (long) *phase;
@                
@                left = (short) (*inbufp >> 16);
@                right =(short) ( *inbufp & 0xffff);
@                left1 = (short) (*(inbufp+1)>> 16);
@                right1 =(short) ( *(inbufp+1) & 0xffff);
@                
@                *r1++ = (float) left + (float) ( left1 - left) *
phase_diff;        
@                *r2++ = (float) right + (float) ( right1 - right) *
phase_diff;        
@                
@                *phase += ratio;
@                *fl_buf += ratio;
@                inbufp = base_addr + (long) *fl_buf;
@            } while (--nsmps); 
@                            
@            if (inbufp >= ((long *)p->bufend)- SNDINBUFSIZ/32 ) {      
@                lseek(p->fdch.fd, (long) *phase * sizeof(long) ,
SEEK_SET );
@                        
@                if ((n = sreadin(p->fdch.fd,p->inbuf,SNDINBUFSIZ *
4,p)) == 0) {
@                    p->endfile = 1;
@                    if (ntogo) goto filend;
@                    else return;
@                }
@                inbufp = (long *) p->inbuf;
@                p->bufend = p->inbuf + n + SNDINBUFSIZ/32;
@                if (ntogo > 0) {
@                    if ((nsmps = n / p->sampframsiz) > ntogo)
@                        nsmps = ntogo; 
@                    ntogo -= nsmps;    
@                    goto shorts;    
@                }
@            }
@            p->inbufp = (char *) inbufp;
@        
@          }
@          break;
@          default:
@          dies("soundin2 of %s not implemented",
getstrformat((int)p->format));
@        }
@        break;
@      default:
@        dies("soundin2 of %s not implemented",
getstrformat((int)p->format));
@      }
@    return;
@
@filend:
@    nsmps = ntogo;
@    switch(chnsout) {                   /* if past end of file, */
@    case 1:
@        do *r1++ = fzero;               /*    move in zeros     */
@        while (--nsmps);
@        break;
@    case 2:
@        do {
@            *r1++ = fzero;
@            *r2++ = fzero;
@        } while (--nsmps);
@        break;
@    }
@}

//////////////// At the beginning of the ENTRY.C file you must add 
//////////////// the following function declarations.....

@void    sndin2set(void*), soundin2(void*); //GAB

//////////////// ..... and the following line in the OENTRY opcodlst[]
//////////////// structure array declaration.

@{ "soundin2",S(SOUNDIN), 5,     "mmmm", "Sook",  sndin2set,NULL, 
soundin2 } //GAB

//////////////// That's all .... and good luck!


Gabriel Maldonado

g.maldonado@agora.stm.it



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08408;
          18 Feb 97 13:34 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ah02778;
          18 Feb 97 13:38 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 11:25:37 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (LAA16888);
          Tue, 18 Feb 1997 11:17:34 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 11:17:22 GMT
Received: from rzaix13.rrz.uni-hamburg.de [134.100.2.13] by hermes 
          via SMTP (LAA16854); Tue, 18 Feb 1997 11:17:19 GMT
Received: from localhost 
          by rzaix13.rrz.uni-hamburg.de (AIX 4.1/UCB 5.64/4.03)          
          id AA13934; Tue, 18 Feb 1997 12:17:17 +0100
Message-Id: <33098FB9.6956@rrz.uni-hamburg.de>
Date: Tue, 18 Feb 1997 12:17:13 +0100
From: Bernd Eggink 
Organization: RRZ Uni Hamburg
X-Mailer: Mozilla 3.01 (X11; I; AIX 1)
Mime-Version: 1.0
To: CSound mailing list 
Subject: Csound95
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Is version 3.45 of cound95 available yet? If so, where can I get it?

	Bernd
--

Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@rzaix13.rrz.uni-hamburg.de
http://www.uni-hamburg.de/eggink/BEggink.html



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08444;
          18 Feb 97 13:34 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ax02543;
          18 Feb 97 13:38 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 12:25:18 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (MAA24944);
          Tue, 18 Feb 1997 12:18:16 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 12:18:00 GMT
Received: from ppp.eunet.be [192.92.130.5] by hermes via ESMTP (MAA24888);
          Tue, 18 Feb 1997 12:17:54 GMT
Received: from lmsnit.be (nit.eunet.be [193.74.251.94]) 
          by ppp.eunet.be (8.7.1/8.7.1) with SMTP id NAA28523;
          Tue, 18 Feb 1997 13:22:04 +0100 (GMT+0100)
Received: from jedi by lmsnit.be (4.1/SMI-4.1)	id AA02761;
          Tue, 18 Feb 97 13:13:48 +0100
Message-Id: <33099CFC.41C67EA6@ping.be>
Date: Tue, 18 Feb 1997 13:13:48 +0100
From: Marc Resibois 
Organization: Solar Flare
X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4c)
Mime-Version: 1.0
To: Bernd Eggink 
Cc: CSound mailing list 
Subject: Re: Csound95
References: <33098FB9.6956@rrz.uni-hamburg.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Bernd Eggink wrote:
> 
> Is version 3.45 of cound95 available yet? If so, where can I get it?
> 
>         Bernd

Sorry, I didn't have the time yet...

Marc.



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08465;
          18 Feb 97 13:34 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aw02778;
          18 Feb 97 13:38 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 12:57:23 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (MAA29270);
          Tue, 18 Feb 1997 12:50:13 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 12:49:59 GMT
Received: from max.roehampton.ac.uk [194.80.240.16] by hermes 
          via ESMTP (MAA29209); Tue, 18 Feb 1997 12:49:57 GMT
Received: from [194.80.242.243] by max (SMI-8.6/SMI-SVR4)	id MAA01355;
          Tue, 18 Feb 1997 12:45:18 GMT
X-Sender: alans@194.80.240.16
Message-Id: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Feb 1997 12:52:20 +0000
To: csound@maths.ex.ac.uk
From: Alan Stones 
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

I seem to remember that recently, someone posted news of a utility to
convert binary/analysis files to text. I've checked the archive but don't
seem to be able to locate it. Any help appreciated.

Alan Stones





Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08728;
          18 Feb 97 13:52 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa04201;
          18 Feb 97 13:56 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 13:56:31 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (NAA06300);
          Tue, 18 Feb 1997 13:48:44 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 13:48:18 GMT
Received: from pp@goggins.bath.ac.uk [138.38.32.13] by hermes 
          via ESMTP (NAA06228); Tue, 18 Feb 1997 13:48:16 GMT
From: jpff@maths.bath.ac.uk
Message-Id: <199702181348.NAA06228@hermes>
Received: from maths.Bath.AC.UK (actually host omphalos.maths.bath.ac.uk)           
          by goggins.bath.ac.uk with SMTP (PP); Tue, 18 Feb 1997 13:46:48 +0000
Date:     Tue, 18 Feb 97 13:42:32 GMT
Subject:  Re: large score files
To: csound@maths.ex.ac.uk
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Message written at 18 Feb 1997 08:56:12 +0000
--- Copy of mail to jnelson@sndart.cemi.unt.edu ---
In-reply-to: <9702171635.AA12232@sndart.cemi.unt.edu> (message from Jon
	Christopher Nelson on Mon, 17 Feb 97 10:35:37 -0600)

I persist in my view that the only limit to score size is machine
memory.  This is part of the extensive changes I made some time ago.
If one has a large score the message "sread: requesting more memory\n"
is printed and it adds another segment of 40,000 bytes.  I have tried
Richard Wentk's program and while slow, ....

Csound Version 3.44 (Feb  1 1997)
orchname:  Wentk.orc
scorename: Wentk.sco
sorting score ...
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory
sread: requesting more memory

and then after a LONG pause it says ...done and carries on.
That pause is significant, and while there there are no signs of life. 
I suspect a quadratic sorting method.

==John



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08740;
          18 Feb 97 13:54 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa04232;
          18 Feb 97 13:58 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 13:57:55 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (NAA06298);
          Tue, 18 Feb 1997 13:48:44 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 13:48:17 GMT
Received: from pp@goggins.bath.ac.uk [138.38.32.13] by hermes 
          via ESMTP (NAA06224); Tue, 18 Feb 1997 13:48:14 GMT
From: jpff@maths.bath.ac.uk
Message-Id: <199702181348.NAA06224@hermes>
Received: from maths.Bath.AC.UK (actually host omphalos.maths.bath.ac.uk)           
          by goggins.bath.ac.uk with SMTP (PP); Tue, 18 Feb 1997 13:46:25 +0000
Date:     Tue, 18 Feb 97 13:42:05 GMT
Subject:  Re: Possible bug
To: csound@maths.ex.ac.uk
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Message written at 17 Feb 1997 22:59:25 +0000
In-reply-to: <3.0.32.19970216144817.006eb91c@sdps.demon.co.uk> (message from
	Richard Wentk on Sun, 16 Feb 1997 15:53:01 +0000)

I have Richard Wentk's orc/score now, and it is progressing quite
happily in a window as I type this.  It had to expand score memory a
large number of times, but it did it.

This is one of teh things I fixed a year or more back.  If it fails it
is because there is insufficient memory.  I have looked at the code
and the check for space exhaustion is there.  Coudl be a Window95 bug
in malloc I suppose.....
==John



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08746;
          18 Feb 97 13:55 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ab04262;
          18 Feb 97 14:00 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 13:59:44 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (NAA06297);
          Tue, 18 Feb 1997 13:48:44 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 13:48:20 GMT
Received: from pp@goggins.bath.ac.uk [138.38.32.13] by hermes 
          via ESMTP (NAA06235); Tue, 18 Feb 1997 13:48:18 GMT
From: jpff@maths.bath.ac.uk
Message-Id: <199702181348.NAA06235@hermes>
Received: from maths.Bath.AC.UK (actually host omphalos.maths.bath.ac.uk)           
          by goggins.bath.ac.uk with SMTP (PP); Tue, 18 Feb 1997 13:46:55 +0000
Date:     Tue, 18 Feb 97 13:42:38 GMT
Subject:  Floating point numbers
To: csound@maths.ex.ac.uk
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Message written at 18 Feb 1997 09:40:46 +0000

Would anyone object if the score read floating point numbers with
optional exponents?  I ask as I have made a modification here which
shortens the code, but as a side effect introduces "standard" floating
point representation.  Beore i incorporate that I wanted to check that
it woudl make someone happy and not upset others.
==John

PS I have already done it to orc files I believe, but I did not mention it.



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09012;
          18 Feb 97 15:04 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa05706;
          18 Feb 97 15:08 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 15:08:30 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (OAA15016);
          Tue, 18 Feb 1997 14:57:22 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 14:57:12 GMT
Received: from bee.uspnet.usp.br [143.107.253.3] by hermes 
          via ESMTP (OAA14991); Tue, 18 Feb 1997 14:57:07 GMT
Original-Received:  from caju 
                   (caju.larc.usp.br [143.107.111.2]) by bee.uspnet.usp.br 
                   (8.6.10/SPARC10-CCE2.0)id MAA15681
PP-warning: Illegal Received field on preceding line
Received: from abobora by caju (SMI-8.6/SMI-SVR4)	id MAA16091;
          Tue, 18 Feb 1997 12:00:02 -0300
Message-Id: <3309C470.4816@larc.usp.br>
Date: Tue, 18 Feb 1997 12:02:09 -0300
From: clovis harada 
Reply-To: clharada@caju.larc.usp.br
Organization: LARC USP
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Mime-Version: 1.0
To: csound@maths.ex.ac.uk
Subject: Hardware Implementation
References: <199702181348.NAA06228@hermes>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Have only one question:

	Are there any research in hardware implementation of csound?

thanks
Clovis Harada



Received: from xenakis.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09048;
          18 Feb 97 15:11 GMT
From: jpff@maths.bath.ac.uk
To: darrin@research.canon.com.au
CC: csound@maths.ex.ac.uk
In-reply-to: <199702180057.LAA25964@garner.research.canon.com.au> (message
	from Darrin Smart on Tue, 18 Feb 97 11:57:43 +1100)
Subject: Re: float vs. double speed
BCC: jpff@maths.bath.ac.uk
Date: Tue, 18 Feb 97 15:15:31 GMT
Sender: jpff@maths.bath.ac.uk
Source-Info:  From (or Sender) name not authenticated.

It is not as simple as that.  Consider scanf and other library
routines.
==John


Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09072;
          18 Feb 97 15:20 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa05974;
          18 Feb 97 15:24 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 15:24:05 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (PAA17687);
          Tue, 18 Feb 1997 15:16:18 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 15:16:01 GMT
Received: from pp@goggins.bath.ac.uk [138.38.32.13] by hermes 
          via ESMTP (PAA17623); Tue, 18 Feb 1997 15:16:00 GMT
From: jpff@maths.bath.ac.uk
Message-Id: <199702181516.PAA17623@hermes>
Received: from maths.Bath.AC.UK (actually host xenakis.maths.bath.ac.uk)           
          by goggins.bath.ac.uk with SMTP (PP); Tue, 18 Feb 1997 15:15:54 +0000
To: darrin@research.canon.com.au
Cc: csound@maths.ex.ac.uk
In-Reply-To: <199702180057.LAA25964@garner.research.canon.com.au> (message	from Darrin Smart on Tue, 18 Feb 97 11:57:43 +1100)
Subject: Re: float vs. double speed
Date: Tue, 18 Feb 97 15:15:31 GMT
Source-Info:  From (or Sender) name not authenticated.
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

It is not as simple as that.  Consider scanf and other library
routines.
==John



Received: from xenakis.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09092;
          18 Feb 97 15:26 GMT
From: jpff@maths.bath.ac.uk
To: A.Stones@roeham.ac.uk
CC: csound@maths.ex.ac.uk
In-reply-to:  (message from Alan
	Stones on Tue, 18 Feb 1997 12:52:20 +0000)
BCC: jpff@maths.bath.ac.uk
Date: Tue, 18 Feb 97 15:30:32 GMT
Sender: jpff@maths.bath.ac.uk
Source-Info:  From (or Sender) name not authenticated.

The programs pv_export and pv_import have been available for a very
long time, and are in the Bath distribution.  lpc_import is missing --
I have it written but there is a bug.
==ohn


Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09122;
          18 Feb 97 15:38 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa06464;
          18 Feb 97 15:42 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 15:41:46 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (PAA19552);
          Tue, 18 Feb 1997 15:31:23 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 15:31:11 GMT
Received: from pp@goggins.bath.ac.uk [138.38.32.13] by hermes 
          via ESMTP (PAA19526); Tue, 18 Feb 1997 15:31:11 GMT
From: jpff@maths.bath.ac.uk
Message-Id: <199702181531.PAA19526@hermes>
Received: from maths.Bath.AC.UK (actually host xenakis.maths.bath.ac.uk)           
          by goggins.bath.ac.uk with SMTP (PP); Tue, 18 Feb 1997 15:30:53 +0000
To: A.Stones@roeham.ac.uk
Cc: csound@maths.ex.ac.uk
In-Reply-To:  (message from Alan	Stones on Tue, 18 Feb 1997 12:52:20 +0000)
Date: Tue, 18 Feb 97 15:30:32 GMT
Source-Info:  From (or Sender) name not authenticated.
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

The programs pv_export and pv_import have been available for a very
long time, and are in the Bath distribution.  lpc_import is missing --
I have it written but there is a bug.
==ohn



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09136;
          18 Feb 97 15:42 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa06515;
          18 Feb 97 15:46 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 15:46:39 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (PAA20010);
          Tue, 18 Feb 1997 15:34:45 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 15:34:31 GMT
Received: from luigi.music.lsu.edu [130.39.123.34] by hermes 
          via SMTP (PAA19976); Tue, 18 Feb 1997 15:34:24 GMT
Received: from bela by luigi.music.lsu.edu (NX5.67d/NX3.0M)	id AA09794;
          Tue, 18 Feb 97 10:15:29 -0600
Message-Id: 
In-Reply-To: <199702180821.AAA25150@sunspot.filoli.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Feb 1997 09:34:13 -0600
To: csound@maths.ex.ac.uk
From: Stephen David Beck 
Subject: Re: midi support for NeXT
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Charlie Baker wrote:

>There is also a not-so-old (3.41?) version that was compiled "fat" for
>NeXT/Intel, from Stephen Beck...he used the old driver library, soo...
>I bet he has a copy of that driver compiled fat also, so he might be
>who you wanna talk to about this.

In fact, when I started compiling the csound binary for NeXT, csound used
midi drivers from NS 2.x and I had to rewrite that part of the code to use
the later midi drivers from the Music Kit.  Frankly, I don't remember what
version of the Music Kit it was, but making the conversion did work.

What didn't work was real-time sound on my cube using MIDI input.  So I
stopped working on MIDI Csound for NeXT hardware.  But I did compile the
code once for a NeXT/Intel "fat" binary.  It also worked (well, the midi
did).

But my motivation for that was to support my NeXT front-end to Csound,
Csnd.app.  As my cube's monitor is dead, NEXTSTEP was (but no longer) a
dead-end for music apps, and I have 5 new PowerMacs and a couple of SGIs in
my studios, I have had no reason to continue work on this.  And I haven't.

And, no, I never tested it on an Intel-based NS machine, even though it was
compiled fat.  Until last year, I had no money for new computers or any
hardware for 4 years.  Amazing what a grant can do for you...

But now that MacOS and OpenStep are merging, there may still be life in my
old code, for the new Mac Rhapsody.  But who knows.  I've been writing too
much code, and not enough music.  I'll wait until Rhapsody is released in
1998 (yeah, right!).

>Oh, yeah, StephenBeck teaches (lucky sot) at LSU: I think his address
>is/was sbeck@math.lsu.edu.

I am very lucky, and that was.

I can be reached at sdb@comp.music.lsu.edu.  Csnd.app version 2 is
available from our web server at http://comp.music.lsu.edu/eams/software/.
We also have a copy of the html csound manual, and a pdf csound manual for
public reference.

Steve


=========================================================================
Stephen David Beck
Associate Professor of Composition
School of Music
Louisiana State University
Baton Rouge, LA  70803-2504
USA
email:  sdb@comp.music.lsu.edu
http://www.music.lsu.edu/faculty/sbeck/sbeck.htm

President, SEAMUS
The Society for Electro-Acoustic Music in the United States
2550 Beverly Boulevard
Los Angeles, CA  90057
http://comp.music.lsu.edu/seamus/
=========================================================================





Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09392;
          18 Feb 97 16:59 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa01261;
          18 Feb 97 17:04 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 16:38:55 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (QAA25874);
          Tue, 18 Feb 1997 16:24:31 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 16:24:17 GMT
Received: from ella.mills.edu [144.91.3.20] by hermes via ESMTP (QAA25813);
          Tue, 18 Feb 1997 16:24:02 GMT
Received: from localhost by ella.mills.edu 
          via SMTP (940816.SGI.8.6.9/930416.SGI)	 id IAA23910;
          Tue, 18 Feb 1997 08:22:48 -0800
Date: Tue, 18 Feb 1997 08:22:47 -0800 (PST)
From: Mike Berry 
To: Alan Stones 
Cc: csound@maths.ex.ac.uk
Subject: Re: your mail
In-Reply-To: 
Message-Id: 
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

	The binary->text converter for analysis files is called Mr.Tweaky
and its at ftp://mills.edu/ccm/csound.ppc/  .Its for mac PPC.

Mike Berry
mikeb@mills.edu
http://www.mills.edu/PEOPLE/gr.pages/mikeb.public.html/mikeb.homepage.html




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09946;
          18 Feb 97 19:40 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id ax01416;
          18 Feb 97 19:45 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 18:50:21 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (SAA10358);
          Tue, 18 Feb 1997 18:41:36 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 18:41:21 GMT
Received: from kfoltman@student.uci.agh.edu.pl [149.156.98.60] by hermes 
          via ESMTP (SAA10319); Tue, 18 Feb 1997 18:41:13 GMT
Received: from localhost (kfoltman@localhost) 
          by student.uci.agh.edu.pl (8.8.5/8.8.5/ts-tmpl.970124) with SMTP	   
          id TAA11411; Tue, 18 Feb 1997 19:38:33 +0100 (MET)
Date: Tue, 18 Feb 1997 19:38:33 +0100 (MET)
From: Krzysztof Foltman 
X-Sender: kfoltman@student
To: Graeme Gerrard 
Cc: "Thomas R. Trenka" , csound@maths.ex.ac.uk
Subject: Re: Manual....and formats
In-Reply-To: <199702171140.WAA04502@oznet02.ozemail.com.au>
Message-Id: 
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

On Mon, 17 Feb 1997, Graeme Gerrard wrote:

> PDF is a great electronic and printable format.

Printable - yes. But it's very inconvenient to read on screen.

...kf




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09973;
          18 Feb 97 19:40 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id bc01416;
          18 Feb 97 19:45 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 19:14:58 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (TAA12138);
          Tue, 18 Feb 1997 19:08:42 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 19:08:33 GMT
Received: from ella.mills.edu [144.91.3.20] by hermes via ESMTP (TAA12118);
          Tue, 18 Feb 1997 19:08:27 GMT
Received: from localhost by ella.mills.edu 
          via SMTP (940816.SGI.8.6.9/930416.SGI)	 id LAA07328;
          Tue, 18 Feb 1997 11:08:09 -0800
Date: Tue, 18 Feb 1997 11:08:08 -0800 (PST)
From: "Matt J. Ingalls" 
To: jpff@maths.bath.ac.uk
Cc: csound@maths.ex.ac.uk
Subject: Re: large score files
In-Reply-To: <199702181348.NAA06228@hermes>
Message-Id: 
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

> 
> I persist in my view that the only limit to score size is machine
> memory.  This is part of the extensive changes I made some time ago.

	so you are the one responisible for that? THANK YOU THANK YOU
THANK YOU!!! (that saved my ass a few years ago!!)

i forget who was having this problem, but they would have gotten
an "out of memory" error message if the problem was indeed a score length
problem. 
> I suspect a quadratic sorting method.

Another way out of this problem is to have your score generation program
create the score in sorted format.  It seems to me that csound will bypass
the sorting for any score with a *.srt filename.

I would assume most people's score generators create note events linearly
in time anyway, so it would be simple to write in sort format. (of course 
you would have to make sure p2s were indeed ALWAYS in increasing order)


-matt




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09981;
          18 Feb 97 19:40 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id bg01416;
          18 Feb 97 19:45 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 19:30:51 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (TAA13216);
          Tue, 18 Feb 1997 19:25:37 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 19:25:27 GMT
Received: from ella.mills.edu [144.91.3.20] by hermes via ESMTP (TAA13191);
          Tue, 18 Feb 1997 19:25:24 GMT
Received: by ella.mills.edu (940816.SGI.8.6.9/930416.SGI)	for csound@maths.exeter.ac.uk 
          id LAA09000; Tue, 18 Feb 1997 11:25:15 -0800
From: David Madole 
Message-Id: <199702181925.LAA09000@ella.mills.edu>
Subject: Floating precision
To: csound-list 
Date: Tue, 18 Feb 1997 11:25:14 -0800 (PST)
Reply-To: madole@mills.edu
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 775       
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

> It may be naive, but why couldn't the option of using doubles internally 
> instead of floats not be available as a command-line option?  It seems to 
> me that about half of the time we really really really care about 
> performance and speed, and about half of the time we care about really 
> really really precise calculations. =)

This would not work.  The compiled code depends on knowing the size of
the number.

> 
> At the very least, it should be possible to implement this as a flag in 
> the makefile?  Then, if someone really need the precision, they could 
> recompile the code with doubles thorughout.
> 

This would work, but be compiler/implementation dependent.  Also, any
code that reads or writes floating point files would need to be
exempted.

Dave





Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10134;
          18 Feb 97 20:29 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02030;
          18 Feb 97 20:33 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 20:33:09 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (UAA19139);
          Tue, 18 Feb 1997 20:28:33 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 20:28:23 GMT
Received: from sndart.cemi.unt.edu [129.120.63.1] by hermes 
          via SMTP (UAA19073); Tue, 18 Feb 1997 20:27:01 GMT
Received: by sndart.cemi.unt.edu (NX5.67e/NX3.0M)	id AA00595;
          Tue, 18 Feb 97 14:20:33 -0600
Message-Id: <9702182020.AA00595@sndart.cemi.unt.edu>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
Original-Received:  by NeXT.Mailer (1.118.2)
PP-warning: Illegal Received field on preceding line
From: Jon Christopher Nelson 
Date: Tue, 18 Feb 97 14:20:32 -0600
To: csound@maths.ex.ac.uk
Subject: large score files
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Matt wrote:
>I would assume most people's score generators create note events
>linearly in time anyway

This is not necessarily the case.  My soundfile granulation score  
generator includes a lot of random variables that can, and usually  
do, result in score files that are NOT linear.

John wrote:
> I persist in my view that the only limit to score size is machine
> memory.  This is part of the extensive changes I made some time ago.

If the only limit to score file size is machine memory, I am  
somewhat perplexed since I allocated 40 MB of RAM to Csound to perf  
a simple (and very small) orchestra with a VERY large score.  It  
worked fine for a score file of 12.5 MB but crashed after about 20  
minutes of allocating more space for memory on a 25 MB score file.   
The score file contains 51 function tables (50-513 point tables and  
another table whose size is dependant upon the soundfile being  
granulated--in this case, a 1.5 second file).  By the way, I ran  
this perf on a Power Mac 8500  (120MHz) with 64 MB of RAM using the  
Mills version of Csound.

Again, I have not looked extensively at the code to find the  
problem.  Any ideas you may have would be appreciated.

regards,
Jon Nelson

Jon Christopher Nelson, Director
CEMI (Center for Experimental Music and Intermedia)
University of North Texas College of Music
P.O. Box 13887
Denton, TX 76203
USA

ph. (817) 565-4926
fax (817) 565-2002
jnelson@sndart.cemi.unt.edu
http://www.music.unt.edu/comp/jnelson.htm



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10187;
          18 Feb 97 20:47 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02105;
          18 Feb 97 20:51 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 20:51:12 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (TAA15826);
          Tue, 18 Feb 1997 19:49:01 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 19:48:44 GMT
Received: from ella.mills.edu [144.91.3.20] by hermes via ESMTP (TAA15419);
          Tue, 18 Feb 1997 19:46:00 GMT
Received: by ella.mills.edu (940816.SGI.8.6.9/930416.SGI)	for csound@maths.exeter.ac.uk 
          id LAA10920; Tue, 18 Feb 1997 11:45:55 -0800
From: David Madole 
Message-Id: <199702181945.LAA10920@ella.mills.edu>
Subject: Re: prettyness of code
To: csound-list 
Date: Tue, 18 Feb 1997 11:45:54 -0800 (PST)
Reply-To: madole@mills.edu
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 891       
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

> 

The reason the inner loops of csound are the way they are is that, in
my opinion, they are almost directly translated from their music-11
equivalents in PDP-11 assembler code, code with which I was familiar.
Ergo the gotos, labels, etc., which as I remember it had the same
names.

Whether the translation was done *SO* directly for the sake of efficiency
(C compilers were pretty stupid back then) or whether the structured
possibilities of C were not immediately obvious to BV only he knows
for sure.  The one true reason to go to C was cross platform potential.

People forget that csound had a PDP-11 assembly ancestor, probably because
you needed a PDP-11 to run it.  Ergo Csound, and some of the idiosyncracies
of the code.

Dave

Dave Madole
Technical Director, Center for Contemporary Music
Listserv Administrator

Mills College
Oakland, CA 94613
510-430-2336

madole@mills.edu




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10194;
          18 Feb 97 20:49 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02114;
          18 Feb 97 20:53 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 20:53:27 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (UAA20238);
          Tue, 18 Feb 1997 20:47:23 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 20:47:13 GMT
Received: from ulysses.Stanford.EDU [36.49.0.124] by hermes 
          via ESMTP (UAA20224); Tue, 18 Feb 1997 20:47:11 GMT
Received: (from tkunze@localhost) 
          by ulysses.stanford.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) 
          id MAA26905; Tue, 18 Feb 1997 12:46:39 -0800
From: Tobias Kunze 
Message-Id: <9702181246.ZM26904@ulysses.stanford.edu>
Date: Tue, 18 Feb 1997 12:46:38 -0800
In-Reply-To: madole@ella.mills.edu (David Madole)        "Floating precision" (Feb 18, 11:25am)
References: <199702181925.LAA09000@ella.mills.edu>
Reply-To: t@ulysses.stanford.edu
X-Url: http://www.stanford.edu/~tkunze
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: madole@mills.edu, csound-list 
Subject: Re: Floating precision
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk


Thanks a lot for the update, Dave!  I guess, that's another
plaidoyer for platform-specific optimization techniques.  I
for my part came to notice that, in some, but by no means rare
circumstances, csound spends more than 98% cpu time in floating
point exceptions (on SGI's typically, when an expseg's k-rate
increment gets too low).  Since floating point exceptions are
not always easy to predict nor easy to avoid, and since noone
(I believe) really cares about float exceptions in dsp, I'll
disable them in the next (3.45) version of the IRIX 6.2 archive
that i keep on my server.

-Tobias

-- 

______________________________________________________________________

Tobias Kunze                       t@kunze.stanford.edu
CCRMA, Stanford University         http://www.stanford.edu/~tkunze




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10229;
          18 Feb 97 21:02 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02176;
          18 Feb 97 21:06 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 21:06:21 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (VAA20909);
          Tue, 18 Feb 1997 21:00:51 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 21:00:41 GMT
Received: from ella.mills.edu [144.91.3.20] by hermes via ESMTP (VAA20902);
          Tue, 18 Feb 1997 21:00:39 GMT
Received: from localhost by ella.mills.edu 
          via SMTP (940816.SGI.8.6.9/930416.SGI)	 id MAA17207;
          Tue, 18 Feb 1997 12:59:27 -0800
Date: Tue, 18 Feb 1997 12:59:25 -0800 (PST)
From: Mike Berry 
To: Jon Christopher Nelson 
Cc: csound@maths.ex.ac.uk
Subject: Re: large score files
In-Reply-To: <9702182020.AA00595@sndart.cemi.unt.edu>
Message-Id: 
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

	You may be making a somewhat common mistake with csound.ppc.  You
have to increase the partition on perf.ppc, not on csound.ppc, in order to
increase the memory partition.

Mike Berry
mikeb@mills.edu
http://www.mills.edu/PEOPLE/gr.pages/mikeb.public.html/mikeb.homepage.html




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10252;
          18 Feb 97 21:10 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02196;
          18 Feb 97 21:14 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 21:13:31 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (VAA21481);
          Tue, 18 Feb 1997 21:09:33 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 21:09:23 GMT
Received: from sndart.cemi.unt.edu [129.120.63.1] by hermes 
          via SMTP (VAA21464); Tue, 18 Feb 1997 21:09:16 GMT
Received: from sndart1 by sndart.cemi.unt.edu (NX5.67e/NX3.0M)	id AA00708;
          Tue, 18 Feb 97 15:03:01 -0600
Message-Id: <9702182103.AA00708@sndart.cemi.unt.edu>
Received: by sndart1.cemi.unt.edu (NX5.67e/NX3.0X)	id AA07647;
          Tue, 18 Feb 97 15:03:14 -0600
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
Original-Received:  by NeXT.Mailer (1.118.2)
PP-warning: Illegal Received field on preceding line
From: Jon Christopher Nelson 
Date: Tue, 18 Feb 97 15:03:12 -0600
To: Mike Berry 
Subject: Re: large score files
Cc: csound@maths.ex.ac.uk
References: 
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Mike wrote:
>You may be making a somewhat common mistake with csound.ppc.  You
>have to increase the partition on perf.ppc, not on csound.ppc, in  
>order to increase the memory partition.

Nope, I increased the RAM on perf.ppc and it still choked on the 25  
MB score file.

Jon Nelson

Jon Christopher Nelson, Director
CEMI (Center for Experimental Music and Intermedia)
University of North Texas College of Music
P.O. Box 13887
Denton, TX 76203
USA

ph. (817) 565-4926
fax (817) 565-2002
jnelson@sndart.cemi.unt.edu
http://www.music.unt.edu/comp/jnelson.htm



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10259;
          18 Feb 97 21:11 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02207;
          18 Feb 97 21:15 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 21:15:12 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (VAA21592);
          Tue, 18 Feb 1997 21:10:50 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 21:10:37 GMT
Received: from jason01.u.washington.edu [140.142.70.24] by hermes 
          via ESMTP (VAA21576); Tue, 18 Feb 1997 21:10:33 GMT
Received: from saul3.u.washington.edu (saul3.u.washington.edu [140.142.83.1])          
          by jason01.u.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) 
          with ESMTP	  id NAA11546; Tue, 18 Feb 1997 13:05:28 -0800
Received: from localhost (karpen@localhost)          
          by saul3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) with SMTP	  
          id NAA06216; Tue, 18 Feb 1997 13:10:34 -0800 (PST)
Date: Tue, 18 Feb 1997 13:10:34 -0800 (PST)
From: Richard Karpen 
To: madole@mills.edu
Cc: csound-list 
Subject: Re: prettyness of code
In-Reply-To: <199702181945.LAA10920@ella.mills.edu>
Message-Id: 
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk


And don't forget that before Music-11 there was Music360 which ran
on the IBM-360!! Even that system, way back when, allowed one to
add their own unit generators as Fortran subroutines! 

RK

On Tue, 18 Feb 1997, David Madole wrote:

> > 
> 
> The reason the inner loops of csound are the way they are is that, in
> my opinion, they are almost directly translated from their music-11
> equivalents in PDP-11 assembler code, code with which I was familiar.
> Ergo the gotos, labels, etc., which as I remember it had the same
> names.
> 
> Whether the translation was done *SO* directly for the sake of efficiency
> (C compilers were pretty stupid back then) or whether the structured
> possibilities of C were not immediately obvious to BV only he knows
> for sure.  The one true reason to go to C was cross platform potential.
> 
> People forget that csound had a PDP-11 assembly ancestor, probably because
> you needed a PDP-11 to run it.  Ergo Csound, and some of the idiosyncracies
> of the code.
> 
> Dave
> 
> Dave Madole
> Technical Director, Center for Contemporary Music
> Listserv Administrator
> 
> Mills College
> Oakland, CA 94613
> 510-430-2336
> 
> madole@mills.edu
> 
> 
> 




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10382;
          18 Feb 97 21:43 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02409;
          18 Feb 97 21:47 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 21:47:28 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (VAA23152);
          Tue, 18 Feb 1997 21:43:45 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 21:43:36 GMT
Received: from ella.mills.edu [144.91.3.20] by hermes via ESMTP (VAA23144);
          Tue, 18 Feb 1997 21:43:33 GMT
Received: by ella.mills.edu (940816.SGI.8.6.9/930416.SGI)	 id NAA21007;
          Tue, 18 Feb 1997 13:40:49 -0800
From: David Madole 
Message-Id: <199702182140.NAA21007@ella.mills.edu>
Subject: Re: large score files
To: Jon Christopher Nelson 
Date: Tue, 18 Feb 1997 13:40:49 -0800 (PST)
Cc: mikeb@mills.edu, csound@maths.ex.ac.uk
Reply-To: madole@mills.edu
In-Reply-To: <9702182103.AA00708@sndart.cemi.unt.edu> from "Jon Christopher Nelson" at Feb 18, 97 03:03:12 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 654       
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

> Nope, I increased the RAM on perf.ppc and it still choked on the 25  
> MB score file.
> 

You may or will get a similar looking memory error if the density of
events (number of instruments allocated) is too high.  This sometimes
happens with matt's score generator, e.g.  I think the only way to
adjust for this is for the programmer to make a fixed pool larger. If
you make the instruments smaller and the program behaves differently,
that may be the case.  The memory allocation scheme for instantiations
of instruments, if I remember right, is not quite so forgiving or smart
as that for score files.  Something to put on the list, I guess.

Dave




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10414;
          18 Feb 97 21:53 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02472;
          18 Feb 97 21:57 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 21:57:16 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (VAA23570);
          Tue, 18 Feb 1997 21:52:48 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 21:52:38 GMT
Received: from ella.mills.edu [144.91.3.20] by hermes via ESMTP (VAA23561);
          Tue, 18 Feb 1997 21:52:36 GMT
Received: from localhost by ella.mills.edu 
          via SMTP (940816.SGI.8.6.9/930416.SGI)	for  
          id NAA21928; Tue, 18 Feb 1997 13:52:35 -0800
Date: Tue, 18 Feb 1997 13:52:35 -0800 (PST)
From: Mike Berry 
To: csound list 
Subject: midiolap and midiage
Message-Id: 
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

	Does anyone know how the midiolap and midiage opcodes work?  Are
they even part of any csound except csound.ppc?  Does anyone have any doc?
I'm looking at the code and I can't figure them out.

Mike Berry
mikeb@mills.edu
http://www.mills.edu/PEOPLE/gr.pages/mikeb.public.html/mikeb.homepage.html




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10561;
          18 Feb 97 22:20 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02629;
          18 Feb 97 22:24 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 22:24:08 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (WAA24640);
          Tue, 18 Feb 1997 22:19:37 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 22:19:28 GMT
Received: from ella.mills.edu [144.91.3.20] by hermes via ESMTP (WAA24628);
          Tue, 18 Feb 1997 22:19:25 GMT
Received: from localhost by ella.mills.edu 
          via SMTP (940816.SGI.8.6.9/930416.SGI)	 id OAA24222;
          Tue, 18 Feb 1997 14:18:43 -0800
Date: Tue, 18 Feb 1997 14:18:41 -0800 (PST)
From: "Matt J. Ingalls" 
To: David Madole 
Cc: Jon Christopher Nelson , mikeb@mills.edu, 
    csound@maths.ex.ac.uk
Subject: Re: large score files
In-Reply-To: <199702182140.NAA21007@ella.mills.edu>
Message-Id: 
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk


> > Nope, I increased the RAM on perf.ppc and it still choked on the 25  
> > MB score file.
> > 
> 
> You may or will get a similar looking memory error if the density of

as i recall, you are not getting a "memory allocation error" message, is
that correct?  it sorts the score fine, then starts cruching along, then
just stops the generation at some point?




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10643;
          18 Feb 97 22:42 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa02719;
          18 Feb 97 22:46 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Tue, 18 Feb 1997 22:46:00 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (WAA25620);
          Tue, 18 Feb 1997 22:41:49 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Tue, 18 Feb 97 22:41:39 GMT
Received: from relay-7.mail.demon.net [194.217.242.9] by hermes 
          via SMTP (WAA25616); Tue, 18 Feb 1997 22:41:38 GMT
Received: from rwentk.demon.co.uk ([158.152.68.129]) 
          by relay-7.mail.demon.net           id aa721414; 18 Feb 97 22:25 GMT
Message-Id: <3.0.32.19970218222534.006c6c60@sdps.demon.co.uk>
X-Sender: rwentk@sdps.demon.co.uk
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 22:25:43 +0000
To: csound@maths.ex.ac.uk
From: Richard Wentk 
Subject: Re: large score files
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

At 13:40 18/02/97 -0800, you wrote:
>> Nope, I increased the RAM on perf.ppc and it still choked on the 25  
>> MB score file.
>> 
>
>You may or will get a similar looking memory error if the density of
>events (number of instruments allocated) is too high.  This sometimes
>happens with matt's score generator, e.g.  I think the only way to
>adjust for this is for the programmer to make a fixed pool larger. If
>you make the instruments smaller and the program behaves differently,
>that may be the case.  The memory allocation scheme for instantiations
>of instruments, if I remember right, is not quite so forgiving or smart
>as that for score files.  Something to put on the list, I guess.
>

I think this could well be something to do with my original problem. The
score sorts just fine, but dies while rendering. Since the score is
basically just a collection of randomly distributed sine blips that gets
less and less dense over time, and since it's more or less at its densest
when it falls over, that could well be where the bug (feature?) lies.

I'd guess it's trying to start another instrument, runs out of its memory
allocation, starts overwriting stuff and then falls off the edge of the world.

Could be completely wrong of course...

John?

R.




Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11553;
          19 Feb 97 3:41 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa04079;
          19 Feb 97 3:45 GMT
Received: from big.fishnet.net by goggins.bath.ac.uk with SMTP (PP);
          Wed, 19 Feb 1997 03:45:41 +0000
Received: from sinewave (port057.vta.fishnet.net [205.216.133.206]) 
          by big.fishnet.net (8.7.5/8.6.9) with SMTP id TAA09112;
          Tue, 18 Feb 1997 19:52:46 -0800
Sender: toby@big.fishnet.net
Message-ID: <330A77E3.54A5571F@rcsreg.com>
Date: Tue, 18 Feb 1997 19:47:47 -0800
From: Toby 
X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.27 i486)
MIME-Version: 1.0
To: jpff@maths.bath.ac.uk
CC: csound@noether.ex.AC.UK
Subject: Re: Floating point numbers
References: <199702181348.NAA06235@hermes>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

jpff@maths.bath.ac.uk wrote:
> 
> Message written at 18 Feb 1997 09:40:46 +0000
> 
> Would anyone object if the score read floating point numbers with
> optional exponents?  I ask as I have made a modification here which
> shortens the code, but as a side effect introduces "standard" floating
> point representation.  Beore i incorporate that I wanted to check that
> it woudl make someone happy and not upset others.
> ==John
> 
> PS I have already done it to orc files I believe, but I did not mention it.


Oh, yes, please do.  I sometimes find myself
jumping through hoops in order to keep score
generating programs from using exponents
when I have them express very small numbers.

If Csound was able to read them directly (Heck,
atof() understands them) than I could
relax a bit more, and concentrate on the musical
results of calculations rather than on the format 
chosen to express them by the language in question.

Besides, what possible disadvantage could there be?

Toby

	-There otta be a law-


Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11572;
          19 Feb 97 3:45 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa04089;
          19 Feb 97 3:49 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Wed, 19 Feb 1997 03:49:29 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (DAA04612);
          Wed, 19 Feb 1997 03:45:52 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Wed, 19 Feb 97 03:45:42 GMT
Received: from root@big.fishnet.net [205.216.133.3] by hermes 
          via ESMTP (DAA04606); Wed, 19 Feb 1997 03:45:41 GMT
Received: from sinewave (port057.vta.fishnet.net [205.216.133.206]) 
          by big.fishnet.net (8.7.5/8.6.9) with SMTP id TAA09112;
          Tue, 18 Feb 1997 19:52:46 -0800
Message-Id: <330A77E3.54A5571F@rcsreg.com>
Date: Tue, 18 Feb 1997 19:47:47 -0800
From: Toby 
X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.27 i486)
Mime-Version: 1.0
To: jpff@maths.bath.ac.uk
Cc: csound@maths.ex.ac.uk
Subject: Re: Floating point numbers
References: <199702181348.NAA06235@hermes>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

jpff@maths.bath.ac.uk wrote:
> 
> Message written at 18 Feb 1997 09:40:46 +0000
> 
> Would anyone object if the score read floating point numbers with
> optional exponents?  I ask as I have made a modification here which
> shortens the code, but as a side effect introduces "standard" floating
> point representation.  Beore i incorporate that I wanted to check that
> it woudl make someone happy and not upset others.
> ==John
> 
> PS I have already done it to orc files I believe, but I did not mention it.


Oh, yes, please do.  I sometimes find myself
jumping through hoops in order to keep score
generating programs from using exponents
when I have them express very small numbers.

If Csound was able to read them directly (Heck,
atof() understands them) than I could
relax a bit more, and concentrate on the musical
results of calculations rather than on the format 
chosen to express them by the language in question.

Besides, what possible disadvantage could there be?

Toby

	-There otta be a law-



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11582;
          19 Feb 97 3:48 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aa04100;
          19 Feb 97 3:52 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Wed, 19 Feb 1997 03:52:20 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (DAA04739);
          Wed, 19 Feb 1997 03:49:39 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Wed, 19 Feb 97 03:49:28 GMT
Received: from rumpleteazer.UCSC.EDU [128.114.129.45] by hermes 
          via ESMTP (DAA04726); Wed, 19 Feb 1997 03:49:27 GMT
Received: from angus.ucsc.edu (angus.UCSC.EDU [128.114.129.6])          
          by cats.ucsc.edu (8.8.5/8.8.4.cats-athena) with SMTP	  id TAA11038 
          for ; Tue, 18 Feb 1997 19:49:36 -0800 (PST)
Received: by angus.ucsc.edu (8.6.10/4.7) id TAA28606;
          Tue, 18 Feb 1997 19:50:08 -0800
Date: Tue, 18 Feb 1997 19:50:08 -0800 (PST)
From: John Francis Beahan 
X-Sender: jfbeahan@angus.ucsc.edu
To: csound mail list 
Subject: piping problem
Message-Id: 
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

I am here @ UCSC working on a project called sonify.  It's main objective 
is to take Data sets and translate them into music so these large amounts 
of data can be better understood.  We are currently trying to use csound 
to create the music.  We've run into a curious problem.  Right now we are 
piping an application that converts the data into I-statements that 
csound can understand to csound using the real-time function described in 
the manual.  Here is the command line we are using:

%son data1.txt | csound -odevaudio -Lstdin demo.orc dummy.sco

It starts out fine for the first few events, but then it suddenly stops 
producing music.  Csound sits there as if waiting for more information, 
but produces no sound.  Yet when we run the application by itself it is 
still generating I-statements.  Either csound suddenly refuses to 
awknowledge the data or something is wrong with the pipe.  Furthermore, 
when we take the I-statements by themselves and paste them into csound 
via -Lstin command alone without piping it works fine.  Does anybody have 
any suggestions or know whats wrong with this scenario that we are missing?
By the way,  we are doing all of this on an SGI, if that helps.

Thanx,  John Beahan 



Received: from stork2.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa13038;
          19 Feb 97 12:13 GMT
Received: from goggins.bath.ac.uk by stork.maths.Bath.AC.UK id aj01363;
          19 Feb 97 12:18 GMT
Received: from hermes.ex.ac.uk by goggins.bath.ac.uk with SMTP (PP);
          Wed, 19 Feb 1997 12:14:08 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (MAA06895);
          Wed, 19 Feb 1997 12:07:42 GMT
Received: from hermes.ex.ac.uk by noether.maths.exeter.ac.uk;
          Wed, 19 Feb 97 12:07:30 GMT
Received: from pp@goggins.bath.ac.uk [138.38.32.13] by hermes 
          via ESMTP (MAA06867); Wed, 19 Feb 1997 12:07:29 GMT
From: jpff@maths.bath.ac.uk
Message-Id: <199702191207.MAA06867@hermes>
Received: from maths.Bath.AC.UK (actually host omphalos.maths.bath.ac.uk)           
          by goggins.bath.ac.uk with SMTP (PP); Wed, 19 Feb 1997 12:06:32 +0000
Date:     Wed, 19 Feb 97 12:01:22 GMT
Subject:  Re: large score files
To: csound@maths.ex.ac.uk
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Message written at 18 Feb 1997 22:28:04 +0000
In-reply-to: <199702181348.NAA06228@hermes> (jpff@maths.bath.ac.uk)

On the PC DOS system it runs OK -- it is happily computing on the
otehr machine as I type.  However under Windows95 it seems to behave
erratically and I am not sure where to start looking (yet).  It seems
as if Windows has a storage management problem.

I will continue to attack it.
==John