Hiya Greg!
 
First, your questions:
1. Yep.  Scene files will store the object location, so anytime you find yourself going through the dialog dance, just make sure you save again afterwards.  Then you won't have to do it again until something moves, and then only for whatever moves.
2 and 3.  The Cut/Copy/Paste system currently only stores references to the region that was cut/copied, which explains all of these affects.  I'll definitely be looking into that now that the feature set and data structures have settled out.  Cut/copy/paste was originally added while some of those structures were still changing, and actually mirroring them would have added another layer of things that could go wrong.  But now that things are stable, I can go back and do that.
4. Hmmm...  Did it successfully load the song, and then die when you tried to do something with it, or did it die before becoming active?  Just wondering if it ran out of audio driver memory or if it failed elsewhere.  Could you tell me about your operating system, system memory, and audio card, in case there's something obvious?  Thanks!
 
On to the proposed features:
1. "since the x-sheet doesn't scroll" -- ummm, it should scroll...  If it isn't, then we've got a bigger problem.  Would some kind of a "waveform panner" suit your needs?  I can't really zoom out on the X-sheet, because there's no way to represent the data of the X-sheet.  But I could create another window where you could pan and zoom around in the waveform and the X-sheet would sync to that.  (This would be a v2.0 feature)
2. Aurora has also mentioned some "bookmarking" capabilities (he has also worked on a multi-minute "music video"), so that will definitely be in the v2.0 feature list.
3. Possible that this is resolved as a side-effect of 1 and 2.
4. In theory, there isn't a hard limit (well, OK, a couple of gigabytes), but really long files may hit system resource limits.  At present, I load entire audio files into buffers, instead of paging them.  I can work around sound card memory limits, but to maintain speed, I will need to be able to load the entire audio file into a system memory buffer (loading from disc in the middle of playback will be extremely unpleasant).  In theory, this should be a reasonably straightforward patch (and may be necessary for me to fix your crash bug from above), in which case it will be a free auto-update.  As for offsets, there are other reasons for needing them, so that will also be a future feature (possibly before v2.0, but no later than v2.0).
5. Multiple audio tracks, multiple objects, and just in general "multiple everything" is planned for v2.0.  This is a fairly wide-ranging change, so it probably won't make it before then.  In the interim, you can swap audio files out reasonably quickly -- one of the beta testers used a dialog-only track for all his phoneme placement, and then swapped it out for the real track for final tweaking.
{Finally}. Just to make sure I'm thinking of this properly:
- take a set of puppeteer tracks and their values at the same time as a phoneme key
- associate that set with the phoneme key
- be able to drop that set into the corresponding tracks at the same location as when you drop the phoneme
- (optional, need clarification) the set of puppeteer tweak keys is clustered in time around the phoneme, not just on the same frame as the phoneme
 
Without the "optional" part -- v2.0 is planned to have a way to define new morphs as linear mixes of existing morphs.  This would allow you to mix whatever puppeteer morphs you needed into a new version of the phoneme and use it whenever you needed it.
With the "optional" part -- This is somewhat more involved.  v2.0 is planning some support for grouping and sequencing of morphs into "super morphs", but I don't think that would cover this model.  Programmatically, this is just being able to paste multiple times from one copy, and paste across a set of tracks at once.  It is possible that the improvements to the clipboard system from above will provide you with the tools you need.  Some form of clipbook, or way to select an area and then create one "super morph" out of that may be possible in v2.0.
 
Definitely an interesting set of v2.0 features.  I'll look into the long audio issues and see what I can discover.  If I find something and fix it, I'll post a new trial version so you can try it out.
 
Mac

Hmm, I've loaded a few songs that range from 5:21 to 10:53 in length. the longer ones obviously took some time loading but they loaded fine and I was able to play them on my machine. Obviosly I'm using the same machine as previously and  have not changed my sound card

First, a possibly embarrassing secret: when you load an audio file into TAFA, it actually gets loaded twice -- once forward, and once backward.  The backward copy is there to support playing the audio backward (not scrubbing backward, but actually using the "Play Backward" button).  So a 45M file will consume 90M of memory and a significant CPU load as it has to walk the audio file sample by sample copying it from one buffer to the next.  So the first thing I can do is to not automatically reverse the audio, but only create it the first time you try to play backwards.  Since a lot of people won't do that, it would save time and memory.  Having said all of this, Aurora's 10min files did load and work, so we'll need to find out what is different.
 
Also, both of these buffers are created as audio driver buffers, which means I'm asking your sound card to hold onto 90M of data.  Creative drivers are not exactly known for gracefully handling unusual situations, and may be choking.  To be fair, I also may not be handling some failure results coming back from them, leading to bad behavior on my part.
 
OK, with all of that in mind, lemme look at your numbers again.
 
I'll take the largest mem free that you reported as your actual available mem free after XP loads, since it consumes a significant quantity.  So 350M is max.
TAFA loading 45M audio: 75M, for a difference of 275M.  Great...
2nd load of 45M audio: 134M, for 216M.
 
OK, these numbers are totally out of line with the actual resource allocation.  As I've been (re)reading your description, something sounds odd to me.  You say that the "CPU usage is hitting the ceiling and program is getting non responsive".  The odd thing is, all of the resource management for audio is done between the time you select an audio file and before the program starts responding to anything again.  The program should be completely unresponsive until it has finished allocating, copying, and flipping the audio file.  But once it has done so, TAFA is not doing any more resource management.  If, after loading your audio file, you are able to do anything at all with TAFA and then after that you see an ongoing memory consumption, then it isn't TAFA.  When you select an audio file, a progress bar appears in the center of the screen (may disappear almost instantly for small audio clips).  Once that bar disappears, any ongoing problem is something else in your system, because TAFA has quit processing.
 
My current best guess is that the Creative driver can't cope with 90M of allocated sound buffers, but thinks that it can.  It's probably trying to page chunks in and out of memory, and is losing track of them along the way.  So, in theory, I could just blame it on the sound drivers.  However, I am asking them to do something pretty nasty, so I'll take a look at loading audio into the sound card piecewise.  This is all based on the assumption that the problem continues to get worse after TAFA has finished loading audio, so if I'm mistaken on that, I'll need to re-evaluate.

I'm most familiar with GoldWave for WAV editing.  I know that it includes a significant chunk of code that he spent years developing to make managing large (gigabyte) audio files fast and smooth.  Any dedicated audio editing software uses piecemeal loading to the audio card, and frequently piecemeal loading even to system memory.  TAFA was originally designed for shorter audio clips, where piecemeal loading wasn't necessary.  But a few minutes is well within the range that it should handle.  While it is probably not reasonable to go to the lengths that full-fledged WAV editors use for managing large files, I can at least do the piecemeal loading to relieve the stress on the audio driver.  I've done that before as well (separate project -- Voice over IP system), but wasn't expecting to need it for TAFA.
 
Let me work out a piecemeal loader and get you an updated trial version to test out.  I should be able to do that tonight (barring unforeseen emergencies).
 
By the way, you mentioned in the original post that the X-Sheet wasn't scrolling for you.  Is that only with this 45M audio file, or does it happen for other files?

I think I may recognize a terminology difference:
 
The X-Sheet never auto-scrolls.  In other words, it doesn't roll along to match the audio playback.  I did this at one point and the performance hit was terrible.  I know of ways to improve this performance, but it will still impact recording and playback speed, and has not been sufficiently important so far.  It does include the black tracking line to show location within the portion of the audio that is onscreen, which helps within small focus regions (a few words, typically)
 
However, the X-Sheet does have a scrollbar that you can use to slide up and down the audio track.  It should also scroll if you have selected a set of keys and are dragging them to the top or bottom of the X-Sheet.

Yeesh...
 
The memory leak was in ancient code...  Well, OK, maybe only 8 month old code, but that's half the development time ago...
 
Anyway, fixed now, with the side benefit that redrawing the morph file is now somewhat faster (only slightly on my machine, but your results may vary).
 
Always good to get the bugs fixed before worrying about the new features  

Not good Mac...
I still get a lot of unresponsive panels....
But I may have stumbled on the bug.
If I start TAFA and don't load anything but the audio, the response is fine. Even shutdown is normal.
 
I think the problem relates to opening the provided Mr Cool Scene & Objects & Audio first.
Then when that long audio is brought in - everything is responding bad.
 
I tried it with both versions.... and the new version does indeed seem a bit better - but only if I dont use the provided examples.
I think its the TAFA scene - because just Loading MR.C doesn't seem to have a problem.
 
I'll continue testing...
 
 
Oh and you are right - I meant auto-scrolling.  
 
 
 
 
 
 
 
**************************
 
More news...starting from scratch Loading Mr.Cool and creating 2 dialog tracks and 20 puppet tracks does not cause any problem.
At least not immediately.  I'll keep testing - but I'm afraid I don't understand the program well enough to not appear stupid in the forum.  Like:  Is it supposed to create a keyframe for every frame when you go into record mode?