Yearly Archives: 2022

You’re Going to Have to Get a Lot Weirder

With the growth of artificial intelligence, you’re going to have to get a lot weirder.

AI systems like GPT-3, Stable Diffusion, DALL-E, and others are trained on gigantic collections of data. They analyze this data and find things that are in common, and use them to synthesize “new” things based on the rules and styles they’ve learned.

Essentially, AI art, writing, and music manages to plagiarize thousands of works simultaneously.

What this means, is that generally things produced by AI are more “average” and a lot closer to the middle ground. “Interesting” and “weird” will gradually be eroded and replaced with things that are more and more average over time. Nuance will be replaced by uniformity and commonality.

Your only hope is to always be weirder, more interesting, and more original than the robots.

Twitter: I Was Off By Four Years

Back in early 2018, I posted that 2018 would be the year that Twitter “ceases to be relevant”.

It turns out that I was off by four (or maybe five) years.

Twitter is certainly relevant TODAY, but much of its relevance is as a lesson in “how to destroy a company in under six months”. Whether it takes a few weeks or a year for the majority of users to leave and the site to become a mostly-forgotten memory is yet to be seen, but it’s toast.

When Elon purchased Twitter, I finally deleted my personal account. I had only been using the site to keep track of what was going on in Ukraine, and wasn’t interested in “joining the circus” after the transition.

Today I deleted links to Twitter from all of my websites. It’s just not somewhere worth participating in, and it’s not a useful place for communicating/publishing news about new things to an audience.

I don’t see it recovering, and not much of value will be lost.

Fixing OSError: cannot write mode RGBA as JPEG in Python

I have an application that was originally written in Python 2.7 and used the Python Image Libary (PIL). Now it uses Python 3.x and Pillow (the PIL replacement). One of the things it does is automatically generate .jpg file thumbnails of uploaded files.

It does this by resizing the uploaded image, and then saving it with the filename extension changed.

I started getting an error when uploading a .png file:

OSError: cannot write mode RGBA as JPEG

A bit of research told me that the behavior has changed. Now you need to discard the alpha (transparency) channel of an image before you’re allowed to save it as an image type that doesn’t have an alpha channel. Since PNG files normally have a transparency layer, it makes sense why I would hit that error. It’s trying to protect me from losing data I might potentially want to keep. However, I don’t want or need alpha channel data for my thumbnails.

The solution is just to convert the image before saving.

thumbnail = im.convert('RGB')
thumbnail.save("my_image_filename.jpg", 'JPEG', quality=92)

It’s a simple fix, but slightly annoying that the behavior has changed over the years.

Creating Album Art Videos with Wondershare Filmora

It’s been a couple years since I last created an album art video, and I normally create them for an entire album all at once. It looks like the tool I used to use is no longer available, so I decided to figure out how to use Wondershare Filmora to do it.

Screenshots are from Filmora 11, but this should be pretty much the same on older and newer versions since it’s a basic operation that’s not likely to change much.

The first step is to create a new project and import the media. In addition to the .wav (or alternatively .mp3 files, though those are lower-quality), you should also have created an album art image file that is 1920×1080 pixels, the standard dimensions of an HD video. If you want to create a 4k video, you’ll need a larger image.

The first step is to drag the image to the video track.

Next drag a song to the audio track.

Now you need change the length of the video track to match the audio track. This can be tricky because the single image is too small to grab at the default zoom level. If you click “zoom in” three or four times you should be able to grab it and drag it longer.

You’ll need to drag this to match the length of your audio track. Filmora makes this easy because it wants to “snap” the video length to the audio length.

An album art project in Wondershare Filmora.

An album art project in Wondershare Filmora.

Next select Export -> Create Video from the menu. Edit the name of the video and select a folder to export to.

Under “Preset” you’ll want to click “Settings”. I have settings I’ve saved as a preset to make things faster. The video encoding bit rate isn’t very important, but you won’t want to set that too high or you’ll have a huge video file for no reason. More important is to set the audio settings to a high bit rate so you have good quality music encoding.

Wondershare Filmora Encoding Settings for Album Art Video

Wondershare Filmora Encoding Settings for Album Art Video

After you have the settings configured, click “Export” and wait a bit for it to finish.

You don’t need to create a new project for each video, and it’s a bunch of extra work to do so.

After the first video is exported, delete the audio track from the audio timeline, drag in the next one, drag the video track slider to match the length, and then click Export -> Create Video again. Remember to change the name. It’s that simple.

Fixing Error LNK2038 In a Visual Studio Project

While building a Visual Studio C++ project in Visual Studio 2022, I received this error while linking to a library:

Error LNK2038 mismatch detected for ‘_MSC_VER’: value ‘1800’ doesn’t match value ‘1900’ in MidiPlayer.obj MIDIPlayer E:\code\MIDIPlayer\wxmsw30ud_core.lib(dlgcmn.obj)

In case you’re not familiar with this error, Visual Studio wants to link with libraries that were built with the same version of Microsoft C (same toolset) as the code you’re compiling. In older versions of Visual Studio that meant that they had been built with the same version of Visual Studio, but now that versions aren’t as tightly-coupled to Visual Studio, it’s also possible that you can get this with libraries built with the same version of Visual Studio that you’re using.

The solution is to rebuild the library with the same MSC version as your project.

For reference, here are the different MSC, MSVC, and toolset versions:

Microsoft C 6.0: _MSC_VER == 600
Microsoft C/C++ 7.0: _MSC_VER == 700
Microsoft Visual C++ 1.0: _MSC_VER == 800
Microsoft Visual C++ 2.0: _MSC_VER == 900
Microsoft Visual C++ 4.0: _MSC_VER == 1000
Microsoft Visual C++ 4.1: _MSC_VER == 1010
Microsoft Visual C++ 4.2: _MSC_VER == 1020
Microsoft Visual C++ 5.0: _MSC_VER == 1100 (Visual Studio 97)
Microsoft Visual C++ 6.0: _MSC_VER == 1200 (Visual Studio 6.0)
Microsoft Visual C++ 7.0: _MSC_VER == 1300 (Visual Studio 2002)
Microsoft Visual C++ 7.1: _MSC_VER == 1310 (Visual Studio 2003)
Microsoft Visual C++ 8.0: _MSC_VER == 1400 (Visual Studio 2005 – v80)
Microsoft Visual C++ 9.0: _MSC_VER == 1500 (Visual Studio 2008 – v90)
Microsoft Visual C++ 10.0: _MSC_VER == 1600 (Visual Studio 2010 – v100)
Microsoft Visual C++ 11.0: _MSC_VER == 1700 (Visual Studio 2012 – v110)
Microsoft Visual C++ 12.0: _MSC_VER == 1800 (Visual Studio 2013 – v120)
Microsoft Visual C++ 14.0: _MSC_VER == 1900 (Visual Studio 2015 – v140)
Microsoft Visual C++ 14.1 – 14.16: _MSC_VER == 1910 – 1916 (Visual Studio 2017 – v141)
Microsoft Visual C++ 14.2 – 14.29: _MSC_VER == 1920 – 1929 (Visual Studio 2019 – v142)
Microsoft Visual C++ 14.3: _MSC_VER == 1930 (Visual Studio 2022 – v143)

It’s interesting that starting with Visual Studio version 2017, Microsoft started incrementing the MSC version with each “micro” build change.

Telling Git To Ignore File Mode Changes

It’s possible for Git to think there have been changes to files when only permissions have changed. This is something that is pretty common if you work across multiple operating systems, and it can be annoying.

For example, running “git status” showed that two of my icon files had changed, but hadn’t edited them. Running “git diff” showed that it was just the file mode properties (permissions or “props”) that had changed.

$ git diff
diff –git a/images/samplitron_largeicon.png b/images/samplitron_largeicon.png
old mode 100644
new mode 100755
diff –git a/images/samplitron_largeicon.xcf b/images/samplitron_largeicon.xcf
old mode 100644
new mode 100755

To make Git stop treating this as a change, there’s a command you can run:

git config –global core.fileMode false

Now when you run “git status” or “git diff”, file mode changes will be ignored.

Fixing Error MSB3843 in a Visual Studio Project

I updated my DrumPads code project to the latest version of Visual Studio 2022 and received this error when trying to build:

Error MSB3843 Project “DrumPads” targets platform “Windows”, but references SDK “Visual C++ 2015-2019 Runtime for Universal Windows Platform Apps v14.0” which targets platform “UAP”. C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets

I’m not sure whether the project was actually set to be UAP, or whether the migration set something to that.

Visual Studio Solution Explorer Showing "Universal Windows"

Solution Explorer Showing “Universal Windows”

To fix the error, I edited the DrumPads.vcxproj file manually. In the PropertyGroup sections for the build configurations I changed this:

<PropertyGroup Condition=”‘$(Configuration)|$(Platform)’==’Release|Win32′” Label=”Configuration”>
<ConfigurationType>Application</ConfigurationType>
<UseDebugLibraries>false</UseDebugLibraries>
<WholeProgramOptimization>true</WholeProgramOptimization>
<CharacterSet>Unicode</CharacterSet>
<PlatformToolset>v143</PlatformToolset
<WindowsAppContainer>true</WindowsAppContainer>
</PropertyGroup>

I removed the line <WindowsAppContainer>true</WindowsAppContainer> entries from all of the configurations and reloaded the project. It no longer showed up as “Universal Windows” and I was able to build without the error.

Solution Explorer Without "Universal Windows"

Solution Explorer Without “Universal Windows”

Changing the Remote URL for a Git Repository

Maybe the repository has been moved, or maybe you have an old repository that was checked out with username and password authentication, and you can’t push to it anymore because GitHub requires ssh authentication now. That was true in my case, since I was going back to work on code I hadn’t touched for a few years.

Although you could just re-check-out the repository, that is unnecessary, and can be annoying if you have changes that you want to push.

Changing the remote URL for a git repository is a simple thing to do, but it’s not necessarily obvious. It’s done using the “git remote” command.

To display the URL of the remote repository:

git remote get-url origin

https://github.com/xangis/SigmaTizm
To change this to a new URL:
git remote set-url origin git@github.com:Xangis/Sigmatizm.git
With this one-line change I was able to continue working as normal without needing to re-check-out the repository.

New Bloodless Mushroom Release – Hydropus

I recently released some new Bloodless Mushroom music, an album titled Hydropus. It’s a collection of glitchy ambient instrumental tracks composed on various vintage synthesizers. The name comes from a genus of mushroom that grows in tropical forests.

The album art is a painting I created early in the Coronavirus lockdowns.

It’s available for listening on YouTube here:

It’s also available on Spotify and other streaming services. Enjoy. 🙂

New OJ Champagne Release – Battery Acid

I wrote a song about developing an addiction to battery acid in the pre-COVID times (2018). I performed it live a few times in Portland, Oregon. During the lockdown I recorded a version of it.

It’s available on YouTube:

It’s also available on Spotify and other streaming services.

Another Little 3D Experiment – Morning Coffee

This is another little 3d experiment.

I didn’t create any of the 3d models, which are stock content for Daz 3D. I just posed the scene.

I learned how to fix “poke through” (where you can see skin sticking out through the geometry of clothes), and learned a little more about bending joints.

 

New Dr. Kilpatient Release – Jam 453

During the COVID-19 lockdowns, Tomasz Kordowski and I had some pretty good jams in our house, The Craniorium (named for all the mannequin heads, of course).

I polished up and released a recording of my favorite one for streaming. It’s called “Jam 453” and it’s available for listening on YouTube:

It’s also on Spotify and all the other streaming services.

Of course, that’s Tomasz Kordowski on piano, and me on drums.

A Beginner Experiment With Stop-Motion Video

Here’s a very beginner experiment.

I’m learning some of the basics of stop-motion video. I created this using Wondershare, which I bought in some sort of holiday sale a couple years ago. Wondershare works pretty well for basic video editing, and if you want something that isn’t too complicated, I recommend it.

Subscribe to the channel if you want to see future things and find out whether I ever get good at it.

For the most part, it’s just taking photographs and stringing them together in a sequence, showing each for a fraction of a second, for example 1/4 second, which gives you four frames per second. More frames per second will give smoother movement. Television has historically been 24 frames per second, while a YouTube video or digital video in general is normally 30. 60 frames per second is also becoming more common.

So far, what’s most difficult is keeping the lighting consistent, and secondarily keeping the movement increments consistent. The biggest problem with the lighting on this one is that in a few frames, my own body is obscuring some of the light.

A Denunciation of Cryptocurrency

Some of my recent posts might make it seem like I am pro-cryptocurrency.

I am not.

Yes, it was a fun playground to tinker around in for a bit, but I know it for what it is – a minefield of pyramid schemes, scams, hucksters, spammers, crooks, and a few honest but gullible suckers.

Cryptocurrency likes to promote itself by pointing out the flaws of a fiat-based central monetary system. The trouble is that it solves none of them, and introduces many more of its own.

Where do I start? It’s easy to manipulate, backed by nothing — essentially vapor — and if something goes wrong, your money disintegrates, or the supply explodes, or one of thousands of possible disasters when there are no central controls on something. At least a fiat currency is backed by a government — and those tend to have force to back up their claims.

It is also incredibly inefficient. Sure, forging metal into coins or paper/plastic into banknotes consumes energy and resources, but the majority of circulating currency is digital (via credit/debit cards) and no physical money changes hands. Meanwhile, with most (not all) cryptocurrencies, every transaction consumes energy. Yes, credit card terminals consume energy, but orders of magnitude less than Bitcoin and Ethereum.

Transactions are also incredibly expensive. Again, look at Bitcoin and Ethereum, where transactions regularly cost tens of dollars to process. You thought Paypal or Stripe fees were kind of high? Multiply them by tens or hundreds and you’re in the realm of crypto.

Reversibility is also an issue. With banks, when you try to send money to the wrong account, it either fails, or is reversible if it succeeds. With crypto, transactions are not reversible, and if you send money to an invalid address, that “money” is gone forever and you have no recourse and no way to recover it. You didn’t just “drop” the currency — you threw it into a black hole.

While there might be some interesting aspects to cryptocurrency that might help advance digital payment technologies of the future (backed by real governments and with a real legal framework to protect users and holders), cryptocurrency today has no value whatsoever. I don’t see that changing anytime soon.

By all means, play in your scam-playgrounds. Don’t be surprised when regulations catch up with you, and you’re in jail for fraud or tax evasion. I just wish it wasn’t necessary to burn forests in order to power this nonsense.

First Steps in 3D

I’ve started learning to use Daz3D. My first render used stock content and was before reading any part of the manual or tutorial. It’s beautifully horrible, and you can see that the body shape, the skin, and the clothing are all fighting about which one gets to be visible.

First Render - Clothes Problem

No, silly, the clothes go OVER the skin, not under.

The second one was before learning how to match hair to body (dang, that’s a lot of scalp, girl).

Second Render - Sane Clothes

Dang, that’s a lot of scalp, girl.

The third one was an actual scene (she’s clearly holding an invisible meatloaf). I still know close to nothing.

Third Render - Hair Fixed

If there were any meatloaf, she would totally be offering you some.

All of these will be very embarrassing if I get to the point of competence. Which is the point. A cringey point of reference for measuring progress, if you will…