Hjalte Bested Møller

i've noticed quite a lot of weird behavoir in pluggos

if i try to sync a sync~ object to the beatcount of plugsync~ by 

it will not sync at all, it's like a bang is skipped once in a while ?? - also noticed this behavoir in many other situations...

sometimes recalling presets do not work like, when i'm in max... in max the presets is recalled perfectly, but in the host, something might not happen... like if i try to hook two pp's to a rangeslider, i understand the reason this could be trouble,- but i think it's weird, when it works perfectly in max ?

pictures wont always load in pluggos, even when properly included.... what is the best format to save pictures to use in pluggos ?

How is the threads prioritized in pluggo compared to max ? 

is overdrive possible ? is it always on ?

is scheduler in audio interrupt possible ?

what does the accurate message to plugconfig exactly do ?

most important question,- how do i ensure that the scheduler is in sync ?

the only way i've found to be safe so far is doing everything in audiorate ?

sorry for the many questions in this post, but answers to just one would be great ;)

-----------
plugsync~ :
if i try to sync a sync~ object to the beatcount of plugsync~ by 
[plugsync~]
   |
 [change]
   |
 [t b]
   |
 [sync~]

it will not sync at all, it's like a bang is skipped once in a while ?? - also noticed this behavoir in many other situations...
-----------
plugphasor~ is just jittering in logic

pictures wont always load in pluggos, even when properly included.... what is the best format to save pictures to use in pluggos ?
------------

How is the threads prioritized in pluggo compared to max ? 
is overdrive possible ? is it always on ?
is scheduler in audio interrupt possible ?
what does the accurate message to plugconfig exactly do ?

most important question,- how do i ensure that the scheduler is in sync ?
the only way i've found to be safe so far is doing everything in audiorate ?

sorry for the many questions in this post, but answers to just one would be great ;)


priorities-threads-in-pluggo

1. OS and Version information for Max/MSP and host applications is

2. Sample patches that demonstrate a problem will drastically 

likelihood of your perceived problem being identified, especially in 

where you're using language like "sometimes recalling presets...." or 

3. Have you taken a look at the "RunTime Issues" chapter of the

Pluggo Developer's Guide? You may find some helpful information

4. If you're working in Max 4.5 or beyond - we don't know that - you

might consider using the qlim object in situations where you have

multiple values being received while a higher-priority process is

running [i.e., the input is being deferred]. Using qlim with no args

will just output the most recent values [see the RefMan pages]. It's

useful in cases where you want to switch inputs to a low-priority

1. OS and Version information for Max/MSP and host applications is
very useful, as always.

2. Sample patches that demonstrate a problem will drastically  
increase the
likelihood of your perceived problem being identified, especially in  
cases
where you're using language like "sometimes recalling presets...." or  
"won't
always load...."

3. Have you taken a look at the "RunTime Issues" chapter of the
Pluggo Developer's Guide? You may find some helpful information
there.

4. If you're working in Max 4.5 or beyond - we don't know that - you
might consider using the qlim object in situations where you have
multiple values being received while a higher-priority process is
running [i.e., the input is being deferred]. Using qlim with no args
will just output the most recent values [see the RefMan pages]. It's
useful in cases where you want to switch inputs to a low-priority
thread during plug-in processing.


Quote: Gregory Taylor wrote on Thu, 06 July 2006 09:08

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

> 1. OS and Version information for Max/MSP and host applications is

G5 1.6 gHz, 1.5 gb ram & G4 Powerbook 867 mHz, 640 mb ram

> 2. Sample patches that demonstrate a problem will drastically 

> likelihood of your perceived problem being identified, especially in 

> where you're using language like "sometimes recalling presets...." or 

i'll post a patch showing the problem i'm having with presets, but it needs to be build & tested in a host, since everything works fine in max...

and sorry for my written English, i could be better, i know...

> 3. Have you taken a look at the "RunTime Issues" chapter of the

> Pluggo Developer's Guide? You may find some helpful information

yup, i have had all the information i found in this important chapter in mind, when building the plug-ins, i will look again to see if something was overlooked.

> 4. If you're working in Max 4.5 or beyond - we don't know that - you might consider using the qlim object in situations where you have multiple values being received while a higher-priority process is running [i.e., the input is being deferred]. Using qlim with no args will just output the most recent values [see the RefMan pages]. It's useful in cases where you want to switch inputs to a low-priority thread during plug-in processing.

thnx, i'll try using more qlim. I currently use deferlow for most situations like that, but maybe qlim is better, since it's only outputting the most recent value.

Quote: Gregory Taylor wrote on Thu, 06 July 2006 09:08
----------------------------------------------------
> 1. OS and Version information for Max/MSP and host applications is
> very useful, as always.

ohh year, here it is :
MaxMSP 4.57
Pluggo Junior 3.54
G5 1.6 gHz, 1.5 gb ram & G4 Powerbook 867 mHz, 640 mb ram
Logic Express 7.1
Ableton Live 5.01

> 2. Sample patches that demonstrate a problem will drastically  
> increase the
> likelihood of your perceived problem being identified, especially in  
> cases
> where you're using language like "sometimes recalling presets...." or  
> "won't
> always load...."

i'll post a patch showing the problem i'm having with presets, but it needs to be build & tested in a host, since everything works fine in max...
and sorry for my written English, i could be better, i know...

> 3. Have you taken a look at the "RunTime Issues" chapter of the
> Pluggo Developer's Guide? You may find some helpful information
> there.

> like if i try to hook two pp's to a rangeslider, i 

> understand the reason this could be trouble,- but i think it's weird, when it works perfectly in max ?

from what i know this should be legal in all situations.

(i.e. also in pluggo runtime which is nothing else but 

but we never know what certain host apps are doing to our

> How is the threads prioritized in pluggo compared to max ?

should be the same, correct me if i am wrong.

> is overdrive possible ? is it always on ?

> is scheduler in audio interrupt possible ?

no idea, but when i switch ASIO drivers in OS 9 or 

windows while cubase/nuendo plays (and yes that is 

possible), third party processes (such as messages 

in plug-ins) are stopped by the host anyway, only

> what does the accurate message to plugconfig exactly do ?

"accurate" knda locks the pluggo runtime sheduler to the

audio clock of the host app, there are people here which 

you probably only need this when you find out that you 

have timing issues in a plug-in during a high processor 

> most important question,- how do i ensure that the scheduler is in sync ?

> the only way i've found to be safe so far is doing everything in audiorate ?

the "audio sync" is controlled by the host - in all cases

of VST/AU/RTAS plug-ins - this is how the plug-in interfaces

about messages, see above (accurate or not accurate), i

am not an expert about this stuff, it is either at least 

half a vector size correct, or it is , well, i think we 

could say "like messages coming from somewhere else in 

max (i.e. with a chance to be delayed under high processor load.)

> like if i try to hook two pp's to a rangeslider, i 
> understand the reason this could be trouble,- but i think it's weird, when it works perfectly in max ?

from what i know this should be legal in all situations.
(i.e. also in pluggo runtime which is nothing else but 
a max runtime)

but we never know what certain host apps are doing to our
poor plug-ins.

> How is the threads prioritized in pluggo compared to max ? 

no idea, but when i switch ASIO drivers in OS 9 or 
windows while cubase/nuendo plays (and yes that is 
possible), third party processes (such as messages 
in plug-ins) are stopped by the host anyway, only
the hosts sheduler itself keeps running.

"accurate" knda locks the pluggo runtime sheduler to the
audio clock of the host app, there are people here which 
can explain  thatmuch better than me.

you probably only need this when you find out that you 
have timing issues in a plug-in during  a high processor 
load situation.

> most important question,- how do i ensure that the scheduler is in sync ?
> the only way i've found to be safe so far is doing everything in audiorate ?

the "audio sync" is controlled by the host - in all cases
of VST/AU/RTAS plug-ins - this is how the plug-in interfaces
work.
about messages, see above (accurate or not accurate), i
am not an expert about this stuff, it is either at least 
half a vector size correct, or it is , well, i think we 
could say "like messages coming from somewhere else in 
max (i.e. with a chance to be delayed under high processor load.)

> like if i try to hook two pp's to a rangeslider, i

We've done some work on pp for the upcoming versions of Pluggo and Max. After we release these, please let us know if if continues to be a problem.

> like if i try to hook two pp's to a rangeslider, i
> understand the reason this could be trouble,- but i think it's weird, when it works perfectly in max ?

We've done some work on pp for the upcoming versions of Pluggo and Max.  After we release these, please let us know if if continues to be a problem.

Priorities / Threads in Pluggo ??