Re: [pygame] GSoC project proposal: A new draw module
On 4/3/2010 12:58 PM, jug wrote: Marcus von Appen wrote: What would be interesting here is, what the Pen class would offer except from the drawing functions wrapped up in a class and som additional shapes. What about e.g. an aa-property to keep the argument amount low, transformation and rotation angles for the x- and y-axis (implicit transformation done upon drawing) or even vector support (e.g. for faster 2d, 2.5d, 3d operations on the shapes) using the math module? What do you think about working out some basic Pen (and utility) class(es) as an example (no need to implement any function or property, just a stub of the class, we can examine and design)? I tried to use OpenGL and found that drawing anything in 2D was very hard. For instance, I couldn't simply build a 3D set of shapes and then draw onto the screen in 2D, using existing Pygame functions; I had to muck around with textures instead. And drawing text in OpenGL -- just 2D text on a 2D surface -- is a nightmare. If people are looking for projects, how about an easy way to switch to a "Pygame mode" of drawing while using OpenGL, so that we can use existing UI and drawing libraries?
Re: [pygame] GSoC project proposal: A new draw module
Marcus von Appen wrote: What would be interesting here is, what the Pen class would offer except from the drawing functions wrapped up in a class and som additional shapes. What about e.g. an aa-property to keep the argument amount low, transformation and rotation angles for the x- and y-axis (implicit transformation done upon drawing) or even vector support (e.g. for faster 2d, 2.5d, 3d operations on the shapes) using the math module? What do you think about working out some basic Pen (and utility) class(es) as an example (no need to implement any function or property, just a stub of the class, we can examine and design)? Regards Marcus I've created a page with all ideas and concepts that everyone can (and should) edit or comment on: http://pexdra.wikidot.com/ Regards Julian
[pygame] Determining note duration from midi input
I think you've done this already, but maybe ticks with buffersize does something? Save the Normal get_ticks() on keydown, and then on keyup, print difference. ( on phone so I don't know the exact sdl_getticks() pygame function ) I found a few notes reading the docs: Excerp from docs: == The buffer_size specifies the number of output events to be buffered waiting for output. (In some cases -- see below -- PortMidi does not buffer output at all and merely passes data to a lower-level API, in which case buffersize is ignored.) latency is the delay in milliseconds applied to timestamps to determine when the output should actually occur. (If latency is < 0, 0 is assumed.) If latency is zero, timestamps are ignored and all output is delivered immediately. If latency is greater than zero, output is delayed until the message timestamp plus the latency. (NOTE: time is measured relative to the time source indicated by time_proc. Timestamps are absolute, not relative delays or offsets.) In some cases, PortMidi can obtain better timing than your application by passing timestamps along to the device driver or hardware. Latency may also help you to synchronize midi data to audio data by matching midi latency to the audio buffer latency. === -- Jake -- Jake
Re: [pygame] Keyboard events problem in Mac OS X 10.6 Snow Leopard
Glad it worked Math. On 4/3/10 9:17 AM, Mathieu Richardoz wrote: Thanks a lot for pointing me to ActivePython, it's working like a charm, and I didn't even have to reinstall PyGame :D I am now wondering if maybe, juste maybe, I could run my Django projects on top of this Python as well, but I guess that is well beyond the scope of this list, so I'll shut up now ^_^ Best regards from a rainy Paris afternoon. Math
Re: [pygame] Keyboard events problem in Mac OS X 10.6 Snow Leopard
Thanks a lot for pointing me to ActivePython, it's working like a charm, and I didn't even have to reinstall PyGame :D I am now wondering if maybe, juste maybe, I could run my Django projects on top of this Python as well, but I guess that is well beyond the scope of this list, so I'll shut up now ^_^ Best regards from a rainy Paris afternoon. Math
Re: [pygame] Keyboard events problem in Mac OS X 10.6 Snow Leopard
I believe I installed the binary from the PyGame website after installing ActivePython. No trouble at all. On 4/3/10 9:05 AM, Mathieu Richardoz wrote: Thanks Dan. That's it, the red box doesn't move, and when I press the arrow keys, I see the keypresses being echoed inside the terminal, which makes me assume they are not being "seen" by my pygame window. I've tried to implement other event types, such as MOUSEBUTTONUP and MOUSEBUTTONDOWN and they work fine. I'm going to try to install ActivePython as well, who knows. May I ask how you installed PyGame on top of it? Was it straightforward or did you have to jump through hoops? ;-) Math
Re: [pygame] Keyboard events problem in Mac OS X 10.6 Snow Leopard
Thanks Dan. That's it, the red box doesn't move, and when I press the arrow keys, I see the keypresses being echoed inside the terminal, which makes me assume they are not being "seen" by my pygame window. I've tried to implement other event types, such as MOUSEBUTTONUP and MOUSEBUTTONDOWN and they work fine. I'm going to try to install ActivePython as well, who knows. May I ask how you installed PyGame on top of it? Was it straightforward or did you have to jump through hoops? ;-) Math
Re: [pygame] Keyboard events problem in Mac OS X 10.6 Snow Leopard
Not really. In fact, it works fine on my 10.6.2 MacBook Pro. A difference would be that I use ActivePython rather that MacPorts Python. Does the screen appear on your machine? The red box just doesn't move? On 4/3/10 8:54 AM, Mathieu Richardoz wrote: Hi Dan, Thank you for your reply :-) Here's the code: --- import pygame pygame.init() screen = pygame.display.set_mode((640, 480)) background = pygame.Surface(screen.get_size()) background = background.convert() background.fill((0, 0, 255)) box = pygame.Surface((25, 25)) box = box.convert() box.fill((255, 0, 0)) box_x = 200 box_y = 200 clock = pygame.time.Clock() playing = True while playing: clock.tick(30) for event in pygame.event.get(): if event.type == pygame.QUIT: playing = False keys = pygame.key.get_pressed() if keys[pygame.K_UP]: box_y -= 5 if keys[pygame.K_DOWN]: box_y += 5 if keys[pygame.K_LEFT]: box_x -= 5 if keys[pygame.K_RIGHT]: box_x += 5 screen.blit(background, (0, 0)) screen.blit(box, (box_x, box_y)) pygame.display.flip() --- Do you see anything I might have done wrong? Math
Re: [pygame] Keyboard events problem in Mac OS X 10.6 Snow Leopard
Hi Dan, Thank you for your reply :-) Here's the code: --- import pygame pygame.init() screen = pygame.display.set_mode((640, 480)) background = pygame.Surface(screen.get_size()) background = background.convert() background.fill((0, 0, 255)) box = pygame.Surface((25, 25)) box = box.convert() box.fill((255, 0, 0)) box_x = 200 box_y = 200 clock = pygame.time.Clock() playing = True while playing: clock.tick(30) for event in pygame.event.get(): if event.type == pygame.QUIT: playing = False keys = pygame.key.get_pressed() if keys[pygame.K_UP]: box_y -= 5 if keys[pygame.K_DOWN]: box_y += 5 if keys[pygame.K_LEFT]: box_x -= 5 if keys[pygame.K_RIGHT]: box_x += 5 screen.blit(background, (0, 0)) screen.blit(box, (box_x, box_y)) pygame.display.flip() --- Do you see anything I might have done wrong? Math
Re: [pygame] Keyboard events problem in Mac OS X 10.6 Snow Leopard
Hi Math- Could you post some of your key event code for us to look at? On 4/3/10 8:03 AM, Mathieu Richardoz wrote: Hello fellow PyGamers, I have a very annoying problem with my PyGame installation under Mac OS X 10.6 Snow Leopard. When I execute a PyGame program from the Terminal, the keys I press are not sent to the game window but to the Terminal window itself, where they are echoed, which means that no key presses are ever detected by my program :'( I've been googling that problem for the past couple of hours, and the only reference to it I've found is this post: http://www.mail-archive.com/pygame-users@seul.org/msg09102.html , to which there was no conclusive answer. I've installed pygame through MacPorts, where it depends upon the python24 package. I thus run it through Python 2.4.6. I even tried to force grab the focus with pygame.event.set_grab(True), but the behaviour remains the same. Thanks in advance for any help you could provide on that matter. Math
[pygame] Keyboard events problem in Mac OS X 10.6 Snow Leopard
Hello fellow PyGamers, I have a very annoying problem with my PyGame installation under Mac OS X 10.6 Snow Leopard. When I execute a PyGame program from the Terminal, the keys I press are not sent to the game window but to the Terminal window itself, where they are echoed, which means that no key presses are ever detected by my program :'( I've been googling that problem for the past couple of hours, and the only reference to it I've found is this post: http://www.mail-archive.com/pygame-users@seul.org/msg09102.html , to which there was no conclusive answer. I've installed pygame through MacPorts, where it depends upon the python24 package. I thus run it through Python 2.4.6. I even tried to force grab the focus with pygame.event.set_grab(True), but the behaviour remains the same. Thanks in advance for any help you could provide on that matter. Math
Re: [pygame] Determining note duration from midi input
Something's rotten somewhere... I'll have to check the midi spec and see, but I think timestamps are part of it. IIRC, the server sends info to the device telling it to start timestamping relative to a particular time. If this is correct, then something may be wrong with the lib or your device. If timestamps are completely in software it may just be the lib. I am curious what pygame.midi.init does. Perhaps the casio uses a non-standard initializarion procedure so the timestamp reset isn't being performed. not really sure though, I'm away from home on my phone. i'll give you a proper reply once I can get home and look over various source codes and maybe we can figure out this casio problem. On 4/3/10, Neilen Marais wrote: > Hi Luke > > On Fri, Apr 2, 2010 at 7:00 PM, Luke Paireepinart > wrote: >> No problem. >> I just changed 'casio_i' until it started reading midi data from my >> keyboard. my ID was 1. how did you figure out your ID's? trial and >> error? > > There is pygame.midi.get_count() and pygame.midi.get_device_info() > that can help. There is a pretty nice example in > pygame/examples/midi.py that comes with the source distribution. > >> I'm not sure if your keyboard has aftertouch, but you basically had the >> right idea. I'm not sure why you think timestamp is wrong. Do you get >> keyup's when you release the key? your keyboard may force sending keyups >> before the key is actually released. >> Here's some event data from my keyboard (playing 2 notes of different >> lengths): >> > 'data1': >> 72, 'data3': 0, 'data2': 66})> >> > 'data1': >> 72, 'data3': 0, 'data2': 64})> >> > 'data1': >> 69, 'data3': 0, 'data2': 66})> >> > 'data1': >> 69, 'data3': 0, 'data2': 64})> > > Hmm, there definitely seems to be something wrong here. No after > touch, simple "digital piano" (Casio Privia PX-200). The numbers I get > don't make sense. Using code that I modified from yours > (http://pastebin.com/kMTt0kQH ), I generated the following output by > playing a stacato note (i.e. very short duration), followed by a short > note followed by a long note. As you can see the timestamps make no > sense! However, looking at the midi event stream in real time, the > events are created at the right time. i.e. I press a key - key down > event. Hold - nothing. Release - key up event. > > 'data1': 60, 'data3': 0, 'data2': 95})> > Key 60 was pressed. > 'data1': 60, 'data3': 0, 'data2': 64})> > Key 60 was held down for 1. > 'data1': 60, 'data3': 0, 'data2': 63})> > Key 60 was pressed. > 'data1': 60, 'data3': 0, 'data2': 64})> > Key 60 was held down for 2. > 'data1': 60, 'data3': 0, 'data2': 67})> > Key 60 was pressed. > 'data1': 60, 'data3': 0, 'data2': 64})> > Key 60 was held down for 0. > 'data1': 60, 'data3': 0, 'data2': 92})> > Key 60 was pressed. > 'data1': 60, 'data3': 0, 'data2': 64})> > Key 60 was held down for -1. > >> Also I dont' think you're registering the events properly because I'm >> unable >> to actually use the event like a normal event. >> >> Yeah, could you specify which version of pygame you're using? >> I'm not sure what 'fastevent' is, I can't find it in the docs. > > As far as I can tell it's a work-alike that is supposed to be faster > (http://www.pygame.org/wiki/todo#fastevent%20as%20default%20event%20module > ). I simply used it because that is what the included pygame example > code used. More info > (http://dev.laptop.org/~mcfletch/OLPCGames/pydoc/pygame.fastevent.html > ) > >> I'm >> suspecting it's broken in my pygame version because the events you were >> registering I wasn't able to access their data meembers. > > I'm using pygame 1.9.1. Conversely, I found that your code that used > the normal event did not work. Digging deeper it seems that the > pygame.midi is buggy in the sense that it uses an event number that is > bigger than pygame.NUMEVENTS, causing them to be ignored. By changing > the pygame/midi.py source to use a lower event number, both > pygame.event and pygame.fastevent works for me. > >> What do you think? > > Would have been great it it worked for me! Well, it seems like there > is some problem with my hardware or some other software component > between pygame and the hardware. Would you agree? I'm pretty sure the > basic hardware and drivers work though, since I tested recording with > rosegarden and it seemed to work quite well! > > Thanks > Neilen > -- Sent from my mobile device
Re: [pygame] Re: Determining note duration from midi input
Hi Luke On Fri, Apr 2, 2010 at 7:00 PM, Luke Paireepinart wrote: > No problem. > I just changed 'casio_i' until it started reading midi data from my > keyboard. my ID was 1. how did you figure out your ID's? trial and error? There is pygame.midi.get_count() and pygame.midi.get_device_info() that can help. There is a pretty nice example in pygame/examples/midi.py that comes with the source distribution. > I'm not sure if your keyboard has aftertouch, but you basically had the > right idea. I'm not sure why you think timestamp is wrong. Do you get > keyup's when you release the key? your keyboard may force sending keyups > before the key is actually released. > Here's some event data from my keyboard (playing 2 notes of different > lengths): > 72, 'data3': 0, 'data2': 66})> > 72, 'data3': 0, 'data2': 64})> > 69, 'data3': 0, 'data2': 66})> > 69, 'data3': 0, 'data2': 64})> Hmm, there definitely seems to be something wrong here. No after touch, simple "digital piano" (Casio Privia PX-200). The numbers I get don't make sense. Using code that I modified from yours (http://pastebin.com/kMTt0kQH ), I generated the following output by playing a stacato note (i.e. very short duration), followed by a short note followed by a long note. As you can see the timestamps make no sense! However, looking at the midi event stream in real time, the events are created at the right time. i.e. I press a key - key down event. Hold - nothing. Release - key up event. Key 60 was pressed. Key 60 was held down for 1. Key 60 was pressed. Key 60 was held down for 2. Key 60 was pressed. Key 60 was held down for 0. Key 60 was pressed. Key 60 was held down for -1. > Also I dont' think you're registering the events properly because I'm unable > to actually use the event like a normal event. > > Yeah, could you specify which version of pygame you're using? > I'm not sure what 'fastevent' is, I can't find it in the docs. As far as I can tell it's a work-alike that is supposed to be faster (http://www.pygame.org/wiki/todo#fastevent%20as%20default%20event%20module ). I simply used it because that is what the included pygame example code used. More info (http://dev.laptop.org/~mcfletch/OLPCGames/pydoc/pygame.fastevent.html ) > I'm > suspecting it's broken in my pygame version because the events you were > registering I wasn't able to access their data meembers. I'm using pygame 1.9.1. Conversely, I found that your code that used the normal event did not work. Digging deeper it seems that the pygame.midi is buggy in the sense that it uses an event number that is bigger than pygame.NUMEVENTS, causing them to be ignored. By changing the pygame/midi.py source to use a lower event number, both pygame.event and pygame.fastevent works for me. > What do you think? Would have been great it it worked for me! Well, it seems like there is some problem with my hardware or some other software component between pygame and the hardware. Would you agree? I'm pretty sure the basic hardware and drivers work though, since I tested recording with rosegarden and it seemed to work quite well! Thanks Neilen
