Priorities / Threads in Pluggo ??


    Jul 06 2006 | 7:16 am
    i've noticed quite a lot of weird behavoir in pluggos
    ----------- 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
    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 ;)

    • Jul 06 2006 | 1:08 pm
      A couple of things come to mind:
      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.
    • Jul 06 2006 | 7:40 pm
    • Jul 07 2006 | 6:46 am
      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.
      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.
      Thank you Gregory
    • Jul 07 2006 | 6:10 pm
      > 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 ?
      should be the same, correct me if i am wrong.
      > is overdrive possible ? is it always on ?
      ?s 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 the hosts sheduler itself keeps running.
      > 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 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.)
      always in sync: -110.
    • Jul 07 2006 | 8:22 pm
      > 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.
      -Tim