
	- I don't like that opening a .rez file requires write permission on the file you're opening!

	- figure out the proper way to make a template parameter be a friend of a template class in TStaticPoolAccesser

	- reimplement TStaticPoolAccesser::copyData and zeroData to use memcpy and memset instead of for-loops

	- I really need to play with very large files (>500meg) and make them faster if at all possible

	- I have taken the call to backupSAT() out of TPoolFile::insertSpace because it is just too slow in the real-time situation of recording.
		- perhaps I could have a more efficient way of storing the SAT or backing it up more efficiently
			- do now have that, but still don't think I want to call it while recording
			- ???  I got it... have a bool flag in TPoolFile which says to turn on or off crash recovery and then do or don't call backupSAT while it's off
	
	- reimplement TPoolFile::copyToFile to do this: 
		- for each pool, use pool accessors to copy alignment-sized buffers of data from the source to the destination.
		- this way, I don't unnecessarily copy data that doesn't belong to any pool

	- The SAT being a vector really does slow things down with VERY large files... If I didn't actually need direct indexing, then this could be changed to something more efficient to modify instead of O(n) operations

	- Perhaps mmap could be used to enhanced PoolFile... 



- DONE -

	- I should at least implement writeSATToFile to go much faster because it really took for ever to write the SAT on a 500 meg file... 
		- Write to a buffer in memory and write it all at once to disk... or change CMultiFile to preallocate space rather than calling ftruncate so many times, which may be what's taking so long
	- And maybe buildSATFromFile too


	- When it's possible, I really need to do something different in TPoolFile::isExclusiveLocked and also TPoolFile::getSharedLockCount because right now, the isExclusiveLocked returns true if it's shared locked obviously because the tryLock fails so it assumes wrongly that there's an exclusive lock obtained
		- perhaps I could keep a counter for the shared locks and bool for the exclusive lock myself in TPoolFile to count the number of locks
			- I would set and increment/decrement these myself when the lock was obtained
			- put mutex protection around actually changing the counter
		- it would still not be quite perfect this way because between the lock/unlock and the counter getting changed there would be a lie returned by isExclusiveLocked() or getSharedLockCount()
			- but I don't believe this is a problem, since getting the lock count would really never be guarenteed accurate

	- make moveData detect the situation that if the whole pool is being moved to an empty pool then just to simply move the whole SAT data to the empty pool and clear the SAT data at the moved pool
		- this will make removing and adding channels more efficient

	- whenever a pool is added or removed, outstanding poolIds are now not for sure valid anymore.  This is because the poolId was actually the index into TPoolFile::SAT and TPoolFile::pools.
		- This even messes up outstanding accessors
	 	- I had to worry about this in CSound::addChannels or removeChannels and cannot allow CSound::removeGeneralDataPool to be public because it would invalidate any pools created after the removed generalDataPool was created
		- two ways of fixing this are:
			* - 1) don't remove the spot in the SAT vector when removing a pool..just reuse it the next time a pool is created
				- but then I do need to remember that it is not valid.. probably name it ""
			- 2) go thru the code and everywhere that a pool ids could be modified, alter all outstanding accessors
				- but this wouldn't help for objects just storing the poolId obtained from the class.

	- make TPoolFile::accessers (and others) sets (instead of vectors?) direct indexing isn't necessary when searching and inserting would become faster



