Patches item #2984142, was opened at 2010-04-08 21:01
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2984142&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: externals
Group: documentation
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: IOhannes m zmlnig (zmoelnig)
Summary: canvasdelete-help.pd
Initial Comment:
Attached is a help patch for [canvasdelete] from iemguts.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2010-06-05 02:20
Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-05-21 17:34
Message:
you patch only documents a side-feature of [canvasdelete].
the real power of [canvasdelete] lies in deleting itself (and its parents)
without crashing Pd.
btw, you don't have to put a [canvasdelete] instance into a canvas that
you want to listen to "delete" messages.
once you have loaded canvasdelete (e.g. with "-lib canvasdelete") this
method is added to Pd's canvas-methods and can be used just like any other
dynamic patching message.
anyhow, i committed a help-patch based on yours with rev13567
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2984142&group_…
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_…
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_…
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_…
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_…
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_…