Music is my backrub

Hmm yes well it seems we’re embarking on a little adventure here. Sounds like a good plan to me, I need a kick in the pants to actually learn Cocoa and learn it well. I do like it, lots, don’t get me wrong. It’s just a lack of practice on my part. But I’m excited to fix that. Our ideas are still a little fuzzy right now, but here’s how I see a few things.

First of all, (and maybe this is just me being stubborn. It almost surely is) I don’t want to use SQL for my app. Since I’m on Mac OS X (Leopard, rawr), I have lots of yummy CoreThings. One such is CoreData (which I’m pretty sure is sql somewhere deep down but it’s hidden from me) which I will use for maintaining files and so on. And then I’ve got CoreAudio. Those are probably the two most important parts.

So instead of using mySql I’ll be using CoreData, and my idea is that instead of doing some sort of wangodango mirroring, there’s simply to be an interface. That is, my application will know all of my music, in some form of objects or whatnot, and it will know Cody’s too (this will all be represented the same, really). The song object will basically have all the metadata needed (title, artist, genre, etc) and also location of where it can be found on disk. If it’s local, no problem. If remote, well then I’ve got to fetch it however Cody and I decide to do it. I say the simpler the better, but that’s not important right now.

But Cody needs to know about my music too, so he can know what I’ve got and where to find it, so my idea is to have an interface that basically says “Hey you, I’ve added a new song->details” And then he will get that data and add implement it however he chooses. Same goes for when he adds a song, he sends me a message and I add it to my collection.

Now, once that is all settled there’s the matter of playing the files. I’ll come right out and say it: I like iTunes, I’m pretty happy with it and I don’t want to ditch it, so I won’t. I’m going to keep using iTunes to play all of my local music. But when it comes to playing remote music, I’ll use our little app (*new feature* If I’m listening to a remote file and I like it enough, have an option to copy it locally and add it to iTunes**) to play it. So basically, I look at music from Cody, and I say “hey I want that song” so I get it, transfer it over, and then play it right in my app. I can do this pretty easily because Mac OS X have Quicktime built in pretty deep. So it’s trivial to play just about any file (maybe not Ogg or FLAC, but who needs that? I don’t).

I think I’ll build up an interface here maybe tonight just to see what it may look like.

EDIT

Okay here’s the UI I’ve made, it’s basically got everything I need. I can select a different machine from the dropdown list and control that machine remotely.

What do you think?

More Detailed Information

Well, our music collaboration software is moving along, at least theoretically. I’ve decided how I want my end to work in the backend:

• xine will be used as the playback engine
• My intra-process messaging queue will be used internally, with the ability to route messages to the outside
• The solution of file transfer is still up in the air, I’m not sure whether to try and hack together an existing standard, or come up with a simple standard.
• Extra care will have to be taken due to endianness.
• MySQL will be used as the linux database backend.

Xine looks like the best solution available. Far better, at least, then the helix engine and gstreamer. I’m unsure about the status of xine on Mac, but I’ll have to look at that. Perhaps a plugin approach would be best, and have available a CoreAudio plugin.

Time will only tell.

Please Don’t Stop the Music

Ok, so corny title. So while planning out the future apartment Jason and I are going to share this January in Ottawa, I was curious how we’d play music. There’s a couple ways to do this. We’ll have 3 computers, each with their own seperate library.

1. Dump all the files together in one location. Requires lots of space, and moving around.
2. Set up iTunes on each computer, and use that. Still requires somebody to get up to change the song.
3. Come up with another solution.

If you know me, you know which decision I went for. I’m deciding to write an app that’ll run on all 3 computers, providing files from each computer to it’s peers, and allowing each computer to play music.

Here’s the catch though: I want to be able to remotely control each computer’s speakers and playlist. I want to say, start playing some music on the big rig, and control it from different computers. I also want to be able to listen to any song on the network on my computer, and Jason to be able to do the same using another computer. Currently, I don’t know of such a “distributed music system”, but if you know of one, hook me up.

Oh, I run linux, and Jason’s 2 computers run OSX (I think one’s PPC, and the other’s an Intel).

SecuriLogin Client – For Linux

Ok, ok, so SecuriLogin Client for Windows wasn’t that secure, but it had the right idea.

How it worked is that it was “supposed” to authenticate user programs on the insertion of existence of a device that matched a USB serial number. This, in concept, could be a USB thumbdrive. I in fact, used code similar to that to implement a screen login utility that prevented family from using my computer. It was, however, easy to get around.

One of the added features, which I toted with me to school, was the application of a desktop wallpaper. When I ran the client program, the insertion of my USB key would trigger the wallpaper to change. Authentication, in fact, could be used as an encrypted module that the key is the USB key. That, however, is not compatible with multiple keys. It would be inefficient to store a separate module for each key. The module could not be stored on the key, as that has distribution problems. The module cannot be stored on the network, for offline use. Perhaps the solution is to encrypt a key on the device, or locally, that contains the key for the module. The module could be encrypted, say with key ‘asdf’. The local computer could have a descriptor file, one encrypted key per line. An authentication algorithm could in fact then read a line, and try to decrypt it. If the first 4 letters, are say OKAY, the rest of the data is the encryption key to the module.

It’s important to understand the concept of module. In my example, a module is some executable file or code. It could be a script, a program, an executable, or anything. It’s a neat concept, but I think it will just stay like that, a concept.

That being said, I think I’ll see if I can tinker around and see what I can come up with in Linux.

Attempting to Catch Wall Messages

I tried to do a little bit of coding tonight trying to catch terminal wall messages. I wasn’t very sucessfull.

I did, however come across this guys blog talking about doing somewhat of the same thing. He’s been unable to catch wall messages as well.

ZDLSharp and Mono

I was able to compile the nightly build of the Mono 2.0 beta the other day, and actually get ZDLSharp running in Linux! There are also a slew of new bugs found in both the Mono version and the Windows version. I’m hoping to make a change to the release schedule and actually release 3.0.5.3 this weekend, and then start work on 3.0.6.0. I feel the bugs are severe enough I need to make a bug fix release. I invite all Linux users to try out ZDLSharp in Mono. I have a precompiled and packaged tar of mono for extraction to your home directory.

Also, thanks to Siggi who helped me find all kinds of bugs, and making ZDLSharp even better!

And finally, I’ve attached a screenshot of ZDLSharp running on my Ubuntu Gutsy Gibbon.