Csound Csound-dev Csound-tekno Search About

Re: [Csnd-dev] Large numbers of input arguments to opcodes

Date2019-01-08 15:34
FromJohn
SubjectRe: [Csnd-dev] Large numbers of input arguments to opcodes
Removing the restriction would involve major changes essentially to
every opcode, or at least that is the only way I can see to do it.

So the current state in github is that there is a new variant of
fillarray

  i[]   fillarray  "file_name"
  k[]   fillarray  "file_name"

where  the file is a list of numbers, space or comma separated and
dealing in a limited way with comments starting with ; or # until eol.
This is the same as gen23

There is also

  i[]   string2array {{ ....}}
  k[]   string2array {{ ....}}

which does much the same for a string except no comment skipping

The name of the second is not good so I would be happy with a new
name.  the fillarray has been tested and seems correct.  string2array
only lightly tested as of now.

While doing this processing  removed some restrictions on 1 and 2D
only arrays and some better checking.

Please try and give feedback

Date2019-01-08 21:41
Fromjoachim heintz
SubjectRe: [Csnd-dev] Large numbers of input arguments to opcodes
first test shows for me that there is one extra zero for each dimension 
of the array.  so for this code (the txt file is attached)

giSnippets[] fillarray "snippets_lines.txt"
printarray giSnippets

i get one extra zero at the beginning
   0: 0.0000 1.0000 0.6970 3.8500 66.2000 -38.8000 0.7700 2.0000 2.1250 
3.8400 89.4300
   10: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600 -31.3000 0.7500 
4.0000 2.5430 etc

wheras for
giSnippets[][] init 765, 6
giSnippets fillarray "snippets_lines.txt"
printarray giSnippets

i get two extra zeros at the beginning:
    0: 0.0000 0.0000 1.0000 0.6970 3.8500 66.2000
    1: -38.8000 0.7700 2.0000 2.1250 3.8400 89.4300
    2: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600

otherwise, the content looks ok.

when i put all my text in the string2array opcode, it seems to struggle 
with the length of the string, but with no obvious result.  i can 
interrupt, but it does not seem to be able to load such long strings.

best -
	joachim





On 08/01/19 16:34, John wrote:
> Removing the restriction would involve major changes essentially to
> every opcode, or at least that is the only way I can see to do it.
>
> So the current state in github is that there is a new variant of
> fillarray
>
>   i[]   fillarray  "file_name"
>   k[]   fillarray  "file_name"
>
> where  the file is a list of numbers, space or comma separated and
> dealing in a limited way with comments starting with ; or # until eol.
> This is the same as gen23
>
> There is also
>
>   i[]   string2array {{ ....}}
>   k[]   string2array {{ ....}}
>
> which does much the same for a string except no comment skipping
>
> The name of the second is not good so I would be happy with a new
> name.  the fillarray has been tested and seems correct.  string2array
> only lightly tested as of now.
>
> While doing this processing  removed some restrictions on 1 and 2D
> only arrays and some better checking.
>
> Please try and give feedback
>
> ==John ffitch

Date2019-01-09 14:56
Fromjpff
SubjectRe: [Csnd-dev] Large numbers of input arguments to opcodes
Apologies -- my stupidity on a ae change.  OK in github


On Tue, 8 Jan 2019, joachim heintz wrote:

> first test shows for me that there is one extra zero for each dimension of 
> the array.  so for this code (the txt file is attached)
>
> giSnippets[] fillarray "snippets_lines.txt"
> printarray giSnippets
>
> i get one extra zero at the beginning
>  0: 0.0000 1.0000 0.6970 3.8500 66.2000 -38.8000 0.7700 2.0000 2.1250 3.8400 
> 89.4300
>  10: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600 -31.3000 0.7500 4.0000 
> 2.5430 etc
>
> wheras for
> giSnippets[][] init 765, 6
> giSnippets fillarray "snippets_lines.txt"
> printarray giSnippets
>
> i get two extra zeros at the beginning:
>   0: 0.0000 0.0000 1.0000 0.6970 3.8500 66.2000
>   1: -38.8000 0.7700 2.0000 2.1250 3.8400 89.4300
>   2: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600
>
> otherwise, the content looks ok.
>
> when i put all my text in the string2array opcode, it seems to struggle with 
> the length of the string, but with no obvious result.  i can interrupt, but 
> it does not seem to be able to load such long strings.
>
> best -
> 	joachim
>
>
>
>
>
> On 08/01/19 16:34, John wrote:
>> Removing the restriction would involve major changes essentially to
>> every opcode, or at least that is the only way I can see to do it.
>> 
>> So the current state in github is that there is a new variant of
>> fillarray
>>
>>   i[]   fillarray  "file_name"
>>   k[]   fillarray  "file_name"
>> 
>> where  the file is a list of numbers, space or comma separated and
>> dealing in a limited way with comments starting with ; or # until eol.
>> This is the same as gen23
>> 
>> There is also
>>
>>   i[]   string2array {{ ....}}
>>   k[]   string2array {{ ....}}
>> 
>> which does much the same for a string except no comment skipping
>> 
>> The name of the second is not good so I would be happy with a new
>> name.  the fillarray has been tested and seems correct.  string2array
>> only lightly tested as of now.
>> 
>> While doing this processing  removed some restrictions on 1 and 2D
>> only arrays and some better checking.
>> 
>> Please try and give feedback
>> 
>> ==John ffitch
>> 

Date2019-01-09 16:55
Fromjoachim heintz
SubjectRe: [Csnd-dev] Large numbers of input arguments to opcodes
thanks!  the file reading works now, also for 2 dimensions.

i cannot get any success for the string2array version.  certainly, the 
string input for my example is 767 x 6 fields; but should it not work 
anyway?

	joachim



On 09/01/19 15:56, jpff wrote:
> Apologies -- my stupidity on a ae change.  OK in github
>
>
> On Tue, 8 Jan 2019, joachim heintz wrote:
>
>> first test shows for me that there is one extra zero for each
>> dimension of the array.  so for this code (the txt file is attached)
>>
>> giSnippets[] fillarray "snippets_lines.txt"
>> printarray giSnippets
>>
>> i get one extra zero at the beginning
>>  0: 0.0000 1.0000 0.6970 3.8500 66.2000 -38.8000 0.7700 2.0000 2.1250
>> 3.8400 89.4300
>>  10: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600 -31.3000 0.7500
>> 4.0000 2.5430 etc
>>
>> wheras for
>> giSnippets[][] init 765, 6
>> giSnippets fillarray "snippets_lines.txt"
>> printarray giSnippets
>>
>> i get two extra zeros at the beginning:
>>   0: 0.0000 0.0000 1.0000 0.6970 3.8500 66.2000
>>   1: -38.8000 0.7700 2.0000 2.1250 3.8400 89.4300
>>   2: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600
>>
>> otherwise, the content looks ok.
>>
>> when i put all my text in the string2array opcode, it seems to
>> struggle with the length of the string, but with no obvious result.  i
>> can interrupt, but it does not seem to be able to load such long strings.
>>
>> best -
>>     joachim
>>
>>
>>
>>
>>
>> On 08/01/19 16:34, John wrote:
>>> Removing the restriction would involve major changes essentially to
>>> every opcode, or at least that is the only way I can see to do it.
>>>
>>> So the current state in github is that there is a new variant of
>>> fillarray
>>>
>>>   i[]   fillarray  "file_name"
>>>   k[]   fillarray  "file_name"
>>>
>>> where  the file is a list of numbers, space or comma separated and
>>> dealing in a limited way with comments starting with ; or # until eol.
>>> This is the same as gen23
>>>
>>> There is also
>>>
>>>   i[]   string2array {{ ....}}
>>>   k[]   string2array {{ ....}}
>>>
>>> which does much the same for a string except no comment skipping
>>>
>>> The name of the second is not good so I would be happy with a new
>>> name.  the fillarray has been tested and seems correct.  string2array
>>> only lightly tested as of now.
>>>
>>> While doing this processing  removed some restrictions on 1 and 2D
>>> only arrays and some better checking.
>>>
>>> Please try and give feedback
>>>
>>> ==John ffitch
>>>
>>

Date2019-01-09 17:04
FromJohn ff
SubjectRe: [Csnd-dev] Large numbers of input arguments to opcodes
Oh dear.  It worked on my tests after fixing a fence post error where it lost the last number.

Will check again.

Sent from TypeApp
On 9 Jan 2019, at 16:56, joachim heintz <jh@joachimheintz.de> wrote:
thanks!  the file reading works now, also for 2 dimensions.

i cannot get any success for the string2array version. certainly, the
string input for my example is 767 x 6 fields; but should it not work
anyway?

joachim



On 09/01/19 15:56, jpff wrote:
Apologies -- my stupidity on a ae change. OK in github


On Tue, 8 Jan 2019, joachim heintz wrote:

first test shows for me that there is one extra zero for each
dimension of the array. so for this code (the txt file is attached)

giSnippets[] fillarray "snippets_lines.txt"
printarray giSnippets

i get one extra zero at the beginning
0: 0.0000 1.0000 0.6970 3.8500 66.2000 -38.8000 0.7700 2.0000 2.1250
3.8400 89.4300
10: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600 -31.3000 0.7500
4.0000 2.5430 etc

wheras for
giSnippets[][] init 765, 6
giSnippets fillarray "snippets_lines.txt"
printarray giSnippets

i get two extra zeros at the beginning:
0: 0.0000 0.0000 1.0000 0.6970 3.8500 66.2000
1: -38.8000 0.7700 2.0000 2.1250 3.8400 89.4300
2: -26.8000 0.4300 3.0000 2.3460 7.5580 55.4600

otherwise, the content looks ok.

when i put all my text in the string2array opcode, it seems to
struggle with the length of the string, but with no obvious result. i
can interrupt, but it does not seem to be able to load such long strings.

best -
joachim





On 08/01/19 16:34, John wrote:
Removing the restriction would involve major changes essentially to
every opcode, or at least that is the only way I can see to do it.

So the current state in github is that there is a new variant of
fillarray

i[] fillarray "file_name"
k[] fillarray "file_name"

where the file is a list of numbers, space or comma separated and
dealing in a limited way with comments starting with ; or # until eol.
This is the same as gen23

There is also

i[] string2array {{ ....}}
k[] string2array {{ ....}}

which does much the same for a string except no comment skipping

The name of the second is not good so I would be happy with a new
name. the fillarray has been tested and seems correct. string2array
only lightly tested as of now.

While doing this processing removed some restrictions on 1 and 2D
only arrays and some better checking.

Please try and give feedback

==John ffitch