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.

hjh

@ddw_music [seq] does seem to be a particularly bad implementation.... expecting the files to be in the same folder as the binary and "popping up a file open dialog" if not found.
In windows [seq] is a separate binary.
If you copy the binary to your patch folder the patch might find that copy first?
But of course it could well be calling another cyclone external to implement the file search.
David.

@whale-av At least it's good to know that [seq]'s behavior is not expected.

Based on the other thread (about midifile timing), I'm probably going to abandon this idea and make the students use [text] anyway.

hjh

@ddw_music There was a tool a long time ago for batch stripping midi notes from a .mid file. Google should find it but it might well not run nowadays. I think it was for windows...... in about 2009/10?
Otherwise you could change the metro tempo in the mrpeach [midifile-help] but there is probably a limit to how fast it will go.
Maybe it could be run in Pd batch mode.
But your students would probably be happier typing in the notes....... especially if you gave them a virtual midi keyboard?
David.

@ddw_music Maybe you can use [pdcontrol] to get the path of the parent patch and use that to construct the message to [seq] within the abstraction.

@ingox "Maybe you can use [pdcontrol] to get the path of the parent patch and use that to construct the message to [seq] within the abstraction."

Yeah, that's probably the way -- if I ever come back to it, I could put that in.

hjh