On 2015-07-19 07:46 PM, IOhannes m zmölnig wrote:
On 07/19/2015 10:52 AM, Fred Jan Kraan wrote:
Some time ago I ran into probably the same issue; how to load an array/table at load time, while said array/table is not guaranteed to have loaded yet. From within an object there is nothing like a loadbang AFAIK. I ended up setting a timer for one second (clock_new()) and load the array/timer when it finishes.
hmm, i wouldn't recommend that. having an external initialize itself after some arbitrary time is prone to hard-to-find errors. most likely the user doesn't know that something special is happening after 1000ms. they also might schedule their own initialization to happen "long enough after startup" (e.g. 1000ms), which will then somehow conflict.
I consider it a hack, not a proper solution. I mentioned it hoping to get some clue on how to fix it properly here ;-).
if you cannot use the table "as is" (and in [partconv~] you cannot), i think the object should use an (internal) loadbang for initialization. if the table is not ready at that time, the user should do a proper initialization on the patch side (after all, they are the only ones who can know when all required initialisation has taken place - and they can only know if the object don't break the process by doing it "somewhat later".
"internal loadbang" sounds about right. I will try to find out how [loadbang] does its magic. If it cannot be made to work, the table name probably shouldn't be an argument to partconv~.
But the good news is that just preventing partconv~ to crash shouldn't be too difficult.
cool, and should be fixed.
There is already a patch ready for this that seems to work and doesn't look too ugly.
gfmdsar IOhannes
Greetings,
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list