WillyC

To try and put across my problem as succinctly as possible, say I have a coll with the following contents:

If I send 1 to the coll it will output '1 2 3 4' as a list.

Can I make it send 1, 2, 3, 4 as seperate terms?

However, if I wish to send 2 to the coll and have 'a 1', 'b c 2' output (i.e. two lists of differing lengths) [iter] is no longer appropriate.

If I was using a [message box] to store my data I could have the message box contain [a 1, b c 2] and the 'comma' would seperate my list into the required terms.

The example should illustrate why I want to do this.

outputting-individual-terms-from-a-coll

Apologies, but this patch perhaps better demonstrates 'why' I'd want to do this (ignore the last patch):

On Sep 1, 2008, at 11:37 AM, Willy C wrote:

> Apologies, but this patch perhaps better demonstrates 'why' I'd want 

I would put some sort of separator in the data itself, then route 

> Apologies, but this patch perhaps better demonstrates 'why' I'd want  
> to do this (ignore the last patch):

I would put some sort of separator in the data itself, then route  
based on that data.

Chris Muir
cbm@well.com	
http://www.xfade.com

On Sep 1, 2008, at 12:44 PM, Chris Muir wrote:

> I would put some sort of separator in the data itself, then route 

> I would put some sort of separator in the data itself, then route  
> based on that data.

i would argue that you're operating with key:value or address:content 

the value can be a float, int, symbol or list. the list should be 

encoded as a symbol by putting qutoes around it in order to be certain 

i would argue that you're operating with key:value or address:content  
pairs.
the value can be a float, int, symbol or list. the list should be  
encoded as a symbol by putting qutoes around it in order to be certain  
it goes through as one atom.

> i would argue that you're operating with key:value or 

> the value can be a float, int, symbol or list. the list should be 

> encoded as a symbol by putting qutoes around it in order to be 

you need key:list-of-value pairs, so it seems

you can achieve this with a two stage key

one coll stores key:list-of-intermediate-key pairs

the second coll stores intermediate-key:value pairs

(I do not have time to do a sample patch right now)

this is more housekeeping, but less quoting unquoting.

it all depends on what kind of things and how many sublists you need 

> i would argue that you're operating with key:value or  
> address:content pairs.
> the value can be a float, int, symbol or list. the list should be  
> encoded as a symbol by putting qutoes around it in order to be  
> certain it goes through as one atom.
>
> hth

continuing along this line:
coll is able to handle key:value pairs.
you need key:list-of-value pairs, so it seems

you can achieve this with a two stage key
one coll stores key:list-of-intermediate-key pairs
the second coll stores intermediate-key:value pairs

would look like
[first coll]
1, 1000
2, 2000 2001

[second coll]
1000, 1 2 3 4
2000, a 1
2001, b c 2

this is more housekeeping, but less quoting unquoting.
it all depends on what kind of things and how many sublists you need  
to put in your coll values.

Funny how looking at a problem in one way for too long can blind you to looking for alternative ways of solving it. I was hell bent in including 'commas' in my coll data...

In my case the best solution seems to be pairing my terms via enclosing the relevant bits with "a b c" then using [zl iter 2].

I think it was the pointer to using [fromsymbol] which i'd been unable to see for myself.

I'd be interested in seeing Chris Muir's solution. Presumably it would enable the use of arbritarily lengthed groups of terms. Anyone fancy doing a Max 4 version?

Solved this using 'commas' to seperate my terms within coll data as per my initial problem. Uses good old backslash(), the [fromsymbol] object and a message box.

Not sure of the implications performance wise of using the messagebox like this to split the list but it works.

Probably not actually as useful as the key:value solutions suggested above mind...

On Sep 2, 2008, at 3:39 PM, Willy C wrote:

> I'd be interested in seeing Chris Muir's solution. Presumably it 

> would enable the use of arbritarily lengthed groups of terms. Anyone 

I decided to check out the .maxpat to .pat converter, which is 

https://cycling74.com/forums/index.php?t=msg&goto=146725

> I'd be interested in seeing Chris Muir's solution. Presumably it  
> would enable the use of arbritarily lengthed groups of terms. Anyone  
> fancy doing a Max 4 version?

I  decided to check out the .maxpat to .pat converter, which is  
discussed in this thread - https://cycling74.com/forums/index.php?t=msg&goto=146725

Outputting individual terms from a coll