Hi Steven,

Keep us posted on the changes to support this. I would personally love to see automatic expansion of arrays  into parallel opcodes, so you can instantiate multiple oscillators from an array. The output would naturally need to be an array.

I think this would also be a great addition to parcs as this is guaranteed to be parallelizable.

Cheers,
Andres

Hi,

Thinking about this, the array grammar should do expansion only if the
opcode argument is not itself an a array, that way you could have an
opcode like:

asig oscilarr 0.5, 440, 0, Array

where array is the wavetable for the oscillator.
However, if you do:

asig oscilarr 0.5, Afreqs, 0, Array

Then you would have several parallel oscillators with the frequencies
stored in Afreqs oscillating with the wavetable stored in Array.

Cheers,
Andrés

On Fri, Nov 9, 2012 at 1:45 PM, Steven Yi  wrote:
> Hi All,
>
> I was looking into implementing generic arrays (arrays of any type) to
> replace t-vars.  Looking at the grammar, it seems to me that we can simplify
> the grammar and remove things like T_IDENT_I, T_IDENT_K, etc. and just use
> T_IDENT.  Essentially, it would make the grammar more generic for parsing,
> and it would move type checking out to a later phase.  So, the parsing phase
> would allow:
>
> fsig oscil fsig2, fsig[45], 123, a234
>
> as it would would be valid for having identifierList-opcode-identifierList;
> type checking and validation phases would then catch this as an error due to
> invalid types for oscil.
>
> I took a look at a C grammar and Java grammar for some inspirations:
>
> http://www.quut.com/c/ANSI-C-grammar-y.html
> http://www.cs.dartmouth.edu/~mckeeman/cs118/notation/java11.html
>
> Also, I think we might be able to simply label in the grammar if we only
> make label be "label:".  We use label for goto in the grammar, but I think
> we could just have it accept "goto T_IDENT".  Then in the checking, it could
> do a lookup of labels with that identifier to see if it exists.
>
> Anyways, thought I'd mention that I'm in this area of code and will be
> looking into restructuring some things in the grammar.  I'm also going to do
> some analysis on the parser/compiler stages so that things are more clear,
> i.e. there's type checking only in a single function.
>
> Thanks!
> steven
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists

Hi,

I think this is an interesting opinion. Can you elaborate on the kind
of problems it created?

I think that because Csound is more strongly type that SC, this would
not be a problem as the parser would force the right types at the
output:

asig oscil 0.5, Afreqs, 0

will produce a type error, as the output must be an array.

However, another option would be to make automatic expansion optional
and disabled by default. So

Asigs oscil 0.5, Afreqs, 0

would produce an error, but:

Asigs oscil 0.5, ||Afreqs, 0

will do the array expansion into parallel instances of the opcode.
(I'm not sure about this notation, but that's the idea...)

Cheers,
Andrés

On Wed, Nov 14, 2012 at 5:11 PM, Justin Smith  wrote:
> If I'm the only one that feels this way, feel free to ignore this, but I
> found automatic array expansion one of the biggest sources of unexpected and
> erroneous behavior when I was using SuperCollider, and I would actually
> prefer that this feature not be present in csound.
>
>
> On Wed, Nov 14, 2012 at 5:02 PM, Andres Cabrera 
> wrote:
>>
>> Hi,
>>
>> Thinking about this, the array grammar should do expansion only if the
>> opcode argument is not itself an a array, that way you could have an
>> opcode like:
>>
>> asig oscilarr 0.5, 440, 0, Array
>>
>> where array is the wavetable for the oscillator.
>> However, if you do:
>>
>> asig oscilarr 0.5, Afreqs, 0, Array
>>
>> Then you would have several parallel oscillators with the frequencies
>> stored in Afreqs oscillating with the wavetable stored in Array.
>>
>> Cheers,
>> Andrés
>>
>> On Fri, Nov 9, 2012 at 1:45 PM, Steven Yi  wrote:
>> > Hi All,
>> >
>> > I was looking into implementing generic arrays (arrays of any type) to
>> > replace t-vars.  Looking at the grammar, it seems to me that we can
>> > simplify
>> > the grammar and remove things like T_IDENT_I, T_IDENT_K, etc. and just
>> > use
>> > T_IDENT.  Essentially, it would make the grammar more generic for
>> > parsing,
>> > and it would move type checking out to a later phase.  So, the parsing
>> > phase
>> > would allow:
>> >
>> > fsig oscil fsig2, fsig[45], 123, a234
>> >
>> > as it would would be valid for having
>> > identifierList-opcode-identifierList;
>> > type checking and validation phases would then catch this as an error
>> > due to
>> > invalid types for oscil.
>> >
>> > I took a look at a C grammar and Java grammar for some inspirations:
>> >
>> > http://www.quut.com/c/ANSI-C-grammar-y.html
>> > http://www.cs.dartmouth.edu/~mckeeman/cs118/notation/java11.html
>> >
>> > Also, I think we might be able to simply label in the grammar if we only
>> > make label be "label:".  We use label for goto in the grammar, but I
>> > think
>> > we could just have it accept "goto T_IDENT".  Then in the checking, it
>> > could
>> > do a lookup of labels with that identifier to see if it exists.
>> >
>> > Anyways, thought I'd mention that I'm in this area of code and will be
>> > looking into restructuring some things in the grammar.  I'm also going
>> > to do
>> > some analysis on the parser/compiler stages so that things are more
>> > clear,
>> > i.e. there's type checking only in a single function.
>> >
>> > Thanks!
>> > steven
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Everyone hates slow websites. So do we.
>> > Make your web apps faster with AppDynamics
>> > Download AppDynamics Lite for free today:
>> > http://p.sf.net/sfu/appdyn_d2d_nov
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>>
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinf

Thanks for elaborating. I think csound's strong typing is an advantage here, as:
asig distort oscil(0.5, Afreq, 0), 500

Would produce a syntax error because the output has to be an array of audio signals. So there is automatic expansion, but not automatic mix down to avoid these issues.

Do you think this would be enough?

I have also proposed typed arrays, whose contents must be of a particular type, to help enforce type checking. See:

http://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays

Cheers,
Andres