Blogs

This week I got to learn a little more about the Planning Department.

Something I'd really love to have some day is a "how a proposal becomes a building" flowchart with approximate times for each step. My rough understanding is:

1. The developer submits a site plan with a ton of details about the proposal. For example, here's a site plan for the recent Lowertown development (not the site plan that was finally approved).
2. Planning staff reviews the plan for compliance with the zoning code and the master plan, and also sends the plan to other departments for further review. (For example, to make sure there's adequate infrastructure to handle storm water.)
3. After some back and forth, staff sends the plan to the planning commission, which may approve it, send it back to staff, or send it on to council.
4. Council may likewise approve it, send it back to planning commission, or whatever. Somewhat bizarrely, Ann Arbor requires this step for every project, even when it's clearly allowed under existing zoning, in which case the most likely result of a "no" vote may be a lawsuit.

I think there are some required delays in there for public notice. I'm a little vague on the details.

Some stuff (a lot of work in single-family neighborhoods, for example?) doesn't require this full process.

You can follow a lot of this on etrakit. E.g., click on "Search" under "Projects" and search for the address "1200 Broadway", and you'll get a lot of details on that Lowertown development. Or you can look for the meetings where the project was discussed in Legistar, for example with a search for planning commission meetings mentioning "1200 Broadway".

A friend also points out this chart, linked from the planning department's Development Review page.

Previously I tried to summarize two legal limits on the growth of property tax millages; roughly:

1. Proposition A limits the annual growth in the taxable value of your house. The increase in your taxable value is limited to inflation (plus the value of any improvements you made in that year).
2. The Headlee Amendment automatically decreases millage rates each year to limit the annual growth in the total revenue collected by the city. Total revenue collected by a given millage is limited to inflation (plus the value of any new construction completed in that year).

The Headlee Amendment especially can create interesting problems for local budgets.

At first glance it makes sense: generally it should cost about the same to deliver a given service from one year to the next. Unless your city's growing, but in that case you get new revenue from new construction.

However, there are some problems here:

1. Inflation is a tricky thing. Not all prices increase at the same rate. For example, maybe a large part of your budget is made up of something that's increasing faster than inflation (say, your employees' health care costs).
2. The Headlee Amendment automatically decreases millage rates when taxable value goes up, but it doesn't *increase* millage rates again when taxable values go back down. So in a recession, millage revenue can decrease; after recovery, it will be allowed to increase only by inflation. Another way to think of this: in inflation-adjusted dollars, millage revenue can only stay the same or (when there's a downturn) decrease; it never increases.

There are a number of ways cities might try to cope with this without cutting services:

1. They can put a measure on a ballot asking voters to approve returning the millage to its original value (a "Headlee override").
2. They may be able to find ways to be a little more efficient each year and deliver the same services for less money. (Ann Arbor, for example, cut its staff from a high of 1,005 to a low of 685 between 2001 and 2013).
3. They can take advantage of the exception for new construction.

That last option can have a big impact. New construction brings new costs too, but city services often have large economies of scale, especially if the new construction is in existing neighborhoods--if you double the number of people living on a given block, you add additional wear and tear to the roads, for example, but the maintenance cost probably doesn't *double*--so the cost per residents goes down.

Property tax isn't the city's only source of income. Your water bills, for example, also go to the city (though the city is legally required to spend that money on water service.) The state also sends some portion of sales tax collected back to the city (though this has declined over the years). More details on all this in Tom Crawford's presentation.

At this week's A2CA we got presentations from the CIty Clerk and the IT department.

A couple things I didn't know about:

If you look up the next city council meeting in Legistar, there should be an "eComment" link which you can use to submit comments. I'm afraid I usually complain to my friends or (occasionally) email my ward 2 council people. Maybe this would be better? It doesn't seem to be used much.

I didn't realize the city had its own fiber. I guess it used to depend on Comcast, but decided at some point that it was more cost effective to just build its own network. The city isn't allowed to go into the ISP business (somebody asked), but it does share its network with the DDA and the AADL.

Mainly though what impressed me was the amount of stuff that the city has online. Some I already knew about, some are worth posts of their own; a few examples:

• A2OpenBook: click on the links on the left side for spending data down to the level of individual transactions. Also downloadable if you wanted to do some analysis of your own. Though maybe you're better off checking to see if the Citizen Guide to Finance and Budget or the Annual Financial Reports answer your questions first.
• Browse the Zoning Map.
• Browse the city code.
• Legistar, for city meetings (previously).
• On a snow day, who couldn't get excited watching the live snow plow tracking?

This is how I understand Michigan property taxes:

Say we decide that the city should deliver each Ann Arbor resident a fresh pie every week, and we vote in a 1.5-mill property tax to fund that.

Suppose you bought a house this year. Take its market value, and divide it by two. That's called the "assessed value" of your house. (Why? I have no idea.)

Take 1.5 thousandths of that assessed value. That's your property tax.

So, for a $380,000 house (about the Ann Arbor median as of this writing), the assessed value would be $190,000 (half of $380,000), and the pie millage would cost you $285 a year ($190,000 times 1.5 divided by 1000).

That works for the first year in your house. But we should actually be using the "taxable value". The taxable value starts out the same as the assessed value (half the market value), but it is only allowed to increase by inflation (CPI) or 5%, whichever is less. If you modify the house (say, you make an addition), the value of the addition is also added to the taxable value (explanation from Ann Arbor Asessing office).

Ann Arbor market values have gone up faster than inflation over the years, so if you pick a property someone's been living in a while and look it up in the online property tax database, you'll see that the taxable value is likely lower than the assessed value.

When the house is sold, the taxable value will be "uncapped", and the next owner's taxable value will reset to the assessed value.

This limit on the growth of taxable values was imposed by Proposal A in 1994.

There's also a second limit which affects the total amount of tax that can be collected from a given millage. That amount is *also* limited to the lesser of inflation or 5%.

So if the total taxable value of all Ann Arbor properties is 5.5 billion, then the 1.5 mill pie tax will collect 1.5 thousandths of that, or 8.25 million. If Ann Arbor's total taxable value increases by more than inflation, then the millage rate is automatically decreased to ensure the total collected is no more than 8.25 million plus inflation. So the 1.5 mill pie tax may eventually become a 1.4 mill pie tax, etc.

This limit was put into place by the Headlee Amendment in 1978. The automatic decrease in millage rate is called a "Headlee rollback".

There's an important exception to this limit: it doesn't apply to new construction. Just as proposition A allows a new addition to your house to increase its taxable value, the Headlee Amendment allows the city to add revenue from any new construction. This makes sense--new construction is going to require new pie deliveries, after all.

All of this has some rather interesting affects on municipal finances--a subject for another post....

Your friends are posting about some local outrage. You're not sure who to trust for the basic facts. I mean, ideally there'd be a newspaper article, but, oh well, they can't necessarily keep up these days.

Fortunately, you know that said outrage is to be discussed at the next city council meeting. And, fortunately, the city has a ton of information online, and you're the internet-researching type. This, fellow civics geek, is the URL you want:

https://a2gov.legistar.com/

This has records not just for city council, but for every meeting of every City committee you've never heard of. You want to see the minutes for the Dec. 18 2012 meeting of the Parks Advisory Commission? You got it.

You can search by date or by committee, and there's a full text search, though I haven't figured out how deep exactly that goes.

The most interesting part is often under the "Meeting Details" link, which will take you to a page with every agenda item broken out, and clicking on *those* gets you staff reports, public commentary, and more.

The tricky part is often finding the right agenda item, as especially for something like city council there can be a lot, some of them pretty similar-sounding. But, you're the internet-researching type, so follow your nose and you'll find what you're looking for, or at a minimum an idea who you'd need to contact to get the details.

For the next couple month's I'm spending my Wednesday nights with my fellow civic nerds at the Ann Arbor Citizens Academy. While I'm at it, I figure I should do some homework of my own; here's some:

One of the most basic questions is: what is the City of Ann Arbor anyway? For me it also helps to work out everything that *isn't* part of the City.

Local government is mostly funded by property taxes--so that's one great place to start. Look up a random address in this Ann Arbor property tax database, then check out the "tax information tab", and look at the most recent summer and winter taxes (they'll have different stuff on them). You'll see something like:

This example is from an owner-occupied home in Ann Arbor. The "millage rate" column adds up to about 67 mills, but note that there's a 9-mill "AAPS OPERATING" millage collected twice a year which such properties don't pay. So they're paying about 49 mills all together (about 49 thousandths of one-half the value of the house; more on that calculation another day!). Of that, about half is for education, mainly AAPS. AAPS is *not* part of the city--it has its own board and its own district boundaries, which extend outside Ann Arbor itself. School taxes are a whole complicated story themselves.

Then there's about 7 mills to Washtenaw County--"WASH COUNTY PARK", "EECS", "VET RELIEF", "ROADS" (which pays just for county roads), "MH&PS COUNTY", and "WASH COUNTY OPER".

HCMA is it's own thing.

So is the library--AADL is independent of the City and of AAPS (though it has the same geographical boundaries as AAPS).

That leaves about 16 mills--about a third--to the city, all on the summer bill. Those include separate millages for trash collection, streets, park maintenance, park acquisition (I believe that's the greenbelt millage), and the bus system--the AAATA is also part of the city.

Now this is just for one type of property. Also, Tax Increment Financing arrangements capture some property tax income but don't show up on tax bills at all as far as I can tell. So it would be more useful to know how the total property tax collected from Ann Arbor properties is distributed--for that, see this chart from the city's website. There you see that the city's portion of the total tax collected is about a quarter. And there are also a few other items there, including the DDA and Spark, which are also part of the City.

Also, of course, property taxes aren't the whole story--the water system, for example, is also the City's responsibility, but it's funded by fees. And not everything the city does is funded revenue earmarked for that purpose.

I'm still trying to figure all this out--more another day!

There's much more about the city's structure in Howard Lazarus's A2CA presentation, and more on city finances in Tom Crawford's A2CA presentation. See also links to all Ann Arbor Citizen's Academy Presentations.

I repeated the previous experiment but using a midi controller instead of the touch screen. So, I hooked up a CME XKEY 25 to each android device (with the help of a USB OTG adapter) and put the mic close to the controller to pick up the sound of my finger hitting a key, then loaded the resulting recording in audacity and measured the time between the key press and the sound.

That gives better latency; compared with previous results:

That was again with "music synthesizer", one of the Android Apps that feels low latency. It would be interesting to measure the difference when using one of the apps that feels more laggy.

It'd also be interesting to compare to a hardware synthesizer, but the only one I have at home has fully weighted keys and probably doesn't sound till the key is somewhere in the middle of the stroke, so it's hard to know what exactly to measure.

I have two Android devices at home, a Nexus 9 tablet and a Nexus 6 phone, and have some synth apps installed on both. I was curious what the total delay is between the time I tap a key on the screen and the time the device produces a sound.

So, I used a 3.5mm-to-1/4" cable to plug the Nexus 9 into the first input of my Zoom H4n recorder, and plugged a mic into the other input. I started up the app "Music Synthesizer" and set it to a piano sound. Subjectively, that app and "Grand Piano Pro" are the only apps I've found with acceptable latencies. On others the latency has either been too high or two unpredictable for me to be able to tap out simple rhythms reliably.

I put the mic right next to the screen, started a recording, and tapped a key on the screen.

I loaded the resulting recording into audacity and looked for the onset of the two noises--the sound of my finger hitting the screen, recorded by the mic, was in the first (left) channel, and the piano sound was in the second (right) channel. I could measure the difference between them--about 45 milliseconds.

I repeated that with the Nexus 6 and got about 50 milliseconds.

(Just to make sure the comparisons even made sense, I also tried just tapping the bare 3.5mm plug against the mic and looking at the result in Audacity, and the offset between the two signals was a tiny fraction of a millisecond, as I'd hope,)

I don't really know if those numbers are good or not. You can certainly hear that the finger-tap and the piano note aren't quite simultaneous. I guess the real test would be to try using them to play some real music. But there's plenty of other reasons why playing on a touch screen isn't very satisfying.

It might also be interesting to do the same experiment with a midi controller plugged into one of the Android devices. And might be interesting to compare to a hardware synth.

Linux is often like the disorganized toolbox in you find in somebody's garage. There's lots of useful tools in there somewhere, but first you're going to have dig around, untangle everything, and do a lot of google searches to figure out what it all is and how to use it.

The Linux situation for musicians is no exception.

Lately I've been attempting some simple multitrack recording. I have a portable recorder (Zoom H4n) that works as a 4-track recorder, but the interface (tiny screen, a few buttons and a selection wheel) is a little cramped. And even my simple projects run out of tracks quickly.

So, laptops are supposed to be able to do this, right?

To record, I've got to get audio into the laptop somehow. My options are:

1. laptop audio jack: unlike my old laptops which had multiple audio jacks, this has one which doubles as input and output; it takes a headset with a TRRS jack like you'd use for mobile phones. The output is stereo but the input is only mono, I'd need some sort of adapter, and I have no idea what sort of inputs it'd handle well: mic, instrument, line level?
2. The Zoom H4n: it's not just a recorder, it's also a USB audio interface, so you hoook it up to the laptop with USB, then plug mics or instruments into it.
3. My Zoom B3 bass pedal: this also functions as a USB audio interface. But all I can record with it is bass guitar. (OK, electric guitar or other instruments might work too.)

So, I can transfer some tracks I'd already recorded with the H4n to audacity, plug the B3 into my laptop, plug headphones and bass into the B3, and hit audacity's "record" button. Audacity streams the existing tracks to the B3, so I can hear them over my headphones, and what I play on bass gets sent back to the laptop and audacity puts it in a new track.

Unfortunately, when I play back the result, the timing sounds all wrong--the bass lags noticeably behind the other instruments.

What's happened is that I was playing in pretty good time with what I heard in my headphones. But what I heard had already taken a little while to get from audacity to my ears. And what I played took a little while to make its way back. So, there was a delay. I shifted the track around a little, and with some trial and error got to make it sound OK. But, that's going to be a pain to do every time, so, what to do instead?

Googling around found me a page explaining how to measure and correct for latency with audacity.

I figured I'd first just test the laptop (leaving the B3 aside for now). I plugged my usual phone earbuds into the laptop's audio jack to create a loop, putting the earbuds right next to the mic and turning up volume pretty high. I made a click track in audacity, and hit record. Then I could zoom in on the two tracks and see that the original click track was offset by about 149ms from the recorded track that had been played over the earbuds and come back through their mic. Repeated tests showed anywhere between 145 and 154ms for that round-trip latency.

The page linked above explains how to tell audacity to automatically shift recorded tracks to compensate for a known latency, and it looked like a shift of 150ms would get me within 5ms of where it should be--and people apparently start hearing events as simultaneous when the events are within about 20ms of each other, so 5ms isn't bad. But, I was curious if I could do a little better, so I switched to jack instead--unlike the default audio system on my laptop (pulseaudio), jack is designed for predictable low latency.

This meant opening qjackctl, setting qjackctl->Setup->Device to the B3, starting jack, then starting audacity and making sure its audio device was set to jack. This time three tests got me exactly 33ms each time. Much better--jack makes a big difference!

I tried a similar test with the H4n, this time using a cable from its headphone jack to one of its inputs to create the loop. There was nasty feedback until I realized I needed to turn off the H4n's own monitoring--I didn't want it sending its input straight back through the headphone jack. Then I also needed to set qjackctl->setup->sample rate to 44100. With that done, I measured latencies ranging from 95ms to 271ms. Ugh! There's no way to automatically adjust for that. (Actually, the first three tests gave me 99ms, 97ms, and 95ms--which I could live with--but after more problems recording later I reran tests and found that quickly repeated tests often give similar latencies, but waiting and coming back can a few minutes later can give very different results, for some reason.) Googling around suggests the H4n just isn't a great USB audio interface if you care about latency.

The B3 got me much more consistent results, about 57-60ms.

But that only helps with the bass guitar, so I ordered a USB audio interface that claims good latency (Focusrite Scarlett 2i2). That's predictably getting me 48ms round trip latency.

For multitrack recording purposes, I care more about the variation in latency than the latency itself, so that's good enough for me. But, it might be interesting to see if I can get those numbers a little lower. Most of the remaining latency is probably happening in software running on my laptop, so some careful configuration there might help.

Also I should try learning Ardour, it looks potentially more useful than Audacity. And their approach to latency measurement and compensation looks more sophisticated. Another day!

I attempted to make a proper crossword puzzle for the 2013 Ann Arbor Juggling Arts Festival.

I did this once before a few years ago, mostly just trying to figure it out on my own from scratch. This time found a great book through interlibrary loan. That and a couple smartphone crossword-solver apps helped. But it still took a lot of trial and error, I still broke a couple rules, and it's still lame in spots.

Still, I like it, and if you're a juggler maybe you'll be amused by a few of the entries; print it out and give it a try:

• Unofficial 2013 Ann Arbor Juggling Arts Festival Crossword puzzle.