vade

Is jit.displays not supported in js world?

var imcdisplays = new JitterObject("jit.displays");

• error: jsjitterobject_Constructor: null class pointer jit_displays

jit-displays-supported-in-js

No sorry it's not at this point. It doesn't have an underlying jitter

object for JS to call. It's just a max wrapper right now.

> Is jit.displays not supported in js world?

> var imcdisplays = new JitterObject("jit.displays");

> • error: jsjitterobject_Constructor: null class pointer jit_displays

No sorry it's not at this point.  It doesn't have an underlying jitter
object for JS to call.  It's just a max wrapper right now.

On 6/18/07, vade  wrote:
>
> Hello
>
> Is jit.displays not supported in js world?
>
> var imcdisplays = new JitterObject("jit.displays");
>
> • error: jsjitterobject_Constructor: null class pointer jit_displays
>
>
> Jitter 1.6.3 Final
>


I don't see what the problem is with sending a message out from mxj 

or js, getting a result from jit.displays, and going back to mxj/js?

It's not the most convenient, but you *are* using Max anyway. I doubt 

that you are querying jit.displays regularly, so there should be no 

So, no promises about 2.0. Maybe js/mxj will, in the future, be able 

to instantiate normal max objects they way they can jit classes.

I don't see what the problem is with sending a message out from mxj  
or js, getting a result from jit.displays, and going back to mxj/js?

It's not the most convenient, but you *are* using Max anyway. I doubt  
that you are querying jit.displays regularly, so there should be no  
complaints about "overhead".

So, no promises about 2.0. Maybe js/mxj will, in the future, be able  
to instantiate normal max objects they way they can jit classes.

> Ugh. This is a freaking *pain* :'(
>
> Feature Request for 2.0 plz?


Well, its a pain in the sense that I prefer elegant and encapsulated solutions that are "clean" so to speak.

Im dealing with some variables for patch initialization that requires some querying of jit.displays or whatever, and due to those timing constraints it would just be cleaner and easier to do it in Javascript.

Of course I can use outlets and inlets, but I like things to be self sufficient and only pass messages from the outside world when I really need to.

But that's religion, in my opinion. Max needs to be about being 

practical sometimes. Be practical, check out how fast you solved the 

problem, hide the patchcords. Celebrate with a cold beverage.

> Well, its a pain in the sense that I prefer elegant and 

> encapsulated solutions that are "clean" so to speak.

> Im dealing with some variables for patch initialization that 

> requires some querying of jit.displays or whatever, and due to 

> those timing constraints it would just be cleaner and easier to do 

> Of course I can use outlets and inlets, but I like things to be 

> self sufficient and only pass messages from the outside world when 

But that's religion, in my opinion. Max needs to be about being  
practical sometimes. Be practical, check out how fast you solved the  
problem, hide the patchcords. Celebrate with a cold beverage.

> Well, its a pain in the sense that I prefer elegant and  
> encapsulated solutions that are "clean" so to speak.
>
> Im dealing with some variables for patch initialization that  
> requires some querying of jit.displays or whatever, and due to  
> those timing constraints it would just be cleaner and easier to do  
> it in Javascript.
>
> Of course I can use outlets and inlets, but I like things to be  
> self sufficient and only pass messages from the outside world when  
> I really need to.


Dont make me fly an airplane into your building.

I kid I kid, but yeah, youve got a point. Anyway I was more curious if I was doing something wrong or if it was something I was unaware of.

Thanks :) P.S. dont smack me on the back of my head!

Quote: Jeremy Bernstein wrote on Mon, 18 June 2007 22:32

----------------------------------------------------

> But that's religion, in my opinion. Max needs to be about being 

> practical sometimes. Be practical, check out how fast you solved the 

> problem, hide the patchcords. Celebrate with a cold beverage.

Wondering.. is this the moment to construct a solid, smooth but urgent 4 or 5 alinea's message? Because.. what you say is not true. Or shall I write a letter (on paper, in an envelope, with a stamp) to the cycling office in which I explain this? Because this could be quite valuable information. Or should I simply come over to San Francisco and bring my laptop? Because then you would certainly be convinced.

But before I arrive, let me make a two-sentence summary of what I am going to tell you.

"When a project gets larger than 10 different subpatchers that have to communicate in an intricate way, max patching becomes programming. In programming, you must utilize every single method to make your code more transparent."

Quote: Jeremy Bernstein wrote on Mon, 18 June 2007 22:32
----------------------------------------------------
> I get that. I really do.
>
> But that's religion, in my opinion. Max needs to be about being  
> practical sometimes. Be practical, check out how fast you solved the  
> problem, hide the patchcords. Celebrate with a cold beverage.
>
> jb
>

Sorry. Although I agree with you in principle, and imagine that 

there's a programming language out there which does what you want, 

you are overlooking the 20-year development of MaxMSP, the need for 

backward compatibility, and the notion that we've probably considered 

most of your suggestions at various points, as well. And that it gets 

a little boring to keep reading the same email from you over and over 

So, come on Mattjis, please give it a little bit of a rest. We're 

working continuously on making the absolute most bestest MaxMSP we 

can imagine, and we know that you're going to love what we've come up 

with. Nevertheless, there are a few things that Max will likely never 

be. Through-and-through consistent is probably one of them.

There are very specific technical reasons why Jitter objects are 

suitable for JS instantiation, while other objects are not. If you've 

programmed any Max or MSP objects in C, you probably already know 

what these are. The day when all Max objects share a common interface 

may come, but until that time, some things will require futzing. But 

isn't it amazing what you can do, even given all the restrictions and 

So, quit yer griping and get back to work! Next time you're in 

Berlin, I'll treat you to a cold beverage to celebrate everything you 

Am 19.06.2007 um 11:42 schrieb Mattijs Kneppers:

> Quote: Jeremy Bernstein wrote on Mon, 18 June 2007 22:32

> ----------------------------------------------------

>> But that's religion, in my opinion. Max needs to be about being

>> practical sometimes. Be practical, check out how fast you solved the

>> problem, hide the patchcords. Celebrate with a cold beverage.

> Wondering.. is this the moment to construct a solid, smooth but 

> urgent 4 or 5 alinea's message? Because.. what you say is not true. 

> Or shall I write a letter (on paper, in an envelope, with a stamp) 

> to the cycling office in which I explain this? Because this could 

> be quite valuable information. Or should I simply come over to San 

> Francisco and bring my laptop? Because then you would certainly be 

> But before I arrive, let me make a two-sentence summary of what I 

> "When a project gets larger than 10 different subpatchers that have 

> to communicate in an intricate way, max patching becomes 

> programming. In programming, you must utilize every single method 

> Hard- and software for interactive audiovisual sampling

Sorry. Although I agree with you in principle, and imagine that  
there's a programming language out there which does what you want,  
you are overlooking the 20-year development of MaxMSP, the need for  
backward compatibility, and the notion that we've probably considered  
most of your suggestions at various points, as well. And that it gets  
a little boring to keep reading the same email from you over and over  
again.

So, come on Mattjis, please give it a little bit of a rest. We're  
working continuously on making the absolute most bestest MaxMSP we  
can imagine, and we know that you're going to love what we've come up  
with. Nevertheless, there are a few things that Max will likely never  
be. Through-and-through consistent is probably one of them.

There are very specific technical reasons why Jitter objects are  
suitable for JS instantiation, while other objects are not. If you've  
programmed any Max or MSP objects in C, you probably already know  
what these are. The day when all Max objects share a common interface  
may come, but until that time, some things will require futzing. But  
isn't it amazing what you can do, even given all the restrictions and  
workarounds?

So, quit yer griping and get back to work! Next time you're in  
Berlin, I'll treat you to a cold beverage to celebrate everything you  
can't have today.

>
> Quote: Jeremy Bernstein wrote on Mon, 18 June 2007 22:32
> ----------------------------------------------------
>> I get that. I really do.
>>
>> But that's religion, in my opinion. Max needs to be about being
>> practical sometimes. Be practical, check out how fast you solved the
>> problem, hide the patchcords. Celebrate with a cold beverage.
>>
>> jb
>>
>
> Dear Cycling '74,
>
> Wondering.. is this the moment to construct a solid, smooth but  
> urgent 4 or 5 alinea's message? Because.. what you say is not true.  
> Or shall I write a letter (on paper, in an envelope, with a stamp)  
> to the cycling office in which I explain this? Because this could  
> be quite valuable information. Or should I simply come over to San  
> Francisco and bring my laptop? Because then you would certainly be  
> convinced.
>
> Ok. I chose for the last option.
>
> But before I arrive, let me make a two-sentence summary of what I  
> am going to tell you.
>
> "When a project gets larger than 10 different subpatchers that have  
> to communicate in an intricate way, max patching becomes  
> programming. In programming, you must utilize every single method  
> to make your code more transparent."
>
> See you in SF. ;)
>
> Mattijs
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling


Hey Jeremy, as always, thanks for your elaborate reply.

I do understand your point and I'll quit ranting about this topic until the moment we have exchanged enough cold beverages to get to know each other a bit better. Promised.

Just to round this up properly for now I'll add a few comments to what you said.

I am -not- whining about new features. I am whining about a purely theoretical attitude towards future developments. But with a few practical consequences. I am happy that you agree -in theory- about my opinion that through-and-through consistensy would be ideal.

But this has a practical side effect. When vade requests such consistency, I wouldn't expect the reply to be 'if you get it working, no matter how, you'll be fine', but 'we'll write it down and consider it, in theory, sometime, ever'. The latter is so much more satisfactory to someone that takes max very seriously.

I take Max dead serious, as I know vade does. The fact alone that I work with max at least 6 days a week for more than 8 hours a day, illustrates that I .. appreciate what max is now. Note, 'appreciation' is an understatement. Please don't interpret my comments as negative critisism, Max is absolutely great.

'if it works, it works'.. this is terribly untrue. I see so much people end up hopelessly confused with max because their patch just stopped working. It became just those two subpatchers too complicated for them. But if they would have dropped the 'if it works, it works' mentality and thought a little more about structuring their patches their project would have ended up as a beautiful piece of media art. Note, these are the people that decide that max is too complicated for them. You will never see a forum post or a support mail from someone like that.

Which doesn't mean one doesn't have to be practical and accept that the cycling development team is small, that you have to deal with backward compatibility, that max is only near perfect, that ibm develops applications with much more inconsistencies that you'd pay 100 grand for.

Quote: Jeremy Bernstein wrote on Tue, 19 June 2007 12:30

> Sorry. Although I agree with you in principle, and imagine that 

> there's a programming language out there which does what you want, 

> you are overlooking the 20-year development of MaxMSP, the need for 

> backward compatibility, and the notion that we've probably considered 

> most of your suggestions at various points, as well. And that it gets 

> a little boring to keep reading the same email from you over and over 

> So, come on Mattjis, please give it a little bit of a rest. We're 

> working continuously on making the absolute most bestest MaxMSP we 

> can imagine, and we know that you're going to love what we've come up 

> with. Nevertheless, there are a few things that Max will likely never 

> be. Through-and-through consistent is probably one of them.

> There are very specific technical reasons why Jitter objects are 

> suitable for JS instantiation, while other objects are not. If you've 

> programmed any Max or MSP objects in C, you probably already know 

> what these are. The day when all Max objects share a common interface 

> may come, but until that time, some things will require futzing. But 

> isn't it amazing what you can do, even given all the restrictions and 

> So, quit yer griping and get back to work! Next time you're in 

> Berlin, I'll treat you to a cold beverage to celebrate everything you 

> Am 19.06.2007 um 11:42 schrieb Mattijs Kneppers:

> > Quote: Jeremy Bernstein wrote on Mon, 18 June 2007 22:32

> > ----------------------------------------------------

But this has a practical side effect. When vade requests such consistency, I wouldn't expect the reply to be 'if you get it working, no matter how, you'll be fine', but 'we'll write it down and consider it, in theory, sometime, ever'. The latter is so much more satisfactory to someone that takes max very seriously. 

Quote: Jeremy Bernstein wrote on Tue, 19 June 2007 12:30
----------------------------------------------------
> Sorry. Although I agree with you in principle, and imagine that  
> there's a programming language out there which does what you want,  
> you are overlooking the 20-year development of MaxMSP, the need for  
> backward compatibility, and the notion that we've probably considered  
> most of your suggestions at various points, as well. And that it gets  
> a little boring to keep reading the same email from you over and over  
> again.
>
> Mattijs: How about now?
>
> C74: No, not yet.
>
> Mattijs: ... How about now?
>
> C74: No, not yet.
>
> Mattijs: Hm... *sniff* how about now?
>
> C74: 
>
>
> So, come on Mattjis, please give it a little bit of a rest. We're  
> working continuously on making the absolute most bestest MaxMSP we  
> can imagine, and we know that you're going to love what we've come up  
> with. Nevertheless, there are a few things that Max will likely never  
> be. Through-and-through consistent is probably one of them.
>
> There are very specific technical reasons why Jitter objects are  
> suitable for JS instantiation, while other objects are not. If you've  
> programmed any Max or MSP objects in C, you probably already know  
> what these are. The day when all Max objects share a common interface  
> may come, but until that time, some things will require futzing. But  
> isn't it amazing what you can do, even given all the restrictions and  
> workarounds?
>
> So, quit yer griping and get back to work! Next time you're in  
> Berlin, I'll treat you to a cold beverage to celebrate everything you  
> can't have today.
>
> jb
>
> Am 19.06.2007 um 11:42 schrieb Mattijs Kneppers:
>
> >
> > Quote: Jeremy Bernstein wrote on Mon, 18 June 2007 22:32
> > ----------------------------------------------------
> >> I get that. I really do.
> >>
> >> But that's religion, in my opinion. Max needs to be about being
> >> practical sometimes. Be practical, check out how fast you solved the
> >> problem, hide the patchcords. Celebrate with a cold beverage.
> >>
> >> jb
> >>
> >
> > Dear Cycling '74,
> >
> > Wondering.. is this the moment to construct a solid, smooth but  
> > urgent 4 or 5 alinea's message? Because.. what you say is not true.  
> > Or shall I write a letter (on paper, in an envelope, with a stamp)  
> > to the cycling office in which I explain this? Because this could  
> > be quite valuable information. Or should I simply come over to San  
> > Francisco and bring my laptop? Because then you would certainly be  
> > convinced.
> >
> > Ok. I chose for the last option.
> >
> > But before I arrive, let me make a two-sentence summary of what I  
> > am going to tell you.
> >
> > "When a project gets larger than 10 different subpatchers that have  
> > to communicate in an intricate way, max patching becomes  
> > programming. In programming, you must utilize every single method  
> > to make your code more transparent."
> >
> > See you in SF. ;)
> >
> > Mattijs
> > --
> > SmadSteck - http://www.smadsteck.nl
> > Hard- and software for interactive audiovisual sampling
>
>
----------------------------------------------------


Am 19.06.2007 um 14:22 schrieb Mattijs Kneppers:

> I do understand your point and I'll quit ranting about this topic 

> until the moment we have exchanged enough cold beverages to get to 

> know each other a bit better. Promised.

> I am -not- whining about new features. I am whining about a purely 

> theoretical attitude towards future developments. But with a few 

> practical consequences. I am happy that you agree -in theory- about 

> my opinion that through-and-through consistensy would be ideal.

Of course I'm in agreement! Who wouldn't be. In what way is it a 

_bad_ idea to have a consistent development environment? I'm 

> But this has a practical side effect. When vade requests such 

> consistency, I wouldn't expect the reply to be 'if you get it 

> working, no matter how, you'll be fine', but 'we'll write it down 

> and consider it, in theory, sometime, ever'. The latter is so much 

> more satisfactory to someone that takes max very seriously.

Well, I'm a practically minded person, and I'm not a programmer by 

training. I learned how to program through MaxMSP. And my very first 

priority in any case you could describe to me is: can you get it 

working at all? If you can, I'm liable to believe that that's great! 

Not just good enough, but splendid, because you've solved your problem.

I appreciate elegant, clever, concise design as much or more as the 

next guy. But I appreciate a solved problem 10x more than a soluble 

problem which remains unsolved because of the theoretical rigidity of 

> I take Max dead serious, as I know vade does. The fact alone that I 

> work with max at least 6 days a week for more than 8 hours a day, 

> illustrates that I .. appreciate what max is now. Note, 

> 'appreciation' is an understatement. Please don't interpret my 

> comments as negative critisism, Max is absolutely great.

I don't understand any of your comments as negative. Nor as 

frustrating or irritating. Simply as idealistic. Idealism is great, 

but it's not ideal when trying to solve problems. And don't worry - 

we respect your seriousness - we're pretty serious about it too. I 

guess I just want to point out that serious people can disagree about 

a serious topic. Or agree, but come to different conclusions.

> 'if it works, it works'.. this is terribly untrue. I see so much 

> people end up hopelessly confused with max because their patch just 

> stopped working. It became just those two subpatchers too 

> complicated for them. But if they would have dropped the 'if it 

> works, it works' mentality and thought a little more about 

> structuring their patches their project would have ended up as a 

> beautiful piece of media art. Note, these are the people that 

> decide that max is too complicated for them. You will never see a 

> forum post or a support mail from someone like that.

We're working on a number of things right now which should serve to 

help bridge some of the inconsistency problems in Max, especially for 

new and intermediate users of the system. There's a lot happening 

under the hood as well, which will make future development of the 

program much, much more "tight", as well. What we do about some of 

the backward compatibility issues is still up in the air, and not 

> Which doesn't mean one doesn't have to be practical and accept that 

> the cycling development team is small, that you have to deal with 

> backward compatibility, that max is only near perfect, that ibm 

> develops applications with much more inconsistencies that you'd pay 

> I do understand your point and I'll quit ranting about this topic  
> until the moment we have exchanged enough cold beverages to get to  
> know each other a bit better. Promised.

> I am -not- whining about new features. I am whining about a purely  
> theoretical attitude towards future developments. But with a few  
> practical consequences. I am happy that you agree -in theory- about  
> my opinion that through-and-through consistensy would be ideal.

Of course I'm in agreement! Who wouldn't be. In what way is it a  
_bad_ idea to have a consistent development environment? I'm  
contrary, but not completely daft. ;)

> But this has a practical side effect. When vade requests such  
> consistency, I wouldn't expect the reply to be 'if you get it  
> working, no matter how, you'll be fine', but 'we'll write it down  
> and consider it, in theory, sometime, ever'. The latter is so much  
> more satisfactory to someone that takes max very seriously.

Well, I'm a practically minded person, and I'm not a programmer by  
training. I learned how to program through MaxMSP. And my very first  
priority in any case you could describe to me is: can you get it  
working at all? If you can, I'm liable to believe that that's great!  
Not just good enough, but splendid, because you've solved your problem.

I appreciate elegant, clever, concise design as much or more as the  
next guy. But I appreciate a solved problem 10x more than a soluble  
problem which remains unsolved because of the theoretical rigidity of  
the solver.

> I take Max dead serious, as I know vade does. The fact alone that I  
> work with max at least 6 days a week for more than 8 hours a day,  
> illustrates that I .. appreciate what max is now. Note,  
> 'appreciation' is an understatement. Please don't interpret my  
> comments as negative critisism, Max is absolutely great.

I don't understand any of your comments as negative. Nor as  
frustrating or irritating. Simply as idealistic. Idealism is great,  
but it's not ideal when trying to solve problems. And don't worry -  
we respect your seriousness - we're pretty serious about it too. I  
guess I just want to point out that serious people can disagree about  
a serious topic. Or agree, but come to different conclusions.

> 'if it works, it works'.. this is terribly untrue. I see so much  
> people end up hopelessly confused with max because their patch just  
> stopped working. It became just those two subpatchers too  
> complicated for them. But if they would have dropped the 'if it  
> works, it works' mentality and thought a little more about  
> structuring their patches their project would have ended up as a  
> beautiful piece of media art. Note, these are the people that  
> decide that max is too complicated for them. You will never see a  
> forum post or a support mail from someone like that.

We're working on a number of things right now which should serve to  
help bridge some of the inconsistency problems in Max, especially for  
new and intermediate users of the system. There's a lot happening  
under the hood as well, which will make future development of the  
program much, much more "tight", as well. What we do about some of  
the backward compatibility issues is still up in the air, and not  
likely to be solved immediately.

> Which doesn't mean one doesn't have to be practical and accept that  
> the cycling development team is small, that you have to deal with  
> backward compatibility, that max is only near perfect, that ibm  
> develops applications with much more inconsistencies that you'd pay  
> 100 grand for.

Quote: Jeremy Bernstein wrote on Tue, 19 June 2007 15:05

> Am 19.06.2007 um 14:22 schrieb Mattijs Kneppers:

> > I do understand your point and I'll quit ranting about this topic 

> > until the moment we have exchanged enough cold beverages to get to 

> > know each other a bit better. Promised.

Great :) Actually there is a chance that I'll be in Berlin in the end of august, together with my colleague Jeroen Hofs (Eboman), who I heard you already met in Paris a few years ago. I'll drop you a mail when things get practical.

> > I am -not- whining about new features. I am whining about a purely 

> > theoretical attitude towards future developments. But with a few 

> > practical consequences. I am happy that you agree -in theory- about 

> > my opinion that through-and-through consistensy would be ideal.

> Of course I'm in agreement! Who wouldn't be. In what way is it a 

> _bad_ idea to have a consistent development environment? I'm 

> > But this has a practical side effect. When vade requests such 

jit.displays - supported in JS ?