[PD] external loading suggestion
lex_ein at f-m.fm
Mon Jul 19 05:24:46 CEST 2004
Hans-Christoph Steiner wrote:
> Part of putting all of the code into a central repository
....like herding the sweetest, but most unwilling cats: not all
plant their code in the CVS.
> and also compiling all of the contributed objects as individual files
Unless I misunderstand you, this requires breaking up existing libs into
objects. Lots of work, and the original developers won't want to do it,
want to touch it after someone's dismantled it.
> allows us to eliminate such conflicts.
No, that means you'll still have two different, say, "counter"
single-entity libs and
hence [counter], and users will still never be able to reach both of them.
Do you mean allowing the user to rename the lib? Doesn't that break
And then break the patch on everyone else's machine?
Load-time namespace management will allow ALL objects to be reachable,
even into the infinite future, whether or not they are in simple (1
entity) or aggregate libraries,
no matter if a developer names ALL his objects the same [thing], as long
as the library
names are different.
> So if you use the packages (Debian, Windows, MacOS X), then there
> won't be conflicts if you don't use any libs.
Who will make the choice of which objects 'live' without renaming, and who
'dies' (gets renamed)?
Even dictionaries allow different definitions of words, and multiple
entries, and they're all accessible to those who
wish to access them.
To expand on my core arguments:
0. Not all users are C developers, nor do they wish to be..
1. Not all developers will plant their code in the CVS.
I imagine the most important one never will do so.
2. All users want arbitrary access to all objects, with
a) no unresolvable conflicts, and
b) an easy workaround for any conflicts, and
c) easy to find, install, and successfully reference objects.
Example, unresolvable as of July 18, 2004:
lib1 contains [counter](2 inlets) and [slope](2 inlets)
lib2 contains [counter](4 inlets) and [slope](4 inlets)
All four objects are useful and interesting, and do what they say in
All should be reachable, without forcing literal renaming, or forcing
Note: lib_obj naming is not 'renaming', but 'name extension'
3. Not all developers will choose to check the name of their new objects
WWW to guarantee uniqueness, because that would force them to choose YAASIN
(Yet Another Arbitrary Silly Irrelevant Name) for their objects.
Perhaps better to force
them to use a thesaurus (see attached pic, courtesy Visual Thesaurus).
4. Objects evolve. There are early versions of objects which are fast
Later versions (same name) have great features, but are slow. The user
should be able
Conclusion: some sort of easy user-end name choices are needed.
I personally like pseudo-heirarchical built-in name mangling as
expressed in maxlib,
followed by path-heirarchical with a lib-name 'namespace' separation, or
a true namespace implementation.
If the argument is that it's a lot of work for a few conflicts, please
note that there are
nearly a hundred actual conflicts in the Pd universe of objects right
now. This is because
every weirdly synonymical-yet-irrelevantly-named object represents a
conflict resolved by the
developer at coding time. That resolution was achieved in an
and ultimately user-alienating way. Each of those conflicts continually
user to tries to use Pd.
I disliked irrelevantly-named objects in Max, and I dislike them even
more in Pd,
because in this new, developing language, they're unnecessary.
We'll never know what those irrelevantly-named objects (INOs) would have
if there had been another way.
Historical interpretive note:
In Max and Pd and others, names are short ONLY to take up minimal space
on the screen, because
they are perforce textual languages, and texts, not diagrams. There is
no functional meaning assigned
to the square boxes without the name present. These are English-centric
and are likely to remain so,
even though this does not serve users(too-short names), or international
users(must know English), all
Why make this point?
In some other gui-based languages, such as eyesweb, object names are
long, and are descriptive,
but objects in patches are represented primarily as icons, perhaps
accented and differentiated from its
functional family members with an additional symbol or letter. These
are inherently more
internationalizable. There is a certain greater compactness and visual
understandability which _can_
be achieved graphically, although eyesweb does not achieve this.
Worse, the ease of mutating an object
is missing in eyesweb - an object cannot be changed "on the fly", but
must be newly created, and the old
one deleted, along with all its prior connections, which must then be
"Freedom of choice, it's what you've got.
Freedom from choice, it's what you want."
> On Jul 18, 2004, at 4:56 PM, Lex Ein wrote:
> Problem: Unique objects exist in more than one library with the same
> name, but different function, with no ombudsman or czar to arbitrate
> who gets the name. This forces library loading order to be an issue:
> IEM's gate vs cyclone's gate.
> So I offer two thoughts: (if this has been discussed before, I
> couldn't find it.) 1. If, at load time, external objects maintained
> their library name persistently, then objects could be absolutely
> selected from a particular library at creation time in the patch.
> This would eliminate the effect of library loading order and increase
> reliability. So instead of [prob 2 4 5] someone publishing a patch
> could specify [mJlib/prob 2 4 5] to guarantee correct operation, and
> alert the user immediately to the required library, with no further
> documentation needed..
> 2. If Pd had a option to enable/disable "object path display" in the
> GUI, ALL object names could be displayed with their library path or
> not, in edit mode.
> Advantages: 1. No need to make up ridiculous non-mnemonic names for
> objects which have nothing to do with their function, simply to avoid
> a dreaded name collision. 2. No more torture for users trying to
> figure out why patches don't work, especially for objects without
> documentation which shall remain unnamed here.
> Disadvantage(s): Not backwards compatible. However, the patch or
> abstraction can be easily edited as text to remove the offending
> path, and it STILL alerts the user to the need for the correct
> It's just a thought.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3767 bytes
Desc: not available
More information about the Pd-list