Look up Table

Kevin Horden · Dec 4, 2003, 01:02 AM

Is there any documentation on using the TRAM for lookup tables?

I'm working on converting MIDI note inputs into delta's for an oscilator. I have calculated all the deltas and worked out an algorithm for deriving the deltas but the most efficient way to implement this would be a lookup table. Calculating it on the fly would take a lot of registers and opcodes.

Cheers,

Kevin

Max M. · Dec 4, 2003, 06:17 AM

Unfortunally, look-up tables are not implemented on 10k1 processor... So it does not make too much sense to bother with thing not present on all of supported cards.

Soeren_B · Dec 4, 2003, 09:15 AM

What is preventing you from calculating these values inside the GUI/C++ code

? You have to get MIDI input from somewhere...

/Soeren

eyagos · Dec 4, 2003, 10:52 AM

Lookup tables, that would be fantastic, altouhg as Max says, they are not supported.

I have an aproximation algorithm to make divisions in dane (i.e. 1/0.4 = 2.5 = 2 + 0.5). It needs 25 opcodes, and with a lookup table could be reduced to 5 or 6. And, almost in my case, these can not be done in the kxl, because each sample needs a different calculation.

**Eugene Gavrilov** · Dec 4, 2003, 12:17 PM

yes, Look-up tables are support in hardware only for 10k2 boards
moreover, kX kernel-level driver currently doesn't handle them at all
and the existing information about look-up tables is not sufficient and will require some investigation...
I doubt I can currently spend time on this...

/E

Max M. · Dec 15, 2003, 08:48 PM

btw. eyagos, you could not use tablelookups in your division approximation algorithm anyway:
Since those table look-ups made on emu10k2 through external tram - there're the same issues and limitations as for xtram delay lines... and yep main of them: the value of data register is not updated immidiatelly after changing its address register (e.g. there's the same latency between time you change "look-up pointer" and time you get desired value from your "look-up data")
E.g. i'd said that emu10k2 implementation of table look-ups is absolutely useless for "every-samplecycle" algorithms...
(anyway i think this means it should never be supported by kX ;)

oh, how cool probably it is to program fx8010 on rfx32 - since there's no xtram at all, but only one huge itram instead ;)

Kevin Horden · Dec 17, 2003, 03:19 PM

The only reason I asked about look-up tables (apart from seeming like a neat solution to my problem) is that while I was trawling for info I found Danial Bertrand's 10k1 assembler guide and saw a reference to look up tables in it. His 10k1 assembler which I believe is used in the Linux Alsa drivers mentions, and has, assembler directives for look up tables on a 10k1. Is he talking or writing rubbish?

Max M. · Dec 17, 2003, 04:44 PM

When Daniel wrote his assembler and that manual it was not 100% known if table-lookups are present at emu10k1 or not... (Later we found that table-lookups are implemented only on 10k2)

(presence of some feature in assembler does not mean that same feature is supported by driver and/or hardware, for example "dane" assembler also supports some features which are not supported by kX driver - i think i'll start some little war on this just after the new year ;)

Kevin Horden · Dec 18, 2003, 01:28 AM

Thanks Max. I think the basic problem is Creative Labs and the way they want to keep all the information under lock and key.