For reference when designing the tests in #66, and related to types like #27.
During manual testing of FrequencyBands I've found the following behaviour regarding its parameter types:
Passing it a JS String for its frequencyBands parameter (which expects a VectorFloat in C++) does NOT produce an error, as would be expected. This is after converting the given frequencyBands array to a VectorFloat through the existing utility function arrayToVector, which means the function can successfully copy a JS String into a C++ VectorFloat. The result of the conversion for a 5-letter String is a vector of 5 NaNs. Essentia then does not complain about this VectorFloat of NaNs.
Passing it a JS String for its float-typed sampleRate parameter produces an error only if the String contains text characters. However, it does not fail with a String containing numeric characters (such as "16000", instead of the JS Number of 16000). This means there is probably some sort of string->number type casting attempted somewhere in Embind, but I couldn't find any verification (checked here, here, here, here, and here).
I've opened a discussion on Emscripten's GitHub repository.
For reference when designing the tests in #66, and related to types like #27.
During manual testing of
FrequencyBandsI've found the following behaviour regarding its parameter types:Stringfor itsfrequencyBandsparameter (which expects aVectorFloatin C++) does NOT produce an error, as would be expected. This is after converting the givenfrequencyBandsarray to aVectorFloatthrough the existing utility functionarrayToVector, which means the function can successfully copy a JSStringinto a C++VectorFloat. The result of the conversion for a 5-letterStringis a vector of 5NaNs. Essentia then does not complain about thisVectorFloatofNaNs.Stringfor itsfloat-typedsampleRateparameter produces an error only if theStringcontains text characters. However, it does not fail with aStringcontaining numeric characters (such as"16000", instead of the JSNumberof16000). This means there is probably some sort of string->number type casting attempted somewhere in Embind, but I couldn't find any verification (checked here, here, here, here, and here).I've opened a discussion on Emscripten's GitHub repository.