[PD] MobMuPlat for Ipad and expr~ woes
Thomas Grill
gr at grrrr.org
Mon Mar 18 12:56:47 CET 2013
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 <pat at digitalworlds.ufl.edu>
> 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)
>
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
--
Thomas Grill
http://grrrr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130318/a0f93719/attachment.htm>
More information about the Pd-list
mailing list