Some pointers on JavaScript...

RELATED
PRODUCTS

Post

Post in this thread if you found good resources for Java Script and Bitwig Controller Scripting.

If you wonder: I removed my old recommendations since they were so out of date and mostly for v1 of Bitwig - this thread started in 2014... ;-)
You may also find some of the initial posts to be no longer relevant, since these days you can also use Java for creating Controller Scripts.

Some newer things that may be helpful:

The first thing you need is a good code editor:
Microsofts "Code" has become one of the best free code editors over the last couple of years:
https://code.visualstudio.com
If you don't want MS snooping after you, you may disable the Telemetry in Settings and hope for the best... ;-)
There are many tools for Java Script development available as "Extensions"

Next, get yourself into the groove with some tutorials:
Jürgen Moßgraber aka "moss" on KVR has created a video series of tutorials that is probably the best introduction to how things work available. Here's a link to the playlist:
https://www.youtube.com/watch?v=l4AuiQ8 ... O3luQCFQR2

Now create your first script:
To create a new Controller Script, you can either start from an existing one or use the Generator that comes with Bitwig Studio (version 4 ATM of writing):
Go to the Dashboard (click the Bitwig Logo at the top of the Bitwig Window) -> Help -> Documentation. There you find the API Reference and a button labeled: "New Project..." click that and fill in the fields to create either a Java or Java Script template.

And this is how you can see what's going on:
To show the "Control Script Console" you can create a shortcut in the Dashboard -> Settings -> Shortcuts and search for "Show Control Script Console" - I use Shift+J for historical reasons...

The Console allows you to see output from your script for debugging.
One of the things I use the most is probably:

Code: Select all

function onMidi(status, data1, data2) {
    printMidi(status, data1, data2);
    ...
}
This will print every midi message the onMidi function receives to the Console so you know exactly what's coming in...
For other debugging you will want to use

Code: Select all

println(YourVariable);
To see for instance the state of a variable on runtime in the Console.

Best of luck and post here in this thread if you find other helpful information for Controller Scripting in Bitwig.

Cheers,

Tom
Last edited by ThomasHelzle on Fri Jul 30, 2021 3:10 pm, edited 10 times in total.
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." - Rumi
Sculptures ScreenDream Mastodon

Post

To me the biggest pain about JavaScript is its case sensitivity. Not the case (sic) with most other languages, but it can be hard to debug when all you've done wrong is write a letter in the wrong case.

Post

robojam wrote:To me the biggest pain about JavaScript is its case sensitivity. Not the case (sic) with most other languages, but it can be hard to debug when all you've done wrong is write a letter in the wrong case.
It'd be pretty much the same for anything else with a c-family syntax too.

As for Javascript itself, Doug Crockford's website (http://javascript.crockford.com/) and book (http://www.amazon.com/exec/obidos/ASIN/ ... rldwideweb) are amongst the best resources around for 'good' use of the language.
my other modular synth is a bugbrand

Post

It's been some years, but I did do some development work in C and C++. While I know there is some case sensitivity, I think most developers got lazy with it (keywords at least) as compilers would usually correct case.

Maybe the reason JavaScript stands out more is that the few times I wrote some, it was often without the help of a compiler and I had to debug based on the issues that a browser would raise when trying to run the code.

Post

Thank you Tom, looking forward to all the little tips. It's food for my inner geek :D
robojam wrote:Maybe the reason JavaScript stands out more is that the few times I wrote some, it was often without the help of a compiler and I had to debug based on the issues that a browser would raise when trying to run the code.
Javascript error reporting is at best ... well it's just rubbish really.

I've not done much with javascript either, except to change images on a web page or use it for form validation. Rather than read the huge Javascript manual and lose my monitor stand, I recently followed the Javascript course at http://www.codecademy.com. It starts off slow, if you are used to programming but by the end it goes a lot deeper into the language. I certainly picked up a lot of new information :)

Post

goatgirl wrote:Thank you Tom, looking forward to all the little tips. It's food for my inner geek :D
robojam wrote:Maybe the reason JavaScript stands out more is that the few times I wrote some, it was often without the help of a compiler and I had to debug based on the issues that a browser would raise when trying to run the code.
Javascript error reporting is at best ... well it's just rubbish really.

I've not done much with javascript either, except to change images on a web page or use it for form validation. Rather than read the huge Javascript manual and lose my monitor stand, I recently followed the Javascript course at http://www.codecademy.com. It starts off slow, if you are used to programming but by the end it goes a lot deeper into the language. I certainly picked up a lot of new information :)
I really didn't start writing javascript until last March with Push and them Maschine scripts. I hated it that much to stay away from it in my career.

I did write a compiler/cross compiler from ActionScript(Flex/PlashPlayer) that created javascript 3 years ago.:) (kind of what I wrote for Bitwig, how the js-stubs are created from Java interfaces)

Javascript has a weakness and a strength, on one had its weakness is it's strength and on the other had its strength is it's weakness and that is the prototype which makes it runtime dynamic. :)

The language being dynamic makes it virtually impossible to make a correct compiler for it, thus you get all these browsers and a million ways to do the same thing.

I can honestly say, my only dealings with the .js will be Bitwig and anything else I do uses a compiler. :)

Mike
Michael Schmalle
http://www.teotigraphix.com
Surfing on sine waves

Maschine4Bitwig - Studio, MK2, MikroMK2, MK1
http://www.teotigraphix.com/bitwig/maschine

Post

Well, with an editor like Komodo Edit or especially WebStorm I don't see it as much of a problem. Sure, it's easier to make certain mistakes in JS but other languages have their own traps ;-)
For stronger checking, look as jslint and other similar checkers, they catch a lot.
You can use them in the editors above.

I didn't find a good overview of what Rhinoceros in Java 1.8 can do yet. Would be interesting to see if there are some new tricks now.

Cheers,

Tom
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." - Rumi
Sculptures ScreenDream Mastodon

Post

ThomasHelzle wrote:Well, with an editor like Komodo Edit or especially WebStorm I don't see it as much of a problem. Sure, it's easier to make certain mistakes in JS but other languages have their own traps ;-)
For stronger checking, look as jslint and other similar checkers, they catch a lot.
You can use them in the editors above.

I didn't find a good overview of what Rhinoceros in Java 1.8 can do yet. Would be interesting to see if there are some new tricks now.

Cheers,

Tom
I use WebStorm for dev, all the IDEs are just using inference and a lexer based of a grammar that is not consistent throughout the javascript ecosystem.

Languages may have other traps, but having a grammar a compiler is created with creates boundaries, that once familiar with remove any traps that may exist.

I have actually made things with Rhino and it doesn't even come close to supporting all the constructs you will find in the wilds of Web development and what developers do. Why? because is actually a java compiler under the hood that needs a set grammar to compile the .js files fed to it.

In my experience, a lot of the problems with javascript in web dev is, you get these "artist" scripters that invent convoluted javascript constructs that wipe away any type of solid software design patterns established in the last 30 years.

The part I am specifically talking about is frameworks in javascript, scalability versed performance. i have dona a lot of work in this area and a compiler can do a tremendous amount of things to code that javascript compilers can't because it's dynamic nature.

Even Mozilla is writing javascript ASM that is close to the metal performance type stuff and they are saying, you MUST do it this way, which is basically forcing developers to write scripts their compiler can optimize.

Anyway. :)

Mike
Michael Schmalle
http://www.teotigraphix.com
Surfing on sine waves

Maschine4Bitwig - Studio, MK2, MikroMK2, MK1
http://www.teotigraphix.com/bitwig/maschine

Post

I'll second the recommendation of Crockford's JavaScript: The Good Parts. It's out of date for modern JavaScript/ECMAScript, but it's actually a very good resource for the JavaScript engine in Bitwig, which is Nashorn.

Nashorn mainly targets the ECMAScript 5.1 specification for the language, but it adds a few features from ECMAScript 6: namely block scoping and the addition of let and const for declarations (better than function-scoped var declarations), et cetera.

For details, see here: http://openjdk.java.net/jeps/292

For what it's worth, I think JavaScript is actually a pretty good language if you stick to the "good parts" and avoid the "bad parts." Its support for things like higher-order functions and closure make it very powerful. Even its dynamic typing isn't necessarily a bad thing. I think the three biggest problems with JavaScript development are:
  • It was created very rapidly, in a roughly two-week period, and despite some brilliance to the design, there are "bad parts" that were put in and can't be removed. (But you can avoid using them, which is almost as good as removing them.)
  • People tend to use it without understanding the nature of the language, which leads to frustration when it doesn't work like they expected. This is compounded by the syntax's superficial similarity to Java (which was intentional, but somewhat unfortunate).
  • Even when its fundamental nature is understood, some programmers try to make it into something it's not instead of working with its strengths. Even the ECMAScript committee isn't immune to this tendency.
All that said, I'm not sure that JavaScript is the best choice for supporting a controller in Bitwig. It's not a problem with JavaScript, itself. The potential issue is that Nashorn has been discontinued/deprecated. As long as Bitwig uses a Java version that includes Nashorn, JavaScript in Bitwig should still be supported. But with Nashorn being deprecated and marked for removal, the future of JavaScript support in Bitwig is uncertain. Maybe Bitwig will stick with older Java versions (and thus keep Nashorn and JavaScript support). I don't know.

If you want to write code and support a controller, at this point you are probably better off using a language that targets the JVM and writing it as a Bitwig Extension. So you could use Java, which is the "native" fit for Bitwig (Java used to be my main language, but I find it painfully verbose, these days). Or you could use something that compiles to Java bytecode: Kotlin, Scala, Groovy, et cetera.

Of course, having recommended that, I'll also confess that I was writing a new controller for the Akai MPK mini mkII last weekend, and I used JavaScript. It was faster and easier to get going with JavaScript than setting up to develop a Java-based extension. (If I do end up coding such an extension, I think I'll tool up with Kotlin, instead of Java. I've enjoyed using Kotlin for Android development.)
Last edited by Philotomy on Sun Feb 24, 2019 8:48 pm, edited 1 time in total.

Post

Thanks for this crucial information. Now we just need a tool which translates javascript extensions into a java Bitwig extension...
Will there be a scripting workshop at SuperBooth like last year?

Post

Tj Shredder wrote: Wed Feb 20, 2019 3:28 pmThanks for this crucial information.
You're welcome. Keep in mind that Nashorn is still there, for now, and Bitwig isn't forced to follow Java version updates, so there's no need for alarm or immediate action. It's more like a long term consideration than anything else. As far as I know, there's been no official word/comment on any change in JavaScript controller support in Bitwig in the near future.
Will there be a scripting workshop at SuperBooth like last year?
Was that question was directed at me? If so, I have no idea. (I'm just some random musician that uses Bitwig and who also happens to be a professional programmer. I have no affiliation with Bitwig GmbH.)

Post

IMO it would be pretty bad if Java Script would be removed. I also am not too fond of new controllers being written in Java if their source isn't available. The whole Controller Script idea isn't exactly userfriendly in the first place, but JS at least is relatively approachable for people who did any kind of scripting before. Java and compiling is quite another matter. And the source being open is quite important, since the documentation isn't exactly a glaring source of enlightenment ;-)

It's great to have Java for bigger projects like the ones Moss writes, but for the average user, it's total overkill IMO.
I actually still hope that one day we will see some graphical tool to click and drag a typical controller script together from components so that normal humans/musicians can use it.

I actually discussed such a tool back in the day with the devs after 1.0 was released, but of course that wasn't exactly the highest priority at the time...

I guess we'll see what comes out of this in due time :-)

Cheers,

Tom
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." - Rumi
Sculptures ScreenDream Mastodon

Post

ThomasHelzle wrote: Wed Feb 20, 2019 7:45 pm IMO it would be pretty bad if Java Script would be removed...JS at least is relatively approachable for people who did any kind of scripting before.
That's a good point. (I wonder if Groovy might be a reasonable alternative?)

Personally, I like JavaScript and I hope it remains supported in Bitwig for a long time. I think it's unfortunate that Nashorn has been deprecated and marked for removal in Java. But Bitwig isn't dependent on the latest versions of Java. Bitwig can bundle and use versions that support Nashorn without worrying about the latest Java versions. So it's something to consider, but it's not an immediate problem.
...the source being open is quite important...
I agree; I like open source software, especially for things like this.
It's great to have Java for bigger projects like the ones Moss writes, but for the average user, it's total overkill IMO.
I agree with this, too. In fact, I'd say even writing a controller in a scripting language like JavaScript isn't something I'd expect of the average user. (But I'm very glad Bitwig allows us to do this.)

Post

Thinking about alternatives, whatever happened to the Python bindings that seem to have been available for a while some time ago?

Post

The best advice I can give for anyone wanting to use JavaScript is:

Don't.

Use Kotlin instead. :)

Although I'm glad that Bitwig allows users to write controllers in JavaScript, the fact that they *also* allow us to write controllers in Java makes this a really easy decision. Use Java, or Kotlin, or any JVM-compatible language before resorting to JavaScript.

Post Reply

Return to “Controller Scripting”