<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Jari et al,<br>
<br>
I have had an interesting talk with Michael Johnson, the VP of
engineering at MM.<br>
He told me that he sees the JW Lua development and plugins in
general for Finale very skeptical for one reason:<br>
too often they mess up Finale documents and users complain to MM
support for document problems that are very hard to track down and
were caused by invalid code in 3rd party plugins. This is also the
reason why MakeMusic doesn't give out the original Finale PDK
anymore.<br>
<br>
Is this really so severe ? I can't remember that this ever happened
to me, although it's a bit difficult to say as usually you don't
notice an internal document mess up at once.<br>
But in my experience it's more or less always Finale bugs that lead
to messy documents... ;-)<br>
<br>
What are your experiences ?<br>
I think it might be possible to do "bad stuff" in C++, but hardly in
JW Lua - assuming that Jari's framework is correct which can't be
guaranteed of course, but is very likely, taking the user feedback
that Jari received and his experience. <br>
<br>
There are a few examples where Jari made restrictions in the use
(e.g. SetNextSysMeasure_ in FCStaffSystem) or where a certain
function needed to be called first. But is there more than that ?<br>
Of course, you can mess up all sorts of flags - but only on purpose
and these can be removed as well.<br>
BTW, maybe it would make sense to integrate a check in Jari's
framework that guarantees that a certain function is called first if
this is necessary. It could be a very simple check (if
function-called-flag is not set then print to warning console).<br>
<br>
I only know one case where a Finale document is messed up and that
cannot be undone:<br>
when you change the documents fonts and the plugin crashes
afterwards, it's not possible to get back to the original fonts by
pressing undo (see my bug descriptions in the mails from
2015-02-19). To avoid this I have started to put all font changes to
the end of the plugin process (if possible), so that any crashes
that may appear before still wouldn't mess up the document, but
simply break with an error message. Since implementing that
workaround I didn't get any problems with JW Lua that couldn't be
undone.<br>
<br>
My experiences are just opposite of what Michael fears and what most
of you probably can confirm:<br>
I <u>very </u>often use JW Lua to <u>fix </u>Finale bugs and
messed up Finale flags. The Perfect Layout plugin for example
currently has about 10 plausability checks for invalid entry,
smartshape or measure flags. These are repaired automatically when
the plugin is sure that it has found an invalid value.<br>
<br>
What could be the outcome of this discussion ?<br>
As Jari and others suggested some time ago, it would be great if the
source code of his current PDK Framework was available to the public
(as is the <a
href="http://finaletips.nu/index.php/download/category/21-plug-in-development">old
version v0.19</a>), so that we could help provide code or bug
fixes. This would definitely boost the development of JW Lua. Even
if Jari had a final word on what code is allowed to go into the
framework. <br>
But this would only be possible if also the original Finale PDK was
made public again. Probably it would even be sufficient if not the
source code of the original PDK, but only the library/include files
were made available to be able to compile.<br>
If we could guarantee that the JW Lua framework is stable and safe,
then MM wouldn't have to worry and everybody would benefit from it.<br>
<br>
What do you think ?<br>
<br>
Best,<br>
Jan<br>
</body>
</html>