Well, I'd say 'type' does say a lot, but then again I am thinking in terms of programming. (Side note: Having the type of variable be determined by first letter (or two for global vars) was certainly a awkward when working on the new parser!). It doesn't help IMO that i- and k- are technically the same in their type, but that the parser will limit their usage when hooking things up. (Another side note, one of the strange things I find about Csound is the mixing of initialization and performance times in the same code. Opcodes are like strange objects that take in both constructor arguments and performance time arguments at the same time. That that extends up to the instrument coding is a strange thing too IMO. I guess in the context of programming today it seems strange as objects as a concept is so common where constructors and methods are clearly defined, but this is all just my own opinion.) There's a lot that can happen with variables too that defy rate. One of the reasons I wrote the avarset/avarget was to read/write individuals samples from an a-var. In code for things like this, one generally would use a "k-rate loop" in csound code to read a value, process, then write the value back, up to ksmps in length. This allowed writing signal processing code in csound code in the same way as one would write it in C, also making it easy to port other C code to Csound. (I had used this when I worked on a port of James Beauchamp's SDS Trumpet a long while ago.) This is just an example of where the rate terminology caused some dissonance where k-vars are used as counters to do audio signal processing. So as far as I see it, we have sort of two clashing views, whether one is thinking on a higher musical level or if one is working on a lower technical level. When looking at VST audio code and seeing how it might be done in a language like Csound, I imagine thinking of types and such might be easier. When coming to Csound from a non-technical background, then thinking of rates may be easier. Maybe this isn't an either-or case but something we'll have to document in different ways depending on who's reading it. Would it be useful then to have the manual as-is but to append a section on a more technical view of Csound that could discuss the variables as types as well as how they are used in processing? We could direct users interested in more low-level signal processing to check out that documentation, while continuing to make the other documentation friendly for non-technical users. steven On Tue, Jan 13, 2009 at 5:15 PM, DavidW wrote: > > > On 14/01/2009, at 11:06 AM, Andres Cabrera wrote: >> Hi David, >> Sometimes the word pass is needed, but many times something like >> a-type or audio type will also be needed. >> > What problems with "type" do you see? > > Just that it doesn't say anything. rate might be wrong, (I've never > had a problem) but if it needs to be replaced they should be > descriptive. > The names of i, k and a rates have a history going back to music V at > least. > > if 'a rate' is not accessible to the user, then it makes sense to drop > public references to it. > Then we have initialisations and controls > > re 'types': there's bound to be already references to data types so > they'll have to be explained/distinguished anyway so why not go for a > descriptor label in the first place? > are you looking for a general term to cover constants, vars, instr. > defs (which unions or classes i guess)? > > D. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net