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 <[email protected]> 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 <[email protected]> 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. >>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
