diff vamp-support/LoaderRequests.h @ 185:3eb00e5c76c4

Pull step & block size out into framing struct, return in config

Update the C++ code to separate out the framing parameters (step and
block size) from the configuration structure into their own structure,
as in the latest schema, and to return the accepted framing params in
the configuration response.

This also implies that the plugin stub (which adapts Piper API
back to Vamp) makes a note of the returned values,
making them available via its own getPreferredStep/BlockSize
so that the host can retry the initialise call in the case where it
failed for having the wrong values first time.

--- a/vamp-support/LoaderRequests.h	Fri Feb 03 13:00:42 2017 +0000
+++ b/vamp-support/LoaderRequests.h	Fri Feb 03 16:23:21 2017 +0000
@@ -130,12 +130,32 @@
 	ConfigurationResponse response;
 
 	response.plugin = req.plugin;
-    
+
+        if (req.configuration.framing.stepSize == 0 ||
+            req.configuration.framing.blockSize == 0) {
+            return response;
+        }
+
 	if (req.plugin->initialise(req.configuration.channelCount,
-				   req.configuration.stepSize,
-				   req.configuration.blockSize)) {
+				   req.configuration.framing.stepSize,
+				   req.configuration.framing.blockSize)) {
+
 	    response.outputs = req.plugin->getOutputDescriptors();
-	}
+
+            // If the Vamp plugin initialise() call succeeds, then by
+            // definition it is accepting the step and block size
+            // passed in
+            response.framing = req.configuration.framing;
+
+	} else {
+
+            // If initialise() fails, one reason could be that it
+            // didn't like the passed-in step and block size. If we
+            // return its current preferred values here, the
+            // host/client can retry with these (if they differ)
+            response.framing.stepSize = req.plugin->getPreferredStepSize();
+            response.framing.blockSize = req.plugin->getPreferredBlockSize();
+        }
 
 	return response;
     }