#POCO Manual?
7 messages in this thread
I agree with all the kudos of POCO. I am BITTERLY disappointed that this
wonderful feature was left entirely out of Animator Studio with no viable
replacement available (gee, you guys could at LEAST have given us some sort of
OLE Automation capabilities that we could call from Visual BASIC or Borland
Delphi or some such!). POCO does have some "holes" in it, though, and it looks
like they will never be filled due to the emphasis shift to AAS. It's just
another example of programmers leaving easily-implemented features out of
something just because THEY couldn't think of a reason any of us would want it.
NEVER do that with a programming tool! The whole purpose of a programming tool
(POCO, IPAS Plug-Ins, etc.) is precisely BECAUSE we out here can often think of
useful things to do with them that the original designers couldn't —
otherwise, they would've just put in all the features into the program to begin
with rather than having people write plug-ins and scripts!
One example in particular: POCO includes the ability to duplicate MOST of
the user-interface commands of Animator Pro. For instance, under the Swap
Screen menu, you can Copy the current Frame to the Swap screen, Paste the Swap
screen to the current Frame, or Exchange the Swap screen and the current Frame.
POCO implements the Copy and Exchange functions but NOT the Paste function.
This meant my FIELDER.POC (in the Library here) is WAY slower than it needs to
be and the user has to be sure the Key color is set to the least-used color in
the whole FLIC for best results, AND has to deal with the fact that my routine
has to trash the current CEL buffer, since I had to use CEL instead of SWAP.
SWAP would have been MUCH better. But there was no Paste Swap facility, even in
1.3. 🙁
<< It's just another example of programmers leaving easily-implemented
features out of something just because THEY couldn't think of a reason any of
us would want it. >>
This is conjecture.
Can you think of any other reason? I mean, the whole point of POCO was to
implement in a programming language the entire features of Animator Pro,
including all of the menu commands. It's not like Gary could have FORGOTTEN
that there was a Paste Swap command — it's RIGHT THERE IN THE SAME "SWAP" MENU
that the other Swap commands are in! It's not like such a command would be
difficult to implement — it already WAS implemented as a MENU command! All the
"SwapPaste()" function would need to do would be to call the same code that the
Paste Swap menu command uses, then return to the caller! It doesn't even
require any parameter passing in either direction!
Not conjecture, Jonas. Deduction.
>>
Can you think of any other reason? I mean, the whole point of POCO was to
implement in a programming language the entire features of Animator Pro,
including all of the menu commands. It's not like Gary could have FORGOTTEN
that there was a Paste Swap command — it's RIGHT THERE IN THE SAME "SWAP" MENU
that the other Swap commands are in! It's not like such a command would be
difficult to implement — it already WAS implemented as a MENU command! All the
"SwapPaste()" function would need to do would be to call the same code that the
Paste Swap menu command uses, then return to the caller! It doesn't even
require any parameter passing in either direction!
Not conjecture, Jonas. Deduction. <<
good heavens MM… okay… back up. back waaaaaaaaaaay up. <g>
1) POCO was not implemented to take advantage of all features in AniPro… that
may have been a direction it was heading, but it never promised that any more
than, say, ADS or AutoLISP promised access to everh AutoCAD feature. The 1.3
version did update the available POCO functions (including the PSTAMP library,
physical inputs, font control, screen functions, titling functions, tween
functions, flic functions, and the ever helpful PDRACCES library) but it is
well known that it still lacks access to the macro interface, many palette
functions, etc.
2) Gary? Gary? hunh?
3) as to what is difficult, have you ever added a programming interface to any
program? that Animator Studio does not have a programming interface has nothing
to do with the difficulty. the development group could only implement so many
features in their alotted time frame. i could ask you to read every book in the
library of congress… it's not a "hard" thing to do, but try getting it all
done in under an hour. 😉
4) this kind of "deduction" has a lot of holes in it. <g> there's a lot more to
what goes on behind the walls of Autodesk programming than "hey, this should be
easy, get it in there!".
on the lighter side, MM, i am equally anxious for a continuation of AniPro
including continued development of the POCO interface. it's a powerful engine
with very little overhead. question is, will AniPro's functionality be
integrated into AStudio, or will a separate AniPro be written for the many
Windows environments. as to a programming interface, this is an Autodesk
tradition and most of the folks in development know their history of open ended
architecture and the plus it offers to their customers in their products.
-dave
Okay, I concede that I may have been assuming too much. But I have been a
programmer for longer than some people here have been breathing. I am right
now a Windows and Mac developer, and have worked on award-winning Apple II
games in the 80s. I program in the machine language of most major CPUs, in all
major high-level languages and several more obscure ones (APL, SNOBOL, etc.) as
well as the scripting languages of many applications (POCO, KeyScript,
Microsoft Access BASIC, VersaForm XL's Pascal-like language, dBase/FoxPro, and
numerous others). I have hand-coded my own Postscript fonts before there was
any such thing as Fontographer, and hand-coded Postscript line art before there
was any such thing as Illustrator. I have written utilities, applications,
games, and even my own programming languages. So, in answer to your question
"have you ever added a programming interface to any program?" the answer is
simply, "yes, I have." I do know what it entails.
>> utilities, applications, games, and even my own programming languages. So,
in answer to your question "have you ever added a programming interface to any
program?" the answer is simply, "yes, I have." I do know what it entails. <<
great. then you also know that the final feature list of a lot of programs is
not always (in fact rarely) determined by the programmers. product managers,
marketing managers, advertisers and researchers, distributors and analysts all
bring to bear what the market needs in a product. oh yeah, and then there's the
users also. <ggg>
point is simple… you and i (or others here) may know what it takes to write a
program to do something… but bringing a product to the market is a whole
different skill set than programming/coding. it not only has to work, it has to
sell.
-dave
>> replacement available (gee, you guys could at LEAST have given us some sort
of OLE Automation capabilities that we could call from Visual BASIC or Borland
Delphi or some such!). <<
implementing a programmable interface (read creating an interpretive compile)
is not such an easy task…. and creating an SDK or an API that isn't shameful
and offers adequate access to the program's internal functions is also no easy
matter. VB was on the list of things to get in first release, along with
hundreds of other requests. the programmers and product managers are aware of
the open ended architecture needed in the program, but only so much can be done
in the first release before it has to become profitable.
>>
POCO does have some "holes" in it, though, and it looks like they will never
be filled due to the emphasis shift to AAS. It's just another example of
programmers leaving easily-implemented features out of something just because
THEY couldn't think of a reason any of us would want it. <<
i don't know about that… (meaning i disgree as to the reason)… and no one
has said that Animator Pro will definitely not be updated. also, programmers
aren't usually the ones who make these types of decisions. at all.
>> Frame. POCO implements the Copy and Exchange functions but NOT the Paste
function. This meant my FIELDER.POC (in the Library here) is WAY slower than <<
there are a lot of areas that POCO does not address in the program… mask
creation, access to separation tools (we wound up having to write our own),
some weirdness with the LoadCel and SaveCel functions… what language doesn't
have its glitches. i use POCO every day. it is invaluable, so i know what
you're saying here. i just question your reality of "why things happen." from
experience, i know why this type of interface was left out and it wasn't
because of programmers. 🙂
-dave