Very simple [uzi] problem...

Brian H.'s icon

Hi,
Am I not getting something pretty basic about slowing-down [uzi] just a bit with [pipe]? Is it just plain too fast for other objects sometimes? It seems to be treating these individual ints as a list. I'd rather use something more compact for this little job, than get into something [counter] > [zl.queue], etc., so I can get on to the big jobs!

Max Patch
Copy patch and select New From Clipboard in Max.

Thanks,
Brian

Bill 2's icon

G'day Brian, AFAIK [pipe] would just delay the super-fast stream of of numbers from [uzi]; it wouldn't actually slow them down. Can't think of any object that would, but maybe someone else can?

If some objects treat the fast stream of numbers as a list, would [iter] maybe fix that?

Otherwise you might have to use a few objects. [counter], a [metro] to not only trigger numbers from [counter] but also control their speed, and maybe a [gate] or something. (I haven't worked it out, but they'd probably be the essentials.)

If you still want it all to be compact, just encapsulate all the objects. Don't give the encapsulation a name and it'll be even smaller than [uzi 127]. ;-)

leafcutter's icon

Which objects is uzi too fast for? Post a patch of your actual problem.

Christopher Dobrian's icon
Max Patch
Copy patch and select New From Clipboard in Max.

I think it works best to think of uzi as operating "in no time at all", since that's pretty much what it does. It sends out its numbers and bangs in a very specific order, as fast as possible, all within a single tick of the scheduler, before anything else happens. Thus, it's good for when you need to freeze time for an instant while accomplishing a bunch of things. If, on the other hand, you want things to happen quickly but with a certain known interval of time between them, it's better to use an object that schedules events in the future, such as metro (or, in some cases, pipe). There are presumably a few cases one can imagine when you'd need to create timed events super-fast, like once every millisecond, but as a rule I think it's best to try to avoid that. Either figure out the way to do what you want in an instant using uzi, or use timed events to make things happen at "musical" time intervals (such as 125 ms, say), or framerate intervals (such as 33.333 ms), etc. If you need things to happen every millisecond (which, after all, is 1000 Hz, an audio rate, not really an event rate) you should probably be doing it in the audio signal domain with MSP.