This would mean re-writing a load of opcodes. I think it's
OK
to have this kind of requirement. Even with so-called
'modern'
synthesis systems (such as supercollider), it exists
(AFAIK).

But of course, you can have opcodes that don't need such
thing. For these any size tables can be used.

What I think would be useful is to allow any size tables to
be created (I don't think this is possible for all GENS)
with
any GEN.

Victor

>
> is the power-of-2 function table size requirement gone for
> csound5?
>
> if so, can you PLEASE remove it?  the optimization it
> gives is far   less important than
> the convenience of specifying your own size.
>
> ideally, it would be better to have "deferred" size for
> most GEN   routines --
> just give a '0' as the size for most GENS and let the
> routine   calculate the size.
>
> multichannel tables expanded beyond loscil family would be
> nice as   well..
>
> Thanks,
> Matt;
> ________________________
>            matt  ingalls
> http://sonomatics.com
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep
> through log files for problems?  Stop!  Download the new
> AJAX search engine that makes searching your log files as
> easy as surfing the  web.  DOWNLOAD SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&
dat=121642
> _______________________________________________
> 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. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I can see where Matt's coming from ...

Personally I would like to see only the table opcode able to accept 
table size of deferred length, as I can see the potential problems in 
allowing such behavior on the FFT GEN routines, etc.

For example




sr		=	48000
ksmps	=	64
nchnls	=	2

#define	FILE	# "/loops/dl_break0.aif" #

itmp		ftgen	1, 0, 0, 1, $FILE., 0, 4, 0
;itmp		ftgen	1, 0, 131072, 1, $FILE., 0, 4, 0

		instr	1

itabsz	filelen	$FILE.

andx	phasor	(1 / itabsz)
andx	=	andx * (itabsz * sr)
a1	table	andx, 1
a1	=	a1 * 32767

	outs	a1, a1

		endin



i1	0	10

e




On Jan 22, 2006, at 3:05 PM, Victor Lazzarini wrote:

> This would mean re-writing a load of opcodes. I think it's
> OK
> to have this kind of requirement. Even with so-called
> 'modern'
> synthesis systems (such as supercollider), it exists
> (AFAIK).
>
> But of course, you can have opcodes that don't need such
> thing. For these any size tables can be used.
>
> What I think would be useful is to allow any size tables to
> be created (I don't think this is possible for all GENS)
> with
> any GEN.
>
> Victor
>
>>
>> is the power-of-2 function table size requirement gone for
>> csound5?
>>
>> if so, can you PLEASE remove it?  the optimization it
>> gives is far   less important than
>> the convenience of specifying your own size.
>>
>> ideally, it would be better to have "deferred" size for
>> most GEN   routines --
>> just give a '0' as the size for most GENS and let the
>> routine   calculate the size.
>>
>> multichannel tables expanded beyond loscil family would be
>> nice as   well..
>>
>> Thanks,
>> Matt;
>> ________________________
>>            matt  ingalls
>> http://sonomatics.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Jan 22, 2006, at 12:05 PM, Victor Lazzarini wrote:

> This would mean re-writing a load of opcodes. I think it's
> OK

is that really true?  when i looked into this [ about 5 years ago! ]
all i found was some bit-wise operations on index increments for
oscillators and stuff -- it would be no big deal to replace the bit-wise
stuff with a modulo or  if statement?


>
> What I think would be useful is to allow any size tables to
> be created (I don't think this is possible for all GENS)

isn't that what i just said?

Matt;
________________________
           matt  ingalls
http://sonomatics.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Jan 23, 2006, at 12:42 PM, Istvan Varga wrote:

> On Monday 23 January 2006 20:20, Matt Ingalls wrote:
>
>> is that really true?  when i looked into this [ about 5 years ago! ]
>> all i found was some bit-wise operations on index increments for
>> oscillators and stuff -- it would be no big deal to replace the  
>> bit-wise
>> stuff with a modulo or  if statement?
>
> Simply replacing a & with a % is not enough, as the latter cannot

as we say in california, "duh!"

> deal with negative numbers correctly, so you need an additional
> if statement to fix that. Also, a % is much slower than a &.

how much? i seriously doubt it's worth the speed gain..

> An if statement is again not enough, as you need at least two to
> wrap negative numbers, and more to deal with the possibility of
> a very large index.
> In any case, using the & operator is the simplest and fastest
> way to wrap any integer value to a 0..N-1 range, as long as
> N is an integer power of two.

but from the user-end it is really inconvenient, and then you have
wasted memory when using large tables.

> Additionally, more changes are needed to clean up any tricky code
> that assumes in some (often non-obvious) way a power of two or at
> least even table size. There are many possibilities for introducing
> bugs, something that is best avoided when a release is just about
> to be made.

well mark it up for the next version then..

IMO, the GENERAL case
should be opcodes that do not expect power-of-2, you can always create
some special optimized opcodes that require power-of-2!

Matt;
________________________
           matt  ingalls
http://sonomatics.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote:

> On Monday 23 January 2006 21:56, Matt Ingalls wrote:
> 
> 
>>well mark it up for the next version then..
> 
> 
> That sounds more reasonable. While I still do not really like
> the idea of changing all opcodes, there are cases (mostly when
> wrapping is not needed) where the power of two limitation can
> be removed easily without any slowdown or major changes.
> 

The issue that would have to be addressed (and whcih I have always seen as the 
main obstacle to the proposed changes) is indeed the definition of the guard 
point, on which many opcodes rely. In the current scheme, the contents of the 
opcode are indicated by the table size being either a pow_of_2 or pow_of_2+1, 
relying on the special significance of the pow_of_2 value.

How does a user indicate the guard point when using a non power-of two size?  As 
soon as this is allowed, 1024 and 1025 cease to have their "special" meanings 
(i.e. both indicate a 1024 table, with different guardpoint contents); one might 
expect 1025 to mean literally a table size of 1025, PLUS a guard point  - the 
fgen score statement would seem to need to be revised to include an explicit 
field to define it. Eliminating all use of guard points is surely not the end 
goal of all this?  That would slow down a lot of opcodes! To say nothing of 
breaking existing scores.


Richard Dobson




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I don't think we should change anything. We can make the oscillators
that use floating-point maths free of the power-of-two requirement, as
well as any other opcode that really does not need that. As far as
guard-points are concerned, a possibility is to implement them in the
opcode and have an extra optional parameter to define them, when the
table is not power-of-two.

Victor

At 23:08 23/01/2006, you wrote:
>Istvan Varga wrote:
>
>>On Monday 23 January 2006 21:56, Matt Ingalls wrote:
>>
>>>well mark it up for the next version then..
>>
>>That sounds more reasonable. While I still do not really like
>>the idea of changing all opcodes, there are cases (mostly when
>>wrapping is not needed) where the power of two limitation can
>>be removed easily without any slowdown or major changes.
>
>The issue that would have to be addressed (and whcih I have always seen as 
>the main obstacle to the proposed changes) is indeed the definition of the 
>guard point, on which many opcodes rely. In the current scheme, the 
>contents of the opcode are indicated by the table size being either a 
>pow_of_2 or pow_of_2+1, relying on the special significance of the 
>pow_of_2 value.
>
>How does a user indicate the guard point when using a non power-of two 
>size?  As soon as this is allowed, 1024 and 1025 cease to have their 
>"special" meanings (i.e. both indicate a 1024 table, with different 
>guardpoint contents); one might expect 1025 to mean literally a table size 
>of 1025, PLUS a guard point  - the fgen score statement would seem to need 
>to be revised to include an explicit field to define it. Eliminating all 
>use of guard points is surely not the end goal of all this?  That would 
>slow down a lot of opcodes! To say nothing of breaking existing scores.
>
>
>Richard Dobson
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote:

> On Tuesday 24 January 2006 00:08, Richard Dobson wrote:
> 
> 
>>The issue that would have to be addressed (and whcih I have always seen as the 
>>main obstacle to the proposed changes) is indeed the definition of the guard 
>>point, on which many opcodes rely. In the current scheme, the contents of the 
>>opcode are indicated by the table size being either a pow_of_2 or pow_of_2+1, 
>>relying on the special significance of the pow_of_2 value.
> 
> 
> Probably that is why the non-power of two table sizes are specified
> as negative numbers. In this mode, the size always includes the guard
> point, like in the pow_of_2+1 case above. A p3 of -101 means 100 samples
> and a guard point which is not copied from sample 0.
> 

This is OK if the reduced flexibility compared to the standard system is 
accepted. That is to say, it only supports the extension" form of guard point. 
It does not therefore form a complete substitute for the standard system. Of 
course, for waveform lookup tables there is no obvious reason not to use a 
power-of-two table, but the second (wraparound) guard-point form is still 
important; I guess the trust is that it will never (?) be required for a non 
power-of-two size. Given the ingenuity of Csound users, I find that difficult to 
believe!  I fully appreciate the problems the power-of-two requirement poses; 
but a ~lot~ of efficiency was gained by that design, not least in the fact that 
opcodes had to perform absolutely no special actions depending on the size of 
the table. Put another way - gaining the use of arbitrary table sizes may yet 
mean losing quite a lot. I would be very interested to see benchmark 
comparisons, especially for the case ksmps = 1.

Richard Dobson









-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

OK thanks to all of you that replies and explanations on this
-- i am very surprised it has so much difference in performance!

One option of course would be to have opcodes [ especially ones whose
f-tables are given at i-rate ] look to see if the table size is a p- 
o-2 in the i-pass.
Then it could set a function pointer to either an optimized p-o-2 or  
non po2
routine for p-time accordingly.

But the main thing i am annoyed with as a USER
   is that i do not want to THINK about power-of-2.  And after  
teaching this csound class
this past semester i can tell you i am not the only one!

i think at the very least we could add default table sizes so the  
user could just
specify 0 for the table size - i think in most general cases you just  
want to use gen10
with an oscili or something and not need to worry about tablesize - a  
reasonable
default size [ 1024? ] would be a nice feature.

the other frequently annoying case is large gen01 functions --  
getting more opcodes to
support "deferred" sizes would be really nice.

i don't know, maybe all this should just be done in some kind of  
front-end pre-process..

and did i mention more multichannel gen01 support as well?



On Jan 24, 2006, at 6:22 AM, Richard Dobson wrote:

> Istvan Varga wrote:
>
>> On Tuesday 24 January 2006 00:08, Richard Dobson wrote:
>>> The issue that would have to be addressed (and whcih I have  
>>> always seen as the main obstacle to the proposed changes) is  
>>> indeed the definition of the guard point, on which many opcodes  
>>> rely. In the current scheme, the contents of the opcode are  
>>> indicated by the table size being either a pow_of_2 or pow_of_2 
>>> +1, relying on the special significance of the pow_of_2 value.
>> Probably that is why the non-power of two table sizes are specified
>> as negative numbers. In this mode, the size always includes the guard
>> point, like in the pow_of_2+1 case above. A p3 of -101 means 100  
>> samples
>> and a guard point which is not copied from sample 0.
>
> This is OK if the reduced flexibility compared to the standard  
> system is accepted. That is to say, it only supports the extension"  
> form of guard point. It does not therefore form a complete  
> substitute for the standard system. Of course, for waveform lookup  
> tables there is no obvious reason not to use a power-of-two table,  
> but the second (wraparound) guard-point form is still important; I  
> guess the trust is that it will never (?) be required for a non  
> power-of-two size. Given the ingenuity of Csound users, I find that  
> difficult to believe!  I fully appreciate the problems the power-of- 
> two requirement poses; but a ~lot~ of efficiency was gained by that  
> design, not least in the fact that opcodes had to perform  
> absolutely no special actions depending on the size of the table.  
> Put another way - gaining the use of arbitrary table sizes may yet  
> mean losing quite a lot. I would be very interested to see  
> benchmark comparisons, especially for the case ksmps = 1.
>
> Richard Dobson
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

Matt;
________________________
           matt  ingalls
http://sonomatics.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I can understand this point.  It is easy to remember a few simple values
like 256 or 1024, but most people seem to be using larger tables these days
and may not want to expend the effort to memorize or recalculate sizes like
65536 or 262144 on a regular basis.

My suggestion to those people is to use a feature that already exists in
Csound:  the @ and @@ score expression operators.

Try f1 0 [@ 1000] 10 1
or  f2 0 [@@ 50000] 9 1 1.0 0.0 2.5 0.5 0.32

@ rounds up to the nearest power of 2 (1024 above) and @@ rounds up to the
nearest power-of-2-plus-1 (65537 above).

Anthony Kozar
anthonykozar AT sbcglobal DOT net


Matt Ingalls wrote on 1/24/06 1:00 PM:

> But the main thing i am annoyed with as a USER
> is that i do not want to THINK about power-of-2.  And after
> teaching this csound class
> this past semester i can tell you i am not the only one!



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Matt Ingalls wrote:


> 
> One option of course would be to have opcodes [ especially ones whose
> f-tables are given at i-rate ] look to see if the table size is a p- o-2 
> in the i-pass.
> Then it could set a function pointer to either an optimized p-o-2 or  
> non po2
> routine for p-time accordingly.

Sure; but lots of opcodes to change! And you need to check for p-o-2 ~and~ 
p-o-2+1. And if the notes are very rapid, it could start to matter CPU-wise. 
Maybe something for Csound 7?

> 
> But the main thing i am annoyed with as a USER
>   is that i do not want to THINK about power-of-2.  And after  teaching 
> this csound class
> this past semester i can tell you i am not the only one!
> 

One one level I sympathize; but there is no escaping the fact that Csound is a 
"scientific" and numerate system; removing concern for table sizes will not 
really make much difference to the amount of stuff a person has to understand to 
use Csound fluently.  At least, power-of-two sizes have a reason behind them! 
The problem with arbitrary sizes is just that - there seems to be no reason to 
choose one number over another. Indeed, Csound is one of the few tools I know 
that make it so easy to demonstrate pedagogically the difference between a small 
and large table, with oscil v oscili. I would have thought that teaching the 
difference between those would be at least as involved as explaining the special 
significance of power-of-two!

Richard Dobson











-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net