tommy

my system is macbook intel 2 ghz , 2 Gb ram.

i'm using it with an audio soundcard motu 828.mkII

It seems to me that the all the metro inspectors of my patch freeze 

I guess that the audio i am still hearing is coming out without any 

of the spatialization effect that I have programmed for it.

During rehearsal today, I had to turn off/on the dac~ while playing 

I need help for a concert that is very close.

Hi all,
my system is macbook intel 2 ghz , 2 Gb ram.
i'm using it with an audio soundcard motu 828.mkII

It seems to me that the all the metro inspectors of my patch freeze  
every two seconds,
although I can still hear the audio.
I guess that the audio i am still hearing is coming out without any  
of the spatialization effect that I have programmed for it.

During rehearsal today, I had to turn off/on the dac~ while playing  
to make it unfreeze , but after
2 seconds it was frozen again.

Any hint about that?
I need help for a concert that is very close.

problem-very-strange-need-help-for-upcoming-concert

Quote: tommy wrote on Mon, 18 June 2007 12:31

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

> my system is macbook intel 2 ghz , 2 Gb ram.

> i'm using it with an audio soundcard motu 828.mkII

> It seems to me that the all the metro inspectors of my patch freeze 

> I guess that the audio i am still hearing is coming out without any 

> of the spatialization effect that I have programmed for it.

> During rehearsal today, I had to turn off/on the dac~ while playing 

> I need help for a concert that is very close.

Quote: tommy wrote on Mon, 18 June 2007 12:31
----------------------------------------------------
> Hi all,
> my system is macbook intel 2 ghz , 2 Gb ram.
> i'm using it with an audio soundcard motu 828.mkII
>
> It seems to me that the all the metro inspectors of my patch freeze  
> every two seconds,
> although I can still hear the audio.
> I guess that the audio i am still hearing is coming out without any  
> of the spatialization effect that I have programmed for it.
>
> During rehearsal today, I had to turn off/on the dac~ while playing  
> to make it unfreeze , but after
> 2 seconds it was frozen again.
>
> Any hint about that?
> I need help for a concert that is very close.
>
> Thank you in advance
>
> Tom
>
>
>
----------------------------------------------------


I'm not sure if this is what you're describing, but if your patch is using quite a bit of CPU, then the UI elements can definitely look stalled and jerky, while the audio is continuously processed properly (hopefully). Are you sure that the sound is not being processed? To check, since you are using spatialization, oscillate a stable sound between two opposite positions over time so that you can definitely hear the change. Run it for a while and see if the audio continues to be properly processed while the UI hangs...

I'm not sure if this is what you're describing, but if your patch is using quite a bit of CPU, then the UI elements can definitely look stalled and jerky, while the audio is continuously processed properly (hopefully).  Are you sure that the sound is not being processed?  To check, since you are using spatialization, oscillate a stable sound between two opposite positions over time so that you can definitely hear the change.  Run it for a while and see if the audio continues to be properly processed while the UI hangs...
tim


And the Performance Options.... selection from

the Options menu will, as ever, allow you to do

And the Performance Options.... selection from
the Options menu will, as ever, allow you to do
some tuning to fit your needs.


i've seen your post and sorry for not answering soon, but I tried to 

but it will take ages to explain how to use it before trying to debug.

I thought the problem was caused by an improper use of

but i realized that i had the same problem on a simpler patch

that only features a 3 comb filter effects with 4

i'm actually running the patch and in dsp status window I see that I 

20% cpu usage , 609 function calls and 116 signals used.

Is this too much? is the "performance option" useful to help my 

i keep looking for the bug into buffers and records (i guess it's not 

On Jun 18, 2007, at 4:45 PM, Gregory Taylor wrote:

> And the Performance Options.... selection from

> the Options menu will, as ever, allow you to do

> knowledge is not enough/science is not enough/Love is dreaming this 

hi guys,
i've seen your post and sorry for not answering soon, but I tried to  
go deeper into the problem.
i'd love to post the patch
but it will take ages to explain how to use it before trying to debug.

(is here by the way... http://mamito.com/incastro)

I thought the problem was caused by an improper use of
buffers and record objects,
but i realized that i had the same problem on a simpler patch
that only features a 3 comb filter effects with 4
point spatialization. [ http://mamito.com/radiopneuma ]

i'm actually running the patch and in dsp status window I see that I  
have
20% cpu usage , 609 function calls and 116 signals used.
Is this too much? is the "performance option" useful to help my  
patch?  how?

i keep looking for the bug into buffers and records (i guess it's not  
there, but i'll look)
other hints are helpful.

>
> And the Performance Options.... selection from
> the Options menu will, as ever, allow you to do
> some tuning to fit your needs.
> --
> knowledge is not enough/science is not enough/Love is dreaming this  
> equation
>


i really cannot understand what's behind this.

I can say that i hear the audio working, but the metro inspectors are completely frozen. I have attached a tif image of my screen showing also dsp status window. In that image the sound is still going, but without visual feedback is hard to play the patch and understand if the audio part is not frozen.

I tried putting higher i/o vector size, or signal vectro size with no success. after a few seconds all the metro inspectors frozen.

Do you think that ths use of metro inspectors is to expensive for 

screen refreshing? how can i deal with this problem.

I need to solve this problem as I'm not really sure this is not going to affect also audio.

thanks again, hope you find out what's next to do.

Hi,
i really cannot understand what's behind this.
I can say that i hear the audio working, but the metro inspectors are completely frozen. I have attached a tif image of my screen showing also dsp status window. In that image the sound is still going, but without visual feedback is hard to play the patch and understand if the audio part is not frozen.

Do you think that ths use of metro inspectors is to expensive for 
screen refreshing? how can i deal with this problem.

i reduced the function calls of the patch from 611 to 496 and it seemed to not freeze for a while.

then it froze again, but all the metro inspectors were frozen,

is the "function calls" where my problem is set?

i reduced the function calls of the patch from 611 to 496 and it seemed to not freeze for a while.
then it froze again, but all the metro inspectors were frozen,
except ONE. what does it mean?

Could you please clarify exactly what you are talking about when you

Could you please clarify exactly what you are talking about when you
say, "metro inspectors"?

the things with the light that give visual feedback of the amplitude.

i took the function calls to 395 and everything seems to go fine

for almost 4 minutes consecutively. I'm testing now if it is going well also for longer time laps.

is it possible that an excessive use of meter inspectors and matrix~ objects can cause performance problems, even if the cpu load is just around and no more 25% ?

i mean meter inspectors.
the things with the light that give visual feedback of the amplitude.

i took the function calls to 395 and everything seems to go fine
for almost 4 minutes consecutively. I'm testing now if it is going well also for longer time laps.

Quote: tommy wrote on Tue, 19 June 2007 20:17

> is it possible that an excessive use of meter inspectors and matrix~ objects can cause performance problems, even if the cpu load is just around and no more 25% ?

I can't explain this, but my experience is that any relatively complex use of matrix~ causes the kind of GUI problems you are describing.

Quote: tommy wrote on Tue, 19 June 2007 20:17
----------------------------------------------------
> is it possible that an excessive use of meter inspectors and matrix~ objects can cause performance problems, even if the cpu load is just around and no more 25% ?
----------------------------------------------------

This seems related to a problem that a few of us have had with the scheduler

freezing on some machines. I've had to solve this problem by driving things

in the signal domain that normally would be driven by metro or qmetro. Just

out of curiousity, could you hook a metro 1000 to a print object and see if

it continues to print after your meters freeze? This problem has been

reported a few times over the past couple of years with no one offering a

You can read more complaints, all a bit different by searching the forums

The machine I was having difficulties with is a G4 DP tower.

This seems related to a problem that a few of us have had with the scheduler
freezing on some machines.  I've had to solve this problem by driving things
in the signal domain that normally would be driven by metro or qmetro.  Just
out of curiousity, could you hook a metro 1000 to a print object and see if
it continues to print after your meters freeze?  This problem has been
reported a few times over the past couple of years with no one offering a
fix.

You can read more complaints, all a bit different by searching the forums
for "metro random stopping".

i'm leaving tomorrow for concert place, but i'll take in high 

consideration what u say and i'll test it on my machine as soon as 

On Jun 20, 2007, at 10:17 PM, Christopher Overstreet wrote:

> This seems related to a problem that a few of us have had with the 

> freezing on some machines. I've had to solve this problem by 

> in the signal domain that normally would be driven by metro or 

> out of curiousity, could you hook a metro 1000 to a print object 

> it continues to print after your meters freeze? This problem has been

> reported a few times over the past couple of years with no one 

> You can read more complaints, all a bit different by searching the 

> The machine I was having difficulties with is a G4 DP tower.

wow chrisofer.
i'm leaving tomorrow for concert place, but i'll take in high  
consideration what u say and i'll test it on my machine as soon as  
possible.

t.
On Jun 20, 2007, at 10:17 PM, Christopher Overstreet wrote:

> This seems related to a problem that a few of us have had with the  
> scheduler
> freezing on some machines.  I've had to solve this problem by  
> driving things
> in the signal domain that normally would be driven by metro or  
> qmetro.  Just
> out of curiousity, could you hook a metro 1000 to a print object  
> and see if
> it continues to print after your meters freeze?  This problem has been
> reported a few times over the past couple of years with no one  
> offering a
> fix.
>
> You can read more complaints, all a bit different by searching the  
> forums
> for "metro random stopping".
>
> The machine I was having difficulties with is a G4 DP tower.
>
>
>


i had 2 concerts during this break and I have to off/onn dac a couple of times while playing. yeah...weird...

As i'm having other 2 concerts with the same patch, im here back to try to fix he problem

Just want to announce that im proceeding step by step to do all the testing you kindly suggested to me.

So now the first step is to change all meter inspector screen update frequency from 50 ms (default) to 100 ms.

and try to test with the scheduler as you told me.

i'll try to use a softer granulation with less grain...

Sorry for it taking too long for answering, i had been busy. I appreciate a lot your help.

hi guys
im still trying to solve this problem.

i had 2 concerts during this break and I have to off/onn dac a couple of times while playing. yeah...weird...
As i'm having other 2 concerts with the same patch, im here back to try to fix he problem

So now the first step is to change all meter inspector screen update frequency from 50 ms (default) to 100 ms. 

then i'll proceed testing with qmetros
and try to test with the scheduler as you told me.

PRoblem very strange, need help for upcoming concert.