Re: [PD] [OT]Re: Preset management for Pd Vanilla

[Miller Puckette via Pd-list]

that's right - savestate just lets a patch add stuff to its parent
(calling) patch when the parent is saved, that is retrieved when reloaded
from a file.  I don't know of other meanings of "savestate" although the
name does (unfortunately) suggest that it's for object archiving ala
NeXTStep (and I think earlier from Smalltalk).

cheers
M

On Fri, Jan 22, 2021 at 03:05:02AM +, Jonathan Wilkes via Pd-list wrote:
>> On Thursday, January 21, 2021, 6:35:34 PM EST, cyrille henry 
>  wrote:  
>  > here we are :
> https://urldefense.com/v3/__https://xkcd.com/927/__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-OTEv7cY$
>  
> 
> This case seems more like the Lisp problem-- every single user has their own 
> non-standard, incompatible, and deeply personal solution to the problem.
> Also-- do I have it right that the only relevant native core class 
> "savestate" isn't about statesaving in its common parlance, but is instead a 
> callback hard-coded to the "save" event that writes a patch file to the 
> filesystem? That's what the guts looked like when I ported it to Purr Data, 
> but I haven't really used it yet.
> 
> -Jonathan
> 
> Le 21/01/2021 ?? 20:48, Antoine Rousseau a ??crit??:
> > You can also have a look to my "AutoPreset" system. It's available from 
> > deken. It's rather old, but that's what I use every day...
> > 
> > Le jeu. 21 janv. 2021 ?? 19:39, Alexandre Torres Porres  > > a ??crit??:
> > 
> >?? ?? Em qui., 21 de jan. de 2021 ??s 15:09, Alexandre Torres Porres 
> >mailto:por...@gmail.com>> escreveu:
> > 
> >?? ?? ?? ?? I??now included "import" and "export" functions so [savestate] 
> >can be used in conjunction
> > 
> > 
> >?? ?? Just making clear this design allows each instance to be saved with 
> >separate presets in a parent patch. Not that I find it crucial. I guess that 
> >2 sharing the same preset bank should be fine for most cases. So using a 
> >file to load and save inside the abstraction (as it was possible before) was 
> >kinda fine. So this is where I start to think I could be compromising my 
> >beloved "KISS" principle... but I was already thinking??import/export was 
> >nice to allow people to store these things in the patch rather than a file, 
> >so it's cool. It's versatile and still simple enough.
> > 
> >?? ?? ___
> >?? ?? Pd-list@lists.iem.at  mailing list
> >?? ?? UNSUBSCRIBE and account-management -> 
> >https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
> > 
> > 
> > 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
> >  
> > 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
>  
>   

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
>  




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [OT]Re: Preset management for Pd Vanilla

[Jonathan Wilkes via Pd-list]

 > On Thursday, January 21, 2021, 10:14:19 PM EST, Miller Puckette 
 >  wrote: 
 > that's right - savestate just lets a patch add stuff to its parent
(calling) patch when the parent is saved, that is retrieved when reloaded
from a file.  I don't know of other meanings of "savestate" although the
name does (unfortunately) suggest that it's for object archiving ala
NeXTStep (and I think earlier from Smalltalk).

At first glance "savestate" seemed like it might be related to "state saving," 
e.g., a core class that provides the hooks necessary to take a "snapshots" at 
will of system state without requiring the user to prepare the patch for that 
purpose ahead of time.

cheers
M

On Fri, Jan 22, 2021 at 03:05:02AM +, Jonathan Wilkes via Pd-list wrote:
>    > On Thursday, January 21, 2021, 6:35:34 PM EST, cyrille henry 
> wrote:  
>  > here we are :
> https://urldefense.com/v3/__https://xkcd.com/927/__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-OTEv7cY$
>  
> 
> This case seems more like the Lisp problem-- every single user has their own 
> non-standard, incompatible, and deeply personal solution to the problem.
> Also-- do I have it right that the only relevant native core class 
> "savestate" isn't about statesaving in its common parlance, but is instead a 
> callback hard-coded to the "save" event that writes a patch file to the 
> filesystem? That's what the guts looked like when I ported it to Purr Data, 
> but I haven't really used it yet.
> 
> -Jonathan
> 
> Le 21/01/2021 ?? 20:48, Antoine Rousseau a ??crit??:
> > You can also have a look to my "AutoPreset" system. It's available from 
> > deken. It's rather old, but that's what I use every day...
> > 
> > Le jeu. 21 janv. 2021 ?? 19:39, Alexandre Torres Porres  > > a ??crit??:
> > 
> >?? ?? Em qui., 21 de jan. de 2021 ??s 15:09, Alexandre Torres Porres 
> >mailto:por...@gmail.com>> escreveu:
> > 
> >?? ?? ?? ?? I??now included "import" and "export" functions so [savestate] 
> >can be used in conjunction
> > 
> > 
> >?? ?? Just making clear this design allows each instance to be saved with 
> >separate presets in a parent patch. Not that I find it crucial. I guess that 
> >2 sharing the same preset bank should be fine for most cases. So using a 
> >file to load and save inside the abstraction (as it was possible before) was 
> >kinda fine. So this is where I start to think I could be compromising my 
> >beloved "KISS" principle... but I was already thinking??import/export was 
> >nice to allow people to store these things in the patch rather than a file, 
> >so it's cool. It's versatile and still simple enough.
> > 
> >?? ?? ___
> >?? ?? Pd-list@lists.iem.at  mailing list
> >?? ?? UNSUBSCRIBE and account-management -> 
> >https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
> > 
> > 
> > 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
> >  
> > 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
>  
>  

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
>  

  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [OT]Re: Preset management for Pd Vanilla

[Jonathan Wilkes via Pd-list]

   > On Thursday, January 21, 2021, 6:35:34 PM EST, cyrille henry 
 wrote:  
 > here we are :
https://xkcd.com/927/

This case seems more like the Lisp problem-- every single user has their own 
non-standard, incompatible, and deeply personal solution to the problem.
Also-- do I have it right that the only relevant native core class "savestate" 
isn't about statesaving in its common parlance, but is instead a callback 
hard-coded to the "save" event that writes a patch file to the filesystem? 
That's what the guts looked like when I ported it to Purr Data, but I haven't 
really used it yet.

-Jonathan

Le 21/01/2021 à 20:48, Antoine Rousseau a écrit :
> You can also have a look to my "AutoPreset" system. It's available from 
> deken. It's rather old, but that's what I use every day...
> 
> Le jeu. 21 janv. 2021 à 19:39, Alexandre Torres Porres  > a écrit :
> 
>    Em qui., 21 de jan. de 2021 às 15:09, Alexandre Torres Porres 
>mailto:por...@gmail.com>> escreveu:
> 
>        I now included "import" and "export" functions so [savestate] can be 
>used in conjunction
> 
> 
>    Just making clear this design allows each instance to be saved with 
>separate presets in a parent patch. Not that I find it crucial. I guess that 2 
>sharing the same preset bank should be fine for most cases. So using a file to 
>load and save inside the abstraction (as it was possible before) was kinda 
>fine. So this is where I start to think I could be compromising my beloved 
>"KISS" principle... but I was already thinking import/export was nice to allow 
>people to store these things in the patch rather than a file, so it's cool. 
>It's versatile and still simple enough.
> 
>    ___
>    Pd-list@lists.iem.at  mailing list
>    UNSUBSCRIBE and account-management -> 
>https://lists.puredata.info/listinfo/pd-list
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [OT]Re: Preset management for Pd Vanilla

[Alexandre Torres Porres]

Em qui., 21 de jan. de 2021 às 20:36, cyrille henry  escreveu:

> here we are :
> https://xkcd.com/927/


AHAHAHAHAHAHAHAHAHAH

Spot on!
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [OT]Re: Preset management for Pd Vanilla

[cyrille henry]

here we are :
https://xkcd.com/927/


Le 21/01/2021 à 20:48, Antoine Rousseau a écrit :

You can also have a look to my "AutoPreset" system. It's available from deken. 
It's rather old, but that's what I use every day...

Le jeu. 21 janv. 2021 à 19:39, Alexandre Torres Porres mailto:por...@gmail.com>> a écrit :

Em qui., 21 de jan. de 2021 às 15:09, Alexandre Torres Porres mailto:por...@gmail.com>> escreveu:

I now included "import" and "export" functions so [savestate] can be 
used in conjunction


Just making clear this design allows each instance to be saved with separate presets 
in a parent patch. Not that I find it crucial. I guess that 2 sharing the same preset 
bank should be fine for most cases. So using a file to load and save inside the 
abstraction (as it was possible before) was kinda fine. So this is where I start to think 
I could be compromising my beloved "KISS" principle... but I was already 
thinking import/export was nice to allow people to store these things in the patch rather 
than a file, so it's cool. It's versatile and still simple enough.

___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

It's nice to see many system options, but this is making it a bit hard for
me in general checking it all out, as sometimes the idea of the process
adopted is not quite clear.

So may I please ask you people to check the general principle of my vanilla
prototype and the enhancements I'm providing in my else/abstraction? Just
tell me what you think of it in comparison to the other options you know.
Like what is the difference in the process, what functionality it provides
that I'm missing, things like that. It's just getting hard for me.

I'm hoping we can use this thread to discuss the possible strategies, the
general issues and challenges for preset systems.

What I'm usually seeing is that generally the preset alternatives are quite
complex and require a bunch of different objects and abstractions.
Sometimes you have particular objects to get particular data (like a float
or a symbol), and you need a connection to and from the float/symbol. Some
will give you a number GUI abstraction that handles this, but it's bad
cause you can't edit the size/color/easily.

Anyway, the simplest one I ran into is the one in Purr Data (which I
believe could be compiled for vanilla). It "only" has two objects, but even
so feels a bit over complicated to me in general. Every parameter needs
have a [preset_node] connected to it. My vanilla approach is similar as you
have one object for each parameter as well. It's just a proof of concept
with more functionalities to be added to, so it has less functionalities.
On the other hand, I'm only using one single object (instead of a 'hub' and
a 'node').

My solution for ELSE seems to be as simple as it can get, you can just one
[preset] object for any parameters of any type you want! It's basically
vanilla making use of [text] and [savestate], it only needs one external,
which is based on cyclone/grab. My concern is that I'm missing possible
strategies and use cases with it.

I'm also up for thinking about adding functionalities to vanilla so it can
provide a preset system on its own. But simple solutions that don't require
too many dependencies and just a single external is supposed to be more
than good enough for me. And it's not like we can't have a minimal but
functional preset strategy with vanilla just by getting all the values and
storing them in your patch. It's just that we want easier and more
convenient things and it can (and probably should) be external solutions.

What do you people think?

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[Jonathan Wilkes via Pd-list]

Em qui., 21 de jan. de 2021 às 14:33, Alexandre Torres Porres 
 escreveu:

> hmm, here's something I wasn't thinking, how to allow one to use the system 
> inside abstractions.
IIRC, the symbolic name given as an argument to preset_hub sets the scope for 
all the preset_node objects with the same name in that canvas (or inside any 
child abstractions, so long as they don't include their own preset_hub inside 
with the same name). So basically the same way 'var' sets scope in Javascript. 
That's why "$0" isn't needed.
Digression-- there's also a new [ab] class in Purr Data which saves 
abstractions with the parent file, and it uses a "canvas private" scoping 
mechanism so that "$0" isn't needed. (Although in that case, file-level 
abstractions are in their own scope for the sake of sanity.)
I find it really handy and would like to find a way to make struct names 
similarly scoped. (Perhaps with a flag.)
-Jonathan


  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[i...@hansroels.be]

On 1/21/21 6:15 PM, Alexandre Torres Porres wrote:
Em qui., 21 de jan. de 2021 às 07:44, i...@hansroels.be 
 > escreveu:


I didn't have time to look at your preset (...) but it seems
similar to the one that I created for my abunch abstractions


Yours actually seem different. And I couldn't really get it yet :) it 
doesn't seem you're using sends/receives, anyway, gotta spend more 
time to try and figure it out.


The negative side is that it takes a lot of work to implement...


you mean that it takes time for one to load it in a patch and set it up?


Yes. If you create new abstractions and patches you have to build them 
in such a way that they send and receive everything from the central 
preset system. I noticed that after a few years I was more and more 
reluctant/lazy to implement my own preset system in new abstractions. So 
I end up having abstractions with and without a preset system... and 
only when it's really necessary I embed my preset system into newer 
abstractions. Not really ideal...


Hans


Or that you took forever to make it? Well, one you did it, it's done :)



--

_www.hansroels.be_ /gsm:/ _+32 474 707849 _

_www.woeha.be_ /audio voor podcasts en installaties/

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[Antoine Rousseau]

You can also have a look to my "AutoPreset" system. It's available from
deken. It's rather old, but that's what I use every day...

Le jeu. 21 janv. 2021 à 19:39, Alexandre Torres Porres  a
écrit :

> Em qui., 21 de jan. de 2021 às 15:09, Alexandre Torres Porres <
> por...@gmail.com> escreveu:
>
>> I now included "import" and "export" functions so [savestate] can be used
>> in conjunction
>>
>
> Just making clear this design allows each instance to be saved with
> separate presets in a parent patch. Not that I find it crucial. I guess
> that 2 sharing the same preset bank should be fine for most cases. So using
> a file to load and save inside the abstraction (as it was possible before)
> was kinda fine. So this is where I start to think I could be compromising
> my beloved "KISS" principle... but I was already thinking import/export was
> nice to allow people to store these things in the patch rather than a file,
> so it's cool. It's versatile and still simple enough.
>
>> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

Em qui., 21 de jan. de 2021 às 15:09, Alexandre Torres Porres <
por...@gmail.com> escreveu:

> I now included "import" and "export" functions so [savestate] can be used
> in conjunction
>

Just making clear this design allows each instance to be saved with
separate presets in a parent patch. Not that I find it crucial. I guess
that 2 sharing the same preset bank should be fine for most cases. So using
a file to load and save inside the abstraction (as it was possible before)
was kinda fine. So this is where I start to think I could be compromising
my beloved "KISS" principle... but I was already thinking import/export was
nice to allow people to store these things in the patch rather than a file,
so it's cool. It's versatile and still simple enough.

>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

Em qui., 21 de jan. de 2021 às 07:44, i...@hansroels.be 
escreveu:

> I didn't have time to look at your preset (...) but it seems similar to
> the one that I created for my abunch abstractions
>

Yours actually seem different. And I couldn't really get it yet :) it
doesn't seem you're using sends/receives, anyway, gotta spend more time to
try and figure it out.


> The negative side is that it takes a lot of work to implement...
>

you mean that it takes time for one to load it in a patch and set it up? Or
that you took forever to make it? Well, one you did it, it's done :)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

Em qui., 21 de jan. de 2021 às 05:36, Albert Rafetseder <
albert.rafetseder...@univie.ac.at> escreveu:

> It saves presets as plain text files (which I appreciate for versioning),
> and allows for complex
> scenes/programs to be stored


What do you mean by "complex scenes/programs"?


> with namespaces and remote control and everything.
>

what's that? :) I downloaded and checked and didn't really get this.

acre/ds handles that differently: You'd do an explicit save into a separate
> file that you choose.
>

yes, I'm using [savestate] that allows you to save with the patch, no file
saving needed, but my vanilla abstraction can be expanded to read/write
files as well. I didn't expand on it cause I started working on this
variant for my library (else/preset), which doesn red/write files as well
(as the help file shows).

In general, the acre/ds system has a very similar structure than my vanilla
abstraction. That is you need sends and receives and separate objects for
separate parameters. I just think my take on it is simpler and I'm not sure
if I'm missing some more advanced functionality from acre/ds.

Em qui., 21 de jan. de 2021 às 08:28, IOhannes m zmölnig 
escreveu:

> acre/ds and kollabs are derived from the same original project.
> kollabs is much more elaborated, e.g. it includes support for scene
> transitions (and afaict, the state-saving part is vanilla only).
> acre/ds is much more minimalistic (which is a virtue as well)
>

Oh, I remember when this one came out and I checked it out. I just said
"wow, this is too complicated", got pretty scared and ran away. Of course
this is just a personal opinion and a matter of taste, but I do in fact
believe a minimalistic approach is quite virtuous. I'm all for the "KISS"
(keep it simple, stupid) principal. People shouldn't spend more than 2
minutes reading a help file :)

I'm proud and happy that my system for ELSE is quite simple. Only one
object (you can have more if you want, of course, in the case you want 2
subgroups or something) plus the [receive] objects that you'd normally have
anyway to send parameter values.

On the other hand, I don't wanna miss interesting features, so there's an
art of trying to make things simple, functional and powerful.

Anyway, by reading through, I don't get how kollabs can be used with simple
things like sending and retrieving values from a number box. I just missed
this in the extensive documentation. But if they share a common ground, it
seems there's no different/special principal that I'm missing.

And well, I see this one is also kind of like a sequencer, with
"transitions" and all. That makes you think "hmmm, that's nice". But I just
think one can use something like a "line" or something and a separate
preset group/object to control the transitions.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[IOhannes m zmölnig]

On 1/21/21 9:35 AM, Albert Rafetseder wrote:

Re this half of your email:


So I'm here to ask what people use in Pd Vanilla, be
it a pure vanilla solution or an external.


Reporting from a noob-user perspective, I have used acre's ds (data
storage) since it is included in VRR (Virtual Rehearsal Room) for preset
management:

https://git.iem.at/pd/acre/-/tree/master/ds
https://git.iem.at/vrr/vrr

AFAICT, it does what it says on the tin. It saves presets as plain text
files (which I appreciate for versioning), and allows for complex
scenes/programs to be stored, with namespaces and remote control and


and of course there is kollabs:

https://github.com/m---w/kollabs

acre/ds and kollabs are derived from the same original project.
kollabs is much more elaborated, e.g. it includes support for scene 
transitions (and afaict, the state-saving part is vanilla only).

acre/ds is much more minimalistic (which is a virtue as well)

gfdsar
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[Albert Rafetseder]

Re this half of your email:

> So I'm here to ask what people use in Pd Vanilla, be
> it a pure vanilla solution or an external.

Reporting from a noob-user perspective, I have used acre's ds (data
storage) since it is included in VRR (Virtual Rehearsal Room) for preset
management:

https://git.iem.at/pd/acre/-/tree/master/ds
https://git.iem.at/vrr/vrr

AFAICT, it does what it says on the tin. It saves presets as plain text
files (which I appreciate for versioning), and allows for complex
scenes/programs to be stored, with namespaces and remote control and
everything.

I didn't try to include acre/ds in my own patches yet.


One detail:

> Once you save the patch, the presets you saved get stored in
> the patch.

I think acre/ds handles that differently: You'd do an explicit save into
a separate file that you choose.

> You can check what's up in my repository for more details...
> https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd

Thanks for sharing, much appreciated!
  Albert.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list