hi
i wanted to play with [tabread~~] and checked out a fresh zexy and compiled and it went fine. when instantiating [tabread~~], i get an error though:
load_object: Symbol "setup_tabread40x7e_tild" not found tabread4~~ ... couldn't create
grep -d recurse "setup_tabread40x7e_tild" externals/
showed me only:
externals/zexy/src/tabread4~~.c:void setup_tabread40x7e_tilde(void) Binary file externals/zexy/src/tabread4~~.o matches Binary file externals/zexy/src/tabread4~~.pd_linux matches
note the 'e' at the end of "void setup_tabread40x7e_tilde(void)" while pd says: Symbol "setup_tabread40x7e_tild" not found (without 'e').
i don't get it. help appreciated.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
hi
i wanted to play with [tabread~~] and checked out a fresh zexy and compiled and it went fine. when instantiating [tabread~~], i get an error though:
this is a bug in Pd's hexloader that has been fixed in the latest and greatest 0.41-test release. altenatively you could use the hexloader to load tabread4~~.
otoh, the recommended way (by upstream developers) of using zexy is still as a library instead of single externals....
so: are there any problems when you try to compile zexy as a lib?
fmadrs. IOhannes
On Fri, 2007-12-07 at 08:00 +0100, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
hi
i wanted to play with [tabread~~] and checked out a fresh zexy and compiled and it went fine. when instantiating [tabread~~], i get an error though:
this is a bug in Pd's hexloader that has been fixed in the latest and greatest 0.41-test release. altenatively you could use the hexloader to load tabread4~~.
works. thank you a lot.
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.
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)? 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 the quasi standard now, i would like my patches to work fine there as well. 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.
hans: [<~],[>~] and [tabread4~~] will load in pd-extended-0.40, right?
so: are there any problems when you try to compile zexy as a lib?
no.
back to [tabread~~]: is there any point in using it without a [line~~] or [vline~~]? if yes, how is it supposed to be used?
thanks roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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
-
IOhannes m zmoelnig -
Roman Haefeli