<div dir="ltr"><div>Ok, I concur, then so be it. Thanks for taking the time to discuss.<br></div><div><br></div><div> 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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Albert</div><div><br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 13, 2020 at 3:54 AM Ivica Bukvic <<a href="mailto:ico@vt.edu">ico@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>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.<br><br><div>Best,<br><br>Ico<br><br>-- <br>Ivica Ico Bukvic, D.M.A.<br>Director, Creativity + Innovation<br>Institute for Creativity, Arts, and Technology<br><br>Virginia Tech<br>Creative Technologies in Music<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br><br><a href="http://www.icat.vt.edu" target="_blank">www.icat.vt.edu</a><br><a href="http://www.performingarts.vt.edu" target="_blank">www.performingarts.vt.edu</a><br><a href="http://l2ork.icat.vt.edu" target="_blank">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net" target="_blank">ico.bukvic.net</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 12, 2020, 16:36 Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Jul 12, 2020 at 1:42 AM Albert Graef <<a href="mailto:aggraef@gmail.com" rel="noreferrer" target="_blank">aggraef@gmail.com</a>> wrote:<br>
><br>
> On Sat, Jul 11, 2020 at 11:59 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" rel="noreferrer" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>><br>
>> <a href="https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/423" rel="noreferrer noreferrer" target="_blank">https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/423</a><br>
><br>
><br>
> 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.<br>
><br>
>> > I'm not sure I understand. You simply put that message into the patch and then it saves it in the old format?<br>
>><br>
>> Yes.<br>
><br>
><br>
> Ah, that's better than my suggestions, since it makes the compatibility requirement visible in the patch.<br>
><br>
> 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?<br>
><br>
> 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.<br>
><br>
>> Regardless of what I do with the symbolic colors as saved in a patch<br>
>> file, I'd still be implementing the "[color #ffffff(---[iemgui]"<br>
>> syntax for setting colors at runtime. That feature is non-trivial to<br>
>> backport on save, so any newer patches<br>
>> using it will necessarily break for users who are stuck on old Pd versions.<br>
><br>
><br>
> 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.<br>
<br>
I think in 0.47 the code was added to Pd Vanilla to load the symbol<br>
colors and accept them in the "color" message arguments.<br>
<br>
But it still saved colors using the lossy float type.<br>
<br>
Currently, Pd Vanilla still saves the lossy float type but understands<br>
the symbol colors.<br>
<br>
Current Purr Data doesn't understand the symbol colors, and it<br>
requires the args for iemguis to have the float color types. Otherwise<br>
it won't display the colors correctly (and it appears it won't display<br>
the label text when symbol colors are loaded from a patch file. I<br>
haven't explored why, but neither Purr or Vanilla are saving symbol<br>
colors to the patch file so this isn't a pressing issue.)<br>
<br>
So perhaps in the release after next I can add the code to understand<br>
the symbol colors, and some versions later I will make symbol colors<br>
the default to be saved. But in the meantime I'll also need to add a<br>
warning any time symbol colors are used so that the user understands<br>
they are *still* saved in the lossy format and therefore don't<br>
properly display the color specified after reloading the patch.<br>
<br>
Pd Vanilla doesn't give such a warning. But while the old weirdo int<br>
format was human unreadable, this "#ffffff" hex format is a web<br>
standard and comes with clear expectations for the color output. So we<br>
want to make it clear that even though we're using it in this interim<br>
period, there's still a bug which is that you'll get different colors<br>
once you save and reload the patch. That's a pretty nasty UI bug, and<br>
until we shift to the symbol colors on save it will be with us.<br>
<br>
-Jonathan<br>
<br>
<br>
><br>
> Albert<br>
><br>
> --<br>
> Dr. Albert Gr"af<br>
> Computer Music Research Group, JGU Mainz, Germany<br>
> Email: <a href="mailto:aggraef@gmail.com" rel="noreferrer" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" rel="noreferrer noreferrer" target="_blank">https://agraef.github.io/</a><br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu" rel="noreferrer" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" rel="noreferrer" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div></div></div>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div></div></div></div></div></div>