Ça le rendrait bien restrictif. Ça me fait penser que tu pourrais faire un programme d'installation qui fait toute la compil, mais bon ce serait un peu lourd.

Ce que tu peux faire c'est le truc suivant :

a) Demoniser fmod pour qu'il ecoute sur un port reseau ou lise dans une zone mémoire partagée

b) faire que les infos de ton appli soient envoyées sur le port ou la zone mémoire en question.

De cette facon fmod et ton appli ne sont pas liés et fmod est facultatif a l'utilisation de ton appli. Par contre tu ne peux toujours pas distribuer ton appli et ton demon fmod dans un même package ou sur un même support.

Question pourquoi ne pas plutot essayer de reprendre un des nombreux plugins mod qui existent dans xmms pour les transformer a ta sauce ?
il y a le modplug qui est très versatile http://modplug-xmms.sourceforge.net/(...)
le mikmod qui est pas très fidèle mais simple :
http://mikmod.raphnet.net/(...)
et xmp qui existe déjà sur pas mal de plateformes
http://xmp.sourceforge.net/(...)

Et surement d'autres.

Kha

C'est pour faire un truc multiplateforme ?

en plus fmod a un son pas terrible des fois...

bref SDL_mixer ou un truc a ta sauce avec openal+mikmod(+vorbis)

si tu as besoin d'aide...

Non si il y a un lien à un moment ou à un autre (dynamique, statique, ...), que tu distribues ca en source ou binaire, c'est soit toi qui est dans l'illégalité soit l'utilisateur qui compile...
Oui si ton projet ne dépend pas de fmod, c'est à dire communique avec fmod avec une API qui pourrait par exemple tres bien etre implementer par un autre programme. Le tout et de pouvoir prouver que tu ne fait pas un travail basé sur fmod, mais que tu utilise simplement fmod. La frontiere peut etre des fois floue...