Forums > MaxMSP

Transport vs Signal

March 6, 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.


March 6, 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.


March 6, 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.


March 6, 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…)


March 6, 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


March 6, 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?


March 7, 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)


March 7, 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)