Sounds and graphics.

How do I play a sound i VB?
And how do I play a *.mpg video in VB?
Can somebody tell me?
Thanks.

«1

Comments

  • To play an MPEG you can use the Windows Media Player control.. You can also use this for playing sounds..

    : How do I play a sound i VB?
    : And how do I play a *.mpg video in VB?
    : Can somebody tell me?
    : Thanks.


  • : To play an MPEG you can use the Windows Media Player control.. You can also use this for playing sounds..
    :
    : : How do I play a sound i VB?
    : : And how do I play a *.mpg video in VB?
    : : Can somebody tell me?
    : : Thanks.

    Or, if you really need high performance, there are DirectSound and DirectMedia.
    From version 7 on, there's a typelib for VB users.
  • : Or, if you really need high performance, there are DirectSound and DirectMedia.
    : From version 7 on, there's a typelib for VB users.
    :

    Dear fellow guru (sorry, couldn't help myself ),

    Let's say I'm writing a wave-mixer program (I'm not, but a friend is). Let's say I decided to allow previewing of edits before writing to disk. Let's say MS "forgot" to add sound capabilities to VB. Let's say I'm tired of typing "let's say". Can you suggest a course of action? I'd guess DirectSound would work, but that'd be a heck of a dependency. I know there are dlls out there giving port access to VB but wouldn't have a clue about how to use the port directly. I'd bet Windows has the appropriate APIs built in. Can you suggest a course of action or a website to look at? Basically, I need to output sample-by-sample to the sound card.

    Thanks,
    KDL
  • : : Or, if you really need high performance, there are DirectSound and DirectMedia.
    : : From version 7 on, there's a typelib for VB users.
    : :
    :
    : Dear fellow guru (sorry, couldn't help myself ),
    :
    : Let's say I'm writing a wave-mixer program (I'm not, but a friend is). Let's say I decided to allow previewing of edits before writing to disk. Let's say MS "forgot" to add sound capabilities to VB. Let's say I'm tired of typing "let's say". Can you suggest a course of action? I'd guess DirectSound would work, but that'd be a heck of a dependency. I know there are dlls out there giving port access to VB but wouldn't have a clue about how to use the port directly. I'd bet Windows has the appropriate APIs built in. Can you suggest a course of action or a website to look at? Basically, I need to output sample-by-sample to the sound card.
    :
    : Thanks,
    : KDL

    DirectSound would, literally, work wonders.
    Anyway, as long as you use DX7, it's included with Windows 2K on, so it's not much of a "dependency" really. That would be the easier way to directly use the port, as far as I know.

    Otherwise, get ready for some nasty surprises when it comes to mixing buffers, and check out the "waveOutWrite" API and friends.
  • : DirectSound would, literally, work wonders.
    : Anyway, as long as you use DX7, it's included with Windows 2K on, so it's not much of a "dependency" really. That would be the easier way to directly use the port, as far as I know.
    :
    : Otherwise, get ready for some nasty surprises when it comes to mixing buffers, and check out the "waveOutWrite" API and friends.
    :

    Didn't know DX7 was included on 2K+, that may make life easier on him. I was thinking of looking into the various wave APIs but according to your description, I probably don't even want to know what they're called!

    Any ideas on C++ only code? He's looking to make a cross-platform application (as in as little rewriting as needed). Or do we not even want to think about that?
  • I believe I am the friend KDL is talking about. At least, if I'm not I'd be very interested to know the other friend... :-)

    : : DirectSound would, literally, work wonders.
    : : Anyway, as long as you use DX7, it's included with Windows 2K on,
    : : so it's not much of a "dependency" really. That would be the easier
    : : way to directly use the port, as far as I know.
    : :
    : : Otherwise, get ready for some nasty surprises when it comes to
    : : mixing buffers, and check out the "waveOutWrite" API and friends.
    : Didn't know DX7 was included on 2K+, that may make life easier on
    : him. I was thinking of looking into the various wave APIs but
    : according to your description, I probably don't even want to know
    : what they're called!
    The waveOutWrite API is quite literally HORRIBLE. I tried to implement it before now in VB, and gave up because it's so convoluted. DirectSound was already on my list of things to check out. FYI, I basically have a core which is intended to be cross platform compatible, and it does all the mixing down itself and has a nice abstract I/O interface, so it's easy to later get data going to a soundcard e.g. via DirectSound rather than to a file, which is what it does at the moment. The core takes an input instruction file, which is generated by a (more likely platform specific) GUI app. There is currently a GUI app in VB that targets the core. Sort of...

    : Any ideas on C++ only code? He's looking to make a cross-platform
    : application (as in as little rewriting as needed). Or do we not even
    : want to think about that?
    he core of the core (ugh...need some better teminology) is written in C and currently compiles with cl and gcc and hopefully other C compilers. I realise that things like output to the soundcard will be platform specific, and this will be handled through conditional compilation. That way even if DirectX headers make use of C++ stuff (do they? I wouldn't know) rather than pure C, it would be ignored by the compiler due to the conditional compilement directives. I hope! :-)

    Ugh...got loads of physics questions to do for tomorrow...

    Jonathan

    ###
    for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
    (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
    /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

  • [b][red]This message was edited by Genjuro at 2003-10-15 9:14:25[/red][/b][hr]
    : : DirectSound would, literally, work wonders.
    : : Anyway, as long as you use DX7, it's included with Windows 2K on, so it's not much of a "dependency" really. That would be the easier way to directly use the port, as far as I know.
    : :
    : : Otherwise, get ready for some nasty surprises when it comes to mixing buffers, and check out the "waveOutWrite" API and friends.
    : :
    :
    : Didn't know DX7 was included on 2K+, that may make life easier on him. I was thinking of looking into the various wave APIs but according to your description, I probably don't even want to know what they're called!
    :
    : Any ideas on C++ only code? He's looking to make a cross-platform application (as in as little rewriting as needed). Or do we not even want to think about that?


    Those APIs are quite bad in VB. It doesn't excel in getting blocks of bytes and manipulate them, but in C++ it's really not *that* hard.

    C++ only code, huh? To achieve platform-independence.
    In theory, it sounds nice. In practice, you'll have to deal with Windows drivers for hardware, multitasking, and so on. And it *is* bad.

    I wrote a similar thing in C++, but it was meant only for Windows.
    Yet, there's a C++ OOP "trick".
    He should create a class, like:

    [code]
    class CSoundManager
    {
    private:
    CSoundBuffer* MainBuffer;
    public:
    virtual void MixBuffer(CSoundBuffer* Buf1, CSoundBuffer* Buf2)=0;
    };
    [/code]

    and then derive:
    [code]
    class CWindowsSoundManager: public CSoundManager
    {
    public:
    void MixBuffer(CSoundBuffer* Buf1, CSoundBuffer* Buf2);
    }
    [/code]
    and a similar class for other platforms (let's suppose "CUnixSoundManager").

    and then, compile the client code like this:
    [code]
    #ifdef _WINDOWS
    CSoundManager* SoundManager = new CWindowsSoundManager;
    #else
    CSoundManager* SoundManager = new CUnixSoundManager;
    #endif
    [/code]

    The idea here is to keep platform-specific issues in specific class files, and then access the platform-dependent implementation through a common CSoundManager "interface", so that when you call "SoundManager->MixBuffers", you get either "CWindowsSoundManager->MixBuffers" or "CUnixSoundManager->MixBuffers" depending on a "#define" in a single row.

    This way, the class "client" code (IE: the code that uses the class) doesn't vary, while the "server" code will be picked correctly at compile/run time, and you have actually a "client code branch" only once (when you decide which sub-class to instance, and instance it).

    The "drawback" is that:
    1) The base class MUST have declared *all* of the functions as virtual (that's no matter if they are "pure virtual" or not, but that class MUST have the prototype)
    2) The derived classes MUST have an implementation for all methods of the base class, and no more.

    Given this, you can "hide" all of the platform-specific APIs inside the derived class, and besides these classes, the remaining code will be platform independent (this means, once these classes are written, the remaining code will NOT need being altered in any way).

    So, I'd say we could at least *think* about that, don't you agree?


  • : : : DirectSound would, literally, work wonders.
    : : : Anyway, as long as you use DX7, it's included with Windows 2K on, so it's not much of a "dependency" really. That would be the easier way to directly use the port, as far as I know.
    : : :
    : : : Otherwise, get ready for some nasty surprises when it comes to mixing buffers, and check out the "waveOutWrite" API and friends.
    : : :
    : :
    : : Didn't know DX7 was included on 2K+, that may make life easier on him. I was thinking of looking into the various wave APIs but according to your description, I probably don't even want to know what they're called!
    : :
    : : Any ideas on C++ only code? He's looking to make a cross-platform application (as in as little rewriting as needed). Or do we not even want to think about that?
    :
    :
    : Those APIs are quite bad in VB. It doesn't excel in getting blocks of bytes and manipulate them, but in C++ it's really not *that* hard.
    :
    : C++ only code, huh? To achieve platform-independence.
    : In theory, it sounds nice. In practice, you'll have to deal with Windows drivers for hardware, multitasking, and so on. And it *is* bad.
    :
    : I wrote a similar thing in C++, but it was meant only for Windows.
    : Yet, there's a C++ OOP "trick".
    : He should create a class, like:
    :
    : [code]
    : class CSoundManager
    : {
    : private:
    : CSoundBuffer* MainBuffer;
    : public:
    : virtual void MixBuffer(CSoundBuffer* Buf1, CSoundBuffer* Buf2)=0;
    : };
    : [/code]
    :
    : and then derive:
    : [code]
    : class CWindowsSoundManager: public CSoundManager
    : {
    : public:
    : void MixBuffer(CSoundBuffer* Buf1, CSoundBuffer* Buf2);
    : }
    : [/code]
    : and a similar class for other platforms (let's suppose "CUnixSoundManager").
    :
    : and then, compile the client code like this:
    : [code]
    : #ifdef _WINDOWS
    : CSoundManager* SoundManager = new CWindowsSoundManager;
    : #else
    : CSoundManager* SoundManager = new CUnixSoundManager;
    : #endif
    : [/code]
    :
    : The idea here is to keep platform-specific issues in specific class files, and then access the platform-dependent implementation through a common CSoundManager "interface", so that when you call "SoundManager->MixBuffers", you get either "CWindowsSoundManager->MixBuffers" or "CUnixSoundManager->MixBuffers" depending on a "#define" in a single row.
    :
    : This way, the class "client" code (IE: the code that uses the class) varies, while the "server" code will be picked correctly at compile/run time, and you have actually a "client code branch" only once (when you call "new" and decide which sub-class to instance).
    :
    : The "drawback" is that:
    : 1) The base class MUST have declared *all* of the functions as virtual (that's no matter if they are "pure virtual" or not, but that class MUST have the prototype)
    : 2) The derived classes MUST have an implementation for all methods of the base class, and no more.
    :
    : Given this, you can "hide" all of the platform-specific APIs inside the derived class, and besides these classes, the remaining code will be platform independent (this means, once these classes are written, the remaining code will NOT need being altered in any way).
    :
    : So, I'd say we could at least *think* about that, don't you agree?
    :
    Glum...When the BOSS speaks the class is silent...and a bit dizzy!
    Bye ;o)


    [b][size=3]
    [blue]C[/blue][red]arry[blue]F[/blue]lag
    [/size][size=2]...debugging is futile.[/red]
    [/b][/size]



  • : : : : DirectSound would, literally, work wonders.
    : : : : Anyway, as long as you use DX7, it's included with Windows 2K on, so it's not much of a "dependency" really. That would be the easier way to directly use the port, as far as I know.
    : : : :
    : : : : Otherwise, get ready for some nasty surprises when it comes to mixing buffers, and check out the "waveOutWrite" API and friends.
    : : : :
    : : :
    : : : Didn't know DX7 was included on 2K+, that may make life easier on him. I was thinking of looking into the various wave APIs but according to your description, I probably don't even want to know what they're called!
    : : :
    : : : Any ideas on C++ only code? He's looking to make a cross-platform application (as in as little rewriting as needed). Or do we not even want to think about that?
    : :
    : :
    : : Those APIs are quite bad in VB. It doesn't excel in getting blocks of bytes and manipulate them, but in C++ it's really not *that* hard.
    : :
    : : C++ only code, huh? To achieve platform-independence.
    : : In theory, it sounds nice. In practice, you'll have to deal with Windows drivers for hardware, multitasking, and so on. And it *is* bad.
    : :
    : : I wrote a similar thing in C++, but it was meant only for Windows.
    : : Yet, there's a C++ OOP "trick".
    : : He should create a class, like:
    : :
    : : [code]
    : : class CSoundManager
    : : {
    : : private:
    : : CSoundBuffer* MainBuffer;
    : : public:
    : : virtual void MixBuffer(CSoundBuffer* Buf1, CSoundBuffer* Buf2)=0;
    : : };
    : : [/code]
    : :
    : : and then derive:
    : : [code]
    : : class CWindowsSoundManager: public CSoundManager
    : : {
    : : public:
    : : void MixBuffer(CSoundBuffer* Buf1, CSoundBuffer* Buf2);
    : : }
    : : [/code]
    : : and a similar class for other platforms (let's suppose "CUnixSoundManager").
    : :
    : : and then, compile the client code like this:
    : : [code]
    : : #ifdef _WINDOWS
    : : CSoundManager* SoundManager = new CWindowsSoundManager;
    : : #else
    : : CSoundManager* SoundManager = new CUnixSoundManager;
    : : #endif
    : : [/code]
    : :
    : : The idea here is to keep platform-specific issues in specific class files, and then access the platform-dependent implementation through a common CSoundManager "interface", so that when you call "SoundManager->MixBuffers", you get either "CWindowsSoundManager->MixBuffers" or "CUnixSoundManager->MixBuffers" depending on a "#define" in a single row.
    : :
    : : This way, the class "client" code (IE: the code that uses the class) varies, while the "server" code will be picked correctly at compile/run time, and you have actually a "client code branch" only once (when you call "new" and decide which sub-class to instance).
    : :
    : : The "drawback" is that:
    : : 1) The base class MUST have declared *all* of the functions as virtual (that's no matter if they are "pure virtual" or not, but that class MUST have the prototype)
    : : 2) The derived classes MUST have an implementation for all methods of the base class, and no more.
    : :
    : : Given this, you can "hide" all of the platform-specific APIs inside the derived class, and besides these classes, the remaining code will be platform independent (this means, once these classes are written, the remaining code will NOT need being altered in any way).
    : :
    : : So, I'd say we could at least *think* about that, don't you agree?
    : :
    : Glum...When the BOSS speaks the class is silent...and a bit dizzy!
    : Bye ;o)
    :
    :
    : [b][size=3]
    : [blue]C[/blue][red]arry[blue]F[/blue]lag
    : [/size][size=2]...debugging is futile.[/red]
    : [/b][/size]

    *LOL*
    Someone was expecting less, from me?

  • : *LOL*
    : Someone was expecting less, from me?

    At least he's humble about it.
  • : Glum...When the BOSS speaks the class is silent...and a bit dizzy!
    : Bye ;o)

    And he tries to tell us he's not one of the gurus around here...
  • : So, I'd say we could at least *think* about that, don't you agree?

    This is pretty much what I expected/hoped for. It's actually similar to code I've written myself (using the Implements keyword) though the C++ specifics tend to lose me a bit. I know what they are when I see them, but I couldn't write them to save my life.

    Thanks for the help!
  • : I believe I am the friend KDL is talking about. At least, if I'm not I'd be very interested to know the other friend... :-)
    :

    Jealous?
  • : : I believe I am the friend KDL is talking about. At
    : : least, if I'm not I'd be very interested to know the other
    : : friend... :-)
    : :
    :
    : Jealous?
    :
    No, just recruiting for my open source project... ;-)

    Jonathan

    ###
    for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
    (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
    /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

  • : : So, I'd say we could at least *think* about that, don't you agree?
    :
    : This is pretty much what I expected/hoped for. It's actually similar to code I've written myself (using the Implements keyword) though the C++ specifics tend to lose me a bit. I know what they are when I see them, but I couldn't write them to save my life.

    Yup, the idea is exactly the same.
    Check out the "virtual" keyword, and perhaps "pure virtual" functions on any C++ book, and it will be a breeze.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories