0
0

Hello.
I would like to know if there is any support (existing or planned) for .NET.
I intend to use FMOD with Visual C# or if necessary with VB .NET.
I got a sample-program to run under Visual C#, but I had to migrate everything by hand.
Thanks for any information. Prem.

  • You must to post comments
0
0

Wow, even Microsoft, a company that seems to like using proprietary technology, has taken note of FMOD? That’s surprising… then again, I guess it’s all in due time. Microsoft is now using Inno Setup, one of the best [b:1nt96nu1]completely free[/b:1nt96nu1] installation systems out there… wouldn’t it be something to see MS start using all third-party technologies?

  • You must to post comments
0
0

They’re using Inno Setup .. that is amazing – I started using that over 2 years ago … and it IS good

  • You must to post comments
0
0

I’d imagine you would have things like Fmod.Sound, Fmod.Music, etc.? I’m just starting to read stuff about .NET for both C# and Delphi for .NET.

  • You must to post comments
0
0

The .NET port does not have to be done in C#. .NET assemblies can be made in any .NET language. Borland has a Delphi for .NET compiler preview available and Microsoft is bringing out Visual C++ for .NET soon.

  • You must to post comments
0
0

Isn’t it possible to just use the VB wrapper with VB.Net?

  • You must to post comments
0
0

Yes, a long time ago I have tried to use the vb6->vb.net converter to open fmod.bas in .net, and I thought only a few manual changes were needed after that to get it working.

Once you have the fmod commands available from .net, you can also make an object oriented wrapper class to make fmod available oo.

  • You must to post comments
0
0

The code for Delphi for .NET is very similar to C#. The DllImport directive is exactly the same bar the double quotes. The only thing different is the function declaration.[code:1gtbv4dn][DllImport(’fmod.dll’, EntryPoint = ‘_FSOUND_Init@12’)]
function FSOUND_Init(mixrate, maxsoftwarechannels: Integer; flags: Cardinal); external;[/code:1gtbv4dn]FMOD would be considered unsafe code due to the use of pointers. Managed code does not allow the use of pointers so that the CLR (Common Language Runtime) can perform garbage collection and keep everything nice and orderly.

  • You must to post comments
0
0

hello.
i tried already once to post this, but it seems it didn’t work.
i had no problem to migrate fmod.bas to C# and VB.NET. and it works fine. only callbacks i could not get to work. and that’s the most important part for me, because i want the program to react immediately when a piece is finished.
prem.

ps: i do have a problem playing very short mp3-pieces. they have a strong noise when they start playing.

  • You must to post comments
0
0

Just to notify there is .Net C++ its included as an extention to C++. I got it with microsoft visual C++.Net 2002 edition in project types its named as “Managed C++ Application” or “Managed C++ Class Library”

  • You must to post comments
0
0

If we want to interface to the FMOD DLL as it stands now, then it will never be managed code. The CIL runtime can not control what the DLL does, so it cannot manage that code.

  • You must to post comments
0
0

He’s right, Brett. By “managed code,” Microsoft is essentially referring to garbage collection. Because fmod.dll is already compiled, and executables can’t be easily directly modified, .NET’s CLR can’t do garbage-collection on it, so unless a specific .NET (let’s say fmodnet.dll) port of FMOD is made, it’s going to be very tough to use FMOD as is in a .NET environment.

  • You must to post comments
0
0

That only means it cannot be used like an Active-X DLL. But it can be used as API just like in any other language e.g. VB6. (DllImport).
Prem.

  • You must to post comments
0
0

From my understanding of .NET, there seems to be two ways we can go here.

  1. Provide source files for each language that define the types and import the functions from the DLL. This is like the current FMOD release where each API update means updating several source files with the same change.
  2. Provide one assembly that works for all .NET languages. This assembly declares all the types and the functions in a common manner. One source file to produce one assembly for all .NET languages.
  • You must to post comments
0
0

Hello all,
I’m new to the forums, new to the FMOD SDK and looking forward to doing some development with it in C#. I’ve found that with some good documentation, porting the function calls with PInvoke to C# is relatively easy. I’ve already done media applications with BASS and Miles in C#. – 3 – 8 band equalizers, Shoutcast playback, etc. DirectX 9 is seriously lacking features of an audio SDK like FMOD. I’d be happy to post my results/source code to the list if anyone is interested and if there is a place to do so.

  • You must to post comments
0
0

[quote="Sly":3b32kzg2]From my understanding of .NET, there seems to be two ways we can go here.

  1. Provide source files for each language that define the types and import the functions from the DLL. This is like the current FMOD release where each API update means updating several source files with the same change.

  2. Provide one assembly that works for all .NET languages. This assembly declares all the types and the functions in a common manner. One source file to produce one assembly for all .NET languages.[/quote:3b32kzg2]

From past experience of P/Invoke number 2 is likely to be the best answer by far. By picking a language (I always use C# as somehow it feels cleaner with P/Invoke) and then creating objects as you would in C++, you can make the native api available to anyone in any .Net language.

There is really no need to consider number 1, a class defined in C# and put in an assembly is accessible from ALL other .Net capable languages. Nice eh? That’s sort of why when you see ArrayList() used in several different languages it looks kinda freaky.

Generally I always ‘hide’ the native calls inside a class and only ‘allow’ that class to use the calls, making the FMod.Net API just a wrapper over the existing ones. Rather than have one source file you could just group all of the existing FMod calls into a class.

Using P/Invoke allows you to define C# structs to match any C ones you have and then marshall directly between the managed and unmanaged types. DotNet even has IntPtr which you can treat like a void *.

There is a lot of code in C# SDL that you could look at for clues (cssdl.sourceforge.net), it’s fairly obvious in there what is happening.

Feel free to ignore this advice (I’m not sure I’ve clarified anything), I only came here with a MacOS X linking problem … but I can’t resist getting involved in P/Invoke problems :)

  • You must to post comments
0
0

Hi!

I have some experience with wrapping C-libraries into Managed Interfaces using .NET. I’m currently twiddling a bit with wrapping Lua 5.0. Anyways, here’s my two cents. The easiest way to do it is with P/Invoke using the DLLImport stuff, but that only allows you to basically port the FMOD API to .NET, which (IMHO) does feel very kludgy to use from .NET languages. Those people want nice classes and objects to work with. Another minus point is, that you will have two DLLs floating around. FMOD.DLL and FMODNET.DLL or whatever … it would be nicer to have just a single DLL. The solution to this is to create a managed wrapper using Managed C++. You create a class library which includes the entire FMOD source code. Then you wrap the necessary parts into Managed classes. It is quite easy to communicate with native code this way. Basically, the managed wrapper code is like an application which just ‘uses’ FMOD … simple as that.

Once a basic wrapper is set up, you can then extend it with some neat .NET features, such as Properties, Delegates, etc… to make it easier/cooler to use.

Thanks to the simple FMOD API it should be very, very easy to create such a wrapper. Obviously, some parts are a bit trickier (DSPs, etc…) but a wrapper for basic functionality should be a weekend project. I think I might even give it a try tonight … just to get some MP3 playback.

If you (Brett) or anybody else want to know more, feel free to ask.

-Marco

  • You must to post comments
0
0

I cannot see Brett wanting to go to that effort for the 3.xx series since all his efforts are on FMOD4 for the foreseeable future. So, if we want .NET usability for the 3.xx series, then we will have to go with the PInvoke approach and have the two DLLs. That’s a small price to pay for being able to easily use FMOD in any .NET language.

  • You must to post comments
0
0

Well, you might be right … I sent him a very small/limited/hacked together sample of how I would do it yesterday evening (the wrapper in Managed C++ and the test-sample in C#). The effort is really not that much more. Even if it is not done for the 3.xx series, he should consider it for FMOD 4. It is much cleaner, IMHO. I guess, this decision is really governed by other factors. How long will it be until version 4 comes around? Does he still want to have version 3.xx floating around?

Everybody using C# should be able to write their own P/Invoke wrapper anyways. Using P/Invoke you should be able to wrap FMOD in its entirety over a weekend. I haven’t looked much into the DSP stuff, but that should also be possible, having FMOD callback C# or VB.NET code … although this requires the FMOD version, which uses stdcall for callbacks.

-Marco

  • You must to post comments
0
0

I just tried to do a small test in C#. I got a small assembly going with init and close working, but got stuck at trying to pass a String to a function that expects a char *.

Not that I’m really serious about using C#. To me it still feels like too much work to do the simplest thing.

  • You must to post comments
0
0

I am new to fmod.

I somehow look into the threads.

So it means that can i use fmod in c# or not? Is yes, how to get started with it?

Coz at the moment i am using DirectSound. I heard fmod is quite good!

Any help, please!

Thank you.

Regards,
Chua Wen Ching :p

  • You must to post comments
Showing 1 - 20 of 75 results
Your Answer

Please first to submit.