To create an echo/fading trail, it makes sense to use the Block solver in simulated mode and blend it with the original. But frankly, I missed the information, and it was an unpleasant discovery for me: Block ignores subframes and only works with full frames, so we'll get strobing or need to set the frame rate tenfold, which is difficult to redo once the animation is set up in frames.
How do other specialists solve this problem? How do they get smooth trails with small pitch? With a separate file and cache? Or is there some trick?
Will there be an improvement for Block in H22? Substeps, for example?

Unfortunately I was too clever in overloading "Iterations" to be both substeps and iterations. So the block is careful to NOT re-evaluate the inputs each iteration for maximum speed; but that defeats exactly this perfectly fine workflow. We have an internal bug: 150401 tracking this.

It's not ideal, as we will keep a copy of the result for every frame, but one approach in H22 for your original problem:

Time Pack, set step rate to 0.1
Average

This will cook 21 layers in a cable for the default window of -1 to 1 and then average on the cable will collapse them into a single image.

Thanks for the iteration variables in H22! That helped a lot. I partially solved the problem by using $F+@iter/@count in transform formulas. This is for a simple single formula animation. A slightly more complex option for a non-formula animation is to copy from the animation outside the block chf("...", $F+@iter/@count ) or cht(..) with $T+@iter/$FPS/10. But remember, this is for a single controlled parameter. If the layer is complex with several animated elements, this won't help. I was hoping for timeshift and timepack here, but frankly, I haven't been able to use them in the block yet. Either they don't work, or I don't understand the concept. As soon as I plug in the Time Pack cable, everything stops working.

Sorry, I was unclear, but the timepack goes directly to an average without using a block. The average will then do accumulation.

You can put a timepack into a block, but you need to a bit of hoop-jumping to run-over the images.

The attached shows both approaches. The block requires a cable rename to erase any incoming cable names. Then Cable Unpack can refer to them by raw index, and we can use @cop_iteration to run over the instances.

The downside of this setup is you end up pre-cooking the 40 substeps in this case, rather than doing them just in time. So this is a workaround rather than replacement for proper substepping.

Gaalvk
Thanks for the iteration variables in H22! That helped a lot. I partially solved the problem by using $F+@iter/@count in transform formulas. This is for a simple single formula animation. A slightly more complex option for a non-formula animation is to copy from the animation outside the block chf("...", $F+@iter/@count ) or cht(..) with $T+@iter/$FPS/10. But remember, this is for a single controlled parameter. If the layer is complex with several animated elements, this won't help. I was hoping for timeshift and timepack here, but frankly, I haven't been able to use them in the block yet. Either they don't work, or I don't understand the concept. As soon as I plug in the Time Pack cable, everything stops working.

Feeding a Time Pack cable should work if you set that input of the block to be Cable type. Inside the block, you can then use Cable Split or Cable Unpack to extract the frame of interest using the @itervariable. The attached scene file shows this.

Unfortunately, we can't yet use Time Shift to change when the input of a block should cook...

Edit: looks like Jeff and I made two versions of the same example for you! Renaming every wire to the same thing, then simply relying on the Index of Cable Unpack is a good way to generically loop over every field of a cable. The approach I'm using is stitching the name using a backticked expression, which is a little less elegant.

omarz
Feeding a Time Pack cable should work if you set that input of the block to be Cable type.

Yes, thanks for clarifying. That was exactly the problem. I was inserting a cable with mono layers into a regular mono input, and everything seemed to work. The cable was being transferred to the block, with all the layers inside (you can view them in the info panel inside the block). I could cut a layer, and it worked in all nodes. However, at the end, the block end returned an unexpected, incomprehensible error and a black layer, even though the block end contained a regular working layer that could be viewed. And no matter what I did, the output from the block end was empty. I simply needed to change the input type in the begin block to cable. I didn't think of that. Users, please pay attention to this: the block input type must strictly be cable!

To be honest, the "obvious" trick with a single field in cable unpack and a variable in the index field wasn't obvious to me at all, and I was struggling with cable split . Thanks for pointing that out, guys!

So, once I figured out how to properly pass layers into the block and select them, I did some testing, and here is the result. In theory, this is exactly what's needed for animation with future/past sampling, just like we're used to in After Effects.
But... a time pack sampling just 10 steps from a video file immediately drops us to 5 FPS, and down to 2 FPS after passing it into the block. Selecting 1 second (24 layers) results in less than 1 FPS in the viewport.
For comparison, on the exact same video, AE gives full real-time playback when sampling 24 "future" layers using echo or time displacement, and 10-15 FPS with 48 layers. There are clearly some fundamental bottlenecks here; time pack obviously doesn't play nice with the file node (I highly dislike it too and have been complaining about its lag since Copernicus was released. Damn, how does it even manage to lag this hard?). This means my original idea — to bake the animation into a cache, load it, and apply a time shift — died instantly, which is a shame.

A simple text animation gives us 5 FPS with 100 layers and about the same with 300 layers in After Effects; a 3x difference is acceptable in theory. But the file node, with its catastrophic, tenfold drop in FPS, is something I absolutely detest.

And yeah, thanks again for your work! In any case, these nodes have opened up some interesting new possibilities for us.