Another problem -- still playing with [seq].
I wanted to make an abstraction to simplify start/stop of a [seq]. I saved the abstraction in a folder with some other abstractions of mine. Here's the relevant bit, minus [declare -lib cyclone]:
Now I find that a "read" message sent to the [seq] within the abstraction tries to resolve a relative path against the location where the abstraction is saved, not the location where the main patch is saved. The main patch and the test MIDI file are in the same folder; the abstraction is in a different folder (enabled by [declare -path ...]). The "read" message causes seq to open a file dialog (indicating that it couldn't find the file). If [seq] is outside the abstraction, no file access problem.
(Note that the "read" message is not being constructed within the abstraction. The abstraction as I designed it does have that option, but I tested it by sending "read ./filename.mid" to the abstraction's left inlet, to be forwarded directly to [seq], and the path resolved differently from the way I expected.)
This means that abstractions might not function transparently just like regular objects -- practically, there is a hierarchy of "real objects" and "fake objects," and the fake objects might trip you up in ways that real objects don't.
Is there a way to get the top-level patch to resolve the path before passing it into the abstraction?
FWIW I grepped the pd doc/ directory and there isn't much about handling paths.