Hi Andrew, I found the same thing, and tweaked the "improper" init script by adding a same_state check and call to save_state, which seems to have fixed it. This is in the 7.1 branch and should be SVN trunk. Glenn
On Tue, May 5, 2009 at 8:56 AM, Andrew Martens <[email protected]>wrote: > Hi again. > > I have been fiddling with this all day and could not get it to work and > then I realised that the unscrambler in the fft_biplex did not have a proper > init script so the parameters were not being tidied up properly as in the > unscrambler used after fft_direct in fft! Sorry it has taken so long. I will > fix this tomorrow. I think fft_biplex should use the generic unscrambler > (instead of its own custom one) and I will see about making this happen. > > Cheers and have a good day > Andrew > > 2009/4/30 G Jones <[email protected]> > >> Hello, >> >> As some of you know, I have recently committed to the SVN some revised >> files based on ideas taken from the 10.1 branch to address problems with >> large FFTs and PFBs in 7.1 Green blocks. For the most part this is working >> well. However, in the biplex_cplx_unscrambler, the reorder block ends up >> with the reorder map argument in the form of a string which grows to be too >> long for large FFTs. This is because the map variable is populated in this >> way in the biplex_cplx_unscrambler. The reorder block mask calls >> backpopulate_mask, which should see that the argument is too long and store >> it in the user field. However, for some reason this is not happening. I >> assume because the biplex_cplx_unscrambler mask is getting run again and >> thus rewriting the map variable field. Does anyone know what the "right" way >> to fix this is? >> Thanks, >> Glenn >> > >
