Deferred length GEN tables

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Deferred length GEN tables

David Akbari
Hi List,

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

<CsoundSynthesizer>
<CsInstruments>


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
</CsInstruments>
<CsScore>
f1 0 0 1 "/loops/dl_break0.aif" 0 4 0
i1 0 10

e
</CsScore>

</CsoundSynthesizer>

/*--- 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Deferred length GEN tables

luis jure
el Tue, 20 Sep 2005 22:23:32 -0400
David Akbari <[hidden email]> escribi?:


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

<snip>

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

<snip>

> 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Deferred length GEN tables

Istvan Varga
In reply to this post by David Akbari
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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Deferred length GEN tables

David Akbari
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:

<CsoundSynthesizer>
<CsInstruments>


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
</CsInstruments>
<CsScore>
i1 0 10

e
</CsScore>

</CsoundSynthesizer>

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:

<CsoundSynthesizer>
<CsInstruments>


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
</CsInstruments>
<CsScore>
i1 0 10

e
</CsScore>

</CsoundSynthesizer>


-David
Reply | Threaded
Open this post in threaded view
|

Re: Deferred length GEN tables

Istvan Varga
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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Deferred length GEN tables

David Akbari
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 [hidden email]