hi, what is so hard about initializing the object with a table? The [cycle~] object does that really well, for example.
And I don't see how it wouldn't work if the table had its contents saved, for example... attached there's a patch using cycle, the table is initialized in the patch with a loadbang, and it still works - remembering that whenever changes are made in the table, cycle needs to be reset so it loads the table back. cheers 2015-07-19 15:40 GMT-03:00 Fred Jan Kraan <[email protected]>: > 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 > > > > > > > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
