Live Set does not save all pattrstorage data properly. Bug?


    Oct 18 2019 | 3:23 pm
    I have made a system that saves track output routings as presets, it is part of a bigger patch, but i have isolated it here for anyone who wants to test it. Within the pattrstorage, all data is saved and recalled properly, but when i save the Live Set and reload it, the track routing related data is not recalled properly. All other data is saved and recalled properly.
    to reproduce the problem: 1.insert the device on a midi track (eg track 5). 2.set the midi ouput of that track to any other midi track (eg track 1) 3.manually type the name or number of the track, in the [textedit] object 4.save the preset in slot 1. 5.set the midi output to track 2. 6.type the name of the new routing in the textedit. 7.save the preset in slot 2. do the same for the other 3 presets.
    if you switch between presets you will notice that the output of the track is routed to the correct tracks, as noted in the textedit. everything is working properly. But save the Live Set, and reopen it. then if you switch between the presets, you will notice that the output is not routed to the correct tracks, as noted in the textedit. the textedit presets on the other hand have been saved and recalled correctly, even though they are saved in the same pattrstorage. just the routing data has been messed up.
    i am using Live 9.7.5 and Max 7.3.4. i hope i am doing something wrong, or else i can not think anything else than that there is some sort of bug that doesn't let Live save track-routing related pattrstorage data properly.
    thanks
    screenshot and device attached

    • Oct 19 2019 | 9:57 am
      I think the preset system cannot rely on the dictionaries because they are created dynamically from some internal representation. Instead I would use an [umenu] filled with the names of available_output_routing_types.
    • Oct 19 2019 | 1:01 pm
      thanks for you reply broc!
      i like your approach, but it has the problem that routings get messed up if you change track positions, or add new tracks etc.. that's because you are saving the umenu position and not the dict itself.
      this is the whole point of why i have been struggling to learn the new [dict] based routing system and create a preset system out of it. and it works! but it doesn't! so what's the point of deprecating the old routing system, to introduce a new [dict] based system, which is tricky to learn, but works rock solid and solves all the problems of the old system, but at the end is useless because you are not able to save it properly?
      that's why i fear that it is officially a bug . should i report it in the submission form? ps:
      I think the preset system cannot be based on the dictionaries because they are created dynamically from some internal representation.
      if this is true then it just confirms the above. the only reason i can think of why you wouldn't be able to base presets on the dict system, is if the identifier of each track is randomly numbered each time you load a Set? i don't think this is the case. from some quick testing i did, i think the identifiers remain pretty constant with each reload. it would be absurd if they didn't.
    • Oct 19 2019 | 2:31 pm
      so what's the point of deprecating the old routing system
      with the old system the routings were represented as a symbol and thus it was not possible to identify the individual entries from available routings.