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

[Bart Visser]

Hi all,

I’m surprised by the skepticism of Michael Johnson. I’ve never experienced anything like this with JW Lua (and can’t remember if this happend with other plugins). Jan’s experience is mine’s as well: with JW Lua we can fix bugs (or not fully functional features) in Finale. I for one would not only love to see more options within JW Lua but think MakeMusic should integrate it into Finale like they did with Human Playback.

So I disagree with Michael Johnson. I wonder if he can show concrete examples of this (besides the problem Jan has pointed out, which might be a bug that can be fixed).

All the best,


Bart


Op 7 december 2016 bij 11:46:52, Jan Angermüller (jan at angermueller.com) schreef:
> 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
> ),  
> 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
> _______________________________________________
> JWLua mailing list
> JWLua at jwmusic.nu
> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>