<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 11, 2020 at 6:49 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">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">Yes. The new code accepts either a float or a symbol in the iemgui arg<br>
slot for colors.</blockquote><div><br></div><div>Good.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes. Pd Vanilla has for awhile accepted both symbol and float args in<br>
the slot for the iemgui colors. And I can confirm it<br>
reads what I'm writing in the feature branch for Purr Data.<br></blockquote><div><br></div><div>Is that branch online somewhere? I couldn't find it at <a href="https://git.purrdata.net/jwilkes/purr-data">https://git.purrdata.net/jwilkes/purr-data</a>, and I'd really like to give it a go myself.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[; pd compatibility 0.47( should do the trick. For "Save with lossy<br>
iemgui color format" we could just switch to that<br>
version and then switch back.</blockquote><div><br></div><div>I'm not sure I understand. You simply put that message into the patch and then it saves it in the old format?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> But I'd want to remove that after a few versions.<br></blockquote><div><br></div><div>If by "a few versions" you mean "a really long time", then I'm alright with it. ;-) See, some people might be stuck with really old Pd versions for all kinds of different reasons, like running on really old hardware and/or a really old Linux version. So I'd say that even though we don't want to be held back by all those legacy systems, as long as we can at least provide some kind of compatibility with them on the patch format level, we should aim for that.<br></div><div><br> </div><div>Albert</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-Jonathan<br>
<br>
><br>
> Finally, concerning the version change: As I said various times before, I'm not a big fan of semantic versioning, but I can understand the rationale behind it. With a disruptive change like this, yes, that'd certainly be a case for a major version bump in the semantic versioning scheme.<br>
><br>
> Cheers,<br>
> Albert<br>
><br>
><br>
> On Sat, Jul 11, 2020 at 5:23 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>><br>
>> On Fri, Jul 10, 2020 at 5:40 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi all,<br>
>> ><br>
>> > I'm porting the "#ffffff" color syntax from Vanilla.<br>
>> ><br>
>> > The thing is-- this won't be forward compatible because new patches<br>
>> > will save iemgui color args as symbols. Previous versions will refuse<br>
>> > to read in the new args correctly because they check for floatargs in<br>
>> > those color slots of the arguments. This can give surprising behavior<br>
>> > to users one or two versions behind-- they'll see breakage in colors,<br>
>> > label display, and possibly other problems with patches created in the<br>
>> > newer version of Purr Data. Worse, there's no way to force an error to<br>
>> > be reported in the old versions, as the iemgui arg-loading code simply<br>
>> > fails silently if it gets wrong arg number and/or types.<br>
>> ><br>
>> > Vanilla's solution was to put a big "FIXME" comment while turning off<br>
>> > the ability to save the new symbolic color args for the time being.<br>
>> > This creates an insidious bug where users are already inputting the<br>
>> > precise "#123456" colors but continue getting the lossy behavior of<br>
>> > the weirdo integers.<br>
>> ><br>
>> > Is this a case for a major version bump? Anything less and I'm afraid<br>
>> > users on older versions won't realize the subtle change in file<br>
>> > format.<br>
>> ><br>
>> > Honestly, I'd rather add a line to the file format that crashes the<br>
>> > old versions than have subtle wrong behavior like this.<br>
>> ><br>
>> > Suggestions?<br>
>><br>
>> I'll answer my own question here:<br>
>><br>
>> We've actually had Vanilla's "version" global method since 2007. That allows<br>
>> us to do this:<br>
>><br>
>> 1. For the next release, hoist a bare message "pd version $whatever"<br>
>> to the top of each saved patch file.<br>
>> 2. If the version is greater than zero, all older versions of Purr<br>
>> Data will output an informative error telling<br>
>> them, "file format newer than this version of Pd (trying anyway...)".<br>
>> It's printed as an error in red, so that should<br>
>> be as obvious as we can get given the circumstances.<br>
>> 3. When people come to the list inquiring about it, we can tell them<br>
>> to upgrade Purr Data.<br>
>><br>
>> This will be a blocker for the next release, so if anyone want to take<br>
>> a stab at coding it that would be much<br>
>> appreciated.<br>
>><br>
>> Note: Vanilla added some code to compare against the current version<br>
>> like "0.47", so that could be handy in the<br>
>> future.<br>
>><br>
>> -Jonathan<br>
>><br>
>><br>
>><br>
>> ><br>
>> > -Jonathan<br>
>> _______________________________________________<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><br>
><br>
><br>
><br>
> --<br>
> 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/" rel="noreferrer" target="_blank">https://agraef.github.io/</a><br>
> _______________________________________________<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><br>
_______________________________________________<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></div>