redhexagonal

is there an object which filters out numbers it has already received, a bit like [change] but with a memory?

removing-repeated-items-in-a-stream-of-numbers

I don't think so, but you could make something with coll, like this:

> is there an object which filters out numbers it has already 

> received, a bit like [change] but with a memory?

>
> is there an object which filters out numbers it has already  
> received, a bit like [change] but with a memory?


Not that I know of, but it's so easy to cobble something together 

with Histo and gate. It's not much different from the perennial 'how 

do I get random numbers without repeats?'

"I've coughed up more frightening things than that before breakfast"

Adding a clear message and parametizing the input data range left as 

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

> is there an object which filters out numbers it has already  
> received, a bit like [change] but with a memory?

Not that I know of, but it's so easy to cobble something together  
with Histo and gate. It's not much different from the perennial 'how  
do I get random numbers without repeats?'

"I've coughed up more frightening things than that before breakfast"
         -- Grandpa Simpson

Adding a clear message and parametizing the input data range left as  
an exercise.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

Quote: bin wrote on Wed, 13 December 2006 12:53

----------------------------------------------------

> is there an object which filters out numbers it has already received, a bit like [change] but with a memory?

Not that I know of, but you could make something pretty easily with the zl series..

Quote: bin wrote on Wed, 13 December 2006 12:53
----------------------------------------------------
> is there an object which filters out numbers it has already received, a bit like [change] but with a memory?
----------------------------------------------------

here is an urn with no repeats on end of loop

> Quote: bin wrote on Wed, 13 December 2006 12:53

> ----------------------------------------------------

> > is there an object which filters out numbers it has already received, a

> Not that I know of, but you could make something pretty easily with the zl

> #P number 71 232 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P number 90 76 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> Interactive audiovisual sampling soft- and hardware

On 12/13/06, Mattijs Kneppers  wrote:
>
>
> Quote: bin wrote on Wed, 13 December 2006 12:53
> ----------------------------------------------------
> > is there an object which filters out numbers it has already received, a
> bit like [change] but with a memory?
> ----------------------------------------------------
>
> Not that I know of, but you could make something pretty easily with the zl
> series..
>
> Like this:
>
> #P comment 71 251 28 196617 out;
> #P comment 148 59 33 196617 reset;
> #P newex 90 94 53 196617 t i i i 1;
> #P number 71 232 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 118 183 21 196617 t 0;
> #P newex 71 212 29 196617 gate;
> #P message 148 94 41 196617 zlclear;
> #P newex 148 143 18 196617 t l;
> #P button 148 75 15 0;
> #P number 90 76 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 118 164 40 196617 zl sect;
> #P newex 148 123 44 196617 zl union;
> #P comment 90 59 28 196617 in;
> #P connect 6 0 2 0;
> #P connect 6 0 1 0;
> #P connect 1 0 5 0;
> #P connect 4 0 6 0;
> #P connect 7 0 9 0;
> #P connect 5 0 1 1;
> #P connect 5 0 2 1;
> #P connect 2 0 8 0;
> #P connect 10 3 7 0;
> #P connect 10 0 7 1;
> #P connect 3 0 10 0;
> #P connect 8 0 7 0;
> #P connect 10 2 2 0;
> #P connect 10 1 1 0;
>
> --
> SmadSteck - http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>
>

On 13-Dec-2006, at 16:21, Mattijs Kneppers wrote:

> Not that I know of, but you could make something pretty easily

Ray should offer prizes for smallest and most flexible solutions. 

Say, a meal at Chez Gerard near Victoria.

Ray should offer prizes for smallest and most flexible solutions.  
Say, a meal at Chez Gerard near Victoria.

Quote: Peter Castine wrote on Wed, 13 December 2006 17:55

> On 13-Dec-2006, at 16:21, Mattijs Kneppers wrote:

> > Not that I know of, but you could make something pretty easily

> Ray should offer prizes for smallest and most flexible solutions. 

> Say, a meal at Chez Gerard near Victoria.

That would be awesome. From a pre-announced moment, people submit solutions during one day. To determine the winner, time of posting after launch, originality, flexibility, cpu-efficiency and of course size (on screen and in text) will be taken into account.

I would definitely participate! Already drooling on possible problems :D..

Btw, if the prize is a meal in NY, has someone got a spare bed? I'll pay the beer.

Quote: Peter Castine wrote on Wed, 13 December 2006 17:55
----------------------------------------------------
> On 13-Dec-2006, at 16:21, Mattijs Kneppers wrote:
>
> > Not that I know of, but you could make something pretty easily
>
> Is anyone keeping score?
>
> Ray should offer prizes for smallest and most flexible solutions.  
> Say, a meal at Chez Gerard near Victoria.

Btw, if the prize is a meal in NY, has someone got a spare bed? I'll pay the beer.


> Not that I know of, but you could make something pretty easily with

nice one, though its restricted to the last 256 entries, but this could 

And the same idea with a limit of 4096 elements:

Mattijs Kneppers wrote:
> Not that I know of, but you could make something pretty easily with
> the zl series..

nice one, though its restricted to the last 256 entries, but this could 
be an advantage...
And the same idea with a limit of 4096 elements:

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


The most universal one is the solution from Jeremy. To make it a bit 

bin ray wrote:
> thanks! ...the histo one works fine

but is limited to a VERY limited range.
The most universal one is the solution from Jeremy. To make it a bit 
smaller I'd do it like that:

The most universal one is the solution from Jeremy. To make it a bit

but is limited to a VERY limited range.
The most universal one is the solution from Jeremy. To make it a bit
smaller I'd do it like that:

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Am 14.12.2006 um 16:12 schrieb Stefan Tiedje:

Quote: Jeremy Bernstein wrote on Thu, 14 December 2006 16:22

I agree, Jeremy wins. Although Stephans addition makes it better. Only, Stephan, you shouldn't have added an extra output to the trigger, I liked that part in Jeremey's patch.

Quote: Jeremy Bernstein wrote on Thu, 14 December 2006 16:22
----------------------------------------------------
> So, do I get the free dinner?
>
> jb
>

> I agree, Jeremy wins. Although Stephans addition makes it better.

> Only, Stephan, you shouldn't have added an extra output to the

> trigger, I liked that part in Jeremey's patch.

Or what about splitting new and old? (and if you need a trigger use a 

Mattijs Kneppers wrote:
> I agree, Jeremy wins. Although Stephans addition makes it better.
> Only, Stephan, you shouldn't have added an extra output to the
> trigger, I liked that part in Jeremey's patch.

Or what about splitting new and old? (and if you need a trigger use a 
bangbang...)

Quote: Stefan Tiedje wrote on Sat, 16 December 2006 13:10

> > I agree, Jeremy wins. Although Stephans addition makes it better.

> > Only, Stephan, you shouldn't have added an extra output to the

> > trigger, I liked that part in Jeremey's patch.

> Or what about splitting new and old? (and if you need a trigger use a 

A nice improvement. I would do the trigger Jeremy's way though (note the [t i i 1] has one less i compared to Stefan's). Updating the coll and outputting through the gate don't have to be in sync. It even has some educational value.. :)

Quote: Stefan Tiedje wrote on Sat, 16 December 2006 13:10
----------------------------------------------------
> Mattijs Kneppers wrote:
> > I agree, Jeremy wins. Although Stephans addition makes it better.
> > Only, Stephan, you shouldn't have added an extra output to the
> > trigger, I liked that part in Jeremey's patch.
>
> Or what about splitting new and old? (and if you need a trigger use a 
> bangbang...)
>
> Stefan (with the f...)
>

> A nice improvement. I would do the trigger Jeremy's way though (note

> the [t i i 1] has one less i compared to Stefan's). Updating the coll

> and outputting through the gate don't have to be in sync. It even has

Both is identical, even the order of execution. If there is a trigger 

object anyway, I never connect any of the outlets to two different 

destinations, instead, i put in as many outlets as I need connections. 

Especially in an educational context, it will make the patch more 

readable even if the order does not matter for all connections...

Mattijs Kneppers wrote:
> A nice improvement. I would do the trigger Jeremy's way though (note
> the [t i i 1] has one less i compared to Stefan's). Updating the coll
> and outputting through the gate don't have to be in sync. It even has
> some educational value.. :)

Both is identical, even the order of execution. If there is a trigger 
object anyway, I never connect any of the outlets to two different 
destinations, instead, i put in as many outlets as I need connections. 
Especially in an educational context, it will make the patch more 
readable even if the order does not matter for all connections...

Quote: Stefan Tiedje wrote on Mon, 18 December 2006 22:34

> > A nice improvement. I would do the trigger Jeremy's way though (note

> > the [t i i 1] has one less i compared to Stefan's). Updating the coll

> > and outputting through the gate don't have to be in sync. It even has

> Both is identical, even the order of execution. If there is a trigger 

> object anyway, I never connect any of the outlets to two different 

> destinations, instead, i put in as many outlets as I need connections. 

> Especially in an educational context, it will make the patch more 

> readable even if the order does not matter for all connections...

Ah, as a rule I never make multiple connections in a forced order when their order doesn't matter. This helps me understand my old patches. That is a point I would prefer to make to new max users.

Although I agree that this specific patch is more readable if you put in more outlets.

Quote: Stefan Tiedje wrote on Mon, 18 December 2006 22:34
----------------------------------------------------
> Mattijs Kneppers wrote:
> > A nice improvement. I would do the trigger Jeremy's way though (note
> > the [t i i 1] has one less i compared to Stefan's). Updating the coll
> > and outputting through the gate don't have to be in sync. It even has
> > some educational value.. :)
>
> Both is identical, even the order of execution. If there is a trigger 
> object anyway, I never connect any of the outlets to two different 
> destinations, instead, i put in as many outlets as I need connections. 
> Especially in an educational context, it will make the patch more 
> readable even if the order does not matter for all connections...
>

Ah, as a rule I never make multiple connections in a forced order when their order doesn't matter. This helps me understand my old patches. That is a point I would prefer to make to new max users. 

I think I would use a javascript for this ... would it be less performant than a native-max version using colls, zl, etc ?

Quote: julienbreval wrote on Thu, 21 December 2006 19:01

> I think I would use a javascript for this ... would it be less performant than a native-max version using colls, zl, etc ?

That would be a nice test! Would you care do it for us? Let a qmetro empty some uzi's on the patch/js and see what the maximum framerate is in both cases. Or do it with a fixed metro and see what the avarage cpu usage is on both cases. I'm curious!

Quote: julienbreval wrote on Thu, 21 December 2006 19:01
----------------------------------------------------
> I think I would use a javascript for this ... would it be less performant than a native-max version using colls, zl, etc ?
----------------------------------------------------

Quote: Mattijs wrote on Fri, 22 December 2006 12:59

> That would be a nice test! Would you care do it for us? 

Why not ? But I am moving from my apartment this week and I don't have any more computer with Max/MSP here. The computer that I use today for mail and so on has no installed operating system so I am using a K-ubuntu Linux live CD :)

The only problem I see about the javascript is that the list of numbers that have already occured can only be longer and longer, hence the algorithm will be slower and slower. Maybe computers are fast enough for you don't see any difference but it has to be tested. Solutions to his could be:

- limiting the size of the memory to N elements

Quote: Mattijs wrote on Fri, 22 December 2006 12:59
----------------------------------------------------
> That would be a nice test! Would you care do it for us? 
----------------------------------------------------

The only problem I see about the javascript is that the list of numbers that have already occured can only be longer and longer, hence the algorithm will be slower and slower. Maybe computers are fast enough for you don't see any difference but it has to be tested. Solutions to his could be:
- limiting the size of the memory to N elements
- using a manual reset


removing repeated items in a stream of numbers