Hi,
if you consider writing an external, why not include the data? Having the data model in Pd data structures and writing an external just to access it is certainly possible, but IMO doesn't make much sense.
I guess I could write a monolithic external that both reads data files and synthesizes but the idea of separating and using datastructures was so that I could provide visualization of the data (which I've done) and also use that some information for synthesis and potentially allow the interaction with the visualization to control synthesis parameters, also, the separation would allow a user to swap out the synthesis technique if they like..
That said, maybe this is asking too much of the datastructure setup... maybe I should simply use datastructures as a visualization and interaction interface as part of a monolithic external that can read data files, synthesize as well as generate the data for visualization...
In your external you can create a (hidden) canvas and add garrays, either with graph_array() from g_array.c or or by sending the "array" message to the canvas with pd_typedmess(). DSP objects like [tabwrite4~] can then access those garrays by their name.
NOTE: I wouldn't really recommend this
---
The other possibility is to have your data model in an abstraction, with the float arrays in [table] or [array define], and then use [clone] or dynamic patching. I think this is less work :-)
This is actually what I am already doing, except I build a datastructure first, then I have [clone]'d abstractions that create the flattened out [array] s from that data structure (pointer) that I can use for the actual synthesis...
One issue with this is that I'd like to be able to have multiple resynthesis patches using the same data.. in my current approach, each resynthesizer has a unique copy of the data structure data, it is CPU intensive to copy all that data around and uses a bunch of RAM just to have duplicate data. If the synthesis abstraction or external could simply use the datastucture data directly, then it shouldn't be very expensive to create a bunch of additional synthesizers.
I guess I could have an intermediary step that takes the analysis data and creates (hidden or not) arrays and then communicate those names to the synthesizers... or simply do that as part of the initial data reading external.
I agree.
-Alex
Christof
This past week I've finally learned a bit more about data structures in PD and I've successfully created my own data structures that model data from ATS files (sines + noise analysis models).
The re-synthesis ended up being a bit heavy because I didn't see a way to use tabread~/tabread4~ directly with arrays of complex data, so I patched some helpers that iterate the data structures and create float arrays from the fields as needed.
I'm wondering if I can replace this with an external that deals with these details internally so I have a few questions before I go down that road:
1) I see that I can register "pointer" methods for externals.. my structure has a field that stores an array that stores arrays of structs, can I expect to be able to get to that data in an external? Any examples?
2) If I am able to get to the data, can I mark it as 'used for dsp' somehow like i see you can do for garrays, and then use it within a dsp callback 'safely' or do i need to copy the data into separate float arrays to do that?.. maybe i should reorganize the data so that I don't have to do the copy, but if I end up creating a bunch of float arrays to model the data inside my data structure, can I then somehow treat it as a "garray" and mark it used in dsp and use it in my dsp method?
Thanks,
Alex
_______________________________________________ Pd-dev mailing list
Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev