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

[Alexandre Torres Porres]

Em sex., 19 de jun. de 2020 às 14:57, Jonathan Wilkes <
jon.w.wilkes at gmail.com> escreveu:

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

Cool, it seems it doesn't hurt to add the symbol method as a quick solution
before you find a more global solution, just so you avoid patches from 0.48
vanilla not working properly. Since Purr Data mentions it's up to date with
0.48, I find it important that it carries all functionalities up to 0.48,
and there are other functionalities mentioned in the release notes of 0.48
that are still missing.

Em sex., 19 de jun. de 2020 às 14:57, Jonathan Wilkes <
jon.w.wilkes at gmail.com> escreveu:

> Thanks, Joseph.
>
> I'll start going through this list.
>

Unfortunately, even though this is a good place to catch "bigger fishes",
this list may eventually miss some smaller ones. For instance, there's this
new functionality for 0.48 not listed there:
https://git.purrdata.net/jwilkes/purr-data/-/issues/460

Another example is the change to the wrap~ object in Vanilla, which had a
bug before 0.48 and got fixed since then (with a compatibility flag). You
recently did the same for Purr Data, so, yeah, that's another example of
something not listed in the release notes for 0.48...

So even if you go through all those things in the release notes and catch
up to 0.51, I don't know if we can be 100% it's up to date. Not only from
0.48 to 0.51, but also from before.

By the way, for 0.51 I updated the help files for many Vanilla objects. One
thing to highlight is that since 0.47 you can set colors with hex notation
for IEMGUIs, that's also missing in Purr Data, so that's something from
0.47 we know Purr Data doesn't have as well... this is yet another detail
missing from the release notes. There was not even a mention that the help
files of the IEMGUIs got a major overhaul now for 0.51...

Moreover, Purr Data has its own help files, so help file updates won't
likely be looked at, and that's why you probably missed the change to wrap~
and how you would miss the IEMGUI updates now.

So I know this is a painfully tedious task, but maybe going over the
documentation of every help file od Pd Vanilla may be an alternative to
catch some things that got away.

And as long as we're at it, I was checking the help files of iemguis for
Purr Data and realized that there are functionalities missing from 0.46!
Since 0.46 the iemguis do not clip values to the slider's range for
instance. That, nonetheless, is something that is mentioned in the release
notes, so maybe it's a good idea to also check on that release notes list
for things before 0.48 - but again, this change was also clearly mentioned
in the Pd documentation since 0.46, so going through the documentation
would also catch this up!

Anyway, I have opened issues regarding 0.48 compatibility in Purr
Data's gitlab repository, I guess that's all I know and the new more recent
information I have (regarding iemguis) I'm including in this email (if you
want I can add an issue for you). I'm aware of these things cause I was
somewhat involved with the changes, but who knows what else might be there
that is missing...

Cheers

Em sex., 19 de jun. de 2020 às 14:57, Jonathan Wilkes <
jon.w.wilkes at gmail.com> escreveu:

> 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
> _______________________________________________
> 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/20200619/ff14ab2f/attachment-0001.html>