"Jumping to" optional arguments

[spatz0r]

Hello all,

I was wondering if I could submit an idea I had for modifying the syntax of CSound that has recieved the approval of Dr. Boulanger. I have provided a small and very simple example exercising the concept I wish to  demonstrate using an opcode (randh) that I know in my month and a half use of the language.

Suda_optional_argument_test.csd

I noticed in the course of experimenting that I had encountered a couple of situations when answering an opcode's arguments where I wished to modify the value of an optional argument that is mutually exclusive with the things that preceded it, but that there was no way to "skip" to that specific optional argument.

In most cases, the arguments that precede the pertinent one were ones that assume default values if they are not specified.

With regards to the .csd I've attached, one would enter some sort of convention (Dr. B suggested "z" or "da" or something of the sort instead of a number) in place of the preceding optional arguments, so that the new line of code would change from
krand randh 1000, 8, 0.5, 0, 200
to
krand randh 1000, 8, z, z, 200
Since 0.5 and 0 were not modified from their default values.

This is of course inapplicable when optional arguments are dependent on each other and contextually inclusive (such as iparm1 and iparm2 in a pluck), but you could see where this would start making sense when you start dealing with opcodes with slightly larger sets of arguments and optional arguments, such as granule or really any granular opcode, where maybe you'd want to modify "ipitch4" but not "iseed", "ipitch1," or "ipitch3."

This also could apply to mandatory arguments in opcodes that may have default values anyhow.

-Nick Suda
[e-mail]
[phone]
Renton, WA/Boston, MA

[peiman]

Or another way to do it is like in SC3 (something like this):

krand randh 1000, 8, ioffset:200

It saves the trouble of having to type extra letters for the default values.

 

Best,

Peiman

On 23 Oct 2009, at 23:00, spatz0r wrote:

Hello all,

I was wondering if I could submit an idea I had for modifying the syntax of
CSound that has recieved the approval of Dr. Boulanger. I have provided a
small and very simple example exercising the concept I wish to  demonstrate
using an opcode (randh) that I know in my month and a half use of the
language.

http://www.nabble.com/file/p26033839/Suda_optional_argument_test.csd
Suda_optional_argument_test.csd

I noticed in the course of experimenting that I had encountered a couple of
situations when answering an opcode's arguments where I wished to modify the
value of an optional argument that is mutually exclusive with the things
that preceded it, but that there was no way to "skip" to that specific
optional argument.

In most cases, the arguments that precede the pertinent one were ones that
assume default values if they are not specified.

With regards to the .csd I've attached, one would enter some sort of
convention (Dr. B suggested "z" or "da" or something of the sort instead of
a number) in place of the preceding optional arguments, so that the new line
of code would change from
krand randh 1000, 8, 0.5, 0, 200
to
krand randh 1000, 8, z, z, 200
Since 0.5 and 0 were not modified from their default values.

This is of course inapplicable when optional arguments are dependent on each
other and contextually inclusive (such as iparm1 and iparm2 in a pluck), but
you could see where this would start making sense when you start dealing
with opcodes with slightly larger sets of arguments and optional arguments,
such as granule or really any granular opcode, where maybe you'd want to
modify "ipitch4" but not "iseed", "ipitch1," or "ipitch3."

This also could apply to mandatory arguments in opcodes that may have
default values anyhow.

-Nick Suda
nick.suda@...
[phone]
Renton, WA/Boston, MA
--
View this message in context: http://www.nabble.com/%22Jumping-to%22-optional-arguments-tp26033839p26033839.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[richarddobson]

spatz0r wrote:
..
> With regards to the .csd I've attached, one would enter some sort of
> convention (Dr. B suggested "z" or "da" or something of the sort instead of
> a number) in place of the preceding optional arguments, so that the new line
> of code would change from
> krand randh 1000, 8, 0.5, 0, 200
> to
> krand randh 1000, 8, z, z, 200
> Since 0.5 and 0 were not modified from their default values.
>

Just considering this in general terms as a language issue: the
arguments are already comma-separated, so that in principle one need
simply run the commas together (with or without whitespace) to indicate
"use the default":

krand randh 1000, 8,,, 200

Possibly the implementation would be easier using placeholder variable
names as suggested; I suppose (recalling standard score notation for a
carry) that one possibility would be to use a point, or some other
non-alphabetical character:

krand randh 1000, 8,.,., 200

Whether this ias actually more self-documenting than the existing
solution is something to be argued, probably.


Richard Dobson


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel