I just found this thread, and there's a lot to catch up on here. I'll just start with a few comments:
It deserves note what a such a device actually measures vs. what we actually feel. (Many of you are probably already aware of this.) While this device could measure vibration transmitted through floors, furniture, and other objects in contact with our bodies, this device cannot measure tactile sensation that arises from sound (in the air) acting directly on our bodies. The transmission of acoustic energy from air to solid matter depends on impedance matching, and the impedance of different parts of each listeners; bodies will respond quite differently compared to furniture and stuff like that. Of course in practice, plenty of tactile sensation is felt through solids in contact with our bodies, so there is plenty of utility in such a device.
As noted in another post here, the vibrotactile human response curve peaks in the "low mid" frequencies, so being able to measure well beyond 250 Hz is probably a plus. Such capability might be useful for designing speaker enclosures among other things, where vibration is usually undesired.
Python is my primary language, and I would say the technology choices look very sound, except for the ReactJS. Not that there's necessarily anything wrong with ReactJS. I have no opinion. I'm just not a UI guy either.
However, one package that might be real nice to look at for data plotting via the web is bokeh
. What I like is that it includes a few simple UI controls and can interact with a server.
About Python concurrency and multiprocessing: Yes, there is a global interpreter lock (GIL) that prevents multiple threads from executing Python code within the same memory/process space at the same time. However, whether this is a major issue or not depends on your code architecture. IMO, the GIL is overblown as a programming restriction, typically by people who come from a Java or C++ world where the solution to any concurrency problem is almost always to use threads. I am of the strong opinion that using threads for any and all concurrency problems almost always leads to poor performance and/or stability. It's not that threads generically suck but rather that pretty much all programmers suck at writing code that uses threads.
The question is where you need concurrency and where you specifically need parallelism. There are many ways to achieve concurrency in-process in Python despite lack of true parallelism. For example, using libraries/architecture, Python code on a single core can handle on the order of 10000s simultaneous network connections while keeping latencies reasonable. Those who need to scale to multiple cores often need to scale to multiple server instances, and by that point, you need a multi-process architecture anyway. Lastly, the GIL can be easily bypassed by code that's written in C or C++, as long as it doesn't need to touch Python data structures. And for those rare occasions where multi-threading is necessary and multi-process is not, writing the threaded code in C or C++ will almost always be the better choice anyway.
Feel free to ask for clarification on stuff.