[PD-dev] saving preset pools in the parent path, rather than the abstraction path?

B. Bogart ben at ekran.org
Fri Nov 12 17:52:57 CET 2004


-----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 SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBlOppjbOsMZSA25cRAryfAKCdNxXDpJ7UOHbbWQQjn8bxKEEI9ACghO8W
oEwh/ciVW+1J7fX0q7ixVSg=
=eX+w
-----END PGP SIGNATURE-----





More information about the Pd-dev mailing list