Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate crate for FMOD plugins development #15

Open
lebedec opened this issue Jul 21, 2024 · 3 comments
Open

Separate crate for FMOD plugins development #15

lebedec opened this issue Jul 21, 2024 · 3 comments
Labels
enhancement New feature or request help wanted Extra attention is needed need more coffee Extra coffee is needed before I can do it

Comments

@lebedec
Copy link
Owner

lebedec commented Jul 21, 2024

based on #14

We probably need a separate crate without linking that will contain everything we need for FMOD DSP plugins development.

  • Author of the original issue is correct that linking feels wrong via plugin development
  • SDK contains separated fmod_dsp.h which noted as header for DSP plugins development
  • We should be sure that plugins don't call FMOD functions and no need FMOD context

Probable solution:

A new crate libfmod-dsp-plugin based on fmod_dsp.h header which contains only definitions for DSP plugins development. Version and backward compatibility based on FMOD_PLUGIN_SDK_VERSION (provided by FMOD team). No linking. No FMOD context bindings.

Blocker:

Need more docs except white papers or any FMOD developer expertise to be sure that this solution correct

@lebedec lebedec added enhancement New feature or request help wanted Extra attention is needed labels Jul 21, 2024
@lebedec
Copy link
Owner Author

lebedec commented Jul 30, 2024

There are 3 plugin types:

  • Codec
  • DSP
  • Output

In application runtime they can be provided all the ways

In SDK each plugin has separate header with its own version FMOD_xxx_PLUGIN_VERSION:

  • fmod_codec.h
  • fmod_dsp.h
  • fmod_output.h

All these definitions must be provided in common FMOD library (included in fmod_common.h which included in fmod.h)

Also, I think there is no much sense to provide Rust safe wrappers for plugin definitions because. Almost all definitions of plugin is callbacks with C FFI interfaces. Maybe we need separate libfmod-sys crate (this is also recommended by the Rust FFI guidelines).

Draft, new libfmod crates hierarchy:

Screenshot 2024-07-30 at 09 26 10

@lebedec lebedec changed the title Separate crate for DSP plugins development Separate crate for FMOD plugins development Jul 30, 2024
@lebedec lebedec added the need more coffee Extra coffee is needed before I can do it label Jul 30, 2024
@melody-rs
Copy link

Feel free to use fmod-audio-sys!

@lebedec
Copy link
Owner Author

lebedec commented Oct 14, 2024

About wrappers for plugin API.

There are issues for short period of time. All occured becuase of "safe" conversion:

Also, working with plugin API in any case leads to raw FFI: specific pointers defintion, byte buffers, C unions, C callbacks, etc

I am becoming more and more confident that FMOD plugins API structures like FMOD_DSP_DESCRIPTION must be raw FFI without wrappers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed need more coffee Extra coffee is needed before I can do it
Projects
None yet
Development

No branches or pull requests

2 participants