The reduce plugin is behaving oddly in this release. I have a score with 36 staves. I am reducing the wind parts two to a staff: i.e. Flute 1 and Flute 2 reduce to a single staff, Flutes 1 and 2. This continues on for all the winds.
With each successive instrument, the plug-in runs slower. When reducing the flutes (first), it took seconds. I am now reducing the horns (fifth) and it took nearly 5 minutes (enough time to type this message).
Addendum: I tried a standard trick -- closing the score and reopening it -- and that makes the problem go away, so I guess I'll just do that after reducing a couple of staves.
Sounds like memory is not being released somehow, which suggests that close and restart is what you would need to do.
Plugins have no control about when memory is released (though it is possible that these plugins have large blocks of global memory, and such memory is retained between sessions). I would not expect there to be an easy fix, but even at worst, a restart should clear such memory blocks.
At least you don't need to reboot the machine...
--
Bob
Just a user of Sibelius. Sib 1.2 - 7, Windows 7 Pro SP 1 64 bit, 4 G RAM. Year 2014.
You wrote this plugin, if memory serves. Thanks for the reply. This plugin is such a time-saver that I don't mind closing and reopening the file so that I can easily combine parts.
One avenue worth exploring is whether repeated use of this plug-in is clogging up the "undo" stack in Sibelius. Just simply saving the score should clear down the "undo" stack. Failing that, closing and re-opening the score should clear the problem.
--
Sibelius 7.5.1/7.1.3/6.2/5.2.5, PhotoScore Ult 7.0.2, Dolet 6.3 for Sibelius, Windows 7 32-bit SP1, 4GB RAM
Was just about to start a new post on this subject when I found this one. Just to say that I've found the same problem with Explode (which, I confess, is one that I wrote).
A benchmark test (Exploding 100 bars of 2 note crochets onto 2 staves) in Sib 7.1.3 takes approx. 1.8 seconds. Repeating the test 10 times gives about the same result.
The same test in Sib 7.5.1 gives the following times over 10 tests:
1.8
2.2
2.8
3.3
3.8
4.3
4.8
5.5
6.1
6.6
So really badly slowing down. I use these plugins hundreds of times a day when orchestrating, so the effect is really noticeable and (excuse the dramatic troll-type language) means that the 7.5 update is unusable for me.
I know that there have always been problems with the undo buffer getting full when plugins do many small edit operations (as Explode and Reduce do), but I'm bemused as to why we have taken so much of a step backwards with this update?
(Thanks Robin BTW - I have tried saving between plugin runs and it makes no difference, and closing and opening does solve it, but there's no way I'm doing that every time I use it.)
I'm on a maxed out Mac Pro so shouldn't be any CPU / memory issues at this end.
Kind of a shame we did not have this kind of data when Avid was working on 7.5.1, as it might have been possible to address the problem then. I suspect there will not be another release for some time.
I would also expect that running almost any plugin that does a lot of work repeatedly will have similar problems. If I encounter any specific examples, I will report them here.
--
Bob
Just a user of Sibelius. Sib 1.2 - 7, Windows 7 Pro SP 1 64 bit, 4 G RAM. Year 2014.
Unfortunately, changing the undo buffer doesn't make any difference - it is still a problem when it is set to the maximum of 30000 (or minimum, or in between).
Major, you can set the undo buffer by going to Sibelius/Preferences/Other - there is a slider where you can set the approx. number of notes to be saved.
FTR, I have been liasing with someone at Sibelius Support about this, who have been able to reproduce the problem and passed it onto the developers - so things are in motion to get a solution. For the time being, the suggestion is either to regularly quit and re-open files, or to just use 7.1 instead.
Not being able to use these plugins in Sibelius 7.5 is a big problem for me personally. I wish the same amount of thought could go into these problems as appear to have been applied to expanding the Sibelius fund raising options. Very disappointed...
David
Can anyone at Sibelius (Sam?) say if the upcoming Sibelius 8 addressed this issue? I use the Reduce, Explode, and Select Notes in Chord Position plugins as a basic part of my work process. I just finished doing a large orchestra score, and I had to work at a snail's pace-just painfully slow waiting for these plugins to work. This is a serious problem for me.
Thanks,
Dave Hanson
--
Sibelius 7.5 on Mac OS 10.9.5, 2.66 GHz Intel Core i7
4 GB 1067 mhz DDR3
Just checking in to report that this problem with the plugin buffer has not been fixed in Sib 8.0 - in fact, running the test plugin as described above it would seem to be even worse than in 7.5, with the 5th iteration taking over 7 seconds or hanging the whole program!
Fingers crossed that a fix will be one of the incremental improvements promised this year. In the meantime, it's back to 7.1.3 for my orchestral copying work…
Well, 3 1/2 months on and I was excited to grab Sib 8.0.1 this morning to see if this had been fixed and… no. Still as creaky as ever! My test plugin ran at 8 seconds, so even slightly slower than 8.0.
Several orchestrators and copyist have been in touch with me recently to see if I've come up with some under-the-hood fix for this, just so that they're actually able to use one of the newer versions, and I've been telling them to wait for 8.0.1 with crossed fingers, so sorry to all of them - I feel your pain!
Looks like at least another 3 months of ploughing on with 7.1.3, with Sibelius 8 waiting tantalisingly in the dock…
Once again reviving this thread with an update for today's 8.1 release - happy to confirm the claims in the release notes that this issue has been addressed! My benchmark tests show the following:
Sib 7.1
Iteration 1 took 1.126 seconds.
Iteration 2 took 1.379 seconds.
...
Iteration 9 took 2.315 seconds.
Iteration 10 took 2.446 seconds.
Sib 7.5
Iteration 1 took 1.153 seconds.
Iteration 2 took 2.102 seconds.
...
Iteration 9 took 34.388 seconds.
Iteration 10 took 47.016 seconds.
Sib 8.1
Iteration 1 took 1.18 seconds.
Iteration 2 took 1.48 seconds.
...
Iteration 9 took 2.739 seconds.
Iteration 10 took 2.765 seconds.
So very nearly back up to 7.1 speeds, and hopefully time will tell that there is no more deterioration of performance over a long score or session.
So well done and thanks to the crew who fixed this - it means that I can finally ditch my horrendous workflow of using 7.1 and 7.5 for different parts of my job, and (hopefully) just have the one icon sitting in the dock! Now, if I could just convince the half of my client base who are still on Sib6 to upgrade…
So, just out of curiosity, were changes made to the plugin code itself, or were the changes made to Sibelius? I would prefer the latter, because it means that whatever fixes were applied would benefit all plugins.
But if changes were made to the ManuScript code, I would be very interested in knowing what the changes were so I can see if I can do something similar to other plugins. If that is the case, could someone contact me off-list?
Thanks
--
Bob
An experienced user of Sibelius. Sib 1.2 - 8, Windows 7 Pro SP 1 64 bit, 8 G RAM. Year 2016.
