Beep sounds wrong

The sim just has generic ones. To see how they really sound, you need a device.


What I do is go by the name for the tones, so TONE_LAP is used for laps, TONE_START/STOP when recording starts/stops, etc.

I agree with Jim. The point of the tones is to use the correct one for the purpose (e.g. lap, low alert, high alert), not to hear exactly how they sound. The user will hear the “right” tone (i.e. same as native app) as long as the CIQ app chose the correct one.

Of all the things that could be fixed in the sim, this is personally the last thing I would worry about.

That's fine.... but I'd prefer consistency between devices. So I had to create a test function to iterate across the 18 sounds on every device I own. Or ask someone to record the test app for the 18 sounds. I use particular sounds for particular reasons. For example, if a device resets during an activity (rare, but happens) and my app recovers persistent data and continues... I alert the athlete with a particular longer tone. If 60 second average power exceeds the current target level by more than 10%, I send the medium length vibration tone.

Tone #8 in the simulator is a very short single chirp, on the Edge 1030, is it a longer vibration tone. Very different!

I guess we leave it to the developer to hope their app behavior isn't too different from device to device... because the behavior isn't anything like the simulator.

I guess you may have missed the point that there is no consistency between native apps across devices, either, by the same logic. So do you want your app to sound like the native app on the device that the user owns, or do you want your app to sound the same on all devices?

Maybe it’s just me, but I think most people only own one device of each type, so they have nothing to compare to. And if they own multiple devices, then they already know that the tones are different, so their expectations are set.

I think you want the meaning of your tone to be consistent across devices, not the precise duration and sound. Unless you are literally describing the tone to users (sounds like you are). In which case it would be better to request an API that can generate the exact tone you want. I’m guessing this will never happen as there is a reason the API is the way it is.

I also think you are asking a lot of users to precisely differentiate between all the different tones your app generates and decode their meaning. Just my opinion, but it would be better to indicate this visually somehow. Especially with all the real estate of an Edge screen.

I would use an alert or error tone where appropriate, then display a visual indication for more information.

While I'm personally avoiding/limiting to use tones in my apps as I find them too intrusive, I think it's a reasonable request to have the simulator fixed in order to have it sound like the physical device (all cases where the device acts differently than the simulator is preferably fixed).

It's likely not even hard to do this fix (but it's a fix that requires maintenance on new device releases, which might be a reason to flag it as a won't fix. On the other hand it could be just a thing to add to the check list you have when releasing a new device (create an image for the device, get the sounds, etc...)....)

While the Garmin people browse the general connect iq forum, if you want the issue to have a higher chance to be considered to be fixed, create a bug report in the connect iq bug forum. ;)

I'd agree with Dave that it'd be nice to have all devices and the simulator consistent. That isn't likely to happen. I disagree that relying on the name of tones is adequate. Maybe for standard actions like lap, start, stop, etc. But what Dave is running into here are tones for non common actions that don't have good names. And given his app is for long distance, possibly multi day events, there is actually a really good chance someone will be using multiple devices, like a 1030 and a 520, (or even a forerunner) for parts of it.

I have a similar problem with my dog tracker app. Tones are a pretty key part of the app for alerting you to the dog status. Dog has stopped and has an animal tree'd. Dog has left a 50 yd radius, or has entered a 50 yd radius. With the actual Garmin Alpha hand held, it uses the same tone for both of those and is not configurable so when you hear the tone, you don't know if it has come or gone. My app lets you configure each tone separately. As well as vibration. On my personal version, I also have a different set of tones for entering/exiting 100 yd radius.

Maybe that is the key here for Dave. Let the user configure these tones to what they would like. Each user responds to different tones, pitches, duration's, vibrations differently.

I'd love to see a fully generic tone command where you can configure it like with vibration. Although even that could be problematic as the sound maker on each device might sound differently depending on the location within the device, the size of the device, and the material of the device.

Fair enough, every dev has different needs. But I would argue that “device resets and app recovers” could be TONE_RESET or TONE_ERROR. Then there could be a pop up that reads “Device was reset” or something.

Average power exceeding target could be TONE_ALERT_HI. If you need different alert tones, you could maybe play it multiple times. Or maybe you have a pop up that shows the specific alert type.

Are you really going to document that “2 second flat tone” means “app recovered” or something? Garmin doesn’t document what those tones sound like (for the most part) to either users or devs, and I can see why.

I’m just saying that this is sort of an attempt to do an end run around functionality that was never intended to be the same on all devices. Which is fine, we all do that kind of thing every now and then. But if the user already knows what some of those tones mean in a different context, maybe it could be confusing. But tbh I have no idea.

I mentioned this before as well, but I agree that what this problem needs is a generic tone generator. Having the sim sound right is just a nice to have and a workaround.

I would love for the sim to emulate devices perfectly. But ppl keep telling me the simulator is not an emulator, when it comes to displaying the correct fonts in data fields or even emulating native button behaviours. I would love for the KEY to be ignored in the sim for VA3 widgets since it always exits to the watchface, or even to actually kill the widget like it would IRL, but I wonder if that will ever happen.

I'm not sure the tones themselves are really that different between devices. I use a set of tones in one of my apps, and they sound pretty much the same between the watches and non-wearables I have. There can be a difference based on the HW used for the tone, it's location and mounting in the device, but that's all I've really noticed. And I'd expect they could sound a bit different between multiple devices of the same type for the same reason.

The app also has a setting for tones, vibrations or both, For a watch, vibrations get your attention where a tone may not, especially if you are listening to music or if you are hard of hearing. But in both cases, if it's something other than say a start/stop/save/discard, I pop up a message for 8-10 seconds, and the color can indicate things there too.

Makes sense Jim. And now that I have onTap() capability on touch screen EDGE devices (my primary target), I can also allow User Dismiss sooner, as well as a timeout.