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 _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
