xh9o

item, not a collection/index of the [coll]. somehow the opposite of merge, tried an empty nsub (i.e. nsub 2 4) but it didn´t work.

remove-item-from-coll

I don't know of a direct way. When I need to do something like this I usually grab the data, manipulate it externally, then rewrite it. Because multiple coll instances can share the same data, you can have one copy that deals with the bit twiddling, and another main instance.

sure, but i want to keep the amount of [coll]-instances as low as possible.

but apropos [grab], sometimes i have trouble using [coll] and [grab] together, like doing some 'nth' and grabing the length. instead [grab] delivers an 'nth'-result. sometimes it helps to re-initialize the [grab] object, sometimes not so it´s difficult to rely on it.

I doubt that having an extra coll instance around would be too expensive. Have you tried it and found some problem?

there were a few (such as in case of different coll-list lengths you can´t use unpack etc.).

Whats wrong with using the 'remove' message ? According to the ref. page it removes both the address and the contents.

it is about to delete only one item of an index, not the entire list of items of the index.

i made a little patch about the grab-problem. the max window describes it, grab does not deliver the length but the items to the uzi (though the message gets the length - ???).

This probably has something to do with the Uzi doing its stuff in one evaluation frame. Here are two variations of the grab example, one using a second coll instead of grab, and one with a deferlow.

thanks, but this all makes the [grab] object kind of obsolete and that´s bad, cause the intentional idea behind it is great.

It's not so much that grab is obsolete, but rather that Uzi acts outside of the Max scheduler, to some extent.

You will come across many areas where the judicious use of a deferlow is just what's needed.

I also don't quite understand your aversion to these techniques. It seems like this sort of stuff is pretty standard.

it seems down to the communication between [uzi] and [grab], as i think to remember having had this behaviour in another context and without [uzi]. but whatever reason: it´s just not like it should be.

i really try to keep code plain and simple, avoid things like deferlow (which in greater context is difficult for precise timing) and the accumulation of table/coll-instances. therefore the grab-idea is genius and that´s simply what i like(d) about it.

it seems down to the communication between [uzi] and [grab], as i think to remember having had this behaviour in another context and without [uzi]. but whatever reason: it´s just not like it should be. 

i really try to keep code plain and simple, avoid things like deferlow (which in greater context is difficult for precise timing) and the accumulation of table/coll-instances. therefore the grab-idea is genius and that´s simply what i like(d) about it.


Fair enough, but this sort of thing is par for the course, I think. Dealing with the vagaries of the scheduler is just something that you get used to.

Here's another version in which I hit the uzi with a bang after setting the number of bangs with the grab. This has a similar effect to the deferlow, but it all happens on the main scheduler thread, so timing will be the same. 

ah ok, very nice. that trick can be an option if you have enough experience or knowledge about the Max interna and when scheduling obstinacy becomes an issue. but newbie as i am it´s difficult to trust in stuff like that, i´m always a little bit afraid of causing later stability/!exception! issues. a fright which is somehow confirmed by this article (

https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue).

therefore it would be heaven if you developers maybe could optimize that specific scheduling issue on some awful rainy november day ;)

ah ok,  very nice. that trick can be an option if you have enough experience or knowledge about the Max interna and when scheduling obstinacy becomes an issue. but newbie as i am it´s difficult to trust in stuff like that, i´m always a little bit afraid of causing later stability/!exception! issues. a fright which is somehow confirmed by this article (https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue).

therefore it would be heaven if you developers maybe could optimize that specific scheduling issue on some awful rainy november day ;)


Any and all of these techniques I've used are just part of Max proficiency, I think. Give it a few months more, and I bet your comfort level with this sort of thing will be fine.

In particular, the trigger object is universally useful for insuring the order of things.

sure. i know it is annoying to hammer such style-issue, but it´s just like an addiction (or sport) to use fewest extra-triggering (or amount of objects in general) while granting stability.

In what context do you want to remove one item from an index?

Do you have the original data? If so, you can "store" the index again without the item you want to remove... I don't know if that technique applies to your case...

That's cheating, but it's an valid way... It's like moving data up and down on an coll! You only need to build the "down" engine because moving up the 5th index it's the same as moving down the 4th, so you can use the same engine but with an [- 1] object when addressing!

Anyway! When I want to remove one item from an index, I store the full data again without the one I want to remove!

Do you have the original data? If so, you can "store" the index again without the item you want to remove... I don't know if that technique applies to your case...
That's cheating, but it's an valid way... It's like moving data up and down on an coll! You only need to build the "down" engine because moving up the 5th index it's the same as moving down the 4th, so you can use the same engine but with an [- 1] object when addressing!

Anyway! When I want to remove one item from an index, I store the full data again without the one I want to remove!


describing the case it is that i have a [coll] of midi-events which besides note, duration etc. stores the time when the event has to happen. and there is an event editor, sorted by that time. so when changing it the menu has to be updated and set back to the edited value which then has a different position and therefore needs to be identifyable - by a flag added to the end of the specific [coll]-index/list. after the menu is updated and set the flag has to be deleted again.

guess it´s easiest with [zl ecils 1] (to identify and if flag cut the last item) and a [route] triggering the storage. it is similar to yours, but in my case don´t need to specify the item position as it is always the last item.

If the lists always have the same length of usable data, and a "x" at the end to mark it for some reason, and you only want to delete all the "x", you don't need to route or ecils or gates.... You just need to re-pack the list without the last element!

sure, i somehow mentioned that ([unpack] for the case of fixed length) in an earlier post.

remove item from [coll]?