I think the disjoint between the audio and the visual is amplified due to the fact that the read head(s) are a couple inches to the left under the cover. So there is always a perceived delay to the audio from where you are looking. This magnifies if you for example look to the right edge of the view while it's playing a couple inches past the left, less so if you can project the last "bar" past the left edge in your mind.
This device would be better I think if the read head could be moved directly to the left edge or even perhaps placed in the center of the view. But I have a feeling it needs to be in darkness to read best.
I'm not sure, to be honest, they all seem a bit meh, but if the Pebbles is close or better than the Forerunner it'll be worth it on price alone I feel.
I'm sure he understands the difference, but with two successful campaigns for the pebble, and this new one already at 2.5m, one can understand his faux pas.
I'm also sure he doesn't need us to tell him the differences between kickstarter order and a true pre-order.
I didn't pay anything extra for duty? I bought my wife a "Round" back in January, and while the Canadian dollar was crappy, I only payed 25% in CDN dollars over the websites listed price. So, not sure if I got lucky or you just didn't. :(
On a side note Canadian shoppers can find the watches at their local Best Buy... at least the current ones anyway. You might not get the style you want though, as they seem to be a bit limited that way. Pricing is usually close to the US price. I paid the extra to get the style I wanted for the wife.
One of the biggest issues for me with the Forerunner is the fact that it seems to have a rather laggy heart rate monitor. Looking at my friend heart rate tracking with the watch, shows rather abrupt increases and decreases in the heart rate, most notable at the beginning and end of a run.
Based on the cost of the Forerunner, if the new Pebble Time 2 is as accurate or better, the cost alone might have me buying it. That said I'm on Android so I would get all the benefits unlike the iOS crowd.
A funny thing about interactive maps while driving. If I'm on my phone and I bring up a road map of the area I'm traveling and I am constantly zooming in and panning the app so that I can see locations around me then the map has failed me.
Landmarks are key to any map, but landmarks that fade in and out of focus are not all that useful. I used to be excited by the prospect of being able to bring up a map of my route and being able to see where I was going on my phone mounted to my dash. But as of late, I've been struggling to find the right zoom level that shows enough detail of the area I'm traveling while showing enough of my route.
On a number of occasions over the last year I've has to pull over and reorient myself on my map due to a failed pan/zoom attempt.
It's funny that this article came out at this time as I've been evaluating ways to mount a larger device (tablet) on my dash as maps on my phone has gotten to be rather cumbersome.
I feel that for the most part the details in this article are accurate, that the attempt by google to make the maps load quicker on mobile have compromised critical details available on the maps.
One of the key areas where this could be addressed is by loading details based on need. For example if I select a travel route between two locations, load more of the details related to that route and reduce the extras that fall outside my concern. Show me roadways that leave my target route, as well as the cities and towns along my route. Making an attempt to provide me the details I need without my need to interact with them as much as possible would be great.
I just have one smallish question. Is the need to bench then add an actor the only way you "allow" transfer of children between parent actors?
In similar systems that I have constructed in the past, I have used a number of methods for passing actors in different states.
Pass a fully instantiated actor via a transfer process. Nothing changes for the actor, beyond reassigning parentage.
Pass a cleaned actor via a similar process to the bench and add process. This was used to allow an actor to be reduced to a resting state as it were. In most cases you could think of it as a resurrection method that allowed discarded actors to be reinstated with only specified base properties in place.
Anyway, I don't use Lua at all, but I like these type of actor messaging models. I look forward to reading through the rest of your documentation once it's done.