Cycling '74

I have a VST synth receiving midievent messages generated from an algorithm

that is triggered by bangs from a metro 250. It plays fine in real time

although, as you can guess, it drives up the cpu % substantially. When I

put it into nonrealtime in DSPstatus the metro seems to tick very slowly. I

Here is a short patch that illustrates the problem.

I have a VST synth receiving midievent messages generated from an algorithm
that is triggered by bangs from a metro 250.  It plays fine in real time
although, as you can guess, it drives up the cpu % substantially.  When I
put it into nonrealtime in DSPstatus the metro seems to tick very slowly. I
also tried metro~ with same results.

Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson


nonrealtime-sfrecord-metro-and-metro

> I have a VST synth receiving midievent messages generated from an algorithm

> that is triggered by bangs from a metro 250. It plays fine in real time

> although, as you can guess, it drives up the cpu % substantially. When I

> put it into nonrealtime in DSPstatus the metro seems to tick very slowly. I

To have scheduler events correctly timed in nonrealtime mode you have to 

put "scheduler in audointerrupt" on. Elsewise they are not synced...

Gary Lee Nelson wrote:
> I have a VST synth receiving midievent messages generated from an algorithm
> that is triggered by bangs from a metro 250.  It plays fine in real time
> although, as you can guess, it drives up the cpu % substantially.  When I
> put it into nonrealtime in DSPstatus the metro seems to tick very slowly. I
> also tried metro~ with same results.

To have scheduler events correctly timed in nonrealtime mode you have to 
put "scheduler in audointerrupt" on. Elsewise they are not synced...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


You have to know "scheduler in audo interrupt" does not work fine in 

nonrealtime mode (with sfplay~Z?). After a while, you'll notice a 

delay. I did not really had the time to check properly where the 

problem comes from, but there is a problem.

Hi,
You have to know "scheduler in audo interrupt" does not work fine in  
nonrealtime mode (with sfplay~Z?). After a while, you'll notice a  
delay. I did not really had the time to check properly where the  
problem comes from, but there is a problem.


Thanks Stefan. That did the trick with adstatus~ takeover = 1.

On 10/23/06 2:07 AM, "Stefan Tiedje" wrote:

>> I have a VST synth receiving midievent messages generated from an algorithm

>> that is triggered by bangs from a metro 250. It plays fine in real time

>> although, as you can guess, it drives up the cpu % substantially. When I

>> put it into nonrealtime in DSPstatus the metro seems to tick very slowly. I

> To have scheduler events correctly timed in nonrealtime mode you have to

> put "scheduler in audointerrupt" on. Elsewise they are not synced...

Thanks Stefan.  That did the trick with adstatus~ takeover = 1.

On 10/23/06 2:07 AM, "Stefan Tiedje"  wrote:

> Gary Lee Nelson wrote:
>> I have a VST synth receiving midievent messages generated from an algorithm
>> that is triggered by bangs from a metro 250.  It plays fine in real time
>> although, as you can guess, it drives up the cpu % substantially.  When I
>> put it into nonrealtime in DSPstatus the metro seems to tick very slowly. I
>> also tried metro~ with same results.
>
> To have scheduler events correctly timed in nonrealtime mode you have to
> put "scheduler in audointerrupt" on. Elsewise they are not synced...
>
> Stefan

I should have recalled this from my experience with render_node. I use

record~ into a buffer. That works fine and is very fast.

On 10/23/06 5:01 AM, "olivier pasquet" wrote:

> You have to know "scheduler in audo interrupt" does not work fine in

> nonrealtime mode (with sfplay~Z?). After a while, you'll notice a

> delay. I did not really had the time to check properly where the

> problem comes from, but there is a problem.

> _______________________________________________

https://cycling74.com/mailman/listinfo/maxmsp

I should have recalled this from my experience with render_node.  I use
record~ into a buffer.  That works fine and is very fast.

On 10/23/06 5:01 AM, "olivier pasquet"  wrote:

> Hi,
> You have to know "scheduler in audo interrupt" does not work fine in
> nonrealtime mode (with sfplay~Z?). After a while, you'll notice a
> delay. I did not really had the time to check properly where the
> problem comes from, but there is a problem.
> _______________________________________________
> maxmsp mailing list
> maxmsp@cycling74.com
> https://cycling74.com/mailman/listinfo/maxmsp

Nonrealtime sfrecord, metro and metro~