Thijs Koerselman

I'm prototyping a user interface in JS, using Jitter gl objects to draw to a

named jit.pwindow in a patcher together with a JitterListener to get the

Now I'm thinking about porting the whole thing to C but since I'm not a very

experienced C programmer and the JS code is about 3k lines I feel I could

use some advise. I've never compiled a Jitter or UI external before (only

MSP) and I'm just curious to know how I should approach this. I know you can

instantiate Jitter objects in C just as you can in JS, so I suspect no

What about JitterListener, is it available too? Or, even better, can I

somehow merge the render context from jit.pwindow with the rest of the code

I need hardware accelerated OpenGL, and Pluggo compatibility is also a big

Is there anyone experienced with this who wants to share some insights?

I'm prototyping a user interface in JS, using Jitter gl objects to draw to a
named jit.pwindow in a patcher together with a JitterListener to get the
mouse callback.

Now I'm thinking about porting the whole thing to C but since I'm not a very
experienced C programmer and the JS code is about 3k lines I feel I could
use some advise. I've never compiled a Jitter or UI external before (only
MSP) and I'm just curious to know how I should approach this. I know you can
instantiate Jitter objects in C just as you can in JS, so I suspect no
problems there.

What about JitterListener, is it available too? Or, even better, can I
somehow merge the render context from jit.pwindow with the rest of the code
to make it one external?

I need hardware accelerated OpenGL, and Pluggo compatibility is also a big
pre.

porting-js-ogl-to-c

> Now I'm thinking about porting the whole thing to C but since I'm not a very

> experienced C programmer and the JS code is about 3k lines I feel I could

> use some advise. I've never compiled a Jitter or UI external before (only

> MSP) and I'm just curious to know how I should approach this. I know you can

> instantiate Jitter objects in C just as you can in JS, so I suspect no

I think that the first question to ask is exactly what you plan to

gain from switching to C from Javascript. If it works, there's no real

need to fix it. If performance is an issue, then it would be worth

trying to build an external. If you're just trying to reduce the

wiring complexity, it might be worth trying to put your functionality

> Is there anyone experienced with this who wants to share some insights?

You mention that you've never compiled a Jitter external before --

Instead of starting with a 3000-line monster, why not start building

some simple externals that have a bit of the functionality of your

main project? It can take time to get used to Jitter's framework,

features, and conventions. It took me ages to figure out how to

specify the number of inputs, let alone to figure out what bip, fip,

fop, and bop were referring to. The challenge of learning the language

(C/C++) can greatly compound the problem of learning the API.

Some recommendations are to output a matrix with a constant size and

color, draw some simple gradients and shapes, handle input, do some

basic OpenGL, et cetera. Once you've got the individual basics done,

you'll have enough experience to put together your final project.

Furthermore, since each work unit along the way will be small and

(relatively) simple, the more experienced folks on the list will be

able to give you targetted advice on how to achieve your goals.

On 8/23/06, Thijs Koerselman  wrote:
> Now I'm thinking about porting the whole thing to C but since I'm not a very
> experienced C programmer and the JS code is about 3k lines I feel I could
> use some advise. I've never compiled a Jitter or UI external before (only
> MSP) and I'm just curious to know how I should approach this. I know you can
> instantiate Jitter objects in C just as you can in JS, so I suspect no
> problems there.
I think that the first question to ask is exactly what you plan to
gain from switching to C from Javascript. If it works, there's no real
need to fix it. If performance is an issue, then it would be worth
trying to build an external. If you're just trying to reduce the
wiring complexity, it might be worth trying to put your functionality
into a patcher.

> Is there anyone experienced with this who wants to share some insights?
You mention that you've never compiled a Jitter external before --
Instead of starting with a 3000-line monster, why not start building
some simple externals that have a bit of the functionality of your
main project? It can take time to get used to Jitter's framework,
features, and conventions. It took me ages to figure out how to
specify the number of inputs, let alone to figure out what bip, fip,
fop, and bop were referring to. The challenge of learning the language
(C/C++) can greatly compound the problem of learning the API.

Some recommendations are to output a matrix with a constant size and
color, draw some simple gradients and shapes, handle input, do some
basic OpenGL, et cetera. Once you've got the individual basics done,
you'll have enough experience to put together your final project.
Furthermore, since each work unit along the way will be small and
(relatively) simple, the more experienced folks on the list will be
able to give you targetted advice on how to achieve your goals.

> I think that the first question to ask is exactly what you plan to

> gain from switching to C from Javascript. If it works, there's no real

> need to fix it. If performance is an issue, then it would be worth

> trying to build an external. If you're just trying to reduce the

> wiring complexity, it might be worth trying to put your functionality

Wiring? I don't understand what you mean, it's JS. But yes performance is

the issue. The UI is a sequencer and it's going to be a really fundamental

thing to me. I need it to be as efficient and snappy as can be. Right now

one instance can use up to 20% of my cpu (while doing a lot of editing), and

that's too much, because I want to use more than one. The opengl part is

already really optimized, so I suspect the cpu load comes from the data

> specify the number of inputs, let alone to figure out what bip, fip,

> fop, and bop were referring to. The challenge of learning the language

> (C/C++) can greatly compound the problem of learning the API.

Well I'm not that much of a beginner either. The Jitter API won't be a lot

more difficult than the Max/MSP one, but you're right about starting with

some small testprojects. I just like to know in advance if it's possible or

not, so I'm not waisting loads of time trying to implement something that's

I'll just start with rendering to a jit.pwindow like I do in JS, but if

anyone knows a way to write opengl interfaces with an integrated rendering

On 8/23/06, Thomas Johnson  wrote:
>
>
> I think that the first question to ask is exactly what you plan to
> gain from switching to C from Javascript. If it works, there's no real
> need to fix it. If performance is an issue, then it would be worth
> trying to build an external. If you're just trying to reduce the
> wiring complexity, it might be worth trying to put your functionality
> into a patcher.

Wiring? I don't understand what you mean, it's JS. But yes performance is
the issue. The UI is a sequencer and it's going to be a really fundamental
thing to me. I need it to be as efficient and snappy as can be. Right now
one instance can use up to 20% of my cpu (while doing a lot of editing), and
that's too much, because I want to use more than one. The opengl part is
already really optimized, so I suspect the cpu load comes from the data
handling of the notes and cc curves.

features, and conventions. It took me ages to figure out how to
> specify the number of inputs, let alone to figure out what bip, fip,
> fop, and bop were referring to. The challenge of learning the language
> (C/C++) can greatly compound the problem of learning the API.

Well I'm not that much of a beginner either. The Jitter API won't be a lot
more difficult than the Max/MSP one, but you're right about starting with
some small testprojects. I just like to know in advance if it's possible or
not, so I'm not waisting loads of time trying to implement something that's
not going to work in the end.

I'll just start with rendering to a jit.pwindow like I do in JS, but if
anyone knows a way to write opengl interfaces with an integrated rendering
context I'd love to hear about it.

On Aug 23, 2006, at 11:46 AM, Thijs Koerselman wrote:

> I'll just start with rendering to a jit.pwindow like I do in JS, 

> but if anyone knows a way to write opengl interfaces with an 

> integrated rendering context I'd love to hear about it.

You'd have to write everything yourself from scratch. Couldn't use 

Jitter. Fundamentally not that tough, but requires a decent amount of 

work (I'd plan on a week or two of focused work to get that all 

> I'll just start with rendering to a jit.pwindow like I do in JS,  
> but if anyone knows a way to write opengl interfaces with an  
> integrated rendering context I'd love to hear about it.

You'd have to write everything yourself from scratch. Couldn't use  
Jitter. Fundamentally not that tough, but requires a decent amount of  
work (I'd plan on a week or two of focused work to get that all  
ironed out).

Couldn't you just make something similar to jit.gl.handle? Basically,

use the JIT_OB3D_DOES_UI flag for your ob3d object and process the

> On Aug 23, 2006, at 11:46 AM, Thijs Koerselman wrote:

> > I'll just start with rendering to a jit.pwindow like I do in JS,

> > but if anyone knows a way to write opengl interfaces with an

> > integrated rendering context I'd love to hear about it.

> You'd have to write everything yourself from scratch. Couldn't use

> Jitter. Fundamentally not that tough, but requires a decent amount of

> work (I'd plan on a week or two of focused work to get that all

Couldn't you just make something similar to jit.gl.handle?  Basically,
use the JIT_OB3D_DOES_UI flag for your ob3d object and process the
input to update how your object draws?

On 8/23/06, Joshua Kit Clayton  wrote:
>
> On Aug 23, 2006, at 11:46 AM, Thijs Koerselman wrote:
>
> > I'll just start with rendering to a jit.pwindow like I do in JS,
> > but if anyone knows a way to write opengl interfaces with an
> > integrated rendering context I'd love to hear about it.
>
> You'd have to write everything yourself from scratch. Couldn't use
> Jitter. Fundamentally not that tough, but requires a decent amount of
> work (I'd plan on a week or two of focused work to get that all
> ironed out).
>
> -Joshua
>
>


On Aug 23, 2006, at 1:10 PM, Wesley Smith wrote:

> Couldn't you just make something similar to jit.gl.handle? Basically,

> use the JIT_OB3D_DOES_UI flag for your ob3d object and process the

Yes, this is possible, but it doesn't put it all into one UI object 

(requires separate jit.gl.render, jit.pwindow, and jit.gl.whateveritis).

> Couldn't you just make something similar to jit.gl.handle?  Basically,
> use the JIT_OB3D_DOES_UI flag for your ob3d object and process the
> input to update how your object draws?

Yes, this is possible, but it doesn't put it all into one UI object  
(requires separate jit.gl.render, jit.pwindow, and jit.gl.whateveritis).

With my knowledge of C I think it would take me at least twice that time.

The only thing I'm really good in as it comes to C is making max crash, so I

think I better stick to Jitter objects for now. The performance increase

will probably still be a lot (and enough) in comparison to js. My first C

reference book is on the way so maybe there's still hope:-) Thanks for

On 8/23/06, Joshua Kit Clayton  wrote:
>
>
>
> You'd have to write everything yourself from scratch. Couldn't use
> Jitter. Fundamentally not that tough, but requires a decent amount of
> work (I'd plan on a week or two of focused work to get that all
> ironed out).

With my knowledge of C I think it would take me at least twice that time.
The only thing I'm really good in as it comes to C is making max crash, so I
think I better stick to Jitter objects for now. The performance increase
will probably still be a lot (and enough) in comparison to js. My first C
reference book is on the way so maybe there's still hope:-) Thanks for
letting me know.

Ok, so if you need jit.gl.rendere and jit.window as well, you can just

pipe the data from those guys into your custom gl object and just

define methods or attributes that take parameters from 'em. For

example you would take the mouse data from jit.window and pipe it into

> > You'd have to write everything yourself from scratch. Couldn't use

> > Jitter. Fundamentally not that tough, but requires a decent amount of

> > work (I'd plan on a week or two of focused work to get that all

> With my knowledge of C I think it would take me at least twice that time.

> The only thing I'm really good in as it comes to C is making max crash, so I

> think I better stick to Jitter objects for now. The performance increase

> will probably still be a lot (and enough) in comparison to js. My first C

> reference book is on the way so maybe there's still hope:-) Thanks for

Ok, so if you need jit.gl.rendere and jit.window as well, you can just
pipe the data from those guys into your custom gl object and just
define methods or attributes that take parameters from 'em.  For
example you would take the mouse data from jit.window and pipe it into
your object.

On 8/23/06, Thijs Koerselman  wrote:
>
>
> On 8/23/06, Joshua Kit Clayton  wrote:
> >
> >
> > You'd have to write everything yourself from scratch. Couldn't use
> > Jitter. Fundamentally not that tough, but requires a decent amount of
> > work (I'd plan on a week or two of focused work to get that all
> > ironed out).
>
>
> With my knowledge of C I think it would take me at least twice that time.
> The only thing I'm really good in as it comes to C is making max crash, so I
> think I better stick to Jitter objects for now. The performance increase
> will probably still be a lot (and enough) in comparison to js. My first C
> reference book is on the way so maybe there's still hope:-) Thanks for
> letting me know.
>
> best, -thijs
>
>
>
>
>
>
>
>
>


> Ok, so if you need jit.gl.rendere and jit.window as well, you can just

> pipe the data from those guys into your custom gl object and just

> define methods or attributes that take parameters from 'em. For

> example you would take the mouse data from jit.window and pipe it into

Sounds like a good plan. I don't really care all that much about a separate

pwindow, as long at it's a lot faster than my JS code. I guess there is no

JitterListener equivalent in C for getting mouse callback?

On 8/23/06, Wesley Smith  wrote:
>
> Ok, so if you need jit.gl.rendere and jit.window as well, you can just
> pipe the data from those guys into your custom gl object and just
> define methods or attributes that take parameters from 'em.  For
> example you would take the mouse data from jit.window and pipe it into
> your object.

Sounds like a good plan. I don't really care all that much about a separate
pwindow, as long at it's a lot faster than my JS code.  I guess there is no
JitterListener equivalent in C for getting mouse callback?

On Aug 23, 2006, at 1:57 PM, Thijs Koerselman wrote:

> Sounds like a good plan. I don't really care all that much about a 

> separate pwindow, as long at it's a lot faster than my JS code. I 

> guess there is no JitterListener equivalent in C for getting mouse 

There is. You just use object_attach(). Check out the jit.notify 

example for now, and I hope to send a better example of this and the 

> Sounds like a good plan. I don't really care all that much about a  
> separate pwindow, as long at it's a lot faster than my JS code.  I  
> guess there is no JitterListener equivalent in C for getting mouse  
> callback?

There is. You just use object_attach(). Check out the jit.notify  
example for now, and I hope to send a better example of this and the  
ob3d_ui approach later.

> There is. You just use object_attach(). Check out the jit.notify

> example for now, and I hope to send a better example of this and the

Ah cool. I'm still stuck with windows though, but I'll have a look at the

1.6 sdk examples. Really nice work btw, the new jitter sdk. It'll help me a

>
> There is. You just use object_attach(). Check out the jit.notify
> example for now, and I hope to send a better example of this and the
> ob3d_ui approach later.

Ah cool. I'm still stuck with windows though, but I'll have a look at the
1.6 sdk examples. Really nice work btw, the new jitter sdk. It'll help me a
lot.

porting js ogl to c