search

BridgesUNCC / bridges-python

Python client library for Bridges
http://bridgesuncc.github.io
MIT License
2 stars 4 forks source link

Visualizing an AudioClip with a bit depth lower than 32 doesn't work with some clips #74

Closed KyleReto closed 4 years ago

KyleReto commented 4 years ago

Sometimes, the visualize method gives an error if the bit depth of the AudioClip is lower than 32. If a sample is set using set_sample() under certain conditions I can't quite figure out, visualizing the audio clip will cause an overflow error "signed short integer is greater than maximum". From what I can gather, this might be caused by python numbers being 32 bit, so assigning them into the clip when the bit depth is lower than 32 causes issues. In my testing, I found that trying to create a sine wave (starting at 0) failed on the first set_sample, which should have been a value of 0, but that just setting a sample to a value of 0 didn't cause it to fail in a vacuum. It's possible that this is just user error, but it's also possible that it's a bug in the python client, and I'm not sure which.

This makes it impossible, or at least difficult, to create an audio clip with a bit depth lower than 32. I've added a test case for this in bridges-client-testing\python\web_tutorial_mastercopy\audio_clip.py, although it's in main() and commented out (because it requires creating a separate audio clip with a different bit depth).

krs-world commented 4 years ago

Alec/Matthew, could one of you take a look at this? We need to figure this out soon..

esaule commented 4 years ago

I probably know what this is. The java and c++ clients were written assuming the bit_depth was always 32. Some of the normalizatin were hardcoded with that assumptin. I guess the python client has the same bug. Haven't looked into it yet.

esaule commented 4 years ago

mmm, there are lots of strange things in the python implementation of audioclip. It is entirely written assuming 32 bits. I'll have to make more changes than I thought.

esaule commented 4 years ago

alright. I went through the AudioClip class in python. I think it is now correct. It follows the same conventions as the java and C++ version. I noticed that the wave parser is much slower in python than c++, but not slow enough to be a problem in my opinion. so that's probably fine.

I updated the documentation of audioclip. And upgraded the python client on the cloud9 server to have the correct version.

@KyleReto check that everything is fine. But I ran the tests (after fixing them to the new convention) and they passed and generated the expected output, so I think they are fine. If there are still issues, reopen this issues.