FMOD now free for Indies
Monkey Archive Forums/Digital Discussion/FMOD now free for Indies
| ||
| Just seen that the audio middleware FMOD is now free for Indies. http://www.develop-online.net/news/audio-middleware-fmod-studio-goes-free-for-indies/0190187 Not used it recently but I have in the past and it was great for playing .MODs and .XMs or anything really. |
| ||
| Did they increase the price a lot at some stage? I seem to remember getting it for $200 a few years back... |
| ||
| The $200 licensing was for approved devs who charged little and made little not for everyone. |
| ||
| Does this require the Android NDK for it to be used on Android devices? I couldn't find a clear answer on the website. |
| ||
| I always avoided FMOD for two reasons: 1. Impulse Tracker support was spotty for NNA's and filtering 2. Those effing per-platform fees were a big startup problem for indies with not a lot of capital Since 2 is no longer an issue, and these days 1 isn't as much an issue anymore because most people have switched to streaming audio anyway, I think this presents a very good opportunity to start incorporating FMOD as a cross-platform monkey module. Format support is pretty good, it's more powerful than the existing system, and on Android (I'm assuming it uses NDK!) there aren't heap pooling limitations. |
| ||
| Maybe it's time to ditch OpenAL on the desktop target??? |
| ||
| I'm confused about this. What exactly IS FMOD Studio? Because that's the only thing they are making free and I'm not clear on exactly what that includes. |
| ||
| "Maybe it's time to ditch OpenAL on the desktop target?" I'd suggest the better idea is to look at using SDL as the base for Win/Mac/Linux/iOS/Android. It provides usable audio access out of the box along with a consistent API for graphics, input, file IO and a bunch of other stuff. It would likely save a lot of cross-platform effort for Mojo over time. |
| ||
| I wouldn't mind an SDL target, but replacing mojo...? A whole lot of bugs would arise, and we would have to wait for them to be solved somewhere else. So, I say let mojo as it is. But... OpenAL is now a mess - it doesn't work in a lot of places, having to use a separate installer isn't the best solution - and it's harder and harder to find an official site, a place where to download and get support for it. I think "fmod" just got renamed as "fmod studio" now - it's not anymore just the dll to play stuff, there's a bunch of tools to edit audio or something - I've downloaded their (windows) installer, and there is the source, dlls and even a ".a" file to build directly into the exe. So yeah, if you have a project, that uses less than USD100,000 of budget, you can use it for free! |
| ||
| GfK: Apparently FMOD "Studio" is a DAW which is made for FMOD. I'm hoping that the API is free, too. I'm not clear on this now but it seems like that's OK, too. They still want you to contact them for console SDK's, probably to prove you've signed a NDA. I was gonna write something saying "Forget SDL", but I did some checking and since version 2.0 they're now zlib instead of lgpl. Still, SDL would make desktop builds quite a bit more complicated. I'd like to see the practical advantages of making a switch. |
| ||
| I didn't say "replace mojo". Mojo is a Monkey API. You just replace the native stuff underneath with an SDL base. That would get rid of the need for OpenAL as SDL automatically routes to DirectX/whatever is appropriate. |
| ||
| muddy_shoes: It's attacking the fly with a nuke. OpenAL should be as easy to pull out as it was putting it in there, whereas swapping in SDL pretty much is the work of an entire target. Also, what the heck. FMOD Studio API doesn't run on Linux? |
| ||
| Yes, if OpenAL is the only issue you care to consider it would be overkill. |
| ||
| @muddy_shoes: I understood you don't want to "get rid of mojo" - it was a poor choice of words from my part, sorry. I should have said to replace *opengl* with sdl. But as Nobuyuki said, It is a lot of work to put SDL in - would be best to create a custom target for that. Adding FMOD should be pretty straight forward - I took a quick look at the basic API, and most functions map directly to monkey's! My worst concern is that the situation behind OpenAL right now is shady at best - we have no idea for how long it will keep working, for a start. Having no official website, just makes me more eerie of the whole situation. |
| ||
| SDL doesn't replace OpenGL. It makes it easy to open an OpenGL context. Edit: To answer the "I get the last word, now go away" argument below - OpenGL is a cross-platform API and the route to hardware accelerated rendering for us on nearly all platforms so why would you want or need to be independent of it for Monkey? The reasons for using SDL are above and wanting to use Direct3D isn't one of them. The reason is to reduce work going forward across the board. Enjoy talking about FMOD. |
| ||
| It will replace the opengl commands inside mojo if you want SDL to be truly independent and able to use Direct-X on Windows - otherwise, there should be no reason to even use it. But regardless of what we both think about SDL, let's stay on topic, which is FMOD now being free... |
| ||
| Back to topic, i know slopeOak ported some version of fmod to monkey, but none of his code is public at the moment. I'm frankly disappointed that studio doesn't have a Linux api because that locks us out of steamOS. |
| ||
| Jut got one reason for using FMOD instead of OpenAL: Here in my university computers, OpenAL fails to detect an audio device. I just downloaded the FMOD Studio Programmer's API and ran the "lowlevel" playsound sample - it works like a charm! (On Windows 8.1, 64 bits nonetheless) |
| ||
| I realise the FMOD free offer might be an exception especially given that there are issues with OpenAL, but generally speaking I think Monkey should avoid dependencies on any software that is not 100% free forever to everyone. That said, there are already exceptions in that you have to pay device manufacturers to use certain SDKs. So I don't want to harp on this point, but I would just be a bit wary of jumping in with both feet. Of course an FMOD *module* would be perfectly okay in any circumstances, and there would be nothing wrong with a config variable that allowed the need for OpenAl to be switched off. |
| ||
| Question: if somebody started making a module for desktop, are there any volunteers to get it working on android? ;) |
| ||
| Monkey should avoid dependencies on any software that is not 100% free forever to everyone. Well, technically iOS development costs $99 per year, so it wouldn't be the first API Monkey uses that you have to invest money... for WinRT you need Windows 8, which isn't free either. I understand your point, and even agree with it. I'm here trying to think how to make a custom target with fmod in it (a module wouldn't work, since desktop would still be using OpenAL, and for sure conflicts will happen for trying to use both)... but it would be nice to have it on monkey as a default option. |
| ||
| Yes, that's why I suggested that there could be a config option to unlink OpenAl so that sound could be handled by a module. |
| ||
| I'm not clear on why conflicts are bound to happen, guys. Doesn't the API handle its own stream and management? Sure, it would be a bit of a kludge, but a separate target seems like an even bigger kludge. You'd be using FMOD for all of your audio, not OpenAL. They'd have their own separate resources, just living in the same process. |
| ||
| The conflict/problem will happen because desktop initialize OpenAL, and if it fails, the app just ends. But, even if OpenAL is initiated successfully, then it will hog the soundcard resources - probably trying to use FMOD then, it will become at least slower, not to say unstable. That's why I said a custom target (if it will not be officially replacing OpenAL) - there's no way you can "disable" OpenAL with just a module. |
| ||
| I would imagine OpenAl and FMod are designed to co-exist pretty well. If if they don't both of these APIs have calls to free resources easily as well as allocate them. But I'd be be very surprised if you need to bother at all. |
   |