I found a serious bug in Pyglet 1.2.2 for Python 2.7, on Windows.

[pyglet_has_bugs]

If one presses and release either ALT key an odd number of times, then tries to press left CTRL, Pyglet no events are fired. (No on_key_pressed, on_key_released, or on_draw.) If one presses a letter key instead of left CTRL, on_key_pressed doesn't get called, but _on_key_released does. Every other odd release of an ALT key fires no _on_draw, as it should.

Here is code that you can use to replicate this bug:

import pyglet

window = pyglet.window.Window()

@window.event

def on_key_press(symbol, modifiers):

    print 'key pressed'

@window.event

def on_key_release(symbol, modifiers):

    print 'key released'

@window.event

def on_draw():

    print 'drew '

    

pyglet.app.run()

[pyglet_has_bugs]

If I run that code in PyCharm's debugger and put a break point in one of the functions that isn't getting called, it suddenly is always called when it's supposed to be. Take the break point out, and then it doesn't get called at all. What the heck is going on here?

[Zim the Fox]

Can confirm the same bug happens with Python 3.3.5 on Windows.

I also noticed, if anyone wants to check, that pressing Alt Gr will cause the "on_key_press" and "on_key_release" events to be fired twice, and print screen will only fire the "on_key_release" event.

[pyglet_has_bugs]

Well dang, I can't even avoid the bug by switching to Python 3, then.

[pyglet_has_bugs]

Someone on reddit.com/r/learnpython says they couldn't reproduce the bug with Pyglet 1.2.2 and Python 3 on Linux.

http://redd.it/2zqtyf

[Leif Theden]

Please, your nick 'pyglet_has_bugs' is a bit excessive; 99.999% software projects have bugs.  In any case, thank you for the detailed bug report.  In the future please submit bug reports to https://bitbucket.org/pyglet/pyglet/issues.  Finally, I've fixed the problem on my branch and submitted a pull request.

In case anyone is interested, the issue is documented here: https://code.google.com/p/pyglet/issues/detail?id=462&q=leif&colspec=ID%20Stars%20Type%20Status%20OpSys%20Modified%20Summary

[pyglet_has_bugs]

Wow, that was fast--thanks for fixing it! Sorry about the name; at the time I made it, I was really baffled at how such a big bug could have evaded notice for so long in such a popular library, and so that's just the first name that came to mind. Yes, bugs are rampant everywhere, and no offense to Pyglet, which I have actually switched to from Pygame.

Do you know why the those functions got called when I put break points in them? It's like quantum mechanics--it only works properly if I look at it, and only breaks if I don't. Here's another analogy: The mail man is supposed to come every week day, but there is a bug: he never comes on Fridays. So, I research where he lives and set up a camera by his bedroom window, which I look at on random Fridays. Every Friday that I check the camera, he gets out of bed and delivers the mail, but every Friday that I don't check the camera, the mail doesn't come. Perhaps he notices the camera? In the case of the code, I suppose that breakpoint modifies how the function is treated, somehow.

Ah, I see you provided a link. I'll go check it out now, thanks again for the quick action!

[pyglet_has_bugs]

Wow, so this has been known for a while, and you just finally fixed it? Just for me? :o :D

[Leif Theden]

I fixed it a while ago, but the fix was never merged.  Tonight I applied an old patch I made and made a pull request.  It may be a few days until this is fixed in bitbucket. In the mean time, don't assign anything to the ALT key.  This bug has been known for a long time, but only affects windows users, and is related to the ALT key, which not many people use anyway.

I can't say how the breakpoints affects it for certain, but my guess is that the breakpoints are causing the pyglet window to lose focus, which interferes with key events in windows, and those side effects don't cause the behavior that was causing erratic input after pressing ALT.  A debugger should never cause functions to work differently.  In this case it is more related to the windows window manager more than anything.

[Adam Bark]

On 22/03/15 05:52, Leif Theden wrote:
> I fixed it a while ago, but the fix was never merged. Tonight I
> applied an old patch I made and made a pull request. It may be a few
> days until this is fixed in bitbucket. In the mean time, don't assign
> anything to the ALT key. This bug has been known for a long time, but
> only affects windows users, and is related to the ALT key, which not
> many people use anyway.
>
> I can't say how the breakpoints affects it for certain, but my guess
> is that the breakpoints are causing the pyglet window to lose focus,
> which interferes with key events in windows, and those side effects
> don't cause the behavior that was causing erratic input after pressing
> ALT. A debugger should never cause functions to work differently. In
> this case it is more related to the windows window manager more than
> anything.
>

I have merged your changes. I also added you to the pyglet team a little
while ago so you should have write access to the repository if you want
to apply your fixes directly.

Thanks,
Adam.

[Rob]

I'll see to it that it gets incorporated in the 1.2.3 bugfix release. I also hope to add a few media driver fixes there.

Rob

Op zondag 22 maart 2015 12:05:24 UTC+1 schreef Adam:

[Justin Northrop]

Thank you very much for your thorough reply. Your guess about the breakpoints doesn't make sense to me, because the order of causality does not flow in that order. When my program is in a state in which pressing A will not trigger a key press event (because I've just pressed and released ALT), and I press A, then no key pressed event fires--unless there is a break point in on_key_press. So you see, the breakpoint can only be hit if the code has already performed correctly in the place that it normally fails. This indicates to me that something horrible is going on. I am amazed.

--
You received this message because you are subscribed to a topic in the Google Groups "pyglet-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pyglet-users/DuHs6HxXSm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pyglet-users...@googlegroups.com.
To post to this group, send email to pyglet...@googlegroups.com.
Visit this group at http://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.

[Justin Northrop]

Actually, your explanation makes sense; the debugger may have already interfered with the focus from the time it boots.

[Justin Northrop]

Actually, the booting of the debugger happens whether I put a break point and it works, or whether I don't put a breakpoint and it doesn't. But, whenever the breakpoint prevented failure, it was always hit at least once before the failure. I just put a condition on it so that it wouldn't be hit until the failure, and now it never gets hit at all. So, all is well with the cosmos after all.

[Leif Theden]

As I noted before, the breakpoint causes window focus to change and due to some circumstance of the window losing focus, the odd behavior seems to be avoided.  The cause of the ALT key bug is related to windows and pyglet not correctly handling the ALT key (which will open a window menu bar in some situations): when the alt key is pressed, windows sends a special event to pyglet.  The event is handled but the return value back to windows was never correct (source of the bug).  The default behavior in this case is to display a window menu bar, which windows attempts to do, but it is not implemented in pyglet and this condition puts the window and pyglet's event queue into an undefined state, and causes some events to be dropped. In this case there events are key presses/releases.  Nothing cosmic about it.  Please see the link I previously posted for more information.

[Justin Northrop]

What I was pointing out is that the breakpoint cannot cause the window focus to change if it is never hit. However, the breakpoint had been hit previously, and I assume that this prior change in focus caused a change that prevented to bug. Thanks again for helping fix it.

[Rob]

Could you try the 1.2.3a1 version?

Install with pip:

$ pip install pyglet==1.2.3a1

Or download here:

https://pypi.python.org/pypi?:action=display&name=pyglet&version=1.2.3a1

Rob

Op dinsdag 24 maart 2015 17:03:51 UTC+1 schreef pyglet_has_bugs:

[Justin Northrop]

It works now, thanks for the quick response. :D

[Brandon Keith Biggs]

Hello,
Does this version fix panning?
I don't see any panning tests in the tests folder.
Thank you,

Brandon Keith Biggs

You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users...@googlegroups.com.

[Rob van der Most]

I did not merge any fixes for panning, so I guess not. Is there an issue for it?

Rob

[Brandon Keith Biggs]

Hello,
It could be that I don't know how to make it work, but when you set pyglet.media.listener you get an error saying that this feature has not been implemented yet.
I do not know of any other ways of panning audio.

Thank you,

Brandon Keith Biggs

[Brandon Keith Biggs]

Hello,
pyglet.media.listener.position
raises an error saying that this feature is not created yet.
Is there another way of panning sound?
thanks,

Brandon Keith Biggs

On 3/30/2015 10:15 AM, Rob van der Most wrote:

[Rob]

Hi,

pyglet.media.listener is deprecated. You should use pyglet.media.get_audio_driver().get_listener()

Do you still get the same error when using that? The call to get_audio_driver() will make sure the driver is initialized.

Rob

Op maandag 30 maart 2015 14:06:03 UTC+2 schreef Brandon Keith Biggs:

[Brandon Keith Biggs]

Hello,
Is this in the documentation? I don't see it.
Also, pyglet.Player().position does not work.
Is there another function for this?

Thank you,

Brandon Keith Biggs

[Brandon Keith Biggs]

Hello,
So I got to play a little with it.
pyglet.media.get_audio_driver().get_listener()
raises a not implemented error.

player.position = (-1, 3, 1)
works, but there is only this to say about it in the documentation:
position
The position of the sound in 3D space.
The position is given as a tuple of floats (x, y, z). The unit defaults to meters, but can be modified with the listener properties.
Type:
3-tuple of float

OK, what is the z and where is the player?
Also, I believe that this did not work in the last version.

I also can't figure out what the difference between position and cone_orientation is.

Finally, is there a built-in way of repeating a sound in the player? I am looking to play machine gun fire or fast footsteps, so many of the same sounds over and over, or putting the seek back to 0 and playing it over again.

Thank you,

Brandon Keith Biggs

[Rob]

The proper way to get the listener is described in the documentation at https://pyglet.readthedocs.org/en/pyglet-1.2-maintenance/programming_guide/media.html#positional-audio

Just wondering: are you using Windows? I just noticed the listener api is missing there. That should be fixed.

I must agree that the documentation is a little sparse and could use some help.

The position of the player positions the audio source at that specific location in the 3d space. You can have multiple players at different coordinates. The listener is the actual spot where you are listening to the sound. The audio drivers will calculate the direction and volume for each sound relative to the listener and mix them to a single stream of sound.

The cone specifies how to handle directional sound, sound can be emitted in a specific direction and forms a cone in which intensity is highest. This only works if you set the direction to something different than (0,0,0). Between inner and outer angle it will change attenuation accordingly.

Rob
Op maandag 30 maart 2015 20:16:07 UTC+2 schreef Brandon Keith Biggs:

...

[Brandon Keith Biggs]

Hello,
I am using windows.
This is not in the API at all...
thanks,

Brandon Keith Biggs

You received this message because you are subscribed to the Google Groups "pyglet-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users...@googlegroups.com.

[Rob]

Indeed. I took it from the documentation of one of the underlying drivers (openAL in this case). All drivers should be modeled to behave the same.

I am currently in the process of fully covering the media package with tests and doing some refactoring. As part of this I will also fix the documentation.

Rob

Op dinsdag 31 maart 2015 14:43:07 UTC+2 schreef Brandon Keith Biggs:

...