a bang is emitted every time a grid transmission ends a bang is emitted every time a grid transmission ends. this is a pattern where [t b a] doesn't cut it, because the bang would be output too early, as it gets output at GRID_BEGIN time (the time at which the grid message is sent). But [#convolve] only outputs its contents after GRID_FLOW time, which is what [#finished] ensures. However you still need a [t a a], because [#finished]'s GRID_FINISH time must happen after [#convolve]'s GRID_FINISH, so that you can be sure that [#convolve] is really finished with producing its output. the third exception is that the GRID atom type is not officially recognised by PureData because PureData provides no means for externals to register new atom types. You can see the effect of this in how GEM uses the POINTER atom type in an unstable way (which is also how GridFlow used to do it) the fourth exception is that GridInlets support multiple selectors with quite peculiar autocasts, meaning that [# +] can't support the equivalent of the 'list' message in the [+] class. much of the text of this page should really go somewhere else, but there is no place for it yet. this is one of GridFlow's exceptions to how much grid-processing is like normal pd message passing. there is also the [#t] class that provides a shortcut for the most common use pattern of [#finished]. the 2nd exception is that it definitely doesn't support any control-recursion (an object can't start processing a new message before it has finished processing its current message). see also [norecurse].