I still think this depends a lot on what you are going to write and where you come from.
For a simple controller integration, the directness of JS is hard to beat. Just save and the script is reloaded, the error messages got better in the meantime (compared to BWS version 1.0) and JS also got better tools.
Of course, if you are a seasoned coder, whatever floats your boat is fine, but if you just start out and tip your toes into scripting, I'd still recommend starting with JS.
Just the same, with the grid in BWS 3, I could totally see a node based visual tool to create controller integrations.
Digging https://cables.gl here, also written in JS in large parts.
Cheers,
Tom
Latest News: Bitwig Updates Bitwig Studio to 5.2
Some pointers on JavaScript...
-
- KVRAF
- Topic Starter
- 6305 posts since 9 Dec, 2008 from Berlin
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." - Rumi
ScreenDream Instagram Mastodon
ScreenDream Instagram Mastodon
-
- KVRer
- 14 posts since 27 Mar, 2017
I'd rank Kotlin pretty high on my list of languages I enjoy using. Other JVM languages I'd consider include Scala and Clojure. I'd rank any of those higher than JavaScript in a general ranking of languages I enjoy using. So I know where you're coming from.
However, for something relatively short and simple like a controller, I think JavaScript is fine (the trick to JavaScript is to only use the "good parts"). Of course, you could also use any language than transpiles to JavaScript. Wouldn't even need to be a JVM language, in that case.
-
- KVRer
- 14 posts since 17 Jan, 2015
I also think that a grid based controller "api" is the way to go (at least as an on ramp to the scripting api if not a replacement). Ableton has this kind of thing via Max MSP.
I am also digging how Cables.gl do this. In fact I have Bitwig midi notes as a midi input to Cables and have some controller functionality mapped in both Bitwig and Cables... so when I increase the volume of a track/channel in Bitwig it also transforms a visual in Cables.
I am also digging how Cables.gl do this. In fact I have Bitwig midi notes as a midi input to Cables and have some controller functionality mapped in both Bitwig and Cables... so when I increase the volume of a track/channel in Bitwig it also transforms a visual in Cables.
-
- KVRist
- 74 posts since 12 Dec, 2007 from Fort Bragg, CA
completly disagree with needing a "grid" style API. Node graph editors for coding are such a pain in the butt to use and do any debugging.
IMO, What would be better would be actual documentation on how the scripting works and more support in the area. Thankfully moss has made some very helpful documents on the matter. Maybe even support from the bitwig crew to improve whats already there.
IMO, What would be better would be actual documentation on how the scripting works and more support in the area. Thankfully moss has made some very helpful documents on the matter. Maybe even support from the bitwig crew to improve whats already there.
---------------------------------------------------------------
http://kirkwoodwest.com/
http://kirkwoodwest.com/
-
- KVRAF
- 8828 posts since 6 Jan, 2017 from Outer Space
I completely (dis)agree, as anything I did in the past 25 years in Max/MSP would have never happened with lines of code programming. Node graph programming is such a relief compared to scripting languages...
But it is simply a different kind of thinking and a matter of taste.
I am not sure though, if this is true for controller handling, the access to the Live API within M4L is as much a pain as it is to do it in Java or Javascript. I would love to see as much a Grid object or a device which can load Pd patches as one which can load a Java program like the mxj object in Max...
-
- KVRAF
- Topic Starter
- 6305 posts since 9 Dec, 2008 from Berlin
I would also say that this isn't a yes or no but a gradient.
For many situations, a node based solution (or other graphic approach, but visual and easy to grasp) would be great, since not every controller situation needs a complex script, sometimes it's just connecting some stuff with certain CCs - more complex than just midi-learn but way less complex than a full Push script.
If you think about something like Moss Flexi script and imagine that with a fullscreen graphical interface and modular instead of just the limited controls available in the current API for the preferences, I'd say that a lot of people would be able to do their own setups that currently aren't.
Yes, that also has to do with the abysmal documentation of the API, but that's not all of it. A major factor is, that coding is a kind of yes/no thing with many people, especially musicians.
So the discussion in this thread isn't reflecting reality. Discussions about using Kotlin over JS are absolutely lost on people who can't even fathom one single line of code...
And this could be done nicely with nodes: drag in a knob, a button, a bank of 8 knobs, a switch between states, have the usual settings for all of those and tinker together what you need...
And the world is even bigger than that when you combine the approaches. I used to work in SideFX Houdini a lot, a 3D software that combines nodes with code in such a brilliant way, that the issues with nodes, that become absolutely idiotic when doing stuff at the atomic level, are solved simply by having nodes that contain code and are compiled on the fly.
What you gain is that you can work visually with all the benefits of that realm where it makes sense and then enter some lines of code (but without all the boilerplate) where the same lines would need 50 nodes.
In the end, I don't care too much either way, since I am able to create the scripts I need in JavaScript myself.
But for Bitwig as a DAW, I think it's important to have a simpler and more approachable solution for integrating controllers at one point.
The API of course would stay and get some decent documentation for those able and willing to use it.
But I guess that's something for version 10...
Cheers,
Tom
For many situations, a node based solution (or other graphic approach, but visual and easy to grasp) would be great, since not every controller situation needs a complex script, sometimes it's just connecting some stuff with certain CCs - more complex than just midi-learn but way less complex than a full Push script.
If you think about something like Moss Flexi script and imagine that with a fullscreen graphical interface and modular instead of just the limited controls available in the current API for the preferences, I'd say that a lot of people would be able to do their own setups that currently aren't.
Yes, that also has to do with the abysmal documentation of the API, but that's not all of it. A major factor is, that coding is a kind of yes/no thing with many people, especially musicians.
So the discussion in this thread isn't reflecting reality. Discussions about using Kotlin over JS are absolutely lost on people who can't even fathom one single line of code...
And this could be done nicely with nodes: drag in a knob, a button, a bank of 8 knobs, a switch between states, have the usual settings for all of those and tinker together what you need...
And the world is even bigger than that when you combine the approaches. I used to work in SideFX Houdini a lot, a 3D software that combines nodes with code in such a brilliant way, that the issues with nodes, that become absolutely idiotic when doing stuff at the atomic level, are solved simply by having nodes that contain code and are compiled on the fly.
What you gain is that you can work visually with all the benefits of that realm where it makes sense and then enter some lines of code (but without all the boilerplate) where the same lines would need 50 nodes.
In the end, I don't care too much either way, since I am able to create the scripts I need in JavaScript myself.
But for Bitwig as a DAW, I think it's important to have a simpler and more approachable solution for integrating controllers at one point.
The API of course would stay and get some decent documentation for those able and willing to use it.
But I guess that's something for version 10...
Cheers,
Tom
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." - Rumi
ScreenDream Instagram Mastodon
ScreenDream Instagram Mastodon
-
- KVRAF
- 8828 posts since 6 Jan, 2017 from Outer Space
Just as you mention it, it would be stunning to have a graphical version of flexi. As controller scripts could also be made with Midi learn, and are still different than the usual project based Midi control possibilities, maybe we can encourage the devs to do that in a way which would immediately be also the basis for a Midi Grid...
I think its more for version 4...
I think its more for version 4...
-
- KVRist
- 74 posts since 12 Dec, 2007 from Fort Bragg, CA
I have to say, i like this discussion. 
I could see a use for the gui thing but i'd still just like to have a working scripting back end. Its getting better with the hardware bindings... which will also make it easier to do a node based thing.
I agree certain node based systems are great... Shader graphs is a perfect example where its more helpful in cases. Somehow the GRID really makes sense here too. I wouldn't mind trying a JavaScript version of that tho...
When it comes down to code, i just don't understand why people think a graph with logic is more accessible than code? Like the Unreal Engine vs Lua script... I think the biggest advantage people find is in a visual system you get pre-defined environment with all the commands in a gui making it easier to go. Whats missing in the bitwig world is having a true environment where its clear what code does what, helper functions, snippets, etc. All those things take ramp up time to get on with a new API.
I think the new hardware surface tool is really slick for example. With the bindings it could be the beginning of a gui based system. But still i would personally love to see the core be much stronger than it is now with more access to internal bitwig objects.
I could see a use for the gui thing but i'd still just like to have a working scripting back end. Its getting better with the hardware bindings... which will also make it easier to do a node based thing.
I agree certain node based systems are great... Shader graphs is a perfect example where its more helpful in cases. Somehow the GRID really makes sense here too. I wouldn't mind trying a JavaScript version of that tho
...When it comes down to code, i just don't understand why people think a graph with logic is more accessible than code? Like the Unreal Engine vs Lua script... I think the biggest advantage people find is in a visual system you get pre-defined environment with all the commands in a gui making it easier to go. Whats missing in the bitwig world is having a true environment where its clear what code does what, helper functions, snippets, etc. All those things take ramp up time to get on with a new API.
I think the new hardware surface tool is really slick for example. With the bindings it could be the beginning of a gui based system. But still i would personally love to see the core be much stronger than it is now with more access to internal bitwig objects.
---------------------------------------------------------------
http://kirkwoodwest.com/
http://kirkwoodwest.com/
-
- KVRAF
- 4590 posts since 7 Jun, 2012 from Warsaw
Well, for script languages there certainly are node-based solutions (Node-RED comes to my mind). For audio devices, there was Synthmaker / Flowstone.For many situations, a node based solution (or other graphic approach, but visual and easy to grasp) would be great, since not every controller situation needs a complex script, sometimes it's just connecting some stuff with certain CCs - more complex than just midi-learn but way less complex than a full Push script.
For your particular use case... still, the niche might be too little for anyone to develop it
Audio companies offer node-based approach for their own ecosystem only (Ableton Max for Live, NI Reakor, Bitwing grid). While generic programming solutions know nohing about audio world, or MIDI.Blog ------------- YouTube channel
Tricky-Loops wrote: (...)someone like Armin van Buuren who claims to make a track in half an hour and all his songs sound somewhat boring(...)
Tricky-Loops wrote: (...)someone like Armin van Buuren who claims to make a track in half an hour and all his songs sound somewhat boring(...)
-
- KVRAF
- 8828 posts since 6 Jan, 2017 from Outer Space
As soon your way of thinking is parallel, its much easier to grab. Code is inherently sequential thinking, which turns parallel structures into a nightmare of keeping track what is going on...
I guess those who are good at reading code, have a node representation in their brain of it.
If its easy for you, you are entitled to call yourself a genius...; - )
Do you remember the flow charts for designing software? That is node based, and now imagine if you just need to draw the flow chart, and the program does the coding automatically. That is my experience of Max programming. And even further, it is also the UI if some nodes are UI elements like a fader...
-
- KVRAF
- Topic Starter
- 6305 posts since 9 Dec, 2008 from Berlin
Yeah, the main thing about node graphs is a.) readability and b.) compactness (when done right and if it isn't used for doing atomic math).
a.) is great in a software like Houdini where it's much simpler to get a gist of what is done even in a complex graph by just looking at it for a moment, it has a flow, a direction and a structure clearly visible.
The same is true in the poly grid - the same thing I do with a handful of nodes there would be very hard to read in comparison as code. This is more true in some situations and areas than others of course.
b.) Nodes shine for me when they encapsulate something complex in a single node. For instance in Houdini, there is a "shortest path" node that computes the shortest connection from one or several points on a grid to some or all other points on that grid. No matter if I even know how that algorithm works, it's one node compared to several hundred lines of code.
This of course breaks down if you do basic math with nodes or read or write memory bit by bit. There code shines and the hoops you have to jump through and the clutter of nodes make them idiotic.
That's why I love the combined approach so much.
And that's my main point here: In a ton of cases, the musician would be easily able to drop down a node that represents 8 knobs visually, set their CCs and connect that for instance to a bank node that represents 8 tracks and their volume etc.
For those who think in code anyway this may sound trivial to do in the API, but even though I wrote 3D shaders in C before and used many other languages, to this day I only can accept what a closure is and how it works in JS and how I use it for a callback in the Bitwig API - I still find it just as alien as on day one.
Like Crockford in his talks says: It needs the next generation of programmers to grok the next language, since our brains are basically programmed themselves by the languages we use.
Now take the average guitarist or pianist and tell him that in order to use the faders on his masterkeyboard the way he wants, he needs to understand concepts as totally alien as that closure etc.. He want's to make music, not learn a language and coding.
I wrote scripts for a Bitwig user for a while who is fully able to write all the business software for his company himself in basic, but even after years didn't grok JS and the API. And he doesn't have the time either, since coding isn't his job, mixing and mastering is.
It's simply about humans being very different and having very different ideas about what they want to spend their life on.
There's no right or wrong in all this, just different approaches and priorities.
And even on the day of release the devs were very aware that the need to deal with "scripts" for all the different input devices is a crutch at best and doesn't fit the general audience of a DAW.
For some it's not an issue at all, but I'd guess that's maybe 0.1% of the users, if that.
And again, the API of course has it's place and needs to stay and improve, it just doesn't do anything for most users.
Cheers,
Tom
a.) is great in a software like Houdini where it's much simpler to get a gist of what is done even in a complex graph by just looking at it for a moment, it has a flow, a direction and a structure clearly visible.
The same is true in the poly grid - the same thing I do with a handful of nodes there would be very hard to read in comparison as code. This is more true in some situations and areas than others of course.
b.) Nodes shine for me when they encapsulate something complex in a single node. For instance in Houdini, there is a "shortest path" node that computes the shortest connection from one or several points on a grid to some or all other points on that grid. No matter if I even know how that algorithm works, it's one node compared to several hundred lines of code.
This of course breaks down if you do basic math with nodes or read or write memory bit by bit. There code shines and the hoops you have to jump through and the clutter of nodes make them idiotic.
That's why I love the combined approach so much.
And that's my main point here: In a ton of cases, the musician would be easily able to drop down a node that represents 8 knobs visually, set their CCs and connect that for instance to a bank node that represents 8 tracks and their volume etc.
For those who think in code anyway this may sound trivial to do in the API, but even though I wrote 3D shaders in C before and used many other languages, to this day I only can accept what a closure is and how it works in JS and how I use it for a callback in the Bitwig API - I still find it just as alien as on day one.
Like Crockford in his talks says: It needs the next generation of programmers to grok the next language, since our brains are basically programmed themselves by the languages we use.
Now take the average guitarist or pianist and tell him that in order to use the faders on his masterkeyboard the way he wants, he needs to understand concepts as totally alien as that closure etc.. He want's to make music, not learn a language and coding.
I wrote scripts for a Bitwig user for a while who is fully able to write all the business software for his company himself in basic, but even after years didn't grok JS and the API. And he doesn't have the time either, since coding isn't his job, mixing and mastering is.
It's simply about humans being very different and having very different ideas about what they want to spend their life on.
There's no right or wrong in all this, just different approaches and priorities.
And even on the day of release the devs were very aware that the need to deal with "scripts" for all the different input devices is a crutch at best and doesn't fit the general audience of a DAW.
For some it's not an issue at all, but I'd guess that's maybe 0.1% of the users, if that.
And again, the API of course has it's place and needs to stay and improve, it just doesn't do anything for most users.
Cheers,
Tom
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." - Rumi
ScreenDream Instagram Mastodon
ScreenDream Instagram Mastodon
-
- KVRer
- 19 posts since 2 May, 2004
Hey guys, anyone know someone I can hire to make me a custom script for my controller? I dont have time to learn javascript. Thank you!
Kevin
www.myspace.com/kevinalvesakagift
Baroque, Blackhole, Lost Language, Solaris
Bestport artist: Gift
www.myspace.com/kevinalvesakagift
Baroque, Blackhole, Lost Language, Solaris
Bestport artist: Gift
-
- KVRAF
- 8828 posts since 6 Jan, 2017 from Outer Space
Which controller? Also custom? What should it do?
The main part, designing the way it should interact you would still have to define. Depending on that, it could be a hell of a lot to program or be as simple as assigning a bunch of controls in Moss’ Flexi…
I would first see if Flexi can nail it…
-
- KVRAF
- Topic Starter
- 6305 posts since 9 Dec, 2008 from Berlin
Yeah, that would also be my recommendation these days, but it didn't exist when this thread (and Bitwig) started...
Although I never got the JS bindings for the API to show up in Code like I could in Komodo (which in the meantime I would no longer recommend BTW.).
Anybody got that working?
I mean the ones in "...\Bitwig Studio\4.0.1\resources\doc\control-surface\js-stubs".
Cheers,
Tom
Although I never got the JS bindings for the API to show up in Code like I could in Komodo (which in the meantime I would no longer recommend BTW.).
Anybody got that working?
I mean the ones in "...\Bitwig Studio\4.0.1\resources\doc\control-surface\js-stubs".
Cheers,
Tom
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." - Rumi
ScreenDream Instagram Mastodon
ScreenDream Instagram Mastodon
