On Dec 24, 2014, at 12:18 AM, pd-list-request@lists.iem.at wrote:
Of course if someone with the knowledge and energy to do this the "right way" has any suggestions, I'm all ears. I have the inkling that if I could employ a full-time dev to do my bidding then Qt Quick would the "right way" to go-- it's in Debian, is cross-platform, well-documented, and it certainly has enough features for Pd's canvas editing.
Actually 2 things come to mind:
Cairo http://cairographics.org/ for rendering and something else like QT or a layer below tk for the chrome. We use cairo for pdf rendering in OpenFrameworks, among a few other things.
Juce http://www.juce.com/: It’s aimed at audio, cross platform, and Max has used it since Max 5. I used it at one place I worked and it can do quite alot actually.
But I don't know how to retrofit a c program like Pd with Qt, nor how to replace Pd's current string-based communication with whatever one is supposed to use to do that.
I guess you don’t really retrofit the existing Pd, but rebuild it. Chris and I have done this with DroidParty & PdParty to some small degree using libpd. Sending messages and samples to and from the dsp engine is working. If that could be expanded to the requisite GUI calls, then bringing patch editing could be next. libpd currently has “sendFloat”, “sendSymbol” etc, off the top of my head we could add something like “createCanvas” which returns a canvas pointer, etc. In the case of libpd, you don’t communicate with the dsp engine over a socket but by function calls. Obviously you could use a socket and pass data along from a separate GUI which then calls the functions.
I’m just musing here that it’d be nice to abstract the dsp graph, canvas, etc within libpd. That would at least make it possible to support patch creation and editing in PdParty, etc without rolling something myself. If did have to, I’d rather do it in a generic way inside libpd so Chris could use it DroidParty or I could add it to ofxPd, etc.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 12/24/2014 01:35 AM, Dan Wilcox wrote:
On Dec 24, 2014, at 12:18 AM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
Of course if someone with the knowledge and energy to do this the "right way" has any suggestions, I'm all ears. I have the inkling that if I could employ a full-time dev to do my bidding then Qt Quick would the "right way" to go-- it's in Debian, is cross-platform, well-documented, and it certainly has enough features for Pd's canvas editing.
Actually 2 things come to mind:
- Cairo http://cairographics.org for rendering and something else
like QT or a layer below tk for the chrome. We use cairo for pdf rendering in OpenFrameworks, among a few other things.
Last time I looked I didn't see any maintained bridges between tk and Qt. tkpath uses Cairo to actually draw the vector graphics, but... you're still using tk which turns out to be the bottleneck. (And tkpath is abandon-ware, unfortunately.)
- Juce http://www.juce.com: It’s aimed at audio, cross platform, and
Max has used it since Max 5. I used it at one place I worked and it can do quite alot actually.
Cross-platform is good. Unfortunately, it isn't a big benefit that Max uses it because Max doesn't provide any documentation or code for us to follow in a potential port. I think Qt has a larger userbase and more docs so I prefer it, but I know Juce has a lot of fans.
But I don't know how to retrofit a c program like Pd with Qt, nor how to replace Pd's current string-based communication with whatever one is supposed to use to do that.
I guess you don’t really retrofit the existing Pd, but rebuild it. Chris and I have done this with DroidParty & PdParty to some small degree using libpd. Sending messages and samples to and from the dsp engine is working. If that could be expanded to the requisite GUI calls, then bringing patch editing could be next. libpd currently has “sendFloat”, “sendSymbol” etc, off the top of my head we could add something like “createCanvas” which returns a canvas pointer, etc. In the case of libpd, you don’t communicate with the dsp engine over a socket but by function calls. Obviously you could use a socket and pass data along from a separate GUI which then calls the functions.
I’m just musing here that it’d be nice to abstract the dsp graph, canvas, etc within libpd. That would at least make it possible to support patch creation and editing in PdParty, etc without rolling something myself. If did have to, I’d rather do it in a generic way inside libpd so Chris could use it DroidParty or I could add it to ofxPd, etc.
Well, let's take Qt. matju actually added some code to Pd-l2ork to start a Qt gui in a separate thread. He did it by adding to Pd's extant makefile and source. It successfully runs and creates a Qt window with some menus. But any time I try to add a Qt lib I get a segfault. All of Qt's docs assume either that I'm using QtCreator or that I have c++ business logic, so I'm a bit stuck.
Presumably I'd want to create a project in QtCreator for the GUI. libpd has hooks for C++ so I suppose I can import that into the project somehow. But then I also need to have a separate thread for libpd than the GUI, and a new mechanism similar to sys_vgui or vmess to move data back and forth between GUI thread and Pd "core" thread.
However, this is where it gets tricky. There are cases where Pd needs to use the getrect function or other coordinate data in the course of calculating a depth-first object chain, a block, or possibly both ([cnv] "get_pos", [inlet], data structures, some externals). There are also cases where the user programmatically change coordinate data for such objects, including iemguis with "delta" and "pos".
If GUI manipulation happens only in the GUI thread (i.e., we completely
separate Pd into GUI thread and audio/message thread), a patch currently
using [cnv] "get_pos" method for a crude control surface will break.
This is because the coordinate data is only being updated on the GUI
side, and not reported back to the "core". (Even if the core updates the
GUI with programmatic coordinate changes.)
If, on the other hand, the "core" is changed so that it queries the GUI to get coordinate data (for example), you either must block until the GUI returns-- which is bad-- or query ansynchrously which breaks determinism-- which is worse.
Finally, if you continually send the relevant GUI event data to the Pd core (mouse motion, clicks, keyboard events), then you're back to what tcl/tk currently does.
I know Desiredata essentially made a copy of the patch structure on the tcl/tk side and then attempted to keep both the "client" (GUI) and "server" (Pd core) synchronized. That seems to me to be rather complicated and prone to error.
So what do you see as a workable solution to Qt + libpd with this in mind? The only path I see is to incrementally move from tcl/tk to the other toolkit, and then when it's working clean up the g_*.c code so that the gui toolkit can take over more responsibilities (like text editing).
-Jonathan
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If GUI manipulation happens only in the GUI thread (i.e., we completely
separate Pd into GUI thread and audio/message thread), a patch currently using [cnv] "get_pos" method for a crude control surface will break. This is because the coordinate data is only being updated on the GUI side, and not reported back to the "core". (Even if the core updates the GUI with programmatic coordinate changes.)
If, on the other hand, the "core" is changed so that it queries the GUI to get coordinate data (for example), you either must block until the GUI returns-- which is bad-- or query ansynchrously which breaks determinism-- which is worse.
Finally, if you continually send the relevant GUI event data to the Pd
does webkit provide a submilisecond setInterval()?
is there anyway to change how tcl/tk responds to input?
maybe like how in javascript instead of each cell of a table having an onClick() , a single loadEventHandler is used foor. the entire table, each tcl/tk canvas is kinda like each document element in concept. anytime user input occurs only controls that respond to that input need redrawn. how about 2 different response modes? or 3even. 1 for patch editing, 1 for performance, and another for dynamic patching?
One thing I really like about a web technology-based interface is the idea that maybe the computer running Pd and the computer accessing the interface wouldn't necessarily have to be the same computer.
I'm imagining running Pd on a small single-board computer, and patching/interacting with it on a tablet or a phone or a laptop, connecting over an ad-hoc wireless network.
Node-webkit from my understanding is really only intended to run locally, as if it were a native application. It includes an implementation of a web browser so that it can run, and that is where the ~100MB bloat comes from.
Maybe instead of relying on node-webkit we could write our own tiny node server, and have users jump into their favorite web browsers to access the interface?
This would lose the convenience of starting Pd like a native program, but it could be really cool to access it from outside devices.
Does anybody with more knowledge of Pd's internals have thoughts on the feasibility of this?
-Brian
On Thu, Jan 1, 2015 at 10:51 PM, Billy Stiltner billy.stiltner@gmail.com wrote:
If GUI manipulation happens only in the GUI thread (i.e., we completely
separate Pd into GUI thread and audio/message thread), a patch currently using [cnv] "get_pos" method for a crude control surface will break. This is because the coordinate data is only being updated on the GUI side, and not reported back to the "core". (Even if the core updates the GUI with programmatic coordinate changes.)
If, on the other hand, the "core" is changed so that it queries the GUI to get coordinate data (for example), you either must block until the GUI returns-- which is bad-- or query ansynchrously which breaks determinism-- which is worse.
Finally, if you continually send the relevant GUI event data to the Pd
does webkit provide a submilisecond setInterval()?
is there anyway to change how tcl/tk responds to input?
maybe like how in javascript instead of each cell of a table having an onClick() , a single loadEventHandler is used foor. the entire table, each tcl/tk canvas is kinda like each document element in concept. anytime user input occurs only controls that respond to that input need redrawn. how about 2 different response modes? or 3even. 1 for patch editing, 1 for performance, and another for dynamic patching?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
my 2 cent : accessing Pd from remote computer is already possible thanks to SSH X-forwarding and I do think this feature should be preserved in any new GUI which intends to replace the actual one. Also there are some other ways to do what we could call MVC (model-view-control [1]) with Pd. And the most serious pretender is certainly Jamoma[2], which will be available in Pd in 2015 (at least, this is one of my new year's resolution :-) )
best
antoine
[1] : http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller [2] : http://jamoma.org/
-- do it yourself http://antoine.villeret.free.fr
2015-01-05 22:19 GMT+01:00 Brian Fay ovaltinevortex@gmail.com:
One thing I really like about a web technology-based interface is the idea that maybe the computer running Pd and the computer accessing the interface wouldn't necessarily have to be the same computer.
I'm imagining running Pd on a small single-board computer, and patching/interacting with it on a tablet or a phone or a laptop, connecting over an ad-hoc wireless network.
Node-webkit from my understanding is really only intended to run locally, as if it were a native application. It includes an implementation of a web browser so that it can run, and that is where the ~100MB bloat comes from.
Maybe instead of relying on node-webkit we could write our own tiny node server, and have users jump into their favorite web browsers to access the interface?
This would lose the convenience of starting Pd like a native program, but it could be really cool to access it from outside devices.
Does anybody with more knowledge of Pd's internals have thoughts on the feasibility of this?
-Brian
On Thu, Jan 1, 2015 at 10:51 PM, Billy Stiltner billy.stiltner@gmail.com wrote:
If GUI manipulation happens only in the GUI thread (i.e., we completely
separate Pd into GUI thread and audio/message thread), a patch currently using [cnv] "get_pos" method for a crude control surface will break. This is because the coordinate data is only being updated on the GUI side, and not reported back to the "core". (Even if the core updates the GUI with programmatic coordinate changes.)
If, on the other hand, the "core" is changed so that it queries the GUI to get coordinate data (for example), you either must block until the GUI returns-- which is bad-- or query ansynchrously which breaks determinism-- which is worse.
Finally, if you continually send the relevant GUI event data to the Pd
does webkit provide a submilisecond setInterval()?
is there anyway to change how tcl/tk responds to input?
maybe like how in javascript instead of each cell of a table having an onClick() , a single loadEventHandler is used foor. the entire table, each tcl/tk canvas is kinda like each document element in concept. anytime user input occurs only controls that respond to that input need redrawn. how about 2 different response modes? or 3even. 1 for patch editing, 1 for performance, and another for dynamic patching?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I now have a Pd console window running on Node-Webkit, plus some menus. The reason I chose Node-Webkit is because all of the bloat includes within it what I need to change from tcl/tk, yet still retain the same basic GUI interface (and be cross-platform). Things like creating/destroying new windows, adding and disabling menus/menuitems, etc. To have even a tiny web server one would have to change the basic design to some kind of single-window IDE where you roll your own patch windows. That could be very interesting, but it is too much work at this moment. However, I am using a sys_vgui wrapper that looks more like pd_vmess. That at least helps to get rid of explicit tcl in the c code, which could help going forward with the kind of interface you're talking about. -Jonathan
On Monday, January 5, 2015 4:22 PM, Brian Fay <ovaltinevortex@gmail.com> wrote:
One thing I really like about a web technology-based interface is the idea that maybe the computer running Pd and the computer accessing the interface wouldn't necessarily have to be the same computer.
I'm imagining running Pd on a small single-board computer, and patching/interacting with it on a tablet or a phone or a laptop, connecting over an ad-hoc wireless network.
Node-webkit from my understanding is really only intended to run locally, as if it were a native application. It includes an implementation of a web browser so that it can run, and that is where the ~100MB bloat comes from.
Maybe instead of relying on node-webkit we could write our own tiny node server, and have users jump into their favorite web browsers to access the interface?
This would lose the convenience of starting Pd like a native program, but it could be really cool to access it from outside devices.
Does anybody with more knowledge of Pd's internals have thoughts on the feasibility of this?
-Brian
On Thu, Jan 1, 2015 at 10:51 PM, Billy Stiltner billy.stiltner@gmail.com wrote:
If GUI manipulation happens only in the GUI thread (i.e., we completely separate Pd into GUI thread and audio/message thread), a patch currently using [cnv] "get_pos" method for a crude control surface will break. This is because the coordinate data is only being updated on the GUI side, and not reported back to the "core". (Even if the core updates the GUI with programmatic coordinate changes.)
If, on the other hand, the "core" is changed so that it queries the GUI to get coordinate data (for example), you either must block until the GUI returns-- which is bad-- or query ansynchrously which breaks determinism-- which is worse.
Finally, if you continually send the relevant GUI event data to the Pd
does webkit provide a submilisecond setInterval()? is there anyway to change how tcl/tk responds to input? maybe like how in javascript instead of each cell of a table having an onClick() ,a single loadEventHandler is used foor. the entire table, each tcl/tk canvas is kinda like each document element in concept.anytime user input occurs only controls that respond to that input need redrawn. how about 2 different response modes? or 3even.1 for patch editing, 1 for performance, and another for dynamic patching? _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hadn't even thought of window management, which is obviously pretty important to the way we currently patch Pd. Thanks for calling that out. And then of course it would be another matter designing an interface that would make patching easy on a touchscreen.
It would be great if we could see multiple implementations arise and use them interchangeably, but I understand there aren't enough man-hours and expertise available for everything.
On Mon, Jan 5, 2015 at 5:23 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I now have a Pd console window running on Node-Webkit, plus some menus.
The reason I chose Node-Webkit is because all of the bloat includes within it what I need to change from tcl/tk, yet still retain the same basic GUI interface (and be cross-platform). Things like creating/destroying new windows, adding and disabling menus/menuitems, etc.
To have even a tiny web server one would have to change the basic design to some kind of single-window IDE where you roll your own patch windows. That could be very interesting, but it is too much work at this moment. However, I am using a sys_vgui wrapper that looks more like pd_vmess. That at least helps to get rid of explicit tcl in the c code, which could help going forward with the kind of interface you're talking about.
-Jonathan
On Monday, January 5, 2015 4:22 PM, Brian Fay ovaltinevortex@gmail.com wrote:
One thing I really like about a web technology-based interface is the idea that maybe the computer running Pd and the computer accessing the interface wouldn't necessarily have to be the same computer.
I'm imagining running Pd on a small single-board computer, and patching/interacting with it on a tablet or a phone or a laptop, connecting over an ad-hoc wireless network.
Node-webkit from my understanding is really only intended to run locally, as if it were a native application. It includes an implementation of a web browser so that it can run, and that is where the ~100MB bloat comes from.
Maybe instead of relying on node-webkit we could write our own tiny node server, and have users jump into their favorite web browsers to access the interface?
This would lose the convenience of starting Pd like a native program, but it could be really cool to access it from outside devices.
Does anybody with more knowledge of Pd's internals have thoughts on the feasibility of this?
-Brian
On Thu, Jan 1, 2015 at 10:51 PM, Billy Stiltner billy.stiltner@gmail.com wrote:
If GUI manipulation happens only in the GUI thread (i.e., we completely separate Pd into GUI thread and audio/message thread), a patch currently using [cnv] "get_pos" method for a crude control surface will break. This is because the coordinate data is only being updated on the GUI side, and not reported back to the "core". (Even if the core updates the GUI with programmatic coordinate changes.)
If, on the other hand, the "core" is changed so that it queries the GUI to get coordinate data (for example), you either must block until the GUI returns-- which is bad-- or query ansynchrously which breaks determinism-- which is worse.
Finally, if you continually send the relevant GUI event data to the Pd
does webkit provide a submilisecond setInterval()?
is there anyway to change how tcl/tk responds to input?
maybe like how in javascript instead of each cell of a table having an onClick() , a single loadEventHandler is used foor. the entire table, each tcl/tk canvas is kinda like each document element in concept. anytime user input occurs only controls that respond to that input need redrawn. how about 2 different response modes? or 3even. 1 for patch editing, 1 for performance, and another for dynamic patching?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Antoine Villeret -
Billy Stiltner -
Brian Fay -
Dan Wilcox -
Jonathan Wilkes