Yes, I think that's a great idea. Its definitely not too soon, these have been discussed for years. Its the time for action :)
.hc
On 01/21/2013 10:12 AM, Leandro da Mota Damasceno wrote:
Shouldn't we try to organize this?
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?
On Mon, Jan 21, 2013 at 10:24 AM, Bill Gribble grib@billgribble.com wrote:
[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 :)
Thanks, Bill Gribble
On Jan 21, 2013, at 6:13, Lorenzo Sutton lorenzofsutton@gmail.com wrote:
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list