hi all -

i think i just came across a unwanted effect of the new convention that 
arrays get their type from the index.  this does not work any more:

instr 1
  aOut[] diskin "fox.wav"
  out aOut[0], aOut[0]
endin

because aOut[0] changes the aOut array to an i-time array, right?

this works indeed:

instr 2
  aOut[] diskin "fox.wav"
  kIndx init 0
  out aOut[kIndx], aOut[kIndx]
endin

but i think it cannot be meant that something so simple and intuitive 
like aOut[0] (which worked all the time) does not work any more.

regards -

I'm afraid the the new rules require coding to be different.  One could use:

out aOut[k(0)], aOut[k(0)]



On Wed, Oct 26, 2016 at 4:27 PM, joachim heintz  wrote:
> hi all -
>
> i think i just came across a unwanted effect of the new convention that
> arrays get their type from the index.  this does not work any more:
>
> instr 1
>  aOut[] diskin "fox.wav"
>  out aOut[0], aOut[0]
> endin
>
> because aOut[0] changes the aOut array to an i-time array, right?
>
> this works indeed:
>
> instr 2
>  aOut[] diskin "fox.wav"
>  kIndx init 0
>  out aOut[kIndx], aOut[kIndx]
> endin
>
> but i think it cannot be meant that something so simple and intuitive like
> aOut[0] (which worked all the time) does not work any more.
>
> regards -

That's what I used to fix my code. In the end I don't think it looks
that bad.


On 26/10/16 17:35, Steven Yi wrote:
> I'm afraid the the new rules require coding to be different.  One could use:
>
> out aOut[k(0)], aOut[k(0)]
>
>
>
> On Wed, Oct 26, 2016 at 4:27 PM, joachim heintz  wrote:
>> hi all -
>>
>> i think i just came across a unwanted effect of the new convention that
>> arrays get their type from the index.  this does not work any more:
>>
>> instr 1
>>  aOut[] diskin "fox.wav"
>>  out aOut[0], aOut[0]
>> endin
>>
>> because aOut[0] changes the aOut array to an i-time array, right?
>>
>> this works indeed:
>>
>> instr 2
>>  aOut[] diskin "fox.wav"
>>  kIndx init 0
>>  out aOut[kIndx], aOut[kIndx]
>> endin
>>
>> but i think it cannot be meant that something so simple and intuitive like
>> aOut[0] (which worked all the time) does not work any more.
>>
>> regards -

I guess that is what we decided, but somehow it feels a bit odd that we cannot
use a constant like that directly.

I know there is a reason, but I can't remember why we can't fix access of
k and a arrays to perf time always,
regardless of index type (i-arrays are
i-time only).



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

> On 26 Oct 2016, at 21:36, Steven Yi  wrote:
> 
> I'm afraid the the new rules require coding to be different.  One could use:
> 
> out aOut[k(0)], aOut[k(0)]
> 
> 
> 
>> On Wed, Oct 26, 2016 at 4:27 PM, joachim heintz  wrote:
>> hi all -
>> 
>> i think i just came across a unwanted effect of the new convention that
>> arrays get their type from the index.  this does not work any more:
>> 
>> instr 1
>> aOut[] diskin "fox.wav"
>> out aOut[0], aOut[0]
>> endin
>> 
>> because aOut[0] changes the aOut array to an i-time array, right?
>> 
>> this works indeed:
>> 
>> instr 2
>> aOut[] diskin "fox.wav"
>> kIndx init 0
>> out aOut[kIndx], aOut[kIndx]
>> endin
>> 
>> but i think it cannot be meant that something so simple and intuitive like
>> aOut[0] (which worked all the time) does not work any more.
>> 
>> regards -

i am really afraid that we compromise the usage of arrays if we don't 
allow to write aOut[0].

i know there were reasons for this change, but isn't it possible to find 
another solution?

when people write kArray[0], they think: "i want to use the first 
element of this array at k-time."  when they write kArray[kIndx]: "i 
want to use this array with an index which can change in the 
performance."  — from the user's view it remains a k-array in both 
cases, as if we use kSpeed=1 in diskin or similar.

the usage of function tables is quite permissive: a table is created at 
i-time, but can be used and changed at k-time.

would it be possible to treat arrays similar to tables in this usability?

for me personally it is not a big deal to use k(0).  but i am teaching a 
lot of csound, and i am afraid this change will distract people.

and as to backwards compatibility: although arrays are rather new in 
csound, it is already some years, and a lot of code has been written, 
which will not work any more, including some examples in the floss 
manual, for instance 03E05 in 
http://write.flossmanuals.net/csound/e-arrays/ (and many more probably).

thanks for considering this; regards -

	joachim




On 26/10/16 22:54, Victor Lazzarini wrote:
> I guess that is what we decided, but somehow it feels a bit odd that we cannot
> use a constant like that directly.
>
> I know there is a reason, but I can't remember why we can't fix access of
> k and a arrays to perf time always,
> regardless of index type (i-arrays are
> i-time only).
>
>
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 26 Oct 2016, at 21:36, Steven Yi  wrote:
>>
>> I'm afraid the the new rules require coding to be different.  One could use:
>>
>> out aOut[k(0)], aOut[k(0)]
>>
>>
>>
>>> On Wed, Oct 26, 2016 at 4:27 PM, joachim heintz  wrote:
>>> hi all -
>>>
>>> i think i just came across a unwanted effect of the new convention that
>>> arrays get their type from the index.  this does not work any more:
>>>
>>> instr 1
>>> aOut[] diskin "fox.wav"
>>> out aOut[0], aOut[0]
>>> endin
>>>
>>> because aOut[0] changes the aOut array to an i-time array, right?
>>>
>>> this works indeed:
>>>
>>> instr 2
>>> aOut[] diskin "fox.wav"
>>> kIndx init 0
>>> out aOut[kIndx], aOut[kIndx]
>>> endin
>>>
>>> but i think it cannot be meant that something so simple and intuitive like
>>> aOut[0] (which worked all the time) does not work any more.
>>>
>>> regards -
>>>        joachim

yes, I agree we have not got it quite right yet, but we will.

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

> On 27 Oct 2016, at 08:12, joachim heintz  wrote:
> 
> i am really afraid that we compromise the usage of arrays if we don't allow to write aOut[0].
> 
> i know there were reasons for this change, but isn't it possible to find another solution?
> 
> when people write kArray[0], they think: "i want to use the first element of this array at k-time."  when they write kArray[kIndx]: "i want to use this array with an index which can change in the performance."  — from the user's view it remains a k-array in both cases, as if we use kSpeed=1 in diskin or similar.
> 
> the usage of function tables is quite permissive: a table is created at i-time, but can be used and changed at k-time.
> 
> would it be possible to treat arrays similar to tables in this usability?
> 
> for me personally it is not a big deal to use k(0).  but i am teaching a lot of csound, and i am afraid this change will distract people.
> 
> and as to backwards compatibility: although arrays are rather new in csound, it is already some years, and a lot of code has been written, which will not work any more, including some examples in the floss manual, for instance 03E05 in http://write.flossmanuals.net/csound/e-arrays/ (and many more probably).
> 
> thanks for considering this; regards -
> 
>    joachim
> 
> 
> 
> 
>> On 26/10/16 22:54, Victor Lazzarini wrote:
>> I guess that is what we decided, but somehow it feels a bit odd that we cannot
>> use a constant like that directly.
>> 
>> I know there is a reason, but I can't remember why we can't fix access of
>> k and a arrays to perf time always,
>> regardless of index type (i-arrays are
>> i-time only).
>> 
>> 
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>>> On 26 Oct 2016, at 21:36, Steven Yi  wrote:
>>> 
>>> I'm afraid the the new rules require coding to be different.  One could use:
>>> 
>>> out aOut[k(0)], aOut[k(0)]
>>> 
>>> 
>>> 
>>>> On Wed, Oct 26, 2016 at 4:27 PM, joachim heintz  wrote:
>>>> hi all -
>>>> 
>>>> i think i just came across a unwanted effect of the new convention that
>>>> arrays get their type from the index.  this does not work any more:
>>>> 
>>>> instr 1
>>>> aOut[] diskin "fox.wav"
>>>> out aOut[0], aOut[0]
>>>> endin
>>>> 
>>>> because aOut[0] changes the aOut array to an i-time array, right?
>>>> 
>>>> this works indeed:
>>>> 
>>>> instr 2
>>>> aOut[] diskin "fox.wav"
>>>> kIndx init 0
>>>> out aOut[kIndx], aOut[kIndx]
>>>> endin
>>>> 
>>>> but i think it cannot be meant that something so simple and intuitive like
>>>> aOut[0] (which worked all the time) does not work any more.
>>>> 
>>>> regards -
>>>>       joachim

I agree with Joachim, and I do have a great deal of code that will break.

Best,
Mike

i am sure you will.  i just read in the issues #554 and #560 ... really 
complicated.

i will be happy to try out some examples whenever you come to a new 
implementation.

	joachim


On 27/10/16 09:38, Victor Lazzarini wrote:
> yes, I agree we have not got it quite right yet, but we will.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 27 Oct 2016, at 08:12, joachim heintz  wrote:
>>
>> i am really afraid that we compromise the usage of arrays if we don't allow to write aOut[0].
>>
>> i know there were reasons for this change, but isn't it possible to find another solution?
>>
>> when people write kArray[0], they think: "i want to use the first element of this array at k-time."  when they write kArray[kIndx]: "i want to use this array with an index which can change in the performance."  — from the user's view it remains a k-array in both cases, as if we use kSpeed=1 in diskin or similar.
>>
>> the usage of function tables is quite permissive: a table is created at i-time, but can be used and changed at k-time.
>>
>> would it be possible to treat arrays similar to tables in this usability?
>>
>> for me personally it is not a big deal to use k(0).  but i am teaching a lot of csound, and i am afraid this change will distract people.
>>
>> and as to backwards compatibility: although arrays are rather new in csound, it is already some years, and a lot of code has been written, which will not work any more, including some examples in the floss manual, for instance 03E05 in http://write.flossmanuals.net/csound/e-arrays/ (and many more probably).
>>
>> thanks for considering this; regards -
>>
>>    joachim
>>
>>
>>
>>
>>> On 26/10/16 22:54, Victor Lazzarini wrote:
>>> I guess that is what we decided, but somehow it feels a bit odd that we cannot
>>> use a constant like that directly.
>>>
>>> I know there is a reason, but I can't remember why we can't fix access of
>>> k and a arrays to perf time always,
>>> regardless of index type (i-arrays are
>>> i-time only).
>>>
>>>
>>>
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>>
>>>> On 26 Oct 2016, at 21:36, Steven Yi  wrote:
>>>>
>>>> I'm afraid the the new rules require coding to be different.  One could use:
>>>>
>>>> out aOut[k(0)], aOut[k(0)]
>>>>
>>>>
>>>>
>>>>> On Wed, Oct 26, 2016 at 4:27 PM, joachim heintz  wrote:
>>>>> hi all -
>>>>>
>>>>> i think i just came across a unwanted effect of the new convention that
>>>>> arrays get their type from the index.  this does not work any more:
>>>>>
>>>>> instr 1
>>>>> aOut[] diskin "fox.wav"
>>>>> out aOut[0], aOut[0]
>>>>> endin
>>>>>
>>>>> because aOut[0] changes the aOut array to an i-time array, right?
>>>>>
>>>>> this works indeed:
>>>>>
>>>>> instr 2
>>>>> aOut[] diskin "fox.wav"
>>>>> kIndx init 0
>>>>> out aOut[kIndx], aOut[kIndx]
>>>>> endin
>>>>>
>>>>> but i think it cannot be meant that something so simple and intuitive like
>>>>> aOut[0] (which worked all the time) does not work any more.
>>>>>
>>>>> regards -
>>>>>       joachim
>>>

I've been chatting with John and Victor over email.  This issue is not
simple.  I've setup a wiki page to track the various combinations of
rules and issues that have arisen:

https://github.com/csound/csound/wiki/Array-Semantics

Everyone is welcome to modify the page with concerns, thoughts, etc.



On Fri, Oct 28, 2016 at 3:38 PM, joachim heintz  wrote:
> i am sure you will.  i just read in the issues #554 and #560 ... really
> complicated.
>
> i will be happy to try out some examples whenever you come to a new
> implementation.
>
>         joachim
>
>
>
> On 27/10/16 09:38, Victor Lazzarini wrote:
>>
>> yes, I agree we have not got it quite right yet, but we will.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>>> On 27 Oct 2016, at 08:12, joachim heintz  wrote:
>>>
>>> i am really afraid that we compromise the usage of arrays if we don't
>>> allow to write aOut[0].
>>>
>>> i know there were reasons for this change, but isn't it possible to find
>>> another solution?
>>>
>>> when people write kArray[0], they think: "i want to use the first element
>>> of this array at k-time."  when they write kArray[kIndx]: "i want to use
>>> this array with an index which can change in the performance."  — from the
>>> user's view it remains a k-array in both cases, as if we use kSpeed=1 in
>>> diskin or similar.
>>>
>>> the usage of function tables is quite permissive: a table is created at
>>> i-time, but can be used and changed at k-time.
>>>
>>> would it be possible to treat arrays similar to tables in this usability?
>>>
>>> for me personally it is not a big deal to use k(0).  but i am teaching a
>>> lot of csound, and i am afraid this change will distract people.
>>>
>>> and as to backwards compatibility: although arrays are rather new in
>>> csound, it is already some years, and a lot of code has been written, which
>>> will not work any more, including some examples in the floss manual, for
>>> instance 03E05 in http://write.flossmanuals.net/csound/e-arrays/ (and many
>>> more probably).
>>>
>>> thanks for considering this; regards -
>>>
>>>    joachim
>>>
>>>
>>>
>>>
>>>> On 26/10/16 22:54, Victor Lazzarini wrote:
>>>> I guess that is what we decided, but somehow it feels a bit odd that we
>>>> cannot
>>>> use a constant like that directly.
>>>>
>>>> I know there is a reason, but I can't remember why we can't fix access
>>>> of
>>>> k and a arrays to perf time always,
>>>> regardless of index type (i-arrays are
>>>> i-time only).
>>>>
>>>>
>>>>
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>>
>>>>> On 26 Oct 2016, at 21:36, Steven Yi  wrote:
>>>>>
>>>>> I'm afraid the the new rules require coding to be different.  One could
>>>>> use:
>>>>>
>>>>> out aOut[k(0)], aOut[k(0)]
>>>>>
>>>>>
>>>>>
>>>>>> On Wed, Oct 26, 2016 at 4:27 PM, joachim heintz 
>>>>>> wrote:
>>>>>> hi all -
>>>>>>
>>>>>> i think i just came across a unwanted effect of the new convention
>>>>>> that
>>>>>> arrays get their type from the index.  this does not work any more:
>>>>>>
>>>>>> instr 1
>>>>>> aOut[] diskin "fox.wav"
>>>>>> out aOut[0], aOut[0]
>>>>>> endin
>>>>>>
>>>>>> because aOut[0] changes the aOut array to an i-time array, right?
>>>>>>
>>>>>> this works indeed:
>>>>>>
>>>>>> instr 2
>>>>>> aOut[] diskin "fox.wav"
>>>>>> kIndx init 0
>>>>>> out aOut[kIndx], aOut[kIndx]
>>>>>> endin
>>>>>>
>>>>>> but i think it cannot be meant that something so simple and intuitive
>>>>>> like
>>>>>> aOut[0] (which worked all the time) does not work any more.
>>>>>>
>>>>>> regards -
>>>>>>       joachim
>>>>
>>>>
>>

example 03E01 in http://write.flossmanuals.net/csound/e-arrays/ comes to 
a different result now.  reduced the point is this:

instr 1
  kArr[] fillarray 1, 2, 3
  printks "   kArr[0] = %d\n", 0, kArr[0]
  kArr[0] = kArr[0] + 10
  printks "   kArr[0] = %d\n", 0, kArr[0]
  turnoff
endin

which returns for me:
    kArr[0] = 0
    kArr[0] = 10

but should be plus one.  strange enough, when i have:

instr 1
  kArr[] fillarray 1, 2, 3
  printks "   kArr[0] = %d\n", 0, kArr[0]
  turnoff
endin

then i indeed get:
    kArr[0] = 1

this is on debian linux.  later more -

	joachim


On 28/10/16 23:05, Steven Yi wrote:
> I've been chatting with John and Victor over email.  This issue is not
> simple.  I've setup a wiki page to track the various combinations of
> rules and issues that have arisen:
>
> https://github.com/csound/csound/wiki/Array-Semantics
>
> Everyone is welcome to modify the page with concerns, thoughts, etc.
>
>
>
> On Fri, Oct 28, 2016 at 3:38 PM, joachim heintz  wrote:
>> i am sure you will.  i just read in the issues #554 and #560 ... really
>> complicated.
>>
>> i will be happy to try out some examples whenever you come to a new
>> implementation.
>>
>>         joachim
>>
>>
>>
>> On 27/10/16 09:38, Victor Lazzarini wrote:
>>>
>>> yes, I agree we have not got it quite right yet, but we will.
>>>
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>>
>>>> On 27 Oct 2016, at 08:12, joachim heintz  wrote:
>>>>
>>>> i am really afraid that we compromise the usage of arrays if we don't
>>>> allow to write aOut[0].
>>>>
>>>> i know there were reasons for this change, but isn't it possible to find
>>>> another solution?
>>>>
>>>> when people write kArray[0], they think: "i want to use the first element
>>>> of this array at k-time."  when they write kArray[kIndx]: "i want to use
>>>> this array with an index which can change in the performance."  — from the
>>>> user's view it remains a k-array in both cases, as if we use kSpeed=1 in
>>>> diskin or similar.
>>>>
>>>> the usage of function tables is quite permissive: a table is created at
>>>> i-time, but can be used and changed at k-time.
>>>>
>>>> would it be possible to treat arrays similar to tables in this usability?
>>>>
>>>> for me personally it is not a big deal to use k(0).  but i am teaching a
>>>> lot of csound, and i am afraid this change will distract people.
>>>>
>>>> and as to backwards compatibility: although arrays are rather new in
>>>> csound, it is already some years, and a lot of code has been written, which
>>>> will not work any more, including some examples in the floss manual, for
>>>> instance 03E05 in http://write.flossmanuals.net/csound/e-arrays/ (and many
>>>> more probably).
>>>>
>>>> thanks for considering this; regards -
>>>>
>>>>    joachim
>>>>
>>>>
>>>>
>>>>
>>>>> On 26/10/16 22:54, Victor Lazzarini wrote:
>>>>> I guess that is what we decided, but somehow it feels a bit odd that we
>>>>> cannot
>>>>> use a constant like that directly.
>>>>>
>>>>> I know there is a reason, but I can't remember why we can't fix access
>>>>> of
>>>>> k and a arrays to perf time always,
>>>>> regardless of index type (i-arrays are
>>>>> i-time only).
>>>>>
>>>>>
>>>>>
>>>>> Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>> Maynooth University
>>>>> Ireland
>>>>>
>>>>>> On 26 Oct 2016, at 21:36, Steven Yi  wrote:
>>>>>>
>>>>>> I'm afraid the the new rules require coding to be different.  One could
>>>>>> use:
>>>>>>
>>>>>> out aOut[k(0)], aOut[k(0)]
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Wed, Oct 26, 2016 at 4:27 PM, joachim heintz 
>>>>>>> wrote:
>>>>>>> hi all -
>>>>>>>
>>>>>>> i think i just came across a unwanted effect of the new convention
>>>>>>> that
>>>>>>> arrays get their type from the index.  this does not work any more:
>>>>>>>
>>>>>>> instr 1
>>>>>>> aOut[] diskin "fox.wav"
>>>>>>> out aOut[0], aOut[0]
>>>>>>> endin
>>>>>>>
>>>>>>> because aOut[0] changes the aOut array to an i-time array, right?
>>>>>>>
>>>>>>> this works indeed:
>>>>>>>
>>>>>>> instr 2
>>>>>>> aOut[] diskin "fox.wav"
>>>>>>> kIndx init 0
>>>>>>> out aOut[kIndx], aOut[kIndx]
>>>>>>> endin
>>>>>>>
>>>>>>> but i think it cannot be meant that something so simple and intuitive
>>>>>>> like
>>>>>>> aOut[0] (which worked all the time) does not work any more.
>>>>>>>
>>>>>>> regards -
>>>>>>>       joachim
>>>>>
>>>>>
>>>
>>

This code is executing at i-time only. If you let it run for one k-cycle, the sum will have executed. This is
because the assignment 

kArr[0] = kArr[0] + 10

is running at perf-time.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 




> On 29 Oct 2016, at 10:36, joachim heintz  wrote:
> 
> instr 1
> kArr[] fillarray 1, 2, 3
> printks "   kArr[0] = %d\n", 0, kArr[0]
> kArr[0] = kArr[0] + 10
> printks "   kArr[0] = %d\n", 0, kArr[0]
> turnoff

Compiles to

fillarray.k args:       kArr    1       2       3
##array_get.k args:     #k0     kArr    0
printks args:   "   kArr[0] = %d\n"     0       #k0
##array_get.k args:     #k1     kArr    0
##add.kk args:  #k2     #k1     10
=.k args:       #k3     #k2
##array_set.k args:     kArr    #k3     0
##array_get.k args:     #k4     kArr    0
printks args:   "   kArr[0] = %d\n"     0       #k4
turnoff args:

which looks right to me.  array_get.k runs at i and k rate
No idea from whence cometh the zero....
I think it comes from te #k2 result ofaddwhich only happens ar k rate so 
at i-timr #k2 and #k3 are zero


On Sat, 29 Oct 2016, joachim heintz wrote:

> example 03E01 in http://write.flossmanuals.net/csound/e-arrays/ comes to a 
> different result now.  reduced the point is this:
>
> instr 1
> kArr[] fillarray 1, 2, 3
> printks "   kArr[0] = %d\n", 0, kArr[0]
> kArr[0] = kArr[0] + 10
> printks "   kArr[0] = %d\n", 0, kArr[0]
> turnoff
> endin
>
> which returns for me:
>   kArr[0] = 0
>   kArr[0] = 10
>
> but should be plus one.  strange enough, when i have:
>
> instr 1
> kArr[] fillarray 1, 2, 3
> printks "   kArr[0] = %d\n", 0, kArr[0]
> turnoff
> endin
>
> then i indeed get:
>   kArr[0] = 1
>
> this is on debian linux.  later more -
>
> 	joachim
>
>
> On 28/10/16 23:05, Steven Yi wrote:
>> I've been chatting with John and Victor over email.  This issue is not
>> simple.  I've setup a wiki page to track the various combinations of
>> rules and issues that have arisen:
>> 
>> https://github.com/csound/csound/wiki/Array-Semantics
>> 
>> Everyone is welcome to modify the page with concerns, thoughts, etc.
>> 
>> 
>> 
>> On Fri, Oct 28, 2016 at 3:38 PM, joachim heintz  
>> wrote:
>>> i am sure you will.  i just read in the issues #554 and #560 ... really
>>> complicated.
>>> 
>>> i will be happy to try out some examples whenever you come to a new
>>> implementation.
>>>
>>>         joachim
>>> 
>>> 
>>> 
>>> On 27/10/16 09:38, Victor Lazzarini wrote:
>>>> 
>>>> yes, I agree we have not got it quite right yet, but we will.
>>>> 
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>> On 27 Oct 2016, at 08:12, joachim heintz  wrote:
>>>>> 
>>>>> i am really afraid that we compromise the usage of arrays if we don't
>>>>> allow to write aOut[0].
>>>>> 
>>>>> i know there were reasons for this change, but isn't it possible to find
>>>>> another solution?
>>>>> 
>>>>> when people write kArray[0], they think: "i want to use the first 
>>>>> element
>>>>> of this array at k-time."  when they write kArray[kIndx]: "i want to use
>>>>> this array with an index which can change in the performance."  — from 
>>>>> the
>>>>> user's view it remains a k-array in both cases, as if we use kSpeed=1 in
>>>>> diskin or similar.
>>>>> 
>>>>> the usage of function tables is quite permissive: a table is created at
>>>>> i-time, but can be used and changed at k-time.
>>>>> 
>>>>> would it be possible to treat arrays similar to tables in this 
>>>>> usability?
>>>>> 
>>>>> for me personally it is not a big deal to use k(0).  but i am teaching a
>>>>> lot of csound, and i am afraid this change will distract people.
>>>>> 
>>>>> and as to backwards compatibility: although arrays are rather new in
>>>>> csound, it is already some years, and a lot of code has been written, 
>>>>> which
>>>>> will not work any more, including some examples in the floss manual, for
>>>>> instance 03E05 in http://write.flossmanuals.net/csound/e-arrays/ (and 
>>>>> many
>>>>> more probably).
>>>>> 
>>>>> thanks for considering this; regards -
>>>>>
>>>>>    joachim
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 26/10/16 22:54, Victor Lazzarini wrote:
>>>>>> I guess that is what we decided, but somehow it feels a bit odd that we
>>>>>> cannot
>>>>>> use a constant like that directly.
>>>>>> 
>>>>>> I know there is a reason, but I can't remember why we can't fix access
>>>>>> of
>>>>>> k and a arrays to perf time always,
>>>>>> regardless of index type (i-arrays are
>>>>>> i-time only).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>> 
>>>>>>> On 26 Oct 2016, at 21:36, Steven Yi  wrote:
>>>>>>> 
>>>>>>> I'm afraid the the new rules require coding to be different.  One 
>>>>>>> could
>>>>>>> use:
>>>>>>> 
>>>>>>> out aOut[k(0)], aOut[k(0)]
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Wed, Oct 26, 2016 at 4:27 PM, joachim heintz 
>>>>>>>> wrote:
>>>>>>>> hi all -
>>>>>>>> 
>>>>>>>> i think i just came across a unwanted effect of the new convention
>>>>>>>> that
>>>>>>>> arrays get their type from the index.  this does not work any more:
>>>>>>>> 
>>>>>>>> instr 1
>>>>>>>> aOut[] diskin "fox.wav"
>>>>>>>> out aOut[0], aOut[0]
>>>>>>>> endin
>>>>>>>> 
>>>>>>>> because aOut[0] changes the aOut array to an i-time array, right?
>>>>>>>> 
>>>>>>>> this works indeed:
>>>>>>>> 
>>>>>>>> instr 2
>>>>>>>> aOut[] diskin "fox.wav"
>>>>>>>> kIndx init 0
>>>>>>>> out aOut[kIndx], aOut[kIndx]
>>>>>>>> endin
>>>>>>>> 
>>>>>>>> but i think it cannot be meant that something so simple and intuitive
>>>>>>>> like
>>>>>>>> aOut[0] (which worked all the time) does not work any more.
>>>>>>>> 
>>>>>>>> regards -
>>>>>>>>       joachim
>>>>>> 
>>>>>> 
>>>> 
>>> 
>> 
>

why does it not run for one k-cycle?  the 'turnoff' terminates the 
instrument *after* the first k-cycle, does it not?

and the printks also prints at this k-cycle.

perhaps you looked at instr 1 of my original example which runs at 
i-time.  but the problem is in instr 2, with the k-time version.


On 29/10/16 11:46, Victor Lazzarini wrote:
> This code is executing at i-time only. If you let it run for one k-cycle, the sum will have executed. This is
> because the assignment
>
> kArr[0] = kArr[0] + 10
>
> is running at perf-time.
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>
>
>
>> On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>
>> instr 1
>> kArr[] fillarray 1, 2, 3
>> printks "   kArr[0] = %d\n", 0, kArr[0]
>> kArr[0] = kArr[0] + 10
>> printks "   kArr[0] = %d\n", 0, kArr[0]
>> turnoff
>> endin

I don't know, but if I run this without the turnoff the numbers increase.

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

> On 29 Oct 2016, at 18:41, joachim heintz  wrote:
> 
> why does it not run for one k-cycle?  the 'turnoff' terminates the instrument *after* the first k-cycle, does it not?
> 
> and the printks also prints at this k-cycle.
> 
> perhaps you looked at instr 1 of my original example which runs at i-time.  but the problem is in instr 2, with the k-time version.
> 
> 
>> On 29/10/16 11:46, Victor Lazzarini wrote:
>> This code is executing at i-time only. If you let it run for one k-cycle, the sum will have executed. This is
>> because the assignment
>> 
>> kArr[0] = kArr[0] + 10
>> 
>> is running at perf-time.
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>> 
>> 
>> 
>>> On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>> 
>>> instr 1
>>> kArr[] fillarray 1, 2, 3
>>> printks "   kArr[0] = %d\n", 0, kArr[0]
>>> kArr[0] = kArr[0] + 10
>>> printks "   kArr[0] = %d\n", 0, kArr[0]
>>> turnoff
>>> endin

yes the numbers increase but the start is zero although kArr[0] has been 
set to 1 by fillarray.  that is what i wanted to address.


On 29/10/16 19:46, Victor Lazzarini wrote:
> I don't know, but if I run this without the turnoff the numbers increase.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 29 Oct 2016, at 18:41, joachim heintz  wrote:
>>
>> why does it not run for one k-cycle?  the 'turnoff' terminates the instrument *after* the first k-cycle, does it not?
>>
>> and the printks also prints at this k-cycle.
>>
>> perhaps you looked at instr 1 of my original example which runs at i-time.  but the problem is in instr 2, with the k-time version.
>>
>>
>>> On 29/10/16 11:46, Victor Lazzarini wrote:
>>> This code is executing at i-time only. If you let it run for one k-cycle, the sum will have executed. This is
>>> because the assignment
>>>
>>> kArr[0] = kArr[0] + 10
>>>
>>> is running at perf-time.
>>> ========================
>>> Dr Victor Lazzarini
>>> Dean of Arts, Celtic Studies and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>>
>>>
>>>
>>>
>>>> On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>>>
>>>> instr 1
>>>> kArr[] fillarray 1, 2, 3
>>>> printks "   kArr[0] = %d\n", 0, kArr[0]
>>>> kArr[0] = kArr[0] + 10
>>>> printks "   kArr[0] = %d\n", 0, kArr[0]
>>>> turnoff
>>>> endin
>>>

To elaborate on what John is saying:

  kArr[0] = kArr[0] + 10

is what causes the kArr[0] to become zero.  Because in Git, k-array
accessors are runing *both* at init-time and perf-time, the above,
this set of compiled out opcodes:

##add.kk args:  #k2     #k1     10
=.k args:       #k3     #k2
##array_set.k args:     kArr    #k3     0

ends up having a #k3 initially set to 0 at init-time, and assigned to
kArr[0] at init-time.  So when the first perf-pass happens, kArr[0]
reports 0.



On Sat, Oct 29, 2016 at 4:49 PM, John ff  wrote:
> But you overwrite the 1with a zero
>
>
>
> Sent from TypeApp
>
> On 29 Oct 2016, at 19:07, joachim heintz  wrote:
>>
>> yes the numbers increase but the start is zero although kArr[0] has been
>> set to 1 by fillarray.  that is what i wanted to address.
>>
>>
>> On 29/10/16 19:46, Victor Lazzarini wrote:
>>>
>>>  I don't know, but if I run this without the turnoff the numbers
>>> increase.
>>>
>>>  Victor Lazzarini
>>>  Dean of Arts, Celtic Studies, and Philosophy
>>>  Maynooth University
>>>  Ireland
>>>
>>>>  On 29 Oct 2016, at 18:41, joachim heintz  wrote:
>>>>
>>>>  why does it not run for one k-cycle?  the 'turnoff' terminates the
>>>> instrument *after* the first k-cycle, does it not?
>>>>
>>>>  and the printks also prints at this k-cycle.
>>>>
>>>>  perhaps you looked at instr 1 of my original example which runs at
>>>> i-time.  but the problem is
>>>> in instr 2, with the k-time version.
>>>>
>>>>
>>>>>  On 29/10/16 11:46, Victor Lazzarini wrote:
>>>>>  This code is executing at i-time only. If you let it run for one
>>>>> k-cycle, the sum will have executed. This is
>>>>>  because the assignment
>>>>>
>>>>>  kArr[0] = kArr[0] + 10
>>>>>
>>>>>  is running at perf-time.
>>>>>  ========================
>>>>>  Dr Victor Lazzarini
>>>>>  Dean of Arts, Celtic Studies and Philosophy,
>>>>>  Maynooth University,
>>>>>  Maynooth, Co Kildare, Ireland
>>>>>  Tel: 00 353 7086936
>>>>>  Fax: 00 353 1 7086952
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>  On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>>>>>
>>>>>>  instr 1
>>>>>>  kArr[] fillarray 1, 2, 3
>>>>>>  printks "   kArr[0] = %d\n", 0, kArr[0]
>>>>>>  kArr[0] = kArr[0] + 10
>>>>>>  printks "   kArr[0] = %d\n", 0,
>>>>>> kArr[0]
>>>>>>  turnoff
>>>>>>  endin
>>>>>
>>>>>
>>>

Originally it ran only at perf time, right? Then we changed to i-time and now both. I am saying this because obviously Joachim's example worked as he expected at some point in time.

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

> On 29 Oct 2016, at 22:07, Steven Yi  wrote:
> 
> To elaborate on what John is saying:
> 
>  kArr[0] = kArr[0] + 10
> 
> is what causes the kArr[0] to become zero.  Because in Git, k-array
> accessors are runing *both* at init-time and perf-time, the above,
> this set of compiled out opcodes:
> 
> ##add.kk args:  #k2     #k1     10
> =.k args:       #k3     #k2
> ##array_set.k args:     kArr    #k3     0
> 
> ends up having a #k3 initially set to 0 at init-time, and assigned to
> kArr[0] at init-time.  So when the first perf-pass happens, kArr[0]
> reports 0.
> 
> 
> 
>> On Sat, Oct 29, 2016 at 4:49 PM, John ff  wrote:
>> But you overwrite the 1with a zero
>> 
>> 
>> 
>> Sent from TypeApp
>> 
>>> On 29 Oct 2016, at 19:07, joachim heintz  wrote:
>>> 
>>> yes the numbers increase but the start is zero although kArr[0] has been
>>> set to 1 by fillarray.  that is what i wanted to address.
>>> 
>>> 
>>>> On 29/10/16 19:46, Victor Lazzarini wrote:
>>>> 
>>>> I don't know, but if I run this without the turnoff the numbers
>>>> increase.
>>>> 
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>> On 29 Oct 2016, at 18:41, joachim heintz  wrote:
>>>>> 
>>>>> why does it not run for one k-cycle?  the 'turnoff' terminates the
>>>>> instrument *after* the first k-cycle, does it not?
>>>>> 
>>>>> and the printks also prints at this k-cycle.
>>>>> 
>>>>> perhaps you looked at instr 1 of my original example which runs at
>>>>> i-time.  but the problem is
>>>>> in instr 2, with the k-time version.
>>>>> 
>>>>> 
>>>>>> On 29/10/16 11:46, Victor Lazzarini wrote:
>>>>>> This code is executing at i-time only. If you let it run for one
>>>>>> k-cycle, the sum will have executed. This is
>>>>>> because the assignment
>>>>>> 
>>>>>> kArr[0] = kArr[0] + 10
>>>>>> 
>>>>>> is running at perf-time.
>>>>>> ========================
>>>>>> Dr Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>>>>>> 
>>>>>>> instr 1
>>>>>>> kArr[] fillarray 1, 2, 3
>>>>>>> printks "   kArr[0] = %d\n", 0, kArr[0]
>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>> printks "   kArr[0] = %d\n", 0,
>>>>>>> kArr[0]
>>>>>>> turnoff
>>>>>>> endin
>>>>>> 
>>>>>> 
>>>> 

Looks like I put in the the change here:

https://github.com/csound/csound/commit/9bdeb6f6f2a5dfc131a823e3ff842f66056c4c43

I don't know what bug 90 is as the one in github issues doesn't seem
to relate. The message is illuminating though: "modified array_get
(perf-time version) to also get value at i-time, to allow working with
global arrays".

So that's probably when someone mentioned i(gkarray[0]) not working.

One possibility is to go back to k-arrays only getting perf-time and
exposing an array_geti opcode that only operates at i-time.  So a user
could use i(array_geti(gkarray,0)).  We're at a point though that I
think some code is going to break one way or another, and we have to
figure out the best break to take.

On Sat, Oct 29, 2016 at 5:20 PM, Victor Lazzarini
 wrote:
> Originally it ran only at perf time, right? Then we changed to i-time and now both. I am saying this because obviously Joachim's example worked as he expected at some point in time.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 29 Oct 2016, at 22:07, Steven Yi  wrote:
>>
>> To elaborate on what John is saying:
>>
>>  kArr[0] = kArr[0] + 10
>>
>> is what causes the kArr[0] to become zero.  Because in Git, k-array
>> accessors are runing *both* at init-time and perf-time, the above,
>> this set of compiled out opcodes:
>>
>> ##add.kk args:  #k2     #k1     10
>> =.k args:       #k3     #k2
>> ##array_set.k args:     kArr    #k3     0
>>
>> ends up having a #k3 initially set to 0 at init-time, and assigned to
>> kArr[0] at init-time.  So when the first perf-pass happens, kArr[0]
>> reports 0.
>>
>>
>>
>>> On Sat, Oct 29, 2016 at 4:49 PM, John ff  wrote:
>>> But you overwrite the 1with a zero
>>>
>>>
>>>
>>> Sent from TypeApp
>>>
>>>> On 29 Oct 2016, at 19:07, joachim heintz  wrote:
>>>>
>>>> yes the numbers increase but the start is zero although kArr[0] has been
>>>> set to 1 by fillarray.  that is what i wanted to address.
>>>>
>>>>
>>>>> On 29/10/16 19:46, Victor Lazzarini wrote:
>>>>>
>>>>> I don't know, but if I run this without the turnoff the numbers
>>>>> increase.
>>>>>
>>>>> Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>> Maynooth University
>>>>> Ireland
>>>>>
>>>>>> On 29 Oct 2016, at 18:41, joachim heintz  wrote:
>>>>>>
>>>>>> why does it not run for one k-cycle?  the 'turnoff' terminates the
>>>>>> instrument *after* the first k-cycle, does it not?
>>>>>>
>>>>>> and the printks also prints at this k-cycle.
>>>>>>
>>>>>> perhaps you looked at instr 1 of my original example which runs at
>>>>>> i-time.  but the problem is
>>>>>> in instr 2, with the k-time version.
>>>>>>
>>>>>>
>>>>>>> On 29/10/16 11:46, Victor Lazzarini wrote:
>>>>>>> This code is executing at i-time only. If you let it run for one
>>>>>>> k-cycle, the sum will have executed. This is
>>>>>>> because the assignment
>>>>>>>
>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>>
>>>>>>> is running at perf-time.
>>>>>>> ========================
>>>>>>> Dr Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>>>>>>>
>>>>>>>> instr 1
>>>>>>>> kArr[] fillarray 1, 2, 3
>>>>>>>> printks "   kArr[0] = %d\n", 0, kArr[0]
>>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>>> printks "   kArr[0] = %d\n", 0,
>>>>>>>> kArr[0]
>>>>>>>> turnoff
>>>>>>>> endin
>>>>>>>
>>>>>>>
>>>>>

My feeling is that if i(gkarray[]) never worked, then there is nothing to break there.

I also think that your solution is acceptable.
Something like overloading i() might be
good

i(gkArr[], 0)

and keeping k-arrays perf time only.

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

> On 29 Oct 2016, at 22:35, Steven Yi  wrote:
> 
> Looks like I put in the the change here:
> 
> https://github.com/csound/csound/commit/9bdeb6f6f2a5dfc131a823e3ff842f66056c4c43
> 
> I don't know what bug 90 is as the one in github issues doesn't seem
> to relate. The message is illuminating though: "modified array_get
> (perf-time version) to also get value at i-time, to allow working with
> global arrays".
> 
> So that's probably when someone mentioned i(gkarray[0]) not working.
> 
> One possibility is to go back to k-arrays only getting perf-time and
> exposing an array_geti opcode that only operates at i-time.  So a user
> could use i(array_geti(gkarray,0)).  We're at a point though that I
> think some code is going to break one way or another, and we have to
> figure out the best break to take.
> 
> On Sat, Oct 29, 2016 at 5:20 PM, Victor Lazzarini
>  wrote:
>> Originally it ran only at perf time, right? Then we changed to i-time and now both. I am saying this because obviously Joachim's example worked as he expected at some point in time.
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>>> On 29 Oct 2016, at 22:07, Steven Yi  wrote:
>>> 
>>> To elaborate on what John is saying:
>>> 
>>> kArr[0] = kArr[0] + 10
>>> 
>>> is what causes the kArr[0] to become zero.  Because in Git, k-array
>>> accessors are runing *both* at init-time and perf-time, the above,
>>> this set of compiled out opcodes:
>>> 
>>> ##add.kk args:  #k2     #k1     10
>>> =.k args:       #k3     #k2
>>> ##array_set.k args:     kArr    #k3     0
>>> 
>>> ends up having a #k3 initially set to 0 at init-time, and assigned to
>>> kArr[0] at init-time.  So when the first perf-pass happens, kArr[0]
>>> reports 0.
>>> 
>>> 
>>> 
>>>> On Sat, Oct 29, 2016 at 4:49 PM, John ff  wrote:
>>>> But you overwrite the 1with a zero
>>>> 
>>>> 
>>>> 
>>>> Sent from TypeApp
>>>> 
>>>>> On 29 Oct 2016, at 19:07, joachim heintz  wrote:
>>>>> 
>>>>> yes the numbers increase but the start is zero although kArr[0] has been
>>>>> set to 1 by fillarray.  that is what i wanted to address.
>>>>> 
>>>>> 
>>>>>> On 29/10/16 19:46, Victor Lazzarini wrote:
>>>>>> 
>>>>>> I don't know, but if I run this without the turnoff the numbers
>>>>>> increase.
>>>>>> 
>>>>>> Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>> 
>>>>>>> On 29 Oct 2016, at 18:41, joachim heintz  wrote:
>>>>>>> 
>>>>>>> why does it not run for one k-cycle?  the 'turnoff' terminates the
>>>>>>> instrument *after* the first k-cycle, does it not?
>>>>>>> 
>>>>>>> and the printks also prints at this k-cycle.
>>>>>>> 
>>>>>>> perhaps you looked at instr 1 of my original example which runs at
>>>>>>> i-time.  but the problem is
>>>>>>> in instr 2, with the k-time version.
>>>>>>> 
>>>>>>> 
>>>>>>>> On 29/10/16 11:46, Victor Lazzarini wrote:
>>>>>>>> This code is executing at i-time only. If you let it run for one
>>>>>>>> k-cycle, the sum will have executed. This is
>>>>>>>> because the assignment
>>>>>>>> 
>>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>>> 
>>>>>>>> is running at perf-time.
>>>>>>>> ========================
>>>>>>>> Dr Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>>>>>>>> 
>>>>>>>>> instr 1
>>>>>>>>> kArr[] fillarray 1, 2, 3
>>>>>>>>> printks "   kArr[0] = %d\n", 0, kArr[0]
>>>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>>>> printks "   kArr[0] = %d\n", 0,
>>>>>>>>> kArr[0]
>>>>>>>>> turnoff
>>>>>>>>> endin
>>>>>>>> 
>>>>>>>> 
>>>>>> 

thanks for the explanation!

the reason that i think it should be initialized to 1 (instead of 0) is 
this line:

  kArr[] fillarray 1, 2, 3

i thought it
1) creates an array with three elements, and
2) sets the initial values to 1, 2, 3

does it not?



On 29/10/16 23:06, Steven Yi wrote:
> To elaborate on what John is saying:
>
>   kArr[0] = kArr[0] + 10
>
> is what causes the kArr[0] to become zero.  Because in Git, k-array
> accessors are runing *both* at init-time and perf-time, the above,
> this set of compiled out opcodes:
>
> ##add.kk args:  #k2     #k1     10
> =.k args:       #k3     #k2
> ##array_set.k args:     kArr    #k3     0
>
> ends up having a #k3 initially set to 0 at init-time, and assigned to
> kArr[0] at init-time.  So when the first perf-pass happens, kArr[0]
> reports 0.
>
>
>
> On Sat, Oct 29, 2016 at 4:49 PM, John ff  wrote:
>> But you overwrite the 1with a zero
>>
>>
>>
>> Sent from TypeApp
>>
>> On 29 Oct 2016, at 19:07, joachim heintz  wrote:
>>>
>>> yes the numbers increase but the start is zero although kArr[0] has been
>>> set to 1 by fillarray.  that is what i wanted to address.
>>>
>>>
>>> On 29/10/16 19:46, Victor Lazzarini wrote:
>>>>
>>>>  I don't know, but if I run this without the turnoff the numbers
>>>> increase.
>>>>
>>>>  Victor Lazzarini
>>>>  Dean of Arts, Celtic Studies, and Philosophy
>>>>  Maynooth University
>>>>  Ireland
>>>>
>>>>>  On 29 Oct 2016, at 18:41, joachim heintz  wrote:
>>>>>
>>>>>  why does it not run for one k-cycle?  the 'turnoff' terminates the
>>>>> instrument *after* the first k-cycle, does it not?
>>>>>
>>>>>  and the printks also prints at this k-cycle.
>>>>>
>>>>>  perhaps you looked at instr 1 of my original example which runs at
>>>>> i-time.  but the problem is
>>>>> in instr 2, with the k-time version.
>>>>>
>>>>>
>>>>>>  On 29/10/16 11:46, Victor Lazzarini wrote:
>>>>>>  This code is executing at i-time only. If you let it run for one
>>>>>> k-cycle, the sum will have executed. This is
>>>>>>  because the assignment
>>>>>>
>>>>>>  kArr[0] = kArr[0] + 10
>>>>>>
>>>>>>  is running at perf-time.
>>>>>>  ========================
>>>>>>  Dr Victor Lazzarini
>>>>>>  Dean of Arts, Celtic Studies and Philosophy,
>>>>>>  Maynooth University,
>>>>>>  Maynooth, Co Kildare, Ireland
>>>>>>  Tel: 00 353 7086936
>>>>>>  Fax: 00 353 1 7086952
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>  On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>>>>>>
>>>>>>>  instr 1
>>>>>>>  kArr[] fillarray 1, 2, 3
>>>>>>>  printks "   kArr[0] = %d\n", 0, kArr[0]
>>>>>>>  kArr[0] = kArr[0] + 10
>>>>>>>  printks "   kArr[0] = %d\n", 0,
>>>>>>> kArr[0]
>>>>>>>  turnoff
>>>>>>>  endin
>>>>>>
>>>>>>
>>>>
>>

That it does, but since it runs before the said line, the memory
gets overwritten by the synthetic k-rate argument.

I think Steven’s proposal to run k[] reading/writing only at
p-time and provide a special means to access this at i-time
is the best solution. It will restore the original behaviour to
your code.

========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 




> On 30 Oct 2016, at 11:32, joachim heintz  wrote:
> 
> thanks for the explanation!
> 
> the reason that i think it should be initialized to 1 (instead of 0) is this line:
> 
> kArr[] fillarray 1, 2, 3
> 
> i thought it
> 1) creates an array with three elements, and
> 2) sets the initial values to 1, 2, 3
> 
> does it not?
> 
> 
> 
> On 29/10/16 23:06, Steven Yi wrote:
>> To elaborate on what John is saying:
>> 
>>  kArr[0] = kArr[0] + 10
>> 
>> is what causes the kArr[0] to become zero.  Because in Git, k-array
>> accessors are runing *both* at init-time and perf-time, the above,
>> this set of compiled out opcodes:
>> 
>> ##add.kk args:  #k2     #k1     10
>> =.k args:       #k3     #k2
>> ##array_set.k args:     kArr    #k3     0
>> 
>> ends up having a #k3 initially set to 0 at init-time, and assigned to
>> kArr[0] at init-time.  So when the first perf-pass happens, kArr[0]
>> reports 0.
>> 
>> 
>> 
>> On Sat, Oct 29, 2016 at 4:49 PM, John ff  wrote:
>>> But you overwrite the 1with a zero
>>> 
>>> 
>>> 
>>> Sent from TypeApp
>>> 
>>> On 29 Oct 2016, at 19:07, joachim heintz  wrote:
>>>> 
>>>> yes the numbers increase but the start is zero although kArr[0] has been
>>>> set to 1 by fillarray.  that is what i wanted to address.
>>>> 
>>>> 
>>>> On 29/10/16 19:46, Victor Lazzarini wrote:
>>>>> 
>>>>> I don't know, but if I run this without the turnoff the numbers
>>>>> increase.
>>>>> 
>>>>> Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>>> On 29 Oct 2016, at 18:41, joachim heintz  wrote:
>>>>>> 
>>>>>> why does it not run for one k-cycle?  the 'turnoff' terminates the
>>>>>> instrument *after* the first k-cycle, does it not?
>>>>>> 
>>>>>> and the printks also prints at this k-cycle.
>>>>>> 
>>>>>> perhaps you looked at instr 1 of my original example which runs at
>>>>>> i-time.  but the problem is
>>>>>> in instr 2, with the k-time version.
>>>>>> 
>>>>>> 
>>>>>>> On 29/10/16 11:46, Victor Lazzarini wrote:
>>>>>>> This code is executing at i-time only. If you let it run for one
>>>>>>> k-cycle, the sum will have executed. This is
>>>>>>> because the assignment
>>>>>>> 
>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>> 
>>>>>>> is running at perf-time.
>>>>>>> ========================
>>>>>>> Dr Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>>>>>>> 
>>>>>>>> instr 1
>>>>>>>> kArr[] fillarray 1, 2, 3
>>>>>>>> printks "   kArr[0] = %d\n", 0, kArr[0]
>>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>>> printks "   kArr[0] = %d\n", 0,
>>>>>>>> kArr[0]
>>>>>>>> turnoff
>>>>

yes, it sounds like the best solution to me, too, as this is how 
k-variables are expected to behave (reading and writing only at k-time).


On 30/10/16 12:40, Victor Lazzarini wrote:
> That it does, but since it runs before the said line, the memory
> gets overwritten by the synthetic k-rate argument.
>
> I think Steven’s proposal to run k[] reading/writing only at
> p-time and provide a special means to access this at i-time
> is the best solution. It will restore the original behaviour to
> your code.
>
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>
>
>
>> On 30 Oct 2016, at 11:32, joachim heintz  wrote:
>>
>> thanks for the explanation!
>>
>> the reason that i think it should be initialized to 1 (instead of 0) is this line:
>>
>> kArr[] fillarray 1, 2, 3
>>
>> i thought it
>> 1) creates an array with three elements, and
>> 2) sets the initial values to 1, 2, 3
>>
>> does it not?
>>
>>
>>
>> On 29/10/16 23:06, Steven Yi wrote:
>>> To elaborate on what John is saying:
>>>
>>>  kArr[0] = kArr[0] + 10
>>>
>>> is what causes the kArr[0] to become zero.  Because in Git, k-array
>>> accessors are runing *both* at init-time and perf-time, the above,
>>> this set of compiled out opcodes:
>>>
>>> ##add.kk args:  #k2     #k1     10
>>> =.k args:       #k3     #k2
>>> ##array_set.k args:     kArr    #k3     0
>>>
>>> ends up having a #k3 initially set to 0 at init-time, and assigned to
>>> kArr[0] at init-time.  So when the first perf-pass happens, kArr[0]
>>> reports 0.
>>>
>>>
>>>
>>> On Sat, Oct 29, 2016 at 4:49 PM, John ff  wrote:
>>>> But you overwrite the 1with a zero
>>>>
>>>>
>>>>
>>>> Sent from TypeApp
>>>>
>>>> On 29 Oct 2016, at 19:07, joachim heintz  wrote:
>>>>>
>>>>> yes the numbers increase but the start is zero although kArr[0] has been
>>>>> set to 1 by fillarray.  that is what i wanted to address.
>>>>>
>>>>>
>>>>> On 29/10/16 19:46, Victor Lazzarini wrote:
>>>>>>
>>>>>> I don't know, but if I run this without the turnoff the numbers
>>>>>> increase.
>>>>>>
>>>>>> Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>>
>>>>>>> On 29 Oct 2016, at 18:41, joachim heintz  wrote:
>>>>>>>
>>>>>>> why does it not run for one k-cycle?  the 'turnoff' terminates the
>>>>>>> instrument *after* the first k-cycle, does it not?
>>>>>>>
>>>>>>> and the printks also prints at this k-cycle.
>>>>>>>
>>>>>>> perhaps you looked at instr 1 of my original example which runs at
>>>>>>> i-time.  but the problem is
>>>>>>> in instr 2, with the k-time version.
>>>>>>>
>>>>>>>
>>>>>>>> On 29/10/16 11:46, Victor Lazzarini wrote:
>>>>>>>> This code is executing at i-time only. If you let it run for one
>>>>>>>> k-cycle, the sum will have executed. This is
>>>>>>>> because the assignment
>>>>>>>>
>>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>>>
>>>>>>>> is running at perf-time.
>>>>>>>> ========================
>>>>>>>> Dr Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>>>>>>>>
>>>>>>>>> instr 1
>>>>>>>>> kArr[] fillarray 1, 2, 3
>>>>>>>>> printks "   kArr[0] = %d\n", 0, kArr[0]
>>>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>>>> printks "   kArr[0] = %d\n", 0,
>>>>>>>>> kArr[0]
>>>>>>>>> turnoff
>>>>>>>>> endin
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>

The major problem is that to get an i-time
value out of an array, we need a special
operator, because i() is not going to work.
I think that is not a big deal, provided we
document it properly.

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

> On 30 Oct 2016, at 11:58, joachim heintz  wrote:
> 
> yes, it sounds like the best solution to me, too, as this is how k-variables are expected to behave (reading and writing only at k-time).
> 
> 
>> On 30/10/16 12:40, Victor Lazzarini wrote:
>> That it does, but since it runs before the said line, the memory
>> gets overwritten by the synthetic k-rate argument.
>> 
>> I think Steven’s proposal to run k[] reading/writing only at
>> p-time and provide a special means to access this at i-time
>> is the best solution. It will restore the original behaviour to
>> your code.
>> 
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>> 
>> 
>> 
>>> On 30 Oct 2016, at 11:32, joachim heintz  wrote:
>>> 
>>> thanks for the explanation!
>>> 
>>> the reason that i think it should be initialized to 1 (instead of 0) is this line:
>>> 
>>> kArr[] fillarray 1, 2, 3
>>> 
>>> i thought it
>>> 1) creates an array with three elements, and
>>> 2) sets the initial values to 1, 2, 3
>>> 
>>> does it not?
>>> 
>>> 
>>> 
>>>> On 29/10/16 23:06, Steven Yi wrote:
>>>> To elaborate on what John is saying:
>>>> 
>>>> kArr[0] = kArr[0] + 10
>>>> 
>>>> is what causes the kArr[0] to become zero.  Because in Git, k-array
>>>> accessors are runing *both* at init-time and perf-time, the above,
>>>> this set of compiled out opcodes:
>>>> 
>>>> ##add.kk args:  #k2     #k1     10
>>>> =.k args:       #k3     #k2
>>>> ##array_set.k args:     kArr    #k3     0
>>>> 
>>>> ends up having a #k3 initially set to 0 at init-time, and assigned to
>>>> kArr[0] at init-time.  So when the first perf-pass happens, kArr[0]
>>>> reports 0.
>>>> 
>>>> 
>>>> 
>>>>> On Sat, Oct 29, 2016 at 4:49 PM, John ff  wrote:
>>>>> But you overwrite the 1with a zero
>>>>> 
>>>>> 
>>>>> 
>>>>> Sent from TypeApp
>>>>> 
>>>>>> On 29 Oct 2016, at 19:07, joachim heintz  wrote:
>>>>>> 
>>>>>> yes the numbers increase but the start is zero although kArr[0] has been
>>>>>> set to 1 by fillarray.  that is what i wanted to address.
>>>>>> 
>>>>>> 
>>>>>>> On 29/10/16 19:46, Victor Lazzarini wrote:
>>>>>>> 
>>>>>>> I don't know, but if I run this without the turnoff the numbers
>>>>>>> increase.
>>>>>>> 
>>>>>>> Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>> 
>>>>>>>> On 29 Oct 2016, at 18:41, joachim heintz  wrote:
>>>>>>>> 
>>>>>>>> why does it not run for one k-cycle?  the 'turnoff' terminates the
>>>>>>>> instrument *after* the first k-cycle, does it not?
>>>>>>>> 
>>>>>>>> and the printks also prints at this k-cycle.
>>>>>>>> 
>>>>>>>> perhaps you looked at instr 1 of my original example which runs at
>>>>>>>> i-time.  but the problem is
>>>>>>>> in instr 2, with the k-time version.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 29/10/16 11:46, Victor Lazzarini wrote:
>>>>>>>>> This code is executing at i-time only. If you let it run for one
>>>>>>>>> k-cycle, the sum will have executed. This is
>>>>>>>>> because the assignment
>>>>>>>>> 
>>>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>>>> 
>>>>>>>>> is running at perf-time.
>>>>>>>>> ========================
>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 29 Oct 2016, at 10:36, joachim heintz  wrote:
>>>>>>>>>> 
>>>>>>>>>> instr 1
>>>>>>>>>> kArr[] fillarray 1, 2, 3
>>>>>>>>>> printks "   kArr[0] = %d\n", 0, kArr[0]
>>>>>>>>>> kArr[0] = kArr[0] + 10
>>>>>>>>>> printks "   kArr[0] = %d\n", 0,
>>>>>>>>>> kArr[0]
>>>>>>>>>> turnoff
>>>>>>>>>> endin
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 

Can you summarise the changes needed?   I think there are two; one to array_get and new syntax.

Sent from TypeApp

On 30 Oct 2016, at 12:03, Victor Lazzarini <Victor.Lazzarini@NUIM.IE> wrote:

The major problem is that to get an i-time
value out of an array, we need a special
operator, because i() is not going to work.
I think that is not a big deal, provided we
document it properly.

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

 On 30 Oct 2016, at 11:58, joachim heintz <jh@JOACHIMHEINTZ.DE> wrote:
 
 yes, it sounds like the best solution to me, too, as this is how k-variables are expected to behave (reading and writing only at k-time).
 
 
 On 30/10/16 12:40, Victor Lazzarini wrote:
 That it does, but since it runs before the said line, the memory
 gets overwritten by the synthetic k-rate argument.
 
 I think
Steven’s proposal to run k[] reading/writing only at
 p-time and provide a special means to access this at i-time
 is the best solution. It will restore the original behaviour to
 your code.
 
 ========================
 Dr Victor Lazzarini
 Dean of Arts, Celtic Studies and Philosophy,
 Maynooth University,
 Maynooth, Co Kildare, Ireland
 Tel: 00 353 7086936
 Fax: 00 353 1 7086952
 
 
 
 
 On 30 Oct 2016, at 11:32, joachim heintz <jh@joachimheintz.de> wrote:
 
 thanks for the explanation!
 
 the reason that i think it should be initialized to 1 (instead of 0) is this line:
 
 kArr[] fillarray 1, 2, 3
 
 i thought it
 1) creates an array with three elements, and
 2) sets the initial values to 1, 2, 3
 
 does it not?
 
 
 
 On 29/10/16 23:06, Steven Yi wrote:
 To elaborate on what John is saying:
 
 kArr[0] = kArr[0] + 10
 
 is what causes the kArr[0] to become zero.  Because in Git, k-array
 accessors are runing *both* at init-time and perf-time, the above,
 this set of compiled out opcodes:
 
 ##add.kk args:  #k2     #k1     10
 =.k args:       #k3     #k2
 ##array_set.k args:     kArr    #k3     0
 
 ends up having a #k3 initially set to 0 at init-time, and assigned to
 kArr[0] at init-time.  So when the first perf-pass happens, kArr[0]
 reports 0.
 
 
 
 On Sat, Oct 29, 2016 at 4:49 PM, John ff <jpff@codemist.co.uk> wrote:
 But you overwrite the 1with a zero
 
 
 
 Sent from TypeApp
 
 On 29 Oct 2016, at 19:07, joachim heintz <jh@JOACHIMHEINTZ.DE> wrote:
 
 yes the numbers increase but the start is zero although kArr[0] has been
 set to 1 by fillarray.  that is what i wanted to address.
 
 
 On 29/10/16 19:46, Victor Lazzarini wrote:
 
 I don't know, but if I run this without the turnoff the numbers
 increase.
 
 Victor Lazzarini
 Dean of Arts, Celtic Studies, and Philosophy
 Maynooth University
 Ireland
 
 On 29 Oct 2016, at 18:41, joachim heintz <jh@JOACHIMHEINTZ.DE> wrote:
 
 why does it not run for one k-cycle?  the 'turnoff' terminates the
 instrument *after* the
first k-cycle, does it not?
 
 and the printks also prints at this k-cycle.
 
 perhaps you looked at instr 1 of my original example which runs at
 i-time.  but the problem is
 in instr 2, with the k-time version.
 
 
 On 29/10/16 11:46, Victor Lazzarini wrote:
 This code is executing at i-time only. If you let it run for one
 k-cycle, the sum will have executed. This is
 because the assignment
 
 kArr[0] = kArr[0] + 10
 
 is running at perf-time.
 ========================
 Dr Victor Lazzarini
 Dean of Arts, Celtic Studies and Philosophy,
 Maynooth University,
 Maynooth, Co Kildare, Ireland
 Tel: 00 353 7086936
 Fax: 00 353 1 7086952
 
 
 
 
 On 29 Oct 2016, at 10:36, joachim
heintz <jh@JOACHIMHEINTZ.DE> wrote:
 
 instr 1
 kArr[] fillarray 1, 2, 3
 printks "   kArr[0] = %d\n", 0, kArr[0]
 kArr[0] = kArr[0] + 10
 printks "   kArr[0] = %d\n", 0,
 kArr[0]
 turnoff
 endin
 
 
 
 
 
 

...and no way to set a karray element at i time? ouside fillarray or 
similar?

On Sun, 30 Oct 2016, Victor Lazzarini wrote:

> yes:  
> 
> 1) k-rate arrays, get and set only at perf time
> 2) New i-time opcode to get value off a
> k-rate array:  i(karr[], index)
> 
> Victor Lazzarini Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
> On 30 Oct 2016, at 14:18, John ff  wrote:
>
>       Can you summarise the changes needed?   I think there are two; one
>       to array_get and new syntax.
> 
> 
> 
> Sent from TypeApp
>

yes, I think so.

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

> On 30 Oct 2016, at 15:32, jpff  wrote:
> 
> ...and no way to set a karray element at i time? ouside fillarray or similar?
> 
>> On Sun, 30 Oct 2016, Victor Lazzarini wrote:
>> 
>> yes:  
>> 1) k-rate arrays, get and set only at perf time
>> 2) New i-time opcode to get value off a
>> k-rate array:  i(karr[], index)
>> Victor Lazzarini Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> On 30 Oct 2016, at 14:18, John ff  wrote:
>> 
>>      Can you summarise the changes needed?   I think there are two; one
>>      to array_get and new syntax.

OK I think I have this coded.  Passed first trivial test


instr 1
k0 init 42
k1[] fillarray 1,2,3
ii = 1
print i(k0)
print i(k1,1)
print i(k1,k0)
print i(gk2,1,1)
endin

Will commit if thhat is OK


On Sun, 30 Oct 2016, Victor Lazzarini wrote:

> yes, I think so.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 30 Oct 2016, at 15:32, jpff  wrote:
>>
>> ...and no way to set a karray element at i time? ouside fillarray or similar?
>>
>>> On Sun, 30 Oct 2016, Victor Lazzarini wrote:
>>>
>>> yes:
>>> 1) k-rate arrays, get and set only at perf time
>>> 2) New i-time opcode to get value off a
>>> k-rate array:  i(karr[], index)
>>> Victor Lazzarini Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>> On 30 Oct 2016, at 14:18, John ff  wrote:
>>>
>>>      Can you summarise the changes needed?   I think there are two; one
>>>      to array_get and new syntax.
>>> Sent from TypeApp

looks good thanks. Did you stop i time direct access?

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

> On 30 Oct 2016, at 16:04, jpff  wrote:
> 
> OK I think I have this coded.  Passed first trivial test
> 
> 
> instr 1
> k0 init 42
> k1[] fillarray 1,2,3
> ii = 1
> print i(k0)
> print i(k1,1)
> print i(k1,k0)
> print i(gk2,1,1)
> endin
> 
> Will commit if thhat is OK
> 
> 
>> On Sun, 30 Oct 2016, Victor Lazzarini wrote:
>> 
>> yes, I think so.
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>>> On 30 Oct 2016, at 15:32, jpff  wrote:
>>> 
>>> ...and no way to set a karray element at i time? ouside fillarray or similar?
>>> 
>>>> On Sun, 30 Oct 2016, Victor Lazzarini wrote:
>>>> 
>>>> yes:
>>>> 1) k-rate arrays, get and set only at perf time
>>>> 2) New i-time opcode to get value off a
>>>> k-rate array:  i(karr[], index)
>>>> Victor Lazzarini Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>> On 30 Oct 2016, at 14:18, John ff  wrote:
>>>> 
>>>>     Can you summarise the changes needed?   I think there are two; one
>>>>     to array_get and new syntax.
>>>> Sent from TypeApp

How can I stop it?  i(k-expr) must be valid and there is no obvious way to 

I meant assignment, Joachim's case.

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

> On 30 Oct 2016, at 16:19, jpff  wrote:
> 
> How can I stop it?  i(k-expr) must be valid and there is no obvious way t

Let me know if the latest version works for you (for some value of you), so 
I can fix the documentation

On Sun, 30 Oct 2016, Victor Lazzarini wrote:

> I meant assignment, Joachim's case.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 30 Oct 2016, at 16:19, jpff  wrote:
>>
>> How can I stop it?  i(k-expr) must be valid and there is no obvious way to say "k-expr but not including ay array eleents"

i pulled and tried the example, but the result is the same. instr 2 is:
   kArr[] array 1, 2, 3
   kArr[0] = kArr[0] + 10
   printks "   kArr[0] = %d\n", 0, kArr[0]

running with -v it returns:

instr 2 allocated at 0x802dc0
	lclbas 0x802f58, opds 0x802fe8
op (array.k) allocated at 0x802fe8
op (##array_get.k) allocated at 0x806e98
opadr = 0x7f5f2d784def
op (##add.kk) allocated at 0x80ad50
opadr = 0x7f5f2d6b070f
op (=.k) allocated at 0x80ad98
opadr = 0x7f5f2d6affa4
op (##array_set.k) allocated at 0x80af48
opadr = 0x7f5f2d784adc
op (##array_get.k) allocated at 0x80ee00
opadr = 0x7f5f2d784def
op (printks) allocated at 0x812cb8
opadr = 0x7f5f2d73e42f
insert(): tp->act_instance = 0x802dc0
psave beg at 0x802f30
    ending at 0x802f30
init array.k:
init ##array_set.k:
init printks:
instr 2 now active:
insno	instanc	nxtinst	prvinst	nxtact	prvact	nxtoff	actflg	offtim
0	0x7a0eb0	(nil)	(nil)	(nil)	(nil)	(nil)	1	0.0
1	0x7eefc0	(nil)	(nil)	(nil)	0x60f358	(nil)	0	1.0
2	0x802dc0	(nil)	(nil)	(nil)	0x60f358	(nil)	1	2.0
    kArr[0] = 10
    kArr[0] = 20
    kArr[0] = 30
    kArr[0] = 40
    kArr[0] = 50
    kArr[0] = 60
    kArr[0] = 70
    kArr[0] = 80
    kArr[0] = 90
    kArr[0] = 100


	joachim


On 30/10/16 19:53, jpff wrote:
> Let me know if the latest version works for you (for some value of you),
> so I can fix the documentation
>
> On Sun, 30 Oct 2016, Victor Lazzarini wrote:
>
>> I meant assignment, Joachim's case.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>>> On 30 Oct 2016, at 16:19, jpff  wrote:
>>>
>>> How can I stop it?  i(k-expr) must be valid and there is no obvious
>>> way to say "k-expr but not including ay array eleents"
>>

Not te inteesting part of -v output.

BUT apologies -- I had a  tyo.  Now says

not writing to sound disk
SECTION 1:
new alloc for instr 1:
    kArr[0] = 1
    kArr[0] = 11
B  0.000 ..  1.000 T  1.000 TT  1.000 M:      0.0
new alloc for instr 2:
    kArr[0] = 1
B  1.000 ..  2.000 T  2.000 TT  2.000 M:      0.0
Score finished in csoundPerform().

will commit code now


On Sun, 30 Oct 2016, joachim heintz wrote:

> i pulled and tried the example, but the result is the same. instr 2 is:
>  kArr[] array 1, 2, 3
>  kArr[0] = kArr[0] + 10
>  printks "   kArr[0] = %d\n", 0, kArr[0]
>
> running with -v it returns:
>
> instr 2 allocated at 0x802dc0
> 	lclbas 0x802f58, opds 0x802fe8
> op (array.k) allocated at 0x802fe8
> op (##array_get.k) allocated at 0x806e98
> opadr = 0x7f5f2d784def
> op (##add.kk) allocated at 0x80ad50
> opadr = 0x7f5f2d6b070f
> op (=.k) allocated at 0x80ad98
> opadr = 0x7f5f2d6affa4
> op (##array_set.k) allocated at 0x80af48
> opadr = 0x7f5f2d784adc
> op (##array_get.k) allocated at 0x80ee00
> opadr = 0x7f5f2d784def
> op (printks) allocated at 0x812cb8
> opadr = 0x7f5f2d73e42f
> insert(): tp->act_instance = 0x802dc0
> psave beg at 0x802f30
>   ending at 0x802f30
> init array.k:
> init ##array_set.k:
> init printks:
> instr 2 now active:
> insno	instanc	nxtinst	prvinst	nxtact	prvact	nxtoff	actflg	offtim
> 0	0x7a0eb0	(nil)	(nil)	(nil)	(nil)	(nil)	1	0.0
> 1	0x7eefc0	(nil)	(nil)	(nil)	0x60f358	(nil)	0 
> 1.0
> 2	0x802dc0	(nil)	(nil)	(nil)	0x60f358	(nil)	1 
> 2.0
>   kArr[0] = 10
>   kArr[0] = 20
>   kArr[0] = 30
>   kArr[0] = 40
>   kArr[0] = 50
>   kArr[0] = 60
>   kArr[0] = 70
>   kArr[0] = 80
>   kArr[0] = 90
>   kArr[0] = 100
>
>
> 	joachim
>
>
> On 30/10/16 19:53, jpff wrote:
>> Let me know if the latest version works for you (for some value of you),
>> so I can fix the documentation
>> 
>> On Sun, 30 Oct 2016, Victor Lazzarini wrote:
>> 
>>> I meant assignment, Joachim's case.
>>> 
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>> 
>>>> On 30 Oct 2016, at 16:19, jpff  wrote:
>>>> 
>>>> How can I stop it?  i(k-expr) must be valid and there is no obvious
>>>> way to say "k-expr but not including ay array eleents"
>>> 
>> 

yes i pulled and tested, and the output is as expected now.
i will test more later and report.

	joachim


On 30/10/16 21:20, jpff wrote:
> Not te inteesting part of -v output.
>
> BUT apologies -- I had a  tyo.  Now says
>
> not writing to sound disk
> SECTION 1:
> new alloc for instr 1:
>    kArr[0] = 1
>    kArr[0] = 11
> B  0.000 ..  1.000 T  1.000 TT  1.000 M:      0.0
> new alloc for instr 2:
>    kArr[0] = 1
> B  1.000 ..  2.000 T  2.000 TT  2.000 M:      0.0
> Score finished in csoundPerform().
>
> will commit code now
>
>
> On Sun, 30 Oct 2016, joachim heintz wrote:
>
>> i pulled and tried the example, but the result is the same. instr 2 is:
>>  kArr[] array 1, 2, 3
>>  kArr[0] = kArr[0] + 10
>>  printks "   kArr[0] = %d\n", 0, kArr[0]
>>
>> running with -v it returns:
>>
>> instr 2 allocated at 0x802dc0
>>     lclbas 0x802f58, opds 0x802fe8
>> op (array.k) allocated at 0x802fe8
>> op (##array_get.k) allocated at 0x806e98
>> opadr = 0x7f5f2d784def
>> op (##add.kk) allocated at 0x80ad50
>> opadr = 0x7f5f2d6b070f
>> op (=.k) allocated at 0x80ad98
>> opadr = 0x7f5f2d6affa4
>> op (##array_set.k) allocated at 0x80af48
>> opadr = 0x7f5f2d784adc
>> op (##array_get.k) allocated at 0x80ee00
>> opadr = 0x7f5f2d784def
>> op (printks) allocated at 0x812cb8
>> opadr = 0x7f5f2d73e42f
>> insert(): tp->act_instance = 0x802dc0
>> psave beg at 0x802f30
>>   ending at 0x802f30
>> init array.k:
>> init ##array_set.k:
>> init printks:
>> instr 2 now active:
>> insno    instanc    nxtinst    prvinst    nxtact    prvact
>> nxtoff    actflg    offtim
>> 0    0x7a0eb0    (nil)    (nil)    (nil)    (nil)    (nil)    1    0.0
>> 1    0x7eefc0    (nil)    (nil)    (nil)    0x60f358    (nil)    0 1.0
>> 2    0x802dc0    (nil)    (nil)    (nil)    0x60f358    (nil)    1 2.0
>>   kArr[0] = 10
>>   kArr[0] = 20
>>   kArr[0] = 30
>>   kArr[0] = 40
>>   kArr[0] = 50
>>   kArr[0] = 60
>>   kArr[0] = 70
>>   kArr[0] = 80
>>   kArr[0] = 90
>>   kArr[0] = 100
>>
>>
>>     joachim
>>
>>
>> On 30/10/16 19:53, jpff wrote:
>>> Let me know if the latest version works for you (for some value of you),
>>> so I can fix the documentation
>>>
>>> On Sun, 30 Oct 2016, Victor Lazzarini wrote:
>>>
>>>> I meant assignment, Joachim's case.
>>>>
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>>
>>>>> On 30 Oct 2016, at 16:19, jpff  wrote:
>>>>>
>>>>> How can I stop it?  i(k-expr) must be valid and there is no obvious
>>>>> way to say "k-expr but not including ay array eleents"
>>>>
>>>
>>

i now tested all the twenty examples in 
http://write.flossmanuals.net/csound/e-arrays/ and they all run perfectly.

there is only one small issue with 03E07 which wants to demonstrate how 
to fill a two-dimensional array:
   iArr[][] init   2,3
   iArr     fillarray  1,2,3,7,6,5
   iRow     =      0
   until iRow == 2 do
   iColumn  =      0
     until iColumn == 3 do
     prints "iArr[%d][%d] = %d\n", iRow, iColumn, iArr[iRow][iColumn]
     iColumn +=    1
   enduntil
   iRow      +=    1
   od

it returns:
   iArr[0][65535] = 0
   iArr[0][65535] = 1
   iArr[0][65535] = 2
   iArr[1][65535] = 0
   iArr[1][65535] = 1
   iArr[1][65535] = 2

but i think it was never really meant to work, so this is not a bug.

should i remove this example from the floss manual?  or is there 
anything which works instead to fill multi-dimensional arrays?

That's odd, I think we should investigate. Fillarray is supposed (now) to fill a 2-d array row - column order.

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

> On 31 Oct 2016, at 16:15, joachim heintz  wrote:
> 
> i now tested all the twenty examples in http://write.flossmanuals.net/csound/e-arrays/ and they all run perfectly.
> 
> there is only one small issue with 03E07 which wants to demonstrate how to fill a two-dimensional array:
>  iArr[][] init   2,3
>  iArr     fillarray  1,2,3,7,6,5
>  iRow     =      0
>  until iRow == 2 do
>  iColumn  =      0
>    until iColumn == 3 do
>    prints "iArr[%d][%d] = %d\n", iRow, iColumn, iArr[iRow][iColumn]
>    iColumn +=    1
>  enduntil
>  iRow      +=    1
>  od
> 
> it returns:
>  iArr[0][65535] = 0
>  iArr[0][65535] = 1
>  iArr[0][65535] = 2
>  iArr[1][65535] = 0
>  iArr[1][65535] = 1
>  iArr[1][65535] = 2
> 
> but i think it was never really meant to work, so this is not a bug.
> 
> should i remove this example from the floss manual?  or is there anything which works instead to fill multi-dimensional arrays?
> 

Yes a bug.  I get the slightly different
iArr[0][-2661] = 0
iArr[0][-2661] = 1
iArr[0][-2661] = 2
iArr[1][-2661] = 0
iArr[1][-2661] = 1
iArr[1][-2661] = 2
Score finished in csoundPerform().

I suspect the prints rater than fillarray
==John


On Mon, 31 Oct 2016, joachim heintz wrote:

> i now tested all the twenty examples in 
> http://write.flossmanuals.net/csound/e-arrays/ and they all run perfectly.
>
> there is only one small issue with 03E07 which wants to demonstrate how to 
> fill a two-dimensional array:
>  iArr[][] init   2,3
>  iArr     fillarray  1,2,3,7,6,5
>  iRow     =      0
>  until iRow == 2 do
>  iColumn  =      0
>    until iColumn == 3 do
>    prints "iArr[%d][%d] = %d\n", iRow, iColumn, iArr[iRow][iColumn]
>    iColumn +=    1
>  enduntil
>  iRow      +=    1
>  od
>
> it returns:
>  iArr[0][65535] = 0
>  iArr[0][65535] = 1
>  iArr[0][65535] = 2
>  iArr[1][65535] = 0
>  iArr[1][65535] = 1
>  iArr[1][65535] = 2
>
> but i think it was never really meant to work, so this is not a bug.
>
> should i remove this example from the floss manual?  or is there anything 
> which works instead to fill multi-dimensional arrays?
>
> 	joachim

Fixed in git -- yes it was prints


On Mon, 31 Oct 2016, joachim heintz wrote:

> i now tested all the twenty examples in 
> http://write.flossmanuals.net/csound/e-arrays/ and they all run perfectly.
>
> there is only one small issue with 03E07 which wants to demonstrate how to 
> fill a two-dimensional array:
>  iArr[][] init   2,3
>  iArr     fillarray  1,2,3,7,6,5
>  iRow     =      0
>  until iRow == 2 do
>  iColumn  =      0
>    until iColumn == 3 do
>    prints "iArr[%d][%d] = %d\n", iRow, iColumn, iArr[iRow][iColumn]
>    iColumn +=    1
>  enduntil
>  iRow      +=    1
>  od
>
> it returns:
>  iArr[0][65535] = 0
>  iArr[0][65535] = 1
>  iArr[0][65535] = 2
>  iArr[1][65535] = 0
>  iArr[1][65535] = 1
>  iArr[1][65535] = 2
>
> but i think it was never really meant to work, so this is not a bug.
>
> should i remove this example from the floss manual?  or is there anything 
> which works instead to fill multi-dimensional arrays?
>
> 	joachim

oh yes ... works for me too.  super -
	j


On 31/10/16 21:44, jpff wrote:
> Fixed in git -- yes it was prints
>
>
> On Mon, 31 Oct 2016, joachim heintz wrote:
>
>> i now tested all the twenty examples in
>> http://write.flossmanuals.net/csound/e-arrays/ and they all run
>> perfectly.
>>
>> there is only one small issue with 03E07 which wants to demonstrate
>> how to fill a two-dimensional array:
>>  iArr[][] init   2,3
>>  iArr     fillarray  1,2,3,7,6,5
>>  iRow     =      0
>>  until iRow == 2 do
>>  iColumn  =      0
>>    until iColumn == 3 do
>>    prints "iArr[%d][%d] = %d\n", iRow, iColumn, iArr[iRow][iColumn]
>>    iColumn +=    1
>>  enduntil
>>  iRow      +=    1
>>  od
>>
>> it returns:
>>  iArr[0][65535] = 0
>>  iArr[0][65535] = 1
>>  iArr[0][65535] = 2
>>  iArr[1][65535] = 0
>>  iArr[1][65535] = 1
>>  iArr[1][65535] = 2
>>
>> but i think it was never really meant to work, so this is not a bug.
>>
>> should i remove this example from the floss manual?  or is there
>> anything which works instead to fill multi-dimensional arrays?
>>
>>     joachim
>>