the ins and outs of rates in M4L
Hey!
So trying to find the absolute fastest rate (not sure how, exactly to put it into proper terms). So far I have just used the live.observer looking at the track time property (giving a float), and then attaching a bang to that gain a 'tick'. After some scurring around the interweb I believe I should be using the phasor~ object at a very high hz (22050 maybe?!) [kinda my first time diving into the msp sector].. I have that attached to a number~ .. After glancing at the results it has me curious since it seems to look very similiar to the 'live.observer(current_song_time) -> to a 'tick' combo , (haven't compared print, prolly should).. but that leads me to my first pondering which seems.. rATES!, is the fastest in m4l determine by ableton? or can I assume that what I read about max/msp correlates to m4l (don't have max). does the max window print entirely everything (running into an instance with using midi and midi talking, and communication errors when it seems to me that midi signals have been parsed at the exactly the same time, but the print still shows the signals to both be there..)
..but the real questions. What is the fastest rate/how to do i accomplish that ? (tick, bang, like said, don't how to label it....?) Kinda any explanation on rates, msp vs max.. terminology would be much appreciated.. set rant_ended_lol 1
> What is the fastest rate/how to do i accomplish that ?
In M4L there are different rates for different things. So what exactly do you want to accomplish?
I wanna know all of them..
It's highly unclear what you need this for. Especially when you mention MIDI which is a lot slower than the maximum rate Max can do.
Anyway, the 'fastest' rate depends on whether you're working in MSP audio or Max message domain. In the audio domain it would be the sample rate divided by the DSP's signal vector size. Example: 44000hz / 64 = 687,5hz. This depends on your DSP settings. Of course a lot of things are calculated on per sample basis, so at 44000hz, but it's output in blocks of the given signal vector size.
In the message domain a metro can run as fast as 1000hz (1ms interval). Whether Max can really keep up that rate depends on the actions triggered by that metro. If processing is too heavy it will lag behind. If using qmetro instead of metro Max will drop actions to keep up with the set metro interval when overloaded.
(Btw, this is all based on my personal understanding of the matter. Anyone please correct me if I'm wrong.)
Now for testing these matters you shouldn't be using print. Printing messages to the Max window take a lot of CPU time and will not give reliable info if printing at these high rates. If you could be more concrete about your goals we can advise on an effective method for testing and measuring.
About the timing of midi messages, they can never occur at the exact same time. It might perceivably seem so but computationally they will always be sequential.