phasor~ -synchronized system in MSP using rate~ getting out of sync, please help.

    Jul 22 2009 | 1:17 pm
    i have built a synchronization system with one 1hz phasor @ the top. with the rate~ object i synchronize every time based process in my patch. wich comes down to a couple of rates coming form the master phasor~ going to several other rates around the patch.
    my problem is that if my computer needs to think for a second because i'm loading some samples, opening another patch or whatever, the signals coming out of the rate~ objects get out of sync. i tried several sunc modes for the rate~ objects but they seem to block the whole process. i don't know why but just using the default seems to work the best.
    so i probably need a system wich syncs al the rates every cycle of the master phasor~ to that phasor again. or did i overlook something?

    • Jul 22 2009 | 7:19 pm
      it seems like i'm missing something when it comes to chaining multiple rate~ objects?
    • Jul 22 2009 | 8:37 pm
      Sending the [sync lock] message to rate~ makes it so that any change to rate~ re-syncs its ramp's start to the master phasor~'s start. Changing the rate from something above 1 (like 2) to something less than 1 (like 0.5) and back again may get the two rate~s out of sync with each other, but they'll still be synched to the master phasor~. Sending the message [reset] to rate~ will let you re-synch it so you could get multiple rate~s back in synch. It seems way easier now (to me anyway) to just use phasors~ with notevalues (assuming Max 5) and their lock attributes set to 1 and tie the whole thing to the global transport...assuming musical time values make sense in your patch.
    • Jul 22 2009 | 8:57 pm
      ok thanks, what i tried before is indeed using the sync lock message. but for some kind of reason, when i send all rate~s that sync lock message with a loadmess the rate~s don't work? but then if dsp needs to think(or something like that it occurs when i open an msp helpfile) they start to run all of a sudden.
    • Jul 22 2009 | 9:16 pm
      for some kind of reason this doesn't occure when i don't send the message to most upper rate~ in the chain wich is directly connected to the 1hz master phasor~.
      i don't get this.
    • Jul 22 2009 | 9:45 pm
      rate~ behaves in ways i can't find described anywhere. it seems that if msp hangs for a little moment (because of opening a patch, drawing/removing a new msp cable or making/deleting/editing an object) all rates get synced back up to the master phasor. is there more i should know?
      the main problem is is that there are different chains of rate~s in the patch wich i sync or de-sync during preformance by changing their phasoe and/or multiplier. when msp needs to thinks for a moment the relative relation between those rate~s should stay the same by not syncing up to a master phasor or just sync up at the same way so that relative relations stay the same.
    • Jul 22 2009 | 10:59 pm
      I would say that Lewis's suggestion is astute, although I don't see what's wrong with the default sync mode (off, aka. cycle) for your purpose. If you have it off, then the rate will just jump to whatever specified position it "was supposed to be at" before you disconnected it.
      I've verified this using a gate~ object.
      Hope this helps, jml
    • Jul 23 2009 | 12:19 am
      both sync modes 'off' and 'cycle' seem to sync up with the master phasor~ after a dropout?
    • Jul 23 2009 | 4:03 am
      I read back through your post.
      I think the ultimate answer is to suggest that you preload everything into buffer~s. Sorry if this is disappointing.
    • Jul 23 2009 | 9:11 am
      i don't understand the technique what you're talking about? what does it exactly mean?
    • Jul 23 2009 | 11:06 am
      would it be a good idea to use triangle~s instead of rate~s?
      i'd rather ask before trying 'cause i don't like to spend two hours resulting in nothing.
    • Jul 23 2009 | 11:26 am
      that's no option either, i need to change phase on the fly.
    • Jul 23 2009 | 2:14 pm
      i think jml meant you should load all of your audio files in to buffers so you don't get these little drop outs when you change things
      it would be interesting to see your patch, i've followed your topics for a while now as i've recently been finding more out about working with at audio rate
    • Jul 23 2009 | 10:49 pm
      i would really like to show you my patch but the problem is it's quite big and complex. i don't have time to spend several hours on documeting and changing the patch so people would understand. but i could post it tommorow as it is now with a couple of small instuctions if you wan't to give it a shot.
    • Jul 23 2009 | 11:36 pm
      And consequentially we won't have time to help you out. It's going to take much longer for us on-forum to figure out exactly what your problem is without specifics than it would for you to take the time off-forum.
      To clarify regarding buffer~s: Please read MSP Tutorial 16 and post back if you have specific questions.
    • Jul 24 2009 | 9:36 am
      yes i'm aware of that, if i don't figure out the problem this afternoon i will try to document my patch and post it on the forum.
      i read the tutorial you sugested but there's nothing i missed wich could help me here. i'm already using buffer's for storing my recorded soundfiles. i'm playing them back with play~ wich is driven by a phasor~, well actually a triangle~ wich is driven by a rate~ of the master phasor~. now there's another chain of two rate~s coming from the master phasor controlling a onebang kind of thing i made to control stop and start recording. when i recorded something these two are in sync, but when a little hangup occurs the two get out of sync wich means a new recording wil be totally out of sync wicth the peace of music.
    • Jul 24 2009 | 4:37 pm
      the solution seems to avoid using multiple rates together. but now i get these new problems with the F*$@##*ING object.
      why please tell me why do all rate~s go back to syncing up with the original phasor~ after a little hang up in msp, and why can't i set it off?
      or ok, i can work around that if that's the only problem. but then why do they get out of sync in sync lock mode when they get the same new multiplier at the same time?
      there are things i just don't can't get my head around. is there a good alternative for rate~ maybe?
    • Jul 25 2009 | 2:10 pm
      I can't reproduce the re-synching you describe when creating new objects, replacing buffers or editing MSP patch cords. MSP always makes an audible "click" when creating new MSP objects while audio processing is on but using scope~ I can't see it effecting the position of rate~s output ramp. I've made lots of patches with a single master phasor~ being read by tons of rates~ and never had the problems you describe. I don't think I've ever cascaded one rate~ into another though so maybe that's got something to do with it? If you could extract just the phasor/rate portion of your patch (whatever the smallest bit is that will misbehave) and post it that might help us troubleshoot. Also, what OS and Max version are you using? Maybe it was fixed in an update or is a windows problem? I'm on OSX10.5.6 Max/MSP/Jitter 5.0.7. Could your patch work with only phasor~s using the musical time values and the global transport?
    • Jul 26 2009 | 12:00 pm
      I'll try and isolate the re-syncing problem this afternoon. I'm on max/msp/jitter 5.0.7 and osx 10.5.7 on a may 2009 unibody MBP. would you think using a master phasor~ with musical time values would help? it would be possible but it's not easy.
    • Jul 26 2009 | 8:31 pm
      i tried using the musical time values for my master phasor~ and it solved pretty much everything except the thing that when MSP hangs for a moment the phasor doesn't go further where it was supposed to be. after a little hangup it rate~ immediately syncs tot he phasor~.
      hereby a little patch wich shows my problem. when you let MSP hang for a moment you can see the rate~ object immediately syncing up with the phasor~ in the scope~s. by hanging up i mean copying a MSP object, opening a MSP help file pr just add or delete a MSP patchline. i think it's essential you have overdrive on and 'in audio interrupt' checked. (wich is also essential for another part of my patch.)
      i'd would like to set this off if posible or at least have some kind of control when this happens being able to delay it for instance.
    • Jul 28 2009 | 8:15 pm
      I've modified your patch along with comments. Keep in mind that the default state of rate~ is sync "off". I think your problems would be very easily avoided if you'd lock the patcher and reset the phase. See patch for more info and let me know if this has helped.
    • Jul 28 2009 | 10:25 pm
      Yea, I see what you mean now. I think the solution is to not edit your patch or open new ones while using your patch (loading new samples into buffers does not cause the re-synching). There's something about the MSP scheduler having to re-compile every time a new object or patch cord is created or deleted which is systemic to how MSP functions. The way rate~ interacts with the scheduler must necessitate it re-synching.
    • Jul 29 2009 | 4:21 am
      a few more suggestions:
      --when you have opened your patch, tell sfrecord~ (for example) to open a file and designate the location.
      --after this, you can proceed to turn the audio on and click a toggle in order to initiate recording. the benefit of forcing this order is that you're guaranteed to start recording *after* DSP has commenced.
      --another workaround would be to NOT use max for recording and pipe the audio out via soundflower to another app. yet another way would be to use an external recording device.
      in this way i would imagine you could avoid every one of the aforementioned situations (what i'm guessing is that it's not just one, but a combination of things that have led to these hiccups).
      i would also recommend (when you have more time) that you read this article by Joshua from '04:
      pay especially close attention to the bits about low priority vs. high and the difference between the max scheduler and an audio thread in which DSP is calculated.
    • Jul 29 2009 | 9:41 am
      thanks for the article. unfortunately none of you're suggestions would work for me, the recording process is a very important process for me since it's there for live sampling external and internal audio. i record things all the time during performance. if the hiccups will only occur at times i diagnosed it won't happen during performance. i was wondering if it could be controlled or set in some kind of way to avoid risks.