Hi folks,
I am delighted to announce the latest release of Integra Live — an interactive audio application for musicians and music education based on a Pure Data engine.
Integra Live supports Mac OS X 10.6 or later and Windows XP or later. It can be downloaded from the Integra Live website:
http://www.integralive.org
Here's the walkthrough...
- Connect over 60 audio modules from delays to granular synths
- Incorporate live interaction with the routing and scripting panels
- Automate parameters using linear or logarithmic envelopes
- Setup audio "scenes" with keyboard and MIDI triggers
- Add parameter controls to the "live view" for performance
- Share and reuse your work with our integrated file format
Coming soon…
- Write your own Integra Live modules in Pure Data using our module developer SDK
For news...
Follow us on Twitter: @integralive
For bugs and feature requests...
Post on our forum: http://integralive.uservoice.com
Have a great year!
Wow, this looks quite nice! I'll have to check it out next time I boot into Mac OS X. On a related note, Apache Flex is pretty close to being in Debian, so perhaps IntegraLive could run there as well:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602499
.hc
On 01/17/2013 06:18 PM, Jamie Bullock wrote:
Hi folks,
I am delighted to announce the latest release of Integra Live — an interactive audio application for musicians and music education based on a Pure Data engine.
Integra Live supports Mac OS X 10.6 or later and Windows XP or later. It can be downloaded from the Integra Live website:
http://www.integralive.org
Here's the walkthrough...
- Connect over 60 audio modules from delays to granular synths - Incorporate live interaction with the routing and scripting panels - Automate parameters using linear or logarithmic envelopes - Setup audio "scenes" with keyboard and MIDI triggers - Add parameter controls to the "live view" for performance - Share and reuse your work with our integrated file format
Coming soon…
- Write your own Integra Live modules in Pure Data using our module developer SDK
For news...
Follow us on Twitter: @integralive
For bugs and feature requests...
Post on our forum: http://integralive.uservoice.com
Have a great year!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
It is really impressive, specially the way pd is embedded so transparently inside it. Is there some place we can find a demo example track? Best, n
Le 18/01/13 04:16, Hans-Christoph Steiner a écrit :
Wow, this looks quite nice! I'll have to check it out next time I boot into Mac OS X. On a related note, Apache Flex is pretty close to being in Debian, so perhaps IntegraLive could run there as well:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602499
.hc
On 01/17/2013 06:18 PM, Jamie Bullock wrote:
Hi folks,
I am delighted to announce the latest release of Integra Live — an interactive audio application for musicians and music education based on a Pure Data engine.
Integra Live supports Mac OS X 10.6 or later and Windows XP or later. It can be downloaded from the Integra Live website:
http://www.integralive.org
Here's the walkthrough...
- Connect over 60 audio modules from delays to granular synths - Incorporate live interaction with the routing and scripting panels - Automate parameters using linear or logarithmic envelopes - Setup audio "scenes" with keyboard and MIDI triggers - Add parameter controls to the "live view" for performance - Share and reuse your work with our integrated file format
Coming soonÂ…
- Write your own Integra Live modules in Pure Data using our module developer SDK
For news...
Follow us on Twitter: @integralive
For bugs and feature requests...
Post on our forum: http://integralive.uservoice.com
Have a great year!
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
I agree. It looks very smooth and sexy, but I cannot figure out how to get it to make a peep. Hahaha. Include a demo song so people can hear it in action. Very sleek looking
pp
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Nicolas Montgermont Sent: Friday, January 18, 2013 10:27 AM To: pd-list@iem.at Subject: Re: [PD] [announce] Integra Live 1.5 released
It is really impressive, specially the way pd is embedded so transparently inside it. Is there some place we can find a demo example track? Best, n
Le 18/01/13 04:16, Hans-Christoph Steiner a écrit :
Wow, this looks quite nice! I'll have to check it out next time I boot into Mac OS X. On a related note, Apache Flex is pretty close to being in Debian, so perhaps IntegraLive could run there as well:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602499
.hc
On 01/17/2013 06:18 PM, Jamie Bullock wrote:
Hi folks,
I am delighted to announce the latest release of Integra Live - an interactive audio application for musicians and music education based on a Pure Data engine.
Integra Live supports Mac OS X 10.6 or later and Windows XP or later. It can be downloaded from the Integra Live website:
http://www.integralive.org
Here's the walkthrough...
- Connect over 60 audio modules from delays to granular synths - Incorporate live interaction with the routing and scripting panels - Automate parameters using linear or logarithmic envelopes - Setup audio "scenes" with keyboard and MIDI triggers - Add parameter controls to the "live view" for performance - Share and reuse your work with our integrated file format
Coming soon.
- Write your own Integra Live modules in Pure Data using our
module developer SDK
For news...
Follow us on Twitter: @integralive
For bugs and feature requests...
Post on our forum: http://integralive.uservoice.com
Have a great year!
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
On 18 Jan 2013, at 15:29, "Pagano, Patrick" pat@digitalworlds.ufl.edu wrote:
I agree. It looks very smooth and sexy, but I cannot figure out how to get it to make a peep. Hahaha. Include a demo song so people can hear it in action. Very sleek looking
pp
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Nicolas Montgermont Sent: Friday, January 18, 2013 10:27 AM To: pd-list@iem.at Subject: Re: [PD] [announce] Integra Live 1.5 released
It is really impressive, specially the way pd is embedded so transparently inside it. Is there some place we can find a demo example track? Best, n
Thanks both for these comments. There will at some point be on the website the set of works produced as part of the Integra Project, once these have been updated to the latest version of the software.
However, I do also think a demo project is a good idea.
In the interim -- there is a set of demo "blocks" that come with the application. Just drag a block from the Block Library on the left to a track. E.g. if you drag "SoundfileLoop" you should within a few seconds hear an "african" drum loop start.
If this doesn't work for you, it would be helpful if you could report on the forum:
http://integralive.uservoice.com
Best,
Jamie
I am also encountering a non-responsive gui after "Double-click here to create another track", I choose anything from the block library and then the gui is unresponsive except for the file menu which lets me save. I will direct other stuff towards the forum, I have not tried it on OSX yet
pp
-----Original Message----- From: Jamie Bullock [mailto:jamie@jamiebullock.com] Sent: Friday, January 18, 2013 10:48 AM To: Pagano, Patrick Cc: Nicolas Montgermont; pd-list@iem.at Subject: Re: [PD] [announce] Integra Live 1.5 released
On 18 Jan 2013, at 15:29, "Pagano, Patrick" pat@digitalworlds.ufl.edu wrote:
I agree. It looks very smooth and sexy, but I cannot figure out how to get it to make a peep. Hahaha. Include a demo song so people can hear it in action. Very sleek looking
pp
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Nicolas Montgermont Sent: Friday, January 18, 2013 10:27 AM To: pd-list@iem.at Subject: Re: [PD] [announce] Integra Live 1.5 released
It is really impressive, specially the way pd is embedded so transparently inside it. Is there some place we can find a demo example track? Best, n
Thanks both for these comments. There will at some point be on the website the set of works produced as part of the Integra Project, once these have been updated to the latest version of the software.
However, I do also think a demo project is a good idea.
In the interim -- there is a set of demo "blocks" that come with the application. Just drag a block from the Block Library on the left to a track. E.g. if you drag "SoundfileLoop" you should within a few seconds hear an "african" drum loop start.
If this doesn't work for you, it would be helpful if you could report on the forum:
http://integralive.uservoice.com
Best,
Jamie
Is there any development with this Promising Software? I really liked how it worked and I am wondering if you are still working on it?
Patrick
-----Original Message----- From: Jamie Bullock [mailto:jamie@jamiebullock.com] Sent: Friday, January 18, 2013 10:48 AM To: Pagano, Patrick Cc: Nicolas Montgermont; pd-list@iem.at Subject: Re: [PD] [announce] Integra Live 1.5 released
On 18 Jan 2013, at 15:29, "Pagano, Patrick" pat@digitalworlds.ufl.edu wrote:
I agree. It looks very smooth and sexy, but I cannot figure out how to get it to make a peep. Hahaha. Include a demo song so people can hear it in action. Very sleek looking
pp
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Nicolas Montgermont Sent: Friday, January 18, 2013 10:27 AM To: pd-list@iem.at Subject: Re: [PD] [announce] Integra Live 1.5 released
It is really impressive, specially the way pd is embedded so transparently inside it. Is there some place we can find a demo example track? Best, n
Thanks both for these comments. There will at some point be on the website the set of works produced as part of the Integra Project, once these have been updated to the latest version of the software.
However, I do also think a demo project is a good idea.
In the interim -- there is a set of demo "blocks" that come with the application. Just drag a block from the Block Library on the left to a track. E.g. if you drag "SoundfileLoop" you should within a few seconds hear an "african" drum loop start.
If this doesn't work for you, it would be helpful if you could report on the forum:
http://integralive.uservoice.com
Best,
Jamie
Hi Patrick,
Absolutely! We have a 1.6 release planned over the next few release with lots of improvements and fixes, and most interestingly for the Pd community, a module development SDK. I'll announce it when it's out.
best,
Jamie
On 9 Jul 2013, at 22:54, "Pagano, Patrick" pat@digitalworlds.ufl.edu wrote:
Is there any development with this Promising Software? I really liked how it worked and I am wondering if you are still working on it?
Patrick
-----Original Message----- From: Jamie Bullock [mailto:jamie@jamiebullock.com] Sent: Friday, January 18, 2013 10:48 AM To: Pagano, Patrick Cc: Nicolas Montgermont; pd-list@iem.at Subject: Re: [PD] [announce] Integra Live 1.5 released
On 18 Jan 2013, at 15:29, "Pagano, Patrick" pat@digitalworlds.ufl.edu wrote:
I agree. It looks very smooth and sexy, but I cannot figure out how to get it to make a peep. Hahaha. Include a demo song so people can hear it in action. Very sleek looking
pp
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Nicolas Montgermont Sent: Friday, January 18, 2013 10:27 AM To: pd-list@iem.at Subject: Re: [PD] [announce] Integra Live 1.5 released
It is really impressive, specially the way pd is embedded so transparently inside it. Is there some place we can find a demo example track? Best, n
Thanks both for these comments. There will at some point be on the website the set of works produced as part of the Integra Project, once these have been updated to the latest version of the software.
However, I do also think a demo project is a good idea.
In the interim -- there is a set of demo "blocks" that come with the application. Just drag a block from the Block Library on the left to a track. E.g. if you drag "SoundfileLoop" you should within a few seconds hear an "african" drum loop start.
If this doesn't work for you, it would be helpful if you could report on the forum:
http://integralive.uservoice.com
Best,
Jamie
Hi,
It looks very nice indeed.
Running the Windows version, I have a problem with the mouse. I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
Windows 7, 64bit OS.
Cheers Pierre-Olivier
On 18/01/2013 00:18, Jamie Bullock wrote:
Hi folks,
I am delighted to announce the latest release of Integra Live — an interactive audio application for musicians and music education based on a Pure Data engine.
Integra Live supports Mac OS X 10.6 or later and Windows XP or later. It can be downloaded from the Integra Live website:
http://www.integralive.org
Here's the walkthrough...
- Connect over 60 audio modules from delays to granular synths - Incorporate live interaction with the routing and scripting panels - Automate parameters using linear or logarithmic envelopes - Setup audio "scenes" with keyboard and MIDI triggers - Add parameter controls to the "live view" for performance - Share and reuse your work with our integrated file format
Coming soon…
- Write your own Integra Live modules in Pure Data using our module developer SDK
For news...
Follow us on Twitter: @integralive
For bugs and feature requests...
Post on our forum: http://integralive.uservoice.com
Have a great year!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant po.boulant@free.fr wrote:
Hi,
It looks very nice indeed.
Running the Windows version, I have a problem with the mouse. I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
Windows 7, 64bit OS.
I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that.
I hope you don't mind but I've added your report to the UserVoice forum:
http://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mouse-interaction-not-working-on-64-bit-windows
If you "vote" for the issue, you will get an automatic notification when it is resolved.
Jamie
No problem about the report. :)
I'm here if you need further testing too. Look me up on IRC freenode #dataflow. I'm "pob" over there.
For what it's worth, the only interaction I have with the GUI is when closing. I can actually click on the buttons of the "save" pop up window.
Cheers Pierre-Olivier
On 18/01/2013 17:15, Jamie Bullock wrote:
On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant po.boulant@free.fr wrote:
Hi,
It looks very nice indeed.
Running the Windows version, I have a problem with the mouse. I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
Windows 7, 64bit OS.
I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that.
I hope you don't mind but I've added your report to the UserVoice forum:
http://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mo...
If you "vote" for the issue, you will get an automatic notification when it is resolved.
Jamie
The GUI is beautiful!!!!! That's Apache Flex? I don't think we can maket tcl/tk look like that on PD, can we?
On Fri, Jan 18, 2013 at 2:44 PM, Pierre-Olivier Boulant po.boulant@free.frwrote:
No problem about the report. :)
I'm here if you need further testing too. Look me up on IRC freenode #dataflow. I'm "pob" over there.
For what it's worth, the only interaction I have with the GUI is when closing. I can actually click on the buttons of the "save" pop up window.
Cheers Pierre-Olivier
On 18/01/2013 17:15, Jamie Bullock wrote:
On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant po.boulant@free.fr wrote:
Hi,
It looks very nice indeed.
Running the Windows version, I have a problem with the mouse. I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
Windows 7, 64bit OS.
I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that.
I hope you don't mind but I've added your report to the UserVoice forum:
http://integralive.uservoice.**com/forums/58883-general/**
suggestions/3565091-mouse-**interaction-not-working-on-64-**bit-windowshttp://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mouse-interaction-not-working-on-64-bit-windows
If you "vote" for the issue, you will get an automatic notification when it is resolved.
Jamie
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
There is a working package for Apache Flex for Debian, there is a link to it in this thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602499
But its not complete enough to be included in Debian. So if someone got that working, I will submit it for inclusion in Debian.
.hc
On 01/18/2013 12:33 PM, Leandro da Mota Damasceno wrote:
The GUI is beautiful!!!!! That's Apache Flex? I don't think we can maket tcl/tk look like that on PD, can we?
On Fri, Jan 18, 2013 at 2:44 PM, Pierre-Olivier Boulant po.boulant@free.frwrote:
No problem about the report. :)
I'm here if you need further testing too. Look me up on IRC freenode #dataflow. I'm "pob" over there.
For what it's worth, the only interaction I have with the GUI is when closing. I can actually click on the buttons of the "save" pop up window.
Cheers Pierre-Olivier
On 18/01/2013 17:15, Jamie Bullock wrote:
On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant po.boulant@free.fr wrote:
Hi,
It looks very nice indeed.
Running the Windows version, I have a problem with the mouse. I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
Windows 7, 64bit OS.
I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that.
I hope you don't mind but I've added your report to the UserVoice forum:
http://integralive.uservoice.**com/forums/58883-general/**
suggestions/3565091-mouse-**interaction-not-working-on-64-**bit-windowshttp://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mouse-interaction-not-working-on-64-bit-windows
If you "vote" for the issue, you will get an automatic notification when it is resolved.
Jamie
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You could do probably 90% of that in Tcl. If you are interested, you should explore theming using GUI plugins:
http://puredata.info/docs/guiplugins/
Here are some specific examples that do theming:
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/scripts/guiplu...
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/scripts/guiplu...
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/scripts/guiplu...
.hc
On 01/18/2013 12:33 PM, Leandro da Mota Damasceno wrote:
The GUI is beautiful!!!!! That's Apache Flex? I don't think we can maket tcl/tk look like that on PD, can we?
On Fri, Jan 18, 2013 at 2:44 PM, Pierre-Olivier Boulant po.boulant@free.frwrote:
No problem about the report. :)
I'm here if you need further testing too. Look me up on IRC freenode #dataflow. I'm "pob" over there.
For what it's worth, the only interaction I have with the GUI is when closing. I can actually click on the buttons of the "save" pop up window.
Cheers Pierre-Olivier
On 18/01/2013 17:15, Jamie Bullock wrote:
On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant po.boulant@free.fr wrote:
Hi,
It looks very nice indeed.
Running the Windows version, I have a problem with the mouse. I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
Windows 7, 64bit OS.
I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that.
I hope you don't mind but I've added your report to the UserVoice forum:
http://integralive.uservoice.**com/forums/58883-general/**
suggestions/3565091-mouse-**interaction-not-working-on-64-**bit-windowshttp://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mouse-interaction-not-working-on-64-bit-windows
If you "vote" for the issue, you will get an automatic notification when it is resolved.
Jamie
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
From: Leandro da Mota Damasceno lemota@gmail.com To: Pierre-Olivier Boulant po.boulant@free.fr Cc: pd-list pd-list@iem.at Sent: Friday, January 18, 2013 12:33 PM Subject: Re: [PD] [announce] Integra Live 1.5 released
The GUI is beautiful!!!!! That's Apache Flex? I don't think we can maket tcl/tk look like that on PD, can we?
It's not that you can't do that in tk, it's just that tk will get in the way of you doing that at nearly every turn. For example, here's the code you'd need to draw a gradient on a canvas:
Buttons would have to be gifs or bitmaps created in some other program (or on the fly with some hacky code similar to the gradient stuff), unless you use tcl/tk 8.6 in which case you could use pngs. You might be able to use the half-implemented tk theming engine to get a scrollbar that looks like the one in Integra, but you'd probably end up using pngs or something for the items in the Module Library, or else pull your hair out trying to figure out how to get the theme to look like that on all platforms when all platforms do _not_ have the same building blocks for their widgets. For Pd'ers who like the stripped down, 1990s look it is serendipitous, because that is all they can get without someone doing an inordinate amount of work to make it look any other way. (Just find a gui made with tk that looks anything like Integra.)
But I do have a question about:
Specifically, the png accompanying "Turnkey Audio Processing"-- specifically the outputs of GranularDelay1 going to the inputs of StereoReverb1. Look quickly then answer the question: Does out1 connect to in1 or in2?
I'm not against bezier curves, but the GUI engine must handle them with care or they'll cause unnecessary problems.
Bezier curves make it more difficult for the user to anticipate ambiguous overlaps with cords. The user makes connections which are obvious in his/her mind as well as obvious when they do the physical work with the mouse of connecting each outlet to each inlet. (Btw, the user's mouse makes a trip between outlet and inlet that is a straight line, so the physical action no longer correlates with the drawn representation.) Then the mind tricks him/her into thinking that the GUI diagram must be as clear as the mental diagram because all the steps leading up to the final result were clear. (This is still a problem in Pd, but slightly less so because the user is more likely to guess correctly what a straight line between a and b looks like, and they can consequently anticipate ambiguous overlaps and attempt to avoid them before making them.) Then the user goes and teaches a class, or runs an errand, and comes back to the patch but the mental picture is now gone. So he/she recreates the mental image from the GUI image, which is ambiguous, which requires either more work to remember the "real" connection or actually manipulating the GUI cord with the mouse to see what really connects to what. Requiring either type of work breaks with the philosophy of being able to deduce what the patch does simply by looking at it. (Btw, I'm still not sure whether your cords overlap or not.)
So cords should try to repel each other in such a situation, or at least color themselves differently when they do in fact overlap. Otherwise you end up with the equivalent of a scheme IDE that sometimes matches a closing parenthesis with two "candidate" opening parentheses but doesn't indicate which is the actual match. Nobody would tolerate such an ambiguity in a text-based langauge. We shouldn't in GUIs, either.
-Jonathan
On Fri, Jan 18, 2013 at 2:44 PM, Pierre-Olivier Boulant po.boulant@free.fr wrote:
No problem about the report. :)
I'm here if you need further testing too. Look me up on IRC freenode #dataflow. I'm "pob" over there.
For what it's worth, the only interaction I have with the GUI is when closing. I can actually click on the buttons of the "save" pop up window.
Cheers Pierre-Olivier
On 18/01/2013 17:15, Jamie Bullock wrote:
On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant po.boulant@free.fr wrote:
Hi,
It looks very nice indeed.
Running the Windows version, I have a problem with the mouse. I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
Windows 7, 64bit OS.
I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that.
I hope you don't mind but I've added your report to the UserVoice forum:
http://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mo...
If you "vote" for the issue, you will get an automatic notification when it is resolved.
Jamie
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
So if we wanted to improve the GUI we would have to drop tcl/tk all together or make it messy and heavy?
On Fri, Jan 18, 2013 at 5:26 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
From: Leandro da Mota Damasceno lemota@gmail.com To: Pierre-Olivier Boulant po.boulant@free.fr Cc: pd-list pd-list@iem.at Sent: Friday, January 18, 2013 12:33 PM Subject: Re: [PD] [announce] Integra Live 1.5 released
The GUI is beautiful!!!!! That's Apache Flex? I don't think we can maket
tcl/tk look like that on PD, can we?
It's not that you can't do that in tk, it's just that tk will get in the way of you doing that at nearly every turn. For example, here's the code you'd need to draw a gradient on a canvas:
Buttons would have to be gifs or bitmaps created in some other program (or on the fly with some hacky code similar to the gradient stuff), unless you use tcl/tk 8.6 in which case you could use pngs. You might be able to use the half-implemented tk theming engine to get a scrollbar that looks like the one in Integra, but you'd probably end up using pngs or something for the items in the Module Library, or else pull your hair out trying to figure out how to get the theme to look like that on all platforms when all platforms do _not_ have the same building blocks for their widgets. For Pd'ers who like the stripped down, 1990s look it is serendipitous, because that is all they can get without someone doing an inordinate amount of work to make it look any other way. (Just find a gui made with tk that looks anything like Integra.)
But I do have a question about:
Specifically, the png accompanying "Turnkey Audio Processing"-- specifically the outputs of GranularDelay1 going to the inputs of StereoReverb1. Look quickly then answer the question: Does out1 connect to in1 or in2?
I'm not against bezier curves, but the GUI engine must handle them with care or they'll cause unnecessary problems.
Bezier curves make it more difficult for the user to anticipate ambiguous overlaps with cords. The user makes connections which are obvious in his/her mind as well as obvious when they do the physical work with the mouse of connecting each outlet to each inlet. (Btw, the user's mouse makes a trip between outlet and inlet that is a straight line, so the physical action no longer correlates with the drawn representation.) Then the mind tricks him/her into thinking that the GUI diagram must be as clear as the mental diagram because all the steps leading up to the final result were clear. (This is still a problem in Pd, but slightly less so because the user is more likely to guess correctly what a straight line between a and b looks like, and they can consequently anticipate ambiguous overlaps and attempt to avoid them before making them.) Then the user goes and teaches a class, or runs an errand, and comes back to the patch but the mental picture is now gone. So he/she recreates the mental image from the GUI image, which is ambiguous, which requires either more work to remember the "real" connection or actually manipulating the GUI cord with the mouse to see what really connects to what. Requiring either type of work breaks with the philosophy of being able to deduce what the patch does simply by looking at it. (Btw, I'm still not sure whether your cords overlap or not.)
So cords should try to repel each other in such a situation, or at least color themselves differently when they do in fact overlap. Otherwise you end up with the equivalent of a scheme IDE that sometimes matches a closing parenthesis with two "candidate" opening parentheses but doesn't indicate which is the actual match. Nobody would tolerate such an ambiguity in a text-based langauge. We shouldn't in GUIs, either.
-Jonathan
On Fri, Jan 18, 2013 at 2:44 PM, Pierre-Olivier Boulant <
po.boulant@free.fr> wrote:
No problem about the report. :)
I'm here if you need further testing too. Look me up on IRC freenode
#dataflow. I'm "pob" over there.
For what it's worth, the only interaction I have with the GUI is when
closing. I can actually click on the buttons of the "save" pop up window.
Cheers Pierre-Olivier
On 18/01/2013 17:15, Jamie Bullock wrote:
On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant po.boulant@free.fr
wrote:
Hi,
It looks very nice indeed.
Running the Windows version, I have a problem with the mouse. I can't interact at all with the GUI. I can click on the menu bar
(File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
Windows 7, 64bit OS.
I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit
Windows, so it's possibly to do with that.
I hope you don't mind but I've added your report to the UserVoice forum:
http://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mo...
If you "vote" for the issue, you will get an automatic notification
when it is resolved.
Jamie
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 ->
On 18/01/13 20:40, Leandro da Mota Damasceno wrote:
So if we wanted to improve the GUI we would have to drop tcl/tk all together or make it messy and heavy?
Or simply have Pd as the engine and devise funkier GUI stuff outside which can communicate with Pd, so that one concentrate on the dataflow (once I said "dsp" and got slapped by Mathieu :) in Pd and on making a beutiful gui somewhere else...
Gripd was a good example of the concept I thik: http://crca.ucsd.edu/~jsarlo/gripd/
I feel more and more this idea of the separation of content and presentation/interface as I had (sic) to use max since ages I was avoiding it, and I find the complete mixture of 'guiness' and curviness makes me dizzy and disctracts me all the time, for example I often whant to grab patch chords to delete them and some silly pop-up will come out. It looks like the content + presentation mixture we have with HTML and still slowly trying to recover....
Of course on the GUI side, I'm not sure there a library out there to support Pd out of the box, that is sliders aren't enough...Maybe JUCE - http://www.rawmaterialsoftware.com/juce.php
Lorenzo.
On Fri, Jan 18, 2013 at 5:26 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
>________________________________ > From: Leandro da Mota Damasceno <lemota@gmail.com <mailto:lemota@gmail.com>> >To: Pierre-Olivier Boulant <po.boulant@free.fr <mailto:po.boulant@free.fr>> >Cc: pd-list <pd-list@iem.at <mailto:pd-list@iem.at>> >Sent: Friday, January 18, 2013 12:33 PM >Subject: Re: [PD] [announce] Integra Live 1.5 released > > >The GUI is beautiful!!!!! That's Apache Flex? I don't think we can maket tcl/tk look like that on PD, can we? It's not that you can't do that in tk, it's just that tk will get in the way of you doing that at nearly every turn. For example, here's the code you'd need to draw a gradient on a canvas: http://wiki.tcl.tk/6100 Buttons would have to be gifs or bitmaps created in some other program (or on the fly with some hacky code similar to the gradient stuff), unless you use tcl/tk 8.6 in which case you could use pngs. You might be able to use the half-implemented tk theming engine to get a scrollbar that looks like the one in Integra, but you'd probably end up using pngs or something for the items in the Module Library, or else pull your hair out trying to figure out how to get the theme to look like that on all platforms when all platforms do _not_ have the same building blocks for their widgets. For Pd'ers who like the stripped down, 1990s look it is serendipitous, because that is all they can get without someone doing an inordinate amount of work to make it look any other way. (Just find a gui made with tk that looks anything like Integra.) But I do have a question about: http://www.integralive.org/ Specifically, the png accompanying "Turnkey Audio Processing"-- specifically the outputs of GranularDelay1 going to the inputs of StereoReverb1. Look quickly then answer the question: Does out1 connect to in1 or in2? I'm not against bezier curves, but the GUI engine must handle them with care or they'll cause unnecessary problems. Bezier curves make it more difficult for the user to anticipate ambiguous overlaps with cords. The user makes connections which are obvious in his/her mind as well as obvious when they do the physical work with the mouse of connecting each outlet to each inlet. (Btw, the user's mouse makes a trip between outlet and inlet that is a straight line, so the physical action no longer correlates with the drawn representation.) Then the mind tricks him/her into thinking that the GUI diagram must be as clear as the mental diagram because all the steps leading up to the final result were clear. (This is still a problem in Pd, but slightly less so because the user is more likely to guess correctly what a straight line between a and b looks like, and they can consequently anticipate ambiguous overlaps and attempt to avoid them before making them.) Then the user goes and teaches a class, or runs an errand, and comes back to the patch but the mental picture is now gone. So he/she recreates the mental image from the GUI image, which is ambiguous, which requires either more work to remember the "real" connection or actually manipulating the GUI cord with the mouse to see what really connects to what. Requiring either type of work breaks with the philosophy of being able to deduce what the patch does simply by looking at it. (Btw, I'm still not sure whether your cords overlap or not.) So cords should try to repel each other in such a situation, or at least color themselves differently when they do in fact overlap. Otherwise you end up with the equivalent of a scheme IDE that sometimes matches a closing parenthesis with two "candidate" opening parentheses but doesn't indicate which is the actual match. Nobody would tolerate such an ambiguity in a text-based langauge. We shouldn't in GUIs, either. -Jonathan > > > > >On Fri, Jan 18, 2013 at 2:44 PM, Pierre-Olivier Boulant <po.boulant@free.fr <mailto:po.boulant@free.fr>> wrote: > >No problem about the report. :) >> >>I'm here if you need further testing too. Look me up on IRC freenode #dataflow. I'm "pob" over there. >> >>For what it's worth, the only interaction I have with the GUI is when closing. I can actually click on the buttons of the "save" pop up window. >> >>Cheers >>Pierre-Olivier >> >> >> >>On 18/01/2013 17:15, Jamie Bullock wrote: >> >>On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant <po.boulant@free.fr <mailto:po.boulant@free.fr>> wrote: >>> >>> >>>Hi, >>>> >>>>It looks very nice indeed. >>>> >>>>Running the Windows version, I have a problem with the mouse. >>>>I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks. >>>> >>>>Windows 7, 64bit OS. >>>> >>>I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that. >>> >>>I hope you don't mind but I've added your report to the UserVoice forum: >>> >>> http://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mouse-interaction-not-working-on-64-bit-windows >>> >>>If you "vote" for the issue, you will get an automatic notification when it is resolved. >>> >>>Jamie >>> >> >>_______________________________________________ >>Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list >>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >> > >_______________________________________________ >Pd-list@iem.at <mailto: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
----- Original Message -----
From: Lorenzo Sutton lorenzofsutton@gmail.com To: pd-list@iem.at Cc: Sent: Friday, January 18, 2013 4:13 PM Subject: Re: [PD] [announce] Integra Live 1.5 released
On 18/01/13 20:40, Leandro da Mota Damasceno wrote:
So if we wanted to improve the GUI we would have to drop tcl/tk all together or make it messy and heavy?
Or simply have Pd as the engine and devise funkier GUI stuff outside which can communicate with Pd, so that one concentrate on the dataflow (once I said "dsp" and got slapped by Mathieu :) in Pd and on making a
beutiful gui somewhere else...
Gripd was a good example of the concept I thik: http://crca.ucsd.edu/~jsarlo/gripd/
I feel more and more this idea of the separation of content and presentation/interface as I had (sic) to use max since ages I was avoiding it, and I find the complete mixture of 'guiness' and curviness makes me dizzy and disctracts me all the time, for example I often whant to grab patch chords to delete them and some silly pop-up will come out. It looks like the content + presentation mixture we have with HTML and still slowly trying to recover....
Of course on the GUI side, I'm not sure there a library out there to support Pd out of the box, that is sliders aren't enough...Maybe JUCE - http://www.rawmaterialsoftware.com/juce.php
What about qt graphics view?
-Jonathan
Lorenzo.
On Fri, Jan 18, 2013 at 5:26 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
>________________________________
> From: Leandro da Mota Damasceno <lemota@gmail.com mailto:lemota@gmail.com> >To: Pierre-Olivier Boulant <po.boulant@free.fr mailto:po.boulant@free.fr> >Cc: pd-list <pd-list@iem.at mailto:pd-list@iem.at> >Sent: Friday, January 18, 2013 12:33 PM >Subject: Re: [PD] [announce] Integra Live 1.5 released > > >The GUI is beautiful!!!!! That's Apache Flex? I don't
think we can
maket tcl/tk look like that on PD, can we?
It's not that you can't do that in tk, it's just that tk
will get in
the way of you doing that at nearly every turn. For example, here's the code you'd need to draw a gradient on a canvas:
Buttons would have to be gifs or bitmaps created in some other program (or on the fly with some hacky code similar to the gradient stuff), unless you use tcl/tk 8.6 in which case you could use pngs. You might be able to use the half-implemented tk theming engine to get a scrollbar that looks like the one in Integra, but you'd probably end up using pngs or something for the items in the Module Library, or else pull your hair out trying to figure out how to get the theme to look like that on all platforms when all platforms do _not_ have the same building blocks for their widgets. For Pd'ers who like the stripped down, 1990s look it is serendipitous, because that is all they can get without someone doing an inordinate amount of work to make it look any other way. (Just find a gui made with tk that looks anything like Integra.)
But I do have a question about:
Specifically, the png accompanying "Turnkey Audio
Processing"--
specifically the outputs of GranularDelay1 going to the inputs of StereoReverb1. Look quickly then answer the question: Does out1 connect to in1 or in2?
I'm not against bezier curves, but the GUI engine must handle them with care or they'll cause unnecessary problems.
Bezier curves make it more difficult for the user to anticipate ambiguous overlaps with cords. The user makes connections which are obvious in his/her mind as well as obvious when they do the physical work with the mouse of connecting each outlet to each inlet. (Btw, the user's mouse makes a trip between outlet and inlet that is a straight line, so the physical action no longer correlates with the drawn representation.) Then the mind tricks him/her into thinking that the GUI diagram must be as clear as the mental diagram because all the steps leading up to the final result were clear. (This is still a problem in Pd, but slightly less so because the user is more likely to guess correctly what a straight line between a and b looks like, and they can consequently anticipate ambiguous overlaps and attempt to avoid them before making them.) Then the user goes and teaches a class, or runs an errand, and comes back to the patch but the mental picture is now gone. So he/she recreates the mental image from the GUI image, which is ambiguous, which requires either more work to remember the "real" connection or actually manipulating the GUI cord with the mouse to see what really connects to what. Requiring either type of work breaks with the philosophy of being able to deduce what the patch does simply by looking at it. (Btw, I'm still not sure whether your cords overlap or not.)
So cords should try to repel each other in such a situation, or at least color themselves differently when they do in fact overlap. Otherwise you end up with the equivalent of a scheme IDE that sometimes matches a closing parenthesis with two "candidate"
opening
parentheses but doesn't indicate which is the actual match. Nobody would tolerate such an ambiguity in a text-based langauge. We shouldn't in GUIs, either.
-Jonathan
> > > > >On Fri, Jan 18, 2013 at 2:44 PM, Pierre-Olivier Boulant <po.boulant@free.fr mailto:po.boulant@free.fr> wrote: > >No problem about the report. :) >> >>I'm here if you need further testing too. Look me up on
IRC
freenode #dataflow. I'm "pob" over there. >> >>For what it's worth, the only interaction I have with the
GUI is
when closing. I can actually click on the buttons of the
"save" pop
up window. >> >>Cheers >>Pierre-Olivier >> >> >> >>On 18/01/2013 17:15, Jamie Bullock wrote: >> >>On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant <po.boulant@free.fr mailto:po.boulant@free.fr> wrote: >>> >>> >>>Hi, >>>> >>>>It looks very nice indeed. >>>> >>>>Running the Windows version, I have a problem with the
mouse.
>>>>I can't interact at all with the GUI. I can click
on the menu
bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks. >>>> >>>>Windows 7, 64bit OS. >>>> >>>I'm sorry to hear that. I must admit, we haven't
yet tested on
64-bit Windows, so it's possibly to do with that. >>> >>>I hope you don't mind but I've added your report
to the
UserVoice forum: >>> >>>
http://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mo...
>>> >>>If you "vote" for the issue, you will get an
automatic
notification when it is resolved. >>> >>>Jamie >>> >> >>_______________________________________________ >>Pd-list@iem.at mailto:Pd-list@iem.at mailing list >>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >> > >_______________________________________________ >Pd-list@iem.at mailto: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
From: Leandro da Mota Damasceno lemota@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Pierre-Olivier Boulant po.boulant@free.fr; pd-list pd-list@iem.at Sent: Friday, January 18, 2013 2:40 PM Subject: Re: [PD] [announce] Integra Live 1.5 released
So if we wanted to improve the GUI we would have to drop tcl/tk all together or make it messy and heavy?
Depends on which features of the interface you want to improve. Ivica improved the logic that controls when scrollbars appear in a patch in Pd-l2ork, as well as more efficient movement and manipulation of iemguis. However, stuff like gradients in a patch, zooming on a canvas, better handling of fonts, and many other issues require "messes" of code.
-Jonathan
On Fri, Jan 18, 2013 at 5:26 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
From: Leandro da Mota Damasceno lemota@gmail.com To: Pierre-Olivier Boulant po.boulant@free.fr Cc: pd-list pd-list@iem.at Sent: Friday, January 18, 2013 12:33 PM
Subject: Re: [PD] [announce] Integra Live 1.5 released
The GUI is beautiful!!!!! That's Apache Flex? I don't think we can maket tcl/tk look like that on PD, can we?
It's not that you can't do that in tk, it's just that tk will get in the way of you doing that at nearly every turn. For example, here's the code you'd need to draw a gradient on a canvas:
Buttons would have to be gifs or bitmaps created in some other program (or on the fly with some hacky code similar to the gradient stuff), unless you use tcl/tk 8.6 in which case you could use pngs. You might be able to use the half-implemented tk theming engine to get a scrollbar that looks like the one in Integra, but you'd probably end up using pngs or something for the items in the Module Library, or else pull your hair out trying to figure out how to get the theme to look like that on all platforms when all platforms do _not_ have the same building blocks for their widgets. For Pd'ers who like the stripped down, 1990s look it is serendipitous, because that is all they can get without someone doing an inordinate amount of work to make it look any other way. (Just find a gui made with tk that looks anything like Integra.)
But I do have a question about:
Specifically, the png accompanying "Turnkey Audio Processing"-- specifically the outputs of GranularDelay1 going to the inputs of StereoReverb1. Look quickly then answer the question: Does out1 connect to in1 or in2?
I'm not against bezier curves, but the GUI engine must handle them with care or they'll cause unnecessary problems.
Bezier curves make it more difficult for the user to anticipate ambiguous overlaps with cords. The user makes connections which are obvious in his/her mind as well as obvious when they do the physical work with the mouse of connecting each outlet to each inlet. (Btw, the user's mouse makes a trip between outlet and inlet that is a straight line, so the physical action no longer correlates with the drawn representation.) Then the mind tricks him/her into thinking that the GUI diagram must be as clear as the mental diagram because all the steps leading up to the final result were clear. (This is still a problem in Pd, but slightly less so because the user is more likely to guess correctly what a straight line between a and b looks like, and they can consequently anticipate ambiguous overlaps and attempt to avoid them before making them.) Then the user goes and teaches a class, or runs an errand, and comes back to the patch but the mental picture is now gone. So he/she recreates the mental image from the GUI image, which is ambiguous, which requires either more work to remember the "real" connection or actually manipulating the GUI cord with the mouse to see what really connects to what. Requiring either type of work breaks with the philosophy of being able to deduce what the patch does simply by looking at it. (Btw, I'm still not sure whether your cords overlap or not.)
So cords should try to repel each other in such a situation, or at least color themselves differently when they do in fact overlap. Otherwise you end up with the equivalent of a scheme IDE that sometimes matches a closing parenthesis with two "candidate" opening parentheses but doesn't indicate which is the actual match. Nobody would tolerate such an ambiguity in a text-based langauge. We shouldn't in GUIs, either.
-Jonathan
On Fri, Jan 18, 2013 at 2:44 PM, Pierre-Olivier Boulant po.boulant@free.fr wrote:
No problem about the report. :)
I'm here if you need further testing too. Look me up on IRC freenode #dataflow. I'm "pob" over there.
For what it's worth, the only interaction I have with the GUI is when closing. I can actually click on the buttons of the "save" pop up window.
Cheers Pierre-Olivier
On 18/01/2013 17:15, Jamie Bullock wrote:
On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant po.boulant@free.fr wrote:
Hi,
It looks very nice indeed.
Running the Windows version, I have a problem with the mouse. I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
Windows 7, 64bit OS.
I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that.
I hope you don't mind but I've added your report to the UserVoice forum:
http://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mo...
If you "vote" for the issue, you will get an automatic notification when it is resolved.
Jamie
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
On 01/18/2013 04:14 PM, Jonathan Wilkes wrote:
From: Leandro da Mota Damasceno lemota@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Pierre-Olivier Boulant po.boulant@free.fr; pd-list pd-list@iem.at Sent: Friday, January 18, 2013 2:40 PM Subject: Re: [PD] [announce] Integra Live 1.5 released
So if we wanted to improve the GUI we would have to drop tcl/tk all together or make it messy and heavy?
Depends on which features of the interface you want to improve. Ivica improved the logic that controls when scrollbars appear in a patch in Pd-l2ork, as well as more efficient movement and manipulation of iemguis. However, stuff like gradients in a patch, zooming on a canvas, better handling of fonts, and many other issues require "messes" of code.
-Jonathan
It also depends on what you mean by "improve". I personally want Pd's GUI to look and act as native as possible on any given platform, and it turns out that Tk is one of the better GUI toolkits for doing that. Tk is quite slow for raw drawing, so that's a problem.
If you want to go the path of IntegraLive, Max5, Live, etc. where they aim to make the program look and act the same no matter which platform, then other toolkits are better for that: GTK, Flex, JUCE, etc.
On that note, it would be fully possible to start right now to write a new GUI for Pd using the toolkit of your choosing. The communication from pd-gui to pd is all Pd messages, so that's easy to generate in any programming language. The tricky part is pd talks to pd-gui mostly using Tcl code.
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.
.hc
On Fri, Jan 18, 2013 at 5:26 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
From: Leandro da Mota Damasceno lemota@gmail.com To: Pierre-Olivier Boulant po.boulant@free.fr Cc: pd-list pd-list@iem.at Sent: Friday, January 18, 2013 12:33 PM
Subject: Re: [PD] [announce] Integra Live 1.5 released
The GUI is beautiful!!!!! That's Apache Flex? I don't think we can maket tcl/tk look like that on PD, can we?
It's not that you can't do that in tk, it's just that tk will get in the way of you doing that at nearly every turn. For example, here's the code you'd need to draw a gradient on a canvas:
Buttons would have to be gifs or bitmaps created in some other program (or on the fly with some hacky code similar to the gradient stuff), unless you use tcl/tk 8.6 in which case you could use pngs. You might be able to use the half-implemented tk theming engine to get a scrollbar that looks like the one in Integra, but you'd probably end up using pngs or something for the items in the Module Library, or else pull your hair out trying to figure out how to get the theme to look like that on all platforms when all platforms do _not_ have the same building blocks for their widgets. For Pd'ers who like the stripped down, 1990s look it is serendipitous, because that is all they can get without someone doing an inordinate amount of work to make it look any other way. (Just find a gui made with tk that looks anything like Integra.)
But I do have a question about:
Specifically, the png accompanying "Turnkey Audio Processing"-- specifically the outputs of GranularDelay1 going to the inputs of StereoReverb1. Look quickly then answer the question: Does out1 connect to in1 or in2?
I'm not against bezier curves, but the GUI engine must handle them with care or they'll cause unnecessary problems.
Bezier curves make it more difficult for the user to anticipate ambiguous overlaps with cords. The user makes connections which are obvious in his/her mind as well as obvious when they do the physical work with the mouse of connecting each outlet to each inlet. (Btw, the user's mouse makes a trip between outlet and inlet that is a straight line, so the physical action no longer correlates with the drawn representation.) Then the mind tricks him/her into thinking that the GUI diagram must be as clear as the mental diagram because all the steps leading up to the final result were clear. (This is still a problem in Pd, but slightly less so because the user is more likely to guess correctly what a straight line between a and b looks like, and they can consequently anticipate ambiguous overlaps and attempt to avoid them before making them.) Then the user goes and teaches a class, or runs an errand, and comes back to the patch but the mental picture is now gone. So he/she recreates the mental image from the GUI image, which is ambiguous, which requires either more work to remember the "real" connection or actually manipulating the GUI cord with the mouse to see what really connects to what. Requiring either type of work breaks with the philosophy of being able to deduce what the patch does simply by looking at it. (Btw, I'm still not sure whether your cords overlap or not.)
So cords should try to repel each other in such a situation, or at least color themselves differently when they do in fact overlap. Otherwise you end up with the equivalent of a scheme IDE that sometimes matches a closing parenthesis with two "candidate" opening parentheses but doesn't indicate which is the actual match. Nobody would tolerate such an ambiguity in a text-based langauge. We shouldn't in GUIs, either.
-Jonathan
On Fri, Jan 18, 2013 at 2:44 PM, Pierre-Olivier Boulant po.boulant@free.fr wrote:
No problem about the report. :)
I'm here if you need further testing too. Look me up on IRC freenode #dataflow. I'm "pob" over there.
For what it's worth, the only interaction I have with the GUI is when closing. I can actually click on the buttons of the "save" pop up window.
Cheers Pierre-Olivier
On 18/01/2013 17:15, Jamie Bullock wrote:
On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant po.boulant@free.fr wrote:
Hi, > > It looks very nice indeed. > > Running the Windows version, I have a problem with the mouse. > I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks. > > Windows 7, 64bit OS. > I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that.
I hope you don't mind but I've added your report to the UserVoice forum:
http://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mouse-interaction-not-working-on-64-bit-windows
If you "vote" for the issue, you will get an automatic notification when it is resolved.
Jamie
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
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, January 18, 2013 4:31 PM Subject: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
On 01/18/2013 04:14 PM, Jonathan Wilkes wrote:
From: Leandro da Mota Damasceno lemota@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Pierre-Olivier Boulant po.boulant@free.fr; pd-list
Sent: Friday, January 18, 2013 2:40 PM Subject: Re: [PD] [announce] Integra Live 1.5 released
So if we wanted to improve the GUI we would have to drop tcl/tk all
together or make it messy and heavy?
Depends on which features of the interface you want to improve. Ivica
improved the logic
that controls when scrollbars appear in a patch in Pd-l2ork, as well as
more efficient
movement and manipulation of iemguis. However, stuff like gradients in a
patch, zooming
on a canvas, better handling of fonts, and many other issues require
"messes" of code.
-Jonathan
It also depends on what you mean by "improve". I personally want Pd's GUI to look and act as native as possible on any given platform, and it turns out that Tk is one of the better GUI toolkits for doing that. Tk is quite slow for raw drawing, so that's a problem.
Tk doesn't do that at all in GNU/Linux, as far as I can tell. That's why that gui plugin is called gtk-look, because it looks somewhat like a gtk window but does not act like it. For example: click the File menu, then click it again to close it (which is how gtk menus work). It won't close. In fact tk menus work exactly this way on any distro that uses x11 as its window system, regardless of the look-and-feel of the distro. Controlling/standardizing look-and-feel is what every desktop environment and window manager is there to do in the first place, even/especially the behemoths like kde and gnome. Setting aside some Gnome 3 ui nonsense, most modern gui toolkits seem to be aware of basic common features among them and have "sane" defaults that essentially standardize the ux for GNU/Linux users. Keeping with this example-- clicking through a menu in Minitube (built with Qt) is exactly the same experience as clicking through a menu in Firefox (probably gtk). Clicking through a tk menu is not the same as these.
Nor is bringing up a file selection menu. The length of the full path determines the width of the file selection menu ("Open" menu), and the icon to climb up one directory is to the RIGHT of this string. Thus if you start inside a directory that has a long path and you want to climb out, say, two levels, each time you click the icon the window gets smaller and the icon moves out from under your mouse, making it unnecessarily burdensome to quickly climb out to the root directory. The "open" dialogue for Qt and Gtk look exactly the same in Gnome because it is actually the _native_ dialogue for the DE/WM/whatever.
If the ttk theming engine can be used to change this behavior that'd be great, but I couldn't find any documentation that even hints that it does. In fact on OSX this ttk theming engine actually guesses wrong at the bgcolor for a dialog window (which took me awhile to figure out with the search plugin).
Anyway I guess tk was developed at a time when you could actually claim "x" as a "platform", but unless you're comfortable using the phrase "information superhighway" and putting rainbow dividers on your webpage then "emulating motif" shouldn't really count as native look-and-feel.
-Jonathan
On 01/18/2013 05:31 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, January 18, 2013 4:31 PM Subject: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
On 01/18/2013 04:14 PM, Jonathan Wilkes wrote:
From: Leandro da Mota Damasceno lemota@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Pierre-Olivier Boulant po.boulant@free.fr; pd-list
Sent: Friday, January 18, 2013 2:40 PM Subject: Re: [PD] [announce] Integra Live 1.5 released
So if we wanted to improve the GUI we would have to drop tcl/tk all
together or make it messy and heavy?
Depends on which features of the interface you want to improve. Ivica
improved the logic
that controls when scrollbars appear in a patch in Pd-l2ork, as well as
more efficient
movement and manipulation of iemguis. However, stuff like gradients in a
patch, zooming
on a canvas, better handling of fonts, and many other issues require
"messes" of code.
-Jonathan
It also depends on what you mean by "improve". I personally want Pd's GUI to look and act as native as possible on any given platform, and it turns out that Tk is one of the better GUI toolkits for doing that. Tk is quite slow for raw drawing, so that's a problem.
Tk doesn't do that at all in GNU/Linux, as far as I can tell. That's why that gui plugin is called gtk-look, because it looks somewhat like a gtk window but does not act like it. For example: click the File menu, then click it again to close it (which is how gtk menus work). It won't close. In fact tk menus work exactly this way on any distro that uses x11 as its window system, regardless of the look-and-feel of the distro. Controlling/standardizing look-and-feel is what every desktop environment and window manager is there to do in the first place, even/especially the behemoths like kde and gnome. Setting aside some Gnome 3 ui nonsense, most modern gui toolkits seem to be aware of basic common features among them and have "sane" defaults that essentially standardize the ux for GNU/Linux users. Keeping with this example-- clicking through a menu in Minitube (built with Qt) is exactly the same experience as clicking through a menu in Firefox (probably gtk). Clicking through a tk menu is not the same as these.
Nor is bringing up a file selection menu. The length of the full path determines the width of the file selection menu ("Open" menu), and the icon to climb up one directory is to the RIGHT of this string. Thus if you start inside a directory that has a long path and you want to climb out, say, two levels, each time you click the icon the window gets smaller and the icon moves out from under your mouse, making it unnecessarily burdensome to quickly climb out to the root directory. The "open" dialogue for Qt and Gtk look exactly the same in Gnome because it is actually the _native_ dialogue for the DE/WM/whatever.
If the ttk theming engine can be used to change this behavior that'd be great, but I couldn't find any documentation that even hints that it does. In fact on OSX this ttk theming engine actually guesses wrong at the bgcolor for a dialog window (which took me awhile to figure out with the search plugin).
Anyway I guess tk was developed at a time when you could actually claim "x" as a "platform", but unless you're comfortable using the phrase "information superhighway" and putting rainbow dividers on your webpage then "emulating motif" shouldn't really count as native look-and-feel.
-Jonathan
This is true, but its also much more difficult situation since when you're talking X11, you're talking GNOME/GTK, KDE/QT, XFCE, OpenBox, Fluxbox, etc. etc. So then Pd would have to detect which of those it should look like. What do you do when someone is running XFCE with GNOME and KDE apps?
One solution is plugins for each of those, then the user can choose. It would be great if someone could get Ttk theming working with Pd, here are some tips: http://blog.ssokolow.com/archives/2011/05/02/making-tk-applications-a-bit-le... http://blog.ssokolow.com/archives/2011/10/01/installing-a-new-ttktile-theme/ http://www.ellogon.org/petasis/tcltk-projects/tilegtk
Here's one plugin I use by Lorenzo Sutton, which gives you GTK open and save panels (muuuch better): https://puredata.info/downloads/zenity-gtk-open-save
.hc
On 18/01/13 22:31, Hans-Christoph Steiner wrote:
It also depends on what you mean by "improve". I personally want Pd's GUI to look and act as native as possible on any given platform, and it turns out that Tk is one of the better GUI toolkits for doing that.
I think that supercollider
is a great example of (cross-platform)
GUI-improvement with their switch to Qt.
my 2 cents y
i also vote personally for a different GUI for PD. i'm firmly in the 'same look, regardless of platform' camp, and have never been visually impressed by any app using Tcl/Tk. it just seems dated. i have no programming experience myself but i can cheer from the sidelines. Juce is a pretty good candidate from what i've seen.
scott
On Sat, Jan 19, 2013 at 4:40 AM, yvan volochine yvan.pd@gmail.com wrote:
On 18/01/13 22:31, Hans-Christoph Steiner wrote:
It also depends on what you mean by "improve". I personally want Pd's GUI to look and act as native as possible on any given platform, and it turns out that Tk is one of the better GUI toolkits for doing that.
I think that
supercollider
is a great example of (cross-platform) GUI-improvement with their switch to Qt.my 2 cents y
-- http://yvanvolochine.com http://soundcloud.com/**yvanvolochinehttp://soundcloud.com/yvanvolochine http://vimeo.com/yv
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
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
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.
.hc
On 01/19/2013 08:20 PM, Hans-Christoph Steiner wrote:
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.
oh yes definitely. i'm personally not interested in building a JUCE-based toolkit for now (and as a matter of fact, am quite happy with the current interface). all my ambitions are directed into abstracting the tcl part away, so that someone _can_ implement an alternative GUI.
fgamsdr IOhannes
haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near future. its a tossup between fltk, qt , opengl ,juce, and processing. i just want to be able to add my waveform data filenames to the presets with a fileopen dialog without using an external, string parsing like .scl files that have 100.00 or 3/2, and polyphonic patchcords would be nice.
http://lists.puredata.info/pipermail/pd-list/2011-03/087772.html
----- Original Message -----
From: Billy Stiltner billy.stiltner@gmail.com To: IOhannes zmölnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Sunday, January 20, 2013 10:04 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near future. its a tossup between fltk, qt , opengl ,juce, and processing. i just want to be able to add my waveform data filenames to the presets with a fileopen dialog without using an external, string parsing like .scl files that have 100.00 or 3/2, and polyphonic patchcords would be nice.
What about the -guicmd "cmd..." flag? Could one write a pd-gui.html that lives at localhost:1234, and have it talk to pd at its port on localhost?
Then you could just write the interface with html5 canvas, svg, javascript, or whatever.
-Jonathan
http://lists.puredata.info/pipermail/pd-list/2011-03/087772.html
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
yeah i have an html javascript java socket interface to my fractal sequencer that draws the fractal that the orbits are being generated from. the only thing i'm sending though is the mouse position which is translated to the fractal space coordinates so the patch can spit out the orbits from that point as well as a zoom feature to zoom in and also a switch to switch from mandelbrot to burningshipx or burningshipy. i do not use the -guicmd or pdnogui yet but plan on using something like that to develop simple tutorials
On Mon, Jan 21, 2013 at 12:54 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Billy Stiltner billy.stiltner@gmail.com To: IOhannes zmölnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Sunday, January 20, 2013 10:04 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near future. its a tossup between fltk, qt , opengl ,juce, and processing. i just want to be able to add my waveform data filenames to the presets with a fileopen dialog without using an external, string parsing like .scl files that have 100.00 or 3/2, and polyphonic patchcords would be nice.
What about the -guicmd "cmd..." flag? Could one write a pd-gui.html that lives at localhost:1234, and have it talk to pd at its port on localhost?
Then you could just write the interface with html5 canvas, svg, javascript, or whatever.
-Jonathan
http://lists.puredata.info/pipermail/pd-list/2011-03/087772.html
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/21/2013 12:54 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Billy Stiltner billy.stiltner@gmail.com To: IOhannes zmölnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Sunday, January 20, 2013 10:04 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near future. its a tossup between fltk, qt , opengl ,juce, and processing. i just want to be able to add my waveform data filenames to the presets with a fileopen dialog without using an external, string parsing like .scl files that have 100.00 or 3/2, and polyphonic patchcords would be nice.
What about the -guicmd "cmd..." flag? Could one write a pd-gui.html that lives at localhost:1234, and have it talk to pd at its port on localhost?
Then you could just write the interface with html5 canvas, svg, javascript, or whatever.
-Jonathan
That sounds feasible to me.
.hc
That sounded like a Lego approach. :)
So the way I see it the GUI development should be in the most seemless way for the user, right?
And we also have the problem between people who prefer a simple, leaner GUI approach (the classic PD, for instance) against people who prefer a more sofisticated, and sexy GUI. And I believe both groups would also like some more knobs and stuff...
so basically, we should at least have two options of gui: simple (classic) or sophisticated (sexy). But it would be cool to make it open enough to anyone develop their own or come up with new and customized ones. that would make PD way cooler than Max/MSP or anything else. So for that to work (and now I must admit I really don't know the architecture behind this part of PD, so maybe it is already this way), the comunication between the GUI and the rest of PD should be kept simple, fast and modulated, working with the leanest possible API. I also think this is a good approach considering that most of these toolkits will stop getting support way before PD ceases to exist. I have also thought about the possibility of skins, but then loading a bunch of bitmaps would not help in terms of performance...
At the same time we pick a toolkit and focus on that one first. So we should think of at least two teems, right? One at the GUI end and the other at the core PD end...
What do you guys think?
On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner hans@at.or.atwrote:
On 01/21/2013 12:54 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Billy Stiltner billy.stiltner@gmail.com To: IOhannes zmölnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Sunday, January 20, 2013 10:04 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near future. its a tossup between fltk, qt , opengl ,juce, and processing. i just want to be able to add my waveform data filenames to the presets with a fileopen dialog without using an external, string parsing like .scl files that have 100.00 or 3/2, and polyphonic patchcords would be nice.
What about the -guicmd "cmd..." flag? Could one write a pd-gui.html that lives at localhost:1234, and have it talk to pd at its port on
localhost?
Then you could just write the interface with html5 canvas, svg, javascript, or whatever.
-Jonathan
That sounds feasible to me.
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think this is the general idea of what everyone wants to support. But the way is actually takes shape is going to depend on whoever actually does the work. A great example of this is the PDDP (Pure Data Documentation Project). We had lots of design meetings and then no one implemented the ideas. Then Jonathan picked up from that what was interesting to him and made the whole meta help system, the search plugin, etc.
The lesson there for me is that big design discussions only work if the people involved them are willing to do the work to implement them. Instead, I think for a more decentralized community like this one, we only should nail down the key parts that everyone must use, then leave other decisions to those who are implementing those parts.
So that means I'm happy to help people write there own GUI, and I'll definitely be involved in the work of making it possible with Pd.
.hc
On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote:
That sounded like a Lego approach. :)
So the way I see it the GUI development should be in the most seemless way for the user, right?
And we also have the problem between people who prefer a simple, leaner GUI approach (the classic PD, for instance) against people who prefer a more sofisticated, and sexy GUI. And I believe both groups would also like some more knobs and stuff...
so basically, we should at least have two options of gui: simple (classic) or sophisticated (sexy). But it would be cool to make it open enough to anyone develop their own or come up with new and customized ones. that would make PD way cooler than Max/MSP or anything else. So for that to work (and now I must admit I really don't know the architecture behind this part of PD, so maybe it is already this way), the comunication between the GUI and the rest of PD should be kept simple, fast and modulated, working with the leanest possible API. I also think this is a good approach considering that most of these toolkits will stop getting support way before PD ceases to exist. I have also thought about the possibility of skins, but then loading a bunch of bitmaps would not help in terms of performance...
At the same time we pick a toolkit and focus on that one first. So we should think of at least two teems, right? One at the GUI end and the other at the core PD end...
What do you guys think?
On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner hans@at.or.atwrote:
On 01/21/2013 12:54 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Billy Stiltner billy.stiltner@gmail.com To: IOhannes zmölnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Sunday, January 20, 2013 10:04 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near future. its a tossup between fltk, qt , opengl ,juce, and processing. i just want to be able to add my waveform data filenames to the presets with a fileopen dialog without using an external, string parsing like .scl files that have 100.00 or 3/2, and polyphonic patchcords would be nice.
What about the -guicmd "cmd..." flag? Could one write a pd-gui.html that lives at localhost:1234, and have it talk to pd at its port on
localhost?
Then you could just write the interface with html5 canvas, svg, javascript, or whatever.
-Jonathan
That sounds feasible to me.
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You're right. Damn, you're always right :)
So, just to know where we are right now... What have been tested/done regarding the GUIs toolkits so far? I think we should at least have this set and go on from there...
On Mon, Jan 21, 2013 at 5:31 PM, Hans-Christoph Steiner hans@at.or.atwrote:
I think this is the general idea of what everyone wants to support. But the way is actually takes shape is going to depend on whoever actually does the work. A great example of this is the PDDP (Pure Data Documentation Project). We had lots of design meetings and then no one implemented the ideas. Then Jonathan picked up from that what was interesting to him and made the whole meta help system, the search plugin, etc.
The lesson there for me is that big design discussions only work if the people involved them are willing to do the work to implement them. Instead, I think for a more decentralized community like this one, we only should nail down the key parts that everyone must use, then leave other decisions to those who are implementing those parts.
So that means I'm happy to help people write there own GUI, and I'll definitely be involved in the work of making it possible with Pd.
.hc
On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote:
That sounded like a Lego approach. :)
So the way I see it the GUI development should be in the most seemless
way
for the user, right?
And we also have the problem between people who prefer a simple, leaner
GUI
approach (the classic PD, for instance) against people who prefer a more sofisticated, and sexy GUI. And I believe both groups would also like
some
more knobs and stuff...
so basically, we should at least have two options of gui: simple
(classic)
or sophisticated (sexy). But it would be cool to make it open enough to anyone develop their own or come up with new and customized ones. that would make PD way cooler than Max/MSP or anything else. So for that to
work
(and now I must admit I really don't know the architecture behind this
part
of PD, so maybe it is already this way), the comunication between the GUI and the rest of PD should be kept simple, fast and modulated, working
with
the leanest possible API. I also think this is a good approach
considering
that most of these toolkits will stop getting support way before PD
ceases
to exist. I have also thought about the possibility of skins, but then loading a bunch of bitmaps would not help in terms of performance...
At the same time we pick a toolkit and focus on that one first. So we should think of at least two teems, right? One at the GUI end and the
other
at the core PD end...
What do you guys think?
On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner <hans@at.or.at wrote:
On 01/21/2013 12:54 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Billy Stiltner billy.stiltner@gmail.com To: IOhannes zmölnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Sunday, January 20, 2013 10:04 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near future. its a tossup between fltk, qt , opengl ,juce, and processing. i just want to be able to add my waveform data filenames to the presets with a fileopen dialog without using an external, string parsing like .scl files that have 100.00 or 3/2, and polyphonic patchcords would be nice.
What about the -guicmd "cmd..." flag? Could one write a pd-gui.html that lives at localhost:1234, and have it talk to pd at its port on
localhost?
Then you could just write the interface with html5 canvas, svg, javascript, or whatever.
-Jonathan
That sounds feasible to me.
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
So all those interested in a new GUI should start working on it, there is lots of interest. Then we can incrementally change pd itself as there is a need.
.hc
On 01/21/2013 02:48 PM, Leandro da Mota Damasceno wrote:
You're right. Damn, you're always right :)
So, just to know where we are right now... What have been tested/done regarding the GUIs toolkits so far? I think we should at least have this set and go on from there...
On Mon, Jan 21, 2013 at 5:31 PM, Hans-Christoph Steiner hans@at.or.atwrote:
I think this is the general idea of what everyone wants to support. But the way is actually takes shape is going to depend on whoever actually does the work. A great example of this is the PDDP (Pure Data Documentation Project). We had lots of design meetings and then no one implemented the ideas. Then Jonathan picked up from that what was interesting to him and made the whole meta help system, the search plugin, etc.
The lesson there for me is that big design discussions only work if the people involved them are willing to do the work to implement them. Instead, I think for a more decentralized community like this one, we only should nail down the key parts that everyone must use, then leave other decisions to those who are implementing those parts.
So that means I'm happy to help people write there own GUI, and I'll definitely be involved in the work of making it possible with Pd.
.hc
On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote:
That sounded like a Lego approach. :)
So the way I see it the GUI development should be in the most seemless
way
for the user, right?
And we also have the problem between people who prefer a simple, leaner
GUI
approach (the classic PD, for instance) against people who prefer a more sofisticated, and sexy GUI. And I believe both groups would also like
some
more knobs and stuff...
so basically, we should at least have two options of gui: simple
(classic)
or sophisticated (sexy). But it would be cool to make it open enough to anyone develop their own or come up with new and customized ones. that would make PD way cooler than Max/MSP or anything else. So for that to
work
(and now I must admit I really don't know the architecture behind this
part
of PD, so maybe it is already this way), the comunication between the GUI and the rest of PD should be kept simple, fast and modulated, working
with
the leanest possible API. I also think this is a good approach
considering
that most of these toolkits will stop getting support way before PD
ceases
to exist. I have also thought about the possibility of skins, but then loading a bunch of bitmaps would not help in terms of performance...
At the same time we pick a toolkit and focus on that one first. So we should think of at least two teems, right? One at the GUI end and the
other
at the core PD end...
What do you guys think?
On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner <hans@at.or.at wrote:
On 01/21/2013 12:54 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Billy Stiltner billy.stiltner@gmail.com To: IOhannes zmölnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Sunday, January 20, 2013 10:04 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near future. its a tossup between fltk, qt , opengl ,juce, and processing. i just want to be able to add my waveform data filenames to the presets with a fileopen dialog without using an external, string parsing like .scl files that have 100.00 or 3/2, and polyphonic patchcords would be nice.
What about the -guicmd "cmd..." flag? Could one write a pd-gui.html that lives at localhost:1234, and have it talk to pd at its port on
localhost?
Then you could just write the interface with html5 canvas, svg, javascript, or whatever.
-Jonathan
That sounds feasible to me.
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
so let's see...Who´s working with what so far?
I´d love to join a team and start learning how to code with one of the toolkits.
On Mon, Jan 21, 2013 at 6:03 PM, Hans-Christoph Steiner hans@at.or.atwrote:
So all those interested in a new GUI should start working on it, there is lots of interest. Then we can incrementally change pd itself as there is a need.
.hc
On 01/21/2013 02:48 PM, Leandro da Mota Damasceno wrote:
You're right. Damn, you're always right :)
So, just to know where we are right now... What have been tested/done regarding the GUIs toolkits so far? I think we should at least have this set and go on from there...
On Mon, Jan 21, 2013 at 5:31 PM, Hans-Christoph Steiner <hans@at.or.at wrote:
I think this is the general idea of what everyone wants to support. But the way is actually takes shape is going to depend on whoever actually does
the
work. A great example of this is the PDDP (Pure Data Documentation Project). We had lots of design meetings and then no one implemented the ideas.
Then
Jonathan picked up from that what was interesting to him and made the
whole
meta help system, the search plugin, etc.
The lesson there for me is that big design discussions only work if the people involved them are willing to do the work to implement them. Instead, I think for a more decentralized community like this one, we only should nail
down
the key parts that everyone must use, then leave other decisions to those
who
are implementing those parts.
So that means I'm happy to help people write there own GUI, and I'll definitely be involved in the work of making it possible with Pd.
.hc
On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote:
That sounded like a Lego approach. :)
So the way I see it the GUI development should be in the most seemless
way
for the user, right?
And we also have the problem between people who prefer a simple, leaner
GUI
approach (the classic PD, for instance) against people who prefer a
more
sofisticated, and sexy GUI. And I believe both groups would also like
some
more knobs and stuff...
so basically, we should at least have two options of gui: simple
(classic)
or sophisticated (sexy). But it would be cool to make it open enough to anyone develop their own or come up with new and customized ones. that would make PD way cooler than Max/MSP or anything else. So for that to
work
(and now I must admit I really don't know the architecture behind this
part
of PD, so maybe it is already this way), the comunication between the
GUI
and the rest of PD should be kept simple, fast and modulated, working
with
the leanest possible API. I also think this is a good approach
considering
that most of these toolkits will stop getting support way before PD
ceases
to exist. I have also thought about the possibility of skins, but then loading a bunch of bitmaps would not help in terms of performance...
At the same time we pick a toolkit and focus on that one first. So we should think of at least two teems, right? One at the GUI end and the
other
at the core PD end...
What do you guys think?
On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner <hans@at.or.at wrote:
On 01/21/2013 12:54 AM, Jonathan Wilkes wrote:
----- Original Message -----
> From: Billy Stiltner billy.stiltner@gmail.com > To: IOhannes zmölnig zmoelnig@iem.at > Cc: pd-list@iem.at > Sent: Sunday, January 20, 2013 10:04 PM > Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
> > haha , last month i tried to install juce to see about making an > alternate graphics front end to my patches. there was some
weirdness
> in the way you compile it then run the introjucer or somethin to > update it then after the update something didn't quite work right. > then there are all the old projects that use the old steinberg vst
sdk
> which you cant get from steinberg anymore so all that is just
awful. i
> think that there should be a really nice updated version of juce > either available now or in the near future. its a tossup between > fltk, qt , opengl ,juce, and processing. i just want to be able to > add my waveform data filenames to the presets with a fileopen dialog > without using an external, string parsing like .scl files that have > 100.00 or 3/2, and polyphonic patchcords would be nice.
What about the -guicmd "cmd..." flag? Could one write a pd-gui.html that lives at localhost:1234, and have it talk to pd at its port on
localhost?
Then you could just write the interface with html5 canvas, svg, javascript, or whatever.
-Jonathan
That sounds feasible to me.
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Wouldn't it be a good idea to settle on a graphics metalanguage rather than translating tcl code to qt or whatever?
Martin
On 2013-01-21 15:11, Leandro da Mota Damasceno wrote:
so let's see...Who´s working with what so far?
I´d love to join a team and start learning how to code with one of the toolkits.
On Mon, Jan 21, 2013 at 6:03 PM, Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at> wrote:
So all those interested in a new GUI should start working on it, there is lots of interest. Then we can incrementally change pd itself as there is a need. .hc On 01/21/2013 02:48 PM, Leandro da Mota Damasceno wrote: > You're right. Damn, you're always right :) > > So, just to know where we are right now... What have been tested/done > regarding the GUIs toolkits so far? I think we should at least have this > set and go on from there... > > > On Mon, Jan 21, 2013 at 5:31 PM, Hans-Christoph Steiner <hans@at.or.at <mailto:hans@at.or.at>>wrote: > >> >> I think this is the general idea of what everyone wants to support. But >> the >> way is actually takes shape is going to depend on whoever actually does the >> work. A great example of this is the PDDP (Pure Data Documentation >> Project). >> We had lots of design meetings and then no one implemented the ideas. Then >> Jonathan picked up from that what was interesting to him and made the whole >> meta help system, the search plugin, etc. >> >> The lesson there for me is that big design discussions only work if the >> people >> involved them are willing to do the work to implement them. Instead, I >> think >> for a more decentralized community like this one, we only should nail down >> the >> key parts that everyone must use, then leave other decisions to those who >> are >> implementing those parts. >> >> So that means I'm happy to help people write there own GUI, and I'll >> definitely be involved in the work of making it possible with Pd. >> >> .hc >> >> On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote: >>> That sounded like a Lego approach. :) >>> >>> So the way I see it the GUI development should be in the most seemless >> way >>> for the user, right? >>> >>> And we also have the problem between people who prefer a simple, leaner >> GUI >>> approach (the classic PD, for instance) against people who prefer a more >>> sofisticated, and sexy GUI. And I believe both groups would also like >> some >>> more knobs and stuff... >>> >>> so basically, we should at least have two options of gui: simple >> (classic) >>> or sophisticated (sexy). But it would be cool to make it open enough to >>> anyone develop their own or come up with new and customized ones. that >>> would make PD way cooler than Max/MSP or anything else. So for that to >> work >>> (and now I must admit I really don't know the architecture behind this >> part >>> of PD, so maybe it is already this way), the comunication between the GUI >>> and the rest of PD should be kept simple, fast and modulated, working >> with >>> the leanest possible API. I also think this is a good approach >> considering >>> that most of these toolkits will stop getting support way before PD >> ceases >>> to exist. I have also thought about the possibility of skins, but then >>> loading a bunch of bitmaps would not help in terms of performance... >>> >>> >>> At the same time we pick a toolkit and focus on that one first. So we >>> should think of at least two teems, right? One at the GUI end and the >> other >>> at the core PD end... >>> >>> What do you guys think? >>> >>> >>> On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner <hans@at.or.at <mailto:hans@at.or.at> >>> wrote: >>> >>>> On 01/21/2013 12:54 AM, Jonathan Wilkes wrote: >>>>> ----- Original Message ----- >>>>> >>>>>> From: Billy Stiltner <billy.stiltner@gmail.com <mailto:billy.stiltner@gmail.com>> >>>>>> To: IOhannes zmölnig <zmoelnig@iem.at <mailto:zmoelnig@iem.at>> >>>>>> Cc: pd-list@iem.at <mailto:pd-list@iem.at> >>>>>> Sent: Sunday, January 20, 2013 10:04 PM >>>>>> Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 >>>> released >>>>>> >>>>>> haha , last month i tried to install juce to see about making an >>>>>> alternate graphics front end to my patches. there was some weirdness >>>>>> in the way you compile it then run the introjucer or somethin to >>>>>> update it then after the update something didn't quite work right. >>>>>> then there are all the old projects that use the old steinberg vst sdk >>>>>> which you cant get from steinberg anymore so all that is just awful. i >>>>>> think that there should be a really nice updated version of juce >>>>>> either available now or in the near future. its a tossup between >>>>>> fltk, qt , opengl ,juce, and processing. i just want to be able to >>>>>> add my waveform data filenames to the presets with a fileopen dialog >>>>>> without using an external, string parsing like .scl files that have >>>>>> 100.00 or 3/2, and polyphonic patchcords would be nice. >>>>> >>>>> What about the -guicmd "cmd..." flag? Could one write a pd-gui.html >>>>> that lives at localhost:1234, and have it talk to pd at its port on >>>> localhost? >>>>> >>>>> Then you could just write the interface with html5 canvas, svg, >>>>> javascript, or whatever. >>>>> >>>>> -Jonathan >>>> >>>> >>>> That sounds feasible to me. >>>> >>>> .hc >>>> >>>> _______________________________________________ >>>> Pd-list@iem.at <mailto: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
Sounds like a good idea, but I don't think that should block anyone from starting. And having a real example to work with will make it much easier to figure out how to convert the Tcl into something more generic. The graphic ideas in Pd are almost all really simple: draw an object box, draw a message box, draw an array, draw connections. And indeed I think the communications between pd and pd-gui should be logical rather than graphical, i.e. "connect 0 1 2 5" instead of a line draw command.
.hc
On 01/21/2013 05:35 PM, Martin Peach wrote:
Wouldn't it be a good idea to settle on a graphics metalanguage rather than translating tcl code to qt or whatever?
Martin
On 2013-01-21 15:11, Leandro da Mota Damasceno wrote:
so let's see...Who´s working with what so far?
I´d love to join a team and start learning how to code with one of the toolkits.
On Mon, Jan 21, 2013 at 6:03 PM, Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at> wrote:
So all those interested in a new GUI should start working on it, there is lots of interest. Then we can incrementally change pd itself as there is a need. .hc On 01/21/2013 02:48 PM, Leandro da Mota Damasceno wrote: > You're right. Damn, you're always right :) > > So, just to know where we are right now... What have been tested/done > regarding the GUIs toolkits so far? I think we should at least have this > set and go on from there... > > > On Mon, Jan 21, 2013 at 5:31 PM, Hans-Christoph Steiner <hans@at.or.at <mailto:hans@at.or.at>>wrote: > >> >> I think this is the general idea of what everyone wants to support. But >> the >> way is actually takes shape is going to depend on whoever actually does the >> work. A great example of this is the PDDP (Pure Data Documentation >> Project). >> We had lots of design meetings and then no one implemented the ideas. Then >> Jonathan picked up from that what was interesting to him and made the whole >> meta help system, the search plugin, etc. >> >> The lesson there for me is that big design discussions only work if the >> people >> involved them are willing to do the work to implement them. Instead, I >> think >> for a more decentralized community like this one, we only should nail down >> the >> key parts that everyone must use, then leave other decisions to those who >> are >> implementing those parts. >> >> So that means I'm happy to help people write there own GUI, and I'll >> definitely be involved in the work of making it possible with Pd. >> >> .hc >> >> On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote: >>> That sounded like a Lego approach. :) >>> >>> So the way I see it the GUI development should be in the most seemless >> way >>> for the user, right? >>> >>> And we also have the problem between people who prefer a simple, leaner >> GUI >>> approach (the classic PD, for instance) against people who prefer a more >>> sofisticated, and sexy GUI. And I believe both groups would also like >> some >>> more knobs and stuff... >>> >>> so basically, we should at least have two options of gui: simple >> (classic) >>> or sophisticated (sexy). But it would be cool to make it open enough to >>> anyone develop their own or come up with new and customized ones. that >>> would make PD way cooler than Max/MSP or anything else. So for that to >> work >>> (and now I must admit I really don't know the architecture behind this >> part >>> of PD, so maybe it is already this way), the comunication between the GUI >>> and the rest of PD should be kept simple, fast and modulated, working >> with >>> the leanest possible API. I also think this is a good approach >> considering >>> that most of these toolkits will stop getting support way before PD >> ceases >>> to exist. I have also thought about the possibility of skins, but then >>> loading a bunch of bitmaps would not help in terms of performance... >>> >>> >>> At the same time we pick a toolkit and focus on that one first. So we >>> should think of at least two teems, right? One at the GUI end and the >> other >>> at the core PD end... >>> >>> What do you guys think? >>> >>> >>> On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner <hans@at.or.at <mailto:hans@at.or.at> >>> wrote: >>> >>>> On 01/21/2013 12:54 AM, Jonathan Wilkes wrote: >>>>> ----- Original Message ----- >>>>> >>>>>> From: Billy Stiltner <billy.stiltner@gmail.com <mailto:billy.stiltner@gmail.com>> >>>>>> To: IOhannes zmölnig <zmoelnig@iem.at <mailto:zmoelnig@iem.at>> >>>>>> Cc: pd-list@iem.at <mailto:pd-list@iem.at> >>>>>> Sent: Sunday, January 20, 2013 10:04 PM >>>>>> Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 >>>> released >>>>>> >>>>>> haha , last month i tried to install juce to see about making an >>>>>> alternate graphics front end to my patches. there was some weirdness >>>>>> in the way you compile it then run the introjucer or somethin to >>>>>> update it then after the update something didn't quite work right. >>>>>> then there are all the old projects that use the old steinberg vst sdk >>>>>> which you cant get from steinberg anymore so all that is just awful. i >>>>>> think that there should be a really nice updated version of juce >>>>>> either available now or in the near future. its a tossup between >>>>>> fltk, qt , opengl ,juce, and processing. i just want to be able to >>>>>> add my waveform data filenames to the presets with a fileopen dialog >>>>>> without using an external, string parsing like .scl files that have >>>>>> 100.00 or 3/2, and polyphonic patchcords would be nice. >>>>> >>>>> What about the -guicmd "cmd..." flag? Could one write a pd-gui.html >>>>> that lives at localhost:1234, and have it talk to pd at its port on >>>> localhost? >>>>> >>>>> Then you could just write the interface with html5 canvas, svg, >>>>> javascript, or whatever. >>>>> >>>>> -Jonathan >>>> >>>> >>>> That sounds feasible to me. >>>> >>>> .hc >>>> >>>> _______________________________________________ >>>> Pd-list@iem.at <mailto: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
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Martin Peach martin.peach@sympatico.ca Cc: PD List pd-list@iem.at Sent: Monday, January 21, 2013 5:48 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
Sounds like a good idea, but I don't think that should block anyone from starting. And having a real example to work with will make it much easier to figure out how to convert the Tcl into something more generic. The graphic ideas in Pd are almost all really simple: draw an object box, draw a message box, draw an array, draw connections. And indeed I think the communications between pd and pd-gui should be logical rather than graphical, i.e. "connect 0 1 2 5" instead of a line draw command.
(Here's a modest proposal, additions, revisions, critiques welcome)
To that end I think the best way to move is by leveraging the tcl "rename" command, which is what the DesireData devs were using to try out the tkzinc canvas (a gui canvas library which I don't recommend).
Basically, someone just needs to write a gui-plugin that renames the procs that are called from sys_gui and sys_vgui. This can be done incrementally. Basically the process would be to write new versions of those procs which a) call the old procs and b) send a FUDI-style message to a proc named something like "forward_mess".
Then, inside proc "forward_mess", write the tcl bindings for the gui toolkit of your choice to send that FUDI message to your alternate gui.
Example: Tooltips
For this example, we'll just consider "manual" tips, which get triggered from within Pd and are thus simple to describe:
[namecanvas foo]
[loadbang] | [tip 1 Hello World( | [s foo]
This will print "Hello World" in a little label in the bottom right-hand corner of a canvas. (Let's assume we've already got canvases working in the alternate gui.)
In the function canvas_tip from g_editor.c, sys_vgui is used to call the proc "pdtk_tip", where the first arg is the .x%lx.c canvas name, the second arg is the number "1" to signify a "manual" tip generated from pd (instead of an autotip from hovering over an object with the mouse). The rest of the args are the user's message, which is "1 Hello World" above (the initial float controls the message display-- nonzero for "on", zero for "off").
Armed with this information, how do we send a tip to our alternate gui? We use the "rename" command from tcl to hijack message from Pd to the pdtk_tip proc:
rename pdtk_tip pdtk_tip_old
Now pdtk_tip has been aliased to pdtk_tip_old, which frees us up to build our own pdtk_tip that will perform a "friendly" MITM attack on Pd:
proc pdtk_tip {w fromc show args} { pdtk_tip_old $w $fromc $show $args forward_mess [list $w "tip" $fromc $show [join $args]] }
And finally, inside forward_mess, put your code to forward the FUDI message to your alternate_gui:
proc forward_mess {args} { # actual command names may vary... ::alternate_gui_bindings::send $args }
Now, if I wrote all my tcl correctly, your alternate_gui will receive the message: .x%lx.c tip 1 1 Hello World
(Note-- this is not the same message that was sent within Pd that ultimately
calls the canvas_tip function. Is the aim to use the _exact_ same FUDI message in the GUI that gets passed within the "c" part of Pd? Or is it just to have _a_ message in FUDI form?)
Then in your alternate_gui you parse that message in the same way you would parse everything your alternate gui receives-- take the selector to refer to the object, the 1st arg as a method of that object, and the remaining args as the args to that method.
I still don't understand the details, but the last release of DesireData it looks like poe.tcl was matju's object-oriented tcl system for handling the gui side of things in a way something like what I describe above. His classes seem to mimic the way things look in Pd, though I could be wrong because I still don't understand exactly how it works.
Anyway, the benefits to this approach:
the original gui which is still in tact
FUDI messages instead of raw tcl procs (and can be developed next to the old, fully-functional tcl gui)
messages to forward_mess, and another set of gui-plugins for each GUI toolkit people want to test out that just loads the tcl binding package for that toolkit and defines forward_mess to send the FUDI messages to it
tcl that processes FUDI messages), the sys_vgui stuff in Pd can be changed to send FUDI messages-- then you just remove the plugins and forward the messages straight to the alternate_gui with (or without) tcl as the middleman.
In fact, even before considering other toolkits, we can make the gui-plugin to rename procs to lay the groundwork for this, or someone smarter than me can make a proc that automates the process of renaming procs if that's even possible.
-Jonathan
.hc
On 01/21/2013 05:35 PM, Martin Peach wrote:
Wouldn't it be a good idea to settle on a graphics metalanguage rather
than
translating tcl code to qt or whatever?
Martin
On 2013-01-21 15:11, Leandro da Mota Damasceno wrote:
so let's see...Who´s working with what so far?
I´d love to join a team and start learning how to code with one of
the
toolkits.
On Mon, Jan 21, 2013 at 6:03 PM, Hans-Christoph Steiner
<hans@at.or.at
mailto:hans@at.or.at> wrote:
So all those interested in a new GUI should start working on it, there is lots of interest. Then we can incrementally change pd itself as there
is
a need.
.hc
On 01/21/2013 02:48 PM, Leandro da Mota Damasceno wrote: > You're right. Damn, you're always right :) > > So, just to know where we are right now... What have been
tested/done
> regarding the GUIs toolkits so far? I think we should at
least
have this > set and go on from there... > > > On Mon, Jan 21, 2013 at 5:31 PM, Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at>wrote: > >> >> I think this is the general idea of what everyone wants
to
support. But >> the >> way is actually takes shape is going to depend on whoever actually does the >> work. A great example of this is the PDDP (Pure Data
Documentation
>> Project). >> We had lots of design meetings and then no one
implemented the
ideas. Then >> Jonathan picked up from that what was interesting to him
and
made the whole >> meta help system, the search plugin, etc. >> >> The lesson there for me is that big design discussions
only work
if the >> people >> involved them are willing to do the work to implement
them.
Instead, I >> think >> for a more decentralized community like this one, we only
should
nail down >> the >> key parts that everyone must use, then leave other
decisions to
those who >> are >> implementing those parts. >> >> So that means I'm happy to help people write there
own GUI, and I'll
>> definitely be involved in the work of making it possible
with Pd.
>> >> .hc >> >> On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote: >>> That sounded like a Lego approach. :) >>> >>> So the way I see it the GUI development should be in
the most
seemless >> way >>> for the user, right? >>> >>> And we also have the problem between people who
prefer a
simple, leaner >> GUI >>> approach (the classic PD, for instance) against
people who
prefer a more >>> sofisticated, and sexy GUI. And I believe both groups
would
also like >> some >>> more knobs and stuff... >>> >>> so basically, we should at least have two options of
gui: simple
>> (classic) >>> or sophisticated (sexy). But it would be cool to make
it open
enough to >>> anyone develop their own or come up with new and
customized
ones. that >>> would make PD way cooler than Max/MSP or anything
else. So for
that to >> work >>> (and now I must admit I really don't know the
architecture
behind this >> part >>> of PD, so maybe it is already this way), the
comunication
between the GUI >>> and the rest of PD should be kept simple, fast and
modulated,
working >> with >>> the leanest possible API. I also think this is a good
approach
>> considering >>> that most of these toolkits will stop getting support
way before PD
>> ceases >>> to exist. I have also thought about the possibility
of skins,
but then >>> loading a bunch of bitmaps would not help in terms of performance... >>> >>> >>> At the same time we pick a toolkit and focus on that
one first.
So we >>> should think of at least two teems, right? One at the
GUI end
and the >> other >>> at the core PD end... >>> >>> What do you guys think? >>> >>> >>> On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph
Steiner
<hans@at.or.at mailto:hans@at.or.at >>> wrote: >>> >>>> On 01/21/2013 12:54 AM, Jonathan Wilkes wrote: >>>>> ----- Original Message ----- >>>>> >>>>>> From: Billy Stiltner
<billy.stiltner@gmail.com
mailto:billy.stiltner@gmail.com> >>>>>> To: IOhannes zmölnig <zmoelnig@iem.at
>>>>>> Cc: pd-list@iem.at
>>>>>> Sent: Sunday, January 20, 2013 10:04 PM >>>>>> Subject: Re: [PD] GUI toolkits and custom
GUIs WAS: Integra
Live 1.5 >>>> released >>>>>> >>>>>> haha , last month i tried to install juce
to see about making an
>>>>>> alternate graphics front end to my
patches. there was some
weirdness >>>>>> in the way you compile it then run the
introjucer or somethin to
>>>>>> update it then after the update something
didn't quite work
right. >>>>>> then there are all the old projects that
use the old
steinberg vst sdk >>>>>> which you cant get from steinberg anymore
so all that is
just awful. i >>>>>> think that there should be a really nice
updated version of juce
>>>>>> either available now or in the near
future. its a tossup
between >>>>>> fltk, qt , opengl ,juce, and processing.
i just want to be
able to >>>>>> add my waveform data filenames to the
presets with a
fileopen dialog >>>>>> without using an external, string parsing
like .scl files
that have >>>>>> 100.00 or 3/2, and polyphonic patchcords
would be nice.
>>>>> >>>>> What about the -guicmd "cmd..."
flag? Could one write a
pd-gui.html >>>>> that lives at localhost:1234, and have it
talk to pd at its
port on >>>> localhost? >>>>> >>>>> Then you could just write the interface with
html5 canvas, svg,
>>>>> javascript, or whatever. >>>>> >>>>> -Jonathan >>>> >>>> >>>> That sounds feasible to me. >>>> >>>> .hc >>>> >>>> _______________________________________________ >>>> Pd-list@iem.at mailto: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
On 01/21/2013 09:46 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Martin Peach martin.peach@sympatico.ca Cc: PD List pd-list@iem.at Sent: Monday, January 21, 2013 5:48 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
Sounds like a good idea, but I don't think that should block anyone from starting. And having a real example to work with will make it much easier to figure out how to convert the Tcl into something more generic. The graphic ideas in Pd are almost all really simple: draw an object box, draw a message box, draw an array, draw connections. And indeed I think the communications between pd and pd-gui should be logical rather than graphical, i.e. "connect 0 1 2 5" instead of a line draw command.
(Here's a modest proposal, additions, revisions, critiques welcome)
To that end I think the best way to move is by leveraging the tcl "rename" command, which is what the DesireData devs were using to try out the tkzinc canvas (a gui canvas library which I don't recommend).
Basically, someone just needs to write a gui-plugin that renames the procs that are called from sys_gui and sys_vgui. This can be done incrementally. Basically the process would be to write new versions of those procs which a) call the old procs and b) send a FUDI-style message to a proc named something like "forward_mess".
Then, inside proc "forward_mess", write the tcl bindings for the gui toolkit of your choice to send that FUDI message to your alternate gui.
Example: Tooltips
For this example, we'll just consider "manual" tips, which get triggered from within Pd and are thus simple to describe:
[namecanvas foo]
[loadbang] | [tip 1 Hello World( | [s foo]
This will print "Hello World" in a little label in the bottom right-hand corner of a canvas. (Let's assume we've already got canvases working in the alternate gui.)
In the function canvas_tip from g_editor.c, sys_vgui is used to call the proc "pdtk_tip", where the first arg is the .x%lx.c canvas name, the second arg is the number "1" to signify a "manual" tip generated from pd (instead of an autotip from hovering over an object with the mouse). The rest of the args are the user's message, which is "1 Hello World" above (the initial float controls the message display-- nonzero for "on", zero for "off").
Armed with this information, how do we send a tip to our alternate gui? We use the "rename" command from tcl to hijack message from Pd to the pdtk_tip proc:
rename pdtk_tip pdtk_tip_old
Now pdtk_tip has been aliased to pdtk_tip_old, which frees us up to build our own pdtk_tip that will perform a "friendly" MITM attack on Pd:
proc pdtk_tip {w fromc show args} { pdtk_tip_old $w $fromc $show $args forward_mess [list $w "tip" $fromc $show [join $args]] }
And finally, inside forward_mess, put your code to forward the FUDI message to your alternate_gui:
proc forward_mess {args} { # actual command names may vary... ::alternate_gui_bindings::send $args }
Now, if I wrote all my tcl correctly, your alternate_gui will receive the message: .x%lx.c tip 1 1 Hello World
(Note-- this is not the same message that was sent within Pd that ultimately
calls the canvas_tip function. Is the aim to use the _exact_ same FUDI message in the GUI that gets passed within the "c" part of Pd? Or is it just to have _a_ message in FUDI form?)
Then in your alternate_gui you parse that message in the same way you would parse everything your alternate gui receives-- take the selector to refer to the object, the 1st arg as a method of that object, and the remaining args as the args to that method.
I still don't understand the details, but the last release of DesireData it looks like poe.tcl was matju's object-oriented tcl system for handling the gui side of things in a way something like what I describe above. His classes seem to mimic the way things look in Pd, though I could be wrong because I still don't understand exactly how it works.
Anyway, the benefits to this approach:
- incremental-- you can build the new gui one piece at a time
- runs alongside tcl gui, so you can compare your incremental results to
the original gui which is still in tact
- your alternate_gui could be an object-oriented tcl/tk gui which processes
FUDI messages instead of raw tcl procs (and can be developed next to the old, fully-functional tcl gui)
- you can have one gui-plugin to rename all the procs and send FUDI
messages to forward_mess, and another set of gui-plugins for each GUI toolkit people want to test out that just loads the tcl binding package for that toolkit and defines forward_mess to send the FUDI messages to it
- once we get some fully functioning guis in other toolkits (or one in
tcl that processes FUDI messages), the sys_vgui stuff in Pd can be changed to send FUDI messages-- then you just remove the plugins and forward the messages straight to the alternate_gui with (or without) tcl as the middleman.
In fact, even before considering other toolkits, we can make the gui-plugin to rename procs to lay the groundwork for this, or someone smarter than me can make a proc that automates the process of renaming procs if that's even possible.
-Jonathan
I think most of the time it will just be better to modify the C code to make it send generic pd messages. But this hack could be a workaround if someone wanted to go that way.
.hc
how would that work, martin?
On Mon, Jan 21, 2013 at 8:35 PM, Martin Peach martin.peach@sympatico.cawrote:
Wouldn't it be a good idea to settle on a graphics metalanguage rather than translating tcl code to qt or whatever?
Martin
On 2013-01-21 15:11, Leandro da Mota Damasceno wrote:
so let's see...Who´s working with what so far?
I´d love to join a team and start learning how to code with one of the toolkits.
On Mon, Jan 21, 2013 at 6:03 PM, Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at> wrote:
So all those interested in a new GUI should start working on it, there is lots of interest. Then we can incrementally change pd itself as there is a need. .hc On 01/21/2013 02:48 PM, Leandro da Mota Damasceno wrote: > You're right. Damn, you're always right :) > > So, just to know where we are right now... What have been
tested/done > regarding the GUIs toolkits so far? I think we should at least have this > set and go on from there... > > > On Mon, Jan 21, 2013 at 5:31 PM, Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at>wrote:
> >> >> I think this is the general idea of what everyone wants to support. But >> the >> way is actually takes shape is going to depend on whoever actually does the >> work. A great example of this is the PDDP (Pure Data Documentation >> Project). >> We had lots of design meetings and then no one implemented the ideas. Then >> Jonathan picked up from that what was interesting to him and made the whole >> meta help system, the search plugin, etc. >> >> The lesson there for me is that big design discussions only work if the >> people >> involved them are willing to do the work to implement them. Instead, I >> think >> for a more decentralized community like this one, we only should nail down >> the >> key parts that everyone must use, then leave other decisions to those who >> are >> implementing those parts. >> >> So that means I'm happy to help people write there own GUI, and
I'll >> definitely be involved in the work of making it possible with Pd. >> >> .hc >> >> On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote: >>> That sounded like a Lego approach. :) >>> >>> So the way I see it the GUI development should be in the most seemless >> way >>> for the user, right? >>> >>> And we also have the problem between people who prefer a simple, leaner >> GUI >>> approach (the classic PD, for instance) against people who prefer a more >>> sofisticated, and sexy GUI. And I believe both groups would also like >> some >>> more knobs and stuff... >>> >>> so basically, we should at least have two options of gui: simple >> (classic) >>> or sophisticated (sexy). But it would be cool to make it open enough to >>> anyone develop their own or come up with new and customized ones. that >>> would make PD way cooler than Max/MSP or anything else. So for that to >> work >>> (and now I must admit I really don't know the architecture behind this >> part >>> of PD, so maybe it is already this way), the comunication between the GUI >>> and the rest of PD should be kept simple, fast and modulated, working >> with >>> the leanest possible API. I also think this is a good approach >> considering >>> that most of these toolkits will stop getting support way before PD >> ceases >>> to exist. I have also thought about the possibility of skins, but then >>> loading a bunch of bitmaps would not help in terms of performance... >>> >>> >>> At the same time we pick a toolkit and focus on that one first. So we >>> should think of at least two teems, right? One at the GUI end and the >> other >>> at the core PD end... >>> >>> What do you guys think? >>> >>> >>> On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at
>>> wrote: >>> >>>> On 01/21/2013 12:54 AM, Jonathan Wilkes wrote: >>>>> ----- Original Message ----- >>>>> >>>>>> From: Billy Stiltner <billy.stiltner@gmail.com <mailto:billy.stiltner@gmail.**com <billy.stiltner@gmail.com>>> >>>>>> To: IOhannes zmölnig <zmoelnig@iem.at <mailto:zmoelnig@iem.at
>>>>>> Cc: pd-list@iem.at <mailto:pd-list@iem.at> >>>>>> Sent: Sunday, January 20, 2013 10:04 PM >>>>>> Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 >>>> released >>>>>> >>>>>> haha , last month i tried to install juce to see about making
an >>>>>> alternate graphics front end to my patches. there was some weirdness >>>>>> in the way you compile it then run the introjucer or somethin to >>>>>> update it then after the update something didn't quite work right. >>>>>> then there are all the old projects that use the old steinberg vst sdk >>>>>> which you cant get from steinberg anymore so all that is just awful. i >>>>>> think that there should be a really nice updated version of juce >>>>>> either available now or in the near future. its a tossup between >>>>>> fltk, qt , opengl ,juce, and processing. i just want to be able to >>>>>> add my waveform data filenames to the presets with a fileopen dialog >>>>>> without using an external, string parsing like .scl files that have >>>>>> 100.00 or 3/2, and polyphonic patchcords would be nice. >>>>> >>>>> What about the -guicmd "cmd..." flag? Could one write a pd-gui.html >>>>> that lives at localhost:1234, and have it talk to pd at its port on >>>> localhost? >>>>> >>>>> Then you could just write the interface with html5 canvas, svg, >>>>> javascript, or whatever. >>>>> >>>>> -Jonathan >>>> >>>> >>>> That sounds feasible to me. >>>> >>>> .hc >>>> >>>> ______________________________**_________________ >>>> Pd-list@iem.at mailto:Pd-list@iem.at mailing list
>>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/**listinfo/pd-list<http://lists.puredata.info/listinfo/pd-list> >>>> >>> >> >
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Messages to the gui _should_ be pd messages (FUDI), no?
-Jonathan
----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Leandro da Mota Damasceno lemota@gmail.com Cc: PD List pd-list@iem.at Sent: Monday, January 21, 2013 5:35 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
Wouldn't it be a good idea to settle on a graphics metalanguage rather than translating tcl code to qt or whatever?
Martin
On 2013-01-21 15:11, Leandro da Mota Damasceno wrote:
so let's see...Who´s working with what so far?
I´d love to join a team and start learning how to code with one of the toolkits.
On Mon, Jan 21, 2013 at 6:03 PM, Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at> wrote:
So all those interested in a new GUI should start working on it, there is lots of interest. Then we can incrementally change pd itself as there is a need.
.hc
On 01/21/2013 02:48 PM, Leandro da Mota Damasceno wrote: > You're right. Damn, you're always right :) > > So, just to know where we are right now... What have been
tested/done
> regarding the GUIs toolkits so far? I think we should at least have this > set and go on from there... > > > On Mon, Jan 21, 2013 at 5:31 PM, Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at>wrote: > >> >> I think this is the general idea of what everyone wants to support. But >> the >> way is actually takes shape is going to depend on whoever actually does the >> work. A great example of this is the PDDP (Pure Data
Documentation
>> Project). >> We had lots of design meetings and then no one implemented
the
ideas. Then >> Jonathan picked up from that what was interesting to him and made the whole >> meta help system, the search plugin, etc. >> >> The lesson there for me is that big design discussions only
work
if the >> people >> involved them are willing to do the work to implement them. Instead, I >> think >> for a more decentralized community like this one, we only
should
nail down >> the >> key parts that everyone must use, then leave other decisions
to
those who >> are >> implementing those parts. >> >> So that means I'm happy to help people write there own
GUI, and I'll
>> definitely be involved in the work of making it possible with
Pd.
>> >> .hc >> >> On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote: >>> That sounded like a Lego approach. :) >>> >>> So the way I see it the GUI development should be in the
most
seemless >> way >>> for the user, right? >>> >>> And we also have the problem between people who prefer a simple, leaner >> GUI >>> approach (the classic PD, for instance) against people
who
prefer a more >>> sofisticated, and sexy GUI. And I believe both groups
would
also like >> some >>> more knobs and stuff... >>> >>> so basically, we should at least have two options of gui:
simple
>> (classic) >>> or sophisticated (sexy). But it would be cool to make it
open
enough to >>> anyone develop their own or come up with new and
customized
ones. that >>> would make PD way cooler than Max/MSP or anything else.
So for
that to >> work >>> (and now I must admit I really don't know the
architecture
behind this >> part >>> of PD, so maybe it is already this way), the comunication between the GUI >>> and the rest of PD should be kept simple, fast and
modulated,
working >> with >>> the leanest possible API. I also think this is a good
approach
>> considering >>> that most of these toolkits will stop getting support way
before PD
>> ceases >>> to exist. I have also thought about the possibility of
skins,
but then >>> loading a bunch of bitmaps would not help in terms of performance... >>> >>> >>> At the same time we pick a toolkit and focus on that one
first.
So we >>> should think of at least two teems, right? One at the GUI
end
and the >> other >>> at the core PD end... >>> >>> What do you guys think? >>> >>> >>> On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at >>> wrote: >>> >>>> On 01/21/2013 12:54 AM, Jonathan Wilkes wrote: >>>>> ----- Original Message ----- >>>>> >>>>>> From: Billy Stiltner
<billy.stiltner@gmail.com
mailto:billy.stiltner@gmail.com> >>>>>> To: IOhannes zmölnig <zmoelnig@iem.at
>>>>>> Cc: pd-list@iem.at
>>>>>> Sent: Sunday, January 20, 2013 10:04 PM >>>>>> Subject: Re: [PD] GUI toolkits and custom
GUIs WAS: Integra
Live 1.5 >>>> released >>>>>> >>>>>> haha , last month i tried to install juce to
see about making an
>>>>>> alternate graphics front end to my patches.
there was some
weirdness >>>>>> in the way you compile it then run the
introjucer or somethin to
>>>>>> update it then after the update something
didn't quite work
right. >>>>>> then there are all the old projects that use
the old
steinberg vst sdk >>>>>> which you cant get from steinberg anymore so
all that is
just awful. i >>>>>> think that there should be a really nice
updated version of juce
>>>>>> either available now or in the near future.
its a tossup
between >>>>>> fltk, qt , opengl ,juce, and processing. i
just want to be
able to >>>>>> add my waveform data filenames to the presets
with a
fileopen dialog >>>>>> without using an external, string parsing
like .scl files
that have >>>>>> 100.00 or 3/2, and polyphonic patchcords
would be nice.
>>>>> >>>>> What about the -guicmd "cmd..." flag?
Could one write a
pd-gui.html >>>>> that lives at localhost:1234, and have it talk to
pd at its
port on >>>> localhost? >>>>> >>>>> Then you could just write the interface with
html5 canvas, svg,
>>>>> javascript, or whatever. >>>>> >>>>> -Jonathan >>>> >>>> >>>> That sounds feasible to me. >>>> >>>> .hc >>>> >>>> _______________________________________________ >>>> Pd-list@iem.at mailto: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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-21 23:35, Martin Peach wrote:
Wouldn't it be a good idea to settle on a graphics metalanguage rather than translating tcl code to qt or whatever?
that's exactly my point: creating a FUDI-style communication from pd->gui, which can easily be parsed by any GUI-client you wish to use.
something like:
obj <id> <x> <y> <name> <args>
which will correctly render an object (whether it has rounded corners or shadows)
fafjrt IOhannes
So would it be an updated FUDI or an all new protocol?
On Tue, Jan 22, 2013 at 6:15 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-21 23:35, Martin Peach wrote:
Wouldn't it be a good idea to settle on a graphics metalanguage rather than translating tcl code to qt or whatever?
that's exactly my point: creating a FUDI-style communication from pd->gui, which can easily be parsed by any GUI-client you wish to use.
something like:
obj <id> <x> <y> <name> <args>
which will correctly render an object (whether it has rounded corners or shadows)
fafjrt IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlD+SrEACgkQkX2Xpv6ydvQP9QCgpNNq45sjxb86iEI6JC8N8e3d LQUAn3N9jbI98/e5OOeGIxz+OkE9DaMj =qQRF -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-22 12:49, Leandro da Mota Damasceno wrote:
So would it be an updated FUDI or an all new protocol?
it would be FUDI. (no reason to update it)
fgamsdr IOhannes
Are there tutorials or any documentation on fudi and pd-gui?
On Jan 22, 2013, at 10:14 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-22 12:49, Leandro da Mota Damasceno wrote:
So would it be an updated FUDI or an all new protocol?
it would be FUDI. (no reason to update it)
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlD+grYACgkQkX2Xpv6ydvQSjgCg3ZS7iZTZHOpQIEEYGuAK8kbO +24AnjtI/zqVFJRQThnuUS+L10S1ER+k =DjF7 -----END PGP SIGNATURE-----
FUDI is dead simple, its the format of Pd messages. Its basically any text you want ending with a semi-colon and a sometimes optional carriage return (i.e. "this is a FUDI message;\n"). If you open a .pd file in a text editor, all of the lines are FUDI messages.
The messages between pd and pd-gui are not really documented, but you can see them by doing:
pd -stderr -d 3
.hc
On 01/22/2013 07:40 AM, Leandro Damasceno wrote:
Are there tutorials or any documentation on fudi and pd-gui?
On Jan 22, 2013, at 10:14 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2013-01-22 12:49, Leandro da Mota Damasceno wrote:
So would it be an updated FUDI or an all new protocol?
it would be FUDI. (no reason to update it)
fgamsdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 22/01/13 09:15, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-21 23:35, Martin Peach wrote:
Wouldn't it be a good idea to settle on a graphics metalanguage rather than translating tcl code to qt or whatever?
that's exactly my point: creating a FUDI-style communication from pd->gui, which can easily be parsed by any GUI-client you wish to use.
This makes sense.
something like:
obj <id> <x> <y> <name> <args>
which will correctly render an object (whether it has rounded corners or shadows)
Basicallu, isn't that already covered in the patch save format (maybe not the id explicitly..)? Lorenzo.
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.
I am working on a pd-clone intended to explore a lot of the topics in this thread. It's not fully baked yet but I'm particularly excited about the approach to namespacing and scope management, which works a lot like
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
[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
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
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
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Lorenzo Sutton lorenzofsutton@gmail.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Monday, January 21, 2013 7:24 AM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
[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.
How does scope work for abstractions?
-Jonathan
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
From: Bill Gribble grib@billgribble.com 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.
How does scope work for abstractions?
Well, every object in a patch has a name. To find that object, the tree of patches and scopes is crawled upward from the site of the lookup. For example, the (equivalent of) [s "foo"] first looks in the scope of the [s], then the patch-global scope of the containing patch, then in the application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"] would try to find an object named "foo", then find "bar" in its patch-global scope (or an object named "bar" within a scope named "foo" in the current patch).
Does that make sense?
Thanks, Bill Gribble
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 7:55 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
From: Bill Gribble grib@billgribble.com 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.
How does scope work for abstractions?
Well, every object in a patch has a name. To find that object, the tree of patches and scopes is crawled upward from the site of the lookup. For example, the (equivalent of) [s "foo"] first looks in the scope of the [s], then the patch-global scope of the containing patch, then in the application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"] would try to find an object named "foo", then find "bar" in its patch-global scope (or an object named "bar" within a scope named "foo" in the current patch).
Does that make sense?
I don't think I understand it.
Let's say I have abstraction [blah]. I want [s foo] and [r foo] inside [blah] and all of [blah]'s children to talk to each other. Then I want to share my abstraction with Bob who needn't worry about the send/receive names I used inside [blah] because they are guaranteed not to conflict with anything he does outside the scope of the [blah] abstraction (e.g., creating a [s foo] on the same canvas where a [blah] object sits).
Can I specify the scope of the s/r symbol in this way?
Jonathan
Thanks, Bill Gribble
Here's how I've managed to send and receive from a parent(multi instance) abstraction to multiple instances of nested sub abstractions.
within main abstraction [mainAb] some data named $0var send it like this [s $0var]
initialize sub abstractions pass names X_1 and X_2 in so you can send and receive data to these abstractions individually [abX X_1 $0] [abX X_2 $0]
within sub abstraction abX initialized with X_1 $1 = X_1 $2 = mainAb's $0
for all instances of abX to receive from main's [s $0var] [r $2var]
to to send and receive locally and have mainAb access within abX [s $2$1varZ] within mainAb [r $0X_1varZ] and [r $0X_2varZ]
a way to get global data to sub abstractions of abX within abX initialize [abY $2var] within abY $1var = mainAb $0var
This information is useful say if you have multiple voices and want to have them share the same control
so say $0var is a send on a filter frequency slider when you move the slider all instances of abX receive the new filter frequency
when you want information to or from a specific instance of abX say like you want to plot each of the voices outputs on a scope use [s~ $2$1varZ] in abX then in main [r~ $0X_1varZ] and [r $0X_2varZ] then you can write those to a table so you can see which voice is sounding On Fri, Jan 25, 2013 at 9:27 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 7:55 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
From: Bill Gribble grib@billgribble.com 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.
How does scope work for abstractions?
Well, every object in a patch has a name. To find that object, the tree of patches and scopes is crawled upward from the site of the lookup. For example, the (equivalent of) [s "foo"] first looks in the scope of the [s], then the patch-global scope of the containing patch, then in the application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"] would try to find an object named "foo", then find "bar" in its patch-global scope (or an object named "bar" within a scope named "foo" in the current patch).
Does that make sense?
I don't think I understand it.
Let's say I have abstraction [blah]. I want [s foo] and [r foo] inside [blah] and all of [blah]'s children to talk to each other. Then I want to share my abstraction with Bob who needn't worry about the send/receive names I used inside [blah] because they are guaranteed not to conflict with anything he does outside the scope of the [blah] abstraction (e.g., creating a [s foo] on the same canvas where a [blah] object sits).
Can I specify the scope of the s/r symbol in this way?
Jonathan
Thanks, Bill Gribble
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Billy Stiltner billy.stiltner@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Bill Gribble grib@billgribble.com; "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 9:43 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
Here's how I've managed to send and receive from a parent(multi instance) abstraction to multiple instances of nested sub abstractions.
I'm talking about doing it without the constraint of having to prepare the child abstractions beforehand with an argument that contains a dollarsign variable. Passing unique identifiers around to simulate scope is really painful. In fact I was going to write some trivial tcl example code here to show how clunky the $0 approach would be, but I can't even imagine what it would look like.
-Jonathan
within main abstraction [mainAb] some data named $0var send it like this [s $0var]
initialize sub abstractions pass names X_1 and X_2 in so you can send and receive data to these abstractions individually [abX X_1 $0] [abX X_2 $0]
within sub abstraction abX initialized with X_1 $1 = X_1 $2 = mainAb's $0
for all instances of abX to receive from main's [s $0var] [r $2var]
to to send and receive locally and have mainAb access within abX [s $2$1varZ] within mainAb [r $0X_1varZ] and [r $0X_2varZ]
a way to get global data to sub abstractions of abX within abX initialize [abY $2var] within abY $1var = mainAb $0var
This information is useful say if you have multiple voices and want to have them share the same control
so say $0var is a send on a filter frequency slider when you move the slider all instances of abX receive the new filter frequency
when you want information to or from a specific instance of abX say like you want to plot each of the voices outputs on a scope use [s~ $2$1varZ] in abX then in main [r~ $0X_1varZ] and [r $0X_2varZ] then you can write those to a table so you can see which voice is sounding On Fri, Jan 25, 2013 at 9:27 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com;
"pd-list@iem.at" pd-list@iem.at
Sent: Friday, January 25, 2013 7:55 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
> From: Bill Gribble grib@billgribble.com > 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.
How does scope work for abstractions?
Well, every object in a patch has a name. To find that object, the
tree
of patches and scopes is crawled upward from the site of the lookup.
For
example, the (equivalent of) [s "foo"] first looks in the
scope of the
[s], then the patch-global scope of the containing patch, then in the application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"] would try to
find an
object named "foo", then find "bar" in its
patch-global
scope (or an object named "bar" within a scope named "foo" in
the current
patch).
Does that make sense?
I don't think I understand it.
Let's say I have abstraction [blah]. I want [s foo] and [r foo] inside
[blah] and
all of [blah]'s children to talk to each other. Then I want to share
my abstraction
with Bob who needn't worry about the send/receive names I used inside
[blah]
because they are guaranteed not to conflict with anything he does outside
the
scope of the [blah] abstraction (e.g., creating a [s foo] on the same
canvas where
a [blah] object sits).
Can I specify the scope of the s/r symbol in this way?
Jonathan
Thanks, Bill Gribble
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
The case you describe is the easy one, once you introduce any kind of lexical hygiene. Names in use in a patch bind closely to the patch or scope in which they are used, so there's no danger of escapes from a patch just because its being used within another patch.
At the same time, references to names that can't be resolved in the local scope do bubble up, so you can have more global names if you need them.
Thanks, Bill Gribble
On Jan 25, 2013, at 21:27, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 7:55 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
From: Bill Gribble grib@billgribble.com 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.
How does scope work for abstractions?
Well, every object in a patch has a name. To find that object, the tree of patches and scopes is crawled upward from the site of the lookup. For example, the (equivalent of) [s "foo"] first looks in the scope of the [s], then the patch-global scope of the containing patch, then in the application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"] would try to find an object named "foo", then find "bar" in its patch-global scope (or an object named "bar" within a scope named "foo" in the current patch).
Does that make sense?
I don't think I understand it.
Let's say I have abstraction [blah]. I want [s foo] and [r foo] inside [blah] and all of [blah]'s children to talk to each other. Then I want to share my abstraction with Bob who needn't worry about the send/receive names I used inside [blah] because they are guaranteed not to conflict with anything he does outside the scope of the [blah] abstraction (e.g., creating a [s foo] on the same canvas where a [blah] object sits).
Can I specify the scope of the s/r symbol in this way?
Jonathan
Thanks, Bill Gribble
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 10:05 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
T he case you describe is the easy one, once you introduce any kind of lexical hygiene. Names in use in a patch bind closely to the patch or scope in which they are used, so there's no danger of escapes from a patch just because its being used within another patch.
So inside [blah] let's say I have this:
[r foo] | [print I_don_t_want_bob_to_trigger_this]
I share my [blah] abstraction with Bob, who creates a [blah] instance in the same patch where he has
[Click here to start my thing( | [s foo]
I suppose I don't know what "lexical hygiene" means. But I think you have to have a way to explicitly state that "binding symbol foo applies to >this< canvas and all of its children, but not to any parents". Do you have a way to do that without using the $0 kludge?
There are also use cases for "binding symbol foo applies to all instances of
this< abstraction", and possibly "all instances of abstractions from >this<
libdir" (though the latter may be overkill).
-Jonathan
At the same time, references to names that can't be resolved in the local scope do bubble up, so you can have more global names if you need them.
Thanks, Bill Gribble
On Jan 25, 2013, at 21:27, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com;
"pd-list@iem.at" pd-list@iem.at
Sent: Friday, January 25, 2013 7:55 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
From: Bill Gribble grib@billgribble.com 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.
How does scope work for abstractions?
Well, every object in a patch has a name. To find that object, the
tree
of patches and scopes is crawled upward from the site of the lookup.
For
example, the (equivalent of) [s "foo"] first looks in the
scope of the
[s], then the patch-global scope of the containing patch, then in the application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"] would try to
find an
object named "foo", then find "bar" in its
patch-global
scope (or an object named "bar" within a scope named "foo" in
the current
patch).
Does that make sense?
I don't think I understand it.
Let's say I have abstraction [blah]. I want [s foo] and [r foo] inside
[blah] and
all of [blah]'s children to talk to each other. Then I want to share
my abstraction
with Bob who needn't worry about the send/receive names I used inside
[blah]
because they are guaranteed not to conflict with anything he does outside
the
scope of the [blah] abstraction (e.g., creating a [s foo] on the same
canvas where
a [blah] object sits).
Can I specify the scope of the s/r symbol in this way?
Jonathan
Thanks, Bill Gribble
On Fri, 2013-01-25 at 19:30 -0800, Jonathan Wilkes wrote:
So inside [blah] let's say I have this:
[r foo] | [print I_don_t_want_bob_to_trigger_this]
I share my [blah] abstraction with Bob, who creates a [blah] instance in the same patch where he has
[Click here to start my thing( | [s foo]
I suppose I don't know what "lexical hygiene" means. But I think you have to have a way to explicitly state that "binding symbol foo applies to >this< canvas and all of its children, but not to any parents". Do you have a way to do that without using the $0 kludge?
PD's behavior and the $0 kludge falls out of the design where there is a single namespace for s/r targets. It's a programming language where there are only global variables. This makes some things easy (communicating with other patches) and some things hard (keeping things private, duplicating code blocks without copies stomping on each other).
My design started from the presumption that all variables (names) are local to a scope. Each patch has its own "global" scope (which is the default for new names), and can have named scopes within it. This sort-of follows a model of "lexical scoping" that you see in languages like Lisp and Scheme where you can explicitly wrap a block of code in an environment where variables just local to that scope are declared. In MFP, a layer (subpatch) or group of layers can share a scope just among themselves, or can use the patch's global scope.
Again, this makes some things easy (cut and paste of subpatches without stepping on each other, management of names without $0-prefixes, knowing that your abstraction won't interfere with someone else's) and some things hard (broadcasting to every instance of a patch/abstraction, listening in on message traffic internal to somebody else's abstraction).
Back to your example: it wouldn't work as-is in MFP. The [s] would have to qualify the "foo" name, since it doesn't exist in the scope of the [s]. Let's say I make a [blah] in the patch with the [s] and I name it "blah_1". The [s foo] would need to be [s blah_1.foo] for it to get where you intend it to go. If you made 2 [blah] instances, "blah_1" and "blah_2", you would have to send to the one that you wanted the message to go to.
There are also use cases for "binding symbol foo applies to all instances of
this< abstraction", and possibly "all instances of abstractions from >this<
libdir" (though the latter may be overkill).
Yes, these are real use cases. I'm still trying to work out which ones are highest-value; you can't do either of these things in MFP right now.
Thanks, Bill Gribble
-Jonathan
At the same time, references to names that can't be resolved in the local scope do bubble up, so you can have more global names if you need them.
Thanks, Bill Gribble
On Jan 25, 2013, at 21:27, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com;
"pd-list@iem.at" pd-list@iem.at
Sent: Friday, January 25, 2013 7:55 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
From: Bill Gribble grib@billgribble.com 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.
How does scope work for abstractions?
Well, every object in a patch has a name. To find that object, the
tree
of patches and scopes is crawled upward from the site of the lookup.
For
example, the (equivalent of) [s "foo"] first looks in the
scope of the
[s], then the patch-global scope of the containing patch, then in the application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"] would try to
find an
object named "foo", then find "bar" in its
patch-global
scope (or an object named "bar" within a scope named "foo" in
the current
patch).
Does that make sense?
I don't think I understand it.
Let's say I have abstraction [blah]. I want [s foo] and [r foo] inside
[blah] and
all of [blah]'s children to talk to each other. Then I want to share
my abstraction
with Bob who needn't worry about the send/receive names I used inside
[blah]
because they are guaranteed not to conflict with anything he does outside
the
scope of the [blah] abstraction (e.g., creating a [s foo] on the same
canvas where
a [blah] object sits).
Can I specify the scope of the s/r symbol in this way?
Jonathan
Thanks, Bill Gribble
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Saturday, January 26, 2013 11:01 AM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
On Fri, 2013-01-25 at 19:30 -0800, Jonathan Wilkes wrote:
So inside [blah] let's say I have this:
[r foo] | [print I_don_t_want_bob_to_trigger_this]
I share my [blah] abstraction with Bob, who creates a [blah] instance in
the same
patch where he has
[Click here to start my thing( | [s foo]
I suppose I don't know what "lexical hygiene" means. But I
think you have to have
a way to explicitly state that "binding symbol foo applies to this< canvas and all of its children, but not to any parents". Do you have a way to do
that without using
the $0 kludge?
PD's behavior and the $0 kludge falls out of the design where there is a single namespace for s/r targets. It's a programming language where there are only global variables. This makes some things easy (communicating with other patches) and some things hard (keeping things private, duplicating code blocks without copies stomping on each other).
The best solution I've seen is Tim Blechmann's use of [declare] in Nova (though one could use a different class rather than overloading a current one):
http://tim.klingt.org/publications/tim_blechmann_nova.pdf
I can't remember what his default behavior was when the binding-symbol isn't [declare]'d, but if it defaulted to global in that case then the system would be backwards compatible with Pd. It's also trivial to learn, as the declaration is basically a stamp on a canvas that says "this name doesn't communicate with my parents, but it can communicate with all my children-- unless of course they declare the name for themselves." He also has a mechanism to explicitly declare something global.
The benefit is that when a name is declared on a canvas, the meaning is trivial to understand: IF stamped THEN local to me and my unstamped children. The drawback is that on a canvas that doesn't have a declaration on it, the user doesn't immediately know how far up the tree the scope goes simply by looking at the patch (though a mechanism could easily be added to reveal that).
Your system has the benefit of sane defaults-- if I understand correctly, names in your system will default to the behavior one currently gets in Pd by prepending a $0 to the name. That probably covers most of the common patching cases. The drawback is that for uncommon cases your namespace notation is non-trivial to learn, even though it makes the scope of uncommon cases explicit.
(To get a sense of how difficult it is for a user to _truly_ grasp scope levels using the "." separator, look at the history of scams based on shuffling the levels of domain names, changing the tld, and even putting the company name as a subdirectory of some nondescript domain name like acctmngr.com/microsoft.)
Anyway, I suppose that's enough commentary until I can actually play around with your system and see how it works. (The png showing the IDE-style interface looks nice, though.)
My design started from the presumption that all variables (names) are local to a scope. Each patch has its own "global" scope (which is the default for new names), and can have named scopes within it. This sort-of follows a model of "lexical scoping" that you see in languages like Lisp and Scheme where you can explicitly wrap a block of code in an environment where variables just local to that scope are declared. In MFP, a layer (subpatch) or group of layers can share a scope just among themselves, or can use the patch's global scope.
Again, this makes some things easy (cut and paste of subpatches without stepping on each other, management of names without $0-prefixes, knowing that your abstraction won't interfere with someone else's) and some things hard (broadcasting to every instance of a patch/abstraction, listening in on message traffic internal to somebody else's abstraction).
Back to your example: it wouldn't work as-is in MFP. The [s] would have to qualify the "foo" name, since it doesn't exist in the scope of the [s]. Let's say I make a [blah] in the patch with the [s] and I name it "blah_1". The [s foo] would need to be [s blah_1.foo] for it to get where you intend it to go. If you made 2 [blah] instances, "blah_1" and "blah_2", you would have to send to the one that you wanted the message to go to.
There are also use cases for "binding symbol foo applies to all
instances of
this< abstraction", and possibly "all instances of
abstractions from >this<
libdir" (though the latter may be overkill).
Yes, these are real use cases. I'm still trying to work out which ones are highest-value; you can't do either of these things in MFP right now.
The libdir scope isn't so important unless it is accompanied by another feature, which is a libdir setup file that is analogous to classname_setup in a c external, except that it's a Pd patch instead of a c file.
There are a few ways it could be implemented, but basically it should be possible for a libdir author to make a "setup" patch that gets loaded (in a way similar to the pd-_float template for arrays) whenever the libdir is loaded. One way to do this would be to load libdirname-meta.pd when libdirname is loaded. (Right now in Pd-ext libdirname-meta.pd just has comments describing the libdir itself.) That way the author could put stuff that is commonly used by all the libdir abstractions in libdirname-meta.pd (like a shared [table], for example), and it will be loaded and available to access. But of course for it to work there must be a libdir scope so that messages can pass back and forth between the setup patch and the libdir abstractions with impunity.
-Jonathan
Thanks, Bill Gribble
-Jonathan
At the same time, references to names that can't be resolved in
the local
scope do bubble up, so you can have more global names if you need
them.
Thanks, Bill Gribble
On Jan 25, 2013, at 21:27, Jonathan Wilkes jancsika@yahoo.com
wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com;
"pd-list@iem.at" pd-list@iem.at
Sent: Friday, January 25, 2013 7:55 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra
Live 1.5
released
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote:
> From: Bill Gribble grib@billgribble.com > 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.
How does scope work for abstractions?
Well, every object in a patch has a name. To find that
object, the
tree
of patches and scopes is crawled upward from the site of the
lookup.
For
example, the (equivalent of) [s "foo"] first looks
in the
scope of the
[s], then the patch-global scope of the containing patch,
then in the
application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"]
would try to
find an
object named "foo", then find "bar" in
its
patch-global
scope (or an object named "bar" within a scope named
"foo" in
the current
patch).
Does that make sense?
I don't think I understand it.
Let's say I have abstraction [blah]. I want [s foo] and [r
foo] inside
[blah] and
all of [blah]'s children to talk to each other. Then I want
to share
my abstraction
with Bob who needn't worry about the send/receive names I
used inside
[blah]
because they are guaranteed not to conflict with anything he does
outside
the
scope of the [blah] abstraction (e.g., creating a [s foo] on the
same
canvas where
a [blah] object sits).
Can I specify the scope of the s/r symbol in this way?
Jonathan
Thanks, Bill Gribble
[This is getting pretty OT for pd-list, let's take further discussion to private email or linux-audio-dev]
Thanks for the Nova link, that thesis looks very interesting. I hadn't heard of Nova before. Is it still active? Looks like at least parts of it merged into SuperCollider but I can't see that the main project is still going.
I am definitely still designing as I iterate... get a bit of functionality working, try to use it to do something different than it could do before, see what irritates me, repeat. Both you and HC have made good points that make me think I still have some work to do on scoping and on layers/subpatches/abstractions.
Your comments about dotted namespaces stump me a bit. I see what you mean about DNS address resolution, but very many programming languages share a common notation and meaning for dotted access to objects/subobjects. I'm trying to make things look as much like "visual python" as I can, so I would tend to use a similar syntax, but then again accessing scopes is not exactly like accessing object attributes. I will have to chew on it a while.
Thanks, Bill Gribble
On Sat, 2013-01-26 at 15:55 -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Saturday, January 26, 2013 11:01 AM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
On Fri, 2013-01-25 at 19:30 -0800, Jonathan Wilkes wrote:
So inside [blah] let's say I have this:
[r foo] | [print I_don_t_want_bob_to_trigger_this]
I share my [blah] abstraction with Bob, who creates a [blah] instance in
the same
patch where he has
[Click here to start my thing( | [s foo]
I suppose I don't know what "lexical hygiene" means. But I
think you have to have
a way to explicitly state that "binding symbol foo applies to this< canvas and all of its children, but not to any parents". Do you have a way to do
that without using
the $0 kludge?
PD's behavior and the $0 kludge falls out of the design where there is a single namespace for s/r targets. It's a programming language where there are only global variables. This makes some things easy (communicating with other patches) and some things hard (keeping things private, duplicating code blocks without copies stomping on each other).
The best solution I've seen is Tim Blechmann's use of [declare] in Nova (though one could use a different class rather than overloading a current one):
http://tim.klingt.org/publications/tim_blechmann_nova.pdf
I can't remember what his default behavior was when the binding-symbol isn't [declare]'d, but if it defaulted to global in that case then the system would be backwards compatible with Pd. It's also trivial to learn, as the declaration is basically a stamp on a canvas that says "this name doesn't communicate with my parents, but it can communicate with all my children-- unless of course they declare the name for themselves." He also has a mechanism to explicitly declare something global.
The benefit is that when a name is declared on a canvas, the meaning is trivial to understand: IF stamped THEN local to me and my unstamped children. The drawback is that on a canvas that doesn't have a declaration on it, the user doesn't immediately know how far up the tree the scope goes simply by looking at the patch (though a mechanism could easily be added to reveal that).
Your system has the benefit of sane defaults-- if I understand correctly, names in your system will default to the behavior one currently gets in Pd by prepending a $0 to the name. That probably covers most of the common patching cases. The drawback is that for uncommon cases your namespace notation is non-trivial to learn, even though it makes the scope of uncommon cases explicit.
(To get a sense of how difficult it is for a user to _truly_ grasp scope levels using the "." separator, look at the history of scams based on shuffling the levels of domain names, changing the tld, and even putting the company name as a subdirectory of some nondescript domain name like acctmngr.com/microsoft.)
Anyway, I suppose that's enough commentary until I can actually play around with your system and see how it works. (The png showing the IDE-style interface looks nice, though.)
My design started from the presumption that all variables (names) are local to a scope. Each patch has its own "global" scope (which is the default for new names), and can have named scopes within it. This sort-of follows a model of "lexical scoping" that you see in languages like Lisp and Scheme where you can explicitly wrap a block of code in an environment where variables just local to that scope are declared. In MFP, a layer (subpatch) or group of layers can share a scope just among themselves, or can use the patch's global scope.
Again, this makes some things easy (cut and paste of subpatches without stepping on each other, management of names without $0-prefixes, knowing that your abstraction won't interfere with someone else's) and some things hard (broadcasting to every instance of a patch/abstraction, listening in on message traffic internal to somebody else's abstraction).
Back to your example: it wouldn't work as-is in MFP. The [s] would have to qualify the "foo" name, since it doesn't exist in the scope of the [s]. Let's say I make a [blah] in the patch with the [s] and I name it "blah_1". The [s foo] would need to be [s blah_1.foo] for it to get where you intend it to go. If you made 2 [blah] instances, "blah_1" and "blah_2", you would have to send to the one that you wanted the message to go to.
There are also use cases for "binding symbol foo applies to all
instances of
this< abstraction", and possibly "all instances of
abstractions from >this<
libdir" (though the latter may be overkill).
Yes, these are real use cases. I'm still trying to work out which ones are highest-value; you can't do either of these things in MFP right now.
The libdir scope isn't so important unless it is accompanied by another feature, which is a libdir setup file that is analogous to classname_setup in a c external, except that it's a Pd patch instead of a c file.
There are a few ways it could be implemented, but basically it should be possible for a libdir author to make a "setup" patch that gets loaded (in a way similar to the pd-_float template for arrays) whenever the libdir is loaded. One way to do this would be to load libdirname-meta.pd when libdirname is loaded. (Right now in Pd-ext libdirname-meta.pd just has comments describing the libdir itself.) That way the author could put stuff that is commonly used by all the libdir abstractions in libdirname-meta.pd (like a shared [table], for example), and it will be loaded and available to access. But of course for it to work there must be a libdir scope so that messages can pass back and forth between the setup patch and the libdir abstractions with impunity.
-Jonathan
Thanks, Bill Gribble
-Jonathan
At the same time, references to names that can't be resolved in
the local
scope do bubble up, so you can have more global names if you need
them.
Thanks, Bill Gribble
On Jan 25, 2013, at 21:27, Jonathan Wilkes jancsika@yahoo.com
wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com;
"pd-list@iem.at" pd-list@iem.at
Sent: Friday, January 25, 2013 7:55 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra
Live 1.5
released
On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote: >> From: Bill Gribble grib@billgribble.com >> 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.
> > How does scope work for abstractions?
Well, every object in a patch has a name. To find that
object, the
tree
of patches and scopes is crawled upward from the site of the
lookup.
For
example, the (equivalent of) [s "foo"] first looks
in the
scope of the
[s], then the patch-global scope of the containing patch,
then in the
application global scope for the name "foo".
Dotted notation can drill down, so [s "foo.bar"]
would try to
find an
object named "foo", then find "bar" in
its
patch-global
scope (or an object named "bar" within a scope named
"foo" in
the current
patch).
Does that make sense?
I don't think I understand it.
Let's say I have abstraction [blah]. I want [s foo] and [r
foo] inside
[blah] and
all of [blah]'s children to talk to each other. Then I want
to share
my abstraction
with Bob who needn't worry about the send/receive names I
used inside
[blah]
because they are guaranteed not to conflict with anything he does
outside
the
scope of the [blah] abstraction (e.g., creating a [s foo] on the
same
canvas where
a [blah] object sits).
Can I specify the scope of the s/r symbol in this way?
Jonathan
Thanks, Bill Gribble
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com; "pd-list@iem.at" pd-list@iem.at Sent: Sunday, January 27, 2013 10:09 AM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
[This is getting pretty OT for pd-list, let's take further discussion to private email or linux-audio-dev]
I think it belongs here because we're talking about scope within a Pd GUI. It is relevant to Pd.
Thanks for the Nova link, that thesis looks very interesting. I hadn't heard of Nova before. Is it still active? Looks like at least parts of it merged into SuperCollider but I can't see that the main project is still going.
It's not active any longer, but I like the way it describes scope handling.
I am definitely still designing as I iterate... get a bit of functionality working, try to use it to do something different than it could do before, see what irritates me, repeat. Both you and HC have made good points that make me think I still have some work to do on scoping and on layers/subpatches/abstractions.
Your comments about dotted namespaces stump me a bit. I see what you mean about DNS address resolution, but very many programming languages share a common notation and meaning for dotted access to objects/subobjects.
The beginners' primers for those languages usually start out with a proposition like, "Ok, we know this stuff looks cryptic, but if you stick with it a world of possibilities will open up that would otherwise be difficult or tedious to implement without this syntax." In Pd the barriers are different-- they have to do with right-to-left ordering, hot vs cold inlets, abstractions, depth first message-passing, and selector interpretation (i.e., lists with one arg often get interpreted as a float or symbol), not to mention DSP fun. If while learning Pd the user is confronted with dot notation in the context of scope or namespacing, they have to learn that concept but now without the benefit of it opening up higher-level possibilities because the rest of the language isn't built around that syntax nor the techniques it represents. So it just becomes another barrier.
It's tricky because in a way [declare] and friends fit awkwardly into the dataflow paradigm-- they sit alone outside the active chains of objects. I imagine this is why Max just sidesteps the issue by having [pv] to store variables local to a canvas. Similarly, Ivica uses [phub foo] for presets in Pd-l2ork in a similar way to how Nova uses [declare]-- it sets the binding symbol for that canvas and its children (including abstractions). Still, that leaves out nonlocal signal sends, abstraction locality, data structure locality, and a lot else that would benefit from a more systematic approach. But do keep in mind that Max works alright in a lot of cases for a lot of users, so whatever the approach is it should stay out of the way 75% of the time and be approachable/accessible the other 25%.
I'm trying to make things look as much like "visual python" as I can, so I would tend to use a similar syntax, but then again accessing scopes is not exactly like accessing object attributes.
The dot notation can be a lot of things. Member data is usually an ancillary inlet. Methods are selectors of incoming messages. Scope is up for grabs. GUI attributes are, too.
I think if [import] could load libraries per patch instead of globally, and if abstractions could somehow override externals when they precede them in the search path, namespaces would work properly.
-Jonathan
I will have to chew on it a while.
Thanks, Bill Gribble
On Sat, 2013-01-26 at 15:55 -0800, Jonathan Wilkes wrote:
----- Original Message -----
> From: Bill Gribble grib@billgribble.com > To: Jonathan Wilkes jancsika@yahoo.com > Cc: Lorenzo Sutton lorenzofsutton@gmail.com;
"pd-list@iem.at" pd-list@iem.at
> Sent: Saturday, January 26, 2013 11:01 AM > Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5
released
> > On Fri, 2013-01-25 at 19:30 -0800, Jonathan Wilkes wrote: >> So inside [blah] let's say I have this: >> >> [r foo] >> | >> [print I_don_t_want_bob_to_trigger_this] >> >> I share my [blah] abstraction with Bob, who creates a [blah]
instance in
> the same >> patch where he has >> >> [Click here to start my thing( >> | >> [s foo] >> >> I suppose I don't know what "lexical hygiene"
means. But I
> think you have to have >> a way to explicitly state that "binding symbol foo applies
to
>> this< canvas and all >> of its children, but not to any parents". Do you have a way
to do
> that without using >> the $0 kludge? > > PD's behavior and the $0 kludge falls out of the design where
there is a
> single namespace for s/r targets. It's a programming language
where
> there are only global variables. This makes some things easy > (communicating with other patches) and some things hard (keeping
things
> private, duplicating code blocks without copies stomping on each > other).
The best solution I've seen is Tim Blechmann's use of [declare] in Nova (though one could use a different class rather than overloading a current one):
http://tim.klingt.org/publications/tim_blechmann_nova.pdf
I can't remember what his default behavior was when the binding-symbol isn't [declare]'d, but if it defaulted to global in that case then
the
system would be backwards compatible with Pd. It's also trivial to
learn,
as the declaration is basically a stamp on a canvas that says "this
name
doesn't communicate with my parents, but it can communicate with all my children-- unless of course they declare the name for themselves." He also has a mechanism to explicitly declare something global.
The benefit is that when a name is declared on a canvas, the meaning is trivial to understand: IF stamped THEN local to me and my unstamped
children.
The drawback is that on a canvas that doesn't have a declaration on it,
the
user doesn't immediately know how far up the tree the scope goes simply by looking at the patch (though a mechanism could easily be added to reveal that).
Your system has the benefit of sane defaults-- if I understand correctly,
names
in your system will default to the behavior one currently gets in Pd by
prepending
a $0 to the name. That probably covers most of the common patching cases. The drawback is that for uncommon cases your namespace notation is non-trivial to learn, even though it makes the scope of uncommon cases
explicit.
(To get a sense of how difficult it is for a user to _truly_ grasp scope
levels using the
"." separator, look at the history of scams based on shuffling
the levels of
domain names, changing the tld, and even putting the company name as a subdirectory of some nondescript domain name like
acctmngr.com/microsoft.)
Anyway, I suppose that's enough commentary until I can actually play
around
with your system and see how it works. (The png showing the IDE-style interface looks nice, though.)
> > My design started from the presumption that all variables (names) are > local to a scope. Each patch has its own "global" scope
(which is the
> default for new names), and can have named scopes within it. This > sort-of follows a model of "lexical scoping" that you see in
languages
> like Lisp and Scheme where you can explicitly wrap a block of code in
an
> environment where variables just local to that scope are declared. In > MFP, a layer (subpatch) or group of layers can share a scope just
among
> themselves, or can use the patch's global scope. > > Again, this makes some things easy (cut and paste of subpatches
without
> stepping on each other, management of names without $0-prefixes,
knowing
> that your abstraction won't interfere with someone else's) and
some
> things hard (broadcasting to every instance of a patch/abstraction, > listening in on message traffic internal to somebody else's > abstraction). > > Back to your example: it wouldn't work as-is in MFP. The [s]
would have
> to qualify the "foo" name, since it doesn't exist in the
scope of
> the > [s]. Let's say I make a [blah] in the patch with the [s] and I
name it
> "blah_1". The [s foo] would need to be [s blah_1.foo] for
it to get
> where you intend it to go. If you made 2 [blah] instances,
"blah_1"
> and > "blah_2", you would have to send to the one that you wanted
the
> message > to go to. > >> There are also use cases for "binding symbol foo applies to
all
> instances of >> >this< abstraction", and possibly "all instances
of
> abstractions from >this< >> libdir" (though the latter may be overkill). > > Yes, these are real use cases. I'm still trying to work out which
ones
> are highest-value; you can't do either of these things in MFP
right
> now.
The libdir scope isn't so important unless it is accompanied by another feature, which is a libdir setup file that is analogous to classname_setup in a c external, except that it's a Pd patch instead of a c file.
There are a few ways it could be implemented, but basically it should be possible for a libdir author to make a "setup" patch that gets
loaded (in a
way similar to the pd-_float template for arrays) whenever the libdir is
loaded.
One way to do this would be to load libdirname-meta.pd when libdirname is loaded. (Right now in Pd-ext libdirname-meta.pd just has comments
describing the
libdir itself.) That way the author could put stuff that is commonly used
by
all the libdir abstractions in libdirname-meta.pd (like a shared [table],
for example),
and it will be loaded and available to access. But of course for it to
work
there must be a libdir scope so that messages can pass back and forth between the setup patch and the libdir abstractions with impunity.
-Jonathan
> > Thanks, > Bill Gribble > >> >> >> -Jonathan >> >> > >> > At the same time, references to names that can't be
resolved in
> the local >> > scope do bubble up, so you can have more global names if you
need
> them. >> > >> > Thanks, >> > Bill Gribble >> > >> > On Jan 25, 2013, at 21:27, Jonathan Wilkes
> wrote: >> > >> >> >> >> >> >> >> >> >> >> ----- Original Message ----- >> >>> From: Bill Gribble grib@billgribble.com >> >>> To: Jonathan Wilkes jancsika@yahoo.com >> >>> Cc: Lorenzo Sutton
>> > "pd-list@iem.at" pd-list@iem.at >> >>> Sent: Friday, January 25, 2013 7:55 PM >> >>> Subject: Re: [PD] GUI toolkits and custom GUIs WAS:
Integra
> Live 1.5 >> > released >> >>> >> >>> On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes
wrote:
>> >>>>> From: Bill Gribble
>> >>>>> 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. >> >>>> >> >>>> How does scope work for abstractions? >> >>> >> >>> Well, every object in a patch has a name. To find
that
> object, the >> > tree >> >>> of patches and scopes is crawled upward from the
site of the
> lookup. >> > For >> >>> example, the (equivalent of) [s "foo"]
first looks
> in the >> > scope of the >> >>> [s], then the patch-global scope of the containing
patch,
> then in the >> >>> application global scope for the name
"foo".
>> >>> >> >>> Dotted notation can drill down, so [s
"foo.bar"]
> would try to >> > find an >> >>> object named "foo", then find
"bar" in
> its >> > patch-global >> >>> scope (or an >> >>> object named "bar" within a scope named > "foo" in >> > the current >> >>> patch). >> >>> >> >>> Does that make sense? >> >> >> >> I don't think I understand it. >> >> >> >> Let's say I have abstraction [blah]. I want [s
foo] and [r
> foo] inside >> > [blah] and >> >> all of [blah]'s children to talk to each other.
Then I want
> to share >> > my abstraction >> >> with Bob who needn't worry about the send/receive
names I
> used inside >> > [blah] >> >> because they are guaranteed not to conflict with
anything he does
> outside >> > the >> >> scope of the [blah] abstraction (e.g., creating a [s
foo] on the
> same >> > canvas where >> >> a [blah] object sits). >> >> >> >> Can I specify the scope of the s/r symbol in this way? >> >> >> >> Jonathan >> >> >> >>> >> >>> Thanks, >> >>> Bill Gribble >> >>> >> > >
On 01/27/2013 04:09 PM, Bill Gribble wrote:
[This is getting pretty OT for pd-list, let's take further discussion to private email or linux-audio-dev]
it's OT if you consider that the subject is "GUI toolkits". i don't think it is OT for a pd-related list, though maybe pd-dev is a slightly better place.
Thanks for the Nova link, that thesis looks very interesting. I hadn't heard of Nova before. Is it still active? Looks like at least parts of it merged into SuperCollider but I can't see that the main project is still going.
nova became supernova, and supernova is now an official alternative scsynth implementation for SC3 (it even comes with SC3, but afaik is not the default synth engine yet(?))
gfamdr IOhannes
----- Original Message -----
From: IOhannes zmölnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Sunday, January 27, 2013 3:15 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
On 01/27/2013 04:09 PM, Bill Gribble wrote:
[This is getting pretty OT for pd-list, let's take further discussion
to
private email or linux-audio-dev]
it's OT if you consider that the subject is "GUI toolkits".
Right.
i don't think it is OT for a pd-related list, though maybe pd-dev is a slightly better place.
Thanks for the Nova link, that thesis looks very interesting. I hadn't heard of Nova before. Is it still active? Looks like at least parts of it merged into SuperCollider but I can't see that the main project is still going.
nova became supernova, and supernova is now an official alternative scsynth implementation for SC3 (it even comes with SC3, but afaik is not the default synth engine yet(?))
gfamdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 27/01/13 21:15, IOhannes zmölnig wrote:
nova became supernova, and supernova is now an official alternative scsynth implementation for SC3 (it even comes with SC3, but afaik is not the default synth engine yet(?))
not yet, unless you have the following line in your startup file:
Server.program = "/usr/local/bin/supernova";
cheers, y
On 18 Jan 2013, at 19:26, Jonathan Wilkes jancsika@yahoo.com wrote:
But I do have a question about:
Specifically, the png accompanying "Turnkey Audio Processing"-- specifically the outputs of GranularDelay1 going to the inputs of StereoReverb1. Look quickly then answer the question: Does out1 connect to in1 or in2?
I'm not against bezier curves, but the GUI engine must handle them with care or they'll cause unnecessary problems.
Good catch! I've added an issue to our tracker to devise a means to clarify connection flow in the case of overlaps.
Jamie
----- Original Message -----
From: Jamie Bullock jamie@jamiebullock.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Leandro da Mota Damasceno lemota@gmail.com; Pierre-Olivier Boulant po.boulant@free.fr; pd-list pd-list@iem.at Sent: Friday, January 18, 2013 2:49 PM Subject: Re: [PD] [announce] Integra Live 1.5 released
On 18 Jan 2013, at 19:26, Jonathan Wilkes jancsika@yahoo.com wrote:
But I do have a question about:
Specifically, the png accompanying "Turnkey Audio Processing"--
specifically the outputs
of GranularDelay1 going to the inputs of StereoReverb1. Look quickly then
answer the
question: Does out1 connect to in1 or in2?
I'm not against bezier curves, but the GUI engine must handle them with
care or they'll cause
unnecessary problems.
Good catch! I've added an issue to our tracker to devise a means to clarify connection flow in the case of overlaps.
As well as keeping some amount of space between bezier cords that don't overlap-- otherwise they may still end up looking ambiguous and the user must work backwards from whatever means you use to clarify overlaps. I.e., "this looks like it may be an overlap; the rule I learned to distinguish overlaps is X; this isn't X; therefore this isn't an overlap" is more work than "this doesn't look like an overlap."
Probably a similar problem if you let cords go behind boxes.
-Jonathan
Jamie
Wow Jamie, This seems like something for which I've been waiting for ages. Amazing job! I have tested it with windows 7 Enterprose 64-bit and it works great.ֲ Can't wait to delve deeper into Integra...
I might be getting ahead of myself, but any prjections as to when one could start creating one's own modules?ֲ
Thanks for your work! Zax
-------------------------------f---------
From: jamie@jamiebullock.com Date: Fri, 18 Jan 2013 16:15:30 +0000 To: po.boulant@free.fr CC: pd-list@iem.at Subject: Re: [PD] [announce] Integra Live 1.5 released
On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant po.boulant@free.fr wrote:
Hi,
It looks very nice indeed.
Running the Windows version, I have a problem with the mouse. I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
Windows 7, 64bit OS.
I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that.
I hope you don't mind but I've added your report to the UserVoice forum:
http://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mo...
If you "vote" for the issue, you will get an automatic notification when it is resolved.
Jamie _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 19 Jan 2013, at 10:55, Eran Sachs eransachs@hotmail.com wrote:
Wow Jamie, This seems like something for which I've been waiting for ages. Amazing job! I have tested it with windows 7 Enterprose 64-bit and it works great. Can't wait to delve deeper into Integra...
I might be getting ahead of myself, but any prjections as to when one could start creating one's own modules?
Thanks for your work!
Thanks for the kind words!
I should point out that this was very much a team effort. Thanks should at least be given to the IEM team, who were responsible for a large portion of the module library. The full list of credits can be accessed via the application "About" window.
Regarding module development, we plan to release the developer SDK in the Spring.
I have now set up an Integra Live forum, so you might want to head there for announcements:
http://integralive.org/forum/
Best,
Jamie
Hey Jamie,
any chance to see a version for Gnu/Linux? it will be nice to help
mac/winwin users to move on to flossOS ;-)
Any help for the coding on nux, there is plenty people here that could
help us, include us at apo33.
cheers
Julien
Hi folks,
I am delighted to announce the latest release of Integra Live -- an
interactive audio application for musicians and music education
based on a Pure Data engine.Integra Live supports Mac OS X 10.6 or later and Windows XP or
later. It can be downloaded from the Integra Live website:http://www.integralive.org
Here's the walkthrough...
- Connect over 60 audio modules from delays to granular synths - Incorporate live interaction with the routing and scripting panels - Automate parameters using linear or logarithmic envelopes - Setup audio "scenes" with keyboard and MIDI triggers - Add parameter controls to the "live view" for performance - Share and reuse your work with our integrated file format
Coming soon...
- Write your own Integra Live modules in Pure Data using our
module developer SDK
For news...
Follow us on Twitter: @integralive
For bugs and feature requests...
Post on our forum: http://integralive.uservoice.com
Have a great year!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Hi Julien,
On 18 Jan 2013, at 17:20, APO33 info@apo33.org wrote:
Hey Jamie, any chance to see a version for Gnu/Linux? it will be nice to help mac/winwin users to move on to flossOS ;-)
Any help for the coding on nux, there is plenty people here that could help us, include us at apo33.
That's really good to hear. There used to be a Linux version before Adobe withdrew support for the AIR runtime. That's the main issue TBH, since the binary swf produced by Flex compilers on any platform are actually portable provided you have the runtime to load it.
This is all of course very annoying, since portability was one of the reasons we chose the AIR platform in the first place.
It seems like the idea of Apache Flex for Linux is mainly to target Flex in the browser, which probably wouldn't work for Integra Live due to sandboxing issues.
The upshot is that I think we will at some point end up porting our UI to something more robust.
best,
Jamie