[sorry about partial message send, thumb slip]
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.
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.
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: http://www.github.com/bgribble/mfp
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 :)
> On 19/01/13 20:20, Hans-Christoph Steiner wrote:
>> On 01/19/2013 01:56 PM, IOhannes m zmölnig wrote:
>>> On 01/18/2013 22:31, Hans-Christoph Steiner wrote:
>>>> I would love it if someone started this since it would greatly help with the
>>>> goal of splitting the GUI from Pd itself. And of course I'd help where I can.
>>> i keep starting that project every now and then: moving all the drawing code
>>> to pd-gui and only use FUDI (that is: not tcl code) to communicate between
>>> pd->gui.
>>>
>>> unfortunately i always get distracted after a short time and i never get to a
>>> really working prototype.
>>>
>>> gmsdr
>>> IOhannes
>> It can be done incrementally, which is likely the only way its going to get
>> done. It turns out that FUDI and tcl proc calls are very similar: space
>> separated list of elements where the first one is the functionality.
>>
>> If the basics were done first, like object drawing, then someone could build a
>> rough GUI with another toolkit to test out.
> 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)
>
> 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...
>
> Or even some sort of semantics related to the GUI... mypatch.hslider.freq .. but this is probably going to far.
>
> As you can see this topic is very thought provoking over here :)
>
> Lorenzo.
>
> _______________________________________________
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list