Hi Pat, maybe i missed your point, but are you sure that expr (and expr~ etc.) is compiled into MobMuPlat? My impression is that it isn't, so that object family can't be used. gr~~~
2013/3/18 Pagano, Patrick <[email protected]> > Hello > > I am trying to get a synthesizer patch i created onto the ipad, i > erroneously thought that if the patch i was using opened up with > PdVanillaFor MobMuPLat that is included in the release of MubMuPlat that it > would work on the ipad. And since i am not selling the application i > assumed that i could use the expr~ since it is included. But now that i > finished setting it up when i load the file onto the ipad i get a bunch of > errors with > > expr if($f1-$f2==0, 0, 1) > error could'nt create > load_object: Symbol "expr_setup" not found > > I know there is some issue with the license and i found this README.txt in > files i has where Iohannes addressed the issue. IS there a way for me to > use this object in this patch? > > I am including IOhannes' stuff regarding hexloader > > > --------- > hexloader > --------- > (c) copyleft 2006-2007 IOhannes m zmĖlnig, IEM > > > the problem > ----------- > when dealing with abstractions and single-file externals, we have a 1-to-1 > correspondence between an objectclass and a file. > examples: > the [expr] object matches an external "./expr.pd_linux" > the [zexy/nop~] object matches an abstraction "./zexy/nop~.pd" > general: > the object [<name>] matches a file "<name>.$EXT" > when dealing with externals, the name of the objectclass is also to be > found > in the setup function within the external > example: > to load the "expr" external, Pd will look for a function > "expr_setup()" within the file "./expr.pd_linux" > general: > the external "<name>" has to provide a setup-function > "void <name>_setup(void)" > > this works fine, as long as there are no special characters involved: > according to the above scheme, when loading the external "expr~" > Pd should actually be looking for "expr~_setup()" within the file > "./expr~.pd_linux"; > unfortunately, the C-language (wherein most externals are written) does not > allow function-names to use any characters other than "a-zA-Z0-9_". > therefore the name "expr~_setup()" is invalid; > therefore, Pd handles the case of the trailing "~" in a special way: it > actually expands the "~" to "_tilde" and looks for "expr_tilde_setup()" > general: > the object [<name>~] corresponds to an external "<name>~.pd_linux" which > offers a setupfunction "<name>_tilde_setup()" > unfortunately this doesn't work well for a larger number of characters > forbidden in C-functionames. > example: > how should the setupfunction for an objectclass [~<~] be named? > > additionally, several filesystems have problems with certain characters. > for instance, you cannot use the character '>' on FAT32 filesystems. > but how do you then create a file for the objectclass [>~]? > > > a solution > ---------- > one solution is to just forbid objects with weird (non alphanumerical) > names. > pretty frustrating > > another solution > ---------------- > use libraries with valid names that hold objects with weird names > > a better solution > ----------------- > another solution is to translate the forbidden characters into allowed > ones. > for instance, every ASCII-character can be called by it's name (e.g. 'a') > as > well as by it's numeric value "97" (or in hex: "0x61") > the here-proposed solution is, to replace every illegal character by it's > hexadecimal representation (in lowercase). > examples: > [>] corresponds to the file "0x3e.pd" > [>~] corresponds to the file "0x3e0x7e.pd" or to "0x3e~.pd" > [a>b] corresponds to the file "a0x3eb.pd" > > the same system can be applied to the setup-functions: > examples: > [a>b] has a setupfunction "a0x3eb_setup()" > CAVEAT: > C also forbids to start function names with numeric values. > therefore, this is a nono: > [>]'s setupfunction would be "0x3e_setup()" (ILLEGAL) > we can simply fix this by putting the "setup()" in front: > [>] has a setupfunction "setup_0x3e()" > > implementation > -------------- > the "hexloader" external adds the possibility to Pd use the proposed > alternative naming scheme. > just load the "hexloader" lib, and the next time you try to create the > (yet unknown) object X, Pd will also look for several alternatives > example: > [>~] > ">~.pd_linux" (filename ILLEGAL on SOME > filesystems) > >~_setup() (ILLEGAL functioname) > setup_>~ (ILLEGAL functioname) > 0x3e0x7e_setup() (ILLEGAL functioname) > setup_0x3e0x7e() > "0x3e~.pd_linux" > 0x3e~_setup() (ILLEGAL functioname) > setup_0x3e~() > 0x3e0x7e_setup() (ILLEGAL functioname) > setup_0x3e0x7e() > "0x3e0x7e.pd_linux" > 0x3e0x7e_setup() (ILLEGAL functioname) > setup_0x3e0x7e() > ">~.pd" (filename ILLEGAL on SOME > filesystems) > "0x3e~.pd" > "0x3e0x7e.pd" > the hexloader will try one alternative after another until it finds one > that actually works (there is no problem in querying the ILLEGAL names, > it is just impossible to create such filenames/setupfunctions) > > > handling of "/" > --------------- > a special problem is the "/" character, as this might be a special > character > in the name of an object and the path-delimiter > example: > "a/b" might be a file "b" in the directory "a" or just "a/b" > solution > -------- > hexloader treats the "/" in a special way, as it tries all possibilities > example: > [a/b} > a/b (file "b" in directory "a") > b_setup() > setup_b() > a0x2fb (file "a/b") > a0x2fb_setup() > setup_a0x2fb() > > > CAVEATS > ======= > obviously the abstraction "0x3e.pd" can be addressed as both [>~] and > [0x3e] > this basically means, we have now an n-to-1 correspondence! > in the case of externals this could be fixed by only using the "setup_*" > naming scheme (instead of Pd's standard "*_setup()") > for practical reasons this has been dumped (too many devs created the wrong > setupfunction and couldn't tell why the externals would not load) > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- Thomas Grill http://grrrr.org
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
