Feature Request: M4L Init object

    newtfish
    Sep 12 2013 | 2:22 am
    I would be very grateful to see a new object that would do the following:
    On initialisation:
    1) Outlet 1 - Outputs a bang whenever the device has been loaded for the first time in a liveset.
    2) Outlet 2 Outputs a bang whenever the device is being reloaded from a saved liveset.
    3) Outlet 3 Outputs a bang whenever the device is being restored from a crashed set.
    Ive lost count of the amount of hours Ive spent trying to get M4L devices to initialise properly. The main problem seems to stem from when the device is saved or reloaded from a crashed liveset. Most of my devices involve using live.remote to connect to parameters, and the initialisation of these causes endless problems and involve very hacky workarounds. Im forever getting the "setting the id cannot be triggered during undo or redo" errors, which Im sure are also caused by this.
    I think this would do the M4L community a lot of favours, because there are a large amount of devices that display problems with this. I often start using a new device while making music and find myself having to go in and edit the patch to get it to save properly (having lost all the edits I have made while making music). Its quite a momentum killer when youre in the middle of a cool idea.
    I for one dream of a day where I can build a patch and it's super simple to initialise it. I stongly believe this feature would lead to a better consumption of max devices and much more happy users of Ableton Live :)
    • Andrew Pask
      Sep 12 2013 | 5:08 am
      If you could detail some issues with device code and steps to repro, we'll definitely look at this.
      We understand that there can be problems with initialisation in MFL devices, the really hard part is getting reliably reproducible scenarios where it's clear to see what could be done to improve things.
      Please feel free to send things into support@
      Cheers
    • newtfish
      Sep 12 2013 | 12:35 pm
      Sure, Ive sent the two that I could find into support, but Im sure there are more.
      Its also really hard trying to locate the issues, especially in a large patch with lots of things initialising happening. A new Init object that reports just these 3 things would allow us to make conditions for virtually every possible scenario, but I understand its not a simple thing to do.
      Let me know if its worth posting here, the bugs ive submitted to support and the workarounds I have carried out so far.
      Here is one simple anomoly for init: Due to a gate being used, the device should never print anything when being initialised. However, when re-initialising from a crashed set produces the output "0.0000"
      Steps to reproduce:
      Step 1: Load device inside set - open max window - nothing printed Step 2: Save and reopen the liveset - open max window - nothing printed Step 3: Crash the liveset (do this by going to task manager and "end task" in windows). Reopen live, it will ask you if you want to restore the liveset. Click "Yes". Open max window. There is a "0.0000" shown in the print BELL statement.
      I think a lot of people might not complain about the problems with initalisation when a liveset crashes, because possibly many developers do not check for this scenario. However, I do test my devices rigidly, because I want them to work seamlessy, so the user doesnt have to worry about any loss of work or inconsistencies when copying or saving devices.