Dear list,
i'm having a kind of naive question. I've been using the glorious SSSAD abstraction (with [presetstore]) to save&load presets in a huge patch, but i'm missing more and more the ability to save&load presets for individual parts of the patch only. E.g. i have two sequencers in the patch, for which i wish to save&load presets independently. I know it's easy to send presets to individual parts when you have hand-made those presets, but what about saving? Is it that the current architecture of SSSAD does not allow this? Then is there a way to modify/develop it to make this possible? Or if it allows, how to do it? Any ideas highly appreciated!
Thanks, Andras
Yeah, I had the same problem and hacked out a osc-style prefix setting that is used to ignore objects without the prefix. This way I can work on two song patches open at the same time without cross saving.
Here is an updated object I was working on a few weeks ago that also includes file saving/loading:
There is also a gui wrapper, but I haven't updated it for the file operations yet.
On Nov 17, 2010, at 10:51 AM, András Murányi wrote:
Dear list,
i'm having a kind of naive question. I've been using the glorious SSSAD abstraction (with [presetstore]) to save&load presets in a huge patch, but i'm missing more and more the ability to save&load presets for individual parts of the patch only. E.g. i have two sequencers in the patch, for which i wish to save&load presets independently. I know it's easy to send presets to individual parts when you have hand-made those presets, but what about saving? Is it that the current architecture of SSSAD does not allow this? Then is there a way to modify/develop it to make this possible? Or if it allows, how to do it? Any ideas highly appreciated!
Thanks, Andras
Dan Wilcox danomatika.com robotcowboy.com
... ahh I forgot. This only works if you have the prefix for all the sssad objects. I use this: [sssad/sssad $1/feedback].
Of course you'd have to change all the patches .. which I did :P. But it's quite useful.
On Nov 17, 2010, at 7:55 PM, Dan Wilcox wrote:
Yeah, I had the same problem and hacked out a osc-style prefix setting that is used to ignore objects without the prefix. This way I can work on two song patches open at the same time without cross saving.
Here is an updated object I was working on a few weeks ago that also includes file saving/loading:
<rc-sssad_-help.pd> <rc-sssad_.pd>
There is also a gui wrapper, but I haven't updated it for the file operations yet.
On Nov 17, 2010, at 10:51 AM, András Murányi wrote:
Dear list,
i'm having a kind of naive question. I've been using the glorious SSSAD abstraction (with [presetstore]) to save&load presets in a huge patch, but i'm missing more and more the ability to save&load presets for individual parts of the patch only. E.g. i have two sequencers in the patch, for which i wish to save&load presets independently. I know it's easy to send presets to individual parts when you have hand-made those presets, but what about saving? Is it that the current architecture of SSSAD does not allow this? Then is there a way to modify/develop it to make this possible? Or if it allows, how to do it? Any ideas highly appreciated!
Thanks, Andras
Dan Wilcox danomatika.com robotcowboy.com
Dan Wilcox danomatika.com robotcowboy.com
Hi,
if you're using the latest version of sssad (which also is two years old or so), then you can use the "saveonly" message to save only the settings of one sssad instance. Also see how it's done in the rj library.
Frank
On Wed, Nov 17, 2010 at 04:51:20PM +0100, András Murányi wrote:
i'm having a kind of naive question. I've been using the glorious SSSAD abstraction (with [presetstore]) to save&load presets in a huge patch, but i'm missing more and more the ability to save&load presets for individual parts of the patch only. E.g. i have two sequencers in the patch, for which i wish to save&load presets independently. I know it's easy to send presets to individual parts when you have hand-made those presets, but what about saving? Is it that the current architecture of SSSAD does not allow this? Then is there a way to modify/develop it to make this possible? Or if it allows, how to do it? Any ideas highly appreciated!
Thanks, Andras
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks, this is interesting. it's just i don't seem to find these list.xyz objects... (bad Google!)
Andras
2010/11/18 Dan Wilcox danomatika@gmail.com
Yeah, I had the same problem and hacked out a osc-style prefix setting that is used to ignore objects without the prefix. This way I can work on two song patches open at the same time without cross saving.
Here is an updated object I was working on a few weeks ago that also includes file saving/loading:
There is also a gui wrapper, but I haven't updated it for the file operations yet.
On Nov 17, 2010, at 10:51 AM, András Murányi wrote:
Dear list,
i'm having a kind of naive question. I've been using the glorious SSSAD abstraction (with [presetstore]) to save&load presets in a huge patch, but i'm missing more and more the ability to save&load presets for individual parts of the patch only. E.g. i have two sequencers in the patch, for which i wish to save&load presets independently. I know it's easy to send presets to individual parts when you have hand-made those presets, but what about saving? Is it that the current architecture of SSSAD does not allow this? Then is there a way to modify/develop it to make this possible? Or if it allows, how to do it? Any ideas highly appreciated!
Thanks, Andras
Dan Wilcox danomatika.com robotcowboy.com
Cool, i was wandering around in the rj lib but i couldn't find how this thing works. Can you just tell me in a nutshell please?
Andras
On Thu, Nov 18, 2010 at 4:26 PM, Frank Barknecht fbar@footils.org wrote:
Hi,
if you're using the latest version of sssad (which also is two years old or so), then you can use the "saveonly" message to save only the settings of one sssad instance. Also see how it's done in the rj library.
Ciao
Frank
On Wed, Nov 17, 2010 at 04:51:20PM +0100, András Murányi wrote:
i'm having a kind of naive question. I've been using the glorious SSSAD abstraction (with [presetstore]) to save&load presets in a huge patch, but i'm missing more and more the
ability
to save&load presets for individual parts of the patch only. E.g. i have
two
sequencers in the patch, for which i wish to save&load presets independently. I know it's easy to send presets to individual parts when
you
have hand-made those presets, but what about saving? Is it that the current architecture of SSSAD does not allow this? Then is there a way to modify/develop it to make this possible? Or if it allows,
how
to do it? Any ideas highly appreciated!
Hi,
On Thu, Nov 25, 2010 at 03:28:01AM +0100, András Murányi wrote:
Cool, i was wandering around in the rj lib but i couldn't find how this thing works. Can you just tell me in a nutshell please?
yeah, it's a bit convoluted, to make it play nice in the background without a user ever having to see a single sssad object ...
Anyway the real interesting feature you will like is not so much the "saveonly" message but local saving which is enabled by adding something like "$0" as second argument to your [sssad] objects. Such local sssad objects cannot be controlled via sending to "SSSAD_ADMIN" anymore! Instead you have to send to "$0-SSSAD_ADMIN".
In rj, the [u_sssad] objects are copies of sssad.pd and they are hidden in [u_dispatch] objects. These objects are in almost every rj abstraction and handle two things: Dispatching of "tagged messages" from an inlet to local receivers and saving the sssad-parameters.
For example a [u_dispatch $0 freq] will turn messages like "freq 440" into a "440" sent to [s $0-freq] and it will also save "440" into a local(!) sssad-parameter called "freq" that is local to the value of $0.
Now a second utility abstraction, [u_loader] will build a bridge between these local sssads with their $0-SSSAD_ADMIN receivers and two global receivers called RJ_SCENE_LOAD and RJ_SCENE_SAVE. Actually these are seldomly used in rjdj scenes.
A typical idiom to get the state of all sssads in one abstraction is to send "save" to the $0-SSSAD_ADMIN in ony abstraction, then collect all the responses into messages and save these into message boxes. This is handled inside of [u_loader] and can be seen all over the rj library, expecially in Andy's synths like s_ejun or s_cwc.
If this sounds too complicated and you want to just have a presettable abstraction, you just need to do this:
3.1) Optionally: Connect [u_loader]'s outlet to an outlet and route incoming "save" messages to its inlet to save settings in the parent patch, e.g. with [u_cocollect] 4) Call you abstractions with unique tags as first argument
Now try sending stuff to RJ_SCENE_SAVE and RJ_SCENE_LOAD and to the inlets of your abstractions.
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Thu, Nov 25, 2010 at 10:19 AM, Frank Barknecht fbar@footils.org wrote:
Hi,
On Thu, Nov 25, 2010 at 03:28:01AM +0100, András Murányi wrote:
Cool, i was wandering around in the rj lib but i couldn't find how this
thing
works. Can you just tell me in a nutshell please?
yeah, it's a bit convoluted, to make it play nice in the background without a user ever having to see a single sssad object ...
Anyway the real interesting feature you will like is not so much the "saveonly" message but local saving which is enabled by adding something like "$0" as second argument to your [sssad] objects. Such local sssad objects cannot be controlled via sending to "SSSAD_ADMIN" anymore! Instead you have to send to "$0-SSSAD_ADMIN".
In rj, the [u_sssad] objects are copies of sssad.pd and they are hidden in [u_dispatch] objects. These objects are in almost every rj abstraction and handle two things: Dispatching of "tagged messages" from an inlet to local receivers and saving the sssad-parameters.
For example a [u_dispatch $0 freq] will turn messages like "freq 440" into a "440" sent to [s $0-freq] and it will also save "440" into a local(!) sssad-parameter called "freq" that is local to the value of $0.
Now a second utility abstraction, [u_loader] will build a bridge between these local sssads with their $0-SSSAD_ADMIN receivers and two global receivers called RJ_SCENE_LOAD and RJ_SCENE_SAVE. Actually these are seldomly used in rjdj scenes.
A typical idiom to get the state of all sssads in one abstraction is to send "save" to the $0-SSSAD_ADMIN in ony abstraction, then collect all the responses into messages and save these into message boxes. This is handled inside of [u_loader] and can be seen all over the rj library, expecially in Andy's synths like s_ejun or s_cwc.
If this sounds too complicated and you want to just have a presettable abstraction, you just need to do this:
- add a [u_loader abstractionname-$1 $0] object
- add a [u_dispatch $0 parametername] object for every parameter
- daisychain all [u_dispatch] with connections and connect the first one
to an inlet. 3.1) Optionally: Connect [u_loader]'s outlet to an outlet and route incoming "save" messages to its inlet to save settings in the parent patch, e.g. with [u_cocollect] 4) Call you abstractions with unique tags as first argument
Now try sending stuff to RJ_SCENE_SAVE and RJ_SCENE_LOAD and to the inlets of your abstractions.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Huh, I'm trying to pick this up (after 3 years...) Honestly, currently my IQ seems to be less than satisfactory to understand and utilize the advice. (It's also almost 40 degrees C here so I'll have to think out loud...)
http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad)
see/understand how to save and load presets exclusive for an abstraction instance.
saving for an abstraction? (eventually using [presetstore]... which I have attached because it's not hosted anywhere any more)?
SSSAD), or I couldn't get away without all that patching that is in u_loader, u_dispatch, u_cocollect etc?
...sorry for the dependent mental state in which I am! :-o
András
On 07/29/2013 07:50 AM, András Murányi wrote:
On Thu, Nov 25, 2010 at 10:19 AM, Frank Barknecht <fbar@footils.org mailto:fbar@footils.org> wrote:
Hi, On Thu, Nov 25, 2010 at 03:28:01AM +0100, András Murányi wrote: > Cool, i was wandering around in the rj lib but i couldn't find how this thing > works. Can you just tell me in a nutshell please? yeah, it's a bit convoluted, to make it play nice in the background without a user ever having to see a single sssad object ... Anyway the real interesting feature you will like is not so much the "saveonly" message but local saving which is enabled by adding something like "$0" as second argument to your [sssad] objects. Such local sssad objects cannot be controlled via sending to "SSSAD_ADMIN" anymore! Instead you have to send to "$0-SSSAD_ADMIN". In rj, the [u_sssad] objects are copies of sssad.pd and they are hidden in [u_dispatch] objects. These objects are in almost every rj abstraction and handle two things: Dispatching of "tagged messages" from an inlet to local receivers and saving the sssad-parameters. For example a [u_dispatch $0 freq] will turn messages like "freq 440" into a "440" sent to [s $0-freq] and it will also save "440" into a local(!) sssad-parameter called "freq" that is local to the value of $0. Now a second utility abstraction, [u_loader] will build a bridge between these local sssads with their $0-SSSAD_ADMIN receivers and two global receivers called RJ_SCENE_LOAD and RJ_SCENE_SAVE. Actually these are seldomly used in rjdj scenes. A typical idiom to get the state of all sssads in one abstraction is to send "save" to the $0-SSSAD_ADMIN in ony abstraction, then collect all the responses into messages and save these into message boxes. This is handled inside of [u_loader] and can be seen all over the rj library, expecially in Andy's synths like s_ejun or s_cwc. If this sounds too complicated and you want to just have a presettable abstraction, you just need to do this: 1) add a [u_loader abstractionname-$1 $0] object 2) add a [u_dispatch $0 parametername] object for every parameter 3) daisychain all [u_dispatch] with connections and connect the first one to an inlet. 3.1) Optionally: Connect [u_loader]'s outlet to an outlet and route incoming "save" messages to its inlet to save settings in the parent patch, e.g. with [u_cocollect] 4) Call you abstractions with unique tags as first argument Now try sending stuff to RJ_SCENE_SAVE and RJ_SCENE_LOAD and to the inlets of your abstractions. Ciao -- Frank Barknecht Do You RjDj.me? _ ______footils.org__
Huh, I'm trying to pick this up (after 3 years...) Honestly, currently my IQ seems to be less than satisfactory to understand and utilize the advice. (It's also almost 40 degrees C here so I'll have to think out loud...)
- is the SSSAD in s-abstractions recent enough for these tricks?
(http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad)
- is there an example patch of SSSAD local saving available? i just
wish to see/understand how to save and load presets exclusive for an abstraction instance.
- or, please, is it possible to list the steps of creating SSSAD local
saving for an abstraction? (eventually using [presetstore]... which I have attached because it's not hosted anywhere any more)?
- is at viable at all to avoid using rjlib for this (and to use 'pure'
SSSAD), or I couldn't get away without all that patching that is in u_loader, u_dispatch, u_cocollect etc?
...sorry for the dependent mental state in which I am! :-o
I don't think it's your mental state. Those tools are clunky.
Have you looked at Ivica's [preset_hub] in Pd-l2ork? You simply name the [preset_hub], and all the [preset_node] objects with the same name on that canvas or a child of it (including abstractions) work together. No need to use dollarsign arguments at all. All state is saved with the patch and adding/removing nodes works seamlessly, even with infinite undo.
His preset system even makes an automatic, hidden connection back into the [preset_node] so you don't get crossed wires.
-Jonathan
András
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Jul 29, 2013 at 7:48 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 07/29/2013 07:50 AM, András Murányi wrote:
On Thu, Nov 25, 2010 at 10:19 AM, Frank Barknecht fbar@footils.orgwrote:
Hi,
On Thu, Nov 25, 2010 at 03:28:01AM +0100, András Murányi wrote:
Cool, i was wandering around in the rj lib but i couldn't find how this
thing
works. Can you just tell me in a nutshell please?
yeah, it's a bit convoluted, to make it play nice in the background without a user ever having to see a single sssad object ...
Anyway the real interesting feature you will like is not so much the "saveonly" message but local saving which is enabled by adding something like "$0" as second argument to your [sssad] objects. Such local sssad objects cannot be controlled via sending to "SSSAD_ADMIN" anymore! Instead you have to send to "$0-SSSAD_ADMIN".
In rj, the [u_sssad] objects are copies of sssad.pd and they are hidden in [u_dispatch] objects. These objects are in almost every rj abstraction and handle two things: Dispatching of "tagged messages" from an inlet to local receivers and saving the sssad-parameters.
For example a [u_dispatch $0 freq] will turn messages like "freq 440" into a "440" sent to [s $0-freq] and it will also save "440" into a local(!) sssad-parameter called "freq" that is local to the value of $0.
Now a second utility abstraction, [u_loader] will build a bridge between these local sssads with their $0-SSSAD_ADMIN receivers and two global receivers called RJ_SCENE_LOAD and RJ_SCENE_SAVE. Actually these are seldomly used in rjdj scenes.
A typical idiom to get the state of all sssads in one abstraction is to send "save" to the $0-SSSAD_ADMIN in ony abstraction, then collect all the responses into messages and save these into message boxes. This is handled inside of [u_loader] and can be seen all over the rj library, expecially in Andy's synths like s_ejun or s_cwc.
If this sounds too complicated and you want to just have a presettable abstraction, you just need to do this:
- add a [u_loader abstractionname-$1 $0] object
- add a [u_dispatch $0 parametername] object for every parameter
- daisychain all [u_dispatch] with connections and connect the first one
to an inlet. 3.1) Optionally: Connect [u_loader]'s outlet to an outlet and route incoming "save" messages to its inlet to save settings in the parent patch, e.g. with [u_cocollect] 4) Call you abstractions with unique tags as first argument
Now try sending stuff to RJ_SCENE_SAVE and RJ_SCENE_LOAD and to the inlets of your abstractions.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Huh, I'm trying to pick this up (after 3 years...) Honestly, currently my IQ seems to be less than satisfactory to understand and utilize the advice. (It's also almost 40 degrees C here so I'll have to think out loud...)
- is the SSSAD in s-abstractions recent enough for these tricks? (
http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad )
- is there an example patch of SSSAD local saving available? i just wish
to see/understand how to save and load presets exclusive for an abstraction instance.
- or, please, is it possible to list the steps of creating SSSAD local
saving for an abstraction? (eventually using [presetstore]... which I have attached because it's not hosted anywhere any more)?
- is at viable at all to avoid using rjlib for this (and to use 'pure'
SSSAD), or I couldn't get away without all that patching that is in u_loader, u_dispatch, u_cocollect etc?
...sorry for the dependent mental state in which I am! :-o
I don't think it's your mental state. Those tools are clunky.
Have you looked at Ivica's [preset_hub] in Pd-l2ork? You simply name the [preset_hub], and all the [preset_node] objects with the same name on that canvas or a child of it (including abstractions) work together. No need to use dollarsign arguments at all. All state is saved with the patch and adding/removing nodes works seamlessly, even with infinite undo.
His preset system even makes an automatic, hidden connection back into the [preset_node] so you don't get crossed wires.
-Jonathan
Now that you told it, I gave myself a shot of it. Mmmmmm...! Simple and fast and feels so good. However... I'm afraid of locking myself in pd-l2ork. That would mean that my songs are basically in l2ork. Where does this thing store its data? Is it possible to dump it out in raw form? On the other hand, you've been using l2ork for a while, right? Can I ask you "how does it feel", do you feel locked in, etc? You no miss 0.43 plugins...?!
Thanks,
András
On 07/29/2013 02:49 PM, András Murányi wrote:
On Mon, Jul 29, 2013 at 7:48 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
On 07/29/2013 07:50 AM, András Murányi wrote:
On Thu, Nov 25, 2010 at 10:19 AM, Frank Barknecht <fbar@footils.org <mailto:fbar@footils.org>> wrote: Hi, On Thu, Nov 25, 2010 at 03:28:01AM +0100, András Murányi wrote: > Cool, i was wandering around in the rj lib but i couldn't find how this thing > works. Can you just tell me in a nutshell please? yeah, it's a bit convoluted, to make it play nice in the background without a user ever having to see a single sssad object ... Anyway the real interesting feature you will like is not so much the "saveonly" message but local saving which is enabled by adding something like "$0" as second argument to your [sssad] objects. Such local sssad objects cannot be controlled via sending to "SSSAD_ADMIN" anymore! Instead you have to send to "$0-SSSAD_ADMIN". In rj, the [u_sssad] objects are copies of sssad.pd and they are hidden in [u_dispatch] objects. These objects are in almost every rj abstraction and handle two things: Dispatching of "tagged messages" from an inlet to local receivers and saving the sssad-parameters. For example a [u_dispatch $0 freq] will turn messages like "freq 440" into a "440" sent to [s $0-freq] and it will also save "440" into a local(!) sssad-parameter called "freq" that is local to the value of $0. Now a second utility abstraction, [u_loader] will build a bridge between these local sssads with their $0-SSSAD_ADMIN receivers and two global receivers called RJ_SCENE_LOAD and RJ_SCENE_SAVE. Actually these are seldomly used in rjdj scenes. A typical idiom to get the state of all sssads in one abstraction is to send "save" to the $0-SSSAD_ADMIN in ony abstraction, then collect all the responses into messages and save these into message boxes. This is handled inside of [u_loader] and can be seen all over the rj library, expecially in Andy's synths like s_ejun or s_cwc. If this sounds too complicated and you want to just have a presettable abstraction, you just need to do this: 1) add a [u_loader abstractionname-$1 $0] object 2) add a [u_dispatch $0 parametername] object for every parameter 3) daisychain all [u_dispatch] with connections and connect the first one to an inlet. 3.1) Optionally: Connect [u_loader]'s outlet to an outlet and route incoming "save" messages to its inlet to save settings in the parent patch, e.g. with [u_cocollect] 4) Call you abstractions with unique tags as first argument Now try sending stuff to RJ_SCENE_SAVE and RJ_SCENE_LOAD and to the inlets of your abstractions. Ciao -- Frank Barknecht Do You RjDj.me? _ ______footils.org__ Huh, I'm trying to pick this up (after 3 years...) Honestly, currently my IQ seems to be less than satisfactory to understand and utilize the advice. (It's also almost 40 degrees C here so I'll have to think out loud...) - is the SSSAD in s-abstractions recent enough for these tricks? (http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad) - is there an example patch of SSSAD local saving available? i just wish to see/understand how to save and load presets exclusive for an abstraction instance. - or, please, is it possible to list the steps of creating SSSAD local saving for an abstraction? (eventually using [presetstore]... which I have attached because it's not hosted anywhere any more)? - is at viable at all to avoid using rjlib for this (and to use 'pure' SSSAD), or I couldn't get away without all that patching that is in u_loader, u_dispatch, u_cocollect etc? ...sorry for the dependent mental state in which I am! :-o
I don't think it's your mental state. Those tools are clunky. Have you looked at Ivica's [preset_hub] in Pd-l2ork? You simply name the [preset_hub], and all the [preset_node] objects with the same name on that canvas or a child of it (including abstractions) work together. No need to use dollarsign arguments at all. All state is saved with the patch and adding/removing nodes works seamlessly, even with infinite undo. His preset system even makes an automatic, hidden connection back into the [preset_node] so you don't get crossed wires. -Jonathan
Now that you told it, I gave myself a shot of it. Mmmmmm...! Simple and fast and feels so good. However... I'm afraid of locking myself in pd-l2ork. That would mean that my songs are basically in l2ork. Where does this thing store its data? Is it possible to dump it out in raw form?
It stores it as hidden args to the relevant [preset_hub]. I told Ivica I thought there should be an option to save the state out to a separate file, but he said that would complicate things (and he's the one implementing all of it). After all, if you're saving state for a patch, that state isn't much good outside of the context of the patch.
The one area that this method does not address is abstractions managing their own state. The obvious benefit of such self-management is with gui abstractions, where you want the abstraction to retain colors, slider values, or whatever when the parent is saved, and without manual intervention.
Maybe there's a way to "embed" a preset_hub into a canvas (as an option in the gop dialog), so that when the patch is created as an abstraction the preset state gets saved as args to the abstraction.
Also-- I think this probably ties in somehow to the idea of simulating named arguments by interpreting arguments after a , as messages to the object. In other words, [foo, pitch 1, decay 3]
would be equivalent to
[initbang] | [pitch 1, decay 3( | [foo]
I can't remember the exact arg syntax of [preset_hub] for saving state, but it seems like it's essentially the same idea, just with the args hidden from the user.
On the other hand, you've been using l2ork for a while, right? Can I ask you "how does it feel", do you feel locked in, etc? You no miss 0.43 plugins...?!
There are only a few things in the hard sense that could lock you in:
number "123" then a bang (quite useful in my opinion)
some gop abstractions not show up correctly in pd-l2ork
I think everything else would only "lock" in a user in the soft sense, e.g., infinite undo makes you feel slightly less like you're programming on an Apple II from the 80s.
In fact there are so many of the latter type of improvements that it's probably less work to port Pd-l2ork to Windows and OSX than it is to put those features back into Pd-Extended and Vanilla. If Pd-l2ork incorporated the 0.43 gui changes then that's probably what I'd spend my time doing. :)
-Jonathan
Thanks,
András
On 7/29/13 1:01 PM, Jonathan Wilkes wrote:
In fact there are so many of the latter type of improvements that it's probably less work to port Pd-l2ork to Windows and OSX than it is to put those features back into Pd-Extended and Vanilla. If Pd-l2ork incorporated the 0.43 gui changes then that's probably what I'd spend my time doing. :)
-Jonathan
Speaking strictly selfishly, that would be a dream-come-true for me. I'd love to see the fork reunite, as it sounds like many excellent improvements have been made in Pd-l2ork that would be nice to have become mainstream.
Phil Stone www.pkstonemusic.com
[...]
- is the SSSAD in s-abstractions recent enough for these tricks? (
http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad )
- is there an example patch of SSSAD local saving available? i just
wish to see/understand how to save and load presets exclusive for an abstraction instance.
- or, please, is it possible to list the steps of creating SSSAD local
saving for an abstraction? (eventually using [presetstore]... which I have attached because it's not hosted anywhere any more)?
- is at viable at all to avoid using rjlib for this (and to use 'pure'
SSSAD), or I couldn't get away without all that patching that is in u_loader, u_dispatch, u_cocollect etc?
...sorry for the dependent mental state in which I am! :-o
I don't think it's your mental state. Those tools are clunky.
Clunky but portable. I'm still interested in an SSSAD-only solution.
Have you looked at Ivica's [preset_hub] in Pd-l2ork? You simply name the [preset_hub], and all the [preset_node] objects with the same name on that canvas or a child of it (including abstractions) work together. No need to use dollarsign arguments at all. All state is saved with the patch and adding/removing nodes works seamlessly, even with infinite undo.
His preset system even makes an automatic, hidden connection back into the [preset_node] so you don't get crossed wires.
-Jonathan
Now that you told it, I gave myself a shot of it. Mmmmmm...! Simple and fast and feels so good. However... I'm afraid of locking myself in pd-l2ork. That would mean that my songs are basically in l2ork. Where does this thing store its data? Is it possible to dump it out in raw form?
It stores it as hidden args to the relevant [preset_hub]. I told Ivica I thought there should be an option to save the state out to a separate file, but he said that would complicate things (and he's the one implementing all of it). After all, if you're saving state for a patch, that state isn't much good outside of the context of the patch.
Well, I just RTFM and the feature is there. You bang this into your preset_hub: [symbol $1] | [write $1.txt( ...and voilá.
The one area that this method does not address is abstractions managing their own state. The obvious benefit of such self-management is with gui abstractions, where you want the abstraction to retain colors, slider values, or whatever when the parent is saved, and without manual intervention.
Maybe there's a way to "embed" a preset_hub into a canvas (as an option in the gop dialog), so that when the patch is created as an abstraction the preset state gets saved as args to the abstraction.
Also-- I think this probably ties in somehow to the idea of simulating named arguments by interpreting arguments after a , as messages to the object. In other words, [foo, pitch 1, decay 3]
would be equivalent to
[initbang] | [pitch 1, decay 3( | [foo]
I can't remember the exact arg syntax of [preset_hub] for saving state, but it seems like it's essentially the same idea, just with the args hidden from the user.
On the other hand, you've been using l2ork for a while, right? Can I ask you "how does it feel", do you feel locked in, etc? You no miss 0.43 plugins...?!
There are only a few things in the hard sense that could lock you in:
- Pd-l2ork uses Max-style [trigger]: e.g., [t b 123] would trigger the
number "123" then a bang (quite useful in my opinion)
good reminder! I've just noticed a few days ago this works but wasn't fully aware it's not portable
- [preset_hub] isn't part of Pd-extended nor vanilla
and i guess won't ever be
- discrepancy between iemgui placement on gop canvas that evidently makes
some gop abstractions not show up correctly in pd-l2ork
I think everything else would only "lock" in a user in the soft sense, e.g., infinite undo makes you feel slightly less like you're programming on an Apple II from the 80s.
In fact there are so many of the latter type of improvements that it's probably less work to port Pd-l2ork to Windows and OSX than it is to put those features back into Pd-Extended and Vanilla. If Pd-l2ork incorporated the 0.43 gui changes then that's probably what I'd spend my time doing. :)
-Jonathan
make no mistake, I've been using l2ork for more than a year... it's just that so far I've not burned the bridges behind me
András
On Mon, Jul 29, 2013 at 10:06 PM, Phil Stone pkstone@ucdavis.edu wrote:
On 7/29/13 1:01 PM, Jonathan Wilkes wrote:
In fact there are so many of the latter type of improvements that it's probably less work to port Pd-l2ork to Windows and OSX than it is to put those features back into Pd-Extended and Vanilla. If Pd-l2ork incorporated the 0.43 gui changes then that's probably what I'd spend my time doing. :)
-Jonathan
Speaking strictly selfishly, that would be a dream-come-true for me. I'd love to see the fork reunite, as it sounds like many excellent improvements have been made in Pd-l2ork that would be nice to have become mainstream.
Phil Stone www.pkstonemusic.com
+1 huh :o}
András
On 07/29/2013 04:18 PM, András Murányi wrote:
[...] - is the SSSAD in s-abstractions recent enough for these tricks? (http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad) - is there an example patch of SSSAD local saving available? i just wish to see/understand how to save and load presets exclusive for an abstraction instance. - or, please, is it possible to list the steps of creating SSSAD local saving for an abstraction? (eventually using [presetstore]... which I have attached because it's not hosted anywhere any more)? - is at viable at all to avoid using rjlib for this (and to use 'pure' SSSAD), or I couldn't get away without all that patching that is in u_loader, u_dispatch, u_cocollect etc? ...sorry for the dependent mental state in which I am! :-o
I don't think it's your mental state. Those tools are clunky.
Clunky but portable. I'm still interested in an SSSAD-only solution.
Have you looked at Ivica's [preset_hub] in Pd-l2ork? You simply name the [preset_hub], and all the [preset_node] objects with the same name on that canvas or a child of it (including abstractions) work together. No need to use dollarsign arguments at all. All state is saved with the patch and adding/removing nodes works seamlessly, even with infinite undo. His preset system even makes an automatic, hidden connection back into the [preset_node] so you don't get crossed wires. -Jonathan Now that you told it, I gave myself a shot of it. Mmmmmm...! Simple and fast and feels so good. However... I'm afraid of locking myself in pd-l2ork. That would mean that my songs are basically in l2ork. Where does this thing store its data? Is it possible to dump it out in raw form?
It stores it as hidden args to the relevant [preset_hub]. I told Ivica I thought there should be an option to save the state out to a separate file, but he said that would complicate things (and he's the one implementing all of it). After all, if you're saving state for a patch, that state isn't much good outside of the context of the patch.
Well, I just RTFM and the feature is there. You bang this into your preset_hub: [symbol $1] | [write $1.txt( ...and voilá.
Ah, nice. I guess he added it recently.
The one area that this method does not address is abstractions managing their own state. The obvious benefit of such self-management is with gui abstractions, where you want the abstraction to retain colors, slider values, or whatever when the parent is saved, and without manual intervention. Maybe there's a way to "embed" a preset_hub into a canvas (as an option in the gop dialog), so that when the patch is created as an abstraction the preset state gets saved as args to the abstraction. Also-- I think this probably ties in somehow to the idea of simulating named arguments by interpreting arguments after a \, as messages to the object. In other words, [foo, pitch 1, decay 3] would be equivalent to [initbang] | [pitch 1, decay 3( | [foo] I can't remember the exact arg syntax of [preset_hub] for saving state, but it seems like it's essentially the same idea, just with the args hidden from the user.
On the other hand, you've been using l2ork for a while, right? Can I ask you "how does it feel", do you feel locked in, etc? You no miss 0.43 plugins...?!
There are only a few things in the hard sense that could lock you in: * Pd-l2ork uses Max-style [trigger]: e.g., [t b 123] would trigger the number "123" then a bang (quite useful in my opinion)
good reminder! I've just noticed a few days ago this works but wasn't fully aware it's not portable
Not portable to Pd-extended or Vanilla, but portable to Max/MSP.
-Jonathan
* [preset_hub] isn't part of Pd-extended nor vanilla
and i guess won't ever be
* discrepancy between iemgui placement on gop canvas that evidently makes some gop abstractions not show up correctly in pd-l2ork I think everything else would only "lock" in a user in the soft sense, e.g., infinite undo makes you feel slightly less like you're programming on an Apple II from the 80s. In fact there are so many of the latter type of improvements that it's probably less work to port Pd-l2ork to Windows and OSX than it is to put those features back into Pd-Extended and Vanilla. If Pd-l2ork incorporated the 0.43 gui changes then that's probably what I'd spend my time doing. :) -Jonathan
make no mistake, I've been using l2ork for more than a year... it's just that so far I've not burned the bridges behind me
András