I noticed that cpspch and cpsoct use a lookup table for converting to cps.
This table only allows 8192 divisions per octave and it truncates the index
to the table instead of rounding the index or interpolating the table
values.  This can lead to some small but possibly significant inaccuracies
in common pitches (especially since 8192 is not divisible by 12).

For example, the difference between cpspch(11.07) and
cpspch(11.00)*(2^(7/12)) is .176 Hz resulting in one beat almost every 5
seconds when played together.  The example below illustrates the effects on
sine tones and a more complex tone that should have a static timbre.

Small imprecisions are also present in pitch and other calculations for
MYFLT == double due to certain constants being defined with too few digits:

#define ONEPT           1.02197486              /* A440 tuning factor */
#define LOG10D20        0.11512925              /* for db to ampfac   */
#define LOGTWO      (0.69314718056)


Does anyone think this should be changed ?

Anthony




instr 1
    ifreq  =        cpspch(11.07)
           print    ifreq
      
    aosc   poscil3  4000, ifreq, p4
           out      aosc
endin

instr 2
    ifreq  =        cpspch(11.00) * 1.49830707688  ; 2 ^ (7/12)
           print    ifreq
      
    aosc   poscil3  4000, ifreq, p4
           out      aosc
endin



f1 0 65536 10 1
f2 0 65536 10 1 1 1 1 1 1

i1 0 10 1
i2 0 10 1

i1 12 10 2
i2 12 10 2
e





-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The same issue is to be applied to powoftwo, octave, semitone and cent 
opcodes... All of them are based on table lookup instead of direct power 
calculation.

Gabriel

Anthony Kozar ha scritto:
> I noticed that cpspch and cpsoct use a lookup table for converting to cps.
> This table only allows 8192 divisions per octave and it truncates the index
> to the table instead of rounding the index or interpolating the table
> values.  This can lead to some small but possibly significant inaccuracies
> in common pitches (especially since 8192 is not divisible by 12).
>
> For example, the difference between cpspch(11.07) and
> cpspch(11.00)*(2^(7/12)) is .176 Hz resulting in one beat almost every 5
> seconds when played together.  The example below illustrates the effects on
> sine tones and a more complex tone that should have a static timbre.
>
> Small imprecisions are also present in pitch and other calculations for
> MYFLT == double due to certain constants being defined with too few digits:
>
> #define ONEPT           1.02197486              /* A440 tuning factor */
> #define LOG10D20        0.11512925              /* for db to ampfac   */
> #define LOGTWO      (0.69314718056)
>
>
> Does anyone think this should be changed ?
>
> Anthony
>
> 
> 
>
> instr 1
>     ifreq  =        cpspch(11.07)
>            print    ifreq
>       
>     aosc   poscil3  4000, ifreq, p4
>            out      aosc
> endin
>
> instr 2
>     ifreq  =        cpspch(11.00) * 1.49830707688  ; 2 ^ (7/12)
>            print    ifreq
>       
>     aosc   poscil3  4000, ifreq, p4
>            out      aosc
> endin
>
> 
> 
> f1 0 65536 10 1
> f2 0 65536 10 1 1 1 1 1 1
>
> i1 0 10 1
> i2 0 10 1
>
> i1 12 10 2
> i2 12 10 2
> e
>
> 
> 
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Gabriel Maldonado wrote:
> The same issue is to be applied to powoftwo, octave, semitone and cent 
> opcodes... All of them are based on table lookup instead of direct power 
> calculation.
> 

And the speedup frequently is important. So how about a global level 
(instr 0) opcode called simply, for example, "precision = x" where if x 
= 0 (the default) the fast table versions are used, if x = 1 the 
accurate slow ones are used. Or vice versa...

Richard Dobson


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Perhaps here is where someone's earlier suggestion about additional
arguments to functions could be really helpful, although it will take
some work up front to implement it.

I think the default form "powoftwo(x)" should be the real, most accurate
calculation - because this is what people coming from diverse musical
and programming backgrounds will expect.  It says it gives you 2 to the
x, so it should give you 2 to the x.

But an optional second argument could make it access the lookup table
instead - "powoftwo(x,1)" - so those people optimizing for speed (more
likely to "know what they're doing") have it at their disposal without
further cluttering an already cluttered namespace.

Yours truly,
David

Richard Dobson wrote:
> Gabriel Maldonado wrote:
>> The same issue is to be applied to powoftwo, octave, semitone and cent 
>> opcodes... All of them are based on table lookup instead of direct power 
>> calculation.
>>
> 
> And the speedup frequently is important. So how about a global level 
> (instr 0) opcode called simply, for example, "precision = x" where if x 
> = 0 (the default) the fast table versions are used, if x = 1 the 
> accurate slow ones are used. Or vice versa...
> 
> Richard Dobson
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This sounds like an excellent solution.

-dB

On Aug 24, 2007, at 11:25 AM, Richard Dobson wrote:

> Gabriel Maldonado wrote:
>> The same issue is to be applied to powoftwo, octave, semitone and  
>> cent
>> opcodes... All of them are based on table lookup instead of direct  
>> power
>> calculation.
>>
>
> And the speedup frequently is important. So how about a global level
> (instr 0) opcode called simply, for example, "precision = x" where  
> if x
> = 0 (the default) the fast table versions are used, if x = 1 the
> accurate slow ones are used. Or vice versa...
>
> Richard Dobson
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Function-style opcodes with more than one argument (like powoftwo(x,1) ) 
would be very very welcome.... Does the present Csound parser allow it, 
or are there plans to do do that in the (near) future...?

Gab

David Ogborn ha scritto:
>
> But an optional second argument could make it access the lookup table
> instead - "powoftwo(x,1)" - so those people optimizing for speed (more
> likely to "know what they're doing") have it at their disposal without
> further cluttering an already cluttered namespace.
>   
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks Steven,
I believe that allowing multiple arguments into a function would be a 
major feature of the new parser.
A new way to write orchestra would rise... For example, the two lines:

klfo   oscili   20, 5, 1
a1      oscili 20000, klfo, 1

could be merged into a single line:

a1   oscili 20000, oscili(20,5,1), 1

But there is an ambiguity, that is the output rate of the function 
oscili(20,5,1): will it be k or a-rate? This will be applied to opcodes 
that have identical name for different rates, such as oscili. To solve 
this ambiguity, I suggest that in case of ambiguity, such as in this 
case, the csound parser should choose the highest available rate (i.e. 
a-rate). If one wants to use the k-rate version of oscili, he can choose 
to the first version in 2 lines of code, or to explicitly call the 
actual name of the opcode required, with the extension:

a1   oscili 20000, oscili.kk(20,5,1), 1

gabriel

Steven Yi ha scritto:
> Hi Gabriel,
>
> The current parser (old or new flex/bison one) does not currently
> support multiple argument functions.  Last I remember there were some
> clear steps in getting it to happen in the new parser but I haven't
> delved into the new parser code in a long time.  (Pretty much the list
> of things that need to be fixed has been the same since January)
>
> steven
>
>
> On 8/25/07, Gabriel Maldonado  wrote:
>   
>> Function-style opcodes with more than one argument (like powoftwo(x,1) )
>> would be very very welcome.... Does the present Csound parser allow it,
>> or are there plans to do do that in the (near) future...?
>>
>> Gab
>>
>> David Ogborn ha scritto:
>>     
>>> But an optional second argument could make it access the lookup table
>>> instead - "powoftwo(x,1)" - so those people optimizing for speed (more
>>> likely to "know what they're doing") have it at their disposal without
>>> further cluttering an already cluttered namespace.
>>>
>>>
>>>       
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>     
>
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I would certainly welcome many of these sorts of additions to Csound's
syntax.  For fun, I typed up a simple instrument with vibrato and an amp
envelope.  I then retyped them as they would look in a theoretical redesign
of the syntax based on the following three premises:

1) Functions could support multiple parameters
2) All opcodes could act as functions
3) Ambiguity is resolved by specifying .i, .k, or .a to the function


; Simple Synth with pitch vibrato and an amp envelope
instr 1
	idur = p3
	iamp = p4
	ipch = cpspch( p5 )

	kline linseg 0, 0.1, iamp, idur - 0.1, 0
	kvib  oscil  0.5, 8, 1
	kvib  =      ( kvib + 0.5 ) * ipch * 0.1
	aosc  oscil  kline, kvib + ipch, 1
	
	out aosc
endin


; Retyped with the theoretical function based syntax
instr 2
	idur = p3
	iamp = p4
	ipch = cpspch( p5 )
	
	kline = linseg.k( 0, 0.1, iamp, idur - 0.1, 0 )
	kvib  = ( oscil.k( 0.5, 8, 1 ) + 0.5 ) * ipch * 0.1
	
	out( oscil.a( kline, kvib + ipch, 1 ) )
endin


; An extreme example to show that an entire synthesizer could
; exist as a single line in the orchestra.
instr 3
	out( oscil.a(linseg.k(0, 0.1, p4, p3 - 0.1, 0), (oscil.k(0.5, 8, 1) + 0.5)
* cpspch.i(p5) * 0.1 + cpspch.i(p5), 1) )
endin


To my eyes, instr 2 looks the cleanest of the three examples.  A function
based syntax may also be easier to read for newcomers whom have experience
with languages such as C, Python, Perl, etc.  I also think this theoretical
syntax could co-exist with the current syntax, maintaining full backwards
capabilities.

My two cents.

Best, 
Jake 

---- 
The Csound Blog 
http://www.thumbuki.com/csound/blog  




Greg Thompson-2 wrote:
> 
> SuperCollider solves the ambiguity by appending .ar or .kr such as -  
> of course its based on an object oriented language, but still, it  
> allows for the possibility of what you're proposing.
> 
> SinOsc.ar(freq, 0, amp)
> Pan2.ar(SinOsc.ar(freq), pan)
> 
> or
> 
> var freq = 220, e, e1;
> e = Env.linen(0.02, 1, 2.1);
> 		e1 = Env.perc(0.52, 1.5, 370);
> 		Formant.ar(freq, EnvGen.kr(e1) + 500, 50 , EnvGen.kr(e))
> 
> greg
> 

-- 
View this message in context: http://www.nabble.com/Inaccuracies-in-cpspch-and-cpsoct-tf4313733.html#a12347661
Sent from the Csound - Dev mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net