bugs can't be reported yet
SourceForge developer pages are presently offline. See our Twitter feed for more information. 2015-07-19 15:46 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>: > 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 <fjkr...@xs4all.nl>: > >> 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 >> > >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list