[CSOUND 6 TODOs]

2)  analyze and assess changes for CSOUND struct
          There is a list below of fields not in API that are only used once

3)  Introduce Context Struct

4)  xtratim

5)  reparsing with active CSOUND instance

6)  Investigate the CSGLOBALS_USE_TREE option 

7)  Should OENTRY table be hashed or tree?

[These are not all checked and need investigation]
instxtcount  1  // set in Engine/csound_orc_compile.c but not used
optxtsize  1 // set in Engine/csound_orc_compile.c but not used
tran_nchnlsi  1 // in Engine/csound_orc_compile
sstrlen0  1 // Unfinished multiple strings

gblacount etc replicated in otran structure and CSOUND
[ OLDER TODOs]

POWER OF TWO ISSUES
-------------------

envlpx
envlpxr

oscil

oscil1
oscili1

foscil
foscili

loscil
loscil3 (these don't depend on pow2 but maths could be simplified with
floating point).

tablei
table3

buzz
gbuzz

tablew

vco

fof
fog
fof2

grain

partikkel

specscal
specfilt
atsadd
atscross

pitch

oscbank

grain2
grain3
oscilikt
osciliktp
oscilitkts
vco2



KNOWN AREAS OF INCOMPLETENESS
-----------------------------

[NEW PARSER]

-notes on old parser
  -rdorchfile in addition to getoptxt act as tokenizer
  -otran is like parser, calls getoptxt to get tokens
  	-otran sets up INSTRTXT pointers in two ways, one is in a flat array indexed
  	by instrument number (including numbers assigned to named instruments), the
  	array is NULL'd; individual INSTRTXT's also point to each other using
  	nxtinstxt so there is a collapsed linked list as well as an array

  -seems like some data held in structs that are not used beyond parse time

  -after INSTRTXT's are created, they're traversed to figure out number of
  args for each opcode to add as sum to instrtxt, but the sum from all
  instruments is summed and assigned to csound->argoffspace (end of otran)

  -constants are held in a pool so that memory wise, all "440" in code will
  point to the same MYFLT "440"

  -four pools: one for constants, one for strings, one for global var names,
  and one for local var names

  -polymorphic opcodes: checks dsblksiz of OENTRY, if > 0xfffc, then is polymorphic,
  and checks for correct version of arg dependent on out arg types (in rdorch.c)


-notes on new parser
	-csound_orc_parse creates AST of TREE * using Bison/Flex; tree should be
	semantically correct at end of parse run and all errors should be checked
	during parsing (?)
	-csound_orc_optimize will attempt to optmize tree using common compiler
	optmization methods
	-csound_orc_compile will transform the AST into INSRTXT, OPTXT, TEXT structs
	to be used by csound
	-when these are finished, CSOUND struct should be setup in the same way as
	when after otran is used (barring any optimization differences)

	-trying to make smaller functions (can be statically inlined) that make the
	compilation process a little more transparent and encapsulated

-other notes
    -look into creating API functions for programmatically building orc from
    opcodes, exposing INSTRTXT chain

-----------------------------------------
AGENDA
<jpff> 1: Loadable instruments
<jpff> 2: integration of UDOs
<jpff> 3: I need to follow what you are doing over types
<jpff> 4: ditto victor with sample-accuracy
<jpff> 5: I relly need to code the better parallel dispatch
<jpff> Can we simplify the environment variables?
<jpff> Wht language changes do we need
<jpff> also... removing power-of-2 tables in oscillators really slows things.
       Should we implement a separate set of opcodes, or switch internally

