[jazzplusplus-devel] Change of direction?

[Dave F. <da...@da...>]

All,

Well, I'm sorry.  I showed up with a lot of energy, worked real hard, and then 
stopped, and it doesn't look like I'm going to be able to start again.  :(

Here's the problem:

Since Jazz++ is in C++, generally speaking a lot more consecutive time is 
required to implement something.  For a general redesign, even more time is 
required.  I don't have that time.  What I have is a lot of short bursts of 
time that I can spend programming if there's a reasonable expectation that 
I'll be able to complete at least one task.  This is shown in my other 
leisurely programming activities, actually.  :)  I'm not the greatest C++ 
programmer ever, so I need a lot more time to work with C++, time I don't 
have.  If Jazz were in another language (Python, specifically) it would be a 
different story.  But it's not.

I would have tried to push for a general change to Python awhile back if there 
were a library available that I knew of for reading/writing midi files, or if 
it was reasonably something that could be implemented quickly.  The GUI 
library (wxWidgets) is already well supported in Python, so reading/writing 
midi files and midi playback (and any custom widgets needed) are the only 
holdups to such a change.

Well, I found a program call 'mma' that generates midi accompaniment, and it's 
written in python.  Looks like they've got writing midi files down pretty 
well, it should be reasonable to use that code to write a midi file reader 
and go.  Playback is the only issue left, then.

As a stopgap, pygame or pyAudiere would both provide midi playback, at least 
until someone could throw python bindings around PortMidi.

So, here's how I figure it.  There's some good code in Jazz++.  A lot of it 
has to be thrown away in a language change like what I'm proposing.  There's 
some bad code in Jazz++ (or at least I've made no secret of my feelings on 
the matter).  IN C++ we have to keep working with it, around it, factoring it 
out, and reimplementing the stuff that uses it.  In a language change we can 
throw out all the bad code.  Some of the good code we get to take with us, 
like the beautiful pianowin class.  Throw some python bindings around it and 
use it as the start of our custom widget library and we can move on.  
Trackwin can be easily re-implemented just like it is in Python.  And we get 
to throw away the dependency on an old wxWidgets API, and in light of the 2.6 
release this is a Very Good Thing.

I figure the widgets we need can be written in Python to start, and then later 
on when we need higher performance out of them, we can re-implement them in 
C++.  That's the beautiful thing about Python.  :)

For distribution, I don't know of a LInux distribution that doesn't include 
Python by default, and then also doesn't include wxPython in its file 
repository.  Linux users are taken care of.  Mac OS X includes Python by 
default, and wxPython is rumored to be pretty stable there.  For Windows 
there's py2exe, which creates a self-standing executable for a python 
program.  (You can download my pyAlarm program to see how well it works if 
you'd like)  We'd have to bundle the dependencies with it, in that case, and 
that's fine.

If we were to switch to Python, I would be able to find more time to work on 
it.  That's my main personal benefit, but there are others.

Python applications are generally faster to develop.  This is very 
well-documented throughout the web so I won't go into detail, I can provide 
links if you'd like.

Python applications are cross-platform in general.  I can testify from 
personal experience that it's a lot simpler to write and maintain a python 
application across platforms than it is to do the same in C++.

Python is a simple enough language to learn that other developers interested, 
even if they don't know python, will be able to quickly take part in 
development.

The other issue is actually a plus, in a way.  I'm interested in dropping 
wxPython from my toolbox when Qt is GPL for all platforms (which is promised 
to happen pretty soon).  Then, when pyQt and pyKDE have updated, I intend to 
make that switch.  Being a KDE user and all, I'd really prefer to have my own 
programs run natively in my preferred environment.  So naturally I'd be 
looking to make a Qt interface that could (and should) exist alongside a 
wxGTK interface for those users who want one.  I don't know that I'll make it 
or be able to keep up to pace with a wxGTK interface if that's what the core 
uses, but it's not that big of a deal.  I'll be happy to keep wxPython around 
for this application if need be.

It's up to you guys.  I need to cut out completely from Jazz in C++.  I'd like 
to work on a midi sequencer anyway, but frankly there are enough in my 
environment that I"m not feeling any particular pain in that area.  I'd like 
to do one to "do it better" and make it more like what I want (for instance 
have it output mod files).  I'd like to work on a midi sequencer with this 
group, I like all of you and you're all very talented programmers.  I'm happy 
to have met each of you and I think I'm a better man for it.   If you guys 
are interested in moving to Python for core development here and all you'd 
need is a codebase to start from, I can throw together a prototype.  Luckily, 
in Jazz++ development we're at a point where what we have is just slightly 
more functional than a prototype, so the future of our work wouldn't be any 
different, other than the language used.

If you're not interested and you'd just as soon keep working on Jazz++ in C++, 
then I need to cut out.  I'll be happy to roll back my changes for you if any 
of you are blocked by me.

So what do you think?

Dave