[L2Ork-dev] call for mentorship: version bump

[Ivica Bukvic]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200712/843cd48e/attachment.html>