Hello again fellow Csounders!

I am a Csound newbie, studying with Dr. Boulanger at Berklee for the past two months. Over the course of being introduced to this language I came up with several ideas that Dr. B liked enough that he encouraged me to post them both on the Csound Mailing List as well as the cSounds.com forum in order to promote a conversation about their possible implementation. I had three ideas, one regarding what I'm about to speak of, one regarding skipping optional arguments, and one involving additions to the syntax of the Advance (a) statement. If you haven't seen either of the other two, it would be awesome if you took a look at those as well. :)

When I first mentioned this next idea to Dr. B, he added that this is not by any means necessarily an addition to Csound; it can be (and is, in many cases) a facet of the front-end you run for the language. The thread I put up on the Mailing List got many responses, most of them related to Python scripts that rectify my suggestion in Python-enabled front-ends, as well as an acknowledgement from Andres Cabrera that QuteCSound to a limited extent already has this function.

Therefore I will arbitrate that perhaps it could be considered at the level of the language itself, so that a "genericization" of the language could be taught to first-week Csounders regardless of the front-end being used.

Copied from my Mailing List post:

(excerpt from email)
Dr. B suggested from a conversation we've been having that it would at the very least be a useful didactic addition to the language to reformat the structure of outputs and arguments to generically "auto-fill" typical generators with "default" values. Whether this could be implemented at the CSound level by creating a new opcode for each instrument that performs this function of whether it would be implemented at the QuteCSound etc. level for a specific ASCII combination the program looks for to intelligently replace values remains to be seen.

For example, in my opinion the simplest thing you can do in a synthesis system is try to procure an A440 sine as a means of feeling your way around. This is the first thing we learn in CSound:

asig oscil 10000 440 1

(paired with f1 0 4096 10 1 and i1 0 6)

Maybe we could do this as a way for beginners to remove distracting numbers entirely and see only the output and arguments generically:

xxx oscil xxx xxx xxx

Which, at the CSound level in combination with an opcode that interprets "xxx"s or at the frontend level with a portion built in that scans for "xxx"s, renders as

asig oscil 10000 440 1

by default.

Not only does this have didactic prospects, it has advantages for demoing opcodes one is unfamiliar with, making generic every opcode except one and then adjusting them back and forth one at a time until a greater sense of its function is established. Also, for managing more complex opcodes such as ones with over 20 arguments.

(end of excerpt)

I get excited by the prospects of this replacement for the absolute beginner. I think of the possibly regained withdrawals from the Berklee class due to an even gentler intro!

A new Etude 1 would essentially look like the oscil opcode with a ton of xxx's, and a note list of hard-coded values gradually replacing each xxx. Then a new Etude 2 could bring in p-fields without it looking as "scary" (at least it did for me).

I want to know if you guys think this is a worthwhile at the level of the language itself. I appreciate all comments and suggestions you have to offer.

Thanks!

-Nick Suda
Renton, WA
nick.suda@gmail.com