Limiting the speed of messages (while retaining all the information)?
So I'm starting to program for my Softstep (amazing footpedal!) and it seems that it doesn't like receiving LED message too quickly.
The way the implementation works, in order to change a single LED state, you have to send 3 pairs of CC messages (40 1, 41 1, 42 3). If you try to turn off an LED and then turn on the next one (by sending 6 short lists) the messages get clipped by the firmware (or something) but basically you get erratic LED behavior (neighboring LEDs turning on/off).
Some people have figured out some workarounds where you send the 3 CC pairs followed by an empty/dummy message (0 0, 0 0, 0 0), to add some 'buffer' time between messages, but I want to see if there's a way of just limited the data rate overall.
The objects I know for this kind of thing (del, pipe, speedlim) aren't suitable as they keep the rate of information the same (pipe) or throw out data (speedlim). Is there a way to keep all the information but make it so that you only send one pair of numbers every 1ms or whatever (so sending it a long list still sends all the data, but it will take a bit to go through).
I guess it's not the most elegant solution, but it might do the trick.
HTH
maybe i'm missunderstanding but i think pipe can do it. every input pair can have it's own delaytime. but i don't know how big pipe's maximum buffer is..
O.
The messages wouldn't be very long though I guess there's a danger of it backing up if the delay is slow enough.
I'm thinking something like a 1ms, just to not have all the messages fly in at once, but still having it be fast.
With your example (@11) is there a danger of [del] not counting at the same rate as pipe (leaving stray/dangling messages)?
Hey,
the [del] this was just an idea how to check if the incoming rate is to fast. the time needs to be higher than the time factor ms for pipe or the del will override the thing.
isn't there this limitation of 2ms minimum timing in max. somehow because the sheduler works in 2ms steps.??
if 1 ms works then why not use it as timefactor for the pipe-delaytime in my example. the delay is not impßortant, use your own way to reset the counter between
2 rapid shots.
O.
This seems like it should work but it doesnt. It sends two lists clumped together then iterates the rest.
yup
a counter resets autom. to 0 if it reaches maximum and you send it another reset with the carry flag so pipe gets 0 as delaytime two times. just remove the carry flag connection to the "0" message. this works if your messages will alway have 6 parts. time to sleep for me..
O.
Here's a solution using [bag] as the central player. I had the same problem with a MIDI device and this abstraction seemed to fix it reliably. If you have 2-element messages coming in too quickly, you can slow the stream down without losing any data. You can change the 'stagger time' in ms (this patch defaults to 25ms) with the right inlet. Shouldn't be too tricky to adapt it according to your needs.
I think if you want full control over "bursts" of messages it is best to store them all and send them out at desired speed.
Just an idea:
Number the 2-element pairs automatically, store them in a [coll] according to the numbers. Then ask for the length of the coll and set this as the maximum of a counter. Start a [metro] and feed the counter's output to the [coll] where the stored messages are. This sends them out at an appropriate speed.
Of course you have to reset the counter and clear the [coll] before or after each run.
I have not tried this but it should work. There is a problem though – as long as the process runs, you must not accept new messages.
@Terry that works really well though it doesn't seem to like repeated entries? (see below).
OK, that functionality was required when I first made the patch. for your purposes you just need to add a non-numerical argument to bag to alter its behaviour so that it stores duplicates, or repeated values. the patch below fixes that problem (I just added a '-' arg to bag as is done in the help file):
This thread is quite amazing.
Somebody has provided a simple solution and everybody else tries to make it more complicated.
Using a metro-based system might be funky since it would need to happen very fast, and often (so there's be a fast metro running the whole time)
@Rodrigo. I don't suppose youve considered contacting the makers of your pedal and ask them to fix it. They ought to be buffering incoming midi messages better
if yps perfect example (or vanillas even more slowening modification) does not work, none does and you have a hardware problem.
i was just replying to correct what rodrigo wrote: "pipe isn't suitable for that".
Yeah it's not perfect on the hardware side. It works fine with the software that comes with it or in standalone mode, the problems are for the recently released SDK where I'm communicating directly to the LEDs.
The bigger hardware problem people have been running into with the softstep (outside the scope of this thread) is the induction noise created by the internal backlight.
From Rodrigo:
Using a metro-based system might be funky since it would need to happen very fast
I just tried this coll/counter/metro thing I mentioned and it works. [metro 15] is the highest speed, anything below is too fast for my SoftStep. Means 3 seconds for 200 messages and then it stops unless you want custom blinking frequencies for the LEDs. But honestly, I would not use that or any of the suggested patches. Adding 6 zeros after every third CC message does the job without much programming or timing problems.
From xidance:
if yps perfect example (or vanillas even more slowening modification) does not work, none does and you have a hardware problem.
Firmware or hardware problem, yes. And only for a particular function. But there are several possible solutions and slowing down the MIDI stream is one of them.
I was wondering if it would be better to just limit the stuff rather than sending the dummy messages, but I guess it's more about what works working than doing something the 'right way'.
Rodrigo, finally I found out what causes the problem and will tell you the details in the KMI forum.
In short:
We don't have a general speed problem, the buffer of the SoftStep is ok. But the 3 consecutive CCs necessary for LED messages are not quickly enough identified by the firmware. Slowing everything down would just make things slower overall. The issue is to separate the groups of 3 CCs by putting a pause between them. But there is no need to program "chunks of 3 CCs plus a pause" in Max. Appending a long dummy message is enough until the firmware problem gets fixed (if ever).
This is an interesting thread here, though. Thank you all for your ideas how to make a number stream slower.
Wow wish I had searched for this sooner - just spent an hour going over the same issue with the same consideration: I can make it work with a zl.queue + metro but it seems a bit heavy-handed, other solutions seem even more heavy.
talking of SoftStep, I decided to start using the SoftStep in 'Standalone' mode: so it only sends out what I need and I don't have to interpret all the sensor data in Max. You can still update LED and display state through sending ctl messages, even though the softstep is in standalone - it seems a little leaner this way.
firmware update.. I wouldn't get my hopes up. I reported in April 2011 that the softstep can't send out midi note '0' in standalone mode, no change in over a year: we'll need the workarounds!
not sure if this is of any use or most elegant, but anyhow - here's a way of delaying multiple lists:
Here's my way to delay a fast stream of midi notes/cc's. Had this problem myself, the patches provided above gave me an idea for a simpler approach.
Well, thanks Floating Point,
I made a patch with your version that only needs to add arguments for the max quantity of numbers needed using scripting... just save this patch to your project folder with name losslesspipe and call it like this: [losslesspipe ms #]
ms = how much delay in ms (default 1), can be changed on 2nd inlet
# = how many numbers in the list (default 1)
it was fun to do this...