[Linux] Re: [Sc-devel] freq vs kfreq docmentation -> 3.1

[Nick Collins]

I've fixed and committed the change to the Formant help file. User  
authentication now proceeding smoothly ; )

I'm not so sure about any variant of:
(only updated at control rate)

Because that would seem to require a longer explanation of how you  
can use an audio rate input, but it will only be sampled at the  
beginning of a block, etc. (control rate) seems succinct enough;  
experts can freely throw in .ar things as they wish, but it's  
probably not great practice; for beginners, maybe too much  
information is confusing, and we don't want documentation bloat?

A bit of a tradeoff, maybe...

best,
N



On 22 Oct 2007, at 15:40, Fredrik Olofsson wrote:

> hi scott,
> as you're free to plug audiorate things into kargs, couldn't the  
> 'note' you added be a little bit more elaborate?  something like...
> freq - Frequency in Hertz (note: only updated at control rate).
>
> btw, there are kargs also in Formant help.
> _f
>
> Am 20.10.2007 um 17:08 schrieb Scott Wilson:
>
>>
>> On 20 Oct 2007, at 15:46, Nick Collins wrote:
>>
>>> Hi Tom,
>>>
>>> Checking the UGen source, I believe the issue is that you can  
>>> only plug in k rate UGens to control frequency. I agree that it's  
>>> confusing for students though and shows inconsistent argument  
>>> naming! There are many other UGens where the allowed rate of an  
>>> input is just mentioned under the description of each argument.  
>>> So the kfreqs can be removed, and a note added to the help file  
>>> under the freq argument to that effect.
>>
>> Hey Nick,
>>
>> I've committed these, and added the notes. I think kargs and iargs  
>> should be renamed as this has been applied inconsistently, and IAC  
>> reminds one unpleasantly of CSound. (ouch! :-p)
>>
>>>
>>> I'm happy to help with help file updating next Weds/Thurs once  
>>> free of immediate deadlines. I've added the kfreq thing to my  
>>> growing list. Scott, also happy to help with other files like  
>>> Object;
>>
>> This would be very cool.
>>
>>> I'd like to rationalise the main help as well, perhaps adding a  
>>> quick start up guide + platform specific READMEs as the most  
>>> obvious link to direct anyone new to the program to the essential  
>>> info for their platform.
>>
>> Yes, I think it should be drastically simplified, and mostly just  
>> point to Dan's new help browser, and some basic documentation and  
>> tutorials. At issue is if Marije has done anything with the  
>> categories yet. I think for the moment it could just point to  
>> Help.all or Help.dumpTree for linux non-GUI users.
>>
>> IAC if you'd like to collaborate on that it would be great to have  
>> it for 3.1!
>>
>> I have one other doc issue, but I'll raise it in another thread.
>>
>> S.
>
>
>   #|
>      fredrikolofsson.com     klippav.org     musicalfieldsforever.com
>   |#
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel at create.ucsb.edu
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel


		
___________________________________________________________ 
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal 
http://uk.docs.yahoo.com/nowyoucan.html