[PD-dev] presets... why not?

[B. Bogart]

multiple state-sets would be very useful to me as well. (I think I mentioned
it in the early discussion) I was really thinking of something like preset
that allows you to change the preset with a click of the button. For me the
place for state files would be in the parent patch folder.

I'm really exited how fast this stuff is moving, I'm sure soon I'll have all
my state-saving dreams come true. (very very important for v_!)

Ben

It's probably a bit early to start plugin in memento into my v_
abtractions...

----- Original Message -----
From: "guenter geiger" <geiger at xdv.org>
To: "Frank Barknecht" <fbar at footils.org>
Cc: "pd-dev" <pd-dev at iem.kug.ac.at>
Sent: Monday, December 01, 2003 12:02 PM
Subject: Re: [PD-dev] presets... why not?


> On Mon, 1 Dec 2003, Frank Barknecht wrote:
> > Hallo,
> > Frank Barknecht hat gesagt: // Frank Barknecht wrote:
> >
> > > > I think that states should be saved relative to the patch directory,
> > > > which is the case with state.
> > >
> > > I disagree.
> >
> > I changed my mind: saving relative is okay, I think now. But still I
> > don't like, if a preset mechanism just proposes a filename
> > automatically, if nothing was specified.
> >
> > I'd prefer it, if the attempt to save a setting will ask the user for
> > a filename instead, just as Pd asks at the first "File -> Save". A way
> > to programmatically set the filename should be included, though.
> > Either through arguments or [set filename( messages.
>
> I think that the real difference in concept, between what are you
> describing and the state external is that
>
> 1) the state can be stored in memory
> 2) the state(s) are written into a single file
>
> I see several advantages in this approach:
> - possible to save several state sets
> - its faster to load new states (they are in memory already)
> - the directories don't get polluted by single state files
>
> The idea of having one file per state was to make it easier to
> handle single states outside of pd, renaming, copying etc.
> At the end I didnt use this feature too often, because it was easier
> to do everything from within pd.
>
> Guenter
>
> > --
> >  Frank Barknecht                               _ ______footils.org__
> >
> > _______________________________________________
> > PD-dev mailing list
> > PD-dev at iem.at
> > http://iem.at/cgi-bin/mailman/listinfo/pd-dev
> >
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev