Hi <span style>Joćo,</span><div><font color="#222222" face="arial, sans-serif"><br></font></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style>Or maybe, even continue to develop ftm for Pd instead of the current data structures?</span></blockquote><div> </div><div><font color="#222222" face="arial, sans-serif">FTM is LGPL and Pd is BSD so this might be a problem for some people (in terms of replacing Pd date structures). Except for that, I think it would be great to have FTM in pd.</font></div>
<div><font color="#222222" face="arial, sans-serif"><br></font></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style>Also afaik, ftm isn't developing much anymore (I might be wrong).</span></blockquote><div><br></div><div>every now and then there are bugfix releases with a couple of new features added, but I think more development time is now directed to MuBu (which I think shares a lot of code with FTM\Gabor, hence soem features developed for MuBu leak back to FTM releases) </div>
<div><br></div><div>best</div><div><br></div><div>Adrian</div><div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif"><br>
</font><br><div class="gmail_quote">On Mon, Mar 26, 2012 at 10:05 AM, Joćo Pais <span dir="ltr"><<a href="mailto:jmmmpais@googlemail.com">jmmmpais@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One approach is to make a public API for the process you're already using for<br>
the "Put" menu array and [table] objects. Users don't have to care (or even<br>
be aware of) the loading of the templates for _float and _float_array which is<br>
a good thing. There should be a way to make your own library using only Pd<br>
patches, and have pd look for libname_setup.pd (or some such naming<br>
scheme) in the path when I do [declare -lib libname], and if it exists load it<br>
un-vis'd. That would allow a safe way for a library to use data structures<br>
without $0-, and be able save/recall state. Plus allow all kinds of other things,<br>
like a library of abstractions which all rely on a table to read-- the table can<br>
be in libname_setup.pd, and the user can create/destroy abstractions from<br>
that library while the common table stays safe in the unvis'd setup patch.<br>
<br>
Of course there's still the problem of name clashes since [struct libname] is a<br>
global variable and [table lib-whatever-table] is a global table, but a unique<br>
libname shouldn't be too hard.<br>
</blockquote>
<br>
I don't know if I understood all the consequences of what you wrote. Did you say to let templates with the same name "repeat" themselves, to allow for a better patching? Isn't it good for now that repeated templates do get marked as bad programming, to avoid conflicts where they aren't supposed to be?<br>
If all name conflicts are ignored, some more interesting patching can be done. If name conflicts remain, patching errors will be easier to detect. Is there a good solution?<br>
Or I was misreading the whole problem?<br>
<br>
Besides being interesting to add messages to data-s, it would also be very productive if some easy operations could be done, that nowadays can only be achieved through more intense patching around the data-s objects: choose a particular scalar on a canvas by its index number like in an array (or without having to detect it's values to see if it's the right one), [previous X( message for [pointer], etc etc. I've sent once such a list to Mr. Puckette, I think I still have it around.<br>
This would make data structures patching less time consuming, and maybe also more approachable to newcomers. When I did my data structures workshop last Pd-Con in Weimar everyone was very happy to understand it, but also not very happy that to make a more complex circuit many operations are necessary. I mean, if [tabread] would only take bangs instead of indexes (which is the case with [struct]), how many people would be taking the trouble to use it?<br>
<br>
<br>
Another related question: I was looking at the ftm library, and it is quite complete, not only for data management, but also for expressions using data's variables with direct access, and also audio objects. In the beginning the difference bweteen Pd and Max was that Pd had the "unique" (although rudimentary) data structures (as said in Puckette's Paper), but with ftm there isn't any exclusivity anymore. Since ftm seems to be a much more mature concept - both in terms of features, and integration with other dimensions of the environment -, would it make sense to make a Pd port of ftm? Or maybe, even continue to develop ftm for Pd instead of the current data structures?<br>
Afaik, IOhannes has done some work porting the ftm lib to Pd, but the work with the gui is missing. Does it make more sense to try to reinvent a wheel someone already did, or just get that wheel and make it better? Also afaik, ftm isn't developing much anymore (I might be wrong).<br>
<a href="http://ftm.ircam.fr/index.php/Main_Page" target="_blank">http://ftm.ircam.fr/index.php/<u></u>Main_Page</a> (including sourceforge link)<br>
<br>
Joćo<br>
<br>
______________________________<u></u>_________________<br>
Pd-announce mailing list<br>
<a href="mailto:Pd-announce@iem.at" target="_blank">Pd-announce@iem.at</a><br>
<a href="http://lists.puredata.info/listinfo/pd-announce" target="_blank">http://lists.puredata.info/<u></u>listinfo/pd-announce</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Adrian Gierakowski<br>
</div>