Forums Feature Suggestions Improved splay functionality

1) Panning sound. The ability to generate seemingly directional sound would be useful.
2) Simultaneous audio streams. Even just two sounds playing simultaneously would be handy.

Now, I haven't fiddled with the Windows API too much, so I'm unaware as to the feasability of simultaneous streaming in just Windows, but in the event that it is, I believe it would be rather beneficial for a more.. "immersive" experience.

I'm aware there are .dlls that allow you to control third-party software such as Winamp, however that requires an additional .dll, and the person to have the program installed that it makes use of. It just gets very hideous. Granted a large number of people use Winamp, but even so.

Just figured I'd put in my two bits. Sorry if this has been requested before, I couldn't find it using search.

As a note, you may be thinking that what I'm talking about sounds more for a game than a chat program, and I suppose you have me there. I'm currently in the process of scripting a rough engine for mIRC; though how it will turn out, who knows.

seeing as how mIRC doesn't handle sounds, adding those would require actually adding the sound capability also. mIRC is a CHAT PROGRAM ppl, not your personal media player. If you want sound capabilities, use winamp/WMPlayer/RelPlayer/<Insert favorite player>.

Er, what? It plays sounds just fine, via the /splay command. Hence the reason this is titled "Improved splay functionality".

And considering the scripting functionality and extensibility with .dlls, I think mIRC can hardly be called "just a chat program" anymore. With the creation of custom MP3 players, games, network capable projects, plotting programs, and various other graphical and textual projects all created using mIRC script, it hardly is only used for chatting purposes.

At least, that's the reason I've stuck with it for five years.. the flexibility and extensibility through the ability to access .dlls has given life to mIRC which other IRC clients don't necessarily have.

Aside from which, I'm only asking for an improvement of a function already provided; not an entirely new tangent direction.

[Addendum]
And as I said, I was scripting a graphical engine for mIRC; hardly trying to create "my own personal media player", which I believe there are .dlls for in the event that I did want to. Hence why mIRC is such a great product, because it CAN do those things, even if they are "worthless" because they stray from the original use of mIRC. But what can be called worthwhile if it cannot grow beyond what it is?

I believe the point KT was making is that mIRC itself doesnt have a built in mp3 player, it only sends the /splay command to windows to deal with

Technically it does since /splay can handle the MP3 format fine, but yes, I get the point.

[Edit]
Of course assuming you have the codecs to support the MP3 format, which I believe the later versions of Windows come with some form of it.

Granted, I can imagine simultaneous streams being unfeasible with just the Windows API, but I'm fairly certain pan control is available, without any extensions such as DirectX. Which would quite suffice for many purposes. I don't have my manuals on hand, and I have a fairly decrepit version of the MSDN on hand, so I can't quite guarantee the panning working, but still, it's a thought.

actually it is quite possible for mirc to handle several sounds using splay. not currently. mirc creates the alias name mIRC with mci to play the sound. it could simply create mIRC1 mIRC2 etc..

this owuld mean you would have to update the indentifiers to determine wich sound your reffering too. Altho mirc is a CHAT program it has other uses besides playing an mp3. I use sounds for events such as joining a channel etc.. send 2 splays causes the first one to stop and play the second

If your interested in doing this now mci.dll can do it for you

If you want quick transition between music files, you can check mci.dll that gives you a little more control than mIRC provides.

I use it to load the next audio file in advance, and start playing it once the current song ends. This DLL is lacking the feature of notifying you when the music ends, so I have to work around it by stealing mIRC's MCI aliases (mircsong, mircwave, mircmidi) and using the "on *end" events to detect when my songs end.

I don't think you'll like this method, because it's too cluttered and can be frustrating sometimes, but if you want, see an example script here.

Really? Hadn't seen that one. I'll have to take a look at it. While panning would be more useful at the moment, multiple sound streams is of course a plus.

Thanks.

And as a little token of my gratitude, here's a screenshot of a line format to a terrain generated by the engine, in mIRC. Using a .dll of course, but hey. It's spiffy. Heh. Still some bugs though, but I'm working on it. And the low fps is because it's in lines mode; it can easily get 50fps when filled.

GEX Terrain

32,513 vertices for 16,256 polygons.

Is it possible to play two files simultaneously with mci.dll?

Dunno, but that's what I gathered from Naruse's post, so I suppose I'll find out once I download and try out the .dll, heh.

Here I'm getting a "MMSYSTEM320" error when I try to. Btw make sure you didn't miss my other post above ^^

yes you can play sounds simultaneously. Each sound must have a unigue alias name however. If im not mistaken there was a way to use MCI with notify. I dont have it any more so i cant look it up.

As for panning im not certain if mci has it by default by there certainly is a command to adjust balance. perhaps using a timer and a quick smart alias you can simulate it. I dont hink it would handle multi speaker setups such as dolby surround just a simple left-right right-left panning.

Oh of course. I'm just working on a simple, functional engine, not trying to make breaking state-of-the-art, heh.

I think that would tax poor mIRC to its limits. Graphics, a basic AI, networking, and Dolby sound.. I hear a pitiful wail from inside my computer.

actually using DX the functionality wouldnt be soo taxing. mIRC would simply make the method call. Sadly MCI lacks this.

Ah, no no no. That's not what I meant, heh. I meant trying to emulate Dolby surround in mIRC script. Though I think a DirectX .dll would be rather complex, as compared to say, OpenGL. True, DirectX is a bit faster, but eesh, it's painful in its complication.

If the current method of playing sounds has no scope for improvement, Perhaps /splay could be improved by using something else. Perhaps something along the lines of BASS or FMOD. I'll leave it to the developers imagination.

Oh there is plenty room for improvement, though I agree on some level with KingTomato, no need to go overboard. It's still a chat with spiffy appendages at its core. But a couple extra controls and functions for an already existing process can't hurt too much I don't imagine.