2010/11/29 IOhannes m zmoelnig <[email protected]> > 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 > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
