Hi All,

I've just chatted with John and Victor on IRC and we went through the
existing tickets in the 6.08 milestone
(https://github.com/csound/csound/milestone/15).  The current plan is
to target November 21st/22nd for doing the release branch and putting
together releases for the 23rd (day before Thanksgiving in the US, two
days before the Csound 30 conference.)

Amongst the issues in the milestone, we had a lengthy discussion about
issues #554 and #560 which are both related to arrays.  The proposal
is modify array get/sets to the following rules:

1. Array opcodes will process according to the type of the array
index.  If an i-type value is given, the array will process at
init-time only. If a k-type is given, the array will process at
control-rate only.
2. i-arrays may have a k-rate index to allow getting values at k-rate,
and the output argument will be k-type.

We have some array accessors at the moment that allow rate 3, which
means getting/setting values at both i- and k-times.  These will go
away.

This may be potentially break some user code, but the rule is very
simple and consistent, compared to the current state of things.

All other issues seem straight forward according to the ticket details.

If there's any issues that are not in the milestone but needs
consideration for 6.08, please reply to this email and we can vet them
here to see if they can get into 6.08 within the timeframe.

Thanks!

+1 on the array changes,  very nice 

You forgot to clarify about String arrays and
the indexing type.

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

> On 6 Oct 2016, at 16:17, Steven Yi  wrote:
> 
> Hi All,
> 
> I've just chatted with John and Victor on IRC and we went through the
> existing tickets in the 6.08 milestone
> (https://github.com/csound/csound/milestone/15).  The current plan is
> to target November 21st/22nd for doing the release branch and putting
> together releases for the 23rd (day before Thanksgiving in the US, two
> days before the Csound 30 conference.)
> 
> Amongst the issues in the milestone, we had a lengthy discussion about
> issues #554 and #560 which are both related to arrays.  The proposal
> is modify array get/sets to the following rules:
> 
> 1. Array opcodes will process according to the type of the array
> index.  If an i-type value is given, the array will process at
> init-time only. If a k-type is given, the array will process at
> control-rate only.
> 2. i-arrays may have a k-rate index to allow getting values at k-rate,
> and the output argument will be k-type.
> 
> We have some array accessors at the moment that allow rate 3, which
> means getting/setting values at both i- and k-times.  These will go
> away.
> 
> This may be potentially break some user code, but the rule is very
> simple and consistent, compared to the current state of things.
> 
> All other issues seem straight forward according to the ticket details.
> 
> If there's any issues that are not in the milestone but needs
> consideration for 6.08, please reply to this email and we can vet them
> here to see if they can get into 6.08 within the timeframe.
> 
> Thanks!

I think that is covered by the index rules given, but to clarify:

For any type of array, the index type will determine the rate at which
the array is accessed/set.  For example:

Sarray[] init 10

Sarray[i1]   <-- only read and written at i-time
Sarray[k1]  <-- only read and written at k-time

If you use:

Sarray[0]

that is a constant and an i-time value, so it will *only* be accessed
or set at i-time.  If you need to set/get the value at k-time, you
need to use a k-time index, such as:

kindx init 0
Sarray[kindx]

or:

Sarray[k(0)]

The output type will be the same as the sub-type of the array, so the
output of Sarray[0] will be an S-var, set at i-time.

The above will apply for all array types, with the exception of the
control-rate access of i-type arrays, which will output k-rate values.

If I've missed something, please let me know.

On Thu, Oct 6, 2016 at 12:25 PM, Victor Lazzarini
 wrote:
> You forgot to clarify about String arrays and
> the indexing type.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 6 Oct 2016, at 16:17, Steven Yi  wrote:
>>
>> Hi All,
>>
>> I've just chatted with John and Victor on IRC and we went through the
>> existing tickets in the 6.08 milestone
>> (https://github.com/csound/csound/milestone/15).  The current plan is
>> to target November 21st/22nd for doing the release branch and putting
>> together releases for the 23rd (day before Thanksgiving in the US, two
>> days before the Csound 30 conference.)
>>
>> Amongst the issues in the milestone, we had a lengthy discussion about
>> issues #554 and #560 which are both related to arrays.  The proposal
>> is modify array get/sets to the following rules:
>>
>> 1. Array opcodes will process according to the type of the array
>> index.  If an i-type value is given, the array will process at
>> init-time only. If a k-type is given, the array will process at
>> control-rate only.
>> 2. i-arrays may have a k-rate index to allow getting values at k-rate,
>> and the output argument will be k-type.
>>
>> We have some array accessors at the moment that allow rate 3, which
>> means getting/setting values at both i- and k-times.  These will go
>> away.
>>
>> This may be potentially break some user code, but the rule is very
>> simple and consistent, compared to the current state of things.
>>
>> All other issues seem straight forward according to the ticket details.
>>
>> If there's any issues that are not in the milestone but needs
>> consideration for 6.08, please reply to this email and we can vet them
>> here to see if they can get into 6.08 within the timeframe.
>>
>> Thanks!

hi steven -

thanks for reporting.  just to be sure:

kArr[0] will only be accessed at init-time, so it is actually the same as
iArr[0] ?

or in other words: if the *index*-type is the decisive factor about i or 
k, how does this relate to the array type itself, expressed as iArr / kArr?

best -
	joachim


On 06/10/16 17:16, Steven Yi wrote:
> Hi All,
>
> I've just chatted with John and Victor on IRC and we went through the
> existing tickets in the 6.08 milestone
> (https://github.com/csound/csound/milestone/15).  The current plan is
> to target November 21st/22nd for doing the release branch and putting
> together releases for the 23rd (day before Thanksgiving in the US, two
> days before the Csound 30 conference.)
>
> Amongst the issues in the milestone, we had a lengthy discussion about
> issues #554 and #560 which are both related to arrays.  The proposal
> is modify array get/sets to the following rules:
>
> 1. Array opcodes will process according to the type of the array
> index.  If an i-type value is given, the array will process at
> init-time only. If a k-type is given, the array will process at
> control-rate only.
> 2. i-arrays may have a k-rate index to allow getting values at k-rate,
> and the output argument will be k-type.
>
> We have some array accessors at the moment that allow rate 3, which
> means getting/setting values at both i- and k-times.  These will go
> away.
>
> This may be potentially break some user code, but the rule is very
> simple and consistent, compared to the current state of things.
>
> All other issues seem straight forward according to the ticket details.
>
> If there's any issues that are not in the milestone but needs
> consideration for 6.08, please reply to this email and we can vet them
> here to see if they can get into 6.08 within the timeframe.
>
> Thanks!
> steven

The differences between kArr[0] and iArr[0] is that the output
arguments will be k- an i-, repsectively.  The array's sub-type's rate
will not be a factor.

ival = iArr[0]
kval init kArr[0]

would be appropriate uses.  I suspect the k-array with i-time index
will be used for accessing global k-arrays, as such:

ival = i(gkArr[0])



On Thu, Oct 6, 2016 at 4:06 PM, joachim heintz  wrote:
> hi steven -
>
> thanks for reporting.  just to be sure:
>
> kArr[0] will only be accessed at init-time, so it is actually the same as
> iArr[0] ?
>
> or in other words: if the *index*-type is the decisive factor about i or k,
> how does this relate to the array type itself, expressed as iArr / kArr?
>
> best -
>         joachim
>
>
>
> On 06/10/16 17:16, Steven Yi wrote:
>>
>> Hi All,
>>
>> I've just chatted with John and Victor on IRC and we went through the
>> existing tickets in the 6.08 milestone
>> (https://github.com/csound/csound/milestone/15).  The current plan is
>> to target November 21st/22nd for doing the release branch and putting
>> together releases for the 23rd (day before Thanksgiving in the US, two
>> days before the Csound 30 conference.)
>>
>> Amongst the issues in the milestone, we had a lengthy discussion about
>> issues #554 and #560 which are both related to arrays.  The proposal
>> is modify array get/sets to the following rules:
>>
>> 1. Array opcodes will process according to the type of the array
>> index.  If an i-type value is given, the array will process at
>> init-time only. If a k-type is given, the array will process at
>> control-rate only.
>> 2. i-arrays may have a k-rate index to allow getting values at k-rate,
>> and the output argument will be k-type.
>>
>> We have some array accessors at the moment that allow rate 3, which
>> means getting/setting values at both i- and k-times.  These will go
>> away.
>>
>> This may be potentially break some user code, but the rule is very
>> simple and consistent, compared to the current state of things.
>>
>> All other issues seem straight forward according to the ticket details.
>>
>> If there's any issues that are not in the milestone but needs
>> consideration for 6.08, please reply to this email and we can vet them
>> here to see if they can get into 6.08 within the timeframe.
>>
>> Thanks!
>> steven
>>