Forums > Dev

porting js ogl to c

August 23, 2006 | 3:33 pm

Hi list,

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.

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

cheers, -thijs


August 23, 2006 | 5:24 pm

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.

Hope this helps.


August 23, 2006 | 6:46 pm

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.

best, -thijs


August 23, 2006 | 8:00 pm

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


August 23, 2006 | 8:10 pm

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?

wes

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


August 23, 2006 | 8:16 pm

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

-Joshua


August 23, 2006 | 8:26 pm

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


August 23, 2006 | 8:40 pm

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.

wes

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


August 23, 2006 | 8:57 pm

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?

-thijs


August 23, 2006 | 9:03 pm

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

-Joshua


August 23, 2006 | 9:27 pm

On 8/23/06, Joshua Kit Clayton wrote:

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

-thijs


Viewing 11 posts - 1 through 11 (of 11 total)