remove item from [coll]?

Aug 15, 2011 at 9:04am

remove item from [coll]?

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.

is there a direct way?

#58483
Aug 15, 2011 at 9:32am

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.

#210167
Aug 15, 2011 at 10:09am

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.

#210168
Aug 15, 2011 at 10:23am

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

#210169
Aug 15, 2011 at 10:51am

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

it´s awful, but it works.

– Pasted Max Patch, click to expand. –
#210170
Aug 15, 2011 at 11:26am

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

#210171
Aug 15, 2011 at 11:43am

@Shell

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

@Chris

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 – ???).

`

– Pasted Max Patch, click to expand. –
#210172
Aug 15, 2011 at 4:40pm

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.

– Pasted Max Patch, click to expand. –
#210173
Aug 16, 2011 at 1:56am

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

#210174
Aug 16, 2011 at 2:47am

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.

#210175
Aug 16, 2011 at 3:17am

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.

#210176
Aug 16, 2011 at 4:15am

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.

– Pasted Max Patch, click to expand. –
#210177
Aug 16, 2011 at 4:54am

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 (http://cycling74.com/2004/09/09/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 ;)

#210178
Aug 16, 2011 at 6:15am

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.

#210179
Aug 16, 2011 at 6:54am

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.

#210180
Aug 16, 2011 at 7:40am

OK. Have fun with that.

#210181
Aug 17, 2011 at 2:35am

Hello!

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!

#210182
Aug 17, 2011 at 3:31am

Hello again!

I had to try! lol

– Pasted Max Patch, click to expand. –
#210183
Aug 17, 2011 at 4:15am

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.

– Pasted Max Patch, click to expand. –
#210184
Aug 17, 2011 at 11:06am

Hi!

That’s another story!

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!

If not, sorry this post!

– Pasted Max Patch, click to expand. –
#210185
Aug 21, 2011 at 6:02pm

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

#210186

You must be logged in to reply to this topic.