IOhannes m zmoelnig wrote:
this email goes to the pd-list too...
obviously it went to pd-dev; sorry for cross-posting
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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmoelnig