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

Fri Jun 19 16:09:20 EDT 2020

Now I remember what my change was to iemguis. It was the issue of the
slider trying to reflect a value that it cannot because of the way how the
pixels were drawn using tcl/tk library and then outputting a different
value as a result of this misalignment. I believe that I fixed that part a
long time ago. As for the values passing unchanged by the object limits,
that is not something I believe is a good idea.

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 Fri, Jun 19, 2020, 16:05 Ivica Bukvic <ico at vt.edu> wrote:

>
> On Fri, Jun 19, 2020, 15:45 Alexandre Torres Porres <porres at gmail.com>
> wrote:
>
>> 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.
>>
>
> Thank you, Alexandre. This is all very helpful. Another way to approa h
> this is to simply do a diff of each file and slowly pick away at things we
> want/need. There aren't that many files to do this. It will, however,
> require a thorough regression checking afterwards.
>
>
>> 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!
>>
>
> IIRC Iemguis in 1.x used to long time ago not clip the values (or had the
> fix that ended passing the values through). Since, I have come to disagree
> with having values pass through the slider unchanged. If you want them
> unchanged, you should pass them directly, not through a GUI object that
> essentially then misleads user as to what is the number that is coming out
> of it. Otherwise you end up with a conflated logic where some objects pass
> values unchanged, while others don't (e.g. number vs numbers).
>
>
>> 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
>>
>
> BTW, now that the development pace is picking up significantly, we could
> use additional helping hands, so if you would like to help with merging
> these, your contributions will be more than welcome.
>
> Best,
>
> Ico
>
>
>> 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
>>
>> _______________________________________________
>> 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/006f2d91/attachment-0001.html>