Hi folks I am planning on recording audio, and later play it back, for on of my projects. The requirement is that it should be c++ ( Visual studio 2008 ) compatible. Rest of our application is mostly in silverlight/ VC++. I have worked with NAudio before in C#, but nothing on vc++.
I would like to know what is best suited for my needs :
VC++ (Visual studio 2008) 32 bit compatible.
Only need to record/playback. No fancy functionalities needed.
Only 32 bit windows 7/vista targeted. Multi-platform functionality is unnecessary.
Need a quickfix code. Doesn't matter if things are slow, requires extra computation power, etc. As long as it doesn't crash, and does what it should properly, I am good.
is free ( at least for research).
Can you suggest something that would be best for me ? Thank you in advance!
Probably the easiest way is using MCI. Basically, you can use mciSendCommand (or mciSendString) to send an MCI_RECORD command to do recording, or an MCI_PLAY to do playback.
Related
I'm quite new to programming, I'm in my first year of my programming; CS1B.
I'm making a text adventure game in Visual Studio 2015, I want to use two sounds, like music in the background and a sound effect.
But whenever I try to do so, the first sound stops when the second sound starts. I'm using the PlaySound() function to do my sounds. I know about FMOD and DirectSound but I don't really know how to set it up.
I tried looking through how to do this, but the stuff I find is really hard for me to follow. Any help will be good. Thanks.
You can separate your sounds into SFX and music (which uses the music system). This way, you can control your background music separately (as well as make use of their music-specific features) from your sound effect events.
In general, you need to have a separate event/sound instance for each of the sound you are playing. If you only have one, it could get 'stolen' and this might be the most possible reason for your problem. It could also be because of your channels.
I am not sure if you are using FMOD Studio or FMOD Designer/FMOD Ex, though, so it really depends on which one you are using. In any case, if you are just starting, I recommend reading up on the FMOD Event System - Best Practices For Programmers
documentation which you can get from the Internet, as well as the FMOD Ex Programmer's API documentation (you will have to have an account to download this, but it's worth it.)
Good luck.
PlaySound only has a single 'voice' to work with, so it can't play more than one sound at a time.
To play more than one sound at a time requires a real-time mixer, so you need to use something else: XAudio2, FMOD, Wwise, MSS, OpenAL, etc.
DirectSound is deprecated and hasn't been updated since 2000. It still exists for BackCompat but has a number of restrictions and other subtle legacy behaviors. The only reason anyone should still be using DirectSound at all is if they are targeting Windows XP.
If you are using C++, you should look at DirectX Tool Kit for Audio which is a simple C++ wrapper for XAudio2.
I would guess simple multithreading would do:
#include <thread>
...
thread playsound(&playsound, this, <other params>);
playsound.detach();
thread othersound(&playsound, this, <other params>);
othersound.detach();
Good luck
In C++ compiled with Visual Studio 2008 or 2010, am looking for a way to play a note on an instrument and then be able to change the pitch of that note (i.e. from a C to a D), its volume, and even the instrument that plays it in a program.
I know this sounds a lot like MIDI, but I'm not sure how to accomplish it. I would be fine or even prefer using a 3rd party program such as CSound, but again don't know how and cannot figure it out.
Thanks in advance for your help!
Edit: Using CSound is easy, but how do I control CSound through Visual Studio?
You need a C++ music synthesizer framework, such as:
CLAM: http://clam-project.org/index.html
STK: https://ccrma.stanford.edu/software/stk/
SuperCollider: http://supercollider.sourceforge.net/
nsound: http://nsound.sourceforge.net/ (maybe the easiest)
playback through soundcard is possible with (I think) all of them.
I am using Windows 7 and developing a chat-like application with Visual Studio 2010. I am looking for an EASY way of capturing audio from a microphone (or rather, from the default recording device), collect the buffer from said input, and send it over a socket. I've seen DirectX solutions recommended, but from my research that is quite the opposite of simple. 5000 lines of sample code for a simple capture/save file program? That simply doesn't work for me (and yes, that was an official sample provided with the SDK).
Anyway, I don't need it to be cross-platform, and I would really prefer something that already comes with Windows, though I don't mind installing a library as long as it doesn't take longer than writing the hardware drivers from scratch to figure it out (exaggeration). I've heard of this waveInOpen function, but oddly enough I cannot find any demos on how to use it. If anyone has an idea or a link to some sample code, I would greatly appreciate it. Thanks everyone for your time!
P.S. I can figure out the networking part myself. I just need access to the raw audio data buffer.
If you're doing the sockets yourself try checking out:
http://www.techmind.org/wave/
http://www.bcbjournal.com/articles/vol2/9810/Low-level_wave_audio__part_3.htm
http://www.relisoft.com/freeware/recorder.html
I enjoyed all of them but the last one, but then again, you might find it far more helpful.
I want to develop native c++ windows application using windows API.
but i find it being difficult because i am unable to render the window and drag and drop components, change the location etc..
How can i view, drag and drop components like i can do in C# ?
May be there is no way to do. if so, what is the fastest procedure to design the application ?
If you like so much the drag and drop of components (and of course for good reason) why would you need to develop it using C++? You can use PInvoke if you need to call some C++ functions from C# code that are not in the .net framework.
But if you really insist, maybe you could try QT.
Using a library framework such as Qt is really the way you want to go. It makes things very simple and still allows you to write code in std c++ to keep most things very fast.
If you EVER have intentions of porting the code to a different platform than windows (whether it be Mac, Linux or even Android ... yes its possible), qt is definately the way you're going to want to go.
I can get an app up and running... smoothly in a few minutes using Qt but much longer and with more confusion using MFC.
Dragging and dropping 'widgets' to form a gui is very easy and possible with Qt's built-in QtDesigner!!! Check it out!!!
http://qt.nokia.com/downloads
Assuming you are using Visual Studio, if your app can be implemented as a dialog box, then you can use the dialog editor to lay things out. Otherwise, you just have to write code to create the windows and place controls. Look at the MFC examples included with Visual Studio.
Jeff Prosise's PROGRAMMING WINDOWS WITH MFC was one of the better books for learning how to do this, but I think it is out of print, and so could be hard to find.
Charles Petzold's PROGRAMMING WINDOWS is the bible for the Win32 API. Again, may be hard to find these days.
If MFC isn't your cup of tea, you could also look at QT, GTK+, or wxWidgets. There are GUI builders for each of those, but they are all pretty primitive compared to what you can do with C#.
As far as I know there is no ide out there that will let you "drag and drop create" standard win api windows like you would with C#.
Personally for that kind of application I always recommend Borland C++ Builder (Which is now Codegear Rad studio)
Although it is not standard API, it allows you to drag an drop and static linking is very easy, so you dont have to worry about redistributables
I just wondering about this.It is said that .NET is better than MFC in a lot of aspects.But when I use my PEID to recursive scan my 'program files' directory,it turns out there are still a lot of programs written with 'Visual C++ 6'(esp. for security software),whose GUI should be written with MFC.
So my questions are:
Is MFC still the dominating framework
for windows desktop aplication?
What frameworks do IE,firefox,Microsoft office(or other famouse desktop applications,if you'd like to list some) use?
What frameworks do the desktop applications(e.g. explorer,card games) of Windows itself use?
thanks.
I say windows forms and WCF are pretty widespread. C#/VB.NET are well-entrenched in corporate america.
IE is COM-based.
Office is MFC/COM.
Windows Apps are usually native code to demo the platform.
For new projects I don't think MFC is the dominant platform, but mostly because newer platforms shield developers from the idiosyncrasies of Win32 and MFC itself and allow for faster development. MFC applications take longer to develop but are, imo, unmatched in responsiveness.
I will not deny that some parts of the platform are irrelevant in 2010 (for example CArchive and most of the Doc/View foundation); on top of that, the dwindling availability of 3rd party components (mostly GUI) is a bit worrisome. FP1/MFCNext was a step in the right direction, I'm anxious to learn about the new MFC functionality in VS 2010.
For optimal integration with the OS, imo C++/MFC is still the best choice because of the nature of C++ as low-level and the fact that Win32 is still the foundation of Windows and that it can most easily be accessed in C or C++.
By the way, I had to write code to change screen resolution and found that C# could only handle detecting screen resolution but not changing it.
To change resolution you had to do a lot of Interop gobbldygook which I tried but was too complex because the Win32 APIs to do that had too many old style arguments.
So, instead I wrote a quick MFC DLL that accessed Win32 API directly and wrapped all the calls to Win32 in a simple API. Then I did an interop call to my simple API in an MFC User dll.
Everything worked fine.
So, there's still no substitute for Win32 API. That has the ultimate power, and you have full access to it via MFC. So, yes MFC is still relevant and so is ATL and so is direct Win32 all of which I'm forced to use from time to time.
So, you may get 90 percent of your work done with .NET, but you have to go under the covers for a few things. Also, I've done a lot of Qt, and would never use it for quick jobs that are windows only. Qt also has become prohibitively expensive if you're doing anything commercial and also it is very very bloated. It's libraries take up gigabytes.