flies

I am a (relatively) experienced max (and experienced C++, php etc) user but

very new to java. Is it possible to reproduce the functionality of the

sorry if this has been covered already...

I am a (relatively) experienced max (and experienced C++, php etc) user but
very new to java.  Is it possible to reproduce the functionality of the
metro and line objects in java?

basic-timing-in-java

You could use a thread or timer depending how fancy you want to get. 

http://exampledepot.com/egs/java.util/ScheduleRepeat.html

> I am a (relatively) experienced max (and experienced C++, php etc) 

> user but very new to java. Is it possible to reproduce the 

> functionality of the metro and line objects in java?

> sorry if this has been covered already...

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

You could use a thread or timer depending how fancy you want to get. 
Timer is easiest.

George Locke wrote:
> Hi all,
>
> I am a (relatively) experienced max (and experienced C++, php etc) 
> user but very new to java.  Is it possible to reproduce the 
> functionality of the metro and line objects in java?
>
> sorry if this has been covered already...
>
> Thanks,
> George
> ------------------------------------------------------------------------
>
>


Great! thanks. I'll use this and it should probably work.

I should have mentioned that i don't need this to be very accurate at all as

i'm making a random, non-metric sequencer.

Someone told me that garbage collecting in java makes real time scheduling

problematic. I take it mxj takes care of some of this?

On Fri, Jun 13, 2008 at 4:18 PM, topher lafata wrote:

> You could use a thread or timer depending how fancy you want to get. Timer

>> I am a (relatively) experienced max (and experienced C++, php etc) user

>> but very new to java. Is it possible to reproduce the functionality of the

>> sorry if this has been covered already...

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

Great!  thanks.  I'll use this and it should probably work.

I should have mentioned that i don't need this to be very accurate at all as
i'm making a random, non-metric sequencer.

Someone told me that garbage collecting in java makes real time scheduling
problematic.  I take it mxj takes care of some of this?

On Fri, Jun 13, 2008 at 4:18 PM, topher lafata  wrote:

>
> You could use a thread or timer depending how fancy you want to get. Timer
> is easiest.
>
> http://exampledepot.com/egs/java.util/ScheduleRepeat.html
>
> Ciao
> t
>
> George Locke wrote:
>
>> Hi all,
>>
>> I am a (relatively) experienced max (and experienced C++, php etc) user
>> but very new to java.  Is it possible to reproduce the functionality of the
>> metro and line objects in java?
>>
>> sorry if this has been covered already...
>>
>> Thanks,
>> George
>> ------------------------------------------------------------------------
>>
>>
>>
>
>

> Someone told me that garbage collecting in java makes real time 

> scheduling problematic. I take it mxj takes care of some of this?

mxj can't really take care of all of this but you as the programmer can.

first we use incremental garbage collection as a default for mxj which 

has a lot lower chance of interrupting you with a full garbage collect.

second. if you allocate enough heap to your jvm and are conscious about 

how many objects you create as your mxj instance executes a full gc

if you need to create tonnes of objects as you are running you could use 

some sort of object pooling strategy and never trigger a full gc as well.

i find that in most cases you allocate a small set of objects on mxj 

instantiation and they hang around to help you do the execution until 

with that mxj instance the gc stuff isn't a problem since during a 

performance the majority of mxj instances are static.

>
> Someone told me that garbage collecting in java makes real time 
> scheduling problematic.  I take it mxj takes care of some of this?
mxj can't really take care of all of this but you as the programmer can.
first we use incremental garbage collection as a default for mxj which 
has a lot lower chance of interrupting you with a full garbage collect.

second. if you allocate enough heap to your jvm and are conscious about 
how many objects you create as your mxj instance executes a full gc
may never happen at all.

if you need to create tonnes of objects as you are running you could use 
some sort of object pooling strategy and never trigger a full gc as well.

i find that in most cases you allocate a small set of objects on mxj 
instantiation and they hang around to help you do the execution until 
you are done
with that mxj instance the gc stuff isn't a problem since during a 
performance the majority of mxj instances are static.
t


On Fri, Jun 13, 2008 at 5:09 PM, topher lafata wrote:

>> Someone told me that garbage collecting in java makes real time scheduling

>> problematic. I take it mxj takes care of some of this?

> mxj can't really take care of all of this but you as the programmer can.

> first we use incremental garbage collection as a default for mxj which has

> a lot lower chance of interrupting you with a full garbage collect.

> second. if you allocate enough heap to your jvm and are conscious about how

> many objects you create as your mxj instance executes a full gc

> if you need to create tonnes of objects as you are running you could use

> some sort of object pooling strategy and never trigger a full gc as well.

> i find that in most cases you allocate a small set of objects on mxj

> instantiation and they hang around to help you do the execution until you

> with that mxj instance the gc stuff isn't a problem since during a

> performance the majority of mxj instances are static.

On Fri, Jun 13, 2008 at 5:09 PM, topher lafata  wrote:

>
>
>> Someone told me that garbage collecting in java makes real time scheduling
>> problematic.  I take it mxj takes care of some of this?
>>
> mxj can't really take care of all of this but you as the programmer can.
> first we use incremental garbage collection as a default for mxj which has
> a lot lower chance of interrupting you with a full garbage collect.
>
> second. if you allocate enough heap to your jvm and are conscious about how
> many objects you create as your mxj instance executes a full gc
> may never happen at all.
>
> if you need to create tonnes of objects as you are running you could use
> some sort of object pooling strategy and never trigger a full gc as well.
>
> i find that in most cases you allocate a small set of objects on mxj
> instantiation and they hang around to help you do the execution until you
> are done
> with that mxj instance the gc stuff isn't a problem since during a
> performance the majority of mxj instances are static.
>
> t
>

n 13 juin 08, at 23:23, George Locke wrote:

Also there's MaxClock which allows you to the same thing as what you 

would do with metro objects, using the Max scheduler. Have a look to 

the Max java api in the ../Max folder/java-doc/api folder to find more 

Also there's MaxClock which allows you to the same thing as what you  
would do with metro objects, using the Max scheduler. Have a look to  
the Max java api in the ../Max folder/java-doc/api folder to find more  
infos.

On Jun 13, 2008, at 14:35 PM, Emmanuel Jourdan wrote:

> n 13 juin 08, at 23:23, George Locke wrote:

> Also there's MaxClock which allows you to the same thing as what 

> you would do with metro objects, using the Max scheduler. Have a 

> look to the Max java api in the ../Max folder/java-doc/api folder 

Thanks for reminding me about that!
T
On Jun 13, 2008, at 14:35 PM, Emmanuel Jourdan wrote:

> n 13 juin 08, at 23:23, George Locke wrote:
>
>> thanks!
>
>
> Also there's MaxClock which allows you to the same thing as what  
> you would do with metro objects, using the Max scheduler. Have a  
> look to the Max java api in the ../Max folder/java-doc/api folder  
> to find more infos.
>
> HTH,
> ej
>
>


you can also then set up a routine to automatically execute after a delay - see the Java tutorial booklet for this. I would probably get something wrong.

Re timing - occasionally somethings happened in a weird order (once you have a longish program)

E.G. time 1040 received before event at 1080

however, the time stamp will tell you when it actually occured

(basic) timing in java?