Some mainstream language for custom modules

[Darkhog]

You plan on using Pixilang for module making, but this may detract module writers. How about using Lua which is modern, grown up language? All you'll need is to write API to access SunVox's internals and actually make sound.

Why Pixilang may detract people? Well, they'll have for once learn pretty niche language just to make music module for SV. Such coder will probably say "kthxbai, I'll go make Buzz modules in language that I actually know". On the other hand, many people know Lua (certainly more than know Pixilang), so there is bigger chance that coder who knows Lua will happen to want to write module for SV.

[NightRadio]

Sorry, i can't answer for sure, because for me this question is still open.
In some aspects you are right. Lua is more popular language, of course. But for the sound synthesis it is not much better than Pixilang. In both ways we need some DSP API and GUI API. These functions are almost ready for Pixilang. Also the Pixilang has a lower barrier to entry, in my opinion :)

[SolarLune]

I'd vote for Python personally, but any support is definitely better than others. I'm pretty sure someone would pick up a simpler language like Pixilang to create a couple of modules.

[trackhead]

I´m not a programmer, but perhaps it would be an idea to integrate jesusonic.

http://reaper.fm/sdk/js/js.php
http://www.cockos.com/jesusonic/

[geckojsc]

I agree, Lua is a really nice language and I would be happy to write plugins with it. One benefit would be the potential to replace the standard Lua interpreter with LuaJIT on certain platforms, which could give great performance improvements.

I've never written anything in Pixilang but it sounds quite simple and I would be happy to learn it. I think plugin-writing capability is an important feature, but I don't mind whether we use Pixilang, Lua, or another language. I'm not sure about Python, some programs I've seen that embed Python for scripting seem quite bloated. Compared to other languages I don't think Python is so good as a lightweight embedded scripting language.

On IRC, Fuzzix brought up the issue about scripting languages not being allowed on the appstore, but I think Apple have relaxed their stance on that (e.g.Codea for iPad), so I hope that isn't a problem.

[NightRadio]

Unfortunately Apple stance is unchanged. You can use any languages and engines in your code, but you can't load plugins from any external sources. All plugins must be included to SunVox distribution.

[Darkhog]

Nightradio, but you can include Lua in your code using static linking. All you will have to do is to load Lua files or execute code entered into some text area field inside sunvox.

[NightRadio]

Darkhog,
of course. For iOS one way only available - include all plugins at the SunVox compilation stage.

[beefinator]

I think it doesn't really matter what language sunvox plugins are coded in; there will always be people who wish it were in a different language.

Personally, I would like LOLCODE.

[gilzad]

I can has sunlib?

While trying to create a physically modelled accordeon module, I noticed that I desperately need scripting capabilities in Sunvox.
I wouldn't mind if the language is Pixilang then. It's very C-familiar and easy to understand. But the biggest benefit would be that NightRadio already has written a compiler for it, thus he knows how the parser should work and how an internal editor should highlight the code on one side. On the other side he also knows how sunvox has to be expanded for Pixilang. I actually found it easier to understand than Lua But I'm not being an enemy of Lua or anything else either. I'll be fine with anything.

I've been thinking of such a scenario:

Codeable modules have a 'code' property that can be accessed via the context menu.


Once you have entered the code menu, an inbuilt code editor will be shown.
This example shows how the note volocity and note range of the MultiSynth is being determined in an if clause. Since we're in the code window of the MultiSynth, any property of itself is accessed through the objective keyword 'this'. We assume that a fictional enum called 'NOTES' allows us to compare notes like numbers. Just one of many possible ideas of course. Not claiming to be the best.
Based on that comparison the cutoff frequency of a chained filter shall be adjusted to some value. To achieve that, we call a fictional proprietary function called GetModule() that would offer access to the passed module number (08 in this case). Ideally we can cast an interface object to the type of module we want to mess with (Filter in this case) and finally access its properties by using namespace notation again ($myFilter.Freq).

A very simple example and of course this is just my own little imagination. I'd be fine with any type of notation and convention, but I really see a big benefit of such a scripting realm in SunVox.

Sorry for bumping up this thread. I really wanted to know how you think about some solution like that.

edit: word correction

[Darkhog]

Gilzad, cool idea. Me wants it.

[dusicyon]

I think it doesn't really matter what language sunvox plugins are coded in; there will always be people who wish it were in a different language.

Personally, I would like LOLCODE.

I agree. I don't mind much about it, sunvox is great now and getting better.