Loading ...
Sorry, an error occurred while loading the content.

Re: [Clip] Re: functional, but dysfunctional also onclipboardchange

Expand Messages
  • hsavage
    ... WordWeb s definition of concurrent. concurrent = Occurring or operating at the same time Although you initialize these DoNothing? clips they are not
    Message 1 of 19 , Feb 3, 2007
    • 0 Attachment
      notetab_is_great wrote:
      >
      > Below is a revised library that demonstrates up to 6 concurrent
      > clips running: manually invoke, a few seconds apart, donothing1,
      > donothing2, donothing3, and donothing4 in that order. Then invoke
      > bar. Then put something on the clipboard. That is a total of 6
      > clips running concurrently, and bar succeeds, providing that
      > OnClipboardChange also succeeds. And watching the status bar long
      > enough (90 seconds from when you started) will demonstrate that the
      > other clips were still there, successfully.

      WordWeb's definition of concurrent.
      concurrent = Occurring or operating at the same time

      Although you initialize these 'DoNothing?' clips they are not running
      concurrently, they are running serially, in tandem, one after another.

      You can discover that by watching the NoteTab status line. The clips
      will run 'last in, first out' order.

      The delays will time out in the last clip then the next most recent clip
      will start timing.

      I believe if you tried this using language to do any actual work NoteTab
      would 'Error' out. It isn't built for concurrent multi-tasking.

      > So it isn't the number of concurrent clips, but apparently
      > something else, that causes the problems. My best guess so far is
      > nested clips, but I suppose it could be something else. But why
      > should nested clips cause more problem than concurrent clips?

      By 'nested' I suppose you mean clips that are started with a ^!Clip
      command within the body of the currently running clip. If so, I use
      nested clips all the time and have no trouble with them.

      > Surprise! donothing4 won't invoke, it beeps. That is true even if
      > OnClipboardChange is removed or renamed. So it seems that Delay
      > only allows other clips to run if the Delay is invoked from an
      > unrested Clip invocation :( That is a severe limitation on
      > building modular code.

      I had no trouble with 'DoNothing4' beeping, it worked exactly like the
      first 3 clips.

      You may possibly be running into a dearth of resources, NoteTab requires
      a lot of ram, some of the commands/functions are more ram intensive than
      others.

      I thought I knew what you were striving for at one time, to use
      'OnClipBoardChange' and have an independent ^!StatusShow of an action to
      be taken, but, I must admit I have no clue at this point.

      ºvº SL-2-9
      2007.02.03 - 16.40.53

      Great Truth About Growing Old:
      "Forget the health food. I need all the preservatives I can get."

      ¤ hrs ø hsavage@...
    • notetab_is_great
      ... to convey a ... *launch* ... Commmunication is the hardest part about computers... knowing what the other fellow is saying so we comprehend and learn...
      Message 2 of 19 , Feb 3, 2007
      • 0 Attachment
        --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
        >
        > (There seems to be not yet achieved sufficient communication so as
        to convey a
        > correct understanding about the important distinction between 1. to
        *launch*
        > a 2nd (or 3rd, etc.) clip while a clip is already currently
        > running --*versus*-- 2. the use of ^!Clip


        Commmunication is the hardest part about computers... knowing what the
        other fellow is saying so we comprehend and learn...


        >
        > # 1 and # 2 are different. # 2 is *not* (not in actuality)
        *launching*
        > another clip while a clip is already running. Instead, what # 2 is
        doing is
        > it is "farming out" (or contracting to) (or, even better yet,
        "routing the
        > processing to").


        I think we agree on the difference between #1 and #2. #1, launching
        another clip while a clip is running, produces clips that appear to be
        running simultaneously. #2, using ^!Clip, which I call "nested
        clips", do not produce, and are not expected to produce, simultaneous
        execution: the ^!Clip operation suspends the first clips, performs the
        clip named as a parameter, and when that one completes, the first
        resumes at the next instruction.


        As far as I can determine, OnClipboardChange is a 2nd way, besides the
        user explicitly launching a clip, for a clip to be initiated. If
        other unnested-Clips are already running, it seems that
        OnClipboardChange can be successfully launched during ^!Delay
        operations in those other clips' operation sequence. But if any
        nested clip is currently running, then OnClipboardChange produces a
        beep, just like the user attempting to launch another clip while a
        nested clip is currently running.


        >
        > Continued further below is that ^!Clip, however many times it is
        used, is to
        > be seen as a conglomeration of clips that in actuality are
        esentially they
        > are united as one huge clip. The point is that, since ^!Clip is for
        "routing
        > the processing to", it is only one clip that is running no matter
        how many
        > times ^!Clip is used.


        When not thinking about simultaneous clips, your "united as one huge
        clip" comment is a reasonable interpretation of the matter, but when
        thinking about simultaneous clips, then there is a visible distinction.

        Initiation of donothing3 directly (one huge clip) does not prevent
        initiation of donothing4. Initiation of donothing3invoker, which has
        exactly the same set of operations as donothing3 because it calls it,
        does prevent initiation of donothing4, which proves there is a
        distinction between "one huge clip", and "united as one huge clip".



        > Are you trying to use clip as a programming language? It is not.
        It is a
        > macro language (a powerful macro language). Notetab is a text
        editor that
        > you can write clips/macros so as to "program (or automate repetitive
        tasks
        > in) the editor".


        In my computer science classes, I learned that a functional computer
        can be created from two instructions: subtract, and branch if
        negative. For example, negation can be synthesized by subtracting
        from 0, addition can be synthesized by negating and subtracting,
        multiplication is a series of additions, etc. So I find that NoteTab
        supports subtract [ ^!Set %x%=^$Calc(^%x%-^%y%)$ ] and branch if
        negative [ ^!If ^%x% < 0 Skip_-3 ], so I conclude that it is a
        programming language. To me, a macro language is simply a linear
        sequence of operations, like a tape recorder/player. Once control
        flow and arithmetic are added to a macro language, it becomes a
        programming language.


        > But clip itself is *definitely not* a programming language. A
        "programable
        > editor" is a term I've heard used about Notetab. But it is a macro
        language
        > that is used to achieve this automation or so called
        "programability" of the
        > editor.
        >
        > Oh, clip has likeness to, say, qbasic. I guess qbasic is considered
        as a
        > programming language. But clip is definitely macros language.
        > --


        So we disagree about what to call the clip language...


        > It *appears* to me that I've not yet *effectively* *totally*
        communicated
        > to/with you.
        >
        > I've no argument with you that your well made point quoted up
        > above "absolutely won't work".
        >
        > But, once again (as per your lib below) and your well made point
        quoted up
        > above, you are *launching* a second (and 3rd, etc.) clip while
        another clip
        > is still running. And, AFAIK when a clip is running, it is not
        supported to
        > *launch* a 2nd clip (nor a 3rd, etc.) so that now two clips are running
        > simultaneously.
        >
        > s/concurrently/simultaneously/; # perl substitution lingo
        >
        > I'm using the term "simultaneously" to replace or in place of
        concurrently
        > term that you used.
        >
        > AFAIK it is not supported in Notetab to launch/run two clips
        *simultaneously*.
        > That's not to say that sometimes it won't at least partially work or
        work
        > under some circumstances but not others.


        You likely have more experience with NoteTab/clip than I do, so I'm
        not going to disagree with anything you say here... but I would like
        to make some terminology definitions so we can communicate better.

        1) documented: a feature that is explained in the documentation.
        Generally all documented features are also supported (see below).

        2) supported: a feature that is claimed to work by the purveyor of the
        product. Generally all supported features are also documented, but
        sometimes older features, while still supported, are dropped from the
        documentation in favor of newer, better features that encompass all
        the capability of the older feature, and sometimes the documentation
        of new features lags the development of the feature and its delivery
        in the product.

        3) bonus: a feature that is not documented or supported, but which, by
        experimentation, is found to work. There is no guarantee that such a
        feature will work in future versions of the product.


        > A Very *Important* distinction: If by "nested" you mean what I call
        parent and
        > child clips (where ^!Clip clip_name is used) -- to do so, this is *not*
        > simultaneously running more than one clip at once.


        I agree; and that is why I was surprised to discover that nested
        clips, which you call parent/child clips, prevent the simultaneous
        invocation of other clips, whereas "one huge clip" does not, even if
        they have the same sequence of operations.


        > So as to illustrate the "nested" and "levels":
        >
        > Mr. Fookes, the author of Notetab, wrote the next clip library:
        >
        > http://www.notetab.com/pad/index.htm
        >
        > On that page, you can download the pad clip library. I
        suggest/offer that you
        > download that library and look at it.


        Yes, a very complex program.


        > I wonder if Mr. Fookes has something that we don't know about such
        as "tags"
        > for clips?


        Understanding such a complex program can often be better done by
        looking at the individual building blocks, and understanding them
        first... but I have no idea what tools Mr. Fookes might have for
        building clip libraries.


        > AFAIK, a *bonus* *if* it even works at all -- let alone whether or
        not it
        > works under more complex circumstances. AFAIK what's supported is
        only 1
        > clip running at a time, not 2 or 3 etc. clips launched and running
        at the
        > *same* time.


        So your theory is that simultaneous clips are a bonus feature.
        Certainly I couldn't find documentation for them, so they don't seem
        to be a documented feature.

        Yet Jody seems to write clips that use the feature, and so do others
        on this board. So it seems to be an acceptable use, perhaps it might
        be a supported feature, but it could be a well-used bonus feature.

        Can anyone declare that simultaneous clips are a bonus feature? What
        are the chances of them being removed, deprecated, or enhanced,
        respectively, in future version of NoteTab?

        If I build clips that depend on them, are they likely to continue working?

        Are there other limits that are likely to surface as clip complexity
        increases?
      • notetab_is_great
        ... I understand that it is extremely likely that multiple operating system threads/CPUs are not used to cause true concurrency. And I understand the how
        Message 3 of 19 , Feb 3, 2007
        • 0 Attachment
          --- In ntb-clips@yahoogroups.com, hsavage <hsavage@...> wrote:
          >
          >
          > notetab_is_great wrote:
          > >
          > > Below is a revised library that demonstrates up to 6 concurrent
          > > clips running: manually invoke, a few seconds apart, donothing1,
          > > donothing2, donothing3, and donothing4 in that order. Then invoke
          > > bar. Then put something on the clipboard. That is a total of 6
          > > clips running concurrently, and bar succeeds, providing that
          > > OnClipboardChange also succeeds. And watching the status bar long
          > > enough (90 seconds from when you started) will demonstrate that the
          > > other clips were still there, successfully.
          >
          > WordWeb's definition of concurrent.
          > concurrent = Occurring or operating at the same time
          >
          > Although you initialize these 'DoNothing?' clips they are not running
          > concurrently, they are running serially, in tandem, one after another.


          I understand that it is extremely likely that multiple operating
          system threads/CPUs are not used to cause true concurrency. And I
          understand the how multitasking on a single thread of control can be
          done. What I am trying to figure out is where the limits of
          multitasking are in the clip programming language.

          I understand that OnClipboardChange, ^!TimerPlay/^!TimerStart, and
          user invocation are the 3 asynchronous ways of initiating a clip. I
          understand that ^!Delay (and are there other such operations?) can
          suspend an unnested clip in such a manner that other clips can be
          invoked in a manner that appears like multitasking.


          > You can discover that by watching the NoteTab status line. The clips
          > will run 'last in, first out' order.
          >
          > The delays will time out in the last clip then the next most recent
          clip
          > will start timing.


          The delays seem to run concurrently. Check your watch from starting
          donothing1 until it completes, whether or not you invoke other
          donothingX clips in the meantime.


          > I believe if you tried this using language to do any actual work
          NoteTab
          > would 'Error' out. It isn't built for concurrent multi-tasking.


          I appreciate your response, and your experience with NoteTab, that has
          led you to your belief system about clips. I'm trying to get past
          belief systems, though, and understand exactly what capabilities are
          provided. It is documented that recursive clips are not supported.


          > > So it isn't the number of concurrent clips, but apparently
          > > something else, that causes the problems. My best guess so far is
          > > nested clips, but I suppose it could be something else. But why
          > > should nested clips cause more problem than concurrent clips?
          >
          > By 'nested' I suppose you mean clips that are started with a ^!Clip
          > command within the body of the currently running clip. If so, I use
          > nested clips all the time and have no trouble with them.


          Yes, that is what I mean by nested clips. And yes, they seem to work
          fine, when not also dealing with multitasking clips.

          But it seems that ^!Delay in a non-nested clip provides more ability
          to multitask clips than ^!Delay in a nested clip, which seems to block
          the ability to start another multitasking clip.


          > > Surprise! donothing4 won't invoke, it beeps. That is true even if
          > > OnClipboardChange is removed or renamed. So it seems that Delay
          > > only allows other clips to run if the Delay is invoked from an
          > > unrested Clip invocation :( That is a severe limitation on
          > > building modular code.
          >
          > I had no trouble with 'DoNothing4' beeping, it worked exactly like the
          > first 3 clips.


          I think you missed the difference in the two invocation sequences I
          was suggesting. Invoking donothing3 and then donothing4 works.
          Invoking donothing3invoker and then donothing4 beeps.


          > You may possibly be running into a dearth of resources, NoteTab
          requires
          > a lot of ram, some of the commands/functions are more ram intensive
          than
          > others.


          Only if NoteTab artificially limits the available resources. My
          machine is quite capable.


          > I thought I knew what you were striving for at one time, to use
          > 'OnClipBoardChange' and have an independent ^!StatusShow of an
          action to
          > be taken, but, I must admit I have no clue at this point.


          Yes, you did understand my goal. But my sample clips that have been
          posted are extremely limited, compared to my plans. When I discovered
          that nested clips and non-nested clips seem to differ in their ability
          to invoke ^!Delay and allow multitasking clips to be initiated, I
          created a sub-goal of attempting to understand the multitasking
          features of NoteTab in more depth, hopefully to discover if other such
          limits exist, before wasting a lot of time coding things that will not
          work.

          Presently, it appears that code must be structured so that ^!Delay
          operations are in non-nested clips, although nested clips can be
          called before or after the ^!Delay operation. This forces code to be
          designed differently than otherwise.

          Presently, it appears that OnClipboardChange, if it gets invoked at a
          time when all the multitasking clips are in non-nested ^!Delays, can
          successfully use as many nested clips of its own as it desires.

          Left to determine are whether there are other operations that wait for
          user input or timers (^!Delay waits for a timer, and if invoked from a
          nested clip, blocks multitasking clip initiation) that will block or
          otherwise confuse multitasking clips.

          >
          > ºvº SL-2-9
          > 2007.02.03 - 16.40.53
          >
          > Great Truth About Growing Old:
          > "Forget the health food. I need all the preservatives I can get."
          >
          > ¤ hrs ø hsavage@...
          >
        • Alan
          (I just saw your reply to Harvey - so I thought I d mention this it s the truth) BTW, my opining is based upon my experience of writing and using clips and
          Message 4 of 19 , Feb 3, 2007
          • 0 Attachment
            (I just saw your reply to Harvey - so I thought I'd mention this it's the
            truth) BTW, my "opining" is based upon my experience of writing and using
            clips and years of following this clips list and that I'm a very highly
            mechanical aptitude person. IOW, I choose not to believe the help file, and
            I "hack like crazy" and if I can make it work reliably then I'll use it. I
            certainly do not have firm belief systems of what I limit myself to that
            consists of what will and what will not work. To resolve something, I
            usually hack code until I get something to work (in addition to considering
            what others offer and considering the documentation/help).

            On Saturday 03 February 2007 15:32, notetab_is_great wrote:
            > --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
            > > (There seems to be not yet achieved sufficient communication so as

            <snipped, 1. launch two clips in fashion whereby these two are "simultaneous
            execution/running versus 2. ^!Clip and how it operates.>

            > I think we agree on the difference between #1 and #2. #1, launching
            > another clip while a clip is running, produces clips that appear to be
            > running simultaneously. #2, using ^!Clip, which I call "nested
            > clips", do not produce, and are not expected to produce, simultaneous
            > execution: the ^!Clip operation suspends the first clips, performs the
            > clip named as a parameter, and when that one completes, the first
            > resumes at the next instruction.

            Yes.

            > As far as I can determine, OnClipboardChange is a 2nd way, besides the
            > user explicitly launching a clip, for a clip to be initiated.

            Yes.

            > If
            > other unnested-Clips are already running, it seems that
            > OnClipboardChange can be successfully launched during ^!Delay
            > operations in those other clips' operation sequence. But if any
            > nested clip is currently running, then OnClipboardChange produces a
            > beep, just like the user attempting to launch another clip while a
            > nested clip is currently running.

            This is where I opine (my useage of AFAIK) that it is a bonus if 2
            simultaneously execution/running clips might happen to work.

            <snipped "chunk (divided up pieces of) coding via the use of ^!Clip versus
            what I've opined as the alternative which is to have "one huge clip">

            > When not thinking about simultaneous clips, your "united as one huge
            > clip" comment is a reasonable interpretation of the matter, but when
            > thinking about simultaneous clips, then there is a visible distinction.
            >
            > Initiation of donothing3 directly (one huge clip) does not prevent
            > initiation of donothing4. Initiation of donothing3invoker, which has
            > exactly the same set of operations as donothing3 because it calls it,
            > does prevent initiation of donothing4, which proves there is a
            > distinction between "one huge clip", and "united as one huge clip".

            I've absolutely no argument with you whatsover about your call there on
            *distinction* . My point, however, is that I opine that such distinction
            exactly as that is attributed to an offshoot of that you are operating under
            a bonus condition and that the bonus is setting the stage for this to happen.

            Once again, I opine that this scenario you mentioned occurs in this fashion to
            you due to what I've termed/opined the bonus of if 2 simultaneous
            executed/running clips might happen to work.

            > In my computer science classes, I learned that a functional computer
            > can be created from two instructions: subtract, and branch if
            > negative. For example, negation can be synthesized by subtracting

            You lost me. Went over my head. That's ok.

            > So we disagree about what to call the clip language...

            Fine. All I know is I got it from Jody that to write a clip is to write a
            macro. And it appears that this came from Mr. Fookes to Jody though I've no
            absolute certainty of this latter.

            I suspect that there might be others who would agree with me. But I doubt
            that this matters. I only asked you because your coding style seemed to me
            to be "programmer like" ie the use of Notetab's perhaps a bit cursory multi
            level or variable within a variable syntax.

            > You likely have more experience with NoteTab/clip than I do, so I'm
            > not going to disagree with anything you say here... but I would like
            > to make some terminology definitions so we can communicate better.
            >
            > 1) documented: a feature that is explained in the documentation.
            > Generally all documented features are also supported (see below).
            >
            > 2) supported: a feature that is claimed to work by the purveyor of the
            > product. Generally all supported features are also documented, but
            > sometimes older features, while still supported, are dropped from the
            > documentation in favor of newer, better features that encompass all
            > the capability of the older feature, and sometimes the documentation
            > of new features lags the development of the feature and its delivery
            > in the product.
            >
            > 3) bonus: a feature that is not documented or supported, but which, by
            > experimentation, is found to work. There is no guarantee that such a
            > feature will work in future versions of the product.

            Agreed on all 3 with one exception. The exception is that (once again, I
            opine) that in some places the help/documentation is terse. And, it is
            enough so that people come to these lists asking for further and usually more
            specific of "in the help/doc, what does it mean by (thus_and_such)".

            > > A Very *Important* distinction: If by "nested" you mean what I call
            > > parent and
            > > child clips (where ^!Clip clip_name is used) -- to do so, this is *not*
            > > simultaneously running more than one clip at once.
            >
            > I agree; and that is why I was surprised to discover that nested
            > clips, which you call parent/child clips, prevent the simultaneous
            > invocation of other clips, whereas "one huge clip" does not, even if
            > they have the same sequence of operations.

            I opine, attribute this to being "in a so called bonus" sets the stage (bonus
            being the prelude to whatever)

            > So your theory is that simultaneous clips are a bonus feature.
            > Certainly I couldn't find documentation for them, so they don't seem
            > to be a documented feature.
            >
            > Yet Jody seems to write clips that use the feature, and so do others
            > on this board. So it seems to be an acceptable use, perhaps it might
            > be a supported feature, but it could be a well-used bonus feature.

            I myself have certainly not known that this is "well used"

            I would tend to think that it has not been used very much. I've not seen it
            in use very much if at all.

            One thing I do know, however, is that if it can work, people will use it.
            I've seen almost anything and everything. So, I'm not surprised that you
            have argument material against my mentioned herein opine of bonus.

            > Can anyone declare that simultaneous clips are a bonus feature? What
            > are the chances of them being removed, deprecated, or enhanced,
            > respectively, in future version of NoteTab?
            >
            > If I build clips that depend on them, are they likely to continue working?
            >
            > Are there other limits that are likely to surface as clip complexity
            > increases?

            notetab_is_great, I sincerely wish you good luck and happiness in all of your
            endeavors.

            --
            Alan.
          • notetab_is_great
            ... it s the ... using ... file, and ... it. I ... that ... considering ... Sounds like a good process to me :) But the documentation can be helpful (though
            Message 5 of 19 , Feb 3, 2007
            • 0 Attachment
              --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
              >
              > (I just saw your reply to Harvey - so I thought I'd mention this
              it's the
              > truth) BTW, my "opining" is based upon my experience of writing and
              using
              > clips and years of following this clips list and that I'm a very highly
              > mechanical aptitude person. IOW, I choose not to believe the help
              file, and
              > I "hack like crazy" and if I can make it work reliably then I'll use
              it. I
              > certainly do not have firm belief systems of what I limit myself to
              that
              > consists of what will and what will not work. To resolve something, I
              > usually hack code until I get something to work (in addition to
              considering
              > what others offer and considering the documentation/help).


              Sounds like a good process to me :) But the documentation can be
              helpful (though terse), in the areas in which it chooses to be. It is
              nice, for example, not to have to try strange combinations of
              characters after ^! to discover what operations are available...
              although maybe we could discover some great features that way!


              > > Yet Jody seems to write clips that use the feature, and so do others
              > > on this board. So it seems to be an acceptable use, perhaps it might
              > > be a supported feature, but it could be a well-used bonus feature.
              >
              > I myself have certainly not known that this is "well used"
              >
              > I would tend to think that it has not been used very much. I've not
              seen it
              > in use very much if at all.
              >
              > One thing I do know, however, is that if it can work, people will
              use it.
              > I've seen almost anything and everything. So, I'm not surprised
              that you
              > have argument material against my mentioned herein opine of bonus.


              Well, sometimes you see what you look for... it is hard to say how
              much use multitasking clips have gotten, but certainly it seems that
              they have gotten some use, because there is discussion about having
              clips that sit in the background and do things, and how to end them
              "typically by watching for Shift+Alt" and a couple coding conventions
              for detecting that combination.


              > > Can anyone declare that simultaneous clips are a bonus feature? What
              > > are the chances of them being removed, deprecated, or enhanced,
              > > respectively, in future version of NoteTab?
              > >
              > > If I build clips that depend on them, are they likely to continue
              working?
              > >
              > > Are there other limits that are likely to surface as clip complexity
              > > increases?
              >
              > notetab_is_great, I sincerely wish you good luck and happiness in
              all of your
              > endeavors.


              Thanks Alan, I wonder if Mr. Fookes ever reads any of this stuff, on
              the forums, and comments. Seems the knowledge on this topic is quite
              limited (only a few responders, with only experimental knowledge (like
              mine, but mine is based on very limited experience so far))... so a
              few comments from Mr. Fookes might be extremely enlightening.
            • Alan
              ... ... I ve seen and contributed to posts/threads like that, searchable in the archives of this the ntb-clips list at Yahoo Groups. But most of them
              Message 6 of 19 , Feb 3, 2007
              • 0 Attachment
                On Saturday 03 February 2007 18:19, notetab_is_great wrote:
                > --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
                <snip>
                > Well, sometimes you see what you look for... it is hard to say how
                > much use multitasking clips have gotten, but certainly it seems that
                > they have gotten some use, because there is discussion about having
                > clips that sit in the background and do things, and how to end them
                > "typically by watching for Shift+Alt" and a couple coding conventions
                > for detecting that combination.

                I've seen and contributed to posts/threads like that, searchable in the
                archives of this the ntb-clips list at Yahoo Groups.

                But most of them would be about how to put a clip into a repetitively looping
                mode while the user does something else, gathers what to input, or etc. And
                then using one of the control sequences of keyboard keys (you mentioned the
                shift+alt) (there are two others for a total of three available) to get the
                clip to do some action, either bring up a prompt for user input or resume
                processing somewhere or exit/end the clip. Outside of that, I'm not aware of
                any that loop repetitively, awaiting a signal of some sort so as to launch a
                2nd clip while this clip continues to run.

                > Thanks Alan, I wonder if Mr. Fookes ever reads any of this stuff, on
                > the forums, and comments. Seems the knowledge on this topic is quite
                > limited (only a few responders, with only experimental knowledge (like
                > mine, but mine is based on very limited experience so far))... so a
                > few comments from Mr. Fookes might be extremely enlightening.

                AFAIK (there I go "opining" again). He's subscribed to this list or used to
                be anyways. I haven't seen much from him of late. Years ago he used to post
                more often on this list if you, for example, search the older archives of
                this list at Yahoo Groups.

                (login to the www yahoo groups first, and then,)

                Are you ready for nostalgia lane? Here goes:

                summer of 2001

                http://tech.groups.yahoo.com/group/ntb-clips/messages/7021?viscount=-30&l=1


                summer of 2000

                http://tech.groups.yahoo.com/group/ntb-clips/messages/4521?viscount=-30&l=1


                Feb. 2000 -- 3 posts on this page of Messages 2571 - 2600 of 16051

                http://tech.groups.yahoo.com/group/ntb-clips/messages/2600?viscount=-30&l=1

                Summer 1999

                http://tech.groups.yahoo.com/group/ntb-clips/messages/1200?viscount=-30&l=1

                March 1999
                http://tech.groups.yahoo.com/group/ntb-clips/messages/100?viscount=-30&l=1

                March 1999 Messages 1 - 30 of 16051
                http://tech.groups.yahoo.com/group/ntb-clips/messages/30?viscount=-30&l=1


                http://tech.groups.yahoo.com/group/ntb-clips/

                can go to there and scroll down to the message history for a profile of
                traffic related. It appears it has tapered off a slight bit over the last
                several years. Well, there's lots of archives to search now.

                Also I just ran across this, an faq by Jody:

                http://www.notetab.net/faq/ntb/index2.htm

                and a frames version of the same:

                http://www.notetab.net/faq/ntb/

                --
                Alan.
              Your message has been successfully submitted and would be delivered to recipients shortly.