Can someone explain to me why change this? It was writable in CTP.  Now I can't fast forward or rewind in my zune music player. I really don't see any reason for that. It just looks like one of the arbitrary restrictions to me.

Edit: I just found out there is no constructors for MediaQueue class in 3.0beta, now you totally lost me! Why do you still keep it in xna then?! I can't construct one, nor can I refer to its members 'cause they are non-static. Great!

Edit 2: I see they moved MediaQueue under MediaPlayer as one of its properties, should have noticed.

I can't answer that (since I'm not on the team), but it may have something to do with consumer expectations. For instance if the user is listening to their own music using Windows Media Player or (when this is on the Xbox) on Xbox 360, setting that value lets you screw with their music. That might not be desired.

sectionboy:

Edit: I just found out there is no constructors for MediaQueue class in 3.0beta, now you totally lost me! Why do you still keep it in xna then?! I can't construct one, nor can I refer to its members 'cause they are non-static. Great!

They keep it in there so the framework can use it.

If you're playing with your console, you surely expect some thing happen to the devices it connects to. You move the joystick, the sprite on your TV might move; you push a button, it shouldn't be surprising if the speaker makes a noise. Of course, the player knows what's gonna happen, let it be TV or speaker or another media player on another PC, there is nothing wrong with that. Expectation is what the game maker tells the player, and if they do, that's totally expected. [ And it doesn't effect zune at all, which is the only device supported media function; xbox360 didn't have this in CTP days. ]

And I don't think the console player can effect the remote media player on network; they should have different decoders.

Nick Gravelyn:

sectionboy:

Edit: I just found out there is no constructors for MediaQueue class in 3.0beta, now you totally lost me! Why do you still keep it in xna then?! I can't construct one, nor can I refer to its members 'cause they are non-static. Great!

They keep it in there so the framework can use it.

Then hide it, make it private.

http://connect.microsoft.com/ - add the request and link to this thread.

Does seem odd that something changed from the CTP to the beta - maybe its not an API that worked well or wasn't suported byt all 3 platforms or something.

sectionboy:

Nick Gravelyn:

sectionboy:

Edit: I just found out there is no constructors for MediaQueue class in 3.0beta, now you totally lost me! Why do you still keep it in xna then?! I can't construct one, nor can I refer to its members 'cause they are non-static. Great!

They keep it in there so the framework can use it.

Then hide it, make it private.

They can't. It's exposed via the MediaPlayer.Queue public property. Therefore the class has to be public.

sectionboy:

If you're playing with your console, you surely expect some thing happen to the devices it connects to. You move the joystick, the sprite on your TV might move; you push a button, it shouldn't be surprising if the speaker makes a noise. Of course, the player knows what's gonna happen, let it be TV or speaker or another media player on another PC, there is nothing wrong with that. Expectation is what the game maker tells the player, and if they do, that's totally expected.

Right. It's one thing if it's your in-game music. But since I should have the ability to play my music (and not yours), I don't expect your game to be able to hijack my music experience and start moving around in my song. Since the MediaPlayer that you use in the framework is the same as Windows Media Player and (eventually) the media functionality of the Guide, I can see exactly why they don't want games doing this. Most users listening to their own music would be extremely annoyed if a game suddenly starts moving around the play position. I often mute game volume and play my own music on top. I know I would be in the camp of angry people if the game started messing with that.

[ And it doesn't effect zune at all, which is the only device supported media function; xbox360 didn't have this in CTP days. ]

Correct. However it was always the plan to add the Media stuff to both Windows and Xbox 360. So when they added those they also had to weigh in consumer expectations. I'm personally surprised it was ever a setable property (since the consumer experience is just as big of an issue on Zune which is a device primarily intended to play music).

And I don't think the console player can effect the remote media player on network; they should have different decoders.

Not really sure what you mean there.

But also remember I could be totally wrong about the motives here. This is just my guess and reasoning assuming I were in charge of such decisions. I would favor the user's right to enjoy their music over the developer's privilege to move around the play position of the media player.

Nick Gravelyn:

I would favor the user's right to enjoy their music over the developer's privilege to move around the play position of the media player

 

Fair enough, but it does seem like a shame that the API functionality is being reduced due to the worry that programmers may use it in ways that the end user may object to (if that is indeed the reason). As an end user, I'd prefer the developers were given as much flexibility as possible to write me the best software possible, and if I didn't like the way they did it I would stop using the software. I will vote for this on connect if someone files it.

Roonda:

As an end user, I'd prefer the developers were given as much flexibility as possible to write me the best software possible, and if I didn't like the way they did it I would stop using the software.

That's you as a developer thinking as a consumer ;). It's really flawed to expect anyone on these boards (or any development board) to truly think like a consumer (myself included) since we are all the developers using the framework. Sure some of the consumers want us developers to have all the flexibility in the world. But there are plenty out there who just want a fun game and don't care what it takes. They don't care what framework we used or anything like that. Plus they won't know that we lost the feature since they'll never have known it was an option. ;)

Let's also not forget how many teams have to come in on these features. It's not just the XNA team calling the shots. They have the Xbox 360 team who likely have a say in what the framework can do on their platform, the Games For Windows LIVE team, the Zune team, possibly the Windows Media Player team, possibly XBLA team, and maybe even others that all get some say in the framework since it directly affects their products. It's a gigantic political jumble that may also play into framework decisions.

Hopefully one of the guys on the team is allowed to discuss this and does so in the next few days so that we can have the official say on things.

Alright, now I see they moved MediaQueue under MediaPlayer as one of its properties, should have noticed. Thank you for pointing that out.

Then again, I can't agree with you about the "user expectation" issue. I can see your point about user's right to enjoy the music, but if you are playing a game or running a program, it should be expected the game has the control over the background music, and it still does in deed: game can still play, pause, stop, skip forward, backward, control the volumn, in other words, game can still mess up with your music "experience" easily, if that's what the developer wants. What's the point of only taking away ff and rw function?

 

And I don't think the console player can effect the remote media player on network; they should have different decoders.

Not really sure what you mean there.

I thought you were talking about playing the songs stored on xbox360 or pc over network. Never mind.

sectionboy:

I can see your point about user's right to enjoy the music, but if you are playing a game or running a program, it should be expected the game has the control over the background music, and it still does in deed: game can still play, pause, stop, skip forward, backward, control the volumn, in other words, game can still mess up with your music "experience" easily, if that's what the developer wants. What's the point of only taking away ff and rw function?

Those are good points I hadn't considered. There are indeed other ways to mess with the experience so it seems that can't possibly be the (only) reason.

So perhaps ZMan is closer to it with the idea that it might not have been as easy to accomplish on Xbox 360 or Windows. Or, as briefly touched on in my last post, it could simply be a political thing based on requirements from one or more of the other Microsoft teams that have some input on the framework. At this point I guess we'll just have to hope we get an official answer or, if we don't, file it on Connect and deal with the limitation for the time being.

Nick Gravelyn:

Roonda:

As an end user, I'd prefer the developers were given as much flexibility as possible to write me the best software possible, and if I didn't like the way they did it I would stop using the software.

That's you as a developer thinking as a consumer ;). It's really flawed to expect anyone on these boards (or any development board) to truly think like a consumer (myself included) since we are all the developers on the framework. Sure some of them want us to have all the flexibility in the world. But there are plenty out there who just want a fun game and don't care what it takes. They don't care what framework we used or anything like that. Plus they won't know that we lost the feature since they'll never have known it was an option. ;)

That's ture. But it really depends on your guys -- platform holders, framework builders, tool makers -- to develop the most flexible framework possible. You don't just take away a feature for no reason. Remember, in this sense, you are a servant to two masters, gamer and developer.

Let's also not forget how many teams have to come in on these features. It's not just the XNA team calling the shots. They have the Xbox 360 team who likely have a say in what the framework can do on their platform, the Games For Windows LIVE team, the Zune team, possibly the Windows Media Player team, possibly XBLA team, and maybe even others that all get some say in the framework since it directly affects their products. It's a gigantic political jumble that may also play into framework decisions.

Hopefully one of the guys on the team is allowed to discuss this and does so in the next few days so that we can have the official say on things.

OK, I take my last sentance back. You guys are servants to hydra -- just too many heads. :)

 

Oops. I made a typo in that post you quoted. I meant to say "developers using the framework" not "developers on the framework". I don't work on the team and want to make sure nobody gets the wrong impression from my posts. I'm going to go ahead and edit that fix in now...

ZMan nailed it. We tried very hard to avoid any breaking changes after the Zune CTP but in some cases that was not possible. When we started implementing the media APIs on Xbox we realized that enabling play position setter for that platform was not possible. We implement the framework media APIs over the native Xbox Media Player API which currently doesn't provide any way to do this.    

So it is not coming back. Thank you for clarifying that :(

Doesn't sound likely for 3.0. But as I said earlier if its an important feature for your scenario then add a request to connect for future versions. The more intfo youcan provide for your scenario the better.

[ Somebody from the team answered my suggestion on Connect MS, "by design", then it was closed when I was typing a rely to that. I am just gonna post it here.]

Me: Thanks for the answer. I can understand the team wants to keep xna consistant cross three platforms, but on the other side, zune doesn't get the 3d graphics either, so xna isn't 100% consistant, nor it needs to be. Not all platform created equal. I know I am just arguing for the zune developers here, and it might be too late for 3.0, but it's a critical function if someone wants to make a music game, like audiosurf, which I think fits zune perfectly, huge media lib, simple input, not gpu/cpu intensive.  Please consider this in future release. Thank you.

Sometimes Connect isn't the greatest tool in resolving issues. I closed the feedback 'by design' as the tool we use to interact with Connect doesn't have many options. The implementation provided in the Beta is indeed by design. We did take your feedback though and I added an item into our internal DB so it can be considered in a future release. Sorry if I wasn't clear in Connect.