Pd-dev June 2017

pd-dev@lists.iem.at

13 participants
18 discussions

Re: [PD-dev] Conflict: incoming OSC data and DSP on
by Roman Haefeli 21 Jun '17

21 Jun '17

Just a wild guess: It looks like your localhost connection is slow for some reason. Is there some anti virus software installed? If so, does the problem still occur when anti virus is stopped? Roman On Mit, 2017-04-12 at 16:02 +0100, Niccolò Granieri wrote: > > > > Does the attached modified version of your test patch still exhibit > > the > > problem? > > Yes, same exact problem. > > > > > On 12 Apr 2017, at 16:01, Roman Haefeli <reduzent(a)gmail.com> wrote: > > > > Does the attached modified version of your test patch still exhibit > > the > > problem? > > > > Roman > > > > On Mit, 2017-04-12 at 13:02 +0100, Niccolò Granieri wrote: > > > > > > > > > > > I cannot with the same Pd version on Linux. I wonder whether it > > > > is > > > > related to the high refresh rate of the number boxes. > > > > > > > > Does the GUI freeze still occur if the the update rate of the > > > > number > > > > boxes (not that of actual data going through the wire!) is > > > > throttled? > > > Hi Roman, I'm not quite sure how I would throttle the number > > > boxes, > > > can you be more specific? > > > > > > > > > > > Is wish more likely the bottleneck on some platforms, but not > > > > on > > > > others? Is wish using 100% of a CPU core when the freeze > > > > happens? > > > Actually Pd drops in CPU usage after the freeze happens. From 40% > > > to > > > 0,8%. But the GUI is completetly frozen and the audio has up to a > > > 5second delay! > > > > > > _______________________________________________ > > > Pd-dev mailing list > > > Pd-dev(a)lists.iem.at > > > https://lists.puredata.info/listinfo/pd-dev > > > > > > > > > > > > > > On 12 Apr 2017, at 12:55, Roman Haefeli <reduzent(a)gmail.com> > > > > wrote: > > > > > > > > > > > > > > > > On Die, 2017-04-11 at 18:33 +0200, Damian Stewart wrote: > > > > > > > > > > Fwiw I can reproduce exactly the behaviour that Niccolò is > > > > > seeing > > > > > here. OSX 10.12.3, pd vanilla 0.47.1 64 bit. > > > > I cannot with the same Pd version on Linux. I wonder whether it > > > > is > > > > related to the high refresh rate of the number boxes. > > > > > > > > Does the GUI freeze still occur if the the update rate of the > > > > number > > > > boxes (not that of actual data going through the wire!) is > > > > throttled? > > > > > > > > Is wish more likely the bottleneck on some platforms, but not > > > > on > > > > others? Is wish using 100% of a CPU core when the freeze > > > > happens? > > > > > > > > (Sorry if I'm repeating what IOhannes already said) > > > > > > > > Roman > > > > > > > > > > > > p.s.: Why is this on pd-dev? > > > > > > > > > > > > > > > > > > > > > > > > > On 11 Apr 2017, at 00:56, Niccolò Granieri > > > > > > <granieriniccolo(a)gmail.com> wrote: > > > > > > > > > > > > Hello Pd-dev mailing list, > > > > > > > > > > > > I am writing, for the first time, to point out an issue I'm > > > > > > having > > > > > > with incoming OSC data in Pd and DSP being turned on. > > > > > > > > > > > > The problem occurs when, while receiving OSC data from > > > > > > inside > > > > > > my > > > > > > machine (thus using a localhost), I turn on DSP. The OSC > > > > > > data > > > > > > stops > > > > > > flowing until I don't turn the DSP off. > > > > > > > > > > > > The only workaround I found to solve this issue is to run > > > > > > two > > > > > > separate instances of Pd: the first one that will act as an > > > > > > OSC > > > > > > parser, not having the need to turn on DSP. Once the data > > > > > > is > > > > > > parsed, the data is sent to a second instance of Pd via > > > > > > FUDI > > > > > > protocol (netsend) where it can coexist with DSP on without > > > > > > causing > > > > > > any issues. > > > > > > > > > > > > This unfortunately brings up the amount of computing power > > > > > > needed. > > > > > > > > > > > > I was wondering if anyone encountered the same problem > > > > > > before, > > > > > > and > > > > > > if there was any better solution. > > > > > > > > > > > > Thanks in advance, glad to be in this mailing list, > > > > > > > > > > > > Niccolò > > > > > > > > > > > > Pure Data 0.47.1 - 64 bit > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > _______________________________________________ > > > > Pd-dev mailing list > > > > Pd-dev(a)lists.iem.at > > > > https://lists.puredata.info/listinfo/pd-dev > > <Test_Patch_Automated_throttled.pd>

4 12

change in how declares are interpreted from within abstractions
by Miller Puckette 19 Jun '17

19 Jun '17

To Pd dev: I just pushed a change that I believe to be a bug fix - now, [declare -path foo] inside an abstraction looks for a subdirectory "foo" relative to the directory that the abstraction was found in, not the calling patch. I think this doesn't break anything but since search paths are so confusing I thought it a good idea to mention the change here in case anyone sees something wrong with it. cheers Miller

2 1

Re: [PD-dev] change in how declares are interpreted from within abstractions
by Dan Wilcox 18 Jun '17

18 Jun '17

I can definitely say this will be helpful for my abstraction libraries. > To Pd dev: > > I just pushed a change that I believe to be a bug fix - now, [declare -path foo] > inside an abstraction looks for a subdirectory "foo" relative to the directory > that the abstraction was found in, not the calling patch. I think this doesn't > break anything but since search paths are so confusing I thought it a good idea > to mention the change here in case anyone sees something wrong with it. > > cheers > Miller -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

[pure-data:bugs] #1299 Typo in Help
by nwheels 14 Jun '17

14 Jun '17

--- ** [bugs:#1299] Typo in Help** **Status:** open **Group:** v0.47 **Created:** Wed Jun 14, 2017 04:55 PM UTC by nwheels **Last Updated:** Wed Jun 14, 2017 04:55 PM UTC **Owner:** nobody **Attachments:** - [funcitons.PNG](https://sourceforge.net/p/pure-data/bugs/1299/attachment/fun… (11.3 kB; image/png) Hello, first time here so in case please excuse me. There is a typo in the Help. Steps to "reproduce": create a new "plus" object [+], right click on it > Help, you land in the "binary arithmetic operators" help page (Pd/doc/5.reference). Current text: "The arithmetic binary operators perform the 4 arithmetic funcitons" Typo: "funcitons" instead of "functions". Thanks Enrico --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

Revamping the remote GUI feature
by Miller Puckette 04 Jun '17

04 Jun '17

Hi Giulio - This is an interesting idea and I'd like to try to incorporate it. I guess it's adequate fro teh GUI to have an additional menu item that would kill whatever instance it's connected to and connect to a new one (or perhaps start one - I guess this should be a dialog window). Meanwhile, yes, the open/save-as dialogs are a problem when Pd and the GUI are on different machines! I'm curious whether it would be possible (or even useful) to make thefile polling step pluggable in Pd so that other solutions (including no-OS ones) could easily be fit into Pd. cheers Miller --------------------------- quote ------ In my understanding the remote GUI features has not been given much attention recently, but we are interested in using it for our application on the embedded platform Bela <http://bela.io>, based on the BeagleBone Black. Currently, our users run their patches using libpd but we want to give them a way to do live patching. For this reason, we want to run the Pd backend on the BeagleBone Black and the GUI front-end on their computer, taking advantage of the ethernet-over-USB connection between the two. In our working prototype the user has to manually start the Pd GUI on the computer, giving the port and address used by the BeagleBone. In order to make this easier out-of-the-box, it should be possible to add a menu entry in the Pd GUI like "attach to running Pd" which would detach (and possibly kill?) the current Pd instance and attach to one on the specified port / interface. Is this a feature that you would be happy to merge back into Pd? Any recommendations? Another issue with running a remote GUI, is that the GUI shows the filesystem of the computer it is running on, while the backend will try to save on that path in the filesystem it is running on, which is pretty inconvenient. I worked around it with a solution that is good for us but is pretty much platform-specific (see below). A more widely useful way of doing this would involve the Pd backend send the directory listing over to the GUI. Additional notes on the current status of the project: The project in its current state is https://github.com/giuliomoro/pure-data/tree/Bela-master Additional changes I already made involve: - writing a Pd audio backend for Bela - taking the polling of file descriptors out of the audio thread, as that is a big burden for low-power embedded platforms, and especially bad for us since we are using Xenomai and we aim at low latency. If the fd is ready to be read, I write to a ringbuffer (got it from libpd/utils) which is then read from the audio thread. This is still patchy but works mostly ok. I should add pre-parsing of the GUI messages in the polling thread so that they do not take too much CPU when they are parsed in the audio thread (messages generated by moving the mouse can be pretty CPU intensive ... ). - load/save when GUI and Pd are on different machines: the BeagleBone automatically exposes and mounts its filesystems to the computer. Exploiting the shared filesystem I allow users to save/load patches from a location on the shared volume by "remapping" in the backend the path passed by the GUI . - when running a remote GUI, the GUI shows the filesystem of the computer it is running on, while the backend will try to save on that path in the filesystem it is running on, which is pretty inconvenient. The BeagleBone automatically exposes and mounts its filesystems to the computer. Exploiting the shared filesystem I allow users to save/load patches from a location on the shared volume by "remapping" in the backend the path passed by the GUI . - so now on Bela I can make live patching with an actual (measured) roundtrip latency of 3.7ms (blocksize 64, delay 0).

1 0

Revamping the remote GUI feature
by Giulio Moro 03 Jun '17

03 Jun '17

In my understanding the remote GUI features has not been given much attention recently, but we are interested in using it for our application on the embedded platform Bela <http://bela.io>, based on the BeagleBone Black. Currently, our users run their patches using libpd but we want to give them a way to do live patching. For this reason, we want to run the Pd backend on the BeagleBone Black and the GUI front-end on their computer, taking advantage of the ethernet-over-USB connection between the two. In our working prototype the user has to manually start the Pd GUI on the computer, giving the port and address used by the BeagleBone. In order to make this easier out-of-the-box, it should be possible to add a menu entry in the Pd GUI like "attach to running Pd" which would detach (and possibly kill?) the current Pd instance and attach to one on the specified port / interface. Is this a feature that you would be happy to merge back into Pd? Any recommendations? Another issue with running a remote GUI, is that the GUI shows the filesystem of the computer it is running on, while the backend will try to save on that path in the filesystem it is running on, which is pretty inconvenient. I worked around it with a solution that is good for us but is pretty much platform-specific (see below). A more widely useful way of doing this would involve the Pd backend send the directory listing over to the GUI. Additional notes on the current status of the project: The project in its current state is https://github.com/giuliomoro/pure-data/tree/Bela-master Additional changes I already made involve: - writing a Pd audio backend for Bela - taking the polling of file descriptors out of the audio thread, as that is a big burden for low-power embedded platforms, and especially bad for us since we are using Xenomai and we aim at low latency. If the fd is ready to be read, I write to a ringbuffer (got it from libpd/utils) which is then read from the audio thread. This is still patchy but works mostly ok. I should add pre-parsing of the GUI messages in the polling thread so that they do not take too much CPU when they are parsed in the audio thread (messages generated by moving the mouse can be pretty CPU intensive ... ). - load/save when GUI and Pd are on different machines: the BeagleBone automatically exposes and mounts its filesystems to the computer. Exploiting the shared filesystem I allow users to save/load patches from a location on the shared volume by "remapping" in the backend the path passed by the GUI . - when running a remote GUI, the GUI shows the filesystem of the computer it is running on, while the backend will try to save on that path in the filesystem it is running on, which is pretty inconvenient. The BeagleBone automatically exposes and mounts its filesystems to the computer. Exploiting the shared filesystem I allow users to save/load patches from a location on the shared volume by "remapping" in the backend the path passed by the GUI . - so now on Bela I can make live patching with an actual (measured) roundtrip latency of 3.7ms (blocksize 64, delay 0).

2 1

[pure-data:bugs] #1298 `motion` message emits canvas_doclick, is it useless?
by Giulio Moro 03 Jun '17

03 Jun '17

--- ** [bugs:#1298] `motion` message emits canvas_doclick, is it useless?** **Status:** open **Group:** v0.47 **Created:** Sat Jun 03, 2017 12:03 AM UTC by Giulio Moro **Last Updated:** Sat Jun 03, 2017 12:03 AM UTC **Owner:** nobody In `g_editor.c`, `canvas_motion()` is called when the canvas receives a `motion` message. As far as I can tell, this happens only when the mouse is moved on the GUI (and there is no click). In a long chain of `if .. else if`, the last `else` is: ``` else { canvas_doclick(x, xpos, ypos, 0, mod, 0); } ``` The signature for `canvas_doclick()` is ``` void canvas_doclick(t_canvas *x, int xpos, int ypos, int which, int mod, int doit) ``` So the above call invokes it with `doit = 0`. So, my points are: 1) why is `canvas_doclick` called when there is no click? This seems semantically wrong. 2) the above call always results in nothing being done (at least with the vanilla GUI objects), as they all do nothing when `doit == 0` (as you would expect). 3) So, it seems that the above call is useless. Unfortunately, it requires a lot of CPU time for patches with a large number of objects, as it calls `canvas_hitbox()` on every object in the patch. 4) Is there any reason why the call to `canvas_doclick(... doit = 0)` is there? can we take it out? --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

[pure-data:bugs] #1297 Arrow keys are misinterpreted when GUI runs on Mac and backend runs on non-Mac
by Ticket 1297 02 Jun '17

02 Jun '17

--- ** [bugs:#1297] Arrow keys are misinterpreted when GUI runs on Mac and backend runs on non-Mac** **Status:** open **Group:** v0.47 **Created:** Fri Jun 02, 2017 04:04 PM UTC by Anonymous **Last Updated:** Fri Jun 02, 2017 04:04 PM UTC **Owner:** nobody If Pd runs, on a non-Apple platform, but the GUI runs remotely on Apple, then arrow keys are not received correctly. The arrow key presses on MacOS are received with `keynum`s 63232, 63233, 63234, 63235. This works just fine if your Pd has been compiled for MacOS, thanks to the `#ifdef __APPLE__` bit in `g_editor.c` ( see below). Unfortunately, if Pd is built for non-Mac and the GUI runs remotely for Mac, then there is an incompatibilty there. In principle, this (and possibly other?) mismatches between GUI and backend can be fixed by improving the communication between the two (e.g.: the GUI should tell Pd on what OS it is running on). On the other hand, I am wondering if this particular one could be simply fixed by removing the `#ifdef`? I tested this on Linux and it seems that there is no harm in removing it: by the time it gets to the #ifdef, for an arrow-key press we have `keynum == 0` and therefore none of the `if()` conditionals in the `#ifdef` is ever true. Have not tested on Windows though. So, proposed patch: ``` diff --git a/src/g_editor.c b/src/g_editor.c index 07818b4..a255b1c 100644 --- a/src/g_editor.c +++ b/src/g_editor.c @@ -1772,7 +1772,6 @@ void canvas_key(t_canvas *x, t_symbol *s, int ac, t_atom *av) if (av[1].a_type == A_SYMBOL && !strcmp(av[1].a_w.w_symbol->s_name, "Return")) keynum = '\n'; -#ifdef __APPLE__ if (keynum == 30 || keynum == 63232) keynum = 0, gotkeysym = gensym("Up"); else if (keynum == 31 || keynum == 63233) @@ -1789,7 +1788,6 @@ void canvas_key(t_canvas *x, t_symbol *s, int ac, t_atom *av) keynum = 0, gotkeysym = gensym("Prior"); else if (keynum == 63277) keynum = 0, gotkeysym = gensym("Next"); -#endif if (gensym("#key")->s_thing && down) pd_float(gensym("#key")->s_thing, (t_float)keynum); if (gensym("#keyup")->s_thing && !down) ``` --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev June 2017