Although I know how to create a VST plugin today, I still don't understand the GUI part of it.
I've been playing around with Steinbergs samples and what I can see is that they are using some default sliders in the exapmles, but am I supposed to use these when designing my own and apply some graphics to them? Or should I create my own completly? How should I think around the GUI approach to make the GUI code also work for both PC and MAC later on?
I've been searching my rearbehind off but can't find anything about these questions anywhere. Please give my a lead or guide me to the light so I can grow my hair back.
How should I think around the GUI approach to make the GUI code also
work for both PC and MAC later on?
If that is your ultimate goal, then I strongly suggest you check out the JUCE library. The plugin wrappers are very good and it is completely cross-platform.
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
I made little sound generator in C# 4.0 using DirectSound.
I would like to mute all other sounds. I want only my application to be able to emit sounds.
How to do it?
I know how to pInvoke so you can give me unmanaged code.
Properly designed programs either stop playing back sound when their main window becomes deactivated. Or use IDirectSound::SetCooperativeLevel() so they play nice with other programs that want to be heard.
You are asking how to make a improperly designed program behave nicely. With a bit of a hint that you don't contemplate being nice yourself. Teaching that uncooperative program a lesson is simple, run its uninstaller. Avoid being the victim of that same advice.
I'm implementing a GUI program (a cards game) in gtkmm (at the moment). I want that my program runs well at least under Windows and Linux (GTK). Mac OS X would be a plus, although not required. Although I'm using gtkmm, I have some concerns with it.
More concretely:
Lack of support for connecting signals at runtime.
The API for treeview is horrible in the sense that you need to make your own classes
in c++ code every tie you have a new Treemodel.
These two things get a lot in my way when implementing GUI code. My questions are, if I switch to wxwidgets:
1.- Is it possible to connect signals at runtime?
2.- Is the ListCtrl API from Wxwidgets comfortable to use in your opinion?
3.- Is there a decent gui builder (preferably free, but not required) in which I don't have to connect signals by hand in c++ code? This is quite important to keep controller and view code separated.
4.- Is there an alternative to wxwidgets which is better and looks good under gtkmm, besides working on Windows. I'd rather not use qt with its preprocessing step
Thanks in advance.
It is possible.
ListCtrl if just fine to use, and you will maybe find some nicer alternative (UltimateListCtrl, wxGrid...).
wxFormBuilder.
Not that I know of.
Yes, I hate Objective-c, plus my project will be portable, so I'd like to code as much of it in C++ as possible, ideally 100%.
So I have a regular C++ project made with Xcode, and want to open some OpenGL windows.
edit: Damn, Glut takes over the app's control with glutMainLoop() and I'll like to have more control over the loop.
Will try freeglut, although I can't find OSX binaries, and I always have such bad luck trying to compile someone else's code.
Update:
I tried yet again to link to SDL 1.3 and this time I could get it to work! yoo-hoo!
I always wanted to work with SDL, but using more than one window was mandatory, and that's a feature of version 1.3 which is under development and I never could get it working.
As it is portable to a zillion OSes, and handles 2D graphics as well as OpenGL I'm going with it. Thanks to all!
If you don't want to use objective-c you're going to have to use either the deprecated carbon libraries, X11, or another library like GLUT to create the window. If portability is a concern either go the GLUT route, or you'll need to write your own window management code for each platform you want to support.
If you don't go the GLUT route you will need to write window management code fore each operating system so I strongly suggest you bite the bullet and write the window management in objective-c++. The only thing you really need to know is that a pointer is always a pointer no matter which language it is in, so just store objective-c ids as void* and cast them back to ids, it actually works out pretty easy.
i guess NeHe tutorials could help;
GLUT works fine for your stated purpose, although you will probably wish for a nice C++ wrapper for it. I ended up hacking my own, and although GLUT isn't friendly to wrapping, it was doable.
EDIT: Since you have a problem with glutMainLoop(), you may be trying to do more than GLUT was designed to do -- it is mainly intended for hacks, one-off projects and opengl demos. And freeglut doesn't compile OOB on the mac, at least that was my experience.
For a portable, fuller featured app, Qt may be the way to go for you. Otherwise, design your C++ for portability and use a thin GUI layer on each platform. If getting something running on each platform is most important, go for the former. If the best user experience on each platform is most important, go for the latter. You may find that "thin" is not the most descriptive term for what is involved.
I found this demo to be useful for getting a simple Cocoa/OpenGL window working, even though the code has a number of ridiculous bugs: http://developer.apple.com/library/mac/#samplecode/CocoaGL/Introduction/Intro.html
This question has been asked over 3 years ago, yet remain quite fresh. I just recently went through similar exercise for planning school curriculum, and trying to figure out what's the best portable library to work with on Mac/Windows/Linux/mobile with OpenGL projects. Perhaps my notes will help someone make a decision. I only mention the main options that I've considered.
Higher level APIs, for window management plus additional goodies, like sprites, fonts, sounds, event handling, etc:
SFML and github repo: nice&tidy, C++, object oriented library that integrates with OpenGL natively. Portability for managing windows and OpenGL 3.3 contexts out of the box on MacOS, Win and Linux. Mobile support provided in the 2.2 branch (github).
SDL2: all major platforms, including mobile, supported. The OpenGL context needs to be manually managed somewhat, so use of GLEW for example comes really handy (see below). A bit lower level than SFML.
Lower level APIs, mostly for window and OpenGL context management:
GLWF: This is pretty much a GLUT replacement for modern OpenGL. Rather low level, but portable across: Win, OSX, Lin. In active development.
GLEW: I only mention it for completness. It doesn't manage windows, but helps managing OpenGL contexts and you might use it together with GLWF or SDL for example.
Others:
Freeglut: Open source continuation of GLUT. Suitable for small demo projects. I have not used it myself, but seen good docs and demo code. In active development.
GLUT: old one, discontinued. Legacy demos and code around the net.
I'm looking for a window... ugh... thing for OpenGL, I've been using SDL but more recently found that its not quite up to my needs in at least any code I've seen. I'd like to find some GUI library that allows me to develop using OpenGL (and SDL if at all possible) with a menu bar, possibly options at the side, and a working-out-of-the-box close button. Qt is the sort of thing I'm looking for, but I'd like to work with something that doesn't force me to make it open source.
A quick list of things I want, a working close button, ability to use OGL, cross platform, any licence that doesn't force me to become open source, free, and the ability to go full screen and change resolution on the fly.
I have searched myself, I'm not a lazy person really ;) I just want to get some opinions here before I dive off into anything and find its not really suitable for my needs.
Thanks in advance for any feedback.
Try wxWidgets. There's a link on using it with OpenGL here.
When Qt 4.5 comes out (later this month, I think) it will be LGPL, so if you can wait a couple weeks, you can use Qt without having to open-source your program.
GLUT (GL Utility Toolkit) comes close to what you're looking for. It's quick and easy and cross-platform, although it does not have support for menu bars. This page also has a number of GLUT-like alternatives.
For the out-of-the-box close-button enabled window, you can have GLUT, as mentionned before, and if your additional GUI needs are really simple, I think GLUT can provide you some.
You could also go for simple OpenGL rendered menus and buttons, either using NVidia Widgets or AntTweakBar.
You don't need 'support' for OGL as long as you can pass it the correct the information. On windows at least, if you have a windowing API that you can hook the HWND from, you can set up OGL to use pretty much any window you want. I've done this successfully with wxWidgets and straight win32. I can't help you with other platforms, but I suspect you can do something similar.
This works with D3D too and is a nice way of separating your rendering code from your windowing API.
SDL can create OpenGL Windows.
http://gpwiki.org/index.php/C:SDL_OGL
There are numerous rendered widget libraries such as those that rotoglup suggested. Have a peek at CEGUI and QuickGUI, they may make you happy (although CEGUI disappoints me with its abuse of XML). And here's a shameless plug: GLICT.