PositiveGrid's Spark 2 amplifier and associated phone app

I recently decided to get back into the world of electric guitars.  Some 15 years ago, I had mostly moved into the world of acoustic guitars, as I lived in a small home and I appreciated not having such a clutter of wires and such.  

I start this entry with a growing sense that I am becoming an old man trying to use complex new devices and software.  But my own growing difficulties as a user case study are paired, as they often are, by the challenges of a new hardware and technology company trying to create a compelling value equation.  Some companies still thrive by making rugged, reliably loud and evocatively rich-sounding amplifiers for electric guitars.  But, the mere existence of digital processors which might obviate the need for effect pedal chains, wifi, Bluetooth, and smartphones creates a temptation for manufacturers of some amps to "go smart" in order to deliver greater value at a budget-friendly price. The realm created by these new technologies has its benefits, but comes with a lot of baggage.

I will start with a bullet list of issues I feel are presented by my new Spark 2 amplifier.

Smartphone App

The Spark app, which I used from an Android Pixel 9, is nice, but has issues.  I will riff through them in no special order.

Upon first launching the app, it asks if you'd like to connect to a Spark Amp.  Provided you've previous established these associations to a particular amp, this question is utterly idiotic.  Connect immediately the most recent (likely, the only) amp to which the phone has been paired.  File this under "DUH".  If other options were needed in the moment (e.g., to pair to another, newly-acquired amp), these should be accessed by interrupting an immediate process of connecting to the previous amp.

Given that the product family now incorporates - indeed, almost demands - use of a smartphone app, the gates of Hell are open.  By which, I mean, every buzzword is represented and accessible through the app, to varied result.  There is "AI" in the form of "players" who will listen to a bit of what you play and then offer some backing tracks, such as a bassline.  This is interesting, but is accessed through an interface that is already glutted with more essential fare.  It should be factored out into another app, perhaps.

Vitally, the smartphone app should allow at least an option to extend the device's timeouts for sleep mode or lockscreen activation while active and connected to an amp.  I keep these timeouts rather short on my phone for the sake of security, but it is a total buzzkill to have to keep waking up your phone (or even entering a passcode or biometric signal) simply to keep working with your guitar amp. 

"Tones"

Users of old school amps are used to creating the "sound" of their instrument using knobs (volume, gain, boosts or cuts to various frequency bands) on the amplifier.  Other modifications to the sound are generally obtained by knobs on foot pedals, each of which typically offers a specific family of functions.  The routing of the signal is expressed by the external cords that connect these pedals to each other, the instrument and the amplifier.

A smart, "soft" amp such as the Spark 2 doesn't preclude the use of such pedals, but offers the promise that much of their function can be digitally modelled within the amp's chassis through digital signal processing and high performance chips that can apply these tweaks in real time.   The digital "pedals" in the Spark 2 app look like familiar metal foot pedals, and populate a fixed-order "signal chain" in the app, which you can access via an Android or IOS device.

In addition to these rich apps, the amp itself features physical knobs.  Each has a familiar index mark on its circumference, which can be swept across the customary 0-10 range (11 is reserved for future updates, I suppose).  However, the position of these knobs does not necessarily reflect those in force in the modelled sound the amp is delivered!  If you use the app to apply a new preset "tone", or to alter the loaded one the amp is actually delivering, the knob positions become a possible lie:  the Treble knob may be set at 5 while the amp is delivering a Treble setting of 7.  The fix?  Stop using dots on the knobs and make the fixed circumferential scale against which they register be a circular bar chart showing the present value in effect.  If you rotate the knob, the LED lights will show where "the dot" is.  If this parameter is altered by any action taken through the app, the same indication can be represented at the knob.

On the Spark 2, there is a "preset selector" knob with 4 positions and 2 banks (8 presets in all). The bank of preset being used is depicted by either red or green LED indicators alongside digits 1-4 of the preset within the bank being used.  These settings are, however, conveyed in the app as preset slots 1A, 2A, 3A, 4A, 1B, 2B, 3B, 4B.  This is confusing in two ways.  It doesn't tell you that "A" is red, and "B" is green.  Furthermore, it emphasizes the least significant variable (preset number) rather than the most significant variable (the bank).  The fix?  Reverse the order and rename the banks.  Presets would then be named "Red 1", "Red 2"... "Green 4".

External GUI Interface via separate device

You can't really control the Spark 2 without use of the app.  At best, the device itself, is intended to offer quick access to 8 tones stored (in red and green banks of four) that you have defined by use of a device running the app.

This makes sense, to a point.  It allows the manufacturer to rely on the fact that 99% of its customers have a smartphone capable of running their app.  They can factor out the cost of making this smartphone device.  But, it comes with a cost.  There is the tension between app and knob position as cited above, and the oddity that the user has one more "thing" he/she has to attend to/juggle - the smartphone or tablet.

A suggestion would be to bake into the device an Android-based interface to replace all of the knobs (excepting those whose settings are not reflected in the digital presets, i.e., "Music" and "Guitar").  This would intrinsically connect to the local amp on power-up and have its touchscreen affixed to the top of the amp.  It would add to the cost, but manageably so - how much does an Android phone of 5 year old vintage, sans circuits for cellular, GPS, bluetooth and other particulars, cost?

Spark Link

I bought the Positive Grid wireless plug dongle pair called Spark Link.  It's ok, I think, but it needs work.  First off, the transmitter (which you plug into your instrument) and the receiver (which you plug into your amp) are almost indistinguishable.  The transmitter has a black plastic collar around its 1/4-in plug, and the receiver has a gold metal one.  It would be better to augment this with embossed letters or symbols, perhaps T and R, or a Victrola and a Terrier.

The two devices share the quirk that their power switch must be given an overly long "long press" to toggle them on and off.  If nothing else is changed, this long press minimum duration should be decreased - with the Spark 2 amp, you literally have at least 6 seconds "work" just to get things powered up.

Additionally, when the transmitter is plugged into many guitars (as on a Telecaster), the LED indicating it has turned on is not going to be readily visible.  Can it be made so that the act of inserting the 1/4-in plug into the guitar turns it on?  Or, perhaps better, can the power switch be made a simple slider?

Also, specifically for the receiver... can this be optionally be built into the amp, or can a small cubby hole allow the existing dongle to be inserted and the door shut?  Such a configuration could perhaps allow the device to receive power from the amp's battery or AC plug, could turn it on whenever the amp is powered on, and could override the amp's 1/4-in input plug when the latter is empty.

To summarize the above, I think an idea embodiment would allow the user to have a Spark amp that has an integrated receiver for a Spark Link transmitter.  The receiver will always have power when the amp is on, and the transmitter will have a slider switch to turn it on/off.  The user will have only one dongle to charge and keep track of.

Optional Battery for the Spark 2

This $79 option is ideally implemented.  The amp has a little cubby hole for it, with a door to snap shut once it is installed.  The battery has a fairly good endurance, as far as I can tell, and charges whenever the amp is plugged in.  Morever, the amp remains usable when the battery is receiving this charge (unlike my Traynor busking amp, which is either charging or playing).

If you wish to have one fewer thing to tote about when going to play somewhere, get this battery.  It has my unreserved endorsement.

Final Cut Pro X

How to take a bad thing and make it worse?  This was a good effort.

I'm using a trial version and find it operates by seeming side effect more than a user intention being properly inferred by him (thanks to transparent design) into a required action that is then faithfully interpreted by the app.  Apple used to do that.

Delete a clip... and watch in dismay as the successive clip's detached audio track disappears (or not), based on some condition of perfect/imperfect leading edge alignment.  How to achieve perfect alignment?  Not really suggested.  Move a clip and watch some random assortment of other material follow the motion while others remain in place.  Resize a clip and watch the preceding or succeeding one leap to the next line when they conflict.  How do you get the one you're adjusting to just move so it precisely fits?  No idea. Magnetic timeline?  What?

Create a text title.  Ok.  Now edit the sample text provided... how?  No idea.  Spend 10 minutes examining about 5 different hypotheses.  Nothing.  Delete the text title.  Guess that isn't something for this project.

I feel as though the app is trying to out-think me, when it should be doing what most brilliant apps do:  respond directly to my action rather than guess at some clever riposte.

Find an audio clip... try to guess how to find its duration.  CMD+I?  No, it brings up an Import panel.  An import is something so weighty and so sporadically done that it in no way merits displacing "Information" as a hotkey action.  I still do not know how to find these durations.

I find the continual "scrubbing" of sound and vision as I move the mouse about incredibly annoying.  There are toggle buttons to disable this, but I just want to uninstall the whole mess.  I feel like a palsied DJ skritch-skratching in a night club.  Toss the scrubbing line and give me a cursor or a hand that moves things when I drag them.  I don't want anything to play or move unless my finger is down on a button or a key.

It organizes your footage into "events".  Great.  Apple seems to think we all value thinking of our life and its data in terms of discrete events.  I sure don't.

Video editing will leap forward when someone dares to discard dated, traditional words like slip/slide/duck/dodge/frolic/etc presently used for common timeline actions.  Why?  Because these words in no way convey their result.  I used FCP 7 for a year and still did not know which of these I wanted at a given moment.

Mac OS X Finder annoyances

The OS X Finder is exceptionally annoying in where it chooses the scope of a search or where to place a new folder.

The "New Folder" function (shift+cmd+N) places the newly-created folder in the folder selected in the left sidebar. An entirely more useful and consistent choice would be within the folder selected in the right panel. This is more useful in that the means of obtaining this function is, at present, extremely cumbersome and the present function is easily supported within the design I recommend by selecting no folder at all in the right panel. It is more consistent because the "Duplicate" (cmd+D) function places the duplicated file in the folder of the original item -- not in the folder selected on the left. The present design is inferior by any evaluation. It is neither the expected behavior nor is it as flexible.

Note: I did find an Applescript which permits the behavior I'm looking for, but for the life of me I cannot see where that was installed. I'll try to identify that.

Similarly, the Spotlight search function only offers options for the scope of the search as the entire Mac or the folder selected in the left sidebar. Once again, the workaround is similar, but tedious -- one can move the folder one would like to use into the left sidebar and then select it, but this makes more work and necessitates a clean-up step of removing the folder from the left sidebar afterward. It is once again the suboptimal choice and not even the simplest, most apparent design.

A modest proposal

Imagine if next November, some number of registered voters arrived home to discover registered letters from their state voting board containing language in the rough form: "You have been selected to serve a two-year term as United States Senator for the Commonwealth of Massachusetts."

My assertion is: our representatives would actually represent us much more effectively if we did not elect them. I believe only a delusional pollyanna could think otherwise when they considered the trends of our political system. If we filled our legislative houses by the same methods we use to fill our jury boxes, we'd have what our democratic process was intended to deliver but no longer can and never will again without such comprehensive rethinking.

Under this system, each registered voter of proven citizenship, able to read at a 7th grade level, and free of gross mental defect and felony conviction would be asked to serve as a Senator or member of the House if randomly selected from their state or voting district. Terms would be standardized to 2 years, to reduce the burden on those who served reluctantly. Those who felt they did a good job and who wanted to continue could ask for a majority vote for extended service, but limited to four consecutive terms. Such votes would either grant them an extended term, or would require them to surrender their seat to a successor selected by the same random draw as provided it.

Corporate influence on elections would vanish. The posturing and fixed thinking would be greatly reduced, as would party-aligned polarization. We could focus on more important things than deciding which slick candidate's slanted portrayal of his opponent was more plausible. Minorities would be represented in a proportional manner. Ideas exchanged within the Senate and House of Representatives would compete on their merits and not on the corrupting currencies that accrue in the form of backscratching favors and control of committees that have ossified over decades.

What are the downsides? Some people will prove inept. This is a big issue if their tenure were protracted (which it will not be), and if their weakness was not mirrored, statistically, by other weak leaders selected to represent other locales. How bad is having a bad senator for 2 years? They do not sign treaties or individually ratify them. Rather, a "strong leader" in the legislative branch of government is, him/herself the cause of one of the great faults of our system, as the fruit leaders deliver is to attract more pork spending to their district at the expense of other districts across the country. This system would ensure, by and large, an equitable distribution along lines that could be convincingly argued by representatives who are unburdened by special interests.

Android Voice Actions

Tim Bray posted a note about a new "listen to" Voice Action which is intended to permit users to issue commands in a fairly flexible (and not strongly defined) manner such as "listen to Birthday by the Beatles".

It is a neat concept for integrating technologies, but I'd urge him to reconsider the wisdom of the command's voicing, as it is not an imperative command. You don't go to a concert and scream out "Listen to Freebird;" the correct form is, "Play Freebird!"

This is not a small issue. The more such mechanisms grow and blossom, the more vital it will be to choose and adhere to the right form of expression so it scales without inconsistencies and descent into mealy-mouthed passivity.

They should fix that.

Gmail/Google/Android contacts

Google's contact management system for Gmail has a wide impact on how I communicate these days. It is a poorly organized affair, whether you look at it from the perspective of an end-user or a third-party app coder who must make use of the data.

This entry covers the shortfalls I see from the end user side.

Impact on End Users

In a manner typical of Google's strengths of collecting information to serve the user, its various platforms (Gmail, Android, etc) keep track of any contact-related information, whether or not it is directly tied to a "contact" in the sense of the word consistent with common practice (a record for a person explicitly added to an address book by reference or authored from scratch). To wit, if you send or receive an email, the email address of the other correspondent will be filed helpfully away, whether or not this person is a "contact" the user has explicitly created a record for. Similar steps are taken with other communications, such as explicitly dialed phone numbers or caller ID information encountered while using your Android phone, for instance. It scales out to just about any type of media you could come up with ... tweets, IMs, activity on Youtube, etc.

This is a helpful sort of initiative, serving the user in future by allowing Google to offer auto-completion service should the user start entering a familiar phone number or email address in another literally (in the sense I typed an address rather than a contact name) addressed communication, etc. However, it falls flat when Google takes the entire venture too far, and fails to recognize and honor a distinction between people the user truly cares about in a persistent manner and those who are merely "passing ships in the night".

For instance, my Gmail page has a presence-tracking chat list in the left column, peopled largely by random bozos spiced with a few truly chat-worthy people. This is substantially due to customers who sent me a single email inquiry regarding my Android app having been automatically tossed into there alongside friends I have known for 15 years and see regularly in real-world social situations. It turns out there is an option to disable this automatic function, but one has to wonder if the better default would not have been to differentiate those people I have explicitly created a contact record from those with whom Google senses I have had some interactions.

Worse things happen when I visit Gmail's (or Android's) contact apps, where we see that the line between who IS a contact versus who is NOT a contact is blurred to the point of erasure. Google generically calls all these people "contacts", and attempts to placate my concerns about this lumping-in by placing the true contacts into a group called "My Contacts" and to throw all the others into a superset of this called "All Contacts". This is an unhelpful organization, and one that I believe replaced a superior model Google had previously employed.

In the old model, rather than have a superset of My Contacts which added in the fragmentary or rich hints of other people who might be good candidates for promotion to the fold of people I consider my true contacts, Google kept these aspiring contacts in a disjoint set called "Suggested contacts" (or similar). This offered me an easier means of managing those who were "My Contacts" and those who were not, as I could visit the set of Suggested Contacts and tag and move over any who seemed to want to come over to the rarified pantheon of power.

In the new model, there is no way I can review in one place the people and addresses Google has sensed might be important to me -- if I am seeing this information, it is in "All Contacts" and they are heterogeneously mixed in with the people who are already "My Contacts".

Why is this important? Well, other than having a chat bar of people I find relevant to my day, I am particularly dogged by having a manageable contact list for use in voice dialing on my Android phone. This is not only important for my own purposes, but for the purposes of everyone who uses my Android app, as it offers voice dialing and other services where users must speak the names of one of their contacts, and Google is not making it easy for users to manage who is a contact and who is not. This is crucial for me, as the speech recognizer is limited in how many names it can store, and the utility of the app plunges when the precious name space is clogged with transient losers who are difficult to keep from naturally trying to swim into the contact list.

Impact on Developers

It is also next to impossible for me to determine this myself in my Java code, but that is to be a subject of a second chapter touching on Android's lack of an object-oriented Java API for accessing contact data. The upshot of this deficiency is a vastly increased need for every third party code to write the same arduous URI-based code on sands that shift with each revision of the Android platform. It creates instability, versioning nightmares and exploding test case scenarios no small third-party developer will ever actually be able to identify, enumerate, let alone support properly.

Apple: how text search should work

My own sense of how the simple text search functions built into word processing, text editing and a variety of other common apps was probably forged by Apple's early usage patterns for this field (or was this a case of Microsoft doing something right?). It's simple, really: you invoke a key combination or menu function, and a dialog pops up to let you type out the pattern you'd like to find within the document you were last looking at. There are some other functions that are nice to have:

• Do you want to search forward or backward from the present spot?
• Must the case of the letters match?
• (in a fancy app such as a code editor) will there be regular expressions in the search criterion?
• (almost always) if the application can modify the text, other fields to permit search-and-replace

And, lastly, there are some contextual factors to consider, most notably: what should be in the text area where you enter the search string when the dialog box appears?

It seemed that there was a consensus of how this should be done, and things were spiffy: if there was text selected in the document when you pressed cmd+f, the selected text would be copied into the search box, affording you an easy means of double-clicking a word and hitting cmd+f and then enter to find the next occurrence.

In a thoughtful embodiment, successive presses of enter on the search box (or cmd+g from any context) would find successive occurrences of the search string. If there were no text selected in the document when you pressed cmd+f, the search box would come up blank or with the previous search string entered and selected, which offered a convenient alternate means to repeat a recent search. The fact that the text would be selected, however, meant that typing any new search string at all would replace the old one. This kept the fresh-start case from being even a tiny hassle. Though you still can find apps that do this precisely right (e.g., the "search within page" function in Firefox), life was good when apps abided by this pattern or a near variation.

But suddenly, the apps that seem most vital to me on the Mac do it pretty darn wrong. They offer no advantages, only shortfalls from the pattern described above. TextEdit (v1.6) and Dashcode (v3.0.1) do not take any text selection from the document when their cmd+f search box is invoked -- they present the previously searched-for text. If you want to search for a word you've selected, rather than the two steps of cmd+f/enter, you must perform 4 steps: cmd+c/cmd+f/cmd+v/enter to achieve this very common desideratum. However, they add a second search function ("Use selection for find" ... cmd+e) which behaves totally differently. It does not actually perform a find at all, but simply copies the selected text into an unseen buffer of what WOULD be in the search box. Actual searching is achieved by subsequent use of cmd+g or shift+cmd+g. Pressing cmd+e when there is no text selected greets the user with a "bonk" error tone... as if he made a mistake of some kind ... stupid user.

Proving that more thought can only be more toxic, X-Code (v3.2.2) takes the cake. It starts with the same behavior of the smaller and adds a third function, ("Find selected text"... no cmd key shortcut) which almost works as you'd like, but it does so without a searchbox being present, which denies you access to any of the other options this box affords (if could be summoned via cmd+f). Here again, the case of your using this function when there is no selected text is rewarded by a "bonk" tone.

Why are so many "behaviorful" functions created when the problem and its sub-cases are so simple? If there is a plausible rationale for why anyone would prefer the approaches taken in these apps to the simpler and more flexible pattern defined above, I'd like to hear it. I would like to feel this is an embarrassing situation of the right way being patented, as I'd tend to think only someone hamstrung by the exigencies of our patent system could prompt Apple to produce such an almost Soviet-style solution to text search. 

Take Away Apple... make your text searches as easy as cmd+f, cmd+g, shift+cmd+g -- with additional options for text replacement and such being available on a find panel that can be dismissed by pressing escape. Your present approach is elephantine and requires the user to mull a variety of tools when only one is needed.