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
On 2017-04-11 00:56, Niccolò Granieri 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.
i don't think that this is a common (or even known) issue. since i'm pretty sure that a number of people are using OSC with DSP turned on, the problem ist most likely somewhere else.
please provide: - a minimal test patch that shows the problem (since you are using localhost, a single test patch should suffice) - detailed information about which external libraries (and which versions) you are using, esp. regarding OSC parsing and networking (you *can* do all those things with vanilla objects, but traditionally externals were needed; it is not clear from your problem description which route you are taking) - detailed information about your system (including your OS).
fgd IOhannes
- I'm attaching the minimal test patch with which I was able to reproduce the bug. - I'm using Pd Vanilla, no externals installed nor required. - I'm running Pd on:
Macbook Pro 13" late 2011 (8,1) 2,4GHz Intel Core i5 16GB RAM, Intel HD Graphics 3000 512 MB
Running: OS X El Capitan (10.11.6)
PureData 0.47.1
On 11 Apr 2017, at 08:11, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-04-11 00:56, Niccolò Granieri 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.
i don't think that this is a common (or even known) issue. since i'm pretty sure that a number of people are using OSC with DSP turned on, the problem ist most likely somewhere else.
please provide:
- a minimal test patch that shows the problem (since you are using
localhost, a single test patch should suffice)
- detailed information about which external libraries (and which
versions) you are using, esp. regarding OSC parsing and networking (you *can* do all those things with: vanilla objects, but traditionally externals were needed; it is not clear from your problem description which route you are taking)
- detailed information about your system (including your OS).
fgd IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 2017-04-11 11:30, Niccolò Granieri wrote:
- I'm attaching the minimal test patch with which I was able to reproduce the bug.
thanks. however, that test patch doesn't do anything (yet).
could you make the TestPatch complete, so that it: - can be run as a standalone? (e.g. it includes a *sender* of OSC data) - sets up the system so that it can exhibit the problem, or at least provide step-by-step instructions on how to trigger the problem.
something as trivial as: 1. click here 2. notice that the number over there changes 3. now turn on the DSP 4. click here again 5. notice that the number doesn't change 6. turn DSP off 7. notice how the number changes again
ideally most of these steps should be automated (apart from the "notice" part, which probably requires a human)
i have a number of bug-patches lying on my harddisk. if they are not self-describing they are pretty worthless.
fgamsf IOhannes
Here is the fully automated patch. Hope it helps.
On 11 Apr 2017, at 10:39, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-04-11 11:30, Niccolò Granieri wrote:
- I'm attaching the minimal test patch with which I was able to reproduce the bug.
thanks. however, that test patch doesn't do anything (yet).
could you make the TestPatch complete, so that it:
- can be run as a standalone? (e.g. it includes a *sender* of OSC data)
- sets up the system so that it can exhibit the problem, or at least
provide step-by-step instructions on how to trigger the problem.
something as trivial as:
- click here
- notice that the number over there changes
- now turn on the DSP
- click here again
- notice that the number doesn't change
- turn DSP off
- notice how the number changes again
ideally most of these steps should be automated (apart from the "notice" part, which probably requires a human)
i have a number of bug-patches lying on my harddisk. if they are not self-describing they are pretty worthless.
fgamsf IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 2017-04-11 13:31, Niccolò Granieri wrote:
Here is the fully automated patch. Hope it helps.
thanks. it's perfect.
unfortunately it just shows that everything is working as expected. even if i lower the first metro to 1ms.
i'm testing this on Debian/sid, with Pd-vanilla (0.47.1, as packaged in Debian).
jsut a wild guess: GUI-updates might eventually become throttled. so you ought to make sure that it is really the numbers that do not arrive over the wire, rather than the numberboxes simply refusing to update at that rate. a simple hack is to send the numbers to the cold inlet of [f] and periodically ([metro 1000]) print out the values stored therein.
fgasdmr IOhannes
Hi IOhannes, thanks a lot for your feedback.
I guess there is something else that I'm not taking into account. Because both on the test patch I sent over, and on the actual patch I'm working on with which I'm having issues, if I turn DSP on the whole patch freezes, until I turn audio off.
GUI-updates might eventually become throttled. so you ought to make sure that it is really the numbers that do not arrive over the wire, rather than the numberboxes simply refusing to update at that rate. a simple hack is to send the numbers to the cold inlet of [f] and periodically ([metro 1000]) print out the values stored therein.
I tried, but being frozen it becomes impossible to even do anything with the incoming values.
I am sure that a colleague of mine had the same issues running the latest pd on another Macbook Pro, 15" late 2011 running El Captain, and a Lenovo ThinkPad running a linux build.
If that could be of any use I can try and find out more precise specs.
On 11 Apr 2017, at 12:42, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-04-11 13:31, Niccolò Granieri wrote:
Here is the fully automated patch. Hope it helps.
thanks. it's perfect.
unfortunately it just shows that everything is working as expected. even if i lower the first metro to 1ms.
i'm testing this on Debian/sid, with Pd-vanilla (0.47.1, as packaged in Debian).
jsut a wild guess: GUI-updates might eventually become throttled. so you ought to make sure that it is really the numbers that do not arrive over the wire, rather than the numberboxes simply refusing to update at that rate. a simple hack is to send the numbers to the cold inlet of [f] and periodically ([metro 1000]) print out the values stored therein.
fgasdmr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 2017-04-11 14:16, Niccolò Granieri wrote:
Hi IOhannes, thanks a lot for your feedback.
I guess there is something else that I'm not taking into account. Because both on the test patch I sent over, and on the actual patch I'm working on with which I'm having issues, if I turn DSP on the whole patch freezes, until I turn audio off.
a simple hack is to send the numbers to the cold inlet of [f] and periodically ([metro 1000]) print out the values stored therein.
I tried, but being frozen it becomes impossible to even do anything with the incoming values.
you obviously would do the patching *before* you switch to freeze mode...
I am sure that a colleague of mine had the same issues running the latest pd on another Macbook Pro, 15" late 2011 running El Captain, and a Lenovo ThinkPad running a linux build.
If that could be of any use I can try and find out more precise specs.
that would certainly not be a bad idea (though i don't know how to make use of the data *right now*).
debugging socket issues is mostly a tricky business. debugging socket issues on machines without access to, is almost impossible.
so far i think the data point is: if too much traffic is happening in Pd's receiver socket, it can stall the GUI updates. afaict, audio processing is not affected (is that correct?)
it might also be interesting to know whether the CPU is idling around or busy doing "things" when that problem happens (and how the CPU load is distributed on the cores).
fgasdrk IOhannes
you obviously would do the patching *before* you switch to freeze mode...
Yes, sorry I didn't specify. By patching everything before, nothing changes. The whole GUI of Pd freezes.
so far i think the data point is: if too much traffic is happening in Pd's receiver socket, it can stall the GUI updates. afaict, audio processing is not affected (is that correct?)
The audio processing is delayed, I measured up to a 5 second delay, but at a basic level (a simple phasor~) there seems to be no distortion or glitching at an audio processing level.
it might also be interesting to know whether the CPU is idling around or busy doing "things" when that problem happens (and how the CPU load is distributed on the cores).
Having a look at the CPU and the different load on the cores there seems to be no difference between before and after turning DSP on and off. When the GUI stops responding there is a significant drop in Pd's usage of CPU, from 35% down to 0,8%.
On 11 Apr 2017, at 13:23, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-04-11 14:16, Niccolò Granieri wrote:
Hi IOhannes, thanks a lot for your feedback.
I guess there is something else that I'm not taking into account. Because both on the test patch I sent over, and on the actual patch I'm working on with which I'm having issues, if I turn DSP on the whole patch freezes, until I turn audio off.
a simple hack is to send the numbers to the cold inlet of [f] and periodically ([metro 1000]) print out the values stored therein.
I tried, but being frozen it becomes impossible to even do anything with the incoming values.
you obviously would do the patching *before* you switch to freeze mode...
I am sure that a colleague of mine had the same issues running the latest pd on another Macbook Pro, 15" late 2011 running El Captain, and a Lenovo ThinkPad running a linux build.
If that could be of any use I can try and find out more precise specs.
that would certainly not be a bad idea (though i don't know how to make use of the data *right now*).
debugging socket issues is mostly a tricky business. debugging socket issues on machines without access to, is almost impossible.
so far i think the data point is: if too much traffic is happening in Pd's receiver socket, it can stall the GUI updates. afaict, audio processing is not affected (is that correct?)
it might also be interesting to know whether the CPU is idling around or busy doing "things" when that problem happens (and how the CPU load is distributed on the cores).
fgasdrk IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Fwiw I can reproduce exactly the behaviour that Niccolò is seeing here. OSX 10.12.3, pd vanilla 0.47.1 64 bit.
On 11 Apr 2017, at 00:56, Niccolò Granieri granieriniccolo@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
On 12 Apr 2017, at 12:55, Roman Haefeli reduzent@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@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
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?
Maybe like this:
[loadbang] | [metro 50] | | number stream with high rate | / [f ] | [0.234\ <- number box that is only updated 20 times/s
Thus, I'd never put GUI objects within the chain, I'd rather place them "besides" with their own connection so that you can delete the GUI elements later without affecting the logic.
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!
I just realized that I cannot see any process named 'wish' on OS X, so I don't know how to separate pd process and its GUI process. I do see a process named 'pd' and another one named 'Pd' in top (terminal command). When running your patch, Pd uses 6.5% and pd 2.7%. No significant cpu usage there. And your patch runs fine with Pd 0.47-1 on OS X 10.10.5. I guess I'm of not much help with this issue then, sorry.
Roman
On 12 Apr 2017, at 12:55, Roman Haefeli reduzent@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@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 12 Apr 2017, at 12:55, Roman Haefeli reduzent@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@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Damian Stewart -
IOhannes m zmoelnig -
Niccolò Granieri -
Roman Haefeli