Creating Mencoder gui for Linux in PyGTK.

[kinematic]

As some of you might have read I offered to help Sharktooth debug MeGUIx but to be honest I've changed my mind. Why? Well, because .net and mono really, really, really suck.......like a retarded hooker on crack. So I've decided that if I'm gonna do something like create a Mencoder gui for Linux I might as well do it in a language I'm really good at so I've decided to use PyGTK to create the frontend (this also has the benefit that's it's truly cross-platform). The only problem is that Mencoder only includes 4 built in noise reduction filters (dn3d, hqdn3d, temporal cleaner and overcomplete wavelet) so I'm thinking why not see if I can port some nr filters written for Avisynth. I'm thinking of porting at least 5 filters to give people some choice. So now I'm here to ask you, the doom9 crowd to give me some input on wich 5 filters should absolutely have to be included.

[Ranguvar]

*requests avs2yuv support with previewing* :)

[kinematic]

OMG!!! Somebody actually replied! I'll take it into considiration :) Right now I'm thinking about the design. It has to be functional, not hide any options from the user and be a bit pleasing on the eye.

[fbgd]

You're planning on porting some avisynth filters to mencoder? Or did I misinterpret?

[kinematic]

No, not porting them to mencoder (altho it should be possible......I think). Making them accessable thru the gui and piping the output to mencoder. Kinda like avidemux but more advanced. Mind you at this point it's all conceptual, it takes a lot of time to get to a finished application.

[Rasi]

creating a linux megui? :)

[buzzqw]

something like Avanti application ? (ffmpeg + avisynth)

i will stay with linux tools in first istance: mencoder, mplayer, ffmpeg AND x264

for filters:
hqdn3d is a great filter, need just to be tuned, but can be enough for start
pay attention to varius deinterlacer/ivtc/speedup filters..

just build sothing that allow user the right degree of flexibility:
encoding with mencoder (xvid/x264/lavc/mpeg4...)
pipe to x264 OR build a lossless file to pipe to x264

one more hint (and don't want to mess or spam) check application like automen or autoff (my apps) or Avanti or WinFF, you can grab some ideas

best regards

BHH

[Ranguvar]

I was actually planning on making a GUI already, in Qt4 - QtEnc ("Cute Enc") :p

Probably better to help with this one, though. but alas, I am a Python n00b (C too...). So, I shall learn at all possible speed :) If I can become useful soon, I'll try to help. Linux really needs a good AviSynth GUI like AvsP. Other features too.

Thanks!

[colyte]

You might wanna have a look at the work already done in OGMRip for example.

Shitty UI, no offence to the coder. But I believe the backbones are rather good.

Just a tip! :)

[Selur]

I'm writing on a crossplattform QT&C++ based gui for mencoder, ffmpeg, x264 (and mediaInfo, mplayer, mkvmerge, tsmuxer, mp4box, avsInfo and hopefully neroaacenc, when I figure out a way to change the channelorder when piping form ffmpeg to neroaac) for some time now (it's a hobby project ;)) and it seems to be working. Took some screenshots and uploaded them over at: http://www.mediahump.com/image/133252/
Could provide sourcecode for linux users and help compiling it if someone wants to test it; could also provide a .deb package for the gui. For Windows I got a .zip with all the files needed (<20MB).
It sure got not as much options and can't do nearly as much as megui, but it's nice, probably got some bugs and is still under developement, so there's always hope for new features :).
If someone is interested drop me a pm.

Cu Selur

Ps.: Wanted to do a public alpha release once I figured out how to handle neroaacenc anyways. ;)
PPs.: won't support avisynth as input under linux until there's a stabil native running avisynth version for linux.

[buzzqw]

@Selur

i will glady test it (on debian sid 64bit)!

BHH

[kinematic]

Look at the all the coders coming out of the woodwork :eek:
Maybe it's best if we combine forces since we all seem to have good ideas?

@ Selur:
I'd also like to test your gui on Debian testing so if you would upload a .deb I'd be gratefull :)

[Ranguvar]

Selur, to me, that's the number one thing missing from Linux encoding. Users of Linux tend not to need a GUI that holds their hand - for that, there's HandBrake, and several others I believe I have seen in some repositories. The main thing missing is what kinematic seems to be proposing - a GUI that exposes all options of tools like mencoder, ffmpeg, x264, etc., but just enables an already experienced user to speedily perform batch encodes with tools like profile support.

But the biggest feature that I feel needs inclusion is AviSynth. Waiting for a native AviSynth would be all well and good - except for the fact that AviSynth 3 is being developed at an extremely slow rate, there is little interest in it from devs (sadly), and it will break compatibility with AVS 2.5 filters, which means it may still be preferable to use AviSynth 2.5x with avs2yuv.

Here are some of the things I am most looking forward to having in a Linux GUI:

1.) Advanced "job" batches - for example, one could create a "job" that took in an MPG file, indexed it with DGIndex (I believe it works in Wine as well) , created an AviSynth script (obviously, one would need to be able to provide variables to the AviSynth script from the GUI, like input filename), encode that AVS with pre-defined settings or even ones auto-dependent on the source (perhaps auto-dependent features for the AviSynth too?), muxed it, and copied the output. Again, the purpose is not to make encoding user-friendly, it is to provide fast encoding set-up for those already intimately familiar with the shell.

2.) AviSynth script preview and tabs, a la AvsP. Except, hopefully, more stable :p Since AvsP is also in Python, you should take a look at it, kinematic :) The full feature set of AvsP (IDE-style error-checking and name completion) is not necessary, but I'd love to see the "Video Information" function, a quick button to play the script with a defined app, the tab-preview system, and the ability to run the mouse over pixels in the preview image and see the RGB values.

3.) A CLI interface! Now you're thinking, what? A CLI interface to a GUI? Yes :p The reason for this would be the advanced jobs support - it would be nice to simply run a pre-made job from the shell.


That's all I can think of, right now at least :p

Oh, and as for porting filters? FFT3DFilter/FFT3DGPU, NNEDI/MCBob, DeHalo_alpha, DeRainbow, LSF, LDF, msmooth, aWarpSharp, and...

I'd better stop now, I've already listed too many :p

[Selur]

@Ranguvar: I too miss most of the mentioned features under Linux, thought about it quite a while did see that I do not have the time to read as much as that would require and definitely do not have the time to design and code such a system on my family&job-free time unless I get a big win at the lottery. Also I really do not like wine. :)
@buzzqw&kinematic: currently hunting a bug, but will send a .deb package and some general instructions tomorrow. (64bit build for buzzq and 32bit build for kinematic) If I don't get to it tomorrow remind me with a pm. :)

[Ranguvar]

@Ranguvar: I too miss most of the mentioned features under Linux, thought about it quite a while did see that I do not have the time to read as much as that would require and definitely do not have the time to design and code such a system on my family&job-free time unless I get a big win at the lottery. Also I really do not like wine. :)

You don't have to do it all yourself ;) Hooray for F/LOSS! And as for Wine, IMO it's the lesser of the evils... AviSynth is so many leagues beyond anything else, it's not even funny. Better AviSynth support for Linux would convert a LOT of the users on Doom9 to Linux, I think. I myself only wishfully experimented with Linux, lamenting how Windows-central AviSynth was, until I just couldn't put up with Windows anymore and switched, first to Arch, and now Gentoo. The 64-bit speed boost to x264 is a big plus, too (Yes, there is a boost, ~10%).

Besides, I already need Wine for some games I can't part myself from, and I think many Linux users will echo that feeling...

But anyways, worst case, how about just letting others add in said support ;) Seems rather a waste to have two projects so similar go on separate - it's counter-productive.

[kinematic]

I don't have any real experience with Avisynth so I don't know how complex it is in terms of the way it's written but maybe it's worth investigating the possibility of a complete re-write in another language so it can run native on Linux.......maybe in c++/QT ?

(why oh why did the original Avisynth devs pick .net? If I had written it I would've made sure it's truly cross-platform)

[nm]

AviSynth 2.x is written in C/C++ and it can be compiled with various MS VC versions. It does not use the .NET framework. The reason why AviSynth is tightly bound to the Windows platform is that it is built around the Video for Windows (VFW) multimedia framework. Porting VFW to Linux is not really a good idea either because it is outdated and there are already better systems around. If you want to help, take a look at AviSynth 3.0 (http://avisynth.org/mediawiki/AviSynth_v3), which is an attempt to write a platform-independent frameserver (the Linux port uses GStreamer).

[DrEaMeR86]

I think that use wine + avs2yuv is the best idea..

[kinematic]

I stand corrected.

Edit: Does anybody know why developement on Avisynth v3 is completely dead from what I gather.

[Ranguvar]

I agree that AviSynth 3 is long-term the best solution, but for now, all we need to do is tell the user to have Wine installed and do avs2yuv (http://akuvian.org/src/avisynth/avs2yuv/) :) We can even modify it if needed, of course. Going avs2yuv also has another benefit - it lets one use 64-bit x264, even though AviSynth is (usually) 32-bit :)

[kinematic]

AvsP is exactly the kind of thing I was thinking about doing.....just goes to show good ideas have already been thought of :p

There's also a general consensus that Avisynth thru wine is the way to go and altho I'm a purist who doesn't like any Windows apps to contaminate his Linux installation I'm beginning to see this is indeed probably the way to go since there are no alternatives to it.

So the basic idea is to create a gui that exposes all mencoder options for various codecs and makes Avisynth filters accessable thru an AvsP like filter section in the gui connecting the whole thing with avs2yuv. That shouldn't be too hard to do :p

Edit: I know where I went wrong, MeGui needs .net. I was confusing things.

[Ranguvar]

Sounds like a plan :D

I will try to learn Python in time to be of use, but I can definitely beta-test and help in any other way you can think of.

Let's make this happen!

[Selur]

Is there a howTo somewhere how to get Avisynth (+Plugins) and avs2yuv (<- is it really needed? Under Windows mencoder&ffmpeg can take avisynth input just fine, though I'm not sure if they just use the vfw interface) running ?

Got no Python experience at all but will also test it once it's there for testing.

Cu Selur

[Ranguvar]

Yeah, avs2yuv is necessary under Linux.

avs2yuv guide: http://akuvian.org/src/avisynth/avs2yuv/

AviSynth: http://avisynth.org/

[kinematic]

The first thing we've got to do is decide wich language to use. I'm very fond of Python but it needs to be a language everybody who wants to contribute can handle. Python, Perl, c/c++...it doesn't matter to me.

[dotBL0t]

I'm using avs2yuv for my encodings under linux but, as far as i've experienced, the problem in using it to preview the changes to the avs script is that it doesn't allow to seek so, imho, it cannot be used as a full featured backend for preview. I think that the best way could be to use avsproxy and find a way to connect to it just as avidemux does, so no more seeking problem this way. If you manage to use python why not use wxWindows instead of PyGTK? The program will run on Windows/Mac with a native GUI this way.

[Ranguvar]

GTK works fine in Windows/Mac? So does Qt, for that matter (as evidenced by the new VLC).

And avs2yuv does have seeking. Run it with no parameters, and you'll get the options. It's quite functional as a backend, and worst case we can simply add what we need :) However, avsproxy is interesting to say the least. After just a quick look (http://avidemux.org/admWiki/index.php?title=Avsproxy), it appears very optimal for what we're trying to do, whereas avs2yuv seems better for direct usage in truth.

As for language, I am learning C, C++, and Python. But, I would rather have a C/C++ implementation over Python. Perhaps it's just an inbred fear of that type of language, after being force-fed Java in my CS classes, dealing with AvsP's instability, and the sluggishness of Gentoo's Portage as compared to the C++ Paludis. Plus, avsproxy is C++, correct? Would using C++ make it easier to utilize? Pardon my n00bish-ness :)

[dotBL0t]

GTK works fine in Windows/Mac? So does Qt, for that matter (as evidenced by the new VLC).

And avs2yuv does have seeking. Run it with no parameters, and you'll get the options. It's quite functional as a backend, and worst case we can simply add what we need :) However, avsproxy is interesting to say the least. After just a quick look (http://avidemux.org/admWiki/index.php?title=Avsproxy), it appears very optimal for what we're trying to do, whereas avs2yuv seems better for direct usage in truth.

As for language, I am learning C, C++, and Python. But, I would rather have a C/C++ implementation over Python. Perhaps it's just an inbred fear of that type of language, after being force-fed Java in my CS classes, dealing with AvsP's instability, and the sluggishness of Gentoo's Portage as compared to the C++ Paludis. Plus, avsproxy is C++, correct? Would using C++ make it easier to utilize? Pardon my n00bish-ness :)

I know that gtk works fine on windows but just as qt apps (like vlc) it uses its own widgets (the open dialog will be the standard gtk one and not the windows one, just as an example).
wxWidgets applications look and feel native. This is because wxWidgets uses the platform's own native controls rather than emulating them. It's also extensive, free, open-source, and mature. Why not give it a try, like many others have?
As far as seeking in avs2yuv, the seek parameter is limited to start piping output from a specific frame. When the piping is started you cannot seek backward or forward.

[Ranguvar]

As far as seeking in avs2yuv, the seek parameter is limited to start piping output from a specific frame. When the piping is started you cannot seek backward or forward.

No, as in, just have avs2yuv pipe a single frame, which can be done simply. But wait... would that be inefficient? Would AviSynth lose info from previous frames, thereby slowing temporal filters immensely? Damn...

Looks like avsproxy for sure :) Someone give LoRd_MuldeR a poke to this thread? Gotta go.

[kinematic]

Do we really want this thing to run on Windows/Mac? I kinda like the idea of it being a Linux only app. If anyone at some stage wants to add Win/Mac suport go right ahead but i won't :p

[stanjr]

Screw Windows. They have enough stuff already!

[kinematic]

Couldn't have said it better myself!

[Ranguvar]

IMO Windows support does not matter (and I hate Mac, but w/e... anyways, since Mac and Linux are both based on Unix, this project will probably be already 99% Mac compatible without even trying, as many Linux apps are, so if someone wants to submit a quick patch). Winblows users already have AvsP, MeGUI, Ripbot264, etc. etc. etc...

We should still try to avoid single-platform code, though, within reason :) It's just good practice.

[dotBL0t]

Would AviSynth lose info from previous frames, thereby slowing temporal filters immensely? Damn...
Not only this. If you use avs2yuv and you need to show 2 frames you have to:

Start avs2yuv
Ask it to give you the frame you need
Stop avs2yuv
Start it again
Ask it the other frame

This way you can get one frame every, let's say, 10 seconds? :p

As far as Python, I think that, because of AvsP is written in Python, many lines of code could be borrowed from it (e.g. Syntax Highlighting...). So welcome Python!!! :devil:

[Ranguvar]

Would we need to create Python bindings for Avsproxy? Sorry, I'm not very experienced with this subject :)

[fbgd]

After taking a look at it, it looks like avsproxy uses winsock to send and receive data to and from avidemux. This is about all I can tell though as I am not a great programmer and certainly do not know anything about winsock :).

Also a question: Is the plan for all the filtering to be done by avisynth and the encoding to be done by mencoder?

[kinematic]

Yes, that's the plan.

And I think it's time to start thinking about how we want it to look, we need some sort of mockup but since I'm not great at designing somebody else will need to do that because we will want something nice looking.

[fbgd]

If all the filtering is going to be done by avisynth, why not use ffmpeg to do the encoding instead of mencoder? Using ffmpeg would allow you to make use of all the libavformat muxers which I don't think mencoder supports correctly.

[Henrikx]

We should still try to avoid single-platform code, though, within reason It's just good practice.

Please take a look at Gambas Basic (http://gambas.sourceforge.net/)
No prejudice, please :)

Example
Xt7-Player (http://www.kde-apps.org/content/show.php/Xt7-Player?content=86197) (Mplayer -GUI) is programmed with Gambas Basic.

[Ranguvar]

If all the filtering is going to be done by avisynth, why not use ffmpeg to do the encoding instead of mencoder? Using ffmpeg would allow you to make use of all the libavformat muxers which I don't think mencoder supports correctly.

I definitely think multiple encoders should be supported, if nothing but the most basic of support - letting you specify a different program to run instead of mencoder, even if there's no GUI to add/remove options. IMO this GUI should be fully adaptable to use any programs in any order. If people like using a certain app that there's no special features for (like graphical settings selection) then we add it. mencoder, ffmpeg, x264, the mkvtoolnix apps, mp4box, DG*, etc. are ones I'd like to see though, for a start :p Well, at first, all we need is probably mencoder and/or ffmpeg, and then add others, since those two can do more than one task.

[kinematic]

There's only one problem with what you propose Ranguvar, the coder ultimately decides what support he/she wants to add based on his/her needs. Personally the only thing I need support for is mencoder (and possibly ffmpeg) and since it seems I'm the only one with enough experience to code this thing (and nobody else has stepped up to commit themselves to this) I'm not adding support for the other things you mentioned (at least not at this point) because coding something like this with mencoder and Avisynth support and an AvsP like filter section is more than enough work as it is. If somebody with experience wants to adds support for what you mentioned they can go right ahead.

[dotBL0t]

I would like to help you, but I started to learn python not so long ago and I'm a self-made "coder", so I feel like I'm not well experienced to join your project right now.

[fbgd]

My only point with using ffmpeg instead of mencoder is that ffmpeg has support for encoding into a wider variety of containers than mencoder does while still providing all the same encoding options. Plus the preset system they are putting in right now for x264 might be helpful.

Also I might be able to contribute a small amount if it were coded in c or c++ but I do not know any python.

[kinematic]

It doesn't nessecarily have to be written in Python, I already said I can handle c/c++ just as well. If multiple people are gonna work on this it needs to be a language everybody is comfortable with.

So I'll ask again, who wants to commit themselves to this project and what's the language your comfortable with?

[buzzqw]

i found ffmpeg more useful for audio handling and quick video conversion.. while i use mencoder for more "structured" encoding

but it's a matter of taste :)

BHH


P.S don't discard PureBasic for programming. a very fast program language for gui developing (and it is portable to linux/win/mac)

[Ranguvar]

There's only one problem with what you propose Ranguvar, the coder ultimately decides what support he/she wants to add based on his/her needs. Personally the only thing I need support for is mencoder (and possibly ffmpeg) and since it seems I'm the only one with enough experience to code this thing (and nobody else has stepped up to commit themselves to this) I'm not adding support for the other things you mentioned (at least not at this point) because coding something like this with mencoder and Avisynth support and an AvsP like filter section is more than enough work as it is. If somebody with experience wants to adds support for what you mentioned they can go right ahead.

Okay, but could you still please add basic support for any other CLI app, like I talked about? Just an empty text box is all that is needed, at least at first :)

[Major_Kong]

Calm down guys, start small and build on that. Make a simple but somewhat complete gui for mencoder (for e.g., just including good support for cropping will make it a killer app in *nix), add profiles to it and you would already have a very good Mencoder gui (at least in the *nix world).
Concentrate on achieving the little things first.

[kinematic]

I'm not gonna concentrate on little things, that's not my style. If I do something, I do it big. It will take some more time but the end result will justify it. I can't give a time frame tho (hopefully an alpha release early next year) because I have some investigating to do on Avisynth and avs2yuv and making it work with the gui since I've never used either one. Writing just the gui itself is the easy part but figuring out how to connect the dots is gonna be the hard part.

Btw, mencoder already has good support for cropping.

[Major_Kong]

I'm not gonna concentrate on little things, that's not my style.

It's not a matter of style, it's a matter of implementation. There are a lot of programs that make big promises but in the end fail. And i think one of the reasons is that they try to do too much without covering the basics.
And i have to disagree with you, making a good gui is not that easy (at least for more elaborate programs).

Btw, mencoder already has good support for cropping.

You didn't understand what i meant. I meant something more than the built-in "cropdetect", like previewing a cropped frame of the movie, as you're changing the crop values. I'ts a very basic feature, that's rare in *nix.

[buzzqw]

@Major_Kong
. I meant something more than the built-in "cropdetect", like previewing a cropped frame of the movie, as you're changing the crop values. I'ts a very basic feature, that's rare in *nix.

ever tryed autoff ?

or (for windows but compilabe for linux also) http://www.64k.it/andres/data/d/DetecCrop02.exe , make sure you have also mplayer.exe in the same folder

BHH

[Major_Kong]

@Major_Kong


ever tryed autoff ?

or (for windows but compilabe for linux also) http://www.64k.it/andres/data/d/DetecCrop02.exe , make sure you have also mplayer.exe in the same folder

BHH

Yup. But the feature i'm talking about is more on the lines of this: click me (http://guide.zhentarim.net/5/b4.png)

Remember that the autocrop feature is not 100% reliable, and more often than not you have to tweak the values. And it's way more easier if you can actually see the preview as you're changing the values.

[buzzqw]

yea.. Yatta...

and yes.. not easy to implement in *nix environment..

BHH

[nm]

Calm down guys, start small and build on that. Make a simple but somewhat complete gui for mencoder (for e.g., just including good support for cropping will make it a killer app in *nix), add profiles to it and you would already have a very good Mencoder gui (at least in the *nix world).
Concentrate on achieving the little things first.
Although you have a point there, Handbrake now has an official GTK GUI and it does these simple things pretty well (including manual/auto cropping).

[kinematic]

It's not a matter of style, it's a matter of implementation. There are a lot of programs that make big promises but in the end fail. And i think one of the reasons is that they try to do too much without covering the basics.
And i have to disagree with you, making a good gui is not that easy (at least for more elaborate programs).



You didn't understand what i meant. I meant something more than the built-in "cropdetect", like previewing a cropped frame of the movie, as you're changing the crop values. I'ts a very basic feature, that's rare in *nix.

The difference here is that I used to be a Linux user frustrated with the lack of a good graphical encoding application until I discovered mencoder and the command line so I know from experience exactly what's lacking. Another big plus is that I can borrow some things from avidemux (such as a cropping filter wich behaves exactly like you describe) and some other nice filters wich are already ported from Avisynth.

So yes, the basics will be covered but I'm not gonna release some half assed program with a lot of stuff missing.

[Henrikx]

Linux user frustrated
I am always frustrated because GTK/Gnome,etc. Ugly.Total Ugly.

Fortunately more and more Applications change to Qt, or offer an Qt-Alternative.

VLC
Avidemux
In near Future Firefox (Nokia Build)
sx264 from Selur
Hanbrake has a super Qt GUI too.

[Ranguvar]

In near Future Firefox (Nokia Build)

Huh?


@kinematic: "Release early, release often." :) Half-assed is better than no-assed.

[Henrikx]

Huh? :)
http://arstechnica.com/news.ars/post/20080818-nokia-helps-port-firefox-to-qt.html
http://browser.garage.maemo.org/news/

[Major_Kong]

Although you have a point there, Handbrake now has an official GTK GUI and it does these simple things pretty well (including manual/auto cropping).

I said it was rare, not non-existent. Besides avidemux i can't remember a program that has it. (Handbrake doesn't count, the version with the feature is still in testing :D )

The difference here is that I used to be a Linux user frustrated with the lack of a good graphical encoding application until I discovered mencoder and the command line so I know from experience exactly what's lacking. Another big plus is that I can borrow some things from avidemux (such as a cropping filter wich behaves exactly like you describe) and some other nice filters wich are already ported from Avisynth.

So yes, the basics will be covered but I'm not gonna release some half assed program with a lot of stuff missing.

And i'm not suggesting you should release a half assed program. I was just talking about covering the basics first. From the rest of the thread you get the idea that some basic features were getting overlooked.
The ability to support avisynth (thru wine) is great, but not everything.

[kinematic]

Well, things are progressing nicely. Last week I had a short vacation and was able to write a lot of code and I will hopefully be able to release a very early alpha at the end of December or early January.

[Major_Kong]

Are there sreenshots of the gui avaliable ? :thanks:

[kinematic]

No, not yet. @ the moment I'm working on some wine/avisynth stuff aimed at better integration/optimization. But what I can tell you is that I will be releasing it under the GPLv3 so once I've released it anybody can do with it what they want or it can develope into one big project.

[Major_Kong]

Forks are not quite a good idea... But anyway, thanks for the reply

PS: Are you using glade to help with the gui ?

[wg]

If you could develop something like the quality of AVStoDVD, but for Linux, that would be a great innovation. DeVeDe is a nice application but it only offers single pass encoding.

Good luck.

[Major_Kong]

Any update avaliable ?

[kinematic]

It's not a verry happy update but an update none the less. Someone broke into our home when were on vacation in December and stole our PC and USB backup hdd amongst other things so everything is lost (we recieved our new PC just this week) and 2 weeks ago I was hit by a car so as you can imagine the last thing on my mind is writing an Linux mencoder frontend.

[Major_Kong]

Ouch...

I wish you better luck in the future.

[Ranguvar]

That really, really sucks :(

I hope you're doing alright, and that you'll get compensation for what was stolen. Best wishes.

[kinematic]

I'm doing much better now Ranguvar and I'm already writing new code but it's gonna take a lot of time since I have to start all over again but I do want to create this program so it will be available eventually.

[kinematic]

Here's an update. I've been real busy with work and other stuff but I did manage to find the time to write the application. I'll be releasing the first alpha on sunday (a few things left to finish). As I said previously it will be released under the GPL so everyone is free to contribute.