Do you know if theres a limit to how much data the ascseq can hold?
Length of symbols? I need the ascseq to drip at 200 ms. (needs the
time too spit out the font metrics. not ideal I know, and Ill be
improving that for the future, but I have a little gig for thursday,
so this is an interim fix) The proposed method look risky. l2s is
currently working well...
Cheers, T.
On 26 Jan 2006, at 11:53, IOhannes m zmoelnig wrote:
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