[L2Ork-dev] call for mentorship: version bump

[Jonathan Wilkes]

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