On Thu, Nov 11, 2004 at 11:14:23PM +0100, Frank Barknecht wrote:

Hallo, B. Bogart hat gesagt: // B. Bogart wrote:

...

Anyone has a suggestion on how to force my pool data to save in the same dir as the parent patch of the abstraction, rather than the directory where the abstraction resides?

This question comes up very often, actually. In RRADical I use the only solution, that in my experience always works: use absolute paths like you get them from [open/savepanel]

I am convinced: relative paths are The Wrong Thing To Do In Pd (tm)

• except for some usecases like namespacing.

(It surely is possible to hack around the fact, that abstractions

ive always just done this, but i guess if you open another patch in the meantime it might be off..

#N canvas 0 0 454 304 12; #X obj 188 59 tot .; #X msg 188 38 query global pd_opendir .: list $pd_opendir; #X obj 188 80 print; #X connect 0 0 2 0; #X connect 1 0 0 0;

don't know their parents when they are written - for example using some Python scripting - but IMO it's hacking and thus should be left to Yves [excuse the silly Graz reference].)

Ciao

Frank Barknecht _ ______footils.org__

---

PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev

On Fri, 12 Nov 2004, Frank Barknecht wrote:

I'm sure, this is possible, for example also with "shell" and basename etc. I'd rather like to discuss, if having to know the parent path generally is needed, if it's a sign of a design error in a patch or if it's a design error in Pd, not to provide this funcionality? It's a very interesting question, which comes up regularily here.

I didn't give this too much thought, but I have the feeling that the current behaviour of abstractions, which is to use paths relative to where the abstraction is, is not the right thing to do.

Shouldn't all abstractions use paths that are relative to the main patch ? (e.g the one that was opened with "open").

I mean, the externals don't use the directory they are stored in (/usr/lib/pd/extra or whatever) as default path. They use the patches directory. Generally abstractions and externals should behave the same IMO.

Guenter

On Fri, 12 Nov 2004, Frank Barknecht wrote:

Yes, I thought so, too, one time, but this is not that easy. For example, I use several abstractions which use other, private abstractions in turn hidden in subdirectories or being next to the main abstracion, or which use saved textfiles or similar things, which I need to find somehow. The only way to find them -- so it seems to me -- is by using the path of the abstraction itself as reference. One cannot know the path of the parent in advance, and it will never be the same on different user's machines.

So I would prefer the default behaviour to stay, as it is currently, that is, reference "." as the directory of the abstraction.

However *if* an abstraction wants to know the parent's path, this should be made explicit, either by inlet things, or by an int/external for this purpose as a [pwd]

Well, yes, most probably changing a fundamental concept like I suggested is a bad idea.

I have hacked up obj1.c in order to provide the functionality, file is attached, use the makefile from doc/6.externs to compile it.

It does not give the path of the parent patch but of the main patch, but this can easily be changed in the new routine.

Guenter

Maybe [pwd] or [pwdir] should just print the directory containing a patch, [parentdir] could print the directory of the direct parent, and

sounds like a fun way to pollute..i guess 'pd' is already taken, but an object where yo could send it a message 'dsp' and it would return 0 or 1, or you could send it 'dsp 1', or 'samplerate' or 'pwd' etc...might be nice. theres surely a lot of info that could be dumped already, id like to know for example which patches/abstractions were needed to make some toplevel patch work, to make it easier to save to another dir or move to another machine etc...

[topdir] would print the main patch's dir?

Hallo, B. Bogart hat gesagt: // B. Bogart wrote:

I think your naming scheme makes a lot of sense Frank,

Is this stuff then soon going into CVS?

Well, it should, but I don't know the Pd internals enough to be able to maintain or extend this. May Guenther is and wants to?

Anyway, I see a final possible memorizing problem with [pwdir] and [parentdir], so I would suggest to use the following names:

[workdir] - directory where a patch is saved. [parentdir] - directory of the direct parent of an abstraction. [topdir] - directory of the toplevel patch (Guenther's "pwdir".)

Maybe these could also go into Pd main?

Another thing to check would be, if Max has similar objects, so we could get the names from Max. Maxers, please speak up now. ;)

Ciao

Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

How about:

[currentdir] [parentdir] [topdir]

As much as I am a fan of UNIX, I don't think we need to build on odd UNIXisms here.

It's too long, IMO, even longer than "parentdir". Maybe [thisdir]?

Ciao

Hallo, guenter geiger hat gesagt: // guenter geiger wrote:

I would rather go for one external with different messages, sort of like ix suggested. Like [current<, [top<, [parent<, [bang< would default to [top<. We could even let it accept additional float messages like 0 to get current, 1 to get parent, 2 to get "parent of parent" ... (Although I am not sure if this is of any use).

The name of the external could be something like "getdir", "directory", or hm,hm "folder" ?

Or: "pwd" ;)

I like that idea.

Ciao

Hallo, guenter geiger hat gesagt: // guenter geiger wrote:

My favorite is "getdir". If noone objects I will put it into CVS under this name by the end of this week.

[getdir] is fine with me, to. I would rather not take the [path] from Max, because a "path" in Pd already has a slightly different meaning (-path, -helppath")

Ciao

On Nov 11, 2004, at 5:14 PM, Frank Barknecht wrote:

Hallo, B. Bogart hat gesagt: // B. Bogart wrote:

...

Anyone has a suggestion on how to force my pool data to save in the same dir as the parent patch of the abstraction, rather than the directory where the abstraction resides?

This question comes up very often, actually. In RRADical I use the only solution, that in my experience always works: use absolute paths like you get them from [open/savepanel]

I am convinced: relative paths are The Wrong Thing To Do In Pd (tm)

• except for some usecases like namespacing.

(It surely is possible to hack around the fact, that abstractions don't know their parents when they are written - for example using some Python scripting - but IMO it's hacking and thus should be left to Yves [excuse the silly Graz reference].)

Absolute paths are a real hardship when it comes to making portable, cross-platform patches. Anyone know what needs to be done so that we can use relative paths everywhere in Pd?

.hc

________________________________________________________________________ ____

"Information wants to be free." -Stewart Brand

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Well quite a response here!

I'll contextualize the foundations of my question. Abstractions are obviously in existence to provide functionality that is re-usable in multiple patches. A parent patch contains these abstractions to create complex interconnections between them or provide and even higher level of functionality. Because the abstraction can be used in any number of contexts the saving of its state may have more to do with its parent patch than itself. Keep in mind I'm talking here as a developer of high-level abstractions that are meant to be used by new users in order to make the learning curve less steep and get them interested right off the bat, and making complex things without (yet) worrying about exactly how they work. PD as somewhere between a programming language and an application. My goal with pixelTANGO is that it is as usable as an application. This may put my problems at odds with other developers, but I do think the approach of high-level abstractions (and I mean so high-level that someone who knows nothing about PD can use them as an example) are extremely important to the future of PD's user base.

The bottom line is:

- - For the end user it is annoying to save a state-file in an absolute location manually. State-saving should be transparent so the user does not have to worry about how it works or where it stores files.

- - abstractions are used in the context of parents. I think it makes little sense that each abstraction has its own set of states that are not attached to the parent somehow. When you load the same abstraction in another patch you don't want it to still have states from its last parent. You might, but considering it is a different context, you probably don't.

- - The high-level meaning of a patch is in the top-most parent. This is where the ~ user spends performance time. The states of all the abstractions are intimately connected to this parent patch, and the collection of states for all abstractions are only useful for this particular patch (or performance mind-set). For this reason the pool has to be associated with the top-most parent.

What I was trying to do when writing the request was make memento do this:

* When you load a (parent) patch memento automatically loads the pool file saved next to the parent patch, which is assumed to be the one last used for this patch.

* The user continues to play with the patch, moving sliders and such. They can either re-load the initial states from the pool, or save the changes they have made over the previous pool.

When the patch is loaded it loads the last state-file used. The user does not ever choose a file to store the values. The usage of states if very transparent.

Now if you have a bunch of patches in one folder (as we usually do) then one patch would stomp over the "presents.dat" (or whatever it is named) created in another. So the ideal place to store the presents would be something like:

[relative top-parent path]/[parent-name]-presets.dat eg ./blah.pd saves ./blah-presents.pd

You email the blah.pd and the blah-present.dat file to a friend, then open the patch and like magic the presets are already loaded.

I don't know if I am on my own here in developing something like pixelTANGO but for me user-transparency is more important than developer elegance.

Well thats where I'm coming from.

I look forward to reading more ideas about these issues, in particular super-high-level abstractions meant for end-users (beginners even) that are transparent to use. (at least as much so as is possible.)

Frank: Now your seeing why I can't accept user-naming of abstractions for pixelTANGO.

B.

Frank Barknecht wrote: | Hallo, | Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: | | |>Absolute paths are a real hardship when it comes to making portable, |>cross-platform patches. Anyone know what needs to be done so that we |>can use relative paths everywhere in Pd? | | | In RRADical, I let the user choose the file as an absolute path from | the toplevel abstraction. Maybe I expressed myself a bit wrongly: | Relative paths are fine *inside* abstractions, because abstractions | actually have a known location in the filesystem called "." whereas if | you use an abstraction inside another patch (the parent) it is not | possible for the abstraction to know the path of that parent without | hacks. | | I also think, that in the interest of encapsulation childs shouldn't | have to know their parent's path. If you need to know the path of a | parent, then you should make that explicit and provide an inlet or a | method for it. This method can deal with absolute paths very easily. | In RRADical, the "FILE" button of "careGUI" is such a method. | | To be able to use relative paths everywhere, we would need to have a | Pd filesystem standard as reference. I don't see that coming soon or | ever. | | Ciao

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hey Frank,

The relationship between two word files and a PD patch and preset file are completely different. The preset file alters the behavior of the PD patch (one word document alters nothing in a second). A preset file is to a patch more like a word Macro is to a word file. The macro *could* be used outside the word document it was attached to, but its perdominate use is in the context within it was created. Macros are actually saved inside of word files. (hence so many virus problems!) The preset file is most useful in the patch from which the states were taken. Presets are so closesly aligned to the parent(main) patch it makes sense that the preset file would be stored near/next to it.

That being said it is true that we're only talking about an extra step in choosing the state file. The only reason I'm finding this one difficult to accept in pixelTANGO is that I worry about other such steps getting in the way of the user actually making something with the patch.

Indeed it would be too restrictive to make it the only way to save a state, BUT as an other way of saving states it does not take away any flexibilty since the method can be changed.

As for pixelTANGO what if the preset manager pt.presets (a wrapper for caretaker) makes a guess as to a "suggested" file name (using guenter's pwd for example) for presets. The user can either change the name or just leave it as the default and choose to load it (no automatic loading). Of course it would be nice to get the name of the top-level patch as well so that the suggestion could be [patch-name]-presets.dat saved inside of [pwd].

Any opinions on the above proposal?

Looking at Guenter's PWD code it looks like there is lots of useful information in the glist... What if there was an external/internal that made all this data accessible within pd? then "pwd" could be an abstraction of this external...

Ben

Frank Barknecht wrote: | Hallo, | B. Bogart hat gesagt: // B. Bogart wrote: | | |>Well quite a response here! | | | Because it's an important topic. | | |>The bottom line is: |> |>- For the end user it is annoying to save a state-file in an |>absolute location manually. State-saving should be transparent so |>the user does not have to worry about how it works or where it |>stores files. | | | But storing state files in absolute places is omnipresent in the | computer world! Even in music software. If you edit a text in Word or | write a track in Cubase, you always are free to save your work | whereever you want, not only next to some application binary. I iam | sure, that every software user is familiar with this concept. This | also is imporant for reusing one toplevel patch with different state | files. Analog to reusing Word to write more than one text document, | which generally is considered to be useful. ;) | | |>- abstractions are used in the context of parents. I think it makes |>little sense that each abstraction has its own set of states that |>are not attached to the parent somehow. | | | There are uses for this, too. For example data delivered with and used | inside an abstraction should be inside the abstraction (for example | different windows for grains etc. | | |>When you load the same abstraction in another patch you don't want |>it to still have states from its last parent. You might, but |>considering it is a different context, you probably don't. | | | In RRADical abstractions itself don't save or restore state *at all*, | only the [caretaker] does this and the [caretaker] belongs in the | toplevel patch. This is the Memento design pattern. | | |>- The high-level meaning of a patch is in the top-most parent. This |>is where the ~ user spends performance time. The states of all the |>abstractions are intimately connected to this parent patch, and the |>collection of states for all abstractions are only useful for this |>particular patch (or performance mind-set). For this reason the pool |>has to be associated with the top-most parent. | | | I agree, that's why it is this way in RRADical. The toplevel patch has | the caretaker object which is only responsible for storing and | restoring state files and only the caretaker is. (Actually it doesn't | have to be in the toplevel patch, it can be in its own separate | patch.) This separation between the state itself and the guy, who is | saving the state, maybe is the single most important concept in | Memento as a design pattern. | | |>What I was trying to do when writing the request was make memento do |>this: |> |>* When you load a (parent) patch memento automatically loads the |>pool file saved next to the parent patch, which is assumed to be the |>one last used for this patch. | | | First: Why? Word doesn't automatically load the last edited document. | | Second: This would be no real problem if the toplevel patch knows its | location: Its working directory is the current working directory. | Even if the toplevel patch is not in the current working directory, a | user can load a state file with [openpanel] like the user does it all | the time in Word. | | |>* The user continues to play with the patch, moving sliders and such. They can |>either re-load the initial states from the pool, or save the changes they have |>made over the previous pool. | | | This actually is, how it's done in Memento/RRADical. | | |>When the patch is loaded it loads the last state-file used. |>The user does not ever choose a file to store the values. | | | Why shouldn't he choose a file? It avoids needing a Word binary for | every .doc file. I really don't see, why having to open a state file | to work on is less useable than automatic loading of state files which | is, what I'd rather consider to be less usability. I mean, the state | file is just a single document describing a track or similar things. | | |>Now if you have a bunch of patches in one folder (as we usually do) then one |>patch would stomp over the "presents.dat" (or whatever it is named) created in |>another. So the ideal place to store the presents would be something like: |> |>[relative top-parent path]/[parent-name]-presets.dat |>eg ./blah.pd saves ./blah-presents.pd | | | I think, this is too restrictive. | | |>You email the blah.pd and the blah-present.dat file to a friend, then open the |>patch and like magic the presets are already loaded. | | | This can be achieved with a not too clever [loadbang] sendung some | messages to [careGUI], if we use something like Guenthers [pwd] | external. However [pwd] must sit in the top-most patch then. | | |>I don't know if I am on my own here in developing something like pixelTANGO but |>for me user-transparency is more important than developer elegance. | | | Actually I think, we are really not that far away in what we want to | achieve. To both of us, the user of our patches is the main target | audience, and our target user is not an experienced Pd user. I require | two more clicks to restore state. (BTW: I intend to make this only one | click actually, so LOAD will directly load a file and restore | settings.) However we do not agree on how automatic state saving and | restoring should happen, as should be clear from this discussion. | | |>Frank: Now your seeing why I can't accept user-naming of abstractions for |>pixelTANGO. | | | Well, yes, this looks consistent with your approach to setting state | file locations, however... ;) | | Ciao