Wed Feb 08, 2012 2:13 am
(Not sure if it's build specific, but I found this with the Win32 build as run under XP. Feel free to post if it happens in other OSs or if you know any more about this than I do.)
Probably needs to go under a bug report or similar documentation, but using an LFO or automation track to control VST instruments settings is a really easy way to crash the software. I think this is because it can create out-of-range values where they aren't expected. (Not 100% sure since I'm not really a programmer, but taking a guess based on what I do know.) So there might be decimals where integer steps are expected, a chance to divide-by-zero
, etc. that kind of thing.
Not sure if there's some way to check against a VSTi to see what kind of values certain parameters are expecting, or if these values can be filtered through a VSTi's GUI (which usually seem to not cause problems) somehow. If those dial outputs can be restricted to what's valid to the VSTi, I think this bug would go away.
Cool feature otherwise though. However, until this "easy to crash" issue with VeSTige is resolved I'd suggest just using the VSTi's GUI and the synch under this new feature to save presets rather than to experimentally drive parameters via other controls during playback. (Or you can tediously mull through and find what dials don't cause crashes, but good luck!)
Don't think it hurts anything else major, crash just means you've got to go through the task manager and kill hung app and hanging Remote VSTi processes. Annoying at worst. Just giving a heads up here if anyone else likes to experiment with these things like I do.
Probably needs to go under a bug report or similar documentation, but using an LFO or automation track to control VST instruments settings is a really easy way to crash the software. I think this is because it can create out-of-range values where they aren't expected. (Not 100% sure since I'm not really a programmer, but taking a guess based on what I do know.) So there might be decimals where integer steps are expected, a chance to divide-by-zero
, etc. that kind of thing.Not sure if there's some way to check against a VSTi to see what kind of values certain parameters are expecting, or if these values can be filtered through a VSTi's GUI (which usually seem to not cause problems) somehow. If those dial outputs can be restricted to what's valid to the VSTi, I think this bug would go away.
Cool feature otherwise though. However, until this "easy to crash" issue with VeSTige is resolved I'd suggest just using the VSTi's GUI and the synch under this new feature to save presets rather than to experimentally drive parameters via other controls during playback. (Or you can tediously mull through and find what dials don't cause crashes, but good luck!)
Don't think it hurts anything else major, crash just means you've got to go through the task manager and kill hung app and hanging Remote VSTi processes. Annoying at worst. Just giving a heads up here if anyone else likes to experiment with these things like I do.