Mark

E.Z.Chooser_0.4_beta.amxd

This is a track output routing and sub-routing chooser M4L device i have designed using regular max and LOM objects. No java-script or anything else. The attached device is optimized for setting MIDI-Track output, but it can be easily modified to set Audio-Track output instead. I suppose it could be modified to set inputs instead of outputs as well. My main concern though is that some of the LOM track properties i am using, have been deprecated since Live 9.7, meaning that it may break functionality in future Live or Max updates. Currently it is working as expected, apart from a couple of minor issues which are listed in the "issues" sub-patcher, included in the attached device. 

If anyone can help me replace the deprecated commands with the new ones it would be great. I hope also that by doing this, it may be possible to fix some of the issues caused by bugs present in the old commands.

Why use this instead of the M4L.chooser.js?

There were 3 reasons i was not happy with the M4L.chooser.js (apart from my inability to modify it due to my complete lack of java-script knowledge):

1. It has some bugs, for example it doesn't update the live.menu when a track is re-named. (This bug has been fixed in E.Z.Chooser)

2. It does not have an option to select sub_routings. (This option is included in E.Z.Chooser)

The third reason was an incorrect assumption i had made that M4L.chooser was inducing latency when changing track routings, due to the use of java-script. It turns out this is a problem of Live itself when there are many tracks present in a set, thus the latency is present whether you change routings from M4L.chooser, or E.Z.Chooser, or Live's track output chooser itself.


This is a track output routing and sub-routing chooser M4L device i have designed using regular max and LOM objects. No java-script or anything else. The attached device is optimized for setting MIDI-Track output, but it can be easily modified to set Audio-Track output instead. I suppose it could be modified to set inputs instead of outputs as well. My main concern though is that some of the LOM track properties i am using, have been deprecated since Live 9.7, meaning that it may break functionality in future Live or Max updates. Currently it is working as expected, apart from a couple of minor issues which are listed in the "issues" sub-patcher, included in the attached device. 
If anyone can help me replace the deprecated commands with the new ones it would be great. I hope also that by doing this, it may be possible to fix some of the issues caused by bugs present in the old commands. 

Why use this instead of the M4L.chooser.js?
There were 3 reasons i was not happy with the M4L.chooser.js  (apart from my inability to modify it due to my complete lack of java-script knowledge):
1. It has some bugs, for example it doesn't update the live.menu when a track is re-named. (This bug has been fixed in E.Z.Chooser)
2. It does not have an option to select sub_routings. (This option is included in E.Z.Chooser)
The third reason was an incorrect assumption i had made that M4L.chooser was inducing latency when changing track routings, due to the use of java-script. It turns out this is a problem of Live itself when there are many tracks present in a set, thus the latency is present whether you change routings from M4L.chooser, or E.Z.Chooser, or Live's track output chooser itself.


 

This is a track output routing and sub-routing chooser M4L device i have designed using regular max and LOM objects. No java-script or a

e·z·chooser-a-simple-midi-track-output-routing-and-sub-routing-m4l-device·-feel-free-to-use-please-help-to-update-or-improve!

E.Z.Chooser_0.4.4.amxd

Main bugs have been fixed and it is working as expected on Live 9.7.3, Max 7.3.4.

Still using the deprecated messages, thus forward compatibility cannot be guarantied.

Unless someone with knowledge of the [dict] object can help me to replace them, see here if you're interested:

https://cycling74.com/forums/m4l-live-9-7-deprecated-track-routings/replies/1#reply-59ab05c3d5272634883ec477

https://cycling74.com/forums/%C2%ABdict%C2%BB-is-it-possible-to-retrieve-a-%C2%ABsub%C2%BBdictionary-using-a-contained-value

Main bugs have been fixed and it is working as expected on Live 9.7.3, Max 7.3.4.
Still using the deprecated messages, thus forward compatibility cannot be guarantied.
Unless someone with knowledge of the [dict] object can help me to replace them, see here if you're interested:

https://cycling74.com/forums/%C2%ABdict%C2%BB-is-it-possible-to-retrieve-a-%C2%ABsub%C2%BBdictionary-using-a-contained-value




E.Z.Chooser_0.4.6.amxd

Added ability to reflect routings and sub_routings changed from Live's Track routing menus.

Now i can say that it works exactly as it should, without any significant issues.

Did a rough test on a LiveSet with 64 tracks and there doesn't seem to be any noticeable difference in latency whether changing routings from E.Z.Chooser, or Live itself.

I am going to stop working on this project for now, unless anyone detects any major bugs or issues, or of course if anyone can help update (ie: to replace the deprecated messages) in order to ensure forward compatibility.

Any feedback would be appreciated, thanks.

Added ability to reflect routings and sub_routings changed from Live's Track routing menus.
Now i can say that it works exactly as it should, without any significant issues.
Did a rough test on a LiveSet with 64 tracks and there doesn't seem to be any noticeable difference in latency whether changing routings from E.Z.Chooser, or Live itself.
I am going to stop working on this project for now, unless anyone detects any major bugs or issues, or of course if anyone can help update (ie: to replace the deprecated messages) in order to ensure forward compatibility.

Any feedback would be appreciated, thanks.


The M4L device is stable, working as expected.

When clicking the EDIT button, sometimes it gets stuck in an infinite loop and max crashes.

Something happens when transitioning from Live to Edit.

As i am using it inside a larger patch which i am still working on and need to edit often, it can be quite frustrating. Has anyone come across this type of problem (crashing when clicking the edit button) with other M4L devices?

The problem is due to the live.observers getting mixed up during the switch to Edit Mode, is there any way to tackle this? 

Maybe freezing the device or something like that?

The M4L device is stable, working as expected.
But...
When clicking the EDIT button, sometimes it gets stuck in an infinite loop and max crashes.
Something happens when transitioning from Live to Edit.

As i am using it inside a larger patch which i am still working on and need to edit often, it can be quite frustrating. Has anyone come across this type of problem (crashing when clicking the edit button) with other M4L devices?

The problem is due to the live.observers getting mixed up during the switch to Edit Mode, is there any way to tackle this? 
Maybe freezing the device or something like that?


Thank you for this! I'm finding it to be quite useful.

I'm afraid I'm unable to help with the live.observer issue. However I can confirm that I've encountered similar behavior when live.observers get too busy and don't properly (re)initialize in the transition from edit/presentation+locked+frozen.

Thank you for this! I'm finding it to be quite useful.
I'm afraid I'm unable to help with the live.observer issue. However I can confirm that I've encountered similar behavior when live.observers get too busy and don't properly (re)initialize in the transition from edit/presentation+locked+frozen.

Have you noticed any other issues apart from the "transition to Edit" problem?

Nice to finally get some feedback!
Have you noticed any other issues apart from the "transition to Edit" problem?


E.Z.Chooser - A simple MIDI Track output routing and sub-routing M4L device. Feel free to use, please help to update or improve!