> have the [partconv~] object be created before the [table]? I tried and have it working actually, not sure how it wouldn't work like I said
2015-07-19 16:55 GMT-03:00 IOhannes m zmölnig <zmoel...@iem.at>: > On 07/19/2015 08:46 PM, Alexandre Torres Porres wrote: > > hi, what is so hard about initializing the object with a table? The > > [cycle~] object does that really well, for example. > > it's very simple if the object can access the table-values directly when > needed. > e.g. [tabread] (we don't need to search for max-compat externals to have > a use-case...) will check whether a table exists directly before it > accesses it; [tabosc~] (that's [cycle~], ain't it?) and other > dsp-objects will check whether the table exists when DSP is turned on > (Pd guarantees that whenever a table appears or disappears the DSP is > re-started). > > but some externals (including [partconv~]) are slightly different, as > they don't access the table-values directly. > rather they munge the data in the table into a local representation (in > the case of [partconv~] the data will be fft-transformed), which is > rather time-consuming. > > i *guess* that even for [partconv~] it would be enough to not access the > table-data before the DSP is started. > this might need major refactoring though. > > > And I don't see how it wouldn't work if the table had its contents saved, > > for example... > > have the [partconv~] object be created before the [table]? > > gfmrdsa > IOhannes > > > _______________________________________________ > 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
