Forums > MaxMSP

Transport vs Signal


Mar 06 2009 | 12:35 am

Months ago I decided I should modify all my tempo oriented patches to run off a phasor instead of a metro.

Except now that I have Max 5 and [transport], I’ve been told that its clock has been improved so much that it is not necessary.
I know it’s a very broad question but I was wondering what people’s opinions on this are.

Mar 06 2009 | 1:28 am

i could still go either way. for amp-windowing functions and high-signal-accuracy, phasor~ is always best. but transport’s got all the great internal messaging… i guess, all in all, if you were to use transport, link different phasor~s to the transport(ya know… something like:

…), and possibly manipulate the phasor~ further with rate~(i heard there was an issue long ago using rate~ with a locked phasor~ but hopefully no longer?…) to get beat-subdivisions/multiples, then that’s probably the best of both worlds.

Mar 06 2009 | 2:12 am

[transport] is operating in the scheduler thread, a high-priority thread, dealing with things like midi, bangs coming from [metro], and such. It is high-priority compared to the main thread dealing with redrawing the screen for instance. But the perform thread, the one given the highest priority, deals with MSP audio processing. So, if you need sample precision, it’s wise to keep your signal-based tools.
On the other hand, if you need more flexibility while programming, and you are happy with the results of [transport] on your system, why bother with signal-based constructions that may be more difficult to debug?
Jean-François.

Mar 06 2009 | 2:44 am

ya, what he said… wise words.
but also… here’s a patch showing how if you need clock triggers, you can get them from the transport, and then if you need signal-accurate windowing functions etc. you can still get them synced to transport via a transport-locked phasor~:

— Pasted Max Patch, click to expand. —

my only qualm is that you can’t link a phasor~ to just any transport via the "@transport" attribute argument like with metro. so i can’t keep separate transports from the global one in the case of phasor~ if i want them(what if i have two patches with transport-synced phasor~s and i DON’T want them synced to the same transport? what then?!!! just kidding, i don’t really mind, but it’s something to think about…)

Mar 06 2009 | 9:08 pm
RabidRaja wrote on Thu, 05 March 2009 18:44
ya, what he said… wise words.
but also… here’s a patch showing how if you need clock triggers, you can get them from the transport, and then if you need signal-accurate windowing functions etc. you can still get them synced to transport via a transport-locked phasor~:

Does slaving the signal timer to a scheduler object seem backwards to anybody else?

mz

Mar 06 2009 | 10:31 pm

Maybe the [transport] system is internally locked to the perform thread (MSP), then just rendered into the scheduler. At least, it should be when overdrive is on. Otherwise, yes, that sounds weird.
transport experts around?

Mar 07 2009 | 6:00 am

…now that you put it that way, it certainly does, but if you have an accurate enough scheduler, it’s handy to separate a clock function from a signal-rate LFO function while keeping them synced to the clock… plus, i assume that the MSP signal-thread doesn’t "slave" to the scheduler-thread(is that even possible considering the notion of a sample-rate?)… so the signal resolution within the scheduler’s timing scheme is a great asset.

(of course, i say all this, and meanwhile i’ve yet to use the transport in my own patches, but maybe signal-clocks are just the old way and i’m too stuck on phasor~) < -thanks to the tilde of signal-objects, i've just closed my parentheses with the ascii symbol of a butt-crack(just thought i'd point that out)

Mar 07 2009 | 11:59 am

http://www.cycling74.com/story/2008/7/15/122424/991

"This is only your memory…. I can’t give you any new information."
(-Johnny Cash as the voice of ‘Space-Coyote’ in The Simpsons Episode, "El Viaje Misterioso De Nuestro Jomer")

Viewing 8 posts - 1 through 8 (of 8 total)

Forums > MaxMSP