Adam Audio T7V studio monitors review

Earlier this year I purchased a pair of Adam Audio T7V speakers. They replaced a pair of Edirol MA-15Ds and it was obviously a big step up.

The speakers look very elegant and clean. It seems a bit like they were deliberately designed to look more simple than some of the higher models – bass port, on/off switch and indicator are all on the back. Nothing wrong with that though, I like the design a lot.

I love the sound. There’s so much detail and depth. I keep revisiting my favourite tracks just to hear all the new things I can discover. The signature “ribbon tweeters” are awesome and I doubt there are any higher frequencies I’d ever be able to hear from any speaker at all.

There’s more than enough power for my small semi-treated room. My desk was just big enough to let me put them in the proper “triangle” layout. I couldn’t resist adding a subwoofer. Not a necessity for 7″ speakers in a small room but a good way to bring up some lower frequencies and more punch to some heavier music. This 2.1 configuration brought me some disappointment at first.

My sound interface was plugged into the sub and the speakers were connected to the sub’s output, just like the manual said. I tried to level things out using the sub’s crossover and volume knobs. This turned out to be very hard and frustrating. I couldn’t find a balanced “flat” setting.

Then I figured out a much better way. I plugged the speakers into the sub’s other input! Both the inputs are just soldered together so the T7Vs effectively get untouched source input. I can easily tune the sub without affecting what goes into the speakers. Win!

Overall I’m really happy with this new setup. Great sound for a great price.

★★★★★ / ★★★★★

Repro shutdown announcement

The Repro iOS app and website will go offline next week.

It’s been an interesting project. I built it from scratch and learned a lot making it. Wrote an iOS app, handled user feedback and went through several updates, later I also built and maintained a server backend API and an accompanying public website. Overall, I still like the idea but the thing is that I like some other ideas even more and need more space to pursue those.

Bye, Repro!

D2 log 009 – Triggers

Added basic support for editable “triggers”. As I mentioned in the previous entry, the original Devastro used this approach for setting up win/lose conditions for each level.

Similar to Unreal Engine’s Blueprints – but less sophisticated, of course. Great for things like: “to win this level, the player needs to kill all enemies, destroy all saucers and find the red key”. I can also easily setup areas that will spawn more enemies when the player enters, events that happen when an item is picked up etc. all without writing any extra code.

The difficult part was to maintain inter-entity links – in the game, the editor and also on disk. The new entity system helped a lot – when saving a level to disk, I store the “index” part of the Entity ID and when loading, fill in the correct “generation” after all entities are loaded.

Triggers will help me add a lot of variety to the game using a limited set of tools. Can’t wait to explore all the possibilities.

D2 log 008 – More entity groundwork

After redoing the entity list I still wanted to improve handling game objects more.

Turned cameras into regular game Entities. They now use the safe handle-based referencing system to bind to other entities that they should “follow”. Also I can setup cameras easily in the editor without extra effort.

HUD overlays are now entities too. They link to the player via an Entity ID, get ammo & health info easily. No explicit wiring in main game code. Player dies – no problem.

The amount of code I was able to remove from the main game loop was quite substantial. I guess I should try to do more things like that. The original Devastro had a system of triggers also implemented as game entities. I used them for setting up conditions for victory – for example, there was a level where the player had to protect a herd of sheep.

This was setup completely in the editor by wiring the triggers for “alive” for each sheep into an “AND” node and wiring that into the “WIN” node. Pretty neat, now that I remember it… maybe I’ll use that approach again.

 

D2 log 007 – Cocoa

Working on the level editor I realized I’d really like my window size to match the phone format which means there won’t be enough space to fit the editing tools, such as entity list & properties, tile picker etc.

I could open a second window to render the editor stuff using the same renderer as the game and IMGUI is great but I already have some “imgui-style” widgets of my own and feel like mixing them together could lead to some hard to fix problems.

So I decided to use Cocoa, the native macOS UI framework. I’ll make a few floating panels independent of the main window. Clean separation, less trouble.

Starting with a simple entity list:

Grid view for selecting map tiles:

And a very early version of an entity property panel:

(Fields are generated dynamically for each entity type based on the property metadata).

Still a lot of work ahead to put it all together and wire it into the editor system, but already looking much better than my previous attempts.

Gogs

As I lean towards self-hosted software, I recently switched from Bitbucket to Gogs.

Gogs is one of the best web-apps I have used in a long time. It’s easy to install and maintain, the interface is great and the whole thing is fast.

The issue tracking and wiki are quite minimal but work well. I do miss an equivalent of Github’s “gists” to hold small snippets of code independent of any repository.

Running on a standalone $5 Digital Ocean VPS.

Rant: fman criticisms

Here’s my reaction to a reddit thread where a bunch of people were wrong about something. It was about the fman file manager and how the author had spent over 3000 hours making it.

Some people argued that making a general file manager application was “easy” and the author of fman had spent way too much time making such a simple app.

Wrong! Anyone who goes to make a tool as general and versatile as a file manager deserves huge respect.

Doing a UI prototype for two pane file list that lets you browse files is EASY. Making a file manager that actually helps you manage files is HARD.

Let’s see what needs to be considered when we try to COPY A FILE:

  • Cross-platform
  • All filesystems
  • All OS versions
  • Network volumes
  • Filename length limits
  • Case sensitivity
  • Special character encoding
  • Handle and report errors
  • Detailed progress indicator
  • Estimate remaining time
  • Pause/resume
  • Interactive options to overwrite/skip/ duplicates
  • Symlinks
  • Hard links
  • Correctly copy attributes, even when support varies between src/destination
  • Sparse files
  • Special files such as /dev/zero
  • Block size (20 byte file can use 4KB of disk space)
  • Quotas
  • Channels
  • Compression
  • Encryption
  • Optimize for SSD/HDD
  • Optimize for same-volume and cross-volume, cross-device copies
  • Sandboxing

All this must work 100% of the time, on 100% systems, otherwise someone is going to lose their data.

I don’t even know if fman actually takes care of all that, but my point is that I can imagine one could easily spend a good portion of development making JUST THIS and I would consider it a great achievement if it actually worked.

D2 log 006 – Rain

Let it rain! There was a rain effect in the first game, so why not bring it over? Good opportunity to see how easy it is to add a new entity type… turns out it it’s really smooth! Only one file to edit and it was up and running, including a custom “numParticles” property in the editor & XML serialization process.

I’m pretty sure I’ll revisit this later and improve it with sound, lighting & thunder effects and little splashes on the ground. For now though, it sets the mood of the level quite well already.

D2 log 005 – Xcode templates

While adding some new code to the project I got annoyed by the default C++ file templates that Xcode used. The header it creates contains old-style #ifdef guard and has a .hpp extension. Every time I use the template I obsessively delete all that stuff and start over with a simple #pragma once.

Why not make it the default? Turns out it’s not hard to create custom templates. They go into ~/Library/Developer/Xcode/Templates/File Templates/Source/ and have this kind of structure:

I’ve made the __FILEBASENAME__ files almost empty, because that’s what I want: