A Visual Introduction to DSP for SDR now includes some slides on digital modulation.
I wrote these a long time ago but the wording was targeted at an amateur radio audience. I finally got around to tweaking it to be slightly more general and publishing the result.
In further news of updating my personal web presence, I have finally set up HTTPS for switchb.org. As I write this I'm working on updating all the links to it that I control.
The thing I found underdocumented in Let's Encrypt/Certbot is: if you want to (or must) manually edit the HTTP configuration, what should the edits be? What I concluded was:
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
<VirtualHost *:443>
ServerName YOUR DOMAIN NAME
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/YOUR DOMAIN OR CERT NAME/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/YOUR DOMAIN OR CERT NAME/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/YOUR DOMAIN OR CERT NAME/chain.pem
...rest of configuration for this virtual host...
</VirtualHost>Notes:
/etc/letsencrypt/options-ssl-apache.conf (which of course may be in a different location depending on your OS and package manager) contains the basic configuration to enable SSL (SSLEngine on) and certbot-recommended cipher options.
My interactive presentation on digital signal processing (previous post with video) is now available on the web, at visual-dsp.switchb.org! More details, source code, etc. at the site.
(P.S. I'll also be at the next meetup, which is tomorrow, January 21, but I don’t have another talk planned. (Why yes, I did procrastinate getting this site set up until a convenient semi-deadline.))
Yesterday I completely rewrote my resource embedding test to cover more cases (especially ones new in HTML5) and be more usable. In the likely event you're not familiar with it, it's a HTML document which embeds many types of resources (images, audio, other HTML, etc.) using all of the possible containers (<img>, <iframe>, etc.) to see how browsers react.
The results can be quite interesting; for example, with the current expansion I discovered that JavaScript embedded in a SVG document will not execute if embedded using <img>, but will with <object>. (In hindsight, this makes perfect sense given the fundamental design principle of Web security, namely “don't add anything which would obviously make existing sites' security assumptions false”, the assumption here being that it's safe to allow <img>s as user-generated content.)
Specific new features:
<audio> and <video> containers.
window.top.
Let me know if you've thought of any additional useful cases.
I’ve uploaded almost all of my published Git repositories (previously hosted on a git-only server on on switchb.org, which is down at the moment) to my account on GitHub. Please update your remote URLs if you have any git clones.
The motivation for this change is simply that GitHub offers better visibility — an automatic web presence for each project, including viewing repository contents. I am not intending to depend on GitHub’s continued existence, of course; I still have local copies of each project, and additionally I plan to arrange so switchb.org automatically mirrors my GitHub repositories.
What I've just uploaded to GitHub also includes a project which I have not previously mentioned, timeline-ui:
A user interface experiment. Multiple types of time-series data, variously static/interactive, historical/future, etc. are displayed in a single view. (This was an idea I had floating around and which I used in 2010 for a class project; there is a lot more that could be done with it.) Written in Java.
I was going to write more about the concept, but I never got around to it; this will have to do.
List of projects just moved to GitHub:
I've finally gotten around to uploading my custom Mac OS X keyboard layout. The most significant additions over the standard U.S. keyboard layout are: mathematical symbols (relevant to calculus and symbolic logic), Greek characters, and arrows. It also makes (, ), :, and | unshifted.
Cubes is a work-in-progress open-source block game (that is, like Minecraft) where the blocks are made out of blocks; in principle, you should be able to build a complete custom block game from scratch simply by building the appropriate block-set, out of blocks. As I mentioned earlier, I'm doing a project on the HCI for this game. I need data.
If you think you might be interested in playing my game, or if you're a current player of a block game (Minecraft, Terraria, FortressCraft, what-ever), please take this survey. I assure you there are no “On a scale from 1 to 5” questions in it.
On September 6, I had an idea which I couldn't not work on. (Unfortunately, it wasn't an idea for either of my course projects this semester.)
As you may know, in Minecraft, the individual cubical blocks are textured with unsmoothed 16×16 pixel textures. All blocks’ shapes (that aren't just cubes) have lengths in multiples of 1⁄16 block (example, so that the objects have (to some degree) the appearance of being made out of voxels, or smaller cubes. And, people have built giant versions of specific blocks out of colored blocks.
So, what if building blocks out of blocks was actually how the block types were defined?
And that's what I've implemented, in JavaScript/WebGL. The working project name is “Cubes”, because I don't know where it's going enough to give it a better name right now.
The block types you see above were all procedurally generated as placeholders, since I don't have any save/load facility to save manually edited blocks (and I'm not sure about the color scheme of the current set of blocks-you-make-blocks-out-of).
Play (requires WebGL-capable browser; I recommend Chrome).
Controls: Standard WASD keys, or arrow keys, and mouselook. The left button adds or removes blocks at the location of the white rectangle cursor; the right button brings up a menu for choosing blocks (the empty square at the top left is the removal tool). The R key enters the world of the selected block; the F key exits.
Update 2011-09-13: I've improved startup; it now tells you more explicitly what went wrong if it fails to load, rather than a blank white screen. I've also added an in-game Help button with controls and browser compatibility info.
I'm on Google+, but I am not planning to post anything important-and-public exclusively there. I might experiment with crossposting.
In terms of what I want out of the place where I post the stuff I post here, LJ is still the better option, in supporting HTML posts, decent archive browsing, and finding context starting from permalinks.
I'm still thinking of switching to a different platform, possibly of my own creation, to get additional features: style sheets for blog posts, embedding JavaScript-containing content in posts (tastefully, I assure you), even better archive browsing, no ads, and a visual design more closely connected with my non-blog site.
I have updated the Minecraft topic at my web site, bringing it up to date with changes, adding many new links, and information about my new world. Also, I didn't previously announce this:
I am running a Minecraft server. I've been running one for a while, but it had a rocky start trying to run on a shared Linode. It now has a dedicated machine (though one which is rather old and running on a home cable connection) and is running 24/7.
The address is: mc.switchb.org
This server runs a copy of my single-player world, updated each day, so changes you make are not persistent (except for your inventory). This is a place to tour, or use for building experiments, not to live in. However, I have attempted to make it suitable for multiplayer use, with direction and instruction signs and multiplayer-capable rail stations (though most of the rail tunnels are single-track).
Feel free to suggest improvements to the facilities, or additional builds.
(Note for those who have tried the server before: I recently fixed a problem causing new players to spawn nowhere in particular rather than at the spawn station.)
I’ve added an Android topic to my site, including listings of apps I use.
Distinctly incomplete, but better published than not.
“Tile Game” was a game I wrote in the spring of 2010 as my final project for CI272 Visual Basic at MVCC. It was written in, of course, Visual Basic. I have just finished porting it to JavaScript and you can play it online.
A while ago I mentioned I was planning to write an introduction to LaTeX. Since then I have, while not actually finished that document, at least produced the skeleton and included all of the topics covered in my original notes-to-myself as well as some useful fundamentals. I don't recommend using it as your sole source of information, and it will probably make LaTeX purists wince in some places, but it admits where it's incomplete or doubtful.
An Idiosyncratic Guide to LaTeX
(Append .pdf or .tex to that URL to specifically get the rendered or source formats.)
As you can see, I decided to write the guide itself in LaTeX, primarily for the sake of including examples (not that I've done much of that yet), but also so that it is self-demonstrating. I considered changing the page size so that it has no page breaks at all, for better on-screen reading, but that would prohibit the use of footnotes. I've considered using margin notes instead, but they would require a large margin which can also be annoying on-screen. Please let me know what you'd like to see for such formatting.
I've written a new topic index page for my site: Games, simulations, and animations. Except for the note about Tile Game, everything on it is something I've already published.
Condensed list of the contents: Tile Game, Fire Worms, Mouse-maze, 15-puzzle, screen savers, Varychase, Linkage, Bouncyworm, Brownian Tree, pendulum animation.
I'm planning to write a short introduction/quick reference to LaTeX (with a particular emphasis on “what corresponds to this HTML element?”, and actually explaining the core syntax rather than just examples of particular cases), as another page on my web site. Should I write it as HTML or LaTeX (rendered to PDF)? Using LaTeX means I can embed rendered examples without each one being an image (which I don't really want to deal with), but the result being a PDF rather than HTML means that the document would have a fixed line width, and possibly require download/be unviewable depending on the particular browser/platform/installed plugins. (It could still have hyperlinks.)
(In case you're wondering, there are several LaTeX-to-HTML conversion tools, and the last time I looked they all either didn't run, accepted a far-too-small subset of LaTeX, or produced too-low-quality or obviously broken output. I used one of them for this post and had to hand-edit black bars out of every image and trim the margins, and the antialiasing is poor.)
What would you prefer?
I've added a mini wheat farm to my Minecraft world, just for the sake of building one. If you're interested in looking, it's southwest, with underground access branching off the spawn tunnel.
I've published my Minecraft notes and bookmarks.
This is a slightly different sort of addition to my site; it is a page that is nearly all information and links I've gathered rather than my own work. I've been wanting to write this type of page on several topics for a while now, having them be a place for:
More fuzzily, I hope that giving myself this organizational concept will get me to publish more of anything. Here are some topics I hope to write about in the future:
I've also thought about adding to various pages of my site automatic indexes of related blog posts (via tags), but I'm not sure it's worth the effort.
Varychase is a graphics toy I just published. Runs in the browser; wave your mouse around and it makes curly patterns.
I originally wrote the option-less version May 29, 2010; yesterday I finally got around to adding a bunch of stuff, polishing the presentation, and publishing it.
It uses <canvas> for the optional line-drawing (I should compare the performance to using SVG instead, as well as also putting the dots in the canvas), and a few miscellaneous HTML5/CSS3 features for optional refinements. I've tested in Safari, Chrome, and Firefox on Mac.
Got a nice fluid layout on your web site? Annoyed at how mobile browsers like to assume pages need nine hundred virtual horizontal pixels to display properly? Add this to your <head>, as I've just done across my site:
<meta name="viewport" content="width=device-width">
This tells iPhone and Android browsers, at least, to present the page with a virtual window width equal to the device's actual screen width. It was invented and specified by Apple.
(I am not taking up the question of whether these browsers are making the right default choice. I will say, however, that in my technical opinion this is the wrong choice of location for this parameter: whether a layout will work at narrow widths depends largely on the stylesheet, not on the HTML; this parameter therefore ought to be stored in the stylesheet (that is, be a CSS extension); insofar as it does depend on the HTML, you can then put it in a <style> element.)
If you're looking to use media types to provide different styles: These browsers also don't respect the “handheld” media type; but they do support draft CSS3 Media Queries, which allow you to condition on the actual screen width — if you want, even in ems! I've used this on the main switchb.org page to make the Big Text less likely to spill off the screen (could use some further testing; all I've used so far is my desktop and a Nexus One), and also in the Caja Corkboard demo (which I wrote this summer (among other things) and ought to blog about).
A data: URL directly contains its content; for example, data:text/plain,Hello%20World!. The main usefulness of this is that you can do things like including images inline in a document. But you can also use it to create 'anonymous' HTML documents, where any link to them or bookmark contains the entire document.
I originally did this in 2006 when I was in need of a URL-encoding tool and did not have one to hand; so I wrote out:
data:text/html,<form action="data:text/plain,"><input id=r>
Properly encoded, that's:
data:text/html,%3Cform%20action=%22data:text/plain,%22%3E%3Cinput%20name=r%3E
This produces a form with a single field which, when submitted, will generate a data URL for a plain text document containing “?r=” and then the text; the URL, then, will contain the entered text URL-encoded after the “?r=”.
Of course, that's a horrible kludge and JavaScript has an encodeURI function...
See my site for the rest of that thought and more examples. (I can't include any actual data URLs in this post because LiveJournal doesn't permit them, for necessary but unfortunate reasons — the origin, in the sense of same-origin policy, of a data URL is the origin of the page containing it.)
