Dynamic [receive] naming not possible?


    Jan 21 2012 | 5:43 am
    SCENARIO:
    * I'm building a tool with up to approx. 60 streaming [send] values. * There are over 50 potential [receive] locations for these values to be sent to. * At each of these 'locations' the user is able to choose which of the 60 streaming values they wish to use to control that particular function.
    PROBLEM:
    I'm concerned about CPU usage that if I was to create individual [receive] objects for each of the 60 values being streamed at each of the 50 potential locations, as this would create (60x50) 3,000 streaming values! Such a waste of resources when only a max of 50 can be used at any given time.
    SOLUTION?
    My ideal solution would be to have a blank [receive] object at each of the 50 locations that could be "set" to a particular (send) name. Therefore, the CPU would be conserved as only the value selected would be streaming... however, apparently this ability doesn't exist - which is a massive shame.
    I found the [forward] - which would be ideal, however it's the exact reverse of what I require. Which begs the question, why does it exist one way and not the other?
    I've thought of using the [matrixctrl] with [router] - however this would mean I have to have a central location that is aware of all the locations to send the values to. The big problem with this is that that my tool has a large amount of bpatchers that can change their presets dynamically (thus also dynamically changing which value they are expecting), making a centralized matrix very complicated.
    Is there a simple solution that I may have overlooked?
    Cheers guys!

    • Jan 21 2012 | 6:17 am
    • Jan 21 2012 | 7:47 am
      That's pretty awesome chris... I was wondering how to do that in max5.
    • Jan 21 2012 | 8:40 am
      oh man i'm blind. man thanks chris.
    • Jan 21 2012 | 11:15 am
      or:
    • Jan 21 2012 | 11:26 am
      The downside to the route solution is that the messages are always being received and dealt with, which makes it slower: