I’m wondering if it’s safe to do something like the following:

opcode CALC_INITIAL_ONSETS i[],iii
  ia,ib,ic xin
  iOnsets[] init 1000
  xout iOnsets
endop

instr 1
iOnsets[] init 1
 . . .
. . .
iOnsets CALC_INITIAL_ONSETS_I ia,ib,ic
. . .
endin

The definition of iOnsets in instr 1 is just syntactic sugar that csound insists upon.

My question is what exactly happens to the iOnsets array in instr 1? Does the opcode CALC_INITIAL_ONSETS return the iOnsets array created within by value or by reference? If by value, is the array in instr 1 correctly resized? If by reference, does the array created within the opcode persist?

I already have a workaround, just curious.

Thanks,
Robert
Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I think it resizes the array and it is all by value.  /te init creares an 
array of specified size.  Most array opcodes will resize if more space is 
needed, maybe canging the internal location of the data.

Or I may have misunderstood the quetion asusual

==Jo ff

On Tue, 28 Jun 2016, C. R. Craig wrote:

> I’m wondering if it’s safe to do something like the following:
>
> opcode CALC_INITIAL_ONSETS i[],iii
>  ia,ib,ic xin
>  iOnsets[] init 1000
>  xout iOnsets
> endop
>
> instr 1
> iOnsets[] init 1
> . . .
> . . .
> iOnsets CALC_INITIAL_ONSETS_I ia,ib,ic
> . . .
> endin
>
> The definition of iOnsets in instr 1 is just syntactic sugar that csound insists upon.
>
> My question is what exactly happens to the iOnsets array in instr 1? Does the opcode CALC_INITIAL_ONSETS return the iOnsets array created within by value or by reference? If by value, is the array in instr 1 correctly resized? If by reference, does the array created within the opcode persist?
>
> I already have a workaround, just curious.
>
> Thanks,
> Robert
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

It hasn’t crashed yet, so I suspect you’re correct :-)

Or I may just be lucky.

Thanks,
Robert

> On Jun 28, 2016, at 12:15 PM, jpff  wrote:
> 
> I think it resizes the array and it is all by value.  /te init creares an array of specified size.  Most array opcodes will resize if more space is needed, maybe canging the internal location of the data.
> 
> Or I may have misunderstood the quetion asusual
> 
> ==Jo ff
> 
> On Tue, 28 Jun 2016, C. R. Craig wrote:
> 
>> I’m wondering if it’s safe to do something like the following:
>> 
>> opcode CALC_INITIAL_ONSETS i[],iii
>> ia,ib,ic xin
>> iOnsets[] init 1000
>> xout iOnsets
>> endop
>> 
>> instr 1
>> iOnsets[] init 1
>> . . .
>> . . .
>> iOnsets CALC_INITIAL_ONSETS_I ia,ib,ic
>> . . .
>> endin
>> 
>> The definition of iOnsets in instr 1 is just syntactic sugar that csound insists upon.
>> 
>> My question is what exactly happens to the iOnsets array in instr 1? Does the opcode CALC_INITIAL_ONSETS return the iOnsets array created within by value or by reference? If by value, is the array in instr 1 correctly resized? If by reference, does the array created within the opcode persist?
>> 
>> I already have a workaround, just curious.
>> 
>> Thanks,
>> Robert
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> 
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>       https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Note: UDO's all manage arguments passing by value.  Native opcodes all
manage arguments using references.  It's a byproduct of how UDO's were
originally implemented and it's a bit of an awkward issue to resolve
having two passing systems sharing the same type declaration system.
On the whole, users using UDOs will generally find that things work as
expected and copying by value is safe in terms of processing
expectations, but internally there is a performance cost.

For your example, the iOnsets array within the UDO will have all of
its values copied into the calling instrument's iOnsets array.  The
copying will resize the array if necessary.

On Tue, Jun 28, 2016 at 5:57 PM, C. R. Craig  wrote:
> It hasn’t crashed yet, so I suspect you’re correct :-)
>
> Or I may just be lucky.
>
> Thanks,
> Robert
>
>> On Jun 28, 2016, at 12:15 PM, jpff  wrote:
>>
>> I think it resizes the array and it is all by value.  /te init creares an array of specified size.  Most array opcodes will resize if more space is needed, maybe canging the internal location of the data.
>>
>> Or I may have misunderstood the quetion asusual
>>
>> ==Jo ff
>>
>> On Tue, 28 Jun 2016, C. R. Craig wrote:
>>
>>> I’m wondering if it’s safe to do something like the following:
>>>
>>> opcode CALC_INITIAL_ONSETS i[],iii
>>> ia,ib,ic xin
>>> iOnsets[] init 1000
>>> xout iOnsets
>>> endop
>>>
>>> instr 1
>>> iOnsets[] init 1
>>> . . .
>>> . . .
>>> iOnsets CALC_INITIAL_ONSETS_I ia,ib,ic
>>> . . .
>>> endin
>>>
>>> The definition of iOnsets in instr 1 is just syntactic sugar that csound insists upon.
>>>
>>> My question is what exactly happens to the iOnsets array in instr 1? Does the opcode CALC_INITIAL_ONSETS return the iOnsets array created within by value or by reference? If by value, is the array in instr 1 correctly resized? If by reference, does the array created within the opcode persist?
>>>
>>> I already have a workaround, just curious.
>>>
>>> Thanks,
>>> Robert
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>>
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here