The following patch adds play speed controls to pytone. Diffed from svn but should apply and work for any recient version of PyTone. 'f' plays faster 's' plays slower 'd' resets to the original speed. Each key press should adjust the speed ~1%. These of course change the pitch as well. -- Richard A. Smith
Hi Richard, thanks for the patch! Before commenting on it, I have to admit that I'm not yet fully convinced whether this feature is something really useful for a general audience. So it would be nice to get some support from other people. On the other hand, the implementation is clean and not intrusive, so I'm not too reluctant to apply the patch. Here my comments: On 12.08.05, Richard Smith wrote:
The following patch adds play speed controls to pytone. Diffed from svn but should apply and work for any recient version of PyTone.
'f' plays faster 's' plays slower 'd' resets to the original speed.
These default key bindings look a bit dangerous to me. Couldn't we use a combination like [, ] and ^ (other suggestions would be welcome, too). Concerning the implemenation: Index: trunk/src/services/players/internal.py =================================================================== --- trunk/src/services/players/internal.py (revision 28) +++ trunk/src/services/players/internal.py (working copy) @@ -355,7 +355,16 @@ song = self.songs[0] song.seekrelative(seconds) self.audiodev.flush() + + def _playerplayfaster(self): + self.songs[0].playfaster() + + def _playerplayslower(self): + self.songs[0].playslower() + def _playerspeedreset(self): + self.songs[0].resetplayspeed() + Here, you have to checks whether self.songs is non-empty, otherwise this raises an exception when no song is being played. Jörg
On Fri, 12 Aug 2005, Joerg Lehmann wrote:
thanks for the patch! Before commenting on it, I have to admit that I'm not yet fully convinced whether this feature is something really useful for a general audience. So it would be nice to get some support from other people. On the other hand, the implementation is clean and not intrusive, so I'm not too reluctant to apply the patch.
Here my comments:
On 12.08.05, Richard Smith wrote:
The following patch adds play speed controls to pytone. Diffed from svn but should apply and work for any recient version of PyTone.
'f' plays faster 's' plays slower 'd' resets to the original speed.
These default key bindings look a bit dangerous to me. Couldn't we use a combination like [, ] and ^ (other suggestions would be welcome, too).
We could put this in a seperate pop-up window, much like the volume, but that you have to bring up first and then use the (, ) and a reset key ? Saving the [, ] keys for something more important when it comes along. I would like to have this included, even if only as a gimmick :) Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On 12.08.05, Dag Wieers wrote: [ snip ]
On 12.08.05, Richard Smith wrote:
The following patch adds play speed controls to pytone. Diffed from svn but should apply and work for any recient version of PyTone.
'f' plays faster 's' plays slower 'd' resets to the original speed.
These default key bindings look a bit dangerous to me. Couldn't we use a combination like [, ] and ^ (other suggestions would be welcome, too).
We could put this in a seperate pop-up window, much like the volume, but that you have to bring up first and then use the (, ) and a reset key ?
Would be an alternative, but this requires some coding.
Saving the [, ] keys for something more important when it comes along.
Actually, we could also use {, } which requires using a modifier even on a US keyboard and is obscure enough to be not too useful for something important, isn't it?
I would like to have this included, even if only as a gimmick :)
Yep. Jörg
thanks for the patch! Before commenting on it, I have to admit that I'm not yet fully convinced whether this feature is something really useful
It's probably not. But its kinda neat. I was quite surprised when I figured out how easy adding it was going to be. Few players have this ability. Out of all the stuff I've done to PyTone this was the simplest change so I figured it was a good place to start. An exercise in getting the svn tree and doing the diffs.
These default key bindings look a bit dangerous to me. Couldn't we use a combination like [, ] and ^ (other suggestions would be welcome, too).
Use whatever key bindings you guys wish. I picked these since they made sense to me. Remember that I don't use the curses UI. I have a QT front end. Well most of a QT front end. *grin*
Here, you have to checks whether self.songs is non-empty, otherwise this raises an exception when no song is being played.
Ahh. Ok. I'll add that in. The next patch I'd like to try and submit is the one that groups all of the curses UI files into a UI/curses directory. Allowing for multiple front ends. I think you mentioned previously that you liked that Idea? I think it has merit. You have created what I think is a really good player framework. Breaking out the UI stuff into its own allows for others to extend the UI section into things native for their environment. -- Richard A. Smith
Hi Richard! On 12.08.05, Richard Smith wrote:
thanks for the patch! Before commenting on it, I have to admit that I'm not yet fully convinced whether this feature is something really useful
It's probably not. But its kinda neat. I was quite surprised when I figured out how easy adding it was going to be. Few players have this ability.
That's true, I was as well :) So let's add it.
Out of all the stuff I've done to PyTone this was the simplest change so I figured it was a good place to start. An exercise in getting the svn tree and doing the diffs.
These default key bindings look a bit dangerous to me. Couldn't we use a combination like [, ] and ^ (other suggestions would be welcome, too).
Use whatever key bindings you guys wish. I picked these since they made sense to me. Remember that I don't use the curses UI. I have a QT front end. Well most of a QT front end. *grin*
Here, you have to checks whether self.songs is non-empty, otherwise this raises an exception when no song is being played.
Ahh. Ok. I'll add that in.
Fine. Just send me a revised patch. Btw, one thing that was missing was the changes to conf/pytonerc. Could you do this as well, please.
The next patch I'd like to try and submit is the one that groups all of the curses UI files into a UI/curses directory. Allowing for multiple front ends. I think you mentioned previously that you liked that Idea?
Yes, and I still do, although initially this means that there is only going to be a curses directory.
I think it has merit. You have created what I think is a really good player framework. Breaking out the UI stuff into its own allows for others to extend the UI section into things native for their environment.
Definitely. Jörg
Fine. Just send me a revised patch. Btw, one thing that was missing was the changes to conf/pytonerc. Could you do this as well, please.
Sure. I removed them. I didn't think they were necessary since it defaults to those keys. So in the config file you want examples of all the config options even if just to the defaults? I'll rework the patch this weekend.
Yes, and I still do, although initially this means that there is only going to be a curses directory.
Ok. I'll get both patches fixed up this weekend then. Is there any interest from others on the list in a KDE front end? My dancebox frontend is quite different and straight pyQT but I might be persuaded to mess with the pyKDE bindings as well and model up a copy of the curses interface in KDE. A starting point for someone else to work with perhaps? -- Richard A. Smith
Hi Richard! sorry for the delay, I was offline during the weekend. On 12.08.05, Richard Smith wrote:
Fine. Just send me a revised patch. Btw, one thing that was missing was the changes to conf/pytonerc. Could you do this as well, please.
Sure. I removed them. I didn't think they were necessary since it defaults to those keys.
So in the config file you want examples of all the config options even if just to the defaults?
Yes, I always keep them in the standard config file, just as a (very primitive) means of documentation.
I'll rework the patch this weekend.
Yes, and I still do, although initially this means that there is only going to be a curses directory.
Ok. I'll get both patches fixed up this weekend then.
Is there any interest from others on the list in a KDE front end?
My dancebox frontend is quite different and straight pyQT but I might be persuaded to mess with the pyKDE bindings as well and model up a copy of the curses interface in KDE.
How difficult would this be? Jörg
On 8/15/05, Joerg Lehmann <joerg@luga.de> wrote:
sorry for the delay, I was offline during the weekend.
No prob. I ended up not getting much done (code wise) this weekend anyway.
My dancebox frontend is quite different and straight pyQT but I might be persuaded to mess with the pyKDE bindings as well and model up a copy of the curses interface in KDE.
How difficult would this be?
Shouldn't be too difficult. pyKDE has controls (I think) for most everthing you had to create in curses. I've actually not messed with pyKDE yet but judging from pyQT it should be pretty easy. I chose to do things the hardway with pyQT. Some of the UI things I wanted to do didn't work well with a pre-defined UI so my developemet has been slower while hand create and learn the QT way of doing things. Of course it helps when you actually _work_ on code as well. Which I've not done a lot of for the past month. -- Richard A. Smith
Here, you have to checks whether self.songs is non-empty, otherwise this raises an exception when no song is being played.
Ahh. Ok. I'll add that in.
Fine. Just send me a revised patch. Btw, one thing that was missing was the changes to conf/pytonerc. Could you do this as well, please.
Ok I fixed up things and added the check for songs > 0 and the config file entries into pytonerc Did you guys ever decide on what keybindings you want by default? Again I don't care. Tell me what keys you want default and I'll send it in. -- Richard A. Smith
Ok I fixed up things and added the check for songs > 0 and the config file entries into pytonerc
Hmmm... seems I'm not done yet. If you try to do a ? help things crash in helpwin. From the traceback it looks like I don't have a description right somewhere. What have I missed? -- Richard A. Smith
Hi Richard! On 22.08.05, Richard Smith wrote:
Ok I fixed up things and added the check for songs > 0 and the config file entries into pytonerc
Hmmm... seems I'm not done yet. If you try to do a ? help things crash in helpwin. From the traceback it looks like I don't have a description right somewhere.
Yes, you have to add the description in src/help.py, more specifically under the "general" key of the descriptions hash. Concerning the key bindings: My suggestion would be {, ~ and }, but maybe somebody else has a better idea. Jörg
Yes, you have to add the description in src/help.py, more specifically under the "general" key of the descriptions hash.
Thanks. That fixed it.
Concerning the key bindings: My suggestion would be {, ~ and }, but maybe somebody else has a better idea.
Ok. I'll set it to those. -- Richard A. Smith
Teilnehmer (3)
-
Dag Wieers -
Joerg Lehmann -
Richard Smith