it seems like i'm missing something when it comes to chaining multiple rate~ objects?

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.

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.

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.

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.

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

both sync modes 'off' and 'cycle' seem to sync up with the master phasor~ after a dropout?

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.

jml

i don't understand the technique what you're talking about? what does it exactly mean?

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.

that's no option either, i need to change phase on the fly.

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

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.

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.

jml

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.

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?

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?

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.

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.

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.

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.

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:https://cycling74.com/story/2005/5/2/133649/9742

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.

jml

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.