[PD] big soundfiles

tim vets timvets at gmail.com
Mon Nov 29 15:15:52 CET 2010


2010/11/29 IOhannes m zmoelnig <zmoelnig at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101129/11f8c972/attachment.htm>


More information about the Pd-list mailing list