<div dir="ltr"><div>Hi Jonathan,</div><div><br></div><div>I'd be for any change that improves Purr Data, but (as usual) I'm concerned about patch format compatibility with vanilla. Just to be clear, did I understand correctly that old patches (from either vanilla or older Purr Data versions) would still be *read* without a problem? And is it true that the (current and future versions of) vanilla will be able to *read* those new-format patches produced by future Purr Data (even if it does not write them at present)?</div><div><br></div><div>That's the most important question for me. Still, I'd *strongly* recommend adding an option to the prefs that will allow saving a patch in the old format, to allow for exchange of patches with colleagues and friends who, for some reason, might still be running an old version of Purr Data or vanilla. Or, better yet, offer a corresponding option in the File menu, i.e., a variant of "Save as..." but named "Save as old format...", "Export to old format...", or something similar. That should be fairly easy to implement. If we don't do this, my crystal ball tells me that there are going to be a *lot* of complaints. ;-)</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Albert<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 11, 2020 at 5:23 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">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></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>