If you need leading zeros, just put your number into double quotes in a message box. Also, if you want to convert 101 (int) into "00000101" (symbol) you can use [sprintf @symout %08d]. Just keep in mind that it is not a good idea generating large amounts of symbols, you'll waste memory and slow down Max. If you need more info, there are plenty of forum discussions about this.
Also (but I'm probably stating the obvious here) losing leading zeros in binary representation is harmless, just as it is in decimal: 101 and 00000101 are exactly the same.
I either need to unpack and repack to send this to a sub-patcher (Which gets increasingly annoying with increasing number of switches), I also wish to add flexibility so a "fixed" number of switches kind of limits it (or I need to send all values even if they're not used at all times - redundancy). Using this I can have one inlet, dynamic creation of objects based on wordlength and neatly transfer everything on one unpack-pack outlet.
so you need a nibble-sized packet? that's not possible, as the smallest data type in max is an int... but what are these switches? are they inside max or somewhere else? if it's in max that sort of representation has to be a list as far as i can understand it.
sorry just read the previous 3 posts... max is _inelegant_ at the best of times, a nasty piece of work at the worst
In fact, you're saying that each switch has three states (on, off, undefined), so why not use a ternary representation rather than binary? This would allow you to express the "undefined" state also for the significant figures of your number (in your example above, what if it was switch 1 being undefined?)
Hm, just figured I could actually always use a leading 1.
edit: undefined is in a sense of "this switch is currently not used because there are only X outputs available, so "MSB" gets discarded either way.
I'm doing some multi-out mumbo-jumbo and each poly~ instance feeds a certain combinations of outputs, come to 16, you have unnecessarily long list to process every time, and if you want to dynamically reduce the outputs your "unpack 0 0 0 0" order gets corrupted.
Now I can just convert this 1xxxxxx binary to DEC and have a nice single value for it. :P
Maybe I should start coding; i don't like workarounds... But I'm a lazy man...
I have come over this a few other times and it just annoyed me that a set of switches has to be in a list message because it makes so much sense for it to be a single message (to me), so this is just one of the instances I want to use it as such.
I can't believe it never occurred to me to just use a leading 1...
I don't know if your interested in external objects or not, Peter Elsea's Lobjects contain an object [bit] that breaks in int into separate bits or [Lbits] that list the bits in an int including the leading zeros. ftp://arts.ucsc.edu/pub/ems/Lobjects/
("this makes sense" referred to the need to have all the data for each switch packed into a single atom, not to the inelegance of Max... I disagree with you, at least as long as you treat Max for what it is: a great tool for combining processes and user interface widgets, where complex processes are often best expressed in traditional programming languages but also possible with plain Max...)
@Wetterberg: … but is it “elegant” code to specifically format a message to tell a recipient “do nothing”?
That's exactly what I'm try to avoiding. By sensing a message this way I can have a fixed size Pack/Unpack for larger lists while this particular part of the list can vary in size, avoiding the need to have empty "maximum message length" slots present all times.
@Nicolas Danet: Hah. Yeah. That as well. Elegant solution. I prefer the leading 1, looks more like I know what I'm doing.
@Rick: great link, but I rather keep it as vanilla as/if possible.
@Andrea Agostini: not sure that I implied anywhere that I thought you agreed on the inelegance of Max?
I really like Max, it just pisses me off sometimes. Less then most of other environment I work in anyway. :-)