Mark

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.

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

6.type the name of the new routing in the textedit.

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.

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 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.

EZ_Output_Preset_2.png

EZ_Output_Preset_2.amxd

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. 

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 w

live-set-does-not-save-all-pattrstorage-data-properly-bug

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.

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. 

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?

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.

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.


with the old system the available routings were represented as one symbol and thus it was not possible to identify the individual entries.

so what's the point of deprecating the old routing system

with the old system the available routings were represented as one symbol and thus it was not possible to identify the individual entries. 

so it has been verified that the [dict] identifiers are not static, but are recreated dynamically (as broc had suggested) every time a Live Set is loaded.

i noticed that the identifier number is assigned to a track incrementally, in the order in which it is queried, and the cycling74 support team told me that the first index number (zero), will be the last one that was saved on the previous load. perhaps this information could be used for a simpler solution than the one i will attempt:

so the only solution (hack) i can think of, would be a combination of my [dict] based patch and broc's [umenu] based patch, ie:

use my dict-identifier based patch for handling the presets, in order to avoid problems when renaming/reordering tracks.

but before saving the Live Set, populate broc's [umenu] in order to "translate" the abstract identifiers into the track number order.

then when loading the Live Set, assign the [umenu] presets into the dict-identifier based presets, which will take over again until the final Save.

So the dict-identifier based system will be active while playing around/editing the set, and the umenu-system will be used to ensure there is consistency of the presets between loads

this could be done more or less automatically, if there was some sort of [savebang] that triggers it when saving the Live Set, or there will have to be a dedicated button for this (and remember to click it before the final save)

this behaviour (non-static identifiers between Live Set loads) is happening with ableton 10.1.3, max 8.1, is there any chance this might have changed since then? 

so it has been verified that the [dict] identifiers are not static, but are recreated dynamically (as broc had suggested) every time a Live Set is loaded.

i noticed that the identifier number is assigned to a track incrementally, in the order in which it is queried, and the cycling74 support team told me that the first index number (zero), will be the last one that was saved on the previous load. perhaps this information could be used for a simpler solution than the one i will attempt:


so the only solution (hack) i can think of, would be  a combination of my [dict] based patch and broc's [umenu] based patch, ie:
use my dict-identifier based patch for handling the presets, in order to avoid problems when renaming/reordering tracks.
but before saving the Live Set, populate broc's [umenu] in order to "translate" the abstract identifiers into the track number order.
then when loading the Live Set, assign the [umenu] presets into the dict-identifier based presets, which will take over again until the final Save.
So the dict-identifier based system will be active while playing around/editing the set, and the umenu-system will be used to ensure there is consistency of the presets between loads
 this could be done more or less automatically, if there was some sort of [savebang] that triggers it when saving the Live Set, or there will have to be a dedicated button for this (and remember to click it before the final save)

ps:
this behaviour (non-static identifiers between Live Set loads) is happening with ableton 10.1.3, max 8.1, is there any chance this might have changed since then? 


ok seems this problem will be finally solved in the new Ableton Live 11!

https://www.ableton.com/en/live/all-new-features/

"MIDI Channel Routings
It  is now possible to route MIDI to and from Max for Live audio effects  and instruments. Inputs and outputs are routable and show up in a  track's MIDI From and MIDI To choosers.

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