C bindings

[BillyDM]

Create C bindings.

This doesn't need to cover every single feature, just ones that make sense to include (i.e. the context graph API and the plugin API).

[olekspickle]

I'd be down to do that

[BillyDM]

Some more notes about the C bindings (taken from the design document):

Firewheel is a large library with a lot of rust-isms (enums, traits, generics, and macros). As such, the goal of the C bindings is NOT to provide access to every single part of the API. Instead, this is a rough overview of what the C bindings will consist of:

• Two backend options:
  • A "CPAL" option which allows you to enumerate available audio devices and to start/stop audio streams.
  • A "no backend" option where the user plugs in a firewheel processor object into their own custom audio stream.
• Optional functions for loading sample resources from memory or from a file path.
• Firewheel Context
  • Construct a Firewheel context with configurable options
  • Methods to get and configure clocks
  • Update method
  • Methods to add, remove, and connect nodes in the graph
    • Some thought will need to be given on what the API to construct nodes should look like. We can simply just have a constructor function for each of the factory nodes. Though preferably there should also be a way to use construct third party nodes as well.
• Nodes
  • Sending updates to nodes will be purely event-driven (no data-driven diffing/patching system). This will be done by defining an update function for each parameter for each factory node. Though some thought will need to be given on what the API for third party nodes should look like.
  • Retrieving state will also be achieved using custom function for each of the factory nodes that have custom state.
• Node Pools
  • I haven't figured out what the API for node pools should look like yet.
• A custom node API. This will be similar to the API in Rust, except that the event types will be simplified to be simple parameter values with integer paramter IDs. There will also be no ProcStore API (instead users can just simply pass around raw pointers to resources they need to share across nodes).

[olekspickle]

Hmm, does it mean its no longer a priority or did you do it already? cause I was about to start working on a draft PR

[BillyDM]

Oh sorry, you haven't commented in over half a year, so I unassigned you. I'll assign you again!

[olekspickle]

yeah, it's been a while, I'll describe the breef in the draft, it's more or less viable I guess but I'd need some feedback for sure. also the new backend, but it can come later

[olekspickle]

what would be the good audio example to showcase capabilities? just initializing context and playing beep enough? would be more fun to do something more complex, but at the moment I'm a bit overwhelmed by C as it is to devise cool audio showcase

anyway - draft pr is up