Hopefully I'm posting this in the most appropriate place. I'm not sure if Barna's still around or what, but here goes anyway....

First off, this vis plugin is a must have for sure. Secondly, as great as it is, there's one thing I don't like about it - the "No Album Cover" image. I'm no graphic artist myself, but come on! I think even I could have done a better job than that. The image I wish was there, is a large picture of the xmplay icon I've seen floating around here. That's kind of a no-brainer if you ask me.

So if you're listening Barna, I beg you to please help me out here. And thanks for such a useful, and practical plugin.

Just to make sure, I did a simple test - converted a file to True Audio (tta) format, for which I have a plugin that plays back that format properly (already tested it) and I have it selected in the "Integration" settings (as I do for most all of the formats I use, with the exception of video mp4, wmv and very few others as well). Window's Explorer recognizes and displays the tta file as an xmplay file with the program's icon.  And just as I thought, when I go to open the file with "XMplay-able" selected by default, the file does not appear in Explorer's "Open file(s)" dialog window. The file I originally encoded, which happened to be an mp4 file does appear, but the tta file is nowhere to be found. As I stated before, the only way I can access the file is by typing in *.tta in the "Filename:", selecting "All files" at the bottom of a long list of formats, or searching through a long list to try and find "The True Audio (tta)". And it's not just that specific plugin or format. This happens to me again and again. I just tried the exact same thing again only with opus instead of tta, with the exact same results. Even if this is a bug (fixing it would be great), but I still think sorting the list of formats would be a good idea too. I was gonna tell you that my list of formats is fairly long, but then I decided - hey, why not count how many are in the list? So I did, and I have 165 entries in the list (not the total number of formats, but how many entries there are). It's a long list to scroll through to find one entry. And I have more plugins sitting around that I have yet to add to the list. An alphabetically arranged list would make it a whole lot easier to look at. I'm sorry, I forgot to mention that yes all the plugins show up in the Plugins "Input and archive plugins" list as well. One other thing, when I do select the file format from the list (tta, opus, or whatever) then the file shows up - like it should. Seems kinda obvious, but the point is that the plugins work, xmplay recognizes them and plays them properly.

Ok, here's another one of my ideas:

I have a lot of input plugins. So many in fact, that when I go to open a specific file-type it's almost impossible to find it in the list of formats. By default xmplay shows "XMPlay-able" (which I think are the formats it handles all on it's own without any extra plugins). The problem with that is, it's a small amount of formats in comparison to the huge amount it can actually load using plugins. So even though it can load a file using a plugin, it doesn't display that file using the default "XMPlay-able". To solve this, you could either type in "*" for the Filename (and hit "Enter") or select "All files" (which is at the bottom of the list after all the plugins - so you have to scroll and scroll some more to get to it) from the list - but then that doesn't even work... because you end up displaying any and every file type out there (images, etc...) instead of just the ones it can actually load with the plugins. So there's that issue... but what I meant to suggest was for the "Files of type:" list of plugins to be alphabetically sorted. This alone would make it far easier to find a specific file-type. As is it is now, it's a garbled mess of formats all over the place, and nearly impossible to find what you're looking for.

Saga:
Sadly, I'm even less familiar with Python than I am with DOS. That being said, I do have Python installed - since some program somewhere apparently needed it. I downloaded the oggscissors.py script and opened it in Python, but the oggscissor website says pyogg and pyvorbis libraries are required. However the link to download those files is dead. When I run it, it says the module ogg.vorbis is missing.

Jimmy Neutron:
I do have very basic knowledge about some of the DOS commands (cd, dir, exit) but that's about it. Just enough to see what's where, but I'm always afraid I'll mistype something and end up formatting my hard drive

Ian:
I was able to successfully merge the opus files in DOS with your help. It's not the most convenient way of doing it, but it does work - and it saves me from having to download the files first as mp3's.

If anyone else has any other ideas, I'd be happy to hear what they are.

Excuse my ignorance, but those commands would be done in DOS? I don't know a lot about DOS, so I wasn't aware you could append/merge files like that. Thanks for the info. Too bad it can't be done directly in xmplay though - cause the real advantage was that I didn't have to actually download the files as mp3's which take up a lot more space, but I could stream a large file and encode it to a much smaller file (as I already mentioned). This would hold true even moreso, when dealing with multiple files. I've only begun to look into radio broadcasts on the net, and I've already come across one with as many as 6 parts (files). I don't know how big each file was, but if I have to download all the mp3's before I can merge them as one file, then the amount of disk space being used can really begin to add up when compared with streaming and encoding all at the same time.

That makes me wonder. I know mp3 files can be edited to no end, but what about opus? Could they be merged together in the same way? I know it's a new format so there are probably few if any editors out there, but all I'd need is to be able to join them into one file.

It isn't until recently that I've found some radio broadcasts that I've wanted to listen to, and realized that xmplay can not only stream them, but encode it down to a file. In the past I would just download the audio file from the net and then play it back in xmplay. Problem was that the audio would be an mp3 and would take up a bit of space to download it, even though it was only recorded in radio (speech) quality. A few days back it dawned on me that I could stream it through xmplay and encode it to opus format at 8 kbps and still get about the same quality, but with a file 1/4 of the size of the mp3. For instance I downloaded a 3 hour broadcast that was originally 40+ MB as an mp3, but encoded it down to an opus file taking up only 10+ MB.

So here's what I'm thinking... some broadcasts I've found are split into mutiple files. I could either do what I've been doing and end up with multiple files for a single broadcast, or I could download them as mp3's and then try and merge (without re-encoding) them together in an audio editor... and then finally re-encode the one combined mp3 file to an opus file using xmplay. To me that seems like a lot of work. I was wondering if there could be a feature added to xmplay (or if it's already there and I just don't know it) that would let you stream & encode multiple files (from a playlist of urls) down to a single joined file, instead of writing out separate files.

My inspiration was VST audio panels, synthesizers audio interfaces...

You've piqued my interest. VST synths have some of the best interfaces out there.

Edit: I guess I should wait for the whole page to load next time - that way I'll actually see the screenshots

Oh, so only newer or revised skins will be able to use this feature then. I guess that stands to reason. The test skin appears to work ok on my system.

I'm not sure I completely understand. Am I supposed to edit a skin or the ini file to make this work? As it is, I don't see the vis in the main window (Win98SE).

I don't think it's wrong that you want to help improve the program, but I think you are going about it the wrong way. I think skinning the options window is a good idea, but it's not up to you to do it. If Ian says "Go ahead and do it", then fine - go for it. But to think you can just do whatever you want with his program, is not ok... and I'm not the only one saying it. I've got nothing more to say on this subject.

Tails_ I think you're missing Dotpitch's point. PSXGamerPro1 is trying to hack xmplay to do all these other things, and maybe he can do a couple things by hacking it, but the person who the made the program (Ian) can do anything he wants with his program. So why not ask him, when he's willing to hear our suggestions? I know if it was me, I wouldn't want someone messing around with my program without asking me. PSXGamerPro1 is acting like it's his program. Where's the respect? If you want something changed, I suggest you do like the rest of us - ASK.

I would also be interested in having a medium-size version... if you're bored have nothing to do

Now this is something I wouldn't mind. Actually I was thinking about it just the other day, and wondering why at least the options window isn't skinned... since it's a fairly significant part of the program's interface. It would be really cool if it could be left open like the other panels, so it felt more like the rest of the interface. But to make those kinds of changes would require some serious work. Not only that, none of the current skins would have the options window matching their skin.

I like the idea, but it would have been better if it was there from the start. You could always make a default skin for all the skins out there now - the most sensible look would be the default blue interface xmplay uses. I know you're just dying to hack this program in some way, but I think Ian would be the one best able to make these changes, assuming he deems them worthwhile.

Regarding the device list sorting, there are default device mappers (eg. "Microsoft Sound Mapper" and "DirectSound - Primary Sound Driver") that ought to come before the real devices. While XMPlay could force "Microsoft Sound Mapper" to come before the other sorted WaveOut devices (as it enumerates them itself), it can't do the same for DirectSound devices (as they're enumerated by the DirectSound plugin). So I'm not sure auto-sorting the device list will be possible.

Thanks for the update Ian. Sorting a list may seem like a minor detail, but it's these kind of things that help make a great program even better. As for the device list, I'm not sure what the difficulty is. I'm not claiming to be an expert by any means, but I don't see how the order in which things are loaded or used by the program has to be associated with the order in which they are then displayed. Can't you just store the items in an array (in the original unsorted state), sort them, and then add them to the list? In other words use an array as a go-between, and disassociate the "list" control from whatever order they are loaded in by the program. If I'm way off base here... feel free to correct me.

Have you ever heard of the term "Cease and Desist"?

.. the dashed squares are the only ones that look right to me. ..

fair enough (I mean that's a good enough reason for me)
Also, I'm glad others are coming up with names, cause I suck at it - lol

Looking back at this thread, I can see 2 suggestions from you. I'm not very familiar with Winamp vis, but as far as I was aware, they require their own window (so can't be displayed in XMPlay's info window). Have you seen something different elsewhere? Regarding the device/encoder sorting, I'll look into that for the next update.

Thanks for the info. I can't really say that I've seen any other programs that show winamp visuals embedded in the interface, but I thought maybe it was possible. I have a little bit of programming ability, and I know for instance that a program like mplayer (video player app), can have it's video output redirected to another window. I was hoping winamp might work the same way. But yeah, I was more commenting on my other suggestion about the encoder/device sorting. I figured it wouldn't be a difficult thing to adjust in the program, so thanks for looking into it.

Ian if you are listening, I was just wondering if you go through all the suggestions here when looking to add new features... or if some of them are perhaps lost in all the posts under this thread. The only reason I'm asking is, I made what I thought was a useful request/suggestion a while ago now, but didn't get any kind of response. I've waited a while (realizing you are busy with other things), but then when I see almost instantaneous responses to other new posts in separate threads - it makes me think you didn't even see my post. In the future, would it be better for me to post my ideas in a separate, more visible thread... or are you just taking time to go through everything that has already been posted here?

Thanks. Was thinking the same thing about the text buttons. .... *been thinking about a close button on the extended window. It could be put on the left side similar to how the auto-size button is done on the right, or put it in place of the auto-size button and move that one to the left side. (will have to try it)*

I like your idea to have the close button on the right side, and then put the auto-size on the left. Also I thought of one other thing. It would probably be a good idea to differentiate the images used (on the main window) to open the EQ panel and the Playlist panel - rather than having the same image for both... and make them more recognizable as to what their functions are.

Me again... I just tried the update, and I think the changes you made are for the better. The big version is too big for my liking so I'll be sticking with the smaller one. My only other suggestion would be to short-form all the names (general, sample) instead of just msg and vis. Either that, or use small case (instead of all capitals) or a smaller font for the type - so the whole word will fit. That way it's more consistent. Other than that, it looks good.