hi all -

i have a collection of arrays and i am looking for a good way to pass 
one of them to an instrument as p-field.  so something like:

gi_arr1[] fillarray ...
gi_arr2[] fillarray ...

and in the instrument currently i write:
   iArr[] = gi_arr1
but i would like to write:
   iArr[] = p4

how could i do this?

thanks -
	joachim

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

Hi,

I am afraid an instrument cannot take arrays as arguments (UDO can), one workaround woud be to use a table instead of array - then it is easy to pass the table number - and convert table to an array and back, if necessary.

Hope there is a better way...

tarmo

On Wednesday, June 29, 2016 08:34:29 PM you wrote:

> hi all -

>

> i have a collection of arrays and i am looking for a good way to pass

> one of them to an instrument as p-field. so something like:

>

> gi_arr1[] fillarray ...

> gi_arr2[] fillarray ...

>

> and in the instrument currently i write:

> iArr[] = gi_arr1

> but i would like to write:

> iArr[] = p4

>

> how could i do this?

>

> thanks -

> joachim

>

> 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

The short answer I have is that it is not currently possible with
Csound.  The longer answer follows below.

The situation is that EVTBLK's (what represent events) internally in
Csound have pfields that are MYFLT's.  A special kind of identifier is
used to interpret the MYFLT as a string.  Beyond that, there is no
support for fields of other types besides numbers and strings.

As it is today, arrays can not be used as pfields.  That said, a path
forward would be change event structures to used typed fields using
CS_VAR_MEM instead, which includes the CS_TYPE for the value stored in
memory.  This would enable, internally, that any type of variable
found in the ORC system to be used within events.  However, additional
work would be required for the external language to enable writing
code where events may take in arguments of types other than strings or
numbers.  This would be much simpler for the event opcodes in the ORC
language, and not very easy for the SCO language.

Besides ftables, an alternative is to use 2-dimensional arrays and
indexes as pfields, but this requires homogenous sizing of sub-arrays.

I think moving towards a more generic EVTBLK would make sense.  I have
no idea though about performance cost, if any, of making such a
change, especially in regards to large amounts of score events read in
from a SCO file. (Needs testing to see if it has an impact.)

There is an additional issue in that semantic analysis does not do
much for verification of pfields as far as I know.  That is to say, if
you pass in a string as p4, but pass it to an opcode that expects a
number, I'm not sure that is currently checked.  The problem doesn't
come up often now, but if pfields are further extended to any type,
then the problem would require run-time verification, rather than
compile-time.

The introduction of user-defined types in the parser3 branch and
overall trajectory of Csound's evolution from 5 to 6 and on to 7
would, to me, point to a more generic handling of event arguments for
instrument scheduling.  My own proposal would be that the EVTBLK
structure be modified, the compiler introduces runtime type checks
where necessary (using a type check opcode), and that event producing
opcodes be modified to deal with any types for arguments.  I would
also propose that the changes and usage be limited to the ORC language
at first, as the changes would be non-trivial.  A later change could
be introduced to bring the ORC and SCO sides of Csound more closely
together such that other types of values could be declared in SCO.
However, I think exploring that is likely to have many issues.

On Wed, Jun 29, 2016 at 3:45 PM, Tarmo Johannes
 wrote:
> Hi,
>
>
>
> I am afraid an instrument cannot take arrays as arguments (UDO can), one
> workaround woud be to use a table instead of array - then it is easy to pass
> the table number - and convert table to an array and back, if necessary.
>
>
>
> Hope there is a better way...
>
>
>
> tarmo
>
>
>
>
>
> On Wednesday, June 29, 2016 08:34:29 PM you wrote:
>
>> hi all -
>
>>
>
>> i have a collection of arrays and i am looking for a good way to pass
>
>> one of them to an instrument as p-field. so something like:
>
>>
>
>> gi_arr1[] fillarray ...
>
>> gi_arr2[] fillarray ...
>
>>
>
>> and in the instrument currently i write:
>
>> iArr[] = gi_arr1
>
>> but i would like to write:
>
>> iArr[] = p4
>
>>
>
>> how could i do this?
>
>>
>
>> thanks -
>
>> joachim
>
>>
>
>> 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

thanks for the explanation, steven.  i think having this in future only 
(or first) in the orc language, would be allright, and very useful. 
currently the lack of this possibility makes it sometimes more difficult 
to work with arrays than with ftables, which is a pity, because we all 
enjoy the simplification and better readable code introduced by the 
array feature in csound.

a two-dimensional array would be no option in my case, as the arrays 
have different lengths.

i am wondering whether something like strset would be possible for 
arrays? like:
arrset 1, iarr_1
arrset 2, kotherarray

so hoping there will be a possibility in future; cheers -
	joachim


On 30/06/16 00:40, Steven Yi wrote:
> The short answer I have is that it is not currently possible with
> Csound.  The longer answer follows below.
>
> The situation is that EVTBLK's (what represent events) internally in
> Csound have pfields that are MYFLT's.  A special kind of identifier is
> used to interpret the MYFLT as a string.  Beyond that, there is no
> support for fields of other types besides numbers and strings.
>
> As it is today, arrays can not be used as pfields.  That said, a path
> forward would be change event structures to used typed fields using
> CS_VAR_MEM instead, which includes the CS_TYPE for the value stored in
> memory.  This would enable, internally, that any type of variable
> found in the ORC system to be used within events.  However, additional
> work would be required for the external language to enable writing
> code where events may take in arguments of types other than strings or
> numbers.  This would be much simpler for the event opcodes in the ORC
> language, and not very easy for the SCO language.
>
> Besides ftables, an alternative is to use 2-dimensional arrays and
> indexes as pfields, but this requires homogenous sizing of sub-arrays.
>
> I think moving towards a more generic EVTBLK would make sense.  I have
> no idea though about performance cost, if any, of making such a
> change, especially in regards to large amounts of score events read in
> from a SCO file. (Needs testing to see if it has an impact.)
>
> There is an additional issue in that semantic analysis does not do
> much for verification of pfields as far as I know.  That is to say, if
> you pass in a string as p4, but pass it to an opcode that expects a
> number, I'm not sure that is currently checked.  The problem doesn't
> come up often now, but if pfields are further extended to any type,
> then the problem would require run-time verification, rather than
> compile-time.
>
> The introduction of user-defined types in the parser3 branch and
> overall trajectory of Csound's evolution from 5 to 6 and on to 7
> would, to me, point to a more generic handling of event arguments for
> instrument scheduling.  My own proposal would be that the EVTBLK
> structure be modified, the compiler introduces runtime type checks
> where necessary (using a type check opcode), and that event producing
> opcodes be modified to deal with any types for arguments.  I would
> also propose that the changes and usage be limited to the ORC language
> at first, as the changes would be non-trivial.  A later change could
> be introduced to bring the ORC and SCO sides of Csound more closely
> together such that other types of values could be declared in SCO.
> However, I think exploring that is likely to have many issues.
>
> On Wed, Jun 29, 2016 at 3:45 PM, Tarmo Johannes
>  wrote:
>> Hi,
>>
>>
>>
>> I am afraid an instrument cannot take arrays as arguments (UDO can), one
>> workaround woud be to use a table instead of array - then it is easy to pass
>> the table number - and convert table to an array and back, if necessary.
>>
>>
>>
>> Hope there is a better way...
>>
>>
>>
>> tarmo
>>
>>
>>
>>
>>
>> On Wednesday, June 29, 2016 08:34:29 PM you wrote:
>>
>>> hi all -
>>
>>>
>>
>>> i have a collection of arrays and i am looking for a good way to pass
>>
>>> one of them to an instrument as p-field. so something like:
>>
>>>
>>
>>> gi_arr1[] fillarray ...
>>
>>> gi_arr2[] fillarray ...
>>
>>>
>>
>>> and in the instrument currently i write:
>>
>>> iArr[] = gi_arr1
>>
>>> but i would like to write:
>>
>>> iArr[] = p4
>>
>>>
>>
>>> how could i do this?
>>
>>>
>>
>>> thanks -
>>
>>> joachim
>>
>>>
>>
>>> 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