It is the 1728th of March 2020 (aka the 22nd of November 2024)
You are 18.219.253.199,
pleased to meet you!
mailto:blog-at-heyrick-dot-eu
I survived - really
I know, I know. I last wrote on Tuesday and since then silence.
I didn't die of an unexpected side effect. Instead, I've been shattered due to a lack of sleep. You see, I sleep on my side.
And when I had a needle stuck in one arm and a different needle stuck in the other arm... kind of run out of sides to sleep on.
Anyway, still around, and in this sudden cold snap I have started my advent calendars. I won't be doing a blog article each day as that takes way too much time. I will, however, be uploading a daily video.
The first thing I need is a "studio". This was thrown together (literally!) by hanging a green cloth on a stand behind me. Given that I'm using internal lighting and not anything special, it's a surprise that it works as well as it does.
Lots of green for chromakeying.
Since I completely suck at remembering lines, I'm using a prompter. This is the little Android portable positioned just below the camera. It's not a perfect arrangement, but I don't fancy spending a hundred euros for a piece of glass to mount in front of the camera. There are cheaper models, but you'll get what you pay for...
Just read the words.
My odd hesitations are not because I can't read, it's because the app I'm using Inmei Teleprompter is very basic and its speed settings are a bit weird. The setting that I use is a little too slow for me, the next setting up is too fast (I could keep up but it would sound dreadful), and we're still on the far left-hand side of the adjustment bar.
Of course, I won't publish the scripts as otherwise you'd spot all of the times where I go off-script slightly. But, alas, reading a script means writing one, then running through it a couple of times to ensure that there are no annoying tongue twisters.
By which time I've probably said more words than I usually do in a week and I then have to speak to camera. Or again if I thought the first version sucked. And maybe again if I sneezed or something.
I do my piece in one continuous take. The title sequence was spliced in afterwards. That's why my booboo about the number of Playmobil people (I originally misread it as 37 billion, went back later because I was like "seriously?" and saw it was only 3.7 billion) was left in. I could have removed it, but that would be an obvious cut.
Of course, by the third take I was cold, needed to pee from all the tea, and was quite enthusiastic about just getting it done already, knowing that was just the prelude. So, yeah, I'll have to try to remember not to keep hitting the microphone with the box.
AND CHARGE THE BLOODY MICROPHONE, RICK!
Ahem, yes. That too. ☺
The animation...
Making the animation.
I didn't put a lot of effort into this, and it shows. Before I did the bit above, I draped the green over the table, started the Stop Motion Studio app, and made a little animation. Lessons to learn? Much better lighting, and don't depend upon the app working in "automatic" mode as it will select the white balance and exposure each time which can lead to... subpar results. Set the camera up manually for consistency.
Finally, I threw together a quick bit of music in SimpleSeq and just recorded it by placing my phone on top of the piano.
That, and a lot of editing, made the final result that you may have already seen.
SimpleSeq v0.19
A new update, this is a bug fix release.
As mentioned in a recent comment, I had accidently left in place a single line of debug code that made all of the instruments be piano. Duh. But since nobody mentioned it, I guess I'm the only person that uses this software. Hmm...
It now gives a position "@ #, # (#.#s)" at the top right of the screen. This is the 'x' (column) and 'y' (note) position in the music, and at what time that note would be played (seconds from the beginning). This was invaluable for timing the tubular bell dongs as Santa did his magic arm wavey thing.
One that's been annoying me for a while. I finally tracked down the problem that was causing the program to randomly crash when saving compressed files. Something was getting corrupted elsewhere, the effects of which were not felt until a new memory claim (for saving) was needed at which point the C library threw in the towel and unceremoniously terminated the entire application, instead of doing something halfway useful like throwing an exception.
Much more sanity checking around loading and saving compressed files.
And, of course, me daring to post a little snippet (that ultimately wasn't involved) to the ROOL forum got me a bit of flack for using inline assembler in a program - such as "If you've got assembler in the code, assume that's what's wrong first" and "You're using assembler where it isn't appropriate. You've got your assembler wrong." and "Don't write 'clever' code, write working and maintainable code.", etc etc (and I've taken the liberty of correcting the numerous typos).
The solution? "Create the library routine, then you've got it and you can use it again in the future, knowing that it works.".
Okay, fair enough, but the library routine would be either the same piece of assembler in a .s file somewhere else, or some unholy weirdness with _swix.
None of which helps when I want to ensure that I was passing the right sort of input into the SWI. My question was, given a char pointer and a struct pointer, they're both passed like that right? Not in the &variable form or something (because that, to my mind, means the address of the pointer itself, not what's being pointed at). Moving the code/SWI/method from this to that, here to there, will make any bloody difference if the input isn't right.
I've fixed up the code to better handle cases where it doesn't return a "done it" condition (the aforementioned sanity checking) and you know what? The problem wasn't even that little bit of inline assembler anyway (it was only suspected as it was new code and a seemingly new problem; but the two ultimately weren't related - it was something else).
Which is still there. Yes, a few lines of assembler. Diddums.
Next time, I think I'll just drop a lot more to DADebug to work my way through what's actually happening. As for asking on the forum? I don't think I shall bother. We all have our peculiar coding quirks.
Yes, I use inline assembler from time to time. But, then, yes I habitually ensure that release builds of my projects build with zero errors and zero warnings. As much as somebody might be horrified that I dared to use a few lines of assembler, I'm horrified when building a project from the ground up results in dozens upon dozens of screenfuls of compiler warnings. And, yet, that happens frequently.
So kindly don't blow up because I happened to use a bit of assembler. For me, that code is perfectly readable and there's nothing particularly "clever" about making an API call then and there as opposed to via a wrapper... and since I'm the only one who's going to see it, that's good enough for me.
No functional changes other than slightly different content at the top right of the screen, so no need for an updated user guide.
Your comments:
Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.