[PD] [tabread~~] (again)

[IOhannes m zmoelnig]

Roman Haefeli wrote:
> 
>> otoh, the recommended way (by upstream developers) of using zexy is 
>> still as a library instead of single externals....
> 
> yeah, works as well. i trapped myself, because i just switched a few
> days ago from zexy.pd_linux to singleobjectclass.pd_linux. i haven't
> thought about issues with filenames and i am surprised that bla~~ is a
> problem and bla~ isn't. 

object~ is so common that Pd has it's own naming mechanism built-in.
it is not generic at all, that is why there is a need for the hexloader.


> however, it causes me a bit head scraping to hear that the library is
> the recommended format. is there a particular reason for this (i mean,
> since hexloader is working)?

probably, because you have not been able to load the object?

i think it makes an object quite unusable if you either have to upgrade 
to the newest bleeding-edge version of Pd or use another external to use it.

i personally prefer to be able to work with any version of Pd (working 
on several machines i don't want to spend my time keeping all of them in 
synch; i haven't found the time to automate the synching (via etherboot 
or whatever)), and with almost no externals.
zexy i know well and use it so much, that i don't care for having a 
number of externals available all at once; but loading 
(+installing+compiling) yet another external just to be able to use the 
one i can already use anyhow, seems to me like an overhead.


> the reason, why i switched was to be aware of and avoid possible
> problems of my patches with pd-extended beforehand. since it is probably

a valid point.
what i meant to say is, that i put some effort into being able to 
compile zexy as single externals (after all i have added this option to 
the configure and have written the hexloader...), but the way i use it 
in everyday life is as a single library.
that is why this has the official support.

> however, when loading hexloader, these problems won't show up
> anymore, which is kind of against the initial reason for going the
> single-object way. 

i am not sure i understand that.

> 
> back to [tabread~~]:
> is there any point in using it without a [line~~] or [vline~~]? if yes,
> how is it supposed to be used? 

yes there is a point.
i think ypatios has posted an example patch on how to use it.

what you can do with [tabread4~~] out of the box is have one signal act 
as an offset (large numbers), and the other one as the relative movement 
to this offset (small numbers), e.g. for a granular engine that works on 
big soundfiles (which was the trigger to write this object).

what you cannot do is to have one very long ramp (e.g. a [line~] going 
from 0 to 1e10 in 50e13 ms) that smoothly reads the array with 
[tabread4~~] without a special object like [line~~].

however, thomas (iem) has now implemented a number of objects for 
"double-precision signals", including [vline~~] (though it is not fully 
working yet)
i don't know yet, when we will release this library.

mfg.asd
IOhannes