I'm a complete newbie at this, just having received my my DCC system,
programmed 4 decoders, and having not yet actually used DecoderPro (just
started it up to play with it). However, I consider that the basic
programming (address, basic configuration) is reasonably easy to do
through the throttle and in theory should only have to be done once.
What I'm hoping to use DecoderPro for is Speed Tables (and probably BEMF
once I get some of the BEMF decoders installed). Given that speed
tables require multiple CVs to be set, and maybe a few times until they
are operating as desired, I would put the higher priority on getting
these features working reliably.
Making the GUI more bullet-proof is also a good goal - if the program
crashes on simple entry errors, people will likely be put off quickly.
Dennis
Bob Jacobsen wrote:
The 0.9.3 update is out, so after I catch my breath, it's time to
think about what to do next.
I'd like to get a "complete" DecoderPro version out by early July,
but I'm not certain what should be considered the most important
things to put in it. I've got a long list of little updates, fixes
and cleanups to include, and I'll probably get to most of them. Big
features are a little more problematic, as I don't often have the
large chunks of time they require.
I've already promised to add Lenz XpressNet support to JMRI and
DecoderPro, and C/MRI support to JMRI itself. So those will be
happening. I've got some other stuff I'm playing with on the
layout-control side of the house, and I'll probably keep doing that
too.
But beyond those, I'd like to see what people think are most
important. What would you most like to see?
Some of the items that have been suggested include:
a) Ops mode programming
b) Better programming GUI, for example making it possible to have
some variables control whether others display, etc. Break some parts
(roster pane, function mapping) into smaller parts so you could
create a programmer that walks you through one item at a time (e.g. a
"step 1" pane that handles the address, then a "step 2" pane that
saves the file, then a "step 3" pane that sets momentum, etc)
c) Much smarter speed-table support, with various tools for smoothing
curves, resetting the curve to a standard one, adjusting it to the
contents of Vstart/VMid/VEnd, etc
d) Improvements to the roster - being able to copy & delete
locomotives, better editing, import/export to various common formats,
etc.
e) Fix the long-standing problem with many PCs not being able to
connect at the MS100 baud rate. (This is a LocoNet-only problem, and
I'll need help from somebody who speaks windows)
f) Integrated installers, esp. for Windows. The current multi-step
install process is getting in the way. It would be pretty simple to
create a two-step install process of the form "Run this Java
installer, then run this DecoderPro installer", perhaps with an
updater that makes future updates quicker downloads.
g) Lots more decoders
h) Add a progress bar when programming. This is not trivial,
unfortunately, because the program doesn't really have any idea how
long the programming will take, or even how many CVs are left to do.
It would take a little effort to get that right-enough to be useful
(nobody likes a progress bar that gets shorter, then longer, then
shorter)
i) Get the "confirm" button working. This is really only faster on
LocoNet command stations right now, as all others need to do a
complete read to implement it. But it's still a useful thing to have
when working with problematic decoders, e.g. you wonder whether the
decoder's been changed, etc.
j) Make the programmer GUI more bullet-proof. Now, if you type
letters in a decimal field, enter a too-large or negative number,
etc, Bad Stuff happens. It would be good if that were more robust.
What do people think?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Yahoo! Groups Sponsor
ADVERTISEMENT
[Image]
Height: ftin
Weight:
Sex:FM
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
