Bugs item #2050351, was opened at 2008-08-13 22:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2050351&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdp_opencv vs pdp_glx
Initial Comment:
pdp_opencv objects work fine with pdp_xv
pdp_opencv objects when used with pdp_glx give this error each frame (with no usable video output):
pdp_glx: packet is not a PDP_IMAGE
versions:
pd-0.41-4 miller/vanilla
pdp-0.12 fresh from pure-data svn today
pidip-0.12.23 fresh from pure-data svn today
pdp_opencv-0.1 fresh from pure-data svn today
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2050351&group_…
Bugs item #2049943, was opened at 2008-08-13 17:19
Message generated for change (Comment added) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2049943&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.40.2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: puredata sound glitch
Initial Comment:
I've recently downloaded Pure Data extended (0.40.3) on a PowerBook G4 with OS X (10.4.11) [thanks, it looks like a platform I can work] and intend to input/output on an M-audio fast track pro. However, when I play an audio patch or the test audio patch, I get this glitch that pulses at about 100 bpm. When I press DIO I get:
audio I/O error history:
seconds ago error type
3.14 unknown
3.14 unknown
3.14 unknown
If I press it again the numbers increase.
I don't how to fix. Please help.
-Joe
----------------------------------------------------------------------
Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2008-08-13 17:24
Message:
Logged In: YES
user_id=769033
Originator: NO
looks like a duplicate of this:
https://sourceforge.net/tracker/index.php?func=detail&aid=1561839&group_id=…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2049943&group_…
Bugs item #2049943, was opened at 2008-08-13 17:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2049943&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.40.2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: puredata sound glitch
Initial Comment:
I've recently downloaded Pure Data extended (0.40.3) on a PowerBook G4 with OS X (10.4.11) [thanks, it looks like a platform I can work] and intend to input/output on an M-audio fast track pro. However, when I play an audio patch or the test audio patch, I get this glitch that pulses at about 100 bpm. When I press DIO I get:
audio I/O error history:
seconds ago error type
3.14 unknown
3.14 unknown
3.14 unknown
If I press it again the numbers increase.
I don't how to fix. Please help.
-Joe
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2049943&group_…
hi all
i followed the README.cvs file included and when doing 'make' i get:
Making all in config
make[1]: Entering directory
`/home/roman/pd-svn/externals/moocow/pdstring/config'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/home/roman/pd-svn/externals/moocow/pdstring/config'
Making all in src
make[1]: Entering directory
`/home/roman/pd-svn/externals/moocow/pdstring/src'
make all-recursive
make[2]: Entering directory
`/home/roman/pd-svn/externals/moocow/pdstring/src'
make[3]: Entering directory
`/home/roman/pd-svn/externals/moocow/pdstring/src'
gcc pdstring.c -o pdstring
pdstring.c:41: error: expected ',' or ';' before 'PACKAGE_VERSION'
In file included from pdstring.c:62:
any2string.c:76: error: expected ',' or ';' before 'PACKAGE_VERSION'
In file included from pdstring.c:63:
string2any.c:59: error: expected ',' or ';' before 'PACKAGE_VERSION'
make[3]: *** [pdstring] Error 1
make[3]: Leaving directory
`/home/roman/pd-svn/externals/moocow/pdstring/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/roman/pd-svn/externals/moocow/pdstring/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/roman/pd-svn/externals/moocow/pdstring/src'
make: *** [all-recursive] Error 1
i am on ubuntu hardy i686, which uses comes with gcc version 4.2.3
roman
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Bugs item #2026159, was opened at 2008-07-23 21:36
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2026159&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.40.2
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Thomas Mayer (elvettsemic)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: update LAME packages from Debian Multimedia
Initial Comment:
As the Debian multimedia repositories (deb http://www.debian-multimedia.org lenny main) have switched from lame 3.97 to 3.98, the name of the library has changed as well from liblame0 to libmp3lame0. As the Debian packages of Pd-extended depend on that lib, pd-extended should do the switch as well.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-08-08 02:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
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: Hans-Christoph Steiner (eighthave)
Date: 2008-07-24 04:10
Message:
Logged In: YES
user_id=27104
Originator: NO
Ok, I updated debian-stable-i386, debian-stable-powerpc, and
debian-testing-i386 with the latest LAME packages from Debian Multimedia.
Ideally, this wouldn't be a strict dependency for installing, but rather a
"recommends" so people could install Pd-extended using the stock Debian
repositories.
Tomorrow's auto-build should have the updated dependency.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2026159&group_…
Bugs item #2021648, was opened at 2008-07-18 17:05
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2021648&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: None
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Federico Ferri (federico__)
Assigned to: IOhannes m zmlnig (zmoelnig)
Summary: zexy: configure.ac: $LDFLAGS in wrong place
Initial Comment:
line 425 of configure.ac:
LFLAGS=${LDFLAGS}
is wrong.
LDFLAGS are passed to gcc, not to ld.
I have in my LDFLAGS -Wl,-O1, which make ld fail.
ld should only see the -O1 option
make output:
i686-pc-linux-gnu-ld -shared --export-dynamic -Wl,-O1 -o zexy.pd_linux *.o -lm -lc
i686-pc-linux-gnu-ld: unrecognized option '-Wl,-O1'
i686-pc-linux-gnu-ld: use the --help option for usage information
make: *** [zexy] Error 1
please fix. (you can fix it by making an empty LFLAGS)
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-08-07 02:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
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: 2008-07-23 07:10
Message:
Logged In: YES
user_id=564396
Originator: NO
good that you have found a solution.
2 remarks:
- i kind of started to migrate the build-system from zexy/src/ to
zexy/build/autoconf/ and incorporated your changes there.
i suggest you just use this build-system from now on.
- i am not so sure whether using $(CC) as linker is truely portable; not
every compiler might be able to implicitely run a linker, like gcc.
if you feel unhappy with this solution (using build/autoconf/), just
re-open this ticket.
----------------------------------------------------------------------
Comment By: Federico Ferri (federico__)
Date: 2008-07-22 19:47
Message:
Logged In: YES
user_id=1628983
Originator: YES
so, finally, I managed to fix your problem.
replace $(LD) with $(CC) in Makefile and you are okay, there's no need of
transforming variables or such. here's the one-liner fix I use in the
Gentoo Ebuild:
sed -i -e 's/\$(LD)/\$(CC)/g' Makefile
you can always check here [1] how do I build externals. please notify me
when you commit this little fix, so I remove the fix from the ebuild.
[1]
http://pd-overlay.svn.sourceforge.net/viewvc/pd-overlay/pd-overlay/media-pl…
(actually Sf's ViewVC is down)
----------------------------------------------------------------------
Comment By: Federico Ferri (federico__)
Date: 2008-07-21 17:08
Message:
Logged In: YES
user_id=1628983
Originator: YES
hi IOhannes,
I'm not sure what you should do; the 'GNU Coding Standards' document
doesn't make mention of this (I generally look-up there things when I'm in
doubt).
As I explained, the $(LDFLAGS) has to be passed to gcc, not to ld.
For example, if you have -Wl,--as-needed in $LDFLAGS, the ld program only
wants to see --as-needed.
There are two options:
1) [PROBABLY BAD] if you want to pass $LDFLAGS directly to linker, you
have to turn the "-Wl,--flag1,--flag2" option into "--flag1 --flag2".
I don't see a handy way to do it.
2) use gcc to do the linking.
please read this excerpt from `man ld`:
------------------------------------------------------------------------------
Note---if the linker is being invoked indirectly, via a compiler
driver
(e.g. gcc) then all the linker command line options should be
prefixed
by -Wl, (or whatever is appropriate for the particular compiler
driver)
like this:
gcc -Wl,--startgroup foo.o bar.o -Wl,--endgroup
This is important, because otherwise the compiler driver program
may
silently drop the linker options, resulting in a bad link.
------------------------------------------------------------------------------
also, beware that using a LFLAGS in Makefile could give you weird results,
since LFLAGS are the Lex-flags (that's not your case, since configure is
just a shell script, but just to inform you ;)
so, in my opinion, you should use $(CC) to link objects.
now I'm asking to some people on IRC but still didn't get a reply. if I'll
eventually get a better answer I'll add a comment here.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-07-21 13:29
Message:
Logged In: YES
user_id=564396
Originator: NO
do you have any reference tpo the correct use of LFLAGS vs LDFLAGS?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2021648&group_…
Bugs item #1577739, was opened at 2006-10-15 20:42
Message generated for change (Comment added) made by fbar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1577739&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: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Frank Barknecht (fbar)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Malformed data at end of patch is treated as sender
Initial Comment:
When opening a patch file Pd doesn't check correctly if
all messages are well-formed. Inserting a line at end
of a patch file, that starts with a symbol and ends
with a ";" will treat the leading symbol as a
receive-target and will send the rest of the line to
that receiver.
For example inserting:
pd dsp 1;
at the end of a patch will switch on audio, even when
the patch is started with "pd -noloadbang".
While this message is harmless, other messages may do
nasty things and open a security hole.
Attached is a patch that illustrates this behaviour,
also see this pd-list message thread:
http://lists.puredata.info/pipermail/pd-list/2006-10/043161.html
----------------------------------------------------------------------
>Comment By: Frank Barknecht (fbar)
Date: 2008-08-05 13:41
Message:
Logged In: YES
user_id=569446
Originator: YES
I see. Okay, I think, then we can savely mark this report as invalid and
close it.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-05 09:57
Message:
Logged In: YES
user_id=564396
Originator: NO
i think there is a clarification needed:
the behaviour you are expecting is _not_ limited to the end of patch
(EOP).
it can just occur anywhere within the patch:
the reason is simple: in reality the "#X" is really just a receiver where
the objectmaker is bound to: it does receives messages from the patch, just
like in your example.
and of course there is a well known example in Pd itself that uses this
mechanism: array!
the "#A" is really just a receiver that is bound to the latest created
array (you can check by creating a new array "foo" and then send a message
[; #A 0 10 20 30 40 50()
when storing a patch, the array will just dump it's data in a form that it
is able to receive.
when reading the patch, the array is bound to the #A and receives the data
it has previously dumped.
ftm does it very similar.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2008-08-05 09:46
Message:
Logged In: YES
user_id=569446
Originator: YES
I didn't know about or think of this use case, which definitely is
interesting.
Some more questions: You write "if objects forget about these messages it
is rather broken objects ..." I thought, Pd itself forgets the data at the
end, not certain objects in Pd or am I wrong?
Then: Currently it seems, only FTM uses the space at the end of a patch
("EOP"?) to store additional data. I didn't yet check how FTM does this,
but what if other objects also start using the EOP-data? Could this lead to
conflicts where one object overwrites data of another object? I think, with
Pd's traditional way of storing data in #-lines, this generally cannot
happen.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-04 19:44
Message:
Logged In: YES
user_id=564396
Originator: NO
even if matju thinks you can use [loadbang] for these kind of things, he
might be wrong here.
the sent messages are sent immediately (even before a hypothetic
[initbang] message!), whereas the loadbang is delayed rather long. (as we
all now)
as claude has pointed out, the "freer than max" talk should show (i hope)
that you can really do cool things with this additional data, which you
could not do with any other "elegant" method i know.
if objects forget about these messages it is rather broken objects than a
bug in Pd.
(e.g. the FTM-objects happily save (and recall) the data via this
send-"hack")
----------------------------------------------------------------------
Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2008-08-04 19:18
Message:
Logged In: YES
user_id=769033
Originator: NO
I think it is a feature too - if I recall correctly, the "Freer Than Max:
Porting FTM to Pure-data" presentation at LAC showed that externals can
save additional data to a Pd patch, using precisely this feature to
re-access it on load.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2008-08-04 19:01
Message:
Logged In: YES
user_id=569446
Originator: YES
But as a feature it is rather broken, because the data at the end of the
file is deleted if you save the patch from Pd. And even the feature can be
build in Pd itself with a loadbang'd semicolon-message box, as matju
pointed out here:
http://lists.puredata.info/pipermail/pd-list/2006-10/043171.html
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-04 18:45
Message:
Logged In: YES
user_id=564396
Originator: NO
i think this is a feature
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1577739&group_…
Bugs item #1577739, was opened at 2006-10-15 20:42
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1577739&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Frank Barknecht (fbar)
Assigned to: Miller Puckette (millerpuckette)
Summary: Malformed data at end of patch is treated as sender
Initial Comment:
When opening a patch file Pd doesn't check correctly if
all messages are well-formed. Inserting a line at end
of a patch file, that starts with a symbol and ends
with a ";" will treat the leading symbol as a
receive-target and will send the rest of the line to
that receiver.
For example inserting:
pd dsp 1;
at the end of a patch will switch on audio, even when
the patch is started with "pd -noloadbang".
While this message is harmless, other messages may do
nasty things and open a security hole.
Attached is a patch that illustrates this behaviour,
also see this pd-list message thread:
http://lists.puredata.info/pipermail/pd-list/2006-10/043161.html
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-05 09:57
Message:
Logged In: YES
user_id=564396
Originator: NO
i think there is a clarification needed:
the behaviour you are expecting is _not_ limited to the end of patch
(EOP).
it can just occur anywhere within the patch:
the reason is simple: in reality the "#X" is really just a receiver where
the objectmaker is bound to: it does receives messages from the patch, just
like in your example.
and of course there is a well known example in Pd itself that uses this
mechanism: array!
the "#A" is really just a receiver that is bound to the latest created
array (you can check by creating a new array "foo" and then send a message
[; #A 0 10 20 30 40 50()
when storing a patch, the array will just dump it's data in a form that it
is able to receive.
when reading the patch, the array is bound to the #A and receives the data
it has previously dumped.
ftm does it very similar.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2008-08-05 09:46
Message:
Logged In: YES
user_id=569446
Originator: YES
I didn't know about or think of this use case, which definitely is
interesting.
Some more questions: You write "if objects forget about these messages it
is rather broken objects ..." I thought, Pd itself forgets the data at the
end, not certain objects in Pd or am I wrong?
Then: Currently it seems, only FTM uses the space at the end of a patch
("EOP"?) to store additional data. I didn't yet check how FTM does this,
but what if other objects also start using the EOP-data? Could this lead to
conflicts where one object overwrites data of another object? I think, with
Pd's traditional way of storing data in #-lines, this generally cannot
happen.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-04 19:44
Message:
Logged In: YES
user_id=564396
Originator: NO
even if matju thinks you can use [loadbang] for these kind of things, he
might be wrong here.
the sent messages are sent immediately (even before a hypothetic
[initbang] message!), whereas the loadbang is delayed rather long. (as we
all now)
as claude has pointed out, the "freer than max" talk should show (i hope)
that you can really do cool things with this additional data, which you
could not do with any other "elegant" method i know.
if objects forget about these messages it is rather broken objects than a
bug in Pd.
(e.g. the FTM-objects happily save (and recall) the data via this
send-"hack")
----------------------------------------------------------------------
Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2008-08-04 19:18
Message:
Logged In: YES
user_id=769033
Originator: NO
I think it is a feature too - if I recall correctly, the "Freer Than Max:
Porting FTM to Pure-data" presentation at LAC showed that externals can
save additional data to a Pd patch, using precisely this feature to
re-access it on load.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2008-08-04 19:01
Message:
Logged In: YES
user_id=569446
Originator: YES
But as a feature it is rather broken, because the data at the end of the
file is deleted if you save the patch from Pd. And even the feature can be
build in Pd itself with a loadbang'd semicolon-message box, as matju
pointed out here:
http://lists.puredata.info/pipermail/pd-list/2006-10/043171.html
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-04 18:45
Message:
Logged In: YES
user_id=564396
Originator: NO
i think this is a feature
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1577739&group_…
Bugs item #1577739, was opened at 2006-10-15 20:42
Message generated for change (Comment added) made by fbar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1577739&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Frank Barknecht (fbar)
Assigned to: Miller Puckette (millerpuckette)
Summary: Malformed data at end of patch is treated as sender
Initial Comment:
When opening a patch file Pd doesn't check correctly if
all messages are well-formed. Inserting a line at end
of a patch file, that starts with a symbol and ends
with a ";" will treat the leading symbol as a
receive-target and will send the rest of the line to
that receiver.
For example inserting:
pd dsp 1;
at the end of a patch will switch on audio, even when
the patch is started with "pd -noloadbang".
While this message is harmless, other messages may do
nasty things and open a security hole.
Attached is a patch that illustrates this behaviour,
also see this pd-list message thread:
http://lists.puredata.info/pipermail/pd-list/2006-10/043161.html
----------------------------------------------------------------------
>Comment By: Frank Barknecht (fbar)
Date: 2008-08-05 09:46
Message:
Logged In: YES
user_id=569446
Originator: YES
I didn't know about or think of this use case, which definitely is
interesting.
Some more questions: You write "if objects forget about these messages it
is rather broken objects ..." I thought, Pd itself forgets the data at the
end, not certain objects in Pd or am I wrong?
Then: Currently it seems, only FTM uses the space at the end of a patch
("EOP"?) to store additional data. I didn't yet check how FTM does this,
but what if other objects also start using the EOP-data? Could this lead to
conflicts where one object overwrites data of another object? I think, with
Pd's traditional way of storing data in #-lines, this generally cannot
happen.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-04 19:44
Message:
Logged In: YES
user_id=564396
Originator: NO
even if matju thinks you can use [loadbang] for these kind of things, he
might be wrong here.
the sent messages are sent immediately (even before a hypothetic
[initbang] message!), whereas the loadbang is delayed rather long. (as we
all now)
as claude has pointed out, the "freer than max" talk should show (i hope)
that you can really do cool things with this additional data, which you
could not do with any other "elegant" method i know.
if objects forget about these messages it is rather broken objects than a
bug in Pd.
(e.g. the FTM-objects happily save (and recall) the data via this
send-"hack")
----------------------------------------------------------------------
Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2008-08-04 19:18
Message:
Logged In: YES
user_id=769033
Originator: NO
I think it is a feature too - if I recall correctly, the "Freer Than Max:
Porting FTM to Pure-data" presentation at LAC showed that externals can
save additional data to a Pd patch, using precisely this feature to
re-access it on load.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2008-08-04 19:01
Message:
Logged In: YES
user_id=569446
Originator: YES
But as a feature it is rather broken, because the data at the end of the
file is deleted if you save the patch from Pd. And even the feature can be
build in Pd itself with a loadbang'd semicolon-message box, as matju
pointed out here:
http://lists.puredata.info/pipermail/pd-list/2006-10/043171.html
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-04 18:45
Message:
Logged In: YES
user_id=564396
Originator: NO
i think this is a feature
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1577739&group_…
Bugs item #1577739, was opened at 2006-10-15 20:42
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1577739&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Frank Barknecht (fbar)
Assigned to: Miller Puckette (millerpuckette)
Summary: Malformed data at end of patch is treated as sender
Initial Comment:
When opening a patch file Pd doesn't check correctly if
all messages are well-formed. Inserting a line at end
of a patch file, that starts with a symbol and ends
with a ";" will treat the leading symbol as a
receive-target and will send the rest of the line to
that receiver.
For example inserting:
pd dsp 1;
at the end of a patch will switch on audio, even when
the patch is started with "pd -noloadbang".
While this message is harmless, other messages may do
nasty things and open a security hole.
Attached is a patch that illustrates this behaviour,
also see this pd-list message thread:
http://lists.puredata.info/pipermail/pd-list/2006-10/043161.html
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-04 19:44
Message:
Logged In: YES
user_id=564396
Originator: NO
even if matju thinks you can use [loadbang] for these kind of things, he
might be wrong here.
the sent messages are sent immediately (even before a hypothetic
[initbang] message!), whereas the loadbang is delayed rather long. (as we
all now)
as claude has pointed out, the "freer than max" talk should show (i hope)
that you can really do cool things with this additional data, which you
could not do with any other "elegant" method i know.
if objects forget about these messages it is rather broken objects than a
bug in Pd.
(e.g. the FTM-objects happily save (and recall) the data via this
send-"hack")
----------------------------------------------------------------------
Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2008-08-04 19:18
Message:
Logged In: YES
user_id=769033
Originator: NO
I think it is a feature too - if I recall correctly, the "Freer Than Max:
Porting FTM to Pure-data" presentation at LAC showed that externals can
save additional data to a Pd patch, using precisely this feature to
re-access it on load.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2008-08-04 19:01
Message:
Logged In: YES
user_id=569446
Originator: YES
But as a feature it is rather broken, because the data at the end of the
file is deleted if you save the patch from Pd. And even the feature can be
build in Pd itself with a loadbang'd semicolon-message box, as matju
pointed out here:
http://lists.puredata.info/pipermail/pd-list/2006-10/043171.html
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-04 18:45
Message:
Logged In: YES
user_id=564396
Originator: NO
i think this is a feature
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1577739&group_…