waveforms + more rants about Rev as a dev. tool for the future

[Richard Gaskin]

jbv wrote:

> So these days the main question is (at least for me) : is it worth adding
> about 1,2 Mb (the Transcript engine) to a standalone, just to handle
> mouse events ? IOW, is it worth keeping Rev as the central dev. tool
> for an app, and why not used C librairies instead, and code the whole
> thing in C ?

Trivializing what the engine delivers as "just to handle mouse events" 
seems unfair, overlooking the majority of what it does.


Exercise for the reader:

1. Boot your favorite C compiler and make button to select a folder, 
filter out every file in that folder that isn't a Qucktime file, and 
then display those QT file names in a scrolling list and have them play 
when clicked on.

2. Then do that in Transcript.

I'd wager you'd save at least two orders of magnitude of your time doing 
it in Transcript over your C version, with no perceived difference in 
runtime performance.

3. Then make another version for another operating system -- the 
benefits multiply.

:)


Sure, there are a good many specialized, computationally-intensive tasks 
for which Transcript is not ideal, like modifying large binary data sets 
such as audio files. For such vertical needs an externals API is 
provided, so you can use Rev to handle the other 90% of your application 
and spend your time on the things unique to your application.

Take a skim through the Transcript Dictionary and in addition to mouse 
events you'll find:

- Extensive file I/O with binary and text modes, overwriting
   or appending, and automatic conversion of line-endings to
   and from platform-specific formats

- Windows Registry manipulation

- Mac AppleScript support

- Mac resource fork manipulation

- Built-in gzip compression and decompresion

- Built-in Base64 and MD5

- Image import, export, scaling, cropping, and rotation in
   most popular formats, with options for controlling image
   compression format and quality

- Automatic appearance changes for platforms (even better
   in v2.2; rather beautiful in the new version)

- Robust omni-platform drag-and-drop support

- Automatic menu initialization and event handling, with automatic
   changes in menu item placement appropriate to each target
   platform

- Robust QuickTime playback support, all the way down to QTVR
   node handling

- Audio recording and playback, with control over options for
   source, codec, and quality settings

- Automatic conversion of a useful subset of HTML and RTF
   formats for styled text manipulation, import, and export

- Command-line access

- Ability to launch external applications and other processes

- Built-in socket support, with library for handling FTP and
   HTTP both synchronously and asynchronously -- with many
   operations just one-liners

- One-line DNS lookups

- One-line access to OS file, folder, and color selector dialogs

- Robust and efficient hierarchically-structured arbitrary data
   storage of both text and binary data in custom property sets

- XML parsing

- Text searching and substring manipulation

- Built-in color table selector objects and eye-dropper tool

- Automatic layout printing, and library for automatic paginated
   text printing with header and footer

- One-line alias/shortcut creation

- Simple, robust, and flexible date and time manipulation, with
   options for localized date formats, month names, etc.

- Robust omni-platform vector objects tools, with arrow heads and
   markers provided automatically for easy chart-making and more

- Robust omni-platform paint tools, with magnify and more

- Built-in transition effects, and flexible access to QT's
   transition effects

- Animation commands

- Automatic memory management, going far beyond mere garbage
   collection

- And more....

Most of these are available with equal ease on all supported platforms, 
a significant feat in itself.

All this for just 2MBs in a single, self-contained executable file with 
no army of DLLs strewn all over the hard drive?

Seems like a bargain to me.

Sure, there is no button in the Rev IDE named "Design and Create 
Application", so I still need to roll up my sleeves and cut some code.

But it's a nearly indescribably joy for me to focus on the people side 
of software design, leaving the bit-counting for the VM, so I'm happy 
for the relatively tiny fraction of my apps that I need to code myself.

> But really, for the last 12 or 18 months, I got the feeling that the
> market of multimedia developpement (and mostly the requests from
 > clients for much more sophisticated functions) has evolved in huge
 > proportions...
> In the same way, my own projects (for personal needs) can't be built
> anymore with Rev only...

That can happen, from time to time you may need things that are best 
done in C.  In many cases the optimal use of one's time will be letting 
Rev handle the UI, file I/O, and other things it does well and easily, 
and focus your efforts on the components unique to your application.


> And therefore I'm wondering whether Rev has (or can) evolved in the
> same proportions... Could it be that a peak could be reached (in the
> number of built-in features that could be added to the engine) in a
 > more or less near future, and that we'd witness constant evolution
 > in the market (and clients') needs, while we would be able to satisfy
 > less and less requests with Rev alone ?

The biggest shift I've seen in the market in recent years is toward 
Internet-savvy applications, at which Rev excels with nearly unequaled 
grace.

This month's example: I'm working on an app for a client that needs to 
allow a team of 20 medical professionals to edit multimedia content from 
three continents.  The system inolves both client and server components, 
with an administration tool for the project managers to create and 
modify user accounts, review status and changes, etc.  The client needs 
to run on both Win 2K, XP and OS X, while the server is running Linux.

Given the highly specialized audience, the UI had to be ultra-simple; no 
off-the-shelf solution like WebDAV would have been unacceptable.

Moreover, the nature of the content editing tasks themselves needs to 
support specific activities far beyond the scope of WebDAV, and be 
integrated into a change-tracking system that allows the project 
managers to identify and review changes easily (including a markup mode 
that shows text revisions with strikethroughs and color to make deleted 
and added content readily identified at a glace).

Given the multi-platform nature of the system C would have been much 
more expensive than Java, and even crafting such a system in Java would 
have been cost-prohibitive.  While the product we're working on has a 
proven track record and is quite profitable, the additional time needed 
to support a Java-based workflow would have eaten at least two years' 
gross margins, possibly more, requiring outside investment, killing any 
amibitions for expanded marketing activities, and radically slowing 
time-to-market.

Using Rev the entire system is funded out of existing sales, with the 
company remaining in the black throughout the development of this new 
system.

That's the sort of value proposition inherent in the Rev workflow that I 
just don't see matched with other methods.  And I see it again and again 
with every product I work on.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com