Changin same term by N+1


    Apr 16 2018 | 2:21 pm
    Hi people,
    I'm wondering if it is possible, and if so how, in Max MSP to change a recursive term by a growing number like the formula n+1 ?
    For example :
    note 71 2.835 1.35 127 0 note 83 5.423 2.956 127 0 note 71 3.458 2.412 127 0
    To have this :
    1 71 2.835 1.35 127 0 2 83 5.423 2.956 127 0 3 71 3.458 2.412 127 0 Any idea ? Thank you very much by advance,
    TOTO

    • Apr 16 2018 | 2:48 pm
      i dont understand your example, but one of the methods to build such a loop is to use the [v] object. one instance can capture the result and another instance of it can be part of the expression or even be on top and trigger the next round.
    • Apr 16 2018 | 2:57 pm
      Thank you, but my question is how to replace - in my example - the term "note" by a number "n+1" each time it sees that term.
      The first time "note" is detected, it becomes the number 1, The second time "note" is detected, it becomes the number 2, The third time "note" is detected, it becomes the number 3, Etc...
      Thanks ;)
    • Apr 16 2018 | 6:20 pm
      Assuming each note is a separate list. [Route] off the note, [count] each list, then [zl.Group] the count number to the list. If not then group the six note values first.
    • Apr 19 2018 | 12:49 pm
      Thanks Rick !
      My goal was to create a list of notes and their properties (pitch [int], time [double], duration [double], velocity [int], muted [bool]). So I used your patch but I modified it a little bit : - I wanted to be able to see all lines in a text file, so I used [coll] instead of a [message] ; - I've also added the possibility to reinitialized the counter ; - The counter added a 0 in my list and made it false. So I added [Zl filter]-[0] to clean results. In my case to remove all 0 int is not a problem but I assume that in other situation it could be a problem. - If you want to observe a new entry you have to reinitialize the counter.
      Here is the patch :
      TOTO
    • Apr 19 2018 | 1:17 pm
      a small patching improvement: use [zl join] instead of [zl group]. It's much easier to see what is happening, no need for an extra bang.
    • Apr 19 2018 | 1:35 pm
      Your code is cleaner than mine, so there is no need [Zl filter] because [loadmess 1] force the list to begin with number 1.
      Thanks ! ;)
    • Apr 19 2018 | 3:37 pm
      The patch becomes even simpler if your dumping your list into a coll.
    • Apr 20 2018 | 10:07 am
      @rick yeah - but they get numbered in reversed order. This is a long standing issue with [coll]. There is no message to *append* to the end of the list, you have to provide a key/index manually.
      EDIT: but of course if OP is to sort them anyway based on a second number in the message, this is rather another small improvement... ;-)