t present slicearray for both k and a arrays runs at both i-time and
k-rate.  It has been suggested in issue #1039 hat it should only run
at k-rate.

I would be pleased to hear any opinions, thoughts r comments on this.

I suppose k and a rate stuff should if possible be non-op at i-time (e.g. not 
produce an output, but do all the necessary
allocation, initialisation etc).

To reuse code, some operators I wrote
don't observe this, but I assumed it was
benign in those cases.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 6 Oct 2018, at 19:09, John  wrote:
> 
> t present slicearray for both k and a arrays runs at both i-time and
> k-rate.  It has been suggested in issue #1039 hat it should only run
> at k-rate.
> 
> I would be pleased to hear any opinions, thoughts r comments on this.
> 

I seem to remember that someone asked that slicearray should work this 
way. The equialent tabarray does nit act at i-time

It could have beeb April 8 this year/

On Sat, 6 Oct 2018, Victor Lazzarini wrote:

> I suppose k and a rate stuff should if possible be non-op at i-time (e.g. not
> produce an output, but do all the necessary
> allocation, initialisation etc).
>
> To reuse code, some operators I wrote
> don't observe this, but I assumed it was
> benign in those cases.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 6 Oct 2018, at 19:09, John  wrote:
>>
>> t present slicearray for both k and a arrays runs at both i-time and
>> k-rate.  It has been suggested in issue #1039 hat it should only run
>> at k-rate.
>>
>> I would be pleased to hear any opinions, thoughts r comments on this.
>>
>> ==John ffitch

>From git log.....

commit a8c49878a2c964288edc05cbb975652a28c7108a
Author: jpff 
Date:   Sun Apr 8 01:06:30 2018 +0100

     workarounf slicearray issue

commit 2e4c54823b9d2c39585d7b8853fd24f53307d3f4
Author: jpff 
Date:   Sun Apr 8 01:03:04 2018 +0100

Investigating logs it has been this way since before May21 2014 so any 
change would be a potential compatibility issue.

Also ound
commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
Author: Steven Yi 
Date:   Thu Apr 17 11:04:55 2014 -0400

     rewrote slicearray to use type system information and copyValue 
functions


where it is both i and k rate.  Harder to check earlier.


On Sat, 6 Oct 2018, John wrote:

> t present slicearray for both k and a arrays runs at both i-time and
> k-rate.  It has been suggested in issue #1039 hat it should only run
> at k-rate.
>
> I would be pleased to hear any opinions, thoughts r comments on this.
>
> ==John ffitch

Hi John,
from a look to the history, the first time that you changed that code to make slicearray work both at i-time and k-time was in your commits on Apr 15, 2014. Before that date, slicearray ran only at k-time.

Do you know/remember why you changed the standard (and correct, in my opinion, for all the reasons I explained in this github issue) behaviour?

Il 2018-10-06 21:48 jpff ha scritto:

Investigating logs it has been this way since before May21 2014 so any change would be a potential compatibility issue.

Also ound
commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
Author: Steven Yi <stevenyi@gmail.com>
Date:   Thu Apr 17 11:04:55 2014 -0400

    rewrote slicearray to use type system information and copyValue functions


where it is both i and k rate.  Harder to check earlier.


On Sat, 6 Oct 2018, John wrote:

t present slicearray for both k and a arrays runs at both i-time and
k-rate.  It has been suggested in issue #1039 hat it should only run
at k-rate.

I would be pleased to hear any opinions, thoughts r comments on this.

==John ffitch

If you read that commit carefully it does not have slicearray running at 
i-time.  Thread is 2 so perf only.  Looking at commit 
bfdd09a6299688e4104fbf42ea1b65b274a69ee5
it is running at i and k -- date Thu Apr 17 11:04:55 2014

My memory is not good, but I think Joachim asked for this or something similar.


On Sat, 6 Oct 2018, Mauro Giubileo wrote:

> 
> Hi John,
> from a look to the history, the first time that you changed that code to make
> slicearray work both at i-time and k-time was in your commits on Apr 15, 2014.
> Before that date, slicearray ran only at k-time.
> 
> Do you know/remember why you changed the standard (and correct, in my opinion,
> for all the reasons I explained in this github issue) behaviour?
> 
> Regards,
> Mauro
> 
> Il 2018-10-06 21:48 jpff ha scritto:
>
>       Investigating logs it has been this way since before May21 2014 so
>       any change would be a potential compatibility issue.
>
>       Also ound
>       commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
>       Author: Steven Yi 
>       Date:   Thu Apr 17 11:04:55 2014 -0400
>
>           rewrote slicearray to use type system information and
>       copyValue functions
> 
>
>       where it is both i and k rate.  Harder to check earlier.
> 
>
>       On Sat, 6 Oct 2018, John wrote:
>
>             t present slicearray for both k and a arrays runs at both i-time and
>             k-rate.  It has been suggested in issue #1039 hat it should only run
>             at k-rate.
>
>             I would be pleased to hear any opinions, thoughts r comments on this.
>
>             ==John ffitch
> 
> 
>

Hi John,

I read that commit carefully (Apr 15 2014 commit 59bc4de8fd4c200bb2a290ac760e8103f737b8f9), and it's clear to me that before that date there was only a single slicearray that worked at k-time (no i-time). But in that date you removed the single slicearray:

- { "slicearray", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii", NULL, (SUBR) tabslice, NULL },

and added the following:

+ { "slicearray.k", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii", (SUBR) tabslice, (SUBR) tabslice, NULL },
+ { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii", (SUBR) tabslice, NULL, NULL },

So, I suppose that at that time someone (maybe Joachim?) asked to add an i-time version of slicearray (being that there was only a k-time version). Then, for some unknown reason (could be a mistake?) you made the k-time version work at i-time too. That's what I suspect, because honestly I see no valid reason to make a statement like "kOutArray[] slicearray kInputArray, iStart, iEnd" work at both i-time and k-time. Someone knows a scenario where that could be needed? I think it would be much more useful to allow the user to use the same k-array for input and output (and this could be achieved returning to a slicearray:k[] that run only at k-time).

Regards,
Mauro

Il 2018-10-06 22:58 jpff ha scritto:

If you read that commit carefully it does not have slicearray running at i-time.  Thread is 2 so perf only.  Looking at commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
it is running at i and k -- date Thu Apr 17 11:04:55 2014

My memory is not good, but I think Joachim asked for this or something similar.


On Sat, 6 Oct 2018, Mauro Giubileo wrote:

Hi John,
from a look to the history, the first time that you changed that code to make
slicearray work both at i-time and k-time was in your commits on Apr 15, 2014.
Before that date, slicearray ran only at k-time.

Do you know/remember why you changed the standard (and correct, in my opinion,
for all the reasons I explained in this github issue) behaviour?

Regards,
Mauro

Il 2018-10-06 21:48 jpff ha scritto:

      Investigating logs it has been this way since before May21 2014 so
      any change would be a potential compatibility issue.

      Also ound
      commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
      Author: Steven Yi <stevenyi@gmail.com>
      Date:   Thu Apr 17 11:04:55 2014 -0400

          rewrote slicearray to use type system information and
      copyValue functions


      where it is both i and k rate.  Harder to check earlier.


      On Sat, 6 Oct 2018, John wrote:

            t present slicearray for both k and a arrays runs at both i-time and
            k-rate.  It has been suggested in issue #1039 hat it should only run
            at k-rate.

            I would be pleased to hear any opinions, thoughts r comments on this.

            ==John ffitch

Sorry, as I said before I've no experience in Csound source code, but if you said that the "2" in that field (the fourth) is to interpret as k-rate only, then what does the following line mean?

{ "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii", (SUBR) tabslice, NULL, NULL },

I supposed that, being that there is only a single "(SUBR) tabslice" in the first of the last 3 fields, that means that a slicearray:i[] runs only at i-time, and on that occasion it uses the 'tabslice' function. I'm wrong?

Regards,
Mauro

Il 2018-10-06 23:43 John ff ha scritto:

I repeat. The thread field is 2 which is krate only

Sent from TypeApp

On 6 Oct 2018, at 22:29, Mauro Giubileo <mgiubileo@computeraltafed.it> wrote:

Hi John,

I read that commit carefully (Apr 15 2014 commit 59bc4de8fd4c200bb2a290ac760e8103f737b8f9), and it's clear to me that before that date there was only a single slicearray that worked at k-time (no i-time). But in that date you removed the single slicearray:

- { "slicearray", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii", NULL, (SUBR) tabslice, NULL },

and added the following:

+ { "slicearray.k", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii", (SUBR) tabslice, (SUBR) tabslice, NULL },
+ { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii", (SUBR) tabslice, NULL, NULL },

So, I suppose that at that time someone (maybe Joachim?) asked to add an i-time version of slicearray (being that there was only a k-time version). Then, for some unknown reason (could be a mistake?) you made the k-time version work at i-time too. That's what I suspect, because honestly I see no valid reason to make a statement like "kOutArray[] slicearray kInputArray, iStart, iEnd" work at both i-time and k-time. Someone knows a scenario where that could be needed? I think it would be much more useful to allow the user to use the same k-array for input and output (and this could be achieved returning to a slicearray:k[] that run only at k-time).

Regards,
Mauro

Il 2018-10-06 22:58 jpff ha scritto:

If you read that commit carefully it does not have slicearray running at i-time.  Thread is 2 so perf only.  Looking at commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
it is running at i and k -- date Thu Apr 17 11:04:55 2014

My memory is not good, but I think Joachim asked for this or something similar.


On Sat, 6 Oct 2018, Mauro Giubileo wrote:

Hi John,
from a look to the history, the first time that you changed that code to make
slicearray work both at i-time and k-time was in your commits on Apr 15, 2014.
Before that date, slicearray ran only at k-time.

Do you know/remember why you changed the standard (and correct, in my opinion,
for all the reasons I explained in this github issue) behaviour?

Regards,
Mauro

Il 2018-10-06 21:48 jpff ha scritto:

      Investigating logs it has been this way since before May21 2014 so
      any change would be a potential compatibility issue.

      Also ound
      commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
      Author: Steven Yi <stevenyi@gmail.com>
      Date:   Thu Apr 17 11:04:55 2014 -0400

          rewrote slicearray to use type system information and
      copyValue functions


      where it is both i and k rate.  Harder to check earlier.


      On Sat, 6 Oct 2018, John wrote:

            t present slicearray for both k and a arrays runs at both i-time and
            k-rate.  It has been suggested in issue #1039 hat it should only run
            at k-rate.

            I would be pleased to hear any opinions, thoughts r comments on this.

            ==John ffitch

Ok, now I understand, but I see you corrected that code yourself on Apr 16 2014 commit 48a10a562baa3889c3b28972876edb00f85af68f:

 - { "slicearray.k", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii",

 + { "slicearray.k", sizeof(TABSLICE), 0, 3, "k[]", "k[]ii", (SUBR) tabslice, (SUBR) tabslice, NULL },

 - { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii",

 + { "slicearray.i", sizeof(TABSLICE), 0, 1, "i[]", "i[]ii", (SUBR) tabslice, NULL, NULL },

Anyway it would be nice to know the reason for that change in the standard behaviour. I searched on the mailing list archive but I haven't found messages before 2015. Maybe someone has those messages from 2014 ?

Regards,
Mauro

Il 2018-10-07 00:38 John ff ha scritto:

That code is wrong and would default if run

Sent from TypeApp

On 6 Oct 2018, at 23:09, Mauro Giubileo <mgiubileo@computeraltafed.it> wrote:

Sorry, as I said before I've no experience in Csound source code, but if you said that the "2" in that field (the fourth) is to interpret as k-rate only, then what does the following line mean?

{ "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii", (SUBR) tabslice, NULL, NULL },

I supposed that, being that there is only a single "(SUBR) tabslice" in the first of the last 3 fields, that means that a slicearray:i[] runs only at i-time, and on that occasion it uses the 'tabslice' function. I'm wrong?

Regards,
Mauro

Il 2018-10-06 23:43 John ff ha scritto:

I repeat. The thread field is 2 which is krate only

Sent from TypeApp

On 6 Oct 2018, at 22:29, Mauro Giubileo < mgiubileo@computeraltafed.it> wrote:

Hi John,

I read that commit carefully (Apr 15 2014 commit 59bc4de8fd4c200bb2a290ac760e8103f737b8f9), and it's clear to me that before that date there was only a single slicearray that worked at k-time (no i-time). But in that date you removed the single slicearray:

- { "slicearray", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii", NULL, (SUBR) tabslice, NULL },

and added the following:

+ { "slicearray.k", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii", (SUBR) tabslice, (SUBR) tabslice, NULL },
+ { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii", (SUBR) tabslice, NULL, NULL },

So, I suppose that at that time someone (maybe Joachim?) asked to add an i-time version of slicearray (being that there was only a k-time version). Then, for some unknown reason (could be a mistake?) you made the k-time version work at i-time too. That's what I suspect, because honestly I see no valid reason to make a statement like "kOutArray[] slicearray kInputArray, iStart, iEnd" work at both i-time and k-time. Someone knows a scenario where that could be needed? I think it would be much more useful to allow the user to use the same k-array for input and output (and this could be achieved returning to a slicearray:k[] that run only at k-time).

Regards,
Mauro

Il 2018-10-06 22:58 jpff ha scritto:

If you read that commit carefully it does not have slicearray running at i-time.  Thread is 2 so perf only.  Looking at commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
it is running at i and k -- date Thu Apr 17 11:04:55 2014

My memory is not good, but I think Joachim asked for this or something similar.


On Sat, 6 Oct 2018, Mauro Giubileo wrote:

Hi John,
from a look to the history, the first time that you changed that code to make
slicearray work both at i-time and k-time was in your commits on Apr 15, 2014.
Before that date, slicearray ran only at k-time.

Do you know/remember why you changed the standard (and correct, in my opinion,
for all the reasons I explained in this github issue) behaviour?

Regards,
Mauro

Il 2018-10-06 21:48 jpff ha scritto:

      Investigating logs it has been this way since before May21 2014 so
      any change would be a potential compatibility issue.

      Also ound
      commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
      Author: Steven Yi <stevenyi@gmail.com>
      Date:   Thu Apr 17 11:04:55 2014 -0400

          rewrote slicearray to use type system information and
      copyValue functions


      where it is both i and k rate.  Harder to check earlier.


      On Sat, 6 Oct 2018, John wrote:

            t present slicearray for both k and a arrays runs at both i-time and
            k-rate.  It has been suggested in issue #1039 hat it should only run
            at k-rate.

            I would be pleased to hear any opinions, thoughts r comments on this.

            ==John ffitch

Thank you for finding that.  I failed to locate it.

Earlier archives of mail are on dream.cs.bath.ac.uk where I will look. In the morning.

⁣Sent from TypeApp ​

On Oct 7, 2018, 00:23, at 00:23, Mauro Giubileo  wrote:
>Ok, now I understand, but I see you corrected that code yourself on Apr
>16 2014 commit 48a10a562baa3889c3b28972876edb00f85af68f: 
>
> - { "slicearray.k", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii",
>
> + { "slicearray.k", sizeof(TABSLICE), 0, 3, "k[]", "k[]ii", (SUBR)
>tabslice, (SUBR) tabslice, NULL },
>
> - { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii",
>
> + { "slicearray.i", sizeof(TABSLICE), 0, 1, "i[]", "i[]ii", (SUBR)
>tabslice, NULL, NULL }, 
>
>Anyway it would be nice to know the reason for that change in the
>standard behaviour. I searched on the mailing list archive but I
>haven't
>found messages before 2015. Maybe someone has those messages from 2014
>?
>
>
>Regards,
>Mauro 
>
>Il 2018-10-07 00:38 John ff ha scritto:
>
>> That code is wrong and would default if run
>> 
>> Sent from TypeApp [1] 
>> On 6 Oct 2018, at 23:09, Mauro Giubileo
> wrote: 
>> 
>> Sorry, as I said before I've no experience in Csound source code, but
>if you said that the "2" in that field (the fourth) is to interpret as
>k-rate only, then what does the following line mean? 
>> 
>> { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii", (SUBR)
>tabslice, NULL, NULL }, 
>> 
>> I supposed that, being that there is only a single "(SUBR) tabslice"
>in the first of the last 3 fields, that means that a slicearray:i[]
>runs only at i-time, and on that occasion it uses the 'tabslice'
>function. I'm wrong? 
>> 
>> Regards,
>> Mauro 
>> 
>> Il 2018-10-06 23:43 John ff ha scritto: 
>> I repeat. The thread field is 2 which is krate only 
>> 
>> Sent from TypeApp [1] 
>> On 6 Oct 2018, at 22:29, Mauro Giubileo <
>mgiubileo@computeraltafed.it> wrote: 
>> 
>> Hi John, 
>> 
>> I read that commit carefully (Apr 15 2014 commit
>59bc4de8fd4c200bb2a290ac760e8103f737b8f9), and it's clear to me that
>before that date there was only a single slicearray that worked at
>k-time (no i-time). But in that date you removed the single slicearray:
>
>> 
>> - { "slicearray", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii", NULL,
>(SUBR) tabslice, NULL }, 
>> 
>> and added the following: 
>> 
>> + { "slicearray.k", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii", (SUBR)
>tabslice, (SUBR) tabslice, NULL },
>> + { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii", (SUBR)
>tabslice, NULL, NULL }, 
>> 
>> So, I suppose that at that time someone (maybe Joachim?) asked to add
>an i-time version of slicearray (being that there was only a k-time
>version). Then, for some unknown reason (could be a mistake?) you made
>the k-time version work at i-time too. That's what I suspect, because
>honestly I see no valid reason to make a statement like "kOutArray[]
>slicearray kInputArray, iStart, iEnd" work at both i-time and k-time.
>Someone knows a scenario where that could be needed? I think it would
>be much more useful to allow the user to use the same k-array for input
>and output (and this could be achieved returning to a slicearray:k[]
>that run only at k-time). 
>> 
>> Regards,
>> Mauro 
>> 
>> Il 2018-10-06 22:58 jpff ha scritto: 
>> If you read that commit carefully it does not have slicearray running
>at i-time.  Thread is 2 so perf only.  Looking at commit
>bfdd09a6299688e4104fbf42ea1b65b274a69ee5 
>> it is running at i and k -- date Thu Apr 17 11:04:55 2014 
>> 
>> My memory is not good, but I think Joachim asked for this or
>something similar. 
>> 
>> On Sat, 6 Oct 2018, Mauro Giubileo wrote: 
>> 
>> Hi John, 
>> from a look to the history, the first time that you changed that code
>to make 
>> slicearray work both at i-time and k-time was in your commits on Apr
>15, 2014. 
>> Before that date, slicearray ran only at k-time. 
>> 
>> Do you know/remember why you changed the standard (and correct, in my
>opinion, 
>> for all the reasons I explained in this github issue) behaviour? 
>> 
>> Regards, 
>> Mauro 
>> 
>> Il 2018-10-06 21:48 jpff ha scritto: 
>> 
>> Investigating logs it has been this way since before May21 2014 so 
>> any change would be a potential compatibility issue. 
>> 
>> Also ound 
>> commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5 
>> Author: Steven Yi  
>> Date:   Thu Apr 17 11:04:55 2014 -0400 
>> 
>> rewrote slicearray to use type system information and 
>> copyValue functions 
>> 
>> where it is both i and k rate.  Harder to check earlier. 
>> 
>> On Sat, 6 Oct 2018, John wrote: 
>> 
>> t present slicearray for both k and a arrays runs at both i-time and 
>> k-rate.  It has been suggested in issue #1039 hat it should only run 
>> at k-rate. 
>> 
>> I would be pleased to hear any opinions, thoughts r comments on this.
>
>> 
>> ==John ffitch
> 
>
>Links:
>------
>[1] http:

yes, i found it. (thanks, john, for the attention.)

i wrote on april 9, 2014 a list of suggestions for extension of the 
array opcodes.  amongst them:
3) slicearray
a) not possible to have i-arrays, e.g.
    iArr[]  fillarray  1, 2, 3, 4, 5, 6, 7, 8, 9
    iArr1[] init       5
    iArr2[] init       4
    iArr1   slicearray iArr, 0, 4        ;[1, 2, 3, 4, 5]
    iArr2   slicearray iArr, 5, 8        ;[6, 7, 8, 9]
b) same for S-arrays:
    SArr[]  init       9
    SArr1[] init       5
    SArr1   slicearray SArr, 0, 4

steven wrote on april 17:
 > I think I've made slicearray work generically now for any type.
 > Joachim: could you pull from develop and try with your various array 
tests?

so it looks like the discussion was to add an i-rate version for 
slicearray, but not to output initialization for k-rate slicearray (if i 
followed up your discussion right).

	joachim


On 07/10/18 01:22, Mauro Giubileo wrote:
> Ok, now I understand, but I see you corrected that code yourself on Apr
> 16 2014 commit 48a10a562baa3889c3b28972876edb00f85af68f:
>
>  - { "slicearray.k", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii",
>
>  + { "slicearray.k", sizeof(TABSLICE), 0, 3, "k[]", "k[]ii", (SUBR)
> tabslice, (SUBR) tabslice, NULL },
>
>  - { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii",
>
>  + { "slicearray.i", sizeof(TABSLICE), 0, 1, "i[]", "i[]ii", (SUBR)
> tabslice, NULL, NULL },
>
>
> Anyway it would be nice to know the reason for that change in the
> standard behaviour. I searched on the mailing list archive but I haven't
> found messages before 2015. Maybe someone has those messages from 2014 ?
>
> Regards,
> Mauro
>
>
> Il 2018-10-07 00:38 John ff ha scritto:
>
>> That code is wrong and would default if run
>>
>>
>> Sent from TypeApp 
>> On 6 Oct 2018, at 23:09, Mauro Giubileo > > wrote:
>>
>>     Sorry, as I said before I've no experience in Csound source code,
>>     but if you said that the "2" in that field (the fourth) is to
>>     interpret as k-rate only, then what does the following line mean?
>>
>>     { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii", (SUBR)
>>     tabslice, NULL, NULL },
>>
>>     I supposed that, being that there is only a single "(SUBR)
>>     tabslice" in the first of the last 3 fields, that means that a
>>     slicearray:i[] runs only at i-time, and on that occasion it uses
>>     the 'tabslice' function. I'm wrong?
>>
>>     Regards,
>>     Mauro
>>
>>
>>     Il 2018-10-06 23:43 John ff ha scritto:
>>
>>         I repeat. The thread field is 2 which is krate only
>>         Sent from TypeApp 
>>         On 6 Oct 2018, at 22:29, Mauro Giubileo <
>>         mgiubileo@computeraltafed.it
>>         > wrote:
>>
>>             Hi John,
>>
>>             I read that commit carefully (Apr 15 2014 commit
>>             59bc4de8fd4c200bb2a290ac760e8103f737b8f9), and it's clear
>>             to me that before that date there was only a single
>>             slicearray that worked at k-time (no i-time). But in that
>>             date you removed the single slicearray:
>>
>>             - { "slicearray", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii",
>>             NULL, (SUBR) tabslice, NULL },
>>
>>             and added the following:
>>
>>             + { "slicearray.k", sizeof(TABSLICE), 0, 2, "k[]",
>>             "k[]ii", (SUBR) tabslice, (SUBR) tabslice, NULL },
>>             + { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]",
>>             "i[]ii", (SUBR) tabslice, NULL, NULL },
>>
>>             So, I suppose that at that time someone (maybe Joachim?)
>>             asked to add an i-time version of slicearray (being that
>>             there was only a k-time version). Then, for some unknown
>>             reason (could be a mistake?) you made the k-time version
>>             work at i-time too. That's what I suspect, because
>>             honestly I see no valid reason to make a statement like
>>             "kOutArray[] slicearray kInputArray, iStart, iEnd" work at
>>             both i-time and k-time. Someone knows a scenario where
>>             that could be needed? I think it would be much more useful
>>             to allow the user to use the same k-array for input and
>>             output (and this could be achieved returning to a
>>             slicearray:k[] that run only at k-time).
>>
>>             Regards,
>>             Mauro
>>
>>
>>             Il 2018-10-06 22:58 jpff ha scritto:
>>
>>                 If you read that commit carefully it does not have
>>                 slicearray running at i-time.  Thread is 2 so perf
>>                 only.  Looking at commit
>>                 bfdd09a6299688e4104fbf42ea1b65b274a69ee5
>>                 it is running at i and k -- date Thu Apr 17 11:04:55 2014
>>
>>                 My memory is not good, but I think Joachim asked for this or something similar.
>>
>>
>>
>>                 On Sat, 6 Oct 2018, Mauro Giubileo wrote:
>>
>>
>>                     Hi John,
>>                     from a look to the history, the first time that you changed that code to make
>>
>>                     slicearray work both at i-time and k-time was in your commits on Apr 15, 2014.
>>
>>                     Before that date, slicearray ran only at k-time.
>>
>>                     Do you know/remember why you changed the standard (and correct, in my opinion,
>>
>>                     for all the reasons I explained in this github issue) behaviour?
>>
>>
>>                     Regards,
>>                     Mauro
>>
>>                     Il 2018-10-06 21:48 jpff ha scritto:
>>
>>                           Investigating logs it has been this way since before May21 2014 so
>>
>>                           any change would be a potential compatibility issue.
>>
>>
>>                           Also ound
>>                           commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
>>                           Author: Steven Yi >                     >
>>                           Date:   Thu Apr 17 11:04:55 2014 -0400
>>
>>                               rewrote slicearray to use type system information and
>>
>>                           copyValue functions
>>
>>
>>                           where it is both i and k rate.  Harder to check earlier.
>>
>>
>>
>>                           On Sat, 6 Oct 2018, John wrote:
>>
>>                                 t present slicearray for both k and a arrays runs at both i-time and
>>
>>                                 k-rate.  It has been suggested in issue #1039 hat it should only run
>>
>>                                 at k-rate.
>>
>>                                 I would be pleased to hear any opinions, thoughts r comments on this.
>>
>>
>>                                 ==John ffitch

Thanks Joachim...  So, from what you found, it appears to me that my previous supposition was right: no one ever asked to make "slicearray:k[]" run at i-time too. This means that no one needed that, it was just a mistake, and so it should be safe to return to the classic behaviour that is coherent with what the reference manual says on this matter and allows to use the same k-array variable both for input and output arrays.

Regards,
Mauro

Il 2018-10-07 02:17 joachim heintz ha scritto:

yes, i found it. (thanks, john, for the attention.)

i wrote on april 9, 2014 a list of suggestions for extension of the array opcodes.  amongst them:
3) slicearray
a) not possible to have i-arrays, e.g.
   iArr[]  fillarray  1, 2, 3, 4, 5, 6, 7, 8, 9
   iArr1[] init       5
   iArr2[] init       4
   iArr1   slicearray iArr, 0, 4        ;[1, 2, 3, 4, 5]
   iArr2   slicearray iArr, 5, 8        ;[6, 7, 8, 9]
b) same for S-arrays:
   SArr[]  init       9
   SArr1[] init       5
   SArr1   slicearray SArr, 0, 4

steven wrote on april 17:

I think I've made slicearray work generically now for any type.
Joachim: could you pull from develop and try with your various array tests?

so it looks like the discussion was to add an i-rate version for slicearray, but not to output initialization for k-rate slicearray (if i followed up your discussion right).

    joachim


On 07/10/18 01:22, Mauro Giubileo wrote:

Ok, now I understand, but I see you corrected that code yourself on Apr
16 2014 commit 48a10a562baa3889c3b28972876edb00f85af68f:

 - { "slicearray.k", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii",

 + { "slicearray.k", sizeof(TABSLICE), 0, 3, "k[]", "k[]ii", (SUBR)
tabslice, (SUBR) tabslice, NULL },

 - { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii",

 + { "slicearray.i", sizeof(TABSLICE), 0, 1, "i[]", "i[]ii", (SUBR)
tabslice, NULL, NULL },


Anyway it would be nice to know the reason for that change in the
standard behaviour. I searched on the mailing list archive but I haven't
found messages before 2015. Maybe someone has those messages from 2014 ?

Regards,
Mauro


Il 2018-10-07 00:38 John ff ha scritto:

That code is wrong and would default if run


Sent from TypeApp <http://www.typeapp.com/r?b=13685>
On 6 Oct 2018, at 23:09, Mauro Giubileo <mgiubileo@computeraltafed.it
<mailto:mgiubileo@computeraltafed.it>> wrote:

    Sorry, as I said before I've no experience in Csound source code,
    but if you said that the "2" in that field (the fourth) is to
    interpret as k-rate only, then what does the following line mean?

    { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]", "i[]ii", (SUBR)
    tabslice, NULL, NULL },

    I supposed that, being that there is only a single "(SUBR)
    tabslice" in the first of the last 3 fields, that means that a
    slicearray:i[] runs only at i-time, and on that occasion it uses
    the 'tabslice' function. I'm wrong?

    Regards,
    Mauro


    Il 2018-10-06 23:43 John ff ha scritto:

        I repeat. The thread field is 2 which is krate only
        Sent from TypeApp <http://www.typeapp.com/r?b=13685>
        On 6 Oct 2018, at 22:29, Mauro Giubileo <
        mgiubileo@computeraltafed.it
        <mailto:mgiubileo@computeraltafed.it>> wrote:

            Hi John,

            I read that commit carefully (Apr 15 2014 commit
            59bc4de8fd4c200bb2a290ac760e8103f737b8f9), and it's clear
            to me that before that date there was only a single
            slicearray that worked at k-time (no i-time). But in that
            date you removed the single slicearray:

            - { "slicearray", sizeof(TABSLICE), 0, 2, "k[]", "k[]ii",
            NULL, (SUBR) tabslice, NULL },

            and added the following:

            + { "slicearray.k", sizeof(TABSLICE), 0, 2, "k[]",
            "k[]ii", (SUBR) tabslice, (SUBR) tabslice, NULL },
            + { "slicearray.i", sizeof(TABSLICE), 0, 2, "i[]",
            "i[]ii", (SUBR) tabslice, NULL, NULL },

            So, I suppose that at that time someone (maybe Joachim?)
            asked to add an i-time version of slicearray (being that
            there was only a k-time version). Then, for some unknown
            reason (could be a mistake?) you made the k-time version
            work at i-time too. That's what I suspect, because
            honestly I see no valid reason to make a statement like
            "kOutArray[] slicearray kInputArray, iStart, iEnd" work at
            both i-time and k-time. Someone knows a scenario where
            that could be needed? I think it would be much more useful
            to allow the user to use the same k-array for input and
            output (and this could be achieved returning to a
            slicearray:k[] that run only at k-time).

            Regards,
            Mauro


            Il 2018-10-06 22:58 jpff ha scritto:

                If you read that commit carefully it does not have
                slicearray running at i-time.  Thread is 2 so perf
                only.  Looking at commit
                bfdd09a6299688e4104fbf42ea1b65b274a69ee5
                it is running at i and k -- date Thu Apr 17 11:04:55 2014

                My memory is not good, but I think Joachim asked for this or something similar.



                On Sat, 6 Oct 2018, Mauro Giubileo wrote:


                    Hi John,
                    from a look to the history, the first time that you changed that code to make

                    slicearray work both at i-time and k-time was in your commits on Apr 15, 2014.

                    Before that date, slicearray ran only at k-time.

                    Do you know/remember why you changed the standard (and correct, in my opinion,

                    for all the reasons I explained in this github issue) behaviour?


                    Regards,
                    Mauro

                    Il 2018-10-06 21:48 jpff ha scritto:

                          Investigating logs it has been this way since before May21 2014 so

                          any change would be a potential compatibility issue.


                          Also ound
                          commit bfdd09a6299688e4104fbf42ea1b65b274a69ee5
                          Author: Steven Yi <stevenyi@gmail.com
                    <mailto:stevenyi@gmail.com>>
                          Date:   Thu Apr 17 11:04:55 2014 -0400

                              rewrote slicearray to use type system information and

                          copyValue functions


                          where it is both i and k rate.  Harder to check earlier.



                          On Sat, 6 Oct 2018, John wrote:

                                t present slicearray for both k and a arrays runs at both i-time and

                                k-rate.  It has been suggested in issue #1039 hat it should only run

                                at k-rate.

                                I would be pleased to hear any opinions, thoughts r comments on this.


                                ==John ffitch

Looig back at the history, I suspect prt of the (my?) confusion is string 
arrays.  It was not clear to me if these were i-time or krate or both.

Question remains, should we change it? slicearray.k I mean

On Sat, 6 Oct 2018, Victor Lazzarini wrote:

> I suppose k and a rate stuff should if possible be non-op at i-time (e.g. not
> produce an output, but do all the necessary
> allocation, initialisation etc).
>
> To reuse code, some operators I wrote
> don't observe this, but I assumed it was
> benign in those cases.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 6 Oct 2018, at 19:09, John  wrote:
>>
>> t present slicearray for both k and a arrays runs at both i-time and
>> k-rate.  It has been suggested in issue #1039 hat it should only run
>> at k-rate.
>>
>> I would be pleased to hear any opinions, thoughts r comments on this.
>>
>> ==John ffitch

how are string array treated in general?  i, k, or both?


On 07/10/18 15:58, jpff wrote:
> Looig back at the history, I suspect prt of the (my?) confusion is
> string arrays.  It was not clear to me if these were i-time or krate or
> both.
>
> Question remains, should we change it? slicearray.k I mean
>
> On Sat, 6 Oct 2018, Victor Lazzarini wrote:
>
>> I suppose k and a rate stuff should if possible be non-op at i-time
>> (e.g. not
>> produce an output, but do all the necessary
>> allocation, initialisation etc).
>>
>> To reuse code, some operators I wrote
>> don't observe this, but I assumed it was
>> benign in those cases.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>>> On 6 Oct 2018, at 19:09, John  wrote:
>>>
>>> t present slicearray for both k and a arrays runs at both i-time and
>>> k-rate.  It has been suggested in issue #1039 hat it should only run
>>> at k-rate.
>>>
>>> I would be pleased to hear any opinions, thoughts r comments on this.
>>>
>>> ==John ffitch
>>

As present and as far as I have managed S arrays are treated identically 
too k arrays, including slicearray exceopt no arithmetic and no maparray

Earlier before the use of .[] there were special cases

On Sun, 7 Oct 2018, joachim heintz wrote:

> how are string array treated in general?  i, k, or both?
>
>
> On 07/10/18 15:58, jpff wrote:
>> Looig back at the history, I suspect prt of the (my?) confusion is
>> string arrays.  It was not clear to me if these were i-time or krate or
>> both.
>> 
>> Question remains, should we change it? slicearray.k I mean
>> 
>> On Sat, 6 Oct 2018, Victor Lazzarini wrote:
>> 
>>> I suppose k and a rate stuff should if possible be non-op at i-time
>>> (e.g. not
>>> produce an output, but do all the necessary
>>> allocation, initialisation etc).
>>> 
>>> To reuse code, some operators I wrote
>>> don't observe this, but I assumed it was
>>> benign in those cases.
>>> 
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>> 
>>>> On 6 Oct 2018, at 19:09, John  wrote:
>>>> 
>>>> t present slicearray for both k and a arrays runs at both i-time and
>>>> k-rate.  It has been suggested in issue #1039 hat it should only run
>>>> at k-rate.
>>>> 
>>>> I would be pleased to hear any opinions, thoughts r comments on this.
>>>> 
>>>> ==John ffitch
>>> 
>>