Hi,
It's more a thought than a real feature request but I think having a scripting API that exposes various parts of the application would be a great improvement. It will allow developers to create custom plugins. When I say "various parts" I mean the UI, the pattern edition, the pattern order table, the modules... I don't know how difficult it could be to implement but there are some existing language interpreters like LUA that can be easily embedded into an existing software.
voilà!
Scripting API
Re: Scripting API
It's not embedded within SunVox but there is a Python package called radiant-voices that can read/write/modify SunVox files. 99% compatible with SunVox.
https://github.com/metrasynth/radiant-voices
https://github.com/metrasynth/radiant-voices
Re: Scripting API
Thank you so much!! I was not aware of that Python lib. Currently I'm writing a small tool that parses custom scripts and compile into XM files so this library opens new horizons to me
I will give a try this week but I'd still like to know what NightRadio thinks about the scripting API.
I will give a try this week but I'd still like to know what NightRadio thinks about the scripting API.
- leondustar
- Posts: 138
- Joined: Tue Feb 28, 2017 12:40 am
- Contact:
Re: Scripting API
iirc this would put certain builds (ios) at risk because scripting engines and appstores usually don't mix.
On one hand I could imagine the non-mobile apps support some kindof scripting language, but that could introduce the following effects:
A: some platforms would not include certain machines (ios)
B: that would break the every-sunvox-patch-runs-everywhere tradition
If sunvox would include a scripting language, I would go for the smallest footprint and only allow a small set of operations.
I would go for integrating one of these, and disabling bindings to keep things portable:
* libPd https://github.com/libpd which supports dsp + logic + huge amount of vanilla synth/effect patches (ps. pdlib has around 25 operators)
* lua by 'borrowing' protoplug code: http://www.osar.fr/protoplug/
* javascript, the most popular scripting language of the web using this tiny javascript lib: https://github.com/MarcoLizza/tiny-js for dsp+logic
* faust: http://faust.grame.frdsp + (harder to write) logic + small amount of faust synth/effect patches
On one hand I could imagine the non-mobile apps support some kindof scripting language, but that could introduce the following effects:
A: some platforms would not include certain machines (ios)
B: that would break the every-sunvox-patch-runs-everywhere tradition
If sunvox would include a scripting language, I would go for the smallest footprint and only allow a small set of operations.
I would go for integrating one of these, and disabling bindings to keep things portable:
* libPd https://github.com/libpd which supports dsp + logic + huge amount of vanilla synth/effect patches (ps. pdlib has around 25 operators)
* lua by 'borrowing' protoplug code: http://www.osar.fr/protoplug/
* javascript, the most popular scripting language of the web using this tiny javascript lib: https://github.com/MarcoLizza/tiny-js for dsp+logic
* faust: http://faust.grame.frdsp + (harder to write) logic + small amount of faust synth/effect patches
- leondustar
- Posts: 138
- Joined: Tue Feb 28, 2017 12:40 am
- Contact:
Re: Scripting API
hm i'm still thinking about this feature.
Formats like mod, xm, sunvox etc are great because you're 99% sure it will sound exactly like intended during playback.
Scriptable nodes therefore would be bad news, because they could 'break' a song / cause cpu-hogs (like some vsts) because of human error.
So where do we REALLY need scripting?
for creating synths?
we can already do that risk-free using metamodules.
custom interface?
again metamodules..
for creating effects?
again..metamodules..
for creating logic / controlled randomization?
see the probability pattern effects, phase and metamodule as arpeggio
controlling sunvox?
midi in mtc +controllers and keyboard shortcuts
MY CONCLUSION: i agree with the author of this post. I can't find any good reasons for scriptable RUNTIME features. Only EDITING features (like xrns plugins for renoise) to manage modules, notes and sampledata etc.
IDEA: I can imagine that sunvox editor:
A. will detect whether pixilang library is installed (=crossplatform)
B. if yes: scan for .pixi files when loading sunvox files (foo.pixi when loading foo.sunvox)
That way you could basically 'extend' metamodules by showing a pixi-container in a popup when pressing 'edit'.
The pixi file would simply hook into the sunvox-api & current slot
this could already open the door to new loaders, interfaces, visualisations, interactive samplers, new ways of editing etc (basically the power of pixi)...all without affecting the sunvox fileformat, editor, or violating the applestore / android guidelines.
I think for windows you can even create a vst(i) loader pixi-file using pixi's dllfeatures, forward notes to it, output the vst audio in on_process, sample notes etc.
Feedback on this simplifed idea please?
ps. I have abandoned the idea of scriptingnodes inside a sunvoxfile.
Formats like mod, xm, sunvox etc are great because you're 99% sure it will sound exactly like intended during playback.
Scriptable nodes therefore would be bad news, because they could 'break' a song / cause cpu-hogs (like some vsts) because of human error.
So where do we REALLY need scripting?
for creating synths?
we can already do that risk-free using metamodules.
custom interface?
again metamodules..
for creating effects?
again..metamodules..
for creating logic / controlled randomization?
see the probability pattern effects, phase and metamodule as arpeggio
controlling sunvox?
midi in mtc +controllers and keyboard shortcuts
MY CONCLUSION: i agree with the author of this post. I can't find any good reasons for scriptable RUNTIME features. Only EDITING features (like xrns plugins for renoise) to manage modules, notes and sampledata etc.
IDEA: I can imagine that sunvox editor:
A. will detect whether pixilang library is installed (=crossplatform)
B. if yes: scan for .pixi files when loading sunvox files (foo.pixi when loading foo.sunvox)
That way you could basically 'extend' metamodules by showing a pixi-container in a popup when pressing 'edit'.
The pixi file would simply hook into the sunvox-api & current slot
Code: Select all
fn on_load(){
// $name =sv_module_get_param_name(0,0)
}
fn on_edit(popup){ // when user clicks edit of metamodule
//popup.hidemoduleview = 1 // dont show modules+back button
// draw stuff here
ret(popup)
}
fn on_event(....){
}
fn on_process(in, out, nsamples) { // metamodule audio output
}
I think for windows you can even create a vst(i) loader pixi-file using pixi's dllfeatures, forward notes to it, output the vst audio in on_process, sample notes etc.
Feedback on this simplifed idea please?
ps. I have abandoned the idea of scriptingnodes inside a sunvoxfile.
Re: Scripting API
I think a SunVox-driven UI would be really cool, but I've had some luck with using Python in conjunction with SunVox clipboard files to pluck things out of SunVox by copying to SunVox clipboard, modify them and replace SunVox clipboard file, then paste them back inside SunVox. Not the same as in-place editing tools I know, but it's a workflow that's available today.
- leondustar
- Posts: 138
- Joined: Tue Feb 28, 2017 12:40 am
- Contact:
Re: Scripting API
Hm interesting, that's safer & more simple than my idea.
@nightradio: is it possible to access the clipboard in pixilang? Because that would be a great crossplatform way to write pixilang tools which can be used while sunvox is open (using copy/paste)
@nightradio: is it possible to access the clipboard in pixilang? Because that would be a great crossplatform way to write pixilang tools which can be used while sunvox is open (using copy/paste)
- NightRadio
- Site Admin
- Posts: 3955
- Joined: Fri Jan 23, 2004 12:28 am
- Location: Ekaterinburg. Russia
- Contact:
Re: Scripting API
Agree with this.MY CONCLUSION: i agree with the author of this post. I can't find any good reasons for scriptable RUNTIME features. Only EDITING features (like xrns plugins for renoise) to manage modules, notes and sampledata etc.
The new Pixilang 3.8 will be released with built-in SunVox functions. API is changed a bit (see the player from the last SunVox Compo), but you no longer have to load SunVox library (DLL, SO, etc.).
The next step - SunVox (editor only) with built-in Pixilang.
And the circle closes :) Pixi with SunVox, SunVox with Pixi.
Will be added in 3.8is it possible to access the clipboard in pixilang? Because that would be a great crossplatform way to write pixilang tools which can be used while sunvox is open (using copy/paste)
- leondustar
- Posts: 138
- Joined: Tue Feb 28, 2017 12:40 am
- Contact:
Re: Scripting API
@nightradio that sounds very interesting. I will have a look at the latest sunvox compo. Yes the circle will be complete (and then the universe will explode haha)
-
- Posts: 51
- Joined: Tue Dec 01, 2015 5:50 am
Re: Scripting API
I wish I knew where to start learning pixilang.....
I look forward to seeing some interesting things you guys are working on!
I look forward to seeing some interesting things you guys are working on!