Michael - just some thoughts on the interlocking questions of JW plugin updates and publishing a PDK:
Some Finale users highly depend on specific plugins or wouldn't update as long as they're not available. As for today, JW as an important plugin developer doesn't update his plugins. Such a situation can arise anytime in the future again. MM would again be the target for questions like "This xyz plugin is so essential for my work, why didn't you include it in the core code?".
Isn't that one of the strongest motivations for publishing a PDK, either pre-compiled or in any other form?
As it is now, there's no big plugin development community. But competition is good for business, and if one developer wouldn't update his plugins, others could jump into the market. If - yes, only if they would have a PDK. Don't get me wrong everyone, I don't want anyone to be kicked out of the market, but at the moment, no one can offer any real replacement for the JW plugins, although some users would urgently need them. This is an unsatisfying situation.
To avoid similar unsatisfying situations in the future, please count my vote for a published PDK, even in a precompiled version. I support Jan's suggestion and am also interested in making the step from JWLua to real plugins.
Thanks to all for the latest comments on this thread.
A few comments:
We’ve posted a statement on the status of Jari here, as pointed out by Michel. As I stated in the past, we’ve worked with Jari for the past 10+ years and we will continue to work with him to support his plug-ins. He is not an employee of MakeMusic.
Knut: The desire for automation of Finale has never waned since 1997. The question is only one of implementation. We have technical work to do in Finale first. That also hasn’t changed. Yes, the growing popularity of scripting languages like Lua have opened the doors to possibilities. Like you, I am passionate about Finale and will strive to share as much information as I can. There is room for improvement, no doubt, but my colleagues and I are working to be more transparent and predictable. In the end, as it should be, the user base will be the judge of our efforts and amount of trust we should merit based on what we deliver, when we deliver it, and the value added.
Jan: I respectfully disagree that the current PDK platform should be further built upon. As I mentioned previously, we want to provide a stable automation platform for users such as yourself. Regretfully, the current model is not that system.
Thank you to all for your support and patience. We will continue to modernize the code, support our 3rd party vendors, release frequent free updates for free, and ultimately work to built trust with all of you.
I really appreciate that, Michael! I'm sure your goals towards increased transparency and predictability are very sincere. Hopefully these efforts will be increasingly evident in your interaction with the user community and your continued development of Finale.
I can't speak for Jan, but I don't think he proposed any further development of the Finale PDK. Actually he seems to thoroughly recognize it's shortcomings in his post above, proposing only that it be released in a pre-compiled state to be able to use Jari's PDK framework, which is much more user friendly, but nevertheless dependent on the native PDK to be complete.
Just wanted to update that Jari has started releasing 64-bit versions of his plug-ins late this week. Access the downloads here.
I also wanted to thank you all for sharing your thoughts on the future of a scripting language, be it a Lua based or Finale PDK based solution. I completely agree with you that a community of such scripts would be wonderful and very helpful. I do hope we can get there sooner rather than later. Additionally, there are design flaws that have been addressed through various plug-in. I too want us to address the underlying problem in Finale. However, stabilizing the code base and addressing fundamental speed issues in the core app are a higher priority in the short term.
As always, thank you for your time, use of Finale, and honest feedback.
Chi, the Finale PDK Framework in Lua that you are referring to has been available since 2013 and regularly been updated.
But it's not the Finale PDK that this thread is about. It is Jari Williamsson's own framework that is a wrapper for the original Finale PDK. His framework is available in C++ (though not in the latest release) and for Lua.
Lua may not be the most popular programming language, but you must see it in context:
the language should work cross-platform, work together with the original Finale C++ code, probably be a scripting language (to not need any external compilers and other software) and it will mainly be used for small scripts that even non-professional developers can write. That's not really possible in C++ or Java. If you have worked with Jari's JW Lua framework, you will see that it more or less only has advantages in these areas. https://en.wikipedia.org/wiki/Scripting_language lists Lua as being as popular as Python.
You should subscribe to the JW Lua mailing list if you are interested in knowing more about Jari's framework.