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