XP: More Graphical Abnormalities: VSTGUI causing damage to scheduler?
I posted back about this a while back and my example/explanation of the problem wasn’t quite correct and failed to take notice. What I have found, and should be addressed, is that, in my own tests, approximately 300-400 vst plugins for windows out of about 800 I have do not work correctly with the vst~ object in max/msp.
What is happening is one of two things. In the first, less volitile situation, the Max scheduler is completely frozen. In the second scenario merely loading the program causes max to freeze, and, the task manager is required to close it down, if you can manage to open it.
So I made a small patch and included a few plugins, one which works, and one which doesn’t. Please, try it out and tell me what you think.
Here is the patch: http://bine.aporre.com/vst_scheduler_interface.zip
So, you load the first plugin, all is fine. Load the 2nd one, and the scheduler craps out. In regards to the 2nd plugin, like I said, I have tested about 800 plugins and about half of them suffer from this. A few of my plugin programming friends said that the problem was VSTGUI. I notice this kind of behavior in Cubase and such, but, the main difference between these 2 applications is that, in Cubase, it’ll still keep the timing and midi events won’t be frozen while the mouse button is down! Graphical updates will cease, but the timeline still goes forward and you can hear the musical information you’ve put in. Doing the same in max/msp completely freezes everything, so if you had some chords going into this Vst~ object from say, an external midi source, they wouldn’t be heard until AFTER you released the mouse button, meaning, well, it’s bad :/
Thanks for your time,
And, albeit possibly redundant, here is a list I have complied of plugins that DO interfere with the scheduler in this mannerism. Items prepended by a "_" mean *any* plugin by this developer causes this behavior. Items without are meant to represent individual plugin names. Albeit, I never meant to release this so…
_Prosoniq //Other Than Northpole
_Rcg Pentagon 1, Triangle 1+2
Admiral Quality Scamp
Aneotic Room Sim
Ballsequencer //(100% Cpu In Max)
Mjharmonicpingonly //Excessive Parameters
More Feedback Machine
Voyager (Cpu Error)
Xchorus //Doesn’t Respond To Cc Messages
ps-1 performance synth
Thanks for the patch and plugs James. I do not lose the scheduler entirely but I am seeing the scheduler stop when I am changing the params in the 2nd vst ( mouse held down)
That is very strange. I had no idea that some plugins
acted this way. My guess is that some plugins do not
have a separate thread for their UIs.
—– Original Message —–
From: Andrew Pask
Date: Friday, September 15, 2006 11:38 am
Subject: [maxmsp] Re: XP: More Graphical Abnormalities: VSTGUI causing
damage to scheduler?
> Thanks for the patch and plugs James. I do not lose the scheduler
> entirely but I am seeing the scheduler stop when I am changing the
> params in the 2nd vst ( mouse held down)
I can’t however, confirm the problem with Hematohm, with Overdrive on or off.
Hrm, well, I may have made some mistakes. I can guarentee that the majority of that list has problems =/ in the same way that the first one has. If you want, and since most are freeware, I can compile you some links so you don’t have to go searching for them. Or, if you’re content with just the first example, then I’ll opt out. Either way, it’d be good to find out what’s up. Aanti of smart electronix says its because people use VSTGUI to develop their interfaces, or something along those lines.
heres a few links for you Andrew….
I deleted the plugins on that list so I would have to reconfirm each link. These 3 seem to do the so called schedule stopping behavior. I think some of those plugins on that list are on there just because I don’t like them. Sorry, I’ll confirm some over again later today…
it sounds strange that VSTGUI should cause this.
what about midi? maybe it happens when a plug-in attempts
to send out midi (which vst~ doesnt want)
hematohm for example sens NRPN (2 CC at once when you move a dial)
Ok, thanks for the reporting. This has been fixed for the next release of Windows MaxMSP, which will be arriving shortly.
Andrew, you’re a god!! Thanks for responding and fixing this.
Any chance of posting this on the incremental update?