Personal tools
You are here: Home downloads hexloader
Document Actions


RSS Feed Category: Libraries and externals — Other products by this author
loader that allows weird characters in object names

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…

Experimental releases

Upcoming and alpha/beta/candidate releases

  • Alpha releases should only be used for testing and development.
  • Beta releases and Release Candidates are normally released for production testing, but should not be used on mission-critical sites.
  • Always install on a separate test server first, and make sure you have proper backups before installing.
hexloader 1.7 (Unreleased)
the BSD release

Project Description

Project resources

the problem

when dealing with abstractions and single-file externals, we have a 1-to-1 correspondence between an objectclass and a file.


  • the [expr] object matches an external "./expr.pd_linux" - the [zexy/nop~] object matches an abstraction "./zexy/nop~.pd"


  • 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


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()"


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.


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()"

by IOhannes m zmoelnig last modified 2015-08-17 11:10 PM

Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser