this email goes to the pd-list too...

Im using [ascseq] to split textfiles into single characters, that are being used in GEM text3d. I have a so-so AFM loader which assembles the characters with a somewhat accurate spacing. I have about 2000 of these separate text3d objects that I use to assemble typographic displays. You know, lots of floating letters in space that every now and so often rearrange into legible lines of text - typewriter style. I have bypassed the problem by removing/reshuffling certain characters in the font - have replaced space with � - asterix. I end up with scarily long single words. And it would be nice not having to do that. The whole mechanism is very fragile and delays cause the whole alignment to jumble up.

in your case (i expect you to have tons of text), i think it is really better to use [ascseq] instead of generating long symbols with spaces in between. (because of the symbol-table; however, benchmarking would be interesting...)

If the ascseq had a bang for every finished message it wouldnt be a problem.

you can get this behaviour via something like

[t b l] | | (b2) | [repack 1] | [t b l] | | | [ascseq] (b1) | (a)

the trick is to split the list into 1-atom messages with [repack 1] you get a bang at (b1) each time [ascseq] has finished 1 atom you get a bang at (b2) each time the whole list has been processed.

so with (b1) you can trigger a [32( repack everything into a long list with [repack].

mfg.asd IOhannes