Binding to other languages

[scalarwaves]

First of all thank you for making Gwion! I love ChucK and this project could be of great use to me. Recently I’ve been trying to create a C wrapper for ChucK to bind with a Rust library. It hasn’t been easy, though that’s not to say ChucK isn’t awesome. Is there a master header like gwion.h that would provide an API suitable for FFI with Rust?

[fennecdjay]

Brillant!
Actually not yet. There is gwion_util.h and gwion_ast.h for the libraries, and an actual gwion.h for an actual Gwion structure.
I've been thinking into unifying all these though.
Definitely gonna look at it soon and warn you.

[scalarwaves]

Wonderful. If you're interested, ruckus is the Rust+ChucK project, which is part of a group of projects related to my WIP digital audio workstation tgtracker. How does Gwions plugin system work with LLVM and all that? Is it similar to Chugins?

[fennecdjay]

I don't know anything about rust FFI, so I'm afraid I won't be able to help on this unless you get more specific ;-)
Anyway Gwion plugin system should be quite similar to Chuck's. Just dynamic libraries loaded at runtime.
In Gwion case, you have to define an GWION_IMPORT function to define a class.
Note that you can also define a driver (e.g. sound ouput) with GWDRIVER and a module (e.g. coverage instrumentation or JIT) with GWMODINI and GWMODEND (both requiring defining GWMODSTR).
You can see actual usage of all this in src/lib (see here as an example) and in this directory

---

A problem in Gwion is the lack of documentation.
If you point me to what you need as resource, I could use that as a starter.
Thanks.

[fennecdjay]

I had a quick look at ruckus, and I'm not quite sure what's going on there, but I think you should look here.
These few lines should enable you to start and run a gwion process. To add more files/strings, you'll need the functions in compile.h.

Also that might be of some help.

You'll almost certainly have to make some change to the Makefile (or anything else), please let me now.

---

Would it help it distributed as a library? Cause that should be as easy as tweaking the Makefile.

[scalarwaves]

Indeed, libgwion.a or libgwion.so would be quite useful, if you could manage it.

gwion_all.h is awesome, thanks mate!

[fennecdjay]

Looking at it 😄

[fennecdjay]

Maybe you can add

libgwion.a: ${lib_obj}
  ${AR} ${AR_OPT}

to your Makefile (line 74).

---

I'm gonna clean my current work and hopefully push soon.

[scalarwaves]

When trying to add that to makefile I got a
Makefile:74: *** missing separator. Stop.

[fennecdjay]

Ins't that because you pasted it and hence loosed the leading TAB of line 2?
Anyway I be pushing in a few minute. Hopefully you'll tell me then.

[scalarwaves]

Yep, that was the problem. I got it working by fixing the tab and adding libgwion.a to the all: target. When you push I'll pull your changes. This is really cool!

[fennecdjay]

I already pushed, just waited for this to finish to warn you 👍

[scalarwaves]

Ok, GCC and some Clang builds succeeded. Does the libgwion.a target need to be added to the all: target? Like this:
all: options util/libgwion_util.a ast/libgwion_ast.a libgwion.a ${GW_OBJ} ${jit_obj}

[fennecdjay]

Not yet.

...

Coming Soon 😃

---

Yes clang/windows builds fail due to some header inclusion issue I have not fixed yet.
@scalarwaves is it an issue for you right now?

[scalarwaves]

Clang is no issue right now, I’m mostly using gcc.

[fennecdjay]

As I understand you might use Gwion inside tgtracker. How do you plan sound output?

[scalarwaves]

That's still to be decided. I want tgtracker to be cross-platform as much as possible, so the current plan is to use Rust bindings rsoundio to libsoundio, which can output to:

• JACK
• PulseAudio
• ALSA
• CoreAudio
• WASAPI

The other option is the Rust library cpal, which can output to:

• Linux (via ALSA)
• Windows
• macOS (via CoreAudio)
• iOS (via CoreAudio)
• Emscripten

I would really really like a Chuck-like language for livecoding in tgtracker, whether it's Chuck, Gwion, or both. I'm in a bit of a crazy mood where I'm coming up with all these ideas to add to tgtracker and feature bloat is a looming problem.

[fennecdjay]

So as far as I understand it, you'll do mixing in tg. You're gonna need a driver to input/ouput
data in/out Gwion. I'll be glad to help if it's the case.

---

EDIT: There is a soundio driver, but that might not be relevant to your problem and it is not yet ported to the new driver system.
Maybe you can look here and there to find actual code. (I use ALSA)

[scalarwaves]

Yes thank you. I'm very new to systems programming so I need all the help I can get. I'll focus on audio IO and see if i can get some input and output streams and a mixer. I'll also setup bindgen to attempt codegen for gwion_all.h and see how that turns out.

[scalarwaves]

I'm setting up a copy of gwion tailored to my dev environment which can be very picky about some things ugh As much as I love ChucK, the project layout is frustrating. I like how you've structured your code. Speaking of binding to other languages, have you ever thought about a Chuck => Gwion bridge? Since the syntax is sooo similar, shouldn't be too hard to translate one to the other.

[fennecdjay]

I like how you've structured your code.

Happy to read that, I guess that's kind of a point of view.
I don't think one can achieve fully automatic Chuck => Gwion bridge easily.
(UAana's, STK, would need a matching plugin).
But a simple bash script could be handy 👍

---

Thank you for your interrest.

---

---

EDIT
The best way would probably be using the Chuck parser to generate the AST, and use the AST to generate Gwion code.

@scalarwaves Is there any place whe can discuss this problem?
Maybe a repo in your Organization would be nice 😄

[fennecdjay]

If you're OK, @scalarwaves, I close this issue as we have a better place for this discussion.