Hi,
I would like to connect 3 box numbers to a message box, so that the three numbers appear as a list within the message, like in this example:

But I don't remember how to do it anymore...
Any tips?

Thank you,
a.

@atux We can also use list objects for this which frees you from the dollar arguments and need of clearing the message with a [set( which means the length of the list is not fixed and can make it much easier to construct complex messages especially when [list store] gets added into the mix where we can us its methods to change single elements without recreating the entire message on each change.

@oid said:

Hi,
however the same behavior remains: if I vary the first box number, it also varies in the message box; but if I vary the second or third, they do not vary in the message (in real time) unless I put a bang above the first box number.

Message.pd

Thank you,

a.

@atux Sure, I was addressing the original issue. Here it is with [list store] which gives a cleaner patch than [pack] and the two extra [t b f]s required, possibly at a tiny cost of a couple cpu cycles.

@oid said:

Thanks, it works well, very nice. I attach the patch here if anyone wants to try it.
Message_2.pd

Bye,
a.

And I will mention one of the handy aspects of [list store] in this sort of setup, it provides an easy and elegant way to grab a single element without storing it or unpacking the entire list or manipulating messages which generally is not a problem when the list is just three elements but can get messy for larger lists.

@atux You seem to have it fixed...... but just for info.....
I didn't realise that you wanted the second and third inputs to update the list, but If you want any input to [pack] to trigger a new list then for your original method you simply need to trigger the left input for all inputs like this...... a standard method......
David.

@whale-av said:

Cool, it works perfectly. I'll attach your patch here.
Maybe it's also faster in terms of CPU (compared to that of oid), is that right?
Message_3.pd

Thank you,
a.

@atux Difference in speed will be tiny, easy enough to test but generally academic on modern computers. For this sort of thing I generally go with what results in the neatest and easiest to read patch and rarely if ever get bitten when it is something so simple. If this is going to be an abstraction which you will be having hundreds of instances of then it can be worth counting those cpu cycles otherwise you can just be aware of the various possible solutions and pick the one you like best for what ever reason.

Most of the time when you start hitting the wall and experience audio drop outs or the like you would be better off sticking your audio in another thread with [pd~] then trying to find ways to save a few cycles, you are just going to hit that wall again when you start changing things. Still good to look for way to improve efficiency but generally you will get larger gains looking at the overall methodology of the patch instead of the minutiae.

if you can use externals, here's a convenient patch