hexloader

Category: Libraries and externals — Other products by this author

Current release: hexloader 1.6

Released 2015-08-17 — tested with pd 0.41, pd 0.42, pd 0.43, pd 0.44, pd 0.45, pd 0.46

a long outstanding release

List all releases… Full release announcement…

Get hexloader for All platforms (Source code) (10.6 kB)

hexloader-1.6.tar.gz

Project Description

Project resources

• Releases
• Contact address
• Code repository

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 "" has to provide a setup-function "void _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 "~.pd_linux" which offers a setupfunction "_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()"