Monthly Archives: February 2016

Samplitude on a tablet

Posted on by
3

Samplitude Pro X2 was recently on sale for a ridiculously low price so I decided to grab a second copy. My studio DAW has Samplitude tied to a dongle for historical reasons so it was nice to get a dongle-free license for mobile use.

So… I’m wondering if Samplitude would be usable on a Windows tablet? I don’t like using a computer for songwriting and demoing, there is enough mousing and typing during the day already. Could a tablet provide a more organic and fun experience somewhat like a 4-track cassette portastudio back in the day?

Inspired by surfaceproaudio.com I decided to try it. I’ve installed Samplitude Pro X2 and ASIO4ALL on a Thinkpad Helix tablet and I’m in the middle of figuring out the workflow and settings that make this possible. Touch only – no keyboard and no mouse! This is a work in progress but so far things look very promising!

Sam Pro X2 tablet

To maximize the space for manipulating audio, I have removed all the visual elements that are not absolutely essential. The Windows 8.1 task bar I’ve moved to the left side of the screen to free some vertical space. The onscreen keyboard is accessible from the task bar all the time. Naming tracks and saving files still requires some typing. I’m trying to fit the frequently used actions on a single toolbar so I’ve removed the toolbar at the bottom. Samplitude has a Big Toolbar option which makes the icons just the right size for touch.

The toolbars can be customized to contain exactly the buttons you need. There is a default palette of commonly used toolbar actions. In addition, any action that can be found in the menus can be added to the toolbar with the custom button. This kind of customization is essential for usability in any software.

Sam toolbar custom action

The arrangement (VIP) window supports touch gestures. I can scroll the timeline, pinch-zoom, marquee-select objects, select a range, move the play cursor – all without buttons.

There are some essential actions still missing from my toolbar. I can select and split objects but have no way to delete or mute them… doh! I guess I’ll remove the zoom and navigation buttons to make room for those.

Advertisement

Garbage in – default out?

Posted on by
Reply

We were freshly into production with this system that had a lot of moving parts. The whole system consisted of several big monolithic applications and half a dozen newer microservice-style services integrated into a “living organism”.

A user was not getting the results she expected. We investigated the problem and found out that a service we were calling was not returning some of the data we were interested in. In particular, data older than three months was not seen by us. A support person for the service said: ‘you should use wide search if you want to see the older items’. But wait – we were using wide search, always had been!

I double-checked the code and sure enough, it did say widesearch=”true”. Strange. So I blew the dust off the API spec and found this: widesearch=”1|0”. Yikes, the value should be a number! And I had coded this, totally my bad. I guess I’ve grown too used to using true and false for boolean values in XML. We were a month into production when we found out we were not using wide search. Never had been!  

Why did we not get an error when we called the service with bad parameters? 1 and 0 look like numbers to me, but the service had been happily accepting the string “true” all along. I decided to run a little experiment against the service in the test environment: 

<request key="..." widesearch=”anything goes?” />
   → 
<response>OK ...valid search results...</response>.

Okay, so it seems there is no validation of the parameter whatsoever. The code probably reads something like this: 

if("1".equals(request.attr("widesearch")) ...

Why did we not find this bug during testing? This integration point was hammered a lot because during the project there were a lot of version updates on both sides of the API fence. Before going into production, the integration was in use for at least half a year in the testing environment. Somehow we just managed to not hit the three-month limit. For us ‘widesearch’ was just a mandatory constant we had to set in the API, not a thing that would be interesting to test.

Now, imagine that the service actually checked that the parameters in the API call have correct data types. We would have found our bug on day one of testing. Actually earlier – the first time we tried to call the test service. Silently choosing a default when the input is garbage does a big disservice to making the whole system robust.

When computers talk to computers it is better to be strict in the protocol. Problems get flushed out way quicker.