Tag: java

Think about the way you think. Think about that thought, and this one. Did you think using words? Did you see the words? Sound them out mentally? If someone asked you describe yourself, you would probably think of a series of adjectives (at least if you’re an English speaker).

We think via language, spoken or written. It’s the source of our intelligence and in some ways the root of our consciousness. Helen Keller is quoted with communicating that:

When I learned the meaning of ‘I’ and ‘me’ and found that I was something, I began to think. Then consciousness first existed for me

The languages you learn are the languages you express yourself with. They mold the way that you think about things and create who you are within your own mind. I’ve written about this before and it’s not an entirely new concept.

Recently I’ve gone to great lengths to change the way I think. Finding new ways to solve problems, especially software problems, often involves learning new languages, syntaxes or paradigms. You can force Java or C to do just about anything, just as you can force the English language to describe just about anything, but it might be that by using Java instead of Haskell, you’re using the wrong tool for the job.

I wanted to expose myself to a breadth of different software paradigms in as little time as possible. Rather than reading dozens of tutorials, or poring through hundreds of pages of reference manuals to get maximum exposure, I bought a book I called Seven Languages in Seven Weeks. Packed into this dense little tome is an overview of seven syntaxes from different families and programming paradigms.

The book begins with Ruby. It’s a fairly common syntax and I considered skipping this chapter. Indeed, with the relative ubiquity of the language I wondered why it had been included at all. In the spirit of playing along with the author I read through the sections and did the exercises as described. It turned out to be a good idea; some of the concepts around using method_missing as a DSL generator I had never put into practice.

From a comfort standpoint starting with a language you’re familiar with is also a bit like reading the introduction to a Latin grammar text book in English. I know the language and therefore the author can present his approach to me with words I can understand before I try to make my way through the rest of his presentation.

Speaking of presentation, Tate clearly has a grasp of basic pedagogy. From the beginning he uses a mneumonic device to help the reader put a face to the chapter and the methodology. For Tate, every language is like a character in a movie. They have their own personalities; something that makes them unique within the dozens of lexical environments out there. For Ruby it’s Mary Poppins. You know, syntactical sugar. Get it.

After Ruby Tate introduces a language I had never heard of, Io. Just try searching for information about this little language on the web. You won’t exactly find the throbbing community that surrounds java or ruby to back you up. No, if you choose to use Io to solve something new, you’ll likely find yourself in uncharted terrority. Not necessarily a bad thing if your approach to the text is to learn new ways to think.

A prototype language, Io is described by Tate as Ferris Bueller. In use I got the distinct impression that Io was heavily influenced by Smalltalk; everything you send is a message, and their are nothing but senders and receivers of messages. Method or function? Not really, there are ‘slots’ with message handlers. Can they be construed as the same thing, abstractly yes, but that is to avoid thinking in a way that make the language unique. Sending messages between objects is a powerful concept, and will help you better understand Objective-C and Smalltalk.

Using Io feels a bit like working in JavaScript, the only other prototype language I have any experience with. The concurrency framework is dead simple and provides the reader with a taste of things to come from languages like Scala and Closure. In fact, the actor framework in Io is so simple and impressive it feels like a great environment in which to teach concepts of asynchronous behavior and concurrent development.

After Io we get to Prolog, the most frustrating language paradigm for me to grasp in the book. Tate says Prolog is like Rainman. That must make me Tom Cruise.

The logic programming paradigm was at once the most fascinating and frustrating for me to study. At first I was enthralled. A language that I can plug values into and simply query against to get the answer like a super-powered database? Sign me up. I immediately found myself fighting the syntax. It took me some time to grasp the recursive nature of the language as well; no looping structures.

Solving the sudoku problem at the end is the best example of the power of Prolog and languages like it. Reducing a game to a couple of line of syntax, injecting the rules and simply asking questions is a beautiful way to solve many of the problems modern engineers are presented with …if Rainman doesnt drive you nuts along the way.

With Scala we take a detour back to familiar territory. Scala is the first variant on the java language I’d had the opportunity to use, so when I began the chapter I had some exposure to it. Most of the concepts in this language sunk right in.

Tate says we can think of Scala as Edward Scissorhands. He is the construction of spare parts and a lot of paradigms that already exist. I prefer to think of Scala as MacGuyver; It can do pretty much anything in a pinch. Scala was a comfortable environment to take a break in for a while. It sports functional programming paradigms like higher-order functions, while retaining many imperative concepts held over from C-based languages. Its also completely interoperable with Java, so all of those libraries we’ve grown attached to like joda and jsyn can be reused in the same lexical environment.

For concurrency Scala provides an actor system, much like Io. Tate clearly planned the book to address concurrency in a methodical way, first by introducing simple examples with Io, then advancing to Scala before diving headlong into the deep waters of Erlang and Clojure.

Things get uncomfortable again as Tate introduces erlang. From the get go Erlang baffled me, and when it was revealed that it was modeled after Prolog, I understood why. The only language compared to an antagonist in a movie, Tate describes Erlang as Agent Smith from the Matrix. Tate says that this is due to the self-replicating capabilities of Agent Smith in relation to the fail-safes built into Erlang, allowing the user to build highly fault tolerant concurrent systems that “just won’t die”. I think it’s because Erlang is evil.

Erlang is clearly very powerful, so as with Prolog I struggled through the examples and problem sets. I still don’t feel like I fully grasp how to do anything useful with it. Of the languages in the book, I feel like this is the one I need to spend the most time with to really understand.

Next we get a lisp. Clojure, a language fully compatible with the jvm is a lisp not at all unlike Scheme, minus a few parentheses. For Tate this language is like Yoda, no doubt due to the “reverse” notation of the arguments and the “inside-outness” of the code construction, at least compared to C.

Surprisingly, I took right to it. Of the new lexical environments this felt the most comfortable, but then, I’ve played with emacs a bit. The concurrency framework is not at all unlike scala with some notable additions. The concept of STM was awkward at first, but after fiddling with it for a while I was comfortable producing usable code.

The interoperability with Java is another major benefit to using Clojure. For Dijkstra’s Sleeping Barber problem, rather than struggle through writing a queue from scratch, I just borrowed the existing Java LinkedBlockingQueue, cranking up one actor to poll it, and another to deliver to it:

In just under 1000 parentheses the barbershop problem was solved. The wrapper around it is unnecessary, but then the whole solution is a little bit wordy for Clojure.

Impressed as I was with Clojure, it was time to study the final language in the book, Haskell. I originally selected the book based on the inclusion of Haskell. For some time now I’ve wanted to take a crack at this pure functional, almost entirely mathematical language.

Compared with the ever logical Spock, I’m still dazzled by Haskell. Having read the chapter and gone through the exercises, I feel like I’ve only scratched the surface of what it can do. It’s unofficial tag is that it makes hard things easy, and easy things hard. That ain’t no lie. Try reading a file with it. Do something simple, like open a socket. I feels like pulling teeth. Now go write a Fibonacci solver. Chances are you’ll have cooked up something that can’t be done as succinctly or quickly as Haskell can do it. Of all the languages in the book, this is the one I intend to dig the deepest with.

Wrap-up

When learning anything, I generally feel like a breadth-first overview is the best method of getting started. When learning new ways to think, this breadth-first search seems even more important. Get all your options on the table, see what’s been discovered before deciding how to tackle the problem. Selecting a strategy to go deeper with is a decision that can always be deferred until you know what your strategies are (Of course, you can only defer for so long before you just need to make a damned decision based on what you already know).

The real value of Seven Languages is that it provides this kind of breadth-first overview. You may know Java or C already. That’s great. What else is out there? What can a language like Io make easy? Clojure will help you understand lisp. Haskell will help you understand any functional and improve your understanding of modern math. Scala will let you build damn near anything.

Tate’s progression makes a lot of sense as well. If I was creating a curriculum to prepare a developer for the real world, I would start a youngster out with something like Ruby. This is an obvious ramp into Java and C. Then I might introduce something like Io to explain prototype languages and concurrency in a simple way. This is an step towards a better understanding of both Javascript and Objective-C. Then I might start them on Scala. It’s maximum exposure to as many concepts as possible. From scala, Learning a functional language is made easier if the programmer has been using Scala’s higher-order stuff like fold and map, and is used to immutable variables. Tate’s text provides a decent way to do all of this, introducing a young developer not only to the syntaxes but to paradigms that are broad enough provide insight to damn near any language out there.

If you’re interested in seeing my solutions to the exercises and problem sets, you can find them here. I learned a lot along the way, and I think I achieved the goal I had set out to achieve: Learning new ways to think.

How about a basic example. When a user logs in, set a bit in a bitset at the location of that user’s ID number. If you have a bitset allocated for each day, you can tell for any given day how many users logged in by looking at the cardinality of the bitset. Want to see if a particular user logged in on a particular day? Just check the location in the bitset for that user’s ID for the day in question for a 1 value. You can also perform more advanced logging, taking the union of multiple sets, or the disunion, to determine various statistics.

The theory behind it is simple and sound. It’s faster than hitting an RDBMS for values that are binary in nature, and the ability to apply basic set theory to your bitsets to analyze your metrics is quite powerful.

I began to use this method and the code examples on the Spool blog to create metrics in a variety of systems, not to mention create silly stuff like prime number tables. It only took a few implementations to realize that the code examples, taken at face value, don’t really work.

The Problem with BitSet.valueOf() and BitSet.toByteArray()

The heart of the problem lies in the output of Java’s default BitSet.valueOf() method. Here is one of the examples on the page:

If you use the Jedis setbit method to set all of your individual bits, then read the entire set out with BitSet.valueOf(), Java reads the bytes as though they were right to left, whereas Redis stores the values in a straight line. Left to right. The bit sex, as it is called, is reversed in this case, and you can’t possibly get an accurate bitset out of Redis if you retrieve it and convert it using plain ol’ BitSet.valueOf(). You have to have a ‘tweener method to flip the bit sex for you.

You might also think, though it isn’t in the examples, that simply performing a BitSet.toByteArray() would create a byte array appropriate for storage in Redis to be read back via redis.getbit(); Not so. Java uses its native byte order for each call. This confuses things greatly, because if you set the bitset using BitSet.toByteArray() and read it back using BitSet.valueOf(), everything looks correct. Try to read a bit out of this array and be prepared for a surprise.

And you can see the gist I created to read bytes out and put bytes in, retaining the integrity both ways, and show how things do and don’t work:

You can run that locally to get something like a code story…

So, whether or not the guys over at Spool have an unfortunately named helper method that looks exactly like the native Java one, or use some other methodology to maintain bit order in their bitsets I can’t say. It goes without saying that you should check and double-check any ol’ method you pull off the streets.

With just a little trepidation I have checked in the code for all of my free software goodies into GitHub. I was getting several requests to provide access to the source for several of my old projects, so rather than emailing code around on a case by case basis, I have simply checked everything in to GitHub for posterity. Who knows, maybe someone will jump in there and fix all the bugs.

I have written some other tools for my personal use that I will likely check in there as well, so check back if you’re interested in that kind of thing.

In my previous post, I discovered that the RWMidi library was available via GitHub, leaving it open to the possibility of forking and making my sync and pulse resolution changes public. Proving that Jung and Sting were on to something, while making these changes I received an e-mail from a user struggling with RWMidi:

There are no exposed methods to send pitch bend in RWMidi. So, newly empowered with forked code from GitHub, I created a method in the MidiOutput class that would allow a user to do this. I did a little research on the format for pitch bend method and came up with this:

Pitch Bend
The pitch bend wheel is also a continuous controller on many MIDI keyboards. Possibly, the Pitch Bend message is in its own category because it is something likely to be done frequently. The two bytes of the pitch bend message form a 14 bit number, 0 to 16383. The value 8192 (sent, LSB first, as 0x00 0x40), is centered, or “no pitch bend.” The value 0 (0x00 0x00) means, “bend as low as possible,” and, similarly, 16383 (0x7F 0x7F) is to “bend as high as possible.” The exact range of the pitch bend is specific to the synthesizer.

Crudely translated this simply means that pitch bends are in the range of 0 to 16383, with 8192 meaning “don’t bend”. Bending up means sending a value higher than 8192, bending lower means sending a value lower.

The format is a little funky and deserves some explanation. Essentially rather than sending two 8-bit bytes to represent the 16-bit value, I have to send two 8-bit bytes representing a 14-bit value, which will be interpreted as a number between 0 and 16383. So, in order to send the correct bytes I have to take my original value and rescale the size of each byte from 8 to 7 bits.

For the plain-jane 16-bit number 4000, the two 8-bit bytes would look like:

8

7

6

5

4

3

2

1

LSB

1

0

1

0

0

0

0

0

MSB

0

0

0

0

1

1

1

1

The 14-bit value that I need to send would be:

8

7

6

5

4

3

2

1

LSB

0

0

1

0

0

0

0

0

MSB

0

0

0

1

1

1

1

1

When visualized like this, it becomes clear that what we need to do is shift the last bit in the least significant byte into the first bit of the most significant byte, thus shifting the entire MSB over a place to the left. The way I have to think about this is to consider the two 8-bit bytes as zero-padded 7-bit bytes, and understand that when the receiving device gets the message, it will trim the last bit of each byte and put the registers together to form one 14-bit value.

Doing this is somewhat straightforward. I take the modulo of the pitch bend value and the greatest possible value I can represent with a 7-bit byte, which is 128, to get the LSB. From there I can simply divide the pitch bend value by 128 to get the binary value of the MSB. To send a pitch bend of 4000, I would send the numerical value 32 for the LSB, and 31 for the MSB. When you strip the first zero of each of these bytes, then string the registers together into one 14-bit number, you get 111110100000. This isn’t the most efficient way of doing this of course, I could shift some bits around, masking off values, etc. But I didn’t. The method I created is pretty straightforward:

There is some error checking here to make sure we don’t try to send a stupid value. Obviously if the max is 16383, there is no reason to allow 16384, not to mention a negative number. To test this I created a little sketch that looks a heck of a lot like a pitch bend slider, using the mouse’s X-position to control the amount of bend. I mapped the value of the 800 pixel width box to match our minimum and maximum pitch bend values, 0 and 16383 respectively:

And there you have it. The code is checked in to my fork of the RWMidi library and a pull request has been issued. I checked in a pre-compiled library with this functionality added as well.

Creating a pitch bend slider on the screen is small potatoes with functionality like this. My sketch should only serve to get you started. You should think about mapping other more exotic pitch bend controls to this method. Perhaps a sine wave generator, allowing you to change the pitch somewhat like an LFO would. Perhaps you can make the pitch “wobble” when the mouse tracks over some position on the screen? That old MIDI keyboard on your desk can already bend the pitch with a slider, how can you take this functionality and make something unique?

Many moons ago, I created a little tool called the GOL Sequencer Bank. You can read more about it here, and here. In order to create the tool, I used RWMidi, a Java/Processing library created by Manuel Odendahl of Ruin&Wesen. While creating the sequencer bank, I discovered that the RWMidi library had no support for MIDI Sync messages, preventing me from syncing the sequencer with a master, like Ableton Live. This simply would not do.

In the past, I would have looked for another library, but given that I had the source readily available, and had already written a ton of code interfacing to RWMidi, I decided it would be a better use of my time to modify the RWMidi library to support sync messages. You can read more about that here. The changes were minimal, and I learned a lot in the process about MIDI, Java, and the art of modifying open source.

Not too long after that word got out that I had made this change to the RWMidi library, and I started getting one-off requests to send my modified library to folks for their own use. For instance, John Keston over at AudioCookbook built his GMS synth using my modified library.

A short time after that, Mr. Keston approached me with what I thought at the time was a strange requirement: modify the library to support greater than 24PPQ for recognizing 64th and 128th note resolutions. In plain English, John wanted the GMS to support 64 and 128 notes using plain-jane MIDI clock. I thought it couldn’t be done, but loved the challenge, and modified the RWMidi library accordingly. It was a doozy.

These modifications to the RWMidi library have only been available as a custom change to the GMS and the GOL Sequencer Bank, but now, through the power of GitHub and social coding, I can make these changes available to anyone who wants them. I have forked the RWMidi library on Github, incorporated the changes there, and issued a pull request to Manuel to include them in the main source.

I have also built a jar file and included it as a download on GitHub. You can get it here.

Having finally discovered the beauty of social coding, I plan on eventually uploading the source of both the HarmonicTable and the GOL Seqeuencer. I’ve had requests in the past to make changes to the synth that I just don’t have time for, this way people in the know can simply fork the source, make their own changes, and ask me to pull them into the main body of work.

As more and more regular Janes and Joes become savvy programmers (i.e. our children), I expect we’ll see the power of social coding change the way we think about how software is made in general…

While I thought the GOL Sequencer Bank would get the bulk of my attention this Winter, it turns out I’m getting far more requests to update to the Harmonic Table controller. Among them were Midi Input capabilities, buttons lighting up, and some bug fixes here and there. All that completed, I give you Harmonic Table 0.5. Here is the breakdown:

Midi Input – This feature allows you to accept midi note on and off events and display them as key presses on the main screen. I see this as a learning tool that allows a user to easily see the relationships between notes. Note: At this time it is difficult to keep up with a rapid number of midi input messages. If you’re using this as a learning tool, it is recommended that you reduce the tempo of your sequencer so you can see these relationships without missing any notes.

Midi Thru – This is just another aspect of midi input. When this is turned on any messages appearing on the midi input will be mirrored to the midi output you have selected

I would be the first person to say that for the most part, MIDI is perfectly acceptable as an interface between musical devices, and has survived for as long as it has because of how dead simple it is. MIDI is still plenty fast, and in terms of interoperability, has yet to be bested. However MIDI does have its shortcomings, and while helping John Keston over at AudioCookbook with his Gestural Music Sequencer, I ran in to a big one.

Way back in the day, I can only assume before Mu-ziq and BT, MIDI clock was implemented at a rate of 24 pulses per quarter note. This means that when you press play on your sequencer, the devices that are synced via this clock hear 24 pulses for ever quarter note, and as a result can playback in time along with these pulses. After 12 pulses pass, you would move by an eighth note, 6 pulses a sixteenth notes and 3 pulses a 32nd note. You should see that as soon as I try to drop to a 64th note resolution, I’m in trouble. How do I wait a pulse and a half if all that I’m relying on is the pulse to tell me when to move forward? I’m sure that while scoring the soundtrack for Legend, Tangerine Dream were perfectly happy being able to sequence 32nd notes, but how am I supposed to start an Aphex Twin cover band without 128th note stuttering beats and retrigger effects?

There are ways around this of course, you can use the native time code in your sequencer or application and just use SMPTE frame based timing to keep it all in sync, but if you’re writing a simple step sequencer to interface with some master sequencer, this is a huge hassle. Whats a guy to do? Convert it!

Conceptually, the steps to do this are simple:

1. Intercept pulses2. Subtract the space between two pulses(in milliseconds)3. Divide this value by the quotient of your conversion divided by 24 (to get n milliseconds)4. Start a thread and send out a pulse to your sequencer every n milliseconds

So, if I want to convert 24 ppq to 96 ppq, I divide 96/24 to get 4. This means that for every pulse I get from the master sequencer, I should generate 4 pulses for my local sequencer. Now, look at the time of the first pulse, and subtract it from the time of the second pulse. Lets pretend I get something like 100 milliseconds. So at this point while the master sequencer will be sending me pulses every 100 milliseconds, I should generate pulses every 25 milliseconds. Then just do this for every pulse I receive (in the case that the time changes and I need to reduce or increase the amount of time between pulses, in the case of a ritardando or accelerando. Seems easy enough, but how to put it in practice.

I worked on a standalone project in java first. Wired through RWMidi, I passed the pulses from the event handler in my main java class to the Sync Converter, then using reflection mapping passed the newly generated pulses back into another even handler in my main class. I decided that this approach sucked for a few reasons. For one, the performance hit I took doing the reflection mapping twice (Once in RWMidi, then again in my sync converter. Also, this required me to have two event handlers to catch the pulses in my main class, one for the originating pulses, and another for the newly generated pulses. Thinking in terms of an end-user, who would likely not want to go through all of this trouble just to convert some pulses, I decided it would be better to jam the sync converter right in line with the MidiInput class of RWMidi. Since I’m no stranger to modifying that library (I enabled sync in it a few months ago), I figured Wesen wouldn’t mind some additional modifications to his work to create this sync converter.

At first, I assumed the best approach would be to create separate thread that handles the entire timing routine, a thread that would just stay in sync with the incoming pulses from the external sequencer. This approach turned out to be silly after 5 minutes. When do the math, at 120 BPM the MIDI timing pulses are roughly 21 Milliseconds apart. Asking a thread to perform even a simple algorithm like the one proposed above while making sure to send a sync pulse on the arrival from the external reference along with a calibrated “in-between” pulse (every 5 milliseconds, in this case), was asking too much. I tried it anyway, even though the math wasn’t working out, and sure enough, a significant amount of drift was occurring between the external and internal sequencers.

So no dice on a replacement time reference. Perhaps I could let the original pulse fall through to keep my internal sequencer in sync, and create a timer/thread to handle the “in-between” pulses? This approach was on the right course, but failed for a few reasons. I couldn’t the separate thread to wake up quickly enough to send the pulse (or pulses), so would fall behin the external sync every 8 to nine pulses. The result was drift. The timer was closer, but the overhead of creating a new thread per timer every 21 milliseconds (at 120 BPM), was just not cutting it, the result was still a bit of drift.

Frustrated, I did what I always do in these situations and went to sleep. It was clear that I was losing track of the number one priority of the clock, keeping that internal device in lock step with the external device. These in-between pulses are technically superfluous, and won’t even be accounted for unless you drop below a note resolution of 32nd note triplets. I started doing the math in my head. If a 1/4 note occurs every 504 milliseconds (120 BPM), than a 64th note only occurs arrives every 31 milliseconds. Would a listener be able to distinguish if a 64th note were off by a few milliseconds one way or the other at this speed? What is the threshold where individual notes just sound like pulses in an oscillation? I speculated that that threshold is the minimum amount of space I would need between pulses, after that it would just be a matter of sending the in-between pulses as quickly as possible.

In order to find out exactly what that threshold was, I ran a sleep test directly on the MidiInput class. I determined what my sleep time was using the same formula from above, and slept the entire midiInput thread for the determined amount. My assumption regarding this was that my sleep times would be less than the speed that any quantized midi message could possibly arrive, so sleeping would be safe, especially if the midiInput would only be used for sync messages. As I increased the tempo, I found that the threshold was around 5 milliseconds, after that you couldn’t sleep the thread for a short enough period of time to meet the 64th note requirement. Once this 5 millisecond threshold is surpassed, the thread doesn’t bother sleeping before sending the extra pulses, it just blasts them on to the receiver of the messages. I also discovered that this method of sleeping the thread was working just fine, and there was no reason to implement another method.

A few tests and mistakes on my part later and Keston was up and running with synced 64th notes on the GMS. Keep an eye on his space to watch his progress. The next release of GOL Sequencer will also include 64th (and possibly 128th note) capability

Bit slow these days with work and other stuff to get around to some of the changes I’m been meaning to make to these projects, but here is a quick 0.3 stab. I had more changes planned for this release, along with some stuff for playing back patterns and keyboard playback support, but for now I only had time to make a few changes:

Chord Mode – Chord mode allows the user to hold down a key on the keyboard and play a chord when a note is clicked. The chord map is on the release page.

Chord Lock – By default when playing a chord by pressing a key, the chord only sounds while the key is held down. In chord lock mode you need only press the key of the chord you want to play, and any note you click after that will play that chord

Various Performance Fixes – Nothing special here, moved some stuff around and improved map loops to speed the whole thing up a bit

I finished up a bunch of changes to the Game of Life Sequencer Bank. Here is a brief overview:

UI Overhaul – Rather than trying to stuff all the sequencers into 1 window, I gave them each their own tab. So now you have 6 tabs across the top with an independent screen for each sequencer. This allowed me to create a 32 x 32 grid rather than just a 16 x 16.

Internal Sync – Previously it was necessary to sync the sequencer to another device to get it to play, I implemented an internal metronome thread instead. The sequencer now works independently if you like.

Update Time – Added this option to increase the interval that the game updates, rather than just waiting for the sequence to end.

Kill Notes – Its working now. If you activate this option only one note at a time will play from the sequencer. Not effective in ORIGINAL mode.

Various and sundry additions – A few more modes added to the scale option, triplets added to the timing sections.

Several months ago I started working on a series of classes to make my life easier when programming for music. I’d started several projects and realized that trying to refer back and forth between MIDI Numbers and Notation by hand was tedious, so I created a library of functions to do it all for me.

I finally got around to formalizing this into one library, and released it here. I’ve put this into action already with the Game Of Life Sequencer Bank and HarmonicTable projects, and its really made it easy to pull scales, chords, drum maps, you name it quickly from a preset library

If this kind of thing is useful for anyone other than me, feel free to use it