[L2Ork-dev] atomic multi-step undo and pd vanilla

[Jonathan Wilkes]

On Fri, Jun 19, 2020 at 12:22 PM Linux ROUEN Normandie
<linux.rouen at free.fr> wrote:
>
> Hello Jonathan,
>
> - Pd Documentation chapter 5. current status
> A complete releases list with details per release from Pure Data v.0.0.1 to latest v.0.51-0.
>
> - pure-data/src/CHANGELOG.txt - Less complete and stopped at v.0.42, but see also the end of the list.

Thanks, Joseph.

I'll start going through this list.

For those who are interested, here's why this is difficult:

>From 0.48:

New "fudiparse", "fudiformat" objects.
"float" now understands symbol messages that look like floats.

We already implemented fudiparse and fudiformat.

But if you've ever used it you instantly realize it's clunky and
lossy. So even in the version
where Vanilla added those classes, a "symbol" message had to be added
to [float] to handle
one common case of confusion users run into without losing the data
payload of the message.

Still, one must ask-- what problem are all of these additions trying
to solve? And the answer to
that is this-- there is no visual indication for the underlying type
(in C) of a given token when
displayed in any of Pd's GUI widgets.

E.g., if I tell you that [print] outputted "5" to the console, you
have no idea whether that is a
t_float or a t_symbol.

That's still a problem post 0.48. But the UX is now less consistent--
the new user learns that
[float] does the practical thing if taking input from the right outlet
of [keyname] (e.g., if you're
typing one of the number keys). But [int] does not. And more
importantly, [route] does not. So
now you've got little [float] boogers scattered through the patch to
handle an edge-case with
atom types that is probably still driving the user crazy.

And then the situation where a user tries to manually send [symbol
42(---[float] and ends up
with zero!

So yeah, we can add this symbol method for [float]. But both Ico and I
actually want to solve some
of these problems on a deeper level, and that takes time and care.

I think a good start would be to short circuit the error handler for
non-existent methods. If a symbol
with a "float"-able payload is triggering an error with a class that
has a float method, the user
probably wants to know that information. Or if the symbolic selector
"12" is sent and rejected for lack
of a "12" method, we need a better way to explain that.

Honestly, I'd prefer to go ahead and convert the payload/selector and
forward it on its way while
still printing out the error.

-Jonathan

>
> Best,
> Joseph Gastelais
>
> - - - - - - - - - - - - - - - - - - - -
> Le 19/06/2020 à 17:29, Jonathan Wilkes a écrit :
>
> On Fri, Jun 19, 2020 at 9:50 AM Matt Barber <brbrofsvl at gmail.com> wrote:
>
> Thanks for this, Guillem.
>
> I'm inclined to suggest that we try to import Vanilla's undo routines if they'd be useful for your project. It may prove easier to do that if we also want to grab the triggerize function, since the triggerize undo is pretty involved and seems to depend on the rest of the undo infrastructure.
>
> I'd like to reiterate the main complaint I get from Pd users who want to migrate to Purr but who don't ultimately end up doing so: Purr is behind on features from recent versions of Vanilla and so more recent patches don't work. I think it's worth being proactive in including the new stuff when possible, and this might be a good opportunity to do so.
>
> Does Pd Vanilla have a comprehensive listing of new features for each release?
>
> If so it would be helpful if someone could compile a list that has the
> feature list per release.
>
> -Jonathan
>
> MB
>
> On Tue, Jun 16, 2020 at 11:54 AM Ivica Bukvic <ico at vt.edu> wrote:
>
> I propose proceeding with whatever is easiest, most maintainable, and least likely to break things. So, cherry picking fixes will be important.
>
> Best,
>
> Ico
>
> --
> Ivica Ico Bukvic, D.M.A.
> Director, Creativity + Innovation
> Institute for Creativity, Arts, and Technology
>
> Virginia Tech
> Creative Technologies in Music
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> ico at vt.edu
>
> www.icat.vt.edu
> www.performingarts.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
> On Tue, Jun 16, 2020, 11:47 Guillem Bartrina Moreno <guillembartrina at gmail.com> wrote:
>
> Hi,
> I have been checking pd vanilla "triggerize" feature, as Matt suggested, together with its undo system. It turns out that pd vanilla already has an atomic multi-step undo system implemented that allows us to start a sequence of undo actions, fill it with all actions that we need and then finalize it. Then, while undoing, if the system encounters the start/end of the sequence it executes all undo steps until the end/start is reached.
> As you have been talking about merging some pd vanilla interesting features into purr data, what do you think about this one?
> I don't know what would be better. I have checked the implementation differences between vanilla and purr data and there are some of them that could probably break the system if we do a direct merge. Basically pd vanilla changed the place where the undo queue is stored and therefore how it's accessed, and some other implementation differences and add-ons.
> An option would be porting only the things that we want to add to purr data, adjusting them as needed. Another one would be implementing them from scratch, as intended.
>
> Best,
>
> --
> Guillem Bartrina Moreno
> _______________________________________________
> 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
>
> _______________________________________________
> 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