Hi, I've got a few comments/requests as a user :) 1. Is there some way to have the 'cursor' move with the current playing track ? (ie when it changes song, look if the cursor was highlighting the previous song and move it to the next song) This way the info-window displays the current song at all times, if once selected. 2. Can I support multiple music directories and/or temporary music directories (like USB storage or CD/DVDs) ? What I would like is to be able to specify multiple locations and have pytone manage each of these. And when a location suddenly gets unmounted/remounted, have it act upon that. 3. I noticed that when starting pytone it starts to eagerly rescan all the files in such a way that my system cannot keep up with it and it influences the interactivity with the ncurses interface (seems not to respond) and playback is being interrupted several times because of this. (I already increased the buffer because of this and that helped, still...) 4. ctrl-enter does not seem to work as advertized, it behaves exactly like Enter. I have to first add a song and then press 'n' if I want to play a song of my own choice immediately. Thanks for listening :) -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Hi Dag, On 10.05.05, Dag Wieers wrote:
I've got a few comments/requests as a user :)
1. Is there some way to have the 'cursor' move with the current playing track ? (ie when it changes song, look if the cursor was highlighting the previous song and move it to the next song) This way the info-window displays the current song at all times, if once selected.
No, this does not currently work and actually I don't like this idea too much. Suppose you were editing the playlist and then a new song comes and all of a sudden the cursor moves.
2. Can I support multiple music directories and/or temporary music directories (like USB storage or CD/DVDs) ? What I would like is to be able to specify multiple locations and have pytone manage each of these. And when a location suddenly gets unmounted/remounted, have it act upon that.
PyTone supports more than one music directory (just add multiple [database.*] sections in the config file). But this support is currently static in the sense that you cannot add/remove databases when PyTone is running. However, you can at any time request a rescanning of the database by selecting the database and pressing 'u'.
3. I noticed that when starting pytone it starts to eagerly rescan all the files in such a way that my system cannot keep up with it and it influences the interactivity with the ncurses interface (seems not to respond) and playback is being interrupted several times because of this. (I already increased the buffer because of this and that helped, still...)
I would say "eagerly" is not the right word. I tried to make it no eager at all, but I have to say that tuning this thing is not really easy and I'm also not too happy with the current situation.
4. ctrl-enter does not seem to work as advertized, it behaves exactly like Enter. I have to first add a song and then press 'n' if I want to play a song of my own choice immediately.
You're meaning alt-enter, I suppose. You're right, there seems to be a small bug. I'll fix that in the next version. Thanks for the feedback, Jörg
On Wed, 11 May 2005, Joerg Lehmann wrote:
On 10.05.05, Dag Wieers wrote:
I've got a few comments/requests as a user :)
1. Is there some way to have the 'cursor' move with the current playing track ? (ie when it changes song, look if the cursor was highlighting the previous song and move it to the next song) This way the info-window displays the current song at all times, if once selected.
No, this does not currently work and actually I don't like this idea too much. Suppose you were editing the playlist and then a new song comes and all of a sudden the cursor moves.
Fair enough. Still when you're not editing (which is what I'm doing more than 99% of the time), the info window is useless as it shows the cursor position while I'm more interested to see the information of the currently playing song. Maybe there's some more clever way to achieve the same thing.
2. Can I support multiple music directories and/or temporary music directories (like USB storage or CD/DVDs) ? What I would like is to be able to specify multiple locations and have pytone manage each of these. And when a location suddenly gets unmounted/remounted, have it act upon that.
PyTone supports more than one music directory (just add multiple [database.*] sections in the config file). But this support is currently static in the sense that you cannot add/remove databases when PyTone is running. However, you can at any time request a rescanning of the database by selecting the database and pressing 'u'.
Interesting, I must say the default config file is a bit overwhelming because of the sheer volume of comments :) I wonder if we can trim it a bit. I've trimmed mine a bit (the first few sections) and attached it for review. It gets rid of some of the redundancy, is a bit more consistent. What I would like to change (still) is to provide different sections that work by themselves (instead of giving alternatives inside the same section). It's easier if you can go over the self-explained examples. Also I would prepend comments with a triple hash, so that you can comment out configuration options with a single hash. Makes it more readable and easier to skim for something. ... 5. I would also prefer to rename /etc/pytonerc into /etc/pytone.conf and have a per user configuration file in ~/.pytone/pytone.conf that either overrides the default or extends the default. That way I do not have to be root to change the configuration :) 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]
Hi Dag, On 11.05.05, Dag Wieers wrote:
On Wed, 11 May 2005, Joerg Lehmann wrote:
On 10.05.05, Dag Wieers wrote:
I've got a few comments/requests as a user :)
1. Is there some way to have the 'cursor' move with the current playing track ? (ie when it changes song, look if the cursor was highlighting the previous song and move it to the next song) This way the info-window displays the current song at all times, if once selected.
No, this does not currently work and actually I don't like this idea too much. Suppose you were editing the playlist and then a new song comes and all of a sudden the cursor moves.
Fair enough. Still when you're not editing (which is what I'm doing more than 99% of the time), the info window is useless as it shows the cursor position while I'm more interested to see the information of the currently playing song. Maybe there's some more clever way to achieve the same thing.
Actually, one could make the contents of the info window switchable between the currently selected item, the song currently being played on the first player, and (if configured) the same info for the second player.
2. Can I support multiple music directories and/or temporary music directories (like USB storage or CD/DVDs) ? What I would like is to be able to specify multiple locations and have pytone manage each of these. And when a location suddenly gets unmounted/remounted, have it act upon that.
PyTone supports more than one music directory (just add multiple [database.*] sections in the config file). But this support is currently static in the sense that you cannot add/remove databases when PyTone is running. However, you can at any time request a rescanning of the database by selecting the database and pressing 'u'.
Interesting, I must say the default config file is a bit overwhelming because of the sheer volume of comments :) I wonder if we can trim it a bit.
I know, but the idea was to use this a form of documentation. But certainly, one could do this better.
I've trimmed mine a bit (the first few sections) and attached it for review. It gets rid of some of the redundancy, is a bit more consistent.
I like it.
What I would like to change (still) is to provide different sections that work by themselves (instead of giving alternatives inside the same section). It's easier if you can go over the self-explained examples.
If you could do that, I would really appreciate the help.
Also I would prepend comments with a triple hash, so that you can comment out configuration options with a single hash. Makes it more readable and easier to skim for something.
Looks nicer and is more practicable.
5. I would also prefer to rename /etc/pytonerc into /etc/pytone.conf and have a per user configuration file in ~/.pytone/pytone.conf that either overrides the default or extends the default.
Ok, the pytonerc name comes from vimrc :) But rc vs .conf doesn't matter too much, does it? Concerning the system wide and user configuration: that's exactly how it works currently: /etc/pytonerc stores the system-wide configuration which can be overridden by the user in ~/.pytone/pytonerc. Jörg
5. I would also prefer to rename /etc/pytonerc into /etc/pytone.conf and have a per user configuration file in ~/.pytone/pytone.conf that either overrides the default or extends the default.
Ok, the pytonerc name comes from vimrc :) But rc vs .conf doesn't matter too much, does it? Concerning the system wide and user configuration: that's exactly how it works currently: /etc/pytonerc stores the system-wide configuration which can be overridden by the user in ~/.pytone/pytonerc.
Not to mention the -c command linne option lets you use whatever config file you choose. -- Richard A. Smith
On Thu, 12 May 2005, Joerg Lehmann wrote:
On 11.05.05, Dag Wieers wrote:
On Wed, 11 May 2005, Joerg Lehmann wrote:
Fair enough. Still when you're not editing (which is what I'm doing more than 99% of the time), the info window is useless as it shows the cursor position while I'm more interested to see the information of the currently playing song. Maybe there's some more clever way to achieve the same thing.
Actually, one could make the contents of the info window switchable between the currently selected item, the song currently being played on the first player, and (if configured) the same info for the second player.
Interesting, I didn't find how to do that. I'll look for it.
What I would like to change (still) is to provide different sections that work by themselves (instead of giving alternatives inside the same section). It's easier if you can go over the self-explained examples.
If you could do that, I would really appreciate the help.
Ok, in that case I will revise the file completely and send it later.
5. I would also prefer to rename /etc/pytonerc into /etc/pytone.conf and have a per user configuration file in ~/.pytone/pytone.conf that either overrides the default or extends the default.
Ok, the pytonerc name comes from vimrc :) But rc vs .conf doesn't matter too much, does it? Concerning the system wide and user configuration: that's exactly how it works currently: /etc/pytonerc stores the system-wide configuration which can be overridden by the user in ~/.pytone/pytonerc.
Unfortunately I noticed that yesterday evening from the code :) Looks good. Disregard the comment :) -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Thu, 12 May 2005 17:10:53 +0200 Joerg Lehmann <joerg@luga.de> wrote:
On 11.05.05, Dag Wieers wrote:
Fair enough. Still when you're not editing (which is what I'm doing more than 99% of the time), the info window is useless as it shows the cursor position while I'm more interested to see the information of the currently playing song. Maybe there's some more clever way to achieve the same thing.
Actually, one could make the contents of the info window switchable between the currently selected item, the song currently being played on the first player, and (if configured) the same info for the second player.
How about two info windows? One left, showing always details of the selected song, and one right, showing always details of the currently playing song. That would make the screen completely symmetric, too :-) Uwe
Hi Udo, On 14.05.05, U. Bielz wrote:
On Thu, 12 May 2005 17:10:53 +0200 Joerg Lehmann <joerg@luga.de> wrote:
On 11.05.05, Dag Wieers wrote:
Fair enough. Still when you're not editing (which is what I'm doing more than 99% of the time), the info window is useless as it shows the cursor position while I'm more interested to see the information of the currently playing song. Maybe there's some more clever way to achieve the same thing.
Actually, one could make the contents of the info window switchable between the currently selected item, the song currently being played on the first player, and (if configured) the same info for the second player.
How about two info windows? One left, showing always details of the selected song, and one right, showing always details of the currently playing song.
My goal was always to have as much space as possible for the database window, because that's what people use most of the time.
That would make the screen completely symmetric, too :-)
While as physicist, I have a strong sympathy for symmetries, I still prefer to keep the symmetry-broken layout we have now. :-) Btw, have you ever tried the one-column layout (just press F10)? Jörg
Hi, On 17.05.05, Joerg Lehmann wrote:
Hi Udo,
s/Udo/Uwe/ Sorry! Jörg
On 14.05.05, U. Bielz wrote:
On Thu, 12 May 2005 17:10:53 +0200 Joerg Lehmann <joerg@luga.de> wrote:
On 11.05.05, Dag Wieers wrote:
Fair enough. Still when you're not editing (which is what I'm doing more than 99% of the time), the info window is useless as it shows the cursor position while I'm more interested to see the information of the currently playing song. Maybe there's some more clever way to achieve the same thing.
Actually, one could make the contents of the info window switchable between the currently selected item, the song currently being played on the first player, and (if configured) the same info for the second player.
How about two info windows? One left, showing always details of the selected song, and one right, showing always details of the currently playing song.
My goal was always to have as much space as possible for the database window, because that's what people use most of the time.
That would make the screen completely symmetric, too :-)
While as physicist, I have a strong sympathy for symmetries, I still prefer to keep the symmetry-broken layout we have now. :-) Btw, have you ever tried the one-column layout (just press F10)?
Jörg
On Tue, 17 May 2005 23:37:01 +0200 Joerg Lehmann <joerg@luga.de> wrote:
Hi,
On 17.05.05, Joerg Lehmann wrote:
Hi Udo,
s/Udo/Uwe/
Sorry!
Nix passiert :-)
While as physicist, I have a strong sympathy for symmetries, I still prefer to keep the symmetry-broken layout we have now. :-) Btw, have you ever tried the one-column layout (just press F10)?
Wait - yes. The result is a traceback (see below). This happens only when I'm using pytone in a xterm. In a console, F10 works perfectly. But I prefer the two column mode despite the missing symmetry. Traceback (most recent call last): File "/usr/share/pytone/pytone.py", line 265, in ? m.run() File "/usr/share/pytone/mainscreen.py", line 125, in run self.channel.process() File "/usr/share/pytone/hub.py", line 167, in process handler(item) File "/usr/share/pytone/mainscreen.py", line 326, in keypressed self.resizeterminal() File "/usr/share/pytone/mainscreen.py", line 284, in resizeterminal self.connectborders() File "/usr/share/pytone/mainscreen.py", line 256, in connectborders win.update() File "/usr/share/pytone/playlistwin.py", line 197, in update self.updatescrollbar() File "/usr/share/pytone/playlistwin.py", line 62, in updatescrollbar self.drawscrollbar(self.playlist.top, len(self.playlist)) File "/usr/share/pytone/window.py", line 243, in drawscrollbar self.vline(3, xpos, curses.ACS_CKBOARD, self.ih-4, self.colors.scrollbar) File "/usr/share/pytone/window.py", line 117, in vline self.win.vline(x, y, c, n, attr) error: wmove() returned ERR I'm using PyTone 2.2.2 on Debian Sarge. Uwe
Hi Uwe, On 19.05.05, U. Bielz wrote: [...]
Wait - yes. The result is a traceback (see below). This happens only when I'm using pytone in a xterm. In a console, F10 works perfectly. But I prefer the two column mode despite the missing symmetry.
Traceback (most recent call last): File "/usr/share/pytone/pytone.py", line 265, in ? m.run() File "/usr/share/pytone/mainscreen.py", line 125, in run self.channel.process() File "/usr/share/pytone/hub.py", line 167, in process handler(item) File "/usr/share/pytone/mainscreen.py", line 326, in keypressed self.resizeterminal() File "/usr/share/pytone/mainscreen.py", line 284, in resizeterminal self.connectborders() File "/usr/share/pytone/mainscreen.py", line 256, in connectborders win.update() File "/usr/share/pytone/playlistwin.py", line 197, in update self.updatescrollbar() File "/usr/share/pytone/playlistwin.py", line 62, in updatescrollbar self.drawscrollbar(self.playlist.top, len(self.playlist)) File "/usr/share/pytone/window.py", line 243, in drawscrollbar self.vline(3, xpos, curses.ACS_CKBOARD, self.ih-4, self.colors.scrollbar) File "/usr/share/pytone/window.py", line 117, in vline self.win.vline(x, y, c, n, attr) error: wmove() returned ERR
That's most probably due to the xterm window being too small. I've added some lower limits in the code, which at least prevents the crash. Jörg
On Tue, 17 May 2005, Joerg Lehmann wrote:
On 14.05.05, U. Bielz wrote:
That would make the screen completely symmetric, too :-)
While as physicist, I have a strong sympathy for symmetries, I still prefer to keep the symmetry-broken layout we have now. :-) Btw, have you ever tried the one-column layout (just press F10)?
The one-column layout is especially nice when you want a tall terminal, like: xterm -fn 6x10 -geometry 40x30 -e pytone With the fixes to allow even smaller dimensions 30x30 is nicer. -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Teilnehmer (4)
-
Dag Wieers -
Joerg Lehmann -
Richard Smith -
U. Bielz