|
|
Post by AudioHTIT on Aug 21, 2020 19:17:01 GMT -5
If that's the case could you provide a link, I obviously missed it. Edit: I now see you missed it too  I might be missing something, but the same API that has been around for years is what we are using. They have added a couple things and some things don't work on the G3P. I've been using the API for many months to control everything I need controlled. I've put my python code here on a thread I started a while back. We just need access to all settings if the API doesn't already cover all settings. With that, we could fairly easily come up with a web app that could be used to configure the unit. I personally have stopped working on it because I'm evaluating whether or not I will continue using Emotiva processors. I think we need two different things and that lumping them together like you're doing complicates one at the expense of the other. First, while the existing API is for the most part 'compatible' with the G3P, it is not in any way 'complete'; we need a an updated and complete API that exploits all of the remote and monitoring capabilities of the G3P -- eg. the ability to control every pair of speakers, directly access all of the codecs and audio modes, etc. Your existing code would work fine, it would just have to be expanded to include the missing functions. Second -- if it's even on the table, as that's what this thread seeks to discuss -- is an interface to the 'settings'. I don't think it's a given that they would be accessible using the same API, and for instance, whether a Web back end would be best handled that way (if that is indeed what's desirable). I certainly don't know if or how they might choose to implement something like that, or even if it's even on the table, but we 'discuss amongst ourselves'. |
|
|
|
Post by megash0n on Aug 21, 2020 21:18:54 GMT -5
I might be missing something, but the same API that has been around for years is what we are using. They have added a couple things and some things don't work on the G3P. I've been using the API for many months to control everything I need controlled. I've put my python code here on a thread I started a while back. We just need access to all settings if the API doesn't already cover all settings. With that, we could fairly easily come up with a web app that could be used to configure the unit. I personally have stopped working on it because I'm evaluating whether or not I will continue using Emotiva processors. I think we need two different things and that lumping them together like you're doing complicates one at the expense of the other. First, while the existing API is for the most part 'compatible' with the G3P, it is not in any way 'complete'; we need a an updated and complete API that exploits all of the remote and monitoring capabilities of the G3P -- eg. the ability to control every pair of speakers, directly access all of the codecs and audio modes, etc. Your existing code would work fine, it would just have to be expanded to include the missing functions. Second -- if it's even on the table, as that's what this thread seeks to discuss -- is an interface to the 'settings'. I don't think it's a given that they would be accessible using the same API, and for instance, whether a Web back end would be best handled that way (if that is indeed what's desirable). I certainly don't know if or how they might choose to implement something like that, or even if it's even on the table, but we 'discuss amongst ourselves'. I agree. We just need an API for all the settings. |
|
|
|
Post by JKCashin on Aug 21, 2020 22:18:13 GMT -5
I might be missing something, but the same API that has been around for years is what we are using. They have added a couple things and some things don't work on the G3P. I've been using the API for many months to control everything I need controlled. I've put my python code here on a thread I started a while back. We just need access to all settings if the API doesn't already cover all settings. With that, we could fairly easily come up with a web app that could be used to configure the unit. I personally have stopped working on it because I'm evaluating whether or not I will continue using Emotiva processors. I think we need two different things and that lumping them together like you're doing complicates one at the expense of the other. First, while the existing API is for the most part 'compatible' with the G3P, it is not in any way 'complete'; we need a an updated and complete API that exploits all of the remote and monitoring capabilities of the G3P -- eg. the ability to control every pair of speakers, directly access all of the codecs and audio modes, etc. Your existing code would work fine, it would just have to be expanded to include the missing functions. Second -- if it's even on the table, as that's what this thread seeks to discuss -- is an interface to the 'settings'. I don't think it's a given that they would be accessible using the same API, and for instance, whether a Web back end would be best handled that way (if that is indeed what's desirable). I certainly don't know if or how they might choose to implement something like that, or even if it's even on the table, but we 'discuss amongst ourselves'. But what's missing? If you press cursor up on the remote, you get the precedig codec. Same for the API. You request the previous surround format, and you get the preceding codec. On the XMC-1 the list would NOT include things like ATMOS... on the XMC-2, it would. I am not sure I understand what you are saying is missing. See the second link here: emotivalounge.proboards.com/post/1027423 |
|
|
|
Post by AudioHTIT on Aug 22, 2020 9:40:15 GMT -5
I think we need two different things and that lumping them together like you're doing complicates one at the expense of the other. First, while the existing API is for the most part 'compatible' with the G3P, it is not in any way 'complete'; we need a an updated and complete API that exploits all of the remote and monitoring capabilities of the G3P -- eg. the ability to control every pair of speakers, directly access all of the codecs and audio modes, etc. Your existing code would work fine, it would just have to be expanded to include the missing functions. Second -- if it's even on the table, as that's what this thread seeks to discuss -- is an interface to the 'settings'. I don't think it's a given that they would be accessible using the same API, and for instance, whether a Web back end would be best handled that way (if that is indeed what's desirable). I certainly don't know if or how they might choose to implement something like that, or even if it's even on the table, but we 'discuss amongst ourselves'. But what's missing? If you press cursor up on the remote, you get the precedig codec. Same for the API. You request the previous surround format, and you get the preceding codec. On the XMC-1 the list would NOT include things like ATMOS... on the XMC-2, it would. I am not sure I understand what you are saying is missing. See the second link here: emotivalounge.proboards.com/post/1027423Exactly what you just said, on the XMC-2 there are more channels, more codecs, more audio modes. We need the updated/expanded API to give us the IR/IP codes to directly access those functions (just as the existing API has many codes that aren’t on the remote). For example if we can raise and lower the level of the rear and sides separately, we should be able to adjust levels on the front height, mid height, and rear height separately. You mentioned Atmos, that’s another example, though the existing ‘Dolby’ command does activate the DSU. The truth is, we don’t know what we don’t know, there could be many functions that could be exposed with an API for things we haven’t thought of. Leave it to say, the XMC-1 API is incomplete as a tool for accessing the XMC-2 — which shouldn’t stop you from using it now, knowing you will have to revisit it when the rest of the codes are released. Edit: I think I see the logic, that using the ‘previous’ and ‘next’ commands you can cycle through all the options. Having a Harmony Hub based remote, I have direct access to all of the modes and never use those. Also note the post you referenced begins with “ In the mean time...”, implying there’s more to come. |
|
|
|
Post by AudioHTIT on Aug 22, 2020 11:05:18 GMT -5
For those who aren’t aware of the current API, I find the following screenshot helpful. These are all the commands available on the XMC-1 in the Harmony remote’s ‘Device’ mode (as viewed from the iPad App), this shows every remote command available in the API. By comparing this to the physical remote, you can get an idea of the additional control that’s available, and what could be available with a G3P API. In the second screenshot I show the XMC-1 App, what’s special about this app is that it provides ‘status’ or feedback. You can see in the display upper center that it mimics ‘most’ of the info display on the XMC, I find this very useful and would like to see it include the exact information that appears on the OSD when you hit ‘Info’. Further feedback is given on the volume slider, where it’s in the relative location for the current volume. As a ‘stopgap’ to an HTML setup, a page could be added that would echo the setup screen, allowing ‘headless’ setup, although not the desired offline setup.   |
|
klinemj
Emo VIPs 
Honorary Emofest Scribe
Posts: 14,761
|
Post by klinemj on Aug 22, 2020 11:09:23 GMT -5
I know I'm likely in a very small minority, but if it makes for a more stable product (especially on the video side of things), I'm all for ditching the OSD altogether. I find the HTTP setup that Monolith chose to be very clever and intriguing. I also remember Lonnie discussing how the OSD "complicates" things. I'm in the same camp as you, doc. I recall Lonnie's comments on how the OSD complicates things for them. For me, I would happily live without it IF there was a simple option that: 1) didn't require me to be sitting directly in front of my processor and pushing buttons/turning knobs and reading changes on a fairly small screen like a typical pre/pro screen (even the large one on the RMC-1 is "small" to my bad eyes). 2) allowed me to do all the setup from a device like a laptop or tablet or other computer...ideally while sitting in my comfy chair. 3) also allowed me to do things like change volume and inputs from the same device/app WHILE still maintaining the option to "go grab the volume knob and turn it down quickly" in case the connection to the pre/pro wasn't working all of a sudden. I don't know and don't care what an API or other things others are talking about are - nor do I really care. I just know that when I listen to music these days, I pick up my tablet, launch Roon, choose my music and which device plays it, and sound begins. Or, I do the same for my Sonos units - often while floating in my pool in sitting in my hot tub. And, if I want to set a TV show to record, I go to hulu.com on my Microsoft Surface and do it from there. I rarely use my TV remote and do it on the TV's screen. That's my 2 cents. Mark |
|
|
|
Post by bitzerjdb on Aug 22, 2020 16:59:13 GMT -5
I stopped using OSD when I added the Video Switch to stabilize the Input switching issues I had. I have to say, I don't miss it at all. Give me a WEB interface or a way to modify the settings with my Laptop and I would be super happy!
|
|
|
|
Post by hsamwel on Aug 23, 2020 15:27:01 GMT -5
As I have said before.. Probably not the OSD feature that’s the problem..
Rather the live update!
Also the transparent graphics shown with live feed see-through needs
alot of cpu/gpu power
The processors would be soooo much faster without these features.
Live update is good in speaker level setup.. But anywhere else
it’s only trouble, slowing down the system and probably causing
some bugs.. Alot of memory rewrites when going through the menus..
But then again, some of these things are what sets Emotiva apart
from the rest featurewise..
|
|
