Altering volume increase/decrease increment - App_Server.cpp

[purps]

I found this part in App_Server.cpp...

Code: [Select]

//<-dceag-c89-b->

/** @brief COMMAND: #89 - Vol Up */
/** Increase the volume 1% */
/** @param #72 Repeat Command */
/** If specified, repeat the volume up this many times */

void App_Server::CMD_Vol_Up(int iRepeat_Command,string &sCMD_Result,Message *pMessage)
//<-dceag-c89-e->
I now understand that // is to comment lines out. Could I alter the above like this...

Code: [Select]

//<-dceag-c89-b->

/** @brief COMMAND: #89 - Vol Up */
/** Increase the volume 1% */
/** @param #72 Repeat Command */
/** If specified, repeat the volume up this many times */

void App_Server::CMD_Vol_Up(int iRepeat_Command,string &sCMD_Result,Message *pMessage)
void App_Server::CMD_Vol_Up(int iRepeat_Command,string &sCMD_Result,Message *pMessage)
void App_Server::CMD_Vol_Up(int iRepeat_Command,string &sCMD_Result,Message *pMessage)
void App_Server::CMD_Vol_Up(int iRepeat_Command,string &sCMD_Result,Message *pMessage)
//<-dceag-c89-e->
Or am I in the wrong area?

[wierdbeard65]

Hey, man!

Ok, I'm not c++ guru, but I do know a bit about it (and other languages).

The line

Code: [Select]

void App_Server::CMD_Vol_Up(int iRepeat_Command,string &sCMD_Result,Message *pMessage)
defines a function / method called CMD_Vol_Up, with 2 parameters which returns no value (void). The change you propose would cause a complier error, I'm afraid.

What should follow is a block of code enclosed by braces: {} This is what the function actually does.

I suggest that you either look at that code to perform the repetition you desire (remembering it will affect any code that calls this). Alternatively, see if you can find where it is being called from and call it multiple times.

My guess is that the first parameter (int iRepeat_Command) represents the number of times to repeat the command anyway, so it may be a simple as going to the first line after the { and inserting something like

Code: [Select]

iRepeat_Command *= 2;to repeat twice as many times as the caller intended, etc.

HTH

For more infor, I recommend looking up a C++ primer, a good one is Teach Yourself C++ in 21 Days.

[phenigma]

This would be great functionality!  All current a/v dSomeone who knows more specifics could comment though.evices rely on a device template to assign the number of 'repeats' for volume commands.  It seems to me that the app_server must (or should) have a device template (it must have somewhere) and that it should follow the same rules as any other device that has volume commands and respond to the configured repeat amount set in the template.

I'm not certain the exact method to implement this but there should be a setting in the template, or it must be added, and then the app_server would have to honour those volume repeat numbers, in a loop.  My understanding is the app_server only handles volume commands when no other device is available (ie no receiver or tv which handles volume setup in the connection manager) so any changes to app_server should only affect systems without another device handling volume control. 

Can someone confirm or correct my assumption of how this should be implemented?

J.

[purps]

Yes this discussion was started in the web orbiter 2.0 thread. I was told that app_server handles volume control in the absence of a receiver, amp, etc.

So is this not the template then? App_Server.cpp?

wierdbeard pointed out the iRepeat_Command - could that not be used somehow? Or could we add a loop or something? Or recursion?

[esev]

I'm not certain the exact method to implement this but there should be a setting in the template, or it must be added, and then the app_server would have to honour those volume repeat numbers, in a loop.  My understanding is the app_server only handles volume commands when no other device is available (ie no receiver or tv which handles volume setup in the connection manager) so any changes to app_server should only affect systems without another device handling volume control. 

I'm with phenigma on this one.  Setting a fixed volume increment/decrement in the code of App_Server.cpp makes that a permanent change for everyone. I'd much rather see this as part of the ''device data'' in the template.  Set the default in the template to 1, then it doesn't change the default behavior everyone is currently expecting.  An end user could then click on the App_Server in their devices tree and set a specific repeat rate required for their hardware.

[jthodges]

Another option is to create a new device template that registers as a message interceptor, and then listens for any volume up/down commands for a particular device, and sends out repeats as configured in device data.  I implemented this for 7.10 and it worked well to give me 2.5 db jumps on my IR-integrated receiver rather than 0.5 db.

Personally, I like this approach better because you can use it to decorate any device that needs a volume adjustment, rather than making it part of a particular device.  But I'm not good enough with the system to say which is the 'correct' approach, I just wanted to throw that out there. 

[tschak909]

an interesting approach. Did you do this in the media PlugIn?

-Thom

[jthodges]

This was a couple of years ago, so I may be forgetting details.  But I believe that I just created a new device template, implemented it in C++, registered to intercept all vol up/down messages (I didn't worry about target device at the time), and repeated them as configured.  I don't recall anything special being done with the media plugin.

I do need to get this working with my 0810 install though, so I will hopefully be digging that back up in the near future.  Assuming it wasn't lost, I'll update this thread if I find anything else that I'm forgetting, and of course will also offer up the code if its useful to anyone.

[tschak909]

it should be shoved into media plugin, and use device data on the target device... We can then add the fields to the wizard pages.

-Thom

[Marie.O]

Why insert it into the media plugin, when it can easily live as a specific device?

[tschak909]

because plugins can intercept and transform events...that was one of the reasons the event interceptors were done that way.... any av stuff needs to go into the media plugin, with the rest of the pipe management code so that it can have access to those data structures.

-Thom

[jthodges]

For me, the draw of the separate device was that you can configure it separately for each audio device that you want to adjust.  For example, maybe I want to triple the volume adjustment rate for one receiver, and double for another.  I can create two devices from this template, one for receiver A configured with 3x repeats and another for receiver B with 2x repeats.  I'm not sure how that would work if it was rolled into the media plugin, but I might just not be understanding the approach.

edit: BTW, I keep saying device, but I seem to remember implementing this as a plugin for some reason.  As I said, it was quite a while ago.  Hopefully I can dig up the code to shed a little more light on it.

[Zaerc]

Code: [Select]

/** @param #72 Repeat Command */
/** If specified, repeat the volume up this many times */

If there already is a repeat-command parameter, why not simply use that?

[jthodges]

The parameter on the vol up/down commands?  I think I did use that, actually, within the interceptor that sends out the additional volume commands.  But I'm not seeing how using the parameter can be a solution in itself, unless the orbiter generating the command was made to use the repeat param.  Am I misunderstanding the suggestion?

[tschak909]

jt.... *thwap*

if you put it in the media plugin, use the repeat devicedata....it can work for all av devices.