[L2Ork-dev] GSOC – auto abstraction save

[Matt Barber]

> 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.

Suppose the saved abstraction has the name of an internal or a loaded
external. Maybe the user wasn't aware of [rpole~] or [drunk]. What happens?

On Wed, Jul 1, 2020 at 9:27 AM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> 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
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200701/e8d5edb9/attachment.html>