next »

[Synetech]

The next time it happens, I will.  This one is unfortunately one of those bugs that isn't reproducible at will - the worst kind.

I know, intermittent bugs are horrible! 

[Synetech]

NEW BUG

This may not be a bug at all, in which case I'll move this to the requests thread.

Setting the vis rendering restriction doesn't just restrict the rending resolution, it also restricts the physical size of the vis window.

For example:

1) enable vis rendering restriction to say, 100x100
2) display the vis window
3) resize the vis window to 500x500 (the window changes size but the resolution stays at 100x100 scaled up to 500x500)

so far so good

4) hide/close the vis window
5) display the vis window -> the vis window is now 100x100 instead of 500x500

Now go back to step 3 and size the window to 50x50 and repeat to the end, you'll see that the vis window remains at 50x50.

This only comes into play when you size the vis window to BIGGER than the rendering resolution.

Like I said, this may not be a bug, or it may just be a limitation, either way, it would be nice if we could get the window to stay at the size we set and have the rendering at the resolution we set regardless of the relationship between the two.

[magisterofmayhem]

magisterofmayhem, it sounds like it could be a lag due to displaying the little popup bubble that shows the current volume.  I find that certain programs/windows cause the info bubble to draw slower than normal and this results in lags in changing volume or seeking.  Closing the window then allows the bubble to draw normall and there is no more lag.

Is the info bubble updated normally for you or is it slow?

the info bubble is updated normally for me. it's always in the right spot and showing the right volume number. i'm not sure if i made it clear, but there's no lag with the volume NORMALLY or with the seeking whatsoever, it's only when dropping the volume to 0 that it takes a while to unmute. i'll move the volume slider from 0 to 10, the volume popup will instantly say 10, but it will take 1 second before i hear anything. if my sound card buffer is set to 2 seconds, i'll hear sound 2 seconds later. however if going from a volume of, say, 5 to a volume of 100, the response is instant.

[Ian @ un4seen]

Like I said, this may not be a bug, or it may just be a limitation, either way, it would be nice if we could get the window to stay at the size we set and have the rendering at the resolution we set regardless of the relationship between the two.

It's more of a limitation than a bug. XMPlay retains the info window dimensions and the vis rendering dimensions - it doesn't also keep a "vis window dimensions" (which would be identical to "vis rendering dimensions" when not restricted). When switching to the vis window with auto-resize enabled, it'll resize to the vis rendering dimensions, which will be restricted if so chosen.

i'm not sure if i made it clear, but there's no lag with the volume NORMALLY or with the seeking whatsoever, it's only when dropping the volume to 0 that it takes a while to unmute. i'll move the volume slider from 0 to 10, the volume popup will instantly say 10, but it will take 1 second before i hear anything. if my sound card buffer is set to 2 seconds, i'll hear sound 2 seconds later. however if going from a volume of, say, 5 to a volume of 100, the response is instant.

This is because volume changes are applied directly to the outbut buffer. If the volume is 0, then the buffer is full of 0s, and increasing the volume will have no effect on that (0 * anything = 0).

[piovrauz]

I don't  think it is really a bug, but:

When I listen to this stream "http://24.30.208.51:8000/", using the "wav writer - normalize", stream is write on disk but individual songs aren't splitted.

I think songs shall be splitted cause when I listen with normal output tracks have the right name at the right instant, so there must right info in the stream.

Only want to know if it is XMPlay related or not, thanks.

PiovrauZ

[Bistzack]

When I increase or decrease the volume using keyboard and while XMPlay is buffering some song (URL or module) I get crash. I uploaded Dr Watson log (xmpbuff.zip).

[Ian @ un4seen]

I don't  think it is really a bug, but:

When I listen to this stream "http://24.30.208.51:8000/", using the "wav writer - normalize", stream is write on disk but individual songs aren't splitted.

I think songs shall be splitted cause when I listen with normal output tracks have the right name at the right instant, so there must right info in the stream.

Only want to know if it is XMPlay related or not, thanks.

The file/track splitting only applies when writing the original stream to disk, via the "Write to disk" option.

When I increase or decrease the volume using keyboard and while XMPlay is buffering some song (URL or module) I get crash. I uploaded Dr Watson log (xmpbuff.zip).

Should be sorted in .7 (now on the XMPlay page).