Many thanks. I am trying to load in a table spectral data to make these data available to an arbitrary number of "readers". I will see how I can deal with this using the tabread and tabwrite externals. Also, it is not clear to me the meaning and the use of the function: "garray_usedindsp" and what is the effect of it. Of course I know that the code is available, but if if somebody can give me a brief idea, I will save a lot of time. Best
Oscar Pablo Di Liscia 2015-09-21 4:27 GMT-03:00 IOhannes m zmoelnig <zmoel...@iem.at>: > On 2015-09-21 00:22, oscar pablo di liscia wrote: > > Hi list. > > I have a question on allocating data and reading it through an external. > > As I have seen so far, the externals that reads arrays, as tabread, > allocate > > the data in their own memory space. As far as I can understand, this > result > > in a "double allocation" of the data. One in the array itself and the > other > > one in the > > internal memory space of the instance of the tabread external. > > The point is that I would like to use an array to hold in memory a > > considerable > > amount of data and to make it available to an arbitrary "reader" objects > > without the need of allocating the data again in each one of the readers. > > Is it possible to write an external that that reads data from an array > "on > > the fly" > > without the need of allocating the data in its own memory space? > > Any help will be most appreciate. > > virtually all¹ objects accessing table data reference the data > "directly" using the "garray_getfloatwords()" function to get a pointer > where the array stores its data. > this does not involve any double allocation at all. > it is also the only sane way to always use up-to-date data: if the user > modifies the data via [tabwrite] or whatever, there is no way to signal > the table consumers that the table data has changed (so that they can > copy the relevant new data into their local copy), so the consumer must > use the changed data directly. > > which objects have you found that proxy the data? > > gfasd,rt > IOhannes > > > > ¹ i seem to remember that [partconv~] does copy the data during > DSP-graph recompilation, mainly because it does some heavy processing on > the data (FFTs and what not), which it doesn't want to do for each > signal block. i might be mistaken though. > > _______________________________________________ > 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