Hi,
This is my logbook for the creation of MidiChat. I reported almost every day I've worked on it. Hope you enjoy it.
Niels Gorisse
20 March Saturday
First day. Started programming in Java on the Distributed Sound Lab. Just making a start, see how things work out. Figured out how to make a frame that would be runnable from an applet as well as stand-alone. Filled in all threads like I think they will be.
21 March Sunday
Created the CGI script that would do it all. It went well. Only one day to make the complete CGI script is not too bad, especially when the language is not completely yours (Perl). However, the security still lacks a little bit right now.
22 March Monday
Made some final decisions about the software structure, like which things have to be a thread, and which not. Figured out that I only need four CGI calls in a complete conversation. The whole conversation should be done directly without any server. Should be possible, although I've never seen such a system before.
Renamed it to MidiChat.
25 March Thursday
I've got the chatting to work. Virtually placed in the channels (they don't work), and the name dialog.
26 March Friday
Did the final proposal on school (Utrecht School of the Arts, faculty Art, Music & Technology, School of Music) and a little demo, during the chatmeeting we had with the school in Germany. Went OK. I chatted with someone in America with it! Great! The system works!
27 March Saterday
Changed the CGI script a little bit. Now login and get-the-users are the same, which makes the number of necessary calls only three (or two with channelnames caching). Also put the security to the max (as far as I can get). Finished one of the three (Perl, Java, C++) languages.
29 March Monday
I started to add the userlist. The chatting on friday was great, but I couldn't see who was in the channel. Also cross-channel connections are still possible. Todo: fix the updating of the userlist....
31 March Wednesday
Finally! The detection of zombie users in the list works great now, so the userlist is done. I've put many hours in this one! I don't have to ping at all while conversating! When a connection dies, the user is just removed from the channel.
Also cross-channel connections are impossible, because I introduced some sort of identification.
On this great day, I've added a few standard IRC commands (/HELP, /JOIN, /BYE, /NICK) too. If you rename to another nickname, it is even displayed when a new user logs in.
31 March Wednesday, later
Run once, write many. I tried MidiChat on a Sun SPARC, and it didn't work. I don't know what went wrong, I'll figure it out later. I also didn't find a decent compiler etc. on the SPARC, maybe that's the reason. I just tested it with the commandline.
I tried to run in on a Macintosh too. At one mac, it runned perfectly, also the connection with the CGI online. Only when I wanted to connect to the PC (I started MidiChat on a PC besides it, and logged in on the same channel), it went wrong while they were conversating. Probably because of difference in the the endline-(\n). I didn't have the time to look some closer to it, but I will, before I launch version 1.0. On another mac, it didn't even make a startup, but I think something was wrong with the mac at the time. Too bad there can be so much little things wrong with a mac (especially with memory management) .
2 April Friday
This week, espacially yesterday, I 've chat a lot with Robert Marsanyi. He is the maker of "JavaMidi", and I got a few great things from him last year, when he visited us, here at the Utrecht School of the Arts. JavaMIDI makes it possible to send&receive MIDI to&from the native OS.
Finally, today I got his Javamidi to work, but I was disappointed that it didn't include any timestamp. This means I won't be able to use it for MidiChat, because timestamp is very important. Actually I counted on it, but it's my own stupid fault that I didn't check it out. Too bad...
I searched for another package which was able to do it. I found some on http://music.calarts.edu/~tre/JavaMusic.html. I concluded this:
There are several Java&Midi combinations available by the time of writing:
- JavaSound
No MIDI input at the currently beta 0.8. However, the specifications are interesting. Future.
- JavaMIDI
Great, for PC and Mac, but no timestamp available. In JRI, J/Direct or OMS. Free source.
This is what Distributed Sound Lab can become. Implemented on IRIX only (no PC or MAC). Free source.
"MidiShare is a real-time multi-tasking MIDI operating system specially devised for the development of musical applications. Its innovative features and careful design, provide developers with a powerful and efficient toolbox for developing MIDI applications."
Source code for Lisp and java is included. But, they say on their homepage that it is not stable yet. However, it all looks surprising.Complete with sequencer and midi file writer/reader, etc. etc. etc. etc.
PC Only, including synchronizing, realtime output scheduling and midi file read/write. Small. Free source. If I don't get it to work, I'll use this one.
A few of them are very big projects, like Distributed Sound Lab has to become, like JavaMIDIkit, or MidiShare. Other smaller ones have no port to the PC, or are too big too. Because I didn't take my java books to here (at my parents) too, I decided to write it myself. Maybe I'll decide not to later this week, but we'll see how far I'll get. Today I'm preparing my classes for a JNI-port...
While finishing my C++MIDI source, I noticed that sysex has no timestamp on it, standard in windows. Because I don't use a special multimediacounter on the midi input, I'll just leave sysex out in the first version.
3 april Saturday
I worked on the class MidiChatPlan today, but not very long (two hours). I did mange to play a few notes, and after the defined delay, they were played again perfectly. So my approach works. I reused some classes I made last year (the midi in&out classes), and the multithreading class I made at the sensorproject in januari. Long live object-oriented programming!
I am planning to implement the last IRC commands for MidiChat tomorrow, and that will be a 'status' for every user. This means: /AWAY ..., /IGNORE ..., /MIDION, /MIDIOFF and /WHOIS. At /WHOIS, information like away/midion/midioff/ignore/delay and ip-address will then be displayed.
5 april Monday
Worked on these things. Nothing spectaculary. However, finished the C++ things. Did it with a smart scheduling: I just use a big array (so no time is spent on sorting). Found out that timing in windows lacks very much (have to do a recalculation of the time after each eventplayback).
9 april Friday
Worked on it whole week, each day a little bit. Some extra's like the /ERONGI (what a work!!), the first-letter-insertion-sort on the userslist, etc. I've given the program to a few friends. One of them is a real IRC-er, so I hoped he could give me some good advise (and he did). These are the things that came out:
- He couldn't use my /COMMANDS. They were all uppercased programmed. I fixed it by just making the first word after '/' uppercase (thanks to built-in methods in java that was programmed in 4 minuts, of course).
- closing an ServerSocket is not possible. This is really a bug in Java, bug nr. 4107121. The program crashed very hard because of this. Was not nice, because it didn't under Windows NT. I've already got a 'work-around' (using the words of Sun), but that one will only work in Java 1.1 Doesn't matter that much, because the Java-C++ things will be programmed in JNI (JavaNativeInterface) which is a 1.1++ thing.
- when you typed a long sentence, the text didn't wrap but was displayed on one line. Made a simple solution to that (I will make a better one in the future).
- the vertical other scroll bar didn't work. Tried preferredSize() everything, didn't hear if it worked yet. I remember I had the same problem on the mac. TextArea's should display scrollbars automatically, like the documentation said.
- The logging in took too long (that was my own complain). Especially when talking with someone in America this week, the logging in took too long. So I made the logging in multitasking. So you can talk to everybody you're already connected to, while it's connecting to the others. An artifact is, that it creates a twilight-zone, in which something you type is just not heared by everyone, determined by the speed of the connection. However, it will never take that long.
- Bug: when you are logging into a channel and someone logs into you too at the same moment. Should be possible (it is programmed that way, just like the multithreaded login), but it crashed....the only bug I found until now! Couldn't find a synchronized-error.
Almost forgot. I redesigned the login-conversation, so you can switch from a server. It is possible now have a few MidiChat servers around the world for example!!
There's only ONE thing to do now: make the link between Java and C++ with JNI...
10 April Saturday
However, I didn't wanted to download 20MB here at home, so I decided to get it up working next week somewhere.....
11 April Sunday
I can't believe it. I just got JNI to work, with the SDK from Microsoft. It was my own fault..... Anyway, it works. I've got homework todo, so maybe later this day I can try some midi things...
14 April Wednesday
Tested it on a Sun Sparc again. Worked perfectly, on 2 provided virtual machines which were present at the machine. Tried it on a mac too, but it didn't work, probably because of something that went wrong at the mac only (somewhere in the identification-dialog between client&server). Anyway, the system works platformindependently (and NOT because of an inline ('\n') problem).
16 April Friday
I've been busy all week, but I didn't report anything yet. Well, I managed JNI completely. I can now send and receive midi, start&stop the things, and get the names of which midi ports are there in the system (play around with Strings). For the receiving of midi, I had to make a seperate thread in java and a circular buffer in C++, because I couldn't make C++ call to Java (actually I did, but it didn't work; probably you can only call back to java in a function which is called out of java).
I was thinking of using 16-bit DLL's to get more accurate timing. I would used the source from the book 'Maximum Midi' by Paul Messick. But I decided not to. That is because:
- the midi in things in his book are all based upon a window on the screen. Of course I can make a invisable window, but than the path is too long: midi in -> interrupt ->16-bit DLL -> invisable window -> 32 bit dll -> invisable window -> in circular buffer -> java catches up the thing. It is a shame he wrote it to use it with a visable window only. Yeah, it is also possible with MFC in his book, but that's more sluggish than everything else.
- I can't use the midi out things. Well, I can of course, but it would mean I could only start sync-ing (which is needed because otherwise it doesn't look to the timestamp!) after I added all events. And I just don't know when the events have arrived...!
Too bad...
Anyway, I hope to finish the midi things this weekend, which leaves the setting of the current MidiChat-timing which every useronline knows in the java application (it is already taken care of in the midi classes).
17 April Saturday
I managed to make a version which received notes that were played, and sended these notes out back again, THROUGH MIDICHAT. I've put it online immediately too. There are still some problems, but I answered most of my 'how do I take care of that??' questions, like where (in which language and in which thread) to cache things.
18 April Sunday
I worked hard on it today. I never saw Java crash, until I started working with JNI. That is each time I ask something which is too much to ask (for example, start a thread in java, make it execute a c++ function, which catches up MIDI events and sends it back to java, WHERE it is put in a queue in c++ for playback), and I do that a lot. I didn't made my classes to support the MIDI-thru test, which is what I tended to test with (using MidiChat in between). So, I need a few computers to work on from now on, which means not working at home.....
18 April Sunday
I worked hard on it today. I never saw Java crash, until I started working with JNI. That is each time I ask something which is too much to ask (for example, start a thread in java, make it execute a c++ function, which catches up MIDI events and sends it back to java, WHERE it is put in a queue in c++ for playback), and I do that a lot. I didn't made my classes to support the MIDI-thru test, which is what I tended to test with (using MidiChat in between). So, I need a few computers to work on from now on, which means not working at home.....
8 May Saturday
Hi. For two weeks, I couldn't do anything because I didn't have two PC's with MIDI and internet at school. But since a week there are two of those, so I could start testing MidiChat. In these lost two weeks, I rewrote the JNI-bridge so that I can not only use MIDI fromout Java, but any other block I have ever written in C++.
I got MidiChat working this week last Wednesday. The last problem was that I use the an array of 16-bits (because Java works that way internally very fast with the build-in String) to store 2 8-bit values, but it didn't come to the other side with the same value. I justed used an other method to communicate, and it did work. So, MidiChat works now! Also the _Chat (the version I released without any MIDI) works on the Macintosh too (besides Sun&windows)!!
Yesterday Niels Bogaerts came to our school telling about KeyStroke. Afterwards we had an interesting discussion about the timing. I decided to implement an other way of timing in the next version.
Yesterday I also released MidiChat publicly on the music-dsp, javasound en csound mailinglists. I already got some reactions. One person was also working on something like MidiChat, and he asked weither you could also use MidiChat without internet. I'll add that functionality soon too.