<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 3, 2020 at 3:54 PM Miller Puckette <<a href="mailto:msp@ucsd.edu">msp@ucsd.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And to add my two cents -<br>
<br>
The "pointer/get/set" approach to manipulating data is horribly clunky,<br>
both unintuitive and inefficient.  If you can think of a better way I'd<br>
love to hear it.<br></blockquote><div><br></div><div>I was thinking that it would be nice to be able to describe more complex structs without having to make a bunch of subpatches..</div><div>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.</div><div>I could then see data access using something like existential operators or ruby's "dig"..<br></div><div><br></div><div>something like:<br></div>{<br>  "x": 32,<br>  "y": [<br>    { "key": "value" },<br>    { "key": "value2" }<br>  ],<br>  "z": {<br>    "p": [1, 2, 3]<br>  },<br>  "meta": [<br>    {<br>      "filledpolygon": {<br>        "color": "x",<br>        "coords": [0, 0, 0, 100, 100, 100, 100, 0]<br>      },<br>      "plot": {<br>        "data": [ "z", "p" ],<br>        "coords": [0, 0]<br>      }<br>    }<br>  ]<br>}</div><div class="gmail_quote"><br></div><div class="gmail_quote">with data access like:<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">[get y[0]?.key] -> |"value"(<br></div><div class="gmail_quote">[get z?.p[0..1]] -> |1 2(</div><div class="gmail_quote">[get z?.q] -> |( or some sort of indication of empty..</div><div class="gmail_quote">[dig z q] -> |1 2 3(</div><div class="gmail_quote">[dig z q 0..1] -> |1 2(</div><div class="gmail_quote">[dig z b] -> |( <br></div><div class="gmail_quote"><div><br></div><div>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.</div><div><br></div><div><div>Though I'm not sure what I'd actually be trying to achieve with all this..</div></div><div><br></div><div>-Alex<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It seems to me that patch languages are badly suited to this kind of task -<br>
but if one were to design a text-language style interface, what language<br>
would be suitable?  Or indeed is there a compleetely different way to think<br>
about it?  I've been wondering about this since Pd's start around 1997 :)<br>
<br>
cheers<br>
Miller<br>
<br>
On Fri, Jan 03, 2020 at 03:42:03PM -0800, x nor wrote:<br>
> Great,<br>
> Thanks for the advice Christof!<br>
> -Alex<br>
> <br>
> On Fri, Jan 3, 2020 at 3:11 PM Christof Ressi <<a href="mailto:christof.ressi@gmx.at" target="_blank">christof.ressi@gmx.at</a>> wrote:<br>
> <br>
> > > I guess I could write a monolithic external that both reads data files<br>
> > and synthesizes<br>
> ><br>
> > you can also build seperate externals for different tasks, similar to<br>
> > [array define], [array get], [array set], etc.<br>
> ><br>
> > > I guess I could have an intermediary step that takes the analysis data<br>
> > and creates (hidden or not) arrays and then communicate those names to the<br>
> > synthesizers...<br>
> ><br>
> > yes, that's what I had in mind.<br>
> ><br>
> > Christof<br>
> ><br>
> > *Gesendet:* Freitag, 03. Januar 2020 um 23:56 Uhr<br>
> > *Von:* "x nor" <<a href="mailto:x37v.alex@gmail.com" target="_blank">x37v.alex@gmail.com</a>><br>
> > *An:* "Christof Ressi" <<a href="mailto:christof.ressi@gmx.at" target="_blank">christof.ressi@gmx.at</a>><br>
> > *Cc:* pd-dev <<a href="mailto:pd-dev@lists.iem.at" target="_blank">pd-dev@lists.iem.at</a>><br>
> > *Betreff:* Re: [PD-dev] capabilities of data structures with externals<br>
> ><br>
> ><br>
> > On Fri, Jan 3, 2020 at 1:34 PM Christof Ressi <<a href="mailto:christof.ressi@gmx.at" target="_blank">christof.ressi@gmx.at</a>><br>
> > wrote:<br>
> ><br>
> >> Hi,<br>
> >><br>
> >> if you consider writing an external, why not include the data? Having the<br>
> >> data model in Pd data structures and writing an external just to access it<br>
> >> is certainly possible, but IMO doesn't make much sense.<br>
> >><br>
> ><br>
> > I guess I could write a monolithic external that both reads data files and<br>
> > synthesizes but the idea of separating and using datastructures was so that<br>
> > I could provide visualization of the data (which I've done) and also use<br>
> > that some information for synthesis and potentially allow the interaction<br>
> > with the visualization to control synthesis parameters, also, the<br>
> > separation would allow a user to swap out the synthesis technique if they<br>
> > like..<br>
> > That said, maybe this is asking too much of the datastructure setup...<br>
> > maybe I should simply use datastructures as a visualization and interaction<br>
> > interface as part of a monolithic external that can read data files,<br>
> > synthesize as well as generate the data for visualization...<br>
> ><br>
> ><br>
> >><br>
> >> In your external you can create a (hidden) canvas and add garrays, either<br>
> >> with graph_array() from g_array.c or or by sending the "array" message to<br>
> >> the canvas with pd_typedmess(). DSP objects like [tabwrite4~] can then<br>
> >> access those garrays by their name.<br>
> >><br>
> >> This is how you create a hidden canvas:<br>
> >> <a href="https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#alsoL728" rel="noreferrer" target="_blank">https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#alsoL728</a><br>
> >> <<a href="https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L728" rel="noreferrer" target="_blank">https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L728</a>><br>
> >><br>
> >> And this is how you add objects:<br>
> >> <a href="https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L868" rel="noreferrer" target="_blank">https://git.iem.at/pd/vstplugin/blob/master/pd/src/vstplugin~.cpp#L868</a><br>
> >><br>
> >> NOTE: I wouldn't really recommend this<br>
> >><br>
> >> ---<br>
> >><br>
> >> The other possibility is to have your data model in an abstraction, with<br>
> >> the float arrays in [table] or [array define], and then use [clone] or<br>
> >> dynamic patching. I think this is less work :-)<br>
> >><br>
> ><br>
> > This is actually what I am already doing, except I build a datastructure<br>
> > first, then I have [clone]'d abstractions that create the flattened out<br>
> > [array] s from that data structure (pointer) that I can use for the actual<br>
> > synthesis...<br>
> > One issue with this is that I'd like to be able to have multiple<br>
> > resynthesis patches using the same data.. in my current approach, each<br>
> > resynthesizer has a unique copy of the data structure data, it is CPU<br>
> > intensive to copy all that data around and uses a bunch of RAM just to have<br>
> > duplicate data. If the synthesis abstraction or external could simply use<br>
> > the datastucture data directly, then it shouldn't be very expensive to<br>
> > create a bunch of additional synthesizers.<br>
> ><br>
> > I guess I could have an intermediary step that takes the analysis data and<br>
> > creates (hidden or not) arrays and then communicate those names to the<br>
> > synthesizers... or simply do that as part of the initial data reading<br>
> > external.<br>
> ><br>
> ><br>
> >><br>
> >> ---<br>
> >><br>
> >> That being said, I think there should be a way for [tabwrite~] etc. to<br>
> >> access data structure "float" arrays. See also:<br>
> >> <a href="https://github.com/pure-data/pure-data/pull/667" rel="noreferrer" target="_blank">https://github.com/pure-data/pure-data/pull/667</a><br>
> >><br>
> ><br>
> > I agree.<br>
> ><br>
> > -Alex<br>
> ><br>
> ><br>
> >><br>
> >><br>
> >> Christof<br>
> >><br>
> >> *Gesendet:* Freitag, 03. Januar 2020 um 17:59 Uhr<br>
> >> *Von:* "x nor" <<a href="mailto:x37v.alex@gmail.com" target="_blank">x37v.alex@gmail.com</a>><br>
> >> *An:* pd-dev <<a href="mailto:pd-dev@lists.iem.at" target="_blank">pd-dev@lists.iem.at</a>><br>
> >> *Betreff:* [PD-dev] capabilities of data structures with externals<br>
> >> This past week I've finally learned a bit more about data structures in<br>
> >> PD and I've successfully created my own data structures that model data<br>
> >> from ATS files (sines + noise analysis models).<br>
> >> The re-synthesis ended up being a bit heavy because I didn't see a way to<br>
> >> use tabread~/tabread4~ directly with arrays of complex data, so I patched<br>
> >> some helpers that iterate the data structures and create float arrays from<br>
> >> the fields as needed.<br>
> >><br>
> >> I'm wondering if I can replace this with an external that deals with<br>
> >> these details internally so I have a few questions before I go down that<br>
> >> road:<br>
> >><br>
> >> 1) I see that I can register "pointer" methods for externals.. my<br>
> >> structure has a field that stores an array that stores arrays of structs,<br>
> >> can I expect to be able to get to that data in an external? Any examples?<br>
> >> 2) If I am able to get to the data, can I mark it as 'used for dsp'<br>
> >> somehow like i see you can do for garrays, and then use it within a dsp<br>
> >> callback 'safely' or do i need to copy the data into separate float arrays<br>
> >> to do that?.. maybe i should reorganize the data so that I don't have to do<br>
> >> the copy, but if I end up creating a bunch of float arrays to model the<br>
> >> data inside my data structure, can I then somehow treat it as a "garray"<br>
> >> and mark it used in dsp and use it in my dsp method?<br>
> >><br>
> >> Thanks,<br>
> >> Alex<br>
> >> _______________________________________________ Pd-dev mailing list<br>
> >> <a href="mailto:Pd-dev@lists.iem.at" target="_blank">Pd-dev@lists.iem.at</a> <a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br>
> >><br>
> ><br>
<br>
> _______________________________________________<br>
> Pd-dev mailing list<br>
> <a href="mailto:Pd-dev@lists.iem.at" target="_blank">Pd-dev@lists.iem.at</a><br>
> <a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br>
<br>
</blockquote></div></div>