2010/11/29 IOhannes m zmoelnig <zmoelnig@iem.at>

On 2010-11-29 14:45, tim vets wrote:
> do I interpret it correct if I assume that a solution for [tabread~]-ing big
> files without quality loss would be to make a counter and split one big
> [line~] movement into small segments ?
>
> something like:
>
> [metro 100]
> |
> [f]X[+ 4410]
> |
> [s adder]
>
> and
>
> [r adder]
> |
> [t �b � � � � � � � �f]
> | � � � � � � � � � � |
> [0, 4410 100( � |
> | � � � � � � � � � �/
> [line~] � � � � �/
> | � � ______ /
> [+~]

???
you are still hitting the problem that the output of [+~] has probably
to little precision.

your patch will thus not give you any benefit.

> |
> [tabread~]

i was _not_ talking about �[tabread~] but about [tabplay~]

sorry if I was not clear, I was in fact thinking of Mathieu's message:

"If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?)�"

which afaict he didn't give an example for yet.

I'm not sure what he meant, but that was what I made up of it...probably wrong :)

Tim

[bang(
|
[tabplay~]

alternatively you can use the send inlet (message!) of [tabread4~] for
better precision. the help-patch directs you to B15.tabread4~-onset.pd

msdfrt#
IOhannes