Forums > MaxMSP

Change the speed of which all messages in a patch are handled?

June 25, 2013 | 4:33 am

I don’t know wether this is even remotely possible, but could i change the speed of which all messages in a patch are handled?

I’m building an editor for a hardware synth. I included all sorts of randomisation features in the patch which send out a whole lot of midi data at once. I’ve got the feeling the synth can’t handle so much information at the same time, resulting in poor performance (e.g.. not all data that was sent to the synth, was actually dealt with)

So i thought slowing down the whole process might resolve this..

any tips regarding this?

cheers,

synnys


June 25, 2013 | 5:20 am

[speedlim] for each data stream (ie not whole patch)
i guess you could alter max’s default scheduler update time by sneding geteventinterval seteventintervla to the Max application (see Max help>vignettes>core>advanced max topics>messages to max), but that’s highly unrecommended… (see also "advanced scheduler settings")


June 25, 2013 | 5:23 am

i’ve got about 80 streams, i now tried using the [pipe] object by incrementing each pipe object by 10ms but this far from ideal since the biggest delay would be round 800ms and i don’t want automation to be delayed.

i’ll look into the ‘speedlim’ thanks,


June 25, 2013 | 5:58 am

[pipe] will do no good i think, since iirc it will only introduce an initial delay and if it’s a stream it won’t have an influence on the stream speed, which is your problem here, ; so maybe [speedlim] is a btter solution.


June 25, 2013 | 6:12 am

I never tried this myself, but wouldn’t a poly~ with local scheduling and downsampling help in your case? It may be easier than slowing down your 80 streams.

p


June 25, 2013 | 6:47 am

well it’s not really a continuous stream, so pipe actually does help a lot.

it’s an editor for the waldorf pulse. so when i hit my randomise button, it sends midi values of all the parameters at once.

Now using a pipe solves this kind of, by delaying each parameter by a different interval.

But now my problem is that each parameter has a delay :D

So ideally i’d like to make something that would:

- delay the value, if the object sending that value, is triggered by a bang
- not delay the value, if the object sending that value, is triggered by me. (meaning actually turning the knob/dial on screen) or by ableton live (when i wanna do automation for example)



dtr
June 25, 2013 | 7:29 am

Speedlim will not help because some messages will not be sent.

You might be able to do it by delaying each stream by a calculated time so that they don’t overlap but what you actually want is a message cue that’s being processed at a settable speed.

I’d advise cooking up something with a [coll] in which you first store all the messages to be sent. Then iterate through the entries, sending each with a timing parameter. Clear the coll when done (or each entry after it’s sent).

Edit: there might very well be this kind of solution floating around somewhere, as a patch or external


June 25, 2013 | 10:20 am

You could send all messages through a common [zl queue] object triggered continuously with [metro 10]. So when sending all parameters at once they will be output at safe intervals of 10ms and when sending individually there is just a delay of 10ms. Probably [metro 1] would work too, for minimal delay.


June 25, 2013 | 11:08 am

zl queue is brilliant for this – it might work well for that other guy that was overloading his lemur, too.


June 25, 2013 | 11:29 am

[ZL QUEUE] sounds promising! thanks!

Back to the drawing table….


June 26, 2013 | 6:28 am

Just found that [zl queue] can also be triggered from the right outlet, ie. no metro needed.

<code>

– Pasted Max Patch, click to expand. –

</code>


June 26, 2013 | 12:21 pm

you could make the generation of the data already dependent on triggers, so that the speed of the data output is not controlled by the scheduler but a [metro 10.]


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