pippin;412941 Wrote: > Chris, > > actually that was what I meant. However, if iPeng's got to support it, > you also need some UI, and just having menus may be a bit too little. > Although it has the big advantage that it will work with the Controller > and Squeezeplay, too. > But you can still re-map menu items to something else and part of this > is what the upcoming iPeng 1.2 interface is about. For example, I plan > to include a "Power" button for servers that can shut down a server > using the SvrPowerControl plugin and will wake it up by sending a WOL > packet. Of course this is all proprietary but once it works you could > as well define some standardized interface. > > Another idea I had, especially with local playback in mind, was that > you could connect players to the server that are not really players. > They would have only part of the capabilities, most notably not the > actual playback capabilities, but you could for example use the > interfaces for play, pause, skip, volume... If a plugin did that and > used these commands to drive an external unit, it's a way to wrap your > whole entertainment into the SB architecture. IRBlaster is going into > the direction but not fully so. Your plugin does the same but only in > connection with an amp connected to a player, if I understand it right. > But theoretically you could write a plugin that wraps a TV control into > this, since essentially all you need for a TV is power, skip and volume > and then you could have a player "TV" controlled through your SC based > equipment. > > Cool?
Yes but there are two issues here. One is that SC can only interpret certain events. For example in the API you can see what you can subscribe to in the command callbacks. If an event is driven from one of these events, then you can either trap that event and have SC ignore it while your plugin does whatever you want, or you can let SC do its thing and continue to do what you want outside of SC. The other situation is sort of like what you are describing. Complety new events that SC knows nothing about and would never be aware of. Let me give some examples: For the first type of event you may have the turning on/off a SB or adjusting volume, picking a track, running a search etc. All of these events you use your SB for you could attach related events to like having an AMP turn on/off, adjusting your lighting to match the gendre of song being played etc. This is all related to what you are doing with the SB. For the second example its a bit tougher. You have to leave the SC environment and ask yourself what does iPeng need to do thats not connected with a SC event? Perhaps this is your point with the UI. For example maybe you want to kick off an application that shows you how much power all of the SB's and amps you have connected are using. My only point is that things that are intrinsic to SC should stay server sided if possible so it works with the largest possible mixture of devices. Things that are heavily UI or device dependant could run natively. I may still be confused by all of the features you have cooked up for iPeng and we will have to wait and see what comes in 1.2. I just see a lot of features people are asking for are truely capable today, although they may not be available. I was suprised what you had to do to support IRBlaster in 1.1 for example. One would have thought that no special UI would have been required in iPeng to support that. But of course you know what you are getting into :-) -- Aesculus Chris ------------------------------------------------------------------------ Aesculus's Profile: http://forums.slimdevices.com/member.php?userid=14876 View this thread: http://forums.slimdevices.com/showthread.php?t=55514 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/discuss
