Well, laziness finally prevailed and reaching all the way to the shelf in my cube to control the empeg became to much. So I wrote a little OS X menu item to control the empeg via hijack over http. This runs as a background app so it doesn't take any space in the dock and only uses space in the menubar if an empeg is on the network. If multiple empegs are on the network it (should) provide a control menu for each. It also shows the current track playing via a tool tip if you mouse over it.

It only provides a couple of functions (ones that I would actually use) at the moment, but I can add more if anybody actually uses it and wants something else. Read the included Readme file for installation instructions and requirements.

Screenshot 1...

Screenshot 2...

Download it at EmpMenuX if you are interested.

-Mike

Whoa.

Whoa? (Is that a good whoa or a bad whoa?)

I think that's bad ass, and i don't even run OSX. man... more and more reasons to "go back home" to macs every day..

Wow!

more and more reasons to "go back home" to macs every day

Anything I can do to convert another ;-)

Incidently there is a new version up with a few additional commands. I have also posted the source since a curious soul sent me a PM about it. Both are available from EmpMenuX.

-Mike

Thank you!

Thoroughly enjoying my switch to MacOS X. Interface Builder is really wonderful. Of course I can only compare this to the days when we had to code Windows resources by hand and the SDK came on floppies. <LOL>

Whoa? (Is that a good whoa or a bad whoa?)

It's my Keanu Reeves impression. No, it means I'm blown away. I like.

Version 0.3 is now up with one bugfix (the menu wasn't going away when the empeg was disconnected from the network) and one small enhancement (the empeg's screen displays a message when it is first discovered). That is probably it for a bit, I may try for some more interesting enhancements this weekend.

-Mike

For us Windoze users, we've been lucky enough to have the use of EmpegTray for a while now.
Glad to see that you mac boys now also no longer have to reach dangerously over to the empeg. Its a good way to get an injury.

Looks very slick too...

I have a question, slightly off topic, but mac related....

I have a powermac (700 Mhz G4 - silver tower) and I'm a windows programmer by day, i've not really used the mac in a while (OS X does look *really* nice) because I found OS-X to be too slow (Was running jaguar), I tried doing some devloping but codewarrior was very slow.... How do you guys do it? Are the newer versions of jaguar and OS-X any faster?

Thanks.

Adrian

How do you guys do it?

Well, I have three macs (two work, one personal) running Jaquar and the *fastest* of the three is a 350Mhz G4. They key is gobs of RAM and a little extra patience. I find Jag to be plenty fast enough for day to day work and the benefits of unix underneath with a usable GUI on top more than make up for the occasional slowness.

-Mike

Do you use the (supplied) gnu tools to create your little apps? I may have to have another play with my mac (mac os x was very nice) and try creating a little program... Just need to download some updates to jaguar....

Thanks

Adrian

Do you use the (supplied) gnu tools to create your little apps?

I use Apple's IDE (Project Builder) a lot. EmpMenuX is actually written in java (I am a java programmer by day and I think in java better than in ObjC) as a native Cocoa application. Because most of what I do is in java I don't touch gcc much except for compiling other peoples programs. I use a lot of the other gnu utilities for various things on a regular basis. It is trivial to create a small program with Cocoa (one of Apples programming APIs) using Project Builder and Interface Builder in either java or objective C. Most of EmpMenuX was done in about two hours and most of that time was me trying to find the right API to add stuff to the top menubar.

-Mike

OK, version 0.4 is now available with a variety of shinny new changes...

• Preferences dialog that allows you to disable commands you do not use.
• Ability to scroll current temperature for a U.S. zipcode on the empeg's screen.
• Ability to scroll stock quotes on the empeg's screen.
• Ability to scroll RSS feed headlines (Slashdot stories, etc) on the empeg's screen.
• Ability to control how often items are scrolled in the Preferences.
• Ability to control how often new empegs are looked for on the network in the Preferences.
• Generally rearranged the source to make it more sane to read/update.
  

If anybody using this wants the ability to scroll something else on the screen speak up and I will see if I can add it.

-Mike

just found this tool.
it is so cool!!!
now i need to get it going with my AirPort, any ideas why it doesn´t work???

it is so cool!!!
now i need to get it going with my AirPort, any ideas why it doesn´t work???

Thanks! It uses UDP broadcast to find your empeg(s) and assumes your broadcast address is 255.255.255.255 which it may not be if you have your network segmented in a funky way. Will jEmplode work over your AirPort? If so I will have to borrow a little more discovery code from it to properly determine the broadcast address.

-Mike

jEmplode's discovery isn't superb, either. If your IP address is a.b.c.d, it tries a.b.c.255, a.b.255.255, and a.255.255.255, and 255.255.255.255. That is, unless it's changed recently. While this may work for some folks, it doesn't for me, as one of my broadcast addresses is a.b.c.127.

Howdy! I'm not a Java coder, but I am a crusty old UDP & BSD kernel
code-whacker. To properly do UDP-based discovery in a BSD-based
networking stack (like OS X) , you need to send to the broadcast
address of each interface marked UP and BROADCAST by the kernel.
This will allow the kernel code to get the broadcast to each interface.
Sending to All-Ones Broadcast on a Berkeley-based network stack only
gets the message out the first discovered interface (by the Host Reqs RFC,
it's an stack implimentation decision what to do - pick one vs. flood to each
interface.)

I looked at the JEmplode source (20b13) and thought it was going to try to
do the Right Thing with it's interfaceToBroadcastAddress hashtable
(in org/jempeg/empeg/ protocol/NetworkEmpegDiscoverer.java) However,
on closer inspection, it's faking out b'cast net addresses by 1) assuming
8-bit subnet masks from all of the IP addresses it can get from Java. To
make matters worse, it gets the addresses from java by calling
InetAddress.getAllByName(), which (by looking at the J2SE v1.4.2 sources),
is returning the list of IP addresses associated with the HOSTNAME in
the various name services (i.e., host tables, DNS, etc).

Please don't take this as a knock of the JEmplode folks. I'm just trying to
explain what the JEmplode code is Really Doing vs. what it Needs To Do
for multiply-homed hosts. I have no idea how to get the real interface
info up into Java (heck, I don't even know how to create JAR files :-)

For some reason, I can't download the source for your app right now, so I
can't tell if you cloned that part of the code. I don't *think* you did, as I'm
having the same problem with my TiBook and airport card and the above
hack should work for my situation but I can't discover the Empeg with your
app. Is there any way to get to your Preferences settings with no Empeg
discovered?

The reason all the above sounds a little hand-wavy is my Mac's at home so
I can't test it right now. I'm at work avoiding working on multi-OS build
environments and distorting NMAKE into performing some unnatural acts...

Hope this helps,
K^2

I have no idea how to get the real interface info up into Java

Apparently, you can't. It's BugID 4691932. (Here's a real hacky class.)

Supposedly, the Java VM will transparently translate 255.255.255.255 into a real broadcast address, but which one it picks is beyond me. In reality, I don't see this being any different than what the OS is going to do on it's own, so that may have just been speculation based on empirical evidence.

Apparently, you can't. It's BugID 4691932

Yeah, that looks vaguely familiar I think I read that before at some point. I can't seem to load the linked hacky class for some reason. Since I am already platform specific (Cocoa UI) I suppose I could use a system call and grab the broadcasts from ifconfig output or some such. That is hacky too though.

-Mike

I can't tell if you cloned that part of the code. I don't *think* you did

Nope, I just coded for the simplest case scenario (255.255.255.255) which worked for me. I figured I wouldn't bother finding the right way unless somebody actually used the program and had a problem. I guess that time is now.

Is there any way to get to your Preferences settings with no Empeg
discovered?

Nope, but they wouldn't do you any good anyway as I have no preferences for how discovery is done and I would prefer not to. I wanted to keep this as simple and user friendly as possible.

-Mike

OK, can those of you having discovery problems please try the latest version (0.5) from my site. This version uses ifconfig output to find interface addresses and broadcast addresses. So it should work properly with multiple interfaces and funky broadcast addresses.

The updated discovery code and a new Icon (courtesy of BaBa) are the only changes in this version so if the previous version worked for you then you can skip this one.

-Mike

OK, can those of you having discovery problems please try the latest version

DId anybody get a chance to try this? I am curious if that solved all the problems.

-Mike

"Will jEmplode work over your AirPort?"

yes it works!!!

sorry, just tried EmpMenuX over AirPort and it works perfect!!!

coooooool stuff i love ut


thanx

DId anybody get a chance to try this? I am curious if that solved all the problems.

I use airport to connect to the internet, and an ethernet cable to connect directly to the empeg. I let OS X and the empeg just auto-assign their own private IP addresses on ethernet when they both determine there's no dhcp server on that ethernet network.

With this setup, the previous version would not detect my empeg, even though jemplode would (sometimes, at least). I could down the airport interface and then it would work just fine.

With the new version, EmpMenuX detects the empeg 100% reliably.

With the new version, EmpMenuX detects the empeg 100% reliably.

Cool. Glad it is working for you guys.

-Mike

now all we need is for some nice person to pack this code into Jemplode! It's getting to be a bit of a pain to have to kill my (Airport) internet connection, turn on my empeg and start Jemplode and then restart my internet connection after Jemplode has found the empeg so that I can do a software update.

now all we need is for some nice person to pack this code into Jemplode

The problem with that is the method I used is platform dependent (it relies on the unix ifconfig command) so it wouldn't work for those poor suckers running windows