[L2Ork-dev] call for mentorship: version bump
jon.w.wilkes at gmail.com
Sun Jul 12 23:48:34 EDT 2020
On Sun, Jul 12, 2020 at 9:54 PM 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.
One possibility: after we default to saving the symbol colors, we can
post a warning on save that the lossless symbol colors
won't be readable on older Purr Data versions, and to use "pd
compatibility 0.47" to save in the compatible format.
Perhaps one such warning per instance if a patch with iemguis in it gets saved.
That's sufficiently annoying that it will teach the users who upgrade
what the issue is, without really getting in the way.
Then after a number of releases we can remove the warning.
> Those who consider this their primary variant of pure-data will not be concerned by this either way.
> 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
> 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.
>> > 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
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
More information about the L2Ork-dev