The devs seem keen to get a new stable release out that includes all current models. They can't do that without knowing what's working, and more importantly, what doesn't.
This is a thread for you to list what camera you are using, what features are working, and which ones aren't.
Options that aren't listed haven't yet been confirmed by users to be working.
Please do not make feature requests in this thread.
Canon 5D Mark III
Audio
Working
Not Working
Expo
Working
All white balance options
ML digital ISO
Not Working
Overlay
Working
Zebras
Spotmeter
Histogram
Waveform
Vectorscope
Not Working
Movie
Working
All image finetuning options
Not Working
Load H264.ini - See the bottom of this page http://www.magiclantern.fm/forum/index.php?topic=4124.25
Shoot
Working
Advanced bracket
Mirror lockup
Not Working
Focus
Working
DotTune AFMA
Not Working
Display
Working
Advanced settings - Screenlayout, UpsideDown mode, UniWB correct
Not Working
Prefs
Working
Not Working
Scripts
Working
Tried a couple of scripts and they're working fine
Not Working
Debug
Working
Screenshot
Not Working
Didn't realize there were so many options until I had to start typing them out :) I dare say the formatting of this post will change as more results are added.
Please feel free to list your camera and the options you have tried.
I like the idea. I'm testing the 4.20 build on a 600d at a shoot this weekend and will report back.
Preliminary testing: (stuff I use most and tested before the shoot)
MZ
WB & ISO shortcuts
3x zoom
cropmarks
all working as expected.
Some of my plans (just what came to my mind right now):
- PicoC will be replaced with TCC. For now, it's still there because it does the job.
- RAW discovery. I don't feel like polishing the old hacks for a stable release (e.g. current bulb ramping method, or UniWB), now that we have the real thing.
- Backend stuff: we are pretty close to the limit of how much RAM we can use (how many things we can cram inside). Module system (under development) will improve this. This can be for 2.5 if you ask me, but g3gg0 would like it earlier.
- I'd like a boot process that supports all cameras with a single download (like the unified 2.3 zip). The current approach does not scale to the new models (it requires a huge fat binary containing the code for all cameras). I'd like a small platform-independent bootloader, the camera-specific modules (ML core), and user modules (functions that are only loaded on demand; usually platform-independent code).
So at this point I don't feel we are ready for a feature freeze.
I'm even thinking to switch to the rolling release model (just nightly), as it seems to fit better a hobby project maintained in our spare time.
P.S. This shouldn't stop you from running these tests. Good bug reports are always welcome, and in most cases, the bugs are fixed very quickly - once we know how to reproduce them.
+1 on rolling release.
I know I don't contribute to the development but I am also for a rolling release. Maybe if something changes dramatically like the need to update files other than autoexec.bin. Like when the dir structure changed or when the boot process will change to use modules then change the version number to denote incompatibility with older builds.
That is how I discovered how great ML is, through the new builds in the google group. I didn't pay attention to the version number, and wasn't waiting for the next.
The big issue with rolling release is staying on top of the documentation. Menu structure has changed a few times since 2.3 it seems. Wish I had more time on my hands to update the user guide.
this might sound stupid, but what is a rolling release?
Btw, shot for 4 1/2 hrs today using the 4-20 build. Absolutely no problems at all. Very stable.
Edit: nevermind, looked up rolling release on Wikipedia.
Quote from: a1ex on April 20, 2013, 05:51:31 PM
- Backend stuff: we are pretty close to the limit of how much RAM we can use (how many things we can cram inside). Module system (under development) will improve this. This can be for 2.5 if you ask me, but g3gg0 would like it earlier.
we can use the free RscMgr RAM on models that have it. (60D, 7D)
others must wait until we e.g. load ML from a object file like a module or have some other method.
Can we pinch memory from used areas? Like reset start and end?
It's been 10 months since the last stable. Time flies. :)
I think it's important to get some new releases out to satisfy those who cannot build their own. Especially for the new ports that aren't included in the nightlies.
It's a difficult situation as this isn't just some piece of software that can just be uninstalled if it all goes south.
I've finally managed to build my own 5D3 releases. I'll stick my hand up to build releases of the new ports on say a weekly basis with their own dedicated release threads with a layout similar to this.
edit: I'll need forum permissions for the nightly section if you're happy for me to do this.
Building a nightly for unsupported cameras is actually quite easy (it's a matter of editing a script), so that's not really an issue. Before doing that I need permission from the port's developer though
Weekly builds probably make sense for those who don't like to be early adopters. Scenario: say we build the weekly on each Monday morning at 5 AM, early adopters can try it and post some feedback in the first half of the week, and if no major problems are found, the more conservative users can grab it for shooting in the weekend. But there isn't really any difference from just downloading only monday nightlies, so it's probably just a matter of taste.
We will need a separate zip for each new port, because these autoexec's are not cross-platform. We could squeeze everything inside, but the fat binary is getting a bit too big and may cause slow loading times.
Docs can be built automatically; they are only outdated. Here's some work in this direction: http://www.magiclantern.fm/forum/index.php?topic=3820
Maybe we can also revisit this:
http://www.magiclantern.fm/forum/index.php?topic=4318
http://nanomad.magiclantern.fm/feats.html
What about adding a thumbs up/down for each feature/camera pair in the feature table (each checkbox)? Example: a user clicks "thumbs up" for "zebra / 5D3", which means that feature works fine on his 5D3. Or, "thumbs down" on "bulb ramping / 50D", which means he had trouble with it. With this we can have some clue about what things are widely used, what things work well, what needs more attention and so on. For more detailed feedback, we can just add a link to the forum.
Download counters should be also helpful.
I also have some experiments which can analyze the code changes and identify which features were affected by code changes. E.g. if one edits the cropmarks code (inside #ifdef FEATURE_CROPMARKS), the "cropmarks" feature can be highlighted somehow in the automatic change log, so users can expect something different when using them.
The weekly-monthly builds back on google groups were good, as you say, it was easy to wait and keep an eye on the post for a few days to read the feedback.
7-zip reduces the 5D3 binary from 413,536 bytes to 171,993 bytes and the current nightly zip from 2,784,803 bytes to 1,360,937 bytes.
The thumbs up/down is a good idea as long as the spam from trolls/accidents (wrong button or whatever) don't affect the results and create more work.
An email update when changes are made to a specific build would be pretty cool. Sounds like a lot of work though.
I think we can adopt a release system similar to Cyanogenmod:
Quote
NIGHTLY BUILDS
Are HIGHLY experimental. Do not post issues to the issue tracker. Chances are the CM team already knows about the issue and are working to fix it. Be patient flash the next nightly. Complaning about battery life or any number of issues will not change a thing as to that these are EXPERIMENTAL builds!!!
M-Series
Something we have learned over the past few months is that if you don't release, someone else will do it for you. Since we are open-source, we absolutely encourage it! Unfortunately, the quality of unofficial builds can vary, and we are serious about quality. Of course nightlies are always available, but we realized that having something that is a bit more stable on a more frequent basis is important. Starting now, we are rolling out our M-Series releases. M-Series builds will be done at the beginning of every month. We did a soft freeze of the codebase for the last week, blocking new features in order to stabilize. Our plan is to continue this (assuming that the response is good) up until stable release, and onward.
We aren't exactly sure what M stands for. "Monthly", "milestone", or perhaps "MINE ALL MINE!". Whatever it is, I hope that we are meeting the needs of community.
M-Series builds will be available under the EXPERIMENTAL tag. The filename will include the date stamp as well as the M version. These builds should be stable enough for daily use, and we encourage feedback and bug reports.
RELEASE CANDIDATE
Everything is believed to be working at the time of release.
Milestone Builds are a good idea. That way they have a "stable' build for the month/week and a nightly for those who can't wait on a new feature.
Weekly would be ok, but here's the problem . . . updates will probably also take longer and feature sets will also have longer wait times.
I think we should have both, a weekly stable, and a bleeding edge nightly - I like living on the edge. That way, people can have more frequent feature sets, and those who would like to test can get the nightlies.
The point is, we cannot guarantee a weekly stable build (or at least I can't). That's why I was proposing to create a "testers" team that picks a build, tests it properly on multiple bodies and properly reports back any issues found. This way devs can very quickly fix the bug (if they already didn't). Once the "testers" think that the build is polished enough we can tag it as "Milestone" for a broader audience to test it. In the meanwhile we'll keep publishing nightly builds as we always did.
I did something similar with the 650D and it worked out pretty well given my limited time.
I would be willing to be a tester ... sign me up.
For me as a tester, i would welcome a more structured way for testing an feedback. A thumps up/down method, with the ability to provide additional info and ore links would be very nice. I now find myself struggling in providing good feedback ( and that includes what does work, what doesn't work, and what i have not tested) in a readable setup.
Additional if a new build is available it would be nice to have an overview of what has changed. This would enable me to focus on stuff that was changed, and not the whole thing. This would also enable the developers to asks the testers to focus on a particular item.
This is the first time I am participating in a project as this, but the method used now with Nanomad works really well for me.
I would welcome a testers build!
A weekly update would be nice, and even if there are no changes, at least we would now that the bugs present are not jet fixed and we can focus on finding new bugs.
I always keep an eye on the change log page to see what's new. http://nanomad.magiclantern.fm/nightly/ChangeLog.txt
Does it look like the rolling release idea is going to take off?
I've been doing it the whole time for 600D/6D and I guess M now. 6D kinda took the front seat but its evening out.
Quote from: Francis on April 20, 2013, 09:23:02 PM
The big issue with rolling release is staying on top of the documentation.
Agree, reluctantly.
As an overwhelmed-by-the-wonderful-vastness newbie of ML, I'm finding the 2.3 documentation to be less and less useful. When I first started using ML 2.3 not that long ago, I was impressed by the documentation. Now it is getting more frustrating. It can be Very Disconcerting for a newbie to try to figure out something, and have the doc's conflict with "ground truth" on the camera LCD.
Also, I'm really eager to try nightly builds for Auto-Dot-Tune and RAW-histograms, but reluctant to expose my camera to what I perceive to be a risky, trial-and-error, potentially costly pre-alpha nightly build.
Perhaps there could be something like a "skin" that exposes less capabilities to beginners (what is documented in stable release?), more to intermediates, more to advanced, and everything to developers?
I recall from my days of active FOSS participation, that there is a real tendency for devs to lose track of how intimidating the learning curve can be. With something like the Audacity audio editor, at least there was very low risk of damaging your computer with a hang. My perception is that even an experienced ML user has a very real chance to brick their DSLR with a nightly build.
Yet, if ML really wants to be have wide acceptance, it needs to retain some level of user friendliness and making newbies feel somewhat welcome. The reality can be that feedback from newbies can be as, or more, valuable than from experts. Unless ML is ok with being increasingly "experts only"? I don't think ML is likely to ever be for beginning photographers, but there are a LOT more intermediates than experts/pros.
It does bring up the question: what assumptions about the experience/expertise level does ML want to make of its "audience"? So far? In the future?
Well I find the UI quite user friendly after the last set of changes, and if you don't know what a feature does you can either
- ignore it
- read the documentation if available
- Google it
- ask on the forum
Had feature shock at first too but then I got over it... there was feature shock from 400D -> 600D. Everything new has a learning curve.
Quote from: l_d_allan on April 26, 2013, 08:00:16 PM
It does bring up the question: what assumptions about the experience/expertise level does ML want to make of its "audience"? So far? In the future?
Well lets asume you deep enough into photography to:
- spend 600+ euro on equipment.
- feel like the hardware could do a better job
- have the guts to download and install ML lantern on your expensive hardware.
Then i would also asume you would be willing to spend the time to figure things out on your own/documentation/forum.
I think the documentation we get with ML are already far superior to what we get from canon ( as there is no real in camera documentation).
I haven't had any issues with lack of documentation, even with the newer features of the nightlys. Read and understand the current 2.3 documentation so you have a basic understanding of how ML is layed out and works (understanding what controls do what), then apply it to the newer features.
If all else fails, ask on the forums. Wealth of information available here, and I've found the developers are more than willing to help.
Quote from: dslrrookie on April 26, 2013, 01:39:20 AM
Does it look like the rolling release idea is going to take off?
Perhaps a "Weekly Build" that could be expected to get "extra attention" compared to a "Nightly Build"? It would be understood to be less than an "Alpha".
So far, I've been impressed by the stability of the two "Nightly Builds" I've used on my 5dm2 and T3i. Still, my concern is that a "Nightly Build" can be not much more than "compiled semi-cleanly with an acceptable number of warnings from the compiler".
My perception is that one of the great strengths of ML is that the developers are passionate about what they are working on, and, perhaps even more important ... "eat their own dog-food". I'd feel more confident about trying out features if there was a sense that something like a "Weekly Build" had been served to several of the "developer dog's" with acceptable taste ... no developer's camera was poisoned / bricked.
Not totally OT, so will ask here:
What about using HG Flow in the source? From what I get it can help somehow to have a bit of more clear repo with master, releases, hotfixes, new features and development branches, no?
I'd like to revisit this.
Quote from: scrax on May 13, 2013, 10:15:37 PM
What about using HG Flow in the source? From what I get it can help somehow to have a bit of more clear repo with master, releases, hotfixes, new features and development branches, no?
This sounds like a great idea. We could pick a nightly build to become the new stable, branch it off so it makes it easier to backport specific fixes.
I need to learn the HG system better.
hg flow looks interesting...
hg flow and then pick a nightly sounds ok to me. But lets first off wait 'till mlv is done - that's what most people are waiting for. I actually liked the procedure in which the 2.3 was released. First let the supporters have a go for a month, then a well produced trailer and to finish it: call it version 3. IMO too many things have changed since 2.3 to call it 2.4.
Quote from: SDX on August 27, 2013, 01:26:31 PM
I actually liked the procedure in which the 2.3 was released. First let the supporters have a go for a month, then a well produced trailer and to finish it:
Agree.
Quotecall it version 3. IMO too many things have changed since 2.3 to call it 2.4.
Very much agree. The 2.3 documentation is almost too "stale" to be useful. There have been absolutely amazing improvements since 2.3.
I'm more of a "casual user" of ML ... perhaps install a latest/greatest "nightly build" every other week or so. I'm regularly baffled by what is new, and how to get it to work. Amazing features show up in the Menu, but it's unclear to me what they do, and what is "best practice".
Also, what might be risky to explore? That troubles me, and makes me reluctant to stray from what I feel I understand, or to help with testing.
Sorry for the whining. I am a HUGE FAN of ML. I try to look at the "change log", and the "Feature Requests", but I'm still often fuzzy on the "best practices".
Quote from: l_d_allan on May 13, 2013, 09:54:34 AM
Perhaps a "Weekly Build" that could be expected to get "extra attention" compared to a "Nightly Build"? It would be understood to be less than an "Alpha".
Perhaps ML could have some "division" on Builds that focused on Bug fixes, and another for New Features.
Perhaps once a week (Sat?), there might be a "New Features Build", and other releases would be "Bug Fixes".
In such a scenario, I think I would be inclined to download and install the Friday Bug Fix build, figuring that it would tend to be the most stable. Let the "early adapters" and "pioneers on the bleeding edge with arrows in their back" wrestle with the latest/greatest, but least tested.
It's not that the Devs would only work on new features once a week, but that they would defer making them visible until Saturday.
However, I'd mention that the "rolling release" model does seem to be working reasonably well. New features are showing up at an astonishing rate, and stability has been more than acceptable.
Quote from: l_d_allan on December 16, 2013, 03:36:02 PM
Perhaps once a week (Sat?), there might be a "New Features Build", and other releases would be "Bug Fixes".
Imho the time period is way too short... though I like the direction.
As I mentioned earlier and like to repeat here, the Linux model sounds good to me and is proven to work - an expectable "merge window" for new features followed by a period of bugfixing until all new features work ok enough to call it a "release", then repeat. For the Linux kernel this period usually comes down to two months, for ML it might be longer or shorter depending how "stable" the new features merged prove to be.
I am new to ML and have not looked at the code, however I would think a good direction would be to move all of the camera firmware code to class. Then have a standard class for the menu. The menu functions would call wrapper functions that would call the camera specific functions.
When one of the developers starts to work on a new camera, (s)he would first start with determining the firmware verification test function. Once established the system would boot with pass or fail and if failure then prompt to continue or not.
At that point the developer would start on each function. For example dual ISO. So the menu class function for dual ISO might look like this:
function menu_iso_dual()
{
try
{
camera_iso_dual();
}
catch(err)
{
Msg("this function is not available");
};
};
It has been too many years since C++ so example is in C# but the basics are there.
With the above structure you could quickly release versions for new cameras with functions as they come available. I would also add a function stability option too. Something like:
Alpha = red menu
Beta = blue menu
RC = green menu
Final = white menu letters.
That way people are aware of the progress on each menu item.
Quote from: Des219 on January 31, 2014, 04:40:07 AM
I am new to ML and have not looked at the code
Then you should not render judgements about the code, b/c you clearly have no idea what you are talking about.
Possibly you do not understand what I am saying. From the forum messages and my own experience as a software developer, my recommendation was to possibly help move the project forward to more end users in less time. I am quite impressed by the developers and what they have accomplished. Not so much by you and your comment.
Quote from: dmilligan on January 31, 2014, 01:13:58 PM
Then you should not render judgements about the code, b/c you clearly have no idea what you are talking about.
An idea would be to let the devs who aren't interested continue their work on the project, whilst another team sets out to create a stable version of ML as it is by now.
However, that would require that a few things that are in progress right now, to be finished (such as merging TL back, for 6D, M and 7D support).
On the other side: There will always be a new and exciting feature under development, so there is no point in waiting 'till everything is in a quite state (since it won't happen).
A new and stable version is, IMO, rather important for the health of the project.
Daily reader but not a dev, so just ignore me if you like.
In my opinion it is "time" for a new release. Been quite a while since 2.3
But the very big new feature that Raw is, doesn't feel quite ready yet.
MLV has only recently been conceived.
So personally I do not mind waiting many more months for a new release.
I know it is going to be awesome when we finally get it.
Quote from: Des219 on February 01, 2014, 12:49:38 AM
Possibly you do not understand what I am saying. From the forum messages and my own experience as a software developer, my recommendation was to possibly help move the project forward to more end users in less time. I am quite impressed by the developers and what they have accomplished. Not so much by you and your comment.
I understand exactly what you are saying. Why don't you have (https://bitbucket.org/hudson/magic-lantern/src/65572fa87394a2598ef4ee75c547b750d46c6963/src/boot-hack.c?at=unified) a look (https://bitbucket.org/hudson/magic-lantern/src/65572fa87394a2598ef4ee75c547b750d46c6963/src/gui.c?at=unified) at the code (https://bitbucket.org/hudson/magic-lantern/src/65572fa87394a2598ef4ee75c547b750d46c6963/src/vram.c?at=unified)? Maybe you'll see why using classes and try/catch blocks is not some simple solution to the problem (for starters, neither is available in C, which is what ML is written in).
Quote from: Des219 on February 01, 2014, 12:49:38 AM
I am quite impressed by the developers and what they have accomplished. Not so much by you and your comment.
Do you think I (https://bitbucket.org/hudson/magic-lantern/pull-request/358/dual-iso-support-for-1100d) don't (https://bitbucket.org/hudson/magic-lantern/pull-request/356/1100d-disable-flexinfo-autoexecbin-is-too) know (https://bitbucket.org/hudson/magic-lantern/pull-request/355/1100d-skip-offsets-for-photo-raw) what (https://bitbucket.org/hudson/magic-lantern/pull-request/336/1100d-fix-recording-macros) I'm (https://bitbucket.org/hudson/magic-lantern/pull-request/331/canceling-a-bulb-exposure-early-with-the) talking (https://bitbucket.org/hudson/magic-lantern/pull-request/328/start-the-intervalometer-on-camera-startup) about (https://bitbucket.org/hudson/magic-lantern/pull-request/327/fix-1808-conflict-between-bulb-timer-and)?
Quote from: Des219 on January 31, 2014, 04:40:07 AM
I am new to ML and have not looked at the code, however I would think a good direction would be to move all of the camera firmware code to class.
I for one think your ideas are just fantastic. Let us know when it's done. Thanks for joining the project!
Quote from: romainmenke on February 01, 2014, 02:21:05 AM
But the very big new feature that Raw is, doesn't feel quite ready yet.
MLV has only recently been conceived.
How so?
And by "recently" you mean since last July?
Quote from: dmilligan on February 01, 2014, 04:58:45 AM
Maybe you'll see why using classes and try/catch blocks is not some simple solution to the problem...
I looked at the links you provided. I thought I read that ML was written in C++, hence the classes recommendation. Structs are available and used in the project. As you know structs were a pre-form of classes. They were the basis of object oriented programming. From the provided example the project references menu.h. Again if menu.h were converted to wrapper functions it could work.
I do not remember saying that it would be a simple solution, just that it would help to advance the project. Also, I said the code example was C# and I was only demonstrating an example. I haven't programmed in C++ for 9 years or more and C for 12 years or more so I am rusty with it. I do know that it is possible to replicate my example in C, because I have done it. I am sure the devs could accomplish it if they wanted to and agreed with the direction.
When are you going to get started?
This is the development section guys, fight with code, not with quips.
Audionut, thanks.
Dmilligan, your second post was much more helpful than your first worthless comment. The GUI.c is interesting. I was surprised to see the supported list.
Here is a link to a try/catch option... http://en.wikipedia.org/wiki/Setjmp.h
It wasn't an open invitation to antagonize a respected member.
Quote from: Des219 on February 02, 2014, 04:56:10 PM
your first worthless comment.
we need support with programming, not with flaming.
so follow audionuts advise and stop that.
Quote from: Des219 on February 02, 2014, 05:28:36 AMI am sure the devs could accomplish it if they wanted to and agreed with the direction.
Here's the problem with this feature: nobody cares about it. Not even you do. You even seem to have the ability to help implement this, yet you have made no attempt to get it started yourself. You weren't even motivated enough by this idea
to look at the code.
Changes to ML don't simply manifest themselves out of nowhere. What you're doing is volunteering hours of someone else's time and energy for a feature in which neither they nor you have any significant interest. It's exactly like proposing some huge government program somebody else has to pay for because you uncritically
feel that it might be a good idea.
This is serious point: do you see why it is a problem to propose complicated features on a whim, with no thought as to the cost and benefits of it to the people who actually have to perform the work? Because this is why you have immediately drawn such ire.
engardeknave, while I respect that you have concern for the developers, ultimately, they are capable of deciding where they spend their development time.
I have a strong desire for keeping the development section in a manner suitable for development, and it is for this reason that I kindly suggest that members place serious thought into the manner in which they post in this thread (and other development threads) in the future.
about exceptions implemented using setjmp:
never ever. no setjmp/longjmp. http://www.abxsoft.com/misra/m122.html
its forbidden in serious guidelines for reason.
(although i dont really understand why we need exception handling. looks like an answer to a question that was never asked)
engardeknave, my whole reason for posting the suggestion was for the developers to save them time and energy in the long run. From reading the thread and a few others about Tragic Lantern vs Magic Lantern, it looks like there is currently a challenge with new camera models, new features, and getting them all into a single release. The typical question that is asked is when will the next stable release be available? This is frustrating for the developers and for the users. If it were feasible to release single features as they become stable that would be a huge benefit to the developers and the end users. Again, the developers are doing a great job and are devoting their personal time on a free project. I was proposing a possible solution to help for future releases.
Unfortunately I do not currently program in C or C++ so I am not comfortable altering code that I am not sure is stable for my $2000 camera. Also, I only have one camera so I would not be a good candidate for cross model programming. It also is very difficult for someone to jump in on the project without discussion with the main developers. Which is why I posted here.
g3gg0, I appreciate that a developer has looked at this. Thank you! I see that the try/catch option with setjmp was not a good one. This is good to know. Since I have your attention, my original post was suggesting to have the main features in a standard class that called wrapper functions to camera specific functions. The attempt of the try/catch would be to call functions and if they are not developed then display that this feature is not yet available. The logic was to implement features as they become stable. Would this be beneficial to you as a developer? Would you also see benefits for the end users?
the problems we currently have, are not related to any language based solutions.
even with C# or any other high level language we would have any advantage.
Quote from: a1ex on April 20, 2013, 05:51:31 PM
- Backend stuff: we are pretty close to the limit of how much RAM we can use (how many things we can cram inside). Module system (under development) will improve this. This can be for 2.5 if you ask me, but g3gg0 would like it earlier.
- I'd like a boot process that supports all cameras with a single download (like the unified 2.3 zip). The current approach does not scale to the new models (it requires a huge fat binary containing the code for all cameras). I'd like a small platform-independent bootloader, the camera-specific modules (ML core), and user modules (functions that are only loaded on demand; usually platform-independent code).
My solution was inline with the above.
Quote from: g3gg0 on February 02, 2014, 11:54:19 PM
the problems we currently have, are not related to any language based solutions.
even with C# or any other high level language we would have any advantage.
Totally agree that a higher level language would not be the solution even if it were possible.
One more thing... sorry if my suggestion insulted anyone's intelligence. I was only making a recommendation based on the perceived problems I had read. It wasn't that I thought the development team was unaware of the possibility of wrapper functions, it was just that they were not initially used and possibly were overlooked since the project had grown so quickly and successfully from the initial implementation. If anyone wants to discuss this with me I would be glad to assist in anyway that I can.