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