My OS X Programming Blog

Added two functions for handling patch names to TOE. Banks takes a destination argument and a channel argument and returns the patch banks available for that channel on that destination device, taking into account the latter’s current mode and current name set for that channel. Patches takes three arguments: a destination, a channel, and a bank. It returns an array of the patch names in that bank, taking into account overriding MIDI name documents specified in the name configuration property associated with that device. The following interaction should explain what these new functions do.

~/Documents/TOE/TOE/build/chicken/Debug$ csi -q
#;1> (load-library 'TOE "TOE.dylib")
#t
#;2> (Initialize)
#;3> (define d (make <Destination> "JD-990"))
#;4> (Banks d 1)
#("Internal" "Preset A")
#;5> (Banks d 10)
#("Rhythms Kits" "Rhythms Kits 2")
#;6> (pp (Patches d 1 "Internal"))
#("Deep SEAmphony"
  "Fourdimensional"
  "Ac.Piano 1"
  "Nasty Man Bass"
  "DistSynChorus"
  "Hybrid Strings"
  "Slow Sync Lead"
  "Fantasia 990"
  "Vectoring 1"
  "Genesises"
  "Digital Rhodes"
  "Analog Brass 1"
  "Throaty Clav"
  "Belstring"
  "Delicate Lead"
  [...]
  "Mellowtron Str")
#;7> (Patches d 10 "Rhythms Kits 2")
#("Drum Set INT")
#;8> (Patches d 10 "Internal")
Error: uncaught exception: (3 "Bank is not in name set for channel of destination device")
#;8> ^D
~/Documents/TOE/TOE/build/chicken/Debug$ 

So here’s a snapshot of my current TOE Xcode project. It does everything I’ve described previously. Some of the names have been shortened and changed. If you read the file TOE.i, you should get a good idea of how to use it.

Before any other function calls you should call Initialize.

For a list of device descriptions of a certain type, call Devices with argument kDeviceTypeSources, kDeviceTypeDestinations, or kDeviceTypePairs.

Open a Sysex device using the Sysex constructor, passing to it the device’s device description or display name. The methods Send, NumOfBytesSent, CancelSend, Receive, and NumOfBytesReceived can then be called on the Sysex object.

Open a destination device using the Destination constructor, passing to it the device’s device description or display name. The method Send can then be called on that Destination object to send MIDI packets to that destination.

SWIG has been updated to version 1.3.27. Chicken has been updated to version 2.2.

The license for TOE is the “four-clause” BSD license, as I’ve discussed.

I welcome thoughtful comments on the design and implementation of TOE, which is of course ongoing. I’ll probably set up a forum for that after my winter vacation.

Unfortunately people are much too willing to write back only about free software/software licenses issues, (X)Emacs development politics, etc., which I’ve written about perhaps a total of ten times during my two years of writing this blog. I think they do that because such topics are so easy to have an opinion on. But you know I have yet to hear a truly independent opinion. So please, if you write, surprise me: write about good software design and programming. Post some good code or write up a good design and send me the link! That’s what this blog tries to do. Not the other stuffs.

Can you take just any software license, change the name and organization, and put it into your source code? Well, no, if the text of the license is itself is copyright and its terms do not allow you to do that. With the GPL, since FSF’s objective is for you to use it, they give everyone the permission to copy and distribute it. Of course they don’t allow you to modify it.

What about the text of the BSD license? According to a number of wiki pages (this one for example), it is considered to be in the public domain, because it was written before the Berne Convention was enacted in the United States. I couldn’t find any further explanation of this. However, some of its text has also been used in other licenses (the Apache License 1.1 and the OpenSSL License, for example) so reusing it appears to be OK.

Software licenses are really just a tool for achieving what you want with the software you write. It isn’t necessary to get emotional discussing them, as so many people do. But then people get emotional talking about text editors :-)! And no, free is not automatically better. I have always wondered how many people actually choose the GPL for their software for the reason RMS intends it to be used. And how many more have done it because it is cool, because it is anti-establishment, because of a sense of selfishness (people can’t profit from code they write), or because they haven’t really thought it through carefully, etc.

My present problem is the choice of a license for TOE, and licenses for software I’ll be building on it. I’ll deal with the former task here. To do that properly I must ask myself why I want to open source TOE in the first place. My two foremost reasons are: (1) my programs are very well-written and I want people to read them, and (2) I want to maximize the number of people who use it. Reason (1) is probably not a most common reason but it’s not unlike the need for others to read a good article that you’ve written, for instance. It’s also the biggest reason I’ve been writing and posting my programs and ports all along! I must admit that I’ve chosen (2) for both selfless and selfish reasons. I do want people to benefit from a better way to build MIDI applications on OS X. However I also want TOE to serve as “advertisement” for what I’ll build on it, some of which will be commercial software, such as version 2 of MyJazzBand. Other reasons that people have for opening source code might be software freedom, collaborations, code contributions and bug fixes. Quite honestly, none of these are very important to me. No, I don’t want to impose my views on you. And no, I don’t need your help :-).

There’re many software licenses from which one can choose. While objective (1) is satisfied as long as the source is open, a (more permissive) non-copyleft license will serve objective (2) better than a copyleft license. Fortunately this is also in line with my personal desire not to write any more GPL code.

The next step is to pick the one non-copyleft license. This choice can be based on the kind of restrictions on the distribution and use of the source code and binaries constructed from it. Most of these restrictions have to do with enforcement of proper attribution, prevention of misrepresentation, and compatibility issues, especially for modified versions. Past experience tells me if your software is any good, people will do anything and everything to claim it as their own. Therefore proper attribution is more important to me than any other restrictions. I will require authorship information of TOE to be included in both source and binary distributions. Further restrictions on routine naming and renaming, linking, etc. are overly restrictive, which also go against objective 2. The attribution clauses in the BSD licenses are sufficient for my purpose.

The last consideration is whether the license should be GPL-compatible. Isn’t it always nicer to be compatible with something? The answer is “no” in this case. The question can be phrased in a different way: do you want someone to take your work, modify it and turn it into a GPL program, thus making it less permissive? That’s really what GPL-compatibility means! Well, no, thank you. Happily there are many GPL-incompatible, free software licenses. One of them is the original BSD license. This then will be the license I use for TOE.

If you think that last part is slightly twisted, I agree :-). But think about objective 2 again. And again.

For another perspective on the process of picking a software license, read an article by Dan Bricklin (remember VisiCalc?).

I added a new type Destination to TOE today. Objects of this type correspond to destination endpoints in CoreMIDI. However it makes more sense to think of them as destination devices because of use of the device name resolution mechanism for obtaining them in TOE. So, we’ll have source devices, destination devices, sysex devices, etc.

SendData is a low-level function for sending MIDI packets to a destination. It will not be the main mechanism for playing MIDI sequences. That will be supported in TOE by a set of higher-level functions more akin to the MIDISequence and MIDIPlayer API in CoreMIDI. But in a pinch it can be used for sending program and control changes to a MIDI device! The Python interaction below shows how to change the volume of channel 0 to 100 and change the program of that channel to 127 on a JD-990.

~/Documents/TOE/TOE/build/python$ python
Python 2.3.5 (#1, Mar 20 2005, 20:38:20) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import TOE
>>> TOE.Initialize()
>>> d = TOE.Destination('JD-990')
>>> d.SendData('\xb0\x07\x64')
>>> d.SendData('\xc0\x7f')
>>> TOE.Terminate()
>>> ^D

Here is the Chicken version of that interaction:

~/Documents/TOE/TOE/build/chicken/Debug$ csi -q
#;1> (load-library 'TOE "TOE.dylib")
#t
#;2> (Initialize)
#;3> (define d (make <Destination> "JD-990"))
#;4> (use lolevel)
#;5> (SendData d (byte-vector #xb0 #x07 #x64))
#;6> (SendData d (byte-vector #xc0 #xf7))
#;7> (Terminate)
#;8> ^D

The nice thing about Chicken is that (unlike Python) it is a compiler so we can build executables from these small Scheme programs that call TOE. Sure will be a quick way to build little utility programs for controlling your MIDI devices by MIDI and sysex messages.