On Wed, Aug 01, 2012 at 08:33:53PM -0400, S. Massy wrote: > Hello, > > Not really a bug, more like a hole in the caching implementation, but I > thought it should be mentioned for the record. When caching a buss, the > effects on the buss (user-track) itself aren't cached and the tracks > on that buss are still marked as MON (though they are no longer being > played). Also, uncaching won't work, because Nama only sees the new wave > for the buss user-track as version 1. So essentially, buss caching isn't > really working, or is an "at your own risk" thing at best: make sure and > backup before trying. Looking at the source, what I see is this: 1. The track output is written out to a WAV file for both bus mix tracks and regular user tracks, with whatever effects are on that track. 2. After caching a bus mix track, effects are *not* removed, nor is a "cache map" entry created for reversing the caching effect. 3. When the bus mix track is set to MON, it no longer picks up audio from the bus member tracks. We don't set member tracks to OFF, to allow us to recover the previous state (possibly with some tracks MON and some OFF) when we return the mix track to REC. However we could set the *bus* to OFF, to force member tracks OFF. This extra state switch has been found to be confusing in the past. ("I set the track to MON, why is it still OFF?") Or just turn OFF all member tracks, and leave it to the user to remember the ones he wanted set MON. If I understand correctly, the simplest fix would be to generate a cache_map entry for bus mix tracks, and to be sure that uncaching sets the mix track to REC and rec_defeat, restoring its previous busly behavior. (I'd also like to do is to get the cache_map data out of git-tracked State.json so that returning to an earlier state will not lose the cache_map entry for an existing track version.) Busily yours, > Cheers, > S.M. > -- > -- Joel Roth