This is one of those news items that’s fun to write, fun to read, fun to comment on, and where no one will be able to say anything unkind. It’s all just one big ball of awesome fluffiness. TuneTracker, the BeOS radio automation software, has just released something very special: TuneTracker System 5, the first version designed entirely and specifically for Haiku. In fact, it actually includes Haiku in the software package. Better yet, TuneTracker also unveiled several system-in-a-box products – which have Haiku and TuneTracker pre-installed.
So, what, exactly, is TuneTracker? It’s a radio automation software package, which is actually quite an apt descirption, surprisingly enough. “Our radio automation packages offer TuneTracker’s legendary automation stability, huge format flexibility, a powerful music selector, built-in Internet streaming, local, live-assist, and satellite capabilities, touch screens, and in Command Center, just about every imaginable automation feature including a remote administration option,” the product page explains.
The new version, System 5, has just been released – and for the first time, it’s released for Haiku. “While BeOS has always been, and continues to be, a rock-solid performer, Haiku is equally solid and dependable, and runs even faster on the same hardware,” the press release states, “Under Haiku, the TuneStacker music selector/program log generator can build an entire day’s program log, randomly selecting all the music, even with aggressive proximity protection, in a few seconds. Haiku has the added benefit of being open source and under active development by programmers around the world.”
This is a very big deal. Sure, TuneTracker is a professional softweare package for a very specific purpose, but it’s been designed from the ground up around BeOS’ strength, and because of this, it makes extensive use of features unique to BeOS, and now Haiku, such as its file system. Haiku’s performance, of course, runs circles around heavy modern operating systems, making it ideally suited for software like this.
Cooler yet, you can also buy systems with Haiku and TuneTracker pre-installed. Again, these are specialised machines with a specific purpose, but we’re still looking at hardware with Haiku pre-installed, and I have to say – I find that quite awesome. “It was clear to us that Haiku 4.1 and TuneTracker System were indeed a match made in heaven,” its developer, Dane Scott, writes, “There were no gotchas or compromises. Everything just worked. Everything just ran. It still gives me goosebumps to think about it. And fast? My gosh. There’s no launch time for anything. You double-click on it and it’s there, even TuneTracker itself.”
Awesome news, this.
Quite brave of them to rely on an alpha version.
Although the Haiku users among us know that stability is not an issue on the right hardware
Haiku needs a few more heroes like them to kick-start the spiral of success.
Given the area of application – managing a music collection and streaming its contents over the internet – it likely made more sense to leap with Haiku than port/re-code the underlying media management code to another operating system. After-all, wasn’t being media centric one of the strengths of BeOS?
If I remember correctly, they did the same when Zeta was around. If so, this indicates that the foundation defined in BeOS and being refined in Haiku is still relevant.
Really Awesome!
This is great news for Haiku!
This really is just one big ball of awesome fluffiness!
I always wondered what happened with Tune Tracker, I assumed it was ported to Windows or something, yet on their site their is no mention of any other platform. That must have been an interesting decade for them waiting for Haiku to become stable enough since BeOS hasn’t liked much hardware for a very long time.
Anyone know how big they are and what their market share is in the field?
They used Zeta for a while.
I read OSNews. Some things are beyond trolling. I have a couple of older SFF boxen I want to try installing Haiku on as potential media centre candidates. This makes that possibility more of a reality. Congratulations to all concerned.
Orf.
Nice to see TuneTracker still alive and kicking.
They were always huge supporters of BeOS, hosting downloads for drivers and other software… pretty cool. Remember BeShare?
I’m sorry, I can’t tell from your post whether you already know this or not but, for your information:
Users of BeShare, the file sharing application, are still totally active on Haiku.
That’s great too!
No, I have not been on BeShare in years. I might if I ever truly adopt Haiku…
Really? Last time I ran BeShare there were about 4 or 5 users, all away and one was atrus the bot. Which server are the hordes of BeShare users using now? It’s not Tycom or Neonplasma, that’s for sure.
How many hordes of users did I say were using BeShare?
I was only mentioning to Tuishimi, who may have thought that BeShare died with BeOS, is still being used by some people on Haiku. I don’t know how many people used to use BeShare, because I’ve only ever used it from Haiku.
This is just AWESOME.
I can’t stop grinning.
Maybe there is spin off for an in-car entertainment system. Or run XBMC or something custom on Haiku for lounge room media centres…
This is something I’ve been wanting to do with BeOS (and later Haiku) for many years now. The problem is, I’m a crappy programmer. I can build an interface in a visual IDE, and I can code simple scripts in scripting languages, but anything lower level than Python, Javascript, Tcl/Tk, PHP or Bash is beyond my abilities.
Hell, it took me three days to make a custom MP3 player in VisualBasic 6 back in college, that would have taken your average high schooler less than two hours. Granted, a solid day was wasted fine-tuning the custom graphical buttons and controls (I was all about skeuomorphism in 2001), but a true ICE interface with all the bells and whistles is far beyond my abilities.
Still, I would love to see one of the big car audio companies embrace Haiku the way the TuneTracker folks have. I think Haiku is the perfect platform for any multimedia-heavy project, and given its open source nature it is much easier from a licensing standpoint.
+1!!!
What I would like to see is something very much LIKE xbmc written for Haiku… For the following reasons I think it would be an excellent project for the community to work on:
1. Use file attributes to store all the metadata on the media (instead of having to use sqlite/mysql like xbmc does). It seems like a perfect fit for Haiku (probably the reason TuneTracker is still a BeOS app).
2. Use it as an excuse to focus more attention on Media Kit. Work has been done on it but its not close to optimal yet. My hope is to see Media Kit get good enough that a good full featured media center type application could be written using it (instead of having to implement everything internally like xbmc does).
3. Its not an easy task, but it isn’t that hard either. Im pretty familiar with XBMC (did some development on it here and there), and if Media Kit was doing all the playback work and the filesystem was doing all the metadata indexing, all you have left is doing a good UI, a scanner, and a plugin architecture. I doubt you would want to get as fancy as xbmc with the state of OpenGL on Haiku at the moment, but I think you could do something decent using webkit/blink to do the rendering.
4. Thread the hell out of the media scanner! XBMC is like 100X faster than it used to be when scanning items into the library, even still I have 350 lines or so of naive code (written in node.js no less) that can outperform it by a few orders of magnitude – and that is on Windows… It is the perfect problem to attack with Haiku’s exceptional threading, its all network latency bound.
5. It sounds like fun. Developers like fun projects
Edited 2013-05-09 03:26 UTC
I see the benefits in storing meta data in the file system, instead of a database, but I have a few doubts:
1) can you easily and *efficiently* do a query on metadata? e.g. SELECT AUTHOR, FILENAME FROM /home/user/mp3/ WHERE TITLE LIKE ‘%RED%’; ?
2) would that query result be cached by the file system cache or would you want to traverse the whole library? Would you need to write your own cache mechanism? Would you want to preserve the state of the cache between runs?
3) Do all copy methods ensure file attributes are preserved? I would think that cp works differently than a copy routine coded in an application and, say, something along sendfile(). That opens the risk of losing precious meta data.
Not to mention confining yourself to one file system.
Yes, but the query language is not SQL. Have a look at this article on Ars:
http://arstechnica.com/information-technology/2010/06/the-beos-file…
Yes, you can save queries. I used to have 4 or 5 queries saved to filter for specific file types or email status. They are known as “live queries” and Tracker displays them like a folder (as an example) when opened. AFAIR, one can do similar with the low level API. But because Attributes are indexed, running the query again is not as intensive as say, using the find file dialogue in Windows XP.
The meta data is preserved. The metadata is stored on an inode level. Read this book for more info:
http://www.nobius.org/~dbg/practical-file-system-design.pdf
Haiku only boots from one file system, so there’s no actual issue here really, is there?
Thanks for your answer. It sounds very nice!
As I donated some money to Haiku years ago, I feel I should have a decent look now!
Haiku uses it’s own BFS on a system drive, but it can write in several popular and not so popular file systems and read from almost anything.
I believe SkyOS toyed with the concept of XBMC.
Given that SkyOS used OpenBeFS as its base file system, maybe it could be possible to bring this over to Haiku – if ever the code for SkyOS becomes open sourced.
All we need now is GoBe Productive to come back. Maybe that long rumoured v3 BeOS port that was never released.
The “port” was to other OS, GoBe was a native BeOS app. 😉 If you look at the Windows version (if you can find a copy still) there’s a libbe.dll etc.
I think the demo version of GoBe Productive for Windows is still available either directly or via the Way Back Machine.
Hopefully, the current owner of the code sees this and start thinking of refreshing it for Haiku. Since it was ported to Windows via a libbe.dll, it should not be overly difficult to refresh it for Haiku.
The sad state of getting the source code for GoBe Productive on Haiku:
https://www.haiku-os.org/community/forum/gobe_productive_haiku#comme…
That was the last “official” information I heard. :'( But I still dream of GoBe Productive being released for Haiku.
GoBe basically recreated enough of the BeOS kits to get GoBe Productive to compile and run on Windows. Pretty crazy stuff really.
The Be Engineer, Pavel Cisler IIRC, that created Eddie did the same kind of thing for Linux using GTK+ V1. I used to have the source kicking around at one point.
I’m not sure I’d call it a “port” per-se – it was more like a fork, and from what I gathered, the newer GP3 code has lost a lot of it’s BeOS (thus Haiku) compatibility as a result.
It still had the base libs from the BeOS runtime implemented on the target platform. I remember looking at their export tables under Windows and wondering if they would work with my own code (never got round to trying though.)
Perhaps, but the initial attempts to “re-port” it back to Haiku were apparently pretty frustrating – just getting the build system to work on Haiku again seemed a large and difficult task.
TBH, I have old and crusty BeOS code and getting it to compile on Haiku is non trivial. Couple that with the fact the API is actually not exactly compatible, and that causes a big headache. (There used to be a way to remove focus from a BWindow even if it was selected, so the code I have used this to implement an input device that directed the input to the focused control on another BWindow, but Haiku breaks this. There’s a work around, but it doesn’t work in the exact same way and is ugly compared to the old way – your input BWindow just never gains focus and it looks wrong.)
Please log a bug for this and it will probably be fixed.
https://dev.haiku-os.org/
A few haiku developers were actually in talks of porting Gobe 3 to Haiku under NDA, because the owners would never opensource it. Couple years later it’s obvious that initiative went nowhere.
Any progress on getting latest Xorg to build on Haiku like Xming and XQuartz? I think this is an important milestone. For me it would allow me to have many more apps on Haiku.
Honestly, this would be wasted effort. BeOS and Haiku have their own native API. All OS that have done this compromise look and feel for functionality – both Cygwin and XQuartz are both seriously ugly. Plus, really, what apps? GTK+ and Qt apps would be better server by porting the underlying toolkits (and Qt already worked at one point, probably still does)… what other amazing X based apps that use the raw API are there? Everything else uses some kind of toolkit that might be ported also, surely?.
For local desktop applications I agree with your arguments, but what about X forwarding?
It is not uncommon to run some graphical application on a remote server. At work we have a big fat server so we can run IntelliJ remotely, since the project takes too long to compile on a laptop.
Having X-related stuff available isn’t that bad, frankly. For example Mac OS X runs X in a window like VM.
I can imagine users that absolutely need X-related stuff on their Haiku system, running X on a different Workspace in full-screen mode, switching between it and Haiku Desktop via ALT + Fx keys. I personally wouldn’t use it 99% of the time. I rather want fully polished port of Qt 5 and maybe a few other cross-platform frameworks running on Haiku.
Haiku project needs 3rd-party developers desperately, so if anyone is interested in porting X, Qt 5 or something else, feel free to do so and join the #Haiku Party.