Today I turn 46, so I decided to blog something about it. This is also my opportunity to thank you all – relatives, colleagues and Chronotron users – for the warm messages on all those social networks I seldom interact with.

Just yesterday, on my way back from a holiday trip, I was handed the usual survey about my stay. One of the first questions was about age group, for which my conceivable options where either 30–45 or 46–60.

This question put me through a tough test: am I old already? Whoever came up with these choices decided that something – body, mind, wallet, or possibly all of that – undergoes drastic changes past 45. And that’s possibly true; however, I can tell you that those of us determined to live our own lives don’t barely notice it.

So, after a moment of hesitation, I selected the first option and called it a day. Remember, this happened yesterday after all.

Developing Chronotron is one of my hobbies. I started this project about 20 years ago as a companion tool to improve my guitar playing abilities. The software has improved a lot since then, though I wish I could say the same of my musical abilities (sigh).

While I don’t spend the entirety of my spare time developing Chronotron, the approach to maintaining, fixing and improving the app is a disciplined one. As a matter of fact, it is because I can’t spend so much time on it that being methodical is a must.

In this post I’ll give you a sneak peek at the Chronotron development process.

The Inputs

Requirements come in a variety of forms, my own usage being still one of the key drivers. I open Chronotron almost daily to play videos, sometimes just for the pleasure of watching Joe Satriani play note by note, or seeing Eric Clapton become left-handed.

It goes without saying that user feedback is the main input for the app regular maintenance cycle. I often add features based on suggestions that you submit either through the app Contact menu, the online form at chronotron.com or Store reviews. There’s also a good deal of inspiration coming from friends who are frequent DAW users, like when choosing the balance control pan law.

One source that deserves special attention is the app telemetry data in the Microsoft Store because it can reveal issues related to a specific app release or OS updates, like it already happened in Release 98.

And that’s about it when it comes to requirements.

Then What?

All these ideas end up in a really, really, long wish list. I call it a to-do list, even though not everything in there will get eventually done.

One of my regular routines is to prioritize the items in the list in a cost/benefit balancing act. The items at the top of the list are the ones shortlisted for the next Chronotron release. User interface (UI, for short) features are easier to implement than DSP algorithms and are more visible to users right away. This is why UI enhancements and bugfixes tend to happen more frequently than anything else.

Once I know which features and fixes will actually make it into the app, the next step is to annotate the parts of the source code relevant to the changes, converting feature-to-do’s into code-to-write’s as I go. This step is crucial to my own sanity. Because a feature may take days or weeks to get implemented, a few hours or even minutes at a time, I couldn’t do it without keeping track of where I am so I can pick up where I left.

I coined the term time-lapsed software development to name this approach. You may have heard that agile software development is done in sprints. In comparison, Chronotron development feels like hurdling.

Another regular task is to reorganize the code to make sure that new features can be added without too much hassle. In technical jargon this is called refactoring. This task is also time-lapsed and guided by code annotations, just like regular app features and fixes (in fact, sometimes you see Chronotron releases with no new features at all, but only “under the hood” changes).

And when the code is written, it needs to be tested.

Testing

A widespread view is that developers aren’t great testers, especially when testing their own code. Indeed, the me-developer isn’t a great tester; however, being a one-man shop, I have no choice but trying my best.

The me-user looks at the app with a critical eye: Is it good enough for my workflow? What would I say if I had to write a user review? Does it perform well on my hardware? My testing routine involves going through most of the Chronotron functions on a couple of devices, including a Windows on ARM one.

That being said, software used to be well tested at a time when you couldn’t afford to ship new floppy disks to your clients every week. In the post-software-stability world we live in, the end users are the testers. Software – even complex systems like Windows – is rushed to the masses and then fixed on the go.

Store apps are software as a service, just like Windows 10. Updates are pushed to you whenever the developer feels like implementing new features and fixing bugs. This is great in many ways, but the inconvenient truth is that the typical Windows 10 configuration has way too many moving parts to be dependable. App updates – or even updates to the tools used to build the apps – can render them unusable. Windows updates can break apps, too, and there’s no easy way for the average Joe to roll back. In short, users at the mercy of the developers and the world is upside down.

As a customer I don’t like that, but I perfectly understand why it happens. Permanent Internet connectivity is widespread and users want features ASAP. Testing is expensive. Mechanisms such as staggered releases exist, but they are there as a mitigation rather to address the actual problem.

Is Chronotron any different? You tell me. I guess the truth is somewhere in the middle.

And when an app is tested successfully – whatever that means –, it gets deployed to the Store.

The Output

You would think that releasing the app to the Store is the easiest part, but it’s not.

The first step is to mark a new app version in the code base so I can track down the changes introduced at each release. For example, if a customer asked why a feature worked in version X but no longer in version Y, that’s how I could find out.

The second step is to create an app package to be submitted to the Store, plus all other required material for the certification process, like updating the app description if features were added, taking new screenshots if the new version looks different, and so on.

When Chronotron is submitted to the Store, Microsoft reviews all the material provided and certifies the app for publication. This process usually takes a couple of days.

While waiting for the certification process to complete, I write and publish the app release notes and occasionally author a blog post to celebrate the new release.

And that’s all!

Now that you know how it all works, what are your thoughts on app development? Let me know by leaving a comment below.

This holiday season I had the chance to try the HP Envy x2 Always-Connected PC (ACPC) running Windows on ARM. My main goal was to get Chronotron running smoothly on it; however, I thought I may as well share in this blog what I learned about the device.

You will find on the Internet some reviews of the HP Envy x2. The general consensus from a user’s perspective is that it’s a well-built device, albeit somewhat underpowered for the price. Read on if you want to know my opinion from an app developer’s standpoint.

Hardware

The version I got has 8Gb of RAM and 256GB of storage. The CPU is a Snapdragon 835 – yes, the same found in many smartphones – featuring 8 cores and a base clock frequency of 2.21GHz.

The screen is gorgeous, sporting a resolution of 1920 x 1280 and support for pen input (which, by the way, is included in the box) and up to 10 touch points. At its maximum brightness, it gets brighter than a Samsung Galaxy Tab, but with a less blueish tone. Contrast is also pretty good, judging by a couple of dark videos I played on it.

The detachable keyboard (also included in the box) makes typing comfortable and provides access to all the symbols developers need without having to resort to obscure key combinations, if you see what I mean. And talking about obscurity, the keyboard is backlit.

There’s also a decently-sized trackpad at the bottom of the keyboard. It has the two buttons embedded in the trackpad itself for the sake of saving space, but they do the trick.

When it comes to sound, the integrated speakers do emit a bit of distortion when pumped up above moderate levels, but that’s not unexpected from the device form factor. Plug in a pair of good headphones into the 3.5mm jack, though, and you’ll get great sound.

All in all, build quality is excellent. The Envy x2 does feel like a premium device, not having anything to envy – pun intended – to the Microsoft’s Surface line.

Software

The Envy x2 ships with Windows 10 S, which is a flavor of Windows 10 limited to Microsoft Store apps, so you can’t download and install software from anywhere else. However, you can convert Windows S to Windows Pro for free, which I had to do anyway in order to run the debugger on it.

Windows 10 on ARM is just Windows 10. This by itself is a technical prowess, but the Microsoft engineers didn’t stop there: they also developed an emulator that allows you to run x86 applications.

Emulation of x86 programs, though usable, is clunky. We should think of it as a workaround while waiting for ARM or ARM64 versions of popular apps to become available. And this is where the trouble begins: a lot of things on the Envy x2 run emulated.

Some OS components, like PowerShell and other bits that rely on the .Net framework, run emulated. I mentioned that a pen is included in the box, so one of the first things I tried was to get a decent inking application. To my surprise, Fresh Paint, Whiteboard and Plumbago – all from Microsoft – ran emulated. Don’t get me wrong: performance is OK, but it could be much, much better.

The situation described above is probably why other reviewers qualify the current Windows on ARM devices as “sluggish” and “netbook-class”, even though the Envy x2 hardware is actually pretty fast.

For example, I can play HD video in Chronotron at the highest quality setting, alter tempo, equalize, do note detection and video adjustments, and playback is still butter smooth, just like you would expect on any recent laptop. By comparison, an Atom-based netbook won’t get anywhere close to this performance level – even though the x86 build of Chronotron relies on Intel-tuned libraries, which gives x86 an inherent advantage.

It is therefore clear to me that, when it comes to number crunching, the Envy x2 is on par with mid-range Intel hardware. However, it is also clear that the chicken and egg problem is at play here: there are few native ARM64 apps because of low market share, and market share is low because performance won’t be there until enough apps are reworked.

So, what about the development tools?

Developer Experience

As great as Microsoft Visual Studio is – and Visual Studio is great –, I have to say that my experience developing for on Windows on ARM so far has been messy.

Many things don’t work smoothly so I find myself looking under the hood more often than not. In just a few hours of use I reported three issues to Microsoft, one of which is severe enough to cripple my app.

To add insult to injury, the UWP package version that supports compiling .Net apps to ARM64 was pulled down recently after a couple of blocking bugs were found. For this reason, as of this writing developers can no longer submit .Net apps targeting ARM64 to the Store.

The good news is that the Windows on ARM team at Microsoft are reachable, responsive and helpful. I can tell you they’re highly committed and are working hard to close all gaps. I presume that – on top of all that effort – they must be facing some challenges with development tools as well, so my kudos to them.

My message to Microsoft as an app developer is that – now that I saw it could work – Windows on ARM won one more supporter. Don’t let me down!

Wrap Up

I concur with other reviewers that the HP Envy x2 is a well-built device. For €799 – the price of a smartphone – I think it’s a good deal taking into account that the keyboard and pen are included.

Windows on ARM has a lot of potential, even though it’s still unquestionably work in progress.

Now, when it comes to value for money, I’d say it all depends on whether or not the software gap gets addressed quickly enough, before the hardware becomes obsolete. If it does, then the Envy x2 is definitely worth its price. Otherwise, I can understand that the value proposition will be harder to justify for some.

And by the way, I confirm that battery life – the main selling point of this device – is excellent unless, like me, you’re doing a lot of remote debugging. But anyway, that’s like driving a Prius on a race track.

Release 113 is the last Chronotron update of this year. That’s at least the plan, unless unexpected issues trigger another urgent deployment.

As you can read in the Release Notes, this update brings a couple of quality improvements. The most noticeable change is that the audio scroller is now resizable, motivated by the fact that most of the app window area remained unused when playing audio files.

A less visible – though nothing short of life-changing – addition is that now the space bar can be used as a shortcut to start and stop playback. Yes, finally! Indeed, this feature was long overdue because it took me a while to get it implemented in a way that doesn’t interfere much with accessibility. I frankly don’t know how many Chronotron users, if any, have specific needs, and I don’t even claim the app meets all accessibility guidelines; however, I definitely don’t want to make things harder for those who rely on those features.

The final significant change in Release 113 is that the ARM package is now 64-bit. In the Release Notes I call this package beta software, though the sad truth is that it has been barely tested. So, if you own a Windows on ARM (a.k.a. WoA) device, don’t hesitate to report any bugs via the usual channels. Better yet, if you happen to be in touch with a WoA device OEM, tell them not to give up: there’s at least one app developer committed to the platform!

All in all, there were 14 app updates in 2018 that brought some new features and many quality improvements. I wrote 18 entries in this blog – a number that is a bit below my initial objective, but hopefully enough to keep you updated on what’s going on.

What’s coming in 2019? Further UI improvements? Updates to core functionality? Inking support? Some AI features? Stay tuned if you want to know!

In the meantime, enjoy Release 113 and don’t hesitate to post your wish list in the Comments section below.

Happy holiday season!

Get Chronotron for 50% off the regular price on Black Friday!

Go to the Microsoft Store on Nov 23^rd (from 00:00 to 24:00 UTC) to benefit from this deal.

In the meantime, you can download Chronotron and enjoy its trial period, during which the app is fully functional.

Long ago, the Chronotron user interface was tab-based, close to the ribbon toolbar concept in Microsoft Office. This worked fine for a while, but as the application grew more and more features, the upper part of the screen started to get a bit too crowded. It became clear that a better solution had to be found to expose all app functionality, yet keeping things as touch-friendly as before.

Enter the Hamburger Menu

The hamburger menu button is the three-bar icon (☰) that many mobile apps show, usually at the top-left corner of the screen. It’s called like that because some renderings of the icon resemble a hamburger.

Chronotron introduced the hamburger menu in Release 72 as a way to give access to the various application toolboxes, kissing goodbye to the tabbed navigation paradigm.

To put things into perspective, it was late 2016. At that time, Microsoft were embracing the hamburger menu in their own apps, and some Chronotron users were begging for a “more modern” user experience, closer to what mobile apps had to offer.

Even though Chronotron used the menu in an uncommon way – the buttons caused the toolbox panes to open at the other side of the screen – it did help keeping screen real estate usage under control and making Microsoft Surface enthusiasts happy.

Not everyone welcomed the revamped user interface, though. The app got a couple of bad reviews from traditional PC users infuriated by this change. Still, I believe that bringing Chronotron in line with what other Windows apps looked like at the time was a necessary, if painful, step.

Rise and Fall of the Hamburger

In the meantime, the world continued to revolve and the hamburger menu fell in disgrace. Today it is generally acknowledged that, with a few exceptions, that navigation pattern hurts app usability metrics. Microsoft and other industry leaders no longer embrace it and the web is full of articles on alternatives.

I have mixed feelings about the hamburger menu, or the way I used it in Chronotron anyway. The fact that I had got rid of all button labels made the app look even sleeker. The problem was that, unless you clicked on the hamburger button or on the ellipsis at the top right of the screen – another usability blow – there was nothing but a bunch of icons to figure out what the app can do. Form over function.

So, in Release 109 I’m taking another bold step and getting rid of the hamburger menu. And always-visible button labels are also back!

Exit the Hamburger Menu

The refreshed Chronotron user interface is based on – you guessed it – tabs. This time, though, the tabs are vertical and placed exactly where the toolbox panes appear.

The labels should also make it easier for users to find their way around, whether they’re already Chronotron fans or new to the app.

Want to see what it looks like? Go ahead and get the latest app update from the Microsoft Store.

Epilogue

For your delight, below is a slideshow of significant changes the Chronotron user interface has gone through over its lifetime. There’s of course a slide for Release 109, and I’m sure it won’t be the last.

This slideshow requires JavaScript.

You may have noticed a number of remarks in the app change log regarding specific improvements on ARM CPUs. Knowing that Chronotron isn’t available for Windows Mobile, what’s the point of those “DSP performance enhancements on ARM”?

The answer is that there are a few Windows laptops and convertibles out there which sport an ARM CPU instead of the more familiar Intel x86 chip, and Chronotron should be able to run on those. For example, the Asus NovaGo, the HP Envy x2 and the recently announced Lenovo Yoga C630 WOS all run full Windows 10 on ARM. And by full, I mean Windows 10, not its Mobile sibling.

I haven’t got my hands yet on a Windows on ARM device I could use for testing and debugging. Currently I rely on the fact that Windows Mobile implements a fair subset of the Windows 10 APIs, so I can run Chronotron on a Lumia 950 phone – which happens to have the same kind of CPU – to perform limited testing and performance optimizations.

This means that I presume the app runs well on Windows on ARM devices, but until I could actually acquire one (they aren’t generally available here in Europe as of this writing), I won’t be able to tell for sure.

It’s not that I haven’t tried, though. I contacted the regional Asus distributor to get a test unit. At the time they didn’t have a review unit yet; however, they told me that once they got one, it would be sent first to tech magazines and websites. This is unfortunate for me, though understandable.

Another thing I did was submitting a suggestion to the Microsoft Developer Rewards Portal about issuing a few perks for developers porting their apps to Windows on ARM. After all, if Microsoft really wanted to incentivize developers to port their apps, the portal would be the place to facilitate early access to the platform. No reaction so far.

There’s also the software side of things. Some tech websites tell you that porting an app to ARM is “as easy as recompiling”, which is not entirely true. For example, Microsoft forgot to enable one of the components of the Windows SDK for the ARM64 target (namely Microsoft.Midi.GmDls), so apps using that specific component can’t just be compiled for 64-bit ARM.

Developers of apps that rely on advanced CPU features and multithreading – like video games and media players – face enough significant differences between the x86 and the ARM architectures to justify serious testing on each. Also, let’s not forget that there are also compiler bugs that surface only when targeting certain CPU architectures.

Going back to the original question in this post, I share the enthusiasm around Windows 10 on ARM: getting Chronotron ready for when such hardware becomes mainstream reflects my endorsement as developer. At the current level of Microsoft involvement, though, it looks like this will take a long time.

The situation I describe above is often referred to as the chicken and egg problem: a platform success depends on apps being developed for it, but there won’t be many apps developed for a platform that isn’t widely available.

Until then, Chronotron on ARM is a chicken hatching from a dinosaur’s egg.