Hi Everyone,

I've been trying to figure out a way to open and load a PD patch as a subpatch. I've been experimenting with [openpanel] and [openpatch], however it just opens the patch and doesn't create a subpatch.

I thought about putting a loadbang in the patches that would then copy all the information in the patch and paste it into a subpatch. But I figured it would have to use shell commands and I'm not too savy with those.

Any help would be greatly appreciated

You know about abstractions, right? It sounds like that might be what you're after.

Save a patch to file (ie 'my-patch.pd') and then create an object of the same name (ie. [my-patch] ). Inlets and outlets work as in sub-patches, and you also have the added feature of creation arguments.

@LiamG Thanks for the quick response! Sorry, I should've been a little more clear
Ideally I would like to use [openpanel] to open and load/create an abstraction within the main PD patch, instead of just creating an abstraction.

I see.

Then you should be able to do this:

[obj 0 0 my-abstraction(
|
[iemguts/sendcanvas]

where 0 0 is the x-y coordinate where you want the object to appear.

If you don't want to use an external, you can use [namecanvas] instead of [sendcanvas], or even [send pd-my_canvas_name].

You can also use [openpanel] to choose the abstraction if you want, but you'll have to split the .pd off the end of the symbol.

@LiamG Thanks for the help! I was able to make an abstraction using [iemguts/sendcanvas] and open a PD patch using [symbol2list] to filter out non-important information from [openpanel] (IE usr/home/desktop/etc..) so my overall patch looks like this...

[bng]
|
[openpanel]
|
[symbol2list /]
|
[unpack s s s]
           /
[symbol2list .]
|
[unpack s s]
         /
[obj 0 0 $1(
|
[iemguts/sendcanvas]

Now the tricky part is to get the abstraction to automatically send and recieve information from the parent patch. I'm currently using [s~] / [r~] however the [r~] in the abstraction doesn't seem to be working. If I connect information into the inlet of the abstraction it'll work, but ideally I would like information to be sent to and from the abstraction automatically upon creation.

@reverbanime Sorry to ask, but is there a typo in the receive name? Receive objects complain if there is no send, and I assume that it exists already in the parent. So I would expect a problem the other way around.
Does [throw~] / [catch~] work?
You could auto-connect to the abstraction once it is created with a [connect "parent-object-no" "parent-outlet-no" "abstr-object-no" "abstr-inlet-no"( message if all else fails.
David.

@whale-av Thanks for the response! I just figured out why [s~] and [r~] aren't working, I forgot that I there was another abstract with the same [s~] / [r~] destinations

However, I'm encountering a new issue now. I'm running the aforementioned patch as an abstraction with the [bang] and [inlets]/[outlets] in the parent window using parent-to-graph. However, information isn't sent to the loaded abstraction until it is saved

My question is; does an external exist that saves an abstraction/patch. A simple ctrl+S in the abstraction resolves this issue, so I'm looking to streamline the process.

THANKS

@reverbanime You can send the message [menusave( to the parent patch.
The problem then is that you will have saved the abstraction as well.
If the parent patch is stable (you are not changing it apart from loading your abstraction) then you can send the parent patch a [delete x (message, where you know the "object number" of the abstraction, before you load the next abstraction from the [openpanel]..... but you will need the [canvasdelete] object.

Or....... if you bury the abstraction 2 levels down (in another empty abstraction....... gui's will show through more than one gop window) then you can send the [clear( message to clear that window....... so removing your "put" abstraction before you load another one, or before you finally resave the empty parent.
David.

Perhaps the abstraction isn't working because of loadbang. Loadbang isn't triggered when you create an object dynamically, so you'll need another solution. Either just send a bang through regular send/receive channels, or send "loadbang" to the [sendcanvas] object. (The problem with the latter solution is that it will loadbang everything, which sometimes messes things up. If this is the case, you'll need to protect the loadbang objects with spigots to make sure they only fire once.)

Note that in L2Ork and Purr data, loadbang *does work with dynamic patch creation, so if you're using those platforms then this isn't the problem.

@whale-av @LiamG So I managed to getting everything working (sort of). Using [menusave( in the abstraction enables information to be sent to and from the parent patch and using [canvasdelete] clears all information. Here's what everything looks like so far...
There's only two things I need to figure out in order for this to be an effective loader...
There needs to be some way to open the effects patch from the parent-to-graph (just pull up the abstraction window that has the effect in it).
AND, for some odd reason information in the abstraction and the parent-to-graph isn't being saved/loaded. I'll save everything and close out the patches, but when I open it up I have to reset everything. I'm kind of new to puredata, so I'm sure I'm just missing something small.

THANKS AGAIN FOR ALL THE HELP

@reverbanime In your Gui objects, the faders and toggles, if you right click them and open the properties window then you will see a button near the top that sys "no init".
If you click that and chose "init" (and then apply or ok) then when you save the patch or the abstraction that they are "in" then the current values will be saved as well.
All of the Gui's from "bang" down to "hradio" in the drop down "put" list can have that property set, so numbers can be saved within the "number2" gui for example.
If you need to go further then you will need some sort of "state saving" setup. There are a few ways to do that..... one such is in the iemlib folder....... [iem_pbank_csv-help]
David.

@whale-av So I managed to get state saving working with [iemguts/canvasargs] however, all of my sends and receives to the effects abstraction are messed up. I'm able to send a bang to the abstraction using [s $2] (which was [s $1] before I implemented state saving), however sending audio is proving to be trickier.

I tried changing all of the sends and receives to [s~ $2Lin], [s~ $2Rin] etc... But the Pd terminal is saying there's no matching sends
I switched over to [throw~] / [catch~] and got a nice signal flow, however I'm planning on having multiple instances of the same abstraction.

I'm really stumped with this one

@reverbanime At first glance (your patch above) you have some send and receive objects that have spaces in their names. The bit after the space will be dropped (ignored).
If that is not the problem then maybe it's time to zip up your patch (and all the abstractions) and upload it.
Otherwise it is pretty impossible to understand and help.... sorry.
David.

@reverbanime P.S. ....... I would expect you to have to do it something like this.
Don't forget that the $1 $2 are the arguments in your abstractions (child patches) and are not the same in your main patch (mother patch) where you have to give the names real values.......
Example..... multiple.zip
David.

@whale-av So I switched over to [catch~] and [throw~] and now information is being sent to/from the effects abstraction nicely! However, if I try and create multiple instances of the effects loader abstraction in the same abstraction, then all sends and receives get sent to both abstractions
Here's the latest Effect Loader and a basic Plate Reverb to test it out with EffectLoaderTEST.zip

Thanks again for all the help!! This is proving to be a much bigger undertaking than I planned, but I'm liking the challenge

@reverbanime Ok.... I think I understand.
What you are missing is an identifier for each effect loader...... a number (0 - n) (or 1 - n) that keeps them unique, and that can be passed to the effect that is opened by each loader so that messages can be passed (using that unique identifier) to and from the effect and the loader (that contains the effect).

Because the effects are abstractions $0 will not work.
The effect can be given it's identifier here.......

It needs to be initiated at the creation of the loader, so it would be good if it were $1.

I have built you a system that will work, using an extra blank abstraction "[rack]" to hold the effects.
The effects inherit $1 from each [effectloader] so that the audio is kept separate.
You will need to check your parameter saving as I have stolen $1 for the new numbering system.
Please BACK UP your current folder before playing with this!
effect_loader_test_1.zip

Hmm..... I can never leave it alone......
The delete (old effect) is not working as I expected. I think the effects in the rack will need "place-holders" (sub-patches) so that a [clear( message can be sent instead of using [iemguts/canvasdelete]
Otherwise it is not possible to keep track of the order in which effects are created...........
I will post a new version of the test soon.
David.

@reverbanime Better.........
The effects don't "appear" in the effects rack sub-patch GOP's unfortunately. If you open one of the sub-patches [pd effect0] for example you will see the effect being destroyed and created.
effect_loader_test_2.zip
David.

@whale-av WOW!!! The 'rack' system is awesome, it's such a great way to store information Unfortunately [initbang] isn't working for me. I'm running PD vanilla on an RPI 3 with l2ork+extended library paths, but when I try loading [iemguts/initbang] / [initbang] PD can't seem to find them. Which is strange since l20rk and pd-extended both have working [initbang] objects, however their builds aren't stable enough to load this patch. I've been looking for the external location, however I could only manage to find the help file

I substituted [initbang] for just a [bang] and I was able to see how the 'rack' system works, but I feel like I'm gonna need [initbang] or some sort of workaround to get this working.

Looking ahead, the final step that would make this an effect tool would be an 'open' button in the graph-to-parent, one that would just 'open' the window/abstraction that the effect was in so you can edit parameters

Thanks again for all the help
-Sean

@reverbanime I think it will work with [loadbang] instead (just tested and should be ok)....... sorry..... it's an old habit for me using initbang for dynamic patching as it is necessary for creating outlets and inlets.
David.

@reverbanime Here it is again without the initbang..

And this gets you part way to opening the effect..... effect_loader_test_3.zip
There is an edit button in the [effectloader] gop window.
If you give your effect abstractions a gop window then the parameters will appear when the edit button is clicked (and close when clicked again).......
You might have to resize the gop's in the rack.......... big enough for all your sliders.
David.