Notification when an import / read into a dict object is complete
I am creating a new Max MIDI Effect, and I am using a dict object to store all the settings for the effect. When the patch is loaded I read the dict in from a JSON file. Programmatically I use a loadbang to trigger an import message to a dict object. I have a JavaScript object that will reference the dictionary after it is loaded.
I want to be sure that my JavaScript code doesn't access the dict before it has been loaded, so I was hoping that the dict object would send something from any of its outlets upon completion of the import from disk to signal that the import is complete.
In this effect I allow a user to open a new settings file at any time, in which case I will do another import from file to dict. This will overwrite any existing settings in the dict.
I thought about getting the keys from the dict and checking to make sure that they are valid. That may work on loadbang if the dict is initially empty, but that won't work after the dict has been set up using a different JSON file.
Ideas?
Thank you!
@ROB you should just be able to use a trigger object:
The first bang is just to start a timer, the second bang is to load the file, and the third bang will be executed after the dict is loaded, and stop the timer.
Thank you, Ben! Is that a general rule in Max, that an operation (like the readany call into dict) completes before the next step begins? I worried that the trigger object would send the three bangs in rapid succession, leaving the import to complete as a background process. If that was true then the third bang could go out before the import had completed.
If not a general rule, is this behavior in any way unique to the trigger object? Here is an approach that I considered, to look for a key in the dictionary that I know will be there; by calling the same dict object in succession I speculated that the "import" operation would be complete by the time the "contains" method is called:
To future readers... this is, indeed, weird behavior. Seems to read in a single scheduler tick. I would have assumed the same thing as rob. Seems, to my very naive eye, like bad architecture to not led the scheduler keep working while reading a large file.
No bad architecture but a bit complicated. Max has 2 different event types, 'scheduler' (high priority) and 'queue' (low priority) events. With overdrive on, Max will use two threads for the execution of events so that high priority events can interrupt and be executed before a low priority event has finished.
https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue