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
On Fri, Jan 3, 2020 at 1:34 PM Christof Ressi christof.ressi@gmx.at wrote:
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.
This is how you create a hidden canvas: https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#alsoL728 https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L728
And this is how you add objects: https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L868
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.
That being said, I think there should be a way for [tabwrite~] etc. to access data structure "float" arrays. See also: https://github.com/pure-data/pure-data/pull/667
I agree.
-Alex
Christof
*Gesendet:* Freitag, 03. Januar 2020 um 17:59 Uhr *Von:* "x nor" x37v.alex@gmail.com *An:* pd-dev pd-dev@lists.iem.at *Betreff:* [PD-dev] capabilities of data structures with externals 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:
- 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
Great, Thanks for the advice Christof! -Alex
On Fri, Jan 3, 2020 at 3:11 PM Christof Ressi christof.ressi@gmx.at wrote:
I guess I could write a monolithic external that both reads data files
and synthesizes
you can also build seperate externals for different tasks, similar to [array define], [array get], [array set], etc.
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...
yes, that's what I had in mind.
Christof
*Gesendet:* Freitag, 03. Januar 2020 um 23:56 Uhr *Von:* "x nor" x37v.alex@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at *Cc:* pd-dev pd-dev@lists.iem.at *Betreff:* Re: [PD-dev] capabilities of data structures with externals
On Fri, Jan 3, 2020 at 1:34 PM Christof Ressi christof.ressi@gmx.at wrote:
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.
This is how you create a hidden canvas: https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#alsoL728 https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L728
And this is how you add objects: https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L868
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.
That being said, I think there should be a way for [tabwrite~] etc. to access data structure "float" arrays. See also: https://github.com/pure-data/pure-data/pull/667
I agree.
-Alex
Christof
*Gesendet:* Freitag, 03. Januar 2020 um 17:59 Uhr *Von:* "x nor" x37v.alex@gmail.com *An:* pd-dev pd-dev@lists.iem.at *Betreff:* [PD-dev] capabilities of data structures with externals 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:
- 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
And to add my two cents -
The "pointer/get/set" approach to manipulating data is horribly clunky, both unintuitive and inefficient. If you can think of a better way I'd love to hear it.
It seems to me that patch languages are badly suited to this kind of task - but if one were to design a text-language style interface, what language would be suitable? Or indeed is there a compleetely different way to think about it? I've been wondering about this since Pd's start around 1997 :)
cheers Miller
On Fri, Jan 03, 2020 at 03:42:03PM -0800, x nor wrote:
Great, Thanks for the advice Christof! -Alex
On Fri, Jan 3, 2020 at 3:11 PM Christof Ressi christof.ressi@gmx.at wrote:
I guess I could write a monolithic external that both reads data files
and synthesizes
you can also build seperate externals for different tasks, similar to [array define], [array get], [array set], etc.
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...
yes, that's what I had in mind.
Christof
*Gesendet:* Freitag, 03. Januar 2020 um 23:56 Uhr *Von:* "x nor" x37v.alex@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at *Cc:* pd-dev pd-dev@lists.iem.at *Betreff:* Re: [PD-dev] capabilities of data structures with externals
On Fri, Jan 3, 2020 at 1:34 PM Christof Ressi christof.ressi@gmx.at wrote:
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.
This is how you create a hidden canvas: https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#alsoL728 https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L728
And this is how you add objects: https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L868
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.
That being said, I think there should be a way for [tabwrite~] etc. to access data structure "float" arrays. See also: https://github.com/pure-data/pure-data/pull/667
I agree.
-Alex
Christof
*Gesendet:* Freitag, 03. Januar 2020 um 17:59 Uhr *Von:* "x nor" x37v.alex@gmail.com *An:* pd-dev pd-dev@lists.iem.at *Betreff:* [PD-dev] capabilities of data structures with externals 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:
- 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
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
For building data structures, the [scalar] object is already an improvement because you save the whole [traverse(, [pointer], [append] shenanigans to create an instance, especially if you don't care about the visual representation.
Also, there is this proposal: https://github.com/pure-data/pure-data/pull/827.
This would it make possible to do [append] -> [v foo] resp. [loadbang] -> [scalar define bla] -> [v foo], so you can simply do [v foo] -> [get - x y] [v foo] -> [element a] *) [v foo] -> [text get -s foo t] *) etc. anywhere in your patch to access the data by name. No need to explicitly store pointers!
Christof
*) I just noticed that the [text] and [array] methods don't support the "-" wildcard in "-s <template> <field>".
Gesendet: Samstag, 04. Januar 2020 um 00:54 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "x nor" x37v.alex@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, pd-dev pd-dev@lists.iem.at Betreff: Re: [PD-dev] capabilities of data structures with externals
And to add my two cents -
The "pointer/get/set" approach to manipulating data is horribly clunky, both unintuitive and inefficient. If you can think of a better way I'd love to hear it.
It seems to me that patch languages are badly suited to this kind of task - but if one were to design a text-language style interface, what language would be suitable? Or indeed is there a compleetely different way to think about it? I've been wondering about this since Pd's start around 1997 :)
cheers Miller
On Fri, Jan 03, 2020 at 03:42:03PM -0800, x nor wrote:
Great, Thanks for the advice Christof! -Alex
On Fri, Jan 3, 2020 at 3:11 PM Christof Ressi christof.ressi@gmx.at wrote:
I guess I could write a monolithic external that both reads data files
and synthesizes
you can also build seperate externals for different tasks, similar to [array define], [array get], [array set], etc.
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...
yes, that's what I had in mind.
Christof
*Gesendet:* Freitag, 03. Januar 2020 um 23:56 Uhr *Von:* "x nor" x37v.alex@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at *Cc:* pd-dev pd-dev@lists.iem.at *Betreff:* Re: [PD-dev] capabilities of data structures with externals
On Fri, Jan 3, 2020 at 1:34 PM Christof Ressi christof.ressi@gmx.at wrote:
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.
This is how you create a hidden canvas: https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#alsoL728 https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L728
And this is how you add objects: https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L868
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.
That being said, I think there should be a way for [tabwrite~] etc. to access data structure "float" arrays. See also: https://github.com/pure-data/pure-data/pull/667
I agree.
-Alex
Christof
*Gesendet:* Freitag, 03. Januar 2020 um 17:59 Uhr *Von:* "x nor" x37v.alex@gmail.com *An:* pd-dev pd-dev@lists.iem.at *Betreff:* [PD-dev] capabilities of data structures with externals 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:
- 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
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Fri, Jan 3, 2020 at 3:54 PM Miller Puckette msp@ucsd.edu wrote:
And to add my two cents -
The "pointer/get/set" approach to manipulating data is horribly clunky, both unintuitive and inefficient. If you can think of a better way I'd love to hear it.
I was thinking that it would be nice to be able to describe more complex structs without having to make a bunch of subpatches.. On that note I was considering trying to write an external that generates struct templates and the drawing commands from json or some other structured text based data. I could then see data access using something like existential operators or ruby's "dig"..
something like: { "x": 32, "y": [ { "key": "value" }, { "key": "value2" } ], "z": { "p": [1, 2, 3] }, "meta": [ { "filledpolygon": { "color": "x", "coords": [0, 0, 0, 100, 100, 100, 100, 0] }, "plot": { "data": [ "z", "p" ], "coords": [0, 0] } } ] }
with data access like:
[get y[0]?.key] -> |"value"( [get z?.p[0..1]] -> |1 2( [get z?.q] -> |( or some sort of indication of empty.. [dig z q] -> |1 2 3( [dig z q 0..1] -> |1 2( [dig z b] -> |(
And while I added the 'meta' in the example above to describe drawing, it might be nice to separate that data representation and visualization so that there could be a variety of ways to visualize the same data.
Though I'm not sure what I'd actually be trying to achieve with all this..
-Alex
It seems to me that patch languages are badly suited to this kind of task - but if one were to design a text-language style interface, what language would be suitable? Or indeed is there a compleetely different way to think about it? I've been wondering about this since Pd's start around 1997 :)
cheers Miller
On Fri, Jan 03, 2020 at 03:42:03PM -0800, x nor wrote:
Great, Thanks for the advice Christof! -Alex
On Fri, Jan 3, 2020 at 3:11 PM Christof Ressi christof.ressi@gmx.at
wrote:
I guess I could write a monolithic external that both reads data
files
and synthesizes
you can also build seperate externals for different tasks, similar to [array define], [array get], [array set], etc.
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...
yes, that's what I had in mind.
Christof
*Gesendet:* Freitag, 03. Januar 2020 um 23:56 Uhr *Von:* "x nor" x37v.alex@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at *Cc:* pd-dev pd-dev@lists.iem.at *Betreff:* Re: [PD-dev] capabilities of data structures with externals
On Fri, Jan 3, 2020 at 1:34 PM Christof Ressi christof.ressi@gmx.at wrote:
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.
This is how you create a hidden canvas:
https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#alsoL728
<
https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L728%3E
And this is how you add objects:
https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L868
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.
That being said, I think there should be a way for [tabwrite~] etc. to access data structure "float" arrays. See also: https://github.com/pure-data/pure-data/pull/667
I agree.
-Alex
Christof
*Gesendet:* Freitag, 03. Januar 2020 um 17:59 Uhr *Von:* "x nor" x37v.alex@gmail.com *An:* pd-dev pd-dev@lists.iem.at *Betreff:* [PD-dev] capabilities of data structures with externals 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:
- 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?
- 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
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
BTW, I don't think anyone ever answered my first set of questions though they were sort of loaded with specific information about a specific goal, though I'm curious in general..
I see in Christof's examples that I can create canvases in an external.. but my question was about what I can do with pointer methods in an external.
Is there an example that uses the public API to discover information from a pointer? To traverse it and extract data? Augment data? Add data? How about the pointer outlet capabilities for externals.. is there any point at this time? It looks like the public API has what an author would need to create an 'owned' pointer (gpointer_init) and then output it, but does the public API provide any way to actually associate anything useful with it?
-Alex
On Fri, Jan 3, 2020 at 1:34 PM Christof Ressi christof.ressi@gmx.at wrote:
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.
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.
This is how you create a hidden canvas: https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L728
And this is how you add objects: https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L868
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 :-)
That being said, I think there should be a way for [tabwrite~] etc. to access data structure "float" arrays. See also: https://github.com/pure-data/pure-data/pull/667
Christof
*Gesendet:* Freitag, 03. Januar 2020 um 17:59 Uhr *Von:* "x nor" x37v.alex@gmail.com *An:* pd-dev pd-dev@lists.iem.at *Betreff:* [PD-dev] capabilities of data structures with externals 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:
- 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
-
Christof Ressi -
Miller Puckette -
x nor