[L2Ork-dev] call for mentorship: version bump

Mon Jul 13 02:50:33 EDT 2020

Ok, I concur, then so be it. Thanks for taking the time to discuss.

Yeah, I understand that we don't want to get bogged down in forward
compatibility issues, it's just that I tend to think of the *patch format*
as somewhat "sacred". ;-) That's because it's our rock bottom compatibility
layer with vanilla.

I certainly welcome those changes, we do maintain compatibility with Pd
0.47 in any case, which is 4 years old now. So there shouldn't be much of a
problem if we lose compatibility with even older versions at some point.

Thanks,
Albert

On Mon, Jul 13, 2020 at 3:54 AM Ivica Bukvic <ico at vt.edu> wrote:

> It seems to me that us, Purr-Data core developers, tend to
> over-think/engineer these things. I think we can move forward faster with
> both the introduction of the lossless interpretation of color scheme and
> the warning/error you mentioned in the next release. If there were any
> users who may have been deeply concerned by this, they would have voiced
> themselves out by now. We could always use the legacy flag to also force
> purr-data to save it in the old format and that way users would still have
> an option of having seamless transition between the vanilla and our
> version, but not at the expense of the default experience. Those who
> consider this their primary variant of pure-data will not be concerned by
> this either way.
>
> 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 Sun, Jul 12, 2020, 16:36 Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
>
>> On Sun, Jul 12, 2020 at 1:42 AM Albert Graef <aggraef at gmail.com> wrote:
>> >
>> > On Sat, Jul 11, 2020 at 11:59 PM Jonathan Wilkes <
>> jon.w.wilkes at gmail.com> wrote:
>> >>
>> >> https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/423
>> >
>> >
>> > Oops, sorry, I overlooked that. Thanks. I'll have a look and test it
>> out once you've resolved the merge conflict on regression_tests.pd.
>> >
>> >> > I'm not sure I understand. You simply put that message into the
>> patch and then it saves it in the old format?
>> >>
>> >> Yes.
>> >
>> >
>> > Ah, that's better than my suggestions, since it makes the compatibility
>> requirement visible in the patch.
>> >
>> > I still don't quite understand why you want to remove that feature
>> again rather sooner than later. Does it incur a lot of technical debt,
>> i.e., is it a lot of extra work to support that feature going forward?
>> >
>> > Also, I'm trying to understand the implications of removing that
>> feature again. Will it then become downright impossible to open patches
>> written by Purr Data in older Pd versions? Or will olden days Pd load them
>> anyway, just with the colors looking a bit out of whack? I don't think that
>> the latter is much of a problem. We've had forward compatibility issues
>> like these for a while already, that's just what we call progress over
>> here. ;-) As long as you can still load the patch in old Pd, and it more or
>> less works as intended with the usual amount of fiddling, most people
>> should be fine.
>> >
>> >> Regardless of what I do with the symbolic colors as saved in a patch
>> >> file, I'd still be implementing the "[color #ffffff(---[iemgui]"
>> >> syntax for setting colors at runtime. That feature is non-trivial to
>> >> backport on save, so any newer patches
>> >> using it will necessarily break for users who are stuck on old Pd
>> versions.
>> >
>> >
>> > Yes, I understand that, and I think that's fine. Rendering a patch
>> completely unreadable in old Pd by just saving it in Purr Data would be a
>> different matter, however; most people would likely consider that a bug.
>>
>> I think in 0.47 the code was added to Pd Vanilla to load the symbol
>> colors and accept them in the "color" message arguments.
>>
>> But it still saved colors using the lossy float type.
>>
>> Currently, Pd Vanilla still saves the lossy float type but understands
>> the symbol colors.
>>
>> Current Purr Data doesn't understand the symbol colors, and it
>> requires the args for iemguis to have the float color types. Otherwise
>> it won't display the colors correctly (and it appears it won't display
>> the label text when symbol colors are loaded from a patch file. I
>> haven't explored why, but neither Purr or Vanilla are saving symbol
>> colors to the patch file so this isn't a pressing issue.)
>>
>> So perhaps in the release after next I can add the code to understand
>> the symbol colors, and some versions later I will make symbol colors
>> the default to be saved. But in the meantime I'll also need to add a
>> warning any time symbol colors are used so that the user understands
>> they are *still* saved in the lossy format and therefore don't
>> properly display the color specified after reloading the patch.
>>
>> Pd Vanilla doesn't give such a warning. But while the old weirdo int
>> format was human unreadable, this "#ffffff" hex format is a web
>> standard and comes with clear expectations for the color output. So we
>> want to make it clear that even though we're using it in this interim
>> period, there's still a bug which is that you'll get different colors
>> once you save and reload the patch. That's a pretty nasty UI bug, and
>> until we shift to the symbol colors on save it will be with us.
>>
>> -Jonathan
>>
>>
>> >
>> > Albert
>> >
>> > --
>> > Dr. Albert Gr"af
>> > Computer Music Research Group, JGU Mainz, Germany
>> > Email: aggraef at gmail.com, web: https://agraef.github.io/
>> > _______________________________________________
>> > 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

-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200713/9f964f3a/attachment.html>