I think definitely we should look into adding
loops, as well as variable/opcode arrays. I am
thinking on the lines of the following syntax:

a1[] arrayinit 10

for ki=0, ki < 10, ki = ki + 1
a1[ki] oscil 10000, kfun*ki, 1
endfor

Of course this is just an example, perhaps we will
need to call a-, k-, i-variable arrays something else
(va, vk, vi ?).

This would also mean that 10 separate oscillators would be
created, and the outputs are stored in a1[0]-a1[9].

Now this is not only syntatic sugar, but a major
addition to the language. Not sure how it would
implemented, but it would be very nice.

> Hi All,
>
> Just another update with the new parser.  I've now gotten
> to the point of getting labels and goto's working.  From
> here on my list I have:
>
> -if-goto
> -if-then-elseif-else
> -UDO's
> -functions
> -polymorphic opcodes (need to check if this isn't done)
> -macros
> -memory clean up
> -cleaning up grammar
> -error reporting
> -general cleaning up of files
>
> I am mostly going in the above order and am continuing to
> work by creating a test first then working to make the
> test work.
>
> Also, I thought CsoundAV had some sort of while loop
> construct using:
>
> while (bool expression)
>   .. opcode statements ..
> wend
>
> but I could not find anything like this in the
> documentation (maybe it was just a suggested idea on the
> mailing list a long time ago).  The question I'm wondering
> is should while loops and for loops be added to Csound?
> It's all syntactic sugar, but it's convenient.  (For-loops
> would need a different delimiter though between statements
> as semicolons are comments).
>
> steven
>
> ----------------------------------------------------------
> --------------- Take Surveys. Earn Cash. Influence the
> Future of IT Join SourceForge.net's Techsay panel and
> you'll get the chance to share your opinions on IT &
> business topics through brief surveys -- and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Re specifically opcode arrays, I think note should be taken of the SAOL 
semantics for this (not least as one use for a Csound backend would be 
as a fast SAOL interpreter - there is a case for ensuring that the 
Csound semantics for arrays facilitates an easy translation to SAOL):

http://www.cs.berkeley.edu/~lazzaro/sa/book/opcodes/filter/index.html#oparray

The notation below might be a problem for any opcodes that have multiple 
or variable numbers of outputs, or even for any opcodes without any 
outputs. SAOL clearly distinguishes between signal-variable arrays, and 
opcode arrays, as can be seen in the example in the link above.

Of course, to support all of SAOL, Csound would need to support 
templates too, which is no doubt "another thing altogether".

Richard Dobson

Victor Lazzarini wrote:
> I think definitely we should look into adding
> loops, as well as variable/opcode arrays. I am
> thinking on the lines of the following syntax:
> 
> a1[] arrayinit 10
> 
..



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

yea, that would be really cool.  although either i don't understand  
the SAOL
version or the example is really poor -- the example seems like it is  
more
work than just using 2 separate opcodes.???

i would like to see something like victor's example except when no
index to the array is given for a variable, the opcode will  
automatically
handle all the elements within the array.
so something like this:

aBfSig arrayinit 4
aBfFilter arrayinit 4

ihp = 1000

aBformatSig in
aBfFilter tone aBfSig, ihp
out aBfFilter


i guess the parser would automatically generate something like:

+ first the size of largest variable array used for output or input  
is found
	( in this example = 4)

+ the opcode is duplicated for that number - so internally the instr  
would look like:

	aBfFilter[0] tone aBfSig[0], ihp
	aBfFilter[1] tone aBfSig[1], ihp
	aBfFilter[2] tone aBfSig[2], ihp
	aBfFilter[3] tone aBfSig[3], ihp

    - note since ihp is not an array, it is used in each instance
    - if arrays are different sizes, the parser needs to determine  
what to do for the smaller array variables
	( i guess just "carry" the last element for input params and do  
nothing for output params? )

+ ideally, the parser or opcodes themselves would know special  
handling of opcodes like in/out/etc to:
		aBformatSig[0], aBformatSig[1],  aBformatSig[2],  aBformatSig[3] inq



On Sep 22, 2006, at 10:31 AM, Richard Dobson wrote:

> Re specifically opcode arrays, I think note should be taken of the  
> SAOL
> semantics for this (not least as one use for a Csound backend would be
> as a fast SAOL interpreter - there is a case for ensuring that the
> Csound semantics for arrays facilitates an easy translation to SAOL):
>
> http://www.cs.berkeley.edu/~lazzaro/sa/book/opcodes/filter/ 
> index.html#oparray
>
> The notation below might be a problem for any opcodes that have  
> multiple
> or variable numbers of outputs, or even for any opcodes without any
> outputs. SAOL clearly distinguishes between signal-variable arrays,  
> and
> opcode arrays, as can be seen in the example in the link above.
>
> Of course, to support all of SAOL, Csound would need to support
> templates too, which is no doubt "another thing altogether".
>
> Richard Dobson
>
> Victor Lazzarini wrote:
>> I think definitely we should look into adding
>> loops, as well as variable/opcode arrays. I am
>> thinking on the lines of the following syntax:
>>
>> a1[] arrayinit 10
>>
>> for ki=0, ki < 10, ki = ki + 1
>> a1[ki] oscil 10000, kfun*ki, 1
>> endfor
>>
>>
> ..
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys -- and earn  
> cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hello... I'm not a developer, but subscribe to this list because I like 
to know what is on the horizon for csound.  So, forgive my intrusion, 
but I wanted to chime in and say that I think this idea would be 
fantastic to implement.  I've been learning supercollider in a class I 
am taking, and while I do not prefer it to csound, I will admit that 
this type of structure is an attractive feature of that language.  
Adding this to csound would be a significant and important addition to 
the language.

Thanks for all of your efforts-- csound is the single best tool I have 
at my disposal and I look forward to its continual evolution.

Oh-- and (unrelated) did anyone ever track down the bug in pconvolve?  
I'm sorry I don't have the c skills to help myself with this issue...

Thanks,
Julian Peterson






Victor Lazzarini wrote:
> I think definitely we should look into adding
> loops, as well as variable/opcode arrays. I am
> thinking on the lines of the following syntax:
>
> a1[] arrayinit 10
>
> for ki=0, ki < 10, ki = ki + 1
> a1[ki] oscil 10000, kfun*ki, 1
> endfor
>
> Of course this is just an example, perhaps we will
> need to call a-, k-, i-variable arrays something else
> (va, vk, vi ?).
>
> This would also mean that 10 separate oscillators would be
> created, and the outputs are stored in a1[0]-a1[9].
>
> Now this is not only syntatic sugar, but a major
> addition to the language. Not sure how it would
> implemented, but it would be very nice.
>
>   
>> Hi All,
>>
>> Just another update with the new parser.  I've now gotten
>> to the point of getting labels and goto's working.  From
>> here on my list I have:
>>
>> -if-goto
>> -if-then-elseif-else
>> -UDO's
>> -functions
>> -polymorphic opcodes (need to check if this isn't done)
>> -macros
>> -memory clean up
>> -cleaning up grammar
>> -error reporting
>> -general cleaning up of files
>>
>> I am mostly going in the above order and am continuing to
>> work by creating a test first then working to make the
>> test work.
>>
>> Also, I thought CsoundAV had some sort of while loop
>> construct using:
>>
>> while (bool expression)
>>   .. opcode statements ..
>> wend
>>
>> but I could not find anything like this in the
>> documentation (maybe it was just a suggested idea on the
>> mailing list a long time ago).  The question I'm wondering
>> is should while loops and for loops be added to Csound?
>> It's all syntactic sugar, but it's convenient.  (For-loops
>> would need a different delimiter though between statements
>> as semicolons are comments).
>>
>> steven
>>
>> ----------------------------------------------------------
>> --------------- Take Surveys. Earn Cash. Influence the
>> Future of IT Join SourceForge.net's Techsay panel and
>> you'll get the chance to share your opinions on IT &
>> business topics through brief surveys -- and earn cash
>>
>>     
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>   
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>     
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>   


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hey Steven,

  i don't know if you saw my emails from yesterday
( i get things all out of order from this list ) but i was suggesting
something more centered around arrays of variables than opcodes.
you could have the parser manually "unwrap" all opcode arrays.
so rather than what you give here:

>
> So, something like this:
>
> ipch = 440
> myoparray[] oparrayinit vco2[10]
> aout init 0
> for i = 0, i < 10, i = i +1
>    aout1 myoparray[i] 5000, ipch * (i + 1)
>    aout = aout + aout1
> fend
>
> would compile down in csound to:
>
> ipch = 440
> myoparray[] oparrayinit vco2[10]
> aout init 0
> __alabel:
> i = 0
> _i1 = ipch * (i + 1)
> aout1 oparray myoparray, i, 500, _i1
> aout = aout + aout1
> i = i + 1
> if i < 10 goto __alabel

i would suggest syntax more like:

ipch array 10, 440 ; 1st arg is size, 2nd argument is optional  
initialize value
for_i (i = 0, i < 10, i = i +1)
    ipch[i] init 440 * (i + 1)
fend
aout vco2 1, ipch


which would compile down to something like:


ipch array 10, 440

i = 0
__alabel:
    ipch[i] init 440 * (i + 1)
i = i + 1
if i < 10 goto __alabel

aout_0 vco2 1, ipch[0]
aout_1 vco2 1, ipch[1]
aout_2 vco2 1, ipch[2]
aout_3 vco2 1, ipch[3]
aout_4 vco2 1, ipch[4]
aout_5 vco2 1, ipch[5]
aout_6 vco2 1, ipch[6]
aout_7 vco2 1, ipch[7]
aout_8 vco2 1, ipch[8]
aout_9 vco2 1, ipch[9]
aout = aout_0+aout_1+aout_2+aout_3+aout_4+aout_5+aout_6+aout_7+aout_8 
+aout_9


OR, if  implementing variable arrays internally is not possible, you  
could
even do everything in the parser by adding a kind of "switch" for  
every instance
when the user indexes the array dynamically, so the above would become:


ipch_0 init 440
ipch_1 init 440
ipch_2 init 440
ipch_3 init 440
ipch_4 init 440
ipch_5 init 440
ipch_6 init 440
ipch_7 init 440
ipch_8 init 440
ipch_9 init 440

i = 0
__alabel:
	i_inArg1 = 440 * (i + 1)
	cggoto (i != 0), "arraylabel_0"
		ipch_0 init i_inArg1
	arraylabel_0:
	cggoto (i != 1), "arraylabel_1"
		ipch_1 init i_inArg1
	arraylabel_1:
	cggoto (i != 2), "arraylabel_2"
		ipch_2 init i_inArg1
	arraylabel_2:
	cggoto (i != 3), "arraylabel_3"
		ipch_3 init i_inArg1		
	..............you get the idea...
	arraylabel_9:
i = i + 1
if i < 10 goto __alabel


aout_0 vco2 1, ipch_0
aout_1 vco2 1, ipch_1
aout_2 vco2 1, ipch_2
aout_3 vco2 1, ipch_3
aout_4 vco2 1, ipch_4
aout_5 vco2 1, ipch_5
aout_6 vco2 1, ipch_6
aout_7 vco2 1, ipch_7
aout_8 vco2 1, ipch_8
aout_9 vco2 1, ipch_9
aout = aout_0+aout_1+aout_2+aout_3+aout_4+aout_5+aout_6+aout_7+aout_8 
+aout_9

-----

although this could get hairy, especially when you are using multiple  
arrays on output
of an opcode (N*N more opcodes allocated!)
but i think it would work.
And it should easily work for things like n-channel signal variables,
what i think is MORE important and powerful than the ability to have  
"banks" of opcodes..
[ it would be awesome to have instrs that could work with any nchnls  
with no extra code
needed.. ]


> decreases the portability of the instrument.  (Though, I started to
> wonder about inner UDO's, like inner classes in Java, where UDO could
> be defned within an instrument and only used within that instrument;
> could avoid nameclashes that way, but not sure how often it'd be
> used).

is that a big problem.

thanks for all your work on this steven!

-m






-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>  Oh-- and (unrelated) did anyone ever track down the bug in pconvolve?  

I cannot find any evidence yet!  Not sure I can remember the problem.
Could you repeat it please?  My memory is not what it was, nor what it
was.

==John ffitch

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

whoops!  looks like it might be fixed.  I had an orc that failed with 
pconvolve but worked with convolve, so I had stopped using pconvolve 
altogether since there seemed to be some confusion about it on this 
mailing list.  I just tried it and it worked exactly as expected.

The bug had been that pconvolve was overwriting memory space so that 
when using it I was getting all sorts of errors, like unknown ftable 
2910958, where no instrument called such a table, etc..

So nevermind; sorry about the bother.  Looks like it's already been 
taken care of.

Thanks,
Julian Peterson


jpff wrote:
>>  Oh-- and (unrelated) did anyone ever track down the bug in pconvolve?  
>>     
>
> I cannot find any evidence yet!  Not sure I can remember the problem.
> Could you repeat it please?  My memory is not what it was, nor what it
> was.
>
> ==John ffitch
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>   


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net