Recordings:

Not Vampires - 1 - Maybe Something -- [9:54]
Not Vampires - 2 - Light Creeps / Frozen Again -- [8:17]
Not Vampires - 3 -- [2:37]
Not Vampires - 4 -- [5:23]
Not Vampires - 5 - The Squeeze -- [6:57]
Not Vampires - 6 - Candy Bandit -- [1:26]
Not Vampires - 7 - Skronky Lydian -- [9:40]
Not Vampires - 8 - Skronky Lydian (Extra) -- [1:06]
Not Vampires - 9 - Rules do not Apply / Las Vegas -- [12:52]
Not Vampires - 10 - Just a Fraud -- [6:42]
Not Vampires - 11 - Strong Judgment (Living and Dead) -- [4:25]
Not Vampires - 12 - How Low (failed) -- [2:15]
Not Vampires - 13 - How Low / Find Me -- [3:53]
Not Vampires - 14 - Find Me -- [3:15]
Not Vampires - 15 - Find Me (reprise failure) -- [2:16]
Not Vampires - 16 - Find Me Interlude -- [0:45]
Not Vampires - 17 -- [4:39]
Not Vampires - 18 - The River -- [6:21]
Not Vampires - 19 - Trees and Mold (almost) -- [3:04]
Not Vampires - 20 - Trees and Mold -- [3:19]
Not Vampires - 21 -- [2:27]
Not Vampires - 22 - Slow -- [12:33]

Comment...

1 Comment

Comment...

Comment...

I've had nothing but contempt for Bitcoin and everything (afaik) that has spawned from that ecosystem, though apparently I've never written about it here. I have nothing but contempt for Bitcoin and everything that has spawned from that ecosystem! I'm hopeful that it's on its way out, but made sad by the fact that so many people have been scammed.

Having said that, it seems that the "Web3" movement wants to move the web past where we are now (which is where Facebook/Google/etc are almost everything), which is an admirable goal. If we can do it in a reasonable way. There's just no reason to build systems that try to be trustless or fully distributed, we already have a fantastic hierarchically distributed infrastructure for this: DNS.

In 2012, I had a thought along these lines -- and I wrote a Google Doc (irony much?) -- don't bother reading it though, it's very outdated and lacking in specifics.

To make the web more open and decentralized, what we need is a new protocol and piece of software!

WATCH - "We Are The Cloud Hosts"

• the ability to publish content to the public
• the ability to publish content to trusted people
• the ability to subscribe to content creators

• the ability to publish content to the public
  
  Typically these require a web server to server the content. WATCH envisions a system where you could run software on multiple systems (your desktop, laptop when it's connected, cloud provider, etc), and it would automatically reproduce and sychronize your content. The protocol would allow connecting to a WATCH domain index in order to connect to the WATCH servers that contain data.
  
  
• the ability to publish content to trusted people
  
  When making WATCH content requests, the requesting user could be identified by digital signature to ensure access rights.
  
  
• the ability to subscribe to content creators
  
  AKA RSS. RSS feed generation and feed display would need to be integrated into this software.

• An instance of the WATCH server running as e.g. watch-index.mydomain.com. If you have your own domain you could run it on a cloud VM, presumably email providers would be able to provide this service for your accounts if it ever caught on, etc. If a user wants data from user@mydomain.com, it would connect there, and (assuming it had permission), would receive a list of WATCH content servers for that account (which could possibly include watch-index.mydomain.com).
• A few instances of WATCH servers running wherever. If you want your web presence to be very reliable you'd put them on VMs in a few AWS zones. If you don't care much you'd leave it running on your laptop or your desktop computer or whatever.

• Part of your WATCH account state would be a feed of content
• To access WATCH feeds (yours, others, a mix of both, whatever), you'd point a browser at any of your own WATCH servers or indexes
• For purely-public web pages, there could be a lot of opt-in shortcuts to this, having the index servers redirect links to content, things like that.
• The WATCH server could provide browser-based and/or filesystem-based interfaces for posting content.

Comment...

Comment...

1 Comment

I recently got my first e-bike, and I have some thoughts:

(I've been riding in NYC for a number of years, most days, somewhere in the thousands of miles per year. Most of the time I ride a Salsa Casseroll Single with fenders, rack, panniers, 20 tooth cog for easier climbs, and most recently a Surly Open Bar handlebars and a stem riser for upright posture. Side note: a video of a recent ride. )

The last few (six?) months I've been dealing with a hamstring issue (too much running with poor biomechanics, curse you teenage self), and bicycling does seem to aggrevate it, so I decided to get an e-bike with a throttle in order to be able to rest a little while still living life and going places by bike. I got a RadRunner 2 (it seems pretty decent, reasonably priced, and you can set it up to carry passengers. I have some qualms from setting it up but I'll save those for another day).

This morning I rode from Tribeca to Union Square to pick up a few things from the green market, and back, usingthe throttle almost exclusively. I found myself going a lot faster than I normally ride, and worryingly defaulting into a "driving" mentality. It left a bad taste in my mouth.

Later in the day, I rode to my office/studio in Red Hook, via the Manhattan Bridge, and made a special effort to go at a usual (leisurely) pace. It worked, and I managed to stay in a better, more peaceful frame of mind, but it took mental effort. I will have to continue that effort.

I find I definitely prefer the peacefulness of riding regular (*cough* acoustic *cough*), but my hamstring appreciated the electric-ness. What's interesting, though, is the economics:

I recharged my battery after riding 15 miles (which would be about 90 minutes of riding at city speeds), and using a Kill-A-Watt, I measured 360Wh of power use at the mains power. I looked up electric rates, and a ballpark we're talking about $0.05 worth of electricity, and the battery probably had less than 0.05% (or $0.25) of its lifetime wear. If I had ridden my regular bike, I would've burned a few hundred calories at least, and unless I was extremely frugal in my eating (I am not), there's no way I would spend only $0.30 on replenishing those calories. So in some ways, this is more economical (and probably more efficient, too?). Obviously there are benefits to exercise but let's assume I have that taken care of anyway.

Delivery people all moved to e-bikes ages ago. There were stories in the news about how they needed them in order to keep up, but I never really realized that the economics of it, even if you are as fit as possible, made generally cheaper to use electricity than to eat the extra food!

It's very good that e-bikes have been made legal in NY, hopefully the parks will follow (it feels like there should be an ADA claim against the parks that ban them, as there are people who can ride e-bikes but can't ride acoustic bikes). I'm still stunned by the efficiency of this bike, even with its massive 3" wide tires and weighing in around 65lbs.

(Update March 19: I was curious how much electricity electric cars use by comparison… sounds like typical is 34kWh per 100 miles, or 340Wh per mile… assuming that holds up in the city, that’d make the electric bike use about 1/15th the power. which is roughly in line with the mass ratio...)

Recordings:

nothing that will be missed

Comment...

1 Comment

Comment...

Comment...

Paul Davis (fellow human being and author of the Ardour DAW) suggested on Twitter that we should have a conversation which would be recorded and available for download/stream via the internet on-demand (apparently this is a thing now?).

It seemed like a reasonable (or dare I say interesting, given our common experiences) suggestion, and generally my willingness to talk to people has a sort of vaguely gaussian curve where the X axis they want to talk to me and the Y axis is how willing I am to talk to them: if they don't want to talk to me at all, or if they REALLY want to talk to me, then I'm pretty much not interested, but if they're in the middle, then sure why not?

We had our interview (which was enjoyable, and it even would have been without a pasty on my desk staring me down for when it was over) using NINJAM in voice chat mode, which mostly works amazingly well, until it doesn't (and then you have to reinitialize the channels -- I've been meaning to fix that for years but meh). I haven't (nor will I likely) listened to it in its entirety, but hopefully I didn't make too much of a fool of myself (thank you Paul for editing it). Paul also is being very modest about his interviewing skills, I thought he did an excellent job (for an emacs user), but we're always our biggest critics (except those instances where you get asshole critics, but to be fair they are usually just assholes and not so much critics).

Anyway, here's the interview.

One final note, after our conversation I do find myself wondering how good of musicians we would both be by now, had we not chosen to write DAWs and instead had spent the last 36 collective years with our time devoted to playing rather than programming. It's a completely unknowable and unrealistic question, anyway: whether or not you consider programming an art, it shares with art the most difficult part which is maintaining an interest in a particular thing for extended periods of time. Would I be an amazing guitarist if I'd spent the last 15 years playing guitar for 8 hours a day? Probably. Could I possibly spend 15 years playing guitar for 8 hours a day? No chance in hell.

4 Comments

Here are my notes:

• Code: git commits from 2020's REAPER v6.19+dev1231 to v6.43+dev1231 for which I am the claimed author (excluding merges): 2,264
• Code: cumulative changes (I'm not sure how to limit this to just my commits so it's global, including third-party SDKs and schwa): 1711 files changed, 132415 insertions(+), 121934 deletions(-)
  
  
• Running (from Strava): 1,366 miles, 44,850ft of climbing, 219 hours. Mileage about the same as 2019, though far less climbing (2019 was 66kft) and a half dozen fewer hours. I've had something or other bothering me nonstop all year but only rarely keeping me from running (at the moment my left glute/hamstring is a bit tight). My high water year for miles was 2017, which was 1,444 (with similar elevation of 44kft, covered in 216 hours). Ah youth.
  
  
• Bicycling: 3,148 miles, 92,560ft of climbing, 346 hours (I'm sure I forgot to record some rides but then there's also probably some GPS errors giving me bonus miles).
  
  These were mostly as transportation or leisure rides, I only rode the road bike 67 of those miles (sorry, buddy. I'll take you out soon). The brompton got about 200 miles (mostly in San Francisco), and the cargo bike even got 100 miles.
  
  The Casseroll single speed is my favorite (thanks, Alex!). This year I replaced its handlebars (Surly Open Bar + stem extender, and a cupholder), seat, front tire, bottom bracket, freewheel (after the old one failed in February, though it was fixed gear 3:1 for a good 6 months before going back to 12:5 freewheel), and twice (March and December) its chain. The brompton also got a new chain.
  
  
• Music played with others: 62 sessions, producing about 87 hours of (very-loosely) edited music. The pandemic made this difficult. Singing with a mask on has its own challenges.
• Music recorded alone: I did about 20 super8 sessions, producing about 9.5 hours of music/youtube videos. Also I recorded 37 doodles, about 2 hours of music.
  
  
• It is probably for the best that I don't have many consumption numbers, such as paper products, disposable masks worn, etc.

It's now time when I bitch about, and document my experiences dealing with Apple's documentation/APIs/etc. For some reason I never feel the need to do this on other platforms, maybe it's that they tend to have better documentation or less fuss to deal with, I'm not sure why, but anyway if you search for "macOS" on this blog you'll find previous installments. Anyway, let's begin.

A bit over a year ago Apple started making computers with their own CPUs, the M1. These have 8 or more cores, but have a mix of slower and faster cores, the slower cores having lower power consumption (whether or not they are more efficient per unit of work done is unclear, it wouldn't surprise me if their efficiency was similar under full load, but anyway now I'm just guessing).

The implications for realtime audio of these asymmetric cores is pretty complex and can produce all sorts of weird behavior. The biggest issue seems to be when your code ends up running on the efficiency cores even though you need the results ASAP, causing underruns. Counterintuitively, it seems that under very light load, things work well, and under very heavy load, things work well, but for medium loads, there is failure. Also counterintuitively, the newer M1 Pro and M1 Max CPUs, with more performance cores (6-8) and fewer efficiency cores (2), seem to have a larger "medium load" range where things don't work well.

The short summary:

• Ignore the thread QoS APIs, for realtime audio they're apparently not applicable (and do not address these issues). This was the biggest timesink for me -- I spend a ton of time going "why doesn't this QoS setting do anything?" Also Xcode has a CPU meter and for each thread it says "QoS unavailable"... so confusing.
  
  
• If a normal thread yields via usleep() or pthread_cond_timedwait() for more than a few hundred microseconds, it'll likely end up running on an efficiency core when it resumes (and it takes an eternity in terms of audio blocks to get bumped back to a performance core, by which there's been an underrun and the thread probably will go back to sleep anyway). Reducing all sleeps/waits to at most a few hundred microseconds is a way to avoid that fate (though Apple recommends against spinning, likely for good reason). It's not ideal, but you can effectively pin normal threads to performance cores using this method.
  
  
• Porting Your Audio Code to Apple Silicon was the most helpful guide (I wish I had seen the link at the bottom of one of the other less-helpful guides sooner! so much time wasted...), though it assumes some knowledge which doesn't seem to be linked in the document:
  
  You want to get your realtime threads in the same thread workgroup as the CoreAudio device's (via kAudioDevicePropertyIOThreadOSWorkgroup), and to do that you first have to make your threads realtime threads using thread_policy_set(THREAD_TIME_CONSTRAINT_POLICY) (side note: we probably should have been doing this already, doh), ideally with the similar parameters that the coreaudio thread uses, which seems to be a period and constraint of ((1000000000.0 * blocksize * mach_timebase_info().denom) / (mach_timebase_info().numer * srate), and a computation of half that. If you don't set this policy, it will fail adding your thread to the workgroup (EINVAL in that case means "thread is not realtime" and not "workgroup is canceled" per the docs). Once you do that, you do effectively get your threads locked to performance cores, and can start breathing again.