[L2Ork-dev] GSOC – auto abstraction save

[Jonathan Wilkes]

On Wed, Jul 1, 2020 at 1:07 AM Matt Barber <brbrofsvl at gmail.com> wrote:
>
> Hello,
>
> Guillem and I have been discussing what the user should see when converting a subpatch to an abstraction, for his GSOC project. There are many possibilities; here's one scenario I came up with as a starting point (w/ some additions by Guillem):
>
> 1. User is in a subpatch window OR has a single [pd ] object selected (Guillem added right-click popup for the latter scenario – extremely convenient, and could have the same thing right-clicking subpatch canvas).
> 2. They hit the hotkey/menu/whatever.
> 3. Up comes the file chooser. Suppose they want to store it in a "Tools" directory, which is in the same directory as the root patch.
> 4. Get path from that selection, and convert to relative path if possible.

There's a nagging problem with Pd that we have to deal with here, too:

1. Pd has a nameclash problem
2. The loader's behavior is complicated

The only way to 100% solve this problem is to use an absolute path.

So conceptually, I'd start there and only open up other possibilities
if you can get them
so close to 100% that the user becomes unlikely to ever hit an edge case.

This is hard because even a user armed with a knowledge of all the
[declare] flags
may not understand when and how the clashes can happen. Does "-lib" *actually*
load anything if it's an abstraction? When is the canvas' path
searched vs the global
ones?

> 5. Bring up new dialog asking if they want to replace the subpatch with the abstraction yes/no, and a toggle to "try to replace every copied instance of this subpatch with abstraction". They hit "yes"

Use cases

1. user starts making a subpatch, then decides to turn that particular
subpatch into an abstraction
2. user does some copy-pasting for polyphony or something, then
decides all those subpatches need to be abstractions
3. user clicks the button (for one of a number of reasons), and the
dialog makes them realize they may have pasted this
subpatch several times in various locations

The question is whether the value to use case 3 outweighs the obstacle
to users in case 1. For case two, I could imagine
the dialog only being shown if there are multiple subpatches selected.

We can probably get feedback from users once this is implemented to
get a better sense of who is using this for what
purpose.

> 6. If the Tools path is [declare]ed on the root patch, replace the subpatch with the abstraction basename. Otherwise, [Tools/basename]. If the toggle was selected, run routine to go through the root patch and compare binbuf for replacement.

loader complexity example: if you declare that path *and* use
[Tools/basename], will it instantiate? I'm pretty sure
I changed "-lib" so that "-lib Tools/basename" will correctly add
"Tools/basename" to the creator table. But I don't know about
the -patch flag.

> 7. Preserve connections, of course.
> 8. Anything to do about the new abstraction creation arguments? Presumably nothing.

For a single pd patch to abstraction conversion-- possibly prepopulate
with "arg1 arg2 etc." selected. Could be handy for
new users.

Or in the dialog an entry for entering the args. Would be even better
if an arg could be an expression: (i * 2 + 400) :)

> 9. What to do about subpatch recursion? Ico suggested throwing an error like when you try to include an instance of an abstraction in itself.

FYI: It will already error out, but it's an unhelpful stack overflow
error after the thing fails to load itself 1000 times.

> 10. What does undo do? I think it must undo the subpatch replacement(s), if any.

I agree.

> 11. What happens with namespace clash? If I save with an object name that already exists, I think it throws an error only if you try to replace.

Not sure what you mean here.

>
> Much of the complexity is due to path. Any way to simplify? Could bring up the secondary dialog to replace subpatches only if the path is at the same level as or deeper than the root patch, so no ../ or absolute paths.

Yeah, it's a tough one. I'll think more about it and let you know if I
have anything.

-Jonathan

>
> Matt
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev