Hi,

There is an unclear situation to me regarding timeinstk and timeinsts.

timeinstk returns 1 in the first cycle. This is in itself fine and is 
documented in the manual.

timeinsts, on the other hand, should "Read absolute time, in seconds, 
since the start of an instance of an instrument.". So one would expect 
this to be 0 on the first cycle. But it is not: timeinsts returns the 
time corresponding to timeinstk and is always off by one k-cycle 
(ksmps/sr).

I would propose to fix timeinsts so that it conforms to the manual.

cheers,

Sounds good to me, but we also have the alternative, which is fixing the manual.


> On 29 Jul 2022, at 11:16, Eduardo Moguillansky  wrote:
> 
> *Warning*
> 
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> 
> Hi,
> 
> There is an unclear situation to me regarding timeinstk and timeinsts.
> 
> timeinstk returns 1 in the first cycle. This is in itself fine and is
> documented in the manual.
> 
> timeinsts, on the other hand, should "Read absolute time, in seconds,
> since the start of an instance of an instrument.". So one would expect
> this to be 0 on the first cycle. But it is not: timeinsts returns the
> time corresponding to timeinstk and is always off by one k-cycle
> (ksmps/sr).
> 
> I would propose to fix timeinsts so that it conforms to the manual.
> 
> cheers,
> 

I just sent a PR with the given changes (https://github.com/csound/csound/pull/1614). The more compelling argument for me is that timek and times do return the correct values, namely 0 for the first cycle and 0 for the time at this cycle, whereas timeinstk and timeinsts are always off by one cycle.

cheers,

Eduardo

Agreed 👍

On Fri 29 Jul 2022, 3:13 p.m. Steven Yi, <stevenyi@gmail.com> wrote:

My vote is to change the behavior of timeinsts to read 0 at start to match the current manual description as that's what I'd expect and want if I used it. 

On Fri, Jul 29, 2022 at 7:28 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Sounds good to me, but we also have the alternative, which is fixing the manual.


> On 29 Jul 2022, at 11:16, Eduardo Moguillansky <eduardo.moguillansky@GMAIL.COM> wrote:
>
> *Warning*
>
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>
> Hi,
>
> There is an unclear situation to me regarding timeinstk and timeinsts.
>
> timeinstk returns 1 in the first cycle. This is in itself fine and is
> documented in the manual.
>
> timeinsts, on the other hand, should "Read absolute time, in seconds,
> since the start of an instance of an instrument.". So one would expect
> this to be 0 on the first cycle. But it is not: timeinsts returns the
> time corresponding to timeinstk and is always off by one k-cycle
> (ksmps/sr).
>
> I would propose to fix timeinsts so that it conforms to the manual.
>
> cheers,
>
> Eduardo

sorry to get late to this discussion.

i don't know how many .csd files of myself (and others) it will break to 
change this.

i used
   if timeinstk() == 1 then
   etc
to do something on the first k-cycle of an instrument.

after this change, it will be done on the second k-cycle.  (which is not 
mainly a question of being 0.00x seconds late, but mostly if this code 
was meant to be executed just once.)

again this is the question between consistency and backwards 
compatibility.  i understand the desire for consistency, but in my 
opinion, the risk of breaking a lot of working .csd files is too big, so 
my vote would be for the manual change.

	joachim


On 30/07/2022 13:13, Victor Lazzarini wrote:
> Perfect. Thanks.
> Could you do a PR against develop too so we capture this change there?
> 
>> On 30 Jul 2022, at 10:15, Eduardo Moguillansky 
>> > > wrote:
>>
>> I just sent a PR with the given changes 
>> (https://github.com/csound/csound/pull/1614). The more compelling 
>> argument for me is that timek and times do return the correct values, 
>> namely 0 for the first cycle and 0 for the time at this cycle, whereas 
>> timeinstk and timeinsts are always off by one cycle.
>>
>> cheers,
>>
>> Eduardo
>>
>> On 30.07.22 00:47, Rory Walsh wrote:
>>> Agreed 👍
>>>
>>> On Fri 29 Jul 2022, 3:13 p.m. Steven Yi,  wrote:
>>>
>>>     My vote is to change the behavior of timeinsts to read 0 at start
>>>     to match the current manual description as that's what I'd expect
>>>     and want if I used it.
>>>
>>>     On Fri, Jul 29, 2022 at 7:28 AM Victor Lazzarini
>>>      wrote:
>>>
>>>         Sounds good to me, but we also have the alternative, which is
>>>         fixing the manual.
>>>
>>>
>>>         > On 29 Jul 2022, at 11:16, Eduardo Moguillansky
>>>          wrote:
>>>         >
>>>         > *Warning*
>>>         >
>>>         > This email originated from outside of Maynooth University's
>>>         Mail System. Do not reply, click links or open attachments
>>>         unless you recognise the sender and know the content is safe.
>>>         >
>>>         > Hi,
>>>         >
>>>         > There is an unclear situation to me regarding timeinstk and
>>>         timeinsts.
>>>         >
>>>         > timeinstk returns 1 in the first cycle. This is in itself
>>>         fine and is
>>>         > documented in the manual.
>>>         >
>>>         > timeinsts, on the other hand, should "Read absolute time,
>>>         in seconds,
>>>         > since the start of an instance of an instrument.". So one
>>>         would expect
>>>         > this to be 0 on the first cycle. But it is not: timeinsts
>>>         returns the
>>>         > time corresponding to timeinstk and is always off by one
>>>         k-cycle
>>>         > (ksmps/sr).
>>>         >
>>>         > I would propose to fix timeinsts so that it conforms to the
>>>         manual.
>>>         >
>>>         > cheers,
>>>         >
>>>         > Eduardo
>>>

I thought about this also (I use timeinstk() == 1 **a lot**). But the 
current situation adds yet another quirk and is not consistent. Should 
also timeinsts keep returning the wrong  time? What about timek? Should 
it adapt to timeinstk?

The current situation is probably the result of negligence: code was put 
out there without testing and folks started using it, creating a 
sedimentary layer of malpractices which now need to be respected.

One middle ground solution is to create a new set of opcodes and mark 
timeinstk and timeinsts as deprecated. In my opinion, to just keep 
applying plasters to the manual would be somewhat sad...

cheers,

Eduardo

n 04.08.22 14:40, joachim heintz wrote:

> sorry to get late to this discussion.
>
> i don't know how many .csd files of myself (and others) it will break 
> to change this.
>
> i used
>   if timeinstk() == 1 then
>   etc
> to do something on the first k-cycle of an instrument.
>
> after this change, it will be done on the second k-cycle.  (which is 
> not mainly a question of being 0.00x seconds late, but mostly if this 
> code was meant to be executed just once.)
>
> again this is the question between consistency and backwards 
> compatibility.  i understand the desire for consistency, but in my 
> opinion, the risk of breaking a lot of working .csd files is too big, 
> so my vote would be for the manual change.
>
>     joachim
>
>
> On 30/07/2022 13:13, Victor Lazzarini wrote:
>> Perfect. Thanks.
>> Could you do a PR against develop too so we capture this change there?
>>
>>> On 30 Jul 2022, at 10:15, Eduardo Moguillansky 
>>> >> > wrote:
>>>
>>> I just sent a PR with the given changes 
>>> (https://github.com/csound/csound/pull/1614). The more compelling 
>>> argument for me is that timek and times do return the correct 
>>> values, namely 0 for the first cycle and 0 for the time at this 
>>> cycle, whereas timeinstk and timeinsts are always off by one cycle.
>>>
>>> cheers,
>>>
>>> Eduardo
>>>
>>> On 30.07.22 00:47, Rory Walsh wrote:
>>>> Agreed 👍
>>>>
>>>> On Fri 29 Jul 2022, 3:13 p.m. Steven Yi,  wrote:
>>>>
>>>>     My vote is to change the behavior of timeinsts to read 0 at start
>>>>     to match the current manual description as that's what I'd expect
>>>>     and want if I used it.
>>>>
>>>>     On Fri, Jul 29, 2022 at 7:28 AM Victor Lazzarini
>>>>      wrote:
>>>>
>>>>         Sounds good to me, but we also have the alternative, which is
>>>>         fixing the manual.
>>>>
>>>>
>>>>         > On 29 Jul 2022, at 11:16, Eduardo Moguillansky
>>>>          wrote:
>>>>         >
>>>>         > *Warning*
>>>>         >
>>>>         > This email originated from outside of Maynooth University's
>>>>         Mail System. Do not reply, click links or open attachments
>>>>         unless you recognise the sender and know the content is safe.
>>>>         >
>>>>         > Hi,
>>>>         >
>>>>         > There is an unclear situation to me regarding timeinstk and
>>>>         timeinsts.
>>>>         >
>>>>         > timeinstk returns 1 in the first cycle. This is in itself
>>>>         fine and is
>>>>         > documented in the manual.
>>>>         >
>>>>         > timeinsts, on the other hand, should "Read absolute time,
>>>>         in seconds,
>>>>         > since the start of an instance of an instrument.". So one
>>>>         would expect
>>>>         > this to be 0 on the first cycle. But it is not: timeinsts
>>>>         returns the
>>>>         > time corresponding to timeinstk and is always off by one
>>>>         k-cycle
>>>>         > (ksmps/sr).
>>>>         >
>>>>         > I would propose to fix timeinsts so that it conforms to the
>>>>         manual.
>>>>         >
>>>>         > cheers,
>>>>         >
>>>>         > Eduardo
>>>>

yes i think the best solution would be:
1. add a note in the manual for timeinstk
2. make your change as timeinstk2, or as you say make a complete new set 
and mark the old ones as deprecated.

best -
	joachim


On 04/08/2022 15:47, Eduardo Moguillansky wrote:
> I thought about this also (I use timeinstk() == 1 **a lot**). But the 
> current situation adds yet another quirk and is not consistent. Should 
> also timeinsts keep returning the wrong  time? What about timek? Should 
> it adapt to timeinstk?
> 
> The current situation is probably the result of negligence: code was put 
> out there without testing and folks started using it, creating a 
> sedimentary layer of malpractices which now need to be respected.
> 
> One middle ground solution is to create a new set of opcodes and mark 
> timeinstk and timeinsts as deprecated. In my opinion, to just keep 
> applying plasters to the manual would be somewhat sad...
> 
> cheers,
> 
> Eduardo
> 
> n 04.08.22 14:40, joachim heintz wrote:
> 
>> sorry to get late to this discussion.
>>
>> i don't know how many .csd files of myself (and others) it will break 
>> to change this.
>>
>> i used
>>   if timeinstk() == 1 then
>>   etc
>> to do something on the first k-cycle of an instrument.
>>
>> after this change, it will be done on the second k-cycle.  (which is 
>> not mainly a question of being 0.00x seconds late, but mostly if this 
>> code was meant to be executed just once.)
>>
>> again this is the question between consistency and backwards 
>> compatibility.  i understand the desire for consistency, but in my 
>> opinion, the risk of breaking a lot of working .csd files is too big, 
>> so my vote would be for the manual change.
>>
>>     joachim
>>
>>
>> On 30/07/2022 13:13, Victor Lazzarini wrote:
>>> Perfect. Thanks.
>>> Could you do a PR against develop too so we capture this change there?
>>>
>>>> On 30 Jul 2022, at 10:15, Eduardo Moguillansky 
>>>> >>> > wrote:
>>>>
>>>> I just sent a PR with the given changes 
>>>> (https://github.com/csound/csound/pull/1614). The more compelling 
>>>> argument for me is that timek and times do return the correct 
>>>> values, namely 0 for the first cycle and 0 for the time at this 
>>>> cycle, whereas timeinstk and timeinsts are always off by one cycle.
>>>>
>>>> cheers,
>>>>
>>>> Eduardo
>>>>
>>>> On 30.07.22 00:47, Rory Walsh wrote:
>>>>> Agreed 👍
>>>>>
>>>>> On Fri 29 Jul 2022, 3:13 p.m. Steven Yi,  wrote:
>>>>>
>>>>>     My vote is to change the behavior of timeinsts to read 0 at start
>>>>>     to match the current manual description as that's what I'd expect
>>>>>     and want if I used it.
>>>>>
>>>>>     On Fri, Jul 29, 2022 at 7:28 AM Victor Lazzarini
>>>>>      wrote:
>>>>>
>>>>>         Sounds good to me, but we also have the alternative, which is
>>>>>         fixing the manual.
>>>>>
>>>>>
>>>>>         > On 29 Jul 2022, at 11:16, Eduardo Moguillansky
>>>>>          wrote:
>>>>>         >
>>>>>         > *Warning*
>>>>>         >
>>>>>         > This email originated from outside of Maynooth University's
>>>>>         Mail System. Do not reply, click links or open attachments
>>>>>         unless you recognise the sender and know the content is safe.
>>>>>         >
>>>>>         > Hi,
>>>>>         >
>>>>>         > There is an unclear situation to me regarding timeinstk and
>>>>>         timeinsts.
>>>>>         >
>>>>>         > timeinstk returns 1 in the first cycle. This is in itself
>>>>>         fine and is
>>>>>         > documented in the manual.
>>>>>         >
>>>>>         > timeinsts, on the other hand, should "Read absolute time,
>>>>>         in seconds,
>>>>>         > since the start of an instance of an instrument.". So one
>>>>>         would expect
>>>>>         > this to be 0 on the first cycle. But it is not: timeinsts
>>>>>         returns the
>>>>>         > time corresponding to timeinstk and is always off by one
>>>>>         k-cycle
>>>>>         > (ksmps/sr).
>>>>>         >
>>>>>         > I would propose to fix timeinsts so that it conforms to the
>>>>>         manual.
>>>>>         >
>>>>>         > cheers,
>>>>>         >
>>>>>         > Eduardo
>>>>>

Ok, if there is consensus about going in this direction I would revert 
the PR changing timeinsts and timeinstk and add two opcodes which do the 
right thing. I'd rather **NOT** name these "timeinsts2", etc., but 
something like "eventtime" and "eventcycles"

cheers,

Eduardo

On 06.08.22 07:54, joachim heintz wrote:
> yes i think the best solution would be:
> 1. add a note in the manual for timeinstk
> 2. make your change as timeinstk2, or as you say make a complete new 
> set and mark the old ones as deprecated.
>
> best -
>     joachim
>
>
> On 04/08/2022 15:47, Eduardo Moguillansky wrote:
>> I thought about this also (I use timeinstk() == 1 **a lot**). But the 
>> current situation adds yet another quirk and is not consistent. 
>> Should also timeinsts keep returning the wrong  time? What about 
>> timek? Should it adapt to timeinstk?
>>
>> The current situation is probably the result of negligence: code was 
>> put out there without testing and folks started using it, creating a 
>> sedimentary layer of malpractices which now need to be respected.
>>
>> One middle ground solution is to create a new set of opcodes and mark 
>> timeinstk and timeinsts as deprecated. In my opinion, to just keep 
>> applying plasters to the manual would be somewhat sad...
>>
>> cheers,
>>
>> Eduardo
>>
>> n 04.08.22 14:40, joachim heintz wrote:
>>
>>> sorry to get late to this discussion.
>>>
>>> i don't know how many .csd files of myself (and others) it will 
>>> break to change this.
>>>
>>> i used
>>>   if timeinstk() == 1 then
>>>   etc
>>> to do something on the first k-cycle of an instrument.
>>>
>>> after this change, it will be done on the second k-cycle. (which is 
>>> not mainly a question of being 0.00x seconds late, but mostly if 
>>> this code was meant to be executed just once.)
>>>
>>> again this is the question between consistency and backwards 
>>> compatibility.  i understand the desire for consistency, but in my 
>>> opinion, the risk of breaking a lot of working .csd files is too 
>>> big, so my vote would be for the manual change.
>>>
>>>     joachim
>>>
>>>
>>> On 30/07/2022 13:13, Victor Lazzarini wrote:
>>>> Perfect. Thanks.
>>>> Could you do a PR against develop too so we capture this change there?
>>>>
>>>>> On 30 Jul 2022, at 10:15, Eduardo Moguillansky 
>>>>> >>>> > wrote:
>>>>>
>>>>> I just sent a PR with the given changes 
>>>>> (https://github.com/csound/csound/pull/1614). The more compelling 
>>>>> argument for me is that timek and times do return the correct 
>>>>> values, namely 0 for the first cycle and 0 for the time at this 
>>>>> cycle, whereas timeinstk and timeinsts are always off by one cycle.
>>>>>
>>>>> cheers,
>>>>>
>>>>> Eduardo
>>>>>
>>>>> On 30.07.22 00:47, Rory Walsh wrote:
>>>>>> Agreed 👍
>>>>>>
>>>>>> On Fri 29 Jul 2022, 3:13 p.m. Steven Yi,  wrote:
>>>>>>
>>>>>>     My vote is to change the behavior of timeinsts to read 0 at 
>>>>>> start
>>>>>>     to match the current manual description as that's what I'd 
>>>>>> expect
>>>>>>     and want if I used it.
>>>>>>
>>>>>>     On Fri, Jul 29, 2022 at 7:28 AM Victor Lazzarini
>>>>>>      wrote:
>>>>>>
>>>>>>         Sounds good to me, but we also have the alternative, 
>>>>>> which is
>>>>>>         fixing the manual.
>>>>>>
>>>>>>
>>>>>>         > On 29 Jul 2022, at 11:16, Eduardo Moguillansky
>>>>>>          wrote:
>>>>>>         >
>>>>>>         > *Warning*
>>>>>>         >
>>>>>>         > This email originated from outside of Maynooth 
>>>>>> University's
>>>>>>         Mail System. Do not reply, click links or open attachments
>>>>>>         unless you recognise the sender and know the content is 
>>>>>> safe.
>>>>>>         >
>>>>>>         > Hi,
>>>>>>         >
>>>>>>         > There is an unclear situation to me regarding timeinstk 
>>>>>> and
>>>>>>         timeinsts.
>>>>>>         >
>>>>>>         > timeinstk returns 1 in the first cycle. This is in itself
>>>>>>         fine and is
>>>>>>         > documented in the manual.
>>>>>>         >
>>>>>>         > timeinsts, on the other hand, should "Read absolute time,
>>>>>>         in seconds,
>>>>>>         > since the start of an instance of an instrument.". So one
>>>>>>         would expect
>>>>>>         > this to be 0 on the first cycle. But it is not: timeinsts
>>>>>>         returns the
>>>>>>         > time corresponding to timeinstk and is always off by one
>>>>>>         k-cycle
>>>>>>         > (ksmps/sr).
>>>>>>         >
>>>>>>         > I would propose to fix timeinsts so that it conforms to 
>>>>>> the
>>>>>>         manual.
>>>>>>         >
>>>>>>         > cheers,
>>>>>>         >
>>>>>>         > Eduardo
>>>>>>

I am happy with the proposal, with thanks to Eduardo for writing these.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 6 Aug 2022, at 11:06, Eduardo Moguillansky  wrote:
> 
> Ok, if there is consensus about going in this direction I would revert the PR changing timeinsts and timeinstk and add two opcodes which do the right thing. I'd rather **NOT** name these "timeinsts2", etc., but something like "eventtime" and "eventcycles"
> 
> cheers,
> 
> Eduardo
> 
>> On 06.08.22 07:54, joachim heintz wrote:
>> yes i think the best solution would be:
>> 1. add a note in the manual for timeinstk
>> 2. make your change as timeinstk2, or as you say make a complete new set and mark the old ones as deprecated.
>> 
>> best -
>>     joachim
>> 
>> 
>>> On 04/08/2022 15:47, Eduardo Moguillansky wrote:
>>> I thought about this also (I use timeinstk() == 1 **a lot**). But the current situation adds yet another quirk and is not consistent. Should also timeinsts keep returning the wrong  time? What about timek? Should it adapt to timeinstk?
>>> 
>>> The current situation is probably the result of negligence: code was put out there without testing and folks started using it, creating a sedimentary layer of malpractices which now need to be respected.
>>> 
>>> One middle ground solution is to create a new set of opcodes and mark timeinstk and timeinsts as deprecated. In my opinion, to just keep applying plasters to the manual would be somewhat sad...
>>> 
>>> cheers,
>>> 
>>> Eduardo
>>> 
>>> n 04.08.22 14:40, joachim heintz wrote:
>>> 
>>>> sorry to get late to this discussion.
>>>> 
>>>> i don't know how many .csd files of myself (and others) it will break to change this.
>>>> 
>>>> i used
>>>>   if timeinstk() == 1 then
>>>>   etc
>>>> to do something on the first k-cycle of an instrument.
>>>> 
>>>> after this change, it will be done on the second k-cycle. (which is not mainly a question of being 0.00x seconds late, but mostly if this code was meant to be executed just once.)
>>>> 
>>>> again this is the question between consistency and backwards compatibility.  i understand the desire for consistency, but in my opinion, the risk of breaking a lot of working .csd files is too big, so my vote would be for the manual change.
>>>> 
>>>>     joachim
>>>> 
>>>> 
>>>> On 30/07/2022 13:13, Victor Lazzarini wrote:
>>>>> Perfect. Thanks.
>>>>> Could you do a PR against develop too so we capture this change there?
>>>>> 
>>>>>> On 30 Jul 2022, at 10:15, Eduardo Moguillansky > wrote:
>>>>>> 
>>>>>> I just sent a PR with the given changes (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fpull%2F1614&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6695ee281dfa43ce880208da77934fd0%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637953771864449627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D11viLuK%2BLPlhfXTKeyKsxy%2BjozqonMM6G43obldoiY%3D&reserved=0). The more compelling argument for me is that timek and times do return the correct values, namely 0 for the first cycle and 0 for the time at this cycle, whereas timeinstk and timeinsts are always off by one cycle.
>>>>>> 
>>>>>> cheers,
>>>>>> 
>>>>>> Eduardo
>>>>>> 
>>>>>> On 30.07.22 00:47, Rory Walsh wrote:
>>>>>>> Agreed 👍
>>>>>>> 
>>>>>>> On Fri 29 Jul 2022, 3:13 p.m. Steven Yi,  wrote:
>>>>>>> 
>>>>>>>     My vote is to change the behavior of timeinsts to read 0 at start
>>>>>>>     to match the current manual description as that's what I'd expect
>>>>>>>     and want if I used it.
>>>>>>> 
>>>>>>>     On Fri, Jul 29, 2022 at 7:28 AM Victor Lazzarini
>>>>>>>      wrote:
>>>>>>> 
>>>>>>>         Sounds good to me, but we also have the alternative, which is
>>>>>>>         fixing the manual.
>>>>>>> 
>>>>>>> 
>>>>>>>         > On 29 Jul 2022, at 11:16, Eduardo Moguillansky
>>>>>>>          wrote:
>>>>>>>         >
>>>>>>>         > *Warning*
>>>>>>>         >
>>>>>>>         > This email originated from outside of Maynooth University's
>>>>>>>         Mail System. Do not reply, click links or open attachments
>>>>>>>         unless you recognise the sender and know the content is safe.
>>>>>>>         >
>>>>>>>         > Hi,
>>>>>>>         >
>>>>>>>         > There is an unclear situation to me regarding timeinstk and
>>>>>>>         timeinsts.
>>>>>>>         >
>>>>>>>         > timeinstk returns 1 in the first cycle. This is in itself
>>>>>>>         fine and is
>>>>>>>         > documented in the manual.
>>>>>>>         >
>>>>>>>         > timeinsts, on the other hand, should "Read absolute time,
>>>>>>>         in seconds,
>>>>>>>         > since the start of an instance of an instrument.". So one
>>>>>>>         would expect
>>>>>>>         > this to be 0 on the first cycle. But it is not: timeinsts
>>>>>>>         returns the
>>>>>>>         > time corresponding to timeinstk and is always off by one
>>>>>>>         k-cycle
>>>>>>>         > (ksmps/sr).
>>>>>>>         >
>>>>>>>         > I would propose to fix timeinsts so that it conforms to the
>>>>>>>         manual.
>>>>>>>         >
>>>>>>>         > cheers,
>>>>>>>    

Do we need to revert timeinstk and add these new opcodes or has this already been done? I can't remember seeing a PR.

We are hoping to release 6.18 at the weekend, and this needs to be done before we release.

Thanks

Victor


> On 6 Aug 2022, at 11:05, Eduardo Moguillansky  wrote:
> 
> Ok, if there is consensus about going in this direction I would revert the PR changing timeinsts and timeinstk and add two opcodes which do the right thing. I'd rather **NOT** name these "timeinsts2", etc., but something like "eventtime" and "eventcycles"
> 
> cheers,
> 
> Eduardo
> 
> On 06.08.22 07:54, joachim heintz wrote:
>> yes i think the best solution would be:
>> 1. add a note in the manual for timeinstk
>> 2. make your change as timeinstk2, or as you say make a complete new set and mark the old ones as deprecated.
>> 
>> best -
>>     joachim
>> 
>> 
>> On 04/08/2022 15:47, Eduardo Moguillansky wrote:
>>> I thought about this also (I use timeinstk() == 1 **a lot**). But the current situation adds yet another quirk and is not consistent. Should also timeinsts keep returning the wrong  time? What about timek? Should it adapt to timeinstk?
>>> 
>>> The current situation is probably the result of negligence: code was put out there without testing and folks started using it, creating a sedimentary layer of malpractices which now need to be respected.
>>> 
>>> One middle ground solution is to create a new set of opcodes and mark timeinstk and timeinsts as deprecated. In my opinion, to just keep applying plasters to the manual would be somewhat sad...
>>> 
>>> cheers,
>>> 
>>> Eduardo
>>> 
>>> n 04.08.22 14:40, joachim heintz wrote:
>>> 
>>>> sorry to get late to this discussion.
>>>> 
>>>> i don't know how many .csd files of myself (and others) it will break to change this.
>>>> 
>>>> i used
>>>>   if timeinstk() == 1 then
>>>>   etc
>>>> to do something on the first k-cycle of an instrument.
>>>> 
>>>> after this change, it will be done on the second k-cycle. (which is not mainly a question of being 0.00x seconds late, but mostly if this code was meant to be executed just once.)
>>>> 
>>>> again this is the question between consistency and backwards compatibility.  i understand the desire for consistency, but in my opinion, the risk of breaking a lot of working .csd files is too big, so my vote would be for the manual change.
>>>> 
>>>>     joachim
>>>> 
>>>> 
>>>> On 30/07/2022 13:13, Victor Lazzarini wrote:
>>>>> Perfect. Thanks.
>>>>> Could you do a PR against develop too so we capture this change there?
>>>>> 
>>>>>> On 30 Jul 2022, at 10:15, Eduardo Moguillansky > wrote:
>>>>>> 
>>>>>> I just sent a PR with the given changes (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fpull%2F1614&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6695ee281dfa43ce880208da77934fd0%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637953771864449627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D11viLuK%2BLPlhfXTKeyKsxy%2BjozqonMM6G43obldoiY%3D&reserved=0). The more compelling argument for me is that timek and times do return the correct values, namely 0 for the first cycle and 0 for the time at this cycle, whereas timeinstk and timeinsts are always off by one cycle.
>>>>>> 
>>>>>> cheers,
>>>>>> 
>>>>>> Eduardo
>>>>>> 
>>>>>> On 30.07.22 00:47, Rory Walsh wrote:
>>>>>>> Agreed 👍
>>>>>>> 
>>>>>>> On Fri 29 Jul 2022, 3:13 p.m. Steven Yi,  wrote:
>>>>>>> 
>>>>>>>     My vote is to change the behavior of timeinsts to read 0 at start
>>>>>>>     to match the current manual description as that's what I'd expect
>>>>>>>     and want if I used it.
>>>>>>> 
>>>>>>>     On Fri, Jul 29, 2022 at 7:28 AM Victor Lazzarini
>>>>>>>      wrote:
>>>>>>> 
>>>>>>>         Sounds good to me, but we also have the alternative, which is
>>>>>>>         fixing the manual.
>>>>>>> 
>>>>>>> 
>>>>>>>         > On 29 Jul 2022, at 11:16, Eduardo Moguillansky
>>>>>>>          wrote:
>>>>>>>         >
>>>>>>>         > *Warning*
>>>>>>>         >
>>>>>>>         > This email originated from outside of Maynooth University's
>>>>>>>         Mail System. Do not reply, click links or open attachments
>>>>>>>         unless you recognise the sender and know the content is safe.
>>>>>>>         >
>>>>>>>         > Hi,
>>>>>>>         >
>>>>>>>         > There is an unclear situation to me regarding timeinstk and
>>>>>>>         timeinsts.
>>>>>>>         >
>>>>>>>         > timeinstk returns 1 in the first cycle. This is in itself
>>>>>>>         fine and is
>>>>>>>         > documented in the manual.
>>>>>>>         >
>>>>>>>         > timeinsts, on the other hand, should "Read absolute time,
>>>>>>>         in seconds,
>>>>>>>         > since the start of an instance of an instrument.". So one
>>>>>>>         would expect
>>>>>>>         > this to be 0 on the first cycle. But it is not: timeinsts
>>>>>>>         returns the
>>>>>>>         > time corresponding to timeinstk and is always off by one
>>>>>>>         k-cycle
>>>>>>>         > (ksmps/sr).
>>>>>>>         >
>>>>>>>         > I would propose to fix timeinsts so that it conforms to the
>>>>>>>         manual.
>>>>>>>         >
>>>>>>>         > cheers,
>>>>>>>         >
>>>>>

I did the fixes (revert the opcodes as they were, did new ones as 
"eventtime" and "eventcycles"), I hope to do the PR today

cheers,

Eduardo

On 23.08.22 14:11, Victor Lazzarini wrote:
> Do we need to revert timeinstk and add these new opcodes or has this already been done? I can't remember seeing a PR.
>
> We are hoping to release 6.18 at the weekend, and this needs to be done before we release.
>
> Thanks
>
> Victor
>
>
>> On 6 Aug 2022, at 11:05, Eduardo Moguillansky  wrote:
>>
>> Ok, if there is consensus about going in this direction I would revert the PR changing timeinsts and timeinstk and add two opcodes which do the right thing. I'd rather **NOT** name these "timeinsts2", etc., but something like "eventtime" and "eventcycles"
>>
>> cheers,
>>
>> Eduardo
>>
>> On 06.08.22 07:54, joachim heintz wrote:
>>> yes i think the best solution would be:
>>> 1. add a note in the manual for timeinstk
>>> 2. make your change as timeinstk2, or as you say make a complete new set and mark the old ones as deprecated.
>>>
>>> best -
>>>      joachim
>>>
>>>
>>> On 04/08/2022 15:47, Eduardo Moguillansky wrote:
>>>> I thought about this also (I use timeinstk() == 1 **a lot**). But the current situation adds yet another quirk and is not consistent. Should also timeinsts keep returning the wrong  time? What about timek? Should it adapt to timeinstk?
>>>>
>>>> The current situation is probably the result of negligence: code was put out there without testing and folks started using it, creating a sedimentary layer of malpractices which now need to be respected.
>>>>
>>>> One middle ground solution is to create a new set of opcodes and mark timeinstk and timeinsts as deprecated. In my opinion, to just keep applying plasters to the manual would be somewhat sad...
>>>>
>>>> cheers,
>>>>
>>>> Eduardo
>>>>
>>>> n 04.08.22 14:40, joachim heintz wrote:
>>>>
>>>>> sorry to get late to this discussion.
>>>>>
>>>>> i don't know how many .csd files of myself (and others) it will break to change this.
>>>>>
>>>>> i used
>>>>>    if timeinstk() == 1 then
>>>>>    etc
>>>>> to do something on the first k-cycle of an instrument.
>>>>>
>>>>> after this change, it will be done on the second k-cycle. (which is not mainly a question of being 0.00x seconds late, but mostly if this code was meant to be executed just once.)
>>>>>
>>>>> again this is the question between consistency and backwards compatibility.  i understand the desire for consistency, but in my opinion, the risk of breaking a lot of working .csd files is too big, so my vote would be for the manual change.
>>>>>
>>>>>      joachim
>>>>>
>>>>>
>>>>> On 30/07/2022 13:13, Victor Lazzarini wrote:
>>>>>> Perfect. Thanks.
>>>>>> Could you do a PR against develop too so we capture this change there?
>>>>>>
>>>>>>> On 30 Jul 2022, at 10:15, Eduardo Moguillansky > wrote:
>>>>>>>
>>>>>>> I just sent a PR with the given changes (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fpull%2F1614&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6695ee281dfa43ce880208da77934fd0%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637953771864449627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D11viLuK%2BLPlhfXTKeyKsxy%2BjozqonMM6G43obldoiY%3D&reserved=0). The more compelling argument for me is that timek and times do return the correct values, namely 0 for the first cycle and 0 for the time at this cycle, whereas timeinstk and timeinsts are always off by one cycle.
>>>>>>>
>>>>>>> cheers,
>>>>>>>
>>>>>>> Eduardo
>>>>>>>
>>>>>>> On 30.07.22 00:47, Rory Walsh wrote:
>>>>>>>> Agreed 👍
>>>>>>>>
>>>>>>>> On Fri 29 Jul 2022, 3:13 p.m. Steven Yi,  wrote:
>>>>>>>>
>>>>>>>>      My vote is to change the behavior of timeinsts to read 0 at start
>>>>>>>>      to match the current manual description as that's what I'd expect
>>>>>>>>      and want if I used it.
>>>>>>>>
>>>>>>>>      On Fri, Jul 29, 2022 at 7:28 AM Victor Lazzarini
>>>>>>>>       wrote:
>>>>>>>>
>>>>>>>>          Sounds good to me, but we also have the alternative, which is
>>>>>>>>          fixing the manual.
>>>>>>>>
>>>>>>>>
>>>>>>>>          > On 29 Jul 2022, at 11:16, Eduardo Moguillansky
>>>>>>>>           wrote:
>>>>>>>>          >
>>>>>>>>          > *Warning*
>>>>>>>>          >
>>>>>>>>          > This email originated from outside of Maynooth University's
>>>>>>>>          Mail System. Do not reply, click links or open attachments
>>>>>>>>          unless you recognise the sender and know the content is safe.
>>>>>>>>          >
>>>>>>>>          > Hi,
>>>>>>>>          >
>>>>>>>>          > There is an unclear situation to me regarding timeinstk and
>>>>>>>>          timeinsts.
>>>>>>>>          >
>>>>>>>>          > timeinstk returns 1 in the first cycle. This is in itself
>>>>>>>>          fine and is
>>>>>>>>          > documented in the manual.
>>>>>>>>          >
>>>>>>>>          > timeinsts, on the other hand, should "Read absolute time,
>>>>>>>>          in seconds,
>>>>>>>>          > since the start of an instance of an instrument.". So one
>>>>>>>>          would expect
>>>>>>>>          > this to be 0 on the first cycle. But it is not: timeinsts
>>>>>>>>          returns the
>>>>>>>>          > time corresponding to timeinstk and is always off by one
>>>>>>>>          k-cycle
>>>>>>>>          > (ksmps/sr).
>>>>>>>>          >
>>>>>>>>          > I would propose to fix timeinsts so that it conforms to the
>>>>>>>>          manual.
>>>>>>>>          >
>>>>>>>>          > cheers,
>>>>>>>>          >
>>>>>>>>          > Eduardo

On a side note, "timek" and  "times" were not working correctly probably 
for a long time. It seems that  declaring the .i variant of an opcode 
prior to the .k variant makes csound pick the wrong opcode even if the 
output variable is a k-variable. So "ktimes = times()" just returns 0. 
If this order is fixed, both times and timek return the same one-cycle 
shift as timeinsts and timeinstk. I would suggest to also leave them and 
provide two parallel opcodes, "elapsedtime" and "elapsedcycles" or 
"totaltime" and "totalcycles" to fix these.

Just the fact that this went unnoticed is somewhat alarming, makes me 
think that there might be (many) other cases where this opcode selection 
mechanism is not doing what it's supposed to...



On 23.08.22 14:11, Victor Lazzarini wrote:
> Do we need to revert timeinstk and add these new opcodes or has this already been done? I can't remember seeing a PR.
>
> We are hoping to release 6.18 at the weekend, and this needs to be done before we release.
>
> Thanks
>
> Victor
>
>
>> On 6 Aug 2022, at 11:05, Eduardo Moguillansky  wrote:
>>
>> Ok, if there is consensus about going in this direction I would revert the PR changing timeinsts and timeinstk and add two opcodes which do the right thing. I'd rather **NOT** name these "timeinsts2", etc., but something like "eventtime" and "eventcycles"
>>
>> cheers,
>>
>> Eduardo
>>
>> On 06.08.22 07:54, joachim heintz wrote:
>>> yes i think the best solution would be:
>>> 1. add a note in the manual for timeinstk
>>> 2. make your change as timeinstk2, or as you say make a complete new set and mark the old ones as deprecated.
>>>
>>> best -
>>>      joachim
>>>
>>>
>>> On 04/08/2022 15:47, Eduardo Moguillansky wrote:
>>>> I thought about this also (I use timeinstk() == 1 **a lot**). But the current situation adds yet another quirk and is not consistent. Should also timeinsts keep returning the wrong  time? What about timek? Should it adapt to timeinstk?
>>>>
>>>> The current situation is probably the result of negligence: code was put out there without testing and folks started using it, creating a sedimentary layer of malpractices which now need to be respected.
>>>>
>>>> One middle ground solution is to create a new set of opcodes and mark timeinstk and timeinsts as deprecated. In my opinion, to just keep applying plasters to the manual would be somewhat sad...
>>>>
>>>> cheers,
>>>>
>>>> Eduardo
>>>>
>>>> n 04.08.22 14:40, joachim heintz wrote:
>>>>
>>>>> sorry to get late to this discussion.
>>>>>
>>>>> i don't know how many .csd files of myself (and others) it will break to change this.
>>>>>
>>>>> i used
>>>>>    if timeinstk() == 1 then
>>>>>    etc
>>>>> to do something on the first k-cycle of an instrument.
>>>>>
>>>>> after this change, it will be done on the second k-cycle. (which is not mainly a question of being 0.00x seconds late, but mostly if this code was meant to be executed just once.)
>>>>>
>>>>> again this is the question between consistency and backwards compatibility.  i understand the desire for consistency, but in my opinion, the risk of breaking a lot of working .csd files is too big, so my vote would be for the manual change.
>>>>>
>>>>>      joachim
>>>>>
>>>>>
>>>>> On 30/07/2022 13:13, Victor Lazzarini wrote:
>>>>>> Perfect. Thanks.
>>>>>> Could you do a PR against develop too so we capture this change there?
>>>>>>
>>>>>>> On 30 Jul 2022, at 10:15, Eduardo Moguillansky > wrote:
>>>>>>>
>>>>>>> I just sent a PR with the given changes (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fpull%2F1614&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6695ee281dfa43ce880208da77934fd0%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637953771864449627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D11viLuK%2BLPlhfXTKeyKsxy%2BjozqonMM6G43obldoiY%3D&reserved=0). The more compelling argument for me is that timek and times do return the correct values, namely 0 for the first cycle and 0 for the time at this cycle, whereas timeinstk and timeinsts are always off by one cycle.
>>>>>>>
>>>>>>> cheers,
>>>>>>>
>>>>>>> Eduardo
>>>>>>>
>>>>>>> On 30.07.22 00:47, Rory Walsh wrote:
>>>>>>>> Agreed 👍
>>>>>>>>
>>>>>>>> On Fri 29 Jul 2022, 3:13 p.m. Steven Yi,  wrote:
>>>>>>>>
>>>>>>>>      My vote is to change the behavior of timeinsts to read 0 at start
>>>>>>>>      to match the current manual description as that's what I'd expect
>>>>>>>>      and want if I used it.
>>>>>>>>
>>>>>>>>      On Fri, Jul 29, 2022 at 7:28 AM Victor Lazzarini
>>>>>>>>       wrote:
>>>>>>>>
>>>>>>>>          Sounds good to me, but we also have the alternative, which is
>>>>>>>>          fixing the manual.
>>>>>>>>
>>>>>>>>
>>>>>>>>          > On 29 Jul 2022, at 11:16, Eduardo Moguillansky
>>>>>>>>           wrote:
>>>>>>>>          >
>>>>>>>>          > *Warning*
>>>>>>>>          >
>>>>>>>>          > This email originated from outside of Maynooth University's
>>>>>>>>          Mail System. Do not reply, click links or open attachments
>>>>>>>>          unless you recognise the sender and know the content is safe.
>>>>>>>>          >
>>>>>>>>          > Hi,
>>>>>>>>          >
>>>>>>>>          > There is an unclear situation to me regarding timeinstk and
>>>>>>>>          timeinsts.
>>>>>>>>          >
>>>>>>>>          > timeinstk returns 1 in the first cycle. This is in itself
>>>>>>>>          fine and is
>>>>>>>>          > documented in the manual.
>>>>>>>>          >
>>>>>>>>          > timeinsts, on the other hand, should "Read absolute time,
>>>>>>>>          in seconds,
>>>>>>>>          > since the start of an instance of an instrument.". So one
>>>>>>>>          would expect
>>>>>>>>          > this to be 0 on the first cycle. But it is not: timeinsts
>>>>>>>>          returns the
>>>>>>>>          > time corresponding to timeinstk and is always off by one
>>>>>>>>          k-cycle
>>>>>>>>          > (ksmps/sr).
>>>>>>>>          >
>>>>>>>>          > I would propose to fix timeinsts so that it conforms to the
>>>>>>>>          manual.
>>>>>>>>          >
>>>>>>>>          > cheers,
>>>>>>>>          >
>>>>>>>>          > Eduardo

The opcode selection is problematic for sure, but just to note in
develop (cs7) the selection *should* be picking the right one since it
reduces the = out and does the opcode selection as if the code was
"ktimes times".  That rewrite of the tree does end up getting a lot
closer to the right values most of the time, but still a more proper
type calculation should be investigated.

On Tue, Aug 23, 2022 at 10:54 AM Eduardo Moguillansky
 wrote:
>
> On a side note, "timek" and  "times" were not working correctly probably
> for a long time. It seems that  declaring the .i variant of an opcode
> prior to the .k variant makes csound pick the wrong opcode even if the
> output variable is a k-variable. So "ktimes = times()" just returns 0.
> If this order is fixed, both times and timek return the same one-cycle
> shift as timeinsts and timeinstk. I would suggest to also leave them and
> provide two parallel opcodes, "elapsedtime" and "elapsedcycles" or
> "totaltime" and "totalcycles" to fix these.
>
> Just the fact that this went unnoticed is somewhat alarming, makes me
> think that there might be (many) other cases where this opcode selection
> mechanism is not doing what it's supposed to...
>
>
>
> On 23.08.22 14:11, Victor Lazzarini wrote:
> > Do we need to revert timeinstk and add these new opcodes or has this already been done? I can't remember seeing a PR.
> >
> > We are hoping to release 6.18 at the weekend, and this needs to be done before we release.
> >
> > Thanks
> >
> > Victor
> >
> >
> >> On 6 Aug 2022, at 11:05, Eduardo Moguillansky  wrote:
> >>
> >> Ok, if there is consensus about going in this direction I would revert the PR changing timeinsts and timeinstk and add two opcodes which do the right thing. I'd rather **NOT** name these "timeinsts2", etc., but something like "eventtime" and "eventcycles"
> >>
> >> cheers,
> >>
> >> Eduardo
> >>
> >> On 06.08.22 07:54, joachim heintz wrote:
> >>> yes i think the best solution would be:
> >>> 1. add a note in the manual for timeinstk
> >>> 2. make your change as timeinstk2, or as you say make a complete new set and mark the old ones as deprecated.
> >>>
> >>> best -
> >>>      joachim
> >>>
> >>>
> >>> On 04/08/2022 15:47, Eduardo Moguillansky wrote:
> >>>> I thought about this also (I use timeinstk() == 1 **a lot**). But the current situation adds yet another quirk and is not consistent. Should also timeinsts keep returning the wrong  time? What about timek? Should it adapt to timeinstk?
> >>>>
> >>>> The current situation is probably the result of negligence: code was put out there without testing and folks started using it, creating a sedimentary layer of malpractices which now need to be respected.
> >>>>
> >>>> One middle ground solution is to create a new set of opcodes and mark timeinstk and timeinsts as deprecated. In my opinion, to just keep applying plasters to the manual would be somewhat sad...
> >>>>
> >>>> cheers,
> >>>>
> >>>> Eduardo
> >>>>
> >>>> n 04.08.22 14:40, joachim heintz wrote:
> >>>>
> >>>>> sorry to get late to this discussion.
> >>>>>
> >>>>> i don't know how many .csd files of myself (and others) it will break to change this.
> >>>>>
> >>>>> i used
> >>>>>    if timeinstk() == 1 then
> >>>>>    etc
> >>>>> to do something on the first k-cycle of an instrument.
> >>>>>
> >>>>> after this change, it will be done on the second k-cycle. (which is not mainly a question of being 0.00x seconds late, but mostly if this code was meant to be executed just once.)
> >>>>>
> >>>>> again this is the question between consistency and backwards compatibility.  i understand the desire for consistency, but in my opinion, the risk of breaking a lot of working .csd files is too big, so my vote would be for the manual change.
> >>>>>
> >>>>>      joachim
> >>>>>
> >>>>>
> >>>>> On 30/07/2022 13:13, Victor Lazzarini wrote:
> >>>>>> Perfect. Thanks.
> >>>>>> Could you do a PR against develop too so we capture this change there?
> >>>>>>
> >>>>>>> On 30 Jul 2022, at 10:15, Eduardo Moguillansky > wrote:
> >>>>>>>
> >>>>>>> I just sent a PR with the given changes (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fpull%2F1614&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6695ee281dfa43ce880208da77934fd0%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637953771864449627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D11viLuK%2BLPlhfXTKeyKsxy%2BjozqonMM6G43obldoiY%3D&reserved=0). The more compelling argument for me is that timek and times do return the correct values, namely 0 for the first cycle and 0 for the time at this cycle, whereas timeinstk and timeinsts are always off by one cycle.
> >>>>>>>
> >>>>>>> cheers,
> >>>>>>>
> >>>>>>> Eduardo
> >>>>>>>
> >>>>>>> On 30.07.22 00:47, Rory Walsh wrote:
> >>>>>>>> Agreed 👍
> >>>>>>>>
> >>>>>>>> On Fri 29 Jul 2022, 3:13 p.m. Steven Yi,  wrote:
> >>>>>>>>
> >>>>>>>>      My vote is to change the behavior of timeinsts to read 0 at start
> >>>>>>>>      to match the current manual description as that's what I'd expect
> >>>>>>>>      and want if I used it.
> >>>>>>>>
> >>>>>>>>      On Fri, Jul 29, 2022 at 7:28 AM Victor Lazzarini
> >>>>>>>>       wrote:
> >>>>>>>>
> >>>>>>>>          Sounds good to me, but we also have the alternative, which is
> >>>>>>>>          fixing the manual.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>          > On 29 Jul 2022, at 11:16, Eduardo Moguillansky
> >>>>>>>>           wrote:
> >>>>>>>>          >
> >>>>>>>>          > *Warning*
> >>>>>>>>          >
> >>>>>>>>          > This email originated from outside of Maynooth University's
> >>>>>>>>          Mail System. Do not reply, click links or open attachments
> >>>>>>>>          unless you recognise the sender and know the content is safe.
> >>>>>>>>          >
> >>>>>>>>          > Hi,
> >>>>>>>>          >
> >>>>>>>>          > There is an unclear situation to me regarding timeinstk and
> >>>>>>>>          timeinsts.
> >>>>>>>>          >
> >>>>>>>>          > timeinstk returns 1 in the first cycle. This is in itself
> >>>>>>>>          fine and is
> >>>>>>>>          > documented in the manual.
> >>>>>>>>          >
> >>>>>>>>          > timeinsts, on the other hand, should "Read absolute time,
> >>>>>>>>          in seconds,
> >>>>>>>>          > since the start of an instance of an instrument.". So one
> >>>>>>>>          would expect
> >>>>>>>>          > this to be 0 on the first cycle. But it is not: timeinsts
> >>>>>>>>          returns the
> >>>>>>>>          > time corresponding to timeinstk and is always off by one
> >>>>>>>>          k-cycle
> >>>>>>>>          > (ksmps/sr).
> >>>>>>>>          >
> >>>>>>>>          > I would propose to fix timeinsts so that it conforms to the
> >>>>>>>>          manual.
> >>>>>>>>          >
> >>>>>>>>          > cheers,
> >>>>>>>>          >
> >>>>>>>>          > Eduardo