Holiday notice: Cycling '74 will be closed Monday, October 9th. Manual authorization, support cases, and manual order processing will be delayed.
Change the speed of which all messages in a patch are handled?
Jun 25 2013 | 11: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
- Jun 25 2013 | 12:20 pm[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")
- Jun 25 2013 | 12:23 pmi'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,
- Jun 25 2013 | 12:58 pm[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.
- Jun 25 2013 | 1:12 pmI 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
- Jun 25 2013 | 1:47 pmwell 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 :DSo 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)
- Jun 25 2013 | 2:29 pmSpeedlim 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
- Jun 25 2013 | 5:20 pmYou 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.
- Jun 25 2013 | 6:08 pmzl queue is brilliant for this - it might work well for that other guy that was overloading his lemur, too.
- Jun 25 2013 | 6:29 pm[ZL QUEUE] sounds promising! thanks!Back to the drawing table....
- Jun 26 2013 | 1:28 pmJust found that [zl queue] can also be triggered from the right outlet, ie. no metro needed.
- Jun 26 2013 | 7:21 pmyou 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.]
