I have been looking at the code in OOps/ugrw1.c but am finding it very
confusing.  Adding various tracing shows that the first kcycle (CS_KCNT ==
1) has time 0.01s when I would has assumed it ran at time zero.

new alloc for instr 1:
printkset: ctime = 4.000000 initime = 0.000000
printk: KCNT = 1
timel = 0.010000 cycles = 0 cysofar = 1.000001
 i   1 time     0.01000:             1.00000
printk: KCNT = 2
timel = 0.020000 cycles = 0 cysofar = -0.000000
printk: KCNT = 3
timel = 0.030000 cycles = 0 cysofar = -0.000000
printk: KCNT = 4
timel = 0.040000 cycles = 0 cysofar = -0.000000
.....

I would have thought that the first cycle (1) would have time 0 but the
calculation is
timel =     ((MYFLT) CS_KCNT * CS_ONEDKR) - p->initime;
which gives the 0.01 value.  Equally confusing is the time printed is
not timel but
    csound->icurTime/csound->esr
so on cycle 1 the current icurTime must be 441 which feels all wrong

I tried subtracting 1 from CS_KCNT used but the led to further
oddities.  I know there have been changes to counting but this all
seems gross and we would have noticed earlier surely?

I feel in need of inspiration!

I have a version that works but it still seems to me that csound->icurTime s 
wrong, giving the time at the end of the kcycle when I expect it to be the 
start.  Will commit new version as soon as I get it on a connected 
computer

On Wed, 3 Jan 2018, Michael Gogins wrote:

> Time to rewrite this.