Hi, I have this weird problem.
Ive been trying various installers over the last years. On all of
them the metro is unstable. Im routing pd-midi into reason, and the
sound from reason into live. I know mentioning reason on this list is
like swearing in church, but thats what I do. And the metro stutters
irregularly.
Now, the only version of pd that runs a stable metro is a 2 year old
one (think it was HC's installer), the kind that reside in the usr
directory, and launched through terminal. Can anyone give me some
kind of explanation to this (other than to do with reason)? And is
there a fix for it?
Cheers, Timon.
hey timon,
On Feb 16, 2006, at 9:18 AM, timon wrote:
Hi, I have this weird problem. Ive been trying various installers over the last years. On all of
them the metro is unstable. Im routing pd-midi into reason, and the
sound from reason into live. I know mentioning reason on this list
is like swearing in church, but thats what I do. And the metro
stutters irregularly.Now, the only version of pd that runs a stable metro is a 2 year
old one (think it was HC's installer), the kind that reside in the
usr directory, and launched through terminal. Can anyone give me
some kind of explanation to this (other than to do with reason)?
And is there a fix for it?
...y'know, chris has been complaining about this for awhile, but I've
not seen it...of course I should point out that I don't use much of
the audio/midi side of pd, and only stick to visual processing, which
seems to deal with large grained timescales where a hiccup in metro
wouldn't be noticeable...
...do you have a small example patch that shows the problem? Are you
running the audio engine when you see the problem? I seem to
remember some problem with pd's timing that was solved by leaving the
audio processing on, even if you aren't using it...
...it could also be a portmidi problem, too: suffice to say, I think
we should solve this ASAP ;-)
james
james tittle wrote:
Are you running the audio engine when you see the problem? I seem to remember some problem with pd's timing that was solved by leaving the audio processing on, even if you aren't using it...
Oh yeah, I forgot about that. This has more to do with OSC and netsend/netreceive IIRC (or was it even normal send/recieve pairs? hmmmm...), but perhaps it affects portmidi as well.
best, d.
Hi Timon,
timon wrote:
Hi, I have this weird problem. Ive been trying various installers over the last years. On all of them the metro is unstable.
<snip> > the metro stutters irregularly.
Can't say I've experienced this. A few questions:
trigger irregularly), or does it have an audible reaction (a triggered note plays irregularly)? I ask because the GUI of the installers is incredibly slow compared with older versions.
Please verify that the problem happens in PD only, perhaps by using the metro to switch an oscillator on and off. If it works fine in PD, then the problem could be the MIDI connection with Reason, or how Reason handles the incoming data. Also it would help to have your OSX version, I imagine. Then somebody can narrow down what the cause might be.
d.
On 16 Feb 2006, at 16:54, derek holzer wrote:
Hi Timon,
timon wrote:
Hi, I have this weird problem. Ive been trying various installers over the last years. On all of
them
the metro is unstable.
<snip> > the metro stutters irregularly.
Can't say I've experienced this. A few questions:
- What do you mean by "stuttering"?
Irregular bangs coming out of the metro.
- Does it happen when only using PD, w/o Reason or Live?
I havent tried. As I use reason or live to generate audio. Ill do a
little test.
- Is it a visual stutter (a connected bang GUI-element appears to
trigger irregularly), or does it have an audible reaction (a
triggered note plays irregularly)? I ask because the GUI of the
installers is incredibly slow compared with older versions.
NO. Its definitely hear-able.
Please verify that the problem happens in PD only, perhaps by using
the metro to switch an oscillator on and off. If it works fine in
PD, then the problem could be the MIDI connection with Reason, or
how Reason handles the incoming data. Also it would help to have
your OSX version, I imagine. Then somebody can narrow down what the
cause might be.
This has been occurring on 10.3++ and 10.4++. I have looked at ways
of monitoring this in PD, but as you say, the GUI redraws slowly and
irregularly. With that in mind it looks like its within PD.
Cheers, Timon.
d.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 12: "Always give yourself credit for having more than personality"
On Feb 17, 2006, at 4:57 AM, timon botez wrote:
On 16 Feb 2006, at 16:54, derek holzer wrote:
Hi Timon,
timon wrote:
Hi, I have this weird problem. Ive been trying various installers over the last years. On all of
them
the metro is unstable.
<snip> > the metro stutters irregularly.
Can't say I've experienced this. A few questions:
- What do you mean by "stuttering"?
Irregular bangs coming out of the metro.
- Does it happen when only using PD, w/o Reason or Live?
I havent tried. As I use reason or live to generate audio. Ill do a
little test.
- Is it a visual stutter (a connected bang GUI-element appears to
trigger irregularly), or does it have an audible reaction (a
triggered note plays irregularly)? I ask because the GUI of the
installers is incredibly slow compared with older versions.
Could you elaborate on this slowness? This is not something that I
have noticed, but it sounds like a problem.
.hc
NO. Its definitely hear-able.
Please verify that the problem happens in PD only, perhaps by using
the metro to switch an oscillator on and off. If it works fine in PD,
then the problem could be the MIDI connection with Reason, or how
Reason handles the incoming data. Also it would help to have your OSX
version, I imagine. Then somebody can narrow down what the cause
might be.This has been occurring on 10.3++ and 10.4++. I have looked at ways of
monitoring this in PD, but as you say, the GUI redraws slowly and
irregularly. With that in mind it looks like its within PD.Cheers, Timon.
d.
--
derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 12: "Always give yourself credit for having more than personality"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers.
- General Smedley Butler
Hi HC,
Hans-Christoph Steiner wrote:
the GUI of the installers is incredibly slow compared with older versions.
Could you elaborate on this slowness? This is not something that I have noticed, but it sounds like a problem.
I've mentioned this before on the list, but whenever I try to run my audio performance patches (built w/ PD Linux 0.39 self-compiled on a G4 Powerbook) on OSX, I get a sluggish or totally non-responsive GUI. I can get them usable if I reduce the complexity, and slowing down the "refresh rate" of things like number boxes and bangs helps. But the bottom line is that the Aqua/TclTk on OSX just doesn't work as well as under Linux on the exact same hardware, and PD suffers from it. It actually can slow down or jam up my entire OSX desktop as well, which is an even bigger bummer. Sometimes this effect lasts even after quitting PD, requiring a restart.
Sara Kolster noticed this as well. She's using a rather old installer (0.37.1) with GEM for video performances which runs pretty smoothly on OSX 10.3. For testing, she installed the latest 0.39 RC-8 and got the same thing... totally unresponsive GUI.
Another less severe irritation is that I sometimes get placement errors, i.e. I draw a box to select some objects and the box appears several cm lower and to the right from where my cursor is. This is a sporadic and infrequent bug, but it does remind me of errors involving number boxes and other GUI elements from earlier installers.
My own comparisons showed James' PD++ installer to be slightly better in terms of GUI response, but still not as usable as under Linux. I also compiled 0.39 myself (outside the build system, which was broken in December when I tried it) with pretty much the same results. I wanted to compile against a newer version of Tcl/Tk but I couldn't convince the compiler to use it. See also:
http://lists.puredata.info/pipermail/pd-list/2006-01/034556.html
best, d.
On 2/17/06, derek holzer derek@x-i.net wrote:
Hi HC,
It actually can slow down or jam up my entire OSX desktop as well, which is an even bigger bummer. Sometimes this effect lasts even after quitting PD, requiring a restart.
This is most likely due to the elevated pthread priority hack Pd uses on OSX. Setting the -nrt flag should bypass that, but it should probably be removed altogether.
The effect lasting after Pd sounds like the Pd process is not killed after the Wish GUI quits. There is nothing Pd can do while it's not running to affect the OS.
cgc
Hi Chris,
chris clepper wrote:
On 2/17/06, derek holzer derek@x-i.net wrote:
It actually can slow down or jam up my entire OSX desktop as well, which is an even bigger bummer. Sometimes this effect lasts even after quitting PD, requiring a restart.
This is most likely due to the elevated pthread priority hack Pd uses on OSX. Setting the -nrt flag should bypass that, but it should probably be removed altogether.
OK, that's interesting. I'll see if -nrt speeds up the GUI too. I'm used to RT stuff on Linux, so I wonder will using -nrt affect audio performance in terms of dropouts and the like?
The effect lasting after Pd sounds like the Pd process is not killed after the Wish GUI quits. There is nothing Pd can do while it's not running to affect the OS.
This is also what I thought. But without a responsive desktop and with no way to exit to console on OSX, there's no way to catch the runaway process and kill it. Too bad...
d.
On Feb 17, 2006, at 12:28 PM, chris clepper wrote:
On 2/17/06, derek holzer derek@x-i.net wrote:
Hi HC,
It actually can slow down or jam up my entire OSX desktop as well, which
is an even bigger bummer. Sometimes this effect lasts even after quitting PD, requiring a restart.This is most likely due to the elevated pthread priority hack Pd uses on OSX. Setting the -nrt flag should bypass that, but it should probably be removed altogether.
I don't recall exactly why it was introduced. I thought it was to
reduce clicking when the GUI was being used during audio playback. If
there aren't any advantages, it sounds like it should be removed.
.hc
The effect lasting after Pd sounds like the Pd process is not killed after the Wish GUI quits. There is nothing Pd can do while it's not running to affect the OS.
"I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits."
- Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
on OSX. Setting the -nrt flag should bypass that, but it should probably be removed altogether.
I don't recall exactly why it was introduced. I thought it was to reduce clicking when the GUI was being used during audio playback. If there aren't any advantages, it sounds like it should be removed.
oh no. please don't remove "-nrt". it saved me tons gray hair (and "-rt" switches). however, i could live with a naming "-nort" or "--no-rt"
fgma.dsr. IOhannes
On 2/20/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Hans-Christoph Steiner wrote:
on OSX. Setting the -nrt flag should bypass that, but it should probably be removed altogether.
I don't recall exactly why it was introduced. I thought it was to reduce clicking when the GUI was being used during audio playback. If there aren't any advantages, it sounds like it should be removed.
oh no. please don't remove "-nrt". it saved me tons gray hair (and "-rt" switches). however, i could live with a naming "-nort" or "--no-rt"
I mean the pthread scheduling hack should be removed or at the very least not be on by default.
cgc
On Feb 17, 2006, at 11:32 AM, derek holzer wrote:
Hi HC,
Hans-Christoph Steiner wrote:
the GUI of the installers is incredibly slow compared with older
versions.Could you elaborate on this slowness? This is not something that I
have noticed, but it sounds like a problem.I've mentioned this before on the list, but whenever I try to run my
audio performance patches (built w/ PD Linux 0.39 self-compiled on a
G4 Powerbook) on OSX, I get a sluggish or totally non-responsive GUI.
I can get them usable if I reduce the complexity, and slowing down the
"refresh rate" of things like number boxes and bangs helps. But the
bottom line is that the Aqua/TclTk on OSX just doesn't work as well as
under Linux on the exact same hardware, and PD suffers from it. It
actually can slow down or jam up my entire OSX desktop as well, which
is an even bigger bummer. Sometimes this effect lasts even after
quitting PD, requiring a restart.Sara Kolster noticed this as well. She's using a rather old installer
(0.37.1) with GEM for video performances which runs pretty smoothly on
OSX 10.3. For testing, she installed the latest 0.39 RC-8 and got the
same thing... totally unresponsive GUI.Another less severe irritation is that I sometimes get placement
errors, i.e. I draw a box to select some objects and the box appears
several cm lower and to the right from where my cursor is. This is a
sporadic and infrequent bug, but it does remind me of errors involving
number boxes and other GUI elements from earlier installers.My own comparisons showed James' PD++ installer to be slightly better
in terms of GUI response, but still not as usable as under Linux. I
also compiled 0.39 myself (outside the build system, which was broken
in December when I tried it) with pretty much the same results. I
wanted to compile against a newer version of Tcl/Tk but I couldn't
convince the compiler to use it. See also:http://lists.puredata.info/pipermail/pd-list/2006-01/034556.html
I was well aware of the slowness of the Pd GUI on Mac OS X, but its
news to me that its actually slower than older versions. That would be
very good to test. Tigital did a bunch of work streamlining the
Tk/Aqua stuff to use CoreGraphics, which should speed things up quite a
bit. I am wondering what makes things go slower with newer versions.
That placement error is a long standing bug, its definiteyl annoying,
but no one has spent some quality time trying to track it down. The
first step would be just to find a way to consistently reproduce it.
Any ideas?
One thing that tigital is proposing, which I think would be worth
trying, is making a Fink/X11 version of Pd. This should get around the
slowness of Tk/Aqua, but would mean that you need X11 to use that
version of Pd.
.hc
best, d.
--
derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 149: "Take a break"
http://at.or.at/hans/
I for one would welcome this change. Because of the ability of programs such as XDarwin which let you launch the X server in rootless mode (or right on top of Aqua) I believe users would certainly enjoy a new era of streamlined Pd under OS X, at least as far as the Tcl/Tk implementation is concerned.
./d5
On Feb 19, 2006, at 8:15 PM, Hans-Christoph Steiner wrote:
One thing that tigital is proposing, which I think would be worth trying, is making a Fink/X11 version of Pd. This should get around the slowness of Tk/Aqua, but would mean that you need X11 to use that version of Pd.
.hc
Hi Hans,
Hans-Christoph Steiner wrote: I was well aware of the slowness of the Pd GUI on Mac OS X, but its news to me that its actually slower than older versions. That would be very good to test. Tigital did a bunch of work streamlining the Tk/Aqua stuff to use CoreGraphics, which should speed things up quite a bit. I am wondering what makes things go slower with newer versions.
I am still using the 0.37.1 PD-version(on osx.3.9) for the exact same reason that the newer versions of pd are super slow. Opening up my performance interface (using quite a few abstractions) and trying to push a toggle or bang is nearly impossible. No response at all.
As you, I am puzzled by the fact what changed in the newer versions which makes the pd-GUI slower than the older versions. I'm using the 0.37.1 version without X11 and i'm using the tcl/tk 8.4.9 (wish shell). I'm not a great fan of using X11, but if that would help figuring out what went different in the production of the newer pd-versions, than that would be worth trying.
Sara
One thing that tigital is proposing, which I think would be worth trying, is making a Fink/X11 version of Pd. This should get around the slowness of Tk/Aqua, but would mean that you need X11 to use that version of Pd.
.hc
Hi Sara (and others reading this thread),
have you tried this on OS X ?
http://www.lachoseinteractive.net/en/products/processwizard/
It's basically just a frontend for the unix renice command. I find that it's possible to get 25-30% increase in efficiency using this.
You can choose to increase the CPU processing priority of either the GUI or the audio/video. whatever you see fit. Possibly this can serve as an interim solution.
./d5
On Feb 19, 2006, at 8:59 PM, sara kolster wrote:
Hi Hans,
Hans-Christoph Steiner wrote: I was well aware of the slowness of the Pd GUI on Mac OS X, but its news to me that its actually slower than older versions. That would be very good to test. Tigital did a bunch of work streamlining the Tk/Aqua stuff to use CoreGraphics, which should speed things up quite a bit. I am wondering what makes things go slower with newer versions.
I am still using the 0.37.1 PD-version(on osx.3.9) for the exact same reason that the newer versions of pd are super slow. Opening up my performance interface (using quite a few abstractions) and trying to push a toggle or bang is nearly impossible. No response at all.
As you, I am puzzled by the fact what changed in the newer versions which makes the pd-GUI slower than the older versions. I'm using the 0.37.1 version without X11 and i'm using the tcl/tk 8.4.9 (wish shell). I'm not a great fan of using X11, but if that would help figuring out what went different in the production of the newer pd-versions, than that would be worth trying.
Sara
One thing that tigital is proposing, which I think would be worth trying, is making a Fink/X11 version of Pd. This should get around the slowness of Tk/Aqua, but would mean that you need X11 to use that version of Pd.
.hc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
What do you do exactly? Increase the priority of the pd background
process?
It sounds like we need to revisit the "realtime" priority stuff on Mac
OS X. Sara, have you tried using the -nrt flag with a newer version
of Pd? I am curious as to whether that would make a difference.
.hc
On Feb 19, 2006, at 9:07 PM, day 5 wrote:
Hi Sara (and others reading this thread),
have you tried this on OS X ?
http://www.lachoseinteractive.net/en/products/processwizard/
It's basically just a frontend for the unix renice command. I find
that it's possible to get 25-30% increase in efficiency using this.You can choose to increase the CPU processing priority of either the
GUI or the audio/video. whatever you see fit. Possibly this can serve
as an interim solution../d5
On Feb 19, 2006, at 8:59 PM, sara kolster wrote:
Hi Hans,
Hans-Christoph Steiner wrote: I was well aware of the slowness of the Pd GUI on Mac OS X, but its
news to me that its actually slower than older versions. That would
be very good to test. Tigital did a bunch of work streamlining the
Tk/Aqua stuff to use CoreGraphics, which should speed things up
quite a bit. I am wondering what makes things go slower with newer
versions.I am still using the 0.37.1 PD-version(on osx.3.9) for the exact same
reason that the newer versions of pd are super slow. Opening up my
performance interface (using quite a few abstractions) and trying to
push a toggle or bang is nearly impossible. No response at all.As you, I am puzzled by the fact what changed in the newer versions
which makes the pd-GUI slower than the older versions. I'm using the
0.37.1 version without X11 and i'm using the tcl/tk 8.4.9 (wish
shell). I'm not a great fan of using X11, but if that would help
figuring out what went different in the production of the newer
pd-versions, than that would be worth trying.Sara
One thing that tigital is proposing, which I think would be worth
trying, is making a Fink/X11 version of Pd. This should get around
the slowness of Tk/Aqua, but would mean that you need X11 to use
that version of Pd..hc
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
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism."
- retired U.S. Army general,
William Odom
Well, I only increase the priority of the pd background process when
I'm doing realtime audio and video simultaneously.
I imagine for users that are dealing with really intense graphic
interfaces, you can simply instead increase processing priority to the
Pd.app instead of the pd background process.
It seems to work anyway, i'd imagine a
% renice -20 -p[pd process id here]
would work just as well. In any event, using these techniques of
manipulating processing priority lets users get a LOT more mileage out
of the pd-extended builds than you would normally get when all
nicelevel = 0.
./d5
On Feb 20, 2006, at 12:42 AM, Hans-Christoph Steiner wrote:
What do you do exactly? Increase the priority of the pd background
process?It sounds like we need to revisit the "realtime" priority stuff on Mac
OS X. Sara, have you tried using the -nrt flag with a newer version
of Pd? I am curious as to whether that would make a difference..hc
On Feb 19, 2006, at 9:07 PM, day 5 wrote:
Hi Sara (and others reading this thread),
have you tried this on OS X ?
http://www.lachoseinteractive.net/en/products/processwizard/
It's basically just a frontend for the unix renice command. I find
that it's possible to get 25-30% increase in efficiency using this.You can choose to increase the CPU processing priority of either the
GUI or the audio/video. whatever you see fit. Possibly this can serve
as an interim solution../d5
On Feb 19, 2006, at 8:59 PM, sara kolster wrote:
Hi Hans,
Hans-Christoph Steiner wrote: I was well aware of the slowness of the Pd GUI on Mac OS X, but its
news to me that its actually slower than older versions. That
would be very good to test. Tigital did a bunch of work
streamlining the Tk/Aqua stuff to use CoreGraphics, which should
speed things up quite a bit. I am wondering what makes things go
slower with newer versions.I am still using the 0.37.1 PD-version(on osx.3.9) for the exact
same reason that the newer versions of pd are super slow. Opening up
my performance interface (using quite a few abstractions) and trying
to push a toggle or bang is nearly impossible. No response at all.As you, I am puzzled by the fact what changed in the newer versions
which makes the pd-GUI slower than the older versions. I'm using the
0.37.1 version without X11 and i'm using the tcl/tk 8.4.9 (wish
shell). I'm not a great fan of using X11, but if that would help
figuring out what went different in the production of the newer
pd-versions, than that would be worth trying.Sara
One thing that tigital is proposing, which I think would be worth
trying, is making a Fink/X11 version of Pd. This should get around
the slowness of Tk/Aqua, but would mean that you need X11 to use
that version of Pd..hc
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
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism." - retired U.S. Army general,
William Odom
Perhaps we could add in a preference which would renice the gui or core
process to a lower priority. That would not require any special
permissions, like setuid. And it could be reset with a reset. Perhaps
even a message to pd to set it, so that a give patch can set things
that way. I wonder if that would be worth it, or whether there is a
better approach (probably).
.hc
On Feb 20, 2006, at 10:20 AM, day 5 wrote:
Well, I only increase the priority of the pd background process when
I'm doing realtime audio and video simultaneously.I imagine for users that are dealing with really intense graphic
interfaces, you can simply instead increase processing priority to the
Pd.app instead of the pd background process.It seems to work anyway, i'd imagine a
% renice -20 -p[pd process id here]
would work just as well. In any event, using these techniques of
manipulating processing priority lets users get a LOT more mileage out
of the pd-extended builds than you would normally get when all
nicelevel = 0../d5
On Feb 20, 2006, at 12:42 AM, Hans-Christoph Steiner wrote:
What do you do exactly? Increase the priority of the pd background
process?It sounds like we need to revisit the "realtime" priority stuff on
Mac OS X. Sara, have you tried using the -nrt flag with a newer
version of Pd? I am curious as to whether that would make a
difference..hc
On Feb 19, 2006, at 9:07 PM, day 5 wrote:
Hi Sara (and others reading this thread),
have you tried this on OS X ?
http://www.lachoseinteractive.net/en/products/processwizard/
It's basically just a frontend for the unix renice command. I find
that it's possible to get 25-30% increase in efficiency using this.You can choose to increase the CPU processing priority of either the
GUI or the audio/video. whatever you see fit. Possibly this can
serve as an interim solution../d5
On Feb 19, 2006, at 8:59 PM, sara kolster wrote:
Hi Hans,
Hans-Christoph Steiner wrote: I was well aware of the slowness of the Pd GUI on Mac OS X, but
its news to me that its actually slower than older versions. That
would be very good to test. Tigital did a bunch of work
streamlining the Tk/Aqua stuff to use CoreGraphics, which should
speed things up quite a bit. I am wondering what makes things go
slower with newer versions.I am still using the 0.37.1 PD-version(on osx.3.9) for the exact
same reason that the newer versions of pd are super slow. Opening
up my performance interface (using quite a few abstractions) and
trying to push a toggle or bang is nearly impossible. No response
at all.As you, I am puzzled by the fact what changed in the newer versions
which makes the pd-GUI slower than the older versions. I'm using
the 0.37.1 version without X11 and i'm using the tcl/tk 8.4.9 (wish
shell). I'm not a great fan of using X11, but if that would help
figuring out what went different in the production of the newer
pd-versions, than that would be worth trying.Sara
One thing that tigital is proposing, which I think would be worth
trying, is making a Fink/X11 version of Pd. This should get
around the slowness of Tk/Aqua, but would mean that you need X11
to use that version of Pd..hc
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
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism." - retired U.S. Army general,
William Odom
¡El pueblo unido jamás será vencido!
- Is it a visual stutter (a connected bang GUI-element appears
to trigger irregularly), or does it have an audible reaction (a
triggered note plays irregularly)? I ask because the GUI of the
installers is incredibly slow compared with older versions.Could you elaborate on this slowness? This is not something that I
have noticed, but it sounds like a problem.
Well, at high speed the dot in the bangs drops out all together. The
redraw of numbers in the float box rarely updates in real time. I
have to admit I have had the tendency of using too many of them. At
times the redraw of the number boxes has frozen all together. Even
when manually dragging the numbers. In a sub window I have closed it
and re-opened it to find the number refreshed. Not sure what causes
that. Have paid attention to what I have done but not detected
anything unusual.
Does that help?
T.
.hc
NO. Its definitely hear-able.
Please verify that the problem happens in PD only, perhaps by
using the metro to switch an oscillator on and off. If it works
fine in PD, then the problem could be the MIDI connection with
Reason, or how Reason handles the incoming data. Also it would
help to have your OSX version, I imagine. Then somebody can
narrow down what the cause might be.This has been occurring on 10.3++ and 10.4++. I have looked at
ways of monitoring this in PD, but as you say, the GUI redraws
slowly and irregularly. With that in mind it looks like its within
PD.Cheers, Timon.
d.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 12: "Always give yourself credit for having more than personality"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle
man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Hi Timon,
timon botez wrote:
Well, at high speed the dot in the bangs drops out all together. The redraw of numbers in the float box rarely updates in real time. I have to admit I have had the tendency of using too many of them. At times the redraw of the number boxes has frozen all together. Even when manually dragging the numbers. In a sub window I have closed it and re-opened it to find the number refreshed. Not sure what causes that. Have paid attention to what I have done but not detected anything unusual.
How fast is "high speed?" How many is "too many"? Maybe you can post the patch? Keep in mind that not being able to visually see the bang doesn't mean that the "bang" message isn't being sent. The bang object has a hold time, and you can set that to a smaller number in the object's properties menu if you need to see it going faster. But the GUI isn't PD's strong point, and quickly refreshing graphics (espc tons of them) can drag down the performance of the entire application. It could simply be that you are using too many fast-refreshing GUI elements and that's what's choking your system.
Still, did you try using these bangs to trigger sounds within PD instead of over MIDI? Did it stutter then?
Also, try it over MIDI to Reason with audio on and then with audio off (assuming that PD is only generating MIDI) and see if that makes a diff.
d.