comparison vamp-client/qt/AutoPlugin.h @ 186:52322dde68ea

Fix erroneous logic for handling step and block size in prior commit The earlier change had a logical misconception. If PluginStub is receiving the correct step and block size back from the configure call, the plugin on the server side must have already been successfully initialised, as the step and block size are only returned in a successful configure response. This means the test for a failed initialise and redo with the correct parameters must be done on the server side (in LoaderRequests) not the client. The client has a more complicated job, which is to notice that a *successful* configure had returned different framing parameters from those passed to the initialise call, and to pretend that it had actually failed until the host called again with the correct parameters. We definitely need tests for this!
author Chris Cannam <cannam@all-day-breakfast.com>
date Mon, 06 Feb 2017 16:44:33 +0000
parents 590b1a1fd955
children ad6025dc0b04 61034472c304
comparison
equal deleted inserted replaced
185:3eb00e5c76c4 186:52322dde68ea
136 } 136 }
137 137
138 virtual bool initialise(size_t inputChannels, 138 virtual bool initialise(size_t inputChannels,
139 size_t stepSize, 139 size_t stepSize,
140 size_t blockSize) { 140 size_t blockSize) {
141 try { 141 return getPlugin()->initialise(inputChannels, stepSize, blockSize);
142 return getPlugin()->initialise(inputChannels, stepSize, blockSize);
143 } catch (const ServiceError &e) {
144 // Sadly, the Vamp API has taught hosts to try to divine
145 // initialisation problems from a bool return value alone
146 log(std::string("AutoPlugin: initialise failed: ") + e.what());
147 return false;
148 }
149 } 142 }
150 143
151 virtual void reset() { 144 virtual void reset() {
152 getPlugin()->reset(); 145 getPlugin()->reset();
153 } 146 }