Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts

Tuesday, August 11, 2015

Colemak: Yet another keyboard layout

(It has been a while since last time. I don't feel sorry; it was never my intention to update regularly. Many things have happened which deserves a mention on the blog, most of which I have already forgotten; some of which I will never forget)

I am writing today because I foolishly decided to learn the Colemak keyboard layout. This in spite that I already write fluently in the rivalling ergonomic layout Dvorak, and that I am to present my master's thesis in less than a week. Writing this short paragraph has already given me a mild headache due to the vast number of characters required to make the words come together, each of which demanding my full attention. If someone gave me a penny for every character I wrote, my thesis alone would have earned me a respectable $1,427.50. If I then sold the pennies for their copper, that would yield a whopping $2,148.42. Enough to buy a new iPhone. And an Apple TV. And an Apple Watch. At least a non-exclusive version.

It all started because I co-inspired two classmates to switch layouts. However, they didn't switch to just plain old Dvorak, which was what I taught myself 15 years ago; these guys were betting on newer and fancier layouts more tailored towards computer scientists, namely Colemak and Programmer Dvorak. Admittedly, some special characters common to programming were awkwardly placed on my Dvorak layout, such as [] and {}. Thus, I wanted something better too. So here I am.

Of course, I first tried Programmer Dvorak. I really liked the idea with special characters as default on the number row, and as a Dvorak native, I learned it quickly. However, some of the most common symbols and numbers (for instance =,*,0,1) had an outright horrendous placement in the unreachable middle of the row. Yack.

So now I am typing my first lines of Colemak. We'll see for how long.

Tuesday, February 19, 2013

Serial Communication with RXTX in Java 1.6 for Mac OS X 10.7 (Lion) with Intel 64 bit processors

After spending way too many hours installing the RXTX library for Java on my Mac, I though it might be worthwhile to save others the trouble by sharing what I did to make it work. (Version 2.2) (2/18/2013)

None of the binaries I found that were available worked for me, and getting the configuration and build instructions right was neither completely trivial; some of my attempts plainly did not import at all (even though my code seemed to compile nicely), while in other attempts the code crashed and gave a non-sensical PortInUseException. (What I gathered from reading the online discussions, is that there are some issues regarding 32-bit vs 64-bit architectures, some issues regarding different parts of RXTX not working well together, some issues with the use of lock-files in Mac, and some issues with regards to RXTX not always working well with Java 1.6)

In any case, these are the steps I found to work:

(Most of which are based on this far more insightful walkthrough by Chris Bartley)

0. Remove all files from previous attempts to make RXTX work.

1. Install XCode Command Line tools, if you haven't already (I used XCode 4.6). (You can get XCode from the App Store. After XCode is installed, open XCode, and go to XCode -> Preferences -> Downloads -> Components -> Command Line Tools to install)

2. Download the source in order to build RXTX yourself. (None of the binaries that I found online worked for me, but you are welcome to jump to step 8 using my binaries if you want). You can get the source by telling this to the Terminal:

$ export CVSROOT=:pserver:anonymous@qbang.org:/var/cvs/cvsroot
$ cvs login
Logging in to :pserver:anonymous@qbang.org:2401/var/cvs/cvsroot
CVS password:
$ cvs checkout -r commapi-0-0-1 rxtx-devel

For the password you may have to type something random (e.g. a space character), if the Terminal goes off looking for a password in a file; but you should not need a password per se.

3. Check that, in your ~/.profile, the PATH environment variable has /usr/bin and /bin first (if needed, modify .profile so that the places where you set the PATH (e.g. "export PATH=$PATH:/opt/local/bin:/opt/local/sbin") have the additions at the end)

4. Set the variable JAVA_HOME:
$ export JAVA_HOME=`/usr/libexec/java_home`

(This step may not be necessary, but if Chris Bartley includes it, so do I)

5. Make sure there are no spaces in the absolute path to the rxtx-devel folder

6. Run the configuration script in the rxtx-devel folder
$ sh ./configure

7. In the rxtx-devel folder, manually edit the Makefile such that the JAVAINCLUDEDIR variable gives the correct path for the file jni_md.h (you will have to search for the file jni_md.h on your hard drive).
JAVAINCLUDEDIR = /System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers

Of course, your path will be different than this; it will be the path to where you found jni_md.h. (This variable was found somewhere around line 107 in the Makefile when I did this.)

8. Build
$ make

Two files are produced with which we are concerned. They are:
    * rxtx-devel/RXTXcomm.jar
    * rxtx-devel/i386-apple-darwin11.4.2/librxtxSerial.jnilib
    
Note that the name of the folder I call "i386-apple-darwin11.4.2" may change depending on your system. This is simply the folder name I got, running OS X 10.7.5 (Lion) on a 2.4 GHz Intel Core 2 Duo (64-bit architecture).

(The files that I produced in this step are available here, in case you want to try those, rather than making your own.)

9. Move the two files acquired in step 8 to /Library/Java/Extensions
Updated! See below

10. Add execution permissions to RXTXcomm.jar
$ chmod +x RXTXcomm.jar

At this point, RXTX works for me. In your Java source file, you should only need to
import gnu.io.*


UPDATE (2/20/2013)
It turns out that step 9 above will break some other Java applications (e. g. the Arduino IDE). A better version of step 9 is the following (these steps are specific to Netbeans, but I am sure you can do something similar using other development environments):

9.1  Move the file RXTXcomm.jar to a location where you can access it from the project where the library is needed, e.g. in a folder "libraries" inside your project folder.

9.2  Move the file librxtxSerial.jnilib to the base directory of your project

9.3  Open your project in Netbeans, then right click on the "Libraries" folder and choose "Add JAR/Folder." Find and select the file RXTXcomm.jar in the dialog that shows up. Since librxtxSerial.jnilib is in the base directory for your project, it will be automatically recognised.

Thursday, April 12, 2012

Distributed Laptop Orchestra

So, this semester I've been involved with this really interesting class at Carnegie Mellon: 15-323 Computer Music Systems and Information Processing. Taught by one of the creators of Audacity and Nyquist, Roger Dannenberg, the course aims to give the students a broad background in how music is treated programatically, to the point were at the end of the semester we can all co-operate to build a full-blown laptop orchestra application!
On Monday April 16, it is going to happen; the world largest distributed laptop orchestra is going to perform as a part of "Symposium on Laptop Ensembles & Orchestras" at Louisiana State University. Apart from LSU and Carnegie Mellon, five more universities in the US and UK will participate

Stanford University
Texas A&M University
University of Colorado
University of Huddersfield (West Yorkshire, England)
Queen's University (Belfast, Northern Ireland)

It will definitely be a late night for our friends on the east side of the Atlantic, as the concert starts at 20:30 EDT (New York -time). That equates to 01:30 BST! And at that time, I will sit on the stage at UC McConomy, eager to hammer notes and sounds out of my keyboard. I expect my fellow europeans to be the same.

The previous CMU laptop orchestra
I also hope the laptop orchestra will actually work. That piece of software right there is running my code - I do not want it to crash with such great universities watching and participating.

If you can't come to McConomy to hear the Carnegie Mellon -version, you should tune in to the live stream from LSU!



If you are interested in the source code for the project, it is available as open source. In fact, you can even download the code and participate yourself! There are instructions on how you should use the system online as well, so I will not go into details here; but I'd still like to give a brief technical overview of the project, and discuss some of the interesting challenges:

(At least to me, they are. But I take no offence if you stop reading now :-)

A performer's computer is connected physically to a live PA system in each of our 7 locations via mini-jacks on the headphone port; our software contains sampled sounds it will loop or play once, depending on the nature of the sound, and it can also generate a few waveforms.

(In order to do this, we must know how to generate, process and play back music in real time on the computer. The music is generated in blocks of bytes, each representing a very short time of sound, by the standard of an ear; this block is then pushed into the computer's music playback buffer, and then the next block is generated. This must be done on a high priority thread, to prevent any lagging. That kind of stuff is what you learn in this course.)

After the music is pushed out to the analog mixer, it is mixed and sent two places: a) To the local speakers, and b) as a soundstream to LSU.

In the local mixer, there is then one input channel for each performer, as well as a stereo input coming from LSU. The stream from LSU contains all the sounds from LSU as well as all the sounds from the 5 remaining locations. Thus, there will be some pretty significant latency issues; speed of light is only so fast, and there is lots of network jitter as well. The sound from LSU will then have some latency, and the sound from the other universities will have an average of twice that latency. This also has the consequence that the performance will sound different at each location, depending on the local mix and also on the varying latencies.

Roger Dannenberg, conductor
(play picture as sound)
So how do the performer know what to play? It certainly can not be very rhythmic considering the constraints discussed in the previous paragraph. But it should be somewhat synchronised, to create at least some sense of structure. To do this, we have created a conductor interface.

The conductor (Roger) will be able to send various conducting messages through a special mode in the software. These messages will appear in the window for all the performers, so that the we can play according to the conducting; variable parameters controlled by the conductor include

* Intensity
* Dynamics
* Pitch (high/med/low)
* Play/stop/fade in/fade out
* Music language/Sound architecture
The performer interface; top half is determined by conductor
Note that the conductor can send different messages to different universities, or "orchestras" as we cleverly named them in the software. There is also a chat system based on an hierarchal form, so anyone can send chat messages to anyone, everyone in a single orchestra, or everyone in the federation of orchestras.

To make all of that work, there is a lot of network logistics going on. The network is organised by nodes and supernodes; all nodes are connected to a supernode, and all supernodes are interconnected. When sending a message from a node (say, the conductor node), the message is first sent to the supernode, then from the supernode to the correct supernode(s) (if applicable) and then from the supernode to the individual node(s).

But, how do the conductor node know at what IP address its supernode is? To do this, each node will register with a special server (currently running at CMU) when they start up. This server will inform the node of what IP its supernode has, or if there is no supernode yet. If there is no supernode yet, then the supernode will initiate a connection when it is set up. In this fashion, as soon as a node is registering with the server, the server will provide information about all the nodes with which it should connect; if the node is a supernode, this includes all nodes in his orchestra, as well as all the other supernodes.

In addition to this, there is a clock synchronisation protocol running, and there is also a performance monitoring system that keeps track of how much data is being sent to and from each node. My contribution to the code has mainly been on this performance monitoring system. It basically collects information of all messages going in and out of a node, as well as the latency to the closest "parent" node (where the node containing the original clock is the uppermost parent; this should be the supernode at LSU).


In sum, this is going to be pretty awesome, and I'm looking forward to celebrate the anticipated huge success of our concert. Wish me luck, and tune in on Monday!

CMU School of Computer Science: Laptop Orchestras in Seven Cities Unite Via Internet for First-of-its-Kind Concert
15-323: Computer Music Systems and Information Processing
LSU: Symposium on Laptop Ensembles & Orchestras

Wednesday, February 8, 2012

Boarding Airplanes Simulation

In lack of anything deep to write about, I decided, wait... In spite of the overwhelming amount of deep topics to write about, I decided to write about this project I'm doing in one of my classes: I'm writing an airplane boarding procedure simulator. It is only a small project, and it is due this Thursday. It is nothing big, just fairly interesting.

(Strangely, there has also been a request for technical material on the blog)

If you have ever travel by air on a regular basis, you most certainly have wondered at some point or another why boarding the plane isn't more efficient. Well, I certainly have. Whenever I have to wait for a guy to store his luggage in the overhead bin, and there is plenty of room behind him, I get this sense that I should have boarded first. But how much time can we possibly gain by boarding in a non-randomized order? Well, this simulator aims to compare different strategies.

To start off, let us create a plane with seats and an aisle, and then let the aisle extend out of the plane and up to that boarding arm hallway thing that takes passengers between the airplane door and the actual terminal building. Then we fill up this arm with a line of passengers; each passenger is given a ticket, either at random, or sorted by whatever algorithm.

Now that we have lined all the passengers up outside the aircraft, each passenger will try to move towards their seat; at first, however, only the very first person in line can actually move! So what do the other people do? Well, they wait until the person in front of them has moved away, which of course takes some time. Then the next thing to consider is when a man has reached his row, he will use extra time to sit down, holding up everybody waiting to get past this point, and also holding up those waiting to get to a row that is occupied by the line of people waiting to get past that man who was sitting down. Now, if the man has a window seat, it may take longer if there is another passenger sitting down at the aisle seat...

It all turns out to be a big scheduling problem, but it is also a somewhat interesting model; each individual person exists inside the plane (in the aisle or in a seat), but it is also the actions of the individuals that change the state of the plane. The individual persons themselves will schedule their own actions based on their target seat and their environment, and some actions (i.e. movement) will change the state of the plane as well as the passenger. Actually, it turns out that most actions are simply to schedule a rescheduling while waiting for something to happen. It is like, writing down in the calendar that one ought to update the calendar. It all got juggled up in my head, at least...
I do have it working by now, but not elegantly, and I haven't generated any interesting line orderings yet. We'll see how it goes. Also, it has clearly been a while since the last time I used Java, so referring to the notes of my old introductory course has been invaluable. So what is the most efficient way to board a plane? I might find out tomorrow.

Thursday, April 15, 2010

Tetris







Move left - left arrow
Move right - right arrow
Move down - down arrow
Rotate - up arrow

Pause - p
Restart - r

Warm thanks to David Kosbie for teaching me this, and for providing JComponents and stuff that are too advanced for me right now.

(If you don't get it to work, try double-clicking inside the applet. If it still doesn't work, switch browser. If it still doesn't work, download the game to your computer (link below). If it still doesn't work, download java and try all this again. If it still doesn't work, buy a Mac)

More:
kosbie.net: Tetris
Play offline: Download Tetris