synnys

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..

change-the-speed-of-which-all-messages-in-a-patch-are-handled

[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")

[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")


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.

[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.

I never tried this myself, but wouldn't a 

 with local scheduling and downsampling help in your case? It may be easier than slowing down your 80 streams.

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.

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)

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. 

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


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

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


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.

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

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

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.]

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