Tom Swirly

Since I just posted a request, I thought it only fair to add some actual content as a balance.

I do a live show and I want a way to "sequence" an entire show and control it from my instrument without ever having to touch the mouse during the whole show. I wanted a way I could hook together sets from songs without having to build new max patches for each set. I wanted a much better way to manage all the many sounds I have from my instrument.

To do this, I've been working on a moderately large Javascript program for Max - right now it's 1423 lines of Javascript, just over half of which is unit tests, as well as a half dozen data files (but I'm expecting a lot more data files (in JSON) once it's all working). I'm expecting the code code to grow to about 2000 lines with somewhat under half the code test code.

I wanted to share my experiences with doing "rapid development" this way and of course get feedback.

I don't think there was ever a point where I didn't expect to have to write tests, so I've been using some sort of hand-rolled, cheap unit test system since I started this. In code like this where I'm trying to bang out a lot of experimental stuff and make massive changes to the data structures all the time I simply have to have complete tests for everything - I have 45 tests right now.

I know rapid development and heavy unit testing seem to be contradictory, but I've banged around the data structures pretty hard by now in many different ways and for the last week or so I've been attempting to delete as many of them as possible and replace them with either lists or dictionaries (associative arrays).

And debugging is really hard... so might as well try to avoid it as much as possible!

I've divided up my code into many small Javascript files each containing something like one class or a few related functions - files with names like groups.js or midi.js.

I use the C preprocessor to put these together properly in exactly the same way you'd use include files in C (pretty simply if you don't know how that works).

So if my code is in command.js and includes other files, the preprocessor puts them together into a file called command.jso.

This is all accomplished with a simple Makefile and gcc.

Many developers have make and gcc installed or you can get free from here: 

http://developer.apple.com/tools/gcc_overview.html

 (and you should - everyone should have gcc for just this reason...)

There's a test subdirectory - with lots of JS test code and a tiny Max patch called tests.maxpat which just has a js box with tests.jso and a single message button "compile, test".

To pontificate a little, Javascript is a very advanced scripting language. I like Python a better (if nothing else, I don't have to do this bogus "#include" stuff in Python!) but all the Python features that allow me to do rapid development are there or at least possible.

Advanced languages such as these let you write code some significant factor more rapidly than older-style languages. I've written some number of 10^5 lines of C and C++ and barely 10^4 lines of Python/Javascript and yet I believe I'm as much as 3 times as productive in those languages as in C/C++ (and to a less pronounced state, Java).

So I make heavy use of mocks, where I create a "fake" version of say this.patcher that I use for testing which has methods that record what happens to them. At the end of running the test, I can look at what commands the mock patcher had to execute, and see if they are what I want.

And you have no idea how many bugs I've found this way before I ever played a note!

Here's how I mock "patcher" for example - though I expect this is somewhat overkill, I wanted to learn a little more about Javascript's capabilities.

and always use _patcher in my code and never this.patcher.

When I run a test, I replace _patcher with a mock class called TestPatcher

that has all the methods on this.patcher I use, but instead of doing anything, simply records what happened in an internal array, "commands" and returns a mock object.

PREPROCESS_CORE=gcc -E -P -C -w -x c
PREPROCESS=$(PREPROCESS_CORE) $(DEFINES)

all: command.jso test/tests.jso midi_main.jso

%.jso: %.js
  $(PREPROCESS) $< -o $@

clean:
  rm *.jso

test/tests.jso: command.jso test/*.js
command.jso: *.js


As this advances, I'll write up more of it - I hope this has some value to readers here in this limited state and don't hesitate to send me email with questions!

I do a live show and I want a way to "sequence" an entire show and control it from my instrument without ever having to touch the mouse during the whole show.  I wanted a way I could hook together sets from songs without having to build new max patches for each set.  I wanted a much better way to manage all the many sounds I have from my instrument.

To do this, I've been working on a moderately large Javascript program for Max - right now it's 1423 lines of Javascript, just over half of which is unit tests, as well as a half dozen data files (but I'm expecting a lot more data files (in JSON) once it's all working).  I'm expecting the code code to grow to about 2000 lines with somewhat under half the code test code.

I don't think there was ever a point where I didn't expect to have to write tests, so I've been using some sort of hand-rolled, cheap unit test system since I started this.  In code like this where I'm trying to bang out a lot of experimental stuff and make massive changes to the data structures all the time I simply have to have complete tests for everything - I have 45 tests right now.

Many developers have make and gcc installed or you can get free from here:  http://developer.apple.com/tools/gcc_overview.html  (and you should - everyone should have gcc for just this reason...)

To pontificate a little, Javascript is a very advanced scripting language.  I like Python a better (if nothing else, I don't have to do this bogus "#include" stuff in Python!) but all the Python features that allow me to do rapid development are there or at least possible.

Advanced languages such as these let you write code some significant factor more rapidly than older-style languages.  I've written some number of 10^5 lines of C and C++ and barely 10^4 lines of Python/Javascript and yet I believe I'm as much as 3 times as productive in those languages as in C/C++ (and to a less pronounced state, Java).

So I make heavy use of mocks, where I create a "fake" version of say this.patcher that I use for testing which has methods that record what happens to them.  At the end of running the test, I can look at what commands the mock patcher had to execute, and see if they are what I want.

When I run a test, I replace _patcher with a mock class called TestPatcher


As this advances, I'll write up more of it - I hope this has some value to readers here in this limited state and don't hesitate to send me email with questions!


how-i-am-handling-a-medium-sized-maxjs-project

Wow!, thank you for sharing all these experiences, and yes, please do post more about how this project goes.

I never thought of the 'makefile' method, nice idea!

Wow!, thank you for sharing all these experiences, and yes, please do post more about how this project goes.
I never thought of the 'makefile' method, nice idea!


Thought I'd bump this. I am trying to manage a large project, and am struggling....Everything I do breaks something else, so I'm feeling like I need to start writing tests.... I'd love to hear more about how this went, if it did!

Thought I'd bump this.  I am trying to manage a large project, and am struggling....Everything I do breaks something else, so I'm feeling like I need to start writing tests.... I'd love to hear more about how this went, if it did!


http://jasmine.github.io/2.4/introduction.html

Have you looked at Jasmine? http://jasmine.github.io/2.4/introduction.html


this looks cool, I will check it out thanks!

I'm trying to use as much JS as possible. If I can figure out how to do it in JS, it always seems easier to maintain and add functionality, compared to patching.

But I still have a lot of max patches, so I'm also curious about any good methodologies for testing max patchers that people have discovered. I feel like I'm going at that part pretty haphazardly.

I'm trying to use as much JS as possible.  If I can figure out how to do it in JS, it always seems easier to maintain and add functionality, compared to patching.

But I still have a lot of max patches, so I'm also curious about any good methodologies for testing max patchers that people have discovered.  I feel like I'm going at that part pretty haphazardly.


So how do you go about importing a js framework such as jasmine into max?

I think I basically understand what jasmine is doing (it seems very well thought-out) but I have no sense of how I would integrate it into my max project..... and searching for javascript framework in the forums isn't yeilding much that seems relevant.

I'm assuming there is some sort of inclusion or importation method?? If there is a help page for that, maybe someone can point me?

I think I basically understand what jasmine is doing (it seems very well thought-out) but I have no sense of how I would integrate it into my max project.....  and searching for javascript framework in the forums isn't yeilding much that seems relevant.

I'm assuming there is some sort of inclusion or importation method??  If there is a help page for that, maybe someone can point me?

https://docs.cycling74.com/max7/vignettes/jsrequire

This page explains require and include:
https://docs.cycling74.com/max7/vignettes/jsrequire


How I am handling a medium-sized Max/js project