API/Python Bindings?

[bannsec]

Does giada expose an API? Specifically looking to use python bindings to interact with it.

[monocasual]

Hi there, no API exposure at the moment. Some guys suggested a MIDI scripting engine; the idea is cool but MIDI-only. However a set of Python APIs would cover more than that - say channels, loops, actions to name a few. Let's keep this issue open ;)

[monocasual]

For future reference: https://github.com/pybind/pybind11

[bannsec]

Yup. Was thinking either exposing an API through REST service perhaps, compiling python functions in C (tho i am not skilled in C/C++ personally), or utilizing something like cffi for direct calls to the tools libraries.

[bannsec]

So i think the biggest question right now for me is, say I wanted to add a channel, change a volume on a channel, etc. What C function calls are needed for those type of actions/where would i find other actions that the gui can perform and how it performs them (i.e.: calls).

[monocasual]

In terms of internal architecture, Giada follows a sort of MVC pattern. All functions from the giada::c:: namespace act as "controllers", connecting the view with the data and implementing the business logic. These are the functions that should be somehow exposed through any form of public API (we already do something similar with MIDI, where each MIDI event is mapped to a specific giada::c:: function).

Some random thoughts now. I think we should introduce a sort of "facade" between those functions and the real API, in order to hide internal objects (such as SampleChannel) they operate on. In addition to that, we are in the middle of a slow namespace refactoring, as many controller functions are still floating in the global namespace. Their "location" might then change out of the blue.

That said, we are super curious to see how this thing evolves. Just keep in mind it's 100% uncharted territory for all of us :ghost:

[bannsec]

Yeah, having given it a bit more thought myself, my guess is that simply calling those handlers through something like cdll would not work as it would not affect the internal space of the app (unless you're using pipes or something similar in the back-end).

Definitely agree the need for an abstraction layer. My concern with using python c binding directly is that it would be very specific to python. If someone comes along and, say, is a crack ruby dev and wants to use that, they would not be able to easily. This leads me to believe, long run, it would be better to have some sort of language agnostic API, such as local REST server, RPC, or similar.

To be honest, my feeling on this is building a REST API endpoint would allow both flexibility, as well as providing a commonly understood technology that others could easily build on top of. This would involve adding sockets and handlers, likely written in C/C++ alongside your core code, to open the listeners and interpret the API coming in.

[monocasual]

+1 to the language agnostic way, absolutely agree on this one.

This would involve adding sockets and handlers, likely written in C/C++ alongside your core code, to open the listeners and interpret the API coming in.

Sounds good. What kind of technologies would you include for such sockets/handlers mechanism? In my wish list I'd include something cross-platform (at least on desktops) and minimal to include/maintain (i.e. unlike a web server :grin:). Named pipes, maybe?

[bannsec]

Certainly not a full server. Was thinking something like restbed:

https://github.com/Corvusoft/restbed

It appears to be able to compile in Linux on Windows. Not clear on Mac, tho the devs seem to want cross compile support as well so I would guess it does/will. Also a plus that it's similarly built for c++11 specs.

[bannsec]

Also, named pipes would be hairy for cross compiling. They work great on nix, but I haven't seen any good implementation on Windows. TCP sockets are probably the most universal way to talk for any platform.

[monocasual]

@bannsec restbed looks great. Just give me a couple of days to wrap my head around this topic, then I'll set up a page in the wiki with a general overview of what we can do.

[monocasual]

@bannsec I have set up a wiki page here -> https://github.com/monocasual/giada/wiki/API-or-%5Byour.favorite.language%5D-bindings where I'm jotting down ideas on the possible implementations. The document is still under development, let me know if you find silly things in there.

[beppe9000]

If you define an HTTP REST API using the OpenAPI specification you can use a piece of software like this to create the client SDKs automatically.

[agritheory]

I'm curious to know why an RPC structure wouldn't be both the most language agnostic and the most performative, though it would still need a well-considered API design.