Connector

i have a java class written in eclipse and call it with my mxj object.. it works fine.. but after i have done some modifications in my class they aren't visible in max.. only after restarting max the changes are visible.. in the WritingMaxExternalsInJava.pdf is written: "There's no need to quit and restart Max if you want to change one line of code in the external object you're developing" that should be the regular behavior.. or not?? if i try to open the class with mxj quickie.. the class is decompiling.. and now thats the strange thing.. my changes are written in the code.. if i compile it again with mxj quickie the object is working with the modifications... so there is another thread in the java forum people there said that eclipse isn't compiling well.. but in my case it is.. so class is compiled but not refreshed.. is there any caching mechanism or maybe i only have to define something in max.java.config.txt..

caching-javaclasses

On 26 sept. 07, at 21:28, Christian Veit wrote:

> i have a java class written in eclipse and call it with my mxj 

> object.. it works fine.. but after i have done some modifications 

> in my class they aren't visible in max.. only after restarting max 

> the changes are visible.. in the WritingMaxExternalsInJava.pdf is 

> written: "There's no need to quit and restart Max if you want to 

> change one line of code in the external object you're developing" 

> that should be the regular behavior.. or not?? if i try to open the 

> class with mxj quickie.. the class is decompiling.. and now thats 

> the strange thing.. my changes are written in the code.. if i 

> compile it again with mxj quickie the object is working with the 

> modifications... so there is another thread in the java forum 

> people there said that eclipse isn't compiling well.. but in my 

> case it is.. so class is compiled but not refreshed.. is there any 

> caching mechanism or maybe i only have to define something in 

I remember having some issues with more than one class in a java 

> i have a java class written in eclipse and call it with my mxj  
> object.. it works fine.. but after i have done some modifications  
> in my class they aren't visible in max.. only after restarting max  
> the changes are visible.. in the WritingMaxExternalsInJava.pdf is  
> written: "There's no need to quit and restart Max if you want to  
> change one line of code in the external object you're developing"  
> that should be the regular behavior.. or not?? if i try to open the  
> class with mxj quickie.. the class is decompiling.. and now thats  
> the strange thing.. my changes are written in the code.. if i  
> compile it again with mxj quickie the object is working with the  
> modifications... so there is another thread in the java forum  
> people there said that eclipse isn't compiling well.. but in my  
> case it is.. so class is compiled but not refreshed.. is there any  
> caching mechanism or maybe i only have to define something in  
> max.java.config.txt..

I remember having some issues with more than one class in a java  
file. Is that you're case?

no i have only one simple class in the java file..

try sending the zap message to your mxj instance and option drag it 

On Sep 27, 2007, at 09:36 AM, Christian Veit wrote:

> no i have only one simple class in the java file..

try sending the zap message to your mxj instance and option drag it  
to create a new one
or re-type the name in the box.
t

>
> no i have only one simple class in the java file..
>
> regards
> Christian


> try sending the zap message to your mxj instance and option drag it 

it seems that the zap message doesn't work in my case..

re-typing the name works good.. but a bit onerously..

> try sending the zap message to your mxj instance and option drag it  
> to create a new one

it seems that the zap message doesn't work in my case.. 

> or re-type the name in the box.
re-typing the name works good.. but a bit onerously.. 

On 27 sept. 07, at 20:29, Christian Veit wrote:

>> try sending the zap message to your mxj instance and option drag it

> it seems that the zap message doesn't work in my case..

> re-typing the name works good.. but a bit onerously...

In fact that's how it's supposed to work, I thought you were doing 

that already. It's different than in JS where the autowatch makes an 

auto reload process, which cannot be done for the mxj object which 

>> try sending the zap message to your mxj instance and option drag it
>> to create a new one
>
> it seems that the zap message doesn't work in my case..
>
>> or re-type the name in the box.
> re-typing the name works good.. but a bit onerously...

In fact that's how it's supposed to work, I thought you were doing  
that already. It's different than in JS where the autowatch makes an  
auto reload process, which cannot be done for the mxj object which  
load a java class on instantiation.

> In fact that's how it's supposed to work, I thought you were doing 

> that already. It's different than in JS where the autowatch makes an 

> auto reload process, which cannot be done for the mxj object which 

alright.. yes i've tried it before also with renaming the mxj object but i think the problem was that i had called a bail() method in my constructor.. i think that was the reason why the reinstanciation hadn't worked...

> In fact that's how it's supposed to work, I thought you were doing  
> that already. It's different than in JS where the autowatch makes an  
> auto reload process, which cannot be done for the mxj object which  
> load a java class on instantiation.
>

alright.. yes i've tried it before also with renaming the mxj object but i think the problem was that i had called a bail() method in my constructor.. i think that was the reason why the reinstanciation hadn't worked... 

On Sep 27, 2007, at 11:29 AM, Christian Veit wrote:

if you send zap and then option drag on the instance the new one you 

created should have the new version of the class. i forget if zap has 

>
>
>> try sending the zap message to your mxj instance and option drag it
>> to create a new one
>
> it seems that the zap message doesn't work in my case..
>

if you send zap and then option drag on the instance the new one you  
created should have the new version of the class. i forget if zap has  
to be enabled via max java config.

On 27 Sep 2007, at 19:29, Christian Veit wrote:

> re-typing the name works good.. but a bit onerously..

You can do a bit of scripting to remove and reinstantiate the mxj 

object which contains your code, so that you can least reload 

everything from a button. (You'll need to name the upstream and 

downstream objects in order to reconnect them.)

nick rothwell -- composition, systems, performance -- 

>> or re-type the name in the box.
> re-typing the name works good.. but a bit onerously..

You can do a bit of scripting to remove and reinstantiate the mxj  
object which contains your code, so that you can least reload  
everything from a button. (You'll need to name the upstream and  
downstream objects in order to reconnect them.)

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


> You can do a bit of scripting to remove and reinstantiate the mxj 

> object which contains your code, so that you can least reload 

> everything from a button. (You'll need to name the upstream and 

> downstream objects in order to reconnect them.)

thanks for that hint.. so i've tried at the moment to remove and reinstantiate the mxj.. it works fine..

now i should reconnect the mxj with the other objects.. should be no problem if i know the connections.. there are two possibilities i could code it into my reconnect mxj..

but the way i would like to prefer is that my reconnect mxj is watching which connections are existing to my reinstantiating mxj.. i would save the connections and remove the object.. the reconnection should only read the saved values, so i could use the reconnect mxj in many cases.. only the name of the object and the classname have to be defined the rest should be done with the reconnect mxj..

so is there a way to find out to which other objects in the patch at which inlets or outlets they are connected.. i didn't found something about that in the java-doc.. so i expect that it is impossible or not?

> You can do a bit of scripting to remove and reinstantiate the mxj  
> object which contains your code, so that you can least reload  
> everything from a button. (You'll need to name the upstream and  
> downstream objects in order to reconnect them.)

thanks for that hint.. so i've tried at the moment to remove and reinstantiate the mxj.. it works fine.. 

now i should reconnect the mxj with the other objects.. should be no problem if i know the connections.. there are two possibilities i could code it into my reconnect mxj.. 

but the way i would like to prefer is that my reconnect mxj is watching which connections are existing to my reinstantiating mxj.. i would save the connections and remove the object.. the reconnection should only read the saved values, so i could use the  reconnect mxj in many cases.. only the name of the object and the classname have to be defined the rest should be done with the reconnect mxj.. 

so now i have a really fine solution.. i have written three mxj objects.. two connection objects (one for upstream and one for downstream connections) with these both objects i can define my connections.. and with the third object (the Reloader Object) i can define my mxj object wich i like to reload..

after sending the connections to my reload object i only have to send a reload message and my mxj will be reinstatntiated.. so developing mxj objects is more comfortable..

I have to zap my mxj object and THEN rename and then rename-back-to-original. Good enough for me.

caching javaclasses?