timeline SDk bug and missing documentation / example


    Jun 21 2006 | 8:10 pm
    Hi there at C74,
    I'm currently trying to code an external that acesses a timeline.
    However, as soon as I include ext_timeline.h I get the following compile
    error on Windows:
    error C2061: syntax error : identifier 'TEHandle'
    It seems ext_timeline.h is defining a Mac specific data type on line 154:
    TEHandle tr_teh; /* text edit handle */
    Additionally, the WritingExternals.pdf from the latest Windows SDK says
    on page 260: "An example is the external object tiCmd, the source for
    which is distributed in the SDK."
    Unfortenately the SDK comes without such an example, so I'm a little bit
    lost at the moment.... Okay, I found a rather old (OS 9) source file for
    tiCmd on the web, but are still unable to compile it due to the unknown
    data type.
    Olaf

    • Jun 21 2006 | 9:26 pm
      Hi Olaf,
      Judging by what Jeremy had to say about the TEHandle used in editor
      windows (cf. the thread "accessing fields in the "ed" struct"),
      tr_teh is possibly no longer actually used. So you could probably write
      typedef void* TEHandle;
      and live to tell the tale. No guarantees, though.
      But if you're #including the headers from the QuickTime for Windows
      SDK (which I do with all my Windows projects) you'll get TextEdit.h
      with the rest of them:
      typedef struct TERec TERec;
      typedef TERec * TEPtr;
      typedef TEPtr * TEHandle;
      struct TERec {
      Rect destRect;
      Rect viewRect;
      Rect selRect;
      short lineHeight;
      short fontAscent;
      Point selPoint;
      short selStart;
      short selEnd;
      short active;
      WordBreakUPP wordBreak; /* NOTE: This field is
      ignored on non-Roman systems and on Carbon (see IM-Text 2-60) */
      TEClickLoopUPP clickLoop;
      long clickTime;
      short clickLoc;
      long caretTime;
      short caretState;
      short just;
      short teLength;
      Handle hText;
      long hDispatchRec; /* added to replace
      recalBack & recalLines. it's a handle anyway */
      short clikStuff;
      short crOnly;
      short txFont;
      StyleField txFace; /*StyleField occupies
      16-bits, but only first 8-bits are used*/
      short txMode;
      short txSize;
      GrafPtr inPort;
      HighHookUPP highHook;
      CaretHookUPP caretHook;
      short nLines;
      short lineStarts[16001];
      };
      Welcome to Mac OS programming.
      -P-
      On 21-Jun-2006, at 22:10, Olaf Matthes wrote:
      > Hi there at C74,
      >
      > I'm currently trying to code an external that acesses a timeline.
      > However, as soon as I include ext_timeline.h I get the following
      > compile error on Windows:
      >
      > error C2061: syntax error : identifier 'TEHandle'
      >
      > It seems ext_timeline.h is defining a Mac specific data type on
      > line 154:
      >
      > TEHandle tr_teh; /* text edit handle */
      >
      > Additionally, the WritingExternals.pdf from the latest Windows SDK
      > says on page 260: "An example is the external object tiCmd, the
      > source for which is distributed in the SDK."
      >
      > Unfortenately the SDK comes without such an example, so I'm a
      > little bit lost at the moment.... Okay, I found a rather old (OS 9)
      > source file for tiCmd on the web, but are still unable to compile
      > it due to the unknown data type.
      >
      > Olaf
      >
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      iCE: Sequencing, Recording & |home | chez nous|
      Interface Building for |bei uns | i nostri|
      Max/MSP Extremely cool http://www.castine.de
    • Jun 22 2006 | 12:33 am
      Hey Peter and Olaf --
      Somehow I missed the initial query. I believe that TEHandle is indeed
      Mac-specific, and Peter's solution below should work (unless you have
      actual need to access any members of the TEHandle structure). The "#ifdef
      WIN_VERSION" I see in the c74 header files shows that the TEHandle stuff
      is indeed declared as void*. TEHandle also seems to be some old OS9-era
      Mac text/buffer handle-thing, with all kinds of warnings about being
      deprecated (love that word...) in the Mac documentation I found on the
      web.
      brad
      On Wed, 21 Jun 2006, Peter Castine wrote:
      > Hi Olaf,
      >
      > Judging by what Jeremy had to say about the TEHandle used in editor windows
      > (cf. the thread "accessing fields in the "ed" struct"), tr_teh is possibly no
      > longer actually used. So you could probably write
      >
      > typedef void* TEHandle;
      >
      > and live to tell the tale. No guarantees, though.
    • Jun 23 2006 | 2:32 pm
      Yarg... this one is driving me crazy!
      I have a fairly stable [rtcmix~] now built (no cygwin1.dll required, yay!)
      for windows-maxmsp, but about once every 20-30 runs of a fairly complex
      patch, I get this message in the Max window:
      (jvm_release)deallocating jvm
      and the app will hang if my next move is not to close it. Has anyone seen
      anything like this before? Any clues for the clue-less?
      Oh yeah, using v 4.5.7, and no javascript or mxj happening in the patch.
      brad
    • Jun 23 2006 | 11:11 pm
      No idea why, but it happens with ftm and gabor libraries also.
      > (jvm_release)deallocating jvm
    • Jun 24 2006 | 4:15 am
      Weird problem, Brad - the jvm should only be deallocated when the app
      is quit. Is your code doing any allocation of max objects or
      max-aware resources in different threads? Does your code use the
      quittask_install method at all?
      Ben
      On 6/23/06, Bradford Garton wrote:
      > Yarg... this one is driving me crazy!
      >
      > I have a fairly stable [rtcmix~] now built (no cygwin1.dll required, yay!)
      > for windows-maxmsp, but about once every 20-30 runs of a fairly complex
      > patch, I get this message in the Max window:
      >
      > (jvm_release)deallocating jvm
      >
      > and the app will hang if my next move is not to close it. Has anyone seen
      > anything like this before? Any clues for the clue-less?
      >
      > Oh yeah, using v 4.5.7, and no javascript or mxj happening in the patch.
      >
      > brad
      > http://music.columbia.edu/~brad
      >
    • Jun 25 2006 | 9:11 pm
      Hi Brad and Peter,
      and thanks for your input. I changed the TEHandle declaration to be
      void* and now I can at least compile the old tiCmd example code I found.
      However, it seems that what I want to code is not possible using the
      timeline (at least not using it's _public_ API). I'm basically searching
      for a way to display MIDI-like information (notes) and to share them
      between objects. My first thought was to try to use the timeline object
      to store, play and display the information. But then I would also need
      an object that accesses data inside the timeline without playing it...
      From what I read so far in the SDK docs and elsewhere it seems I have
      to write my own graphical object that then makes the internal data
      available to other objects.
      Olaf
      Bradford Garton wrote:
      > Hey Peter and Olaf --
      >
      > Somehow I missed the initial query. I believe that TEHandle is indeed
      > Mac-specific, and Peter's solution below should work (unless you have
      > actual need to access any members of the TEHandle structure). The
      > "#ifdef WIN_VERSION" I see in the c74 header files shows that the
      > TEHandle stuff is indeed declared as void*. TEHandle also seems to be
      > some old OS9-era Mac text/buffer handle-thing, with all kinds of
      > warnings about being deprecated (love that word...) in the Mac
      > documentation I found on the web.
      >
      > brad
      > http://music.columbia.edu/~brad
      >
      >
      > On Wed, 21 Jun 2006, Peter Castine wrote:
      >
      >> Hi Olaf,
      >>
      >> Judging by what Jeremy had to say about the TEHandle used in editor
      >> windows (cf. the thread "accessing fields in the "ed" struct"), tr_teh
      >> is possibly no longer actually used. So you could probably write
      >>
      >> typedef void* TEHandle;
      >>
      >> and live to tell the tale. No guarantees, though.
      >
      >
      >
    • Jun 26 2006 | 9:33 am
      On 25-Jun-2006, at 23:11, Olaf Matthes wrote:
      > From what I read so far in the SDK docs and elsewhere it seems I
      > have to write my own graphical object that then makes the internal
      > data available to other objects.
      Timeline has a reputation for being somewhat difficult and/or
      instable to use. To what extent the reputation is deserved is a
      question for a different thread. The point I want to make is that you
      might find it easier to write an object doing what you want
      independent of the timeline context.
      Sharing data between objects can be readily done using the example
      for the 'refer' message from the SDK. The double-dereferencing may
      seem like a strange idea to people coming from the Windows world, but
      it was not only absolutely standard in the Classic Max Toolbox, it
      was a technique used in a variety of other cool programming
      architectures popular in the 70s & 80s. No reason not to adapt the
      technique to use simple pointers if you prefer.
      > I'm basically searching for a way to display MIDI-like information
      > (notes) and to share them between objects.
      If I may say so, you might want to take a look at the iCE objects. I
      know you're a DIY kind of guy, but ice.lattice provides a highly
      flexible framework for sructuring arbitrary time-based data,
      including MIDI-like stuff and more.
      Hope this helps,
      Peter
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +---> Litter Power & Litter Bundle for Jitter
      Heavy-Duty Mathematics for Everyday Use
      iCE: Sequencing, Recording &
      Interface Building for |home | chez nous|
      Max/MSP Extremely cool |bei uns | i nostri|
    • Jun 26 2006 | 5:02 pm
      Hi Brad,
      Is there an example patch that illustrates the problem? I am
      suspicious of a piece of code in the kernel and would like to check it
      out.
      Ben
      On 6/24/06, Bradford Garton wrote:
      > I found the cause of the problem last night (occasionally going beyond the
      > bounds of an array, duh), and now need to figure out why it's happening.
      > But I can't explain why it would consistently trigger the
      > jvm-deallocation message. I added lots of branches/changes/prints to the
      > code in the process of debugging, with similar symptoms in several
      > different patchers, so I don't think the memory-trashing I caused would
      > hit the same location each time. I'm not doing much max-aware stuff that
      > I know about, although the code I'm including is a lot of unix-like C++
      > (with memory allocs/deallocs).
      >
      > I think at this point we shake our heads and say "hmmm, it's a mystery..."
      >
      > brad
      > http://music.columbia.edu/~brad
      >
      >
      > On Fri, 23 Jun 2006, Ben Nevile wrote:
      >
      > > Weird problem, Brad - the jvm should only be deallocated when the app
      > > is quit. Is your code doing any allocation of max objects or
      > > max-aware resources in different threads? Does your code use the
      > > quittask_install method at all?
      > >
      > > Ben
      > >
      > > On 6/23/06, Bradford Garton wrote:
      > >> Yarg... this one is driving me crazy!
      > >>
      > >> I have a fairly stable [rtcmix~] now built (no cygwin1.dll required, yay!)
      > >> for windows-maxmsp, but about once every 20-30 runs of a fairly complex
      > >> patch, I get this message in the Max window:
      > >>
      > >> (jvm_release)deallocating jvm
      > >>
      > >> and the app will hang if my next move is not to close it. Has anyone seen
      > >> anything like this before? Any clues for the clue-less?
      > >>
      > >> Oh yeah, using v 4.5.7, and no javascript or mxj happening in the patch.
      > >>
      > >> brad
      > >> http://music.columbia.edu/~brad
      > >>
      > >
      >