Is build 68 the last hurrah before a new final?

[Roj]

Are we down to the wire here at last?

[Paul]

Depends what I want the next release to be. My original plan was that we are far from the next release.

[acozz]

I think there should be one more build to fix bugs then a release so that skinners can update their skins with the new resizability without having to have their own webspace and also so people can stop requesting resizable playlists.

[Tokelil]

My original plan was that we are far from the next release.Hmm I kind of like that... Though some kind of feature to show the skins for the beta versions would be good!

[Roj]

Depends what I want the next release to be. My original plan was that we are far from the next release.
Could you give us a thumbnail overview of what that plan is? I'm very curious and anticipatory.

Personally, I'd just take 4.11 with a resizable playlist and be happy; the fixes for the crossfade plugin are also welcome. I'm not very demanding at this point - 4.11 almost reached my happy place. The additional features iterated above would pretty much do it for me, especially if they were accompanied with a fully fledged ASIO plugin (hint hint, Shaohao :) ).

[brian]

The additional features iterated above would pretty much do it for me, especially if they were accompanied with a fully fledged ASIO plugin (hint hint, Shaohao :) ).
I have the impression from other threads that Shao Hao doesn't think he can do much more with the ASIO plugin.

[Rex_Mundi_Incarnit]

I'd really, really like xtra support for visualisations. Somehow i think that with a little tinkering the visualisations can run much faster. The vis windows could use an update as well. In the end, perhaps some new visuals would be nice too (but thats probably not Paul's job).

[Roj]

I have the impression from other threads that Shao Hao doesn't think he can do much more with the ASIO plugin.
Ah - I had not realized.

OK then.

[brian]

Yes, it's a pity, but there it is. In any event we need to bear in mind that Shao Hao doesn't create QCD input and playback plugins from scratch, he `merely'(!) adapts existing Winamp plugins. His last post on the subject intimated that he plans a Winamp playback plugins manager for QCD, which he hopes will get round some of the issues with his present ASIO plugin for QCD. Of course it would be better if he spoke on his own behalf here; I may have got it wrong.

[acozz]

He's stated that he doesn't have an ASIO capable sound card and thus can't test anything himself. But I think he got around that somehow.

[Roj]

Yes, it's a pity, but there it is. In any event we need to bear in mind that Shao Hao doesn't create QCD input and playback plugins from scratch, he `merely'(!) adapts existing Winamp plugins. His last post on the subject intimated that he plans a Winamp playback plugins manager for QCD, which he hopes will get round some of the issues with his present ASIO plugin for QCD. Of course it would be better if he spoke on his own behalf here; I may have got it wrong.
From what I understand, he's a HUGELY busy guy which doesn't surprise me given his talents. I'm just grateful he sees fit to grace us with them.

[plover]

Somehow i think that with a little tinkering the visualisations can run much faster.

Many visuals can run faster than they do. The Retro visuals that I've looked at run at 25 frames/sec, and I set MeterzPak to the same (I don't know about the visuals included with the QCD install). I assume that when the Retro Vis Pack was first released 25 f/s was a good speed for the low end machines of the time or something as the QCD vis api supports up to 100 f/s. There is currently nothing in the vis api that would allow for a variable frame rate set through the player -- any given vis has to implement this itself (which I may do for a later version of MeterzPak). If you have a compiler it would be very easy to recompile the Retro Vis Pack with a higher frame rate. I suppose I could make a higher frame rate versions available of MeterzPak and Retro Vis Pack if people want this.

[Rex_Mundi_Incarnit]

Most vis on my machine when running at 320*200*16, i get 15 fps. For the very simple ones just above 20fps. That is very slow compared to some of the winamp vis. that i can run at 1024*768*16 like milkdrop at 30fps. Is it just the fault of my 550 mhz P3 machine? Does each vis simply require a faster machine to run, at what you say, 25 fps?

[ace2701]

Most vis on my machine when running at 320*200*16, i get 15 fps. For the very simple ones just above 20fps. That is very slow compared to some of the winamp vis. that i can run at 1024*768*16 like milkdrop at 30fps. Is it just the fault of my 550 mhz P3 machine? Does each vis simply require a faster machine to run, at what you say, 25 fps?
At work, we have a 300 mhz running NT at 1024x768 true color. At home , I have a 773 mhz running W98SE at 1024x768 true color. Both systems give me very smooth visuals. While I haven't checked the framerate, or used detatched or full screen vis, I'm very satisfied with the look.

[#The fREaK!]

Most vis on my machine when running at 320*200*16, i get 15 fps. For the very simple ones just above 20fps. That is very slow compared to some of the winamp vis. that i can run at 1024*768*16 like milkdrop at 30fps. Is it just the fault of my 550 mhz P3 machine? Does each vis simply require a faster machine to run, at what you say, 25 fps?

What vis priority are you using? If its low, try increasing it.

[Rex_Mundi_Incarnit]

What vis priority are you using? If its low, try increasing it.

nope, doesn't help. My computer only becomes non-responsive. ACE2701, at what resolution do you play the vis in full screen? I'd like to know, cause otherwise my computer must be total crap :(

[ace2701]

nope, doesn't help. My computer only becomes non-responsive. ACE2701, at what resolution do you play the vis in full screen? I'd like to know, cause otherwise my computer must be total crap :(
Sorry.. don't ever use full screen. I'm one of the few that takes pleasure in looking at and enjoying the entire skin, including the vis.

[plover]

Most vis on my machine when running at 320*200*16, i get 15 fps. For the very simple ones just above 20fps. That is very slow compared to some of the winamp vis. that i can run at 1024*768*16 like milkdrop at 30fps. Is it just the fault of my 550 mhz P3 machine? Does each vis simply require a faster machine to run, at what you say, 25 fps?
I'm referring only to the native QCD vis. If you are talking about Sonique vis run through the adapter plugin, what I said may not mean much. I don't know the Sonique api and don't know whether it is especially inefficient or not, or what slowdown might be introduced by the translation through the adapter plugin.

FWIW, on my machine (AMD 2100+), Rabbit Hole (1.1) runs just fine at 1280*1024*24, but SpaceThing (2.3) gets about 5 fps at that resolution. In a 640*480 window, SpaceThing gets about 20 fps (75% CPU), and in the Phaseless skin vis window (150*200 ?), it gets 60 fps (25% CPU)

[MrZebra]

Is there any chance that the default skin's timer font get reverted to what it was in 4.11? The new b66+ font look too pixelated.

[Rex_Mundi_Incarnit]

FWIW, on my machine (AMD 2100+), Rabbit Hole (1.1) runs just fine at 1280*1024*24, but SpaceThing (2.3) gets about 5 fps at that resolution. In a 640*480 window, SpaceThing gets about 20 fps (75% CPU), and in the Phaseless skin vis window (150*200 ?), it gets 60 fps (25% CPU)

I get for rabbit hole @ 320*200*32, 20fps @ 80% CPU usage. So in fullscreen @16bps it may be a little higher. Anyway, it means i cant raise the resolution any higher or the thing becomes too slow. :( BTW i find that Sonique vis run faster on my system than most QCD native ones (esp the ones that come with the installer). That's partly why i originally raised this discussion

[Hanzo]

I've never been able to run QCD's visuals without the player blinking out in front of visuals when using Sonique's or the default visuals.

It seems that the animation from the title, track position and current track in the playlist somehow mess with the full screen mode. If anyone has played Quake III Arena and somebody sends you a message via MSN you know what it kinda looks like. All your FPS drop to the floor no matter how powerful your video card is.

It doesn't matters much, but maybe there is something to fix it... :D

[plover]

I get for rabbit hole @ 320*200*32, 20fps @ 80% CPU usage. So in fullscreen @16bps it may be a little higher. Anyway, it means i cant raise the resolution any higher or the thing becomes too slow. :( BTW i find that Sonique vis run faster on my system than most QCD native ones (esp the ones that come with the installer). That's partly why i originally raised this discussion
Hmm... I'm getting really low framerates for those vis too. (Heh... I just found the framerate counter ... I was reporting on SpaceThing before as it has its own counter... ;) ) We may need Paul to tell us what the framerate counter is actually based on as I'm getting rates of over 80 fps for MeterzPak which I know is programmed to go at 25 fps. Perhaps the rate shown by QCD is based on how long it takes to draw a frame and thus shows how many frames could be drawn rather than how many frames are drawn. (Although I'm not at all sure how the rate that's shown relates to CPU usage.)

I know that Paul is dissatisfied with the vis api, but I don't know whether the inefficiency we're seeing has more to do with the api or with the actual plugins. MeterzPak is not a very good example as what it draws is so simple.

I just tried a test which seems to indicate that the inefficiency is probably in the plugin code.
I ran the Resonatorz module of the Retro Vis Pack in a 600*800 window and got a rating of 20 fps at 80% CPU.
I then ran my Pyrometerz vis (which has a similar degree of complexity) in the same window and got a rating of 60 fps at 30% CPU.
I'll have to go back and look at the source code for these. Pyrometerz was one of the first vis that I wrote and, I think I based the code pretty closely on Resonatorz. I have no idea what I could have done to cause such a large performance difference.

[J44xm]

Regarding the titular question ... no, apparently not. ;)

[Matt]

Is there any chance that the default skin's timer font get reverted to what it was in 4.11? The new b66+ font look too pixelated.

i have changed the timer font in b69. I agree it wasn't right in b66. I think the new one is a better suited font.

[MrZebra]

i have changed the timer font in b69. I agree it wasn't right in b66. I think the new one is a better suited font.
Thanks. I still prefered the way it was in 4.11 but the one in b69 is an improvement over b66/67/68.

[Roj]

Thanks. I still prefered the way it was in 4.11 but the one in b69 is an improvement over b66/67/68.So with B69 can we get an interim final???

Huh huh huh????

[Paul]

My guess is that the next release will be around B80.

[Tokelil]

My guess is that the next release will be around B80.
:D Some nice things must be in store for us!! :cool:

Why are people so hooked on releases anyway? Most people in the forum use development builds anyway!

[Paul]

Sometimes I feel I want to do a release asap to get the new skinning features out, but there is much more I want to do (not just with skinning) that I think it will be worth the wait. And besides, the new skinning features are still being flushed out, new capabilities are being discovered by those pushing its limits. Things are definitely still in beta form.

[Roj]

:D Some nice things must be in store for us!! :cool:

Why are people so hooked on releases anyway? Most people in the forum use development builds anyway!Not me - I *never* do dev builds of anything.

[Roj]

My guess is that the next release will be around B80.
Guess I'll hang in with nice, stable 4.11 until then. :)

[Rex_Mundi_Incarnit]

Guess I'll hang in with nice, stable 4.11 until then. :)

The latest dev build is pretty stable on my pc. I had a couple of crashes, i changed some settings in various plugins and it no longer crashes. ;)

btw, will the next version be called QCD 5? Or QCD 4.something? Does it depend on the number of changes made in the next version?

[#The fREaK!]

It would be quite strange to change from 4.11 to 5 without atleast 10 times the changes there are currently from 4.11, so I dont think Paul would do that. I think it will be 4.2.

[MrZebra]

I always run the latest dev build at home, downgrade to the previous one if something major is wrong with it.

At work, I usually only run release versions, I'm still with 4.11 at work. I only install dev builds at work if I really want to use one of it's new features AND after testing it at home first.

One suggestion for Paul, in the Version History you could put a list of the changes being worked on for the next version. Like create a section for Build 70 and list all the things that are planned for it and mark them when they are done. So we can follow progress. Just a suggestion really.