Rick's b.log - 2023/12/02
It is the 21st of November 2024 You are 18.189.185.63, pleased to meet you!

I survived - really

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.

How the videos were made

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

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.

Anyway, here's the update.

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:

No comments yet...