[L2Ork-dev] GSOC – auto abstraction save

[Jonathan Wilkes]

On Wed, Jul 1, 2020 at 11:07 AM Matt Barber <brbrofsvl at gmail.com> wrote:
>
> > 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?

Ah, I understand.

So you have to worry about two things:

1. Is there currently a creator for this name? This can be answered by
searching the current creator methodspace
2. Is there a file with this name that is further up in the path
search order than the path we're going to give to this
abstraction? This is a real pain. It's probably not cheap to do a
loader "dry-run" through the paths to see
what it comes up with.

I'd almost prefer a [declare -strict] created at the top of every
patch created from the "New" menu option. Then
we could load up a "strict" mode with sane, usable behavior. (As it is
we have behavior which covers every
conceivable use case, but does so poorly.)

-Jonathan

>
> 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
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev