The hack in webapp.js that wraps the module code in a define call (for proper use from the client) is terrible. We should write some real middleware for doing this.

scaling stops working and all displays except 0,0 are empty.

./bin/run_1x1.sh --module_duration 10 -m balls

Then open a client. The first module display works fine, but after transitioning (to balls again) the client display is all black. The logs show the client connecting for each module, but the server<-->client socket comms are spotty after the first module display.

From bit of digging into the network events it appears that the per-module socket connection is not being made (open event never fires).

Interestingly, if the playlist if modified to contain

  {
      "name": "balls",
      "path": "demo_modules/balls/balls.js",
      "title": "Bouncing Balls",
      "author": "Matt Handley"
  },
  {
      "name": "balls2",
      "path": "demo_modules/balls/balls.js",
      "title": "Bouncing Balls",
      "author": "Matt Handley"
  },

then ./bin/run_1x1.sh --module_duration 10 -m balls -m balls2 works as expected. Something about transitioning to a different module avoids the problem.

Note, issue manifests with other modules that use the network object too (first noticed for chicago-brick-live).

There is probably some kind of standard for this.

Esp confusing when styles are mixed. Use all the new hotness.

there are still a few leftover dependencies in the repo, like leaflet.js that aren't used by any public modules. These should go away.

See attached log file. This could be related to local changes -- I haven't tried in a clean client.

walllog.txt

Right now, there's no good way to have client-only or server-only code. Add support for this, potentially disallowing shared code in the module with register by having two separate 'main' files.

As a first step, write down a design of such a thing and the tradeoffs there.

Instead of using memory-debug for fading out, use the solid color module.

Right now, we use tricks to infer discontinuities in the parametrized state space on the client (assigning null for a value, for example). state should support this explicitly, with specific behavior of each interpolator when inside of an interval of discontinuity.

Right now, we support xfade, but add other visual transitions types between modules.

When the server has been running for a while, we lose some timing resolution, which destroys our state interpolation on the clients. Implement a method for being able to reset the current time back down to some reasonable number.

Change state interpolation to no longer require manually removing Xms on client.

Right now, we have 0. Let's fix that.

Rather than passing the whole module as a single string, have the clients fetch the code from the server.

If two 'loadModule' events are sent to a client in rapid succession, some aspects of the global state management fail to execute properly. This is because we set up a bunch of these globals as soon as the event arrives, rather than as soon as the state machine is actually ready to show the module. This can result is all kinds of bugs, and is prerequisite to #45, which might generate loadModule events at a high rate.

Occasionally, time can wind backwards from the perspective of the client (as when the server is restarted). Rather than forcing module implementors to handle negative deltas, we should detect this situation and prevent this annoying detail from leaking into the module's tick/draw methods.

Messages sent from server via network are dropped if clients haven't yet opened a connection on the same namespace. This makes initialization things (that one would normally put in willBeShownSoon) super annoying. Fix this by queuing such messages until the client actually connects.

The google installation of chicago-brick needs npm link shenanigans because of the way server/webapp.js sets the default directory for serving requests. This should be fixed.

And the error should point to the actual error line, if possible.

If the module was already loaded, though, and a syntax error is encountered, the server should not abort, though.

Tests are currently run with a githook before commit. Having a Travis job would make PR review easier (no leap of faith or need to run branch locally) and will keep chicago-brick healthy an easier task as development continues.

Rather than having to pass a bunch of random individual fields around to the next state, create a struct that better represents "a module that is being displayed".

This should make it easier to position absolute content inside.

we still have a lot of deps in package.json for modules that aren't part of the core application or the demo modules, which is kind of rude of us. :)

This issue tracks improvements to the status page:

• Add ops to the page, like rebooting specific clients or the server process itself.
• Add a better UI to modify the playlist
• Add better monitoring about what the server is doing, including data like current RAM or CPU usage. Bonus points if we can track it over time and also mark transitions to help detect leaks, etc.

i know we can leave them out of a module list, but you can't do anything useful with just slideshow without configuring it first. This makes it odd to see in the playlist.

Right now, it's tricky to add more options to the title card generator, as 'title' and 'author' are plumped specially through the whole module set manager on the server & client. Instead, just blindly copy 'title' everywhere, and move 'author' (along with 'path') as a key inside of the 'title' object. This should have the effect of removing a bunch of code & making it easier to extend the title card with more options later.

It should talk to the main module server via some API to get the status it needs.

This should help detangle some of the complexity of the current server process.

Right now, there's no way for modules that only want to display for a specific duration to do that without hacking an estimated duration into the playlist. Fix this so that, say, the video module can report its intended duration to the framework.

i was on the train and watching chrome wait for the font in client/index.html

pretty often, the module (any of my p5 modules) would kick off and be borked until that font loaded. I'm assuming some asynchronous stuff is happening before everything is set up. Removing that font clears up the intermittent issue, though.

This is in contrast to the current "must be in server/util" strategy.

Right now, multi-file modules don't work, because we eval a blob of code from the client. Fixing #83 should get us to the point where we are serving up modules over HTTP and requesting them via requirejs, which is a first step. In fact, after that issue is closed, the client should work with multi-file modules with no problem.

That is not true for the server, however, which still uses the old safeEval method. Even weirder, the safeEval method uses the built-in node require method to do ITS requiring, which caches loaded files. A dep from modules/a.js to modules/b.js will result in the client getting the freshest a and b, due to our cache limits and the server getting the newest a (because we manually read it from the fs), but the OLDEST b (because node's require cached it).

So, when requiring via node's require, we must wipe any deps after the module is finished loading. This should be easier than in the client, because node's require is synchronous.

I noticed this on the google drive module. The title card keeps showing "Google Drive Images\nJacob Lee" even when a playlist has a different title for the module.

Implicit globals were initially a big speed improvement, but they affect debugging because they change the line numbers in the client-side eval'd module.

Fix this by removing the remaining implicit globals.

It would be neat to have a consistent way to say "start this video HERE", where here might be derived all kinds of ways.

Add a mode to the clients (via url param, perhaps) that will log a warning if a client draw is too slow (> 16ms).

Our current eval wrapper ( @artdent's fork of vm-shim) adds a bunch of:

var NAME = sandbox['NAME'];

lines to the top and bottom of the eval'd script. This makes line numbers in Errors basically worthless. Switch to using a custom eval wrapper, which does a better job of handling these line numbers.

OR, make random-js work on client & server in a sane way.

To help ensure that things are always disposed when a module fades out, write the necessary wrappers around methods like setInterval to ensure that the framework can dispose of various timers. Furthermore, check to ensure that the number of DOM elements doesn't change.

https://gist.github.com/branneman/8048520

I like number 7 myself.

I attempted to work on #45, but the module/playlist loading code is just WAY TOO COMPLICATED. This bug will track the work necessary to really fix this.

Setting up a new chicago-brick install could be as simple as:

npm install --save chicago-brick 
npm install --save my-cool-brick-module

This would then produce a package.json file that describes the chicago-brick installation (yay for easy sharing). The package.json file could also be expanded to include any module configuration (e.g., configure the slideshow to show specific media).

chicago-brick/module versioning can (and should) be managed using npm peer dependencies. This also keep modules from breaking when chicago-brick introduces a major revision (breaking change).

During applmak@'s big module refactoring, /status's playlist updates stopped working, because we error out when attempting to define a new module with a name that's already registered. Fix this by clearing out the already-registered modules when performing a playlist update (or reusing the ones that are already defined).

right now, config/demo-playlist.json plays a bunch of stuff that doesn't work unless you go and configure API keys. The docs for that are bad and the feedback for it is bad.

In addition to better instructions, the modules should have a way to say they are unhealthy and be skipped by the server if their API keys aren't available, for example.

This should prevent needing to reload when developing, which is just great for everybody.

This should make it easier to debug issues, because we can rely on certain channels being a certain color.