Installing Flow-Rite battery watering on a Polaris Ranger EV

Definitely a narrow-audience scratchpad post.  We love our electric Polaris Ranger EV utility vehicle here at Prairie Haven.  But putting water in the batteries is not a lot of fun.  Messy, tedious, slow, etc.  So today’s project was to put a battery watering system in.

UPDATE UPDATE: ONE YEAR LATER

Everything is fine and we still heartily endorse this gizmo.  Battery watering now happens once a month.

Winter tip (and correction):  We do water the batteries in the winter after all.  I use the EV to plow snow which is pretty tough on the batteries and makes them use more water than in the summer.  It works fine in winter, but here’s the tip — don’t do this when the EV has been below freezing for a while.  Sometimes the couplers freeze.  It’s easier just to wait for a few days of above-freezing temps in the garage than it is to coax the couplers into doing their thing when they’re frozen.

We did forget to charge the batteries before we watered them once.  THAT was a pain the neck because we had to go back to the “old way” of watering to siphon off the water at the top of the batteries.  Never again!  We’ve added this handy reminder-sign to the business end of the filler hose so we’ll never forget again.

UPDATE: one month later and the results are in

Wow.  This is a complete success.  We just watered the batteries for the first time and several things stand out.  First, the batteries required dramatically less water — only a few ounces on each bank of four batteries.  Second, the batteries didn’t require any cleaning because there was no spillage at all — unlike before where the battery tops were always covered with battery acid and needed extensive work before starting to do the watering.  Third, as a result the job only took 5 minutes instead of the 3 hours we used to spend.  Pry these out of our cold dead hands.  Now, back to the original post…

Project start: 3pm

Standing on the driver’s side.  There’s the diagram of the finished system (see below), an example of the gizmo that’s going to go into the batteries, the battery compartment and the really-useful ratchet box wrench for loosening the battery hold downs.

Bag of watering gizmos

The kit came disassembled, which I really liked because we only needed to loosen the battery hold downs, not take them off.  We could thread the hoses under the hold downs and wires before hooking them to the watering gizmos.

First couple watering gizmos

We picked the easiest ones to learn on (the hardest ones are at the back – you owners already know this).  Having the hold downs loose was helpful for wiggling the gizmos in, but the breakthrough came when we started twisting the lockdown handles of the battery caps a bit.  The little handles are what really collide with the hold downs, twisting them out of the way made a big difference.

Cutting and installing the tubing was easy — we mostly used the measurements on the diagram, especially the 8-inch lengths.  Some of the longer runs (10-14 inches) had to be custom measured because the diagram didn’t match the layout of our batteries.  We’d just stick one end of the tube on, hold it close to its destination and then snip it to fit.  We wound up with about a foot of tubing left over, but we were prepared to steal some from the water hook-up hoses if we ran short.

It goes a lot faster with two people splitting the tasks

Here’s Marcie dropping gizmos into the batteries.  It’s way more than twice as fast when two people can each be concentrating on half the job at hand.  Otherwise there’s lots of changing position/tools.

All done: 5pm

This is the way the finished product looked.  This is the first side, just to keep things straight.  The whole project took a couple hours and we could do it much faster now that we’ve done it once and learned some tricks.

Layout diagram

I know, the copyright notice is pretty intimidating — but hey, this diagram’s on their web site for all to see.  Here’s the link to their site:

https://flow-rite.com/sites/all/files/file/pdf-pro-fill/layouts/POLARIS-96V.PDF

The part number for this rig is BG-U96V-1G

You also need the little squeeze-bottle filler that drops into a gallon of distilled water.

Results:  The next morning

We watered the batteries (and cleaned them) this morning, remembering to charge the batteries before filling them.  What used to be an “all morning project” was a short job that fit in before Marcie headed off for her real all-morning project.

Here’s an action shot — showing off my battery-watering pants.  They’re more like a battery-watering apron these days.  I think they can now be retired.

We splurged and spent a few minutes cleaning the batteries so they’d look spiffy for this final photo.  Compressed air to spray off the debris, liberal dose of battery cleaner, rinsed them off with the hose and another round of compressed air to dry things off.

We were wondering if we’d be able to tell when to quit pumping water and accidentally overfill the batteries.  No worries there — the little squeeze bulb just quits, we could both feel the really abrupt transition to “no more room” as we went to full-batteries.  Those little floating shut off valves work great.

Today’s watering took about a gallon of water (pretty normal) and 15 minutes (pretty nifty!).

The EV

Here’s a picture of the compleat EV — purple collecting bags, wide/smooth tires and a watering system.

Winter Tips:

I talked to the folks who sold us the kit about what to do in winter.  My main concern was that trapped water would freeze and rupture the tubing.  They told me that the water finds its way into the batteries as the water level drops enough to open those valves back up.  My plan is not to water the batteries in winter, just to play it safe.

Electrical repair of Power Trac PT-1850

A scratchpad post as I diagnose and repair an electrical fault in our Power Trac PT-1850.  Pretty sparse right now, just starting.

The Problem:

  1. Reset circuit breaker
  2. Turn ignition on without starting motor — I get the normal beeps, flashing strobe and 12.4 volts on the gauge (normal for a 12 volt battery at rest)
  3. Crank and start the motor
  4. Voltage drops to around 11 volts (indicating to me that something is really pulling hard, maybe a short) and stays there for about 15 to 30 seconds, then the breaker pops and the voltage jumps up to 13.2 (pretty normal alternator-charging voltage, battery seems to be getting charged up).
  5. With the breaker open/popped the strobe stops flashing. But tilt seat, emergency seat switch and draft control are still operational and the tractor made it back to the barn (about a mile).
  6. Use the ignition switch to shut off the engine (which is weird because the breaker is right in front of the ignition switch in the wiring diagram, so why does it still work?)
  7. The ignition switch is dead *after* I shut the engine off — no strobe, no beeps, no voltage on the gauge when I key it on.
  8. Return to number 1 above

My current theory is that I have a short (first project — see if I can figure out which circuit it’s in, and where). One option is to replace the alternator (I have one coming, but at $600 I’d like to avoid opening the box if I can).

Wiring Diagrams

Here’s a PDF I got from Power Trac (which is newer than my machine and doesn’t match up as the next one – figuring out which one is right is another task for today)

1850 Wiring diagram 6-1-20110001

Here’s an older GIF (I need to retrace my steps to figure out where I found this on the ‘net)

wiringlogicfromptdwgs

UPDATE: 2018

Here’s a pretty good example of how a lot of Power Trac puzzlers get solved by the gang on TractorByNet.  This long thread talked all around the issue, which was eventually solved by replacing the alternator. Here’s a link to that thread.

https://www.tractorbynet.com/forums/power-trac/346106-weird-electrical-puzzler-breaker-pops.html

But in addition I a) bought a second PT-1850 so that time-critical projects could continue during breakdown times and b) sent this guy back to PowerTrac for repair plus an 800-hour

MySQL repair or replacement on OSX Server (Yosemite)

ID-100264078

Another scratchpad post.  This one is a reminder of what I did to repair MySQL on OSX Server after the upgrade from Mavericks to Yosemite kinda broke things.

I was working to solve two problems: intermittent “unable to connect to database” errors on all our WordPress sites, and the dreaded “unable to update PID” errors when starting and stopping MySQL.

  • I think the “unable to connect” errors are caused by intruders trying to brute-force break the passwords on my (roughly 35) web sites.  This problem can possibly be cured just by doing the “tuning” steps at the end of the cookbook.
  • “Unable to update PID…” type problems are more symptomatic of a broken MySQL implementation and probably require the whole process.

None of these were terrible (a system-restart every few days kept things more or less in check) so I limped along for a while after upgrading from Mavericks to Yosemite, but it finally drove me crazy and I decided to upgrade MySQL and rebuild all the databases.

The cookbook

I tried several approaches and finally landed on one which I can reliably repeat in the future (as long as the good folks at Mac Mini Vault continue to provide their magnificent script).

backup:

I used backups from all sorts of places.  I thought I was being a little over the top, but things went wrong and I was really glad to have all these safety nets.  Here were the backups I had available:

  • Time Machine backups of the /usr/local/mysql/ directory
  • Pre-upgrade copies of the /usr/local/mysql/data/ directory (and their Time Machine backups)
  • Historical (nightly) MYSQLDUMPs of all the databases (and their Time Machine backups).  Use this command to write each database to a text file.  I have a script that does all 35 of my databases at once, every night.
    sudo mysqldump -u root -p[root_password] [database_name] > dumpfilename.sql

clear out the previous installation of MySQL:

This was by far the hardest part to get right.  MySQL doesn’t have an “uninstall” script and reacts badly when little odds and ends are left over from previous installations.  My OSX Server has been running MySQL since OSX Lion and there was a fair amount of cruft left behind that was causing some of the trouble.  Here’s my current list of things to move or remove (although not all of them will exist on any given machine):

  • move the old data directory (/usr/local/mysql/data/) to someplace else (yet another backup)
  • rename the old base MySQL directory (this is the directory with the version-number that the mysql alias points to – I renamed rather than deleted as a backup)
  • remove the /usr/local/mysql alias (it’s going to get recreated during the install, pointing at the new/correct base directory)
  • move MySQL.com out of /Library/StartupItems/
  • move My* out of /Library/PreferencePanes/
  • move My* out of your account’s /Library/PreferencePanes/  (I had two mismatched ones of these, one lurking in /Users/admin/Library/PreferencePanes that was really old)
  • edit /etc/hostconfig and remove the line MYSQLCOM=-YES- (If it’s still there — this was left over from the days when MySQL shipped as part of OSX Server)
  • remove entries for receipts for mysql in /Library/Receipts/Install-history.plist (I edited the plist with a text editor to do this)
  • remove receipts for mysql in /private/var/db/receipts/
  • remove mysql-related scripts from /Librarly/LaunchDaemons/
  • remove any aliases for mysql.sock from /var/mysql/, /etc/ and /private/var/mysql/ (I’ve had good luck leaving the directories in place and just deleting the aliases – ymmv)
  • If the Mac Mini Vault (MMV) script has been run before, here are a couple more things:
    • remove the MYSQL_PASSWORD item from the desktop
    • remove MySQL-install.plist from your /Downloads/ directory

install MySQL using the MMV script:

NOTE: the folks who maintain the script only support it for a clean install of MySQL on a freshly-loaded version of OSX.  So this cookbook is OUTSIDE the bounds of what they support — please don’t complain to them if things break.  Instead thank them for sharing this script publicly, and consider buying some of their services.

Click HERE to read an introduction to the script on MMV’s site

Click HERE to read the important documentation of the script

Last step:  change the MySQL root password:

sudo mysqladmin -u root -p'MMV-generated-password' password 'mypasswd'

MySQL should now be running properly.  I restarted the server to make sure MySQL started up on a reboot.  I also started and stopped MySQL a few times from the command line to make sure that the “unable to update PID…” problems were solved:

sudo /usr/local/mysql/support-files/mysql.server stop
sudo /usr/local/mysql/support-files/mysql.server start

I do NOT TRUST the MySQL preference-pane that is installed in OSX System Preferences and don’t use it – that may have been another source of dreaded “failure to update PID…” errors.  Just sayin’

import the databases:

I chose to rebuild my databases from the nightly dumps.  I tried various versions of “moving the data directory back and using the Update command” and had a rough time with all of them.  Besides, rebuilding the databases for the first time in many years seemed like a good housekeeping item.  I have about 35 databases — it took about an hour.  Note: change all the ‘mydb’ ‘myuser’ ‘mypasswd’ to values that match your environment.

  • Log into mysql as MySQL’s root user:
mysql -u root -p'mypasswd'
  • Create the databases in mysql using this command:
create database mydb;
  • Create a user for each database in mysql using this command (btw Sequel Pro 1.0.2 is crashing when it creates a user — a known bug, just do it from the command line).  Note: I’m assuming that you’re only using MySQL for WordPress sites like I am, and only need one user per database — this process will get a lot more tedious if you have multiple users per database.
grant all privileges on mydb.* to myuser@localhost identified by 'mypasswd';
  • Import the text-dump of each database into the newly-created empty one using Sequel Pro — File > Import

tuning:

Two things have really helped with the brute-force attacks.  Opening up MySQL a bit and changing a setting in PHP.

To give MySQL a little more oxygen, I followed the guidelines in a sample .cnf file that came with the Mac Mini Vault script.  I slightly changed the settings, mostly to make them conform to MySQL standards (I’m not sure whether this matters).

  • edit /usr/local/mysql/my.cnf and add these lines at the very bottom (these are just a starting point, feel free to fiddle with them a bit):
innodb_buffer_pool_size=2G
skip-name-resolve
max_connect_errors=100000
max_connections=500
  • edit /private/etc/php.ini and turn off persistent links.  Here’s the way my file looks right now:
; Allow or prevent persistent links.  
; http://php.net/mysql.allow-persistent 
mysql.allow_persistent = Off

Image courtesy of Stuart Miles at FreeDigitalPhotos.net

 

 

Adding SSL to my OSX server

I decided it was time to make a little statement and add “always on” encryption to this completely innocuous site.  The online equivalent of moving a lemonade stand inside a bank vault.  Now when you read about refurbishing my car, or fixing a seed drill, you’ll be doing it over an encrypted connection.

This is another scratchpad post for folks who run an OXS Server and want to use a multi-domain UC (unified communications) SSL certificate.  The rest of you can stop here — this is probably the most boring post of all time.

UPDATE – May 2016 – Cloudflare Origin Cert on an OSX Server:

This section describes using Cloudflare Origin Certificates, the following section is the original post where I was installing a Godaddy cert.

I’ve taken to using Cloudflare for all my sites.  If you haven’t come across them, I heartily recommend you take a look — they’re a pretty nifty gang.  Somewhere along there they added SSL to all the connections from end-users to their servers but that left the link from Cloudflare to my sites unencrypted.

They now support several ways to secure that connection – most of which are free.  Free is good, since commercial certs to cover the 20 or so websites I host start to add up.  I decided to try implementing their preferred approach where they issue me an “origin cert” (rather than using a self-signed cert which wouldn’t give end-users as much confidence).

Doing that on OSX Server is dead simple.  Here are the steps

Create a new cert-request on OSX Server.

CloudflareCert1

We’ll create one for my buddy Foo (at bar.com).

CloudflareCert2

Which results in a cert request that looks like this

CloudflareCert3

Go to Cloudflare (I’m assuming the site is already established there) and submit the cert request.  Note that I’ve elected to submit my own CSR.  Cloudflare has a pretty interesting process to do it on their own but I decided I needed to generate the CSR within OSX Server in order to have a socket for the cert when it is issued.

CloudflareCert4

Cloudflare generates the cert and provides it in a variety of formats.  I elected PEM format and the certificate appears in the window.  I copied/pasted/saved that text into a new text file (demo-cert.pem in this example) and saved it to the desktop of the server.

CloudflareCert5

Back to OSX Server now.  The CSR shows up as a pending cert in the Certificates window.  Double-clicking it results in this screen.   Drag the newly-saved demo-cert.pem file into the Certificate Files box and all is complete.

CloudflareCert6

Create a new SSL web site, use the newly-installed cert, point it at the same directory as the port-80 cleartext site, do a redirect to the port-443 site to complete the job.  Don’t forget to tick the “allow overrides using .htaccess files” box in Advanced Settings for the site so’s the permalinks work.

Original post – August 2014 – Godaddy Cert

I’m a happy Godaddy customer, so the examples in this post are Godaddy-oriented.  But the theory should apply to any Unified Communications (UC) cert vendor.

Single-domain cert

Here is Godaddy’s list of steps for installing a standard single-domain cert.   Click here to view the help page these came from.  The process for a multi-domain cert is almost the same, but let’s start with “vanilla.”

To Generate a CSR with Mac OS X 10.7-10.9

  1. On the Mac, launch Server.
  2. Click Certificates on the left.
  3. Click +.
  4. Click Next.
  5. Complete the on-screen fields, and then click Next
  6. Either copy the CSR that displays, or click Save and save the file locally.

After you have successfully requested a certificate, you need to install the certificate files we provide on your server.

To Install an SSL Certificate with Mac OS X 10.9

  1. Download your certificate’s files — you can use the files we offer for Mac OS 10.6 (more info).
  2. On the Mac, launch Server.
  3. Click Certificates on the left.
  4. Double-click the common name of the certificate you requested.
  5. Click and drag the certificate and bundle files into the Certificate Files section.
  6. Click OK.

This installs the certificate on your server. To verify its installation, you should see your certificate’s common name listed in the Settings menu.

Multi-domain Unified Communications (UC) cert

There are two things that are different when using a UC cert.

Change #1) Use one CSR to request the cert

  • Create one certificate signing request (CSR) in the OSX Server app, no matter how many domains are going to be covered by the UC cert.  The CSR is just creating a socket into which the certificate is going to be installed by OSX Server and only one such socket is needed.
  • All of the domains added through Godaddy’s “manage Subject Alternative Names (SAN)” process will work once the cert is installed.
  • Take care in choosing the domain name when creating the CSR.  This will be the “common name” on the cert and is the only domain name that cannot change later.  This is the apex of the hierarchy of the cert and is the only one that will appear if site-visitors view the cert.
  • The picture below is an example of the Godaddy management interface looking at a (prior version of) the cert that secures this page.  That cert appears in OSX Server’s list of Trusted Certificates as “server.cloudmikey.com” — that name came from the CSR I generated in OSX Server.
  • The alternate domains that will also work with this version of the cert are “cloudmikey.com” and “server.haven2.com” but those names are entered at the Godaddy end, NOT through CSR’s from OSX Server.
  • To restate — just create one CSR and add the rest of the domains through the cert-vendor’s Subject Alternative Name process.  In my case, the domain in the CSR was for “server.cloudmikey.com”

GD-UCC

Change #2) Add domains to the cert BEFORE downloading it to OSX Server

  • Don’t download the cert that’s created from the CSR just yet.  It will only have the Common Name and doesn’t yet include the other domains that the cert will cover
  • In the case of the cert shown above, the SANs “cloudmikey.com” and “server.haven2.com” were added through Godaddy’s cert-management interface before I downloaded/installed the cert.

Follow the vendor-provided download/install steps. 

Now that the cert has the proper names added, it installs the same way a single-domain cert does (see above).

To recap Godaddy’s instructions: download the OSX 10.6 version of the files, unzip them, click on the pending cert request in Server, drag the two unzipped files into the CSR when it asks for them, click OK and wait a bit while the cert installs.

Verify that the cert covers the domain-names that are needed

Once the cert has been installed, review (double-click) the cert on OSX Server to make sure that all the needed domains are there.  The list of domains is in the middle of the cert, each entry is titled “DNS Name”  If they’re all there, jump ahead and start assigning the cert to web pages and services.

If the names listed on the installed cert don’t match what’s needed, add the missing domains before using it

  • Delete the cert from OSX server (it’s OK, it’ll be downloaded again in a jiffy)
  • Return to Godaddy and modify the Subject Alternative Names (SANs) to get the domains right
  • Create a new CSR on OSX Server – again, this is just a socket into which the cert will install.
  • Download/install/verify the cert

Note: The cert will install correctly as long as the domain in the new CSR matches one of the domains covered by the cert.  But it will always be appear under the common name on the cert, which confused me.  I surprised myself by installing this cert under a “haven2.com” CSR — it installed just fine, but it’s name changed to “server.cloudmikey.com” on the list of Trusted Certificates in OSX Server.  Best to avoid confusion by creating the replacement CSR under the common name.

Once the cert is right, associate the cert with web pages and services.

  • Web pages and services will operate correctly as long as the domain of the web-page or service matches one of the domains on the cert.
  • It doesn’t matter that the common name of the cert (server.cloudmikey.com in this case) doesn’t match the domain of the web page (haven2.com).

That concludes my report.  This web page is running under a later version of that cert — you can see what it looks like by double-clicking the “lock” in the URL bar of your browser.

Renew the cert

A year has passed and it’s time to renew the cert.  Here’s a checklist:

  • Launch the Server app, open the cert that is coming up for renewal, click the “renew” button, generate a CSR.
  • Renew the cert at the cert-provider, using the newly-generated CSR (this is a copy/paste operation at Godaddy)
  • Download the certs from the vendor once you have been validated
  • Open up the “pending” cert again in the Server app and drag the newly-downloaded cert files from the vendor into the box that’s displayed.
  • There should now be two certs in the Server app list — the current one and the new one.  Update the cert configuration to point at the newly-renewed cert.
  • Test with the new cert and once all is working and verified, delete the expiring one

Using Ableton Live to drive Logic Pro X

This is another scratchpad post to remind myself how I set up two of my favorite digital audio workstations (Ableton Live and Apple Logic Pro X) to run at the same time.  I like facets of each of these systems and want to have the best of both worlds — the live-performance flexibility of Live and the instruments and signal processing of Logic.  In some perfect future, Logic will run as a Rewire slave and a fella won’t have to do all this goofy stuff.  Until then, this is a set of notes on how I do it.  Your mileage may vary.  I’ll will try to respond to your questions as best I can (click HERE to contact me) — but I’ll be sluggish, don’t count on a reply in anything less than 24 hours.

Overview

The goal is to use MIDI coming from Live to control instruments in Logic, and get that audio back into Live.  This is where you’re headed and this diagram may be all you need.

Update – March, 2017

This revised version of the post…

Changes the audio transport mechanism from Soundflower to Loopback (by Rogue Amoeba Software).

Soundflower is no longer being actively supported and I haven’t been able to get it working properly since OSX 10.9.  Loopback is great stuff and I heartily recommend it — but it isn’t free.

Revises the Logic and Live templates to reflect this change in audio processing.

Advises against using this approach if your Live workflow includes controllers such as Ableton Push or NI’s Komplete Kontrol.

Remember, all this post does is describe how to convert Logic into a software instrument that’s available to Live (as if Logic were a Rewire slave to Live).  There is a strong presumption that Live is the “Master” and Logic is the “Slave.”

Logic breaks controllers like Push and Komplete Kontrol because it grabs them away from Live as it starts up.  Komplete Kontrol works fine under Logic, but it’s completely disabled in Live (except for MIDI).  Push shuts down entirely as soon as Logic is running.  Rats.

If you rely on controllers that don’t use MIDI to communicate with the DAW (like Push) my suggestion is to use this dual-DAW configuration in a separate (controller-free) session, capture the Logic sound in Live audio tracks, dump out of Logic and complete your work in Live-only sessions with your controllers back in the workflow.

Resources

16-channel project templates for Live and Logic

Here are links to two project files which you are welcome to try out as a template.  They’re set up to do 14 channels of audio and MIDI.  Why not 16, you ask?  Because this template includes a B3 organ instrument in Logic, which consumes 3 MIDI channels all by itself.  The configuration steps to set up the environment are still required, but you should then be able to load these up as a starting point.

Zip archive of the (revised) Logic and Live templates

Excellent video introduction to the Loopback software

I highly recommend you watch this video which, at about minute 3, walks you through setting up a two-channel audio connection between Logic and Live that is exactly the same as what this tutorial shows.

https://www.youtube.com/watch?v=mwQSXlYGZfA

Quick Checklist

After a few times through, this checklist may serve as a useful shorthand reminder of the steps that are required.  It’s basically a table of contents of the rest of the post.

Disconnect all external MIDI devices

Install Loopback

Set up the IAC bus

Click the “Device is online” button

Optional: rename the port

Open Live first.

Configure Preferences in Live

Configure Audio Preferences in Live to recognize Loopback as its audio input

Configure MIDI Preferences in Live to recognize the IAC Driver

Open a new or existing project in Live

Drag External Instruments into empty MIDI tracks

Configure the External Instrument MIDI output(s) to send it to Logic via the IAC driver

Configure the External Instrument’s Audio input to receive audio back from Logic

Open Logic

Configure global preferences in Logic

Un-tick “Control surface follows track selection” in Logic Pro > Control Surface > Preferences

Set the global Audio Output device to Loopback

Open a new or existing Logic project

Set project-level configuration preferences (only required for multitrack work)

Select “Auto demix by channel” if multitrack recording

Configure the project to only listen to MIDI from the IAC MIDI input (this is an essential step — skipping this will result in all sorts of weird errors as MIDI flows directly from sources rather than through Live)

Open the Environment window

Select the “Click and ports” layer

Delete the connection between the “sum” and “input notes” objects

Create a connection between the inbound IAC MIDI port and the “input notes” object

Create or select Software Instrument track(s)

Assign MIDI channels to correspond with the MIDI-To settings in Live

Record-arm the track(s)

Switch back to Live

Test the configuration

Reestablish external MIDI controllers in Live

Oddities:

Assign B3 Organ instruments FIRST, and only to MIDI channels 1,2 and 3

Drummer tracks don’t respond to external MIDI

Debugging:

Controller (e.g. Ableton Push or Komplete Kontrol) stops working in Live. 

IAC Driver can’t be selected as a “MIDI to” destination in Live (it’s greyed out)

All channels sound in Logic if any channel is record-armed in Live

Two channels sound in Logic, the external-keyboard channel and the record-armed one

Instruments sound in Logic even if no Live tracks are record-armed

Instruments stop responding to MIDI as new channel strips are added in Logic

Step by Step:

Disconnect all external MIDI devices

First get your template working without the complications of stray MIDI coming from your devices (use the computer-keyboard to generate notes in Live), then add external sources of MIDI back in one at a time and debug any conflicts.

Install Loopback

Download Loopback HERE.

Configure Loopback

Loopback provides several ways to get this job done.  I’ve chosen to set it up as a simple “loopback” device (no audio source) with 32 channels (16 stereo pairs, added manually) and a label to help me identify it when setting preferences in the DAWs.  Here’s how it looks in Loopback:

And here’s how it looks in Audio MIDI Setup:

Set up the IAC bus (used to pass MIDI signals from Live to Logic).

It’s in the MIDI window of Audio MIDI Setup.   If this the first time the IAC bus has been used the IAC icon will likely be greyed out.

IAC-default

Tick the “Device is online” box to bring it online

Optional: rename the port (by clicking on the name and waiting for it to turn into an edit box).

It will have 16 midi in/out ports even though the “Connectors” boxes are greyed out.  Here’s the way the IAC Driver Properties dialog will look when it has been put online and the port has been renamed (note, this is the name that are being used in the template files, either rename the port or revise the audio routing in Live and Logic to match).

IAC-2

 

Open Live first.

Opening Logic first may cause Logic to launch as a Rewire host and Live will then automatically open as a Rewire Slave – the whole goal of this exercise is to have Live act as the master not Logic.

Configure Preferences in Live

Configure Audio Preferences in Live to recognize Soundflower as its audio input.  This tutorial uses the 32-channel Loopback device configured above.  Use a 2-channel Loopback device for single-instrument configuration, “multi voice” versions need the 32-channel option if mixing is going to be done in Live.  2-channel Loopback will work if multi-channel audio is going to be mixed in Logic before it is brought into Live.  Use smaller buffer sizes if latency becomes an issue for live performance.  Note that sample sizes and sample rates are set in Loopback, Live and Logic.

Note for multi-channel configurations:  To make some or all of the channels of the Loopback device visible to External Instruments, toggle them in Preferences > Audio > Input Config


Configure MIDI Preferences in Live to recognize the IAC Driveronly enable the IAC drive for MIDI Output to Logic.  Getting MIDI Input data from Logic causes the risk of MIDI loops — so leave that option turned off.

Live-pref-midi

Open a new or existing project in Live.

Feel free to download the Live template I’ve posted in the “Resources” section near the beginning of this post.

Drag External Instruments into empty MIDI tracks

Configure the External Instrument MIDI output(s) to send it to Logic via one of the MIDI channels of the IAC driver (Channel 1 in the picture below).  In multichannel configurations this is the Live end of the MIDI mapping to Logic – these channel assignments are mapping the MIDI from Live into the corresponding channel in Logic.

Configure the External Instrument’s Audio input to receive audio back from Logic.  Since Soundflower has selected as the global audio-input source for Live in Preferences, the channel selections will all refer to Soundflower.  The single-number options refer to single channels, the options with two vertical bars refer to stereo pairs.  The stereo pairs are the likely choice in most situations.

Live-instrument-config

Open Logic.

Ignore the warning that another Rewire host is running – this is the correct  behavior, we don’t want Logic to be the host.

Configure global preferences in Logic

Un-tick “Control surface follows track selection” in Logic Pro > Control Surface > Preferences.

Logic-Control-Surface-Preferences

Set the global Audio Output device to the Loopback device .  The 32 channel version is used in this setup.

Open a new or existing Logic project.

Feel free to download the Logic template I’ve posted in the “Resources” section near the beginning of this post.

Set project-level configuration preferences

The steps in this section are to overcome the somewhat wonky multi-channel MIDI routing in Logic and are not required for driving a single channel in Logic from Live

Select “Auto demix by channel if multitrack recording” in File > Project Settings > Recording

Logic-File-Project-Settings-Recording

Configure the project to only listen to MIDI from the IAC MIDI input.  Projects default to listening to all instruments.  This causes endless trouble with MIDI loops.  These steps force Logic to only listen to the MIDI being sent from Live.  Here are the steps:

Open the Environment window – Window > Environment
Select the “Click and ports” layer
Delete the connection between the “sum” and “input notes” objects
Make a connection only between the inbound IAC MIDI port (which is where the MIDI events from Live will be coming from) and the “input notes” object.

Click on this photo to get a full-sized version — it’s hard to see, but the second little triangle, coming from IAC Live -> Logic, is the only one that’s connected to the “Input Notes” object

Logic-Environment-IAC-MIDI

Set up the tracks in Logic

Create or select Software Instrument track(s). 

Assign MIDI channels to correspond with the MIDI To settings in Live

Record-arm the track (or tracks)

Click on this photo to get a full-sized version — note that all channels are armed for recording, and each has a different MIDI channel assigned as seen with the light number in brackets immediately to the right of each track name.

Logic-Project-Window

Use the Mixer window to assign audio channels to tracks in Logic.  This is only required for multi-channel configurations. Click this picture to expand it to full size and take a hard look at the “Output” row, that’s where the assignments are made.

Logic-Mixer-Window

Switch back to Live

Test the configuration.  Logic should now respond to MIDI events from Live.  Enable the Computer MIDI Keyboard function in Live, record-arm a track or two in Live and type a few A’s, S’s and D’s on the computer keyboard.  Notes should sound in Logic on the tracks corresponding to the ones that have been record-armed in Live.

Reestablish external MIDI controllers in Live.   Bring each external controller back into the Live configuration one at a time and iron out any wrinkles that may appear.  In general problems will be caused either if MIDI events leak into Logic directly rather than being forced to pass through Live first or because Logic “took over” a controller (e.g. Push or Komplete Kontrol).  Debugging all possible problems with external controllers is beyond the scope of this post.  But likely fixes will be in Logic’s MIDI Environment.

Oddities:

Assign B3 Organ instruments FIRST, and only to MIDI channels 1,2 and 3 – B3 type instruments (e. Vintage B3 Organ or the Legacy series of B3 organs) require more than one MIDI channel – and those channel-assignments default to MIDI channels 1,2 and 3.  Adding one of these instruments “on top” of already-assigned instruments causes unusual breakage, thus it’s a good idea to avoid these channels for anything except B3 instruments.

Drummer tracks don’t respond to external MIDI – either export the track to an audio file for use in Live, or follow these steps to create a Software Instrument track that mimics the Drummer track but that will respond to MIDI

Select/create a Software Instrument track

Copy the channel strip settings from the Drummer track (right-click on the name of the channel strip, select “Copy Channel Strip Setting”

Paste the channel strip settings into the Software Instrument Track

Adjust MIDI and audio settings in the new channel strip

Bonus – copy/paste regions from the Drummer track into the new Software Instrument track to get MIDI renditions of the region – which can then be exported into Live and used to trigger the drummer

Here’s a drawback to staying MIDI rather than exporting to audio – the “automatic hi-hat” components of the Drummer don’t come across, because they’re not imbedded in MIDI.  Best turn that feature off in the Drummer settings off if MIDI is the format you’re using.

Debugging:

Controller (e.g. Ableton Push or Komplete Kontrol) stops working in Live.  This is true.  Logic is grabs those controllers away from Live when it starts.  I have no fix, only a workaround.  Use this dual-DAW configuration sparingly, then shut down Logic and complete your production in Live by itself.

IAC Driver can’t be selected as a “MIDI to” destination in Live (it’s greyed out)

  • use the Audio Midi Setup app to confirm that the IAC Driver “device is online” box is ticked
  • confirm that the IAC output MIDI ports are enabled in Live -> Preferences -> MIDI

Two channels sound in Logic, the external-keyboard channel and the record-armed one – check the project’s Environment window to make sure that Logic is only receiving MIDI from the IAC driver.

Instruments sound in Logic even if no Live tracks are record-armed – check the project’s Environment window to make sure that Logic is only receiving MIDI from the IAC driver

Instruments stop responding to MIDI as new channel strips are added in Logic – check to make sure that the “disappearing” instruments aren’t assigned to MIDI channels 1, 2 or 3 if there’s a B3 organ instrument in the mix (which uses all three of those channels).  One reminder is to delete or mute the MIDI 2 and 3 channel strips in Live if a B3 organ part of the mix in Logic.

New gTLD preparedness project

Another scratchpad post — this time about what a “get ready for new gTLDs” project might look like.  I’ll try to write these thoughts in a way that scales from your own organization up to world-wide.

I’m doing this with an eye towards pushing this towards ICANN and new-gTLD applicants and saying “y’know, you really should be leading the charge on this.  This is your ‘product’ after all.”  Maybe we could channel a few of those “Digital Engagement” dollars into doing something useful?  You know, actually engage people?  Over a real issue?  Just sayin’

Here we go…

Why we need to do this

gtld-get-ready1

 

 

  • Impacts of the arrival of some new gTLDs could be very severe for some network operators and their customers
  • There may not be a lot of time to react
  • Progress on risk-assessment and mitigation-planning is poor (at least as I write this)
  • Fixes may not be identified before delegation
  • Thus, getting ready in advance is the prudent thing to do
  • We benefit from these preparations even if it turns out we don’t need them for the new gTLD rollout

The maddening thing is, we may not know what’s really going to happen until it’s too late to prepare — so we may have to make guesses.

New gTLD impacts could be very broad and severe, especially for operators of private networks that were planned and implemented long before new gTLDs were conceived of.  ISPs and connectivity providers may be similarly surprised.  Click HERE to read a blog post that I wrote about this — but here are some examples:

  • Microsoft Active Directory installations may need to be renamed and rebuilt
  • Internal certificates may need to be replaced
  • Long-stable application software may need to be revised
  • New attack vectors may arise
  • And so forth…

The key point here is that in the current state of play, these risks are unknown.  Studies that would help understand this better are being lobbied for, but haven’t been approved or launched as I write this.

A “get ready” effort seems like a good idea

Given that we don’t know what is going to happen, and that some of us may be in a high-risk zone, it seems prudent to start helping people and organizations get ready.

  • If there are going to be failures, preparedness would be an effective way to respond
  • The issues associated with being caught by surprise and being under-prepared could be overwhelming
  • “Hope for the best, prepare for the worst” is a strategy we often use to guide family decisions — that rule might be a good one for this situation as well
  • Inaction, in the face of the evidence that is starting to pile up, could be considered irresponsible.

Looking on the bright side, it seems to me that there are wide-ranging benefits to be had from this kind of effort even if mitigation is never needed.

  • We could improve the security, stability and resiliency of the DNS for all, by making users and providers of those services more nimble and disaster resistant
  • If we “over prepare” as individuals and organizations, we could be in a great position to help others if they encounter problems
  • Exercise is good for us.  And gives all factions a positive focal point for our attention.  I’ll meet you on that common ground.

Here’s a way to define success

I’m not sure this part is right, but I like having a target to shoot at when I’m planning something, and this seems like a good start.

Objectives:

  • Minimize the impact of new-gTLD induced failures on the DNS, private and public networks, applications, and Internet users.
  • Make technical-community resources robust enough to respond in the event of a new-gTLD induced disruption
  • Maximize the speed, flexibility and effectiveness of that response.

Who does what

This picture is trying to say “everybody can help.”  I got tired of adding circles and connecting-lines, so don’t be miffed if you can’t find yourself on this picture.  I am trying to make the point that it seems to me that ICANN and the contracted parties have a different role to play than those of us who are on the edge, especially since they’re the ones benefiting financially from this new-gTLD deal.

Note my subtle use of color to drive that home.  Also note that there’s a pretty lively conversation about who should bear the risks.

gtld-get-ready2

Approach

How do we get from here to there?  If I were in complete command of the galaxy, here’s a high level view of how I’d break up the work.

gtld-get-ready3

As I refine this Gantt chart, it becomes clear to me that a) this is something that can be done, but b) it’s going to take some planning, some resources and (yes, dearly beloved) some time.  Hey!  I’m just the messenger.

We should get started

So here you are at the end of this picture book and mad fantasy.  Given all this, here’s what I’d do if this puzzler were left up to me.

gtld-get-ready4

And here are the things I’d start doing right away:

  • Agree that this effort needs attention, support and funding
  • Get started on the organizing
  • Establish a focal point and resource pool
  • Broaden the base of participation
  • Start tracking what areas are ready, and where there are likely to be problems

There you go.  If you would like this in slide-deck form to carry around and pitch to folks, click HERE for an editable Powerpoint version of this story.  Carry on.

__________________

Disclaimer:  While the ICANN community scrambles to push this big pile of risk around, everybody should be careful to say where they’re coming from.  I’m a member of the ISPCP constituency at ICANN, and represent a regional IXP (MICE) there.  I don’t think this issue generates a lot of risk for MICE because we don’t provide recursive resolver services and thus won’t be receiving the name-collision notifications being proposed by ICANN staff.  I bet some of our member ISPs do have a role to play, and will be lending a hand.

I am also a first-generation registrant of a gaggle of really-generic domain names.  New gTLDs may impact the value of those names but experts are about evenly divided on which way that impact will go.  I’m retired, and can’t conceive of how I’ll be making money from any activity in this arena.