Pd-list August 2019

pd-list@lists.iem.at

45 participants
54 discussions

[PD-announce] Ofelia v3.0.1 released.
by Zack Lee 28 Aug '19

28 Aug '19

Hi, Ofelia v3.0.1 is now available on Deken. Changes: - Added more examples (3d, drawing, math..) - Fixed type checking issue in "ofxOfeliaPdBindings.i" - Fixed bug when outputting a table with a string key using ofOutlet() - ofArray's array elements can be accessed using square brackets Thanks! Zack _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

1 0

Problem loading Ofelia
by Alexandros 27 Aug '19

27 Aug '19

I'm trying to load the Ofelia library but I get this error message: ofelia.pd_linux: libGLEW.so.2.0: cannot open shared object file: No such file or directory I did this in the terminal: dpkg -s libglew-dev dpkg -s libglew2.1 and both packages are installed in my system. I don't get a libglew2.0 with "apt-cache search libglew", but only a 2.1. I've run the install_dependencies.sh script and all dependencies are supposed to have been properly installed in my system. I'm on UbuntuStudio 19.04 with Pd-0.49.0

3 3

Re: [PD] [PD-dev] Why don't we implement zooming in Tcl?
by Christof Ressi 27 Aug '19

27 Aug '19

Hi, > Write or find a Tcl parser and bind all the tcl comands coming from Pd to > new functions written for whatever toolkit you like. This is what I would like to avoid my all means :-) The Tcl commands are, well, just too Tcl specific. > Make an abstraction layer between Pd and the TCL calls, and swap in compatible > calls to another toolkit. This has been proposed a few times but seems like > major surgery. I think this is the way to go! It would certainly require major surgery but I think it would pay off tremendously in the future, because people could easily do alternative GUIs without forking the core. But first someone has to come up with a proof of concept. Christof > Gesendet: Dienstag, 27. August 2019 um 03:43 Uhr > Von: "Miller Puckette" <msp(a)ucsd.edu> > An: "Christof Ressi" <christof.ressi(a)gmx.at> > Cc: pd-dev <pd-dev(a)lists.iem.at> > Betreff: Re: [PD-dev] Why don't we implement zooming in Tcl? > > Well, possiblities: > > Rip the GUI out and replace it (this is done in Purr Data) > > Write or find a Tcl parser and bind all the tcl comands coming from Pd to > new functions written for whatever toolkit you like. This was done once > by a very smart person and shown (I think) at the first Pure Data Convention > (Graz!) Perhas Iohannes will remember who this was or know how to find it. > Maybe it's even in the Pd convention book... > > Make an abstraction layer between Pd and the TCL calls, and swap in compatible > calls to another toolkit. This has been proposed a few times but seems like > major surgery. > > (previous suggestoin, lite version) - Hang onto Tcl/Tkfor dialogs and the > like, but redo the "pd window" calls using some other toolkit (less major > surgery, but then you're using two toolkits, ugh.) > > Do somtheing not int he above list (and that I haven't though of :) > > M > > > On Tue, Aug 27, 2019 at 02:38:17AM +0200, Christof Ressi wrote: > > > Maybe I'm missing something obvious? > > > > Of course I did... We send raw Tcl commands from the core with the actual canvas coordinates and this complicates things because of how Tk's "scale" method works... > > > > Maybe it's time to eventually refactor the GUI messaging and use abstract commands instead of actual Tcl code, with logical coordinates instead of actual coordinates... This would mean that zooming could be implemented easily on the GUI side. > > > > But what's more important: people can replace the Tk GUI with other (better) GUIs. I think the libpd people would love that as well, because apps could easily integrate Pd's GUI into their GUI framework of choice. Also, people can offer alternative GUIs for Pd vanilla. Personally, I can imagine writing a Qt GUI. This would be similar to how Supercollider has alternative language clients which all talk to the Server via well-defined OSC messages. > > > > <rant> > > > > I appreciate Pd's minimalism but a simple GUI should also be a *fast* GUI. The Tk canvas implementation is actually pretty terrible performance-wise. Moving an object in a larger patch maxes out a whole core(!) on my Laptop. It appears that Tk simply redraws the whole canvas :-( Any decent GUI framework should use some kind of spatial partitioning to determine which part of the canvas actually needs to be redrawn. Qt's QGraphicsScene does this pretty well (I've written a level editor where the view can easily contain 10 thousands of tiles and editing/zooming is smooth!). > > > > So I'm pretty frustated with Tk. A short-term solution could be to patch Tk's canvas code, but in the long run I think we need an abstract GUI interface, so that people can experiment with better GUI frameworks. > > > > </rant> > > > > Christof > > > > > Gesendet: Dienstag, 27. August 2019 um 00:30 Uhr > > > Von: "Christof Ressi" <christof.ressi(a)gmx.at> > > > An: pd-dev(a)iem.at > > > Betreff: [PD-dev] Why don't we implement zooming in Tcl? > > > > > > Hi, I've been wondering why the zooming is implemented on the Pd core? Tk's canvas has a scale method and people have been using to implement a zoom feature, e.g. https://www.tek-tips.com/viewthread.cfm?qid=239833 > > > > > > Ideally, the core shouldn't have to know about the size of the GUI window at all and just work with "logical" coordinates. The GUI can scale the content to whatever size it wants and when communicating with the core it would transform the mouse coordinates between logical and screen coordinates. Some better GUI frameworks already do that for you (e.g. Qt's QGraphicsScene/QGraphicView), but it shouldn't be too hard to do it manually for Tk. This would also allow fractional zoom factors. Unfortunately, Tk doesn't allow fractional font sizes (or has this changed?), but we could have at least *some* steps between 100% and 200%. Also, it would make the Pd core code much easier because we wouldn't have to worry about zoom at all... > > > > > > This is just I've been wondering about when having a look at the zooming code and coming from my experience of developing GUI apps with Qt. Maybe I'm missing something obvious? > > > > > > Christof > > > > > > > > > > > > > > > _______________________________________________ > > > Pd-dev mailing list > > > Pd-dev(a)lists.iem.at > > > https://lists.puredata.info/listinfo/pd-dev > > > > > > > > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev(a)lists.iem.at > > https://lists.puredata.info/listinfo/pd-dev >

2 2

Re: [PD] [PD-dev] Why don't we implement zooming in Tcl?
by Christof Ressi 27 Aug '19

27 Aug '19

> Maybe I'm missing something obvious? Of course I did... We send raw Tcl commands from the core with the actual canvas coordinates and this complicates things because of how Tk's "scale" method works... Maybe it's time to eventually refactor the GUI messaging and use abstract commands instead of actual Tcl code, with logical coordinates instead of actual coordinates... This would mean that zooming could be implemented easily on the GUI side. But what's more important: people can replace the Tk GUI with other (better) GUIs. I think the libpd people would love that as well, because apps could easily integrate Pd's GUI into their GUI framework of choice. Also, people can offer alternative GUIs for Pd vanilla. Personally, I can imagine writing a Qt GUI. This would be similar to how Supercollider has alternative language clients which all talk to the Server via well-defined OSC messages. <rant> I appreciate Pd's minimalism but a simple GUI should also be a *fast* GUI. The Tk canvas implementation is actually pretty terrible performance-wise. Moving an object in a larger patch maxes out a whole core(!) on my Laptop. It appears that Tk simply redraws the whole canvas :-( Any decent GUI framework should use some kind of spatial partitioning to determine which part of the canvas actually needs to be redrawn. Qt's QGraphicsScene does this pretty well (I've written a level editor where the view can easily contain 10 thousands of tiles and editing/zooming is smooth!). So I'm pretty frustated with Tk. A short-term solution could be to patch Tk's canvas code, but in the long run I think we need an abstract GUI interface, so that people can experiment with better GUI frameworks. </rant> Christof > Gesendet: Dienstag, 27. August 2019 um 00:30 Uhr > Von: "Christof Ressi" <christof.ressi(a)gmx.at> > An: pd-dev(a)iem.at > Betreff: [PD-dev] Why don't we implement zooming in Tcl? > > Hi, I've been wondering why the zooming is implemented on the Pd core? Tk's canvas has a scale method and people have been using to implement a zoom feature, e.g. https://www.tek-tips.com/viewthread.cfm?qid=239833 > > Ideally, the core shouldn't have to know about the size of the GUI window at all and just work with "logical" coordinates. The GUI can scale the content to whatever size it wants and when communicating with the core it would transform the mouse coordinates between logical and screen coordinates. Some better GUI frameworks already do that for you (e.g. Qt's QGraphicsScene/QGraphicView), but it shouldn't be too hard to do it manually for Tk. This would also allow fractional zoom factors. Unfortunately, Tk doesn't allow fractional font sizes (or has this changed?), but we could have at least *some* steps between 100% and 200%. Also, it would make the Pd core code much easier because we wouldn't have to worry about zoom at all... > > This is just I've been wondering about when having a look at the zooming code and coming from my experience of developing GUI apps with Qt. Maybe I'm missing something obvious? > > Christof > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev(a)lists.iem.at > https://lists.puredata.info/listinfo/pd-dev >

1 0

pix_delay argument
by Peter P. 26 Aug '19

26 Aug '19

Hi list, can it be that if pix_delay is being sent a "frame delay" into its right inlet that is the same as its argument (max delay) it will not delay at all? cheers, P

3 2

Re: [PD] Problem loading Ofelia
by Zack Lee 25 Aug '19

25 Aug '19

Hi Alexandros, I built Ofelia external on Ubuntu 18.04 LTS and it seems like the binary is incompatible in newer Ubuntu and some other distros. Maybe you could try something like the following script which I found from this post: https://forum.openframeworks.cc/t/building-executables-that-run-in-the-futu… $ sudo ln -s /usr/lib/libGLEW.so /usr/lib/libGLEW.so.2.0 If this doesn't work, I would suggest building the external yourself following the instruction from: https://github.com/cuinjune/ofxOfelia#build-requirements I will try to make Ofelia binary work across different versions and distros in the close future. If anyone has a good idea to do this, please let me know. Best Zack

3 2

Re: [PD] [PD-dev] keyboard navigation: #ifdefs
by Christof Ressi 24 Aug '19

24 Aug '19

hey, have you tried to compile this without HAVE_KEYBOARDNAV? The remaining line would be "canvas_connect(gl, nobj, 0, indx, kbdnav->kn_ioindex);" which doesn't look right. Just go for the most obvious solution: if (connectme) { #ifdef HAVE_KEYBOARDNAV ... #else canvas_connect(gl, indx, 0, nobj, 0); #endif } Yes, "..." will also have a call to "canvas_connect(gl, indx, 0, nobj, 0);", but that's not a problem. Actually, you don't even save a line because of the additional #ifdefs and the resulting code is much harder to read. Finally, "..." could simply delegate to a method defined in your source file, so your implementation doesn't clutter the original Pd sources. Christof Gesendet: Samstag, 24. August 2019 um 19:31 Uhr Von: "Henri Augusto Bisognini" <msndohenri(a)hotmail.com> An: "pd-dev(a)lists.iem.at" <pd-dev(a)lists.iem.at> Betreff: [PD-dev] keyboard navigation: #ifdefs Hey list! I've been trying to isolate the keyboard navigation as much as i could since you guys said it should be compiled optionally. While a lot of stuff could be moved to it's own file (g_kbdnav.c) there are also a lot of code that need to be in the middle of pd's core functions. For example, here is the modified canvas_obj() function on the g_text.c to not cinlude the code related to keyboard navigation: https://gist.github.com/HenriAugusto/e417c8f269ad10df2dc3359b907ea588 It's not as pretty as it could be but it's readable (if your editor has code folding you can just hide the relevant lines to see what the code looks like, for example). Is there a better way to do this? Cheers, Henri. ____________________________ Just in case, those are examples of some other modified core functions: in g_text.c glist_drawiofor(...) - draws a rectangle around the selected in/outlet canvas_howputnew(...) - position a new object exactly below/above to selected in/outlet in g_canvas.c canvas_drawlines(...) - draws lines in different colors while navigating through connections canvas_map(...) - draws each object's index if the user has asked so (useful for the goto functionality) ------------------------------------------------------------ De: Christof Ressi <christof.ressi(a)gmx.at> Enviado: terça-feira, 16 de julho de 2019 14:32 Para: Henri Augusto Bisognini <msndohenri(a)hotmail.com> Cc: pd-dev(a)lists.iem.at <pd-dev(a)lists.iem.at> Assunto: Aw: Re: [PD-dev] First complete keyboard navigation prototype Hi, > But it appears that actually the size of the struct is deduced while compiling. So if you write an external it is going to think the canvas struct is the same size as it was in the pd header files that were used during compilation. exactly. > When using the pointer to implementation idiom, wouldn't the pointer itself change the size of the struct? yes, it will > You've said something about that not being a problem when you add it as the last member of the struct but i don't understand why and how that would work. usually, externals shouldn't care about the *size* the t_editor struct (at least I can't think of any use case), so you can get away with adding new fields at the end (although it's certainly not recommended). Note that those headers aren't really public anyway! However, appending fields conditionally can lead to problems: struct Foo { int a; #ifdef FOO_EX int c; #endif }; Now let's say we need to add another member: struct Foo { int a; #ifdef FOO_EX int c; #endif in b; }; If the host compiles with FOO_EX defined and the client doesn't, the latter will assume a wrong offset for 'b'. The solution is to add a field for private data *once*. The advantage is that a) we can hide the private data and b) we can extend it without worrying about compatibility: struct Foo { int a; PrivateFoo *p; }; We can still add public members if needed: struct Foo { int a; void *private; int b; }; 'private' points to a private data structure that is not be visible to clients. There you can conditionally enable members without problems: struct PrivateFoo { #ifdef USE_BAR struct MyFeature feature; #endif }; MyFeature could be in a seperate source file together with your methods and it only gets compiled when needed. Again, have a look at the "t_canvas_private" struct and the "gl_privatedata" member of "_glist" (aka "t_canvas") and do the same for "_editor", e.g.: in g_canvas.h: typedef struct _editor { ... void *e_privatedata; } t_editor; in g_editor.c: #ifdef HAVE_KEYBOARDNAV #include "g_keyboardnav.h" #endif typedef struct _editor_private { #ifdef HAVE_KEYBOARDNAV t_keyboardnav keyboardnav; #endif } t_editor_private; the "t_keyboardnav" struct is defined in "g_keyboardnav.h" and its methods implemented in "g_keyboardnav.c". Both only get compiled when needed. Hope this makes sense. Christof_______________________________________________ Pd-dev mailing list Pd-dev(a)lists.iem.at https://lists.puredata.info/listinfo/pd-dev[https://lists.puredata.info/lis…

1 0

[Re] [PD-announce] ofelia v3.0.0 released!
by rolfm＠dds.nl 24 Aug '19

24 Aug '19

hi zack, i'm not a LUA user, but ofelia looks great. AND i started to use it, without LUA for now. 2 remarks: - the simpleColorQuad example crashes Pd (i'm on Windows 10, Pd-0.50-i386) - not all of-Pd objects are in the help: i wanted to change the background color and found by accident [ofBackground], without a corresponding help. thanks for all your work. rolf

1 0

Praise and question for the new [pdcontrol]
by Pierre Alexandre Tremblay 23 Aug '19

23 Aug '19

First the praise: amazing! I needed this so badly! Second, the question: I’m trying to launch the browser with file paths that have a relative element in them, in effect building them with the output of the message [dir 0 ../docs/my_sexy_object_documentation.html] But when I send the message [browse /fullfilepathtothefile/../docs/fluid.ampslice~.html] I get (Tcl) UNHANDLED ERROR: wrong # args: should be "::pd_menucommands::menu_openfile filename" while executing "::pd_menucommands::menu_openfile /ze_path..." ("uplevel" body line 7) invoked from within "uplevel #0 $docmds” Is that an expected behaviour? thanks pa

2 2

[PD-announce] Live Electronics Tutorial 1.0 beta 13 & ELSE 1.0 beta 23 are out!
by Alexandre Torres Porres 22 Aug '19

22 Aug '19

So, both of these need Pd 0.50, which came out just right now! First let me talk about the tutorial, because I wanna focus on the new examples I created that make use of the new [slop~] object from Pd 0.50! I have examples on how to use it as a slew limiter and how to use it as a one pole filter for non linear glides/portamento. I also have an example on how to build a pure vanilla non linear ADSR envelope. Just search for 'slop~' and you may find these files... check it at: https://github.com/porres/Live-Electronic-Music-Tutorial The ELSE library has also been updated. It has many important fixes, some breaking changes and 6 new objects. This also needs Pd 0.50, as this new release fixes some issues that affected objects in ELSE. Get it and check the changelog at https://github.com/porres/pd-else/releases/tag/v1.0-beta23 Most of the binaries are already up in deken by the time this message hits the world wide web. Cheers _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list August 2019