My group is in the process of programming a PureData code that reacts to buttons and an IMU sensor connected to an Arduino.

The buttons send values from 0-7 (0 always being the LOW state), currently we have sorted the list of incoming values by ascending order (so 0000001 or 0000012). However, we want to control the nth value of the incoming numbers because we want it to look more like (1000007 or 1200007).

We've looked everywhere and tried almost all of the objects in the PureData object list. Do you have any suggestions? (I have attached our current code). Plswork.pd

@Chitch I think you will find it very difficult to work with the values as you want them to "look".
Pd works very well with "lists" which can then be routed (filtered) and sorted.
I would suggest "tagging" the incoming values with a list header using [list prepend] (or if you are using Pd extended....... [prepend].....) once you have split the incoming list with [unpack]

They would then "look" like "list 1 7" or "list 12 7"

But maybe I am not understanding you well....?
Especially as you are then sorting the button values into ascending order.
Is it that you want to sort them in ascending order, but still know from which button they were sent?

The [pack] in [pd serial] does not pack for me...... it needs a bang once all the data is set.

If you really do want values like 1000007 and 1200007 you can simply add 1000000 or 1200000 to the incoming data once you have separated it into the component "button" atoms.... maybe?

I see @weightless is on your case. As he says, a sample incoming message string would be useful!
And a description of that string, and how you want to use it as well..... if possible.
David.

@weightless Yes, Arduino sends the state of each button to the Pure Data patch; 0 if it is not being pressed and the number assigned to the button when it is pressed (e.g 1 is assigned to 1, 2 is 2 and so forth).

We are using 7 buttons and one accelerometer that sends three values. While the accelerometer works just fine, we want to always print the buttons values in the correct position, so that 1 will always be on the first spot, the 2 on the second one and so on rather than just in a ascending way.

@whale-av an example of what the message would look like if button 3, 4 and 5 were pressed would be 0034500 rather than 0000345 as it does now, with the highest number always being on the last spot. Instead we want 5 in the fifth spot, 4 in the fourth spot and so forth for every button. Does it make more sense now?

@Chitch Maybe.....
Replace [list-sort asc]............ new_sort_asc.pd
I am assuming you have [list-drip]

And connect it directly to the inlet of [pd serial]
It will need modification if your list is actually 10 atoms long (should be obvious).
David.
@LiamG It looks as though it's a list of floats in the patch. The OP has posted it as a number..... but I don't think that is correct.
There has to be an easier way, but I cannot see it straight away. There might be a [list] object already.

You might want to consider doing this with an array instead of a list. It's very easy to set and retrieve individual elements using [array set] and [array get], and once it's set you can reference the same array from anywhere.

But if you need to be working with lists for some reason, you could pack the numbers and then force them into a symbol like this:

It's not going to be easy to work with the output though, since it's a symbol not a float. As David mentioned, all floats will be truncated to get rid of redundant zeros.

@whale-av Your suggestion prints out the values exactly how we wanted them to, but only button 1 seems to work now :/ . Does anyone have any idea why that could be? I've attached my current Plswork.pd code to this reply.

@Chitch Yes, all the buttons are working, but [unpack] unpacks from right to left.
All... (except one that I cannot remember) Pd objects "execute" right first left last.
So the other [==] logic objects receive their correct number, followed by the incorrect number.... they output 1 followed immediately by a few 0's....... (tip.. put a print on one to see!).

As the output is already sorted...... 1 2 3 4 5 6 7...... you can connect directly and you don't need your spiders web.
If I get a chance I will reduce your patch to the minimum required, so check back occasionaly even if you don't need to.
I hope that was understandable.
Check out ......... http://puredata.info/docs/manuals/pd/x2.htm
It is great bedtime reading....!
David.
PS..... this will work...... code2.pd It might not take account of the other 3 pieces of the list properly though. I do not know how to deal with them, as I do not know what they look like. I changed the connecting outlet of [moses 9] which might help.
Could you post a couple of samples of what you get from the outlet of [repack 10]....?
And what the translation should be for reverb etc.

@whale-av Thank you so much, David! Your code works great now What I did was to simply create another [t a b] object that connected the inlet to the [moses 9] to access the accelerometer values. And yeah, we really weaved a web bigger than Charlotte's in our code

@Chitch That's great !!
You are going to need a trigger here as well........

As I noticed that unless the same note is triggered twice it will not sound.
Probably (well..... definitely... ) you connected to the toggle after you connected to the message box [113(..... so the spigot is not opened until the note value has already been sent.

It is a good idea to use triggers everywhere that an object sends on to more than one other object.
Errors in the "order of operations" are the most common errors in Pd, and sometimes the most difficult to spot, or find.

Although you could just do away with the spigot and use [select 1] to reject any zeros.....!!

Corrected and simplified....... code3.pd
Prepare to learn about "abstractions" next.....

Ok...... so it's not really necessary for your patch, but when things need correcting in the same way in many places, or you want to add a dinky new tool to your note/pitch control, it makes it much easier.
Here is your patch with the note/pitch bit as an abstraction.
It is as simple as can be..... and an introduction to the power of abstractions........ that were called "sub-routines" in the 1970's when I was at Uni (punch cards and ticker-tape) and are now generally called "libraries".....
code4.zip
Have fun.
David.