jirko

(min list elements is 8, and the list length is dynamic, but max is 8)

(the list element is also the position in the resulting list.

if the position exist, it has to be a 1, if not a 0.)

(the list element is also the position in the resulting list.
if the position exist, it has to be a 1, if not a 0.)

Hope this makes sense!
Any help will be much appreciated!!


list-issue

I'm still on my first cup of coffee, so I'm sure there are more elegant ways to do this, particularly if you're willing to use 3rd party objects.

Thanks Chris. Good alternative to do this with standart max objects.

amazing luke, very simply and easy to expand. this is my favourite.

amazing luke, very simply and easy to expand. this is my favourite.
thanks guys.


also for fun, 2 ways in javascript. first, the more traditional approach:

function list() {
  var args = Array.prototype.slice.call(arguments);
  outlet(0, [1, 2, 3, 4, 5, 6, 7, 8].map(
    function(i) {
      return args.some(function(j) {return i == j;});
    }));
}

It's interesting to compare the efficiency of these approaches. Not surprisingly, the LObjects solution was fastest, although because the input list was 1-based, it took two Lobjects. The Uzi/zl method was second fastest, the table method was third, and the javascript was well back. I could only get the second JS version to work, fwiw.

yeah i neglected to do what i needed to do to 

 to a real array with slice and then calling 

 to be noticeably (about 7%) faster than repeatedly doing 

. And then getting rid of pop and just indexing into arguments is a whole 30% faster, though it's still 5 times slower than the uzi version. Something that made no noticeable difference? Going forwards through the array and using pop versus going backwards and using shift. I would have thought that shift would be slower because it has to shift the keys for all of the remaining array elements; however, both shift and pop on a "real" javascript array are probably native code and the difference on such a small array turns out to be negligible. in any case, for reference:

I wonder if js is similar to mxj, in that much of the performance hit comes just from firing up the interpreter.

I'm always surprised that there's so much interest in the performance of max patches, but no real profiling tools that I'm aware of.

yeah i neglected to do what i needed to do to arguments in my first version.

interestingly, i found that converting arguments to a real array with slice and then calling args.pop to be noticeably (about 7%) faster than repeatedly doing Array.prototype.pop.call(arguments). And then getting rid of pop and just indexing into arguments is a whole 30% faster, though it's still 5 times slower than the uzi version. Something that made no noticeable difference? Going forwards through the array and using pop versus going backwards and using shift. I would have thought that shift would be slower because it has to shift the keys for all of the remaining array elements; however, both shift and pop on a "real" javascript array are probably native code and the difference on such a small array turns out to be negligible. in any case, for reference:

I'm always surprised that there's so much interest in the performance of max patches, but no real profiling tools that I'm aware of.


it's funny that some time ago i had to do the same kind of stuff for a patch, but the difference here was that :

-i needed to be able entering individual elements of input list ; ie for example a "5" then a "3" and, when entering the "3", not erasing the "1" which was matching the "5" (am i clear ? :s). In fact i needed to input things individually, not as a list.

-i needed it to be able to behave such as, if i entered a second time a number, it would set its state in the resulting list as "0". So if i entered a "5" a first time, its state would be set to "1", and if i entered that "5" a second time its resulting value in the resulting list would be "0".

It was for making some kind of scale. I know it's not exactly what you want, but it's very similar in some points, so i post it here, hoping it can be of any interest. It works the most basically with a table, which is the better choice here maybe :)

dunno if it's of any interest in that form. it made sense in its original context ;)

hey,
it's funny that some time ago i had to do the same kind of stuff for a patch, but the difference here was that :
-i needed to be able entering individual elements of input list ; ie for example a "5" then a "3" and, when entering the "3", not erasing the "1" which was matching the "5" (am i clear ? :s). In fact i needed to input things individually, not as a list.
-i needed it to be able to behave such as, if i entered a second time a number, it would set its state in the resulting list as "0". So if i entered a "5" a first time, its state would be set to "1", and if i entered that "5" a second time its resulting value in the resulting list would be "0".
It was for making some kind of scale. I know it's not exactly what you want, but it's very similar in some points, so i post it here, hoping it can be of any interest. It works the most basically with a table, which is the better choice here maybe :)

dunno if it's of any interest in that form. it made sense in its original context ;)


list issue