My OS X Programming Blog
Mac OS X Cocoa and CoreMIDI Programming
About Andrew Choi


MIDI Programs

MIDI File Player (External Device)

MIDI Destination Pop-Up Button

MIDI File Player (Internal Synth)

MusicSequence Sample Code

MIDI File Writer

MIDI Name Document Parser

NameConfigSetup

Fish Creek MIDI Framework

MidnamUtility

SysExSenderX

Other Programs

FCBlogEditor

FCBlog and Patch

Chinese Checkers Program

jyut6 ping3 Cantonese Input Method

Cocoa Sample Programs

Syntax Coloring Using Flex

NSTextField and Undo

NSToolbar

Implementing File Import

Launch Application and Open URL

Saving Uncommitted Text Field Edits

Algorithms

Jazz Chord Analysis as Optimization

Optimal Line Breaking for Music

Optimal Chord Spacing

   

A blog where I will write mostly about programming in Cocoa and CoreMIDI, and experiences from my ports of Emacs and XEmacs to the Mac OS.

A Kagi ACG in C++
Friday November 5, 2004

It’s been an interesting day of work: I’ve translated Kagi’s reference ACG written in Perl into a functionally equivalent version in (ANSI) C++. Here’s my comment at the beginning of the file:

ACG_XXA_cppreference.cpp - translated into C++ from ACG_Package/Code_N_Scripts/Perl/ACG_XXA_reference.pl in Kagi's SDK. This CGI is an *exact* functional replacement for Kagi's original Perl script with the following exceptions: (1) a ACG:OemApprovalCode of "no" is returned instead of "yes" for an invalide ACG:UserPurchaseDate, and (2) the formatting of ACG:ResultCodeMessage is different (the leading ", " is removed) in checkForInputBufferUnderFlow and checkForInputBufferOverFlow. I believe both of these are bugs in the Perl script.
It passes all 109 tests in the “muster” test suite of the SDK, producing exactly the same output as the Perl script except as noted above.

This program is a translation of a Kagi script and not an original work. As such I do not claim its copyright. It’s just a few hundred lines of code, so let’s just leave it at that. If Kagi should see this and feel that I should not post it (although I can’t imagine why), I’ll gladly remove it :-).

I need an ACG written in C++ because I’ll be integrating my own active code generation algorithm into it, which will be written in C++. It’ll be much easier to send a single executable file to Kagi instead of a Perl script and the external routines it calls. Using C++ (instead of say Objective-C) also allows the ACG to be hosted on platforms other than Mac OS X. Writing the C++ version is also a good way to learn about the ACG specifications.

It’s also interesting to note that C++, when used suitably, is a great language for implementing CGI’s (and in fact any kind of scripts in general). Contrary to popular belief, C++ can be a very high-level language! My C++ version is therefore just as easy, if not easier, to read and uses about the same number of lines compared to the Perl version. If you don’t believe me, read the two versions side-by-side and see for yourself!

Implementing a CGI
Thursday November 4, 2004

I’ve looked at some of the C/C++ libraries for implementing CGI’s listed on the CGI Resource page. None of them is very useful. CGI-LIB and gDecoder are C (and not C++) libraries. GNU Cgicc did not build under OS X. It also doesn’t seem to be actively maintained. The most useful examples turned out to be some NCSA sample programs. Unfortunately these are written in C. I’ve converted the code post-query.c and util.c into C++. Here’s the result.

It’s also very easy to test CGI’s on OS X. Put your CGI’s in /Library/WebServer/CGI-Executables/ and your web pages in /Library/WebServer/Documents/. Then, turn on “Personal Web Sharing” in the Sharing panel in “System Preferences”. The web pages can then be accessed in http://localhost/ and the CGI’s in http://localhost/cgi-bin/. Here’s an HTML file that can be used to test the CGI I posted above.

Kagi
Wednesday November 3, 2004

Here’re some considerations that may go into using Kagi as one’s e-Commerce service provider.

  • Kagi has been around for a very long time.
  • People generally recommend them. A few developers on the mailing lists did have negative comments: their complaints were about response time to questions and order processing. These developers seem to be more happy with eSellerate.
  • Kagi’s set up procedure seems to be reasonably simple. Basically you set up web pages for your product and arrange how activation codes are generated and distributed for purchases. Then you sign a contract and you’re ready to go.
  • An important consideration for me is that Kagi can host on their machines an Activation Code Generator (ACG) that I’ve written. This way I can generate activation code using my own algorithm. Doing so will prevent one from being tied to a certain e-Commerce service provider’s “canned” activation code generation algorithm. It’s also more secure than an algorithm that everyone uses.
  • They also provide a Kagi Registration Module that can be embedded into Cocoa applications. When invoke, the KRM presents a GUI for the user to purchase the application without using a web browser. This seems to be of marginal usefulness though.

I’ve finished reading their ACG specifications and I’ll be thinking about writing one. Since an ACG is really just a CGI, I’m looking at libraries for writing CGI’s. Since my encryption code is in C, I’ll probably be writing my CGI in C or C++. Here’s a list of libraries for writing CGI’s in C/C++ I’m looking at.

E-Commerce Service Providers
Tuesday November 2, 2004

Spent most of the day reading documentation from e-Commerce service providers. People on the Cocoa programming mailing lists seem to recommend Kagi and eSellerate. So I’m mainly looking at them. I believe I now have to rethink my scheme for generating keys/registration codes since it must tie into the Kagi’s or eSellerate’s method of handling purchases. The simplest option seems to be to use registration code generation/verification algorithms they provide. But then I must trust how secure their scheme is. For a low-cost shareware (which mine will be) this probably doesn’t matter very much. And I can save a lot of effort in designing and implementing my own scheme. If I want to use my own registration code generation algorithm, the only (secure) option seems to be to run my own server to handle requests from the e-Commerce service provider. Only Kagi supports this method though.

Final Touches
Monday November 1, 2004

I worked on a number of small features/improvements to my program today: made the minimum bar widths proportional to the size of the font selected for chords and meter of the song, added a “New Document” command for creating 3/4-time untitled documents, and added two count-off bars to generated accompaniments and handled the visual feedback of the current bar during playback correctly. Here’s a screen shot showing some of these new additions.

And here’s a generated MIDI file with the count-off bars.

More importantly, the implementation of my automatic accompaniment generation program is essentially complete!! The only programming left is a software protection/registration scheme. I did some reading on this topic back in January. I’ll spend the next few weeks to work on this. Then I’ll be working on artwork, manual, tutorial, and promotional material.

October 2004
Sun Mon Tue Wed Thu Fri Sat
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

November 2004
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
Sep  Dec

xml

Search this blog with


Lists

Less-Known Facts About Emacs

Emacs Rants

Chinese Restaurants in Calgary

Calgary/Banff Tourist Attractions

C++ Reading List

Science Fiction Series

Top-10 Reason I Stopped Working on Emacs

Top-10 Types of Questions I Get About Emacs

10 Defining Moments as Programmer


Misc

Carbon XEmacs

Emacs for Mac OS X


Copyright © 2003, 2004, 2005 Andrew Choi (Contact Information). Created with FCBlog