[JW Lua] Can JW Lua scripts mess up documents that can't be repaired afterwards ?

[Jan Angermüller]

Jari et al,

I have had an interesting talk with Michael Johnson, the VP of 
engineering at MM.
He told me that he sees the JW Lua development and plugins in general 
for Finale very skeptical for one reason:
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.

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.
But in my experience it's more or less always Finale bugs that lead to 
messy documents... ;-)

What are your experiences ?
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.

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 ?
Of course, you can mess up all sorts of flags - but only on purpose and 
these can be removed as well.
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).

I only know one case where a Finale document is messed up and that 
cannot be undone:
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.

My experiences are just opposite of what Michael fears and what most of 
you probably can confirm:
I _very _often use JW Lua to _fix _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.

What could be the outcome of this discussion ?
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 old version v0.19 
<http://finaletips.nu/index.php/download/category/21-plug-in-development>), 
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.
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.
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.

What do you think ?

Best,
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jwmusic.nu/pipermail/jwlua_jwmusic.nu/attachments/20161207/2de02422/attachment.html>