Re: [Sursound] Never do electronic in public.

[Marc Lavallée]

Another interesting chip is the Simblee,
for "simple bluetooth low energy"
(a quick search is recommended)

Strong points:
- small
- low power Bluetooth 
- low latency communication 
- embedded micro-controller with 29 GPIOs
- Arduino programming
- with a special mobile application framework
  (the app is streamed from the Simblee to the phone)
- programming FTDI transceiver is not fake... 

Combined with a BNO055 (and a small battery), 
it could make a very nice little head tracker.

On Mon, 1 Feb 2016 22:05:37 -0500, I wrote :
> Le Mon, 1 Feb 2016 22:01:26 +0100,
> Bo-Erik Sandholm  a écrit :
> 
> > http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/
> > In the near future serial over USB with windows might be flaky.
> 
> That may be another reason to go wireless...
> 
> A new chip, the esp32 (still in beta) is an upgrade of the esp8266,
> with two processors, wifi, bluetooth, extras gpios and a i2s interface
> (for audio), but with no usb (by design, because wireless is the
> future:
> 
> http://esp32.de/

--
Marc




___
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.

Re: [Sursound] Never do electronic in public.

[Dave Malham]

On this topic (of binaural/headtracking eyc.) there's some interesting
looking papers at the Audio for Games conference next weekend
http://www.audioforgames.net/2016/schedule-papers/

wish I was going
  Dave


On 3 February 2016 at 14:41, Jörn Nettingsmeier <
netti...@stackingdwarves.net> wrote:

> On 02/03/2016 02:48 PM, florian.came...@orf.at wrote:
>
> (But we shouldn't divert from the original topic.)
>>
>
> no, that is frowned upon here :-D
> thanks for the insightful comments, i was wondering the same...
>
>
>
>
> --
> Jörn Nettingsmeier
> Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
>
> Meister für Veranstaltungstechnik (Bühne/Studio)
> Tonmeister VDT
>
> http://stackingdwarves.net
>
> ___
> 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.
>



-- 

As of 1st October 2012, I have retired from the University.

These are my own views and may or may not be shared by the University

Dave Malham
Honorary Fellow, Department of Music
The University of York
York YO10 5DD
UK

'Ambisonics - Component Imaging for Audio'
-- next part --
An HTML attachment was scrubbed...
URL: 

___
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.

Re: [Sursound] Never do electronic in public.

[Jörn Nettingsmeier]

On 02/03/2016 02:48 PM, florian.came...@orf.at wrote:


(But we shouldn't divert from the original topic.)


no, that is frowned upon here :-D
thanks for the insightful comments, i was wondering the same...




--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net

___
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.

Re: [Sursound] Never do electronic in public.

[florian.camerer]

Woe, woe, this is a veritable can of worms (dialogue in the center)...
The film guys have good reasons for that, and a cheap escape is certainly not 
the reason.
When you strictly follow the placement of a person on the screen with the 
audio, the picture editing is 
very much enforced and underlined, and with rapid cuts the audio jumps around 
like a rubber ball.
So this philosophy is totally dependent on the cooperation of the director to 
shoot and edit in a way
so that following the audio panorama according to the picture is not cheesy.
And: very often there is ambience on top of the voices, so that makes things 
more believable.
I have tried following the picture placement once in a theater play 
post-production. After 3 minutes
I reverted to the center channel, because it sounded so "artificial". Sounds 
weird, yes, but if picture editing
does not fully respect stereo placement it does not really work. And which 
director takes care about stereo-
compatible picture editing? 

(But we shouldn't divert from the original topic.)

Best regards, Florian



Von: Sursound [sursound-boun...@music.vt.edu]" im Auftrag von "David 
Pickett [d...@fugato.com]
Gesendet: Mittwoch, 03. Februar 2016 12:32
An: Surround Sound discussion group
Betreff: Re: [Sursound] Never do electronic in public.

At 12:01 03-02-16, Justin Bennett wrote:

 >> On 02 Feb 2016, at 18:00, sursound-requ...@music.vt.edu wrote:
 >>
 >> From: David Pickett<mailto:d...@fugato.com>
 >>>
 >>
 >> But...  I seem to be the only person I know who complains about ALL
 >> the dialogue coming from the centre speaker on 5.1 movies!  Having
 >> sterero dialogue seems to me to be a basic necessity for realism (AKA
 >> consistent and natural cues)!
 >>
 >> David

  If you sit in the middle of the (home)
 >cinema then of course you can
 >use stereo effectively, but think of the poor person sitting on the
 >end of the row, all the dialogue
 >then sounds like it comes from the closest speaker.

If the off-axis listener gets mono from the
closest speaker, in what way is that any worse
than the person in the middle when all that is
available to him is mono from the centre
speaker?  At least with stereo dialogue, the
person in the middle gets in, and the others are
no worse off than with only a centre feed.

 >Same problem in amplified theatre / opera, etc..

Same problem with any real 2 channel stereo.  So
why dont we make MONO recordings instead.

 >Centre-speaker dialogue is a cheap way to
ignore the problem, so that’s what happens most!

Cheap is the right word!

David

___
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.
___
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.

Re: [Sursound] Never do electronic in public.

[David Pickett]

At 12:01 03-02-16, Justin Bennett wrote:

>> On 02 Feb 2016, at 18:00, sursound-requ...@music.vt.edu wrote:
>>
>> From: David Pickett
>>>
>>
>> But...  I seem to be the only person I know who complains about ALL
>> the dialogue coming from the centre speaker on 5.1 movies!  Having
>> sterero dialogue seems to me to be a basic necessity for realism (AKA
>> consistent and natural cues)!
>>
>> David

 If you sit in the middle of the (home)
>cinema then of course you can
>use stereo effectively, but think of the poor person sitting on the
>end of the row, all the dialogue
>then sounds like it comes from the closest speaker.

If the off-axis listener gets mono from the 
closest speaker, in what way is that any worse 
than the person in the middle when all that is 
available to him is mono from the centre 
speaker?  At least with stereo dialogue, the 
person in the middle gets in, and the others are 
no worse off than with only a centre feed.


>Same problem in amplified theatre / opera, etc..

Same problem with any real 2 channel stereo.  So 
why dont we make MONO recordings instead.


>Centre-speaker dialogue is a cheap way to 
ignore the problem, so that’s what happens most!


Cheap is the right word!

David

___
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.

Re: [Sursound] Never do electronic in public.

[Eero Aro]

David Pickett wrote:


But...  I seem to be the only person I know who complains about ALL
the dialogue coming from the centre speaker on 5.1 movies!  Having
sterero dialogue seems to me to be a basic necessity for realism (AKA
consistent and natural cues)!


That was the fault of the film sound that Alan Blumlein didn't like.
That's why he started his project to "make the voice follow the person".

There was a period in 1950's when the voice did follow the person,
especially in widescreen movies. Oklahoma! is a good example.
But soon the dialogue was put into the center channel only.

Eero
___
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.

Re: [Sursound] Never do electronic in public.

[Justin Bennett]

> On 02 Feb 2016, at 18:00, sursound-requ...@music.vt.edu wrote:
> 
> From: David Pickett
>> 
> 
> But...  I seem to be the only person I know who complains about ALL
> the dialogue coming from the centre speaker on 5.1 movies!  Having
> sterero dialogue seems to me to be a basic necessity for realism (AKA
> consistent and natural cues)!
> 
> David

Or better, use LCR / trifield. If you sit in the middle of the (home) cinema 
then of course you can
use stereo effectively, but think of the poor person sitting on the end of the 
row, all the dialogue
then sounds like it comes from the closest speaker. Same problem in amplified 
theatre / opera, etc..
Centre-speaker dialogue is a cheap way to ignore the problem, so that’s what 
happens most!

best, Justin



Justin Bennett

jus...@justinbennett.nl
www.justinbennett.nl
http://jubilee-art.org/



___
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.

Re: [Sursound] Never do electronic in public.

[Marc Lavallée]

On Tue, 2 Feb 2016 16:46:33 +0530, umashankar manthravadi wrote:
> One more question. How useful or effective is it to have headtracking
> only on the horizontal axis ? will it help at all ?
> 
> umashankar

The horizontal axis is the most important and the easiest. With a
horizontal only decoder, the vertical cues are simply mapped to the
horizon (and faded, I suppose). The result can be as good/bad as plain
stereo on headphones, with the "in the head" sensation... It can be
much better too, because it's nice to turn the head and hear the sound
changing accordingly; impression of some realism is a legitimate quest.

On Tue, 02 Feb 2016 08:37:16 +0100, David Pickett wrote:
> Although I use a pair of Sennheiser HD600 headphones almost every day
> for making and editing recordings, I cant get at all excited about
> having to wear headphones to listen to music for pleasure, and
> unlike  mulitchannel loudspeaker surround, I personally regard the
> effort to perfect binaural sound on headphones as a waste of time
> and  energy.  This may be my loss; but it is my honest opinion, and
> others are entitled to disagree.

I partially agree.
Listening to imperfect HRTF is not worst than listening with some other
imperfect method; I mean, it could be enjoyable too... It depends on the
context; some audiophiles prefer mono for good reasons. It's nice
to listen to one instrument (piano or voice for example) from one mono
source that echos in a room; it can be much better than sitting
right in the middle of a speaker array that tries to mimic some other
audio environment. Simplicity is valuable (even when avoidable), and
that's why some people can enjoy bad music with bad ear buds in noisy
environments.

I guess I'm not helping much...
--
Marc
___
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.

Re: [Sursound] Never do electronic in public.

[umashankar manthravadi]

One more question. How useful or effective is it to have headtracking only on 
the horizontal axis ? will it help at all ?

umashankar

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: David Pickett<mailto:d...@fugato.com>
Sent: Tuesday, February 2, 2016 3:19 PM
To: Surround Sound discussion group<mailto:sursound@music.vt.edu>
Subject: Re: [Sursound] Never do electronic in public.

At 10:37 02-02-16, Politis Archontis wrote:

 >The issue is that all these emerging VR and AR technologies,
 >independently of if they will be successful or not, should be designed
 >from the bottom-up to deliver consistent and natural cues, especially
 >if you are mixing reality with the virtual. Otherwise, you end up with
 >a mess of audiovisual conflicting cues, which may be exhausting and
 >disorientating.

But...  I seem to be the only person I know who complains about ALL
the dialogue coming from the centre speaker on 5.1 movies!  Having
sterero dialogue seems to me to be a basic necessity for realism (AKA
consistent and natural cues)!

David

___
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.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20160202/27b4ccf6/attachment.html>
___
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.

Re: [Sursound] Never do electronic in public.

[David Pickett]

At 10:37 02-02-16, Politis Archontis wrote:

>The issue is that all these emerging VR and AR technologies,
>independently of if they will be successful or not, should be designed
>from the bottom-up to deliver consistent and natural cues, especially
>if you are mixing reality with the virtual. Otherwise, you end up with
>a mess of audiovisual conflicting cues, which may be exhausting and
>disorientating.

But...  I seem to be the only person I know who complains about ALL 
the dialogue coming from the centre speaker on 5.1 movies!  Having 
sterero dialogue seems to me to be a basic necessity for realism (AKA 
consistent and natural cues)!


David

___
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.

Re: [Sursound] Never do electronic in public.

[Politis Archontis]

Hi David,

I agree completely with what you say apart from a single point: This dichotomy 
is the exact reason why, in my opinion, proper binaural rendering is crucial. 
And I don’t think music is the issue here anyway (actually most of the people I 
know listening to music with loudspeakers at their places, are perfectly happy 
with a mono playback, or preference to a “diffuse” room sound, since they will 
rarely sit down to listen to music specifically). The issue is that all these 
emerging VR and AR technologies, independently of if they will be successful or 
not, should be designed from the bottom-up to deliver consistent and natural 
cues, especially if you are mixing reality with the virtual. Otherwise, you end 
up with a mess of audiovisual conflicting cues, which may be exhausting and 
disorientating. 

About music listening however, there is a chance that with headphones you can 
teach all these young people some proper listening habits! since if the 
processor binauralizes and externalizes correctly the stereo or multichannel 
recording, then they won’t be able to escape the sweet spot :-).

Regards,
Archontis

> On 02 Feb 2016, at 09:37, David Pickett  wrote:
> 
> At 07:42 02-02-16, umashankar manthravadi wrote:
> 
> >For the moment, I would like video kept out of motion tracked audio on
> >headphones. I want this to be a system where I can sit in a rocking
> >chair and listen to music of many kinds on a good pair of headphones
> >and the headtracking is only to reinforce the audio image.
> 
> Although I use a pair of Sennheiser HD600 headphones almost every day for 
> making and editing recordings, I cant get at all excited about having to wear 
> headphones to listen to music for pleasure, and unlike mulitchannel 
> loudspeaker surround, I personally regard the effort to perfect binaural 
> sound on headphones as a waste of time and energy.  This may be my loss; but 
> it is my honest opinion, and others are entitled to disagree.
> 
> Most young people that I see in the city where I live seem to have earbuds 
> permanently in their ears; they are presumably listening to normal stereo 
> recordings made for loudspeakers and seem to be quite happy with that format 
> and MP3 quality.  I fear it might be rather disorienting for such people to 
> be listening to recordings that give them cues that contradict those they 
> would get from the environment where they are actually standing or walking.  
> Unlike Umashankar at home in his rocking chair, this is at least rather 
> dichotomous, or whatever the word is.
> 
> David
> 
> ___
> 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.

___
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.

Re: [Sursound] Never do electronic in public.

[David Pickett]

At 07:42 02-02-16, umashankar manthravadi wrote:

>For the moment, I would like video kept out of motion tracked audio on
>headphones. I want this to be a system where I can sit in a rocking
>chair and listen to music of many kinds on a good pair of headphones
>and the headtracking is only to reinforce the audio image.

Although I use a pair of Sennheiser HD600 headphones almost every day 
for making and editing recordings, I cant get at all excited about 
having to wear headphones to listen to music for pleasure, and unlike 
mulitchannel loudspeaker surround, I personally regard the effort to 
perfect binaural sound on headphones as a waste of time and 
energy.  This may be my loss; but it is my honest opinion, and others 
are entitled to disagree.


Most young people that I see in the city where I live seem to have 
earbuds permanently in their ears; they are presumably listening to 
normal stereo recordings made for loudspeakers and seem to be quite 
happy with that format and MP3 quality.  I fear it might be rather 
disorienting for such people to be listening to recordings that give 
them cues that contradict those they would get from the environment 
where they are actually standing or walking.  Unlike Umashankar at 
home in his rocking chair, this is at least rather dichotomous, or 
whatever the word is.


David

___
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.

Re: [Sursound] Never do electronic in public.

[umashankar manthravadi]

For the moment, I would like video kept out of motion tracked audio on 
headphones. I want this to be a system where I can sit in a rocking chair and 
listen to music of many kinds on a good pair of headphones and the headtracking 
is only to reinforce the audio image.

Umashankar
p.s. I have ordered bits to build a usb contraption to turn headmovements into 
xy.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Stefan Schreiber<mailto:st...@mail.telepac.pt>
Sent: Tuesday, February 2, 2016 3:32 AM
To: Surround Sound discussion group<mailto:sursound@music.vt.edu>
Subject: Re: [Sursound] Never do electronic in public.

David McGriffy wrote:

>
>I got a GearVR recently and it does work better than Google Cardboard. Much
>of this is just comfort, I think, but I understand that it has its own
>gyros, mostly because they are faster. 'Heresay' is that the Oculus Rift
>samples at least 1000Hz. I have actually written an audio rate rotate that
>could handle this, but it does seem like overkill. At normal head turning
>rates, I find interpolating the rotation within each block to be enough.
>
>
>
http://blogs.valvesoftware.com/abrash/latency-the-sine-qua-non-of-ar-and-vr/

(Written by a super-expert of VR)

> Assuming accurate, consistent tracking (and that’s a big if, as I’ll
> explain one of these days), the enemy of virtual registration is
> latency. < If too much time elapses between the time your head starts
> to turn and the time the image is redrawn to account for the new pose,
> the virtual image will drift far enough so that it has clearly wobbled
> (in VR), or so that is obviously no longer aligned with the same
> real-world features (in AR). >

(Elaboration:)

> Suppose you rotate your head at 60 degrees/second. That sounds fast,
> but in fact it’s just a slow turn; you are capable of moving your head
> at hundreds of degrees/second. Also suppose that latency is 50 ms and
> resolution is 1K x 1K over a 100-degree FOV. Then as your head turns,
> the virtual images being displayed are based on 50 ms-old data, which
> means that their positions are off by three degrees, which is wider
> than your thumb held at arm’s length. Put another way, the object
> positions are wrong by 30 pixels. Either way, the error is very
> noticeable.


In other words: There are speed/delay problems, there are sync problems,
there might be more...


> You can do prediction to move the drawing position to the right place,
> and that works pretty well most of the time. Unfortunately, when there
> is a sudden change of direction, the error becomes even bigger than
> with no prediction.


> Tracking latency is highly dependent on the system used. An IMU (3-DOF
> gyro and 3-DOF accelerometer) has very low latency – on the order of 1
> ms – but drifts. < In particular, position derived from the
> accelerometer drifts badly, because it’s derived via double
> integration from acceleration. > Camera-based tracking doesn’t drift,
> but has high latency due to the need to capture the image, transfer it
> to the computer, and process the image to determine the pose; that can
> easily take 10-15 ms. < Right now, one of the lowest-latency
> non-drifting accurate systems out there is a high-end system from NDI,
> which has about 4 ms of latency, so we’ll use that for the tracking
> latency. >



> It would be far easier and more generally applicable to have the
> display run at 120 Hz, which would immediately reduce display latency
> to about 8 ms, bringing total latency down to 12-14 ms.

(s. PlaystationVR...)

> If you ever thought that AR/VR was just a simple matter of showing an
> image on the inside of glasses or goggles, I hope that by this point
> in the blog it’s become clear just how complex and subtle it is to
> present convincing virtual images – and we’ve only scratched the surface.


Wise words... (No, really!)

But not to get stuck and despair: Motion-tracked audio seems to be
so much easier to realize...


Best regards,

Stefan









___
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.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20160202/64330e2c/attachment.html>
___
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.

Re: [Sursound] Never do electronic in public.

[Marc Lavallée]

Le Mon, 1 Feb 2016 22:01:26 +0100,
Bo-Erik Sandholm  a écrit :

> http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/
> In the near future serial over USB with windows might be flaky.

That may be another reason to go wireless...

A new chip, the esp32 (still in beta) is an upgrade of the esp8266,
with two processors, wifi, bluetooth, extras gpios and a i2s interface
(for audio), but with no usb (by design, because wireless is the future:

http://esp32.de/

--
Marc

___
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.

Re: [Sursound] Never do electronic in public.

[Stefan Schreiber]

David McGriffy wrote:



I got a GearVR recently and it does work better than Google Cardboard. Much
of this is just comfort, I think, but I understand that it has its own
gyros, mostly because they are faster. 'Heresay' is that the Oculus Rift
samples at least 1000Hz. I have actually written an audio rate rotate that
could handle this, but it does seem like overkill. At normal head turning
rates, I find interpolating the rotation within each block to be enough.

 


http://blogs.valvesoftware.com/abrash/latency-the-sine-qua-non-of-ar-and-vr/

(Written by a super-expert of VR)

Assuming accurate, consistent tracking (and that’s a big if, as I’ll 
explain one of these days), the enemy of virtual registration is 
latency. < If too much time elapses between the time your head starts 
to turn and the time the image is redrawn to account for the new pose, 
the virtual image will drift far enough so that it has clearly wobbled 
(in VR), or so that is obviously no longer aligned with the same 
real-world features (in AR). >


(Elaboration:)

Suppose you rotate your head at 60 degrees/second. That sounds fast, 
but in fact it’s just a slow turn; you are capable of moving your head 
at hundreds of degrees/second. Also suppose that latency is 50 ms and 
resolution is 1K x 1K over a 100-degree FOV. Then as your head turns, 
the virtual images being displayed are based on 50 ms-old data, which 
means that their positions are off by three degrees, which is wider 
than your thumb held at arm’s length. Put another way, the object 
positions are wrong by 30 pixels. Either way, the error is very 
noticeable.



In other words: There are speed/delay problems, there are sync problems, 
there might be more...



You can do prediction to move the drawing position to the right place, 
and that works pretty well most of the time. Unfortunately, when there 
is a sudden change of direction, the error becomes even bigger than 
with no prediction. 



Tracking latency is highly dependent on the system used. An IMU (3-DOF 
gyro and 3-DOF accelerometer) has very low latency – on the order of 1 
ms – but drifts. < In particular, position derived from the 
accelerometer drifts badly, because it’s derived via double 
integration from acceleration. > Camera-based tracking doesn’t drift, 
but has high latency due to the need to capture the image, transfer it 
to the computer, and process the image to determine the pose; that can 
easily take 10-15 ms. < Right now, one of the lowest-latency 
non-drifting accurate systems out there is a high-end system from NDI, 
which has about 4 ms of latency, so we’ll use that for the tracking 
latency. >




It would be far easier and more generally applicable to have the 
display run at 120 Hz, which would immediately reduce display latency 
to about 8 ms, bringing total latency down to 12-14 ms.


(s. PlaystationVR...)

If you ever thought that AR/VR was just a simple matter of showing an 
image on the inside of glasses or goggles, I hope that by this point 
in the blog it’s become clear just how complex and subtle it is to 
present convincing virtual images – and we’ve only scratched the surface. 



Wise words... (No, really!)

But not to get stuck and despair: Motion-tracked audio seems to be 
so much easier to realize...



Best regards,

Stefan









___
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.

Re: [Sursound] Never do electronic in public.

[Stefan Schreiber]

Stefan Schreiber wrote:


David McGriffy wrote:



I got a GearVR recently and it does work better than Google 
Cardboard. Much

of this is just comfort, I think, but I understand that it has its own
gyros, mostly because they are faster. 'Heresay' is that the Oculus Rift
samples at least 1000Hz.


Yes, but do you need this?

The Rift is scheduled for release on March 28, 2016, making it one of 
the first consumer-targeted virtual reality headsets. It has a 
resolution of 1080×1200 per eye, a 90 Hz refresh rate, and a wide 
field of view.



https://en.wikipedia.org/wiki/Oculus_Rift

I see an issue if an assumed 125 Hz or 250 Hz sensor is not synced to 
90 Hz, because this will lead to different "phases" brought into a 
non-fractional pattern. The problem then is that the 90Hz impression 
will be not be really smooth, in this case (A kind of 3:2 pulldown 
effect, so to speak. Different time lengths in 90 uneven parts, old 
story.)


You don't have to sync sensor and screen update speeds  if you have a 
very high sensor speed.


And if I think about a bit further:

The video frames (75 to 120 Hz refresh rate) should be built up 
according "current" positional and view directional data.


The audio case is a bit different, IMO. Audio synthesis (VR/AR) has to 
be aligned with the video data, but the "colour changes" introduced by 
head orientation are very probably less time-sensitive. (s. available 
studies I have cited.)


Does this make sense?

Stefan






If you are thinking wireless headphones, remember the latency that that
introduces. I find my everyday bluetooth headset, built for music, is
useless for VR because of latency.


You don't need (absolute) real-time capability to listen to a recording.

Tracking needs RT response.

Best,

Stefan


And if you headphones are going to be
wired, then running that extra USB might not be too bad.

David McGriffy


On Mon, Feb 1, 2016 at 12:49 PM, Bo-Erik Sandholm 
wrote:

 

Apperently there exists a head tracking specialized version of the 
bno055

called bno070 - but I cannot find a place to buy this.
you can get up to 250 samples / second from that version.

Matthias did not complain about the update rate with the DIY 
headtracker

http://www.rcgroups.com/forums/showthread.php?t=1677559


http://electronicspurchasingstrategies.com/2014/03/06/hillcrest-bosch-sensortec-collaborate-sensor-hub-solution/ 



http://docsfiles.com/pdf_bno070.html


http://ae-bst.resource.bosch.com/media/_tech/media/product_flyer/Mobile-Hillcrest-Labs-Sensor-Hub-Product-Brief-BNO0701.pdf 




https://www.eiseverywhere.com/file_uploads/5c881a2f6eaaa90ed3f3d30fb20852db_Newsflash_BNO077.pdf 




maybe it is better to not think about that and try and use what I 
have ?


It is easy to find videos about using the bno055 in different 
projects but

i do not want videos... have not found links to the software used...



Better luck when google github bno055 :-)


https://www.reddit.com/r/virtualreality/comments/3faq11/why_we_need_to_move_to_ambisonic_sound_in_the/ 



http://vriscoming.com/daydream-vr/

Bo-Erik

2016-02-01 18:56 GMT+01:00 Marc Lavallee :

  


On Mon, 01 Feb 2016 17:46:47 +
Stefan Schreiber  wrote:



What is a 10 DOF motion sensor??? (Didn't you mean 9DOF?)
  


It's 9DOF + barometric pressure, so 9DOF is enough. For more info:




http://playground.arduino.cc/Main/WhatIsDegreesOfFreedom6DOF9DOF10DOF11DOF 

  


--
Marc
___
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.




-- next part --
An HTML attachment was scrubbed...
URL: <
https://mail.music.vt.edu/mailman/private/sursound/attachments/20160201/252ce84f/attachment.html 

  
___

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.

  


-- next part --
An HTML attachment was scrubbed...
URL: 
 


___
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.


 



___
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.




___
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.

Re: [Sursound] Never do electronic in public.

[Stefan Schreiber]

David McGriffy wrote:



I got a GearVR recently and it does work better than Google Cardboard. Much
of this is just comfort, I think, but I understand that it has its own
gyros, mostly because they are faster. 'Heresay' is that the Oculus Rift
samples at least 1000Hz.


Yes, but do you need this?

The Rift is scheduled for release on March 28, 2016, making it one of 
the first consumer-targeted virtual reality headsets. It has a 
resolution of 1080×1200 per eye, a 90 Hz refresh rate, and a wide 
field of view.


https://en.wikipedia.org/wiki/Oculus_Rift

I see an issue if an assumed 125 Hz or 250 Hz sensor is not synced to 90 
Hz, because this will lead to different "phases" brought into a 
non-fractional pattern. The problem then is that the 90Hz impression 
will be not be really smooth, in this case (A kind of 3:2 pulldown 
effect, so to speak. Different time lengths in 90 uneven parts, old story.)


You don't have to sync sensor and screen update speeds  if you have a 
very high sensor speed.





If you are thinking wireless headphones, remember the latency that that
introduces. I find my everyday bluetooth headset, built for music, is
useless for VR because of latency. 


You don't need (absolute) real-time capability to listen to a recording.

Tracking needs RT response.

Best,

Stefan


And if you headphones are going to be
wired, then running that extra USB might not be too bad.

David McGriffy


On Mon, Feb 1, 2016 at 12:49 PM, Bo-Erik Sandholm 
wrote:

 


Apperently there exists a head tracking specialized version of the bno055
called bno070 - but I cannot find a place to buy this.
you can get up to 250 samples / second from that version.

Matthias did not complain about the update rate with the DIY headtracker
http://www.rcgroups.com/forums/showthread.php?t=1677559


http://electronicspurchasingstrategies.com/2014/03/06/hillcrest-bosch-sensortec-collaborate-sensor-hub-solution/

http://docsfiles.com/pdf_bno070.html


http://ae-bst.resource.bosch.com/media/_tech/media/product_flyer/Mobile-Hillcrest-Labs-Sensor-Hub-Product-Brief-BNO0701.pdf


https://www.eiseverywhere.com/file_uploads/5c881a2f6eaaa90ed3f3d30fb20852db_Newsflash_BNO077.pdf


maybe it is better to not think about that and try and use what I have ?

It is easy to find videos about using the bno055 in different projects but
i do not want videos... have not found links to the software used...



Better luck when google github bno055 :-)


https://www.reddit.com/r/virtualreality/comments/3faq11/why_we_need_to_move_to_ambisonic_sound_in_the/

http://vriscoming.com/daydream-vr/

Bo-Erik

2016-02-01 18:56 GMT+01:00 Marc Lavallee :

   


On Mon, 01 Feb 2016 17:46:47 +
Stefan Schreiber  wrote:
 


What is a 10 DOF motion sensor??? (Didn't you mean 9DOF?)
   


It's 9DOF + barometric pressure, so 9DOF is enough. For more info:

 


http://playground.arduino.cc/Main/WhatIsDegreesOfFreedom6DOF9DOF10DOF11DOF
   


--
Marc
___
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.

 


-- next part --
An HTML attachment was scrubbed...
URL: <
https://mail.music.vt.edu/mailman/private/sursound/attachments/20160201/252ce84f/attachment.html
   


___
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.

   


-- next part --
An HTML attachment was scrubbed...
URL: 

___
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.

 



___
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.

Re: [Sursound] Never do electronic in public.

[Bo-Erik Sandholm]

http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/
In the near future serial over USB with windows might be flaky.

Bo-Erik
On 1 Feb 2016 21:53, "Bo-Erik Sandholm"  wrote:

> Standard aliexpress Bluetooth module v2.0+edr have a data rate of 2.1
> Mbit/s
> It is not so bad if you can get the sensors UART to push data near that
> speed.
>
> - Bo-Erik
> On 1 Feb 2016 20:33, "David McGriffy"  wrote:
>
>> Right, 10DOF is with altitude. I'm building a drone controller out of
>> piece
>> parts as a demonstration.
>>
>> Yes, there are certainly ways to achieve low latency convolution, but all
>> at the expense of CPU, which is already at a premium when running on
>> phones.
>>
>> I first heard the 20ms figure from some folks working in the VR biz.
>> Admittedly, they are more camera and content producers and not headset
>> makers, so perhaps this is just a dream goal of theirs. It does make some
>> sense to me as that's 50Hz, or the same as some TV refresh rates. Being
>> one
>> frame off there can certainly be noticeable, especially with speech vs
>> moving lips.
>>
>> It does seem quite reasonable to me that an audio only app would not be as
>> critical. And, of course, the video and audio frame rates don't really
>> match anyway, or we'd be getting 882 or 960 sample blocks instead of 128
>> or
>> 512.
>>
>> I got a GearVR recently and it does work better than Google Cardboard.
>> Much
>> of this is just comfort, I think, but I understand that it has its own
>> gyros, mostly because they are faster. 'Heresay' is that the Oculus Rift
>> samples at least 1000Hz. I have actually written an audio rate rotate that
>> could handle this, but it does seem like overkill. At normal head turning
>> rates, I find interpolating the rotation within each block to be enough.
>>
>> Any modern gyro and processor will run fast enough. My little 8-bit
>> controllers run their complete flight control loop in under 2ms. The limit
>> on update rate, and latency for that matter, will be the wireless link.
>> Wifi will be fastest but highest power. Bluetooth lower power but lower
>> bandwidth and still wireless. Wired would not only be very fast but could
>> provide power.
>>
>> If you are thinking wireless headphones, remember the latency that that
>> introduces. I find my everyday bluetooth headset, built for music, is
>> useless for VR because of latency. And if you headphones are going to be
>> wired, then running that extra USB might not be too bad.
>>
>> David McGriffy
>>
>>
>> On Mon, Feb 1, 2016 at 12:49 PM, Bo-Erik Sandholm 
>> wrote:
>>
>> > Apperently there exists a head tracking specialized version of the
>> bno055
>> > called bno070 - but I cannot find a place to buy this.
>> > you can get up to 250 samples / second from that version.
>> >
>> > Matthias did not complain about the update rate with the DIY headtracker
>> > http://www.rcgroups.com/forums/showthread.php?t=1677559
>> >
>> >
>> >
>> http://electronicspurchasingstrategies.com/2014/03/06/hillcrest-bosch-sensortec-collaborate-sensor-hub-solution/
>> >
>> > http://docsfiles.com/pdf_bno070.html
>> >
>> >
>> >
>> http://ae-bst.resource.bosch.com/media/_tech/media/product_flyer/Mobile-Hillcrest-Labs-Sensor-Hub-Product-Brief-BNO0701.pdf
>> >
>> >
>> >
>> https://www.eiseverywhere.com/file_uploads/5c881a2f6eaaa90ed3f3d30fb20852db_Newsflash_BNO077.pdf
>> >
>> >
>> > maybe it is better to not think about that and try and use what I have ?
>> >
>> > It is easy to find videos about using the bno055 in different projects
>> but
>> > i do not want videos... have not found links to the software used...
>> >
>> >
>> >
>> > Better luck when google github bno055 :-)
>> >
>> >
>> >
>> https://www.reddit.com/r/virtualreality/comments/3faq11/why_we_need_to_move_to_ambisonic_sound_in_the/
>> >
>> > http://vriscoming.com/daydream-vr/
>> >
>> > Bo-Erik
>> >
>> > 2016-02-01 18:56 GMT+01:00 Marc Lavallee :
>> >
>> > > On Mon, 01 Feb 2016 17:46:47 +
>> > > Stefan Schreiber  wrote:
>> > > > What is a 10 DOF motion sensor??? (Didn't you mean 9DOF?)
>> > >
>> > > It's 9DOF + barometric pressure, so 9DOF is enough. For more info:
>> > >
>> >
>> http://playground.arduino.cc/Main/WhatIsDegreesOfFreedom6DOF9DOF10DOF11DOF
>> > >
>> > > --
>> > > Marc
>> > > ___
>> > > 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.
>> > >
>> > -- next part --
>> > An HTML attachment was scrubbed...
>> > URL: <
>> >
>> https://mail.music.vt.edu/mailman/private/sursound/attachments/20160201/252ce84f/attachment.html
>> > >
>> > ___
>> > 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.
>> >
>> -- next part -

Re: [Sursound] Never do electronic in public.

[Bo-Erik Sandholm]

Standard aliexpress Bluetooth module v2.0+edr have a data rate of 2.1 Mbit/s
It is not so bad if you can get the sensors UART to push data near that
speed.

- Bo-Erik
On 1 Feb 2016 20:33, "David McGriffy"  wrote:

> Right, 10DOF is with altitude. I'm building a drone controller out of piece
> parts as a demonstration.
>
> Yes, there are certainly ways to achieve low latency convolution, but all
> at the expense of CPU, which is already at a premium when running on
> phones.
>
> I first heard the 20ms figure from some folks working in the VR biz.
> Admittedly, they are more camera and content producers and not headset
> makers, so perhaps this is just a dream goal of theirs. It does make some
> sense to me as that's 50Hz, or the same as some TV refresh rates. Being one
> frame off there can certainly be noticeable, especially with speech vs
> moving lips.
>
> It does seem quite reasonable to me that an audio only app would not be as
> critical. And, of course, the video and audio frame rates don't really
> match anyway, or we'd be getting 882 or 960 sample blocks instead of 128 or
> 512.
>
> I got a GearVR recently and it does work better than Google Cardboard. Much
> of this is just comfort, I think, but I understand that it has its own
> gyros, mostly because they are faster. 'Heresay' is that the Oculus Rift
> samples at least 1000Hz. I have actually written an audio rate rotate that
> could handle this, but it does seem like overkill. At normal head turning
> rates, I find interpolating the rotation within each block to be enough.
>
> Any modern gyro and processor will run fast enough. My little 8-bit
> controllers run their complete flight control loop in under 2ms. The limit
> on update rate, and latency for that matter, will be the wireless link.
> Wifi will be fastest but highest power. Bluetooth lower power but lower
> bandwidth and still wireless. Wired would not only be very fast but could
> provide power.
>
> If you are thinking wireless headphones, remember the latency that that
> introduces. I find my everyday bluetooth headset, built for music, is
> useless for VR because of latency. And if you headphones are going to be
> wired, then running that extra USB might not be too bad.
>
> David McGriffy
>
>
> On Mon, Feb 1, 2016 at 12:49 PM, Bo-Erik Sandholm 
> wrote:
>
> > Apperently there exists a head tracking specialized version of the bno055
> > called bno070 - but I cannot find a place to buy this.
> > you can get up to 250 samples / second from that version.
> >
> > Matthias did not complain about the update rate with the DIY headtracker
> > http://www.rcgroups.com/forums/showthread.php?t=1677559
> >
> >
> >
> http://electronicspurchasingstrategies.com/2014/03/06/hillcrest-bosch-sensortec-collaborate-sensor-hub-solution/
> >
> > http://docsfiles.com/pdf_bno070.html
> >
> >
> >
> http://ae-bst.resource.bosch.com/media/_tech/media/product_flyer/Mobile-Hillcrest-Labs-Sensor-Hub-Product-Brief-BNO0701.pdf
> >
> >
> >
> https://www.eiseverywhere.com/file_uploads/5c881a2f6eaaa90ed3f3d30fb20852db_Newsflash_BNO077.pdf
> >
> >
> > maybe it is better to not think about that and try and use what I have ?
> >
> > It is easy to find videos about using the bno055 in different projects
> but
> > i do not want videos... have not found links to the software used...
> >
> >
> >
> > Better luck when google github bno055 :-)
> >
> >
> >
> https://www.reddit.com/r/virtualreality/comments/3faq11/why_we_need_to_move_to_ambisonic_sound_in_the/
> >
> > http://vriscoming.com/daydream-vr/
> >
> > Bo-Erik
> >
> > 2016-02-01 18:56 GMT+01:00 Marc Lavallee :
> >
> > > On Mon, 01 Feb 2016 17:46:47 +
> > > Stefan Schreiber  wrote:
> > > > What is a 10 DOF motion sensor??? (Didn't you mean 9DOF?)
> > >
> > > It's 9DOF + barometric pressure, so 9DOF is enough. For more info:
> > >
> >
> http://playground.arduino.cc/Main/WhatIsDegreesOfFreedom6DOF9DOF10DOF11DOF
> > >
> > > --
> > > Marc
> > > ___
> > > 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.
> > >
> > -- next part --
> > An HTML attachment was scrubbed...
> > URL: <
> >
> https://mail.music.vt.edu/mailman/private/sursound/attachments/20160201/252ce84f/attachment.html
> > >
> > ___
> > 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.
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://mail.music.vt.edu/mailman/private/sursound/attachments/20160201/b49200e1/attachment.html
> >
> ___
> Sursound mailing list
> Sursound@music.vt.edu
> https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here,
>

Re: [Sursound] Never do electronic in public.

[David McGriffy]

Right, 10DOF is with altitude. I'm building a drone controller out of piece
parts as a demonstration.

Yes, there are certainly ways to achieve low latency convolution, but all
at the expense of CPU, which is already at a premium when running on phones.

I first heard the 20ms figure from some folks working in the VR biz.
Admittedly, they are more camera and content producers and not headset
makers, so perhaps this is just a dream goal of theirs. It does make some
sense to me as that's 50Hz, or the same as some TV refresh rates. Being one
frame off there can certainly be noticeable, especially with speech vs
moving lips.

It does seem quite reasonable to me that an audio only app would not be as
critical. And, of course, the video and audio frame rates don't really
match anyway, or we'd be getting 882 or 960 sample blocks instead of 128 or
512.

I got a GearVR recently and it does work better than Google Cardboard. Much
of this is just comfort, I think, but I understand that it has its own
gyros, mostly because they are faster. 'Heresay' is that the Oculus Rift
samples at least 1000Hz. I have actually written an audio rate rotate that
could handle this, but it does seem like overkill. At normal head turning
rates, I find interpolating the rotation within each block to be enough.

Any modern gyro and processor will run fast enough. My little 8-bit
controllers run their complete flight control loop in under 2ms. The limit
on update rate, and latency for that matter, will be the wireless link.
Wifi will be fastest but highest power. Bluetooth lower power but lower
bandwidth and still wireless. Wired would not only be very fast but could
provide power.

If you are thinking wireless headphones, remember the latency that that
introduces. I find my everyday bluetooth headset, built for music, is
useless for VR because of latency. And if you headphones are going to be
wired, then running that extra USB might not be too bad.

David McGriffy


On Mon, Feb 1, 2016 at 12:49 PM, Bo-Erik Sandholm 
wrote:

> Apperently there exists a head tracking specialized version of the bno055
> called bno070 - but I cannot find a place to buy this.
> you can get up to 250 samples / second from that version.
>
> Matthias did not complain about the update rate with the DIY headtracker
> http://www.rcgroups.com/forums/showthread.php?t=1677559
>
>
> http://electronicspurchasingstrategies.com/2014/03/06/hillcrest-bosch-sensortec-collaborate-sensor-hub-solution/
>
> http://docsfiles.com/pdf_bno070.html
>
>
> http://ae-bst.resource.bosch.com/media/_tech/media/product_flyer/Mobile-Hillcrest-Labs-Sensor-Hub-Product-Brief-BNO0701.pdf
>
>
> https://www.eiseverywhere.com/file_uploads/5c881a2f6eaaa90ed3f3d30fb20852db_Newsflash_BNO077.pdf
>
>
> maybe it is better to not think about that and try and use what I have ?
>
> It is easy to find videos about using the bno055 in different projects but
> i do not want videos... have not found links to the software used...
>
>
>
> Better luck when google github bno055 :-)
>
>
> https://www.reddit.com/r/virtualreality/comments/3faq11/why_we_need_to_move_to_ambisonic_sound_in_the/
>
> http://vriscoming.com/daydream-vr/
>
> Bo-Erik
>
> 2016-02-01 18:56 GMT+01:00 Marc Lavallee :
>
> > On Mon, 01 Feb 2016 17:46:47 +
> > Stefan Schreiber  wrote:
> > > What is a 10 DOF motion sensor??? (Didn't you mean 9DOF?)
> >
> > It's 9DOF + barometric pressure, so 9DOF is enough. For more info:
> >
> http://playground.arduino.cc/Main/WhatIsDegreesOfFreedom6DOF9DOF10DOF11DOF
> >
> > --
> > Marc
> > ___
> > 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.
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://mail.music.vt.edu/mailman/private/sursound/attachments/20160201/252ce84f/attachment.html
> >
> ___
> 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.
>
-- next part --
An HTML attachment was scrubbed...
URL: 

___
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.

Re: [Sursound] Never do electronic in public.

[Bo-Erik Sandholm]

Apperently there exists a head tracking specialized version of the bno055
called bno070 - but I cannot find a place to buy this.
you can get up to 250 samples / second from that version.

Matthias did not complain about the update rate with the DIY headtracker
http://www.rcgroups.com/forums/showthread.php?t=1677559

http://electronicspurchasingstrategies.com/2014/03/06/hillcrest-bosch-sensortec-collaborate-sensor-hub-solution/

http://docsfiles.com/pdf_bno070.html

http://ae-bst.resource.bosch.com/media/_tech/media/product_flyer/Mobile-Hillcrest-Labs-Sensor-Hub-Product-Brief-BNO0701.pdf

https://www.eiseverywhere.com/file_uploads/5c881a2f6eaaa90ed3f3d30fb20852db_Newsflash_BNO077.pdf


maybe it is better to not think about that and try and use what I have ?

It is easy to find videos about using the bno055 in different projects but
i do not want videos... have not found links to the software used...



Better luck when google github bno055 :-)

https://www.reddit.com/r/virtualreality/comments/3faq11/why_we_need_to_move_to_ambisonic_sound_in_the/

http://vriscoming.com/daydream-vr/

Bo-Erik

2016-02-01 18:56 GMT+01:00 Marc Lavallee :

> On Mon, 01 Feb 2016 17:46:47 +
> Stefan Schreiber  wrote:
> > What is a 10 DOF motion sensor??? (Didn't you mean 9DOF?)
>
> It's 9DOF + barometric pressure, so 9DOF is enough. For more info:
> http://playground.arduino.cc/Main/WhatIsDegreesOfFreedom6DOF9DOF10DOF11DOF
>
> --
> Marc
> ___
> 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.
>
-- next part --
An HTML attachment was scrubbed...
URL: 

___
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.

Re: [Sursound] Never do electronic in public.

[Stefan Schreiber]

Marc Lavallee wrote:


On Mon, 01 Feb 2016 17:46:47 +
Stefan Schreiber  wrote:
 


What is a 10 DOF motion sensor??? (Didn't you mean 9DOF?)
   



It's 9DOF + barometric pressure, so 9DOF is enough. For more info:
http://playground.arduino.cc/Main/WhatIsDegreesOfFreedom6DOF9DOF10DOF11DOF

--
Marc

 


Thanks!

If the pressure is below 900 hectopascal and you are about at sea-level, 
the weather is probably quite bad...


Best,

Stefan

___
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.

Re: [Sursound] Never do electronic in public.

[Stefan Schreiber]

David McGriffy wrote:


Oh how I wish I had time to play with this stuff. At this moment on my
breadboard I have a Teensy 3.2, a 6DOF gyro module, etc. Bluetooth modules
should be in today. 10DOF modules on order. I think the magnetometer is
important for HT to prevent drift. The altitude, perhaps not so much. Of
course, this is for a drone project (I'm writing a book about building
drones). And I have audio projects backed up ...

For audio and head tracking, I have been playing in Unity to Google
Cardboard and now GearVR. I have some demo code for anyone interested in
Unity development.

The standard I hear in the VR world is 20ms "motion to photons". Minimum
frame rate of 60Hz, preferably 90-120Hz. These faster rates do not allow
convolution with the full block size of the listen database, though careful
truncation should be OK.

David McGriffy
VVAudio

 


https://depositonce.tu-berlin.de/bitstream/11303/1318/1/Dokument_28.pdf

(System latency)

Chapter 4.1.3

Figure 4.4 displays the results together with the mean value of all 17 
persons and a
95 %-confidence interval depending on the total latency time. An 
average value of 0.5
was assumed as the threshold that needs to be passed to allow a 
perception. Hence
if the 95 %-confidence interval of the mean value exceeded this limit, 
the respective

total latency time was counted to be perceptible.
Each (total) latency time falling short of 85 ms was ignored by the 
subjects. The
transition between “not perceptible” and “perceptible” occurred in a 
range between
85 ms and 101 ms. For latency times exceeding 101 ms localization 
artifacts were

perceived.



5.2.1

Sandvad and Wenzel [110, 136, 137] have previously investigated the 
influence of
the system’s total latency time on localization. They concluded that 
for producing
real time auralization the auralization system has to meet the 
following requirements:
The total latency time has to be below 91 ms, the update rate has to 
be at least 60 Hz

and a minimal spatial resolution of about 2± is required.



The experiment at IRT which focused on latency (described in section 
4.1.3) produced
similar the results, i. e., a maximal latency time of 81 ms using an 
update rate


of 120 Hz and a spatial resolution of 5± (due to the step-motor). The 
head tracker
system itself had a latency time of theadtracker = 8.3 ms and an 
angular resolution of

0.1±.
Since the electronic auralization system (BRS Processor) itself has a 
shorter latency
time (tBRS < 6 ms), the system’s total latency time is in the order of 
magnitude
of about ttotal = theadtracker + tBRS ' 15 ms. Thus does not exceed 
the upper limit

of 85 ms and fulfils the requirements previously mentioned.



The link to this dissertation originally came from Aaron Heller (I 
was combing some "old" mails... :-) )




The standard I hear in the VR world is 20ms "motion to photons".


I somewhat would like to express my doubts!

You must be aware that update rate and latency are s.th. quite different.

20ms (max.) latency looks (suspiciously) close to 1s/(min. update rate).

I would have thought the same. However, max latency should be < 
significantly greater > than (1/min. update rate) s.


(?)



The standard I hear in the VR world is 20ms "motion to photons".



Sources?! No "hearsay" accepted, at least not at this point!

Best,

Stefan

P.S.: It was all about "Never do MATH in public"... ;-)



___
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.

Re: [Sursound] Never do electronic in public.

[Marc Lavallee]

On Mon, 01 Feb 2016 17:46:47 +
Stefan Schreiber  wrote:
> What is a 10 DOF motion sensor??? (Didn't you mean 9DOF?)

It's 9DOF + barometric pressure, so 9DOF is enough. For more info:
http://playground.arduino.cc/Main/WhatIsDegreesOfFreedom6DOF9DOF10DOF11DOF

--
Marc
___
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.

Re: [Sursound] Never do electronic in public.

[Stefan Schreiber]

David McGriffy wrote:


Oh how I wish I had time to play with this stuff. At this moment on my
breadboard I have a Teensy 3.2, a 6DOF gyro module, etc. Bluetooth modules
should be in today. 10DOF modules on order. I think the magnetometer is
important for HT to prevent drift. The altitude, perhaps not so much. Of
course, this is for a drone project (I'm writing a book about building
drones). And I have audio projects backed up ...

For audio and head tracking, I have been playing in Unity to Google
Cardboard and now GearVR. I have some demo code for anyone interested in
Unity development.

The standard I hear in the VR world is 20ms "motion to photons". Minimum
frame rate of 60Hz, preferably 90-120Hz. 



I believe "motion to sound pressure" :-)   latency requirements are more 
relaxed.


Because this is an important issue, I would like to receive some more 
feedback here.


I agree about update rates. (60Hz, or 80-120 Hz.)


What is a 10 DOF motion sensor??? (Didn't you mean 9DOF?)

Best,

Stefan







These faster rates do not allow
convolution with the full block size of the listen database, though careful
truncation should be OK.

David McGriffy
VVAudio

On Mon, Feb 1, 2016 at 5:52 AM, Michael Chapman  wrote:

 


I just looked back at sursound mails and michael chapman had pointed out
that the teensy has four channel audio support. >
http://www.pjrc.com/teensy/td_libs_Audio.html

umashankar


 


Must refuse the credit.
I just participated in that thread.

Michael

___
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.

   


-- next part --
An HTML attachment was scrubbed...
URL: 

___
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.

 



___
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.

Re: [Sursound] Never do electronic in public.

[Jörn Nettingsmeier]

On 02/01/2016 04:25 PM, David McGriffy wrote:


The standard I hear in the VR world is 20ms "motion to photons". Minimum
frame rate of 60Hz, preferably 90-120Hz. These faster rates do not allow
convolution with the full block size of the listen database, though careful
truncation should be OK.


? the latency of a convolver has nothing to do with the length of the 
kernel, only with its own blocksize. with a standard pc, it should be 
easily possible to get under 3 ms latency, even less if you're prepared 
to upsample your hrtfs and content to 96k (and burn twice as much cpu, 
and waste storage). in any case, you can make use of the full length of 
the hrtfs.


--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net

___
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.

Re: [Sursound] Never do electronic in public.

[David McGriffy]

Oh how I wish I had time to play with this stuff. At this moment on my
breadboard I have a Teensy 3.2, a 6DOF gyro module, etc. Bluetooth modules
should be in today. 10DOF modules on order. I think the magnetometer is
important for HT to prevent drift. The altitude, perhaps not so much. Of
course, this is for a drone project (I'm writing a book about building
drones). And I have audio projects backed up ...

For audio and head tracking, I have been playing in Unity to Google
Cardboard and now GearVR. I have some demo code for anyone interested in
Unity development.

The standard I hear in the VR world is 20ms "motion to photons". Minimum
frame rate of 60Hz, preferably 90-120Hz. These faster rates do not allow
convolution with the full block size of the listen database, though careful
truncation should be OK.

David McGriffy
VVAudio

On Mon, Feb 1, 2016 at 5:52 AM, Michael Chapman  wrote:

> > I just looked back at sursound mails and michael chapman had pointed out
> > that the teensy has four channel audio support. >
> > http://www.pjrc.com/teensy/td_libs_Audio.html
> >
> > umashankar
> >
> >
> Must refuse the credit.
> I just participated in that thread.
>
> Michael
>
> ___
> 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.
>
-- next part --
An HTML attachment was scrubbed...
URL: 

___
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.

Re: [Sursound] Never do electronic in public.

[Michael Chapman]

> I just looked back at sursound mails and michael chapman had pointed out
> that the teensy has four channel audio support. >
> http://www.pjrc.com/teensy/td_libs_Audio.html
>
> umashankar
>
>
Must refuse the credit.
I just participated in that thread.

Michael

___
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.

Re: [Sursound] Never do electronic in public.

[umashankar manthravadi]

I just looked back at sursound mails and michael chapman had pointed out that 
the teensy has four channel audio support. > 
http://www.pjrc.com/teensy/td_libs_Audio.html

umashankar

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Bo-Erik Sandholm<mailto:bosses...@gmail.com>
Sent: Monday, February 1, 2016 1:12 PM
To: sursound<mailto:sursound@music.vt.edu>
Cc: umashankar mantravadi<mailto:umasha...@hotmail.com>; Stefan 
Schreiber<mailto:st...@mail.telepac.pt>; Marc Lavallée<mailto:m...@hacklava.net>
Subject: Re: [Sursound] Never do electronic in public.

I am not really very structured and gets distracted easily, in this
experiment the final hardware setup is not decided, currently my software
structure thinking is like this.

OSC for the protocol as most available Ambisonics sw is VST's for PC or Mac
and Reaper accepts OSC for controls. If done right OSC does not have a
latency problem. Just remember the speed of data output from the sensor
needs to be set high :-)

Reaper is because I am currently thinking of the binaural conversion
experiments with Ambisonics, there do exist 4 channel vst player software's
more like normal apps when the playback chain is configured for end users.

Or would it be better to use oculus rift syntax for the position messages
to be compatible with VR apps?
Or maybe make it changeable by just loading different software?
With my current WiFi plan maybe the wifi chip should accept oculus syntax
and convert and send OSC to be flexible?

Actually the pico-platinche with the bno055 is nice because it is smaller
than the diy head tracker  and have more free CPU and memory for the
protocol implementation as the sensor with its built in cpu does drift
elimination and calibration.
As far as I know the bno055 is the only sensor with built in calibration
and drift compensation available to hobbyists.

If the communication is serial over USB, tcp-ip over USB or using WiFi or
Bluetooth does not matter so much at this stage.

Bluetooth might be best for platform flexibility, works with phones, PC and
Mac and workable with Linux. But the same is valid for WiFi., and currently
the Chinese Bluetooth module is larger than the WiFi but needs less power.

And I think I have burnt my BT module with 5v and is waiting for a new
one...

Best Regards
Bo-Erik
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20160201/6ff7cf2a/attachment.html>
___
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.

Re: [Sursound] Never do electronic in public.

[Bo-Erik Sandholm]

I am not really very structured and gets distracted easily, in this
experiment the final hardware setup is not decided, currently my software
structure thinking is like this.

OSC for the protocol as most available Ambisonics sw is VST's for PC or Mac
and Reaper accepts OSC for controls. If done right OSC does not have a
latency problem. Just remember the speed of data output from the sensor
needs to be set high :-)

Reaper is because I am currently thinking of the binaural conversion
experiments with Ambisonics, there do exist 4 channel vst player software's
more like normal apps when the playback chain is configured for end users.

Or would it be better to use oculus rift syntax for the position messages
to be compatible with VR apps?
Or maybe make it changeable by just loading different software?
With my current WiFi plan maybe the wifi chip should accept oculus syntax
and convert and send OSC to be flexible?

Actually the pico-platinche with the bno055 is nice because it is smaller
than the diy head tracker  and have more free CPU and memory for the
protocol implementation as the sensor with its built in cpu does drift
elimination and calibration.
As far as I know the bno055 is the only sensor with built in calibration
and drift compensation available to hobbyists.

If the communication is serial over USB, tcp-ip over USB or using WiFi or
Bluetooth does not matter so much at this stage.

Bluetooth might be best for platform flexibility, works with phones, PC and
Mac and workable with Linux. But the same is valid for WiFi., and currently
the Chinese Bluetooth module is larger than the WiFi but needs less power.

And I think I have burnt my BT module with 5v and is waiting for a new
one...

Best Regards
Bo-Erik
-- next part --
An HTML attachment was scrubbed...
URL: 

___
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.

Re: [Sursound] Never do electronic in public.

[umashankar manthravadi]

Dear marc

There seem to be dozens of nine axis (three each of gyro, magnetic and 
accelerometer with two data and two power pins connecting to usb Arduino – here 
are some  links
https://www.adafruit.com/products/1714
https://www.pjrc.com/store/teensy.html
http://www.ebay.com/itm/ws/eBayISAPI.dll?ViewItem&item=270962872404&ssPageName=ADME:L:OC:US:3160&rmvSB=true
http://planetkris.com/2014/12/easier-better-arduino-imu-head-tracker/

most of the action is happening in gamer groups and drone control – all the way 
to ready to use ide and guis.

umashankar

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Marc Lavallée<mailto:m...@hacklava.net>
Sent: Monday, February 1, 2016 10:20 AM
To: umashankar manthravadi<mailto:umasha...@hotmail.com>
Cc: Surround Sound discussion group<mailto:sursound@music.vt.edu>
Subject: Re: [Sursound] Never do electronic in public.

On Mon, 1 Feb 2016 07:53:46 +0530,
umashankar manthravadi  wrote :

> VVaudio working in audio mulch will accept midi to control parameters
> like azimuth and elevation. There are plenty of two board (but tiny
> boards) that will  provide usb output from a 9degrees of freedom
> chip. We just need to convert X and Y to midistreams.

I'd be curious to see a list of appropriate sensors and boards. Fons is
already working on a similar project; we'll learn more when it's ready.

> Would like to see it integrated audio on USB but we need not start
> there.

It would keep the device small, cheaper, and compatible with many
systems that already have a headphone output. But there's probably
small and cheap usb headphone amplifier modules that could be
integrated.

> I am sure it can be used with ambisonics.xyz too, but is that site
> dead ?

It's http://ambisonic.xyz/ (without a s).
It still works (but only for Chrome based browsers)

--
Marc

> umashankar
>
> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
> From: Marc Lavallée<mailto:m...@hacklava.net>
> Sent: Monday, February 1, 2016 7:37 AM
> To: Surround Sound discussion group<mailto:sursound@music.vt.edu>
> Subject: Re: [Sursound] Never do electronic in public.
>
> On Mon, 01 Feb 2016 01:17:42 +,
> Stefan Schreiber  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.
>
> > 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. Simply,
> a head tracking gizmo could be able to work with any software that
> requires it, so the more open the better. The protocol is probably
> more important than the hardware, which could vary.
>
> > * 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
>
> ___
> 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.

-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20160201/093f39a3/attachment.html>
___
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.

Re: [Sursound] Never do electronic in public.

[Marc Lavallée]

On Mon, 1 Feb 2016 07:53:46 +0530,
umashankar manthravadi  wrote :

> VVaudio working in audio mulch will accept midi to control parameters
> like azimuth and elevation. There are plenty of two board (but tiny
> boards) that will  provide usb output from a 9degrees of freedom
> chip. We just need to convert X and Y to midistreams. 

I'd be curious to see a list of appropriate sensors and boards. Fons is
already working on a similar project; we'll learn more when it's ready.

> Would like to see it integrated audio on USB but we need not start
> there.

It would keep the device small, cheaper, and compatible with many
systems that already have a headphone output. But there's probably
small and cheap usb headphone amplifier modules that could be
integrated.

> I am sure it can be used with ambisonics.xyz too, but is that site
> dead ?

It's http://ambisonic.xyz/ (without a s). 
It still works (but only for Chrome based browsers)

--
Marc
 
> umashankar
> 
> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
> 
> From: Marc Lavallée<mailto:m...@hacklava.net>
> Sent: Monday, February 1, 2016 7:37 AM
> To: Surround Sound discussion group<mailto:sursound@music.vt.edu>
> Subject: Re: [Sursound] Never do electronic in public.
> 
> On Mon, 01 Feb 2016 01:17:42 +,
> Stefan Schreiber  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.
> 
> > 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. Simply,
> a head tracking gizmo could be able to work with any software that
> requires it, so the more open the better. The protocol is probably
> more important than the hardware, which could vary.
> 
> > * 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
> 
> ___
> 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.

___
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.

Re: [Sursound] Never do electronic in public.

[Stefan Schreiber]

umashankar manthravadi wrote:


VVaudio working in audio mulch will accept midi to control parameters like 
azimuth and elevation. There are plenty of two board (but tiny boards) that 
will  provide usb output from a 9degrees of freedom chip. We just need to 
convert X and Y to midistreams. Would like to see it integrated audio on USB 
but we need not start there. I am sure it can be used with ambisonics.xyz too, 
but is that site dead ?

umashankar
 


OSC is MIDI's successor protocol...

Best,

Stefan


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Marc Lavallée<mailto:m...@hacklava.net>
Sent: Monday, February 1, 2016 7:37 AM
To: Surround Sound discussion group<mailto:sursound@music.vt.edu>
Subject: Re: [Sursound] Never do electronic in public.

On Mon, 01 Feb 2016 01:17:42 +,
Stefan Schreiber  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.

 


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. Simply,
a head tracking gizmo could be able to work with any software that
requires it, so the more open the better. The protocol is probably more
important than the hardware, which could vary.

 


* 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

___
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.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20160201/cb6c1be6/attachment.html>
___
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.
 



___
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.

Re: [Sursound] Never do electronic in public.

[Stefan Schreiber]

Marc Lavallée wrote:


On Mon, 01 Feb 2016 01:17:42 +,
Stefan Schreiber  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.

Re: [Sursound] Never do electronic in public.

[umashankar manthravadi]

VVaudio working in audio mulch will accept midi to control parameters like 
azimuth and elevation. There are plenty of two board (but tiny boards) that 
will  provide usb output from a 9degrees of freedom chip. We just need to 
convert X and Y to midistreams. Would like to see it integrated audio on USB 
but we need not start there. I am sure it can be used with ambisonics.xyz too, 
but is that site dead ?

umashankar

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Marc Lavallée<mailto:m...@hacklava.net>
Sent: Monday, February 1, 2016 7:37 AM
To: Surround Sound discussion group<mailto:sursound@music.vt.edu>
Subject: Re: [Sursound] Never do electronic in public.

On Mon, 01 Feb 2016 01:17:42 +,
Stefan Schreiber  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.

> 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. Simply,
a head tracking gizmo could be able to work with any software that
requires it, so the more open the better. The protocol is probably more
important than the hardware, which could vary.

> * 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

___
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.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://mail.music.vt.edu/mailman/private/sursound/attachments/20160201/cb6c1be6/attachment.html>
___
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.

Re: [Sursound] Never do electronic in public.

[Marc Lavallée]

On Mon, 01 Feb 2016 01:17:42 +,
Stefan Schreiber  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.

> 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. Simply,
a head tracking gizmo could be able to work with any software that
requires it, so the more open the better. The protocol is probably more
important than the hardware, which could vary.

> * 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

___
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.

Re: [Sursound] Never do electronic in public.

[Stefan Schreiber]

Marc Lavallée wrote:


The BNO055 is a wonder.
 

Fully agreed. This sensor looks and feels like a quality solution. 100Hz 
updates are sufficient for our needs.



Here's a complete integration with bluetooth:
https://www.youtube.com/watch?v=84MOS78-Hso
Too bad the schematics are not provided.

The sensor looks easy to use, but it needs calibration:
https://www.youtube.com/watch?v=Nz4EozK4cPY

If made small enough, 


< small >  is a key requirement. (i.e. < miniaturisation >)

Best,

Stefan


a complete device could be useful not only for
head tracking, but also to track the orientation of an ambisonic
microphone (or a panoramic/360 camera).

--
Marc

On Sun, 31 Jan 2016 20:16:24 +0100,
Bo-Erik Sandholm  wrote :

 


I copied the wrong link, touch interface is not always good :-)

I was involved in getting Matthias to support the diy head tracker
with the gy-85 an a aurdino nano with USB connectivity, in the
current setup we need a initial calibration and a pd plugin to
convert to OSC to talk to Reaper daw.

Now I saw this module, neat and small no calibration needed.
https://www.tindie.com/products/FabLab/pico-platinchen/

https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview

http://github.com/arduino-org/Arduino/tree/ide-org-1.6.1.x/libraries/NAxesMotion

Maybe it overkill and have one processor too much in the chain...
Currently the plan is convert to OSC high speed serial in the
pico-platinchen.

I will add a esp-01 esp8266 to connect the serial port and send the
OSC data with UDP WiFi to the PC running Reaper. The WiFi setup will
be done in esp-01 code.

Probably a esp8266 and the BNO055 directly connected could manage it
without the ATmega328P on the pico platinchen.
But currently the cost of for example
http://www.ebay.com/itm/Adafruit-9-DOF-Absolute-Orientation-IMU-Fusion-Breakout-BNO055-PID-2472-/171821750983?hash=item28015fdac7:g:-wYAAOSwBLlVTrbI
is not cheaper than the pico...

A naked bno055 is 13 usd on ali express but needs a circuit board and
be built to combine with the esp-01.

So 2 small modules and a battery is the system, and be mounted on the
headband of a headset.

I am definitely open for all possible forms of cooperation.
Bo-Erik
On 31 Jan 2016 16:58, "Marc Lavallée"  wrote:

   


Warning: the discussion is drifting to DIY electronic gadgetry. :)

On Sun, 31 Jan 2016 11:16:26 +0100,
Bo-Erik Sandholm  wrote :

 


I have decided to simplify  the DIY head tracking dongle build and
setup in some aspects, now I have ordered this sensor that do not
need initial calibration.
This is the new sensor module:
https://learn.adafruit.com/adafruit-neopixel-uberguide/overview
   


The page is about addressable LED modules. Is it an error?

I would use a GY-85 board and a micro-controller, as seen here:
http://www.rcgroups.com/forums/showthread.php?t=1677559
This is a good starting point.

 


It will initially be combined with a esp8266 module for WiFi
connectivity or maybe Bluetooth
http://www.esp8266.com/wiki/doku.php?id=getting-started-with-the-esp8266

   


http://www.aliexpress.com/item/Promotion-Brand-NEW-HC-05-Wireless-Bluetooth-RF-Transceiver-Module-serial-RS232-TTL/32367579918.html

Could there be some added latency when using wifi or bluetooth? A
direct usb connection should be faster, but avoiding a cable would
be desirable because many android devices cannot easily use their
usb port for communication. If using wifi, I would try multicast
udp.

Here's a page that explains how to use the bluetooth module:

http://www.instructables.com/id/Cheap-2-Way-Bluetooth-Connection-Between-Arduino-a/

 


Power will probably be from one of these, giving around 10 hours
of operations:

   


http://www.aliexpress.com/item/4PCS-Hot-Sale-Soshine-900mAh-14500-battery-3-2V-LiFePO4-AA-Rechargeable-Battery/32242320597.html

Nice!

 


I will send OSC (open sound control
https://en.m.wikipedia.org/wiki/Open_Sound_Control) directly from
the sensor.
   


OSC is a good protocol, but an application specific protocol could
be designed to be more compact, reducing the latency.

 


This should simplify the build of the head tracked sensor,
reducing the soldering need.
   


There would be 4 modules involved: a sensing assembly, a
micro-controller, a wifi transmission module, and a power supply.
Going usb-wired would remove the wifi transmitter and the supply.

A custom firmware can be programmed for the ESP-8266, which have
GPIOs, so maybe it could be used as a micro-controller:

http://hackaday.com/2015/03/18/how-to-directly-program-an-inexpensive-esp8266-wifi-module/

If a micro-controller is required, the trinket is an alternative to
the arduino nano: https://learn.adafruit.com/introducing-trinket/
It's much smaller, works at 3.2V. For a 5V USB wired version, it can
provide 3.2 volts for other boards.

 


This should simplify the setup of playback using
http://www.matthiaskronlachner.com/?p=2015
And maybe later ambiexplorer can be

Re: [Sursound] Never do electronic in public.

[Stefan Schreiber]

Bo-Erik Sandholm wrote:


I copied the wrong link, touch interface is not always good :-)

I was involved in getting Matthias to support the diy head tracker with the
gy-85 an a aurdino nano with USB connectivity, in the current setup we need
a initial calibration and a pd plugin to convert to OSC to talk to Reaper
daw.
 


Reaper runs on a PC, but not on Android/iOS.

Most certainly you/we would need "just" a playback program/app for 
certain (surround) "immersive audio formats"? 

Reaper is interesting for academic use, but still... Which person 
listens to her/his music via a DAW?!



Now I saw this module, neat and small no calibration needed.
https://www.tindie.com/products/FabLab/pico-platinchen/

https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview

http://github.com/arduino-org/Arduino/tree/ide-org-1.6.1.x/libraries/NAxesMotion

Maybe it overkill and have one processor too much in the chain...
Currently the plan is convert to OSC high speed serial in the
pico-platinchen.
 



At a certain point you have to define what exactly you aim for...

1. Bluetooth vs. WiFi

I would opt for BT

2. Latency issues

IMO you should update positions with at least 60Hz, global latency 
should be <=80ms. (Integration of different but similar experimental 
results/studies)


3. OSC

I still believe this is useable... If Marc or anybody is able to design 
*FSSC protocol, you are very welcome :-)




I will add a esp-01 esp8266 to connect the serial port and send the OSC
data with UDP WiFi to the PC running Reaper. The WiFi setup will be done in
esp-01 code.
 

But "nobody" has yet decided to use WiFi, UDP protocol and to play FOA 
files via a PC and Reaper...   ??!!


Of course you could...


Probably a esp8266 and the BNO055 directly connected could manage it
without the ATmega328P on the pico platinchen.
But currently the cost of for example
http://www.ebay.com/itm/Adafruit-9-DOF-Absolute-Orientation-IMU-Fusion-Breakout-BNO055-PID-2472-/171821750983?hash=item28015fdac7:g:-wYAAOSwBLlVTrbI
is not cheaper than the pico...

A naked bno055 is 13 usd on ali express but needs a circuit board and be
built to combine with the esp-01.

So 2 small modules and a battery is the system, and be mounted on the
headband of a headset.

I am definitely open for all possible forms of cooperation.
Bo-Erik
 



Again: You need a defined plan what your device is supposed to do, to 
connect to which devices (PCs? iOS/Android devices? ...), etc.


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.


Best,

Stefan

* FSSC = Fast and Simple Sound Control.  The name is the aim...  :-D


On 31 Jan 2016 16:58, "Marc Lavallée"  wrote:

 


Warning: the discussion is drifting to DIY electronic gadgetry. :)

On Sun, 31 Jan 2016 11:16:26 +0100,
Bo-Erik Sandholm  wrote :

   


I have decided to simplify  the DIY head tracking dongle build and
setup in some aspects, now I have ordered this sensor that do not
need initial calibration.
This is the new sensor module:
https://learn.adafruit.com/adafruit-neopixel-uberguide/overview
 


The page is about addressable LED modules. Is it an error?

I would use a GY-85 board and a micro-controller, as seen here:
http://www.rcgroups.com/forums/showthread.php?t=1677559
This is a good starting point.

   


It will initially be combined with a esp8266 module for WiFi
connectivity or maybe Bluetooth
http://www.esp8266.com/wiki/doku.php?id=getting-started-with-the-esp8266

 


http://www.aliexpress.com/item/Promotion-Brand-NEW-HC-05-Wireless-Bluetooth-RF-Transceiver-Module-serial-RS232-TTL/32367579918.html

Could there be some added latency when using wifi or bluetooth? A
direct usb connection should be faster, but avoiding a cable would be
desirable because many android devices cannot easily use their usb port
for communication. If using wifi, I would try multicast udp.

Here's a page that explains how to use the bluetooth module:

http://www.instructables.com/id/Cheap-2-Way-Bluetooth-Connection-Between-Arduino-a/

   


Power will probably be from one of these, giving around 10 hours of
operations:

 


http://www.aliexpress.com/item/4PCS-Hot-Sale-Soshine-900mAh-14500-battery-3-2V-LiFePO4-AA-Rechargeable-Battery/32242320597.html

Nice!

   


I will send OSC (open sound control
https://en.m.wikipedia.org/wiki/Open_Sound_Control) directly from the
sensor.
 


OSC is a good protocol, but an application specific protocol could be
designed to be more compact, reducing the latency.

   


This should simplify the build of the head tracked sensor, reducing
the soldering need.
 


There would be 4 modules involved: a sensing assembly, a
micro-controller, a wifi transmission module, and a power s

Re: [Sursound] Never do electronic in public. (was: Never do math in public...)

[Marc Lavallée]

The BNO055 is a wonder.
Here's a complete integration with bluetooth:
https://www.youtube.com/watch?v=84MOS78-Hso
Too bad the schematics are not provided.

The sensor looks easy to use, but it needs calibration:
https://www.youtube.com/watch?v=Nz4EozK4cPY

If made small enough, a complete device could be useful not only for
head tracking, but also to track the orientation of an ambisonic
microphone (or a panoramic/360 camera).

--
Marc

On Sun, 31 Jan 2016 20:16:24 +0100,
Bo-Erik Sandholm  wrote :

> I copied the wrong link, touch interface is not always good :-)
> 
> I was involved in getting Matthias to support the diy head tracker
> with the gy-85 an a aurdino nano with USB connectivity, in the
> current setup we need a initial calibration and a pd plugin to
> convert to OSC to talk to Reaper daw.
> 
> Now I saw this module, neat and small no calibration needed.
> https://www.tindie.com/products/FabLab/pico-platinchen/
> 
> https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview
> 
> http://github.com/arduino-org/Arduino/tree/ide-org-1.6.1.x/libraries/NAxesMotion
> 
> Maybe it overkill and have one processor too much in the chain...
> Currently the plan is convert to OSC high speed serial in the
> pico-platinchen.
> 
> I will add a esp-01 esp8266 to connect the serial port and send the
> OSC data with UDP WiFi to the PC running Reaper. The WiFi setup will
> be done in esp-01 code.
> 
> Probably a esp8266 and the BNO055 directly connected could manage it
> without the ATmega328P on the pico platinchen.
> But currently the cost of for example
> http://www.ebay.com/itm/Adafruit-9-DOF-Absolute-Orientation-IMU-Fusion-Breakout-BNO055-PID-2472-/171821750983?hash=item28015fdac7:g:-wYAAOSwBLlVTrbI
> is not cheaper than the pico...
> 
> A naked bno055 is 13 usd on ali express but needs a circuit board and
> be built to combine with the esp-01.
> 
> So 2 small modules and a battery is the system, and be mounted on the
> headband of a headset.
> 
> I am definitely open for all possible forms of cooperation.
> Bo-Erik
> On 31 Jan 2016 16:58, "Marc Lavallée"  wrote:
> 
> >
> > Warning: the discussion is drifting to DIY electronic gadgetry. :)
> >
> > On Sun, 31 Jan 2016 11:16:26 +0100,
> > Bo-Erik Sandholm  wrote :
> >
> > > I have decided to simplify  the DIY head tracking dongle build and
> > > setup in some aspects, now I have ordered this sensor that do not
> > > need initial calibration.
> > > This is the new sensor module:
> > > https://learn.adafruit.com/adafruit-neopixel-uberguide/overview
> >
> > The page is about addressable LED modules. Is it an error?
> >
> > I would use a GY-85 board and a micro-controller, as seen here:
> > http://www.rcgroups.com/forums/showthread.php?t=1677559
> > This is a good starting point.
> >
> > > It will initially be combined with a esp8266 module for WiFi
> > > connectivity or maybe Bluetooth
> > > http://www.esp8266.com/wiki/doku.php?id=getting-started-with-the-esp8266
> > >
> > http://www.aliexpress.com/item/Promotion-Brand-NEW-HC-05-Wireless-Bluetooth-RF-Transceiver-Module-serial-RS232-TTL/32367579918.html
> >
> > Could there be some added latency when using wifi or bluetooth? A
> > direct usb connection should be faster, but avoiding a cable would
> > be desirable because many android devices cannot easily use their
> > usb port for communication. If using wifi, I would try multicast
> > udp.
> >
> > Here's a page that explains how to use the bluetooth module:
> >
> > http://www.instructables.com/id/Cheap-2-Way-Bluetooth-Connection-Between-Arduino-a/
> >
> > > Power will probably be from one of these, giving around 10 hours
> > > of operations:
> > >
> > http://www.aliexpress.com/item/4PCS-Hot-Sale-Soshine-900mAh-14500-battery-3-2V-LiFePO4-AA-Rechargeable-Battery/32242320597.html
> >
> > Nice!
> >
> > > I will send OSC (open sound control
> > > https://en.m.wikipedia.org/wiki/Open_Sound_Control) directly from
> > > the sensor.
> >
> > OSC is a good protocol, but an application specific protocol could
> > be designed to be more compact, reducing the latency.
> >
> > > This should simplify the build of the head tracked sensor,
> > > reducing the soldering need.
> >
> > There would be 4 modules involved: a sensing assembly, a
> > micro-controller, a wifi transmission module, and a power supply.
> > Going usb-wired would remove the wifi transmitter and the supply.
> >
> > A custom firmware can be programmed for the ESP-8266, which have
> > GPIOs, so maybe it could be used as a micro-controller:
> >
> > http://hackaday.com/2015/03/18/how-to-directly-program-an-inexpensive-esp8266-wifi-module/
> >
> > If a micro-controller is required, the trinket is an alternative to
> > the arduino nano: https://learn.adafruit.com/introducing-trinket/
> > It's much smaller, works at 3.2V. For a 5V USB wired version, it can
> > provide 3.2 volts for other boards.
> >
> > > This should simplify the setup of playback using
> > > http://www.matthiaskronlachner.com/?p=2015

Re: [Sursound] Never do electronic in public. (was: Never do math in public...)

[Bo-Erik Sandholm]

I copied the wrong link, touch interface is not always good :-)

I was involved in getting Matthias to support the diy head tracker with the
gy-85 an a aurdino nano with USB connectivity, in the current setup we need
a initial calibration and a pd plugin to convert to OSC to talk to Reaper
daw.

Now I saw this module, neat and small no calibration needed.
https://www.tindie.com/products/FabLab/pico-platinchen/

https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview

http://github.com/arduino-org/Arduino/tree/ide-org-1.6.1.x/libraries/NAxesMotion

Maybe it overkill and have one processor too much in the chain...
Currently the plan is convert to OSC high speed serial in the
pico-platinchen.

I will add a esp-01 esp8266 to connect the serial port and send the OSC
data with UDP WiFi to the PC running Reaper. The WiFi setup will be done in
esp-01 code.

Probably a esp8266 and the BNO055 directly connected could manage it
without the ATmega328P on the pico platinchen.
But currently the cost of for example
http://www.ebay.com/itm/Adafruit-9-DOF-Absolute-Orientation-IMU-Fusion-Breakout-BNO055-PID-2472-/171821750983?hash=item28015fdac7:g:-wYAAOSwBLlVTrbI
is not cheaper than the pico...

A naked bno055 is 13 usd on ali express but needs a circuit board and be
built to combine with the esp-01.

So 2 small modules and a battery is the system, and be mounted on the
headband of a headset.

I am definitely open for all possible forms of cooperation.
Bo-Erik
On 31 Jan 2016 16:58, "Marc Lavallée"  wrote:

>
> Warning: the discussion is drifting to DIY electronic gadgetry. :)
>
> On Sun, 31 Jan 2016 11:16:26 +0100,
> Bo-Erik Sandholm  wrote :
>
> > I have decided to simplify  the DIY head tracking dongle build and
> > setup in some aspects, now I have ordered this sensor that do not
> > need initial calibration.
> > This is the new sensor module:
> > https://learn.adafruit.com/adafruit-neopixel-uberguide/overview
>
> The page is about addressable LED modules. Is it an error?
>
> I would use a GY-85 board and a micro-controller, as seen here:
> http://www.rcgroups.com/forums/showthread.php?t=1677559
> This is a good starting point.
>
> > It will initially be combined with a esp8266 module for WiFi
> > connectivity or maybe Bluetooth
> > http://www.esp8266.com/wiki/doku.php?id=getting-started-with-the-esp8266
> >
> http://www.aliexpress.com/item/Promotion-Brand-NEW-HC-05-Wireless-Bluetooth-RF-Transceiver-Module-serial-RS232-TTL/32367579918.html
>
> Could there be some added latency when using wifi or bluetooth? A
> direct usb connection should be faster, but avoiding a cable would be
> desirable because many android devices cannot easily use their usb port
> for communication. If using wifi, I would try multicast udp.
>
> Here's a page that explains how to use the bluetooth module:
>
> http://www.instructables.com/id/Cheap-2-Way-Bluetooth-Connection-Between-Arduino-a/
>
> > Power will probably be from one of these, giving around 10 hours of
> > operations:
> >
> http://www.aliexpress.com/item/4PCS-Hot-Sale-Soshine-900mAh-14500-battery-3-2V-LiFePO4-AA-Rechargeable-Battery/32242320597.html
>
> Nice!
>
> > I will send OSC (open sound control
> > https://en.m.wikipedia.org/wiki/Open_Sound_Control) directly from the
> > sensor.
>
> OSC is a good protocol, but an application specific protocol could be
> designed to be more compact, reducing the latency.
>
> > This should simplify the build of the head tracked sensor, reducing
> > the soldering need.
>
> There would be 4 modules involved: a sensing assembly, a
> micro-controller, a wifi transmission module, and a power supply. Going
> usb-wired would remove the wifi transmitter and the supply.
>
> A custom firmware can be programmed for the ESP-8266, which have GPIOs,
> so maybe it could be used as a micro-controller:
>
> http://hackaday.com/2015/03/18/how-to-directly-program-an-inexpensive-esp8266-wifi-module/
>
> If a micro-controller is required, the trinket is an alternative to
> the arduino nano: https://learn.adafruit.com/introducing-trinket/
> It's much smaller, works at 3.2V. For a 5V USB wired version, it can
> provide 3.2 volts for other boards.
>
> > This should simplify the setup of playback using
> > http://www.matthiaskronlachner.com/?p=2015
> > And maybe later ambiexplorer can be modified to accept OSC data?
>
> It could even be used with a browser (chrome) based player.
>
> In the end, the first problem to avoid is latency, and it can invalidate
> many potential solutions.
>
> > This will allow you to use any headphones and DAC and amplifier
> >
> > Best regards
> >
> > Bo-Erik
>
> I already bought some of the parts to create a head-tracking device,
> months ago. Let's do it and share the designs. Even if we have
> personalized HRTFs with order 1024 decoders, we need head-tracking.
> The other solution is to use the sensors in phones or oculus-like
> devices, but they are all too big or a bit expensive for the task
> of listening to binaural 

Re: [Sursound] Never do electronic in public. (was: Never do math in public...)

[Paul Hodges]

--On 31 January 2016 10:58 -0500 Marc Lavallée 
wrote:

> Warning: the discussion is drifting to DIY electronic gadgetry. :)

I just got some new electronic gadgetry. :-)  Not home-made, though,
commercial, designated with a block of random letters and numbers:
something like SPS200...

Paul


-- 
Paul Hodges

___
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.