Steve

I'm building a Jitter patcher that contains a Java mxj object. That object receives both bang() and jit_matrix() messages. These messages are driven by a qmetro object. The bang() messages are supposed to arrive every 100 ms, while the jit_matrix messages arrive once every 8 seconds.

My question is this: what happens when the bang() processing within the mxj object exceeds 100 ms? For example, let's say the bang() processing takes 365 ms to complete. Do the bang messages which should have arrived during the 365 ms be queued? Are they thrown away, instead?

The same questions come up with the jit_matrix message. If the bang() method is doing some processing, and a jit_message should arrive, but cannot because the bang() method is still running, what happens to that jit_matrix message?

I'm building a Jitter patcher that contains a Java mxj object.  That object receives both bang() and jit_matrix() messages.  These messages are driven by a qmetro object.  The bang() messages are supposed to arrive every 100 ms, while the jit_matrix messages arrive once every 8 seconds.

My question is this:  what happens when the bang() processing within the mxj object exceeds 100 ms?  For example, let's say the bang() processing takes 365 ms to complete.  Do the bang messages which should have arrived during the 365 ms be queued?  Are they thrown away, instead?

The same questions come up with the jit_matrix message.  If the bang() method is doing some processing, and a jit_message should arrive, but cannot because the bang() method is still running, what happens to that jit_matrix message?

question-about-qmetro-and-bangjit_matrix-msgs

i may be wrong but i believe the whole idea behind qmetro is that

it will not generate another bang until the previous one has completed

its whole chain of processing.it will just throw it away. it seems 

want two qmteros one at 100 ms and one at 8 seconds.

On Jun 18, 2007, at 10:48 AM, Steve Bursch wrote:

> I'm building a Jitter patcher that contains a Java mxj object. 

> That object receives both bang() and jit_matrix() messages. These 

> messages are driven by a qmetro object. The bang() messages are 

> supposed to arrive every 100 ms, while the jit_matrix messages 

> My question is this: what happens when the bang() processing 

> within the mxj object exceeds 100 ms? For example, let's say the 

> bang() processing takes 365 ms to complete. Do the bang messages 

> which should have arrived during the 365 ms be queued? Are they 

> The same questions come up with the jit_matrix message. If the bang 

> () method is doing some processing, and a jit_message should 

> arrive, but cannot because the bang() method is still running, what 

i may be wrong but i believe the whole idea behind qmetro is that
it will not generate another bang until the previous one has completed
its whole chain of processing.it will just throw it away. it seems  
like you might
want two qmteros one at 100 ms and one at 8 seconds.

>
> I'm building a Jitter patcher that contains a Java mxj object.   
> That object receives both bang() and jit_matrix() messages.  These  
> messages are driven by a qmetro object.  The bang() messages are  
> supposed to arrive every 100 ms, while the jit_matrix messages  
> arrive once every 8 seconds.
>
> My question is this:  what happens when the bang() processing  
> within the mxj object exceeds 100 ms?  For example, let's say the  
> bang() processing takes 365 ms to complete.  Do the bang messages  
> which should have arrived during the 365 ms be queued?  Are they  
> thrown away, instead?
>
> The same questions come up with the jit_matrix message.  If the bang 
> () method is doing some processing, and a jit_message should  
> arrive, but cannot because the bang() method is still running, what  
> happens to that jit_matrix message?
>
> Thanks in advance.
>
> ---Steve
>


I am using two qmetro objects in the patcher; I was unclear about that in my previous message.

A follow-up question would be: since the qmetro object (or perhaps the Max scheduler?) throws away the bang messages that cannot be processed, after the bang() method completes its processing after 365 ms, when should the next bang message arrive?

My guess is the next bang message should arrive 35 ms after the bang() method completes its 365 ms processing. Is that correct? Or is the next bang message is scheduled 100 ms after the bang() method completes, assuming the qmetro object emits bang messages every 100 ms?

A follow-up question would be:  since the qmetro object (or perhaps the Max scheduler?) throws away the bang messages that cannot be processed, after the bang() method completes its processing after 365 ms, when should the next bang message arrive?

My guess is the next bang message should arrive 35 ms after the bang() method completes its 365 ms processing.  Is that correct?  Or is the next bang message is scheduled 100 ms after the bang() method completes, assuming the qmetro object emits bang messages every 100 ms?


> A follow-up question would be: since the qmetro object (or perhaps the Max scheduler?) throws away the bang messages that cannot be processed, after the bang() method completes its processing after 365 ms, when should the next bang message arrive?

Let's imagine that all there is in the patch is this one qmetro, and

your mxj object. Here's a breakdown of what would happen:

1. (0 ms) scheduler tells qmetro it should generate a bang. qmetro

outputs bang, which goes into mxj object. mxj object starts working.

2. (100 ms) scheduler tells qmetro it should generate a bang. qmetro

queues the bang because the work of the previous bang has not

3. (200 ms) scheduler tells qmetro it should generate a bang. qmetro

queues the bang because of the work of the previous bang has not

completed. this bang "usurps" the other bang in the queue - ie, there

are not two bangs in the queue, there is just one.

4. (365 ms) mxj object finishes its work and returns. control returns

to the qmetro object, which has another bang queued and ready to go.

it outputs that bang immediately. qmetro's queue is now empty.

Hope that helps. Feel free to ask more questions.

> A follow-up question would be:  since the qmetro object (or perhaps the Max scheduler?) throws away the bang messages that cannot be processed, after the bang() method completes its processing after 365 ms, when should the next bang message arrive?

Let's imagine that all there is in the patch is this one qmetro, and
your mxj object.  Here's a breakdown of what would happen:

1. (0 ms) scheduler tells qmetro it should generate a bang.  qmetro
outputs bang, which goes into mxj object.  mxj object starts working.

2. (100 ms) scheduler tells qmetro it should generate a bang.  qmetro
queues the bang because the work of the previous bang has not
completed.

3. (200 ms) scheduler tells qmetro it should generate a bang.  qmetro
queues the bang because of the work of the previous bang has not
completed.  this bang "usurps" the other bang in the queue - ie, there
are not two bangs in the queue, there is just one.

4. (365 ms) mxj object finishes its work and returns.  control returns
to the qmetro object, which has another bang queued and ready to go.
it outputs that bang immediately.  qmetro's queue is now empty.

Hope that helps.  Feel free to ask more questions.
Ben


In my Jitter patcher, I have 2 qmetro objects. As mentioned before, one supplies a bang message every 100 ms directly to the mxj object, while the other supplies a jit_matrix message every 8 seconds to the mxj object through a jit.qt.movie object.

I observed that the name of the thread on which these 2 messages are dispatched is "main." I take this to mean that these 2 messages are dispatched to the mxj object on the same thread.

My question is this: can it ever happen that 1 of these messages could be delivered to the mxj object while the other is still running in that object?

My guess is that the answer is no, but I wanted to ask someone more knowledgeable just to be sure.

In my Jitter patcher, I have 2 qmetro objects.  As mentioned before, one supplies a bang message every 100 ms directly to the mxj object, while the other supplies a jit_matrix message every 8 seconds to the mxj object through a jit.qt.movie object.

I observed that the name of the thread on which these 2 messages are dispatched is "main."  I take this to mean that these 2 messages are dispatched to the mxj object on the same thread.

My question is this:  can it ever happen that 1 of these messages could be delivered to the mxj object while the other is still running in that object?

> My question is this: can it ever happen that 1 of these messages could be delivered to the mxj object while the other is still running in that object?

the very short answer is no. a qmetro only outputs into the main

thread, and the main thread can only do one thing at a time.

> My question is this:  can it ever happen that 1 of these messages could be delivered to the mxj object while the other is still running in that object?

the very short answer is no.  a qmetro only outputs into the main
thread, and the main thread can only do one thing at a time.

Thanks again. It's good to know that the execution of bang() and jit_matrix() methods in an mxj object cannot run concurrently or overlap.

> Thanks again. It's good to know that the execution of bang() and jit_matrix() methods in an mxj object cannot run concurrently or overlap.

Just to be clear, it is not true that they *cannot* run concurrently

or overlap - it is only true that they will not overlap in the

situation you described, where all messages are being sent in as a

result of a bang emanating from a qmetro object. When things are also

happening in the scheduler thread, as they might be if you were using

a metro object instead of a qmetro, then things can be more

Just to be clear, it is not true that they *cannot* run concurrently
or overlap - it is only true that they will not overlap in the
situation you described, where all messages are being sent in as a
result of a bang emanating from a qmetro object.  When things are also
happening in the scheduler thread, as they might be if you were using
a metro object instead of a qmetro, then things can be more
complicated.

Got it. I don't currently have any plans to use the scheduler thread. The patcher, in its present state, is complicated enough as it is without trying to make it even more complicated.

Got it. I don't currently have any plans to use the scheduler thread.  The patcher, in its present state, is complicated enough as it is without trying to make it even more complicated.

Question about qmetro and bang/jit_matrix msgs