This would be a nice feature
Do you mean the "-x" flag? ;-)
Christof
On 16.08.2020 02:42, William Huston wrote:
What about this?
[pd NAME IGNORED ... -p ARG1 ARG2...]
This would be a nice feature, in that it would make subpatches work more like abstractions.
Thanks, BH
-- William Huston: WilliamAHuston@gmail.com mailto:WilliamAHuston@gmail.com Binghamton NY
*Public Service Mapping / Videography / Research / Education / Safety Advocacy* Blog http://WilliamAHuston.blogspot.com -- Facebook http://facebook.com/billhuston -- Twitter http://twitter.com/WilliamAHuston-- Youtube https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1*-- Podcast Blog https://billhustonpodcast.blogspot.com/
*Document collections*: VirtualPipelines http://TinyURL.com/VirtualPipelines -- BHDCSDimockArchive http://bit.ly/BHDCSDimockArchive *Please support my work! -- *TinyURL.com/DonateToBillHuston http://TinyURL.com/DonateToBillHuston
**
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Sorry, is this documented anywhere?
I see a -x option to the [clone] object, which works for abstractions only.
I am talking about a general way to send positional parameters into a subpatch similar to how I can pass parameters into an abstraction.
[image: image.png]
-- William Huston: WilliamAHuston@gmail.com Binghamton NY
*Public Service Mapping / Videography / Research / Education / Safety Advocacy* Blog http://WilliamAHuston.blogspot.com -- Facebook http://facebook.com/billhuston -- Twitter http://twitter.com/WilliamAHuston-- Youtube https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1
- -- Podcast Blog https://billhustonpodcast.blogspot.com/*
*Document collections*: VirtualPipelines http://TinyURL.com/VirtualPipelines -- BHDCSDimockArchive http://bit.ly/BHDCSDimockArchive *Please support my work! -- *TinyURL.com/DonateToBillHuston
On Sat, Aug 15, 2020 at 9:28 PM Christof Ressi info@christofressi.com wrote:
This would be a nice feature
Do you mean the "-x" flag? ;-)
Christof On 16.08.2020 02:42, William Huston wrote:
What about this?
[pd NAME IGNORED ... -p ARG1 ARG2...]This would be a nice feature, in that it would make subpatches work more like abstractions.
Thanks, BH
-- William Huston: WilliamAHuston@gmail.com Binghamton NY
*Public Service Mapping / Videography / Research / Education / Safety Advocacy* Blog http://WilliamAHuston.blogspot.com -- Facebook http://facebook.com/billhuston -- Twitter http://twitter.com/WilliamAHuston-- Youtube https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1
- -- Podcast Blog https://billhustonpodcast.blogspot.com/ *
*Document collections*: VirtualPipelines http://TinyURL.com/VirtualPipelines -- BHDCSDimockArchive http://bit.ly/BHDCSDimockArchive *Please support my work! -- *TinyURL.com/DonateToBillHuston
Pd-dev mailing listPd-dev@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Ah, sorry I terribly misread your question! Ignore my last mail :-/
Passing arguments to subpatches is currently not possible. Generally, how would you distinguish between abstraction creation arguments and subpatch arguments? $1, $2, $3, inside a subpatch already refer to the enclosing abstraction's creation arguments. This means you would need a dedicated syntax (or a dedicated object) to access subpatch creation arguments. I don't see this happening, to be honest.
I'd say, if you need creation arguments, just use an abstraction ;-)
Christof
PS: internally, subpatches don't really have creation arguments at all. Instead they have a pointer to the canvas environment of the enclosing abstraction or root canvas.
On 16.08.2020 04:01, William Huston wrote:
Sorry, is this documented anywhere?
I see a -x option to the [clone] object, which works for abstractions only.
I am talking about a general way to send positional parameters into a subpatch similar to how I can pass parameters into an abstraction.
image.png
-- William Huston: WilliamAHuston@gmail.com mailto:WilliamAHuston@gmail.com Binghamton NY
*Public Service Mapping / Videography / Research / Education / Safety Advocacy* Blog http://WilliamAHuston.blogspot.com -- Facebook http://facebook.com/billhuston -- Twitter http://twitter.com/WilliamAHuston-- Youtube https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1*-- Podcast Blog https://billhustonpodcast.blogspot.com/
*Document collections*: VirtualPipelines http://TinyURL.com/VirtualPipelines -- BHDCSDimockArchive http://bit.ly/BHDCSDimockArchive *Please support my work! -- *TinyURL.com/DonateToBillHuston http://TinyURL.com/DonateToBillHuston
**
On Sat, Aug 15, 2020 at 9:28 PM Christof Ressi <info@christofressi.com mailto:info@christofressi.com> wrote:
This would be a nice featureDo you mean the "-x" flag? ;-) Christof On 16.08.2020 02:42, William Huston wrote:What about this? [pd NAME IGNORED ... -p ARG1 ARG2...] This would be a nice feature, in that it would make subpatches work more like abstractions. Thanks, BH -- William Huston: WilliamAHuston@gmail.com <mailto:WilliamAHuston@gmail.com> Binghamton NY *Public Service Mapping / Videography / Research / Education / Safety Advocacy* Blog <http://WilliamAHuston.blogspot.com> -- Facebook <http://facebook.com/billhuston> -- Twitter <http://twitter.com/WilliamAHuston>-- Youtube <https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1>*-- Podcast Blog <https://billhustonpodcast.blogspot.com/> * *Document collections*: VirtualPipelines <http://TinyURL.com/VirtualPipelines> -- BHDCSDimockArchive <http://bit.ly/BHDCSDimockArchive> *Please support my work! -- *TinyURL.com/DonateToBillHuston <http://TinyURL.com/DonateToBillHuston> ** _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at> https://lists.puredata.info/listinfo/pd-dev_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em sáb., 15 de ago. de 2020 às 23:17, Christof Ressi info@christofressi.com escreveu:
subpatches don't really have creation arguments at all.
I'd say the creation argument is a symbol that just shows up as the subcanvas name in the top window and doesn't really do anything, it's just something you use to know what it's supposed to do, like a function name.
Creation arguments for subpatches is something i have wanted for years. Would come in very handy in a few cases.
Like, when you need to make just 2 copies of something in a patch. Left / right pairs for stereo processing, etc. Much easier just to have 2 subpatches than save a separate abstraction file, especially if you're working on a big project with lots of files. Also makes it easier to share things with people if you only have to share one .pd file rather than a folder with abstractions, etc.
But the main thing i have always wanted it for is for state saving. If there was something akin to $0 for subpatches, then they could be uniquely identified, and uniquely tied to an enclosed abstraction. So, say you have a simple volume control abstraction ( inlet~ -> *~ -> outlet ), and you enclose that it [pd volume] subpatch which is just a graph-on-parent slider. If you could do something like [pd volume #0] and have that argument unique to that subpatch, and then put [volume-abstraction #0] inside that subpatch, then you would have unique caller / listener pairs for that subpatch only, but also have the ability to save the state of the slider in the subpatch by setting it to 'init'. So, in effect, you could create any number of [pd volume #0] subpatches, and all have them with their own independent slider values that can be saved in the parent patch. For simple examples like that, maybe not too much to be gained...can just use an inlet to the abstraction and join it that way. But would be very useful for larger patches with multiple GUI elements. Would save a lot of messy cable joining, and [route 0 1 2 3 4 5 6 7] etc solutions.
The purpose of subpatches is to hide stuff. If you feel the need for creation arguments, it is a good indication that you really should be using an abstraction instead. That's what they are made for.
Like, when you need to make just 2 copies of something in a patch. Left / right pairs for stereo processing, etc. Much easier just to have 2 subpatches than save a separate abstraction file, especially if you're working on a big project with lots of files.
This is rather messy. If you have to (almost) identical patches, you should be using an abstraction instead. This is cleaner and guarantees that the instances stay in sync. If you edit one instance, do you always want to delete and recreate all other instances, like you have to with subpatches?
Also makes it easier to share things with people if you only have to share one .pd file rather than a folder with abstractions, etc.
Just share a .zip file?
If you could do something like [pd volume #0] and have that argument unique to that subpatch
Just pass some identifier that is unique to the enclosed abstraction, e.g. [myabs $0]. For example, [myabs] can then have a [r $0/init], so you can (re)init all instances from the parent patch. This is actually a common pattern.
But the main thing i have always wanted it for is for state saving.
BTW, have a look at the new [savestate] object.
Christof
On 16.08.2020 12:49, Matt Davey wrote:
Creation arguments for subpatches is something i have wanted for years. Would come in very handy in a few cases.
Like, when you need to make just 2 copies of something in a patch. Left / right pairs for stereo processing, etc. Much easier just to have 2 subpatches than save a separate abstraction file, especially if you're working on a big project with lots of files. Also makes it easier to share things with people if you only have to share one .pd file rather than a folder with abstractions, etc.
But the main thing i have always wanted it for is for state saving. If there was something akin to $0 for subpatches, then they could be uniquely identified, and uniquely tied to an enclosed abstraction. So, say you have a simple volume control abstraction ( inlet~ -> *~ -> outlet ), and you enclose that it [pd volume] subpatch which is just a graph-on-parent slider. If you could do something like [pd volume #0] and have that argument unique to that subpatch, and then put [volume-abstraction #0] inside that subpatch, then you would have unique caller / listener pairs for that subpatch only, but also have the ability to save the state of the slider in the subpatch by setting it to 'init'. So, in effect, you could create any number of [pd volume #0] subpatches, and all have them with their own independent slider values that can be saved in the parent patch. For simple examples like that, maybe not too much to be gained...can just use an inlet to the abstraction and join it that way. But would be very useful for larger patches with multiple GUI elements. Would save a lot of messy cable joining, and [route 0 1 2 3 4 5 6 7] etc solutions.
On Sun, 2020-08-16 at 18:49 +0800, Matt Davey wrote:
Much easier just to have 2 subpatches than save a separate abstraction file, especially if you're working on a big project with lots of files. Also makes it easier to share things with people if you only have to share one .pd file rather than a folder with abstractions, etc.
I see how distributing only one file is simpler than a folder with many pd files, but having many copies of the same code is impractical and clumsy. How about an extended file format (.pdz?) that is actually an archive containing all the relevant files that would be extracted on the fly at loading time? I can't count the number of software that work like this, so there is precedent. Am not sure if the added bloat to Pd would be worthwhile...
Roman
I always structure my patches as xxxpatch.pd, and all abstractions in a folder, so that all abstractions can be called as [pp/xxx]. Then there's only one pd file in the main project folder, everything else is tucked away. Also very easy to zip together.
If you want to pack pd projects in a "pd format", don't forget all other files that belong to Pd projects - sound, midi, text, images, video, ... Is it worth it to re-invent a pd-zip format when zip already exists and is ubiquitous?
On Sun, 2020-08-16 at 18:49 +0800, Matt Davey wrote:
Much easier just to have 2 subpatches than save a separate abstraction file, especially if you're working on a big project with lots of files. Also makes it easier to share things with people if you only have to share one .pd file rather than a folder with abstractions, etc.
I see how distributing only one file is simpler than a folder with many pd files, but having many copies of the same code is impractical and clumsy. How about an extended file format (.pdz?) that is actually an archive containing all the relevant files that would be extracted on the fly at loading time? I can't count the number of software that work like this, so there is precedent. Am not sure if the added bloat to Pd would be worthwhile...
Roman
I always structure my patches as xxxpatch.pd, and all abstractions in a folder, so that all abstractions can be called as [pp/xxx]. Then there's only one pd file in the main project folder, everything else is tucked away. Also very easy to zip together.
+1
Personally, I always have a "main.pd" and all abstractions in an "abs" subfolder. "main.pd" has a [declare -path abs], so I don't need to prepend the folder all the time. This way I can easily rename/move the abstraction folder and I only have to modify the [declare].
Both methods achieve the same thing, it's just a matter of taste.
Anyway, the takeaway is that the "proper" way of shipping a Pd project is to have a single main patch and all abstractions (and other resources) in subfolders.
Is it worth it to re-invent a pd-zip format when zip already exists and is ubiquitous?
To answer this rhetoric question: of course not! :-)
Christof
On 17.08.2020 11:57, João Pais wrote:
I always structure my patches as xxxpatch.pd, and all abstractions in a folder, so that all abstractions can be called as [pp/xxx]. Then there's only one pd file in the main project folder, everything else is tucked away. Also very easy to zip together.
If you want to pack pd projects in a "pd format", don't forget all other files that belong to Pd projects - sound, midi, text, images, video, ... Is it worth it to re-invent a pd-zip format when zip already exists and is ubiquitous?
On Sun, 2020-08-16 at 18:49 +0800, Matt Davey wrote:
Much easier just to have 2 subpatches than save a separate abstraction file, especially if you're working on a big project with lots of files. Also makes it easier to share things with people if you only have to share one .pd file rather than a folder with abstractions, etc.
I see how distributing only one file is simpler than a folder with many pd files, but having many copies of the same code is impractical and clumsy. How about an extended file format (.pdz?) that is actually an archive containing all the relevant files that would be extracted on the fly at loading time? I can't count the number of software that work like this, so there is precedent. Am not sure if the added bloat to Pd would be worthwhile...
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Aug 17, 2020, at 7:58 AM, Christof Ressi info@christofressi.com wrote:
I always structure my patches as xxxpatch.pd, and all abstractions in a folder, so that all abstractions can be called as [pp/xxx]. Then there's only one pd file in the main project folder, everything else is tucked away. Also very easy to zip together.
+1
Personally, I always have a "main.pd"
+1
I have a bash script (tailored for mac but it can be used on linux if you tweak where pd is) that creates a directory tree that also includes a backup script within a "bak" dir and a pd template I used a lot. I'll update it soon but you can find an older version here:
https://github.com/fdch/fd_lib/blob/master/scripts/pdstart.sh
On macOS, unzip usually is a simple double click. On Window/Linux it's usually something like right click -> extract. Is this too much to ask for users of a computer music program? ;-)
Christof
On 17.08.2020 08:55, Roman Haefeli wrote:
On Sun, 2020-08-16 at 18:49 +0800, Matt Davey wrote:
Much easier just to have 2 subpatches than save a separate abstraction file, especially if you're working on a big project with lots of files. Also makes it easier to share things with people if you only have to share one .pd file rather than a folder with abstractions, etc.
I see how distributing only one file is simpler than a folder with many pd files, but having many copies of the same code is impractical and clumsy. How about an extended file format (.pdz?) that is actually an archive containing all the relevant files that would be extracted on the fly at loading time? I can't count the number of software that work like this, so there is precedent. Am not sure if the added bloat to Pd would be worthwhile...
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Christof Ressi -
Fede Camara Halac -
João Pais -
Matt Davey -
Roman Haefeli -
William Huston