zl.reg

the message objects does a lot, not only it has up to 9 arguments, these arguments also can be of variable type, and it accepts messages such as "append" and "prepend". i once wrote one, but it is much slower than the original.

zl.reg doesn't work unless it's cleared before every new sysex message comes in. The advantage of using the regular message object is that it takes in a whole sysex message and then clears itself again as each new sysex message arrives. zl.reg just keeps accumulating messages and then wants to send them all out at once. I thought of using zl.stack but that just sends the sysex back out one byte at a time in reverse order!

What I don't like about using message is that it constantly wants to keep changing size to fit all the message in - not really ideal when sysex messages can be all sorts of lengths! (And Roman will know why that will annoy me! Makes my ultra-neat patches look messy! 😂🤣😂)

Hi, what do you mean with zl.reg accumulating? [value] is also able to store lists but may be less performant.

The problem I have is that the mixer control software I’m using (Mixing-Station) to interface my array of 4 X-Touch controller units to my X32 Rack mixer sends out updates for the scribble strip colours in rapid bursts of 8 sysex messages.

Each message has 8 bytes that determine the colour of each of the 8 LCD screenlets on the X-Touch. For whatever reason (and interestingly CuBase does exactly the same), rather than set all 8 LCD screenlet colours in one message, the software sends 8 messages changing the colours one screenlet at a time from left to right.

What I have discovered is that the X-Touch can’t process all the messages as fast as they are being sent and so some of the screenlets on the right hand channels end up with the wrong colours.

The solution is to use Max to detect the colour messages (byte six in the sysex message) and then resend the last one, which has the correct colours for all 8 screenlets, to arrive after a 50ms delay, by which time the X-Touch has caught up and can process it properly.

Message is ideal for this as it only holds the last complete message it receives via its right inlet but the object constantly changes size according to the message lengths - messy!

zl.reg keeps adding each message on to the end of the others it’s already stored, and then wants to send the whole lot out in one go - just as bad as the original problem!

I just wanted to know if there was a direct replacement for the regular message object that did exactly the same in an object box of fixed size without displaying its contents.

I guess value would work if it only stores the last message it is sent.

I can't reproduce that with zl.reg. for me it works like message. Only stores the last message received in right inlet.

Ok. I’ll try it again tomorrow. Maybe the Mac and Windows versions are different as it didn’t work when I tried it earlier.

zl.reg does what you want. What are you doing to the poor little zl.reg? I've never seen one accumulating input data. Maybe try a fresh one. — Regarding the speed problem: Once I had random bursts of lists and needed a sequenced output. Could solve that by a 'buffer' made of [coll]. Data gets numbered and stored in a coll and a metro shoots the first (or last) line out and deletes it in a steady pace. When the coll is empty, nothing happens. I think it is best done with two named colls, one for collection and one for output.

You could encapsulate the message object to keep it tidy. You could even give it an appropriate name like "mess". :-)

(Like you, Andy, I like patches tidy, too. I find 'em much easier to understand.)

Well isn't that just typical of IT work?! Yesterday zl.reg didn't work as I expected - today it does!

Thanks for all the suggestions though.

I've tried six times now to explain how I use coll objects like RAM in my current project but I'm feeling off colour today and I keep loosing what I've typed so you'll have to use your imagination! ;-)

if you never need more than 2 messages at a time to be processed (i.e. not more than 1 to be buffered), [speedlim] does that, too.

The irony here is that I want everything to pass through as fast as possible with the sole exception of this one single sysex message!

Well, it almost worked but I was still getting spurious instances where the right hand channel of the fourth unit was still getting dodgy data. So I've followed @Peter Ostry's hint and created coll based stacks. This definitely works. It's now just a question of paring the timing back until it's as fast as it can go without the problem coming back:

I've created a temporary send object with the white connectors so that I can control the timing factor from the main interface until I can find a stable value under all working conditions - so far it appears that 6-7ms is reliable.

Yeah. White connectors are the fastest.

pink!

I did a quick test and in slow motion you can see that white connectors are faster than black ones but transparent connectors win because they have a fiber optic characteristic. If you make a double connection with them, you can't even see the bang travel anymore.

Ha ha! Brilliant!

he did not even try pink ones casue he knows they would win.

I reckon that they're there but they are so fast they are invisible!