Recherche avancée

Sur d’autres sites (6130)

• Methods For Retaining State

  26 décembre 2011, par Multimedia Mike — General, evernote, organization

  I jump around between projects. A lot. Over the years, I have employed various methods for retaining state or context as I switch to a different project. Here’s a quick survey and a general classification of their effectiveness.

  Good

  • Evernote : This is a cloud-based note-taking service that has a web client, Mac and Windows clients, and clients for just about ever mobile platform out there. I have an account and access it via the web interface as as the Windows, iOS, and Android clients. I really like it.

  
  
  

  Okay

  • Series of text files : I have been doing this for a very long time. I have many little note-filled directories here and there that are consistently migrated to new machines but generally forgotten about. This isn’t a terrible method but can be unwieldy when you work on lots of different machines. I’m still tracking down all these directories and importing them into Evernote.

  Bad

  • Layout of desktop windows : I have a habit of working on one project in a set of windows on one desktop space and another project in a second set of windows in another space, etc. Oh, this makes me shudder just thinking about it, mostly because of living in constant fear of a power failure or some other inadvertent reset (darn you, default config’d Windows Update) that wipes the state clean (sure, all of the work might have been saved, but I was relying on those windows to be set up in just the right manner to remind me of all the things I was working on). These days, I force myself to reboot at least once a week so I can’t get too deep into this habit. When it’s time to change projects, I write up exactly what I was doing and where I left off and stick it in Evernote.
  • Open browser windows : I guess it’s common to have many, many tabs open in one’s web browser in this day and age. Like many, I use open tabs as a stack of items to read. The state problem comes when a few of the open tabs represent TODO items. Then I start living in fear that the browser might crash or be restarted in an unexpected way and I struggle to recall what 3-5 important TODO items were that I had opened in separate tabs (on top of a stack of less important items). Again, I try to shut down the browser frequently in order to break this tendency. TODO items are better filed in Evernote.
  • Unsaved data in a text editor : Okay, this is just sloppy on my part, shoving temporary data into a text editor window thinking it’s supremely ephemeral. The problem comes when it’s linked to one of the many tasks on my desktop that might be bumped down a few priority levels ; when finally returning to the context-free data, I’m at a loss to explain what it’s for. Evernote gets it, once more, with a more thorough description of what was going on.
  • Email inbox : I make an effort to ensure that my email inbox has the fewest number of messages possible. Once things are dealt with, they get filed away elsewhere. This implies that things in my inbox require action. Some things have a habit of hanging around, though. Longer items now get described in better detail and filed away in Evernote.
  • Classic paper : Thanks to Derek in the comments for reminding me of this one. Paper is a reliable standby but it can get unwieldy when Post-It Notes litter your work area. Further, it can be problematic when you have multiple physical work areas.
  • Shell history : Another method I rely on entirely too often. This is when I count on a recipe of command line incantations living on in the history buffer of my Unix shell (generally Bash). What sequence of git commands allowed me to do XYZ ? Let’s check the shell history– I sure hope it’s still in there.

  Conclusion
  I guess what I’m trying to say here is that I really like Evernote. If you have similar troubles with retaining state, try it out. I hear there are many other services similar to it with slightly varying feature sets (people rave about Microsoft OneNote). So there are plenty of options and something out there is surely a fit.

  Evernote has a free tier and a premium tier. For my meager note-taking needs, I don’t come anywhere close to the free tier’s limit but I decided to pay for a premium subscription simply because I feel like I derive so much value from the service.

  One downside, however, is that I seem to be doing a lot less blogging since I got on Evernote earlier this year (though it is where I author most of these posts nowadays ; I especially like that I have a notebook labeled “Posted” whose incrementing count reminds me that I am getting some stuff out there). I originally started this blog as a sort of technical journal in order to organize notes and projects in a central location. It’s strange to think that if Evernote existed in 2005, I might never have had a reason to start this blog.

• Releasing GME Players and Tools

  22 mai 2012, par Multimedia Mike — General, alsa, github, gme, pulseaudio, Python, sdl

  I just can’t stop living in the past. To that end, I’ve been playing around with the Game Music Emu (GME) library again. This is a software library that plays an impressive variety of special music files extracted from old video games.

  I have just posted a series of GME tools and associated utilities up on Github.

  Clone the repo and try them out. The repo includes a small test corpus since one of the most tedious parts about playing these files tends to be tracking them down in the first place.

  Players
  At first, I started with trying to write some simple command line audio output programs based on GME. GME has to be the simplest software library that it has ever been my pleasure to code against. All it took was a quick read through the gme.h header file and it was immediately obvious how to write a simple program.

  First, I wrote a command line tool that output audio through PulseAudio on Linux. Then I made a second program that used ALSA. Guess what I learned through this exercise ? PulseAudio is actually far easier to program than ALSA.

  I also created an SDL player, seen in my last post regarding how to write an oscilloscope. I think I have the A/V sync correct now. It’s a little more fun to use than the command line tools. It also works on non-Linux platforms (tested at least on Mac OS X).

  Utilities
  I also wrote some utilities. I’m interested in exporting metadata from these rather opaque game music files in order to make them a bit more accessible. To that end, I wrote gme2json, a program that uses the GME library to fetch data from a game music file and then print it out in JSON format. This makes it trivial to extract the data from a large corpus of game music files and work with it in many higher level languages.

  Finally, I wrote a few utilities that repack certain ad-hoc community-supported game music archives into... well, an ad-hoc game music archive of my own device. Perhaps it’s a bit NIH syndrome, but I don’t think certain of these ad-hoc community formats were very well thought-out, or perhaps made sense a decade or more ago. I guess I’m trying to bring a bit of innovation to this archival process.

  Endgame
  I haven’t given up on that SaltyGME idea (playing these game music files directly in a Google Chrome web browser via Google Chrome). All of this ancillary work is leading up to that goal.

  Silly ? Perhaps. But I still think it would be really neat to be able to easily browse and play these songs, and make them accessible to a broader audience.

• Size Discrepany in the ‘du’ Command

  22 juin 2012, par Multimedia Mike — General

  I had a problem today while using the common Unix command ’du’. As a refresher, ’du’ stands for disk usage and is a handy tool for understanding how much disk space is being occupied.

  I think ’du’ is probably doing the right thing. The problem might be that I’m getting strange (read : 1/2 the expected number) when running the tool against directories on vmhgfs, the VMware filesystem.

  Science Project
  On an Ubuntu Linux VMware session, my home directory is on the main file system, which is ext4. The directory /mnt/hgfs is reported by ’mount’ to be of type vmhgfs and is shared with the host machine.

  Create a directory in the home directory and generate a 10 MiB file :

  mkdir /home/melanson/dir
  dd if=/dev/urandom of=/home/melanson/dir/random-file bs=1048576 count=10
  

  Create a directory on the shared drive and copy the same file :

  mkdir /mnt/hgfs/vmshare/dir
  cp /home/melanson/dir/random-file /mnt/hgfs/vmshare/dir
  

  Run ’du’ on each directory using the -k and -h options :

  du -k /home/melanson/dir /mnt/hgfs/vmshare/dir
  10244   /home/melanson/dir
  5120    /mnt/hgfs/vmshare/dir
  du -h /home/melanson/dir /mnt/hgfs/vmshare/dir
  
  11M    /home/melanson/directory
  
  5.0M   /mnt/hgfs/vmshare/directory
  

  I noticed this discrepancy when I was trying to pack a set of files (akin to ’tar’-ing) living in a directory in the shared location. I was going mad trying to understand why the original directory was only 2 MB as reported by ’du’ but the final packed file was 4 MB.

  To be fair, the man page for ’du’ succinctly states that the tool’s purpose is merely to "estimate file space usage".