on OSX with both 0.40-2 and 0.39.2, none of the zexy externals >~, <~, ==~
if I replace >~ in my patch with 0x2e0x7e, i get an error: load_object: Symbol "0x2e0x7e_setup" not found
just a note to say that i have noticed this as well... i cheated by copying the folder from 39-2 but i don't see why that shouldn't work (it has for other things)
i need my [>~] and etc back :) no spectral gating until that happens
Kevin
On 4/17/07, Damian Stewart damian@frey.co.nz wrote:
on OSX with both 0.40-2 and 0.39.2, none of the zexy externals >~, <~, ==~
- basically all the ones named eg 0x2e0x7e.pd on disk - are not loading.
if I replace >~ in my patch with 0x2e0x7e, i get an error: load_object: Symbol "0x2e0x7e_setup" not found
-- Damian Stewart +64 27 305 4107
f r e y live music with machines http://www.frey.co.nz http://www.myspace.com/freyed
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Kevin McCoy wrote:
just a note to say that i have noticed this as well... i cheated by copying the folder from 39-2 but i don't see why that shouldn't work (it has for other things)
i need my [>~] and etc back :) no spectral gating until that happens
the hexloader seems to be broken in newer versions of pd.
instead of fixing it in pd, i have decided to write an external loader.
but i don't know where i should put it....
the obivous place would be ./externals/loaders/ but this seems to be occupied by the libdir loader. i would rather have it (and all other loaders to come) in separate directories rather than in a flat structure. (this would mean something like ./externals/loaders/hexloader and ./externals/loaders/libdir but the latter would mean moving the libdir-loader around which i won't do since it will eventually break things...)
how should i proceed?
mfga.sdr IOhannes
On Apr 18, 2007, at 11:19 AM, IOhannes m zmoelnig wrote:
Kevin McCoy wrote:
just a note to say that i have noticed this as well... i cheated by copying the folder from 39-2 but i don't see why that shouldn't work (it has for other things)
i need my [>~] and etc back :) no spectral gating until that happens
the hexloader seems to be broken in newer versions of pd.
instead of fixing it in pd, i have decided to write an external
loader.but i don't know where i should put it....
the obivous place would be ./externals/loaders/ but this seems to be occupied by the libdir loader. i would rather have it (and all other loaders to come) in separate directories rather than in a flat structure. (this would mean something like ./externals/loaders/hexloader and ./externals/loaders/libdir but the latter would mean moving the libdir-loader around which i won't do since it will eventually break things...)
how should i proceed?
Hmm, I like the idea of encapsulating the hexloader code, but I think
if the hexloader is a separate loader, then the other loaders won't
benefit from its translation of non-alphanumeric ASCII. I think the
way the loader stuff is implemented, it is just a failover, if the
first loader fails, then the next one tries. I think that the
classname should be the filename not only for objects written in C
and Pd, but also any other language.
If you are rearchitecting this stuff, I would like to make a
suggestion. What I would also like to see is that the hexloader is
split into two naming schemes: file system, which would translate
only / \ : * ? " < > | and the setup function, which would do the
whole translation. That would make the files a lot more readable.
If the loader is the route you end up taking, the CVS directory
hierarchy sounds good to me, feel free to move the libdir loader to
it's own folder, or leave it.
.hc
mfga.sdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith