Re: [PD-dev] oggread~ not working on pd-extended or libpd on windows.
I think vanilla is compiled with MSVC and extended with MinGW so there
are incompatibilities in the c runtime especially where file pointers
are concerned. Sometimes externals will work on both versions but if the
external opens its own files using Pd functions to find the path then it
probably won't.
Martin
On 2014-04-05 11:36, Rafael Vega wrote:
I also find it strange that using the external on pd-vanilla by copying
the dll to the extra folder in the vanilla directory works fine. Any
ideas why? Maybe has something to do with compiler environment
differences between vanilla and extended? Do you guys use MinGW for both?
On Sat, Apr 5, 2014 at 10:34 AM, Rafael Vega email.r...@gmail.com
mailto:email.r...@gmail.com wrote:
Hi Miller,
On my windows machines (XP and 8.1), if I tried to open with mode
'r', the later call to ov_open would fail. If I change the mode to
'rb', the later call to ov_open works fine. I also read somewhere
that the 'b' mode does nothing on Unix (I still have to test that
when I'm back to my Linux and Mac machines).
As for the comparison against NULL, the original code was comparing
if((x-x_file = sys_fopen(filename-s_name, r)) 0)
And I changed it to = instead. You are right in that it makes no
sense to compare the sign of a pointer so == it is :)
R.
On Sat, Apr 5, 2014 at 9:03 AM, Miller Puckette m...@ucsd.edu
mailto:m...@ucsd.edu wrote:
I THink it should really be:
if((x-x_file = sys_fopen(filename-s_name, r)) == 0)
sys_fopen returns NULL (also known as 0) on failure, otherwise a
pointer;
it makes no sense to check the sign of a pointer as far as I know.
cheers
Miller
On Fri, Apr 04, 2014 at 11:21:37PM -0400, Martin Peach wrote:
I think it's here:
http://sourceforge.net/p/pure-data/patches/
Martin
On 2014-04-04 21:49, Rafael Vega wrote:
Even more stuff ;)
In the same file, oggread~.c there is a line that reads:
if((x-x_file = sys_fopen(filename-s_name, r)) 0)
But it should be:
if((x-x_file = sys_fopen(filename-s_name, rb)) = 0)
Now, to figure out how to submit a patch to pd-extended :P
On Fri, Apr 4, 2014 at 7:22 PM, Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
mailto:email.r...@gmail.com mailto:email.r...@gmail.com
wrote:
Follow up:
Looking at the code for oggread~, I found that it does
the actual
opening of the file with
if(ov_open(x-x_file, x-x_ov, NULL, -1) 0)
on the ov_open documentation it warns windows
programmers not to use
ov_open but ov_open_callbacks instead [1] and [2] so I
changed that
line to the following and I'm getting the message
Bitstream does
not contain any Vorbis data. I'm pretty sure my file is
a valid ogg
file. I created it using audacity and also tried with an
ogg file
downloaded from freesound.org http://freesound.org
http://freesound.org.
Any help with this will be very much appreciated
:)
int ret = ov_open_callbacks(x-x_file,
x-x_ov, NULL, -1,
OV_CALLBACKS_DEFAULT);
switch(ret){
case OV_EREAD:
post(A read from media returned an
error.);
break;
case OV_ENOTVORBIS:
post(Bitstream does not contain any
Vorbis data);
break;
case OV_EVERSION:
post(OV_EVERSION - Vorbis version
mismatch.);
break;
case OV_EBADHEADER:
post(Invalid Vorbis bitstream header.);
break;
case OV_EFAULT:
post(Internal logic fault; indicates a
bug or
heap/stack corruption.);
break;
}
if(ret 0)
links:
[1]
http://xiph.org/vorbis/doc/vorbisfile/ov_open_callbacks.html
[2] http://xiph.org/vorbis/doc/vorbisfile/ov_open.html
On Fri, Apr 4, 2014 at 5:48 PM, Rafael Vega
email.r...@gmail.com mailto:email.r
Re: [PD-dev] oggread~ not working on pd-extended or libpd on windows.
I think it's here:
http://sourceforge.net/p/pure-data/patches/
Martin
On 2014-04-04 21:49, Rafael Vega wrote:
Even more stuff ;)
In the same file, oggread~.c there is a line that reads:
if((x-x_file = sys_fopen(filename-s_name, r)) 0)
But it should be:
if((x-x_file = sys_fopen(filename-s_name, rb)) = 0)
Now, to figure out how to submit a patch to pd-extended :P
On Fri, Apr 4, 2014 at 7:22 PM, Rafael Vega email.r...@gmail.com
mailto:email.r...@gmail.com wrote:
Follow up:
Looking at the code for oggread~, I found that it does the actual
opening of the file with
if(ov_open(x-x_file, x-x_ov, NULL, -1) 0)
on the ov_open documentation it warns windows programmers not to use
ov_open but ov_open_callbacks instead [1] and [2] so I changed that
line to the following and I'm getting the message Bitstream does
not contain any Vorbis data. I'm pretty sure my file is a valid ogg
file. I created it using audacity and also tried with an ogg file
downloaded from freesound.org http://freesound.org.
Any help with this will be very much appreciated
:)
int ret = ov_open_callbacks(x-x_file, x-x_ov, NULL, -1,
OV_CALLBACKS_DEFAULT);
switch(ret){
case OV_EREAD:
post(A read from media returned an error.);
break;
case OV_ENOTVORBIS:
post(Bitstream does not contain any Vorbis data);
break;
case OV_EVERSION:
post(OV_EVERSION - Vorbis version mismatch.);
break;
case OV_EBADHEADER:
post(Invalid Vorbis bitstream header.);
break;
case OV_EFAULT:
post(Internal logic fault; indicates a bug or
heap/stack corruption.);
break;
}
if(ret 0)
links:
[1] http://xiph.org/vorbis/doc/vorbisfile/ov_open_callbacks.html
[2] http://xiph.org/vorbis/doc/vorbisfile/ov_open.html
On Fri, Apr 4, 2014 at 5:48 PM, Rafael Vega email.r...@gmail.com
mailto:email.r...@gmail.com wrote:
Hi.
I am trying to use [oggread~] external on an application i'm
developing with libpd. No problems on mac or linux. Howerver, on
windows (xp and 8, 32bit) I keep getting an error message from
oggread~ when I try to open an ogg file. Even ogg_read~-help.pd
won't work:
oggread~: file C:/Users/rv/any.ogg opened
oggread~: error: could not open C:/Users/rv/Desktop/any.ogg as
an OggVorbis file
oggread~: file closed due to error
I have tried pd-extended (both installer and standalone) and I
also compiled oggread~ into my application and loaded it with
libpd, same outcome.
The weirdest part is that if I run pd vanilla, copy oggread~.dll
from pd-extended into the extra directory, the ogg files are
opened correctly.
Any ideas on how to make this work? What kind of debug info can
I provide?
--
Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
--
Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
--
Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Requesting SVN commit access
Yes I'd be happy to include anything that works better in mrpeach/net. I'm curious as to what is special about the Behringer X32 that makes it hard to communicate with the existing externals. Martin On 2014-02-25 12:53, Jonathan Wilkes wrote: Hi Dennis, I'm not sure who has the keys to the kingdom here. But at far as the update for Martin's library you can just contact him directly (along with any documentation that explains your changes). Then he can push the updates himself. Generally that's the process for updates to preexisting libraries. Of course you can also get svn access to add your own library for other things. Best, Jonathan On Tuesday, February 25, 2014 10:29 AM, Dennis Engdahl engd...@snowcrest.net wrote: To the list members: My name is Dennis Engdahl. I have been developing computer programs since the days of the keypunch (and paper tape), and have taught computer science at the college level for 20 years. I am now retired, and have started an internet providing company which my sons now run. I am an expert at communications software (TCP/IP, etc.), and am interested in pd to communicate with my church's new Behringer X32. Since the UDP routines Martin Peach wrote are not able to receive data successfully from the X32, I researched the problem and created a new routine which will communicate. If you're interested in the details, you can either look at my source, or pm me. At this time, I would like to commit this routine (udpsndrcv.c) and its help file to Martin's area, to allow others to communicate with hardware with the same requirements as the X32. I am interested also in the audio aspects of pd, and may be developing other routines to help out in the future. Please allow me SVN commit access to be able to accomplish this. Thank you, Dennis Engdahl engd...@snowcrest.net mailto:engd...@snowcrest.net (530) 926-2996 ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Requesting SVN commit access
Hi Dennis, I didn't see any attachments to previous emails from you. I think that sending and receiving on the same port is not an intended use of the UDP protocol, which was designed for throw and forget messaging. It makes more sense to do this with TCP, which maintains a two-way connection. Can you connect to the X32 with TCP? Anyway, I'd like to see what you did. Martin On 2014-02-25 21:02, Dennis Engdahl wrote: Martin: I hope you received my previous e-mail with the attachment. If not, please let me know. The X32 responds to commands by sending the response to the IP and port from which it received the command. These are the problems with the present approach which my routine solves: 1. The from port used while sending a command is assigned by the system, and is not reported to the user. Therefore, the user has no way to set up a listener on that port to receive the X32's response. 2. Even if we modify the existing routines to allow the user to specify the from port, after doing so, the same port cannot be used again to set up udpreceive. The system returns an in use error when trying to do so. In Winsock, the from IP, from port, to IP, and to port must be unique for a connection to be set up. Since the user is specifying the from port, to IP, and to port, and since the from IP is static, only one connection can be set up at a time. Both udpsend and udpreceive try to set up a connection. If the from port is static, the second connection fails. My routine allows the setting of the from port. Then, my routine only sets up one connection, and sends and receives on that one connection. Since the user is specifying the from port, more than one connection can be established (by more than one patch) by specifying different (known) ports (see the help page for my routine.) Thank you for your response, Martin. I am more than willing for you to take over the routine if you wish, or to solve this another way if you wish. I just wish to communicate with the X32. Sincerely, Dennis Engdahl engd...@snowcrest.net (530) 926-2996 On Tue, 25 Feb 2014, Martin Peach wrote: Date: Tue, 25 Feb 2014 12:58:57 -0500 From: Martin Peach martin.pe...@sympatico.ca To: Jonathan Wilkes jancs...@yahoo.com, Dennis Engdahl engd...@snowcrest.net, pd-dev@iem.at pd-dev@iem.at Subject: Re: [PD-dev] Requesting SVN commit access Yes I'd be happy to include anything that works better in mrpeach/net. I'm curious as to what is special about the Behringer X32 that makes it hard to communicate with the existing externals. Martin On 2014-02-25 12:53, Jonathan Wilkes wrote: Hi Dennis, I'm not sure who has the keys to the kingdom here. But at far as the update for Martin's library you can just contact him directly (along with any documentation that explains your changes). Then he can push the updates himself. Generally that's the process for updates to preexisting libraries. Of course you can also get svn access to add your own library for other things. Best, Jonathan On Tuesday, February 25, 2014 10:29 AM, Dennis Engdahl engd...@snowcrest.net wrote: To the list members: My name is Dennis Engdahl. I have been developing computer programs since the days of the keypunch (and paper tape), and have taught computer science at the college level for 20 years. I am now retired, and have started an internet providing company which my sons now run. I am an expert at communications software (TCP/IP, etc.), and am interested in pd to communicate with my church's new Behringer X32. Since the UDP routines Martin Peach wrote are not able to receive data successfully from the X32, I researched the problem and created a new routine which will communicate. If you're interested in the details, you can either look at my source, or pm me. At this time, I would like to commit this routine (udpsndrcv.c) and its help file to Martin's area, to allow others to communicate with hardware with the same requirements as the X32. I am interested also in the audio aspects of pd, and may be developing other routines to help out in the future. Please allow me SVN commit access to be able to accomplish this. Thank you, Dennis Engdahl engd...@snowcrest.net mailto:engd...@snowcrest.net (530) 926-2996 ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [pure-data:bugs] #1116 autobuild wrong architecture for i386
--- ** [bugs:#1116] autobuild wrong architecture for i386** **Status:** open **Created:** Fri Oct 04, 2013 07:09 PM UTC by Martin Peach **Last Updated:** Fri Oct 04, 2013 07:09 PM UTC **Owner:** Hans-Christoph Steiner On Debian squeeze with dual-P4 CPU I get: $ sudo dpkg -i Pd-0.44.0-extended-20131003-debian-squeeze-i386.deb dpkg: error processing Pd-0.44.0-extended-20131003-debian-squeeze-i386.deb (--install): package architecture (amd64) does not match system (i386) Errors were encountered while processing: Pd-0.44.0-extended-20131003-debian-squeeze-i386.deb --- Sent from sourceforge.net because pd-...@lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SIGPIPE on iemnet's tcpserver
On 2013-07-03 06:37, Antoine Villeret wrote: Hi Martin, thanks for that, but I don't know how many clients there are so it's quite difficult to figure out port number in this case. My problem is that I can't listen several time on the same port with [udpreceive] but with multicasting, that's why I switched to [udpserver]. Not sure what you want to do here. Do you want several [udpreceive]s listening to the same port, or a single [udpreceive] that listens on multiple ports, or a single [udpreceive] that listens on the same port for messages from multiple sources? Or something else... Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SIGPIPE on iemnet's tcpserver
Well [udpreceive] should be able to receive from many different senders, no? (It's a bug if not...) Based on what the [udpreceive] receives, route your replies to one or more [udpsend]s based on info in the incoming packets, or set the port of a single [udpsend] before sending. UDP is connectionless, it doesn't know or care if the other end exists. Martin On 2013-07-03 11:33, Antoine Villeret wrote: thanks for that, in fact, some of my clients need the same infos and this is why I first try to do multicasting but reaching multiple clients on the same host is different than addressing one packet to different hosts... for now all my clients try to connect around each 10 second to server to query some infos and to update their state but I could guarantee that only one client will try to connect at a time so it could be difficult to use a server which doesn't accept more than one connection... or maybe i'm wrong and there is another solution, not based on networking ? -- do it yourself http://antoine.villeret.free.fr 2013/7/3 IOhannes m zmoelnig zmoel...@iem.at mailto:zmoel...@iem.at -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-03 12:37, Antoine Villeret wrote: that's why I switched to [udpserver]. i guess you meant [tcpserver] instead of [udpserver]. in any case, i'm thinking about removing the multi-client feature of iemnet's [udpserver], so you could only send replies to the *last* client that connected. the idea is, that you could use it as a server that can be queried by clients (in a ping/pong sort of ways: the clients sends a query packet and is immediately answered with an answer packet), similarily to DNS. maintaining a number of connections is simply impossible with a connectionless protocol. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHUMTUACgkQkX2Xpv6ydvQMpQCeOx09OJYP3LszFo39rqGjjYoL l5gAoN5Y6sdSXR06w4hBSw2+WZKGS6HH =WJYl -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SIGPIPE on iemnet's tcpserver
On 2013-07-02 14:38, Antoine Villeret wrote: all of this is quite complex for a not so difficult task : I want to make several instance of Pd talking to each other on one machine I started with udpsend/udpreceive but I found no way to do broadcast on localhost and I do need to have lots of clients You don't need to broadcast on a single machine, just use different port numbers. You can send to several ports with several [udpsend]s. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] shared class data and functions
On 2012-11-14 02:17, Jonathan Wilkes wrote:
I have three classes:
foo, bar, bow
Foo has a function:
void foo_blah(t_foo *x, t_symbol *s, t_int argc, t_atom *argv)
{
if(x-x_member == 1) do_something...
}
Bar and bow both have x-x_member, too, and I want all three
to use the same function so I don't have to copy it two more times.
Is there a way to do this:
void foo_blah(t_pd *x, t_symbol *s, t_int argc, t_atom *argv)
{
if we can cast x to t_foo, t_bar or t_bow then
check if x has x-member equal to 1, and if so then do_something...
}
which I can call by sending t_foo, t_bar or t_bow as the first
arg to that function?
It seems like I should be able to do this but I can't figure out all the
pointer bs.
Something like (t_foo *)x-member, or ((t_bar *)x)-member?
Martin
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] string2any doesn't create in mrpeach/tcpsocketserver-help.pd
On 2012-03-21 17:20, Roman Haefeli wrote: On Wed, 2012-03-21 at 22:13 +0100, Roman Haefeli wrote: On Wed, 2012-03-21 at 15:26 -0400, Hans-Christoph Steiner wrote: Hey Martin, Hey Hans Sorry to chime in, but I wrote that particular abstraction. I just ran the load_every_help.py test script on Pd-extended 0.43 and saw this: loading: /Applications/Pd-0.43.1-extended-20120310.app/Contents/Resources/extra/mrpeach/tcpsocketserver-help.pd declare: declare: unknown declaration declare: declare: unknown declaration tcpserver listening on port 2468 verbose(3): tcpclient: (GPL) 2003 Martin Peach, compiled for pd-0.43 on Mar 10 2012 04:07:08 any2string 0 -1 error: ... couldn't create string2any 0 59 error: ... couldn't create tcpserver listening on port 11001 string2any 0 59 error: ... couldn't create tcpserver listening on port 11002 slipdec: maximum packet length is 65536 slipdec: maximum packet length is 65536 slipenc: maximum packet length is 65536 slipenc: maximum packet length is 65536 Should be fixed with r16087. Thanks for checking! It seems Martin preferred [import] over [declare] and fixed it as well. Yes, [declare] didn't work for me. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] string2any doesn't create in mrpeach/tcpsocketserver-help.pd
On 2012-03-21 17:39, Roman Haefeli wrote: On Wed, 2012-03-21 at 17:25 -0400, Martin Peach wrote: On 2012-03-21 17:20, Roman Haefeli wrote: On Wed, 2012-03-21 at 22:13 +0100, Roman Haefeli wrote: On Wed, 2012-03-21 at 15:26 -0400, Hans-Christoph Steiner wrote: Hey Martin, Hey Hans Sorry to chime in, but I wrote that particular abstraction. I just ran the load_every_help.py test script on Pd-extended 0.43 and saw this: loading: /Applications/Pd-0.43.1-extended-20120310.app/Contents/Resources/extra/mrpeach/tcpsocketserver-help.pd declare: declare: unknown declaration declare: declare: unknown declaration tcpserver listening on port 2468 verbose(3): tcpclient: (GPL) 2003 Martin Peach, compiled for pd-0.43 on Mar 10 2012 04:07:08 any2string 0 -1 error: ... couldn't create string2any 0 59 error: ... couldn't create tcpserver listening on port 11001 string2any 0 59 error: ... couldn't create tcpserver listening on port 11002 slipdec: maximum packet length is 65536 slipdec: maximum packet length is 65536 slipenc: maximum packet length is 65536 slipenc: maximum packet length is 65536 Should be fixed with r16087. Thanks for checking! It seems Martin preferred [import] over [declare] and fixed it as well. Yes, [declare] didn't work for me. [declare -stdpath extra/moocow] from my commit just a few minutes ago did work. The problem was not [declare], but a wrong declaration. Back when the help patch was written, moocows stuff was automatically loaded in Pd-extended and I only added the [declare -stdlib extra/pdstring] to make the help-patch work on Pd-vanilla installations. Now, since pdstring stuff is not automatically loaded anymore, the first mentioned [declare] was necessary. In Pd-extended, one can also use [import moocow] which does exactly the same, but might break in Pd-vanilla installations where [import] is not installed. Ah I see. Maybe you should revert it to your fix. I didn't realize you were working on it as well. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] float handling in [binfile] for UTF-8 handling
On 2012-01-31 03:41, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-01-31 00:52, Hans-Christoph Steiner wrote: That does make more sense, so something like [bytes2utf8], etc. utf8 is always a list of bytes. if you get values255 than it is not utf-8; do you mean unicode points? The same idea could be used for unicode, converting pairs of bytes into single numbers, taking care of endianness. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] float handling in [binfile] for UTF-8 handling
On 2012-01-30 17:45, Hans-Christoph Steiner wrote: The current pdstring format of lists of bytes seems to be working out pretty well. I just had a thought, it would be nice to be able to write Unicode text out as UTF-8 files using [binfile]. I think currently it only accepts byte values of 0-255. What if it converted values 255 in the UTF-8 style? Or should that be a separate [utf8file]? I suppose the advantage of [utf8file] would be to make an easy conversion to [utf16file] and [utf32file]. [binfile] can work with any kind of file. It seems simpler to have filters that could convert between lists of bytes and lists of utf character codes, the way [slipenc] and [slipdec] will operate on any stream of bytes. Then they wouldn't be tied to [binfile], and binfile wouldn't get all bloated with obscure variations. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] pd at startup creates 2 canvases, why?
On 2011-12-11 12:14, Ivica Ico Bukvic wrote: They contain templates for arrays. [; pd-_float vis 1; pd-_float_array vis 1 ( More interestingly, it does not do canvas_free for those two instances when closing pd, suggesting this is a memory leak. So, what gives? Why does it create 2 invisible canvases, what is their function, and how do they differentiate from the regular canvases. They aren't listed in the Window menu. But like any other canvas, you can send them objects and messages: [; pd-_float obj 20 20 keyname, obj 20 80 print all_your_keys_are_belongs_to_us, connect 1 1 2 0 ( OK, so that explains why they are created. However, this does not answer the question why they are not being destroyed when exiting pd. Neither canvas_free nor glist_free are triggered when quitting pd, so this must be a memory leak, no? The OS releases all the memory allocated by the process when it terminates, so no. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help compiling pd 0.43 on Windows 7
On 2011-11-28 12:37, Hans-Christoph Steiner wrote: I think Miller doesn't use MinGW, so building vanilla on Windows is probably easiest using MSVC like he does. Pd-extended builds nightly (when the server is up) using the pd/src/makefile.mingw. It seems like the latest Windows nightly build is from November 3 and after November 4 there are not even any logs... Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding an Open method to pdlua and tclpd
On 2011-10-27 19:07, Hans-Christoph Steiner wrote: It would be really awesome if you could edit the file and have the object automatically updated. That would be a lot harder. I suppose using the file alteration monitor stuff in GNU/Linux and Mac OS X, you could efficiently get notification whether the file changed, but polling might not be so bad. I guess the hard part would be re-registering the object with Pd. If the editor could send back to Pd the name of the file that was saved it would be much easier. For now you could just save it under a new name and make one of those. Also the [pdluax] object loads its script each time it's instantiated so you can use the same name, although you still need to make a new object on the canvas. OTOH dynamically changing the inlet/outlet count of an object especially when there are more than one in a patch would seem to guarantee crashing of Pd. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding an Open method to pdlua and tclpd
On 2011-10-12 12:43, Hans-Christoph Steiner wrote:
Now that pdlua and tclpd are officially part of Pd-extended, I just had
a little thought/feature request to make working with those objects
easier. It would be very nice if you could right-click on the object,
and click Open and have Pd open the script file in the associated
editor. You can do this on all platforms using:
::pd_menucommands::menu_openfile {filename}
Or at least use that as example code for how to do it.
I have just got that working for pdlua in svn. Some notes:
A class must have a menu-open method before the Open item will be
highlighted:
class_addmethod(our_class, (t_method)our_menu_open, gensym(menu-open),
A_NULL);
and the method itself:
static void our_menu_open(t_our_class *x)
calls sys_vgui(::pd_menucommands::menu_openfile {%s}\n, filename);
So the object needs to know the name of its script. For pdlua I added a
field _scriptname in the lua side with an accessor _whoami.
Martin
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Creating an external / sinewave equation example
On 2011-09-04 16:52, Rick T wrote: ... I've been able to find instructions on how to create a hello world C-external but not one that creates a simple sine wave from a sinewave equation like A*sin(w*t+p) (https://secure.wikimedia.org/wikipedia/en/wiki/Sine_wave) Does anyone have one or know where to find one. The canonical reference is here: http://iem.at/pd/externals-HOWTO/node6.html You just need to plug your equation into the perform routine. Also check the source for osc~ in d_osc.c of the Pd source, which uses a fancy 32-bit float cosine table scanning method that was useful when it mattered but is getting obsolete as a call to sin() is probably just as fast nowadays. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On 2011-08-20 21:21, Hans-Christoph Steiner wrote: I tried these patches a bit but haven't fully tested them yet. But I did just finish updating the MinGW setup, there have been big improvements in the last 2 years since I looked last. The nicest is 'mingw-get' for installing packages :) Here's the documentation on the whole setup, it now includes ffmpeg with many codecs, but gmerlin-avdecoder didn't build. It also includes a pthread DLL that can be linked using only -lpthread like all other platforms (i.e. libpthread-2.dll). I left in -lpthreadGC2 for backwards compatibility: http://puredata.info/docs/developer/WindowsMinGWGet/ That looks very nice, I need to try it (usually something sticks because I can't find the right version of something, the MinGW people seem to randomly change what's in their packages) but I see you have the lines: svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended/0.41/ cd 0.41/pd/src make -f makefile.mingw Are Windows folks doomed to live in the past or is it possible to build 0.43 with MinGW the same way? Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] On RHEL5 mrpeach's packOSC sometimes generates negative values incompatible with udpsend for floats and negative input values
Hi Adrian, I think that must be an older version of packOSC. I'm sure I fixed all that. It's not hard to compile your own as it doesn't depend on any libs. If you get pd trunk from svn and do make mrpeach from the externals directory it usually works. No need to build everything. Then you need to copy the *.pd_linux and *-help.pd patches to wherever pd is installed. Martin On 2011-04-14 02:55, Adrian Corston wrote: I am a PD newbie running PD on RHEL5 using RPMs downloaded from here: http://ccrma-www.stanford.edu/planetccrma/mirror/centos/linux/planetccrma/5/i386/ OS is RHEL 5.5 and uname -a says: Linux myhost 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux Using the PD file below (based on one I found somewhere) I see packOSC outputting negative numbers when floats or negative numbers are input. #N canvas 2929 425 631 244 10; #X obj 210 115 mrpeach/packOSC; #X msg 210 24 send /int 1; #X msg 258 77 send /negative -1; #X msg 234 53 send /float 0.1; #X text 293 24 - works well; #X text 343 53 - convert float to negative value: ERROR!; #X text 375 77 - negative value. ERROR!; #X obj 210 151 print; #X connect 0 0 7 0; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 0 0; Clicking on the send buttons in order, I see this output, the latter two lines of which udpsend won't accept (it expects an array of positive octets and prints an error when it receives negative numbers.) print: 47 105 110 116 0 0 0 0 44 105 0 0 0 0 0 1 print: 47 102 108 111 97 116 0 0 44 102 0 0 61 -52 -52 -51 print: 47 110 101 103 97 116 105 118 101 0 0 0 44 105 0 0 -1 -1 -1 -1 I am guessing it might be a issue with octet signing - for the last example (send /negative -1) it looks like -1 -1 -1 -1 maybe should be 255 255 255 255 which I am guessing would represent -1. But I'm no OSC expert. Does it look like a problem with the RPM? It's the only one I could find for RHEL5. I had a whole bunch of trouble compiling pd-extended from source but I suspect I might need to go back to that option. Thanks for any help you can provide, Adrian. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working pd-ext 0.43 build on windows?
As I mentioned last week, you can change the pd-settings.reg file in a text editor so it starts like this: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Pd-extended] flags= loadlib1=libdir loadlib2=vanilla/list loadlib3=vanilla loadlib4=extra loadlib5=Gem loadlib6=cyclone loadlib7=zexy nloadlib=7 ; delete any previous loadlib flags loadlib8=- loadlib9=- ... Martin On 2011-04-11 18:53, Hans-Christoph Steiner wrote: Try loading 'libdir' as the first lib. .hc On Apr 11, 2011, at 6:32 PM, João Pais wrote: hmm, vanilla and vanilla/list are already in the startup libs of pd. and after that when trying import them, they say [import]: can't load library in 'vanilla' (vanilla/list seems to work). also, when editing the startup parameters in pd, the writing is really small, hardly readable. I forgot to add, I am interested in feedback on this particular feature. Right now its in there to try out. I'm not yet convinced it should be permanent, but it does offer some advantages, especially on mobile phones and smaller computers. .hc On Apr 11, 2011, at 12:59 PM, João Pais wrote: of course, I saw that being discussed some days ago. ok. On Mon, 11 Apr 2011 17:32:19 +0200, Hans-Christoph Steiner h...@at.or.at wrote: Most vanilla objects are split out into their own 'vanilla' lib right now. So if you don't add vanilla/list and vanilla to the libraries loaded by default, they won't be loaded. You can do [import vanilla/list vanilla] to quickly try a patch without changing your prefs. .hc On Apr 11, 2011, at 9:03 AM, João Pais wrote: Hi, I thought about downloading a build of pd-ext 0.43 that works, to try it out. But the version I tried yesterday is apparently not ok, for example even cnv objects don't exist. Does anyone noticed a previous windows build that is more stable? (even if it doesn't have all the extra objects) João --Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. --Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] integrating pdlua into Pd-extended
I just built that lua-5.1.4 package in MinGW. Just typing 'make mingw'produces liblua.a and lua51.dll in src. liblua.a is somewhat larger than the dll. 'Make install' copies liblua.a into /usr/local/lib and creates an empty directory /usr/local/lib/lua. The error in the latest autobuild log (2011-03-27_03.31.00_mingw32_nt-5.1_windowsxp-i386_pd-extended.txt) is gcc -s -shared -Wl,--enable-auto-import -o pdlua.dll pdlua.o -L/home/pd/auto-build/pd-extended/pd/src -L/home/pd/auto-build/pd-extended/pd/bin -L/home/pd/auto-build/pd-extended/pd/obj -lpd -lwsock32 -lkernel32 -luser32 -lgdi32 -llua51.dll c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -llua51.dll So maybe it should be looking for -llua instead of -llua51.dll. Or else placing lua51.dll in /usr/local/lib or /usr/local/lib/lua might work. The lua wiki seems to imply that you should link against the dll. I'll change it to -llua first as that seems consistent with the rest of the MinGW Pd build. Martin On 2011-03-27 12:25, Hans-Christoph Steiner wrote: Hmm, turns out it was already installed on the Windows build machine, but I just updated it. Something with the way pdlua is being linked makes it not able to find lua51.dll. My guess is because the Lua build system doesn't generate a liblua51.dll.a to put in /usr/local/lib, like the other libs there. libogg for example. I don't know how to generate the liblua51.dll.a, do you? .hc On Mar 26, 2011, at 9:03 PM, Martin Peach wrote: If you get the latest source here: http://www.lua.org/ftp/lua-5.1.4.tar.gz and then: make mingw ...it should just work. Martin On 2011-03-26 20:20, Hans-Christoph Steiner wrote: Yeah, we can build Lua on Windows and install it into the MinGW path. That's how the rest of the libraries are currently handled. Then the installer grabs the .dlls from the MinGW install path. Have you successfully built Lua on Windows? If so, let me know the details, and I'll install it on the build server. .hc On Mar 26, 2011, at 6:31 PM, Martin Peach wrote: From the gnu make manual it seems that running pkg-config is not recommended inside a Makefile. It should probably be done in the configure stage, but anyway, since liblua has different names on each platform, pkg-config only returns that name. So I ended up just hard-coding liblua names and lua.h path for each OS in the Makefile. Now the nightly build for Windows is failing because it can't resolve -llua51.dll. It seems that there is no standard place to put that dll. Sooo, maybe pd-extended should build lua as well, like portaudio, or should the dll be put in pd/bin, like pthreads.dll? Martin On 2011-03-18 23:55, Hans-Christoph Steiner wrote: Martin, I think you could put different pkg-config lines in the per-OS section of the Makefile, and that would work for differences between Debian/Ubuntu, Mac OS X, and Windows liblua. That won't help if different GNU/Linux distros have different names for the lib tho. .hc On Mar 18, 2011, at 5:02 PM, katja wrote: Hello, In the original Makefile.static for pdlua it is defined: lua-5.1.3 This worked for me on OSX. Katja On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen cla...@goto10.org mailto:cla...@goto10.org wrote: Hey, On 18/03/11 17:38, Martin wrote: The error actually seems to originate in pkg-config not finding lua5.1: From my limited experience, Lua 5.1 libraries have different names all over the place, even in different GNU/Linux distros (lua51, lua5.1, lua5, lua, ...). A bit of a nightmare. pkg-config lua --libs should do it on Mac OS X/Fink. .hc Claude ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ Pd-dev mailing list
Re: [PD-dev] integrating pdlua into Pd-extended
If you get the latest source here: http://www.lua.org/ftp/lua-5.1.4.tar.gz and then: make mingw ...it should just work. Martin On 2011-03-26 20:20, Hans-Christoph Steiner wrote: Yeah, we can build Lua on Windows and install it into the MinGW path. That's how the rest of the libraries are currently handled. Then the installer grabs the .dlls from the MinGW install path. Have you successfully built Lua on Windows? If so, let me know the details, and I'll install it on the build server. .hc On Mar 26, 2011, at 6:31 PM, Martin Peach wrote: From the gnu make manual it seems that running pkg-config is not recommended inside a Makefile. It should probably be done in the configure stage, but anyway, since liblua has different names on each platform, pkg-config only returns that name. So I ended up just hard-coding liblua names and lua.h path for each OS in the Makefile. Now the nightly build for Windows is failing because it can't resolve -llua51.dll. It seems that there is no standard place to put that dll. Sooo, maybe pd-extended should build lua as well, like portaudio, or should the dll be put in pd/bin, like pthreads.dll? Martin On 2011-03-18 23:55, Hans-Christoph Steiner wrote: Martin, I think you could put different pkg-config lines in the per-OS section of the Makefile, and that would work for differences between Debian/Ubuntu, Mac OS X, and Windows liblua. That won't help if different GNU/Linux distros have different names for the lib tho. .hc On Mar 18, 2011, at 5:02 PM, katja wrote: Hello, In the original Makefile.static for pdlua it is defined: lua-5.1.3 This worked for me on OSX. Katja On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen cla...@goto10.org mailto:cla...@goto10.org wrote: Hey, On 18/03/11 17:38, Martin wrote: The error actually seems to originate in pkg-config not finding lua5.1: From my limited experience, Lua 5.1 libraries have different names all over the place, even in different GNU/Linux distros (lua51, lua5.1, lua5, lua, ...). A bit of a nightmare. pkg-config lua --libs should do it on Mac OS X/Fink. .hc Claude ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] svn-repository general question
On 2011-02-19 11:29, Ingo Randolf wrote: Hello thank you for the answer. in the subfolder ./trunk/pd i can read the INSTALL.TXT file... which tells me to make a ./configure in /trunk/pd/src ... this INSTALl.txt is a) outdated i thought so. b) meant for the source release(!) rather than an SVN-snapshot the latter means: it is considered bad style to put anything generated (mostly binaries, but also scripts, like configure) into VCS. hence configure (which is generated from configure.ac) is missing in the SVN. ok. to generate everything needed in order to run configure (btw, nowadays this is in .../pd rather than .../pd/src) just run (in .../pd): $ ./autogen.sh so, since autogen.sh is also a script, it is not included in the svn-snapshot...? can you please tell me what to do, if i want to compile the snapshot then? - copy the scripts into?? or better copy the source out of the svn-maintained folder, and copying the scripts needed to create the configure script... etc...? where do i get those scripts from...? copying them from a source-release? copying the snapshot-sources into a source-release?? is there a step-by-step tutorial for compiling a svn-snapshot? I was using this: http://puredata.info/docs/developer/BuildingPdExtended But recently I have been unable to build Pd this way because trunk is inconsistent ATM. I think the idea is to choose a version in /branches and build that, starting in the packages directory. It worked for me with Pd-extended 0.42.5 on linux at least. For the latest versions of externals build them separately from trunk/externals. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] svn-repository general question
On 2011-02-19 13:50, Hans-Christoph Steiner wrote: On Feb 19, 2011, at 12:14 PM, Martin Peach wrote: On 2011-02-19 11:29, Ingo Randolf wrote: is there a step-by-step tutorial for compiling a svn-snapshot? I was using this: http://puredata.info/docs/developer/BuildingPdExtended But recently I have been unable to build Pd this way because trunk is inconsistent ATM. I think the idea is to choose a version in /branches and build that, starting in the packages directory. It worked for me with Pd-extended 0.42.5 on linux at least. For the latest versions of externals build them separately from trunk/externals. Yes, its true, its a bit of a mess. We haven't figured out out to bridge from git to svn very well yet, and both pure-data and pd-extended are now developed out of git. If you want to build like the nightly builds, then use the 'rsync' method of getting the source. It's weird, I remember the shift from cvs to svn took a few months of discussion on the list but I don't remember seeing anything about moving to git... Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compiling pdlua in windows, macos, android, ...
Does that mean [pdlua] is a 'loader'? Is it all right to just take the code from gitorious (the latest version seems to be at http://gitorious.org/pdlua) and stick it in svn trunk/externals/lua or should it go somewhere else? Martin On 2011-01-18 09:13, Hans-Christoph Steiner wrote: I think adding pdlua to Pd-extended is a good idea, I'll help you where I can. I've been thinking that loaders should be installed into the pd/startup folder, where they will be automatically loaded at startup. I plan on doing that for the libdir loader. .hc On Jan 18, 2011, at 8:53 AM, Martin Peach wrote: Yes I'm interested in that too, still learning lua. It would be nice to have [pdlua] in pd-extended. I can try to build it for WinXP and see what's involved. Martin On 2011-01-18 06:54, João Pais wrote: Hi, I looked at [pdlua] last week, and was quite impressed by the examples there, and how it's easy to create new externals that go beyond pd's capabilities (for example to parse lists and symbols, etc.) - provided you learn about lua. I wanted to use this in a project, but in the website - http://claudiusmaximus.goto10.org/cm/2008-06-19_pdlua-0.5_released.html - there's only instructions to compile in linux. Since the developer isn't responding to my mails, I wanted to know if it's possible to get this working on other plattforms. So I wanted to ask around: - does anyone has any already built binaries of pdlua for windows and macos? - since I guess the answer is going to be no, is anyone interested in helping me trying to compile pdlua in these systems? Although since I have limited access to macos, and never compiled anything on windows, helping me means telling me what to do, which dependencies to get, etc. - this project is something that should work on all plattforms, and, in the future also in android (when pd for android is also that far). can anyone say something about the feasibility of porting pdlua to android? [I cannot evaluate the dumbness of this question] I would like to use pdlua, but if it's not a feasible solution, I'll ask instead someone to write a C external for me. Thanks, João ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev http://at.or.at/hans/ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compiling pdlua in windows, macos, android, ...
Yes I'm interested in that too, still learning lua. It would be nice to have [pdlua] in pd-extended. I can try to build it for WinXP and see what's involved. Martin On 2011-01-18 06:54, João Pais wrote: Hi, I looked at [pdlua] last week, and was quite impressed by the examples there, and how it's easy to create new externals that go beyond pd's capabilities (for example to parse lists and symbols, etc.) - provided you learn about lua. I wanted to use this in a project, but in the website - http://claudiusmaximus.goto10.org/cm/2008-06-19_pdlua-0.5_released.html - there's only instructions to compile in linux. Since the developer isn't responding to my mails, I wanted to know if it's possible to get this working on other plattforms. So I wanted to ask around: - does anyone has any already built binaries of pdlua for windows and macos? - since I guess the answer is going to be no, is anyone interested in helping me trying to compile pdlua in these systems? Although since I have limited access to macos, and never compiled anything on windows, helping me means telling me what to do, which dependencies to get, etc. - this project is something that should work on all plattforms, and, in the future also in android (when pd for android is also that far). can anyone say something about the feasibility of porting pdlua to android? [I cannot evaluate the dumbness of this question] I would like to use pdlua, but if it's not a feasible solution, I'll ask instead someone to write a C external for me. Thanks, João ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] is there a way for an object to detect whethere its inlet is connected to something
I suppose I am getting it wrong as usual but I thought signal objects only do computation when signals arrive at the inlets. Martin On 2010-12-27 05:10, Ivica Ico Bukvic wrote: Hi all, I guess subject says it all. For the sake of efficiency I am hoping to detect whether an inlet is connected to anything and if so to perform its signal-based operations. Otherwise, it should remain dormant. Is there anything in the existing API that allows for this? Many thanks! Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] is there a way for an object to detect whethere its inlet is connected to something
Haha I knew I would be wrong! I've also noticed that some objects (my [sqosc~] especially) sometimes continue to make sound or distort the sound of other objects when they are disconnected, that [*~] on the output has no effect: some things just make no sense... I guess I would use a flag that would be set if the object has ever received a message on that inlet, but I really have no idea what you're doing, so that's probably wrong too;) Martin On 2010-12-27 13:50, Ivica Ico Bukvic wrote: On Mon, 2010-12-27 at 11:31 -0500, Martin Peach wrote: I suppose I am getting it wrong as usual but I thought signal objects only do computation when signals arrive at the inlets. Martin Not according to what I am getting when I create a bunch of phasor~ objects (unconnected to anything), start the dsp, open cpu load patch and then cut and paste said phasor~ objects. there is a noticeable dip in CPU utilization when they are cut. Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PATCH] Replace getbytes calls by alloca whenever possible in mrpeach's packOSC.c
Hi Lta, Did you post the patch somewhere? I can't find it. Martin On 2010-12-12 12:49, Julien 'Lta' BALLET wrote: Hello, I can't test on other platform than on Linux, so some help testing this would be appreciated, but this functions is available at least under windows, and osx. The semantic is the same on all the platforms, according to the documenation. I've included the correct header on windows, unix and osx. -- Lta. On Sun, Dec 12, 2010 at 3:52 PM, patko colet.patr...@free.fr mailto:colet.patr...@free.fr wrote: Hello, is your patch working on all platforms? - Julien 'Lta' BALLET elthar...@gmail.com mailto:elthar...@gmail.com a écrit : Hello, Good question indeed. This is a general improvement. Sorry for not explaining it in the first place, this is my first post and patch on the pd-dev ml. -- Lta On Fri, Dec 10, 2010 at 5:01 PM, Hans-Christoph Steiner h...@at.or.at mailto:h...@at.or.at wrote: My first question is: what's the problem that you are trying to solve? Are there specific bugs, or just a general improvement? .hc On Dec 10, 2010, at 8:50 AM, Julien 'Lta' BALLET wrote: Hello, As said in the title, i submit you a small patch to mrpeach's osc code, to replace calls to getbytes by alloca calls in part of the code that might get called in the soundcard callback. The considered memory sizes are quites small and then won't smash the stack. This removes the need for memory deallocation and reduces the page fault risk as well as the memory allocation time. This is kind of a naive patch, since i don't fully know yet the pd codebase. Any comment would be appreciated. Regards, Lta. ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] split out 'osc' and 'net' from 'mrpeach'?
On 2010-11-28 12:13, Hans-Christoph Steiner wrote: Hey Martin and all, Just had a thought: originally everything in the 'mrpeach' folder was bundled into a single library, which I think Martin didn't really intend. I did it to get Martin's valuable code out there in a kind of beta way. Now I think its quite clear that the 'net' and 'osc' sections in 'mrpeach' are really the canonical way of doing networking and OSC with Pd, so I think it makes sense to have them distributed as the 'net' and 'osc' library. I'm guessing Martin had that intention originally. Also, I noticed that IOhannes's filed an Intent-To-Package for something called 'pd-osc', which I am guessing is externals/mrpeach/osc. So my only question is: what becomes of 'mrpeach'? I agree it makes sense to package things by function rather than by author. So here's my take: Inside OSC ATM is [pipelist], which should maybe go into some list lib although it's useful for delaying timestamped OSC messages. In Net, [tcpreceive] is unnecessary as its functionality is covered by [tcpclient]. [binfile] and [midifile] should go into a file handling lib. [slipenc] and [slipdec] are useful for OSC over serial, so maybe put them in Net? [tab2flist], [flist2tab], [tabfind] operate on table/arrays. [sqosc~], [rc~], [rcosc~], [rojo~] are audio generators. [op~] is similar to [~], [~] etc but doesn't have trouble instantiating without hexloader. str only works with the (unaccepted) string patch, so it could be dropped. cmos is not really useful except to simulate some CMOS logic ICs. [life2x] is a cellular automaton. [which] tends to crash a lot, but can help to find the path to an external. [runningmean] is a math object. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] split out 'osc' and 'net' from 'mrpeach'?
On 2010-11-28 15:57, Roman Haefeli wrote: On Sun, 2010-11-28 at 13:38 -0500, Martin Peach wrote: On 2010-11-28 12:13, Hans-Christoph Steiner wrote: Hey Martin and all, Just had a thought: originally everything in the 'mrpeach' folder was bundled into a single library, which I think Martin didn't really intend. I did it to get Martin's valuable code out there in a kind of beta way. Now I think its quite clear that the 'net' and 'osc' sections in 'mrpeach' are really the canonical way of doing networking and OSC with Pd I'd hesitate to call using mrpeach/net the 'canonical' way. Last time I checked, there were still issues with many classes, in particular the blocking issue of [tcpsend]/[tcpclient]/[tcpserver] discussed in a plethora of mails. That's also the reason why IOhannes rewrote those and released them as the iemnet library. The classes from iemnet are high-performance and don't suffer from any blocking issue. That's another reason they should be in net instead of mrpeach: it seems that having my name on the folder inhibits others from improving the objects, so we end up with multiple parallel incompatible objects, in this case with the same names. (And when was the last time you checked?) Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] midiout
On 2010-10-27 06:10, Enrique Vetere wrote: Hi. I've been trying to use midiout but it does not work when sending sysex because it sends 1 byte at a time. Chatting with matju on #irc where he showed me the source code, I think the problem is that midiout uses ultimately sys_alsa_putmidibyte to send snd_seq_ev_set_sysex(ev,1,data) one byte at a time So we thought about writing an external that uses alsa-midi functions and he guided me the first steps. Now, the problem is that this external would need access to structure midi_handle, and variables alsa_midioutfd and alsa_nmidiout which are defined in s_midi_alsa.c (because creating and opening ALSA ports is handled there). The functions provided by s_midi are not good enough as I need to snd_seq_ev_set_sysex(ev, data_array_size,data_array) So my question is: is it possible to write such external? or I need to patch the sources? IMHO this is a bug, so you should patch the source, then submit the patch to the tracker. Also it seems to bug differently on different OSs, only linux uses alsa. Pd's sysex implementation didn't work properly on WIN32 either last time I checked. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] midiout
On 2010-10-27 09:37, Paulo Casaes wrote: Just to chime in, I was able to get midiout to send sysex data to a micro korg using midiout on Os X. What i discovered was that I had to put a 1ms delay between every byte or message being sent to midiout. That sounds like a bug as well Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] question about multithreaded externals in Pd
I think maybe
pthread_create(x-unsafe_t, NULL,
(void *) pd_cwiid_pthreadForAudioUnfriendlyOperations,
(void *)rPars);
should be something like:
pthread_create(x-unsafe_t, NULL,
pd_cwiid_pthreadForAudioUnfriendlyOperations,
(void *)rPars[this_thread]);
since rPars can't be used by any other thread, you need to make a copy
for each thread.
Also the function declaration
void pd_cwiid_pthreadForAudioUnfriendlyOperations(void *ptr)
should be:
void *pd_cwiid_pthreadForAudioUnfriendlyOperations(void *ptr)
Also nothing guarantees that a thread will be created right away. It may
be that the processor has to reload its cache to do something like that,
causing significant slowdown in execution speed and possible audio
glitches (but not crashing).
Martin
On 2010-10-01 20:36, Ivica Ico Bukvic wrote:
Hi all,
I am wondering if anyone can shed some light on the following
predicament. I am by no means a multi-threading guru so any insight
would be most appreciated.
The following are relevant excerpts from the code of an external. AFAIK
the external initializes mutex and cond and spawns a secondary worker
thread that deals with audio-unfriendly (xrun-causing) write operations
to the wiimote and terminates it when the object is destructed waiting
for the thread to join back and then destroying the mutex.
Now, if I add a bit of usleep right after the thread has been spawned as
part of the constructor (as included below) the external seems very
stable (e.g. cutting and pasting it as fast as keyboard allows, or in
other words constructing and destructing instances of it as fast as
possible does not result in a crash). Yet, when one does not use usleep
right after spawning the secondary (worker) thread in the constructor,
the whole thing is very crash-prone, almost as if the spawning of thread
does not go well unless given adequate time to do get things all into
sync, so to say, even though this makes to me no sense as the way I
understand it the constructor does not move ahead until pthread_create
does not return a value (which in this case I am not bothering to read).
Curiously, when not using usleep, a crash may occur right at creation
time, at any point while the object exists, and even as late as during
its destruction. Any ideas?
P.S. I am also including the entire file for those interested in trying
it out.
Best wishes,
Ico
Relevant excerpts (in random order and incomplete to allow for greater
legibility):
//struct defining the object
typedef struct _wiimote
{
t_object x_obj; // standard pd object (must be first in struct)
...
//Creating separate threads for actions known to cause sample drop-outs
pthread_t unsafe_t;
pthread_mutex_t unsafe_mutex;
pthread_cond_t unsafe_cond;
t_float unsafe;
...
t_float led;
...
} t_wiimote;
//constructor
static void *pd_cwiid_new(t_symbol* s, int argc, t_atom *argv)
{
...
x-led = 0;
// spawn threads for actions known to cause sample drop-outs
threadedFunctionParams rPars;
rPars.wiimote = x;
pthread_mutex_init(x-unsafe_mutex, NULL);
pthread_cond_init(x-unsafe_cond, NULL);
pthread_create(x-unsafe_t, NULL, (void *)
pd_cwiid_pthreadForAudioUnfriendlyOperations, (void *)rPars);
//WHY IS THIS NECESSARY? I thought that pthread_create call will first
finish spawning thread before proceeding
usleep(100); //allow thread to sync (is there a better way to do this?)
...
}
//destructor
static void pd_cwiid_free(t_wiimote* x)
{
if (x-connected) {
pd_cwiid_doDisconnect(x); //this one has nothing to do with
thread but
rather disconnects the wiimote
}
x-unsafe = -1; //to allow secondary thread to exit the while loop
pthread_mutex_lock(x-unsafe_mutex);
pthread_cond_signal(x-unsafe_cond);
pthread_mutex_unlock(x-unsafe_mutex);
pthread_join(x-unsafe_t, NULL);
pthread_mutex_destroy(x-unsafe_mutex);
...
}
//worker thread
void pd_cwiid_pthreadForAudioUnfriendlyOperations(void *ptr)
{
threadedFunctionParams *rPars = (threadedFunctionParams*)ptr;
t_wiimote *x = rPars-wiimote;
t_float local_led = 0;
t_float local_rumble = 0;
unsigned char local_rpt_mode = x-rpt_mode;
while(x-unsafe -1) {
pthread_mutex_lock(x-unsafe_mutex);
if ((local_led == x-led) (local_rumble == x-rumble)
(local_rpt_mode == x-rpt_mode)) {
pthread_cond_wait(x-unsafe_cond,x-unsafe_mutex);
}
if (local_led != x-led) {
local_led = x-led;
//do something
}
}
if (local_rumble != x-rumble) {
local_rumble = x-rumble;
//do something else
Re: [PD-dev] pd_error() for udpsend, tcpsend, etc.
Hans-Christoph Steiner wrote: Hey Martin, I've been using udpsend/udpreceive in a project and they've been great. I have one small request, which I'd happily implement if you don't want to. For the error like not connected, it would be very handy if they used pd_error() so that the error is findable. Yes sure, go ahead and do it. I think all the error messages need to be looked at re that issue, when I have time... Also it would be nice to have some kind of guidelines for which error message to use when. There seem to be several variants available. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] patch for mrpeach/tcpserver.c
Ivica Ico Bukvic wrote: Attached fixes (version 0.42.5 pd-extended): out-of-order output on tcpserver.c provides output of IP and socket on disconnect so if one maintains a database of what client is associated with what socket (e.g. through a coll), this way it reports it in a way that such an external database can be updated accordingly. Thanks for that. I have updated tcpserver.c in svn. Attached patch is created using diff -u. It is a diff against an old version of tcpserver.c. You should get a recent version from the Pd svn repository: http://sourceforge.net/scm/?type=svngroup_id=55736 or the nightly builds at: http://autobuild.puredata.info/auto-build/ Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] patch for mrpeach/tcpserver.c
Ivica Ico Bukvic wrote: Speaking of tcpserver.c isn't the tcpserver_notify() function making an unsafe outlet_float() call when it is being triggered by an external event (disconnection) which can happen out-of-order and thus potentially causing crashes? Shouldn't this be wrapped also in a clock_delay()? No, it's called from a poll routine that Pd calls at a safe time. The disconnect happens asynchronously but Pd checks for activity on that socket with a select() call, which, if it detects a disconnect, results in tcpserver_notify() being called. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] clock_delay question
Ivica Ico Bukvic wrote:
Likewise, I noticed that netclient (maxlib) uses something called
sys_pollfn() call, is this safe?
Oops, I meant sys_addpollfn()...
Another question related to this. In the netclient.c (maxlib) there is
the following code excerpt:
/* get's called when connection has been made */
static void netclient_tick(t_netclient *x)
{
outlet_float(x-x_outconnect, 1);
/* add pollfunction for checking for input */
sys_addpollfn(x-x_fd, (t_fdpollfn)netclient_rcv, x);
}
Isn't the outlet_float call here unsafe as it is being triggered by an
external potentially out-of-sync force (namely connection)? Shouldn't
this be done through clock_delay() just to be safe? If I understand this
correctly, Pd does audio in 64-byte chunks and then the data processing
in between. Is this correct?
If so, how does Pd deal with such events if they happen during the times
the pd's message tree is not being traversed (e.g. during the dsp
cycle)?
That is why they are poll functions. The poll functions are polled right
after the dsp update, in sys_microsleep(). A select call is made to see
if any of the file descriptors are ready for read/writing. So if the
socket connects at any random time, the float will only be sent out the
outlet after the dsp. Another poll function is then registered to check
for received data on the socket.
sys_microsleep() is called from m_pollingscheduler(), Pd's main loop, in
m_sched.c, after the dacs are written, so (as I understand it), it is
safe to make calls from a pollfunction. I think it's only outlet writes
made directly from the dsp object's perform routine that are dangerous,
they should be scheduled for right after the dac writes using
clock_delay(0).
Martin
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] clock_delay question
Ivica Ico Bukvic wrote:
Another question related to this. In the netclient.c (maxlib) there is
the following code excerpt:
/* get's called when connection has been made */
static void netclient_tick(t_netclient *x)
{
outlet_float(x-x_outconnect, 1);
/* add pollfunction for checking for input */
sys_addpollfn(x-x_fd, (t_fdpollfn)netclient_rcv, x);
}
Isn't the outlet_float call here unsafe as it is being triggered by an
external potentially out-of-sync force (namely connection)? Shouldn't
this be done through clock_delay() just to be safe? If I understand this
correctly, Pd does audio in 64-byte chunks and then the data processing
in between. Is this correct?
If so, how does Pd deal with such events if they happen during the times
the pd's message tree is not being traversed (e.g. during the dsp
cycle)?
That is why they are poll functions. The poll functions are polled right
after the dsp update, in sys_microsleep(). A select call is made to see
if any of the file descriptors are ready for read/writing. So if the
socket connects at any random time, the float will only be sent out the
outlet after the dsp. Another poll function is then registered to check
for received data on the socket.
sys_microsleep() is called from m_pollingscheduler(), Pd's main loop, in
m_sched.c, after the dacs are written, so (as I understand it), it is
safe to make calls from a pollfunction. I think it's only outlet writes
made directly from the dsp object's perform routine that are dangerous,
they should be scheduled for right after the dac writes using
clock_delay(0).
Martin
Thanks for the explanation. I am not sure however how does this apply to
the aforesaid example, so I would greatly appreciate your insight in
that specific scenario. Namely:
In the netclient example is the outlet_float call ok even though the
netclient_tick function containing it is triggered by an external
out-of-sync force (namely network connection)?
Yes, because netclient_tick is called after a clock timeout that was
triggered by the connect routine running in a different thread.
If so, what ensures that
this particular call is not going to happen right in the middle of other
GUI stuff already being sent out and/or dsp loop as the network client
has no idea when that is actually happening? Shouldn't this be also
clock_delay()?
It _is_ clock_delayed.
netclient_tick() is associated with a clock in netclient_new() as:
x-x_clock = clock_new(x, (t_method)netclient_tick);
and the x_clock is set to timeout in 0 milliseconds in
netclient_child_connect() after the socket connects, which can happen at
any time since it's running in a separate thread.
The clock will only be checked at one point in the main loop, after the
dacs have been written, so the function it calls will run at a safe time.
In other words, are outlet_something calls safe to be made from
non-dsp functions no matter when they happen *or* are they safe to be
made only in objects that are being pushed by incoming data streams
(which is typically most of Pd objects, but not all, e.g. such as metro
for instance)? If latter is the case, I would say clock_delay(0) is
necessary even on the aforesaid call.
I guess the rule is this:
Outlet calls are safe as long as they are:
1 outside of dsp perform routines and
2 called from Pd's main thread.
Martin
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] changes in atom_getsymbol between pd 0.40-3 and 0.42.4?
Maybe easiest and safest is to make sure sizeof(gphoto_gimme_struct) is big enough to hold some maximum number of args by declaring it a fixed size: #define MAXARGS 339966 t_atom argv[MAXARGS]; instead of t_atom *argv; and then copy up to MAXARGS atoms in a loop: for (i = 0; (i argc)(i MAXARGS); ++i) threadargs-argv[i] = argv[i]; instead of threadArgs-argv = argv; ...or you could leave the struct alone and separately allocate the precise amount of memory for argc atoms, as threadArgs-argv = malloc(sizeof(*argv)*argc)); and then copy them over. Martin B. Bogart wrote: Thanks Martin, I can't get the syntax right, care to give me a hint? B. Bogart martin.pe...@sympatico.ca wrote: So what have I misunderstood? argv is a pointer, it's size is 4. You're still not copying whatever argv is pointing to. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd file format: color settings
Martin Peach wrote: Yes but why? You can accurately represent every 32-bit int with a float, but Pd clips them by using the %g format specifier to print them, instead of %f. Ooops not true, only up to 24 bits are exact, after that integers increment by increasing powers of two; but using %g to format floats loses precision before that compared to %f. In m_atom.c, at line 68, the function atom_string() converts atoms into strings, and in the case of float atoms, uses this line to do it: sprintf(tbuf, %g, a-a_w.w_float); This prints both of the floats 16777215.0 and 16777214.0 as 167772e+7. It seems to me that sprintf(tbuf, %f, a-a_w.w_float); would be better, since it prints 16777215.00, 16777214.00. Or even better a routine to clip off unnecessary trailing zeros and decimal points: int i; i = sprintf(tbuf, %f, a-a_w.w_float); while ((--i 0) (tbuf[i] == '0')) tbuf[i] = '\0'; if tbuf[i] = '.' tbuf[i] = '\0'; I'll post this as a patch for atom_string() later today. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd file format: color settings
That formula should read: color = ([red] * 65536) + ([green] * 256) + ([blue]) In binary the idea is to shift the 8 'red' bits 16 to the left, then add 8 'green' bits shifted 8 bits, and finally 8 'blue' bits, so in all 24 bits are occupied. Multiplying the blue value by -1 in the original formula has the effect of setting the 16 bits to the left of it to 1, so you get different shades of pure blue. Martin Robert Schwarz wrote: Hi all, I recently tried writing patches in a text editor (or from scripts) and had problems getting the color settings right, for bang elements. There is some documentation at http://puredata.info/docs/developer/fileformat with the explanation: Color: Some graphical elements have color attributes. Per color only one signed integer value is stored that contains the three 8-bit color components (RGB). Formula to calculate color attribute values: color = ( [red] * -65536) + ( [green] * -256) + ( [blue] * -1) Where [red], [green], [blue] obviously represent the three color components, their values range from 0 to 255. They apply to the attributes [background color], [front color], [label color] of various elements. I tried that, but it didn't work. Instead of showing the whole spectrum I just got different shades of blue. Also, when I opened one of my handwritten patches in PureData, looked at the color settings and saved, the resulting numbers changed. I assume that some kind of rounding is happening, and colors are actually saved in lower resolution. Do you have any ideas? Also, my application is a 13x13 button matrix, each triggering different chords via MIDI. The buttons should be color coded. Obviously, it's too much work setting all colors individually and I might want to create several of these patches with different colors. Maybe there is another obvious solution I didn't see. Any help is appreciated! (I'm using standard pd 0.42_5 on Arch Linux, but this shouldn't make a difference.) ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd file format: color settings
Ah yes, in g_all_guis.c line 281:
void iemgui_all_colfromload(t_iemgui *iemgui, int *bflcol)
{
if(bflcol[0] 0)
{
bflcol[0] = -1 - bflcol[0];
iemgui-x_bcol = ((bflcol[0] 0x3f000) 6)|((bflcol[0]
0xfc0) 4)|
((bflcol[0] 0x3f) 2);
}
else
{
bflcol[0] = iemgui_modulo_color(bflcol[0]);
iemgui-x_bcol = iemgui_color_hex[bflcol[0]];
}
...so if the colour is negative it's a negated (all bits flipped) 18-bit
rgb value and if it's positive it's an indexed colour from the iemgui
palette.
11RRGGBB
is bit-flipped to get:
00rrggbb
which is shifted into this:
rr00gg00bb00
so the 2 LSBs of each colour are set to 0. I don't know why.
Martin
Robert Schwarz wrote:
Thanks for the quick answer.
The concept of embedding three 8 bit components in one integer was clear
to me, but I think that pd doesn't really use all 8 bits for the colors.
Or maybe there is some issue with 2-complements or something.
For example, if I want to create three bang objects, in red (#ff),
green (#00ff00) and blue (#ff), your formula gives values of:
16711680, 65280, 255 for the three colors.
But I insert them in a patch, like:
#N canvas 825 10 450 300 10;
#X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 16711680 0 0 ;
#X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 65280 0 0 ;
#X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 255 0 0 ;
I see the colors white, white, yellow.
Now, when I change the colors by hand, to really get red, blue and green
on the bang objects and save the file, it reads:
#N canvas 825 10 450 300 10;
#X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 -258049 -1 -1 ;
#X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 -4033 -1 -1 ;
#X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 -64 -1 -1 ;
So it uses negative numbers, and -64 means full blue.
Now, when I re-open the same file and look at the properties of the blue
bang object, the color now reads: #fc instead of the #ff I
entered just before saving.
That's why I suspect some lower resolution going on. I tried to browse
this part in the sources, but all the GUI code confuses me.
For your interest, this patch results for colors of #04, #000400 and
#04 set by hand in the properties window:
#X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 -4097 -1 -1;
#X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 -65 -1 -1;
#X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 -2 -1 -1;
Setting colors to lower values, like #01 results in getting them
rounded down to #00.
So, the resolution is apparently 256/4 = 64 values, or 6 bits.
Indeed, if I replace the formula with:
color = (-([red]+1)/4*64*64) - (([green]+1)/4*64) - ([blue]+1)/4
I get the same values that Pure Data produces.
Hm, I might just have solved my problem.
It's still weird and some developer could check this our or change the
documentation.
Cheers, Robert
On 02/13/2010 11:08 PM, Martin Peach wrote:
That formula should read:
color = ([red] * 65536) + ([green] * 256) + ([blue])
In binary the idea is to shift the 8 'red' bits 16 to the left, then add
8 'green' bits shifted 8 bits, and finally 8 'blue' bits, so in all 24
bits are occupied.
Multiplying the blue value by -1 in the original formula has the effect
of setting the 16 bits to the left of it to 1, so you get different
shades of pure blue.
Martin
Robert Schwarz wrote:
Hi all,
I recently tried writing patches in a text editor (or from scripts) and
had problems getting the color settings right, for bang elements.
There is some documentation at
http://puredata.info/docs/developer/fileformat
with the explanation:
Color: Some graphical elements have color attributes. Per color only
one signed integer value is stored that contains the three 8-bit
color components (RGB). Formula to calculate color attribute values:
color = ( [red] * -65536) + ( [green] * -256) + ( [blue] * -1)
Where [red], [green], [blue] obviously represent the three color
components, their values range from 0 to 255. They apply to the
attributes [background color], [front color], [label color] of
various elements.
I tried that, but it didn't work. Instead of showing the whole spectrum
I just got different shades of blue. Also, when I opened one of my
handwritten patches in PureData, looked at the color settings and saved,
the resulting numbers changed. I assume that some kind of rounding is
happening, and colors are actually saved in lower resolution.
Do you have any ideas?
Also, my application is a 13x13 button matrix, each triggering different
chords via MIDI. The buttons should be color coded. Obviously, it's too
much work setting all colors individually and I might want to create
several of these patches with different colors.
Maybe there is another obvious solution I didn't see.
Any help is appreciated!
(I'm using standard pd 0.42_5 on Arch Linux, but this shouldn't make
Re: [PD-dev] [PD] midiout / sysex on windows
Yes, why not just send a list though? It seems that in WinXP [midiout] sends 247(start sysex) followed by 240(end sysex), the intervening message doesn't get transmitted. Also if the message contains numbers 127 then more bytes get transmitted, not good. Also as lists seem to be easier to generate than comma separated messages, and a list already has its buffer allocated, there is no need to reserve 1000 or so bytes just in case. Maybe someone should add a list method to [midiout]? Maybe rename it to [sysexout] and skip the need to put 247 and 240 in every message... Martin cyrille henry wrote: martin.pe...@sympatico.ca a écrit : On linux with alsa midi, sysex output works this way: bang | [tb bbb] | | || [247( [123( [88( [240( |_|_|| | | [midiout] this is the same than : [240, 88, 123, 247( (with coma) c That is, banging all the values separately into [midiout] during one message time slot. (Note the message is written backwards since the first byte to transmit is the sysex status byte, 240) Banging them in one at a time manually only sends one byte, banging them in as a list stops [midiout] from working until you reopen the patch. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [mrpeach/tcpserver]: full socket send buffer blocks pd
Roman Haefeli wrote: Hi Martin Hi Roman, sorry for the late reply. I wasn't sure, if I should report that as a bug. The new version of [tcpserver] seems to work fine, BUT now it suffers again from the initial problem, that maxlib's [netserver] is still suffering from: If the send buffer of a certain socket is full, [tcpserver] is blocked and thus blocks Pd. From a user perspective, i can think of a few solutions to deal with that. However, i don't have clue, what's possible/difficult to implement. a) If the server doesn't get the necessary ACKs in a meaningful time, if shuts down the connection after a while. It's up to the OS to deal with ACKs. The programmer has no (easy) way of accessing the low-level TCP communications. The send() function puts the data in the queue and returns. If the queue is blocked you don't find out until much later. The connection is closed some minutes after the disconnect occurs. b) Instead of writing to the send buffer, [tcpserver] could output a message saying, that the data couldn't be sent. Except it doesn't know the data couldn't be sent. I tried unplugging the cable and then plugging it back in. Sometimes all the data that was sent in the meantime will suddenly appear at the client, a few minutes after it was sent from the server. Other times I get 'client disconnected' messages a few minutes after the cable was unplugged. The timeout could probably be adjusted with the Time To Live parameter for the socket but it won't ever be zero. The internet protocols were designed to work over broken networks so it's normal that they wouldn't fail at the first attempt to send. UDP was intended for 'send and forget' messages. Maybe you could try [udpsend] to send vast quantities of data, alongside [tcpserver] for control. The previous incarnation of [tcpserver] used select() to see if there is still room in the buffer but as we saw this slows the whole thing to a crawl since the buffer has to be checked for every single byte in case it just filled up. It seems more efficient to have the client reply when it gets the message. c) Change the behaviour of the 'sent' message from last outlet so, that it reflects the amount of bytes actually transmitted and not the number of bytes written to the send buffer. Again 'it thinks' the data _was_ sent, so it returns the amount that it sent, even if it is still in the queue on the server, as long as the connection is still open. d) put something here, that i didn't think of I think you need to incorporate some kind of feedback from the clients. Either each client could send a request or a heartbeat every second or so, or the server could require a response to each message before sending more. Or use a separate UDP channel for the kind of data that could rapidly fill a buffer, like audio. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] denormals: svf, freeverb (was Re: bug in freeverb???)
It seems -ffast-math is not currently one of the CFLAGS except for darwin externals and some others like pdp. If it fixes the denormal problem it should probably be there. The gcc docs are very terse about what it actually does though. Also the PD_BADFLOAT macro in m_pd.h never gets called by any code: #define PD_BADFLOAT(f) *(unsigned int*)(f))0x7f80)==0) || \ (((*(unsigned int*)(f))0x7f80)==0x7f80)) , maybe because a floating point calculation that results in a denormal will be trapped before the user code can test it, unless the processor is set to ignore denormals. PD_BADFLOAT works if you're doing integer fixed point math and packing the result into a floating point frame, as in osc~. Martin Hans-Christoph Steiner wrote: I thought that compiling with -ffast-math disabled the denormal stuff. Or maybe it was a different compiler flag. That might be an easier route to deal with denormals. .hc On Aug 15, 2009, at 11:12 AM, Martin Peach wrote: I wonder if this line, right after you check in for denormality, might not be causing trouble: // very slight waveshape for extra stability sv-b = sv-b - sv-b * sv-b * sv-b * 0.001f; Since cubing a tiny number and multiplying it by .001 could end up creating a denormal, which isn't checked for until it's gone through a series of further computations and ends up as the new in. Also (I don't really know), I thought that denormals were caught as a processor exception whenever they occurred, so neutralizing them in the code after the fact won't do anything to speed up the process, except to prevent a cascade of denormals. The thing to do would be to replace the exception handler with your own. A bunch of interesting stuff here: http://software.intel.com/en-us/articles/x87-and-sse-floating-point-assists-in-ia-32-flush-to-zero-ftz-and-denormals-are-zero-daz/ where the conclusion reads: To avoid serialization and performance issues due to denormals and underflow numbers, use the SSE and SSE2 instructions to set Flush-to-Zero and Denormals-Are-Zero modes within the hardware to enable highest performance for floating-point applications. Martin Ed Kelly wrote: Hi Damon, I have tried to implement this technique, to fix the svf~ and I am still getting denormal errors pegging the CPU. Is there anything I have missed do you think? After reading a little bit about unions and uint32_t I think I've used them correctly... If this bug can be zapped for good then I'd like to eliminate denormal errors from the svn for good! Best, Ed --- On Fri, 14/8/09, Damon Chaplin da...@karuna.eclipse.co..uk wrote: From: Damon Chaplin da...@karuna.eclipse.co.uk Subject: Re: [PD-dev] denormals: svf, freeverb (was Re: [PD] bug in freeverb???) To: Ed Kelly morph_2...@yahoo.co.uk Cc: PD List pd-l...@iem.at, pddev pd-dev@iem.at Date: Friday, 14 August, 2009, 1:51 PM On Fri, 2009-08-14 at 13:06 +0100, Damon Chaplin wrote: On Fri, 2009-08-14 at 13:03 +0100, Damon Chaplin wrote: if (u.int_value 0x7f80) fv = 0.0f; Oops. That should be: if (u.int_value 0x7f80 == 0) fv = 0.0f; Or even better: if ((u.int_value 0x7f80) == 0) fv = 0.0f; Damon ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [tcpserver]: bad performance of new version
Roman Haefeli wrote: On Fri, 2009-05-01 at 18:48 -0400, Martin Peach wrote: Roman Haefeli wrote: On Fri, 2009-05-01 at 09:16 -0400, Martin Peach wrote: Roman Haefeli wrote: On Thu, 2009-04-30 at 10:17 -0400, Martin Peach wrote: Roman Haefeli wrote: i ve been testing the new netpd-server based on the new [tcpserver]/[tcsocketserver FUDI] now for a while and definitely could solve some problems, but some new ones were introduced. i found, that the most recent version of [tcpserver] peforms quite bad cpu-wise. this has some side-effects. in netpd, when a certain number of users are logged in (let's say 16), it can happen, that the traffic of those clients makes the netpd-server use more than the available cpu-time. i made some tests and checked, if all messages come through and if messages delivered by the server are still intact. under normal circumstances, there is no problem at all. but under heavy load, when the pd process is demanding more than available cpu time, some messages are corrupted or lost completely; in the worst case the pd process segfaults, at the moment of a client connecting or disconnecting. i guess, this is due to some buffer under- or overrun between pd and the tcp stack, but i don't really know. Hi Roman, Did you try using the new [timeout( message? The latest version of tcpserver defaults to a 1ms timeout, so if you have a bunch if disconnected clients, Pd will hang for 1ms each, which will quickly add up to more than the audio block time and then Pd will start thrashing and eventually die or become comatose, as it were. no, i haven't tried this parameter yet. but i sure will do and report back, when i can tell more about how it behaves. i haven't fully understood, what it does and what it can be used for. could you elaborate that a bit more? yet it sounds a bit strange to me, that i need to tweak a networking object with a time value for correct operation. When you send some message through tcpserver, the send routne first checks to see if it can be sent. The call to do this is a function known as select, which has a timeout parameter. The select call returns as soon as the socket is available or the timeout expires, whichever comes first. If the socket is blocked, select would never return if there was no timeout. So I gave the call a default 1ms timeout. ok. i think, i understand. thanks for the explanation. This could all be done using threads as well but I just don't know when I'll have time to do it. no hurry. it's not the case, that i know, that threading would help for the issues, i am experiencing. i just wanted to have my troubles reported. and i think, i read somewhere about server implementations, that they often use a separate thread for each socket. I still don't see that it would solve your problem anyway, if your application insists on sending to disconnected clients, you would have lots of threads sitting around, and still get no feedback about the connection. the only feedback needed: was something actually sent or not? if you (or the patch) _know_, that messages are not received by the other end, then you (the patch) can handle the situation somehow. anyway, that is the part that seems to be already working. by using the current [tcpserver], you notice, if the other end vanished or is still listening. the problems i currently encounter are coming from the fact, that the performance of the new version is probably 20 times worse than the version included in current stable pd-extended. for me its a problem, since with a certain sane number of clients connected (let's say 16), it already overloads the cpu of a 1.7GHz pentium m processor. why the big difference to the previous version? If you set the sending timeout to zero (by sending [timeout 0( message to [tcpserver] )then the performance should be the same as the older version. AFAIK that's all I changed. Did you try that yet? If not, something else is causing the slowdown. If it works better, maybe set the timeout to 10 instead of 1000. there is no difference in performance, no matter what value i use for 'timeout'. on my box, sending the message (in byte representation) from the benchmark test 1000 times takes ~90ms for [tcpserver]. the same (in ascii presentation) sent with [netserver] takes around 8ms. the only difference i can see with lower ( 10us) timeout value is, that messages on the receiving side (client) are messed up, completely lost, partially cut or concatenated together. on my box, the new [tcpserver] with 'timeout' set to 0 performs much worse than the old version with the buffer overrun problem. Maybe just calling select slows everything down then. It seems to be a trade-off between speed and reliability. You should really send udp packets, then nothing hangs if the other end doesn't receive them. You could still have a low-bandwidth tcp connection open to test the connection. have you tested on windows only? i haven't tried windows yet. how
Re: [PD-dev] [tcpserver]: bad performance of new version
Roman Haefeli wrote: On Thu, 2009-04-30 at 10:17 -0400, Martin Peach wrote: Roman Haefeli wrote: i ve been testing the new netpd-server based on the new [tcpserver]/[tcsocketserver FUDI] now for a while and definitely could solve some problems, but some new ones were introduced. i found, that the most recent version of [tcpserver] peforms quite bad cpu-wise. this has some side-effects. in netpd, when a certain number of users are logged in (let's say 16), it can happen, that the traffic of those clients makes the netpd-server use more than the available cpu-time. i made some tests and checked, if all messages come through and if messages delivered by the server are still intact. under normal circumstances, there is no problem at all. but under heavy load, when the pd process is demanding more than available cpu time, some messages are corrupted or lost completely; in the worst case the pd process segfaults, at the moment of a client connecting or disconnecting. i guess, this is due to some buffer under- or overrun between pd and the tcp stack, but i don't really know. Hi Roman, Did you try using the new [timeout( message? The latest version of tcpserver defaults to a 1ms timeout, so if you have a bunch if disconnected clients, Pd will hang for 1ms each, which will quickly add up to more than the audio block time and then Pd will start thrashing and eventually die or become comatose, as it were. no, i haven't tried this parameter yet. but i sure will do and report back, when i can tell more about how it behaves. i haven't fully understood, what it does and what it can be used for. could you elaborate that a bit more? yet it sounds a bit strange to me, that i need to tweak a networking object with a time value for correct operation. When you send some message through tcpserver, the send routne first checks to see if it can be sent. The call to do this is a function known as select, which has a timeout parameter. The select call returns as soon as the socket is available or the timeout expires, whichever comes first. If the socket is blocked, select would never return if there was no timeout. So I gave the call a default 1ms timeout. This could all be done using threads as well but I just don't know when I'll have time to do it. I still don't see that it would solve your problem anyway, if your application insists on sending to disconnected clients, you would have lots of threads sitting around, and still get no feedback about the connection. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [tcpserver]: bad performance of new version
Roman Haefeli wrote: On Fri, 2009-05-01 at 09:16 -0400, Martin Peach wrote: Roman Haefeli wrote: On Thu, 2009-04-30 at 10:17 -0400, Martin Peach wrote: Roman Haefeli wrote: i ve been testing the new netpd-server based on the new [tcpserver]/[tcsocketserver FUDI] now for a while and definitely could solve some problems, but some new ones were introduced. i found, that the most recent version of [tcpserver] peforms quite bad cpu-wise. this has some side-effects. in netpd, when a certain number of users are logged in (let's say 16), it can happen, that the traffic of those clients makes the netpd-server use more than the available cpu-time. i made some tests and checked, if all messages come through and if messages delivered by the server are still intact. under normal circumstances, there is no problem at all. but under heavy load, when the pd process is demanding more than available cpu time, some messages are corrupted or lost completely; in the worst case the pd process segfaults, at the moment of a client connecting or disconnecting. i guess, this is due to some buffer under- or overrun between pd and the tcp stack, but i don't really know. Hi Roman, Did you try using the new [timeout( message? The latest version of tcpserver defaults to a 1ms timeout, so if you have a bunch if disconnected clients, Pd will hang for 1ms each, which will quickly add up to more than the audio block time and then Pd will start thrashing and eventually die or become comatose, as it were. no, i haven't tried this parameter yet. but i sure will do and report back, when i can tell more about how it behaves. i haven't fully understood, what it does and what it can be used for. could you elaborate that a bit more? yet it sounds a bit strange to me, that i need to tweak a networking object with a time value for correct operation. When you send some message through tcpserver, the send routne first checks to see if it can be sent. The call to do this is a function known as select, which has a timeout parameter. The select call returns as soon as the socket is available or the timeout expires, whichever comes first. If the socket is blocked, select would never return if there was no timeout. So I gave the call a default 1ms timeout. ok. i think, i understand. thanks for the explanation. This could all be done using threads as well but I just don't know when I'll have time to do it. no hurry. it's not the case, that i know, that threading would help for the issues, i am experiencing. i just wanted to have my troubles reported. and i think, i read somewhere about server implementations, that they often use a separate thread for each socket. I still don't see that it would solve your problem anyway, if your application insists on sending to disconnected clients, you would have lots of threads sitting around, and still get no feedback about the connection. the only feedback needed: was something actually sent or not? if you (or the patch) _know_, that messages are not received by the other end, then you (the patch) can handle the situation somehow. anyway, that is the part that seems to be already working. by using the current [tcpserver], you notice, if the other end vanished or is still listening. the problems i currently encounter are coming from the fact, that the performance of the new version is probably 20 times worse than the version included in current stable pd-extended. for me its a problem, since with a certain sane number of clients connected (let's say 16), it already overloads the cpu of a 1.7GHz pentium m processor. why the big difference to the previous version? If you set the sending timeout to zero (by sending [timeout 0( message to [tcpserver] )then the performance should be the same as the older version. AFAIK that's all I changed. Did you try that yet? If not, something else is causing the slowdown. If it works better, maybe set the timeout to 10 instead of 1000. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [tcpserver]: bad performance of new version
Roman Haefeli wrote: i ve been testing the new netpd-server based on the new [tcpserver]/[tcsocketserver FUDI] now for a while and definitely could solve some problems, but some new ones were introduced. i found, that the most recent version of [tcpserver] peforms quite bad cpu-wise. this has some side-effects. in netpd, when a certain number of users are logged in (let's say 16), it can happen, that the traffic of those clients makes the netpd-server use more than the available cpu-time. i made some tests and checked, if all messages come through and if messages delivered by the server are still intact. under normal circumstances, there is no problem at all. but under heavy load, when the pd process is demanding more than available cpu time, some messages are corrupted or lost completely; in the worst case the pd process segfaults, at the moment of a client connecting or disconnecting. i guess, this is due to some buffer under- or overrun between pd and the tcp stack, but i don't really know. Hi Roman, Did you try using the new [timeout( message? The latest version of tcpserver defaults to a 1ms timeout, so if you have a bunch if disconnected clients, Pd will hang for 1ms each, which will quickly add up to more than the audio block time and then Pd will start thrashing and eventually die or become comatose, as it were. I think you need to experiment with different values for the timeout. Set it to zero and it should give the same results as the previous version; maybe try something around 100 instead of the default 1000 (it's in microseconds). The other way to fix this in the tcpserver source is to make a new thread for each client, but I'm afraid that will just open another can of worms/zombies. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] open_via_path() weirdness
IOhannes m zmoelnig wrote: hi all, in the course of trying to find the filehandle-leak bug in Gem i found a weird problem with open_via_path(). can anybody find anything wrong with the attached code? if not, try the attached patch as well. A minor thing is that you use #ifdef __WIN32__ instead of #ifdef MSW, which may or may not work. everything works fine on linux, but on w32 i cannot close the file-handle anymore (i get an errno of EBADF, which means that fd isn't a valid open file descriptor). which in turn results in a filehandle leak. I don't know if it's related but I had trouble with the very similar canvas_open on WinXP in the [which] object. I compiled it with VisualStudioC++2005ExpressEdition against various pd.libs from Miller's site. Every time Pd would crash whenever i tried to use the fd, although the same code runs fine on linux (no need for a pd.lib there). So imagine my surprise when which works fine when built as part of pd-extended on Hans' machine. So I think that I'm seeing some incompatibility of the dlls as made with MinGW and VC. Martin i notice that hardly anyone (esp. Pd itself) uses open_via_path(). is there a reason for that? is it buggy? (couldn't find anything wrong though) i use it quite a lot, e.g. in [msgfile]; i guess nobody ever tried to open 1000 files with msgfile on w32, so the error never appeared... fgamsdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] win32 build farm 'msys.exe' (WAS: symlinks render pdstring unbuildable on MinGW/Windows)
Bryan Jurish wrote: This is still stumping me. The win32 build farm machine's config.log is showing me (for externals/moocow/locale): configure:2701: gcc \ -DPD -O2 -mcpu=i586 -mtune=pentium3 \ -I/home/pd/auto-build/pd-extended/pd/src \ -Wall -W -ggdb \ -I/home/pd/auto-build/pd-extended/Gem/src \ -mms-bitfields \ -DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' \ -D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' \ -L/home/pd/auto-build/pd-extended/pd/bin \ conftest.c 5 command line:4:1: macro names must be identifiers command line:5:1: macro names must be identifiers command line:6:1: macro names must be identifiers command line:7:1: macro names must be identifiers I'm guessing here but it looks like the 4th, 5th 6th and 7th defines in the command line are causing trouble. Indeed they are not identifiers as such, they are just strings. One thing that looks odd is the single quote '' instead of the more commonly used . Without knowing what that particular combo of gcc and shell most enjoys, I would change that and see what happens next. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] library finding it's own path?
zmoel...@iem.at wrote: hi all. does anybody know of a nice way for an external object/library to find out it's own path (at the time of loading the external)? my current solution involves way too many Pd-internals (like accessing the c_externdir member of the t_class structure) Have a look at the source for [mrpeach/which] in svn. I took some code from Pd internals and it calls some more, but maybe not _way_ too much. What's missing from it is a way to know if a name refers to an internal. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [tcpserver]: new 'clientbuf' method seems to be buggy
Roman Haefeli wrote: On Mon, 2009-04-06 at 21:26 +, martin.pe...@sympatico.ca wrote: Spoke too soon. On Debian setting the buffer to any size always returns me 2048, so that's no good. On WinXP some values (1,2) do what you said. Others (10,12) don't. I'm not sure what to do about that. It seems to be the OS. here, what [tcpserver] reporst as the used buffersize, is always twice the number i send. for numbers below 1024, 2048 is reported. for numbers higher than 131071, always 262142 is reported. It's completely up to the operating system to manage the buffers the way it chooses. If you ask for a buffer of a certain size you can get anything above that size as a result. So Linux appears to never go below 2048 while Windows gives you whatever you ask for. Anyway, today I changed [tcpserver] and [tcpclient] in svn to use a default 1ms timeout in the select call before sending each byte. This seems to give the buffer time to clear before attempting to send the next byte. You can change the timeout in microseconds with the [timeout( message if you want to tweak it. A value of zero works most of the time but the problem of dropped data seems to disappear if you use about 1ms. The timeout should normally not delay Pd because it only comes into effect when the buffer is not emptying fast enough. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] How to pass indeterminate args to a thread
B. Bogart wrote: I'm now getting a segfault when trying to access a member of the structure in the thread function: #0 0xf7d531cb in strlen () from /lib/i686/cmov/libc.so.6 #1 0xf7d1f648 in vfprintf () from /lib/i686/cmov/libc.so.6 #2 0xf7d43e04 in vsnprintf () from /lib/i686/cmov/libc.so.6 #3 0x080c68d6 in post (fmt=0xf7f7db5a My symbol: %s) at s_print.c:51 #4 0xf7f7d829 in mythread () from /home/bbogart/src/gphoto/src/pd-external/gphoto2.pd_linux The way I'm trying to access the member is as follows: post(My symbol: %s, ((struct floatArgStruct *)threadArgs)-s-s_name); You called pthread_create() with threadargs: ret = pthread_create( thread1, NULL, mythread, threadArgs); when you probably should just use threadargs, since it's already a pointer. Or else you need to dereference the handle: post(My symbol: %s, ((*(struct floatArgStruct**))threadArgs)-s-s_name); Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] How to pass indeterminate args to a thread
Mathieu Bouchard wrote: On Fri, 27 Feb 2009, Martin Peach wrote: You called pthread_create() with threadargs: ret = pthread_create( thread1, NULL, mythread, threadArgs); when you probably should just use threadargs, since it's already a pointer. Or else you need to dereference the handle: post(My symbol: %s, ((*(struct floatArgStruct**))threadArgs)-s-s_name); No, it was supposed to be just threadArgs, but the type of threadArgs changed while writing the code, as I made him change it from a global variable to a malloc. In the end, it turns out it wasn't quite useful, because there's only going to be one extra thread, after all. Too bad, you could have tested if the compiler could handle types changing while the code was being written. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Frank Barknecht wrote: Hallo, Martin Peach hat gesagt: // Martin Peach wrote: Well isn't it just easier to use something with a different name? If you have a backwards [pow] why not just call it [backwardspow] instead of letting users guess which [pow] is the right one? If a former external becomes a builtin in some future Pd version, you cannot use something with a different name, you can only rename the old external to something else. And what if the new builtin name was used by different, conflicting classes? What if Pd gets a [counter] builtin as is sometimes requested? I suggest that the first object to use the name 'owns' the name and any subsequently invented objects use different names. That's all. If there's already a [counter] then Pd's new builtin counter would have to be called [pdcounter] or something. The name doesn't affect the function, and usually is not much use beyond being a unique identifier. You still need to look at the help patch to know what any version of [counter] actually does. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
IOhannes m zmoelnig wrote: Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: they could, but it was an effort to do so. any ordinary external would not be able to do it. So am I understanding it correctly, that Zexy's [pack] is not doing the fuddling Cyclone does and now suddenly became an object that overwrites internals by changes in Pd 0.42? exactement! because i didn't do any fudlling (well knowing that zexy's [pack] is not ready to replace Pd's [pack]; but stating the intention to become so LATER by using class_new(pack) - thinking that this was a safe thing to do), i was shocked that suddenly my pack would be used instead of the vanilla one. I guess it never occurred to any of you to use objects with different names... Or else why not just call every pd object object and then use paths to access them, like [pd/some/library/subdirectory/object]? Just kidding in a frustrated sort of way. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
IOhannes m zmoelnig wrote: Martin Peach wrote: I guess it never occurred to any of you to use objects with different names... Or else why not just call every pd object object and then use paths to access them, like [pd/some/library/subdirectory/object]? Just kidding in a frustrated sort of way. i don't get you point. why it might seem questionable to want to override a given function with a supposedly better one, i don't see why i should bully anyone who wants to do that... Well isn't it just easier to use something with a different name? If you have a backwards [pow] why not just call it [backwardspow] instead of letting users guess which [pow] is the right one? Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended'sdefault libs]
Hans-Christoph Steiner wrote: Different names are a good idea, for sure. But Pd should also not go down in flames if someone happens to create an object with a name that is already used somewhere. Its not possible to know every single object that has ever been made. I just ran into this myself trying to create an abstraction called beat. Apparently, there is already a [beat], so I got unexpected results. Maybe a [which] object could help. Banging a [which pow~] would output the path to the pow~ that pd was using. Inputting a path would tell pd to use that one. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [tcpsocketserver] - a protocol-aware wrapper around [tcpserver]
IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: This looks very cool, we need an easy to use OSC replacement for dumpOSC/sendOSC. One thing, I get this when I load them: unpackOSCstream ... couldn't create unpackOSCstream ... couldn't create packOSCstream ... couldn't create packOSCstream ... couldn't create afaik, they are in mrpeach/osc (as has been discussed on some list: the problem with tcp/ip as a transport of OSC being a stream-based protocol rather than packet-based) They are there in svn at least. I just committed the tcpsocketserver abstractions in the same place. I haven't had time to test them though... Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] startup order for pd/pd-gui
Hans-Christoph Steiner wrote: One thing that is twisting my brain into knots is the startup order/ procedure. It is not very easy to follow and different on each platform. This is something I would really like to smooth out. Right now, I am looking for tips on figuring out everything that is going on. I've searched around some, but am not finding any archived discussions. Anyone have some tips or know about where some stuff might be written? .hc Here are my notes from an earlier version, so they may not be up to date: Here we will trace the flow of control through the various parts of pd as pd starts up. *** pd / pd.exe *** PD starts in s_entry.c, where two types of main function, one for MSW and the other for Unix (linux and OSX (and Cygwin, we hope)), call sys_main(argc, argv), which is in s_main.c. On Windows, s_entry.c is the only file compiled into pd.exe. The rest ends up in pd.dll, which is linked to pd.exe. This is done so that externs will be able to link back to functions defined in pd. main() in s_entry.c calls: | |-sys_main in s_main.c calls: | |-pd_init(): in m_pd.c, calls: | | | |-mess_init(): in m_class.c sets up the builtin symbols s_pointer, s_float, | | s_symbol, s_bang, s_list, s_anything, s_signal, s__N, s__X, | | s_x, s_y, and s_, as well as the classes pd_objectmaker, | | for making boxes and pd_canvasmaker for making canvases. | | pd_canvasmaker is bound to the symbol s__N (#N, i.e. a new window). | | pd_objectmaker gets a pointer to new_anything(). | | | |-obj_init(): in m_obj.c sets up a generic inlet_class and adds pointers to | | inlet_bang, inlet_pointer, inlet_float, inlet_symbol, inlet_list, | | and inlet_anything. | | Also sets up specific pointerinlet_class, floatinlet_class, and | | symbolinlet_class. | | | |-conf_init(): in m_conf.c calls setup functions for the builtin objects. | | m_pd_setup() sets up the bindlist class that allows the binding | | of several objects to the same symbol, the way pointerinlet_class, | | floatinlet_class etc. are all bound to the symbol inlet | | | |-glob_init(): in m_glob.c sets up a pd class to respond to messages like open, quit, and the | symbols for the audio and MIDI dialogs, (and watchdog on Non-MacOSX unix). | |-sys_findprogdir(argv[0]): in s_main.c finds the path to the pd program, and from there | decides what sys_libdir and sys_guidir should be. | |-sys_loadpreferences(): in sfile.c, loads a file named .pdsettings from the user's home directory | (Unix), or (Windows) gets preferences from the registry. | |-sys_rcfile(): (non-Windows only) in s_path.c, attempts to load and parse a file named .pdrc (STARTUPNAME) | |-sys_argparse(): in s_main.c attempts to parse the command line arguments in the same way as | the .pdrc file. (sys_rcfile also calls sys_argparse). | |-sys_afterargparse(): in s_main.c sets the midi and ausio parameters according to the preferences | | that were loaded from .pdrc and the command line. Calls: | | | |-sys_open_audio(): in s_audio.c: opens audio in platform-specific manner | | | |-sys_open_midi(): in s_midi.c: opens midi in platform-specific manner | |-sys_startgui(sys_guidir-s_name): in s_inter.c sets up some signal handlers, opens a TCP socket (sys_guisock) | | on port 5400 (FIRSTPORTNUM) and then forks. | | *The child starts the gui process: | | *Under unix, the environment variables TCL_LIBRARY and TK_LIBRARY are declared | | *and the pd-gui program is called with the paths to tcl and tk libs, the pd.tk script and the port number as arguments: | | */bin/sh sh -c TCL_LIBRARY=LIBDIRPATH/tcl/library TK_LIBRARY=LIBDIRPATH/tk/library GUIDIRPATH/pd-gui 5400 | | *where LIBDIRPATH = sys_libdir-s_name, usually /lib/pd, and GUIDIRPATH = guidir, usually /lib/pd/bin | | *On Windows and MacOSX, the Wish shell is spawned and fed the pd.tk script. | | *The child exits, doesn't return. | | *On non-MacOSX unix platforms the parent thread opens a pipe, then forks again: | | **The child gives itself a higher priority by calling sys_set_priority(1) and | | **calls the shell to execute pd-watchdog. From the code: | | **To prevent lockup, we fork off a watchdog process with higher real-time priority than ours. The GUI has to send | | **a stream of ping messages to the watchdog THROUGH the Pd process which has to pick them up from the GUI and forward | | **them. If any of these things aren't happening the watchdog starts sending stop and cont signals to the Pd process | | **to make it timeshare with the rest of the system. (Version 0.33P2 : if there's no GUI, the watchdog pinging is done | | **from the scheduler idle routine in this process instead.) | | **The child exits. | | *The parent sets itself to another priority by calling sys_set_priority(0).
Re: [PD-dev] Pd 0.42-0 test 6 available
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
IOhannes m zmoelnig wrote:
speaking of adding things to the Pd API...
is it totally out of your ways to
- add a function that returns the version of Pd?
something like const char* pd_versionstring(void) would be nice.
this could be used to ensure that an external is running with a Pd
version compatible to the one it was compiled against
Since the version will most likely be used for a numeric comparison, and
it is stored as a number, perhaps it makes sense to return numeric types
instead of a char*?
int pd_majorversion(void)
int pd_minorversion(void)
int pd_bugfixversion(void)
personally i don't care so much for the details.
i proposed the string as it outputs the full version number (with all
test and whatnot).
Why not add 4 global variables
EXTERN t_int pd_majorversion;
EXTERN t_int pd_minorversion;
EXTERN t_int pd_bugfixversion;
EXTERN t_symbol pd_testversion;
...to m_pd.h, which would be initialized when pd starts up from the #defines
PD_MAJOR_VERSION, PD_MINOR_VERSION, PD_BUGFIX_VERSION and PD_TEST_VERSION?
Or make it a struct:
typedef struct
{
t_int major_version;
t_int minor_version;
t_int bugfix_version;
t_symbol test_version;
} t_pd_version;
EXTERN t_pd_version pd_version;
Martin
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd 0.42-0 test 6 available
IOhannes m zmoelnig wrote: Martin Peach wrote: personally i don't care so much for the details. i proposed the string as it outputs the full version number (with all test and whatnot). Why not add 4 global variables because global variables suck Oh. OK then. There seem to be quite a lot of them in pd though. Is there is a reason why they aren't all hidden behind accessor functions? Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pointer to struct messages
Isidro Gonzalez wrote:
Say we are programming an external and we have a
user-defined struct like:
typedef struct {
float dist[8];
float ang[8];
float gain[8];
}loudspeakers;
Is there a way to output and receive
a pointer to this struct from and to oulets and inlets
of pd objects and so communicate
the data between them?
One way would be to convert a text representation of the pointer into a
symbol and send that:
char buf[9];
/*each byte of the pointer will be printed as two hex characters*/
loudspeakers *pointer_to_loudspeakers;
t_symbol a_symbol;
sprintf(buf, %p, pointer_to_loudspeakers);
a_symbol = gensym(buf);
Then send a_symbol to other objects.
A symbol method in the receiver would convert the symbol name back into
a pointer with:
sscanf(s-s_name, %p, (void*)pointer_to_loudspeakers);
Another way, that uses no c, would be to load the 24 floats into a table
and access it by name using [tabread loudspeakers] and [tabwrite
loudspeakers].
Martin
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-extended on windows -open patch
patrick wrote: hi, i am making a video tutorial on how to install and use pd-extended / pdmtl on windows. i want to load a patch when opening puredata. i've installed puredata extended in C:/Program Files/pd (default). the patch that i want to load is located in C:/Program Files/pd/extra/pdmtl/1.browser.pd i did modify the startup box by adding -open C:/Program Files/pd/extra/pdmtl/1.browser.pd (after -helppath), but it's crashing pd (had to reinstall it). putting the patch in C:/ and -open C:/1.browser.pd is working. anyone can help me? Did you try putting the path in quotes like: C:/Program Files/pd/extra/pdmtl/1.browser.pd? Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to compile pdstring from moocow?
Roman Haefeli wrote: 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 For some reason PACKAGE_VERSION is defined here: externals\build\src\any2string.c(1):#define PACKAGE_VERSION CVS I think it should properly be defined in a .h file that is #included by the above files. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [declare -stdpath]: does it work?
Roman Haefeli wrote: hi all i have [tcpserver] from mrpeach installed in: /usr/local/lib/pd/extra/mrpeach/tcpserver.pd_linux and i have a patch with: [declare -stdpath extra/mrpeach] [tcpserver] however, [tcpserver] doesn't instantiate. as verbose output i get: tried /home/roman/extra/mrpeach/tcpserver.l_i386 and failed tried /home/roman/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver.pd_linux and failed tried /home/roman/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.l_i386 and failed tried /home/roman/tcpserver/tcpserver.l_i386 and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.l_i386 and failed tried /home/roman/extra/mrpeach/tcpserver/tcpserver.pd_linux and failed tried /home/roman/tcpserver/tcpserver.pd_linux and failed tried /usr/local/lib/pd/extra/tcpserver/tcpserver.pd_linux and failed tried /home/roman/extra/mrpeach/tcpserver.pd and failed tried /home/roman/tcpserver.pd and failed tried /usr/local/lib/pd/extra/tcpserver.pd and failed tried /home/roman/extra/mrpeach/tcpserver.pat and failed tried /home/roman/tcpserver.pat and failed tried /usr/local/lib/pd/extra/tcpserver.pat and failed tcpserver couldn't create it seems, that [declare -stdpath] is completely ignored. do i oversee something or is [declare -stdpath] broken? this is with pd-vanilla 0.41 on ubuntu hardy (without any ~/.pdrc nor any other preference file) i'll post a bug report, if someone can confirm it, but i would like someone else to confirm it first, since i am a bit cautious with bugreports about declare, since there's lots that someone can (me) do wrong when testing it. Yes it never works for me either on pd-extended; you have to do [mrpeach/tcpserver], or take tcpserver.pd_linux out of mrpeach and put it into /usr/local/lib/pd/extra. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sms pd external - design choices
Hans-Christoph Steiner wrote: It would be great to have people start using this string/blob functionality, but it needs to be changed so that it'll work without patching Pd itself. IOhannes outlined this idea, and we talked about it briefly in the past. This current implementation of the string patch will need to be removed from the next release of Pd-extended (and should have been removed from this release). The core of the idea that IOhannes mentioned is just declaring an external type number and using that, rather than patching Pd. It sounds like a good idea but I really don't understand how it can work. I would code it but I don't know what to code :( It seems to me that if a type is unknown to Pd it will not be processed. Last time it took me about two weeks to get the string patch to work, and I don't seem to have that kind of time any more, so maybe IOhannes, who knows how to do it, could give it a go? Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sms pd external - design choices
Rich E wrote:
Now, I want to turn write a set of externals using a buffered
analysis. Originally, I thought that all operations to the buffer
would happen using one external, but this now seems like it will get
too messy once anything more than basic operations are attempted
(something like cross-synthesis would take enough code to constitude
its own external). So, I have decided that, like the process of SMS,
the different modes of operation should be seperated into analysis,
synthesis, and editing. However, they would all still need access to
the same buffer (which could also be its own external, or possibly be
inside the analysis external).
So now I am looking for a way to make it where various externals have
access to the same buffer - a data structure containing a header and
sequential frames of analysis.
I originally thought that outputting a pointer would be the easiest,
but then realized that pd can output 'gpointers', which are not the
same as a void pointer. So it does not look possible to pass a
regular c pointer around in pd land.
If you have pd-extended or apply the string patch
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/packages/patches/add_string_support.patch?view=log
, you can use t_blobs as a kind of atom:
typedef struct _blob /* pointer to a blob */
{
unsigned long s_length; /* length of blob in bytes */
unsigned char *s_data; /* pointer to 1st byte of blob */
} t_blob;
It's totally up to you as The Programmer to keep track of the memory, Pd
only passes the pointers around.
Martin
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Messaging between Pd and GUI
Samuel Tarakajian wrote: That's exactly what I was hoping to do: communicate with the Pd core though a socket connection. The real question is how to do that. Setting up the connection is easy, but I have no idea what kind of messages Pd core is expecting. Is there a list somewhere? You can look in the source code for calls to sys_vgui(). Also starting pd with -d1 -d2 or -d3 prints the gui messages as they occur (-d1 prints messages from pd to pd-gui, -d2 prints messages from pd-gui to pd, -d3 prints both types). And pd.tk is where the tcl/tk procs that communicate with pd are found. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] setup() for hex loader
IOhannes m zmoelnig wrote: apart from that, the same thing is also possible with M$VC, you just have to specify it differently. i think it is via _DLL_InitTerm() or the like. the only problem about it is, that it is so hard to google. i haven't found many references to _DLL_InitTerm() (and some ofthem refer to OS/2). i think the proper way to do it is to use DllMain() http://msdn.microsoft.com/en-us/library/ms682583.aspx Are you sure it's not GetProcAddress() that you want? s_loader.c line 262 uses it... http://msdn.microsoft.com/en-us/library/ms683212.aspx Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
Could someone point me to IOhannes' technique? If it makes sense I'll give it a go during the next week. Martin From: Hans-Christoph Steiner [EMAIL PROTECTED] To: pd-dev List pd-dev@iem.at Subject: [PD-dev] removing string types from pd-extended release Date: Thu, 8 May 2008 20:44:09 +0200 Hey, We talked about this in the recent past. Could someone who knows the details remove the declarations of the string type from branches/pd- extended/0.40? Or shall I just remove the whole patch? I want to include string support, but using the technique that IOhannes laid out, which should be possible without patching Pd (AFAIK). .hc Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing string types from pd-extended release
I've attached the reasoning behind my string patch, probably there is a
lot wrong with it.
But I can't see how to do this kind of thing otherwise without modifying Pd.
Martin
Hans-Christoph Steiner wrote:
I don't know the details, but I believe it was just choosing an
unused number to represent the type. Then also not using a keyword.
Ultimately, there could be something like /etc/services where we can
register these numbers. Or maybe they could just be included in the
Pd headers.
http://lists.puredata.info/pipermail/pd-dev/2008-04/011257.html
.hc
On May 8, 2008, at 10:33 PM, Martin Peach wrote:
Could someone point me to IOhannes' technique? If it makes sense
I'll give it a go during the next week.
Martin
From: Hans-Christoph Steiner [EMAIL PROTECTED]
To: pd-dev List pd-dev@iem.at
Subject: [PD-dev] removing string types from pd-extended release
Date: Thu, 8 May 2008 20:44:09 +0200
Hey,
We talked about this in the recent past. Could someone who knows the
details remove the declarations of the string type from branches/pd-
extended/0.40? Or shall I just remove the whole patch? I want to
include string support, but using the technique that IOhannes laid
out, which should be possible without patching Pd (AFAIK).
.hc
-
---
Using ReBirth is like trying to play an 808 with a long stick.-
David Zicarelli
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
All information should be free. - the hacker ethic
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
I think it would be most efficient to have a string type be a length followed
by that many unsigned chars,
similar to a Pascal string but with the length being something like a 32-bit
integer.
It would not be added to pd's symbol list. The atom whose type was string would
have
to contain a pointer to the first byte of the string, and a length. Multibyte
characters would just
be counted as multiple characters when calculating the length, so the length
would be the number of bytes
in the string, not the number of characters.
It looks too easy to me...In m_pd.h, add:
A_STRING
to t_atomtype at line 139 of m_pd.h.
Add
t_string * w_string;
to t_word at line 122 of m_pd.h.
Add the typedef:
typedef struct _string /* pointer to a string */
{
unsigned long s_length; /* length of string in bytes */
unsigned char *s_data; /* pointer to 1st byte of string */
} t_string;
at line 106 of m_pd.h
...so a string atom would have a_type = A_STRING and a_w = a_w.w_string, which
points to a t_string containing
the length and a pointer to the string.
This we did first and now we are compiling pd on linux to see if it breaks
anything...not so far.
If pd is otherwise able to handle atom types it doesn't know about (?), all the
string manipulation objects could
be built as externals.
As I see it the atom types are defined in m_pd.h and registered in m_class.c,
which would need to have functions added
to it to handle string, like adding:
t_symbol s_string ={string, 0, 0};
to the list of t_symbols around line 555, and changing:
static t_symbol *symlist[] = { s_pointer, s_float, s_symbol, s_bang,
s_list, s_anything, s_signal, s__N, s__X, s_x, s_y, s_};
to:
static t_symbol *symlist[] = { s_pointer, s_float, s_symbol, s_bang,
s_list, s_anything, s_signal, s__N, s__X, s_x, s_y, s_, s_string};
...and pd_typedmess needs a handler for string messages around line 658:
if (s == s_string)
{
if (argc == 1) (*c-c_stringmethod)(x, argv-a_w.w_string);
else goto badarg;
return;
}
...and a handler for messages with string arguments with other names, just
befor case A_SYMBOL, line 728:
case A_STRING:/* MP 20070106 string type */
post(pd_typedmess A_STRING);
if (!argc) goto badarg;
if (argv-a_type == A_STRING)
{
post(argv-a_type == A_STRING, argc = %d, narg= %d, argc,
narg);
*ap = (t_int)(argv-a_w.w_string);
mp = 1;
}
argc--;
argv++;
narg++;
ap++;
break;
Still in m_class.c, around line 344 we add:
void class_addstring(t_class *c, t_method fn)
{
c-c_stringmethod = (t_stringmethod)fn;
}
This is used to register a string handler with pd so that incoming strings will
be sent to fn.
We added:
else if (sel == s_string) /* MP 20070106 string type */
{
post(class_addmethod: %p, fn);
if (argtype != A_STRING || va_arg(ap, t_atomtype)) goto phooey;
class_addstring(c, fn);
}
around line 300 of m_class.c in case someone calls
Re: [PD-dev] Undefined reference to 's_list'
Greg Surges wrote:
HI all,
I'm trying to compile some of my externals for Windows, and I'm running
into a strange error.
This code:
void *nrciOut_new() // constructor
{
t_nrciOut *x = (t_nrciOut *)pd_new(nrciOut_class);
outlet_new(x-x_obj, s_list);
return (void *) x;
}
Causes the linker to return an error:
undefined reference to 's_list'
Which linker are you using?
It may relate to the interpretation of EXTERN which is defined in
m_pd.h differently for MSW and gcc. Or you didn't link against pd.lib.
Also, you probably want to save the value returned by outlet_new in case
you want to actually use the outlet...
Martin
But if I change the s_list to '0' it seems to work... It seems strange
to me that the linker can find the rest of the PD libraries, but not the
s_list struct.
Has anyone run into anything similar?
Thanks much,
Greg Surges
--
http://www.uwm.edu/~gssurges/
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] string support and generic types
IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: I am fine with leaving the string patch in this release as it is if it will be compatible with a generic approach to defining new atoms types. Can anyone speak to that? does the patch still register the string keyword? (and in doing so breaks all other objects that use [string( without the string-atomtype?) The latest version registers the blob keyword instead, but I think it is not necessary for it to register a name at all. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] string support and generic types
Hans-Christoph Steiner wrote: Hey, IOhannes and Miller worked out a solution for declaring generic types, it didn't sound to hard to implement. For the next Pd- extended release, I think we'll probably should remove the Martin's string patch in favor of this approach. OK if the new method is implemented first, and documented as well ;) Then I will change [str] to fit. I'm using the str object a lot right now in my pd web server: http://132.205.142.13 Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] string support and generic types
It's mostly this patch, the sensor input comes from an arduino with a sonar attached. Still at the dangerous stage, implements a minimal http 1.1 server. It's pd-extended 0403 from today's autobuild. Martin From: Hans-Christoph Steiner [EMAIL PROTECTED] To: Martin Peach [EMAIL PROTECTED] CC: pd-dev@iem.at Subject: Re: [PD-dev] string support and generic types Date: Thu, 27 Mar 2008 16:12:01 -0400 On Mar 27, 2008, at 3:22 PM, Martin Peach wrote: Hans-Christoph Steiner wrote: Hey, IOhannes and Miller worked out a solution for declaring generic types, it didn't sound to hard to implement. For the next Pd- extended release, I think we'll probably should remove the Martin's string patch in favor of this approach. OK if the new method is implemented first, and documented as well ;) Then I will change [str] to fit. I'm using the str object a lot right now in my pd web server: http://132.205.142.13 Wow, that's nice. Is it Pd-extended per chance? Looking forward to trying that code! :) .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev webserverx.pd Description: application/puredata ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] make patch_pd fails builds on 10.5
This has to do with the add_string_support patch, which might conflict with some other patch. Does your m_obj.c have a union inletunion around line 12? If so does it have a field t_blob **iu_blobslot; in it? And is there a line #define i_blobslot i_un.iu_blobslot around line 34? ...because if you have that error, one of the above is missing. Martin Brandon Zeeb wrote: Yo Pd-dev, The 'make patch_pd' step prevents one from successfully building pd- extended on Mac os x 10.5. When after you've make patch_pd when you build pd-extended, you will get the following error: m_obj.c: In function blobinlet_new: m_obj.c:222: error: union inletunion has no member named iu_blobslot make[2]: *** [m_obj.o] Error 1 make[1]: [pd] Error 2 (ignored) make -C /Users/bz/Downloads/puredata-extended/pd/src BUILDLAYOUT_DIR=/ Users/bz/Downloads/puredata-extended/packages cvs_root_dir=/Users/bz/ Downloads/puredata-extended DESTDIR=/Users/bz/Downloads/puredata- extended/packages/darwin_app/build/Pd-0.41.4.app/Contents/Resources prefix= libpddir=/Users/bz/Downloads/puredata-extended/packages/ darwin_app/build/Pd-0.41.4.app/Contents/Resources OPT_CFLAGS=- march=pentium4 -msse2 -mfpmath=sse -ftree-vectorize -ftree-vectorizer- verbose=2 UNAME=Darwin install makefile:171: warning: overriding commands for target `../bin/pdtcl.dll' makefile:165: warning: ignoring old commands for target `../bin/ pdtcl.dll' cc -g -O2 -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno- parentheses -Wno-switch -DDL_OPEN -DMACOSX -DUNISTD -I/usr/X11R6/ include -I../portaudio/include -I../portaudio/src/ common -I../portaudio/src/os/mac_osx/ -I../portmidi/ pm_common -I../portmidi/pm_mac -I../portmidi/porttime - DUSEAPI_PORTAUDIO -DPA19 -DPA_USE_COREAUDIO -DNEWBUFFER -DMACOSX3 - DPA_BIG_ENDIAN -Wno-error -O2 -DUSEAPI_JACK -DINSTALL_PREFIX=\\ -c - o ../obj/m_obj.o m_obj.c m_obj.c: In function blobinlet_new: m_obj.c:222: error: union inletunion has no member named iu_blobslot make[2]: *** [m_obj.o] Error 1 make[1]: *** [pd_install] Error 2 make: *** [darwin_app_core] Error 2 Any insights? Cheers, ~Brandon ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] mrpeach external fails to build on OS X 10.5
I guess it's the line: tcpserver.c:89: error: syntax error before u_long which indicates that the compiler doesn't know what a u_long is. You could try uncommenting line 34: //#include sys/types.h or setting it to #include types.h Martin bsoisoi wrote: Hi Devs, I have a working setup for pd-extended on 10.5. Pd-extended fails to build when the mrpeach externals are set in LIB_TARGETS. Here is what I see: cc -DPD -march=pentium4 -msse2 -mfpmath=sse -ftree-vectorize -ftree- vectorizer-verbose=2 -I/Users/bz/Downloads/puredata-extended/pd/src - Wall -W -ggdb -I/sw/include -DMACOSX -DUNIX -Dunix -o /Users/bz/ Downloads/puredata-extended/externals/mrpeach/net/tcpserver.o -c / Users/bz/Downloads/puredata-extended/externals/mrpeach/net/tcpserver.c /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:89: error: syntax error before u_long /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:89: warning: no semicolon at end of struct or union /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:97: error: syntax error before } token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:97: warning: type defaults to int in declaration of t_tcpserver /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:97: warning: data definition has no type or storage class /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:104: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:105: error: syntax error before t_tcpserver /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:106: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:107: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:108: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:109: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:110: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:111: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:112: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:113: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:115: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c: In function tcpserver_socketreceiver_doread: /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:152: error: y undeclared (first use in this function) /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:152: error: (Each undeclared identifier is reported only once /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:152: error: for each function it appears in.) /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c: In function tcpserver_socketreceiver_read: /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:178: error: y undeclared (first use in this function) /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c: At top level: /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:245: error: syntax error before t_tcpserver /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c: In function tcp_server_send_bytes: /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:259: error: x undeclared (first use in this function) /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:259: error: client undeclared (first use in this function) /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:266: error: argc undeclared (first use in this function) /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:268: error: argv undeclared (first use in this function) /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c: At top level: /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:369: error: syntax error before * token /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c: In function tcpserver_send: /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:374: error: x undeclared (first use in this function) /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:379: error: argc undeclared (first use in this function) /Users/bz/Downloads/puredata-extended/externals/mrpeach/net/ tcpserver.c:385: error: argv undeclared (first use in this function)
Re: [PD-dev] calling external code(.dll) from pd-external(win32xp)
best boy wrote:
hi,
are there any examples (source.c) for calling a dll from within a pd
external?
This little bit from s_loader.c shows how pd loads externals, which are dlls
on Windows:
#ifdef MSW
{
HINSTANCE ntdll = LoadLibrary(filename);
if (!ntdll)
{
post(%s: couldn't load external scheduler lib , filename);
return (0);
}
externalmainfunc =
(t_externalschedlibmain)GetProcAddress(ntdll, main);
}
Martin
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] calling external code(.dll) from pd-external(win32xp)
best boy
maybe this is a misunderstanding. i try to explain.
i want to write a pd external (which will be a dll on win).
this pd external should contain code to call functions from another dll
which is not pd-related
I think you would still use the same two functions: LoadLibrary to load the
dll and GetProcAddress to find the address of the function you want to call.
It won't make any difference if you call the dll from another dll or an exe.
LoadLibrary() and GetProcAddress() are part of the Windows API and not
related to pd.
Martin
This little bit from s_loader.c shows how pd loads externals, which are
dlls
on Windows:
#ifdef MSW
{
HINSTANCE ntdll = LoadLibrary(filename);
if (!ntdll)
{
post(%s: couldn't load external scheduler lib , filename);
return (0);
}
externalmainfunc =
(t_externalschedlibmain)GetProcAddress(ntdll, main);
}
Martin
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd OSC implementation(s) incompatible with SC3? [Fwd: Re: [sc-users
Claude Heiland-Allen wrote: Thought this might be of interest to developers of OSC externals. In short: Pd OSC implementations should send OSC on the same port that they listen on, as that is the standard way OSC works. should but not must..., and OSC is transport independent so it has no concept of ports. In my work I default to replying on the same port but also implement messages like /replyto 9996 so I can route replies from multiple targets. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SVN access...
David Plans Casal wrote: On 18 Feb 2008, at 21:45, Mike McGonagle wrote: I was wondering if there is anything posted for accessing the SVN archives? I looked on the PureData.info site, and it still only has the CVS stuff. https://sourceforge.net/svn/?group_id=55736 svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data pure-data That gets you a really huge amount of data. svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals externals gets you just the externals. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] svn troubles
Hans-Christoph Steiner wrote: On Feb 17, 2008, at 5:00 AM, [EMAIL PROTECTED] wrote: Quoting Martin Peach [EMAIL PROTECTED]: Hi all, I tried running 'svn cleanup' from my externals directory but I get the same error. This is with cygwin svn 1.4.5 on WinXp. weird. what comes to my mind is: - are you sure you have enough space on your disk? (svn needs more space than cvs, as it caches the original copy of a file) - i have encountered problems on w32 with forbidden filenames, such as AUX and COM, but this doesn't seem to be the case here... - svn is less tolerant than cvs when it comes to collisions: e.g. if you have a file Hello.c and a file hello.c in the same directory and your local filesystem is case-insensitive, the checkout will fail. nevertheless, i haven't find a case-problem in the gridflow/doc/flow_classess folder. I think that's caused by files in SVN that have names with illegal characters for NTFS in them. For example * is not allowed in NTFS, but it is on Mac OS X and GNU/Linux. Strange that it didn't show up before in cvs. My local cvs copy doesn't have that file. Maybe it was quietly dropped. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] svn troubles
Hi all, I'm trying to check out the externals from sourceforge. I managed to get a copy of pd no problem. With externals I get a bunch of them but it stops with: ... A externals/gridflow/doc/flow/flow_classes/listelement-help.pd svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again svn: Can't open file 'externals/gridflow/doc/flow_classes/.svn/tmp/text-base/inv*-icon.png.svn-base': No such file or directory I tried running 'svn cleanup' from my externals directory but I get the same error. This is with cygwin svn 1.4.5 on WinXp. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] ui development / desiredata?
chris clepper wrote: On OSX the bottom right of the patcher window can be below the bottom of the screen - even at massive resolutions (1536 lines!). This makes it impossible to resize the window without manually editing the patch text. Some sort of check for max screen size should be in place. This is incidentally about the only app in the history of the MacOS that has done this. Apple's very own Picture Viewer did that when you zoomed in, at least on OS9. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] snprintf vs. sprintf_s?
Miller Puckette wrote: Hi Devs, I found out that .Net apparently doesn't use snprintf but has a similar function named sprintf_s. (A couple of recent patches change sprintfs to snprintfs leading to compile errors in .Net). I'm thinking of just putting the following in s_main.c and s_file.c: #ifdef MSW #define snprinf sprintf_s #endif My question: will this break cygwin or some other non-microsoft compiler for Windows? Probably. I did it like this in tcpclient.c, which compiles OK in pd-extended: #ifdef _MSC_VER #define snprintf sprintf_s #endif _MSC_VER is only defined for the microsoft compiler. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Error when crosscompiling pdlua
Frank Barknecht wrote: Hallo, Martin Peach hat gesagt: // Martin Peach wrote: With dlls you have to export symbols using a def file or /export: statement on the command line (or __declspec(dllexport) in the code with MSVC). On linux all symbols in a shared library are visible by default, it's about the structure of a windows dll versus that of a unix shared library, not gcc. So unless pd.dll is built with sys_loader exposed, I won't be able to build a loader-external, right? If so, then I'll let the MS-Windows-people take over building pdlua. Usually on Windows you link against pd.lib, not pd.dll, so it ought to work. You will need to include the header file containing sys_loader (except I can't find sys_loader anywhere in the pd source). Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Error when crosscompiling pdlua
Frank Barknecht wrote: some more info: Could this be related to Claude's findings mentioned in the lua.c file: /** Pd loader registration, defined in pd/src/s_loader.c but not exported. */ void sys_register_loader(loader_t loader); /** Pd extern dir declaration (for help finding), defined in pd/src/m_class.c but not exported. */ void class_set_extern_dir(t_symbol *s); If sys_register_loader is not exported, how are loaders meant to be built? And why does gcc not complain on native Linux using practically the same command line? With dlls you have to export symbols using a def file or /export: statement on the command line (or __declspec(dllexport) in the code with MSVC). On linux all symbols in a shared library are visible by default, it's about the structure of a windows dll versus that of a unix shared library, not gcc. Martin Frank Barknecht hat gesagt: // Frank Barknecht wrote: I fail to cross-compile pdlua on Debian for W32. This is my error: $ i586-mingw32msvc-gcc -I/lua-5.1.2/src/ -I./ -I/usr/include/ -shared lua5.1.dll pd.dll -o lua.dll lua.c /tmp/ccobudhL.o:lua.c:(.text+0x1bc4): undefined reference to `_class_set_extern_dir' /tmp/ccobudhL.o:lua.c:(.text+0x1c65): undefined reference to `_class_set_extern_dir' /tmp/ccobudhL.o:lua.c:(.text+0x1c92): undefined reference to `_class_set_extern_dir' /tmp/ccobudhL.o:lua.c:(.text+0x1e09): undefined reference to `_sys_register_loader' Info: resolving _s_ by linking to __imp__s_ (auto-import) collect2: ld returned 1 exit status This is with the precompiled lua5.1.dll from http://luabinaries.luaforge.net/download.html and the precompiled pd.dll from Miller's site, both 0.41 and 0.40 give the same error. I could remove the _class_set_extern_dir stuff from lua.c, but I'm quite sure that _sys_register_loader is important. Any ideas how to fix this? ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] freeverb's type-punned pointers
Hans-Christoph Steiner wrote:
Hey,
I want to fix the type-punned pointer problem in freeverb~ so it can
be compiled with full optimization. Here's the code snippets in
question, with the warnings being issued for the FIX_DENORM_NAN_FLOAT
() lines:
#define IS_DENORM_FLOAT(v) *(unsigned long*)(v))0x7f80)==0)
((v)!=0.f))
#define FIX_DENORM_NAN_FLOAT(v)((v)=IS_DENORM_NAN_FLOAT(v)?0.f:(v))
static inline t_float comb_processR(t_freeverb *x, int filteridx,
t_float input)
{
t_float output;
int bufidx = x-x_combidxR[filteridx];
output = x-x_bufcombR[filteridx][bufidx];
FIX_DENORM_NAN_FLOAT(output);
x-x_filterstoreR[filteridx] = (output*x-x_combdamp2) + (x-
x_filterstoreR[filteridx]*x-x_combdamp1);
FIX_DENORM_NAN_FLOAT(x-x_filterstoreR[filteridx]);
[snip]
Could I just cast things to (unsigned long)? Or is there a better way?
I think the proper way is to use a union, so you can refer to the same
thing as two different types.
Martin
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] No rule to make target `/usr/include/stdlib.h'
Hans-Christoph Steiner wrote: So this error is driving me mad: make: *** No rule to make target `/usr/include/stdlib.h', needed by `g_canvas.o'. Stop This is the first line of the first file that you're trying to compile, so it looks like the compiler isn't being specified. Turns out that in the makefile.mingw in pd/src (maybe not the same makefile you're using) the variable $(CC) is never defined; normally it should be set to point to gcc. Did some line(s) get dropped accidentally? Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] No rule to make target `/usr/include/stdlib.h'
Hans-Christoph Steiner wrote: make: *** No rule to make target `/usr/include/stdlib.h', needed by `g_canvas.o'. Stop This is the first line of the first file that you're trying to compile, so it looks like the compiler isn't being specified. Turns out that in the makefile.mingw in pd/src (maybe not the same makefile you're using) the variable $(CC) is never defined; normally it should be set to point to gcc. Did some line(s) get dropped accidentally? AFAIK, if CC is not defined, make automatically defines it. Or something does, at least, since when I echo $(CC), I get gcc. I tried manually defining it and it didn't change the error :( Did you try a make depend first? Just guessing... Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compile pd with cygwin
Patrice Colet wrote: Hello! I've added -mno-cygwin and -I/cygdrive/c/Mingw/include -L/cygdrive/c/Mingw/lib because: 1° The __WIN32 flag doesn't work with cygwin 2° there is a cruel conflict with errno.h cygwin version. So it's not possible to compile with cygwin without mingw, unless using voodoo... Well it seems like the Windows API that mingw provides is essential for the audio and midi interfaces, unless you have a precompiled portmidi and portaudio. The rest could be done in cygwin's pseudo-unix, probably not GEM though. I think if there was a tcl/tk for cygwin it would be even more compatible with the unix version. ... cc -g -O2 -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-s witch -mno-cygwin -DUSEAPI_PORTAUDIO -DPA_LITTLE_ENDIAN -DPA19 -I/cygdr ive/c/Mingw/include -L/cygdrive/c/Mingw/lib -I../portaudio/pa_common -I../po rtaudio/pablio -I../portaudio/pa_asio -I../portmidi/pm_common -I../portmidi/po rttime -I../portmidi/pm_win -I../portmidi/pm_win_ds -mms-bitfields -DINSTA LL_PREFIX=\/usr/local\ -c -o ../obj/g_canvas.o g_canvas.c g_canvas.c:58: erreur: un 'el'ement de l'initialisation n'est pas une constante g_canvas.c:59: erreur: un 'el'ement de l'initialisation n'est pas une constante Line 58: static t_symbol *canvas_newfilename = s_; Probably the compiler doesn't like this because _s is declared EXTERN which is configured for MSW instead of just extern. g_canvas.c:574: attention : canvas_makebindsym d'efini localement apr`es a voir 'et'e r'ef'erenc'e avec lien dllimport. It was prototyped in g_canvas.h as EXTERN t_symbol *canvas_makebindsym(t_symbol *s); In m_pd.h EXTERN is defined as: #ifdef MSW #ifdef PD_INTERNAL #define EXTERN __declspec(dllexport) extern #else #define EXTERN __declspec(dllimport) extern #endif /* PD_INTERNAL */ #else #define EXTERN extern #endif /* MSW */ so you probably need to avoid using MSW here for cygwin because the __declspec stuff only works with MSVC. The extern things must be accessible from outside the pd dll so you need to export the symbols somehow. ... == I have to give up for the moment, even if I've just replaced MSW with __WIN32 and added a few lines of codes to configure.in and makefile.in, it took me too much time for no satisfying results. Oh, too bad... I tried it a couple years ago as well and didn't get it to work either, but I learned a lot about the insides of pd;). Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compile pd with cygwin
Patrice Colet wrote: Hans-Christoph Steiner a écrit : That stuff wasn't removed from Pd, but instead never made it into Miller's sources. If you get this running smoothly, then I think it is likely to be included by Miller. The big thing to do would be to make the ./configure make work on Cygwin, then we'll have a unified build system on all platforms. One tip, when posting changes to code, you should post a diff -uw, otherwise it's hard to tell what you have changed. I don't think anyone here has s_midi.c memorized, but I could be wrong ;). Post the errors that you were getting before adding s_stuff.h and that will be easier to troubleshoot. Okay, let's start with these diff (I might have reversed the new and the old file, sorry for that, also I'll make separated diff files when make will run smoothly) and after that, there is my last error message (I didn't go further because s_inter.c seems linked to s_midi.c by the sys_close_midi() function, and I don't get how to deal with it) : $ diff -uw d_osc.c d_osc.c.old --- d_osc.c 2007-12-01 06:02:38.21875 +0100 +++ d_osc.c.old 2007-01-19 07:37:56.0 +0100 Yes that's a backwards diff... s_inter.o: dans la fonction sys_bail : /home/pat/pdextended/pd-extended/pd-extended/pd/src/s_inter.c:1276: r'ef'erence ind'efinie vers _sys_close_midi sys_close_midi has several incarnations but you must choose one. The MSW version uses portmidi, so if you can build portmidi then use s_midi_pm.c by specifying it in the makefile. s_file.o: dans la fonction sys_loadpreferences : /home/pat/pdextended/pd-extended/pd-extended/pd/src/s_file.c:292: r'ef'erence in d'efinie vers _sys_initloadpreferences sys_initloadpreferences in s_file.c also has a version for each platform. The MSW version looks in the registry for preferences but the unix version just uses the .pdsettings preferences file. I would go for the unix version because I dislike the opaqueness of the registry. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] widdling away flatspace
Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: What does the Debian package have to do with flatspace? The Debian package pd-externals was built from the externals/build/ src build system Günter set up years ago. The flatspace lib in Pd- extended is the contents of that build system. I know that both flatspace and the pd-externals deb are using the old build system, but I don't see how the existence or non-existence of the deb would influence the existence of flatspace in pd-extended. Maybe it has to do with some quantum physics entanglement issue, I didn't understand? ;) Anyway if all externals from flatspace are also included in other subdirectories of pd-extended then I don't see why pd-extended would need a flatspace. But I'm no pd-extended user, so probably someone else should comment. I use pd-extended and I think it would be a lot easier to use if _everything_ was in flatspace so I don't have to rewrite all my objects with the directory prefix and manually track down the help files. For example all the stuff in mrpeach could just as easily be in flatspace since none of it depends on anything else, there is no library file they all need except for pd itself. If any name conflicts arise I would just rename the offending objects. (Also I think the proper term is whittling which is like shaving wood from a stick, not widdling which is like urinating in a dribbly fashion ;)) Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: PD Strings
Mathieu Bouchard wrote: As long as you support strings that have embedded nulls, there is no difference between a string and a blob. Given the number of languages that support embedded nulls, you could safely call a blob a string. Yes they support anything at all that will fit into the available RAM, that's why string is too restrictive a term for it, so I changed the name to blob, and now Blob's your uncle... Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gem vs. mrpeach strings?
IOhannes m zmoelnig wrote: Martin Peach wrote: IOhannes m zmoelnig wrote: the [text3d]... objects expect a string message with pdstrings (according to moocows stuff). OK, so the message [string( is being interpreted by pd as a selector for A_STRING instead of just a message string, because string has become a reserved word. correct. my proposal is therefore to entirely skip reserved words when introducing new types and solely rely on the atom-type (A_BLOB), rather than the list selector. Fair enough, but that would mean changing the pd API, for instance the class_addmethod function, which wants a selector. Pd seems to use the type A_BLOB in some places and the selector s_blob in others, I'm not sure if it could be made to use only the type without breaking all the currently existing externals. do you have any strong reason why you need to reserve a selector when introducing a new atom-type? (apart from: that was the way it seemed to be done) That's right. I basically copied the way it was done for floats and lists. I tried not using a selector but things didn't work properly, like class_addmethod. If you can see how it could be made to work without the selector, please let us know. your string-patch adds a special message string for your strings. i think that is where the problem comes in: A_GIMME != A_STRING The latest version of the patch in cvs calls it A_BLOB instead of A_STRING. Does this resolve the issue? Or will it cause [blob( messages to go wrong? the problem is not with A_BLOB vs A_STRING, but with use of selectors. see above. True, I forgot to mention that I also changed the string selector to blob. Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gem vs. mrpeach strings?
Hans-Christoph Steiner wrote: On Nov 9, 2007, at 7:47 AM, IOhannes m zmoelnig wrote: hi Martin Peach wrote: Hans-Christoph Steiner wrote: Unfortunately, looks like I found another similar bug when loading [widget]. But [widget] fails to load at all: Well OK, I'm still not clear on why the string patch should be the cause any of that. i don't think that your string patch has anything to do with _that_ one. Yesterday I committed a change to the patch which just involves renaming string to blob. i think the problem is, that your patch introduces reserved symbols in the first place. personally i would remove the entire [string ...( message and replace it by a [list ...( (don't use a special selector) I would like to know if the problems go away with that. (What's a consistency check? It's c++, right?) no, it's a pd thing. you also get this when you use weird (that is: non pd-ish, user-defined) atoms and pd doesn't know how to handle them. i am currently thinking of a proposal for user-defined atom-types, which can be registered like classes and then be used by objects like [str],... and (that is the important thing) do not interfere with each other. i need this for a separate project, and it would be a cool feature for pd to have. What kind of other atom types are you thinking? Like int? I suppose to make Pd into a full-fledged programming language, it would be useful to be able to support things like 128-bit floats, 32-bit ints, etc.. It would be good to have a clean way to support new atom types like strings, it also seems that this feature could open up a big can of worms. I don't know why my posts are not getting through but the last one I sent explained where the consistency check error is coming from, and there is just no way it could be caused by the string type unless the patch is being improperly applied or gem is trying to use a string type, but then it should cause pd to not compile. Why did the string patch work for everything except gem for the past 6 months if it supposedly breaks everything? Martin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
