A scratchpad post to remind myself how to configure a Kontakt instrument so that light guides and knobs will show up correctly in Komplete Kontrol.  There’s a video walkthrough at the end of this post.

Here’s a picture of the destination – the light guides appear on the keyboard and Komplete Kontrol knobs are mapped to the patch in two banks.

Light Guides

Use the Factory/Utilities/Set Key Color script to set the key colors.  This is saved as part of the instrument, in Kontakt.

Mapping to knobs on Komplete Kontrol

Use “host automation” within Komplete Kontrol to map knobs to controls within the Kontakt patch.  These mappings are saved as user presets within Komplete Kontrol not Kontakt.

Use the Factory/Utilities/6 MIDI Controllers script to “make controls visible” if they’re not directly available for host automation.  This takes two “save” actions.  The script is saved into the Kontakt instrument, the host automation mapping is saved as a user preset within Komplete Kontrol.

Here’s a video walkthrough.

This one’s going to get the least hits ever, I bet.

I transferred the authoritative nameserver of a domain from Godaddy to Cloudflare and things got stuck.  The NS propagated pretty well, but it never got picked up by Google or Verisign’s public DNS (check with https://www.whatsmydns.net).  Since my ISP uses Google’s 8.8.8.8 server for customer DNS, I couldn’t reach my sites and mail got goofy.

The problem turned out to be outdated DS records that lingered at Godaddy after I tried their DNSSEC product, had all sorts of problems and turned it off.   DS records aren’t deleted automatically in that process — they need to be deleted manually on the Domain Details/Settings tab.  Who knew?  Why should I have to know??

Google (and Cloudflare, the destination authoritative server) saw the outdated DS records and ruled the domain bogus.  In the case of Cloudflare, it never completed the setup process (constantly rescanning the nameservers and saying “Pending Nameserver Update”).

Google’s public DNS simply wouldn’t resolve the names and returned SERVFAIL.  Here’s an example of the dig command when it was failing (note the period at the end of the command).

dig @8.8.8.8 www.example.com.

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.example.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42587
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.example.com. IN A

Here’s the result of a query to DNSVIS.NET query of the name.  It’s pretty incomprehensible but if you get a page that looks like this, you’ve probably got the same problem I had.

This was the page that cracked the case for me:

https://developers.google.com/speed/public-dns/docs/troubleshooting

One last thing.  Here’s the page where you can flush the Google DNS cache for a domain.

https://developers.google.com/speed/public-dns/cache

This is a scratchpad post to remind myself how to put together a machine-learning system on a Mac.  This won’t work on a PC as some of the software is Mac-only.  In this configuration a WiiMote (input device) is connected to Wekinator (real time interactive machine-learning software) through OSCulator (OSC bridging and routing software).  Wekinator outputs are mapped to MIDI to drive Ableton Live through another instance of OSCulator.

Here is a block diagram (clicking on it makes it bigger)

Before beginning

Grab a copy of the following .oscd templates to simplify the connection from OSCulator to Wekinator — https://github.com/fiebrink1/wekinator_examples/tree/master/inputs/Wiimote/WiimoteViaOsculator_MacOnly .  This example uses the 3-input template.

WiiMote to OSCulator

WiiMote to OSCulator is a built in feature of OSCulator.   Open OSCulator with the 3-input template linked above.  Open the sliding panel on the right side of the main OSCulator page, turn on the WiiMote, click “Start Pairing”.   Here’s the way it looks when it’s working.

OSCulator to Wekinator

This first instance of OSCulator translates the motions of the WiiMote into OSC messages and pushes them to Wekinator on Wekinator’s default UDP port (6448).  If you’re using the example .oscd file, this should be working now.  I’ve included the mapping if you are building this from an empty OSCulator file.

If you are starting from an empty OSCulator file, here is what the Parameters page looks like in this first instance of OSCulator.   If Wekinator is running, locating and selecting these entries should be available through the drop down menus.

Wekinator to OSCulator (this is the second instance of OSCulator)

The default Wekinator output port is 12000.  The second instance of OSCulator (instantiated through File/New) is set to listen on port 12000.  If Wekinator is running, OSCulator will pick up the Wekinator outputs and they should be displayed in the Messages column of OSCulator.

2nd instance of OSCulator to Ableton Live

OSCulator has been configured to convert the OSC messages from Wekinator to MIDI CC messages in this example.  I picked those message numbers because they’re within a range (85-90) that’s generally not used by other devices.

Once OSCulator is producing MIDI, Ableton Live can be trained to apply those MIDI signals in the normal way.  Turn on the MIDI Map Mode switch (blue, in the upper right corner, says “MIDI”), click on the control that should receive the MIDI signals and toggle the device on and off in OSCulator.  The mappings will appear in the box on the left (under “MIDI Mappings”) as they’re added.  I found it useful to turn all the devices off (untick the boxes in the left column) before starting the mapping.

Notes and Tips

• I found that controls sometimes wouldn’t work.  It turned out that sometimes controls were set to a higher value than the maximum value coming to them from OSCulator.  So the control wouldn’t “pick up” the MIDI signal.  Setting the unresponsive control (eg. “Warmth”) to zero solves that problem.
• Signals coming into Live were quite jittery at first.   Cranking up the “Smoothing” settings in the 1st instance of OSCulator fixed that.
  

This is a scratchpad post for links to Drone articles that have caught my eye

Click here – to get back to the “Aerial Favorites” page on PrairieHaven.com

Why the Drone Revolution Can’t Get off the Ground

Someone Crashed a Drone on The White House Lawn

NYTimes article about the White House drone

Of Guns and Drones

Giving the Drone Industry Leeway to Innovate

Days of Wine and Droning – Gail Collins

Audubon Socieity – How Drones Affect Birds

The Verge – Deadmouse on Drones (Youtube video)

IEEE Spectrum – California’s No-Drone Zone

HackADay – 1 hour home-brew drone build project

Bloomberg – FAA says small drones will provide significant benefits

Politico – President Obama executive order on drone privacy due soon

NYTimes – New to the archeologist’s toolkit, the drone

NYTimes Editorial – Regulating the drone economy

IEEE Spectrum – What Might Happen If an Airliner Hit a Small Drone?

Bloomberg – What the French know about drones that Americans don’t

Samantha Dickinson Tweeted this photo from the ICANN meeting today and tagged it #VolunteerFatigue.  I’m living proof.

Let’s say that each of those 7 working groups needs 4 volunteers — that’s almost 30 people.  Just from the ccNSO.  Just for upcoming working groups.  Never mind the GSNO, ALAC, SSAC and GAC.  A rough extrapolation puts the total required at over 100 volunteer community members just to handle the IANA/Accountability/Transition work.

ICANN is dangerously thin at the bottom of the bottom-up process.  Are there that many people with the experience/time/expertise/will available?  What happens to all the other Working Group work in the meantime?

There’s a difference between being a customer and being a client.  People on both ends of a relationship always get into trouble when they don’t understand this.

A customer – is always right

A client – expects to hear the truth, especially when it’s unpleasant

This is true in professional relationships.  Doctors, lawyers, accountants are expected to provide good advice in their professional relationship — but their customers are always right.  Reports should be: on time, of high quality, and delivered at a fair price.

The same goes for religious relationships.  When we are in the worship service, we are the clients of the person leading the show.  But we customers are right — the coffee should taste good, the roof shouldn’t leak and we have every right to be treated with respect.

In higher education the student customer should get good value for their tuition dollar, grades should arrive on time, campus services should be superb and their teachers should be engaged and respectful.  But the student is the client of the teacher when it comes to grades and feedback on their work.

The relationship between the regulated and the regulator is a mix of services (a customer relationship), policy and compliance (which are stakeholder and client relationships).

Be careful when you cross the streams.

I was reading the Appendices of a recent ICANN report when I came across an interesting assumption built into their analysis.  The boffins that did this portion of the study are projecting 22% annual growth in total domains for the next five years.

Here’s the reference that caught my eye:

You can find this on page 150 of the newly-released Whois study — done by the Expert Working Group on gTLD Directory Services.  Here’s the link to the study — https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf

The thing that struck me was that whopping 22% annual growth rate.  Partly this is due to some pretty optimistic assumptions about the growth in the number of new gTLDs (I’m willing to bet any money that the beginning of 2015 will not see 200,000 gTLD domains in the root).  But leaving that aside, 22% year over year growth isn’t something we’ve seen since pre-bubble glory days.

Here’s a little chart I put together to show you the history.  We’re running about 4% growth right now.  A long way from 22%.  If I were building budgets for ICANN, I’d be seriously researching where these projections are coming from and applying a pretty serious quantity of cold water.  Just saying…

Notes to the nit-pickers:

• The assumptions are in a scoping study done by IBM to determine how much a system would cost — so these numbers could be pretty old, given how long the EWG has been running
• These numbers do not include ccTLDs (since IBM didn’t) — they’d be a lot prettier if I had, since that’s where all the growth has been for the last 5 years or so
• Verisign seems to be quite far behind in publishing their quarterly statistics reports, so I had to finish up with RegistrarStats data.  No warranty expressed or implied.
• Ping me if you want the spreadsheet that this chart is built on — visit the Get In Touch page to find out how

This post is a heads up to all uber-geeks about a terrific research initiative to try to figure out causes and mitigation of name-collision risk.  There’s a $50,000 prize for the first-place paper, a $25,000 prize for the second place paper and up to five $10,000 prizes for third-place papers.  That kind of money could buy a lot of toys, my peepul.  And the presentation of those papers will be in London — my favorite town for curry this side of India.  Interested?  Read on.  Here’s a link to the research program — you can skip the rest of this post and get right to the Real Deal by clicking here:

www.NameCollisions.net

Background and refresher course — what is the DNS name-collision problem?

Key points

• Even now, after months of research and public discussion, I still don’t know what’s going to happen
• I still don’t know what the impact is going to be, but in some cases it could be severe
  
• Others claim to know both of those things but I’m still not convinced by their arguments right now
• Thus, I still think the best thing to do is learn more
• That’s why I’m so keen on this research project.

Do note that there is a strong argument raging in the DNS community about all this.  There are some (myself included) who never met or even heard of the DNS purists who currently maintain that this whole problem is our fault and that none of this would have happened if we’d all configured our private networks with fully-qualified domain names right from the start.

Where were those folks in 1995 when I opened my first shrink-wrapped box of Windows NT and created the name that would ultimately become the root of a huge Active Directory network with thousands of nodes?  Do you know how hard it was to get a domain name back then?  The term “registrar” hadn’t been invented yet.  All we were trying to do is set up a shared file, print and mail server for crying out loud.  The point is that there are lots of legacy networks that look like the one depicted below, some of them are going to be very hard and expensive to rename, and some of them are likely to break (perhaps catastrophically) when second level names in new gTLDs hit the root.  m’Kay?

Private networks, the way we’ve thought about them for a decade

Here’s my depiction the difference between a private network (with all kinds of domain names that don’t route on the wider Internet) and the public Internet (with the top level names you’re familiar with) back in the good old days before the arrival of 1400 new gTLDs.

Private networks, the way they may look AFTER 1400 new gTLDs get dropped into the root

The next picture shows the namespace collision problem that the research efforts should be aimed at addressing.  This depiction is still endorsed by nobody, your mileage may vary, etc. etc.  But you see what’s happening.  At some random point in the future, when a second-level name matching the name of your highly-trusted resource get delegated, there’s the possibility that traffic which has consistently been going to the right place in your internal network will suddenly be routed to an unknown, untrusted destination on the worldwide Internet.

The new TLDs may unexpectedly cause traffic that you’re expecting to go to your trusted internal networks (or your customer’s networks) to suddenly start being routed to an untrusted external network, one that you didn’t anticipate.  Donald Rumsfeld might call those external networks “unknown unknowns” — something untrusted that you don’t know about in advance.

Think of all the interesting and creative ways your old network could fail.  Awesome to contemplate, no?  But wait…

What if the person who bought that matching second-level name in a new gTLD is a bad-actor?  What if they surveyed the error traffic arriving at that new gTLD and bought that second-level name ON PURPOSE, so that they could harvest that error traffic with the intention of doing harm?  But wait…

What if you have old old old applications that are hard-coded to count on a consistent NXDOMAIN response from a root server.  Suppose that the application gets a new response when the new gTLD gets delegated (and thus the response from the root changes from the expected NXDOMAIN to an unexpected pointer to the registry).  What if the person that wrote that old old old application is long gone and the documentation is…  um…   sketchy?  But wait…

To top it all off, with this rascal, problems may look like a gentle random rain of breakage over the next decade or so as 2nd-level names get sold.  It’s not going to happen on gTLD-delegation day, it’s going to happen one domain at a time.  Nice isolated random events sprinkled evenly across the world.  Hot damn.  But wait…

On the other end of the pipe, imagine the surprise when some poor unsuspecting domain-registrant lights up their shiny new domain and is greeted by a flood of email from network operators who are cranky because their networks just broke.  What are THEY going to be able to do about those problems?  Don’t think it can happen?  Check out my www.corp.com home page — those cats are BUSY.  That domain gets 2,000,000 error hits A DAY.  Almost all of it from Microsoft Active Directory sites.

So argue all you want.  From my perch here on the sidelines it looks like life’s going to get interesting when those new gTLDs start rolling into the root.  And that, dear reader, is an introduction to the Name Collision problem.

Mitigation approaches.

Once upon a time, 3 or 4 months ago when I was young and stupid, I thought this might be a good way to approach this problem.  I’m going to put it in this post as well, but then I’m going to tell you why it won’t work.  Another explanation of why we need this research and we need it now.

Start here:

If you have private networks that use new gTLDs (look on this list) best start planning for a future when those names (and any internal certificates using those names) may stop working right. 

A bad solution:

In essence, I thought the key to this puzzler was to take control of when the new gTLDs become visible to your internal network.  It’s still not a terrible idea, but I’ve added a few reasons why it won’t work down at the end.  Here’s the scheme that I cooked up way back then.

By becoming authoritative for new gTLDs in your DNS servers now, before ICANN has delegated them, you get to watch the NXD error traffic right now rather than having to wait for messages from new registries.  Here’s a list of the new gTLDs to use in constructing your router configuration.

This is the part where you look at the NXD traffic and find the trouble spots.  Then, with a mere wave of my hand and one single bullet point, I encourage you to fix all your networks.  Maybe you’ve got a few hundred nodes of a distributed system all over the world that you need to touch?  Shouldn’t be a problem, right?

This is the Good Guy part of this approach.  Of course, because we all subscribe to the One World, One Internet, Everybody Can Reach Everything credo, we will of course remember to remove the preventative blocking from our routers just as soon as possible.  Right?  Right?

The reasons why this won’t work:

The first thing that blows my idea out of the water is that you probably don’t have complete control over the DNS provider your customers use.  I still think this is a pretty good idea in tightly-run corporate shops that don’t permit end users to modify the configuration of their machines.  But in this Bring Your Own Device world we live in, there’s going to be a large population of people who configure their machines to point at DNS providers who aren’t blocking the names that conflict with your private network space.

Let’s assume for a minute that everything is fine in the internal network, and the corporate DNS resolver is blocking the offending names while repairs are being made (hopefully cheaply).  Suppose a road warrior goes out to Starbucks and start using a laptop that’s configured to point at Google’s 8.8.8.8 DNS resolver.  In the old days before new gTLDs, the person would fire up their computer, go to the private name, the query would fail and they would be reminded to fire up the VPN to get to those resources.  Tomorrow, with a conflicting new gTLD in the root, that query might succeed, but they wouldn’t be going to the right place.

Here’s the second problem.  My tra-la-la scheme above assumes that most mitigation will be easy, and successful.  But what it it’s not?  What if you have a giant Active Directory tree which, by all accounts, is virtually impossible to rename without downtime?  What if you have to “touch” a LOT of firmware in machines that are hard-wired to use new gTLDs.  What if vendors haven’t prepared fixes for the devices that are on your network looking at a new gTLD with the presumption that it won’t route to the Internet (yet now it does)?  Or the nightmare scenario — something breaks that has to be diagnosed and repaired in minutes?

The research project

See why we need you to look hard at this problem?  Like, right now??  ICANN is already delegating these domains into the root.  Here’s a page that lists the ones that have already been delegated.

http://newgtlds.icann.org/en/program-status/delegated-strings

If you see one of your private network names on THIS list, you’re already in the game.  Hooyah!  So this is moving FAST.  This research should have been done years ago, long before we got to this stage.  But here we are.  We, the vast galaxy of network operators and administrators who don’t even know this is coming, need your help.  Please take a look at the NameCollisions.net site and see if you can come up with some cool ideas.  I hope you win — because you’ll help the rest of us a lot.  I’ll buy you a curry.