On Wed, May 15, 2019 at 09:44:50PM +0100, john wrote:
> As I said I am being thick!
(:-))

> 
> I looked at the code and at initialisatio time it calculates the time for 
> the first printing as 0.1s from oneset, but not being in the conditional 
> means it does not tr printng unti relesae,  thn it thinks it is past time 
> so it prints on every k-cycle ntil it has caught up.
> 
> At least tta is how I read the code.  What it shoud do I have no idea. 
> The code has been extensivelt reworked at some stage as it was buggy. 
> Hum...

Coincidentally (!) I've also been looking at the code.  I also happen
to have the 5.19 source handy, so comparison was easy.  I noticed
that printk has the same behaviour, so I compared that instead.

Here are the relevant segments:

5.19:

in printkset:
    /* Set cysofar to - 1 so that on the first call to printk - when
     * cycle = 0, then there will be a print cycle.     */
    p->cysofar = -1;

in printk:
    /* Divide the current elapsed time by the cycle time and round down to
     * an integer.
     */
    cycles =    (int32) (timel / p->ctime);

    /* Now test if the cycle number we arein is higher than the one in which
     * we last printed. If so, update cysofar and print.    */
    if (p->cysofar < cycles) {
      p->cysofar = cycles;
      /* Do the print cycle.
      ...*/
    }


6.12:

in printkset:
     p->printat = CS_KCNT;

in printk:
    /* Now test if the cycle number has reached the next print time */
    if (p->printat <= CS_KCNT-1) {
      /* Do the print cycle.
      ...*/
      p->printat += p->ctime;
    }


Without actually checking, it looks to me as if the fix is to change
that last line to:

      p->printat = CS_KCNT +  p->ctime;

so it always set its next printout to p->ctime from "now".

Does that look right?

	-- Pete --

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here