Porting to gwion.

[fennecdjay]

I forked this repo and worked a bit on it.
Could you create a Gwion branch so that I can make a PR?

It works on my Machine 😄
And it should also on yours with the latest Gwion from the master branch.

I'm pretty happy it uncovered a few things in Gwion's implementation:

• a problem with global things being incorrectly freed
• a problem when overriding function
• reference arrays not behaving as in chuck

All is fixed now 🍾

I tried to modify as little code as possible, just using const where applicable, and the new final keyword where requested in the comments.

I have not looked at the other directory yet, I might try it at some point, hoping it'll be as interesting as this one.
Could the LinuxSampler plugin suit your needs?

---

I don't know how to report that, but it seems (looking at top and perf stat results), that this is more efficient than the chuck version 👍

[forrcaho]

Let's create a repository of Gwion sample code under the Gwion project, that doesn't necessarily have to port all the ChucK code I have here, and can (hopefully) have other examples as well. Maybe gwion-example-code (adding example to the repo name because they would be "official" examples of Gwion syntax).

I only created the "base" case for my additive synthesis code because ChucK doesn't have abstract classes; I suggest we get rid of the base case and make Additive.gw and AdditivePartial.gw abstract. That will help to demonstrate more of Gwion's syntax.

As for the fluidsynth directory, that is code I wrote to take advantage of the hooks I wrote for ChucK's fluidsynth chugin to support fluidsynth's tuning API. Do I understand correctly that Gwion uses plugins both for basic functionality and the sort of hooks into external libraries that ChucK uses chugins for? If so, maybe we can write a Gwion fluidsynth plugin.

[fennecdjay]

I'm not quite sure why you want those classes abstract, could you explain it to me?
Otherwise, the idea of an example repo seems pretty good.

[forrcaho]

The subclassed versions, AdditiveInst01 / AdditivePartialInst01 and AdditiveSqrTri / AdditivePartialSqrTri illustrate how I thought these classes would be used. That is, Additive.ck describes an instrument made out of an array of partials, and AdditivePartial.ck is the class that all of the partials belong to, but the precise relationship of how these are supposed to work together for any specific additive instrument (e.g. the exact frequency and amplitude of a given partial and how those change with time) is something I thought would be specified in subclasses.

The only reason that the base class contains a concrete implementation (a simple saw wave) is because ChucK doesn't have abstract classes, meaning I had to put something in there. The design would be much more consistent if the saw wave (if indeed we wanted to implement a saw wave with additive synthesis) was implemented as another set of subclasses, and the base classes were abstract.

I hope that makes sense.