Re: [PD] Preset management for Pd Vanilla

[Ico Bukvic]

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

-- 
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
i...@vt.edu

ci.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net



On Mon, Nov 13, 2023 at 2:24 PM Ico Bukvic  wrote:

> 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
>
> --
> 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
> i...@vt.edu
>
> ci.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
>
>
> On Sun, Nov 12, 2023 at 8:52 AM Ico Bukvic  wrote:
>
>> Interesting. Will investigate. Thanks.
>>
>> 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
>> i...@vt.edu
>>
>> ci.icat.vt.edu
>> l2ork.icat.vt.edu
>> ico.bukvic.net
>>
>> On Sun, Nov 12, 2023, 08:32 Alexandre Torres Porres 
>> wrote:
>>
>>> this [image: Screen Shot 2023-11-12 at 10.31.08.png]
>>>
>>> Em dom., 12 de nov. de 2023 às 09:40, Ico Bukvic  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
 i...@vt.edu

 ci.icat.vt.edu
 l2ork.icat.vt.edu
 ico.bukvic.net

 On Sun, Nov 12, 2023, 00:29 Alexandre Torres Porres 
 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 
> 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
>> i...@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 <
>> por...@gmail.com> wrote:
>>
>>>
>>>
>>> Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres <
>>> por...@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 

Re: [PD] Preset management for Pd Vanilla

[Ico Bukvic]

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

-- 
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
i...@vt.edu

ci.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net



On Sun, Nov 12, 2023 at 8:52 AM Ico Bukvic  wrote:

> Interesting. Will investigate. Thanks.
>
> 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
> i...@vt.edu
>
> ci.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
> On Sun, Nov 12, 2023, 08:32 Alexandre Torres Porres 
> wrote:
>
>> this [image: Screen Shot 2023-11-12 at 10.31.08.png]
>>
>> Em dom., 12 de nov. de 2023 às 09:40, Ico Bukvic  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
>>> i...@vt.edu
>>>
>>> ci.icat.vt.edu
>>> l2ork.icat.vt.edu
>>> ico.bukvic.net
>>>
>>> On Sun, Nov 12, 2023, 00:29 Alexandre Torres Porres 
>>> 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  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
> i...@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 <
> por...@gmail.com> wrote:
>
>>
>>
>> Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres <
>> por...@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.
>>

Re: [PD] Preset management for Pd Vanilla

[Ico Bukvic]

Interesting. Will investigate. Thanks.

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
i...@vt.edu

ci.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sun, Nov 12, 2023, 08:32 Alexandre Torres Porres 
wrote:

> this [image: Screen Shot 2023-11-12 at 10.31.08.png]
>
> Em dom., 12 de nov. de 2023 às 09:40, Ico Bukvic  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
>> i...@vt.edu
>>
>> ci.icat.vt.edu
>> l2ork.icat.vt.edu
>> ico.bukvic.net
>>
>> On Sun, Nov 12, 2023, 00:29 Alexandre Torres Porres 
>> 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  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
 i...@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 <
 por...@gmail.com> wrote:

>
>
> Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres <
> por...@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 

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

this [image: Screen Shot 2023-11-12 at 10.31.08.png]

Em dom., 12 de nov. de 2023 às 09:40, Ico Bukvic  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
> i...@vt.edu
>
> ci.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
> On Sun, Nov 12, 2023, 00:29 Alexandre Torres Porres 
> 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  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
>>> i...@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 <
>>> por...@gmail.com> wrote:
>>>


 Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres <
 por...@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 
> 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 

Re: [PD] Preset management for Pd Vanilla

[Ico Bukvic]

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
i...@vt.edu

ci.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sun, Nov 12, 2023, 00:29 Alexandre Torres Porres 
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  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
>> i...@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 
>> wrote:
>>
>>>
>>>
>>> Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres <
>>> por...@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 
 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 

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

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  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
> i...@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 
> wrote:
>
>>
>>
>> Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres <
>> por...@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 
>>> 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  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.
>
>
>
> 

Re: [PD] Preset management for Pd Vanilla

[Ico Bukvic]

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
i...@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 
wrote:

>
>
> Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres <
> por...@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 
>> 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  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.hartm...@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 :

 +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 <
 por...@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 <
 por...@gmail.com> escreveu:

 Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres <
 por...@gmail.com> 

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

Em sáb., 11 de nov. de 2023 às 16:11, Alexandre Torres Porres <
por...@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 
> 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  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.hartm...@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 :
>>>
>>> +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 >> >:
>>>
>>>
>>> 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 <
>>> por...@gmail.com> escreveu:
>>>
>>> Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres <
>>> por...@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

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

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 
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  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.hartm...@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 :
>>
>> +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 > >:
>>
>>
>> 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 <
>> por...@gmail.com> escreveu:
>>
>> Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres <
>> por...@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

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

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  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.hartm...@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 :
>
> +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 :
>
>
> 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 <
> por...@gmail.com> escreveu:
>
> Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres <
> por...@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

Re: [PD] Preset management for Pd Vanilla

[KHM t.hartmann via Pd-list]

+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 HartmannKünstlerisch-Wissenschaftlicher Mitarbeiter / Assistant ProfessorexMedia - SoundKunsthochschule für Medien Köln (KHM)Academy of Media Arts ColognePeter-Welter-Platz 250676 Kölnt.hartm...@khm.de+49 (0) 221 20189 228www.khm.dewww.exmedia.khm.dewww.hartmanntobias.comAm 11.11.2023 um 12:02 schrieb hans w. koch :+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. :-)cheershansAm 11.11.2023 um 06:47 schrieb Alexandre Torres Porres :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?cheersEm sex., 22 de jan. de 2021 às 14:27, Alexandre Torres Porres  escreveu:Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres  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 listUNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list___Pd-list@lists.iem.at mailing listUNSUBSCRIBE 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

[hans w. koch]

+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 :
> 
> 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 
>  escreveu:
> Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres 
>  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

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

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 <
por...@gmail.com> escreveu:

> Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres <
> por...@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

Re: [PD] Preset management for Pd Vanilla

[Alexandre Torres Porres]

Em sex., 22 de jan. de 2021 às 01:35, Alexandre Torres Porres <
por...@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

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