Phil Mills

I now have six songs that include all the new audio tracks I intend for them to have. That leaves eight more to beat into that condition. The process should consume spare time for four or five days...I take long breaks. After that, fine-tuning and enough of a mastering pass for Bandcamp.

My frequent problem, and source of slowdown, can be phrased as, "That sounds really nice and it would be a shame for it not to be heard, but I can't convince myself it fits into this song as I currently envision it." I'm completely open to the idea of my songs being reinterpreted in varying styles, even doing it myself, but one style per recording seems like a good goal.

There are a lot of incoming tracks (20?) that I should have in hand a little over a week from now. They are for extra instruments and backing/harmony vocals. After that, it's a process of seeing which fit with what I have now, and what I think the songs should sound like when released...then doing actual mixes. The mixing will have a few iterations that include listening on different systems and fine tuning.

Having it available by FKO will be easy, barring any substantial drama. Completion before February would be good, because FAWM will otherwise overwrite my album focus. Finishing by late December is perhaps possible and also funny, as in, "Here's my holiday album, which contains absolutely NO holiday-themed songs".

There are days when I feel as if I've done very little except uncover more of my musical ignorance. And the strange part of that is, I mostly enjoy it...more stuff to learn!

The current episode in this series was initiated by a suggestion that one song for CD3 could benefit from the addition of horns. Since I have some nice horn samples among my digital toys, I looked into it and discovered that I didn't know: pitch ranges for various instruments, articulation options, or genre differences for tone and phrasing.

This is only one example; something similar happens with each new subject I touch on: arranging, production, sound design, mixing in general, specifics of individual mixing tools....

Luckily, YouTube is my friend, even if time isn't.

It has been more than twelve years and I don't really know why I'm writing something here again.

Possibly it's because posts here include a subject line. That suggests they should have a topic.

Facebook is the land of sharing, but not in a particularly good way; anything I see, I see 20 times and it often feels like original thought has taken a vacation. I don't imagine leaving it, though, as long as it's the most common source of news about what friends are doing and how they're feeling.

Filkhaven/Discord is OK, but with an ephemeral vibe. I feel as if it's time for me to think again while putting down words and maybe this is the place for that.

Maybe I'll post again, only with something to say next time. Let me think about it.

There are properties associated with messages. Some of them would be nice to keep in the backup and some probably irrelevant. Here I am discovering how they are transmitted.

When I started this, I was handling background database updates by keeping control of which thread was allowed access at any one time. This worked fine for simple cases but was starting to look top-heavy. The recommended method is to have each thread maintain its own "scratchpad" of modified objects and, when there's a commit, merge the changes into any other affected threads.

It took a bit of a rewrite compared to the simple template code for Core Data that Apple provides but it looks as if it will be easy to work with from here on.

Bug score: Open 13, Fixed: 75.

Posting with selected metadata. At this point posting mostly works except for some oddities with pending messages saved from earlier sessions.

Yesterday I had a friend coming over and, while waiting for him, I put the iPad version of the program through some tests. As usual, sitting down and using the application rather than just following my planned-out steps reveals a number of bugs.

The thing that makes iPad development a little more difficult that iPhone is that the iPhone UI usually only has one thing happening at any time. For the iPad there are extra sanity checks concerning synchronized display of data.

Bug score: Open 20, Fixed 63.

New things that work are, using index controls to navigate through word lists, making toolbars disappear or not depending on the screen being displayed, improvements (more detail) for error objects being generated because of server errors, and consistent behavior concerning remembering selections when returning to parent table views.

Bug score: Open 24, Fixed 51.

Creating an interface for managing stopwords turned out to be a bit more time-consuming than I'd expected. Partly that was getting the database access right but mostly it was spent figuring out a couple of oddities within the development kit.

There is a controller class which one can use as a caching interface to the database. It tracks DB changes and updates query results accordingly. Optionally, it informs a delegate that changes have happened. However, if you give it a delegate and it detects that the changes aren't being processed, it invalidates its own cache. This causes havoc if the programmer's strategy is to defer such processing to a more appropriate time.

The other weirdness was the product of the visual interface editor. The task was to put a sub-view inside a scrolling view which, itself, was inside a primary view. The tool decided to apply positive x/y offsets to the sub-view and compensating negative offsets to the scroller. It looked great until the user tried to make anything scroll...then, confusion in the form of objects wandering aimlessly across the screen.

Bug score: Open 31, Fixed 40.