Pd-dev June 2010

pd-dev@lists.iem.at

16 participants
113 discussions

[ pure-data-Patches-3011594 ] get delwrite~ to work with block~, -nogui, rate changes
by SourceForge.net 04 Jun '10

04 Jun '10

Patches item #3011594, was opened at 2010-06-04 12:57 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3011594&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: get delwrite~ to work with block~, -nogui, rate changes Initial Comment: Maître Corbeau, sur un arbre perché, Tenait en son bec un fromage. Maître Renard, par l'odeur alléché, Lui tint à peu près ce langage : " Hé ! bonjour, Monsieur du Corbeau, Que vous êtes joli ! que vous me semblez beau ! Sans mentir, si votre ramage Se rapporte à votre plumage, Vous êtes le phénix des hôtes de ces bois. " A ces mots le Corbeau ne se sent pas de joie ; Et pour montrer sa belle voix, Il ouvre un large bec, laisse tomber sa proie. Le Renard s'en saisit, et dit : " Mon bon Monsieur, Apprenez que tout flatteur Vit aux dépens de celui qui l'écoute : Cette leçon vaut bien un fromage, sans doute. " Le Corbeau, honteux et confus, Jura, mais un peu tard, qu'on ne l'y prendrait plus. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-06-04 14:52 Message: can you tell us about the file that you attached, the why and the what maybe? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3011594&group_…

1 0

[ pure-data-Patches-3011594 ] get delwrite~ to work with block~, -nogui, rate changes
by SourceForge.net 04 Jun '10

04 Jun '10

Patches item #3011594, was opened at 2010-06-04 16:57 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3011594&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: get delwrite~ to work with block~, -nogui, rate changes Initial Comment: Maître Corbeau, sur un arbre perché, Tenait en son bec un fromage. Maître Renard, par l'odeur alléché, Lui tint à peu près ce langage : " Hé ! bonjour, Monsieur du Corbeau, Que vous êtes joli ! que vous me semblez beau ! Sans mentir, si votre ramage Se rapporte à votre plumage, Vous êtes le phénix des hôtes de ces bois. " A ces mots le Corbeau ne se sent pas de joie ; Et pour montrer sa belle voix, Il ouvre un large bec, laisse tomber sa proie. Le Renard s'en saisit, et dit : " Mon bon Monsieur, Apprenez que tout flatteur Vit aux dépens de celui qui l'écoute : Cette leçon vaut bien un fromage, sans doute. " Le Corbeau, honteux et confus, Jura, mais un peu tard, qu'on ne l'y prendrait plus. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3011594&group_…

1 0

[ pure-data-Bugs-2221231 ] consistency check failed: canvas_create_editor
by SourceForge.net 04 Jun '10

04 Jun '10

Bugs item #2221231, was opened at 2008-11-04 10:00 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2221231&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended >Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: consistency check failed: canvas_create_editor Initial Comment: i'm still getting this error in console. consistency check failed: canvas_create_editor how could i get rid of it? thank you for help. ha2k.haak(a)gmail.com ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-06-03 20:04 Message: it seems that the error message has changed but it is still present i Pd-extended 0.42.5 rc1 on Ubuntu/Karmic: consistency check failed: canvas_vis ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2221231&group_…

1 0

[ pure-data-Patches-3011285 ] fix gl_goprect logic
by SourceForge.net 04 Jun '10

04 Jun '10

Patches item #3011285, was opened at 2010-06-03 19:54 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3011285&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: fix gl_goprect logic Initial Comment: Based on a patch from Ivica Ico Bukvic, this change seems to help the GOP red rectangle get set more accurately, and according to Ivica also helps with other GOP bugs. I checked it into Pd-extended 0.42.5 here: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=135… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3011285&group_…

1 0

[ pure-data-Bugs-3010589 ] PD vanilla 0.42-5 - midiout 'loses' (re-orders) bit
by SourceForge.net 03 Jun '10

03 Jun '10

Bugs item #3010589, was opened at 2010-06-02 13:02 Message generated for change (Comment added) made by mrpeach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3010589&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Miller Puckette (millerpuckette) Summary: PD vanilla 0.42-5 - midiout 'loses' (re-orders) bit Initial Comment: WinXP Pro SP3 Pd version 0.42-5 17-Jan-07 version of PortMidi thread: http://puredata.hurleur.com/sujet-4275-vanilla-portmidi-midiout-loses-order… (see thread for text colored in where neccessary) hey everyone, I've been working with PD vanilla 0.42-5 - PortMidi midiout last night, trying to figure out why it wouldn't work with my AKAI MPD 24 properly. Here's what I found: Patch (as attached:) 240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247 | midiout And to check the results, i used: midiout -> Midiyoke -> MidiOX (all latest versions) Problem The message I sent (which was a valid MPD 24 SysEx message, double-checked several times from MidiOX directly) was DEC 240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247 and should convert have converted to HEX F0 47 00 68 31 00 0B 08 00 00 48 61 6C 6C 6F 20 20 20 F7 instead, it comes out HEX F0 47 00 68 31 00 02 08 00 00 52 61 6C 6C 1B 20 20 20 F7 - with 3 wrong HEX pairs. What happens I looked a bit at the first number, DEC 11 that should come out HEX 0B but comes out HEX 02 here's how it behaves in reverse engineering: when i send DEC 0, 1, 2 or 3, it comes out HEX 0 when i send DEC 4, 5 6 or 7, it comes out HEX 1 see table: DEC .. DEC -> HEX 00 .. 03 -> 00 04 .. 07 -> 01 08 .. 11 -> 02 12 .. 15 -> 03 16 .. 19 -> 04 20 .. 23 -> 05 24 .. 27 -> 06 28 .. 31 -> 07 32 .. 35 -> 08 36 .. 39 -> 09 40 .. 43 -> 0A 44 .. -> 0B etc. When you look at the BIN, it becomes obvious what's happening: DEC (BIN) .. DEC (BIN) -> HEX (BIN) 00 ( 0) .. 03 ( 11) -> 00 ( 0) 04 ( 100) .. 07 ( 111) -> 01 ( 1) 08 ( 1000) .. 11 ( 1011) -> 02 ( 10) 12 ( 1100) .. 15 ( 1111) -> 03 ( 11) 16 (10000) .. 19 (10011) -> 04 ( 100) 20 (10100) .. 23 (10111) -> 05 ( 101) .. two bits at the end are truncated. It wouldn't surprise me if we found them somewhere in the other 'wrong numbers' ofthe original message. When I manipulate the numbers to come out correctly in MidiOX, my MPD 24 will happily accept the sysex and execute it so the probelm is definitely not MidiOx or Midiyoke. Questions 1) can anyone confirm this? 2) is anyone currently maintaining PortMidi, so this could maybe get fixed? thanks groovelastig ---------------------------------------------------------------------- >Comment By: Martin Peach (mrpeach) Date: 2010-06-03 13:30 Message: I tried the new portmidi and it seems to work. At least [midiin] on a debian machine receives the exact same message. I just replaced the portmidi folder pd/portmidi with the new one and recompiled: nmake clean nmake ---------------------------------------------------------------------- Comment By: groovelastig (groovelastig) Date: 2010-06-03 10:40 Message: link to portmedia / portmidi: https://sourceforge.net/apps/trac/portmedia/wiki/portmidi ---------------------------------------------------------------------- Comment By: groovelastig (groovelastig) Date: 2010-06-03 10:36 Message: @mrpeach thank you for confirming! FWIW, the 15th position DEC 111 -> HEX 1B (mis-)behaves exactly as the 7th position, described above the 11th DEC 72 -> HEX 52 position 'substracts' HEX 40 (DEC 64) and the does the same --- AFAIK there's a new(er) version of PortMIDI available (v200), and according to the changelog it's backwards compatible. Is someone up for trying and compiling Pd vanilla with their new files? (and pretty please? ; ) ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2010-06-03 00:43 Message: I get this too. You can put the 11 anywhere up to the seventh position and it transmits OK. The function winmm_write_byte() in pmwinmm.c doesn't get called for some of the message. This looks like a portmidi bug. (I think it would be better to buffer the whole sysex message at the Pd end and use portmidi's Pm_WriteSysEx() function to send it.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3010589&group_…

1 0

[ pure-data-Bugs-3010589 ] PD vanilla 0.42-5 - midiout 'loses' (re-orders) bit
by SourceForge.net 03 Jun '10

03 Jun '10

Bugs item #3010589, was opened at 2010-06-02 19:02 Message generated for change (Comment added) made by groovelastig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3010589&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: PD vanilla 0.42-5 - midiout 'loses' (re-orders) bit Initial Comment: WinXP Pro SP3 Pd version 0.42-5 17-Jan-07 version of PortMidi thread: http://puredata.hurleur.com/sujet-4275-vanilla-portmidi-midiout-loses-order… (see thread for text colored in where neccessary) hey everyone, I've been working with PD vanilla 0.42-5 - PortMidi midiout last night, trying to figure out why it wouldn't work with my AKAI MPD 24 properly. Here's what I found: Patch (as attached:) 240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247 | midiout And to check the results, i used: midiout -> Midiyoke -> MidiOX (all latest versions) Problem The message I sent (which was a valid MPD 24 SysEx message, double-checked several times from MidiOX directly) was DEC 240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247 and should convert have converted to HEX F0 47 00 68 31 00 0B 08 00 00 48 61 6C 6C 6F 20 20 20 F7 instead, it comes out HEX F0 47 00 68 31 00 02 08 00 00 52 61 6C 6C 1B 20 20 20 F7 - with 3 wrong HEX pairs. What happens I looked a bit at the first number, DEC 11 that should come out HEX 0B but comes out HEX 02 here's how it behaves in reverse engineering: when i send DEC 0, 1, 2 or 3, it comes out HEX 0 when i send DEC 4, 5 6 or 7, it comes out HEX 1 see table: DEC .. DEC -> HEX 00 .. 03 -> 00 04 .. 07 -> 01 08 .. 11 -> 02 12 .. 15 -> 03 16 .. 19 -> 04 20 .. 23 -> 05 24 .. 27 -> 06 28 .. 31 -> 07 32 .. 35 -> 08 36 .. 39 -> 09 40 .. 43 -> 0A 44 .. -> 0B etc. When you look at the BIN, it becomes obvious what's happening: DEC (BIN) .. DEC (BIN) -> HEX (BIN) 00 ( 0) .. 03 ( 11) -> 00 ( 0) 04 ( 100) .. 07 ( 111) -> 01 ( 1) 08 ( 1000) .. 11 ( 1011) -> 02 ( 10) 12 ( 1100) .. 15 ( 1111) -> 03 ( 11) 16 (10000) .. 19 (10011) -> 04 ( 100) 20 (10100) .. 23 (10111) -> 05 ( 101) .. two bits at the end are truncated. It wouldn't surprise me if we found them somewhere in the other 'wrong numbers' ofthe original message. When I manipulate the numbers to come out correctly in MidiOX, my MPD 24 will happily accept the sysex and execute it so the probelm is definitely not MidiOx or Midiyoke. Questions 1) can anyone confirm this? 2) is anyone currently maintaining PortMidi, so this could maybe get fixed? thanks groovelastig ---------------------------------------------------------------------- Comment By: groovelastig (groovelastig) Date: 2010-06-03 16:40 Message: link to portmedia / portmidi: https://sourceforge.net/apps/trac/portmedia/wiki/portmidi ---------------------------------------------------------------------- Comment By: groovelastig (groovelastig) Date: 2010-06-03 16:36 Message: @mrpeach thank you for confirming! FWIW, the 15th position DEC 111 -> HEX 1B (mis-)behaves exactly as the 7th position, described above the 11th DEC 72 -> HEX 52 position 'substracts' HEX 40 (DEC 64) and the does the same --- AFAIK there's a new(er) version of PortMIDI available (v200), and according to the changelog it's backwards compatible. Is someone up for trying and compiling Pd vanilla with their new files? (and pretty please? ; ) ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2010-06-03 06:43 Message: I get this too. You can put the 11 anywhere up to the seventh position and it transmits OK. The function winmm_write_byte() in pmwinmm.c doesn't get called for some of the message. This looks like a portmidi bug. (I think it would be better to buffer the whole sysex message at the Pd end and use portmidi's Pm_WriteSysEx() function to send it.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3010589&group_…

1 0

[ pure-data-Bugs-3010589 ] PD vanilla 0.42-5 - midiout 'loses' (re-orders) bit
by SourceForge.net 03 Jun '10

03 Jun '10

Bugs item #3010589, was opened at 2010-06-02 19:02 Message generated for change (Comment added) made by groovelastig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3010589&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: PD vanilla 0.42-5 - midiout 'loses' (re-orders) bit Initial Comment: WinXP Pro SP3 Pd version 0.42-5 17-Jan-07 version of PortMidi thread: http://puredata.hurleur.com/sujet-4275-vanilla-portmidi-midiout-loses-order… (see thread for text colored in where neccessary) hey everyone, I've been working with PD vanilla 0.42-5 - PortMidi midiout last night, trying to figure out why it wouldn't work with my AKAI MPD 24 properly. Here's what I found: Patch (as attached:) 240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247 | midiout And to check the results, i used: midiout -> Midiyoke -> MidiOX (all latest versions) Problem The message I sent (which was a valid MPD 24 SysEx message, double-checked several times from MidiOX directly) was DEC 240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247 and should convert have converted to HEX F0 47 00 68 31 00 0B 08 00 00 48 61 6C 6C 6F 20 20 20 F7 instead, it comes out HEX F0 47 00 68 31 00 02 08 00 00 52 61 6C 6C 1B 20 20 20 F7 - with 3 wrong HEX pairs. What happens I looked a bit at the first number, DEC 11 that should come out HEX 0B but comes out HEX 02 here's how it behaves in reverse engineering: when i send DEC 0, 1, 2 or 3, it comes out HEX 0 when i send DEC 4, 5 6 or 7, it comes out HEX 1 see table: DEC .. DEC -> HEX 00 .. 03 -> 00 04 .. 07 -> 01 08 .. 11 -> 02 12 .. 15 -> 03 16 .. 19 -> 04 20 .. 23 -> 05 24 .. 27 -> 06 28 .. 31 -> 07 32 .. 35 -> 08 36 .. 39 -> 09 40 .. 43 -> 0A 44 .. -> 0B etc. When you look at the BIN, it becomes obvious what's happening: DEC (BIN) .. DEC (BIN) -> HEX (BIN) 00 ( 0) .. 03 ( 11) -> 00 ( 0) 04 ( 100) .. 07 ( 111) -> 01 ( 1) 08 ( 1000) .. 11 ( 1011) -> 02 ( 10) 12 ( 1100) .. 15 ( 1111) -> 03 ( 11) 16 (10000) .. 19 (10011) -> 04 ( 100) 20 (10100) .. 23 (10111) -> 05 ( 101) .. two bits at the end are truncated. It wouldn't surprise me if we found them somewhere in the other 'wrong numbers' ofthe original message. When I manipulate the numbers to come out correctly in MidiOX, my MPD 24 will happily accept the sysex and execute it so the probelm is definitely not MidiOx or Midiyoke. Questions 1) can anyone confirm this? 2) is anyone currently maintaining PortMidi, so this could maybe get fixed? thanks groovelastig ---------------------------------------------------------------------- Comment By: groovelastig (groovelastig) Date: 2010-06-03 16:36 Message: @mrpeach thank you for confirming! FWIW, the 15th position DEC 111 -> HEX 1B (mis-)behaves exactly as the 7th position, described above the 11th DEC 72 -> HEX 52 position 'substracts' HEX 40 (DEC 64) and the does the same --- AFAIK there's a new(er) version of PortMIDI available (v200), and according to the changelog it's backwards compatible. Is someone up for trying and compiling Pd vanilla with their new files? (and pretty please? ; ) ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2010-06-03 06:43 Message: I get this too. You can put the 11 anywhere up to the seventh position and it transmits OK. The function winmm_write_byte() in pmwinmm.c doesn't get called for some of the message. This looks like a portmidi bug. (I think it would be better to buffer the whole sysex message at the Pd end and use portmidi's Pm_WriteSysEx() function to send it.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3010589&group_…

1 0

WebPd in Pure Data's SVN
by chrism 03 Jun '10

03 Jun '10

Hello all, It seems like Google Code might not allow for AGPL licensed projects. How do people feel about me checking the WebPd source into the Pure Data Sourceforge SVN somewhere? If that's ok, where would be a good subdirectory? Chris. ------------------- http://mccormick.cx

4 5

[ pure-data-Bugs-3010589 ] PD vanilla 0.42-5 - midiout 'loses' (re-orders) bit
by SourceForge.net 03 Jun '10

03 Jun '10

Bugs item #3010589, was opened at 2010-06-02 13:02 Message generated for change (Comment added) made by mrpeach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3010589&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: PD vanilla 0.42-5 - midiout 'loses' (re-orders) bit Initial Comment: WinXP Pro SP3 Pd version 0.42-5 17-Jan-07 version of PortMidi thread: http://puredata.hurleur.com/sujet-4275-vanilla-portmidi-midiout-loses-order… (see thread for text colored in where neccessary) hey everyone, I've been working with PD vanilla 0.42-5 - PortMidi midiout last night, trying to figure out why it wouldn't work with my AKAI MPD 24 properly. Here's what I found: Patch (as attached:) 240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247 | midiout And to check the results, i used: midiout -> Midiyoke -> MidiOX (all latest versions) Problem The message I sent (which was a valid MPD 24 SysEx message, double-checked several times from MidiOX directly) was DEC 240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247 and should convert have converted to HEX F0 47 00 68 31 00 0B 08 00 00 48 61 6C 6C 6F 20 20 20 F7 instead, it comes out HEX F0 47 00 68 31 00 02 08 00 00 52 61 6C 6C 1B 20 20 20 F7 - with 3 wrong HEX pairs. What happens I looked a bit at the first number, DEC 11 that should come out HEX 0B but comes out HEX 02 here's how it behaves in reverse engineering: when i send DEC 0, 1, 2 or 3, it comes out HEX 0 when i send DEC 4, 5 6 or 7, it comes out HEX 1 see table: DEC .. DEC -> HEX 00 .. 03 -> 00 04 .. 07 -> 01 08 .. 11 -> 02 12 .. 15 -> 03 16 .. 19 -> 04 20 .. 23 -> 05 24 .. 27 -> 06 28 .. 31 -> 07 32 .. 35 -> 08 36 .. 39 -> 09 40 .. 43 -> 0A 44 .. -> 0B etc. When you look at the BIN, it becomes obvious what's happening: DEC (BIN) .. DEC (BIN) -> HEX (BIN) 00 ( 0) .. 03 ( 11) -> 00 ( 0) 04 ( 100) .. 07 ( 111) -> 01 ( 1) 08 ( 1000) .. 11 ( 1011) -> 02 ( 10) 12 ( 1100) .. 15 ( 1111) -> 03 ( 11) 16 (10000) .. 19 (10011) -> 04 ( 100) 20 (10100) .. 23 (10111) -> 05 ( 101) .. two bits at the end are truncated. It wouldn't surprise me if we found them somewhere in the other 'wrong numbers' ofthe original message. When I manipulate the numbers to come out correctly in MidiOX, my MPD 24 will happily accept the sysex and execute it so the probelm is definitely not MidiOx or Midiyoke. Questions 1) can anyone confirm this? 2) is anyone currently maintaining PortMidi, so this could maybe get fixed? thanks groovelastig ---------------------------------------------------------------------- >Comment By: Martin Peach (mrpeach) Date: 2010-06-03 00:43 Message: I get this too. You can put the 11 anywhere up to the seventh position and it transmits OK. The function winmm_write_byte() in pmwinmm.c doesn't get called for some of the message. This looks like a portmidi bug. (I think it would be better to buffer the whole sysex message at the Pd end and use portmidi's Pm_WriteSysEx() function to send it.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3010589&group_…

1 0

[ pure-data-Bugs-2952825 ] pd hangs in windows Vista and won't work until system reboot
by SourceForge.net 03 Jun '10

03 Jun '10

Bugs item #2952825, was opened at 2010-02-16 10:10 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2952825&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 >Status: Pending Resolution: Works For Me Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pd hangs in windows Vista and won't work until system reboot Initial Comment: Sometimes (unfortunately I haven't observed any apparent cause that triggers the problem), I open PD and it won't create a new patch (file/new) nor open any patch (file/open). It won't even quit untill I kill the process, and clicking on "DIO errors" doesn't produce any printout. Furthermore, all menus of the menu bar are empty (only a "--" item) except the File menu. Even if I kill and restart PD, it won't ever work, untill I reboot the operating system, then everything is fine. This is PD Vanilla 0.42.5 on Windows Vista. When it gets "frozen" like this, if I launch it with -lib Gem (I have Gem installed), it won't print the usual Gem output on the console (no output at all). After reboot, everything usually works. This happens every once in a while, and it is NOT necessary after some crash or anything. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-06-02 18:05 Message: I meant your particular install of Windows, like it wouldn't happen on another computer, or with a fresh install of Windows. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2010-06-02 04:09 Message: Hi, I didn't find any way to make it happen. It happens from time to time, not very often, when I start Pd. By windows install do you mean Windows itself, or pd-for-windows' install? I have never seen anything similar with any other program. When this happens, the interface doesn't _seem_ unresponsive at first sight: I mean, you can click on a menu and the menu drops down: but if you choose any item (for example File/New), nothing happens. Also if you click on "DIO Errors" the button does do the button-like "movement", but nothing is printed on the console. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-06-01 21:15 Message: Sounds to me like a problem with your windows install. Can you provide step-by-step instructions to make it happen everytime? ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2010-06-01 19:45 Message: It's not always acrotray.exe. It has happened to me that killing acrotray.exe didn't fix it and killing some other apparently random process did. And no, killing pd.exe does not fix it. When this happens, I have to kill random processes (well not actually random: I try to kill those that i know or guess that are useless or safe to kill) until I find one that works, I'm not sure whether killing other processes without _also_ restarting Pd works, because usually it goes as follows: - first I restart Pd, and it's frozen again - I close it, kill some process and open Pd again - and so on, until it works. Well, for this same reason maybe I didn't actually try killing pd.exe with the task manager, but I certainly did check the task manager to ensure there was no extra pd.exe process. Note that these freezings I'm talking about are ALWAYS at Pd startup: I start Pd and it's already frozen. It has never happened to me that it hangs like this (and won't recover afret restart). ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-06-01 17:40 Message: - try killing pd.exe in the Windows Task Manager, that has always done it for me - I haven't been able to reproduce this using recent builds of Pd-extended 0.42.5 on Windows XP and Windows 7. - otherwise, it sounds like some weirdness with acrotray is the issue ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2010-02-16 10:16 Message: I've just found out that killing the "acrotray.exe" process seems to fix the problem: after doing that, PD works fine. Acrotray is something related to Adobe Acrobat or Acrobat Reader. What relation it can have with PD is beyond my understanding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2952825&group_…

1 0

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 2010