Hi List,

I was wondering if the following would be considered a BUG or a FEATURE 
??





sr		=	44100
ksmps	=	100
nchnls	=	2

		instr	1

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

	outs	aout, aout

		endin


f1	0	0	1	"/loops/dl_break0.aif"	0	4	0
i1	0	10

e




/*--- from Csound5, Sept 20 2005 Output ---*/
writing 4096-byte blks of shorts to dac:0
SECTION 1:
ftable 1:
deferred alloc
audio sr = 44100, monaural
opening AIFF infile /loops/dl_break0.aif
   defer length 120795
new alloc for instr 1:
INIT ERROR in instr 1: deferred-size ftable 1.000000 illegal here
itabsz  tableng.i       1
INIT ERROR in instr 1: deferred-size ftable 1.000000 illegal here
aout    table.a andx    1       0       0       0
           B  0.000 - note deleted.  i1 had 2 init errors
inactive allocs returned to freespace
end of score.              overall amps:      0.0      0.0
            overall samples out of range:        0        0
1 errors in performance

It would seem that simply changing the tablesize to a power of two like 
131072 or 262144 works OK, but I mean I really think the table opcodes 
should be able to read deferred size GEN tables ... is this idea 
possible at present, and I am just unaware of how to implement it?


-David

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

el Tue, 20 Sep 2005 22:23:32 -0400
David Akbari  escribió:


> I was wondering if the following would be considered a BUG or a FEATURE 



> INIT ERROR in instr 1: deferred-size ftable 1.000000 illegal here



> It would seem that simply changing the tablesize to a power of two like 
> 131072 or 262144 works OK, but I mean I really think the table opcodes 
> should be able to read deferred size GEN tables ... 

deferred-size tables can only be used by the loscil opcode (it's in the
manual), so it should be considered a feature.

but i agree that the table opcode _should_ be able to read deferred-size
tables. if i'm not mistaken, gabriel maldonado did away with that limitation
a _long_ time ago in his version of csound for windows, but i'm not sure,
i'm on linux and i only use canonical csound. what i know is that those
changes never made their way into the canonical sources.

best,

lj


-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

David Akbari wrote:

> I was wondering if the following would be considered a BUG or a FEATURE ??
> 
> ...
> 
> It would seem that simply changing the tablesize to a power of two like 
> 131072 or 262144 works OK, but I mean I really think the table opcodes 
> should be able to read deferred size GEN tables ... is this idea 
> possible at present, and I am just unaware of how to implement it?

It has always been this way, I do not think the table opcodes ever
supported deferred tables. While the opcodes can be changed to allow
non power of two sizes, the cost is increased CPU usage whenever
wrapping to table length is needed.
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

On Sep 22, 2005, at 4:35 AM, Istvan Varga wrote:

>
> It has always been this way, I do not think the table opcodes ever
> supported deferred tables. While the opcodes can be changed to allow
> non power of two sizes, the cost is increased CPU usage whenever
> wrapping to table length is needed.

This is a good reason to not allow the table opcode to be able to index 
non deferred f-tables, but what about the tableng opcode? I think it 
would be quite useful to at least be able to use the idea of a table 
length in samples which is obtained at i-rate.

For example, the following code results in an error which I do not 
believe it should:





sr	=	44100
kr	=	441
ksmps	=	100
nchnls	=	2

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

gifn1	ftgen	1, 0, 131072, 1, $TEHFILE., 0, 4, 0
gifn2	ftgen	2, 0, 0, 1, $TEHFILE., 0, 4, 0

		instr	1

itabsz	tableng	2

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

	outs	a1, a1

		endin


i1	0	10

e




SECTION 1:
new alloc for instr 1:
INIT ERROR in instr 1: deferred-size ftable 2.000000 illegal here
INIT ERROR in instr 1: Table 2.000000 not found

	  B  0.000 - note deleted.  i1 had 2 init errors

while this code is the workaround:





sr	=	44100
kr	=	441
ksmps	=	100
nchnls	=	2

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

gifn1	ftgen	1, 0, 131072, 1, $TEHFILE., 0, 4, 0

		instr	1

itabsz	filelen	$TEHFILE.

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

	outs	a1, a1

		endin


i1	0	10

e





-David

I changed tableng to allow non power of two table sizes (note that you
can already use ftlen on deferred tables). It should be noted, though,
that the returned table length is the total number of (mono) samples - 1
(for the guard point), for example with a stereo file of 20000 sample
frames, 39999 would be returned.

David Akbari wrote:

> This is a good reason to not allow the table opcode to be able to index 
> non deferred f-tables, but what about the tableng opcode? I think it 
> would be quite useful to at least be able to use the idea of a table 
> length in samples which is obtained at i-rate.
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

On Sep 23, 2005, at 12:05 PM, Istvan Varga wrote:

> I changed tableng to allow non power of two table sizes (note that you
> can already use ftlen on deferred tables). It should be noted, though,
> that the returned table length is the total number of (mono) samples - 
> 1
> (for the guard point), for example with a stereo file of 20000 sample
> frames, 39999 would be returned.

That is quite amazing ...

Thanks, Istvan!

Hopefully other users as well as myself will be more encouraged to use 
variety in implementations involving the indexing of digital audio 
files stored in tables!

Also thanks for pointing out the inherent problem in trying to directly 
index a deferred length table. Studying the idea closer, it would 
probably result in a fairly large CPU hit in trying to make sure the 
array is not indexed past it's overall length; and potentially unstable 
if the user is not extensively careful in their implementation. In that 
case it seems users would be better off just using a diskin or soundin 
opcode.


-David

(Thanks again!!)

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk