@willblackhurst Actually we can do it without a plugin.
sp-abs.pd

But dealing with tcl's nested lists in pd is a pain because of the lack of curly braces. This may not be a problem if you are not worried about have a drop down list of file types to choose from and can set the type before opening the panel. Would be easier to deal with as a plugin. [list [list pd [list .pd]]] in the set message can be edited for type or types, [list [list audio [list .wav .aiff]]] would just give you .wav and .aiff types. Not quite an abstraction despite what the name suggests, I realized that formatting the lists would be a pain and decided not to bother, will make a plugin version later.

@willblackhurst From what I can see the [savepanel] and [openpanel] objects never call the tcl variable for the filetypes and just ignores the Files of Types menu completely so even if you use [hcs/sys_gui] to set the variable to what you want it never updates them. Would require editing pd's source to make it work. This seems like a good feature request and worth filing an issue for on the pd git. You could make a custom [openpanel] [savepanel] with a gui plugin without much effort if a plugin is OK for your project. I think I saw in the next release of pd abstractions will be able to load plugins which would make this method work well even with projects you intend to share. Don't have time to throw together a demo of plugin now but it is mostly just copying the code from pd-gui.tcl and using [hcs/sys_gui] in an abstraction to run the new proc and send to a send in the abstraction. I can throw something together later or tomorrow if need be, but you can probably figure it out without much effort.

@rph-r I am not sure what other change you are talking about, everything works exactly as I would expect it, the only wrong behavior I see is the stuff associated with [r $1-type] that I mentioned. [savestate] came with 0.49 and you just use the send and receives of the the UI elements to make your list for it, use a [pack] and [unpack] with an extra element which is only used for [savestate] to bang.

You can also use [list store] instead of [pack] with a [set n $1( between each receive and [list store] with n replaced by the appropriate index value, this can be a good way to go when the number of parameters you need to save gets high.

@rph-r It works exactly as expected, watch the symbol boxes when you switch either of the first two channels, they switch on both channels when you change either and so does the internal state of both [pd filters] but not the vradio since it is not connected to [r $1-type] and its own send/receive symbols are $0-from_type and $0-to_type. There is no reason these would bog down [savestate], can't say why it was causing problems for you without seeing how you implemented it, I regularly store far greater amounts of data in [savestate] without issue.

@rph-r If your subpatches don't need a [savestate] to hold their data between sessions then the subpatch as an abstraction shouldn't need [savestate], just use the abstraction exactly like you want to use the subpatch. But [savestate] can load a good amount of data before it bogs things down, I think you have some issue in your patch/abstraction which is causing [savestate] to seem heavy and also making it seem like subpatch arguments are working. Can you upload your patch?

@raynovich The version without the backslash shouldn't work unless you are in the root directory, which is unlikely, or you have a directory named 'user' containing that directory structure in the directory you are in, which is also unlikely. Leading slash is root directory, where cd / takes you. Have you created the directory without leading slash and then confirmed in the terminal it has been created? Something else could be happening that just makes it seem like it works as expected. You should ALWAYS use a leading slash with absolute paths, no leading slash means the path is relative to your current directory.

@raynovich Not sure about [command] and [shell] in this case but if you only need to do file manipulation and the like perhaps the [file] object will work in this case? I know [file cwd] does not affect the working directory of [command] so maybe it will not have the issue with ofelia? I don't know much about ofelia.

@Pepe_mv98 You need to connect the device to pd first, run amidi -l to get a list of available input and output ports and then use aconnect to connect them. You can also use aconnect -o and aconnect -i to list output and input ports as well and is helpful when you have a good number of devices to sort through. The man pages for these two programs should answer any other questions you have. And there are various ways to automate and simplify these connections but for simple setups like a single connection I never found the need beyond writing a very simple script which I lost and never bothered to rewrite.

@ddw_music Yeah, I was just mentioning it because it may be a solution for @bobfred since pipewire can also speak alsa or at least expose alsa ports without shutting down, not sure if he is doing anything which actually requires jack. I have no experience with bluetooth beyond the idiot proof connection of my phone to my stereo, figured you would be able to answer if using alsa was actually viable so I tagged you, did not want to send bobfred down a rabbit hole out of my own ignorance.

@ddw_music I'm guessing this had SuperCollider in the mix so you had to use jack? With pd you could do it all with alsa, latency will still be poor but that is not always an issue, but this could end up meaning lots of alsa loopback device fun depending on requirements.