<div dir="ltr">Shouldn't we try to organize this?<br><br>I mean, apparently we had people testing and working with the toolkits.. It would be great to know which ones have been tested so far, what are their pro and cons... Then we could pick one approach and go for it... or is it too soon?<br>
<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 10:24 AM, Bill Gribble <span dir="ltr"><<a href="mailto:grib@billgribble.com" target="_blank">grib@billgribble.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[sorry about partial message send, thumb slip]<br>
<br>
I am working on a pd-clone intended to explore a lot of the topics in this thread. It's not fully baked yet -- the biggest working patch is a biquad filter designer with pole-zero and freq response plotting -- but I'm particularly excited about the approach to namespacing and scope management, which works a lot like hc describes. Patches have a set of scopes which can be mapped onto subpatches (represented as layers, not separate windows). Name resolution in send/receive elements works like you would want it to.<br>
<br>
The GUI is implemented in Clutter, which is a pretty nice toolkit and gives you things like zooming for free. With the pd-style graphics the GUI isn't that huge a load.<br>
<br>
I'm submitting a paper to LAC in a week or so, and the code (Linux only ATM, and not for the faint of heart) is on github: <a href="http://www.github.com/bgribble/mfp" target="_blank">http://www.github.com/bgribble/mfp</a><br>
<br>
It's a bit premature to "announce" this code, but the discussion is hitting really close to a lot of the topics of my interest so I couldn't resist :)<br>
<div class="im HOEnZb"><br>
Thanks,<br>
Bill Gribble<br>
<br>
On Jan 21, 2013, at 6:13, Lorenzo Sutton <<a href="mailto:lorenzofsutton@gmail.com">lorenzofsutton@gmail.com</a>> wrote:<br>
<br>
</div><div class="HOEnZb"><div class="h5">> On 19/01/13 20:20, Hans-Christoph Steiner wrote:<br>
>> On 01/19/2013 01:56 PM, IOhannes m zmölnig wrote:<br>
>>> On 01/18/2013 22:31, Hans-Christoph Steiner wrote:<br>
>>>> I would love it if someone started this since it would greatly help with the<br>
>>>> goal of splitting the GUI from Pd itself. And of course I'd help where I can.<br>
>>> i keep starting that project every now and then: moving all the drawing code<br>
>>> to pd-gui and only use FUDI (that is: not tcl code) to communicate between<br>
>>> pd->gui.<br>
>>><br>
>>> unfortunately i always get distracted after a short time and i never get to a<br>
>>> really working prototype.<br>
>>><br>
>>> gmsdr<br>
>>> IOhannes<br>
>> It can be done incrementally, which is likely the only way its going to get<br>
>> done. It turns out that FUDI and tcl proc calls are very similar: space<br>
>> separated list of elements where the first one is the functionality.<br>
>><br>
>> If the basics were done first, like object drawing, then someone could build a<br>
>> rough GUI with another toolkit to test out.<br>
> When you say 'FUDI' what exctly do you mean... what I mean is for me FUDI is actually [netsend] and/or [netreceive] interacting with 'something else'... would this be something more clever? Is it still relying on sockets (have no strong feeling about that nor pro nor con just to have a clearer picture)<br>
><br>
> Would it make sense within this to think of some kind of 'patching' conventions, for example the fact that parameters are always set/modified by messages (and thus easily routable)? maybe some sort of 'namespacing' lingo e.g. mypatch.freq mypatch.amplitude etc...<br>
><br>
> Or even some sort of semantics related to the GUI... mypatch.hslider.freq .. but this is probably going to far.<br>
><br>
> As you can see this topic is very thought provoking over here :)<br>
><br>
> Lorenzo.<br>
><br>
> _______________________________________________<br>
> <a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div>