Carl's Notes

Warning: Gets very technical, so beware!

So, the very first magic wand the theatre company I'm involved with had caused some electrical burns to its original operator due to malpractices by the original creator.
I think it might be fortunate that he's dead now, though I think it was more due to age than an accident with his contraptions.

The second version (that I'm aware of) was the one that our current fairy queen broke this year taking last year's decorations off it, so the third version was the one I fixed up and improved.

The fourth version, which this post is about, is one I've been asked to build to replace our old one.
The fifth version, and there will be one, will have even more features than V4, so we'll either be able to choose which features to enable, or which wand to use for each year after, depending on what features we want to use that year.

( Very technical details are here... )

So, apparently I've done so well with repairing our current magic wand that I've been asked to make our next one! =^.^=

Further talks and research into what people would like and would find useful and/or helpful has yielded a pretty good amount of information.
For example, since our director of 25 years has somewhat retired and her son (who has also been with us for a very long time) has taken over as director, he has quite a lot of ideas that could make things even better, including our future magic wand.

Our previous wand was only capable of flashing when charged and turned on, so there is a lot that can be done to improve on that.
In fact, our current wand is now capable of glowing when charged and on, which is already a great improvement.

He'd mentioned that what he'd like a very capable wand that can do a lot, but the various features can be turned on or off as desired each year.
He did also say that it would probably require a user's manual because of all the features, but we do make sure our fairies are able to use the wand well before the show starts.

Here's a list of some example effects that we'd like a new wand to do:

• Pulsate or cycle through a rainbow when the fairy is invoking a spell.
  (this is a very straightforward effect that can be easily done with about fifteen dollars-worth of parts, and is programmable to boot)
• A ‘disco ball’-like effect of dots of light rotating slowly around inside the bulb.
  (this is going to be tricky, as we can't have any shadows on the front of the bulb)
• A sort of ‘chaser’ effect, with columns of light spinning around the bulb.
  (this should be relatively straightforward. Just a few LEDs with fins between each pair so their light doesn't interfere with each other)

Quite an interesting list, though I'm quite sure it's not complete yet.
Though I'm not sure that would be possible to have all those effects on the same wand, not without having multiple wand tips anyway.

I also don't think I'm ready to try putting all that together my first time making a new wand, so I'll likely be making at least two wands, with the first one being rather less capable than the later one(s).
Hopefully I can get the first one done before February 27th, as that's when my theatre company is having its cast party...

Okay, just one prop.

But it's a rather interesting problem, and one that's taken me two weeks to get to even a moderate understanding what the problem is...

I've already mentioned on here about the idea I'm working on for a remote sound-effect trigger system.
Well, our director noticed how (seemingly) adept I am with electronics, and on November 8th approached me with a supposedly simple problem.

You see, we feature our fairy queen with a magic wand prop, which gives off a bright flash when its button is pressed. The flash is bright enough to be seen in the back rows of the theatre, but not bright enough to blind the fairy.
Anyway, apparently our current fairy queen was taking last year's decorations off the wand when she accidentally broke the ball off the end.

You know, the ball that contains a flash circuit board from an old film camera?
She broke the wires off the circuit board, and the question was how to get it back in working order.

My initial response: Yeah! Sure! I'll have it done by next week!

Yeah, no.

The circuit board was taken from an old film camera, and therefore not intended to be used in the manner we have been, so the pads I'm supposed to solder the wires back onto are not marked, which in turn meant that I had to follow the traces on the PCB by hand.
(yes, I checked. The part number on the board didn't show up anywhere online)

Anyway, after finding about half-a-dozen different schematics for various brands of old xenon-type flash units (none of which matched mine), I finally (thought) I'd figured it out and decided to move all the components to a new board.
Unfortunately, it didn't work, and I then moved only the parts responsible for charging the capacitor back to the original board, where it worked again.
(turns out I'd missed a connection)

My current plan is (as I'm still not finished it yet) to use both boards to make it a more compact package, incorporating a plug and socket between the wand itself and the flash unit so we can have a backup flash unit.
(and hopefully this won't happen again)

I wired the whole thing up again in a temporary manner on my workbench (aka, my bed with a board overtop) and it works again! =^.^=
Next up is to move the charge LED (now a bright white one instead of a tiny green one) next to the flashbulb, lower the value of the resistor right beside it, and wire the boards together properly.

It's actually quite fascinating knowing a theatre director. You get to learn all sorts of things, and get a bit of an "in" to see even more stuff.

For example, I was able to see what you might call a minimalist production of “Hound of the Baskervilles” that used three males actors and a two-sided fireplace, and was later invited to usher the same show at another venue.
(we joked about starting a new theatre company called Three Men and a Fireplace. It would work! Honest!)

Anyway, there were a few scenes where one of the actors had a small plastic gun they had to fire a series of shots from, but the shot sound effects were part of an audio file played through the sound system, so they had to synchronize their hand motions to the audio file, which didn't work very often.
(well, not to me, anyway)

So I decided that there ought to be a better way to do this.

I found out that they use a program to cue up all the sounds that make up the sound effects portion of the show into a sort of audio script.
It's triggered somewhat like PowerPoint, just keep pressing a key to trigger the effects.

You can also trigger particular effects via other keys on the keyboard if your script isn't actually a single linear progression.
This is important, because it makes what I'm trying to do possible.

I also found out that you can buy a hobbyist-oriented four-button key fob and wirelessly-activated relay.

Put these two thoughts together, and you get a key fob whose relay activates a key on the guts from a USB keyboard.

Now, while you can get USB keyboards pretty cheap nowadays, there is an issue with most of their circuit boards.

The pads used to connect the board to the key matrix do not actually accept solder.
In fact, the one board I'd tried actually had the hot solder roll around on top of it, and broke right back off easily after letting it cool and harden.

Second option was to use any of a multitude of microcontrollers, small very low-end computers that are (usually) easily programmed to do simple tasks.
Well, there aren't too many things simpler than pushing a button when an input changes, so it should work fine, right?

First test was with an Adafruit Trinket, a small ten-pin micro microcontroller that has three data pins and a bunch of power pins. Useful for small projects.
Plus I was able to have it emulate a USB keyboard! =^.^=

Unfortunately, I need about six I/O pins or so (might be up to eight, I'm not sure yet), so while it was great as a temporary test rig, it won't be useful in the long run.

Because the Trinket is compatible with Arduino microcontrollers (as are many microcontrollers nowadays, much to my relief), I'm currently mocking up some software on my recently-purchased Arduino Leonardo (one of their latest official boards) before I choose a smaller board to 'port it over to.

Ideally, I want to put as much of the parts as possible into a small plastic project case so it all looks fairly professional.
(with the added benefit of preventing connections from getting bumped)

Anyway, I'd tried to show my progress to my director friend, and she and her husband (who does the music and sound effects for her shows) are both quite happy about the possibilities.
Unfortunately, due to a faulty cable, I wasn't able to actually demonstrate the project to them, but I will have a working model to show them later.
(honest! =^.~=)

So, back in October of last year, I attended a showing of Hound of the Baskervilles, a lighthearted take on the Sherlock Holmes classic.
It didn't take itself seriously at all (much to my great amusement), and surprised me at how well it did for a somewhat minimalist show.
(having only three actors and one stagehand, along with a small array of props and set pieces)

In fact, I enjoyed it so much I saw it a second time! =^.^=
(fortunately, as I was involved with a pantomime at that point, I was only charged ten dollars a ticket instead of the twenty-five it ordinarily cost)

The only thing I noticed that could be improved upon (and there was damn little of that, aside from seating and visibility) was the synchronization of gunshots to the actor's hand motions.

Having spoken with a couple of people involved with the production of the show, I learned that they had a soundboard program doing the sound effects.
Pretty simple setup, you press a key and the associated sound effect played.
I was told that the gunshot effect was manually triggered, so the actor with the gun had to be in sync with the sound person triggering the shots.

Now, I put my thinking cap on for this and tried to come up with a way to make it easier to keep the sound tied pretty closely to the actor's motions.
One option I came up with involves a cheap USB keyboard, a wireless relay, and a wireless key fob.

The key fob activates the wireless relay, which in turn closes over one of the keys on the keyboard, sending the key-pressed message to the computer.

It's pretty simple, and requires very cheap parts.
Ought to take less than thirty dollars, I'm guessing.
I already ordered the remote and relay, now all I need are the cheap keyboard and some kind of power supply.

Looks like the trick's going to be the power supply at the moment, mostly because I'm not sure where exactly to look.
Lee's Electronics has something that should work for less than ten bucks, but I'd still need some kind of socket to plug it into.

Ah well, still at the drawing board...

Sometimes I surprise myself with how quickly I can put together a small program.

Case in point: Yesterday I was playing an online Scrabble-like game called Popotamo, and had been using an online word-search tool to find the highest-scoring options (the longest words, in this case), but kept running into problems when the board got pretty full.

So I decided to grab a copy of the SOWPODS dictionary (the dictionary used by the game I've been playing) and try to write a simple program to provide suggestions based on the tiles I had already, as well as providing an option for specifying constraints for the words.

As it turns out, it was actually a rather simple program to write, taking less than four hours to complete, most of which was spent trying to figure out how to design the User Interface.

Originally, I'd written it in Python, an easy-to-use scripting language, but realized that it's not a very fast language, nor is it terribly portable.
So I decided to rewrite it in Java, which took less than two hours, most of which was spent trying to remember how Java does GUIs...
However, the advantages Java has over Python were threefold: First, it was fast, which is great when processing long lists of words. Second, it is entirely platform-independent, which means that it can run on any type of computer that has a Java implementation. Third, the program can be packaged up into a single file, which means that you don't have to fiddle around with the dictionary file, because it's wrapped up in the single file.
(also, if I so chose, I could embed it in a web page, but I've decided against that for the moment)

Anyway, I was quite surprised at how fast it came together, and once I've found an appropriate place to host the file, I'll be posting a link here so others can use it too.

In much happier news, work on my Dig Site game is progressing very nicely.

It took me a day (only! Yes, this surprises me) to add support for checking to see if the board contains any valid moves.

I've delayed adding this before because I thought that it would be overly complicated, take too much time to run, and/or be nearly impossible.

As it turns out, the code is actually relatively simple (so far as concept goes, anyway), it doesn't take much time to run, and it was actually easier to write than I thought.
(most of the time was spent figuring out how it should be structured and what checks should be in place)

In addition, I've added support for some form of difficulty levels, which I'm managing by increasing the number of block types the higher the player's score gets.

This also means that I need more colours for block types.
Last time I tried to add more colours, colour was the only way to tell some blocks apart, and certain colours were difficult to tell apart.

I was thinking that it might work to overlay black outline versions of the tiles I'm thinking of using over top the coloured rounded square I have right now to give it a flavour of what I've been working towards.

Still not sure about it, but it would solve a couple of problems I have.

Whatever my normal is...
(no! Seriously! Sometimes I don't know what my normal is!)

So, now that my sister is married off, I'm next in line by age.
Fortunately, my mother has said that she'll hold off on nagging me to get married until I get a job, so I'm relatively safe on that score for now.

What I hope to work on this week is my Dig Site game for Android (you can visit the official blog for my projects of that sort on my Tumblr site), redoing some of the fan-art I've been in the process of creating for Darc Sowers' Codename: Hunter comic, and trying to have another look at moving back a version of Ubuntu.
(I've found altogether too many reasons to avoid Ubuntu Oneiric Ocelot, it is no longer something I know I can easily ignore)

If I think I can, I might try working some more on my Prolog adventure game framework.
My interest has been piqued after a friend expressed interest in the language's current status.

I've created a Tumlbr account for the projects that I'll be releasing publicly:
http://dvh-dev.tumblr.com/

Note that this has my real name attached to this, not this one.
(I use Carl Foxmarten for my artistic pursuits)

I'll be posting updates at least once a week until Dig Site is released, then I'll be using it for some other projects of similar scope.

I never realized just how much knowing about different programming languages would affect my knowledge of other programming languages.

For instance: I learned C, Java and C++ before I attended university, where I learned more about them and programming in general.

While at university, I learned that the above languages were all the same type of language, namely, they're all Imperative languages, which means you give the processor a list of instructions that it executes pretty much directly.

I also learned about two more types of programming languages, such as Logic Programming, which is where you construct a solution to a problem and let the built-in logic solver solve the problem itself, without specifying the exact sequence of instructions, as well as Functional Programming, which is similar to Imperative Programming, without giving you any form of global state, which means that every function returns the exact same result when given the exact same parameters.
(Functional Programming is often used for low-level systems programming, such as for low-level Operating System functions and BIOSes)

I learned about these programming language types by learning about programming languages that implement these types, such as Prolog and Erlang.

While designing the Event system for my Tetris Power project, I started to realize just how using a Logic Programming language would simplify the core of the system.

For instance, many events more-or-less directly trigger other events, like a "block_land" event might trigger a "row_full" event, which itself triggers a "score_add" event, which then has to add a floating score to the screen.

Theoretically, it should be relatively easy to do something like this if I use Prolog (the only Logic Programming language I know at present), though it could be a little awkward in places, due to the extra layer between the game logic and the rendering system.

I'm going to be examining this more fully and even starting a new branch to work on this to see what happens in practice.

More will be posted as I learn about it.