Roku Developer Program

[malort]

Just noticed this too while browsing the docs. The last question now is if we can pull the menu volume setting? Would be nice to ignore firing events if the menu volume is off. Either way, this is great news! Thanks Roku.

[BradC]

"TheEndless" wrote:

"BradC" wrote:
Been using them since I joined this little party in 2012.

Way to hold out on us, man... 😉
They were just added to the SDK docs on March 31st.

I know, I got that happy feeling you get when you have an answer someone is looking for, then after I typed it, I saw it was you who asked, and I was like, "wait a minute... he must already know this." then I stopped and looked at the date, and I was like, "...oh... this is a really old question, that's why... it probably didnt' even exist back when he asked. everybody probably knows it now and I'll look like an idiot for acting like I think it's new info in 2015." Then I see this thread and am disappointed again that I didn't share it, since it would have actually been useful to people. 😞 I'm just glad you posted the update.


The odd part is I must have gotten the info from the docs somewhere, unless it was in the sample code.

[TheEndless]

"malort" wrote:
Just noticed this too while browsing the docs. The last question now is if we can pull the menu volume setting? Would be nice to ignore firing events if the menu volume is off. Either way, this is great news! Thanks Roku.

See above...

[malort]

I have read the thread, and maybe I missed something. I do understand the stock sounds will use the global volume, and if one sets the volume off, our trigger will be silent. I would just like to know if the volume is off so we can bypass unnecessary code.

"TheEndless" wrote:

"malort" wrote:
Just noticed this too while browsing the docs. The last question now is if we can pull the menu volume setting? Would be nice to ignore firing events if the menu volume is off. Either way, this is great news! Thanks Roku.

See above...

[TheEndless]

"malort" wrote:
I have read the thread, and maybe I missed something. I do understand the stock sounds will use the global volume, and if one sets the volume off, our trigger will be silent. I would just like to know if the volume is off so we can bypass unnecessary code.

I don't know of any way to get the volume setting, but if the box handles that automatically I'm not sure why you'd need it, unless you're wanting it for custom sounds.

[malort]

The box does not handle the sounds automatically when using the 2d api. Yes, it will handle the volume accordingly when using the built-in sounds, so that is great, really great. The fact is we have to add our own code to trigger the events. If the user has disabled the menu volume, then why not bypass any logic used to trigger the sound clips. It's not really a big issue, and it's probably not much of a performance hit to just trigger vs checking if the volume is off.

"TheEndless" wrote:

"malort" wrote:
I have read the thread, and maybe I missed something. I do understand the stock sounds will use the global volume, and if one sets the volume off, our trigger will be silent. I would just like to know if the volume is off so we can bypass unnecessary code.

I don't know of any way to get the volume setting, but if the box handles that automatically I'm not sure why you'd need it, unless you're wanting it for custom sounds.

[squirreltown]

"malort" wrote:
The box does not handle the sounds automatically when using the 2d api. Yes, it will handle the volume accordingly when using the built-in sounds, so that is great, really great. The fact is we have to add our own code to trigger the events. If the user has disabled the menu volume, then why not bypass any logic used to trigger the sound clips. It's not really a big issue, and it's probably not much of a performance hit to just trigger vs checking if the volume is off.

You are assuming that the box with zero volume set is doing trigger(0) but we don't actually know if thats how the firmware handles it. Performance-wise I'd bet it's un-measurable.

[destruk]

It would still be useful to be able to query the volume setting - that way if the volume is "off" then we wouldn't need to use memory loading a sample (custom or not) that won't be played or heard.

[RokuKC]

Thanks for the feedback. The feature request is noted.

[malort]

I am not assuming anything the firmware does. I am only talking about the logic I have to use when I need to calculate the right sound. If the user chooses to mute the feedback, then there is no reason for me to iterate through any audio feedback logic I have employed. Either way, as I did mention, it's probably not a big performance hit at all.. it just seems like the right way to handle it.

"squirreltown" wrote:

"malort" wrote:
The box does not handle the sounds automatically when using the 2d api. Yes, it will handle the volume accordingly when using the built-in sounds, so that is great, really great. The fact is we have to add our own code to trigger the events. If the user has disabled the menu volume, then why not bypass any logic used to trigger the sound clips. It's not really a big issue, and it's probably not much of a performance hit to just trigger vs checking if the volume is off.

You are assuming that the box with zero volume set is doing trigger(0) but we don't actually know if thats how the firmware handles it. Performance-wise I'd bet it's un-measurable.