Outputting individual terms from a coll


    Sep 01 2008 | 6:28 pm
    Hello all,
    To try and put across my problem as succinctly as possible, say I have a coll with the following contents:
    1, 1 2 3 4;
    2, a 1 b c 2;
    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?
    Obviously [iter] would do this.
    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.
    However, this is not a valid coll entry:
    2, a 1 , b c 2;
    Any ideas for how I could achieve this?
    The example should illustrate why I want to do this.
    Regards

    • Sep 01 2008 | 6:37 pm
      Apologies, but this patch perhaps better demonstrates 'why' I'd want to do this (ignore the last patch):
    • Sep 01 2008 | 7:44 pm
      On Sep 1, 2008, at 11:37 AM, Willy C wrote:
      > 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.
      -C
      Chris Muir
      cbm@well.com
    • Sep 01 2008 | 8:04 pm
    • Sep 01 2008 | 9:32 pm
      On Sep 1, 2008, at 12:44 PM, Chris Muir wrote:
      > I would put some sort of separator in the data itself, then route
      > based on that data.
      Like this:
      Chris Muir
      cbm@well.com
    • Sep 01 2008 | 9:32 pm
      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
      /*j
    • Sep 02 2008 | 8:20 am
      On 1-sep-2008, at 23:32, jasch wrote:
      > 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
      your example
      1, 1 2 3 4;
      2, a 1 b c 2;
      would look like
      [first coll]
      1, 1000
      2, 2000 2001
      [second coll]
      1000, 1 2 3 4
      2000, a 1
      2001, b c 2
      (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
      to put in your coll values.
      HtH
      -jennek
    • Sep 02 2008 | 10:39 pm
      Many thanks all.
      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?
      Cheers
    • Sep 02 2008 | 11:13 pm
      3am moment...
      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...
    • Sep 03 2008 | 12:24 am
      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
      > fancy doing a Max 4 version?
      I decided to check out the .maxpat to .pat converter, which is
      Chris Muir
      cbm@well.com