#new PAR.EXE
66 messages in this thread
Hello Brick (what a great name!),
I understand you're the PAR star & man of the hour. (BTW, fantastic toy, er,
tool, I mean)
I have a couple of things: 1st, some comments on the PAR.EXE (I downloaded the
latest from the forum), then a problem to report.
PAR.EXE
I have one very simple user-interface suggestion which would make life easier –
after a click on the PLAY button it would be very helpful if a second click on
the same button would STOP the animation. Don't do away with the STOP button,
just make the PLAY do double duty, toggling between playing & stopping. You
wouldn't even have to change the button face. This would make starting and
stopping much easier, since one wouldn't have to look away from the animation
and quickly reposition the the cursor over the stop button.
The new version of PAR.EXE frustrates me in one way: when I drag the scroll
button on the scrub bar and then release it, there is a short delay before the
cursor reappears, even on this Pentium-66. In addition, the whole process
seems much more sluggish than the older version. If this is a result of the
'improvements', I might vote to unimprove it.
I also vote for either a version that will run when shelled to DOS from 3DS or
a 3DS plug-in that will operate the PAR. It's a major pain to close down 3DS
to view another segment or test animation. Top on my wish list: small program
that I can run from withing 3DS that offers the minimum function Select File,
Play, Stop, etc. Leave out all the file copy, delete, joining, etc., just let
me play animations!
PROBLEM
I had a nasty PAR-drive crash a few days ago. Using the newest PAR.EXE, I
deleted a few stills and some .ANI files, one of which emptied out a
"directory". I then killed the empty "project/directory". This somehow
TRASHED all data on the disk. It comes up now with some message that files are
corrupt and asks me very politely to please reformat the drive.
Although PAR.EXE would not let me access anything on the drive, the DOS driver
let me copy some files from DOS. The directory structure was completely
trashed with files in all the wrong directories (with most of them missing).
Do you have any comments on how or why this happened and how to avoid it in the
future? I had backup copies of everything important but one 2200 frame
animation. Lost for good, even though it's still sitting on the drive?
Gus mentioned that "a single byte in the directory structure that would get
messed up could throw the whole shebang up in smoke" and that the "PAR file
system is very simple in the sense that it assumes nothing won't ever go wrong.
On a standard file system, there is a lot of redundancy to avoid this sort of
things." If this is unavoidable, have you considered writing a utility similar
to one of the low-level DOS disk recovery/editors that would allow some manual
directory repair?
Don't get me wrong: even if fragile, the PAR is one fantastic piece of
equipment – I haven't used the single-frame features of my 7750 deck since I
got the PAR!
JKJ
John: What's wrong with using the pause button for the toggle start/stop. I
understand your problem but don't understand why you can't use the pause
button.
I also would like to see an IPAS to run the par within 3DS. I love the new
file handling capabilities and do not have the mouse problem you are
experiencing.
BTW: Friday my slomo stuff was used as an example of high quality and
smoothness against a BVW suite attempting to compete for the business. The
client chose the PAR output quality over the BVW DT quality. I ended up doing
an hour of slomo output for this guy.
PC Graphics and Video had an article on the PAR and rated its quality
unbelievably clean. Said it was definitly betacam SP quality. As far as my
client is concerned it is better than betacam SP quality. <BG>
>>use pause button to toggle start/stop…
I haven't tried this (I can't get at it just now), but it would certainly work
– as long as clicking PAUSE initially would start the animation from a dead
stop, so a second click would pause it.
Sounds like you're having fun AND doing well at this stuff. I'm finally about
to get the TBC, so I'll have a whole 'nother set of options to play with.
JKJ
So that's why you forgot the obvious wish list item. You don't have the TBC IV
yet. Here's my biggest wish list item for DPS to consider: (Let me know what
you think of this idea)
This will benefit those that need to do alot of rotoscoping, which I find
myself doing this week.
Since rotoscoping requires a tremendous amount of dos drive space it is
advantagous to keep the rotoscope files on the PAR drive and access them via an
IFL. Then save the animation back out to the PAR again. Using this method
requires about 10% of the HD space and it is all PAR space. The problem with
this approach is that the PAR isn't network compatible when doing file import.
According to Greg P. It would be next to impossible to do. So, if this is not
possible then we're back to porting all the map files from the PAR to a
gigantic, spelled $$$$$, dos hard drive. Then use NDUMP to put the finished
animation directly to the PAR from a network rendering. What would be nice is
to be able to transfer the *.ani files to the DOS drive as 3DS compatible *.JPG
files. These can be compressed enough to make Rotoscoping with the PAR on a
network bearable and possible.
How about it guys, can a program "PAR Utility" be written to convert the *.ani
files to sequential XXXX0000.JPGs before they are saved to the DOS drive?
Hi Don,
<< can a program "PAR Utility" be written to convert the *.ani files to
sequential XXXX0000.JPGs before they are saved to the DOS drive? >>
… with the ability to select a range XXXX1234 – XXXX2112 from the whole
*.ani…
Don:
>> Can a program "PAR Utility" be written to convert the *.ani files to
>> sequential XXXX0000.JPGs before they are saved to the DOS drive?
I'd love to write this program (so I can charge you for it! <bg>) but how about
just a batch file through Image Alchemy or something similar to read the Targas
and write out JPEGS to a DOS drive?
Rewriting PARDRV.EXE to do this internally wouldn't be that difficult, but for
that you'd have to get DPS to spring for it since we wrote it under contract
for them. If enough users wanted to chip in a few bucks… :^)
Greg Pyros
Don,
Couldn't you use Video Post to run an .IFL off the PAR drive, saving as
JPG onto your DOS drive?
Kevin Krell – Computer Support Associates
Yes indeed, I've done that before and it works great, BUT, I thought it would
be much faster doing it from a PAR.exe. Doing it from VP takes ~ 15-20 seconds
per frame. While not always the fastest way VP is always coming through with a
sure fire reliable Utility function for many image operations. VP is probably
one of the best kept secrets in the 3DS package.
>> How about it guys, can a program "PAR Utility" be written to convert
>> the *.ani files to sequential XXXX0000.JPGs before they are saved to the
>> DOS drive?
Yeah. 3D Studio will do that for you. Just run a batch from the Video Post and
save the results as JPEG's!
Over a year ago, I wrote a program to handle batches of TGA's. The idea was to
check a series of Targa files making sure they were in order (no missing files
in a series of numbered files), checking for consistencies (sizes, resolution,
etc. to detect problem files), etc. One of the option was to save the files as
JPEG while doing the checks. Here is a list of the command line options:
WHATTGA v 1.0
Program by Pyros Partnership, Inc.
Copyright (c) 1993, Gus J Grubba. All rights reserved.
Usage: WHATTGA options [filemask] <Enter>
Where options:
-? – This message
-A – Check Aspect Ratio consistency
-D – Delete TGA file after conversion
-G – Write GIF file
-I – Check file integrity
-J[q] – Write JPEG file where q is the quality factor (255=Best)
-L – List all files (defaults to problem files only)
-M – Check Gamma Value consistency
-P – Stops after problem file
-R – Check resolution consistency
-S[x] – Check numeric sequence where x is the sequence step
-Tx – Targa+ Mode (-T? for available modes)
-VT – View image on TARGA+ as it is processed
-VA – View image on ATVISTA as it is processed
-Z[x] – Check size consistency where x is the allowed discrepancy percentage
Example: WHATTGA -VT -S1 C:\IMAGES <Enter>
This will check for sequence on all TGA files found under C:\IMAGES and
display them over the TARGA as it goes. I could write some support code to
facilitate doing this from the PAR (if you leave the PAR in "Increment" mode,
it will loop for ever when it reaches the end of an animation, instead of
returning an error).
Like this, I also wrote a WHATJPG that does the inverse (looks over a list of
JPG files and convert them back to TGA as it goes). I wrote this because Greg
needed (that's why there are options for both the Targa (what I have) and the
Vista (what he has) <g>) and I don't know if it ever made to the "public".
Gus & Don:
>> I don't know if it ever made to the "public".
Sure it did! It's in the "Action IPAS Utilities Library". One of the most
popular sets, after NDUMP! WhatTGA has been lifesaver for me!
Greg Pyros
Maybe this is what I'm looking for.
If I understand you correctly: From the dos prompt C:\images I would run the
program :
WHATTGA -J100 D:\parproj\ABCD0000.ANI
and this would go to my PAR drive's project directory, access the mentioned ani
file and put them as sequential JPEG files with a quality of 100.
Seems to me this would not work until I have the files already in TGA format on
the DOS drive. Herein lies the problem. If I have enough room to put the
files on the DOS drive as TGA's what would I need to convert them to jpeg for?
The idea here is to find a faster way to get the *.ani on the PAR to the dos
directory as *####.jpg's without ever going to the TGA step. As Kevin stated I
can get the JPG's now but I've found the process very slow. I just thought
doing it from the PAR.exe would speed things up considerably.
Remember, the goal here is to get to the point where I can use large quantities
of roto files and be able to use NDUMP with my PAR as a receiver of the
finished animation using the network rendering. Since NDUMP doesn't support
access of the PAR files across the network, the option is to put the roto files
on the server drive in a jpg format so they will all fit. Now to find a speedy
way to get from *.ani to the jpg files without seeing tga's in the interim or a
long tedious process to get there.
No, if you set the PAR in Targa mode, that's what you have. A bunch of Targas.
You only see one filename because that's the way it works, but in reality, you
have as many Targas as there are frames. The software as it is today won't work
because it "sees" only a single targa. All I have to do is to add PAR awareness
so it will correctly extract all the "targas" out of the ANI file. No Targa
file will ever make to your disk. Only the [optional] JPEG files.
>>All I have to do is to add PAR awareness
OK, Do you think this would be a faster process than using the IFL and video
post to extract the JPG's from the PAR ani?
Not really. Granted I don't take the time 3DS takes to load an image, I'm not
sure the time difference is that great. The main reason for the software is to
check image integrity (like a missing frame, a bad formatted frame, etc). In
the case of the PAR, had the images any problems you would know by just looking
at the animation (something not that easy with 1,800 Targas ready to be sent
over to tape/vdisk/Abekas).
Hey Don.
>> What's wrong with using the pause button for the toggle start/stop.
I just got my PAR back up and running and tried this. It would work ok IF the
initial click on the pause button would start the animation, which it doesn't.
Works ok if you PLAY 1st, then use PAUSE to toggle. However, that still
requires some dexterous mouse movement.
Concerning your ANI->JPG comment, I think that would be a good idea. It seems
like direct JPG output would be much quicker and give better quality than 1st
copying as TGA then converting, since the TGA would retain the initial lossy
JPG artifacts, and the TGA->JPG conversion may even result in additional
artifacting.
I have a 1 gig drive for my PAR. Along with the TBC-IV, I was going to get the
1.7 as a second drive. Do you know if that will work or do I need two drives
the same size for some reason?
JKJ
I don't think it would matter about mixing the drives. Seems all you have to
do is set the Master/slave jumpers properly. I was planning to order the
second drive this week but this morning I got my priorities switched from the
big Roto project to a different one for the same client. Seems there are some
legal problems with some of the title graphics in the project and now the
lawyers are involved. Oh well. SNAFU! 🙁
Play toggle? picky, picky, picky. One extra mouse click???
All you have to do is first click on the pause button to activate, then click
on play then just toggle the pause on and off. This is the way all VCRs work.
I do have one JVC CD player the has a combined pause/play button.
"It seems like direct JPG output would be much quicker and give better quality
than 1st copying as TGA…."
Faster, yes.. Better.. no.. Exactly the same. When you move from the PAR
compressed format to any RGB format, there is no subsequent loss. In other
words, you could go from TGA to IFF to SGI to TIFF and back to TGA and there
would be no loss. The loss would come in as soon as you compress with JPEG.
Brick
>>no loss…
What I was referring to was ANI->bitmap, then bitmap->JPG, which would result
in a second JPEG compression. Would that perhaps result in additional loss,
especially considering the possibility of different JPEG parameters for the
second compression? I may test this when I get time.
BTW, you told me to get PAR 1.30b and try the slider. I've been checking the
forum library every day, but I haven't seen it yet. Is it on its way, or do I
need to call the BBS? Thanks.
JKJ
RE: PAR130b.zip
Its there in the hardware/opsys/video forum (at least it shows up for
WinCim).. At least a few people have downloaded it already.
Brick
To be honest, I am really against supporting jpeg as an output format… I
don't mean like cross my arms, and stamp my foot against it, but well, kinda
like… Ahhh MAAANN… JPEG?… REALLY?… To me it seems you always want to
keep the image in the RGB or uncompressed domain, especially for things like
compositing, esp when working with alpha channels. Having just one set of jpeg
algorithms wandering through the image is one thing, but when you add the
second layer of another jpeg algorithm on top of it, the chances of rapidly
increasing artifacting get better and better. We have tried MANY generations
of importing and exporting from the PAR without noticeable effect. Not so with
some of the JPEG software I have seen which butchers the image in only a few
generations.. All this doesn't mean that we will never support jpeg, we
probably will soon enough, but *I* won't use it…
Brick
I had originally suggested this as a speedy way to resolve the dilema of multi
channel rotoscope files and hard drive capacity and still be able to use the
PAR for network rendering. I appreciate the double algorithm and the artifacts
issue but maybe you'd care to comment on any possible way that network slaves
can access the roto files on the PAR as animated tex. maps and then use NDUMP
for the output back to the PAR. Greg P. says this network access is just about
impossible and still keep the file sequence straight. Something about having
to predict a future event (which file is going to be needed) and dumping it
back to the dos path directory before the slave calls for it) and execut the
future event just in time. In my simple way of resolving this issue is to put
all the rotofiles on the dos drive in sequential order but compress the file to
jpg size. I can do it now but it requires a slow VP rendering process to batch
convert the *.ani's through the IFL procedure. Outputing from the PAR to JPG
just seemed much simpler and faster.
Maybe this reason will help you understand the 'why' behind this JPEG output
request.
>>…JPEG..seems you always want to keep the image in RGB or >>…uncompressed
domain…
I may misunderstand how the PAR stores frames, but I was under the impression
that they were JPG compressed. If so, then it seems that a PAR->TGA output
would result in a TGA already containing any initial PAR-induced JPG artifacts.
Then a DOS TGA->JPG conversion could introduce additional artifacts (as you
mentioned). This was the whole point of my previous comment stemming from
DonL's request for PAR->JPG.
I wonder: if PAR is true JPG, can you possibly write a PAR->JPG output (and
perhaps the reverse) that would not introduce any additional compression
artifacts, but simply mirror the .ANI frame bit for bit? If so, then a JPG
output from the PAR would be extremely useful to 3DS'ers like Don and company.
The reasoning: 3DS can accept JPG as input for texture maps, etc. If a
PAR->TGA _does_ retain JPG artifacts, then using an equivalent JPG may be far
better than the TGA, since the JPG would occupy much less disk space.
(Remember, when using bitmaps in materials in 3DS, the image quality is not
nearly the issue it is in other applications, since the bitmap is stretched,
skewed, scaled, distorted, blurred, etc.) In Don's rotoscoping example, copying
hundreds of frames from PAR to disk might be much less painful if the files
were simply much smaller.
Again, is a lossierless <g> PAR->JPG possible? I admit to knowing zilch about
JPG algorithms so this may be the equivalent of asking for antigravity or
something.
BTW, I've been putting v1.30b thru the mill here with numerous small test files
and have found no problems yet. I've purposely tried some things that crashed
me before, like deleting a bunch of ANI and STL files and projects. Thanks
again for the play/pause control. The Down-arrow key on my keyboard is now all
I need to play/pause/play all night.
JKJ
PS. PAR wishlist item for the day: An option to autoswitch into single field
mode whenever the animation is paused/stopped, and back into frame mode when
restarted. This would a) make interactive viewing more pleasant for fields-ON
animations, and b) make it easier/quicker to dump an animation to tape with
long manual head & tails (since the ANI would not have to be sandwiched between
separate specially rendered non-interlaced frames).
OK, now I'll shut up for a while (since I'm leaving in the morning for a week
of work in Colorado <g>)
John:
Did you notice that the frame count jumps when using the play/stop function vs.
using the pause toggle? The animation seems OK but the frame count acts
strange. Check it out.. ref 1.30b
Don,
>> The animation seems OK but the frame count acts strange. Check it out..
ref 1.30b <<
agreed. I saw that too. Most strange. Seems like the count lags behind the
actual animation, then hiccups, and realises it's in the wrong place. I'm not
too worried since the animation doesn't get affected.
>>PAR 1.30b…
Oops, I just checked again and it's there now. PARdon the false alarm!
JKJ
Yo, Brick.
I just checked out the new PAR130 from the lib here. Outstanding. Thanks, Mr.
Wizard!
– I love the new loading screen. Very nice. Not only a time
passer but full of interesting info as well. You have gone far
beyond the call of duty! Very professionally done.
– The new SCRUB bar code is a major enhancement. Much smoother and
easier to use. The CAPS lock is a nice touch. One thing (on my
system anyway): after every click on the scrub bar, the mouse cursor
still disappears for aprox. 1 sec following the button release.
– The PLAY button toggle works very nicely – MUCH appreciated. As
a card-carrying lazy and picky animator (right Don? <g>), this makes
the playback interface easier to use. (I haven't read the forum
messages yet to see if anyone else commented about this, but I've
got some private email echoing "..it's great") Thank you!
Since you seem bent on making this program the best, let me risk another
suggestion: consider not buffering the keyboard.
Programs that offer interactive keyboard control are generally easier to use if
unbuffered, so Mr. User can't accidentally get ahead of himself by holding down
a key too long. Unbuffering makes the control feel much more responsive since
the current operation (for example, frame stepping) stops as soon as the key is
released. I don't know how your program handles the kbd, but in the simplest
case I think a forced flush just after a key grab will assure at most one extra
operation. Just a thought.
And another wishlist item from picky 'ol lazy bones:
A playback range, similar to the segment control in 3DS, where
I could, for example, play back frames 122-175 repeatedly with a
simple mouse click. This would, at minimum, allow me to
repeatedly and easily examine a small segment. Then again, a
scripter might also.
Once again, great work. 🙂
JKJ
Thanks for the comments on the new PAR 1.30b software.
" consider not buffering the keyboard."
Its on the list..
" A playback range, similar to the segment control in 3DS"
Already on the list..
Brick
Thanks for your review. I'll have to download this new PAR.exe today!
JKJ:
Hi there, stranger!
>> after a click on the PLAY button it would be very helpful if a second
>> click on the same button would STOP the animation.
I was thinking along those lines, but leaning towards a right click to stop.
That way you could have the mouse anywhere and halt the animation.
>> Top on my wish list: small program that I can run from withing 3DS that
>> offers the minimum function Select File, Play, Stop, etc.
Well, you're in luck! We just finished a PXP which does exactly that –
replaces the PXP which comes with the PAR adding your wish list feature set!
Greg Pyros
Hi Greg,
<< >> Top on my wish list: small program that I can run from withing 3DS that
>> offers the minimum function Select File, Play, Stop, etc.
Well, you're in luck! We just finished a PXP which does exactly that –
replaces the PXP which comes with the PAR adding your wish list feature set! >>
Congrats.. 🙂
jonas[adesk]
Greg –
>>We just finished a PXP which does exactly that – replaces the PXP which comes
with the PAR adding your wish list feature set!
So you left out the punch line – when and where will this debut???
bob
Bob:
I will be happy to show it at the next 3DS user's group meeting if you give me
a few minutes and have a PAR there!
Greg Pyros
Hey big GP,
Stranger? Than what?
I'm glad to hear about your new PAR-PXP! How do I get my sweaty little hands
on one? (PARdon me if you've answered this in another message – I'm currently
running about 4 days behind in my reading.)
JKJ (…than fiction?)
JKJ:
Check your e-mail for details!
Greg Pyros
"after a click on the PLAY button it would be very helpful if a second click
on the same button would STOP the animation. "
Ok… I will add that.
The mouse update problem you are having is graphic card related. We have done
a LOT of experimenting with this, and the problem centers around having a high
speed screen update under DOS. Faster machines/graphics cards flicker less.
But even some of our fast machines will flicker the mouse alot when we use a
slow graphics card. We are still working on it.
Also we have changed a few things with the next release. (since you brought
up the scrub bar)
The scrub bar action has been changed so that you can use the caps-lock key as
your jog/shuttle key. When you are in caps-lock (or shift) it will be locked
to single frame accuracy. The normal mode has been rescaled so that you can
now move in smaller increments easier. You can still move completely from one
end of the animation to the other, but it is now much easier to move around a
small portion of the animation with normal mouse movements.
Brick
Brick,
I've been meaning to call you guys about the new frame slider, but
haven't had the chance. I don't know if it's working the way it should, because
the older one works MUCH better. The old one would respond VERY accurately to
my mouse moves, whether they were slow or fast, the animation playback would
match. The "new & improved" slider, on the other hand, will only access about
12 frames out of the whole animation. On a 1200 frame animation, if I drag the
slider quickly from one end to the other, only every hundredth frame (or so)
will be displayed. If I move slower, and it takes me 10 seconds to run the
length of the slider, I STILL get only every hundredth frame on screen. If I do
this on a shorter animation, it will still only access a single frame every
1/12 of the total anim, no matter how slowly I drag the slider. I know about
the shift control for single frame accuracy, but this is generally too slow.
Also, when I drag backwards, the response is very sluggish, and can take a
while to catch up with the mouse movement. Is this the way it is supposed to
opperate? Because if so, I vote for the old one!
I also have the same problem as John with the cursor disappearing after
using the slider. This is not the flickering problem which I've always had, but
what happens is if I drag the slider, then let go, the cursor will vanish for
about four seconds before reappearing.
And while I'm on a roll, it would be great if the dos file slider would
work the same as windows sliders did, if draged the slider would move in direct
relation to how far you move the mouse. I've notced that in the new Par
software, if there are not many files in the directory, then draging the slider
is ok, but if there are alot, then it takes ALOT of mouse travel to work your
way through the list. In a directory with 1000 files, it can take several feet
of mouse travel just to make it through the list. Clicking in the scroll bar
below the slider SHOULD drop down one "page", regardless of the number of files
in the directory, but as it is now, a click will drop down the list by over a
hundred frames if there are alot in the directory. These inconsistancies in the
action of the scroll bar make it difficult to quickly find a single file or
start of a sequence in a large directory, while the same process is quick and
easy in windows. And I should mention that everybody at work dislikes the new
sliders as well. Also, I've noticed that the par software is very slow at
reading directories on the Dos drives, slower than any other software I have.
Is this normal also? Aside from these problems, I love the new additions to the
software. 🙂
Thanks,
David
The sliders have been changed (de-sensitized) so that you have much more
control. Look for PAR version 1.30b which I will post here tomorrow. (will
take awhile to show up) or on our BBS
416-754-8368, there is a second number as well but I don't remember that one
off hand.
It sounds to me like there is something wierd in your system. The Dos slider
and scrub bar use the exact same code so they should act the same. It sounds
to me like you are confusing the old dos slider code with the new code. In
1.09 it was rather pokey about how it reacted in the dos requestors. I have
found the DOS requestor to be quite responsive so maybe there is something in
your system that we cannot duplicate in ours..
ANYONE else have any comments about the DOS file requestor speed?
Try the 1.30b version when you get it and let me know what you think.
Brick
>> Try the 1.30b version…
Thanks, I'll let you know what happens.
David
Brick,
Another thing I didn't mention:
I can't get the PAR to recognize ANY of my keyboard commands: "P" or "S" or the
arrow keys, etc.
Alec Jason
Are they defined in your PAR.INI file? If you erase the PAR.INI file, the key
commands are not recreated by PARINIT.
I checked the Par.ini file and found that the entire hotkey section is missing.
How do you get that section back in? I thought it was automatically part of the
.ini file.
I noted that the .ini file is also missing the FORCE_FRAME_FIELD line — and
probably some others.
I tried to call you BBS several times yesterday and this morning but your modem
never answers.
Alec Jason
Hmm, just called the BBS. It may have been down for maintenance. unzip the
PAR_ALL file and it will have the complete PAR.ini in it. Then copy that to
your dps_par directory and REBOOT!.. PARINIT will reinstall the proper
information into the PAR.INI file, and then you can run with all of your hot
keys.
Brick,
I've already downloaded and installed the 1.30b PAR software. I did not reboot
but instead just used a batch file to run the three .exe's and start the PAR.
Is it absolutely necessary to reboot? I do not want the PAR drivers loaded all
the time — every time I reboot. It appears that your installation procedure
believes that everyone who owns a PAR will be using it whenever they use their
computer. I would much prefer to load the drivers just before I need to use the
PAR through the use of a batch file. Is there something wrong with my doing
this?
To get the hot key's working: Can I just copy and paste the hot key section
from an old .ini file into my new .ini file or do I need to actually re-install
and reboot?
Thanks.
Alec Jason
i use two batch files here. One to load the parinit and one to launch the
par.exe. I also have the Parinit in my batch file for 3DS so I have access to
the PXP. I never load the par from the autoexec.bat.
"Is it absolutely necessary to reboot? I do not want the PAR drivers loaded all
the time — every time I reboot. It appears that your installation procedure
believes that everyone who owns a PAR will be using it whenever they use their
computer."
Of course! and EVERYONE who owns a computer should own a PAR..! Maybe we can
talk Microsoft into bundling it with Windoze.<BG>
The installer attempts to make the PAR foolproof for everyone to use. If you
can figure out how to run it (real rocket science here <G>) then more power to
ya.
" I would much prefer to load the drivers just before I need to use the PAR
through the use of a batch file. Is there something wrong with my doing
this?""
Nope, thats the way I do it!
"To get the hot key's working: Can I just copy and paste the hot key section
from an old .ini file into my new .ini file?"
Sure.
Brick
Thank you for your quick reply.
>>..mouse update problem is graphic card related…
I may have misstated this – it is not a cursor update or flicker problem. I
have a very fast PCI video board in a fast Pentium box. (I've clocked flics
under DOS at over 400 frames/sec) There are actually two things I noticed with
the scrub bar…
One, the entire process of dragging the bar feels much more sluggish
than the earlier (non-PharLap) version of PAR.EXE. The frames
displayed seem jerky and erratic, regardless of how slowly or
smoothly I drag the bar. At least on my system and the way I use
it, I have not found ANY advantages to the new 'non-linear' scrub
bar code. If I were king, I'd proclaim a user-selectable (INI?)
option to switch to the old code.
Two, when I drag the scrub bar any distance and then release it,
there is a half-second or so delay (I'm not in a position to time it
just now) during which the cursor disappears completely and then
reappears. Mouse control is lost during this delay so if I am
working rapidly and already moving the mouse towards the next target
on the the screen, my hand-eye synchronization is wiped out. With
the delay, I have to watch and wait till the cursor reappears, then
start the move. The whole process adds an overall feeling of
slugishness to the user-interface, especially after the
above-mentioned scrub bar drag. Pardon my detail and apparent
pickyness here, but I'm sort of a self-proclaimed UI nut. <g>
You didn't answer one question: perhaps the absence of an answer provides me
with your answer: Is there any way to recover an animation currently sitting
on a disk with the directory trashed? It seems it would be relatively easy with
some sort of low-level disk editor program which you may already have as a
by-product of the PAR development. Since by definition, each animation is a
contiguous block of disk sectors, I suspect recovery would simply require 1)
locating the beginning of the block, & 2) editing a 'directory' entry to point
to it. ???
Another small suggestion. How about a courtesy message instead of a blank
screen while loading/initializing. Is this possible? I thought I read that
the initialization time is proportional to the drive space used. In that case,
some message would be especially nice for big drives, at minimum
"Initializing…", or better "Initializing, xxx.." where xxx is perhaps a
sector count, percent completed, or something else that changes. This is a
simple device that reduces user anxiety for time-intensive tasks by providing
reassurance that things are proceeding and not not hung for some reason. (All
this assumes you have easy access to the screen while initializing.)
JKJ
Like I told David, the mouse code has again been rewritten for 1.30b. The
mouse disappearing and coming back is new. I will look into that. Try 1.30b
and let me know what happens. We unfortunately do not have the choice of going
back to the old code. That code is not compatible with Phar Lap. We can add
some new code, but I think you will like the 1.30b feel better so please let me
know what you think.
The PAR file format is not as simple as contiguous blocks of data. Each field
is individually compressed and dynamically stored on the drive. Once you lose
the synchronization between the file system and the FAT(for lack of a better
term), it is almost impossible to recover, or at the very least painful. More
redundancy has been added in the new version as has better error recovery.
I totally agree with you about the blank screen during loading. We should do
the PC thing and put up some advertising. It actually does say something now,
but it goes by so fast that no one can read it. I will move that code so that
it appears in the blank screen.
If you want to stop and start animations without taking your eyes off
the par output monitor, just leave your fingers on the P and S keys on your
keyboard, then stop and play to your hearts content. A list of the hot key
controls is listed in the readme that came with the new exe. I whole-heartedly
agree with you about the new frame slider. The old one responded VERY
accurately with the speed at which I dragged the mouse, but the new one,
well… sucks. No matter what speed I drag the slider, only 12 frames are read,
even if it takes me 10 seconds to drag the full length. 🙁
David
I also prefer the old scrub bar response. The new method is too slow, i.e. you
have to drag your mouse very slowly so that the PAR keeps up.
With the old method, I could quickly drag the mouse to the end of the scrub bar
and the corresponding frame "would be there".
Later,
-Jeff
I do hope they change this. If this bugs anyone else, I hope they speak
up so DPS will consider this.
David
The hot keys do work but on my system I've noticed a forward creep of 3-4
frames when pausing to the next start. With the mouse, clicking on the pause
as a toggle it is accurate and starts up where I paused.
How've you been David? Still wailing, er, whale-ing?
>>PAR keyboard control…
I do use the keys, especially the arrow keys to single-frame thru an animation.
I find that a lot easier then the shift-mousedrag method. It seems that on my
system Ins/Del also performed the Start/Stop, as well as the P/S, but I'll have
to wait to verify that.
It's just that some days I feel like a keyboard kind of guy and other days I
feel more like the rodent.
JKJ
We added the Play/Toggle mode today at JKJ's suggestion. You can now click
play on and off to toggle the play mode of the anim.
The old (1.27b/1.28b/1,29) software had the smallest accuracy set at 10
frames. It has now been reset to 2. You can also lock down single frame
accuracy with shift, or caps lock in 1.30b.
I agree with your comments, John. I would also like to reiterate a need for
some sort of diagnostic software that would aid in the repair of file system
corruption. I also second some simple playback conrtols from a 3DS plug-in.
All in all, the PAR still gets a big star from me!
— James — MAP —
>>PAR file system repair…
Maybe we could each send $50 to Gus along with some old back issues of Dr
Dobb's Journal of Computer Calisthenics & Orthodontia, "Running Light Without
Overbyte", and he would take pity on us and write such a program. !
(I'll try tempting him with an especially exciting Jan '80 "All-CP/M" issue)
JKJ
>> (I'll try tempting him with an especially exciting Jan '80 "All-CP/M"
>> issue)
I can't wait! I will promptly get the centerfold (a gorgeous front view of a
Zilog Z80) and hang it right next to my Manischewitz chicken soup poster! <g>
Let me think about this. This goes to xxx as well. I think some kind of
"mirror" could help. A mirror copy of the system tables could be kept
some place else. In case the master table gets screwed, just replace with the
copy (though you would loose anything created after the last copy was done).
This could be done in such a way that every write operation would check the
consistency of the table and update the mirror. This would add some processing
time but for writing only (which isn't really that bad). Reads wouldn't
change.
The mirror can potentially suffer from the same problems as the original
table. We have already played with that. The answer is to make the software
work properly and react properly in the first place. The PAR now reads and
updates internal information on every operation, and verifies that operation
before performing the next. In short it constantly double checks memory
against actual data. This should take care of all the controllable file
problems.
Brick
>>The answer is to make the software work properly and react properly in the
first place.
Right! The corrupted data requiring a reformat is a reproducable bug. It
occurs after deleting a project name then exiting the PAR and the next time
launching the PAR.exe the drive is shot. I have learned not to delete the
project names here. You can delete files with no problem but leave the
directories alone until you're ready to reformat.
Wishlist: An option to transfer the *.ani files to the dos drive as 3DS
compatible, sequentially numbered JPG files. I go into more detail as to how
this would benefit us in my message to John Jordan.
You say you added the toggle feature to the play button. Is this, now, just a
redundant pause button or does it have a different benefit?
"You say you added the toggle feature to the play button. Is this, now, just a
redundant pause button or does it have a different benefit?"
It just toggles between the PLAY and STOP modes. It doesn't pause. I just saw
it as a QUICK thing to throw in there because I had just read that section of
the code a few minutes before I read the request for the feature here.. (good
timing)..
Brick
>>It just toggles between the PLAY and STOP modes. It doesn't pause.<<
I can't see any difference. Pause starts up again at the same location. Maybe
if you pushed STOP the animation should reset to the first frame automatically.
Right now the play/stop does the same thing as toggling the pause. In your
modification, toggling the play will do the same thing as toggling the the
pause. If so, we could possibly redefine the pause button for a new feature.
Such as reverse play in default speed (whatever that is). Here is what I mean
by reverse play: If you click and hold the on the reverse << button the
animation will play in reverse but slomo speed. I have recorded this for some
special efects before. Of course this also would be redundant function. <G>
Hi Don,
I do not know what PAR.exe is/does. Could you give me thumbnail info? I
have used AniPro and just got 3DS, and want to learn more about digital
editing, etc.
thanks, jhg
The Par is a hardware JPG compression board that uses a dedicated IDE that you
store your rendered animations on and when hooked up to any standard VCR it
will play the animation in real time for recording. If you need near broadcast
quality you can hook up the Component output cabling to an MII or Betacam SP
and record real time as well. The best compression ratios with present hard
drive speeds is about 11 : 1 average. Since the resolution is 50% higher than
a targa + it will produce some very clean high quality output, the best for the
money, hands down. It is Mfg. by Digital Processing Systems. It single
handedly has made frame by frame recording obsolete. Additionally, an optional
TBC IV card can be added to do real time frame grabbing and recording from any
video source. It has time lapse, slomo and special effects capabilities. The
software also has some very basic cuts non linear editing features for doing
video ping pong, reverse play etc. If you need a dealer, contact Digimation.
Thanks Don,
I just received an info packet about hardware from the Florence Ky
office, I did not realize that PAR = DR-2100
jhg
" we could possibly redefine the pause button for a new feature. "
Like I said, it was easy enough to change the Play to do Play/Stop so we did.
We need to save those buttons for _future_ enhancements. Play reverse… I
guess, it will look funny on field rendered animation. The problem is that the
drive cannot play backwards at 4MB/s.. Maybe we could talk Micropolis into
adding it as a feature for the TRUE AV drives (reverse spin!)
Brick
Yes but even the way I get the reverse play has really thrilled one of my
clients.
PS Tonight the Discovery Channel showed a program about the making of Forest
Gump The Crow, and others. One of my clients called me up to tell me he was
just bragging to some investors that HE just did some of these effects at my
studio this afternoon with his new project that was the same as the ones they
were watching on this show using this thing called a "PAR".
What we did is take a piece of video of an actor's eyes blinking. I used the
pingpong feature and lengthened the one blink to a fluttering of the eyes. IT
was a scene from another segment. He needed the eye flutter as an after
thought cut away to a startled look. Once again the PAR came to the rescue.
PAR, the newest ICON in the low budget video producer's vocabulary! <BG>
>> exciting Jan '80 "All-CP/M" issue <<
ROFL
— James — MAP —