Marc Lavallée wrote:
On Mon, 01 Feb 2016 01:17:42 +0000,
Stefan Schreiber <st...@mail.telepac.pt> wrote :
Again: You need a defined plan what your device is supposed to do, to
connect to which devices (PCs? iOS/Android devices? ...), etc.
The plan is to track the orientation of a moving body part that is
known to affect our ability to localize sound; according to recent
scientific studies, the head is a prime suspect. The connectivity
could be an option: serial, usb, wifi or bluetooth. Such a project does
not need all parameters to be defined in the rock, and prototypes are
required.
Pretty clear to me. Especially since I already have been involved in
Bo-Erik's close predecessor project, just a few months ago...
So don't worry: I fully understand that this is all about some HT
module, which will allow to implement head-tracked binaural decoders for
various surround formats, and maybe even for (motion-compensated) stereo
playback.
See also available "similar" products:
1. http://dysonics.com/
2. AmbiExplorer
3. http://www.3dsoundlabs.com/
---------------------------------------------------
Anyway: Isn't your project pretty finished when you will have decided
on the new < reference hardware >? I see this as an open hardware
project. Software/apps can be written later. You maybe would have to
implement just one < reference appliance >, which could be a PC
solution, or an Ambisonics playback app for Android.
The FreeIMU project was open (and is probably no longer maintained).
We can expect sensors, processors and transmitters to be updated
regularly, so I prefer to avoid defining a reference hardware.
But I also would expect that a company like Bosch will try to keep
backward-compatibility in its own chip/sensor families. (s. ARM
processors in general)
Simply,
a head tracking gizmo could be able to work with any software that
requires it, so the more open the better.
Agreed.
The protocol is probably more
important than the hardware, which could vary.
Disagreed. Most OS software I know assumes some specific hardware
environment. (For example, a PC. Which is not a fixed but sufficiently
defined environment.)
If both software and hardware are not really defined (I take the freedom
to combine your last two phrases!), you will end in chaos.
I am aware that different hardware designs can be adopted to fit to some
specific software stack. (This is the 2nd statement, but not the 1st.)
I would opt for a defined (even if flexible) hardware environment, and
to adapt this to as many software environments as possible. It is not
that easy to write solutions for Windows, MacOS, Linux, iOS, Android,
...you see what I mean.
Not < any > of the cited three "similar" products offers software for
any major OS. Which just shows once more that software adaptation is not
trivial.
Best regards,
Stefan
P.S.:
* FSSC = Fast and Simple Sound Control. The name is the aim... :-D
OSC is not ideal for slow links, because it requires a minimum of 24
bytes to send a single value... The Firmata protocol could be a better
choice: https://github.com/firmata
http://firmata.org/wiki/Design_Issues
--
Marc
Valuable point. But 100Hz * 24 bytes (or say 30 bytes) is still not that
much...
If BT has some latency issues or say (for example) Android, the problem
was not OSC.
_______________________________________________
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit
account or options, view archives and so on.
