Never really needed fancy preset management other than storing messages in a basic vanilla way. But I've seen people mention how Pd lacks a nice preset system. Not that I know what a fancy one actually needs since I never felt the demand. So I'm here to ask what people use in Pd Vanilla, be it a pure vanilla solution or an external. And also to ask what people miss.
This is what I came up with as a pure vanilla abstraction, it's based on [text] and [savestate]. Here's the thing: https://drive.google.com/file/d/1A0ISEJo5F1E578WHM1doo1n2CJAthonU/view?usp=s...
In short, the preset abstraction takes messages and stores them. You can have many of these on your patch and use them to recall presets for any parameters. It takes any kind of messages. I'm making use of built-in sends and receives in the number boxes to make the patch cleaner. Just think that you can have separate control of each parameter having its own preset or group all of them together globally, or a group here and another there, whatever... Once you save the patch, the presets you saved get stored in the patch.
As for my current idea for my ELSE library, I'm using an object similar to grab to take messages from [receive] objects. It's a development over this original vanilla abstraction. My first draft is this, I hope that sharing the screenshot give you a nice idea.
[image: Screen Shot 2021-01-21 at 04.47.42.png] You can check what's up in my repository for more details... https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd
cheers
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.
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
Em qui., 21 de jan. de 2021 às 05:36, Albert Rafetseder < albert.rafetseder+pd@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 zmoelnig@iem.at 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
Hi Alexandre,
I didn't have time to look at your preset system yet (I will though...) but it seems similar to the one that I created for my abunch abstractions (mine is based on the older [textfile] object and about 10 years old...). My preset system has been tested a lot in classrooms and performances and works well. It not only saves faders, toggles, etc. but also symbols (location of loaded sound files) and the content of arrays. You can also use two preset groups simultaneously in one patch. The negative side is that it takes a lot of work to implement...
If you want to have a look: download abunch at www.hansroels.be/abunch-eng.htm In the downloaded abunch folder open an example folder (with presets), for example 'ex2j-grainsample.pd' You can open the presets-help file for more explanation. There is also an extra example file (about simultaneous groups of different presets) 'ex1o-presetsystem.pd'
best, Hans
On 1/21/21 8:52 AM, Alexandre Torres Porres wrote:
Never really needed fancy preset management other than storing messages in a basic vanilla way. But I've seen people mention how Pd lacks a nice preset system. Not that I know what a fancy one actually needs since I never felt the demand. So I'm here to ask what people use in Pd Vanilla, be it a pure vanilla solution or an external. And also to ask what people miss. This is what I came up with as a pure vanilla abstraction, it's based on [text] and [savestate]. Here's the thing: https://drive.google.com/file/d/1A0ISEJo5F1E578WHM1doo1n2CJAthonU/view?usp=s...
In short, the preset abstraction takes messages and stores them. You can have many of these on your patch and use them to recall presets for any parameters. It takes any kind of messages. I'm making use of built-in sends and receives in the number boxes to make the patch cleaner. Just thinkthat you can have separate control of each parameter having its own preset or group all of them together globally, or a group here and another there, whatever... Once you save the patch, the presets you saved get stored in the patch. As for my current idea for my ELSE library, I'm using an object similar to grab to take messages from [receive] objects. It's a development over this original vanilla abstraction. My first draft is this, I hope that sharing the screenshot give you a nice idea. Screen Shot 2021-01-21 at 04.47.42.png You can check what's up in my repository for more details... https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em qui., 21 de jan. de 2021 às 07:44, info@hansroels.be info@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 :)
On 1/21/21 6:15 PM, Alexandre Torres Porres wrote:
Em qui., 21 de jan. de 2021 às 07:44, info@hansroels.be mailto:info@hansroels.be <info@hansroels.be mailto:info@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 abstractionsYours 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 :)
Just an FYI-- Purr Data has preset_hub and preset_node from Ivica's Pd-l2ork. I don't think it handles state transitions, but the UX is nice and works seamlessly across abstractions without requiring "$0" for symbolic names.
Best,Jonathan
On Thursday, January 21, 2021, 2:54:33 AM EST, Alexandre Torres Porres <porres@gmail.com> wrote:
Never really needed fancy preset management other than storing messages in a basic vanilla way. But I've seen people mention how Pd lacks a nice preset system. Not that I know what a fancy one actually needs since I never felt the demand. So I'm here to ask what people use in Pd Vanilla, be it a pure vanilla solution or an external. And also to ask what people miss. This is what I came up with as a pure vanilla abstraction, it's based on [text] and [savestate]. Here's the thing: https://drive.google.com/file/d/1A0ISEJo5F1E578WHM1doo1n2CJAthonU/view?usp=s... In short, the preset abstraction takes messages and stores them. You can have many of these on your patch and use them to recall presets for any parameters. It takes any kind of messages. I'm making use of built-in sends and receives in the number boxes to make the patch cleaner. Just think that you can have separate control of each parameter having its own preset or group all of them together globally, or a group here and another there, whatever... Once you save the patch, the presets you saved get stored in the patch.
As for my current idea for my ELSE library, I'm using an object similar to grab to take messages from [receive] objects. It's a development over this original vanilla abstraction. My first draft is this, I hope that sharing the screenshot give you a nice idea. You can check what's up in my repository for more details... https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Yeah, cool, sure, I'm aware, but thanks for pointing that out anyway though, it's good that we take that into consideration as well in this thread for comparing and checking out preset management systems for Pd. And why not even bring to the table preset features from other systems, like MAX? I'm actually looking into that as well...
I guess I should have mentioned that, but I just wanted to ask for other existing solutions available for vanilla, either as pure vanilla abstractions or anything that uses externals available in our ecosystem.
And while we're at it, it seems to me one could just get the code of preset_hub / preset_node and port the exact same thing and distribute as an external for vanilla, right? I'm assuming it doesn't require any special Purr Data modification. If so, I guess one thing to consider is that thing we recently discussed in the pd-dev list, that for in order of two objects sharing data and info, like I'm assuming preset_hub and preset_node do, you'd need a single binary library, or have something a single [preset] object and use Miller's trick that the argument will call the separate object (as in [preset hub] and [preset node]) - I like this idea better.
I just had a quick look at Purr's system though. It seems a bit more complex than I'd like, taking int consideration the same matter I pointed in the email I sent just before yours came in. But I'm gonna spend some more time on that too (as well as with other systems mentioned here, and maybe new ones yet to be mentioned) and see if I'm missing something cool I haven't thought of yet.
cheers
Em qui., 21 de jan. de 2021 às 14:17, Jonathan Wilkes jancsika@yahoo.com escreveu:
Just an FYI-- Purr Data has preset_hub and preset_node from Ivica's Pd-l2ork. I don't think it handles state transitions, but the UX is nice and works seamlessly across abstractions without requiring "$0" for symbolic names.
Best, Jonathan
On Thursday, January 21, 2021, 2:54:33 AM EST, Alexandre Torres Porres < porres@gmail.com> wrote:
Never really needed fancy preset management other than storing messages in a basic vanilla way. But I've seen people mention how Pd lacks a nice preset system. Not that I know what a fancy one actually needs since I never felt the demand. So I'm here to ask what people use in Pd Vanilla, be it a pure vanilla solution or an external. And also to ask what people miss.
This is what I came up with as a pure vanilla abstraction, it's based on [text] and [savestate]. Here's the thing: https://drive.google.com/file/d/1A0ISEJo5F1E578WHM1doo1n2CJAthonU/view?usp=s...
In short, the preset abstraction takes messages and stores them. You can have many of these on your patch and use them to recall presets for any parameters. It takes any kind of messages. I'm making use of built-in sends and receives in the number boxes to make the patch cleaner. Just think that you can have separate control of each parameter having its own preset or group all of them together globally, or a group here and another there, whatever... Once you save the patch, the presets you saved get stored in the patch.
As for my current idea for my ELSE library, I'm using an object similar to grab to take messages from [receive] objects. It's a development over this original vanilla abstraction. My first draft is this, I hope that sharing the screenshot give you a nice idea.
[image: Screen Shot 2021-01-21 at 04.47.42.png] You can check what's up in my repository for more details... https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em qui., 21 de jan. de 2021 às 14:33, Alexandre Torres Porres < porres@gmail.com> escreveu:
But I'm gonna spend some more time on that too (as well as with other systems mentioned here, and maybe new ones yet to be mentioned) and see if I'm missing something cool I haven't thought of yet.
Em qui., 21 de jan. de 2021 às 14:17, Jonathan Wilkes jancsika@yahoo.com
escreveu:
the UX is nice and works seamlessly across abstractions
hmm, here's something I wasn't thinking, how to allow one to use the system inside abstractions. One way that was already possible would be to have separate files to load in each abstraction, but I now included "import" and "export" functions so [savestate] can be used in conjunction (see screenshot below). I had to add an outlet for that, and also added a second outlet to send a bang when the preset is empty.
[image: Screen Shot 2021-01-21 at 15.07.47.png]
it's already been updated to the repository https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd
Hey Alexandre,
if interested take a look at my solution here: https://github.com/JRSV/RSVP.V3.full-vanilla perhaps a different approach, but works for me
On Thu, Jan 21, 2021 at 1:13 PM Alexandre Torres Porres porres@gmail.com wrote:
Em qui., 21 de jan. de 2021 às 14:33, Alexandre Torres Porres < porres@gmail.com> escreveu:
But I'm gonna spend some more time on that too (as well as with other systems mentioned here, and maybe new ones yet to be mentioned) and see if I'm missing something cool I haven't thought of yet.
Em qui., 21 de jan. de 2021 às 14:17, Jonathan Wilkes jancsika@yahoo.com
escreveu:
the UX is nice and works seamlessly across abstractions
hmm, here's something I wasn't thinking, how to allow one to use the system inside abstractions. One way that was already possible would be to have separate files to load in each abstraction, but I now included "import" and "export" functions so [savestate] can be used in conjunction (see screenshot below). I had to add an outlet for that, and also added a second outlet to send a bang when the preset is empty.
[image: Screen Shot 2021-01-21 at 15.07.47.png]
it's already been updated to the repository https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em qui., 21 de jan. de 2021 às 15:09, Alexandre Torres Porres < porres@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.
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 porres@gmail.com a écrit :
Em qui., 21 de jan. de 2021 às 15:09, Alexandre Torres Porres < porres@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
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 <porres@gmail.com mailto:porres@gmail.com> a écrit :
Em qui., 21 de jan. de 2021 às 15:09, Alexandre Torres Porres <porres@gmail.com <mailto:porres@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 <mailto: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
Em qui., 21 de jan. de 2021 às 20:36, cyrille henry ch@chnry.net escreveu:
here we are : https://xkcd.com/927/
AHAHAHAHAHAHAHAHAHAH
Spot on!
On Thursday, January 21, 2021, 6:35:34 PM EST, cyrille henry ch@chnry.net wrote:
here we are :
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 <porres@gmail.com mailto:porres@gmail.com> a écrit :
Em qui., 21 de jan. de 2021 às 15:09, Alexandre Torres Porres <porres@gmail.com mailto:porres@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 mailto: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
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 +0000, Jonathan Wilkes via Pd-list wrote:
On Thursday, January 21, 2021, 6:35:34 PM EST, cyrille henry ch@chnry.net wrote:
here we are :https://urldefense.com/v3/__https://xkcd.com/927/__;!!Mih3wA!R6uAxiWLBX_uU5C...
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 <porres@gmail.com mailto:porres@gmail.com> a ??crit??:
?? ?? Em qui., 21 de jan. de 2021 ??s 15:09, Alexandre Torres Porres <porres@gmail.com mailto:porres@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 mailto:Pd-list@lists.iem.at mailing list ?? ?? UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
On Thursday, January 21, 2021, 10:14:19 PM EST, Miller Puckette msp@ucsd.edu 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 +0000, Jonathan Wilkes via Pd-list wrote:
> On Thursday, January 21, 2021, 6:35:34 PM EST, cyrille henry ch@chnry.net wrote: > here we are : https://urldefense.com/v3/__https://xkcd.com/927/__;!!Mih3wA!R6uAxiWLBX_uU5C...
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 <porres@gmail.com mailto:porres@gmail.com> a ??crit??:
?? ?? Em qui., 21 de jan. de 2021 ??s 15:09, Alexandre Torres Porres <porres@gmail.com mailto:porres@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 mailto:Pd-list@lists.iem.at mailing list ?? ?? UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
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
Em qui., 21 de jan. de 2021 às 19:14, Alexandre Torres Porres
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 thought of a way to make my vanilla approach quite closer to my final design for ELSE. It'd require some ninja dynamic patching, but it'd be pretty pretty straight-forward if this happens https://github.com/pure-data/pure-data/pull/604 - this PR adds an inlet to [receive] so we can set receive names (there's another PR/issue we'd need to take care first),
The vanilla design would still need things like number boxes to have sends and receives to get and set preset values. Receive names would be passed as arguments and we'd have some naming conventions for send, like ending with "-set", so we don't need to pass them also as arguments (it'd be too much pollution in my opinion).
Proof of concept
[image: Screen Shot 2021-01-22 at 01.19.22.png] Not that I think we *need* 100% vanilla solutions everytime... but it's a nice exercise. And this is pretty much the same of my ELSE abstraction, it'd have the same features! The difference is that my ELSE design doesn't require the [send] objects. I'm just not doing this vanilla approach now because I don't wanna spend time doing ninja stuff. I can wait to see if we can get that PR that adds an inlet to receive before I revisit this.
The design seems pretty simple and powerful. As far as the other strategies go, I don't think I'm missing use cases or features of other current systems out there. There's the "morphing" or "interpolation" thing that I may be still neglecting and thinking that using things "line" objects is just as fine, but let's see. I'll also look into how max does interpolation, someone already told me that, I think I have an idea for that too.
cheers
Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres < porres@gmail.com> escreveu:
There's the "morphing" or "interpolation" thing that I may be still neglecting and thinking that using things "line" objects is just as fine, but let's see. I'll also look into how max does interpolation, someone already told me that, I think I have an idea for that too.
I neglected the fact that [line] doesn't work with lists :) so I created an object that does it called [morph]. Hence, this takes care of preset transitions. I don't think it's necessary to put this feature inside the preset object as it makes it more complicated and in the end it's good this is a separate object as it's also useful outside the preset system and can be used on its own to morph into different arrays and stuff.
I'm doing something similar for interpolation, with another object to allow one to manually interpolate between values and lists of values, also incorporating that feature from Max. This should all be up in my repository this weeked.
cheers
I'm revisiting this. I'm proud of my presets system in ELSE but I think Pd needs something natively. What do you people think and say?
cheers
Em sex., 22 de jan. de 2021 às 14:27, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres < porres@gmail.com> escreveu:
There's the "morphing" or "interpolation" thing that I may be still neglecting and thinking that using things "line" objects is just as fine, but let's see. I'll also look into how max does interpolation, someone already told me that, I think I have an idea for that too.
I neglected the fact that [line] doesn't work with lists :) so I created an object that does it called [morph]. Hence, this takes care of preset transitions. I don't think it's necessary to put this feature inside the preset object as it makes it more complicated and in the end it's good this is a separate object as it's also useful outside the preset system and can be used on its own to morph into different arrays and stuff.
I'm doing something similar for interpolation, with another object to allow one to manually interpolate between values and lists of values, also incorporating that feature from Max. This should all be up in my repository this weeked.
cheers
+1 for a native preset system. thats the one thing i miss thinking back of the times i used max/msp (particularily the morphing feature). advantage over else: it can then be used in PdParty e.g. :-)
cheers hans
Am 11.11.2023 um 06:47 schrieb Alexandre Torres Porres porres@gmail.com:
I'm revisiting this. I'm proud of my presets system in ELSE but I think Pd needs something natively. What do you people think and say?
cheers
Em sex., 22 de jan. de 2021 às 14:27, Alexandre Torres Porres porres@gmail.com escreveu: Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres porres@gmail.com escreveu: There's the "morphing" or "interpolation" thing that I may be still neglecting and thinking that using things "line" objects is just as fine, but let's see. I'll also look into how max does interpolation, someone already told me that, I think I have an idea for that too.
I neglected the fact that [line] doesn't work with lists :) so I created an object that does it called [morph]. Hence, this takes care of preset transitions. I don't think it's necessary to put this feature inside the preset object as it makes it more complicated and in the end it's good this is a separate object as it's also useful outside the preset system and can be used on its own to morph into different arrays and stuff.
I'm doing something similar for interpolation, with another object to allow one to manually interpolate between values and lists of values, also incorporating that feature from Max. This should all be up in my repository this weeked.
cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Else’s has morphing, interpolation, etc and is an abstraction that uses [savestate] and [text] mainly.
It also relies on an external, [retrieve], similar to [grab] from MAX. This one gets data from objects connected to named [receive] objects. One could make a vanilla version without it, but it’d be much more complicated. Or we could have a new [grab] / [retrieve] like object in Vanilla, and I could build a Vanilla external abstraction and bring my system to vanilla like that.
We maybe don’t even need a new object and could have something like an extra functionality in [send] where it can get things back. I think some net objects work like that and it would hopefully not be too weird or crazy, and maybe people would likewise abuse this for other use cases.
Seems like a very not much intrusive addition that opens the door for this. What do you people think?
Cheers
On Sat, 11 Nov 2023 at 08:39 KHM t.hartmann t.hartmann@khm.de wrote:
+1 as well, for a native preset system. Best would be the possibility for interpolation between values in various ways, from jump to customisable interpolation curves.
Dr. Tobias Hartmann Künstlerisch-Wissenschaftlicher Mitarbeiter / Assistant Professor
exMedia - Sound
Kunsthochschule für Medien Köln (KHM) Academy of Media Arts Cologne Peter-Welter-Platz 2 50676 Köln
t.hartmann@khm.de +49 (0) 221 20189 228
www.khm.de www.exmedia.khm.de
www.hartmanntobias.com
Am 11.11.2023 um 12:02 schrieb hans w. koch hansw.koch@gmail.com:
+1 for a native preset system. thats the one thing i miss thinking back of the times i used max/msp (particularily the morphing feature).
advantage over else: it can then be used in PdParty e.g. :-)
cheers hans
Am 11.11.2023 um 06:47 schrieb Alexandre Torres Porres porres@gmail.com:
I'm revisiting this. I'm proud of my presets system in ELSE but I think Pd needs something natively. What do you people think and say?
cheers
Em sex., 22 de jan. de 2021 às 14:27, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres < porres@gmail.com> escreveu:
There's the "morphing" or "interpolation" thing that I may be still neglecting and thinking that using things "line" objects is just as fine, but let's see. I'll also look into how max does interpolation, someone already told me that, I think I have an idea for that too.
I neglected the fact that [line] doesn't work with lists :) so I created an object that does it called [morph]. Hence, this takes care of preset transitions. I don't think it's necessary to put this feature inside the preset object as it makes it more complicated and in the end it's good this is a separate object as it's also useful outside the preset system and can be used on its own to morph into different arrays and stuff.
I'm doing something similar for interpolation, with another object to allow one to manually interpolate between values and lists of values, also incorporating that feature from Max. This should all be up in my repository this weeked.
cheers
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
Or yet a new functionality for [pdcontrol] if not in [send] or a whole new object
On Sat, 11 Nov 2023 at 16:08 Alexandre Torres Porres porres@gmail.com wrote:
Else’s has morphing, interpolation, etc and is an abstraction that uses [savestate] and [text] mainly.
It also relies on an external, [retrieve], similar to [grab] from MAX. This one gets data from objects connected to named [receive] objects. One could make a vanilla version without it, but it’d be much more complicated. Or we could have a new [grab] / [retrieve] like object in Vanilla, and I could build a Vanilla external abstraction and bring my system to vanilla like that.
We maybe don’t even need a new object and could have something like an extra functionality in [send] where it can get things back. I think some net objects work like that and it would hopefully not be too weird or crazy, and maybe people would likewise abuse this for other use cases.
Seems like a very not much intrusive addition that opens the door for this. What do you people think?
Cheers
On Sat, 11 Nov 2023 at 08:39 KHM t.hartmann t.hartmann@khm.de wrote:
+1 as well, for a native preset system. Best would be the possibility for interpolation between values in various ways, from jump to customisable interpolation curves.
Dr. Tobias Hartmann Künstlerisch-Wissenschaftlicher Mitarbeiter / Assistant Professor
exMedia - Sound
Kunsthochschule für Medien Köln (KHM) Academy of Media Arts Cologne Peter-Welter-Platz 2 50676 Köln
t.hartmann@khm.de +49 (0) 221 20189 228
www.khm.de www.exmedia.khm.de
www.hartmanntobias.com
Am 11.11.2023 um 12:02 schrieb hans w. koch hansw.koch@gmail.com:
+1 for a native preset system. thats the one thing i miss thinking back of the times i used max/msp (particularily the morphing feature).
advantage over else: it can then be used in PdParty e.g. :-)
cheers hans
Am 11.11.2023 um 06:47 schrieb Alexandre Torres Porres <porres@gmail.com
:
I'm revisiting this. I'm proud of my presets system in ELSE but I think Pd needs something natively. What do you people think and say?
cheers
Em sex., 22 de jan. de 2021 às 14:27, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres < porres@gmail.com> escreveu:
There's the "morphing" or "interpolation" thing that I may be still neglecting and thinking that using things "line" objects is just as fine, but let's see. I'll also look into how max does interpolation, someone already told me that, I think I have an idea for that too.
I neglected the fact that [line] doesn't work with lists :) so I created an object that does it called [morph]. Hence, this takes care of preset transitions. I don't think it's necessary to put this feature inside the preset object as it makes it more complicated and in the end it's good this is a separate object as it's also useful outside the preset system and can be used on its own to morph into different arrays and stuff.
I'm doing something similar for interpolation, with another object to allow one to manually interpolate between values and lists of values, also incorporating that feature from Max. This should all be up in my repository this weeked.
cheers
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
Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres < porres@gmail.com> escreveu:
Or yet a new functionality for [pdcontrol] if not in [send] or a whole new object
A "retrieve" method to [value] would actually make sense.
Anyway, I'm giving ideas and most probably most of you don't really know about my preset system in ELSE in detail. The key element is [savestate], which saves the data in a patch, which are values and receive destinations. So I'm not thinking of another object for preset management, just using this existing one for that, as a side product. The data is saved in a [text] object, which is the best plase to store such a thing and it's the 2nd key element per se.
The "retrieve" function is to "grab" the data from objects connected or bound to existing "receive" objects/symbols. This makes things much easier and I hope things are clearer.
[value] seems now like a good candidate for this functionality. It would require the injection of a lot of code for this, but maybe that's ok, not sure if this is a good reason to create a whole new object. And it fits into the idea of [value], which can already send a value to another object, so why can't it also 'grab'/'retrieve'?
And also, the external abstraction that I mentioned could also be part of the 'extra' library that comes with the Pd distribution, which already has some abstractions anyway. While we're at it, I was already hoping to include yet another abstraction there, a biquad coefficient calculator for the [biquad~] object.
cheers
On Sat, 11 Nov 2023 at 16:08 Alexandre Torres Porres porres@gmail.com wrote:
Else’s has morphing, interpolation, etc and is an abstraction that uses [savestate] and [text] mainly.
It also relies on an external, [retrieve], similar to [grab] from MAX. This one gets data from objects connected to named [receive] objects. One could make a vanilla version without it, but it’d be much more complicated. Or we could have a new [grab] / [retrieve] like object in Vanilla, and I could build a Vanilla external abstraction and bring my system to vanilla like that.
We maybe don’t even need a new object and could have something like an extra functionality in [send] where it can get things back. I think some net objects work like that and it would hopefully not be too weird or crazy, and maybe people would likewise abuse this for other use cases.
Seems like a very not much intrusive addition that opens the door for this. What do you people think?
Cheers
On Sat, 11 Nov 2023 at 08:39 KHM t.hartmann t.hartmann@khm.de wrote:
+1 as well, for a native preset system. Best would be the possibility for interpolation between values in various ways, from jump to customisable interpolation curves.
Dr. Tobias Hartmann Künstlerisch-Wissenschaftlicher Mitarbeiter / Assistant Professor
exMedia - Sound
Kunsthochschule für Medien Köln (KHM) Academy of Media Arts Cologne Peter-Welter-Platz 2 50676 Köln
t.hartmann@khm.de +49 (0) 221 20189 228
www.khm.de www.exmedia.khm.de
www.hartmanntobias.com
Am 11.11.2023 um 12:02 schrieb hans w. koch hansw.koch@gmail.com:
+1 for a native preset system. thats the one thing i miss thinking back of the times i used max/msp (particularily the morphing feature).
advantage over else: it can then be used in PdParty e.g. :-)
cheers hans
Am 11.11.2023 um 06:47 schrieb Alexandre Torres Porres <porres@gmail.com
:
I'm revisiting this. I'm proud of my presets system in ELSE but I think Pd needs something natively. What do you people think and say?
cheers
Em sex., 22 de jan. de 2021 às 14:27, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres < porres@gmail.com> escreveu:
There's the "morphing" or "interpolation" thing that I may be still neglecting and thinking that using things "line" objects is just as fine, but let's see. I'll also look into how max does interpolation, someone already told me that, I think I have an idea for that too.
I neglected the fact that [line] doesn't work with lists :) so I created an object that does it called [morph]. Hence, this takes care of preset transitions. I don't think it's necessary to put this feature inside the preset object as it makes it more complicated and in the end it's good this is a separate object as it's also useful outside the preset system and can be used on its own to morph into different arrays and stuff.
I'm doing something similar for interpolation, with another object to allow one to manually interpolate between values and lists of values, also incorporating that feature from Max. This should all be up in my repository this weeked.
cheers
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
I encourage Miller and the vanilla community to explore pd-l2ork's preset_hub and preset_node (see x_preset.c). It will require pd to adopt keeping glist consistent across various operations (cut/copy/undo/redo etc.). Once done, it allows for presetting of individual objects through various contexts that are both embeddable in the patch or can be saved into a file. Most importantly, this mechanism is able to distinguish between multiple instances of the same abstraction.
Best,
Ico
Yeah, sure, thanks, it's definitely worth looking since you already have it working and all. I'm all up for it of course. BTW, I cannot run the latest pd-l2ork on my 10.14.6 macOS, but I'm having a look at Purr Data to remember how it rolls... I was never able to really fully understand it.
Let me see if I have the slightest idea correctly. It seems you have [preset_hub] that manages (stores and recalls) presets. And you have the [preset_node] object that connects to GUIs and things you want to store data from. BTW, seems like a more "Vanilla like" convention would be a single [preset] object, and you could have [preset hub] and [preset node]. Anyway, if a change to the core is needed and a whole preset system layout is to be provided, I wonder if we could also have "preset node names" as built in symbols in GUI objects. And it'd be great if we could also have interpolation and morphing, with exponential curves, as in my system in ELSE, with the [preset hub] object.
cheers
Em dom., 12 de nov. de 2023 às 01:37, Ico Bukvic ico@vt.edu escreveu:
I encourage Miller and the vanilla community to explore pd-l2ork's preset_hub and preset_node (see x_preset.c). It will require pd to adopt keeping glist consistent across various operations (cut/copy/undo/redo etc.). Once done, it allows for presetting of individual objects through various contexts that are both embeddable in the patch or can be saved into a file. Most importantly, this mechanism is able to distinguish between multiple instances of the same abstraction.
Best,
Ico
-- Ivica Ico Bukvic, D.M.A. Director, Creativity + Innovation Director, Human-Centered Design iPhD Institute for Creativity, Arts, and Technology
Virginia Tech Creative Technologies in Music School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu
ci.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.net
On Sat, Nov 11, 2023 at 7:58 PM Alexandre Torres Porres porres@gmail.com wrote:
Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres < porres@gmail.com> escreveu:
Or yet a new functionality for [pdcontrol] if not in [send] or a whole new object
A "retrieve" method to [value] would actually make sense.
Anyway, I'm giving ideas and most probably most of you don't really know about my preset system in ELSE in detail. The key element is [savestate], which saves the data in a patch, which are values and receive destinations. So I'm not thinking of another object for preset management, just using this existing one for that, as a side product. The data is saved in a [text] object, which is the best plase to store such a thing and it's the 2nd key element per se.
The "retrieve" function is to "grab" the data from objects connected or bound to existing "receive" objects/symbols. This makes things much easier and I hope things are clearer.
[value] seems now like a good candidate for this functionality. It would require the injection of a lot of code for this, but maybe that's ok, not sure if this is a good reason to create a whole new object. And it fits into the idea of [value], which can already send a value to another object, so why can't it also 'grab'/'retrieve'?
And also, the external abstraction that I mentioned could also be part of the 'extra' library that comes with the Pd distribution, which already has some abstractions anyway. While we're at it, I was already hoping to include yet another abstraction there, a biquad coefficient calculator for the [biquad~] object.
cheers
On Sat, 11 Nov 2023 at 16:08 Alexandre Torres Porres porres@gmail.com wrote:
Else’s has morphing, interpolation, etc and is an abstraction that uses [savestate] and [text] mainly.
It also relies on an external, [retrieve], similar to [grab] from MAX. This one gets data from objects connected to named [receive] objects. One could make a vanilla version without it, but it’d be much more complicated. Or we could have a new [grab] / [retrieve] like object in Vanilla, and I could build a Vanilla external abstraction and bring my system to vanilla like that.
We maybe don’t even need a new object and could have something like an extra functionality in [send] where it can get things back. I think some net objects work like that and it would hopefully not be too weird or crazy, and maybe people would likewise abuse this for other use cases.
Seems like a very not much intrusive addition that opens the door for this. What do you people think?
Cheers
On Sat, 11 Nov 2023 at 08:39 KHM t.hartmann t.hartmann@khm.de wrote:
+1 as well, for a native preset system. Best would be the possibility for interpolation between values in various ways, from jump to customisable interpolation curves.
Dr. Tobias Hartmann Künstlerisch-Wissenschaftlicher Mitarbeiter / Assistant Professor
exMedia - Sound
Kunsthochschule für Medien Köln (KHM) Academy of Media Arts Cologne Peter-Welter-Platz 2 50676 Köln
t.hartmann@khm.de +49 (0) 221 20189 228
www.khm.de www.exmedia.khm.de
www.hartmanntobias.com
Am 11.11.2023 um 12:02 schrieb hans w. koch hansw.koch@gmail.com:
+1 for a native preset system. thats the one thing i miss thinking back of the times i used max/msp (particularily the morphing feature).
advantage over else: it can then be used in PdParty e.g. :-)
cheers hans
Am 11.11.2023 um 06:47 schrieb Alexandre Torres Porres < porres@gmail.com>:
I'm revisiting this. I'm proud of my presets system in ELSE but I think Pd needs something natively. What do you people think and say?
cheers
Em sex., 22 de jan. de 2021 às 14:27, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres < porres@gmail.com> escreveu:
There's the "morphing" or "interpolation" thing that I may be still neglecting and thinking that using things "line" objects is just as fine, but let's see. I'll also look into how max does interpolation, someone already told me that, I think I have an idea for that too.
I neglected the fact that [line] doesn't work with lists :) so I created an object that does it called [morph]. Hence, this takes care of preset transitions. I don't think it's necessary to put this feature inside the preset object as it makes it more complicated and in the end it's good this is a separate object as it's also useful outside the preset system and can be used on its own to morph into different arrays and stuff.
I'm doing something similar for interpolation, with another object to allow one to manually interpolate between values and lists of values, also incorporating that feature from Max. This should all be up in my repository this weeked.
cheers
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
So, what happens when you get to run Pd-L2Ork on 10.14?
Best,
Ico
this [image: Screen Shot 2023-11-12 at 10.31.08.png]
Em dom., 12 de nov. de 2023 às 09:40, Ico Bukvic ico@vt.edu escreveu:
So, what happens when you get to run Pd-L2Ork on 10.14?
Best,
Ico
-- Ivica Ico Bukvic, D.M.A. Director, Creativity + Innovation Institute for Creativity, Arts, and Technology
Virginia Tech Creative Technologies in Music School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu
ci.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.net
On Sun, Nov 12, 2023, 00:29 Alexandre Torres Porres porres@gmail.com wrote:
Yeah, sure, thanks, it's definitely worth looking since you already have it working and all. I'm all up for it of course. BTW, I cannot run the latest pd-l2ork on my 10.14.6 macOS, but I'm having a look at Purr Data to remember how it rolls... I was never able to really fully understand it.
Let me see if I have the slightest idea correctly. It seems you have [preset_hub] that manages (stores and recalls) presets. And you have the [preset_node] object that connects to GUIs and things you want to store data from. BTW, seems like a more "Vanilla like" convention would be a single [preset] object, and you could have [preset hub] and [preset node]. Anyway, if a change to the core is needed and a whole preset system layout is to be provided, I wonder if we could also have "preset node names" as built in symbols in GUI objects. And it'd be great if we could also have interpolation and morphing, with exponential curves, as in my system in ELSE, with the [preset hub] object.
cheers
Em dom., 12 de nov. de 2023 às 01:37, Ico Bukvic ico@vt.edu escreveu:
I encourage Miller and the vanilla community to explore pd-l2ork's preset_hub and preset_node (see x_preset.c). It will require pd to adopt keeping glist consistent across various operations (cut/copy/undo/redo etc.). Once done, it allows for presetting of individual objects through various contexts that are both embeddable in the patch or can be saved into a file. Most importantly, this mechanism is able to distinguish between multiple instances of the same abstraction.
Best,
Ico
-- Ivica Ico Bukvic, D.M.A. Director, Creativity + Innovation Director, Human-Centered Design iPhD Institute for Creativity, Arts, and Technology
Virginia Tech Creative Technologies in Music School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu
ci.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.net
On Sat, Nov 11, 2023 at 7:58 PM Alexandre Torres Porres < porres@gmail.com> wrote:
Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres < porres@gmail.com> escreveu:
Or yet a new functionality for [pdcontrol] if not in [send] or a whole new object
A "retrieve" method to [value] would actually make sense.
Anyway, I'm giving ideas and most probably most of you don't really know about my preset system in ELSE in detail. The key element is [savestate], which saves the data in a patch, which are values and receive destinations. So I'm not thinking of another object for preset management, just using this existing one for that, as a side product. The data is saved in a [text] object, which is the best plase to store such a thing and it's the 2nd key element per se.
The "retrieve" function is to "grab" the data from objects connected or bound to existing "receive" objects/symbols. This makes things much easier and I hope things are clearer.
[value] seems now like a good candidate for this functionality. It would require the injection of a lot of code for this, but maybe that's ok, not sure if this is a good reason to create a whole new object. And it fits into the idea of [value], which can already send a value to another object, so why can't it also 'grab'/'retrieve'?
And also, the external abstraction that I mentioned could also be part of the 'extra' library that comes with the Pd distribution, which already has some abstractions anyway. While we're at it, I was already hoping to include yet another abstraction there, a biquad coefficient calculator for the [biquad~] object.
cheers
On Sat, 11 Nov 2023 at 16:08 Alexandre Torres Porres porres@gmail.com wrote:
Else’s has morphing, interpolation, etc and is an abstraction that uses [savestate] and [text] mainly.
It also relies on an external, [retrieve], similar to [grab] from MAX. This one gets data from objects connected to named [receive] objects. One could make a vanilla version without it, but it’d be much more complicated. Or we could have a new [grab] / [retrieve] like object in Vanilla, and I could build a Vanilla external abstraction and bring my system to vanilla like that.
We maybe don’t even need a new object and could have something like an extra functionality in [send] where it can get things back. I think some net objects work like that and it would hopefully not be too weird or crazy, and maybe people would likewise abuse this for other use cases.
Seems like a very not much intrusive addition that opens the door for this. What do you people think?
Cheers
On Sat, 11 Nov 2023 at 08:39 KHM t.hartmann t.hartmann@khm.de wrote:
> +1 as well, for a native preset system. > Best would be the possibility for interpolation between values in > various ways, from jump to customisable interpolation curves. > > > > __________________________________________ > > Dr. Tobias Hartmann > Künstlerisch-Wissenschaftlicher Mitarbeiter / Assistant Professor > > exMedia - Sound > > Kunsthochschule für Medien Köln (KHM) > Academy of Media Arts Cologne > Peter-Welter-Platz 2 > 50676 Köln > > t.hartmann@khm.de > +49 (0) 221 20189 228 > > www.khm.de > www.exmedia.khm.de > > www.hartmanntobias.com > > Am 11.11.2023 um 12:02 schrieb hans w. koch hansw.koch@gmail.com: > > +1 for a native preset system. thats the one thing i miss thinking > back of the times i used max/msp (particularily the morphing feature). > > > advantage over else: it can then be used in PdParty e.g. :-) > > cheers > hans > > Am 11.11.2023 um 06:47 schrieb Alexandre Torres Porres < > porres@gmail.com>: > > > I'm revisiting this. I'm proud of my presets system in ELSE but I > think Pd needs something natively. What do you people think and say? > > > cheers > > > Em sex., 22 de jan. de 2021 às 14:27, Alexandre Torres Porres < > porres@gmail.com> escreveu: > > Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres < > porres@gmail.com> escreveu: > > There's the "morphing" or "interpolation" thing that I may be still > neglecting and thinking that using things "line" objects is just as fine, > but let's see. I'll also look into how max does interpolation, someone > already told me that, I think I have an idea for that too. > > > I neglected the fact that [line] doesn't work with lists :) so I > created an object that does it called [morph]. Hence, this takes care of > preset transitions. I don't think it's necessary to put this feature inside > the preset object as it makes it more complicated and in the end it's good > this is a separate object as it's also useful outside the preset system and > can be used on its own to morph into different arrays and stuff. > > > I'm doing something similar for interpolation, with another object > to allow one to manually interpolate between values and lists of values, > also incorporating that feature from Max. This should all be up in my > repository this weeked. > > > cheers > > _______________________________________________ > > 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
Interesting. Will investigate. Thanks.
Best,
Ico
So, Pd-L2Ork does ship with SDL library but was built on a newer OSX that does not support older OS versions. If you upgrade your OS to 11.x or newer, it should work just fine.
Does anyone else have this issue?
Best,
Ico
Forgot to add, you could build from scratch following the github instructions. Should take 15-30 minutes and should require only 2-3 commands to do so. I unfortunately do not have access to older OSX anymore.
Best,
Ico
Em qui., 21 de jan. de 2021 às 14:33, Alexandre Torres Porres porres@gmail.com 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
In addition, preset_hub is impervious to undo/redo and other actions and keeps track of all objects, offers ability to automate things by quickly cycling between presets, is able to save and load presets from a file without making the patch dirty, as is the case with L2Ork Tweeter, and can differentiate between multiple instances of the same abstraction, as is the case in the Pd-L2Ork K12 module.
Best,
Ico
On 1/21/2021 1:09 PM, Alexandre Torres Porres wrote:
Em qui., 21 de jan. de 2021 às 14:33, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> escreveu:
But I'm gonna spend some more time on that too (as well as with other systems mentioned here, and maybe new ones yet to be mentioned) and see if I'm missing something cool I haven't thought of yet. Em qui., 21 de jan. de 2021 às 14:17, Jonathan Wilkes <jancsika@yahoo.com <mailto:jancsika@yahoo.com>> escreveu: the UX is nice and works seamlessly across abstractionshmm, here's something I wasn't thinking, how to allow one to use the system inside abstractions. One way that was already possible would be to have separate files to load in each abstraction, but I now included "import" and "export" functions so [savestate] can be used in conjunction (see screenshot below). I had to add an outlet for that, and also added a second outlet to send a bang when the preset is empty.
Screen Shot 2021-01-21 at 15.07.47.png
it's already been updated to the repository https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
In addition, preset_hub is impervious to undo/redo and other actions and keeps track of all objects, offers ability to automate things by quickly cycling between presets, is able to save and load presets from a file without making the patch dirty, as is the case with L2Ork Tweeter, and can differentiate between multiple instances of the same abstraction, as is the case in the Pd-L2Ork K12 module. It can change scope on the fly, and many other things. As a result, in some ways it is even more flexible than the Max's pattrstorage. One thing that may be added later is also interpolation (akin to pattrstorage).
Best,
Ico
On 1/21/2021 1:09 PM, Alexandre Torres Porres wrote:
Em qui., 21 de jan. de 2021 às 14:33, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> escreveu:
But I'm gonna spend some more time on that too (as well as with other systems mentioned here, and maybe new ones yet to be mentioned) and see if I'm missing something cool I haven't thought of yet. Em qui., 21 de jan. de 2021 às 14:17, Jonathan Wilkes <jancsika@yahoo.com <mailto:jancsika@yahoo.com>> escreveu: the UX is nice and works seamlessly across abstractionshmm, here's something I wasn't thinking, how to allow one to use the system inside abstractions. One way that was already possible would be to have separate files to load in each abstraction, but I now included "import" and "export" functions so [savestate] can be used in conjunction (see screenshot below). I had to add an outlet for that, and also added a second outlet to send a bang when the preset is empty.
Screen Shot 2021-01-21 at 15.07.47.png
it's already been updated to the repository https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Albert Rafetseder -
Alexandre Torres Porres -
Antoine Rousseau -
cyrille henry -
hans w. koch -
Ico Bukvic -
info＠hansroels.be -
IOhannes m zmölnig -
Ivica Ico Bukvic
-
Jonathan Wilkes -
José Rafael Subía Valdez -
KHM t.hartmann -
Miller Puckette