Catchup: Mountaineer

Introduction

Because a big part of this site’s raison d’etre is my desire to distributable-ise my past work, I’m going to be doing a lot of these ‘Catchup’ posts. Basically the idea of these posts is letting you guys know about a past project of mine, and what to expect in the future from it.

The first Catchup software will be the personal project that I have used the most out of everything I’ve ever built: Mountaineer!

Before I get started, I just want to say: I imagine Mountaineer could be a little divisive: it is exactly what it sounds like. If drug use makes you uncomfortable, then you might want to skip ahead to one of my other projects. I don’t want to get political, so I’ll just say that it’s up to each person to make responsible and well-informed decisions about their own life and leave it at that.

Origin Story

Mountaineer has grown from an idea I had several years ago and implemented with pen and paper into a full-fledged joint-smoking measurement and prediction tool, in addition to a somewhat half-baked statistical analysis suite. If that sounds perplexing, read on!

I had the original idea for Mountaineer just before getting high some years ago – I tend to write down all my ideas and hang on to them. For this post, I dug out the page on which the original concept for what would become Mountaineer was formulated. The idea was that I would roll my joint, hold it up to a lamp that never moved and sketch the outline the shadow made. Then, while I smoked, I could hold the joint up to that position and see, based on the shadow, how far through the joint I was.
After some more thinking about it, I decided the shadow idea wouldn’t work, since even very subtle rotations of the joint while being held up to the light would result in significant inaccuracies in measurement. What I ended up settling on was to trace the joint outline onto a small piece of paper (I used the back of pages from order-books from the cafe I worked at – I used to always leave them in my back pocket and not realise until I got home, so I accumulated tons of them).

I called each traced drawing a Jointometer Since I had the idea years ago, I’ve made one for literally every joint I’ve smoked by myself, and I still have them all.
However, being a programmer, I saw the potential for digitising my Jointometer.

The Dawn of Mountaineer

At first I simply replicated the function of my paper-based Jointometers in Processing (which was what I was playing with at the time), with a few inclusions like volume-calculation, percent markers and some simple UI. Once functional, the application changed very little for about 6 months. Every time I got high, I’d use Mountaineer to make a digital Jointometer and ensure it was saved to my computer. The application traveled with me through several computers, even surviving the trip from OSX to Windows.

In the past 12 months or so, I’ve been incrementally improving Mountaineer. A lot of it has been minor things – font improvements, changes of colour-schemes, etc. But there was a revolution that began in October last year: I decided to start recording events that occurred throughout my joint-smoking session. I would press ‘D’ when I took a drag, ‘L’ when I lit (or re-lit) the joint, ‘A’ when I ashed the joint, and ‘W’ when I took a drink of water. I would also record how far I was through the joint whenever I measured it against the on-screen trace, and the time that I started. I wasn’t quite sure what I’d do with the data, but I decided I wanted it.

I put a handful of these sessions into Excel to create some graphs of my joint-smoking sessions – I found it fascinating to see such a magical and mercurial experience as smoking a joint by myself represented in such an objective and analytical way. About two months and four joints later, I stepped up the game, and began recording the data as CSV files. I then wrote a second application: the Mountaineer Analysis suite.

The Mountaineer Analysis Suite and the Dawn of Prediction

I got tired of putting the data into excel each time, basically. So I wrote an application to read the CSV files and display graphs of my sessions. I don’t have any screenshots of the old suite, but basically all it would give me is a simple line graph with axis labels.

I used to enjoy flicking through the past sessions I’d recorded, pressing ‘D’ for each drag and so on, looking at how the line graphs differed each time. The interesting thing was how little they varied – they were strikingly linear. The linear regressions almost always have an r² value of over 0.95, and often over 0.99. Which got me to thinking – if the graphs of percent-smoked against time is so linear, perhaps I can analyse the data as I collect it, get the regression from the incomplete data set, and predict the time and drags remaining before the joint is completed.

As it turns out, it works excellently. So, after having barely changed for over 6 months, I overhauled the original Mountaineer application completely, integrating a lot of the data-crunching ability from the Analysis Suite. The result is very decent predictions for how many drags, and how many minutes are remaining in my session.

But…Why?

It’s a valid question. Sometimes I take a step back and ask it to myself. At first glance, it all seems so complex and involved that surely it ruins the experience of getting high altogether. It’s something I’m constantly aware of, and it’s why I’ve carefully made Mountaineer to be as subtle and minimalist as possible. It’s a huge bummer while you’re getting high to see a timer count down, or to see the sacred moment you’re in captured by a cold linear regression. So all those things are hidden by default, and I don’t turn them on unless I want or need them.

I find there comes a point in every session where I’m very high, my throat is getting a little sore from all the smoke, and I’m looking at the last 10-15% of my joint and wondering if I can continue (my cannabis tolerance these days is sufficient that it’s usually my throat that limits how much I can smoke, not my cannabinoid receptors). It’s at these times that I bring up the projection for number-of-drags-remaining (most recently, visualised as a cluster of low-opacity circles), and take solace that the data I generated in the past suggests that I’ve got at least another four drags in me. Not to mention the pleasure I get from defying the data, and taking one or two more past that.

Ultimately, Mountaineer is a fun application for the times that I’m sober, and a slightly useful application for the times that I’m getting high. I think it’s both interesting and entertaining to have such detailed recordings of the times that I’ve gotten stoned – they’re some of the best times that I’ve had.

Moving Forward

So where to now?

Well, in its current state, Mountaineer and the Analysis Suite are both very stable and usable (this is actually a critical thing with Mountaineer – when I’m stoned there’s no way I’m capable of handling a crash, and the joint can’t be re-traced, so the data is lost forever. This has only happened once).
However, I realise that there aren’t all that many people who get stoned by themselves in front of their computer on a regular basis, and probably fewer who are willing to religiously press certain keyboard shortcuts whenever they do anything while stoned out of their mind.

So I’ve been working on a version for Android and iOS with a great deal of variability in its use. The key will be that if someone wants to leverage all the cool statistical analysis stuff and learn more about their own cannabis use and generally keep a quantified record of their adventures (or misadventures) with Mary Jane, they can. But someone can also just as well use Mountaineer to check their process through their joint and never touch any of that stuff. I feel that it’s useful either way.

Another awesome benefit of using Unity is I get access to all of .NET, which means I can have all my data stored in a SQL database, allowing me to take Mountaineer with me anywhere, and be able to use it on multiple devices.

Reimplementing the whole thing in Unity is a daunting task, as I’ve been working on Mountaineer on-and-off for over a year now. The biggest challenge has been in that Processing is entirely screen-space based, while Unity doesn’t play particularly nicely with screen-space. But it’s been progressing slowly over the past few months, in between my other projects.

I’ll probably make a separate post about Mountaineer for Unity (which will potentially even have a different  name) when I get closer to having version 0.1 finished. At this point, I have a lot of the core functionality down, but I’m not at the point yet where it’s really usable.

And What about Processing?

Because I actually use Mountaineer on a regular basis, I’m still maintaining and adding features to the Processing app – I’ll continue to do so until I can use the Unity version functionally. This means being able to record all the data I can currently record with 100% stability and reliability. Once I get to that point, I’m going to put the Processing app to bed – that will motivate me to add features and functionality to the Unity app.

However, I’m not planning on making the Processing app available for download – Processing has no way of hiding the source code, and because I actually plan on the Unity app being a ‘thing’ i.e. distributing it professionally, I’m not super keen about the source code for the seed project being online.

Perhaps if the mobile app fails spectacularly, or if it is tremendously popular, I’ll go ahead and post the source to see what other people come up with, but for now, I’m keeping this thing under my hat. Sorry people!

---

 

---

 

…This became a tremendously long post – sorry about that everyone! If you made it this far, congratulations! If you scrolled down to here after seeing how huge the post was, go and check out the Project page for Mountaineer, there’ll be a far briefer explanation of what it is and what it does there, without the history lesson.