"rate" gives information - the variable, reminding one that things  
occur at different  rates
"type" is a redundancy, like "stuff" you don't get a clue from the  
name how it used.

For my $ it would be better to rename "krate" as "kontrolRate" and
irate as "instrumentRate" or some other suitable name that indicates  
what/when its accessed.
Dirtto for the other rates.....

DavidWorrall.

On 14/01/2009, at 8:54 AM, Oeyvind Brandtsegg wrote:

> I am probably missing something obvious, but I don't understand why
> the term "rate" is misleading.
> I frequently explain the difference between these variable types to my
> students in terms of their different update rates.
>
> Inherent in my previous sentence, I do agree that we speak of
> variables of different type, but "audio type" seems a bit cimbersome
> an expression to me. Maybe we could just call it "audio variable" ?
> Not sure.
>
> best,
> Oeyvind
>
> 2009/1/13 Andres Cabrera :
>> Hi all,
>>
>> On recent conversations with Steven, the idea came up to change the
>> documentation to remove terms like i-rate, k-rate and a-rate, since
>> they are somewhat misleading, and instead rewrite to use i-type,
>> k-type and a-type, and terms like perf-pass and init-pass.
>>
>> Opinions?
>>
>> Cheers,
>> Andrés


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

"pass" does make more sense. "type" has other uses/connotations too  
which it is prob. better to avoid.

D.


On 14/01/2009, at 10:52 AM, Andres Cabrera wrote:

> Hi Oeyvind,
> Rate is misleading as there is actually only a single rate in Csound:
> control rate. i-rate is not actually a rate, since it is not periodic,
> but occurs only on instrument initialization, and a-rate is not a rate
> either, but indicates a vector processed at k-rate.
>
> Talking in terms of passes is clearer, I think. You have init-passes
> and perf-passes.
>
> So i-, k- and a- are actually variable types. I guess audio type and
> audio variable could be interchangeable.
>
> Cheers,
> Andrés
>

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

On Wed, Jan 14, 2009 at 12:10 AM, Fons Adriaensen  wrote:
> On Tue, Jan 13, 2009 at 06:52:10PM -0500, Andres Cabrera wrote:
>
>> Rate is misleading as there is actually only a single rate in Csound:
>> control rate. i-rate is not actually a rate, since it is not periodic,
>> but occurs only on instrument initialization, and a-rate is not a rate
>> either, but indicates a vector processed at k-rate.
>
> That's an implementation detail, and irrelevant to a user.
> Conceptually, samples are generated at a-rate. The whole
> system behave 'as if'.

Until it doesn't, of course.  The fiction of the a-rate is a "leaky
abstraction" - that is, there are instances where a conceptual model
of an a-rate leads to csound code that doesn't work properly because
the actual implementation peaks through.  Sample delays are probably
the most common case of this, but I'm sure there are others.  It's
probably important when considering latency and real-time performance
as well.

I think it's better to use terminology that reflects the
implementation of control rate and audio vectors.  It's fine for users
to pretend there's an a-rate, but it's better if they understand when
and why that abstraction holds rather than treating it as a first
principle and later saying, "that's not really how it works, this is
what's actually going on."

John Lato

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

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

On 14/01/2009, at 1:16 PM, Steven Yi wrote:

> 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.
>
No arguments from me on this . My sense is to prioritise naming for  
clarity of coding - and then find/use aliases it they're too obscure  
at the users level. Indirection such as this costs very little these  
days.
The nomenclature has been inherited (in the non-OO sense) from the  
original music V (or earlier) code which was in Fortran (vII if I  
remember, but it could have been IV - Richard will know) in which  
variables of a particular type had to begin with a letter from a  
limited range (integers from i,j etc)
... That necessity went by the way with the translation to C. If I  
rememeber correctly, csound was derived from Music 4BF. However  my  
punchcard version was of Music V direct from Bell. Still find old  
cards as bookmarks!

> (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.)
>
yep - there was no OO in them days either. Opcode is a powerful idea  
though, What would it be replaced with?
It seems to me that what we're talking about is a major revision here  
- not incremental -  i.e. could take place parallel to current dev:  
"OOsound"? :-)

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

>> Rate is misleading as there is actually only a single rate in Csound:
>> control rate. i-rate is not actually a rate, since it is not periodic,
>> but occurs only on instrument initialization, and a-rate is not a rate
>> either, but indicates a vector processed at k-rate.
> 
> That's an implementation detail, and irrelevant to a user.
> Conceptually, samples are generated at a-rate. The whole
> system behave 'as if'.
> 
> IMHO the term 'rate' comes closest to what is relevant to a
> musical user. 'Type' is software engineering language, and
> I'd guess most Csound users are not software engineers, nor
> should they be expected to be.

+ 1

Stef


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

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

this would definitely be very useful IMHO.

Stef


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

+1 to Steven's suggestion of "signal".

It seems to apply to all different types of variables, it also makes
sense in terms of what I term the "implicit opcode loop", and I don't
think it introduces any false understandings.  It makes the audio
vector a true implementation detail which is orthogonal to
expectations provided by the user's understanding of the meaning (of
signal).

I personally think of
i - initialization time
k - kontrol rate
a - audio signal

but that's probably too idiosyncratic to appear in the manual.

John Lato

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

I still like k-rate and a-rate
==John ffitch

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

This makes the most sense to me.  Th use of "-rate" for everything was 
confusing to me for quite a while until I simply internalized those 
names by rote.  It's always better, IMHO, to use the clearest, least 
ambiguous terminology one can.

- Dave

John Lato wrote:
> +1 to Steven's suggestion of "signal".
> 
> It seems to apply to all different types of variables, it also makes
> sense in terms of what I term the "implicit opcode loop", and I don't
> think it introduces any false understandings.  It makes the audio
> vector a true implementation detail which is orthogonal to
> expectations provided by the user's understanding of the meaning (of
> signal).
> 
> I personally think of
> i - initialization time
> k - kontrol rate
> a - audio signal
> 
> but that's probably too idiosyncratic to appear in the manual.
> 
> John Lato

-- 
~DaveSeidel = [
   http://mysterybear.net,
   http://daveseidel.tumblr.com,
   http://twitter.com/DaveSeidel
];


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net