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.
Enter numbers from number boxes to a message box
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 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
is there a way to make the message not output anything stored from pack unless a bang hits? i don't want it to trigger every time values get changed.
@rosemyxine Just use the first f of the pack for the bang and follow it with a [list split 1] or a [$2 $3 ...(
Oops! Looks like something went wrong!