timeline SDk bug and missing documentation / example

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.

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:

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
>

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.

> 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.

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
>

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.
>
>
>

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.

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
> >>
> >
>