This sounds interesting, but I would like time to
consider. One thing that perhaps might confuse
a little bit is that arrays indexes start at 1 rather than
0. Would that be an issue? I can't think at the
moment if it goes against other conventions in
Csound, or is the C in me thinking...

>
> I want to chime in here with some of my own thoughts.  I
> think that I may even have a reasonable solution to the
> different ideas about how arrays should behave.  (Sorry
> this is long -- but I want to answer your questions before
> you ask them :)
>
> First, I think it is absolutely necessary that we have
> both signal arrays and opcode arrays.  And I would really
> like for them to have a more explicit syntax so that the
> behavior can be more easily predicted.  However, I really
> appreciate Matt's suggestions and I think in many (but not
> all) cases we may be able to do away with the need for
> explicit looping statements.
>
> One of the problems that I see with Matt's suggested
> syntax is that it will disallow certain interesting signal
> routings that some users may wish to use.
>
> For example, if I define three signal arrays:
>
> dim ainput[4]
> dim abus[4]
> dim ifreqs[4]   ;; afterwards I set these to different
> values
>
> I may wish to do something like filtering channel 1 of
> ainput[] with each of ifreq[] values and store the result
> to their respective abus[] indices:
>
> for i = 1 to 4  ;; (the "for" syntax here is conceptual
> only)
>     abus[i]  reson  ainput[1], ifreqs[i], ibwidth
> fend
>
> With matt's "auto-syntax", I do not see how this could be
> done:
>
> abus   reson   ainput, ifreqs, ibwidth
>
> will use channels 1-4 of ainput[].  (Not that we could not
> have both implied and explicit array access syntax to
> potentially solve this problem, but the problem of
> incongruent array sizes would remain).
>
> The other problem I see with the auto-unpacking syntax is
> that sometimes you will want a "bank" of opcodes and
> sometimes you will not.  Usually, with any opcode with
> some internal state (oscillators, filters, etc.) you will
> want an array of opcodes to be automatically created by
> Matt's syntax.  But in circumstances where there is no
> saved state in between k-passes, it would be more
> efficient to have only one opcode allocated:
>
> abus   =     abus + ainput  ;; this would work fine with
> only one = and +
>
> Thus, my suggestion is to always have explicit array
> indices for both signal arrays and opcode arrays but to
> allow _ranges_ of indices to be specified to alleviate the
> need to always have explicit loop statements.  Consider
> the following:
>
> abus[1:4]   reson[1:4]   ainput[1:4], ifreqs[1:4], ibwidth
>
> would create four resons and loop four times having the
> same effect as
>
> for i = 1 to 4
>     abus[i]  reson[i]  ainput[i], ifreqs[i], ibwidth
> fend
>
>
> On the otherhand, we can still easily do the following:
>
> abus[1:4]   reson[1:4]   ainput[1], ifreqs[1:4], ibwidth
>
> would create four resons and loop four times using
> ainput[1] each time
>
> for i = 1 to 4
>     abus[i]  reson[i]  ainput[1], ifreqs[i], ibwidth
> fend
>
>
> It would be possible to write
>
> abus[1:4]   reson   ainput[1], ifreqs[1:4], ibwidth
>
> but this would only allocate ONE reson and loop four times
> like this
>
> for i = 1 to 4
>     abus[i]  reson  ainput[1], ifreqs[i], ibwidth
> fend
>
> and would probably not give the result that the user wants
> because the internal reson state would be "confused".
>
>
> But having this flexibility is important so that we can do
> the following:
>
> abus[1:4]   =  abus[1:4] + ainput[1:4]  ;; combine two
> four channel sigs or
> abus[1:4]   =  abus[1:4] + ainput[1]    ;; add mono sig to
> all four buses
>
> and only one instance each of the = and + will be created.
>
>
> In addition, this syntax can be much more flexible than
> Matt's suggestion and still maintain its compactness:
>
> dim ainput[4]
> dim abus[8]
>
> abus[1:4]   =  abus[5:8] + ainput[1:4]
> or even
> abus[1:4]   =  abus[3:6] + ainput[1:4]
>
> Of course, I think that i-rate (maybe even k-rate)
> expressions should be allowed as indices:
>
> dim ainput[p5]
> dim abus[p5*2]
>
> abus[1:p5]   =  abus[p5+1:p5*2] + ainput[1:p5]
>
> OR
>
> dim ainput[nchnls]
> dim abus[nchnls*2]
>
> abus[1:nchnls]   =  abus[nchnls+1:nchnls*2] +
> ainput[1:nchnls]
>
>
> Additionally, some syntacic "sugar" could be allowed in
> the form of "list comprehensions":
>
> dim ainput[4]
> dim abus[8]
>
> abus[:4]   =  abus[5:] + ainput[:]
>
> [:4] means from the first array element to the 4th.  [5:]
> means from the 5th to the last.  And [:] means from the
> first to the last.
>
> It may even be really convenient to include this
> possibility:
>
> abus[1:4]   =   ainput[4:1]
>
> which would be treated as
>
> for i = 1 to 4
>     abus[i]   =   ainput[5-i]
> fend
>
>
> The most important thing, I believe, about this implied
> looping syntax is that Csound will calculate the array
> index boundaries at the beginning of each loop and save
> them (so that they cannot be altered during the loop) AND
> Csound will make sure that all ranges of indices (greater
> than 1) are the SAME size.  Any mismatch in the size of
> the ranges is a performance time error and the instrument
> instance should be deactivated.
>
> abus[1:4]   =  abus[1:4] + ainput[1:2]  ;; this is
> ambiguous -> perferror abus[1:4]   =  abus[1:4] +
> ainput[1]    ;; this is OK
>
> abus[1:4]  reson[1:2]  ainput[1], ifreqs[1:4], ibwidth  ;;
> this is an error abus[1:4]  reson       ainput[1],
> ifreqs[1:4], ibwidth  ;; this is OK
>
>
> As far as "mixing down" the output of opcode arrays, I see
> a couple of possibilities.  Providing some "special case"
> channel summation and product opcodes would be useful:
>
> dim ainput[4]
> dim abus[4]
>
> abus[:]  reson[1:4]  ainput[:], ifreq, ibwidth
> aout     sum         abus[:]       ;; one instance of sum
> reads abus[1:4] aring    product     abus[:]       ;; aout
> & aring are not arrays
>
> Matt's suggestion for special versions of the in and out
> opcodes should be kept as well:
>
> dim ainput[4]
>
> ainput[:]  inq
>            outq  ainput[:]
>
>
> An alternative option for "mixing down" is to allow one
> more piece of syntactic sugar so that we can eliminate the
> intermediate array:
>
> dim ainput[4]
>
> aout[&]  reson[1:4]  ainput[:], ifreq, ibwidth ;; aout is
> NOT an array
>
> which would be treated like this:
>
> for i = 1 to 4
>     atemp  reson[i]  ainput[i], ifreq, ibwidth
>     aout   =         aout + atemp
> fend
>
> We can discuss alternative syntaxes for this shortcut, but
> you get the basic idea.
>
> Note in the version of the syntax that I have been
> describing here that it is not necessary to pre-dimension
> the opcode arrays.  reson[1:4] creates an array of size
> four and simultaneously describes how the opcode array is
> used in the loop.  Because of this, opcode arrays will
> always be written opcode[1:n]  and I do not think that
> there are too many instances where this will be
> insufficient (although I can think of at least one).
>
> In cases where it is necessary to explicitly access one
> element of an opcode array at a time (eg. in an explicit
> loop) then we would likely want some other syntax.  I
> would propose something like this:
>
> for ki = 1 to 4
>     ifreq  table           ki, imytable
>     atemp  reson[ki of 4]  ainput[ki], ifreq, ibwidth
>     aout   =               aout + atemp
> fend
>
>
> I like how this syntax for opcode arrays keeps the name of
> the opcode on the line that it is operating on -- this
> seems the most clear and intuitive way to do it to me as
> opposed to having named opcode arrays.  But there are
> advantages to the named array option as well.  I would be
> very interested to hear if anyone has other suggestions
> for syntax in this area.
>
> I ask that everyone will seriously consider my proposal
> here and I hope that you will find it as flexible and as
> satisfactory as I do.
>
> Thanks.
>
>
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
>
>
> Steven Yi wrote on 9/24/06 6:18 PM:
>
> > I think that automatic unpacking/repacking might not be
> > doable because of the possibility of different array
> > sizes, i.e. if I passed an array with length 10 as an
> > arg and then an array with length 8 as another arg, then
> > another array with length 5 as the output arg, it's not
> quite clear what is supposed to happen.  It think that
> > signal arrays could be done and the optional
> > initialization value makes great sense, but
> > auto-unpacking/repacking seems like it would have too
> many variables to make it clearly intuitive what's going
> > to happen, and it might actually be clearer just to
> > iterate in a couple of for loops to see what's really
> > going on in user-code than to take it on faith what's
> happening.
>
> > On 9/24/06, matt ingalls  wrote:
> >> 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
> >>
>
>
> ----------------------------------------------------------
> --------------- 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

I am not opposed to having array indexes start with 0.  However, I think a
very strong case can be made for having them start at 1.

I we think of signal arrays as multi-channel signals, then the "natural" way
to number them is starting with 1.  This is how Csound does so in other
contexts and all of the signal processing software I have seen calls quad
channels 1,2,3,4.

Also, when you think about passing in a pfield constant for the number of
channels or number of opcodes in an array (using my proposed syntax),
ainput[1:p5] is easier to write and understand IMHO than ainput[0:p5-1].
This is especially true I think for ainput[1:nchnls] versus
ainput[0:nchnls-1].

So, 1 would be my preference, but I can live with 0.

Anthony

matt ingalls wrote on 9/28/06 5:03 PM:

> f-table indexing starts with index 0, i would assume arrays should as
> well..
> 
> which, btw, it might be interesting to see if there is a solution to all
> this to be done with ftables -- they are basically an array after all..
> 
> or, could the crappy things i find about ftables
> ( 1-dimensional, power-of-2 size requirement, no "named" tables,
> no default common/standard table shapes, etc.. )
> be solved by creating a new "array" variable type?
> 
> On Sep 28, 2006, at 1:32 PM, Victor Lazzarini wrote:
> 
>> a little bit is that arrays indexes start at 1 rather than
>> 0. Would that be an issue? I can't think at the
>> moment if it goes against other conventions in
>> Csound, or is the C in me thinking...


-------------------------------------------------------------------------
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